一起奇怪的DNS故障

1、DNS 是域名系统(Domain Name System)的缩写，最早于1983 年由保罗 ?莫卡派乔斯（ Paul Mockapetris ）发明。域名系统(DNS) 是用于在TCP/IP网络中命名计算机和网络服务的系统，该系统将这些计算机和网络服务组织到域的层次结构中。DNS 命名通过用户的友好名称查找计算机和服务。当用户在应用程序中输入DNS 名称时， DNS 服务可以将此名称解析为与此名称相关的其他信息，如IP 地址等。DNS 服务作为企业中非常重要的角色，承担着企业的重要任务。越来越多的企业开始在自己的企业部署部DNS 服务器。但是，随着网络规模和网络流量的增长，DNS 也随之出现了

2、各种奇怪的故障。笔者之前就遇到一起奇怪的DNS 故障。为了解决这个故障，前后经过多次的折腾，最后终于“制服 ”这台不 “听话 ”的 DNS 服务器。为了表述方便以及从与安全角度考虑，笔者隐去了该企业的真名，称为某集团。我们先来看看该集团的网络情况网络现状服务器现状：1、两台 DC 服务器集成 DNS 服务，其中一台 IP 为的 DNS 服务器作为主 DNS 服务器，负荷量比较大。而另一台的负荷量较小。2、一台 OA 服务器， OA 服务器上安装了有第三方公司开发的OA 系统。操作系统是 Windows Server 2003 ，使用 IIS6 的发布功能，将 OA 的系统发布成 WEB 方式。

3、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 服务器，该

4、DNS 服务器是台 DC（活动目录集成DNS ）。以前从中国移动接入互联网，后来因为移动 DNS 服务器出现一次问题，本地的这台 DNS 服务器出现无法解析外部地址的情况。后改为中国电信的 DNS 解析，依然无法很好的进行外部解析，具体问题表现为：1、在服务器上使用nslookup 解析部地址，正反向都通过，无问题。（ DNS 本身的简单查询和递归查询测试也通过）2、（在服务器上）解析外部地址，有些地址能解析，有些地址不能解析，不能解析的地址反复试好多次（多达14 次）才能解析成功。问题关键就是这里：时而能解析到，时而解析不到。3、（客户端上）不能解析外部地址，IE 打开那些不能解析到的就会打

5、不开（服务器解析不到当然打不开）。客户端需要多次刷新页面。排错一：首先：检查了该服务器的配置： ip 地址、掩码、网关、 DNS （指自己）、在 DNS 转发器上做了一条转发，转发到电信的 DNS 服务器上。这些都是正确配置。其次：怀疑是缓存的问题，就使用ipconfig /flushdns命令对该服务器的作为客户机的身份的缓存清除一下。然后使用DNSCMD/clearcache 命令清除了该DNS 服务器本身的缓存。 命令不行，就用DNS 控制台里的清除缓存，重新加载等办法，甚至重启服务器。结果，发现问题依旧。 DNS 日志里也没有发现与外部服务器解析相关的记录。此时同时想到了DNS 缓存是

6、不是中毒了，于是通过命令，逐条检查缓存中的缓存记录。发现缓存记录都是正常的， 并为出现病毒的迹象，故此排除缓存病毒问题。第三：发现服务器网卡是千兆自适应网卡，交换机也是千兆的自适应口，而网线使用的是超五类的线，怀疑：两个千兆自适应口因为通过 100M 的超五类非屏蔽线时， 总把超五类的线当成1000M 使用，由此引发双方通过网卡超频这段超五类的非屏蔽网线（因为手头一时没有六类线），就在服务器上和交换机上都将网卡速度降为100M 。发现问题依旧。第四：又怀疑是网络延迟造成。于是使用nslookup 命令中的 settimeout=5 的方式增加了 nslookup 的查询的响应时间。结果发现查询

