DNS是域名系统(DomainNameSystem)的缩写，最早于1983年由保罗•莫卡派乔斯（PaulMockapetris）发明。域名系统(DNS)是用于在TCP/IP网络中命名计算机和网络服务的系统，该系统将这些计算机和网络服务组织到域的层次结构中。

　　DNS是域名系统(DomainNameSystem)的缩写，最早于1983年由保罗•莫卡派乔斯（PaulMockapetris）发明。域名系统(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系统。操作系统是WindowsServer2003，使用IIS6的发布功能，将OA的系统发布成WEB方式。

　　3、一台ExchangeServer服务器，主要提供OA办公系统的邮件服务。

　　4、一台Web服务器，该服务器主要提供公司内部的WWW访问

　　5、一台OASQL服务器，该服务器主要是为办公系统OA提供后台数据库支持。

　　6、一台WebSQL服务器，该服务器主要作为WEBServer的后台服务器

　　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命令中的settimeout=5的方式增加了nslookup的查询的响应时间。结果发现查询结果又是5秒超时（nslookup程序默认是2秒超时）。于是我又把时间加到10秒，又出现10秒超时。就是说问题根本使用增加查询时间，都是超时。

　　结论：可能是网络中存在导致DNS查询超时的因素。可能是网络硬件引起。

　　排错二：

　　从DNS查询症状上判断，有可能是网络延迟造成的，考虑到这里，有三个原因会造成延迟：

　　其一是网络中服务器与核心交换机之间的接口均为1000M接口，而连接线缆采用的是超五类非屏蔽双绞线，于是，专门购买了一根7米的六类双绞线，更换原来的超五类非屏蔽线，更换之后，发现变化不大。由此排除因为网线超频导致的DNS查询延迟问题。

　　其二是因为网络中存在大量的包，导致数据碰撞几率增加。而网络中的大量包一般是交换机或路由器的问题所致。就再检查交换机或路由器的配置，发现路由器上采用了热备的方式将两台Cisco路由器连接。并且网线与热备不对应。怀疑是网线的引起，后来在下班之后，将网线的复位为原来初始化的，发现DNS查询稍微有改善。但解析失败依然存在。由此排除因为网线和交换机的配置问题引发。

　　其三，考虑到防火墙上的端口是否正常了DNS服务需要的UDP53和TCP53端口，因为只一个TCP或者UDP的端口，也会出现DNS查询延迟故障。于是192.168.1.9检查防火墙配置，发现防火墙上正确的了相对应的端口。那么排除防火墙的设置故障。

　　结论：排除路由器与交换机和防火墙的硬件的故障和设置故障。

　　思考：通过数据包的查询的流向开分析查询失败的故障

　　排错三

　　首先从服务器上收集了服务器的配置状况MPS报告（MPSRPT_NETWORK,MPSreport下载地址），检查了MPS报告里的各类日志文件，DCDIAG没有任何报错。再检查DNS服务器日志，在最新的DNS服务器日志里，我确实发现了很多和错误日志，但是经过仔细研究，认为它们跟本问题不相干（自2010以来，类似的错误就很少报告）。此外，考虑到这个是外部网址的解析问题，内部没问题，所以可以忽略这些错误跟日志。从其他的日志里，也没有发现跟这个问题可能相关的错误。