工程师手记－无法解析出正确的MX记录

     预备知识：
     众所周知，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
http://support.microsoft.com/kb/203204

     我看到这个问题就觉得比较奇怪，因为DNS服务器接收到客户请求时会首先尝试在本地的缓存和本地的区域中进行解析，如果失败，那么就会将这个请求交给用户在转发器中设置的DNS服务器上。如果没有设置转发器，那么就将DNS查询请求交给“根目录提示”中的Internet DNS根服务器，最终得到一个答案回送给客户。如果服务器是从其它名称服务器上获得答案的，那么就会以“Non-authoritative answer”显示。但是这个客户告诉我test.cn的区域本就是在这台服务器上的，MX记录也在这个区域中。由于此时我没有什么想法，所以我要求客户协助我收集一些必要的信息：

     收集服务器上的MPS报告。MPS报告是十分有用的信息，不同类型的MPS会包含不同的信息。这个工具的下载地址是：http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

     建议客户清空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服务器疑难解答

      http://www.microsoft.com/technet/prodtechnol/windowsserver2003/zh-chs/library/ServerHelp/e42d510a-443d-4c31-96da-f66a67a89d86.mspx

      DNS客户端疑难解答

      http://www.microsoft.com/technet/prodtechnol/windowsserver2003/zh-chs/library/ServerHelp/0347e3db-f010-4229-a722-5f8fe653f549.mspx

 

      工程师心语：

      在进行排错的时候，以往的经验固然十分重要，但是往往一些联想或假设也能帮助我们解决一些比较少见的问题。另外，我们平时很少接触的诊断日志和跟踪日志在解决一些比较复杂的问题时往往是非常有用的信息。在工作之中，我们也会经常使用Netmon这类的网络监视（嗅探）工具，很多人认为看数据包是一件很高深的工作，但事实并不是这样。网络中的数据包往往是明文传输的，除非使用了SSL或者IPSec进行加密。从抓获的数据包中我们能够获得最可靠也是最根本的信息。通过抓包分析解决很多性能相关的网络问题往往是最快也是最方便的。

      最后，我可以将排错的过程归结成以下公式：

      解决方法=以往的经验*50%+资料搜索*30%+大胆的假设*10%+运气*10%