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

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早期的服务器，性能并不高，内存也小，再加上安装的Windows Server2003网络操作系统，而Windows Server 2003操作系统DNS的处理转发能力都不及Windows Server2008，尤其Windows Server 2008系统的 DNS功能在背景区域加载和DNS转发性能上的改进，都会大大增加DNS的转发效率。并且考虑到该集团还有Wins服务器，可以通过Windows Server2008DNS中的GlobalNames区域功能，可以将原来的Wins与DNS服务器合并，解决单标签访问问题。于是想到了下列解决方法。

解决方法二：

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

解决方法三：

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

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

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

总结：

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

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

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

4. 遇到问题应该仔细分析，小心求证。本着先软后硬的原则。问题会得到圆满的解决。

奇怪DNS故障之终极解决