网络工程师手记－
无法解析出正确的MX记录
工程师简介：陈孝俊，现任职于微软全球技术支持中心。主要负责为微软的客户和合作伙伴提供Exchange、Windows和Networking方面的售后技术支持。您可以通过 [email]dell3@sohu.com[/email]与他联系
     预备知识：
     众所周知，DNS是域名系统（Domain Name System）的缩写，该系统用于命名组织到域层次结构中的计算机和网络服务。DNS命名用于Internet等TCP/IP网络中，通过用户友好的名称查找计算机和服务。当用户在应用程序中输入DNS名称时，DNS服务可以将此名称解析为与之相关的其它信息，如IP地址。在Windows网络之中，有一些常用的工具来测试DNS解析，其中我们最常用的就是NSLOOKUP命令，该命令可以用于正向和反向的DNS解析。
     以下文章中讲到了DSLOOKUP命令的一个用途，同样也和我下面讲述的问题有一些联系：
How to obtain Internet Mail Exchanger records with the Nslookup.exe Utility
[url]http://support.microsoft.com/kb/203204[/url]
     问题1：
     客户使用的是一台Windows 2000 Server的系统，已经安装了SP4以及一些关键的安全补丁。这台服务器工作在Workgroup模式下，上面安装了Windows的DNS服务，并且配置了多个DNS的区域。其中有一个区域，名称为test.cn，添加了一条MX记录供邮件服务器使用。
     现在遇到的问题是这个客户使用NSLOOKUP命令测试名称解释的时候经常出现超时的错误，测试的结果如下：
 
C:\Documents and Settings\Administrator>nslookup
DNS request timed out.
    timeout was 2 seconds.
*** Can't find server name for address 192.168.1.1: Timed out
*** Default servers are not available
Default Server:  UnKnown
Address:  192.168.1.1

     排错1：
     虽然现在的局域网内反向（PTR）记录没有什么实用价值，但是如果DNS服务器上没有配置服务器本身的PTR记录，那么会造成解析NSLOOKUP解析超时，因为NSLOOKUP命令总是会尝试解析服务器的名称。由于这个原因，我首先要求客户建立这台DNS服务器的反向记录。
     问题2：
     建立PTR记录之后又发现新的问题。当尝试在服务器本机解析test.cn中的MX记录时，发现会出现解析错误，但并不是一直出现，只是随机出现。具体的问题如下：
 
> set type=mx
> test.cn
Server:  ns.test.cn
Address:  192.168.1.1
 
test.cn MX preference = 10, mail exchanger = mail.test.cn
mail.test.cn    internet address = 192.168.1.244
> test.cn
Server:  ns.test.cn
Address:  192.168.1.1
 
Non-authoritative answer:
test.cn.com     MX preference = 0, mail exchanger = null.centralnic.net
但是，如果在客户机上使用NSLOOKUP命令测试时，却发现没有问题。

 
     排错2：
     我看到这个问题就觉得比较奇怪，因为DNS服务器接收到客户请求时会首先尝试在本地的缓存和本地的区域中进行解析，如果失败，那么就会将这个请求交给用户在转发器中设置的DNS服务器上。如果没有设置转发器，那么就将DNS查询请求交给“根目录提示”中的Internet DNS根服务器，最终得到一个答案回送给客户。如果服务器是从其它名称服务器上获得答案的，那么就会以“Non-authoritative answer”显示。但是这个客户告诉我test.cn的区域本就是在这台服务器上的，MX记录也在这个区域中。由于此时我没有什么想法，所以我要求客户协助我收集一些必要的信息：
     收集服务器上的MPS报告。MPS报告是十分有用的信息，不同类型的MPS会包含不同的信息。这个工具的下载地址是： [url]http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en[/url]
     建议客户清空DNS缓存且检查转发器的设置之后再测试一下。
     为了查看DNS具体的工作过程，我决定开启DNS Debug Logging（在DNS管理工具中右击服务器，日志标签下的那些设置）。
     Debug Logging会增加服务器的负荷，所以不建议在系统没有问题的时候启用该日志。
     问题3：
     客户将服务器上MPS报告以及DNS Debug Log给了我，并且告诉我清空DNS缓存以及转发器后问题依旧。
     排错3：
     之所以要求客户清除转发器的设置，是为了排除转发服务器配置错误的可能。没有配置转发器的服务器上，如果DNS查询本地解析不了，DNS查询将转发到Internet根服务器上，我们可以相信这些根服务器是不会有问题的。
     即便这样配置了，问题依旧发生。此时我不得不查看了客户给的DNS Debug Log，在其中发现如下的记录（由于记录很多，所以只能截取其中关键的几行）：
 
Rcv   192.168.1.1     0003    Q [0001   D   NOERROR] （4）test（2）cn（0）
UDP question info at 00DF449C
  ……
 
