13518219792
怎样解决奇怪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年由保罗•莫卡派乔斯（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故障问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。
