怎样解决奇怪 DNS 故障，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
DNS 命名通过用户的友好名称查找计算机和服务。当用户在应用程序中输入 DNS 名称时，DNS 服务可以将此名称解析为与此名称相关的其他信息，如 IP 地址等。
DNS 服务作为企业中非常重要的角色，承担着企业的重要任务。越来越多的企业开始在自己的企业部署内部 DNS 服务器。但是，随着网络规模和网络流量的增长，DNS 也随之出现了各种奇怪的故障。笔者之前就遇到一起奇怪的 DNS 故障。为了解决这个故障，前后经过多次的折腾，终于“制服”这台不“听话”的 DNS 服务器。
为了表述方便以及从保密与安全角度考虑，笔者隐去了该企业的真名，称为某集团。
我们先来看看该集团的网络情况
网络现状
服务器现状：
1、两台 DC 服务器集成 DNS 服务，其中一台 IP 为 10.10.1.5 的 DNS 服务器作为主 DNS 服务器，负荷量比较大。而另一台 10.10.1.9 的负荷量较小。
2、一台 OA 服务器，OA 服务器上安装了有第三方公司开发的 OA 系统。操作系统是 Windows Server 2003，使用 IIS6 的发布功能，将 OA 的系统发布成 WEB 方式。
3、一台 Exchange Server 服务器，主要提供 OA 办公系统的邮件服务。
4、一台 Web 服务器，该服务器主要提供公司内部的 WWW 访问
5、一台 OA SQL 服务器，该服务器主要是为办公系统 OA 提供后台数据库支持。
6、一台 Web SQL 服务器，该服务器主要作为 WEB Server 的后台服务器
7、ERP 服务器等，该服务器与本案无关，不予考虑。
网络接入设备
1、接入层均采用 Cisco 交换机。
2、核心层采用 Cisco 核心路由器
3、各设备之间均采用超五类非屏蔽双绞线。
4、企业网与公网之间采用飞塔防火墙做 NET 转换。
网络拓扑图
网络拓扑图（部分）
网络故障描述
本地 DNS 服务器 DNS01.contoso.net，该 DNS 服务器是台 DC（活动目录集成 DNS）。以前从中国移动接入互联网，后来因为移动 DNS 服务器出现一次问题，本地的这台 DNS 服务器出现无法解析外部地址的情况。后改为中国电信的 DNS 解析，依然无法很好的进行外部网站解析，具体问题表现为：
1、在服务器上使用 nslookup 解析内部地址，正反向都通过，无问题。（DNS 本身的简单查询和递归查询测试也通过）
2、（在服务器上）解析外部网站地址，有些地址能解析，有些地址不能解析，不能解析的地址反复试好多次（多达 14 次）才能解析成功。问题关键就是这里：时而能解析到，时而解析不到。
3、（客户端上）不能解析外部地址，IE 打开那些不能解析到的网站就会打不开（服务器解析不到当然打不开）。客户端需要多次刷新页面。
排错一：
首先：检查了该服务器的配置：ip 地址、掩码、网关、DNS（指自己）、在 DNS 转发器上做了一条转发，转发到电信的 DNS 服务器 61.134.1.4 上。这些都是正确配置。
其次：怀疑是缓存的问题，就使用 ipconfig /flushdns 命令对该服务器的作为客户机的身份的缓存清除一下。然后使用 DNSCMD /clearcache 命令清除了该 DNS 服务器本身的缓存。命令不行，就用 DNS 控制台里的清除缓存，重新加载等办法，甚至重启服务器。结果，发现问题依旧。DNS 日志里也没有发现与外部服务器解析相关的记录。此时同时想到了 DNS 缓存是不是中毒了，于是通过命令，逐条检查缓存中的缓存记录。发现缓存记录都是正常的，并为出现病毒的迹象，故此排除缓存病毒问题。
第三：发现服务器网卡是千兆自适应网卡，交换机也是千兆的自适应口，而网线使用的是超五类的线，怀疑：两个千兆自适应口因为通过 100M 的超五类非屏蔽线时，总把超五类的线当成 1000M 使用，由此引发双方通过网卡超频这段超五类的非屏蔽网线（因为手头一时没有六类线），就在服务器上和交换机上都将网卡速度降为 100M。发现问题依旧。
第四：又怀疑是网络延迟造成。于是使用 nslookup 命令中的 set timeout= 5 的方式增加了 nslookup 的查询的响应时间。结果发现查询结果又是 5 秒超时（nslookup 程序默认是 2 秒超时）。于是我又把时间加到 10 秒，又出现 10 秒超时。就是说问题根本使用增加查询时间，都是超时。
结论：可能是网络中存在导致 DNS 查询超时的因素。可能是网络硬件引起。
排错二：
从 DNS 查询症状上判断，有可能是网络延迟造成的，考虑到这里，有三个原因会造成延迟：
其一是网络中服务器与核心交换机之间的接口均为 1000M 接口，而连接线缆采用的是超五类非屏蔽双绞线，于是，专门购买了一根 7 米的六类双绞线，更换原来的超五类非屏蔽线，更换之后，发现变化不大。由此排除因为网线超频导致的 DNS 查询延迟问题。
其二是因为网络中存在大量的广播包，导致数据碰撞几率增加。而网络中的大量广播包一般是交换机或路由器的问题所致。就再检查交换机或路由器的配置，发现路由器上采用了热备的方式将两台 Cisco 路由器连接。并且网线位置与热备位置不对应。怀疑是网线的位置引起，后来在下班之后，将网线的位置复位为原来初始化的位置，发现 DNS 查询稍微有改善。但解析失败依然存在。由此排除因为网线和交换机的配置问题引发。
其三，考虑到防火墙上的端口是否正常开启了 DNS 服务需要的 UDP53 和 TCP53 端口，因为只开启一个 TCP 或者 UDP 的端口，也会出现 DNS 查询延迟故障。于是检查防火墙配置，发现防火墙上正确的开启了相对应的端口。那么排除防火墙的设置故障。
结论：排除路由器与交换机和防火墙的硬件的故障和设置故障。
思考：通过数据包的查询的流向开分析查询失败的故障
排错三
首先从服务器上收集了服务器的配置状况 MPS 报告（MPSRPT_NETWORK, MPS report 下载地址 http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0 displaylang=en），检查了 MPS 报告里的各类日志文件，DCDIAG 没有任何报错。再检查 DNS 服务器日志，在 *** 的 DNS 服务器日志里，我确实发现了很多警告和错误日志，但是经过仔细研究，认为它们跟本问题不相干（自 2010 以来，类似的错误警告就很少报告）。此外，考虑到这个是外部网址的解析问题，内部没问题，所以可以忽略这些错误跟警告日志。从其他的日志里，也没有发现跟这个问题可能相关的错误。
鉴于以上方案都无法奏效，就从服务器和客户机进行 4 次抓包，通过抓包分析故障原因。
从客户机抓包来看，使用电信服务器 61.134.1.4 直接进行地址解析，而且发现解析全部成功，包括 www.sina.com，www.sohu.com，www.google.com，www.tudou.com，www.xiaoli.cc，www.hao123.com，www.chinaren.com，没有发现任何的错误。
但是，当将客户机的 DNS 指定为内部服务器 10.10.1.5 时，发现当您在解析 www.tudou.com，www.chinaren.com，www.sohu.com 等网站时就出现超时。尝试去通过以下步骤去比对哪一环节造成延迟：
步骤 1：
在客户机 10.20.2.5 抓包中，找一个 DNS 请求，比如说解析 www.sohu.com 不成功，这个请求的发送时间是 Jan 13, 2010 12:23:52.823093000
然后在相同的抓包里看到来自 DNS 服务器 10.10.1.5，结果是解析失败，错误代码是 Server failure (2)，这个回复的接收时间是 Jan 13, 2010 12:24:03.790867000 中间的间隔大概是 10 秒。
步骤 2：
在 DNS 服务器 10.10.1.5 的抓包中，我尝试寻找这个对应的来自于 10.20.2.5 的 DNS 请求，看 DNS 服务器是如何将这个 DNS 请求转发到电信服务器 61.134.1.4。但是在 2010 12:23:52.823093000 和 2010 12:24:03.790867000 这个时间段里，我没有看到自客户机 10.20.2.5 发来的包含 www.sohu.com 的 DNS 请求。与这个时间段接近的这么一个 DNS 请求是发生在 Jan 13, 2010 12:23:47.056713000。这一点，我觉得很奇怪，我重新检查了其他失败的请求，也发现了类似的问题。所以我怀疑，DNS 服务器和这个客户机的系统时间没有同步。
此外，我发现这台服务器单位时间的负载非常大，也有可能是因为这台 DNS 服务器过忙而导致无法及时响应某些来自客户机的地址解析请求。
然后我又检查了刚刚抓过来的 *** 一次抓包和 nslookup 的调试日志，我发现直接使用电信 DNS 服务器时，都能正常解析。但当把 DNS 服务器修改为内部服务器 10.10.1.5 时，就发现很多的超时了。然后我又检查了抓包，同样比较客户机抓包和服务器抓包，可以发现两者之间有比较明显的时间差。次外，还有以下发现：
步骤 1：
在客户机抓包中，我找到一个解析 www.sina.com 失败的 DNS 请求，客户机发送的时间是 Jan 13, 2010 14:34:16.876351000
然后检查相同抓包，来自 DNS 服务器的回复是 Jan 13, 2010 14:34:21.175179000，结果是解析失败，错误代码还是 Server failure (2)。这里请求和回复之间的间隔是 5 秒钟，这正是 DNS 服务器默认的超时间隔。
步骤 2
在服务器抓包中，同样相同的来自客户机 10.20.2.5 的包含 www.sina.com 的 DNS 请求包到达内部 DNS 服务器 10.10.1.5 的时间是 Jan 13, 2010 14:34:15.041088000，与客户端那边还是有大概 1 秒的时间差。然后内部 DNS 服务器将这个 DNS 请求转到电信服务器 61.134.1.4 的时间是 Jan 13, 2010 14: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 早期的服务器，性能并不高，内存也小，再加上安装的 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 故障之 *** 解决
西北工业大学微软高级技术培训中心
讲师：张驰 MCP ID：3098942
DNS 是域名系统 (Domain Name System) 的缩写，最早于 1983 年由保罗 bull; 莫卡派乔斯（Paul Mockapetris）发明。域名系统 (DNS) 是用于在 TCP/IP 网络中命名计算机和网络服务的系统，该系统将这些计算机和网络服务组织到域的层次结构中。DNS 命名通过用户的友好名称查找计算机和服务。当用户在应用程序中输入 DNS 名称时，DNS 服务可以将此名称解析为与此名称相关的其他信息，如 IP 地址等。
DNS 服务作为企业中非常重要的角色，承担着企业的重要任务。越来越多的企业开始在自己的企业部署内部 DNS 服务器。但是，随着网络规模和网络流量的增长，DNS 也随之出现了各种奇怪的故障。笔者之前就遇到一起奇怪的 DNS 故障。为了解决这个故障，前后经过多次的折腾，*** 终于“制服”这台不“听话”的 DNS 服务器。
为了表述方便以及从保密与安全角度考虑，笔者隐去了该企业的真名，称为某集团。
我们先来看看该集团的网络情况
网络现状
服务器现状：
1、两台 DC 服务器集成 DNS 服务，其中一台 IP 为 10.10.1.5 的 DNS 服务器作为主 DNS 服务器，负荷量比较大。而另一台 10.10.1.9 的负荷量较小。
2、一台 OA 服务器，OA 服务器上安装了有第三方公司开发的 OA 系统。操作系统是 Windows Server 2003，使用 IIS6 的发布功能，将 OA 的系统发布成 WEB 方式。
3、一台 Exchange Server 服务器，主要提供 OA 办公系统的邮件服务。
4、一台 Web 服务器，该服务器主要提供公司内部的 WWW 访问
5、一台 OA SQL 服务器，该服务器主要是为办公系统 OA 提供后台数据库支持。
6、一台 Web SQL 服务器，该服务器主要作为 WEB Server 的后台服务器
7、ERP 服务器等，该服务器与本案无关，不予考虑。
网络接入设备
1、接入层均采用 Cisco 交换机。
2、核心层采用 Cisco 核心路由器
3、各设备之间均采用超五类非屏蔽双绞线。
4、企业网与公网之间采用飞塔防火墙做 NET 转换。
网络拓扑图
网络拓扑图（部分）
网络故障描述
本地 DNS 服务器 DNS01.contoso.net，该 DNS 服务器是台 DC（活动目录集成 DNS）。以前从中国移动接入互联网，后来因为移动 DNS 服务器出现一次问题，本地的这台 DNS 服务器出现无法解析外部地址的情况。后改为中国电信的 DNS 解析，依然无法很好的进行外部网站解析，具体问题表现为：
1、在服务器上使用 nslookup 解析内部地址，正反向都通过，无问题。（DNS 本身的简单查询和递归查询测试也通过）
2、（在服务器上）解析外部网站地址，有些地址能解析，有些地址不能解析，不能解析的地址反复试好多次（多达 14 次）才能解析成功。问题关键就是这里：时而能解析到，时而解析不到。
3、（客户端上）不能解析外部地址，IE 打开那些不能解析到的网站就会打不开（服务器解析不到当然打不开）。客户端需要多次刷新页面。
排错一：
首先：检查了该服务器的配置：ip 地址、掩码、网关、DNS（指自己）、在 DNS 转发器上做了一条转发，转发到电信的 DNS 服务器 61.134.1.4 上。这些都是正确配置。
其次：怀疑是缓存的问题，就使用 ipconfig /flushdns 命令对该服务器的作为客户机的身份的缓存清除一下。然后使用 DNSCMD /clearcache 命令清除了该 DNS 服务器本身的缓存。命令不行，就用 DNS 控制台里的清除缓存，重新加载等办法，甚至重启服务器。结果，发现问题依旧。DNS 日志里也没有发现与外部服务器解析相关的记录。此时同时想到了 DNS 缓存是不是中毒了，于是通过命令，逐条检查缓存中的缓存记录。发现缓存记录都是正常的，并为出现病毒的迹象，故此排除缓存病毒问题。
第三：发现服务器网卡是千兆自适应网卡，交换机也是千兆的自适应口，而网线使用的是超五类的线，怀疑：两个千兆自适应口因为通过 100M 的超五类非屏蔽线时，总把超五类的线当成 1000M 使用，由此引发双方通过网卡超频这段超五类的非屏蔽网线（因为手头一时没有六类线），就在服务器上和交换机上都将网卡速度降为 100M。发现问题依旧。
第四：又怀疑是网络延迟造成。于是使用 nslookup 命令中的 set timeout= 5 的方式增加了 nslookup 的查询的响应时间。结果发现查询结果又是 5 秒超时（nslookup 程序默认是 2 秒超时）。于是我又把时间加到 10 秒，又出现 10 秒超时。就是说问题根本使用增加查询时间，都是超时。
结论：可能是网络中存在导致 DNS 查询超时的因素。可能是网络硬件引起。
排错二：
从 DNS 查询症状上判断，有可能是网络延迟造成的，考虑到这里，有三个原因会造成延迟：
其一是网络中服务器与核心交换机之间的接口均为 1000M 接口，而连接线缆采用的是超五类非屏蔽双绞线，于是，专门购买了一根 7 米的六类双绞线，更换原来的超五类非屏蔽线，更换之后，发现变化不大。由此排除因为网线超频导致的 DNS 查询延迟问题。
其二是因为网络中存在大量的广播包，导致数据碰撞几率增加。而网络中的大量广播包一般是交换机或路由器的问题所致。就再检查交换机或路由器的配置，发现路由器上采用了热备的方式将两台 Cisco 路由器连接。并且网线位置与热备位置不对应。怀疑是网线的位置引起，后来在下班之后，将网线的位置复位为原来初始化的位置，发现 DNS 查询稍微有改善。但解析失败依然存在。由此排除因为网线和交换机的配置问题引发。
其三，考虑到防火墙上的端口是否正常开启了 DNS 服务需要的 UDP53 和 TCP53 端口，因为只开启一个 TCP 或者 UDP 的端口，也会出现 DNS 查询延迟故障。于是检查防火墙配置，发现防火墙上正确的开启了相对应的端口。那么排除防火墙的设置故障。
结论：排除路由器与交换机和防火墙的硬件的故障和设置故障。
思考：通过数据包的查询的流向开分析查询失败的故障
排错三
首先从服务器上收集了服务器的配置状况 MPS 报告（MPSRPT_NETWORK, MPS report 下载地址 http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0 displaylang=en），检查了 MPS 报告里的各类日志文件，DCDIAG 没有任何报错。再检查 DNS 服务器日志，在 *** 的 DNS 服务器日志里，我确实发现了很多警告和错误日志，但是经过仔细研究，认为它们跟本问题不相干（自 2010 以来，类似的错误警告就很少报告）。此外，考虑到这个是外部网址的解析问题，内部没问题，所以可以忽略这些错误跟警告日志。从其他的日志里，也没有发现跟这个问题可能相关的错误。
鉴于以上方案都无法奏效，就从服务器和客户机进行 4 次抓包，通过抓包分析故障原因。
从客户机抓包来看，使用电信服务器 61.134.1.4 直接进行地址解析，而且发现解析全部成功，包括 www.sina.com，www.sohu.com，www.google.com，www.tudou.com，www.xiaoli.cc，www.hao123.com，www.chinaren.com，没有发现任何的错误。
但是，当将客户机的 DNS 指定为内部服务器 10.10.1.5 时，发现当您在解析 www.tudou.com，www.chinaren.com，www.sohu.com 等网站时就出现超时。尝试去通过以下步骤去比对哪一环节造成延迟：
步骤 1：
在客户机 10.20.2.5 抓包中，找一个 DNS 请求，比如说解析 www.sohu.com 不成功，这个请求的发送时间是 Jan 13, 2010 12:23:52.823093000
然后在相同的抓包里看到来自 DNS 服务器 10.10.1.5，结果是解析失败，错误代码是 Server failure (2)，这个回复的接收时间是 Jan 13, 2010 12:24:03.790867000 中间的间隔大概是 10 秒。
步骤 2：
在 DNS 服务器 10.10.1.5 的抓包中，我尝试寻找这个对应的来自于 10.20.2.5 的 DNS 请求，看 DNS 服务器是如何将这个 DNS 请求转发到电信服务器 61.134.1.4。但是在 2010 12:23:52.823093000 和 2010 12:24:03.790867000 这个时间段里，我没有看到自客户机 10.20.2.5 发来的包含 www.sohu.com 的 DNS 请求。与这个时间段接近的这么一个 DNS 请求是发生在 Jan 13, 2010 12:23:47.056713000。这一点，我觉得很奇怪，我重新检查了其他失败的请求，也发现了类似的问题。所以我怀疑，DNS 服务器和这个客户机的系统时间没有同步。
此外，我发现这台服务器单位时间的负载非常大，也有可能是因为这台 DNS 服务器过忙而导致无法及时响应某些来自客户机的地址解析请求。
然后我又检查了刚刚抓过来的 *** 一次抓包和 nslookup 的调试日志，我发现直接使用电信 DNS 服务器时，都能正常解析。但当把 DNS 服务器修改为内部服务器 10.10.1.5 时，就发现很多的超时了。然后我又检查了抓包，同样比较客户机抓包和服务器抓包，可以发现两者之间有比较明显的时间差。次外，还有以下发现：
步骤 1：
在客户机抓包中，我找到一个解析 www.sina.com 失败的 DNS 请求，客户机发送的时间是 Jan 13, 2010 14:34:16.876351000
然后检查相同抓包，来自 DNS 服务器的回复是 Jan 13, 2010 14:34:21.175179000，结果是解析失败，错误代码还是 Server failure (2)。这里请求和回复之间的间隔是 5 秒钟，这正是 DNS 服务器默认的超时间隔。
步骤 2
在服务器抓包中，同样相同的来自客户机 10.20.2.5 的包含 www.sina.com 的 DNS 请求包到达内部 DNS 服务器 10.10.1.5 的时间是 Jan 13, 2010 14:34:15.041088000，与客户端那边还是有大概 1 秒的时间差。然后内部 DNS 服务器将这个 DNS 请求转到电信服务器 61.134.1.4 的时间是 Jan 13, 2010 14: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 早期的服务器，性能并不高，内存也小，再加上安装的 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 故障问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
六了个六
6666