本节书摘来自异步社区《DNS与BIND（第5版）》一书中的第7章，第7.6节,作者： 【美】Joseph Davies 更多章节内容可以访问云栖社区“异步社区”公众号查看。
7.6 保持一切平稳运行
维护的一个重要意义在于：能够在真正的问题出现之前，察觉到某些异常。问题发现得越早，就越容易进行修复。正如老话说的：预防为主，治疗为辅。
这一章的内容不全然是关于故障排除的（本书稍后会有一章专门讨论如何排除故障），更偏重于故障出现前的预防。而故障排除是在问题变得复杂后，不得不进行的操作，并且需要根据症状来找出问题。
下面两小节将讨论预防性维护的相关内容：定期查看syslog文件及BIND名称服务器的统计信息，以检查是否存在任何问题。就像给名称服务器做体检一样。
7.6.1 常见的Syslog消息
named能产生大量的syslog消息。而实际上，能看到的只是很少一部分。下面会介绍常见的syslog消息，但不包括区域数据文件的语法错误报告。
每当named启动时，便会发送一条严重级别为LOG_NOTICE的消息。在BIND 8名称服务器中，该消息如下所示：
在BIND 9名称服务器中，该消息明显省略了不少内容：
这条消息记录了named的启动时间、所运行的BIND版本以及谁在何处建立了它（对BIND 8而言）。当然，这没有什么需要特别留意的。但是如果不确定操作系统所支持的BIND版本，则可以参考该消息。
每当向名称服务器发送reload命令时，BIND 8名称服务器会发送如下严重级别为LOG_NOTICE的消息：
BIND 9名称服务器的日志如下：
这条消息记录了named重新载入其数据库（reload命令的执行结果）的时间。这也没有什么需要特别留意的。但是当追踪一条有问题的资源记录在区域数据中存在了多长时间，或者追踪更新过程中的错误所导致的整个区域丢失了多长时间时，则可能会对该消息感兴趣。
在名称服务器启动后，可能会立即看到另一条消息：
这意味着名称服务器认为操作系统不支持getrlimit()和setrlimit()系统调用，当试图定义coresize、datasize、stacksize或files时会用到这两个系统调用。但无论是否真的在配置文件中使用了这些子语句，BIND都将显示该消息。如果没有使用这些子语句，则可以忽略该消息。如果使用了，并且操作系统实际上是支持getrlimit()和setrlimit()的，则需要定义HAVE_GETRUSAGE并重新编译BIND。该消息的严重级别为LOG_INFO。
如果在具有多个网络接口（特别是虚拟网络接口）的主机上运行名称服务器，则可能会在启动后不久，或者甚至可能在名称服务器已经运行了一段时间后，看到如下消息：
这意味着BIND已经用完了文件描述符（file descriptor）。BIND会使用相当多的文件描述符：其监听的每个网络接口需要使用两个（UDP和TCP各一个），而且打开区域数据文件还需要一个。如果这超出了操作系统对进程所做的限制，则BIND就无法取得更多文件描述符，那么就会看到该消息。该消息的严重级别取决于，是BIND的哪部分无法获得文件描述符：越是重要的子系统，严重级别就越高。
接下来，要么让BIND少使用一些文件描述符，要么增加操作系统能够提供给BIND使用的文件描述符数量：
如果不需要BIND监听所有网络接口（特别是虚拟的网络接口），可以使用listen-on子语句来配置BIND仅监听必要的接口。listen-on的语法详见本书 第10章。
如果操作系统支持getrlimit()和setrlimit()（如前所述），则可以使用files子语句来配置名称服务器使用更多的文件。files子语句的语法详见本书第10章。
如果操作系统对打开文件数量的限制过于严格，则可以在启动named前，使用ulimit命令提高该限制值。
每当名称服务器载入一个区域，就会发送如下严重级别为LOG_INFO的消息：
这条消息记录了名称服务器载入区域的时间、该区域的类别（在本例中为IN），以及区域SOA记录的序号。
大约每个小时，BIND 8名称服务器都会发送严重级别为LOG_INFO的消息，内容是当前的统计信息：
（BIND 9不会把统计信息作为日志消息来发送。）每条消息的前两个数字是时间。如果用第一个数字减去第二个数字，就能知道服务器已经运行了多少秒钟。（名称服务器若能自动计算该多好。）CPU条目显示了服务器在用户模式（user mode）和系统模式（system mode）下所消耗的时间分别为13.01秒和3.26秒。同样地，接下来显示了子进程的统计信息。NSTATS消息列出了服务器所接收到的查询类型以及每类查询的数量。XSTATS消息列出了附加的统计信息。本章稍后将会详细介绍NSTATS和XSTATS下的统计信息。
如果BIND发现一个不符合RFC 952标准的名称，就会记录一条syslog错误：
该消息的严重级别为LOG_ERROR。请参考本书第4章的主机命名规则。
还有另一条严重级别为LOG_ERROR的syslog消息，是关于区域数据的：
该消息意味着区域数据有问题。例如，可能有如下配置：
ts2的MX记录是错误的，并将导致产生上面的错误消息。ts2是toystory2的一个别名，而toystory2是规范名称。前面曾介绍过，当名称服务器查找一个名称并找到CNAME时，它会用规范名称替换原始名称，并试图查找规范名称。因此，当服务器查找ts2的MX数据时，它会找到一条ts2的CNAME记录，然后就会查找toystory2的MX记录。由于服务器会依据ts2的CNAME记录进行查找，所以它永远也不会使用ts2的MX记录；实际上，该记录是非法的。换句话说，一台主机的所有资源记录都必须使用规范名称；在应该使用规范名称的地方却使用别名是错误的。
下面的消息表明，一个BIND 8的slave在试图进行区域传输时，无法访问任何master服务器：
BIND 9的slave则会产生如下消息：
该消息在BIND 8上的严重级别为LOG_NOTICE，而在BIND 9上的严重级别为LOG_ERROR，并且仅在第一次区域传输失败时发送该消息。（当区域传输最终成功时，BIND会发送另一条syslog消息，告知区域传输已经完成。）当该消息第一次出现时，不需要立即采取任何行动。名称服务器将会根据SOA记录中的重试周期，继续尝试区域传输。几天以后（或者到了过期时间的一半），可以检查服务器是否能够完成区域传输。或者，可以通过检查备份区域数据文件的时间戳，来验证区域传输是否完成。当区域传输成功时，就会创建一个新的备份文件。如果名称服务器发现区域是最新的，也会使用UNIX的touch命令处理备份文件。无论哪种情况，备份文件的时间戳都会被更新。因此，只要在slave上执行ls -l /usr/local/named/db_*_命令，就可以知道slave与master服务器最后一次同步各个区域的时间。本书将在第14章介绍如何排除slave区域传输失败的问题。
如果查看syslog消息，就会在slave取得新的区域数据时，或在使用类似nslookup的工具传输区域时，看到严重级别为LOG_INFO的syslog消息：
如果使用allow-transfer子语句（将在第11章予以介绍）来限制哪些服务器可以载入区域，那么在该消息中所看到的可能是denied而不是started：
只有在捕获严重等级为LOG_INFO的syslog消息时，才会看到以下消息：
通常，该消息意味着名称服务器有一些bug，导致其发送错误的响应包。这个错误可能发生在远程名称服务器（192.1.1.1）上而不是本地服务器（wormhole）。要诊断这种错误，必须抓取网络上的响应包并加以解码。手动解码DNS包已经超出了本书的范围，所以这里不会涉及具体细节。发生这种错误的一个可能的原因是：如果响应包表示其应答部分包含多个答案（例如四条地址资源记录），而实际上却只有一个答案。这时只能通过电子邮件（假设可以通过地址查找到主机名称）通知问题主机的管理员。产生该消息的另一个可能的原因是：下层网络通过某种方式改变（或破坏）了UDP响应包。由于对UDP包的校验是可选的，所以低层网络可能不会发现这个错误。
当试图将属于另一个区域的记录悄悄放入自己的区域数据文件中时，BIND 8的named会记录如下消息：
而BIND 9则会记录如下消息：
举例来说，如果使用如下区域数据：
把bar.edu区域的数据添加到movie.edu的区域数据文件中，就会产生上述错误消息。这条syslog消息的严重级别为LOG_WARNING。
前面曾经介绍过，不能在资源记录的数据部分中使用CNAME。BIND 8将会检测到此错误：
而BIND 9直到仍不能检测到此错误。
下面的例子就是一个错误的资源记录：
第二条NS记录应该是monsters-inc.movie.edu而不是mi.movie.edu。当启动名称服务器时，这条syslog消息不会立刻出现。
提示
只有在查询到出问题的数据时，才会出现这个syslog消息。在BIND 8服务器上，该syslog消息的严重级别为LOG_INFO。
下面的消息表明，名称服务器可能正在保护自己，以抵抗某种网络攻击：
名称服务器向远程名称服务器发送一个查询，但是所收到的应答却不是来自名称服务器列出的任何一个远程名称服务器的地址。其潜在的安全问题是：入侵者诱使名称服务器去查询远程名称服务器，与此同时入侵者发送应答（将该应答伪装成由远程名称服务器发出），并希望名称服务器会将其加入缓存。或许入侵者会发送一个假的PTR记录，将他的一台主机的IP地址，指向被信任的主机域名。一旦假的PTR记录进入缓存，入侵者就能使用BSD的一个“r”命令（例如，rlogin）来取得系统的访问权。
不那么偏执的管理者可能会意识到产生此问题的另一种情况：如果父区域的名称服务器只知道子区域中一个多宿主名称服务器的其中一个IP地址，则父区域只会告知名称服务器其所知道的IP地址；而当名称服务器使用这个地址查询远程多宿主名称服务器时，远程名称服务器却从另外一个IP地址进行响应。不过，如果远程名称服务器的主机上运行的是BIND，则应该不会发生这个问题，因为BIND会尽可能使用查询时所用的IP地址来进行响应。这条syslog消息的严重级别为LOG_ INFO。
下面是一个有趣的syslog消息：
目前已定义的类别有：class 1，Internet（IN）；class 3，Chaos（CH）；以及class 4，Hesiod（HS）。哪来的class 226？这正是名称服务器通过这条syslog消息想要表达的：一定是哪里出错了，因为根本就没有class 226。那么应该怎么做呢？什么也做不了，真的。该消息没有提供足够的信息；不知道这个查询来自何处，也不知道查询了什么。另一方面，如果是class字段出错了，那么查询中的域名也可能只是一堆垃圾。该问题的真正原因可能是：远程名称服务器或解析器出现了故障，或者UDP报文损坏了。这条syslog消息的严重级别为LOG_INFO。
下面的消息可能会在备份其他区域时出现：
唉，讨厌的253.253.192.in-addr.arpa的管理员改变了序号格式却没有通知你。这算是对管理其区域的slave的某种感谢吗？应该给这个管理员发个消息，问问这个改变是故意的还是不小心导致的。如果是故意的，或者不想联系该管理员，那么必须在本地处理该问题：首先终止slave，然后删除该区域的备份文件，最后重新启动服务器。该过程会将slave上所有旧的序号删除，所以它会很高兴地接受新的序号。这条syslog消息的严重级别为LOG_ INFO。
顺便说一下，如果那个讨厌的管理员运行的是BIND 8或9的名称服务器，那么他必定错过（或忽略）了其服务器所记录的一条消息，告知他将区域序号给更正回来。在BIND 8名称服务器上，该消息如下所示：
在BIND 9名称服务器上，该消息如下所示：
这条消息的严重级别为LOG_ NOTICE。
还应该提醒他记住这次教训，无论对名称服务器做出何种更改，都应该仔细检查syslog。
毫无疑问，下面这条BIND 8消息非常眼熟：
在BIND 9上，则如下所示：
这表示Internet上名称服务器的授权关系出了问题。父名称服务器将子域授权给子名称服务器，但是该子名称服务器却不是该子域的权威。在上例中，edu的名称服务器将movie.edu授权给主机.125，但是该主机上的名称服务器却不是movie.edu的权威。除非认识movie.edu的管理员，否则对此问题也无能为力。这条消息的严重级别为LOG_INFO。
如果配置文件中有如下内容：
则每当名称服务器接收到查询时，都会产生一条严重等级为LOG_INFO的syslog消息：
不过，BIND 9中的格式稍有不同：
这些消息包括发送查询的主机IP地址以及查询本身。在BIND 及其后续版本的名称服务器上，递归查询被标记为XX+而不是XX。BIND 9名称服务器则用“+”标记递归查询，用“-”标记非递归查询。而BIND 8.4.3及其后续版本、BIND 9.3.0及其后续版本甚至会用E和S来分别标记EDNS0查询和TSIG-signed查询。（EDNS0可参考第10章，TSIG可参考第11章。）
如果在一台繁忙的名称服务器上记录所有的查询，要确保其拥有足够的磁盘空间。（在正在运行的服务器上，可以使用querylog命令切换是否记录查询。）
启动BIND ，可能会看到如下syslog消息：
在BIND 9名称服务器上，则如下所示：
这些消息表明：有一个名称服务器正在运行，而在第一个名称服务器尚未终止的情况下，又启动了第二个名称服务器。可能与预想的不同，第二个名称服务器会继续运行，但不会监听任何接口。
7.6.2 了解BIND的统计信息
应该定期查看名称服务器的统计信息，主要是了解它们有多忙。下面将举一个名称服务器统计信息的例子，并解释其每一行的含义。在名称服务器正常运行期间，会处理许多查询和响应，所以，首先会介绍一个典型的交互过程。
如果不清楚查询的整个过程，则很难理解统计信息的含义。为了帮助理解名称服务器的统计信息，图7-2展示了一个应用程序查询域名的过程。该应用程序（FTP）会查询本地名称服务器。本地名称服务器之前已经查询过该区域的数据，并且知道远程名称服务器的位置。它会查询每台远程名称服务器两次，以找到答案。与此同时，应用程序超时了，并且又发送了一个同样的查询。
请记住，即使名称服务器向远程名称服务器发送了一个查询，远程名称服务器未必能够立刻接收到该查询。这个查询可能被下层网络给延误或者遗失了，也可能是远程服务器主机正忙于处理其他应用。
请注意，BIND名称服务器只有在它仍然试图应答原来的查询时，才能检测出该查询是否重复。因为本地名称服务器还在处理应用程序的第1次查询，所以它才能检测到重复的查询。但是1号远程名称服务器没有检测到来自本地名称服务器的重复查询，因为它已经对前一个查询做出了应答。在本地名称服务器接收到来自1号远程名称服务器的第1次响应后，所有其他响应都作为重复响应而被丢弃。整个过程需要进行以下交互：
![image]()
图7-2 查询/响应的交互过程
这些交互将在本地名称服务器上产生如下统计信息：
在上面的例子中，本地名称服务器只接收到来自应用程序的查询，也只向远程名称服务器发送查询。通常，本地名称服务器也会接收到来自远程名称服务器的查询（也就是说，除了询问远程服务器自己所需要的信息外，本地服务器也会提供远程服务器所需的信息），但是为了简单起见，这个例子没有显示任何来自远程名称服务器的查询。
1．BIND 8的统计信息
现在已经了解了应用程序与名称服务器之间典型的交互过程，以及由此产生的统计信息，下面介绍一个内容更丰富的统计信息例子。要得到BIND 8名称服务器的统计信息，可以使用ndc：
等待几秒，就可以查看名称服务器当前工作目录下的named.stats文件。如果统计信息没有转储到该文件，则服务器可能在编译时没有定义STATS，因此就不会收集统计信息。下面是来自Paul Vixie的BIND 名称服务器的统计信息。而BIND 8名称服务器的统计信息有着相同的项目（RnotNsQ除外），不过项目的排列顺序不一样。对于BIND 9名称服务器而言，以9.1.0为例，所收集的是一组完全不同的统计信息，详情请参阅下一小节。
如果BIND 8名称服务器在“(Global)”之后没有包含任何以IP地址分类的段落，则要想追踪每台主机的统计信息，就需要在options语句中将host-statistics设置为
然而，保存主机的统计信息需要相当大的内存，所以除非是试图建立名称服务器的活动档案，否则通常不会这么做。
现在一行一行地来解释这些统计信息。
上面这行记录了这段统计信息的转储时间。圆括号中的数字（800708260）就是从UNIX纪元（1970年1月1日）开始算起，直到转储时的总秒数。还好，BIND会将其转换为实际的日期和时间：1995年5月17日，上午3点57分40秒。
上面这行记录了本地名称服务器已经运行了多长时间（以秒为单位）。将其除以86400（60×60×24，即一天的总秒数），就可以转换成天数。该服务器已经运行了大约8.5天。
上面这行记录了从上次重载后，本地名称服务器已经运行了多长时间（以秒为单位）。只有当服务器是一个或多个区域的primary名称服务器，“time since reset”与“time since boot”的数值才可能会不同。因为区域的slave名称服务器会通过区域传输来自动取得最新的数据，而通常不会重载。既然该服务器已经reset过，那么它就可能是某个区域的primary名称服务器。
这个名称服务器收到过14条类型无法识别的查询。如果不是有人正在试验新的类型，那么就是哪里的设计有缺陷，或许Paul需要升级他的名称服务器了。
上面这行记录了已经完成了268 459次地址查询。地址查询通常是最常见的查询类型。
上面这行记录了已经完成了3 044次名称服务器查询。在内部，当名称服务器试图查找root区域的服务器时，便会产生NS查询。在外部，dig和nslookup之类的应用程序也可以用来查询NS记录。
为了将邮件地址规范化（用规范名称替换别名），有些版本的sendmail会产生CNAME查询。其他版本的sendmail则使用ANY查询（稍后予以说明）。此外，dig或nslookup也很有可能产生CNAME查询。
slave名称服务器会利用SOA查询来检查其区域数据是否最新。如果数据不是最新的，它接着会以AXFR查询来进行区域传输。由于这组统计信息也会显示AXFR查询，所以可以借此判断slave名称服务器是否从该服务器下载过区域数据。
指针查询将地址解析成名称。有许多种软件都会查找IP地址：inetd、rlogind、rshd、网络管理软件以及网络追踪软件。
主机信息查询很可能来自于某些以交互方式查找HINFO记录的人。
sendmail之类的邮件程序，会在电子邮件的投递过程中进行邮件交换器查询。
有些应用程序必须进行文本查询，因此该数值才会这么大。这可能是有人使用了类似Harvest的工具，Harvest是一项由科罗拉多大学所研发的信息搜索及检索技术。
这是一个比较新的记录类型，用来将域名解析为OSI网络服务器访问点（OSI Network Service Access Point）的地址。
slave名称服务器发送AXFR查询以便启动区域传输。
ANY查询可以请求一个名称所对应的任意类型的记录。sendmail是最常使用该查询类型的程序。由于sendmail会查找一个邮件目的地的CNAME、MX以及地址记录，所以它会发送ANY记录类型的查询，以便将所有的资源记录都缓存在本地名称服务器上。
其余的统计信息按照主机分别保存。如果查看曾与名称服务器交换过数据包的主机列表，将会发现名称服务器到底有多忙碌：会在列表中看到上百甚至上千台主机。虽然列表的大小令人印象深刻，但是统计信息本身值得注意的内容却不多。下面将解释所有的统计信息，甚至那些计数为0的项目，不过只有少数的统计信息是有用的。为了使统计信息更容易阅读，需要通过工具来展开这些统计信息（因为其输出格式非常紧凑）。本书英文版作者编写了一个名为bstat的工具来完成这项工作。下面是该工具的输出结果：
在原始的统计信息（没有经过bstat处理）中，每台主机的IP地址后面是一串数值列表。该表的列标题位于开头，是一些形如密码的符号。这些符号被分成几行，但是主机的统计信息却全部在一行中。接下来，将会以15.255.152.2（relay.hp.com）这台曾和名称服务器交互过的主机的统计信息为例，简要介绍每行的含义。为了便于说明，本书将先写出列标题（例如RQ），然后再写出relay主机在该列中的数值。
RQ 441
RQ是接收到的来自relay主机的查询数量。这是因为relay主机需要查询该名称服务器所提供的区域信息。
RR 137
RR是接收到的来自relay主机的响应数量。这是针对来自该名称服务器的查询所做出的响应。不要试图将此数值同RQ联系在一起，因为它们之间没有任何关系。RQ是来自relay主机的查询数量；而RR则是relay主机提供给该名称服务器的应答（因为该名称服务器曾向relay主机发送查询）。
RIQ 0
RIQ是接收到的来自relay主机的逆向查询数量。原本通过逆向查询可以将地址解析成名称，不过该功能现在已由PTR记录来处理。老版本的nslookup在启动时会使用逆向查询，所以有可能看到RIQ的值不为0。
RNXD 1
RNXD是接收到的来自relay主机“no such domain”（无此域）应答的数量。
RFwdQ 2
RFwdQ是接收到的来自relay主机的，在能够应答之前还需要进一步处理的查询数量。如果主机的解析器（通过resolv.conf）被配置为，将所有查询发送至名称服务器，则该数据会比现在大得多。
RFwdR 108
RFwdR是接收到的来自relay主机的，需要传回发送此查询的应用程序的响应数量。
RDupQ 0
RDupQ是接收到的来自relay主机的重复查询的数量。只有当解析器（通过resolv.conf）被配置为查询该名称服务器时，才会出现重复查询。
RDupR 0
RDupR是接收到的来自relay主机的重复响应的数量。当名称服务器无法在待定查询（pending queries）列表中找到引发响应的原始查询时，该响应就是重复响应。
RFail 0
RFail是接收到的来自relay主机的SERVFAIL响应的数量。SERVFAIL响应表明发生了某种服务器故障。通常产生服务器故障响应的原因是，远程服务器在所读取的区域数据文件中发现了语法错误。因此，对于有错误的区域数据文件中的区域数据所做的任何查询，都会导致来自远程名称服务器的服务器故障应答。这可能是引发SERVFAIL响应的最常见的原因。另外，当远程名称服务器试图分配更多内存却失败时，或者远程slave名称服务器的区域数据超时，也会导致服务器故障响应。
RFErr 0
RFErr是接收到的来自relay主机的FORMERR响应的数量。FORMERR表示远程名称服务器认为本地名称服务器的查询存在格式错误。
RErr 0
RErr是除了SERVFAIL或FORMERR之外的错误数量。
RTCP 0
RTCP是通过TCP连接接收到的来自relay主机的查询数量。（大部分查询都通过UDP。）
RAXFR 0
RAXFR是区域传输被启动的数量。该数值为0则表明，relay主机不是该名称服务器所服务的任何区域的slave。
RLame 0
RLame是接收到的错误授权的数量。如果该数值不为0，则表示某个区域被授权给位于此IP地址的名称服务器，但是该名称服务器却并非此区域的权威。
ROpts 0
ROpts是接收到的包含IP options设置的数据包数量。
SSysQ 13
SSysQ是发送给relay主机的系统查询的数量。系统查询是由本地名称服务器所启动的。大部分系统查询都会发送至root名称服务器，因为系统查询被用来保持root名称服务器列表始终是最新的。不过如果地址记录（A）比名称服务器记录（NS）先超时，也会使用系统查询来查找名称服务器的地址。由于relay主机不是root名称服务器，所以这些系统查询必定是由于第二种原因产生的。
SAns 439
SAns是发送给relay主机的应答数量。该名称服务器从relay主机收到441次查询（RQ），却只应答了439次。不知道发生了什么导致有2次查询没有被应答……
SFwdQ 85
SFwdQ是当查询的结果不在该名称服务器的区域数据或缓存中时，再发送（转发）给relay主机的查询数量。
SFwdR 7
SFwdR是从某个名称服务器发送（转发）给relay主机的响应数量。
SDupQ 84
SDupQ是发送给relay主机的重复查询的数量。不过事情可能没有看起来这么糟糕。如果查询首先发送给任何其他名称服务器，则该数值就会被加1。虽然relay主机可能在第一次接收到查询时就做出了应答，但是该查询仍会被当做重复查询，因为在发送给relay主机之前，该查询已被发送给其他名称服务器。
SFail 0
SFail是发送给relay主机的SERVFAIL响应的数量。
SFErr 0
SFErr是发送给relay主机的FORMERR响应的数量。
SErr 0
SErr是当目的地址是relay主机时，sendto()系统调用失败的数量。
RNotNsQ 0
RNotNsQ是接收到的并非来自53号端口（名称服务器端口）的查询数量。在BIND 8之前，所有名称服务器的查询都来自53号端口。凡不是来自53号端口的查询都来自于解析器。然而，BIND 8名称服务器的查询可以来自53之外的端口，这导致该统计信息失去了意义，因为再也无法区分查询是来自于解析器还是名称服务器。因此，在BIND 8的统计信息中，已不再统计RNotNsQ的值。
SNaAns 431
SNaAns是发送给relay主机的非权威应答的数量。由该数值可以得知，发送给relay主机的439次应答（SAns）中，有431次来自于缓存数据。
SNXD 0
SNXD是发送给relay主机的“no such domain”（无此域）应答的数量。
2．BIND 9的统计信息
BIND 是BIND 9中第一个能够保存统计信息的版本。可以使用rndc促使BIND 9转储其统计信息：
如同BIND 8名称服务器，BIND 9名称服务器会将统计信息转储到其工作目录下一个名为named.stats的文件中。不过，这些统计信息看起来和BIND 8的完全不同。下面是来自于BIND 9名称服务器统计文件中的内容：
每当名称服务器接收到stats命令，都会在统计信息文件最后附加一段新的统计信息（该段内容介于“+++ Statistics Dump +++”和“--- Statistics Dump ---”之间）。和前面介绍的统计信息文件一样，圆括号中的数字（979436130）是从UNIX纪元（1970年1月1日）开始算起，直到转储时的总秒数。不幸的是，BIND不会将其转换为实际的日期和时间，不过可以使用date命令将其转换成更具可读性的格式。例如，要转换979584113这个从UNIX纪元（1970年1月1日）开始算起的时间，可以使用：
现在一行一行地来解释这些统计信息。
success 651
这是名称服务器已经处理的成功查询（successful query）的数量。成功查询是指那些不会导致referral（转发）或error（错误）响应的查询。
referral 10
这是名称服务器已经处理的将导致referral响应的查询数量。
nxrrset 11
这是名称服务器已经处理的将导致如下响应的查询数量：查询者所查询的记录类型并不存在于其指定的域名中。
nxdomain 17
这是名称服务器已经处理的将导致如下响应的查询数量：查询者所指定的域名不存在。
recursion 296
这是名称服务器所接收到的，需要递归处理才能应答的查询数量。
failure 217
这是名称服务器所接收到的，导致出现nxrrset和nxdomain之外的错误应答的查询数量。
这些统计信息的数量显然比BIND 8名称服务器少得多，不过在BIND 9未来的版本中或许会记录更多的统计信息。
3．BIND统计信息的运用
名称服务器“健康”吗？怎样才是“健康”的运行状态呢？单凭一组统计信息，很难判断一个名称服务器是否健康。必须观察服务器在运行一段时间后所产生的统计信息，才能了解在当前配置下，什么样的统计值才是正常的。这些统计值由产生查询的应用程序、服务器的类别（primary、slave、caching-only）以及所服务的区域在命名空间中的层次共同决定，因此在各名称服务器之间会有显著不同，
在统计信息中还有一点需要注意：即名称服务器每秒钟接收到的查询数量。将接收到的查询总数，除以名称服务器已经运行的秒数，即可得到该数值。Paul的BIND 名称服务器在746 683秒钟内接收到1 992 938次查询，即大约每秒2.7次查询——不算是非常忙的服务器1。如果计算出来的数字实在太离谱，则应该检查到底是哪台主机在发送如此多的查询，以及确定这些查询是否真的必要。在某个时候，可能会决定需要更多名称服务器来分担这些负载。本书将在下一章说明这种情况。
