网管经验之Windows服务器DNS故障问题.doc

网管经验之Windows服务器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控制台左窗格中该服务器名称左边的加号。你将看到一个名为Cached Lookups的文件夹。单击其左边的加号或双击文件夹图标或标签以展开下一级。这样可显示出你的名称服务器已为其缓存了数据的那些顶级域。继续展开，直至看到你要查看的缓存数据所在的那一域名。如我们的名称服务器已为缓存了三条NS记录和一条A记录。如果依次双击net和hp,我们还会看到这些名称服务器的缓存地址。如果想看缓存数据上的 TTL，请双击右窗格中的一条记录。若 DNS 控制台处于高级查看模式（选择查看 高级），则出现的窗口将显示出该记录的 TTL。在检查 TTL 之前，一定要用操作 刷新或用 F5 键刷新 DNS 控制台，否则你看到的 TTL 可能会大于当前 TTL。如果右键单击该记录，你可能会注意到有一个删除记录选项。DNS的一些常见的错误1. 忘记增加序列号在你未使用 DNS 控制台而是用手动方式更改区域数据文件时，就会出现一些问题。DNS 控制台在它每次更改区域数据时都会记着在 SOA 记录中增加序列号，所以你不必为此操心。不过，这也意味着你可能不会养成更新序列号的习惯，所以在进行一次性手动修改时，你可能会忘记增加序列号。此问题的主要症状是，从属名称服务器不会获得你在主服务器上对该区域做的任何更改。从属服务器认为区域数据并未更改，因为它看到的序列号仍是原来的序列号。该怎样检查当时是否记着增加序列号呢？不幸的是，这就不是那么容易了。如果你不记得原序列号是什么，而现在的序列号不能表明它是什么时候更新的，则没有直接的方法判断它是否已更改。在启动主服务器时，不管你是否更改了序列号，它都将加载更新后的区域数据文件。最好的办法只能是使用 nslookup 来比较主服务器和从属服务器返回的数据。如果它们返回不同的数据，则表明你可能忘了增加序列号。如果你能想起最近作的一次更改，则可以查看此数据。如果记不起最近一次作的更改，则可以从一个主服务器和一个从属服务器复制该区域，将结果排序并使用文件比较工具将它们加以比较。还有一个好消息，即，尽管确定该区域此前是否已复制比较难，但现在要确保该区域被复制却非常简单。只须在 DNS 控制台中双击 SOA 记录并手动编辑序列号字段，增加主服务器上此区域的副本中的序列号即可。从属服务器将在刷新时间间隔内获得此新的数据，如果它们用了 NOTIFY，则会更快。2. 以手动方式更改DNS服务器要记住 Microsoft DNS 服务器会定期更新其区域数据文件。每次用 DNS 控制台对一个区域的数据进行更改时，就有一个写操作挂起：在 DNS 服务器退出之前，它必须重写该区域的数据文件，否则它就会丢失你所作的更改。可以将此比作内存中一个已更新的页：操作系统在退出之前必须将它写到磁盘上。如果你在一个写操作挂起期间对一个区域数据文件作了手动更改，则在名称服务器退出后你会莫名其妙地丢失所作的更改。比如你在服务器正在运行且有一个写操作挂起时向一个名为的新子域添加了委派。作完更改后，你必须将服务器停下并再次启动，以让它再次读取该区域数据。但是在服务器退出时，它将重写 区域数据文件，你的委派于是就会丢掉。如果仔细观察（平时就需要这样）事件查看器，会在服务器停止事件之前看到这样一条消息：The DNS server wrote version 37 of zone to file .dns.（DNS 服务器写入区域 的版本 37 到文件 .dns。）如果你用操作 | 更新服务器数据文件来强制服务器重写其区域数据文件，则服务器就会与区域数据文件同步，而不必在退出时重写。所以，如果要对区域数据文件作手动更改，那么要么首先停止服务器（但这意味着在你作更改期间服务器将不响应任何查询），要么使用 DNS 控制台将服务器与区域数据文件同步，然后再进行更改。3. 从属服务器无法加载区域数据如果一个从属服务器无法从其主控服务器获取某个区域的当前序列号，那么最初它是不会给你发警告消息的。然而，如果该问题一直存在而且从属服务器在有效期时间内无法确定其数据是否是最新的，那么该区域就会过期。在一个 Microsoft DNS 服务器上，你将在事件查看器中看到与下文类似的一条消息：在获得成功区域复制或从这个区域作为其源的主服务器获得成功区域复制之前 区域就超时了，该区域已经被关闭。区域过期后，当你向名称服务器查询该区域中的数据时，就会收到 SERVFAIL 错误消息：C: nslookup robocop .Server: Addresses: 19, cant find : Server failed出现此问题的原因主要有三个：由于网络故障与主控服务器的连接断开，为主控服务器配置的 IP 地址不正确，主控服务器上的区域数据文件中有语法错误。首先，应使用 DNS 控制台检查该从属服务器在尝试从中加载数据的那一（些）主控服务器的地址。右键单击左窗格中该区域的域名，选择属性，然后查看常规选项卡，确认它是否真是主名称服务器的 IP 地址。如果是，请检查到此 IP 地址的连接：C: ping 19Pinging 19 with 32 bytes of data:Request timed out.Request timed out.Request timed out.Request timed out.如果无法连接到主控服务器，请确定该服务器的主机是否真的在运行（例如，已通电），或检查网络问题。你可能还需要检查主控服务器对该区域中数据的查询是否返回权威性响应。如果主控服务器的响应对于该区域不是权威性的，则从属服务器就不从该主控服务器中复制此区域。可使用 nslookup 检查主控服务器的对于区域的 SOA 记录的权威性响应，命令格式如下：C: nslookup -norec -type=SOA . 19此命令向位于地址 的名称服务器发送一个非递归查询，以查询 的 SOA 记录。我们必须发送非递归查询，这样位于 的名称服务器就不会将该查询转发给另一个服务器。如果将此主控服务器配置正确，则对此查询的响应就应是权威性的。（记住，除非 nslookup 返回了“非权威性”响应，否则响应就是权威性的。）非权威性的响应可能表明主控服务器在加载该区域时发生问题，通常是由于区域数据文件中存在语法错误。请与该主控服务器的管理员联系，让他检查其事件查看器或系统日志的输出中是否有表明出现语法错误的消息。我们从来还没有见到过 Windows 2000 名称服务器因为区域数据文件中有语法错误而对于此区域失去非权威性的情况，但旧的 BIND 名称服务器确实会表现出这种现象。所以，如果你的名称服务器是某一区域的从属服务器，而此区域的主要主名称服务器是 BIND 名称服务器，该服务器现在对该区域不具有权威性，那么问题可能就是一个语法错误。如果对查询的响应是权威性的但从属服务器仍无法成功复制该区域，那么你可以使用nslookup的ls命令来手动复制该区域。如果看到类似于下面的错误消息，则很可能是主控服务器限制区域复制：C: nslookup - Default Server: Address: ls * Cant list domain : Query refused请与该主控服务器的管理员联系，问是否在对区域复制进行限制。请他检查你正在尝试复制的区域的属性窗口的区域复制选项卡上的选项（如果他在运行 Microsoft DNS 服务器）。如果该远程服务器在运行着 BIND，则请问他是否在使用 xfrnets 或 allow-transfer 功能来对区域复制进行限制。在问题已被排除而且你的服务器能成功复制该区域后，你会在事件查看器中看到下面的消息：A more recent version, version 212 of zone wasfound at DNS server at 19. Zone transfer is in progress.The DNS server wrote version 212 of zone tofile .dns.（在 19 的 DNS 服务器上找到区域 的更新的版本212。正在进行区域复制。DNS 服务器写入区域 的版本 212 到文件 .dns。）DNS故障还有几种情况，我们将在下期继续讨论。/experience/20040609/2888.asp4. 网络连接断开虽然与原始的 ARPANET时代相比，如今的 Internet 已可靠得多，但网络中断的现象仍很常见。这些故障往往看起来好像是性能问题：C: nslookup .Server: Address: DNS request timed out.* Request to timed-out使用 nslookup，你可以查找你的名称服务器要与之对话的那些名称服务器的名称和地址，以便解析该名称：C: nslookupDefault Server: Address: set type=ns .Server: Address: 19Non-authoritative answer:NS. internet address = 6NS.CSL. internet address = 4NS.CSL. internet address = 4TURTLE.MCC.COM internet address = 15NS1. internet address = 5 com.Server: Address: 19Non-authoritative answer:C.ROOT-SERVERS.NET internet address = 2D.ROOT-SERVERS.NET internet address = 0E.ROOT-SERVERS.NET internet address = 0I.ROOT-SERVERS.NET internet address = 7F.ROOT-SERVERS.NET internet address = 41G.ROOT-SERVERS.NET internet address = J.GTLD-SERVERS.INTERNIC.NET internet address = 1A.ROOT-SERVERS.NET internet address = H.ROOT-SERVERS.NET internet address = 3B.ROOT-SERVERS.NET internet address = 07然后你可以检查你的主机与这些服务器的连接。但是，ping也不会比你的名称服务器幸运多少。如果ping成功了，你就应该查一查这些远程服务器是否真的在运行。C: ping 6 -ping 第一个 名称服务器Pinging 6 with 32 bytes of data:Request timed out.C: ping 4 -ping 第二个 名称服务器Pinging 4 with 32 bytes of data:Request timed out.现在剩下要做的只是查找网络中的故障。像tracert这样的实用工具可帮你确定问题是出在你的网络上、在目标网络上、还是在中间某个地方，在查找故障位置时也需要运用一些常识了。5.缺少子域委派尽管取得ICANN认证的注册员尽了最大努力以尽可能快地处理你的请求，但让你的子域的委派出现在根名称服务器中也可能需要一两周的时间。你的父级不同（是取得ICANN 认证的注册员还是其他区域管理员），你的等待时间也会不一样。有的父级办事速度快且有责任心；而有的父级则办事拖拉。等到你的委派数据出现在父级区域的名称服务器上后，你的名称服务器就能够在 Internet 域名称空间查找数据了，但Internet 上（在你的域之外）没有任何人会知道怎样在你的 名称空间查找数据。这意味着，尽管你可以将邮件发送到你的域之外，但收件人却不能回复你的邮件。而且，也没有人能够按名称 telnet 到、ftp 到，甚至不能 ping 到你的主机。要知道，你运行的任何 子域都是这种情况。在父级将这些子域委派到你的服务器之前，Internet 上的名称服务器不能够逆映射你网络上的地址。如要确定你区域的委派是否已在你的父级区域的名称服务器中，请向一个父级名称服务器查询你的区域的 NS 记录。如果父级名称服务器中有此数据，则 Internet 上的任何名称服务器都能找到它：C: nslookupDefault Server: Address: server .-Query a root name serverDefault Server: Address: set norecurse -Instruct the server to answer out of set type=ns -its own data and to look for NS records 249.249.192.. -for 249.249.192.Server: Address: * cant find 249.249.192..: Non-existent domain从这里可以清楚地看出尚未添加委派。你可以耐心地等待，如果在向父级区域请求委派后等待的时间太长，你可以与父级区域的管理员联系，问他们是怎么回事。6子域委派不正确子域委派不正确是 Internet 上另一个常见的问题。让委派保持最新需要人的参与 - 将你对你的一组权威性名称服务器作的更改通知父级区域的管理员。因此，委派信息往往会由于管理员作更改时不将此情况通知他们的父级管理员而变得不准确。有相当多的管理员都认为，建立委派是一劳永逸的事：在建立他们的区域时，他们让父级管理员知道哪些名称服务器是权威性的，然后就再也不与父级管理员沟通此事了。他们甚至在母亲节也不知道打个电话。一名管理员可能会添加一个新的名称服务器，撤下另一个，又改变了某一个名称服务器的 IP 地址，而这一切都可能不让父级区域的管理员知道。久而久之，由父级区域正确委派的名称服务器的数目就会变少。在这种情况下，最好的结局是名称解析时间延长，因为进行查询的名称服务器要费尽周折去查找该区域的权威性名称服务器。如果委派信息严重过时而最后一个权威性名称服务器主机被停机维修，那么就无法访问到该区域中的信息。如果你怀疑有委派错误，不管是从你的父级到你的区域，从你的区域到你的一个子级，还是从一个远程区域到该区域的一个子级，你都可以用 nslookup 来检查：C: nslookupDefault Server: Address: server . -Set server to the parent name-server you suspect has bad delegationDefault Server: Address: set type=ns -Look for NS records . -for the zone in questionServer: a.gtld-server