DNS体系结构

DNS是目前互联网上最不可或缺的服务器之一，每天我们在互联网上冲浪都需要DNS的帮助。DNS服务器能够为我们解析域名，定位电子邮件服务器，找到域中的域控制器……面对这么一个重要的服务器角色，我们有必要对它进行一番深入研究，本文尝试探讨一下DNS的体系结构，从而让大家能更好地了解DNS的原理。

DNS的主要工作是域名解析，也就是把计算机名翻译成IP地址，这样我们就可以直接用易于联想记忆的计算机名来进行网络通讯而不用去记忆那些枯燥晦涩的IP地址了。现在我们给出一个问题，在DNS出现之前，互联网上是如何进行计算机名称解析的？这个问题显然是有实际意义的，描述DNS的RFC882和883出现在1984年，但1969年11月互联网就诞生了，难道在DNS出现之前互联网的先驱们都是互相用IP地址进行通讯的？当然不是，但早期互联网的规模确实非常小，最早互联网上只有4台主机，分别在犹他大学，斯坦福大学，加州洛杉矶分校和加州圣芭芭拉分校，即使在整个70年代互联网上也只有几百台主机而已。这样一来，解决名称解析的问题就可以使用一个非常简单的办法，每台主机利用一个Hosts文件就可以把互联网上所有的主机都解析出来。这个Hosts文件现在我们还在使用，路径就在\\Windows\\System32\\Drivers\\etc目录下，如下图所示就是一个Hosts文件的例子，我们在图中可以很清楚地看到Hosts文件把[url]www.baidu.com[/url]解析为202.108.22.5。

在一个小规模的互联网上，使用Hosts文件是一个非常简单的解决方案，一般情况下，斯坦福大学的主机管理员每周更新一次Hosts文件，其他的主机管理员每周都定时下载更新的Hosts文件。但显然这种解决方案在互联网规模迅速膨胀时就不太适用了，就算现在的互联网上有一亿台主机，想想看，如果每个人的计算机中都要有一个容纳一亿台主机的Hosts文件！呵呵，是不是快要崩溃了！

互联网的管理者们及时为Hosts文件找到了继任者－DNS，DNS的设计要求使用分布式结构，既可以允许主机分散管理数据，同时数据又可以被整个网络所使用。管理的分散有利于缓解单一主机的瓶颈，缓解流量压力，同时也让数据更新变得简单。DNS还被设计使用有层次结构的名称空间为主机命名，以确保主机域名的唯一性。

DNS的设计要求您已经看到了，下面我来具体解释一下。DNS的前身Hosts文件是一个完全的分散解析方案，每台主机都自己负责名称解析，这种方法已经被我们否定了。那我们能否使用一个完全集中的解析方案呢？也就是全世界只有一个Hosts文件，互联网用户都利用这个文件进行名称解析！这个方案咋一听还是有可取之处的，至少大家都解脱出来了，不用每台计算机都更新那个Hosts文件了，全世界只要把这个唯一的Hosts文件维护好就完事大吉了。实际上仔细考虑一下，有很多的问题，例如这台存放Hosts文件的主机会成为性能瓶颈，面临巨大的流量压力，而且每个域名解析的结果都要通过这个文件进行更新，更新的速度可想而知不会太及时。因此，DNS也没有采用这种完全集中的解析方案。

目前DNS采用的是分布式的解析方案。具体是这样的，互联网管理委员会规定，域名空间的解析权都归根服务器所有，也就是说，根服务器对互联网上所有的域名都享有完全的解析权！且慢，有读者要提问了，那这个根服务器不就相当于全世界唯一的Hosts文件了吗？呵呵，不要着急，根服务器用了一个简单的操作，就改变了这种结构。根服务器使用的是什么操作？委派！下图就是根服务器委派的示意图，如下图所示，根服务器把com结尾的域名解析权委派给其他的DNS服务器，以后所有以com结尾的域名根服务器就都不负责解析了，而由被委派的服务器负责解析。而且根服务器还把以net，org，edu，gov等结尾的域名都一一进行了委派，这些被委派的域名被称为顶级域名，每个顶级域名都有预设的用途，例如com域名用于商业公司，edu域名用于教育机构，gov域名用于政府机关等等，这种顶级域名也被称为顶级机构域名。根服务器还针对不同国家进行了域名委派，例如把所有以CN结尾的域名委派给中国

互联网管理中心，以JP结尾的域名委派给日本互联网管理中心，CN，JP这些顶级域名被称为顶级地理域名。

