一起奇怪的DNS故障Word格式.docx
- 文档编号:19410580
- 上传时间:2023-01-06
- 格式:DOCX
- 页数:7
- 大小:115.72KB
一起奇怪的DNS故障Word格式.docx
《一起奇怪的DNS故障Word格式.docx》由会员分享,可在线阅读,更多相关《一起奇怪的DNS故障Word格式.docx(7页珍藏版)》请在冰豆网上搜索。
操作系统是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服务器DNS,该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查询延迟故障。
于是检查防火墙配置,发现防火墙上正确的开启了相对应的端口。
那么排除防火墙的设置故障。
排除路由器与交换机和防火墙的硬件的故障和设置故障。
思考:
通过数据包的查询的流向开分析查询失败的故障
排错三:
首先从服务器上收集了服务器的配置状况MPS报告(MPSRPT_NETWORK,MPSreport下载地址.microsoft./downloads/details.aspx?
familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&
displaylang=en),检查了MPS报告里的各类日志文件,DCDIAG没有任何报错。
再检查DNS服务器日志,在最新的DNS服务器日志里,我确实发现了很多警告和错误日志,但是经过仔细研究,认为它们跟本问题不相干(自2010以来,类似的错误警告就很少报告)。
此外,考虑到这个是外部网址的解析问题,部没问题,所以可以忽略这些错误跟警告日志。
从其他的日志里,也没有发现跟这个问题可能相关的错误。
鉴于以上方案都无法奏效,就从服务器和客户机进行4次抓包,通过抓包分析故障原因。
从客户机抓包来看,使用电信服务器61.134.1.4直接进行地址解析,而且发现解析全部成功,包括.sina.,.sohu.,.google.,.tudou.,.xiaoli.cc,.hao123.,.chinaren.,没有发现任何的错误。
但是,当将客户机的DNS指定为部服务器10.10.1.5时,发现当您在解析.tudou.,.chinaren.,.sohu.等时就出现超时。
尝试去通过以下步骤去比对哪一环节造成延迟:
步骤1:
在客户机10.20.2.5抓包中,找一个DNS请求,比如说解析.sohu.不成功,这个请求的发送时间是Jan13,201012:
23:
52.823093000
然后在相同的抓包里看到来自DNS服务器10.10.1.5,结果是解析失败,错误代码是Serverfailure
(2),这个回复的接收时间是Jan13,201012:
24:
03.790867000中间的间隔大概是10秒。
步骤2:
在DNS服务器10.10.1.5的抓包中,我尝试寻找这个对应的来自于10.20.2.5的DNS请求,看DNS服务器是如何将这个DNS请求转发到电信服务器61.134.1.4。
但是在201012:
52.823093000和201012:
03.790867000这个时间段里,我没有看到自客户机10.20.2.5发来的包含.sohu.的DNS请求。
与这个时间段接近的这么一个DNS请发生在Jan13,201012:
47.056713000。
这一点,我觉得很奇怪,我重新检查了其他失败的请求,也发现了类似的问题。
所以我怀疑,DNS服务器和这个客户机的系统时间没有同步。
此外,我发现这台服务器单位时间的负载非常大,也有可能是因为这台DNS服务器过忙而导致无法及时响应某些来自客户机的地址解析请求。
然后我又检查了刚刚抓过来的最后一次抓包和nslookup的调试日志,我发现直接使用电信DNS服务器时,都能正常解析。
但当把DNS服务器修改为部服务器10.10.1.5时,就发现很多的超时了。
然后我又检查了抓包,同样比较客户机抓包和服务器抓包,可以发现两者之间有比较明显的时间差。
次外,还有以下发现:
在客户机抓包中,我找到一个解析.sina.失败的DNS请求,客户机发送的时间是Jan13,201014:
34:
16.876351000
然后检查相同抓包,来自DNS服务器的回复是Jan13,201014:
21.175179000,结果是解析失败,错误代码还是Serverfailure
(2)。
这里请求和回复之间的间隔是5秒钟,这正是DNS服务器默认的超时间隔。
步骤2
在服务器抓包中,同样相同的来自客户机10.20.2.5的包含.sina.的DNS请求包到达部DNS服务器10.10.1.5的时间是Jan13,201014:
15.041088000,与客户端那边还是有大概1秒的时间差。
然后部DNS服务器将这个DNS请求转到电信服务器61.134.1.4的时间是Jan13,201014:
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早期的服务器,性能并不高,存也小,再加上安装的WindowsServer2003网络操作系统,而WindowsServer2003操作系统DNS的处理转发能力都不及WindowsServer2008,尤其WindowsServer2008系统的DNS功能在背景区域加载和DNS转发性能上的改进,都会大大增加DNS的转发效率。
并且考虑到该集团还有Wins服务器,可以通过WindowsServer2008DNS中的GlobalNames区域功能,可以将原来的Wins与DNS服务器合并,解决单标签访问问题。
于是想到了下列解决方法。
解决方法二:
因为考虑到在真实的网络服务器上直接做调试和修改,可能会影响网络的正常运行。
于是,先通过微软的SCVM2007(虚拟化技术)中的P2V的技术,将真实的物理服务器全部虚拟成一台台虚拟的服务器,总共虚拟了8台。
然后在虚拟的网络中做压力测试。
通过虚拟的网络压力测试之后,发现确实存在以上的问题。
于是进行方法三。
解决方法三:
1.购置新的性能较高的IBM服务器2台,在集团里将原来的WindowsServer2003DNS集成活动目录升级为WindowsServer2008。
2.将两台AD集成DNS服务的服务器通过WindowsServer的负载均衡功能建立起负载均衡服务器。
使两台DNS不要像以前手工指定客户机的DNS服务器到某个服务器,而是直接让服务器自己进行负载。
实施方法二已经两个月了,两台DNS服务器都工作正常。
至此问题才得到完全解决。
总结:
1.DNS服务器越来越重要,负载也越来越大,但是我们往往因为考虑到DNS仅仅是进行名称解析,工作压力不大而忽视了DNS服务器的负载问题。
2.尽量使用最近的WindowsServer网络操作系统,性能和处理能力都得到改善。
3.在网络故障时,尽量先对网络环境进行模拟,不要直接在真实服务器上修改,避免服务器故障进一步扩大。
尽可能使用虚拟环境。
4.遇到问题应该仔细分析,小心求证。
本着先软后硬的原则。
问题会得到圆满的解决。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 一起 奇怪 DNS 故障