怎樣解決奇怪DNS故障

怎樣解決奇怪DNS故障，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

DNS 命名通過用戶的友好名稱查找計(jì)算機(jī)和服務(wù)。當(dāng)用戶在應(yīng)用程序中輸入 DNS 名稱時(shí)，DNS 服務(wù)可以將此名稱解析為與此名稱相關(guān)的其他信息，如 IP 地址等。

DNS服務(wù)作為企業(yè)中非常重要的角色，承擔(dān)著企業(yè)的重要任務(wù)。越來越多的企業(yè)開始在自己的企業(yè)部署內(nèi)部DNS服務(wù)器。但是，隨著網(wǎng)絡(luò)規(guī)模和網(wǎng)絡(luò)流量的增長，DNS也隨之出現(xiàn)了各種奇怪的故障。筆者之前就遇到一起奇怪的DNS故障。為了解決這個(gè)故障，前后經(jīng)過多次的折騰，終于“制服”這臺(tái)不“聽話”的DNS服務(wù)器。

為了表述方便以及從保密與安全角度考慮，筆者隱去了該企業(yè)的真名，稱為某集團(tuán)。

我們先來看看該集團(tuán)的網(wǎng)絡(luò)情況

網(wǎng)絡(luò)現(xiàn)狀

服務(wù)器現(xiàn)狀：

1、兩臺(tái)DC服務(wù)器集成DNS服務(wù)，其中一臺(tái)IP為10.10.1.5的DNS服務(wù)器作為主DNS服務(wù)器，負(fù)荷量比較大。而另一臺(tái)10.10.1.9的負(fù)荷量較小。

2、一臺(tái)OA服務(wù)器，OA服務(wù)器上安裝了有第三方公司開發(fā)的OA系統(tǒng)。操作系統(tǒng)是Windows Server 2003，使用IIS6的發(fā)布功能，將OA的系統(tǒng)發(fā)布成WEB方式。

3、一臺(tái)Exchange Server服務(wù)器，主要提供OA辦公系統(tǒng)的郵件服務(wù)。

4、一臺(tái)Web 服務(wù)器，該服務(wù)器主要提供公司內(nèi)部的WWW訪問

5、一臺(tái)OA SQL 服務(wù)器，該服務(wù)器主要是為辦公系統(tǒng)OA提供后臺(tái)數(shù)據(jù)庫支持。

6、一臺(tái)Web SQL服務(wù)器，該服務(wù)器主要作為WEB Server的后臺(tái)服務(wù)器

7、ERP服務(wù)器等，該服務(wù)器與本案無關(guān)，不予考慮。

網(wǎng)絡(luò)接入設(shè)備

1、接入層均采用Cisco交換機(jī)。

2、核心層采用Cisco核心路由器

3、各設(shè)備之間均采用超五類非屏蔽雙絞線。

4、企業(yè)網(wǎng)與公網(wǎng)之間采用飛塔防火墻做NET轉(zhuǎn)換。

網(wǎng)絡(luò)拓?fù)鋱D

網(wǎng)絡(luò)拓?fù)鋱D（部分）

網(wǎng)絡(luò)故障描述

本地DNS服務(wù)器DNS01.contoso.net，該DNS服務(wù)器是臺(tái)DC（活動(dòng)目錄集成DNS）。以前從中國移動(dòng)接入互聯(lián)網(wǎng)，后來因?yàn)橐苿?dòng)DNS服務(wù)器出現(xiàn)一次問題，本地的這臺(tái)DNS服務(wù)器出現(xiàn)無法解析外部地址的情況。后改為中國電信的DNS解析，依然無法很好的進(jìn)行外部網(wǎng)站解析，具體問題表現(xiàn)為：

1、在服務(wù)器上使用nslookup解析內(nèi)部地址，正反向都通過，無問題。（DNS本身的簡單查詢和遞歸查詢測試也通過）

2、（在服務(wù)器上）解析外部網(wǎng)站地址，有些地址能解析，有些地址不能解析，不能解析的地址反復(fù)試好多次（多達(dá)14次）才能解析成功。問題關(guān)鍵就是這里：時(shí)而能解析到，時(shí)而解析不到。

3、（客戶端上）不能解析外部地址，IE打開那些不能解析到的網(wǎng)站就會(huì)打不開（服務(wù)器解析不到當(dāng)然打不開）?？蛻舳诵枰啻嗡⑿马撁妗?/p>

排錯(cuò)一：

首先：檢查了該服務(wù)器的配置：ip地址、掩碼、網(wǎng)關(guān)、DNS（指自己）、在DNS轉(zhuǎn)發(fā)器上做了一條轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)到電信的DNS服務(wù)器61.134.1.4上。這些都是正確配置。

其次：懷疑是緩存的問題，就使用ipconfig /flushdns 命令對該服務(wù)器的作為客戶機(jī)的身份的緩存清除一下。然后使用DNSCMD /clearcache命令清除了該DNS服務(wù)器本身的緩存。命令不行，就用DNS控制臺(tái)里的清除緩存，重新加載等辦法，甚至重啟服務(wù)器。結(jié)果，發(fā)現(xiàn)問題依舊。DNS日志里也沒有發(fā)現(xiàn)與外部服務(wù)器解析相關(guān)的記錄。此時(shí)同時(shí)想到了DNS緩存是不是中毒了，于是通過命令，逐條檢查緩存中的緩存記錄。發(fā)現(xiàn)緩存記錄都是正常的，并為出現(xiàn)病毒的跡象，故此排除緩存病毒問題。

