问题真的出在 DNS 上吗？
在开始讨论如何排除 DNS 问题之前，我们想知道您是否清楚怎样判断某个问题是由 DNS 而不是由别的命名服务造成的。在 Windows 主机上，判断问题的原因是否真的出在 DNS 上可是件困难的事。Windows 支持的命名服务真是名目繁多：如 DNS、WINS、HOSTS、LMHOSTS 等数不胜数。然而常用的 Windows 2000 nslookup 却全然不理会其他这些命名服务。您可能会只顾在 Windows 2000 计算机上运行 nslookup 和查询名称服务器，而有问题的服务却可能在使用另一种不同的命名服务，这样，您无异于竹篮打水。
怎样才能知道将矛头指向哪里呢？首先，您需要考虑是哪一类程序出了问题。如果是 TCP/IP 客户端，如 telnet 或 ftp，那么问题可能出在 DNS 和 HOSTS 文件上。如果是一个支持 NetBIOS 命名的实用程序，如 net（与在 net use 中一样）中，那么值得怀疑的还要包括 WINS 和 LMHOSTS 文件。其他也使用 DNS 名称或 NetBIOS 名称作为参数的客户端（如 ping）也会使用这些命名服务中的任意一种。
接下来，再考虑 Windows 使用这些命名服务的顺序。在查找问题时，应按照此顺序检查各种服务。
这些提示对您查出问题的症结会有帮助，至少可帮您排除一个怀疑对象。如果在缩小了怀疑范围后 DNS 仍脱不了干系，您才需要阅读本章内容。
检查缓存
如我们前面讲到的，您可以使用 DNS 控制台来检查名称服务器的缓存区中的内容。如果怀疑您的名称服务器缓存了来自另一服务器的错误的或过时的数据，则这一方法可派上用场。如要检查一个服务器的缓存区，请单击 DNS 控制台左窗格中该服务器名称左边的加号。您将看到一个名为 Cached Lookups 的文件夹。单击其左边的加号或双击文件夹图标或标签以展开下一级。这样可显示出您的名称服务器已为其缓存了数据的那些顶级域。继续展开，直至看到您要查看的缓存数据所在的那一域名。在图 13-1 中，我们已通过不断单击展开了要在其中查看缓存数据的 acmebw.com。
图 13-1 缓存中 acmebw.com 的 NS 和 A 记录
如在右边窗格中所见到的，我们的名称服务器已为 acmebw.com 缓存了三条 NS 记录和一条 A 记录。如果依次双击 net 和 acmebw，我们还会看到这些名称服务器的缓存地址。
如果想看缓存数据上的 TTL，请双击右窗格中的一条记录。若 DNS 控制台处于高级查看模式（选择查看 高级），则出现的窗口将显示出该记录的 TTL。例如，在图 13-2 中，我们双击了 acmebw.com A 记录。
图 13-2 缓存记录上的 TTL
在检查 TTL 之前，一定要用操作 刷新或用 F5 键刷新 DNS 控制台，否则您看到的 TTL 可能会大于当前 TTL。
如果右键单击该记录，您可能会注意到有一个删除记录选项。现在，有某种在 BIND 中无法执行的操作。您可以使用 DNS 控制台一个记录一个记录地删除缓存的数据。如果您知道名称服务器的缓存中某些记录已过时，可以将它们删除并让您的名称服务器从一个权威性名称服务器中获得更新后的记录。
潜在问题列表
让我们逐一讨论一些在生活中常见的 DNS 问题。这些问题中有许多问题都是容易识别和纠正的。我们当然要讲述这些问题 - 它们之所以是一些最常见的问题，是因为它们是由一些最常见的错误造成的。下面就是这些问题，不分先后顺序。
1. 忘记增加序列号
只有在您未使用 DNS 控制台而是用手动方式更改区域数据文件时，才会出现此问题。DNS 控制台在它每次更改区域数据时都会记着在 SOA 记录中增加序列号，所以您不必为此操心。不过，这也意味着您可能不会养成更新序列号的习惯，所以在进行一次性手动修改时，您可能会忘记增加序列号。
此问题的主要症状是，从属名称服务器不会获得您在主服务器上对该区域做的任何更改。从属服务器认为区域数据并未更改，因为它看到的序列号仍是原来的序列号。
该怎样检查当时是否记着增加序列号呢？不幸的是，这就不是那么容易了。如果您不记得原序列号是什么，而现在的序列号不能表明它是什么时候更新的，则没有直接的方法判断它是否已更改。 1
在启动主服务器时，不管您是否更改了序列号，它都将加载更新后的区域数据文件。最好的办法只能是使用 nslookup 来比较主服务器和从属服务器返回的数据。如果它们返回不同的数据，则表明您可能忘了增加序列号。如果您能想起最近作的一次更改，则可以查看此数据。如果记不起最近一次作的更改，则可以从一个主服务器和一个从属服务器复制该区域，将结果排序并使用文件比较工具将它们加以比较。
还有一个好消息，即，尽管确定该区域此前是否已复制比较难，但现在要确保该区域被复制却非常简单。只须在 DNS 控制台中双击 SOA 记录并手动编辑序列号字段，增加主服务器上此区域的副本中的序列号即可。从属服务器将在刷新时间间隔内获得此新的数据，如果它们用了 NOTIFY，则会更快。
2. 忘记重启主要主控服务器
与上一个问题一样，只有在手动更改区域数据文件时才会有此问题。DNS 控制台可以动态添加和删除数据，所以不需要重启主要主控名称服务器。
但是，如果未使用 DNS 控制台，您可能会在编辑区域数据文件后忘记重启主要主控名称服务器。该名称服务器不知道要加载新数据 - 它不会自动检查此文件以查看是否已更改。这样，您作的任何更改都不能在名称服务器的数据中反映出来：将不会加载新区域，新记录也不会反映到从属服务器。
如想查出上次是在什么时候重启名称服务器的，请查看“事件查看器”输出中最后一个条目，它类似于：
DNS 服务器已开始。
这些事件上的日期和时间将告诉您上次重启名称服务器是在什么时间。
如果该重启时间与您上次作更改的时间不相符，则请使用 DNS 控制台停止并重启该名称服务器，然后重新加载其数据。还要检查您更改的区域数据文件上的序列号是否也增加了。
3. DNS 服务器丢失以手动方式作的更改
最后关于手动更改还要再强调一点：要记住 Microsoft DNS 服务器会定期更新其区域数据文件。每次用 DNS 控制台对一个区域的数据进行更改时，就有一个写操作挂起：在 DNS 服务器退出之前，它必须重写该区域的数据文件，否则它就会丢失您所作的更改。可以将此比作内存中一个已更新的页：操作系统在退出之前必须将它写到磁盘上。
如果您在一个写操作挂起期间对一个区域数据文件作了手动更改，则在名称服务器退出后您会莫名其妙地丢失所作的更改。比如您在服务器正在运行且有一个写操作挂起时向一个名为 movie.edu 的新子域添加了委派。作完更改后，您必须将服务器停下并再次启动，以让它再次读取该区域数据。但是在服务器退出时，它将重写 movie.edu 区域数据文件，您的委派于是就会丢掉。如果仔细观察（平时就需要这样）事件查看器，会在服务器停止事件之前看到这样一条消息：
The DNS server wrote version 37 of zone movie.edu to file movie.edu.dns.
（DNS 服务器写入区域 movie.edu 的版本 37 到 文件 movie.edu.dns。)
如果您用操作 | 更新服务器数据文件来强制服务器重写其区域数据文件，则服务器就会与区域数据文件同步，而不必在退出时重写。所以，如果要对区域数据文件作手动更改，那么要么首先停止服务器（但这意味着在您作更改期间服务器将不响应任何查询），要么使用 DNS 控制台将服务器与区域数据文件同步，然后再进行更改。
4. 从属服务器无法加载区域数据
如果一个从属服务器无法从其主控服务器获取某个区域的当前序列号，那么最初它是不会给您发警告消息的。然而，如果该问题一直存在而且从属服务器在有效期时间内无法确定其数据是否是最新的，那么该区域就会过期。在一个 Microsoft DNS 服务器上，您将在事件查看器中看到与下文类似的一条消息：
在获得成功区域复制或从这个区域作为 其源的主服务器获得成功区域复制之前 movie.edu 区域就超时了。该区域已经被关闭。
区域过期后，当您向名称服务器查询该区域中的数据时，就会收到 SERVFAIL 错误消息：
C:\ nslookup robocop wormhole.movie.edu.
Server: wormhole.movie.edu
Addresses: 192.249.249.1, 192.253.253.1
*** wormhole.movie.edu can't find robocop.movie.edu: Server failed
出现此问题的原因主要有三个：由于网络故障与主控服务器的连接断开，为主控服务器配置的 IP 地址不正确，主控服务器上的区域数据文件中有语法错误。
首先，应使用 DNS 控制台检查该从属服务器在尝试从中加载数据的那一（些）主控服务器的地址。右键单击左窗格中该区域的域名，选择属性，然后查看常规选项卡，如图 13-3 所示。
图 13-3 显示出主控服务器的区域属性窗口
确认它是否真是主名称服务器的 IP 地址。如果是，请检查到此 IP 地址的连接：
C:\ ping 192.249.249.3
Pinging 192.249.249.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
如果无法连接到主控服务器，请确定该服务器的主机