每个被委派的DNS服务器同样使用委派的方式向下发展，例如和讯公司想申请使用hexun.com域名，这时和讯就要向负责.com域名的DNS服务器提出申请，只要hexun.com还没有被其他公司或个人使用，而且申请者按时足额缴纳了费用，负责.com域名的服务器就会把hexun.com域名委派到和讯公司自己的DNS服务器60.28.251.1。只要DNS服务器使用委派，域名空间就会逐步形成现有的分布式解析架构。这种架构把域名解析权下放到各公司自己的DNS服务器上，既有利于及时更新记录，同时对平衡流量压力也很有好处。

那么，在这种分布式的解析结构中，DNS服务器如何进行域名解析呢？换句话说，其他的DNS服务器怎么知道由60.28.251.1负责解析hexun.com的域名呢？如果一个互联网用户想解析域名[url]www.hexun.com[/url]，过程是怎么样的呢？如下图所示，用户把解析请求发送到自己使用的DNS服务器上，DNS服务器发现自己无法解析[url]www.hexun.com[/url]这个域名，于是就把这个

域名发送到根服务器请求解析，根服务器发现这个域名是以com结尾的，于是告诉查询者这个域名应该询问负责com的DNS服务器。这时查询者会转而向负责com的域名服务器发出查询请求，负责com域名的DNS服务器回答说[url]www.hexun.com[/url]是以hexun.com结尾的域名，以hexun.com结尾的域名已经被委派到DNS服务器60.28.251.1了，因此这个域名的解析应该询问60.28.251.1。于是查询者最后向60.28.251.1发出查询请求，这次应该可以如愿以偿了，60.28.251.1会告诉查询者所需要的答案，查询者拿到这个答案后，会把这个查询结果放入自己的缓存中，如果在缓存的有效期内有其他DNS客户再次请求这个域名，DNS服务器就会利用自己缓存中的结果响应用户，而不用再去根服务器那里跑一趟了。

以上介绍的域名解析过程我们可以通过一个实验来加以说明，Berlin是一个DNS服务器，IP地址为192.168.1.200，其他IP参数如下图所示。我们现在用Berlin来解析一个域名，我们用抓包工具ethereal追踪一下域名解析的轨迹。

在DNS服务器上查询[url]www.hexun.com[/url]，如下图所示，DNS服务器已经解析了这个域名，但到底解析的过程是什么样的呢？向下看！

打开抓包工具Ethereal，如下图所示，我们看到第8条记录显示DNS服务器Berlin向198.41.0.4发出了一个查询请求，请求解析

[url]www.hexun.com[/url]，198.41.0.4何许人也，13个根服务器之一！

接下来看第9条记录，198.41.0.4给Berlin一个回应，告诉了Berlin这个域名解析问题应该询问负责com区域的DNS服务器，而且198.41.0.4还给出了负责com区域服务器的域名和IP地址。

接下来的第10条记录显示了Berlin向192.55.83.30发出了域名解析请求，从上图可知，192.55.83.30就是负责com区域的域名服务器之一，这次查询会有什么样的回应呢？

从下图的第11条记录可以看出，负责com区域的域名服务器告诉Berlin，以hexun.com结尾的域名已经委派出去，现在有四个服务器负责，Berlin可以向这四个服务器中的任何一个提出查询请求。

从第12条记录可以看出，Berlin这次向59.173.14.26提出了查询请求，59.173.14.26就是上图中提到的负责hexun.com区域的四个服务器之一。这次查询会有什么样的结果呢？

如下图的第13条记录所示，这次查询终于有了结果，负责hexun.com的59.173.14.26终于告诉Berlin，[url]www.hexun.com[/url]对应的IP是60.28.250.55。

详解DNS的常用记录（上）

在上篇，我们介绍了DNS服务器的体系结构，从中我们了解到如果我们希望注册一个域名，那么必须经过顶级域名服务器或其下级的域名服务器为我们申请的域名进行委派，把解析权委派到我们的DNS服务器上，这样我们才可以获得对所申请域名的解析权。本文中我们将再进一步，假设我们已经为公司成功申请了一个域名hexun.com，现在hexun.com的解析权被委派到公司的DNS服务器202.99.16.1，那我们在202.99.16.1服务器上该进行什么样的配置呢？

一 安装DNS服务器

首先我们要在服务器上安装DNS组件，服务器的TCP/IP配置如下图所示。

安装DNS组件非常简单，依次点击 控制面板－添加或删除程序－添加/删除Windows组件－网络服务，如下图所示，选择“域名系统”即可。

二 创建区域

DNS服务器创建完毕之后，我们接下来就要创建DNS区域了，区域是DNS服务器所负责的名称空间，DNS服务器有正向区域和反向区域，正向区域负责把域名解析为IP，而反向区域负责把IP解析为域名。