第三：發(fā)現(xiàn)服務(wù)器網(wǎng)卡是千兆自適應(yīng)網(wǎng)卡，交換機(jī)也是千兆的自適應(yīng)口，而網(wǎng)線使用的是超五類的線，懷疑：兩個(gè)千兆自適應(yīng)口因?yàn)橥ㄟ^100M的超五類非屏蔽線時(shí)，總把超五類的線當(dāng)成1000M使用，由此引發(fā)雙方通過網(wǎng)卡超頻這段超五類的非屏蔽網(wǎng)線（因?yàn)槭诸^一時(shí)沒有六類線），就在服務(wù)器上和交換機(jī)上都將網(wǎng)卡速度降為100M。發(fā)現(xiàn)問題依舊。

第四：又懷疑是網(wǎng)絡(luò)延遲造成。于是使用nslookup命令中的set timeout=5的方式增加了nslookup的查詢的響應(yīng)時(shí)間。結(jié)果發(fā)現(xiàn)查詢結(jié)果又是5秒超時(shí)（nslookup程序默認(rèn)是2秒超時(shí)）。于是我又把時(shí)間加到10秒，又出現(xiàn)10秒超時(shí)。就是說問題根本使用增加查詢時(shí)間，都是超時(shí)。

結(jié)論：可能是網(wǎng)絡(luò)中存在導(dǎo)致DNS查詢超時(shí)的因素。可能是網(wǎng)絡(luò)硬件引起。

排錯(cuò)二：

從DNS查詢癥狀上判斷，有可能是網(wǎng)絡(luò)延遲造成的，考慮到這里，有三個(gè)原因會(huì)造成延遲：

其一是網(wǎng)絡(luò)中服務(wù)器與核心交換機(jī)之間的接口均為1000M接口，而連接線纜采用的是超五類非屏蔽雙絞線，于是，專門購買了一根7米的六類雙絞線，更換原來的超五類非屏蔽線，更換之后，發(fā)現(xiàn)變化不大。由此排除因?yàn)榫W(wǎng)線超頻導(dǎo)致的DNS查詢延遲問題。

其二是因?yàn)榫W(wǎng)絡(luò)中存在大量的廣播包，導(dǎo)致數(shù)據(jù)碰撞幾率增加。而網(wǎng)絡(luò)中的大量廣播包一般是交換機(jī)或路由器的問題所致。就再檢查交換機(jī)或路由器的配置，發(fā)現(xiàn)路由器上采用了熱備的方式將兩臺(tái)Cisco路由器連接。并且網(wǎng)線位置與熱備位置不對應(yīng)。懷疑是網(wǎng)線的位置引起，后來在下班之后，將網(wǎng)線的位置復(fù)位為原來初始化的位置，發(fā)現(xiàn)DNS查詢稍微有改善。但解析失敗依然存在。由此排除因?yàn)榫W(wǎng)線和交換機(jī)的配置問題引發(fā)。

其三，考慮到防火墻上的端口是否正常開啟了DNS服務(wù)需要的UDP53和TCP53端口，因?yàn)橹婚_啟一個(gè)TCP或者UDP的端口，也會(huì)出現(xiàn)DNS查詢延遲故障。于是檢查防火墻配置，發(fā)現(xiàn)防火墻上正確的開啟了相對應(yīng)的端口。那么排除防火墻的設(shè)置故障。

結(jié)論：排除路由器與交換機(jī)和防火墻的硬件的故障和設(shè)置故障。

思考：通過數(shù)據(jù)包的查詢的流向開分析查詢失敗的故障

排錯(cuò)三

首先從服務(wù)器上收集了服務(wù)器的配置狀況MPS報(bào)告（MPSRPT_NETWORK, MPS report下載地址http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en），檢查了MPS報(bào)告里的各類日志文件，DCDIAG沒有任何報(bào)錯(cuò)。再檢查DNS服務(wù)器日志，在***的DNS服務(wù)器日志里，我確實(shí)發(fā)現(xiàn)了很多警告和錯(cuò)誤日志，但是經(jīng)過仔細(xì)研究，認(rèn)為它們跟本問題不相干（自2010以來，類似的錯(cuò)誤警告就很少報(bào)告）。此外，考慮到這個(gè)是外部網(wǎng)址的解析問題，內(nèi)部沒問題，所以可以忽略這些錯(cuò)誤跟警告日志。從其他的日志里，也沒有發(fā)現(xiàn)跟這個(gè)問題可能相關(guān)的錯(cuò)誤。

鑒于以上方案都無法奏效，就從服務(wù)器和客戶機(jī)進(jìn)行4次抓包，通過抓包分析故障原因。

從客戶機(jī)抓包來看，使用電信服務(wù)器61.134.1.4直接進(jìn)行地址解析，而且發(fā)現(xiàn)解析全部成功，包括www.sina.com，www.sohu.com，www.google.com，www.tudou.com，www.xiaoli.cc，www.hao123.com，www.chinaren.com，沒有發(fā)現(xiàn)任何的錯(cuò)誤。

