问题真的出在 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.
如果无法连接到主控服务器，请确定该服务器的主机是否真的在运行（例如，已通电），或检查网络问题。
您可能还需要检查主控服务器对于对该区域中数据的查询是否返回权威性响应。如果主控服务器的响应对于该区域不是权威性的，则从属服务器就不从该主控服务器中复制此区域。可使用 nslookup 检查主控服务器的对于区域的 SOA 记录的权威性响应，命令格式如下：
C:/> nslookup -norec -type=SOA movie.edu. 192.249.249.3
此命令向位于地址 192.249.249.3 的名称服务器发送一个非递归查询，以查询 movie.edu 的 SOA 记录。我们必须发送非递归查询，这样位于 192.249.249.3 的名称服务器就不会将该查询转发给另一个服务器。
如果将此主控服务器配置正确，则对此查询的响应就应是权威性的。（记住，除非 nslookup 返回了“非权威性”响应，否则响应就是权威性的。）非权威性的响应可能表明主控服务器在加载该区域时发生问题，通常是由于区域数据文件中存在语法错误。请与该主控服务器的管理员联系，让他检查其事件查看器或系统日志的输出中是否有表明出现语法错误的消息。我们从来还没有见到过 Windows 2000 名称服务器因为区域数据文件中有语法错误而对于此区域失去非权威性的情况，但旧的 BIND 名称服务器确实会表现出这种现象。所以，如果您的名称服务器是某一区域的从属服务器，而此区域的主要主名称服务器是 BIND 名称服务器，该服务器现在它对该区域不具有权威性，那么问题可能就是一个语法错误。
如果对查询的响应是权威性的但从属服务器仍无法成功复制该区域，那么您可以使用 nslookup 的 ls 命令来手动复制该区域（如在第 12 章所述，ls 可执行区域复制）。如果看到类似于下面的错误消息，则很可能是主控服务器限制区域复制：
C:/> nslookup - 192.249.249.3
Default Server: terminator.movie.edu
Address: 192.249.249.3
> ls movie.edu
[terminator.movie.edu]
*** Can't list domain movie.edu: Query refused
>
请与该主控服务器的管理员联系，问她是否在对区域复制进行限制。请她检查您正在尝试复制的区域的属性窗口的区域复制选项卡上的选项（如果她在运行 Microsoft DNS 服务器）。如果该远程服务器在运行着 BIND，则请问她是否在使用 xfrnets 或 allow-transfer 功能来对区域复制进行限制。
在问题已被排除而且您的服务器能成功复制该区域后，您会在事件查看器中看到下面的消息：
A more recent version, version 212 of zone movie.edu was
found at DNS server at 192.249.249.3. Zone transfer is in progress.
The DNS server wrote version 212 of zone movie.edu to
file movie.edu.dns.
（在 192.249.249.3 的 DNS 服务器上找到
区域 movie.edu 的更新的版本 212。正在进行区域复制。
DNS 服务器写入区域 movie.edu 的版本 212 到
文件 movie.edu.dns。）
5. 向区域中添加了地址，但忘了添加相应的 PTR 记录
因为在 DNS 中从主机名到 IP 地址的映射与从 IP 地址到主机名的映射是脱节的，所以很容易忘记为新的主机添加 PTR 记录。添加 A 记录是比较直观的，但许多已习惯了主机表的人误以为添加一个地址记录时也会自动进行逆映射。但事实却不是这样 - 您需要向相应的 in-addr.arpa 区域为该主机添加一条 PTR 记录。所幸的是，DNS 使这一点很容易做到，因为在您选择新建主机...时它提供了一个创建相关的指针 (PTR) 记录复选框。
忘了给主机添加 PTR 记录通常会导致此主机不能通过身份验证检查。例如，该主机上的用户将不能 rsh 或 rcp 到其他主机。与这些程序通信的那些服务器需要能够将该连接的 IP 地址映射为一个域名以检查授权文件。
另外，许多大的 FTP 档案，包括 ftp.uu.net，拒绝那些 IP 地址不能逆映射为域名的主机对其进行匿名 ftp 访问。ftp.uu.net 的 FTP 服务器将发出一条消息，下面是其部分内容：
530- Sorry, we're unable to map your IP address 140.186.66.1
530- to a hostname in the DNS.This is probably because your
530- nameserver does not have a PTR record for your address in its
530- tables, or because your reverse nameservers are not registered.
530- We refuse service to hosts whose names we cannot resolve.
531-
这就把您不能使用匿名 ftp 的原因说得相当明白了。而其他 FTP 站点可能只是直接拒绝服务，而不显示这些信息性消息。
可用 nslookup 来检查您是否忘了添加 PTR 记录：
C:/> nslookup
Default Server: terminator.movie.edu
Address: 192.249.249.3
> beetlejuice --Check for a hostname-to-address mapping
Server: terminator.movie.edu
Address: 192.249.249.3
Name: beetlejuice.movie.edu
Address: 192.249.249.23
> 192.249.249.23 --Now check for a corresponding
address-to-hostname mapping
Server: terminator.movie.edu
Address: 192.249.249.3
*** terminator.movie.edu can't find 192.249.249.23: Non-existent domain
在 249.249.192.in-addr.arpa 的主要主控服务器上，快速检查一下 DNS 控制台或 249.249.192.in-addr.arpa.dns 文件就会看出是否已将 PTR 记录添加到该区域中。
6. 记录的 RDATA 字段中域名错误
在使用 DNS 控制台添加 CNAME、MX 和 NS 记录时，须记住，对于资源记录特定的数据，要指定主机的完全合格的域名称。DNS 控制台假定您在 RDATA 字段中键入的名称是完全合格的。所以，如果想创建一个如图 13-4 中所示的 CNAME 记录，则 CNAME 记录在区域数据文件中应类似于下面的形式：
bigt IN NS terminator.
这可能不是您所希望的，因为没有顶级 terminator 域。您可能会认为，如果在句点处停下了，DNS 控制台将把区域的名称附加到该名称后。实际不是这样的。
图 13-4 创建一个 CNAME 记录（错误的方式）
只须检查区域数据文件（在操作 | 更新服务器数据文件之后）或使用 nslookup，就能很容易发现这些错误：
C:/> nslookup -type=ns movie.edu.
Server: terminator.movie.edu
Address: 192.249.249.3
movie.edu nameserver = wormhole.movie.edu
movie.edu nameserver = terminator
wormhole.movie.edu internet 地址 = 192.253.253.1
wormhole.movie.edu internet address = 192.249.249.1
7. 网络连接断开
虽然与原始的 ARPANET 时代相比如今的 Internet 已可靠得多，但网络中断的现象仍很常见。这些故障往往看起来好像是性能问题：
C:/> nslookup nisc.sri.com.
Server: terminator.movie.edu
Address: 192.249.249.3
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 4 seconds.
DNS request timed out.
timeout was 8 seconds.
*** Request to terminator.movie.edu timed-out
使用 nslookup，您可以查找您的名称服务器要与之对话的那些名称服务器的名称和地址，以便解析该名称：
C:/> nslookup
Default Server: terminator.movie.edu
Address: 192.249.249.3
> set type=ns
> sri.com.
Server: terminator.movie.edu
Address: 192.249.249.3
Non-authoritative answer:
sri.com nameserver = NS.sri.com
sri.com nameserver = NS.CSL.sri.com
sri.com nameserver = TURTLE.MCC.COM
sri.com nameserver = NS1.sri.com
NS.sri.com internet address = 128.18.30.66
NS.CSL.sri.com internet address = 130.107.4.94
NS.CSL.sri.com internet address = 192.12.33.94
TURTLE.MCC.COM internet address = 128.62.1.215
NS1.sri.com internet address = 128.18.30.65
> com.
Server: terminator.movie.edu
Address: 192.249.249.3
Non-authoritative answer:
com nameserver = C.ROOT-SERVERS.NET
com nameserver = D.ROOT-SERVERS.NET
com nameserver = E.ROOT-SERVERS.NET
com nameserver = I.ROOT-SERVERS.NET
com nameserver = F.ROOT-SERVERS.NET
com nameserver = G.ROOT-SERVERS.NET
com nameserver = J.GTLD-SERVERS.INTERNIC.NET
com nameserver = A.ROOT-SERVERS.NET
com nameserver = H.ROOT-SERVERS.NET
com nameserver = B.ROOT-SERVERS.NET
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
I.ROOT-SERVERS.NET internet address = 192.36.
148.17
F.ROOT-SERVERS.NET internet address = 192.5.
5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
J.GTLD-SERVERS.INTERNIC.NET internet address = 198.41.
0.21
A.ROOT-SERVERS.NET internet address = 198.41.0.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
B.ROOT-SERVERS.NET internet address = 128.9.0.107
然后您可以检查您的主机与这些服务器的连接。但是，ping 也不会比您的名称服务器幸运多少。如果 ping 成功了，您就应该查一查这些远程服务器是否真的在运行。
C:/> ping 128.18.30.66 --ping first sri.com name server
Pinging 128.18.30.66 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
C:/> ping 130.107.4.94 --ping 第二个 sri.com 名称服务器
Pinging 130.107.4.94 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
现在剩下要做的只是查找网络中的故障。像 tracert 这样的实用工具可帮您确定问题是出在您的网络上、在目标网络上、还是在中间某个地方。
在查找故障位置时也需要运用一些常识。例如，如果 ping 测试表明您不能连接到 Internet 的任何根名称服务器，那么，每一个根名称服务器的本地网络都中断或 Internet 的商业主干网崩溃是不大可能的。按照“奥卡姆剃刀”原则，可能造成此现象 - 您的 网络到 Internet 的连接丢失 - 的最简单情形最有可能是发生此现象的原因。
8. 缺少子域委派
尽管取得 ICANN 认证的注册员尽了最大努力以尽可能快地处理您的请求，但让您的子域的委派出现在根名称服务器中也可能需要一两周的时间。您的父级不同（是取得 ICANN 认证的注册员还是其他区域管理员），您的等待时间也会不一样。有的父级办事速度快且有责任心；而有的父级则办事拖拉。与在现实生活中一样，您对他们需要有耐心。
等到您的委派数据出现在父级区域的名称服务器上后，您的名称服务器就能够在 Internet 域名称空间查找数据了，但 Internet 上（在您的域之外）没有任何人会知道怎样在您的 名称空间查找数据。
这意味着，尽管您可以将邮件发送到您的域之外，但收件人却不能回复您的邮件。而且，也没有人能够按名称 telnet 到、ftp 到，甚至不能 ping 到您的主机。
要知道，您运行的任何 in-addr.arpa 子域都是这种情况。在父级将这些子域委派到您的服务器之前，Internet 上的名称服务器不能够逆映射您网络上的地址。
如要确定您区域的委派是否已在您的父级区域的名称服务器中，请向一个父级名称服务器查询您的区域的 NS 记录。如果父级名称服务器中有此数据，则 Internet 上的任何名称服务器都能找到它：
C:/> nslookup
Default Server: terminator.movie.edu
Address: 192.249.249.3
> server a.root-servers.net.--Query a root name server
Default Server: a.root-servers.net
Address: 198.41.0.4
> set norecurse --Instruct the server to answer out of
> set type=ns --its own data and to look for NS records
> 249.249.192.in-addr.arpa. --for 249.249.192.in-addr.arpa
Server: a.root-servers.net
Address: 198.41.0.4
*** a.root-servers.net can't find 249.249.192.in-addr.arpa.
: Non-existent domain
从这里可以清楚地看出尚未添加委派。您可以耐心地等待，如果在向父级区域请求委派后等待的时间太长，您可以与父级区域的管理员联系，问他们是怎么回事。
9. 子域委派不正确
子域委派不正确是 Internet 上另一个常见的问题。让委派保持最新需要人的参与 - 将 您对您的一组权威性名称服务器作的更改通知父级区域的管理员。因此，委派信息往往会由于管理员作更改时不将此情况通知他们的父级管理员而变得不准确。有相 当多的管理员都认为，建立委派是一劳永逸的事：在建立他们的区域时，他们让父级管理员知道哪些名称服务器是权威性的，然后就再也不与父级管理员沟通此事 了。他们甚至在母亲节也不知道打个电话。
一名管理员可能会添加一个新的名称服务器，撤下另一个，又改变了某一个名称服务器的 IP 地 址，而这一切都可能不让父级区域的管理员知道。久而久之，由父级区域正确委派的名称服务器的数目就会变少。在这种情况下，最好的结局是名称解析时间延长， 因为进行查询的名称服务器要费尽周折去查找该区域的权威性名称服务器。如果委派信息严重过时而最后一个权威性名称服务器主机被停机维修，那么就无法访问到 该区域中的信息。
如果您怀疑有委派错误，不管是从您的父级到您的区域，从您的区域到您的一个子级，还是从一个远程区域到该区域的一个子级，您都可以用 nslookup 来检查：
C:/> nslookup
Default Server: terminator.movie.edu
Address: 192.249.249.3
> server a.gtld-servers.net. --Set server to the parent name
--server you suspect has bad delegation
Default Server: a.gtld-servers.net
Address: 198.41.0.4
> set type=ns --Look for NS records
> hp.com. --for the zone in question
Server: a.gtld-servers.net
Address: 198.41.0.4
Non-authoritative answer:
hp.com nameserver = RELAY.HP.COM
hp.com nameserver = HPLABS.HPL.HP.COM
hp.com nameserver = NNSC.NSF.NET
hp.com nameserver = HPSDLO.SDD.HP.COM
Authoritative answers can be found from:
hp.com nameserver = RELAY.HP.COM
hp.com nameserver = HPLABS.HPL.HP.COM
hp.com nameserver = NNSC.NSF.NET
hp.com nameserver = HPSDLO.SDD.HP.COM
RELAY.HP.COM internet address = 15.255.152.2
HPLABS.HPL.HP.COM internet address = 15.255.176.47
NNSC.NSF.NET internet address = 128.89.1.178
HPSDLO.SDD.HP.COM internet address = 15.255.160.64
HPSDLO.SDD.HP.COM internet address = 15.26.112.11
假如您怀疑到 hpsdlo.sdd.hp.com 的委派不正确，您可以在 hpsdlo 区域查询 hp.com 中的数据，并检查返回的结果：
> server hpsdlo.sdd.hp.com.
Default Server: hpsdlo.sdd.hp.com
Addresses: 15.255.160.64, 15.26.112.11
> set norecurse
> set type=soa
> hp.com.
Server: hpsdlo.sdd.hp.com
Addresses: 15.255.160.64, 15.26.112.11
Non-authoritative answer:
hp.com
origin = relay.hp.com
mail addr = hostmaster.hp.com
serial = 1001462
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
Authoritative answers can be found from:
hp.com nameserver = RELAY.HP.COM
hp.com nameserver = HPLABS.HPL.HP.COM
hp.com nameserver = NNSC.NSF.NET
RELAY.HP.COM internet address = 15.255.152.2
HPLABS.HPL.HP.COM internet address = 15.255.176.47
NNSC.NSF.NET internet address = 128.89.1.178
如果 hpsdlo 确实是权威性的，它就会返回一个权威性的响应。hp.com 区域的管理员能告诉您 hpsdlo 是否应是 hp.com 的一个权威性名称服务器，所以您应与该管理员联系。
互操作性问题
Microsoft DNS 服务器与 BIND 名称服务器之间至少有一个已知的互操作性问题：区域复制有时会因为专用的 WINS 记录而失败。
当一个 Microsoft DNS 服务器被配置为向 WINS 服务器查询它在某一给定区域中查不到的名称时，它就会向区域数据文件中插入一条特殊的记录。该记录类似于：
@ IN WINS <WINS 服务器的 IP 地址>
然而不幸的是，WINS 不是 IN 类中的标准记录类型。因此，任何复制此区域的 BIND 从属名称服务器都会再这条 WINS 记录上发生阻塞而拒绝加载该区域。BIND 服务器的管理员在其系统日志输出中将看到下面这一消息：
May 23 15:58:43 terminator named-xfer[386]:
"fx.movie.edu IN 65281" - unknown type (65281)
避免出现此问题的办法是，将 Microsoft DNS 服务器配置为在复制区域之前滤出该专用记录。具体做法是，在 DNS 控制台的左窗格中选择该区域，右键单击它，选择选择属性。在显示出的属性窗口中单击 WINS 选项卡，如图 13-5 所示。
图 13-5 “不复制此记录”复选框
选中不复制此记录就会将 WINS 记录从这一区域中滤出。不过，任何 Microsoft DNS 服务器从属服务器都不会看到此记录，尽管它们可以使用它。
问题症状
不幸的是，有些问题并不像我们在这里列出的这些那样容易找出。您很可能会遇到一些假象，无法直接判断其原因，这往往是因为许多问题都有可能造成您所看到的症状。对于这种情况，我们将提供这些症状的一些常见原因以及查找它们的办法。
无法查找本地名称
当像 telnet 或 ftp 这样的程序不能查找某个本地名称时，所要做的第一件事是使用 nslookup 尝试查找此同一名称。这里所说的“同一名称”是指字面上 完全相同的同一名称，如果用户原来未带域名或圆点，则也不要添加。查询的名称服务器要与用户查询的相同。
用户往往会在键入时拼错名称或对搜索列表的工作方式理解不正确，需要您的指导。有时，您会真的遇到主机配置错误，如解析器配置中的错误（如名称服务器的 IP 地址错误）。您可以使用 nslookup 的 set all 命令来查找这类错误。
如果 nslookup 指出是名称服务器的问题，而不是主机配置有问题，则请检查与名称服务器的类型关联的问题。如果该名称服务器是区域的主要主控名称服务器，但它响应的数据不是您认为它应该响应的那种，那么您应该：
· 检查该区域或区域数据文件中是否包含这一有问题的数据。
· 确保记录中的域名是正确的（问题 6）。
如果名称服务器是一个从属服务器，则应首先检查其主控服务器中的数据是否正确。如果主控服务器有，但从属服务器却没有，则请：
· 确认您是否增加了主服务器上的序列号（问题 1）。
· 查找从属服务器上更新区域时的问题（问题 4）。
如果主服务器没有正确的数据，则请诊断主服务器上的问题。
如果有问题的服务器不是包含此数据的区域的权威服务器，则请检查您的父级区域对您的区域的委派是否存在并且正确（问题 8 和 9）。记住，在此名称服务器看来，您的区域与其他任何远程区域都一样。尽管它所在的主机可能在您的区域中，该名称服务器也必须通过您的父级区域的服务器才能找到您区域的一个权威性服务器。
无法查找远程名称
如果本地查找成功但无法查找位于您本地区域之外的名称，则需要检查另外一组问题：
· 您能 ping 该远程区域的名称服务器吗？您可能因为网络连接的丢失（问题 7）而无法连接该远程区域的服务器。
· 该远程区域是新的吗？也许它的委派尚未显示出来（问题 8）。也有可能该远程区域的委派信息是错误的，或者由于疏忽而过时（问题 9）。
· 此域名在该远程区域的服务器上确实存在吗？它在所有这些服务器上都存在吗（问题 1、2 和 4）？
响应错误或不一致
如果在查找一个本地名称时得到的响应是错误的，或者得到的响应不一致，那么，根据您查询的是哪一个名称服务器或您是在什么时间查询的，首先检查您的名称服务器之间是否同步：
· 它们中的区域的序列号是否相同？在进行手动更改后是否忘了增加主服务器上的序列号（问题 1）？如果忘了，那么这些名称服务器可能会有同样的序列号，但它们会作出与权威性的数据不同的应答。
· 在作了手动更改后是否忘了重启主服务器（问题 2）？如果忘了，那么主服务器将返回（例如通过 nslookup）一个与区域数据文件中的序列号不同的序列号。
· 从属服务器在从主服务器进行更新时有问题吗（问题 4）？
· 名称服务器的循环功能在循环您正在查找的域名的地址吗？
如果在一个远程区域中查找名称时得到这些结果，那么就应检查该远程区域的名称服务器是否已丧失同步。例如，您可以使用像 nslookup 这 样的工具来确定该远程区域的管理员是否忘了增加序列号。如果一些名称服务器作出与它们的权威数据不同的应答，但都显示同一序列号，那么可能就是该序列号未 增加。如果主服务器的序列号比从属服务器的序列号低得多，则表明主服务器的序列号可能无意间被重置了。我们通常都假定一个区域的主名称服务器作为 SOA 记录中起始点列出的那一主机上运行。
但是，您恐怕无法断定主名称服务器是否未重启过。要确定远程名称服务器之间的更新问题也很困难。在这种情况下，如果您能确定远程名称服务器所发出的数据不正确，请与区域管理员联系并（委婉地）将您发现的情况告诉她。这将有助于让该管理员查出远程端的问题。
查找需要很长时间
名称解析时间长的原因通常是由以下两个问题之一造成的：
· 连接丢失（问题 7），此问题可用像 ping 和 tracert 这样的工具来诊断
· 委派信息不正确（问题 9），此问题由错误的名称服务器或错误的 IP 地址造成。
通常，发送几个 ping 将会指向这些问题原因中的一个或多个。要么您根本无法到达这些名称服务器，或者是您可以到达主机但名称服务器不响应。
不过，有时这些结果不是最终结果。例如，父级名称服务器可能会委派到一组名称服务器，它们对 ping 或查询没有响应，但到远程网络的连接看起来好像没问题（比如 tracert 可以到达远程网络的“门前台阶”- 您到主机之间的最后一个路由器）。委派信息真的如此过时吗（名称服务器早已移到其他地址）？是不是干脆主机停机了？抑或远程网络真的有问题？通常，要想查出真正原因，需要给该远程区域的管理员打个电话或发一个邮件。（别忘了，whois 可以给您提供电话号码哟！）
以上大概就是我们所想讲述的全部内容。当然，本文绝对算不上一个包罗万象的问题列表，但我们希望它能帮您解决您遇到的较常见的 DNS 问题，并帮您想出解决其余问题的主意。诸位，要是我们 开始时就有一本故障排除指南该多好啊！
以上一章内容承蒙 O'Reilly & Associates 公司提供。
我们代表 Microsoft Corporation 衷心希望本文中的信息能对您有所帮助。但是应由您自己承担使用本文中信息而带来的风险。本文中的所有信息都“按原样”提供，对于其准确性、完整性、特殊用途的适用性、所有权和不侵权原则，并没有任何明示或暗示的保证；本文提及的任何第三方产品和信息，Microsoft Corporation 都并未参与创作，也不向您推荐、支持或作出任何保证。对使用该信息而造成的任何损失，不管是直接的、间接的、特别的，还是偶然的或必然的，即使已经警告过可能会有这种损失，Microsoft Corporation 将不承担任何责任。本文档中提到的产品的所有价格可能会随时更改，恕不另行通知。
1 另一方面，如果您像许多人那样，将日期编到序列号中（例如，1998010500 表示 1998 年 1 月 5 日的第一次数据修订），那么您一眼就能看出在进行更改时是否更新了序列号。然而，DNS 控制台使这一想法几乎不可能实现，因为每次更改它都只将序号增加 1。
2101
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