DNS区域有三种类型，正向区域，反向区域和存根区域。要理解区域类型，先要明白DNS服务器有主服务器和辅助服务器的区别。一般情况下，企业申请域名时会考虑配备两个DNS服务器，一个是主服务器，另一个是辅助服务器。一般的解析请求由主服务器负责，辅助服务器的数据是从主服务器复制而来的，辅助服务器的数据是只读的，当主服务器出现故障或由于负载太重无法响应客户机的解析请求时，辅助服务器会挺身而出担负起域名解析的任务。现在我们回过头来解释一下什么是主要区域，主服务器使用的区域就是主要区域，同样，辅助服务器使用的区域是辅助区域。存根区域可以看做是一个特殊的，简化的辅助区域，具体区别我们在后续博文中会加以介绍。

一般我们使用较多的是正向区域，而且从逻辑上考虑，必然是先创建主要区域，因为辅助区域和存根区域都需要从主要区域复制数据，因此我们现在的任务是要为区域hexun.com创建一个正向的主要区域。如下图所示，我们在DNS服务器上选择创建一个正向区域。

出现新建区域向导，点击下一步继续。

选择创建一个主要区域。

区域名称和申请的域名是一样的，hexun.com。

区域数据文件是hexun.com.dns，区域内的所有记录都存储在这个文件里，注意，这个文件我们以后会用到的。

向导询问是否允许区域动态更新，一般来说，如果DNS区域在企业内网使用，我们会允许动态更新；如果用于Internet，那么一般不需要动态更新。

如下图所示，区域创建完毕。

区域创建完毕之后，如下图所示，区域中只有一个NS记录和一个SOA记录，我们接下来要做的工作就是在区域中创建适当的DNS记录。

三 创建记录

DNS记录是DNS区域数据的具体表现形式，我们接下来为大家介绍几种最常见的DNS记录，大家掌握了这些记录就可以基本掌握DNS的基本应用了。 1、 A记录

A记录也称为主机记录，是使用最广泛的DNS记录，A记录的基本作用就是说明一个域名对应的IP是多少，例如，我们想通过A记录说明一台主机的域名是bbs.hexun.com，IP是202.99.16.185，那么我们就可以进行下列操作。如下图所示，我们在hexun.com区域中选择“新建主机”。

如下图所示，我们在A记录中说明了域名bbs.hexun.com对应的IP是202.99.16.185。其中提到了一个完全合格域名的概念，这里我们介绍一下。完全合格域名指的是点结尾的域名，例如bbs.hexun.com.就是一个完全合格域名。在一般的网络应用中，我们可以省略完全合格域名最右侧的点，但DNS对这个点不能随便省略。因为这个点代表了DNS的根，有了这个点，完全合格域名就可以表达为一个绝对路径，例如bbs.hexun.com.就可以表示为DNS根下的com子域下hexun.com域中一个名为bbs的主机。如果DNS发现一个域名不是以点结尾的完全合格域名，就会把这个域名加上当前的区域名称作为后缀，让其满足完全合格域名的形式需求。例如DNS会把域名bbs处理为

bbs.hexun.com.。因此，如果要求输入完全合格域名，我们应该注意让域名以点结尾。

A记录的基本用法是描述域名和IP的对应关系，其实A记录还有一个高级用法，A记录有负载平衡的作用。DNS经常被用作一个低成本的负载平衡解决方案，主要就是依靠A记录来实现的。举个例子加以说明，例如我们有四个Web服务器共同负责[url]www.hexun.com[/url]这个网站，四个Web服务器的IP地址分别为202.99.16.81，202.99.16.82，202.99.16.83和202.99.16.84，那么我们就应该创建如下的主机记录。

以上我们用四条A记录分别描述了[url]www.hexun.com[/url]对应的四个IP，那么，到底如何利用这些IP来实现负载平衡呢？原理是这样的，客户机访问Web服务器一般都使用域名，因此需要利用DNS服务器把域名解析为IP。第一个客户机查询[url]www.hexun.com[/url]时，DNS服务器会告诉客户机这个域名对应的IP是202.99.16.81，第二个客户机来查询时DNS服务器就会把答案

改为202.99.16.82，依此类推，DNS使用了“轮询”的技术把不同的访问用户导向了四个不同的Web服务器，这样就达到了一个简易负载平衡的效果。 我们可以通过一个简单的实验来验证一下DNS轮询的效果，如下图所示，我们在客户机上用ping [url]www.hexun.com[/url]的方式来查询域名对应的IP，但奇怪的是，客户机两次查询域名得到的是同一个结果，这时为什么呢？难道DNS轮询不起作用了吗？