但是，當(dāng)將客戶機(jī)的DNS指定為內(nèi)部服務(wù)器10.10.1.5時(shí)，發(fā)現(xiàn)當(dāng)您在解析www.tudou.com，www.chinaren.com，www.sohu.com等網(wǎng)站時(shí)就出現(xiàn)超時(shí)。嘗試去通過以下步驟去比對哪一環(huán)節(jié)造成延遲：

步驟1：

在客戶機(jī)10.20.2.5抓包中，找一個(gè)DNS請求，比如說解析www.sohu.com不成功，這個(gè)請求的發(fā)送時(shí)間是Jan 13, 2010 12:23:52.823093000

然后在相同的抓包里看到來自DNS服務(wù)器10.10.1.5，結(jié)果是解析失敗，錯(cuò)誤代碼是Server failure (2)，這個(gè)回復(fù)的接收時(shí)間是Jan 13, 2010 12:24:03.790867000中間的間隔大概是10秒。

步驟2：

在DNS服務(wù)器10.10.1.5的抓包中，我嘗試尋找這個(gè)對應(yīng)的來自于10.20.2.5的DNS請求，看DNS服務(wù)器是如何將這個(gè)DNS請求轉(zhuǎn)發(fā)到電信服務(wù)器61.134.1.4。但是在2010 12:23:52.823093000和2010 12:24:03.790867000這個(gè)時(shí)間段里，我沒有看到自客戶機(jī)10.20.2.5發(fā)來的包含www.sohu.com的DNS請求。與這個(gè)時(shí)間段接近的這么一個(gè)DNS請求是發(fā)生在Jan 13, 2010 12:23:47.056713000。這一點(diǎn)，我覺得很奇怪，我重新檢查了其他失敗的請求，也發(fā)現(xiàn)了類似的問題。所以我懷疑，DNS服務(wù)器和這個(gè)客戶機(jī)的系統(tǒng)時(shí)間沒有同步。

此外，我發(fā)現(xiàn)這臺(tái)服務(wù)器單位時(shí)間的負(fù)載非常大，也有可能是因?yàn)檫@臺(tái)DNS服務(wù)器過忙而導(dǎo)致無法及時(shí)響應(yīng)某些來自客戶機(jī)的地址解析請求。

然后我又檢查了剛剛抓過來的***一次抓包和nslookup的調(diào)試日志，我發(fā)現(xiàn)直接使用電信DNS服務(wù)器時(shí)，都能正常解析。但當(dāng)把DNS服務(wù)器修改為內(nèi)部服務(wù)器10.10.1.5時(shí)，就發(fā)現(xiàn)很多的超時(shí)了。然后我又檢查了抓包，同樣比較客戶機(jī)抓包和服務(wù)器抓包，可以發(fā)現(xiàn)兩者之間有比較明顯的時(shí)間差。次外，還有以下發(fā)現(xiàn)：

步驟1：

在客戶機(jī)抓包中，我找到一個(gè)解析www.sina.com失敗的DNS請求，客戶機(jī)發(fā)送的時(shí)間是Jan 13, 2010 14:34:16.876351000

然后檢查相同抓包，來自DNS服務(wù)器的回復(fù)是Jan 13, 2010 14:34:21.175179000，結(jié)果是解析失敗，錯(cuò)誤代碼還是Server failure (2)。這里請求和回復(fù)之間的間隔是5秒鐘，這正是DNS服務(wù)器默認(rèn)的超時(shí)間隔。

步驟2

在服務(wù)器抓包中，同樣相同的來自客戶機(jī)10.20.2.5的包含www.sina.com的DNS請求包到達(dá)內(nèi)部DNS服務(wù)器10.10.1.5的時(shí)間是Jan 13, 2010 14:34:15.041088000，與客戶端那邊還是有大概1秒的時(shí)間差。然后內(nèi)部DNS服務(wù)器將這個(gè)DNS請求轉(zhuǎn)到電信服務(wù)器61.134.1.4的時(shí)間是Jan 13, 2010 14:34:15.041088000。但是，自此之后，內(nèi)部服務(wù)器就再?zèng)]從電信服務(wù)器上收到關(guān)于這個(gè)請求的回復(fù)包了。

所以，從這里的結(jié)果來看，電信服務(wù)器沒有及時(shí)響應(yīng)也是造成解析無法成功的原因之一。

通過以上分析，我有以下懷疑：

1. 確保域內(nèi)客戶機(jī)和DNS服務(wù)器時(shí)間軸保持同步

2. 檢查電信DNS服務(wù)器61.134.1.4有時(shí)候未能及時(shí)響應(yīng)，原因也可能是過于繁忙。檢查從電信到公司網(wǎng)絡(luò)的鏈路情況。

3. 增加額外的DNS服務(wù)器來進(jìn)行DNS負(fù)載均衡，做成負(fù)載均衡方式。

解決方法一：

檢查了網(wǎng)絡(luò)中的客戶機(jī)的時(shí)間配置，發(fā)現(xiàn)所有客戶機(jī)的時(shí)間軸都是同步的，并不存在時(shí)間差問題。所以懷疑一被排除。