Snd   210.21.4.130    305a    Q [0001   D   NOERROR] （3）192（3）168（1）1（3）244（0）
UDP question info at 005419AC

     以上是一个收（Rcv）和一个发（Snd）的数据记录，从中我发现了一个问题。标准的MX记录应该指向一条A记录，当要求解析邮件服务器地址的时候，服务器首先给出一个FQDN（全称域名），然后根据这个FQDN查询相应的A记录，从而最终获得IP地址。但是从日志中可以发现服务器在接到客户请求后向外部服务器（210.21.4.130）发送了一个查询请求，这个请求就是解析192.168.1.244的IP地址。很明显，客户那里的MX记录指向了一个IP地址，服务器尝试将这个地址作为域名进行解析，这样可能会造成问题。于是，我建议用户修改MX记录，将其指向一个A记录。
     问题4：
     客户修改了记录之后重新使用NSLOOKUP命令进行解析测试，但是问题依旧发生。同时客户重新提供了一份新的DNS Debug Log供我进行分析。
 
     排错4：
     到了这个时候，我还是不清楚导致这个问题的根本原因。我怀疑过由于服务的负荷太大导致解析不正常，但是没有道理问题只发生在服务器上，而客户端完全正常，据此可以判断问题应该和服务器本机有所关联。于是我再一次查看了服务器上的一些日志，希望有所发现。
     根据NSLOOKUP命令解析出的结果在DNS Debug Log中搜索了一下，发现了一个奇怪的问题，就是在错误的结果之前均能够找到一个特殊的查询请求：（4）test（2）cn（3）com（0）。但是客户从来没有尝试过解析test.cn.com，为什么会有这样的解析请求呢？详细情况请看以下记录：
 
Rcv   192.168.1.1     0002    Q [0001   D   NOERROR] （4）test（2）cn（3）com（0）
UDP question info at 0053CEDC
  ……
 
Snd   202.96.69.38    08b2    Q [0001   D   NOERROR] （4）test（2）cn（3）com（0）
UDP question info at 0054BE8C
    ……
 
Rcv   202.96.69.38    08b2  R Q [8081   DR  NOERROR] （4）test（2）cn（3）com（0）
UDP response info at 00DFEDBC
      DATA   0 （4）null（10）centralnic（3）net（0）
    …….
 
Snd   192.168.1.1     0002  R Q [8081   DR  NOERROR] （4）test（2）cn（3）com（0）
UDP response info at 00DFEDBC
      DATA   0 （4）null（10）centralnic（3）net（0）
    ……
      从上面的记录中可以看出，null.centralnic.net并不是对应于test.cn域的邮件服务器，而是解析test.cn.com时回应的数据。接着我在查看MPS报告时发现如下的信息：
 
 Host Name . . . . . . . . . . . . : test
        Primary DNS Suffix  . . . . . . . : com
        Node Type . . . . . . . . . . . . : Broadcast
        WINS Proxy Enabled. . . . . . . . : No

      其中Primary DNS Suffix  . . . . . . . : com这个配置引起了我的注意，因为在工作组环境中的计算机Primary DNS Suffix应该是空的，不会有任何值。很明显这个com后缀是人为加上去的。由于问题出在了服务器接到的请求由正确的test.cn变成了错误的test.cn.com，那么会不会与这个DNS后缀有什么联系呢？
      为了证明我的猜测，我建立了一个测试环境，希望能够有些收获。我安装了一台Windows 2000的DNS服务器以及一台Windows 2000的客户机。由于在一台计算机上进行抓包不是很方便，所以我独立安装了一台Windows 2000的客户机，在客户机上使用NSLOOKUP命令进行测试，并且将客户机的Primary DNS Suffix也设置成com，这样我就可以在服务器上使用网络监视器进行抓包分析。进行抓包之后，我终于有了发现，请看具体的截屏：

 
      从这个抓包的结果中我们可以发现NSLOOKUP的工作方式：
      当我们输入一个要解析的域名或主机之后，NSLOOKUP会首先将主DNS后缀加在用户输入的信息后面。在这个例子中，我输入了test.cn，但是发出的第一条查询却是test.cn.com。当解析失败之后，NSLOOKUP工具再次发出一个新的请求，此时这个请求后面就没有添加主DNS后缀。很巧的是，这个客户的环境中，test.cn.com是可以从外部解析到的，所以NSLOOKUP直接将解析到的结果显示出来，而没有再次尝试使用test.cn进行查询，这就是问题的根本原因了。至于有时候能够正常解析，则很可能是缓存的缘故。
      根据我的研究，解决这个问题的方法有两个：
      1. 删除错误的主DNS后缀。
      2. 在NSLOOKUP命令中，在每个要解析的域名或主机名之后加上一个句点，这个点号的作用就是告诉系统名称已经写到根了，不用把本机的主DNS后缀加在用户输入的信息后面了，这样解析也就正常了。
      总结
      DNS是一个基本的服务，但是基本不等于简单。DNS服务配置不当往往会导致各种各样的问题，例如在多个Domain的环境中往往会因为DNS设计不佳造成AD复制的问题。下面是有关DNS常见错误的一些资料：
      DNS服务器疑难解答
      DNS客户端疑难解答
 
      工程师心语：
      在进行排错的时候，以往的经验固然十分重要，但是往往一些联想或假设也能帮助我们解决一些比较少见的问题。另外，我们平时很少接触的诊断日志和跟踪日志在解决一些比较复杂的问题时往往是非常有用的信息。在工作之中，我们也会经常使用Netmon这类的网络监视（嗅探）工具，很多人认为看数据包是一件很高深的工作，但事实并不是这样。网络中的数据包往往是明文传输的，除非使用了SSL或者IPSec进行加密。从抓获的数据包中我们能够获得最可靠也是最根本的信息。通过抓包分析解决很多性能相关的网络问题往往是最快也是最方便的。
      最后，我可以将排错的过程归结成以下公式：
      解决方法=以往的经验*50%+资料搜索*30%+大胆的假设*10%+运气*10%