其实并非DNS轮询出了问题，而是由于客户机有DNS缓存机制，当客户机第一次查询DNS服务器获得了域名对应的IP地址，客户机会把查询结果放入缓存，这样下次查询时就直接从缓存获取结果而不用去问DNS服务器了。明白了这个道理，我们只要用IPCONFIG/FLUSHDNS清除客户机的DNS缓存就可以继续实验了，实验结果如下图所示，我们可以看到DNS轮询已经发挥了作用。

2、 NS记录

NS记录和SOA记录是任何一个DNS区域都不可或缺的两条记录，NS记录也叫名称服务器记录，用于说明这个区域有哪些DNS服务器负责解析，SOA记录说明负责解析的DNS服务器中哪一个是主服务器。因此，任何一个DNS区域都不可能缺少这两条记录。

假设hexun.com区域有两个DNS服务器负责解析，ns1.hexun.com是主服务器，ns2.hexun.com是辅助服务器，ns1.hexun.com的ip是202.99.16.1，ns2.hexun.com的ip是202.99.16.2。那么我们应该创建两条NS记录，当然，NS记录依赖A记录的解析，我们首先应该为ns1.hexun.com和ns2.hexun.com创建两条A记录，创建的A记录如下图所示。

有了两条主机记录的支持，我们就可以编辑ns记录了，如下图所示，当前区域的ns记录是创建hexun.com区域时系统自动创建的。这条ns记录并不能正常工作，因为nsserver并不是一个可以解析的完全合格域名，因此我们删除这条记录，重新再创建两条NS记录。

如下图所示，我们创建一条ns记录，ns服务器的完全合格域名是

ns1.hexun.com..，解析出的IP是202.99.16.1，这条记录说明有一个服务器ns1.hexun.com负责hexun.com的域名解析。

用同样方法创建ns2.hexun.com的ns记录，创建完成的结果如下图所示。

3、 SOA记录

NS记录说明了有两个DNS服务器负责hexun.com的域名解析，但哪个是主服务器呢？NS记录并没有说明，这个任务由SOA记录来完成。SOA记录也称为起始授权机构记录，SOA记录中负责说明哪个DNS服务器是主服务器，以及主服务器和辅助服务器之间的一些关联参数。如下图所示就是hexun.com的SOA记录，我们逐一进行分析。

首先我们要分析序列号，序列号反映了DNS服务器数据变化的次数，DNS服务器的数据每更新一次，序列号就加大一位。但我们仔细想想，对管理员来说，了解这个参数意义不大，因为DNS服务器到底是更新了10000次还是9999次对管理员来说并没有实质性的影响。实际上，这个参数是给辅助服务器使用的。我们前面提到，辅助服务器的数据都是从主服务器复制而来的，那么辅助服务器怎么判断主服务器的数据有没有进行更新呢？辅助服务器只要简单地检查一

下主服务器的序列号就明白了，如果主服务器的序列号比辅助服务器的序列号大，那么辅助服务器就应该去主服务器进行增量更新了。

主服务器这个参数的重要性不言而喻，目前的SOA记录中主服务器参数是nsserver.，这并不是一个可以解析的完全合格域名，我们应该把主服务器改为ns1.hexun.com.，如下图所示，这才是正确的主服务器参数。可能大家会有疑问，为什么NS记录和SOA记录默认都是nsserver.，主要是因为nsserver.是这台DNS服务器的NETBIOS名称。

从上图可知，我们把SOA记录中的负责人参数改为了admin.hexun.com.，看起来象个主机的完全合格域名，其实意思是admin@hexun.com，是一个邮箱地址。那么为什么负责人这个参数不直接写成admin@hexun.com呢？毕竟这样就好理解多了，这时因为@符号在DNS中有特殊含义，@在DNS中代表当前区域，

也就是代表hexun.com，因此我们被迫把邮件地址写成了完全合格域名的格式。

刷新间隔指的是辅助服务器每隔15分钟联系一下主服务器，查看主服务器有无数据更新。重试间隔10分钟值的是如果辅助服务器和主服务器失去了联系，那么辅助服务器每隔10分钟联系一下主服务器，在此期间由辅助服务器负责当前区域的域名解析。过期时间是1天指的是如果辅助服务器过了一天还没有联系上主服务器，辅助服务器就会认为主服务器永远不会再回来了，自己的数据也没有保存的意义了，因此会宣布数据过期，并拒绝为用户继续提供解析服务。TTL一个小时指的是记录在DNS缓存中的生存时间是一个小时。