請來電信的工程師以及我們?nèi)ル娦殴緦﹄娦诺腄NS服務(wù)器進(jìn)行檢查。發(fā)現(xiàn)電信的DNS服務(wù)居然沒有問題。而且電信到該集團(tuán)的光纜通信也是正常的，并沒有延遲和故障點(diǎn)，逐排除電信DNS問題。

這時(shí)，發(fā)現(xiàn)已經(jīng)只有一種情況，就是負(fù)載過大成為故障引發(fā)原因。于是在該集團(tuán)內(nèi)部的DNS服務(wù)器做了調(diào)整，把***的子機(jī)場（該集團(tuán)的一個(gè)子單位）的流量全部指向正常的DNS服務(wù)器（192.168.1.9），問題果然解決。

但是正當(dāng)我們準(zhǔn)備舉杯歡慶的時(shí)候，問題又出現(xiàn)了。正常的DNS服務(wù)器（192.168.1.9）在正常工作了一個(gè)周之后又發(fā)生了與之前***臺(tái)DNS相同的故障表現(xiàn)。于是，再次對曾經(jīng)正常的DNS服務(wù)器（192.168.1.9）進(jìn)行抓包，發(fā)現(xiàn)：這臺(tái)DNS服務(wù)器又出現(xiàn)了跟之前那個(gè)DNS服務(wù)器相同的問題。就是單位時(shí)間內(nèi)DNS服務(wù)器收到數(shù)量巨大的查詢包，而某些數(shù)據(jù)包無法及時(shí)的轉(zhuǎn)發(fā)成功。考慮到兩臺(tái)DNS服務(wù)器在大的流量增加時(shí)都會(huì)出現(xiàn)相同的問題，立即就考慮是不是服務(wù)器性能以及流量的問題。于是檢查兩臺(tái)DNS服務(wù)器，發(fā)現(xiàn)兩臺(tái)DNS服務(wù)器都是IBM早期的服務(wù)器，性能并不高，內(nèi)存也小，再加上安裝的Windows Server2003網(wǎng)絡(luò)操作系統(tǒng)，而Windows Server 2003操作系統(tǒng)DNS的處理轉(zhuǎn)發(fā)能力都不及Windows Server2008，尤其Windows Server 2008系統(tǒng)的 DNS功能在背景區(qū)域加載和DNS轉(zhuǎn)發(fā)性能上的改進(jìn)，都會(huì)大大增加DNS的轉(zhuǎn)發(fā)效率。并且考慮到該集團(tuán)還有Wins服務(wù)器，可以通過Windows Server2008DNS中的GlobalNames區(qū)域功能，可以將原來的Wins與DNS服務(wù)器合并，解決單標(biāo)簽訪問問題。于是想到了下列解決方法。

解決方法二：

因?yàn)榭紤]到在真實(shí)的網(wǎng)絡(luò)服務(wù)器上直接做調(diào)試和修改，可能會(huì)影響網(wǎng)絡(luò)的正常運(yùn)行。于是，先通過微軟的SCVM2007（虛擬化技術(shù)）中的P2V的技術(shù)，將真實(shí)的物理服務(wù)器全部虛擬成一臺(tái)臺(tái)虛擬的服務(wù)器，總共虛擬了8臺(tái)。然后在虛擬的網(wǎng)絡(luò)中做壓力測試。通過虛擬的網(wǎng)絡(luò)壓力測試之后，發(fā)現(xiàn)確實(shí)存在以上的問題。于是進(jìn)行方法三。

解決方法三：

1. 購置新的性能較高的IBM服務(wù)器2臺(tái)，在集團(tuán)里將原來的Windows Server 2003DNS集成活動(dòng)目錄升級為Windows Server 2008。

2. 將兩臺(tái)AD集成DNS服務(wù)的服務(wù)器通過Windows Server 的負(fù)載均衡功能建立起負(fù)載均衡服務(wù)器。使兩臺(tái)DNS不要像以前手工指定客戶機(jī)的DNS服務(wù)器到某個(gè)服務(wù)器，而是直接讓服務(wù)器自己進(jìn)行負(fù)載。

實(shí)施方法二已經(jīng)兩個(gè)月了，兩臺(tái)DNS服務(wù)器都工作正常。至此問題才得到完全解決。

總結(jié)：

1. DNS服務(wù)器越來越重要，負(fù)載也越來越大，但是我們往往因?yàn)榭紤]到DNS僅僅是進(jìn)行名稱解析，工作壓力不大而忽視了DNS服務(wù)器的負(fù)載問題。

2. 盡量使用最近的Windows Server網(wǎng)絡(luò)操作系統(tǒng)，性能和處理能力都得到改善。

3. 在網(wǎng)絡(luò)故障時(shí)，盡量先對網(wǎng)絡(luò)環(huán)境進(jìn)行模擬，不要直接在真實(shí)服務(wù)器上修改，避免服務(wù)器故障進(jìn)一步擴(kuò)大。盡可能使用虛擬環(huán)境。

4. 遇到問題應(yīng)該仔細(xì)分析，小心求證。本著先軟后硬的原則。問題會(huì)得到圓滿的解決。

奇怪DNS故障之***解決

西北工業(yè)大學(xué)微軟高級技術(shù)培訓(xùn)中心

講師：張馳 MCP ID：3098942

