鉴于以上方案都无法奏效，就从服务器和客户机进行4次抓包，通过抓包分析故障原因。

　　从客户机抓包来看，使用电信服务器61.134.1.4直接进行地址解析，而且发现解析全部成功，包括，，，，，，，没有发现任何的错误。

　　但是，当将客户机的DNS指定为内部服务器10.10.1.5时，发现当您在解析，，等网站时就出现超时。尝试去通过以下步骤去比对哪一环节造成延迟：

　　步骤1：

　　在客户机10.20.2.5抓包中，找一个DNS请求，比如说解析不成功，这个请求的发送时间是Jan13,201012:23:52.823093000

　　然后在相同的抓包里看到来自DNS服务器10.10.1.5，结果是解析失败，错误代码是Serveilure(2)，这个回复的接收时间是Jan13,201012:24:03.790867000中间的间隔大概是10秒。

　　步骤2：

　　在DNS服务器10.10.1.5的抓包中，我尝试寻找这个对应的来自于10.20.2.5的DNS请求，看DNS服务器是如何将这个DNS请求转发到电信服务器61.134.1.4。但是在201012:23:52.823093000和201012:24:03.790867000这个时间段里，我没有看到自客户机10.20.2.5发来的包含的DNS请求。与这个时间段接近的这么一个DNS请求是发生在Jan13,201012:23:47.056713000。这一点，我觉得很奇怪，我重新检查了其他失败的请求，也发现了类似的问题。所以我怀疑，DNS服务器和这个客户机的系统时间没有同步。

　　此外，我发现这台服务器单位时间的负载非常大，也有可能是因为这台DNS服务器过忙而导致无法及时响应某些来自客户机的地址解析请求。

　　然后我又检查了刚刚抓过来的最后一次抓包和nslookup的调试日志，我发现直接使用电信DNS服务器时，都能正常解析。但当把DNS服务器修改为内部服务器10.10.1.5时，就发现很多的超时了。然后我又检查了抓包，同样比较客户机抓包和服务器抓包，可以发现两者之间有比较明显的时间差。次外，还有以下发现：

　　步骤1：

　　在客户机抓包中，我找到一个解析失败的DNS请求，客户机发送的时间是Jan13,201014:34:16.876351000

　　然后检查相同抓包，来自DNS服务器的回复是Jan13,201014:34:21.175179000，结果是解析失败，错误代码还是Serveilure(2)。这里请求和回复之间的间隔是5秒钟，这正是DNS服务器默认的超时间隔。

　　步骤2

　　在服务器抓包中，同样相同的来自客户机10.20.2.5的包含的DNS请求包到达内部DNS服务器10.10.1.5的时间是Jan13,201014:34:15.041088000，与客户端那边还是有大概1秒的时间差。然后内部DNS服务器将这个DNS请求转到电信服务器61.134.1.4的时间是Jan13,201014:34:15.041088000。但是，自此之后，内部服务器就再没从电信服务器上收到关于这个请求的回复包了。

　　所以，从这里的结果来看，电信服务器没有及时响应也是造成解析无法成功的原因之一。

　　通过以上分析，我有以下怀疑：

　　1.确保域内客户机和DNS服务器时间轴保持同步

　　2.检查电信DNS服务器61.134.1.4有时候未能及时响应，原因也可能是过于繁忙。检查从电信到公司网络的链路情况。

　　3.增加额外的DNS服务器来进行DNS负载均衡，做成负载均衡方式。

　　解决方法一：

　　检查了网络中的客户机的时间配置，发现所有客户机的时间轴都是同步的，并不存在时间差问题。所以怀疑一被排除。

　　请来电信的工程师以及我们去电信公司对电信的DNS服务器进行检查。发现电信的DNS服务居然没有问题。而且电信到该集团的光缆通信也是正常的，并没有延迟和故障点，逐排除电信DNS问题。

　　这时，发现已经只有一种情况，就是负载过大成为故障引发原因。于是在该集团内部的DNS服务器做了调整，把最大的子机场（该集团的一个子单位）的流量全部指向正常的DNS服务器（192.168.1.9），问题果然解决。

　　但是正当我们准备举杯欢庆的时候，问题又出现了。正常的DNS服务器（192.168.1.9）在正常工作了一个周之后又发生了与之前第一台DNS相同的故障表现。于是，再次对曾经正常的DNS服务器（192.168.1.9）进行抓包，发现：这台DNS服务器又出现了跟之前那个DNS服务器相同的问题。就是单位时间内DNS服务器收到数量巨大的查询包，而某些数据包无法及时的转发成功。考虑到两台DNS服务器在大的流量增加时都会出现相同的问题，立即就考虑是不是服务器性能以及流量的问题。于是检查两台DNS服务器，发现两台DNS服务器都是IBM早期的服务器，性能并不高，内存也小，再加上安装的WindowsServer2003网络操作系统，而WindowsServer2003操作系统DNS的处理转发能力都不及WindowsServer2008，尤其WindowsServer2008系统的DNS功能在背景区域加载和DNS转发性能上的改进，都会大大增加DNS的转发效率。并且考虑到该集团还有Wins服务器，可以通过WindowsServer2008DNS中的GlobalNames区域功能，可以将原来的Wins与DNS服务器合并，解决单标签访问问题。于是想到了下列解决方法。

　　解决方法二：

　　因为考虑到在真实的网络服务器上直接做调试和修改，可能会影响网络的正常运行。于是，先通过微软的SCVM2007（虚拟化技术）中的P2V的技术，将真实的物理服务器全部虚拟成一台台虚拟的服务器，总共虚拟了8台。然后在虚拟的网络中做压力测试。通过虚拟的网络压力测试之后，发现确实存在以上的问题。于是进行方法三。

　　解决方法三：

　　1.购置新的性能较高的IBM服务器2台，在集团里将原来的WindowsServer2003DNS集成活动目录升级为WindowsServer2008。

　　2.将两台AD集成DNS服务的服务器通过WindowsServer的负载均衡功能建立起负载均衡服务器。使两台DNS不要像以前手工指定客户机的DNS服务器到某个服务器，而是直接让服务器自己进行负载。

　　实施方法二已经两个月了，两台DNS服务器都工作正常。至此问题才得到完全解决。

　　总结：

　　1.DNS服务器越来越重要，负载也越来越大，但是我们往往因为考虑到DNS仅仅是进行名称解析，工作压力不大而忽视了DNS服务器的负载问题。

　　2.尽量使用最近的WindowsServer网络操作系统，性能和处理能力都得到改善。

　　3.在网络故障时，尽量先对网络进行模拟，不要直接在真实服务器上修改，避免服务器故障进一步扩大。尽可能使用虚拟。