详解DNS常用记录（下）

在上文中我们介绍了DNS服务器中几种不可或缺的记录，包括A记录，NS记录和SOA记录。本文中我们将继续为大家介绍DNS的另外几种常用记录，希望能对大家了解DNS有所帮助。

四 MX记录

MX记录也被称为邮件交换器记录，MX记录用于说明哪台服务器是当前区域的邮件服务器，例如在hexun.com区域中，mail.hexun.com是邮件服务器，而且IP地址是202.99.16.125。那么我们就可以在DNS服务器中进行下列处理： 1、 为邮件服务器创建A记录

如下图所示，我们首先为邮件服务器创建一条A记录，这时因为MX记录中描述邮件服务器时不能使用IP地址，只能使用完全合格域名。

2、 创建MX记录

如下图所示，在DNS服务器中选择创建MX记录。

MX记录如下图所示，这条MX记录说明mail.hexun.com是hexun.com的邮件服务器，而且优先级是10。注意，如果hexun.com区域有多个MX记录，而且优先级不同，那么其他邮局给hexun.com发邮件时会首先把邮件发给优先级最高的邮件服务器，代表优先级的数字越低则优先级越高，优先级最高为0。

MX记录对邮件服务器来说是不可或缺的，两个互联网邮局系统在相互通讯时必须依赖DNS的MX记录才能定位出对方的邮件服务器位置。例如163.net邮局给263.net邮局发一封电子邮件，那163邮局的SMTP服务器就需要向DNS服务器发出一个查询请求，请DNS服务器查询263.net的MX记录，这样163邮局的SMTP服务器就可以定位263.net的SMTP服务器，然后就可以把邮件发送到263邮局。

我们通过一个例子来具体说明一下MX记录的用途，我们在192.168.0.109上搭建了一个邮件服务器，我们利用这个邮件服务器给itettest1@sohu.com发送一

封电子邮件，当邮件服务器给sohu.com邮局发送邮件时，我们用抓包工具ethereal记录抓包过程。如下图所示，我们可以看出邮件服务器

192.168.0.109在发送邮件时首先向DNS服务器发出一个查询请求，请求查询sohu.com的MX记录，DNS服务器告诉查询者sohu.com邮局的邮件服务器是sohumx.h.a.sohu.com，这样192.168.0.109才知道应该把邮件发送到sohumx.h.a.sohu.com。

五 Cname记录

Cname记录也被称为别名记录，其实就是让一个服务器有多个域名，大致相当于给一个人起个外号。为什么需要Cname记录呢？一方面是照顾用户的使用习

惯，例如我们习惯把邮件服务器命名为mail，把ftp服务器命名为ftp，那如果只有一台服务器，同时提供邮件服务和FTP服务，那我们究竟该怎么命名呢？我们可以把服务器命名为mail.hexun.com，然后再创建一个Cname记录叫ftp.hexun.com就可以两者兼顾了。另外使用Cname记录也有安全方面的考虑因素，例如我们不希望别人知道某个网站的真实域名，那我们可以让用户访问网站的别名，例如我们访问的百度网站的真实域名就是

[url]www.a.shifen.com[/url]，我们使用的[url]www.baidu.com[/url]只是[url]www.a.shifen.com[/url]的别名而已。

好，下面我们举个创建Cname记录的例子，假设我们要为mail.hexun.com创建一个别名ftp.hexun.com，那我们就可以进行下列操作。如下图所示，我们选择在DNS服务器中创建Cname记录。

记录内容如下图所示，我们为mail.hexun.com创建了一个别名记录，别名是ftp.hexun.com。

对ftp.hexun.com进行解析，结果如下图所示，DNS服务器告诉我们ftp.hexun.com就是mail.hexun.com。

六 SRV记录

SRV记录是服务器资源记录的缩写，SRV记录是DNS记录中的新鲜面孔，在RFC2052中才对SRV记录进行了定义，因此很多老版本的DNS服务器并不支持SRV记录。那么SRV记录有什么用呢？SRV记录的作用是说明一个服务器能够提

供什么样的服务！SRV记录在微软的Active Directory中有着重要地位，大家知道在NT4时代域和DNS并没有太多关系。但从Win2000开始，域就离不开DNS的帮助了，为什么呢？因为域内的计算机要依赖DNS的SRV记录来定位域控制器！微软的即时通讯服务器Live Communications Server也可以依靠SRV记录定位即时通讯服务器，有鉴于SRV记录可以定位特定服务器的位置，我们可以预计，在微软将来的服务器产品中SRV记录将发挥越来越多的作用。 下面我们举个例子说明SRV记录的作用，假设在hexun.com域中