DNS 是域名系統(tǒng) (Domain Name System) 的縮寫，最早于1983年由保羅•莫卡派喬斯（Paul Mockapetris）發(fā)明。域名系統(tǒng) (DNS) 是用于在 TCP/IP 網(wǎng)絡(luò)中命名計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)的系統(tǒng)，該系統(tǒng)將這些計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)組織到域的層次結(jié)構(gòu)中。DNS 命名通過用戶的友好名稱查找計(jì)算機(jī)和服務(wù)。當(dāng)用戶在應(yīng)用程序中輸入 DNS 名稱時(shí)，DNS 服務(wù)可以將此名稱解析為與此名稱相關(guān)的其他信息，如 IP 地址等。

DNS服務(wù)作為企業(yè)中非常重要的角色，承擔(dān)著企業(yè)的重要任務(wù)。越來越多的企業(yè)開始在自己的企業(yè)部署內(nèi)部DNS服務(wù)器。但是，隨著網(wǎng)絡(luò)規(guī)模和網(wǎng)絡(luò)流量的增長，DNS也隨之出現(xiàn)了各種奇怪的故障。筆者之前就遇到一起奇怪的DNS故障。為了解決這個(gè)故障，前后經(jīng)過多次的折騰，***終于“制服”這臺(tái)不“聽話”的DNS服務(wù)器。

為了表述方便以及從保密與安全角度考慮，筆者隱去了該企業(yè)的真名，稱為某集團(tuán)。

我們先來看看該集團(tuán)的網(wǎng)絡(luò)情況

網(wǎng)絡(luò)現(xiàn)狀

服務(wù)器現(xiàn)狀：

1、兩臺(tái)DC服務(wù)器集成DNS服務(wù)，其中一臺(tái)IP為10.10.1.5的DNS服務(wù)器作為主DNS服務(wù)器，負(fù)荷量比較大。而另一臺(tái)10.10.1.9的負(fù)荷量較小。

2、一臺(tái)OA服務(wù)器，OA服務(wù)器上安裝了有第三方公司開發(fā)的OA系統(tǒng)。操作系統(tǒng)是Windows Server 2003，使用IIS6的發(fā)布功能，將OA的系統(tǒng)發(fā)布成WEB方式。

3、一臺(tái)Exchange Server服務(wù)器，主要提供OA辦公系統(tǒng)的郵件服務(wù)。

4、一臺(tái)Web 服務(wù)器，該服務(wù)器主要提供公司內(nèi)部的WWW訪問

5、一臺(tái)OA SQL 服務(wù)器，該服務(wù)器主要是為辦公系統(tǒng)OA提供后臺(tái)數(shù)據(jù)庫支持。

6、一臺(tái)Web SQL服務(wù)器，該服務(wù)器主要作為WEB Server的后臺(tái)服務(wù)器

7、ERP服務(wù)器等，該服務(wù)器與本案無關(guān)，不予考慮。

網(wǎng)絡(luò)接入設(shè)備

1、接入層均采用Cisco交換機(jī)。

2、核心層采用Cisco核心路由器

3、各設(shè)備之間均采用超五類非屏蔽雙絞線。

4、企業(yè)網(wǎng)與公網(wǎng)之間采用飛塔防火墻做NET轉(zhuǎn)換。

網(wǎng)絡(luò)拓?fù)鋱D

網(wǎng)絡(luò)拓?fù)鋱D（部分）

網(wǎng)絡(luò)故障描述

本地DNS服務(wù)器DNS01.contoso.net，該DNS服務(wù)器是臺(tái)DC（活動(dòng)目錄集成DNS）。以前從中國移動(dòng)接入互聯(lián)網(wǎng)，后來因?yàn)橐苿?dòng)DNS服務(wù)器出現(xiàn)一次問題，本地的這臺(tái)DNS服務(wù)器出現(xiàn)無法解析外部地址的情況。后改為中國電信的DNS解析，依然無法很好的進(jìn)行外部網(wǎng)站解析，具體問題表現(xiàn)為：

1、在服務(wù)器上使用nslookup解析內(nèi)部地址，正反向都通過，無問題。（DNS本身的簡單查詢和遞歸查詢測試也通過）

2、（在服務(wù)器上）解析外部網(wǎng)站地址，有些地址能解析，有些地址不能解析，不能解析的地址反復(fù)試好多次（多達(dá)14次）才能解析成功。問題關(guān)鍵就是這里：時(shí)而能解析到，時(shí)而解析不到。

3、（客戶端上）不能解析外部地址，IE打開那些不能解析到的網(wǎng)站就會(huì)打不開（服務(wù)器解析不到當(dāng)然打不開）?？蛻舳诵枰啻嗡⑿马撁?。

排錯(cuò)一：

首先：檢查了該服務(wù)器的配置：ip地址、掩碼、網(wǎng)關(guān)、DNS（指自己）、在DNS轉(zhuǎn)發(fā)器上做了一條轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)到電信的DNS服務(wù)器61.134.1.4上。這些都是正確配置。

