教学之友,学习之友。

站长教学网

当前位置: 站长教学网 > 服务器 > DNS服务器 >

3种奇怪DNS故障和解决方法(2)

时间:2012-03-25 14:48来源:未知 作者:ken 点击:

排错二:

 

从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。但是,自此之后,内部服务器就再没从电信服务器上收到关于这个请求的回复包了。

 

所以,从这里的结果来看,电信服务器没有及时响应也是造成解析无法成功的原因之一。

 

(责任编辑:ken)

TAG标签: windows 2008 dns 2003 故障
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
注册登录:不允许匿名留言,登录后留言无需输入验证码。
栏目列表
最新内容