致谢：转自 http://bbs.chinaunix.net/thread-1573358-1-1.html ，由 llzqq 发表。
有关公网DNS
公网DNS服务器是直接服务于广大上网用户的，负责域名（域名记录）到IP地址之间的翻译工作。公网DNS通常是各个网络运营商按照自己的网络分布规划DNS的分布，一般做法是按行政区域放置，如按省份放置。每个省份内也有细分在各地区放置的情况。
近几年来细心的网友会发现上网时如果打错了URL地址（或干脆莫名其妙）会访问到114网站或百度等网站。今天我画了一个简单的图表简要说明一下原因。
如图所示，大方形框内为公网DNS网络基本构架，负责接收用户解析请求的是前端硬件设备如大家常常提到的F5（硬件设备功能单一，负载能力巨大，故把它做为前端设备很合适，图中用A表示）。前端设备后面与递归服务器群连接（一般是LAN连接，也有WAN连接的）。当用户请求域名解析时前端设备会把请求传递到其后的递归DNS处理，最后把结果告知用户。同时前端设备还有负载均衡，链路状态检查等功能。
近年来各个网络运营商如网通，电信等在利益驱使下推出了利用DNS技术实现的网络推广业务。原理很简单，就是当用户不小心打错URL地址或者由于某种原因（如域名欠费）访问的域名不能解析时，公网DNS的前端设备会自动为用户解析到一个被推广的网站上，以此来获得网络推广收入（真是无耻啊，根本不考虑用户感受）。
如果是这样的话，我们为什么不绕过前端设备直接向递归服务器群请求域名解析呢？恩，想法是好的，但这里有两个困难：
- 那些递归DNS的IP地址没有公布，大家不知道，没法用啊。
- 运营商限制了向递归服务器请求的IP地址，也没法用！！
权益之计：
- 使用国外的DNS。
- 自己架设递归DNS。
域名解析及DNS功能分类
按功能（角色）的分类
-
权威DNS
权威DNS是经过上一级授权对域名进行解析的服务器，同时它可以把解析授权转授给其他人，如COM顶级服务器可以授权ABC.COM的权威服务器为NS.ABC.COM，同时NS.ABC.COM还可以把授权转授给NS.DDD.COM，这样NS.DDD.COM就成了ABC.COM实际上的权威服务器了。平时我们解析域名的结果都源自权威DNS。
-
递归DNS
负责接受用户对任意域名查询，并返回结果给用户。递归DNS的工作过程参见本文第二节。递归DNS可以缓存结果以避免重复向上查询。我们平时使用最多的就是这类DNS，他对公众开放服务，一般由网络运营商提供，大家都自己可以架递归DNS提供服务。递归DNS一定要有可靠的互联网连接方可使用。
-
转发DNS:
负责接受用户查询，并返回结果给用户。但这个结果不是按标准的域名解析过程得到的，而是直接把递归DNS的结果转发给用户。它也具备缓存功能。他主要使用在没有直接的互联网连接，但可以连接到一个递归DNS那里，这时使用转发DNS就比较合适。其缺陷是：直接受递归DNS的影响，服务品质较差。
域名解析过程
用户—>本地递归服务器—>根权威服务器—>COM权威服务器—>ABC.COM权威服务器—>用户
如图所示，用户A解析域名的过程就是上面的过程。用户B是先经过转发服务器，由转发服务器再向递归服务器请求的。
FAQ：
-
递归服务器怎么知道根权威服务器的地址？
很简单，在递归服务器上都保存有一份根服务器的地址列表。最新的根服务器地址列表在这里可以得到：ftp://ftp.internic.net/domain/named.root
-
递归服务器每次查询域名都要向根那里找权威服务器吗？
不是的，一旦成功一次，递归服务器就会把权威服务器列表缓存下来（如COM顶级服务器列表可以缓存48小时）。
-
这些DNS都是什么人在管理？
本地递归服务器一般由电信运营商架设，服务于自己的用户，并有其管理，自然人也架设。根服务器与顶级域服务器由国际组织统一部署管理（实际控制器在美国政府）。对顶级域服务器来说销售商有可控的写入权。对于像图中所示的NS.ABC.COM的权威服务器就没有门槛了，谁都可以架设。
智能DNS
前言
智能DNS即为BIND+VIEW的功能实现。在国内，最早把智能DNS投向市场的是偶（怎么给人不谦虚的感觉呢）。我想BIND9.X引入VIEW（视图）功能并不是针对中国的，但是这个功能正好能解决我国网络运营商之间的互联互通问题，可谓天上的馅饼。本文结合自己这几年来架设维护智能DNS的经验体会随便写些东西，希望对大家有所帮助。时间仓促加之知识有限，难免错误之处，大家一块讨论吧。
前提
使用智能DNS有个前提假设，就是各个网络运营商都有自用的公网DNS为自己的用户提供域名解析服务。如果不是这样的，那智能DNS就没有存在的必要了（原因将在下面讨论）。所幸的是目前情况基本满足这个条件，网通，电信，教育网等都自成体系。
功能
智能DNS最基本的功能是可以智能的判断访问您网站的用户，然后根据不同的访问者把您的域名（域名记录）分别解析成不同的地址。如访问者是网通用户，智能DNS服务器会把你域名对应的网通IP地址解析给这个访问者。如果用户是电信用户，智能DNS服务器会把您域名对应的电信IP地址解析给这个访问者。由此我们可以让网通、电信、教育网、移动、国外用户智能的选择访问你的服务器。
原理
以ABC.COM域名为例。用户访问WWW.ABC.COM时的工作过程如图所示。这里省略了与本文讨论无关的细节，目的是化繁为简。
- 网通用户向本地DNS请求解析WWW.ABC.COM。
- 本地DNS向ABC.COM的权威DNS（这里的权威DNS一定是智能DNS）。
- 智能DNS根据请求者（这里是本地DNS）的IP地址在自己的ACL里面进行匹配，然后把匹配的结果返回给本地DNS。
- 本地DNS把结果告诉用户，并把结果缓存起来。
- 用户访问网通线路上的网站服务器。
特别关注
这里有几点重要问题，值得单独列出，不然在使用智能DNS的过程中碰到就诧异了。
- 智能DNS判断用户来源的依据是“本地DNS”而非是用户自身的IP地址。
- 由上延伸，如果电信用户使用了网通DNS，通过智能DNS将会匹配到网通的解析结果。
- 本地DNS一般情况下不会亲自向智能DNS请求解析，这是由本地DNS的网络拓扑决定的，详情见另一篇帖子《扫盲系列之：有关公网DNS》
面临的问题
- 各网络运营商的IP地址收集困难，有其是象“长城宽带”、“广电网”等这样的小运营商他们的用户使用的DNS五花八门，根本不适于使用智能 DNS。所以说智能DNS并不是把运营商划分的越细越好。总之结合自己的能力就好。
- 各大网络运营商相互渗透的情况（幸好是个别现象，但要引起重视），比如广东电信的公网DNS的后台有数目不详的服务器架设到网通的线路上 了。这样造成的后果就是明明使用的是电信DNS，但有时候解析到网通的结果。
- 众所周知的网络攻击事件越来越多的落到了DNS上面，这个事情很无奈。 最后，关于架设智能DNS技术细节这里就不讨论了，相信很容易就能在网上找到。
域名迁移
说的更通俗一点，域名迁移就是修改域名的权威DNS，即将域名ABC.COM的原权威DNS由A迁移到B。实际工作中最常见的形式是将域名转到另一家DNS服务商来解析。本文就域名迁移过程中几个值得关注的问题讨论一下。
为什么要域名迁移?
通常情况下，我们从那里购买的域名就由那家的DNS作为该域名的权威DNS负责解析该域名。如你不满意他们的服务质量，或他们无法提供你需要的服务内容，这时就需要把域名迁移到你认为更好的DNS上。
域名迁移正确流程
-
首先到B把你的域名添加上去，包括SOA、NS、A、CNAME、MX记录等。然后用dig/nslookup等工具验证一下是否刚才添加的记录是否生效，如验证A记录WWW.ABC.COM：
dig @B WWW.ABC.COM A -
到原域名注册商处修改域名权威DNS为B，即修改域名的NS记录为B。注意，位于域名原权威DNS上的其他各种记录要保留一段时间不要马上删除。然后在该域名的顶级域DNS上验证一下刚才的修改是否生效。如验证ABC.COM现在的权威DNS：
dig @a.gtld-servers.net ABC.COM NS
域名迁移的过渡期
域名权威DNS由A转移到B的过程中域名解析权发生变化，世界各地的递归DNS要知道这个变化需要一段时间，因为各地DNS都缓存了该域名以前的状态，更新到最新的状态需要时间。
过渡期时长的确定
我们对域名进行trace查询以便了解该域名NS记录的TTL值。如查询CN类域名。
# dig xxx.cn ns +trace
xxx.cn. 21600 IN NS ns.xxx.cn.
xxx.cn. 21600 IN NS ns.xxx.com.
;; Received 83 bytes from 203.119.25.1#53(A.DNS.cn) in 46 ms
xxx.cn. 21600 IN NS ns.xxx.cn.
xxx.cn. 21600 IN NS ns.xxx.com.
;; Received 83 bytes from 129.44.79.4#53(ns.xxx.cn) in 78 ms
上面权威DNS与顶级域DNS上NS记录的TTL值相同，则过渡期为21600秒。特殊情况，如果该域名的原权威DNS上定义的该域名NS记录的TTL值与顶级域DNS上定义的值不同。则这个时候原权威DNS上的TTL为有效值。如163.cn:
# dig 163.cn ns +trace
163.cn. 21600 IN NS ns1.newfavor.net.
163.cn. 21600 IN NS ns2.newfavor.net.
;; Received 72 bytes from 203.119.28.1#53(D.DNS.cn) in 62 ms
163.cn. 10800 IN NS dns1.amway.com.
163.cn. 10800 IN NS ns2.newfavor.net.
163.cn. 10800 IN NS ns1.newfavor.net.
;; Received 174 bytes from 61.145.126.88#53(ns1.newfavor.net) in 93 ms
可以看到该域名在顶级域上NS记录的TTL为21600，而在权威DNS上有重新定义为10800，则这个时候原权威DNS上的TTL为有效值。 在实际工作中稳妥起见我们取两者中较大的为最后的参考值。下面列出几种域名NS记录的TTL值：
COM. TTL = 172800 (48小时)
NET. TTL = 172800 (48小时)
ORG. TTL = 86400 (24小时)
CN. TTL = 21600 (6小时)
域名配置ZONE文件
这次把ZONE文件拿出来简单说明一下。ZONE文件是DNS上保存域名配置的文件，对BIND来说一个域名对应一个ZONE文件，现以abc.com的ZONE文件为例展开。罗嗦一句，该ZONE存在于权威DNS上。
$TTL 6h //第1行
$ORIGIN abc.com. //第2行
@ 3600 IN SOA ns1.ddd.com. root.ddd.com.( //第3行
929142851 ; Serial //第4行
1800 ; Refresh //第5行
600 ; Retry //第6行
2w ; Expire /第7行
300 ; Minimum //第8行
)
@ 2d IN NS ns1.ddd.com. //第9行
@ 2d IN NS ns2.ddd.com. //第10行
@ 2d IN NS ns3.ddd.com. //第11行
@ 3600 IN A 120.172.234.27 //第12行
a 3600 IN A 120.172.234.27 //第13行
b 3600 IN CNAME a.abc.com. //第14行
@ 3600 IN MX a.abc.com. //第15行
@ 3600 IN TXT "TXT" //第15行
第1行，这行内容给出了该域名(abc.com)各种记录的默认TTL值，这里为6小时。即如果该域名的记录没有特别定义TTL，则默认TTL为有效值。
第2行，这行内容标识出该ZONE文件是隶属那个域名的，这里为abc.com。
第3行，从这行开始到第8行为该域名的SOA记录部分，这里的@代表域名本身。ns1.ddd.com表示该域名的主权威DNS。root.ddd.com表示该主权威DNS管理员邮箱，等价于root@ddd.com。
第4行，Serial部分，这部分用来标记ZONE文件更新，如果发生更新则Serial要单增，否则MASTER不会通知SLAVE进行更新。
第5行，Refresh部分，这个标记SLAVE服务器多长时间主动(忽略MASTER的更新通知)向MASTER复核Serial是否有变，如有变则更新之。
第6行，Retry部分，如Refresh过程不能完成，重试的时间间隔。
第7行，Expire部分，如SLAVE无法与MASTER取得联系，SLAVE继续提供DNS服务的时间，这里为2W(两周时间)。Expire时间到期后SLAVE仍然无法联系MASTER则停止工作，拒绝继续提供服务。Expire的实际意义在于它决定了MASTER服务器的最长下线时间(如MASTER迁移，DOWN机等)。
第8行，Minimum部分，这个部分定义了DNS对否定回答(NXDOMAIN即访问的记录在权威DNS上不存在)的缓存时间。
第9-11行，定义了该域名的3个权威DNS服务器。通常NS记录的TTL大些为宜，这里为2天。设置过小只会增加服务器无谓的负担，同时解析稳定性会受影响。
第12-15行，比较简单，是两个A,CNAME,MX记录，不再讨论了。
名词解释：
- SOA记录：权威记录从这里开始，它定义了3-8行这些重要的参数。
- A记录：记录域名到IP之间的关联。
- CAME记录：让张三住到李四家里，这时张三李四是同一个地址。
- MX记录：定义了发往XXX@ABC.COM邮箱的邮件服务器地址。
- TXT记录：这个记录的内容是文本格式如126.COM的TXT为"v=spf1 include:spf.163.com -all",TXT通常用于邮件服务器来标识自己的身份避免被认为是垃圾邮件服务器。这里不再深入讨论。
- 其他不常用记录类型没有列出！
域名安全
网络安全不应该只停留在口头上，事实证明网络安全隐患遍布互联网。近期Twitter与Baidu出现的问题如出一辙。以下多出自本人见解未必全面，仅供探讨。
网络安全层面
-
互联网线路的安全隐患，如数据包中途探嗅与篡改、骨干路由器被入侵等，这个层面是网络运营商的问题，我们作为互联网用户是无力涉及的。
-
服务器安全隐患，包括操作系统、运行的软件及服务器自身的物理安全问题等。提升服务器安全总的原则是“一多一少”，一多是做个勤快的管理员，多多关注软件的BUG公布并及时升级软件。一少是尽量少的运行非必要的程序，尽量少的向互联网开放网络端口。举个简单的例子，互联网上很大部分的服务器都向外开放SQL数据库的监听端口，真不知道管理员是怎么想的。
-
一度被人遗忘的角落就是域名的安全，究其原因主要是很少人真正认识域名与DNS体系，缺乏相关的技术支持。
本文将就上面提到的“3”即域名安全问题展开。首先了解一下域名体系现存的安全隐患。主要有如下3个方面：
-
域名管理平台的安全问题，有能力出售域名的商家多如牛毛，但有能力管理好域名的就很少。我们知道通常情况下域名提供商对其出售的域名提供权威DNS来解析域名，并且提供域名管理平台（WEB管理平台）。域名管理平台主要功能首先是登录验证并添加/修改域名的NS、A、CNAME、MX、TXT等记录。一旦这个域名管理平台发生问题，后果不言而喻。Twitter与Baidu出现的问题就是通过域名管理平台篡改了域名的NS记录导致的。现实中域名所有者安全意识淡薄往往设置非常简单的登录管理密码，或表现为从来不更新密码，这都是危险的信号。
-
网络运营商的恶意拦截域名解析，这个现象多出现在国内。具体表现为地方性域名解析异常。其做法一般是运营商在所属的公用DNS上硬性绑定域名解析到特定IP地址上。深层次原因无非是利益驱动。
-
病毒、木马等滋事捣乱，这个只发生在受侵害的计算机上，具体表现为本机DNS地址被篡改为一个恶意DNS上，导致解析异常。
解决之道
-
针对域名管理平台的安全问题，普通大众（穷人）由于受各种条件限制能做的不多：首先选择比较好的域名提供商并树立起域名安全意识。对大型网站能做的就比较多（主要是有钱啊，如google、baidu等）：首先是直接向域名机构购买域名（跳过域名提供商），用自己的域名管理平台管理域名（当然这个后台是不对外的，用的时候开机，平时在保险柜），这就从根本上遏制了“黑客”的滋扰。
-
对于网络运营商的恶意拦截域名解析，受害者通常是无权无钱的。能做的只能是向其上级部门申诉，祈祷上帝帮忙了。
-
针对病毒、木马等滋事捣乱，涉及面比较小，没啥可说的，杀之而后快。
域名解析的授权
首先是两个相关的概念：
- 域名授权： 指定谁是该域名的权威DNS，即由谁负责解析该域名（由NS记录操作完成）。
- 权威DNS: 特指对特定域名具有权威发布能力的DNS；互联网上域名（域名记录）解析果的原出处。
目前域名解析授权状况
目前在互联网上域名解析授权大体上是谁出售域名就把域名的权威DNS授权给谁并由其提供域名的权威DNS来完成域名解析工作，如购买了新网域名。默认就是由新网的权威DNS（nsx.xinnetdns.com、nsx.xinnet.cn）负责所售域名解析:
[root@test root]#dig @a.gtld-servers.net xinnet.com ns
;; ANSWER SECTION:
xinnet.com. 172800 IN NS ns.xinnet.cn.
xinnet.com. 172800 IN NS ns.xinnetdns.com.
xinnet.com. 172800 IN NS ns2.xinnet.cn.
xinnet.com. 172800 IN NS ns2.xinnetdns.com.
域名解析授权是怎么实现的
域名解析授权是个树状的，从上而下的分层体系，简图如下：
首先“.”DNS把COM/NET/CN/ORG/TV等等域名按后缀的不同分别授权给不同的DNS，以利于分别管理。如COM/NET域名被授权给了如下几个权威DNS。这里不难想像要修改COM/NET的授权DNS要到“.”DNS上去操作才能完成。
[root@test root]#dig com. ns
;; ANSWER SECTION:
com. 96045 IN NS d.gtld-servers.net.
com. 96045 IN NS g.gtld-servers.net.
com. 96045 IN NS b.gtld-servers.net.
com. 96045 IN NS k.gtld-servers.net.
com. 96045 IN NS f.gtld-servers.net.
com. 96045 IN NS l.gtld-servers.net.
com. 96045 IN NS j.gtld-servers.net.
com. 96045 IN NS a.gtld-servers.net.
com. 96045 IN NS i.gtld-servers.net.
com. 96045 IN NS m.gtld-servers.net.
com. 96045 IN NS e.gtld-servers.net.
com. 96045 IN NS h.gtld-servers.net.
com. 96045 IN NS c.gtld-servers.net.
同理可知，要指定或修改ABC.COM的权威DNS要去顶级DNS上操作。通常来说一般的域名所有者是无权登录顶级DNS进行操作的。只能通过域名提供商（如新网，万网等）的专用接口（位于域名商的域名管理平台上）来间接操作顶级DNS上的记录。
以ABC.COM为例简要说明怎么指定自己的权威DNS，假设ABC.COM是在新网购买，那么默认该域名的权威DNS就是nsx.xinnetdns.com、nsx.xinnet.cn。这时候要修改默认权威DNS。首先登录新网的域名管理后台，找到修改域名DNS页面即可完成操作（详细过程这里有：http://docs.aidns.cn/help02.htm）。操作完成后要验证一下是否修改成功：
[root@test root]#dig @a.gtld-servers.net abc.com ns
;; ANSWER SECTION:
abc.com. 172800 IN NS ns1.ai-dns.com.
abc.com. 172800 IN NS ns2.ai-dns.com.
abc.com. 172800 IN NS ns3.ai-dns.com.
这里我们把ABC.COM授权给了nsx.ai-dns.com了。
域名权威DNS的再授权
以ABC.COM为例，再授权是指在nsx.ai-dns.com上面再次指定该域名的权威DNS，再授权的意义有这么几个：
-
扩展现有的权威DNS数量，如现有ns1,ns2,ns3.ai-dns.com共三台DNS，现在要增加到4台，则可以在原3台DNS上abc.com的ZONE文件内增加ns4这个NS记录。原来的ZONE内容：
$TTL 2d $ORIGIN abc.com. @ 3600 IN SOA ns1.ai-dns.com. root.ai-dns.com.( 2288091841 1h 600 1w 900 ) @ 2d IN NS ns1.ai-dns.com. @ 2d IN NS ns2.ai-dns.com. @ 2d IN NS ns3.ai-dns.com.增加ns4这个NS记录后为：
$TTL 2d $ORIGIN abc.com. @ 3600 IN SOA ns1.ai-dns.com. root.ai-dns.com.( 2288091841 1h 600 1w 900 ) @ 2d IN NS ns1.ai-dns.com. @ 2d IN NS ns2.ai-dns.com. @ 2d IN NS ns3.ai-dns.com. @ 2d IN NS ns4.ai-dns.com.
当然增加NS4的操作也可以在顶级DNS上完成，不再赘述。
2. 把权威DNS重新授权给其他DNS，如把原来的权威DNS（nsx.ai-dns.com）重新授权给别人（nsx.ddd.com）。操作过程同上，不再赘述。
### 再授权可能存在的潜在问题
再授权无疑使得域名解析授权变得更灵活，但是存在以下潜在的隐患。当原授权的权威DNS（即在顶级DNS定义的权威DNS）故障时，这时再授权的DNS将无法工作，导致域名无法解析（这是由域名解析过程是自上而下的这个特性决定的）。同时也增加了安全隐患。
附加部分1：慎用WHOIS来查看域名权威DNS。
对于域名的Whois数据库是由域名销售商控制的，即每个域名销售商都有自己的WHOIS服务器，这些服务器用来存储自身出售的域名信息，如域名所有人，联系方法，到期时间等内容。WHOIS信息中显示的域名当前权威DNS信息很可能没有及时与域名实际的权威DNS信息同步而导致错误的判断。
附加部分2：“.”根DNS是怎么被授权的？
由于“.”根DNS所处域名解析体系的顶端，无法按照常规方法对其授权。到目前为止其授权方法是把所有“.”DNS列表存放在一个文本文件内（自己授权给自己），名字通常为root.hint内容如下（部分节选）：
. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
## 擅用日志排除BIND故障
这么多年来耳闻目染，发现网友提出的几乎99%的问题本来是不需要求助就能解决的，追其根源是不擅于（或不知道）使用软件本身提供的运行日志来解决问题。本文就BIND服务器日志简要说明。这里假设一网友反映“启动named进程后配置的域名解析服务不工作”这一简单问题说明怎么使用named的日志来解决。
首先了解一个named启动参数:“-g”，这个参数可以使named启动过程的细节展现在面前，自然的哪里的问题就一目了然了。
[root@test ~]#named -gc /var/named/etc/named.conf 02-Jan-2010 11:05:54.687 starting BIND 9.5.1-P3 -gc /var/named/etc/named.conf 02-Jan-2010 11:05:54.687 found 1 CPU, using 1 worker thread 02-Jan-2010 11:05:54.688 using up to 4096 sockets 02-Jan-2010 11:05:54.697 loading configuration from ‘/var/named/etc/named.conf’ 02-Jan-2010 11:05:54.698 /var/named/etc/named.conf:45: missing ‘;’ before ‘key’ 02-Jan-2010 11:05:54.698 loading configuration: failure 02-Jan-2010 11:05:54.698 exiting (due to fatal error)
我们看到日志提示在named.conf文件的第45行少写了“；”，好，问题找到了排除问题就简单了。打开named.conf把那个“；”补上。
[root@test ~]##named -gc /var/named/etc/named.conf 02-Jan-2010 11:06:33.807 starting BIND 9.5.1-P3 -gc /var/named/etc/named.conf 02-Jan-2010 11:06:33.807 found 1 CPU, using 1 worker thread 02-Jan-2010 11:06:33.808 using up to 4096 sockets 02-Jan-2010 11:06:33.817 loading configuration from ‘/var/named/etc/named.conf’ 02-Jan-2010 11:06:33.819 using default UDP/IPv4 port range: [49152, 65535] 02-Jan-2010 11:06:33.819 using default UDP/IPv6 port range: [49152, 65535] 02-Jan-2010 11:06:33.821 no IPv6 interfaces found 02-Jan-2010 11:06:33.821 listening on IPv4 interface re0, 192.168.0.20#53 02-Jan-2010 11:06:33.822 listening on IPv4 interface re0, 192.168.0.10#53 02-Jan-2010 11:06:33.823 listening on IPv4 interface lo0, 127.0.0.1#53 02-Jan-2010 11:06:33.832 command channel listening on 127.0.0.1#953 02-Jan-2010 11:06:33.833 ignoring config file logging statement due to -g option 02-Jan-2010 11:06:33.840 zone 127.IN-ADDR.ARPA/IN: loaded serial 1 02-Jan-2010 11:06:33.840 zone test.com/IN: loaded serial 912200620 02-Jan-2010 11:06:33.841 running 02-Jan-2010 11:06:33.841 zone test.com/IN: sending notifies (serial 912200620)
问题排除。上面方法适用于下列情形：
1. 安装BIND后调试named,看看有没有问题。
2. 出现致命错误named中断运行了。
3. 非重要DNS服务器，可以停机检查的。
对于正在运行的DNS服务器，不想让其停止运行，这时候要发现潜在问题再使用上述方法就不太适宜了。这就要求我们可以让named把日志记录到专门的文件内，供我们随时查询。具体操作是在named.conf配置log:
logging { channel warning { file “log/named.log” versions 3 size 2048k; severity warning; print-category yes; print-severity yes; print-time yes; }; channel query { file “log/query.log” versions 3 size 2048k; severity info; print-category yes; print-severity yes; print-time yes; }; category default { warning; }; category queries { query; }; };
这里我们让named把named运行日志和日常查询日志分别记录到named.log和query.log文件内。最后测试一下解析是否正常了：
[root@test ~]#dig @localhost www.test.com ; «» DiG 9.5.1-P3 «» @localhost www.test.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 45637 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.test.com. IN A ;; ANSWER SECTION: www.test.com. 3600 IN A 12.1.1.1 ;; AUTHORITY SECTION: test.com. 172800 IN NS ns2.test.com. test.com. 172800 IN NS ns1.test.com. test.com. 172800 IN NS ns3.test.com. ;; ADDITIONAL SECTION: ns1.test.com. 3600 IN A 12.2.2.2 ns2.test.com. 3600 IN A 12.3.3.3 ns3.test.com. 3600 IN A 12.4.4.4 ;; Query time: 29 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 2 11:48:03 2010 ;; MSG SIZE rcvd: 148
由于是针对初级用户，更深相关细节不再赘述。