web.hexun.com是一个Web服务器，web.hexun.com在80端口提供网站服务，那么我们如何用SRV记录说明这些信息呢？如下图所示，我们在DNS服务器中选择新建“其他新纪录”。

记录类型我们选择SRV。

下图是我们创建的SRV记录，这条记录的意思是服务器web.hexun.com在hexun.com域中提供HTTP服务，此服务基于TCP协议，守护在80端口。

七 PTR记录

PTR记录也被称为指针记录，PTR记录是A记录的逆向记录，作用是把IP地址解析为域名。由于我们在前面提到过，DNS的反向区域负责从IP到域名的解析，因此如果要创建PTR记录，必须在反向区域中创建。下面我们举例说明如何创建反向区域以及PTR记录。

如下图所示，我们在DNS服务器的反向区域中选择“新建区域”。

出现新建区域向导，选择下一步继续。

区域类型选择“主要区域”。

向导要求输入当前的网络号，网络号是IP地址和子网掩码进行与运算后的结果，反向区域的名称不能随便设置，必须是颠倒的网络号再加上in-addr.arpa

后缀。例如当前的网络号是202.99.16，那反向区域的名称就应该是16.99.202.in-addr.arpa。

设置反向区域的数据文件，使用默认值即可。

这个区域也不需要动态更新。

如下图所示，反向区域创建完成。

创建了反向区域之后，我们就可以在反向区域中创建PTR记录了，如下图所示，我们选择在反向区域中创建PTR记录。

如下图所示，我们创建的PTR记录把202.99.16.1解析为域名ns1.hexun.com。

创建了PTR记录后，我们就可以把IP解析为域名了，下图是我们用nslookup工具测试的结果，我们看到IP地址已经被正确地解析为域名了。其实当我们运行nslookup后，nslookup所做的第一件事就是把DNS服务器的IP地址202.99.16.1进行反向解析。

配置DNS辅助服务器

在前文中，我们介绍了如何在DNS服务器中创建常用的DNS记录，本文中我们要为大家介绍如何配置DNS的辅助服务器，同时也要介绍一下和辅助区域类似的存根区域。

DNS辅助服务器是一种容错设计，考虑的是一旦DNS主服务器出现故障或因负载太重无法及时响应客户机请求，辅助服务器将挺身而出为主服务器排忧解难。辅助服务器的区域数据都是从主服务器复制而来，因此辅助服务器的数据都是只读的，当然，如果有必要，我们可以很轻松地把辅助服务器升级为主服务器。我们通过下面的一个实验为大家介绍如何配置DNS辅助服务器，如下图所示，ns1.hexun.com是hexun.com的主服务器，ns2.hexun.com是hexun.com的辅助服务器。

一 权限设置

如果我们想把ns2.hexun.com配置为hexun.com的辅助服务器，首先我们要在主服务器ns1.hexun.com上进行权限设置。出于安全原因，主服务器并不允许任意的DNS服务器从自己的区域中复制数据，默认情况下，只有这个区域的DNS服务器才被允许成为辅助DNS服务器。如下图所示，在hexun.com区域的属性中切换到“区域复制”标签，我们发现默认设置是允许区域复制的，只是被允许的都是hexun.com的域名服务器。

切换到“名称服务器”标签，如下图所示，hexun.com区域有两个名称服务器，ns1.hexun.com和ns2.hexun.com，ns1.hexun.com是主服务器，那么显然ns2.hexun.com就是获得区域复制授权的辅助服务器了。

二 创建辅助区域

Ns2.hexun.com获得授权成为hexun.com的辅助DNS服务器之后，我们就可以在ns2.hexun.com上创建辅助区域了。如下图所示，我们在辅助DNS服务器上选择“新建区域”。

如下图所示，出现新建区域向导，点击下一步继续。

区域类型选择“辅助区域”，这是辅助服务器使用的区域类型。

区域名称是hexun.com。

区域的主服务器是202.99.16.1，辅助服务器将从主服务器复制区域数据。

如下图所示，DNS辅助区域创建完毕。

三 区域数据传输

在202.99.16.2上创建了DNS辅助区域后，我们发现辅助服务器不能从主服务器复制数据，错误信息如下图所示。

出现上述故障不用担心，DNS区域复制经常会遇到这种故障，基本都是由于新创建的DNS辅助区域没有来得及和主服务器同步。我们稍微等上几分钟，然后刷新一下区域就正常了，如下图所示，辅助服务器已经从主服务器复制了所有的区域数据。以后辅助服务器就会向SOA记录中描述的那样，每隔15分钟检查一下主服务器有没有更新。一旦发现主服务器有新记录，辅助服务器会立刻使用增量复制把主服务器的新记录复制过来。