其次：懷疑是緩存的問題，就使用ipconfig /flushdns 命令對該服務(wù)器的作為客戶機(jī)的身份的緩存清除一下。然后使用DNSCMD /clearcache命令清除了該DNS服務(wù)器本身的緩存。命令不行，就用DNS控制臺(tái)里的清除緩存，重新加載等辦法，甚至重啟服務(wù)器。結(jié)果，發(fā)現(xiàn)問題依舊。DNS日志里也沒有發(fā)現(xiàn)與外部服務(wù)器解析相關(guān)的記錄。此時(shí)同時(shí)想到了DNS緩存是不是中毒了，于是通過命令，逐條檢查緩存中的緩存記錄。發(fā)現(xiàn)緩存記錄都是正常的，并為出現(xiàn)病毒的跡象，故此排除緩存病毒問題。

第三：發(fā)現(xiàn)服務(wù)器網(wǎng)卡是千兆自適應(yīng)網(wǎng)卡，交換機(jī)也是千兆的自適應(yīng)口，而網(wǎng)線使用的是超五類的線，懷疑：兩個(gè)千兆自適應(yīng)口因?yàn)橥ㄟ^100M的超五類非屏蔽線時(shí)，總把超五類的線當(dāng)成1000M使用，由此引發(fā)雙方通過網(wǎng)卡超頻這段超五類的非屏蔽網(wǎng)線（因?yàn)槭诸^一時(shí)沒有六類線），就在服務(wù)器上和交換機(jī)上都將網(wǎng)卡速度降為100M。發(fā)現(xiàn)問題依舊。

第四：又懷疑是網(wǎng)絡(luò)延遲造成。于是使用nslookup命令中的set timeout=5的方式增加了nslookup的查詢的響應(yīng)時(shí)間。結(jié)果發(fā)現(xiàn)查詢結(jié)果又是5秒超時(shí)（nslookup程序默認(rèn)是2秒超時(shí)）。于是我又把時(shí)間加到10秒，又出現(xiàn)10秒超時(shí)。就是說問題根本使用增加查詢時(shí)間，都是超時(shí)。

結(jié)論：可能是網(wǎng)絡(luò)中存在導(dǎo)致DNS查詢超時(shí)的因素?？赡苁蔷W(wǎng)絡(luò)硬件引起。

排錯(cuò)二：

從DNS查詢癥狀上判斷，有可能是網(wǎng)絡(luò)延遲造成的，考慮到這里，有三個(gè)原因會(huì)造成延遲：

其一是網(wǎng)絡(luò)中服務(wù)器與核心交換機(jī)之間的接口均為1000M接口，而連接線纜采用的是超五類非屏蔽雙絞線，于是，專門購買了一根7米的六類雙絞線，更換原來的超五類非屏蔽線，更換之后，發(fā)現(xiàn)變化不大。由此排除因?yàn)榫W(wǎng)線超頻導(dǎo)致的DNS查詢延遲問題。

其二是因?yàn)榫W(wǎng)絡(luò)中存在大量的廣播包，導(dǎo)致數(shù)據(jù)碰撞幾率增加。而網(wǎng)絡(luò)中的大量廣播包一般是交換機(jī)或路由器的問題所致。就再檢查交換機(jī)或路由器的配置，發(fā)現(xiàn)路由器上采用了熱備的方式將兩臺(tái)Cisco路由器連接。并且網(wǎng)線位置與熱備位置不對應(yīng)。懷疑是網(wǎng)線的位置引起，后來在下班之后，將網(wǎng)線的位置復(fù)位為原來初始化的位置，發(fā)現(xiàn)DNS查詢稍微有改善。但解析失敗依然存在。由此排除因?yàn)榫W(wǎng)線和交換機(jī)的配置問題引發(fā)。

其三，考慮到防火墻上的端口是否正常開啟了DNS服務(wù)需要的UDP53和TCP53端口，因?yàn)橹婚_啟一個(gè)TCP或者UDP的端口，也會(huì)出現(xiàn)DNS查詢延遲故障。于是檢查防火墻配置，發(fā)現(xiàn)防火墻上正確的開啟了相對應(yīng)的端口。那么排除防火墻的設(shè)置故障。

結(jié)論：排除路由器與交換機(jī)和防火墻的硬件的故障和設(shè)置故障。

思考：通過數(shù)據(jù)包的查詢的流向開分析查詢失敗的故障

排錯(cuò)三

首先從服務(wù)器上收集了服務(wù)器的配置狀況MPS報(bào)告（MPSRPT_NETWORK, MPS report下載地址http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en），檢查了MPS報(bào)告里的各類日志文件，DCDIAG沒有任何報(bào)錯(cuò)。再檢查DNS服務(wù)器日志，在***的DNS服務(wù)器日志里，我確實(shí)發(fā)現(xiàn)了很多警告和錯(cuò)誤日志，但是經(jīng)過仔細(xì)研究，認(rèn)為它們跟本問題不相干（自2010以來，類似的錯(cuò)誤警告就很少報(bào)告）。此外，考慮到這個(gè)是外部網(wǎng)址的解析問題，內(nèi)部沒問題，所以可以忽略這些錯(cuò)誤跟警告日志。從其他的日志里，也沒有發(fā)現(xiàn)跟這個(gè)問題可能相關(guān)的錯(cuò)誤。

鑒于以上方案都無法奏效，就從服務(wù)器和客戶機(jī)進(jìn)行4次抓包，通過抓包分析故障原因。