7、结果又是 5 秒超时（ nslookup 程序默认是 2 秒超时）。于是我又把时间加到 10 秒，又出现 10 秒超时。就是说问题根本使用增加查询时间，都是超时。结论：可能是网络中存在导致 DNS 查询超时的因素。可能是网络硬件引起。排错二：从 DNS 查询症状上判断，有可能是网络延迟造成的，考虑到这里，有三个原因会造成延迟：其一是网络中服务器与核心交换机之间的接口均为1000M 接口，而连接线缆采用的是超五类非屏蔽双绞线，于是，专门购买了一根 7 米的六类双绞线，更换原来的超五类非屏蔽线，更换之后，发现变化不大。由此排除因为网线超频导致的 DNS 查询延迟问题。其二是因为网络中存在大量的广播

8、包，导致数据碰撞几率增加。而网络中的大量广播包一般是交换机或路由器的问题所致。 就再检查交换机或路由器的配置，发现路由器上采用了热备的方式将两台 Cisco 路由器连接。并且网线位置与热备位置不对应。怀疑是网线的位置引起，后来在下班之后，将网线的位置复位为原来初始化的位置，发现 DNS 查询稍微有改善。但解析失败依然存在。由此排除因为网线和交换机的配置问题引发。其三，考虑到防火墙上的端口是否正常开启了DNS 服务需要的UDP53 和 TCP53 端口，因为只开启一个TCP 或者 UDP 的端口，也会出现 DNS 查询延迟故障。于是检查防火墙配置，发现防火墙上正确的开启了相对应的端口。那么排除防

9、火墙的设置故障。结论：排除路由器与交换机和防火墙的硬件的故障和设置故障。思考：通过数据包的查询的流向开分析查询失败的故障排错三：首先从服务器上收集了服务器的配置状况MPS 报告（MPSRPT_NETWORK, MPS report下载地址.microsoft./downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en），检查了 MPS 报告里的各类日志文件， DCDIAG 没有任何报错。再检查DNS 服务器日志，在最新的 DNS 服务器日志里，我确实发现了很多警告和错误日志，但

10、是经过仔细研究，认为它们跟本问题不相干（自2010 以来，类似的错误警告就很少报告）。此外，考虑到这个是外部网址的解析问题，部没问题，所以可以忽略这些错误跟警告日志。从其他的日志里，也没有发现跟这个问题可能相关的错误。鉴于以上方案都无法奏效，就从服务器和客户机进行4 次抓包，通过抓包分析故障原因。从客户机抓包来看， 使用电信服务器直接进行地址解析，而且发现解析全部成功，包括.sina. ，.sohu. ，.google. ，.tudou. ，.xiaoli.cc ，.hao123. ，.chinaren. ，没有发现任何的错误。但是，当将客户机的 DNS 指定为部服务器时，发现当您在解析 .t

11、udou. ，.chinaren. ，.sohu. 等时就出现超时。尝试去通过以下步骤去比对哪一环节造成延迟：步骤 1：在客户机抓包中，找一个 DNS 请求，比如说解析 .sohu. 不成功，这个请求的发送时间是 Jan 13, 2010 12:23:52.823093000然后在相同的抓包里看到来自DNS 服务器，结果是解析失败，错误代码是 Server failure (2) ，这个回复的接收时间是Jan 13,2010 12:24:03.790867000中间的间隔大概是10 秒。步骤 2：在 DNS 服务器的抓包中，我尝试寻找这个对应的来自于的 DNS 请求，看 DNS 服务器是如何将

12、这个 DNS 请求转发到电信服务器。但是在 2010 12:23:52.823093000和 2010 12:24:03.790867000 这个时间段里，我没有看到自客户机发来的包含 .sohu. 的 DNS 请求。与这个时间段接近的这么一个 DNS 请发生在 Jan 13, 2010 12:23:47.056713000。这一点，我觉得很奇怪，我重新检查了其他失败的请求，也发现了类似的问题。所以我怀疑， DNS 服务器和这个客户机的系统时间没有同步。此外，我发现这台服务器单位时间的负载非常大，也有可能是因为这台 DNS 服务器过忙而导致无法及时响应某些来自客户机的地址解析请求。然后我又检查