四 存根区域

Windows Server 2003在DNS中新推出了一种存根区域，相比以往的辅助区域，DNS管理员们又多了一种选择。存根区域和辅助区域有类似之处，都要从区域的主服务器复制数据。不同之处在于，辅助区域复制区域中的所有记录，但存根区域只复制区域的SOA记录，NS记录以及解析NS记录的A记录（也称粘连记录）。也就是说，存根区域并不需要在自己的区域中保存所有的DNS记录，存根区域只要知道利用哪个DNS服务器可以对DNS记录进行解析就可以了。

下面我们在202.99.16.2上删除刚创建的辅助区域，重新创建一个存根区域，大家可以来比较一下存根区域和辅助区域有哪些区别。 如下图所示，我们在202.99.16.2上选择“新建区域”。

区域类型选择“存根区域”，如下图所示，创建向导中已经对存根区域的工作性质进行了说明。

存根区域的名称是hexun.com。

区域数据的名称是hexun.com.dns。

存根区域也需要从主服务器复制数据，如下图所示，hexun.com的主服务器是202.99.16.1。

如下图所示，存根区域创建完成。

查看一下新创建的存根区域内容，如下图所示，我们发现存根区域中只有SOA记录，NS记录以及与NS记录相关联的A记录。也就是说，这个存根区域并没

有保存hexun.com的所有DNS记录，但它知道202.99.16.1上拥有hexun.com的全部记录，如果需要解析记录，可以向202.99.16.1发起查询请求。

DNS的辅助服务器配置起来很简单，只要注意好设置区域复制的权限即可，辅助服务器既可以帮助主服务器进行负载平衡，也是一个容错设计，因此被DNS管理员普遍使用

揭秘DNS后台文件

在前文中我们介绍了DNS的体系结构，常用记录，还介绍了辅助服务器的配置，今天我们来介绍一下DNS服务器背后的几个文件。其实DNS服务器的工作完全依靠这几个文件，了解了DNS的后台文件后，有利于更好地理解DNS服务器，也可以让大家明白为什么有高手声称配置DNS最好的工具就是记事本。 DNS服务器所使用的文件并不复杂，一个是Boot文件，负责存储DNS服务器的启动信息；一个是Cache.dns，负责存储根服务器的域名和IP地址；还有一个

最重要的文件就是区域数据文件，负责存储区域内的所有DNS记录。这些文件都在\\Windows\\System32\\DNS目录下，我们找到负责解析hexun.com区域的DNS服务器202.99.16.1，来分析一下这个DNS服务器所使用的上述文件。 一 Boot文件

首先来看看Boot文件，奇怪的是，在DNS服务器C:\\Windows\\System32\\DNS目录下，我们并没有发现Boot文件，具体如下图所示，这时为什么呢？

这时因为DNS的引导信息可以有三种保存的途径，一是可以保存在Boot文件，二是可以保存在注册表，三是可以保存在Active Directory。微软可能是怕用户误删除了Boot文件，因此默认情况下把引导信息用另外两种方式保存。如果我们想查看Boot文件的内容，首先要修改DNS服务器引导信息的保存方式。如下图所示，在DNS管理器中选择查看DNS服务器的属性。

在DNS服务器属性中切换到“高级”标签，如下图所示，选择从文件加载区域数据，这样DNS服务器就会把启动信息写到Boot文件中。

如下图所示，Boot文件终于出现了！

用记事本打开boot文件查看一下，其实内容很简单，Primay代表DNS服务器是当前区域的主服务器，从Boot文件可以看到，当前的DNS服务器是hexun.com区域的主服务器，同时也是16.99.202.in-addr.arpa区域的主服务

器。但并不是根域的DNS服务器，要想解析根域，需要依靠cache.dns，chache.dns中记录了13个根服务器的域名和IP地址。

202.99.16.2是hexun.com的辅助服务器，我们看看它的Boot文件内容是什么。如下图所示，secondary表示是当前区域的辅助服务器，主服务器是202.99.16.1，根域的解析也是要依靠cache.dns中的13个根服务器。

总结：看了两个例子，我们发现DNS服务器中的Boot文件其实很简单，就是描述了当前的DNS服务器负责哪些区域，是区域的主服务器还是辅助服务器，区域数据文件放在哪里等问题。我们完全可以利用Boot文件控制DNS启动时加载的区域数据，也可以改变DNS服务器的角色，例如从辅助服务器改为主服务器。