從客戶機(jī)抓包來看，使用電信服務(wù)器61.134.1.4直接進(jìn)行地址解析，而且發(fā)現(xiàn)解析全部成功，包括www.sina.com，www.sohu.com，www.google.com，www.tudou.com，www.xiaoli.cc，www.hao123.com，www.chinaren.com，沒有發(fā)現(xiàn)任何的錯(cuò)誤。

但是，當(dāng)將客戶機(jī)的DNS指定為內(nèi)部服務(wù)器10.10.1.5時(shí)，發(fā)現(xiàn)當(dāng)您在解析www.tudou.com，www.chinaren.com，www.sohu.com等網(wǎng)站時(shí)就出現(xiàn)超時(shí)。嘗試去通過以下步驟去比對哪一環(huán)節(jié)造成延遲：

步驟1：

在客戶機(jī)10.20.2.5抓包中，找一個(gè)DNS請求，比如說解析www.sohu.com不成功，這個(gè)請求的發(fā)送時(shí)間是Jan 13, 2010 12:23:52.823093000

然后在相同的抓包里看到來自DNS服務(wù)器10.10.1.5，結(jié)果是解析失敗，錯(cuò)誤代碼是Server failure (2)，這個(gè)回復(fù)的接收時(shí)間是Jan 13, 2010 12:24:03.790867000中間的間隔大概是10秒。

步驟2：

在DNS服務(wù)器10.10.1.5的抓包中，我嘗試尋找這個(gè)對應(yīng)的來自于10.20.2.5的DNS請求，看DNS服務(wù)器是如何將這個(gè)DNS請求轉(zhuǎn)發(fā)到電信服務(wù)器61.134.1.4。但是在2010 12:23:52.823093000和2010 12:24:03.790867000這個(gè)時(shí)間段里，我沒有看到自客戶機(jī)10.20.2.5發(fā)來的包含www.sohu.com的DNS請求。與這個(gè)時(shí)間段接近的這么一個(gè)DNS請求是發(fā)生在Jan 13, 2010 12:23:47.056713000。這一點(diǎn)，我覺得很奇怪，我重新檢查了其他失敗的請求，也發(fā)現(xiàn)了類似的問題。所以我懷疑，DNS服務(wù)器和這個(gè)客戶機(jī)的系統(tǒng)時(shí)間沒有同步。

此外，我發(fā)現(xiàn)這臺(tái)服務(wù)器單位時(shí)間的負(fù)載非常大，也有可能是因?yàn)檫@臺(tái)DNS服務(wù)器過忙而導(dǎo)致無法及時(shí)響應(yīng)某些來自客戶機(jī)的地址解析請求。

然后我又檢查了剛剛抓過來的***一次抓包和nslookup的調(diào)試日志，我發(fā)現(xiàn)直接使用電信DNS服務(wù)器時(shí)，都能正常解析。但當(dāng)把DNS服務(wù)器修改為內(nèi)部服務(wù)器10.10.1.5時(shí)，就發(fā)現(xiàn)很多的超時(shí)了。然后我又檢查了抓包，同樣比較客戶機(jī)抓包和服務(wù)器抓包，可以發(fā)現(xiàn)兩者之間有比較明顯的時(shí)間差。次外，還有以下發(fā)現(xiàn)：

步驟1：

在客戶機(jī)抓包中，我找到一個(gè)解析www.sina.com失敗的DNS請求，客戶機(jī)發(fā)送的時(shí)間是Jan 13, 2010 14:34:16.876351000

然后檢查相同抓包，來自DNS服務(wù)器的回復(fù)是Jan 13, 2010 14:34:21.175179000，結(jié)果是解析失敗，錯(cuò)誤代碼還是Server failure (2)。這里請求和回復(fù)之間的間隔是5秒鐘，這正是DNS服務(wù)器默認(rèn)的超時(shí)間隔。

步驟2

在服務(wù)器抓包中，同樣相同的來自客戶機(jī)10.20.2.5的包含www.sina.com的DNS請求包到達(dá)內(nèi)部DNS服務(wù)器10.10.1.5的時(shí)間是Jan 13, 2010 14:34:15.041088000，與客戶端那邊還是有大概1秒的時(shí)間差。然后內(nèi)部DNS服務(wù)器將這個(gè)DNS請求轉(zhuǎn)到電信服務(wù)器61.134.1.4的時(shí)間是Jan 13, 2010 14:34:15.041088000。但是，自此之后，內(nèi)部服務(wù)器就再?zèng)]從電信服務(wù)器上收到關(guān)于這個(gè)請求的回復(fù)包了。

所以，從這里的結(jié)果來看，電信服務(wù)器沒有及時(shí)響應(yīng)也是造成解析無法成功的原因之一。

通過以上分析，我有以下懷疑：

1. 確保域內(nèi)客戶機(jī)和DNS服務(wù)器時(shí)間軸保持同步

2. 檢查電信DNS服務(wù)器61.134.1.4有時(shí)候未能及時(shí)響應(yīng)，原因也可能是過于繁忙。檢查從電信到公司網(wǎng)絡(luò)的鏈路情況。

3. 增加額外的DNS服務(wù)器來進(jìn)行DNS負(fù)載均衡，做成負(fù)載均衡方式。

解決方法一：

檢查了網(wǎng)絡(luò)中的客戶機(jī)的時(shí)間配置，發(fā)現(xiàn)所有客戶機(jī)的時(shí)間軸都是同步的，并不存在時(shí)間差問題。所以懷疑一被排除。