13、了刚刚抓过来的最后一次抓包和 nslookup 的调试日志，我发现直接使用电信 DNS 服务器时，都能正常解析。但当把 DNS 服务器修改为部服务器时，就发现很多的超时了。 然后我又检查了抓包， 同样比较客户机抓包和服务器抓包， 可以发现两者之间有比较明显的时间差。次外，还有以下发现：步骤 1：在客户机抓包中，我找到一个解析 .sina. 失败的 DNS 请求，客户机发送的时间是 Jan 13, 2010 14:34:16.876351000然后检查相同抓包，来自 DNS 服务器的回复是 Jan 13, 2010 14:34:21.175179000 ，结果是解析失败，错误代码还是 Serve

14、r failure(2)。这里请求和回复之间的间隔是5 秒钟，这正是 DNS 服务器默认的超时间隔。步骤 2在服务器抓包中，同样相同的来自客户机的包含 .sina.的 DNS 请求包到达部 DNS 服务器的时间是 Jan 13, 2010 14:34:15.041088000 ，与客户端那边还是有大概 1 秒的时间差。然后部 DNS 服务器将这个 DNS 请求转到电信服务器的时间是 Jan 13, 2010 14:34:15.041088000 。但是，自此之后，部服务器就再没从电信服务器上收到关于这个请求的回复包了。所以，从这里的结果来看，电信服务器没有及时响应也是造成解析无法成功的原因之一

15、。通过以上分析，我有以下怀疑：1.确保域客户机和DNS 服务器时间轴保持同步2.检查电信 DNS 服务器有时候未能及时响应，原因也可能是过于繁忙。检查从电信到公司网络的链路情况。3.增加额外的 DNS 服务器来进行 DNS 负载均衡，做成负载均衡方式。解决方法一：检查了网络中的客户机的时间配置，发现所有客户机的时间轴都是同步的，并不存在时间差问题。所以怀疑一被排除。请来电信的工程师以及我们去电信公司对电信的DNS 服务器进行检查。发现电信的DNS 服务居然没有问题。而且电信到该集团的光缆通信也是正常的， 并没有延迟和故障点， 逐排除电信 DNS 问题。这时，发现已经只有一种情况， 就是负载过大

16、成为故障引发原因。于是在该集团部的 DNS 服务器做了调整，把最大的子机场（该集团的一个子单位） 的流量全部指向正常的 DNS 服务器（），问题果然解决。但是正当我们准备举杯欢庆的时候，问题又出现了。 正常的 DNS服务器（）在正常工作了一个周之后又发生了与之前第一台 DNS 相同的故障表现。于是，再次对曾经正常的DNS 服务器（ ）进行抓包，发现：这台 DNS服务器又出现了跟之前那个 DNS 服务器相同的问题。就是单位时间DNS 服务器收到数量巨大的查询包，而某些数据包无法及时的转发成功。 考虑到两台 DNS服务器在大的流量增加时都会出现相同的问题，立即就考虑是不是服务

17、器性能以及流量的问题。 于是检查两台 DNS 服务器，发现两台 DNS 服务器都是 IBM 早期的服务器，性能并不高，存也小，再加上安装的 Windows Server2003 网络操作系统，而 Windows Server 2003操作系统 DNS 的处理转发能力都不及Windows Server2008 ，尤其Windows Server 2008系统的DNS 功能在背景区域加载和DNS 转发性能上的改进，都会大大增加 DNS 的转发效率。并且考虑到该集团还有 Wins 服务器，可以通过 Windows Server2008DNS 中的 GlobalNames 区域功能，可以将原来的 Wi

18、ns 与 DNS 服务器合并，解决单标签访问问题。于是想到了下列解决方法。解决方法二：因为考虑到在真实的网络服务器上直接做调试和修改，可能会影响网络的正常运行。于是，先通过微软的SCVM2007 （虚拟化技术）中的 P2V 的技术，将真实的物理服务器全部虚拟成一台台虚拟的服务器，总共虚拟了 8 台。然后在虚拟的网络中做压力测试。通过虚拟的网络压力测试之后，发现确实存在以上的问题。于是进行方法三。解决方法三：1.购置新的性能较高的IBM 服务器 2 台，在集团里将原来的Windows Server 2003DNS集成活动目录升级为Windows Server2008 。2.将两台 AD 集成 DNS 服务的服务器通过Windows Server的负载均衡功能建立起负载均衡服务器。使两台DNS 不要像以前手工指定客户