二 Cache.dns

以前我们介绍DNS体系结构时曾经描述过域名解析的过程：DNS服务器发现一个域名自己不能解析，就会把这个查询提交给根服务器，根服务器通过迭代方式可以让DNS服务器最终找到答案。这个过程中有个关键问题，DNS服务器怎么知道谁是互联网上的根服务器呢？答案现在就可以揭晓了，Cache.dns中存储了13个根服务器的域名和IP地址！这13个根服务器除了在东京，伦敦，斯德哥尔摩各有一台，其余都在美国。

如下图所示，Cache.dns中描述了13台服务器的完全合格域名以及IP地址，其中@是个缩写，代表当前区域，也就是根域。每个服务器用两条记录描述，一条记录是NS记录类型，一条是A记录类型。NS记录说明谁是根域的DNS服务器，A记录说明这台DNS服务器的IP地址是多少。

Cache.dns的内容也可以通过DNS服务器属性中的“根提示”来查看，如下图所示，我们查看DNS服务器的属性，在属性中切换到“根提示”标签，所看到的内容就是cache.dns中所描述的13个根服务器。

总结：Cache.dns中记录了互联网上13个根服务器的域名和IP，我们有很多地方需要利用Cache.dns，例如北京新增加了一个DNS根服务器，但Win2003并不知道这个变化，这时我们就需要通过修改Cache.dns来完成这个工作。或者是假设一个大企业使用了私有根，自己做了一个根服务器，这时也要修改Cache.dns才能让DNS服务器知道这个私有根的存在。 三 区域数据文件

接下来我们要介绍的就是最重要的区域数据文件了，区域数据文件保存了区域中所有的DNS记录，是DNS服务器的核心数据。从前面的Boot文件可以看出，hexun.com区域的数据都存放在了hexun.com.dns文件中，接下来我们就用记事本打开C:\\windows\\system32\\dns\\hexun.com.dns，结果如下图所示。

我们从区域数据文件中可以看出DNS记录的具体存储方式，首先我们来分析一下文件中的SOA记录，记录内容如下图所示。@是缩写，代表当前区域，相当于hexun.com. ，SOA是记录类型，ns1.hexun.com.表示的是hexun.com的主服务器，12是记录的更新序列号，900秒是15分钟的刷新间隔，辅助服务器和主服务器每隔900秒联系一次；600秒是10分钟的重试时间，如果辅助服务器和主服务器失去了联系，就每隔10分钟联系一下主服务器；86400是过期时间，如果辅助服务器过了一天都没和主服务器联系上，辅助服务器就认为自己的数据过期了；3600秒是DNS记录在缓存中的生存时间。

刚才分析的内容其实和下图中的SOA记录是完全一致的。

再来看看其他的几条记录，如下图所示，注意其中的A记录。DNS中的记录是要以完全合格域名的形式存在的，如果域名不以点结尾，那么DNS会自动在域名的最后追加上当前区域，把格式补充为完全合格域名的形式。例如mail就会被补充为mail.hexun.com.

我们利用DNS的区域数据文件完成两项常见任务，DNS的空域名解析和泛域名解析。空域名解析就是解析hexun.com，泛域名解析就是把所有以hexun.com结尾但又没有出现在DNS区域中的域名进行解析，例如ww.hexun.com。一般情况下网站对这两种域名解析会进行处理，因为有时访问者喜欢省事在浏览器中直接输入hexun.com就进行访问，而且也可能把[url]www.hexun.com[/url]误输为ww.hexun.com。

空域名解析比较简单，如果我们想把空域名解析成202.99.16.80，那就可以在区域数据文件中输入 @ A 202.99.16.80，刚才我们提到了，@代表了当前区域，相当于hexun.com. 。

泛域名解析也不难，例如我们想把泛域名也解析成202.99.16.80，那么我们就可以在区域数据文件中输入 * A 202.99.16.80，*是通配符，代表任意字符的组合，具体如下图所示。

在保存DNS区域数据文件之前，最好先停止DNS服务，然后保存文件之后再启动DNS服务。如下图所示，我们发现空域名解析和泛域名解析都生效了。

再用区域数据文件完成一项常见任务，DNS的委派！介绍DNS体系结构时我们就提到过，正是由于有了伟大的委派，DNS才发展到今天。我们这次准备把

shanghai.hexun.com的解析权委派给DNS服务器ns.shanghai.hexun.com，这台服务器的IP是211.99.213.1，那么我们在区域数据文件中写入下列两条记录就OK了。

在DNS管理器中可以看到，我们设置的委派已经生效了。