DNS故障处理一例(转)
今天有局方说用nslookup时会超时，并且说超时是我们引起的，咨询了一下DNS大拿，原理nslookup解析的时候过程是这样的，转一下博客：
最近同事报障，说是在内网进行nslookup测试时发现：当使用内网DNS服务器192.168.1.1进行解析时，DNS服务器响应非常快，而且没有任何错误；但当使用DMZ区的服务器51.144.198.99进行测试时，发现总是提示请求超时，然后再返回正确解析。由此怀疑我们正在使用的防火墙在处理DNS请求时存在问题。
国内的防火墙产品也确实一点也不争气，在使用过程中总是会出现一些莫名其妙的问题，如在低版本操作系统中支持的功能在高版本中可能就支持不好，有时为了解决低版本操作系统中的一个Bug而进行防火墙操作系统升级，结果可能会是解决了一个，又新出来一堆！这不，才升级了防火墙，同事就找上门来了，没有办法，谁让咱用的防火墙厂家不争气呢，人家怀疑咱这里出问题也是正常啊！
首先查看故障现象，按同事所说进行测试：
C:\>nslookup
Default Server:dns.dg
Address:192.168.1.1
> www.netadmin.com.cn
Server:dns.dg
Address:192.168.1.1
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn
> server 51.144.198.99
Default Server:[51.144.198.99]
Address:51.144.198.99
> www.netadmin.com.cn
Server:[51.144.198.99]
Address:51.144.198.99
DNS request timed out. （请求超时）
timeout was 2 seconds.
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn
C:\>ping 192.168.1.1 （内网DNS服务器）
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time<1ms TTL=127
Reply from 192.168.1.1: bytes=32 time<1ms TTL=127
Reply from 192.168.1.1: bytes=32 time<1ms TTL=127
Reply from 192.168.1.1: bytes=32 time<1ms TTL=127
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping 51.144.198.99 （DMZ区DNS服务器）
Pinging 51.144.198.99 with 32 bytes of data:
Reply from 51.144.198.99: bytes=32 time<1ms TTL=126
Reply from 51.144.198.99: bytes=32 time<1ms TTL=126
Reply from 51.144.198.99: bytes=32 time<1ms TTL=126
Reply from 51.144.198.99: bytes=32 time<1ms TTL=126
Ping statistics for 51.144.198.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
经过ping命令的测试，测试主机到内网DNS服务器、DMZ区DNS服务器响应都很快，所以线路应该没有问题。如果是防火墙策略问题，则nslookup查询时应该完全无响应，而不是在后面又进行了正确解析。
那么可能是下面的几种原因：
可能１：DMZ区服务器有问题；经过在DMZ区其它服务器进行nslookup测试，发现DMZ区的DNS服务器响应正常，由此排除了这种可能。
可能2：防火墙有问题，有可能是高吞吐量时响应有问题。在晚上流量比较小时进行了nslookup测试，发现故障现象仍然存在。看来并不是网络吞吐量引起的防火墙问题。
难道防火墙存在处理DNS请求时存在问题？不敢这么想！一年前我们发现防火墙存在着FTP问题，结果到现在还没有解决！防火墙厂家的开发人员太有才了！好希望不是防火墙的问题！
由于在内网进行测试时所使用的主机均为同网段主机，所以尝试更换一台不同网段的主机进行测试，结果竟然�D�D�D没有问题！
OK，只要有机器没有问题，那这个DNS的问题就应该不是防火墙引起的！只要不是防火墙的问题，那就好解决！呵呵，真是怕了防火墙厂家了！
解决技术问题，如果从表面看不出是什么问题引起的，那么经常用的功能就是Debug，只有从更深层次去查看，才更容易发现问题。那么nslookup工具有没有Debug功能呢？经过简单查看帮助，发现其有两个Debug参数：
[no]debug- print debugging information（显示一般调试信息）
[no]d2- print exhaustive debugging information（显示详细调试信息）
OK，准备使用d2参数查看两台机器执行Debug时分别做了些什么动作！
PC-A（Windows XP）：
C:\ >nslookup
Default Server:dns.dg
Address:192.168.1.1
> server 51.144.198.99
Default Server:[51.144.198.99]
Address:51.144.198.99
> set d2
> www.netadmin.com.cn
Server:[51.144.198.99]
Address:51.144.198.99
------------
SendRequest(), len 45
HEADER:
opcode = QUERY, id = 18, rcode = NOERROR
header flags:query, want recursion
questions = 1,answers = 0,authority records = 0,additional = 0
QUESTIONS:
www.netadmin.com.cn.dgic.cn, type = A,
------------
DNS request timed out.
timeout was 2 seconds.
timeout (2 secs)
SendRequest failed
------------
SendRequest(), len 37
HEADER:
opcode = QUERY, id = 19, rcode = NOERROR
header flags:query, want recursion
questions = 1,answers = 0,authority records = 0,additional = 0
QUESTIONS:
www.netadmin.com.cn, type = A,
------------------------
Got answer (84 bytes):
HEADER:
opcode = QUERY, id = 19, rcode = NOERROR
header flags:response, want recursion, recursion avail.
questions = 1,answers = 2,authority records = 0,additional = 0
QUESTIONS:
www.netadmin.com.cn, type = A,
ANSWERS:
->www.netadmin.com.cn
type = CNAME,, dlen = 19
canonical name = www.365master.com
ttl = 698 (11 mins 38 secs)
->www.365master.com
type = A,, dlen = 4
internet address = 219.141.209.244
ttl = 700 (11 mins 40 secs)
------------
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn
PC-B（Windows 2000 Server）：
C:\ >nslookup
Default Server:dns.dg
Address:192.168.1.1
> server 51.144.198.99
Default Server:[51.144.198.99]
Address:51.144.198.99
> set d2
> www.netadmin.com.cn
Server:[51.144.198.99]
Address:51.144.198.99
------------
SendRequest(), len 37
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags:query, want recursion
questions = 1,answers = 0,authority records = 0,additional = 0
QUESTIONS:
www.netadmin.com.cn, type = A,
------------------------
Got answer (132 bytes):
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags:response, want recursion, recursion avail.
questions = 1,answers = 2,authority records = 2,additional = 0
QUESTIONS:
www.netadmin.com.cn, type = A,
ANSWERS:
->www.netadmin.com.cn
type = CNAME,, dlen = 19
canonical name = www.365master.com
ttl = 2521 (42 mins 1 sec)
->www.365master.com
type = A,, dlen = 4
internet address = 219.141.209.244
ttl = 2917 (48 mins 37 secs)
AUTHORITY RECORDS:
->365master.com
type = NS,, dlen = 16
nameserver = dns11.hichina.com
ttl = 2917 (48 mins 37 secs)
->365master.com
type = NS,, dlen = 8
nameserver = dns12.hichina.com
ttl = 2917 (48 mins 37 secs)
------------
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn
经过对照两台PC机的输出，不难发现，问题就出在PC-A在进行nslookup查询时，多出了一次查询，而且多出的这次查询的对象就是www.netadmin.com.cn.dgic.cn，其最后的后缀（dgic.cn）就是测试机PC-A所在的域名。
在PC使用Nslookup工具进行域名查询测试时，如果该PC是活动目录中的一台主机，默认情况下该主机除了向DNS服务器递交真正需要查询的域名外，它还向DNS服务器递交“查询的域名＋活动目录域后缀”（可能为多个）”这样的请求。
PC-Ａ是活动目录dgic.cn中的一员，在其向内网DNS服务器进行查询请求时，它会提交两个请求，分别为：www.netadmin.com.cn.dgic.cn和www.netadmin.com.cn。对于前者，内网DNS服务器192.168.1.1中含有域dgic.cn，但没有www.netadmin.com.cn.dgic.cn主机记录(Ａ记录)，nslookup没有任何输出；对于后者，其进行一般Ａ记录的查询，并进行正确输出显示。当PC-A使用DMZ区DNS服务器进行nslookup查询时，同样道理，它也会向其发送两个查询请求，对于www.netadmin.com.cn.dgic.cn，由于DMZ区DNS服务器没有域dgic.cn的记录，于是其向上层服务器查询，在得不到响应的情况下最终返回查询超时；对于www.netadmin.com.cn这一域名，其可以进行查询得到结果，并最终正常输出。
PC-B只是工作组中一台主机，所以没有域后缀，这样，当其进行nslookup测试时，无论其使用内网DNS服务器还是DMZ区DNS服务器，其只提交一项域名请求，那就是www.netadmin.com.cn，所以查询结果没有超时现象。
最终，得出了结论：这并不是一个网络故障，而是nslookup工具的原因。
那么有没有办法禁止nslookup这种行为呢，办法还是有的。其一是使用nslookup中的search参数；其二就是使用srchlist参数。
Search参数：启用域名搜索列表。这也是默认设置，也就是在使用nslookup进行域名测试时，nslookup会把主机的域名缀附加到所要请求的域名后面。如果想禁用它，则只需在nslookup环境中，使用set nosearch命令即可禁用。
Srchlist参数：使用域名搜索列表时所要附加的域名列表。默认情况下其值即主机所在的活动目录。如果想更改，可以在nslookup环境中使用命令“set srchlist=域名1/域名2/域名3”，如果想禁止nslookup工具附加域名，则只需“set srchlist=”即可。
下面用nslookup工具的另外一种用法来演示这两个参数的使用，并进而证实我们的结论：
例一：使用默认设置
C:\>nslookup www.netadmin.com.cn 51.144.198.99
*** Can't find server name for address 51.144.198.99: Non-existent domain
Server:UnKnown
Address:51.144.198.99
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn
例二：使用“nosearch”参数
C:\>nslookup -nosearch www.netadmin.com.cn 51.144.198.99
*** Can't find server name for address 51.144.198.99: Non-existent domain
Server:UnKnown
Address:51.144.198.99
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn
例三：使用“srchlist=”参数
C:\>nslookup -srchlist= www.netadmin.com.cn 51.144.198.99
*** Can't find server name for address 51.144.198.99: Non-existent domain
Server:UnKnown
Address:51.144.198.99
Non-authoritative answer:
Name:www.365master.com
Address:219.141.209.244
Aliases:www.netadmin.com.cn