請來電信的工程師以及我們?nèi)ル娦殴緦﹄娦诺腄NS服務(wù)器進(jìn)行檢查。發(fā)現(xiàn)電信的DNS服務(wù)居然沒有問題。而且電信到該集團(tuán)的光纜通信也是正常的，并沒有延遲和故障點(diǎn)，逐排除電信DNS問題。

這時(shí)，發(fā)現(xiàn)已經(jīng)只有一種情況，就是負(fù)載過大成為故障引發(fā)原因。于是在該集團(tuán)內(nèi)部的DNS服務(wù)器做了調(diào)整，把***的子機(jī)場（該集團(tuán)的一個(gè)子單位）的流量全部指向正常的DNS服務(wù)器（192.168.1.9），問題果然解決。

但是正當(dāng)我們準(zhǔn)備舉杯歡慶的時(shí)候，問題又出現(xiàn)了。正常的DNS服務(wù)器（192.168.1.9）在正常工作了一個(gè)周之后又發(fā)生了與之前***臺(tái)DNS相同的故障表現(xiàn)。于是，再次對曾經(jīng)正常的DNS服務(wù)器（192.168.1.9）進(jìn)行抓包，發(fā)現(xiàn)：這臺(tái)DNS服務(wù)器又出現(xiàn)了跟之前那個(gè)DNS服務(wù)器相同的問題。就是單位時(shí)間內(nèi)DNS服務(wù)器收到數(shù)量巨大的查詢包，而某些數(shù)據(jù)包無法及時(shí)的轉(zhuǎn)發(fā)成功?？紤]到兩臺(tái)DNS服務(wù)器在大的流量增加時(shí)都會(huì)出現(xiàn)相同的問題，立即就考慮是不是服務(wù)器性能以及流量的問題。于是檢查兩臺(tái)DNS服務(wù)器，發(fā)現(xiàn)兩臺(tái)DNS服務(wù)器都是IBM早期的服務(wù)器，性能并不高，內(nèi)存也小，再加上安裝的Windows Server2003網(wǎng)絡(luò)操作系統(tǒng)，而Windows Server 2003操作系統(tǒng)DNS的處理轉(zhuǎn)發(fā)能力都不及Windows Server2008，尤其Windows Server 2008系統(tǒng)的 DNS功能在背景區(qū)域加載和DNS轉(zhuǎn)發(fā)性能上的改進(jìn)，都會(huì)大大增加DNS的轉(zhuǎn)發(fā)效率。并且考慮到該集團(tuán)還有Wins服務(wù)器，可以通過Windows Server2008DNS中的GlobalNames區(qū)域功能，可以將原來的Wins與DNS服務(wù)器合并，解決單標(biāo)簽訪問問題。于是想到了下列解決方法。

解決方法二：

因?yàn)榭紤]到在真實(shí)的網(wǎng)絡(luò)服務(wù)器上直接做調(diào)試和修改，可能會(huì)影響網(wǎng)絡(luò)的正常運(yùn)行。于是，先通過微軟的SCVM2007（虛擬化技術(shù)）中的P2V的技術(shù)，將真實(shí)的物理服務(wù)器全部虛擬成一臺(tái)臺(tái)虛擬的服務(wù)器，總共虛擬了8臺(tái)。然后在虛擬的網(wǎng)絡(luò)中做壓力測試。通過虛擬的網(wǎng)絡(luò)壓力測試之后，發(fā)現(xiàn)確實(shí)存在以上的問題。于是進(jìn)行方法三。

解決方法三：

1. 購置新的性能較高的IBM服務(wù)器2臺(tái)，在集團(tuán)里將原來的Windows Server 2003DNS集成活動(dòng)目錄升級為Windows Server 2008。

2. 將兩臺(tái)AD集成DNS服務(wù)的服務(wù)器通過Windows Server 的負(fù)載均衡功能建立起負(fù)載均衡服務(wù)器。使兩臺(tái)DNS不要像以前手工指定客戶機(jī)的DNS服務(wù)器到某個(gè)服務(wù)器，而是直接讓服務(wù)器自己進(jìn)行負(fù)載。

實(shí)施方法二已經(jīng)兩個(gè)月了，兩臺(tái)DNS服務(wù)器都工作正常。至此問題才得到完全解決。

總結(jié)：

1. DNS服務(wù)器越來越重要，負(fù)載也越來越大，但是我們往往因?yàn)榭紤]到DNS僅僅是進(jìn)行名稱解析，工作壓力不大而忽視了DNS服務(wù)器的負(fù)載問題。

2. 盡量使用最近的Windows Server網(wǎng)絡(luò)操作系統(tǒng)，性能和處理能力都得到改善。

3. 在網(wǎng)絡(luò)故障時(shí)，盡量先對網(wǎng)絡(luò)環(huán)境進(jìn)行模擬，不要直接在真實(shí)服務(wù)器上修改，避免服務(wù)器故障進(jìn)一步擴(kuò)大。盡可能使用虛擬環(huán)境。

4. 遇到問題應(yīng)該仔細(xì)分析，小心求證。本著先軟后硬的原則。問題會(huì)得到圓滿的解決。

關(guān)于怎樣解決奇怪DNS故障問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。