奇怪DNS故障之終極解決
DNS 命名通過用戶的友好名稱查找計算機和服務(wù)。當用戶在應(yīng)用程序中輸入 DNS 名稱時，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故障。為了解決這個故障，前后經(jīng)過多次的折騰，***終于“制服”這臺不“聽話”的DNS服務(wù)器。
為了表述方便以及從保密與安全角度考慮，筆者隱去了該企業(yè)的真名，稱為某集團。
我們先來看看該集團的網(wǎng)絡(luò)情況
網(wǎng)絡(luò)現(xiàn)狀
服務(wù)器現(xiàn)狀：
1、兩臺DC服務(wù)器集成DNS服務(wù)，其中一臺IP為10.10.1.5的DNS服務(wù)器作為主DNS服務(wù)器，負荷量比較大。而另一臺10.10.1.9的負荷量較小。
2、一臺OA服務(wù)器，OA服務(wù)器上安裝了有第三方公司開發(fā)的OA系統(tǒng)。操作系統(tǒng)是Windows Server 2003，使用IIS6的發(fā)布功能，將OA的系統(tǒng)發(fā)布成WEB方式。
3、一臺Exchange Server服務(wù)器，主要提供OA辦公系統(tǒng)的郵件服務(wù)。
4、一臺Web 服務(wù)器，該服務(wù)器主要提供公司內(nèi)部的WWW訪問
5、一臺OA SQL 服務(wù)器，該服務(wù)器主要是為辦公系統(tǒng)OA提供后臺數(shù)據(jù)庫支持。
6、一臺Web SQL服務(wù)器，該服務(wù)器主要作為WEB Server的后臺服務(wù)器
7、ERP服務(wù)器等，該服務(wù)器與本案無關(guān)，不予考慮。
網(wǎng)絡(luò)接入設(shè)備
1、接入層均采用Cisco交換機。
2、核心層采用Cisco核心路由器
3、各設(shè)備之間均采用超五類非屏蔽雙絞線。
4、企業(yè)網(wǎng)與公網(wǎng)之間采用飛塔防火墻做NET轉(zhuǎn)換。
網(wǎng)絡(luò)拓撲圖
網(wǎng)絡(luò)拓撲圖（部分）
網(wǎng)絡(luò)故障描述
本地DNS服務(wù)器DNS01.contoso.net，該DNS服務(wù)器是臺DC（活動目錄集成DNS）。以前從中國移動接入互聯(lián)網(wǎng)，后來因為移動DNS服務(wù)器出現(xiàn)一次問題，本地的這臺DNS服務(wù)器出現(xiàn)無法解析外部地址的情況。后改為中國電信的DNS解析，依然無法很好的進行外部網(wǎng)站解析，具體問題表現(xiàn)為：
1、在服務(wù)器上使用nslookup解析內(nèi)部地址，正反向都通過，無問題。（DNS本身的簡單查詢和遞歸查詢測試也通過）
2、（在服務(wù)器上）解析外部網(wǎng)站地址，有些地址能解析，有些地址不能解析，不能解析的地址反復(fù)試好多次（多達14次）才能解析成功。問題關(guān)鍵就是這里：時而能解析到，時而解析不到。
3、（客戶端上）不能解析外部地址，IE打開那些不能解析到的網(wǎng)站就會打不開（服務(wù)器解析不到當然打不開）?？蛻舳诵枰啻嗡⑿马撁?。
排錯一：
首先：檢查了該服務(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ù)器的作為客戶機的身份的緩存清除一下。然后使用DNSCMD /clearcache命令清除了該DNS服務(wù)器本身的緩存。命令不行，就用DNS控制臺里的清除緩存，重新加載等辦法，甚至重啟服務(wù)器。結(jié)果，發(fā)現(xiàn)問題依舊。DNS日志里也沒有發(fā)現(xiàn)與外部服務(wù)器解析相關(guān)的記錄。此時同時想到了DNS緩存是不是中毒了，于是通過命令，逐條檢查緩存中的緩存記錄。發(fā)現(xiàn)緩存記錄都是正常的，并為出現(xiàn)病毒的跡象，故此排除緩存病毒問題。
第三：發(fā)現(xiàn)服務(wù)器網(wǎng)卡是千兆自適應(yīng)網(wǎng)卡，交換機也是千兆的自適應(yīng)口，而網(wǎng)線使用的是超五類的線，懷疑：兩個千兆自適應(yīng)口因為通過100M的超五類非屏蔽線時，總把超五類的線當成1000M使用，由此引發(fā)雙方通過網(wǎng)卡超頻這段超五類的非屏蔽網(wǎng)線（因為手頭一時沒有六類線），就在服務(wù)器上和交換機上都將網(wǎng)卡速度降為100M。發(fā)現(xiàn)問題依舊。
第四：又懷疑是網(wǎng)絡(luò)延遲造成。于是使用nslookup命令中的set timeout=5的方式增加了nslookup的查詢的響應(yīng)時間。結(jié)果發(fā)現(xiàn)查詢結(jié)果又是5秒超時（nslookup程序默認是2秒超時）。于是我又把時間加到10秒，又出現(xiàn)10秒超時。就是說問題根本使用增加查詢時間，都是超時。
結(jié)論：可能是網(wǎng)絡(luò)中存在導(dǎo)致DNS查詢超時的因素?？赡苁蔷W(wǎng)絡(luò)硬件引起。
排錯二：
從DNS查詢癥狀上判斷，有可能是網(wǎng)絡(luò)延遲造成的，考慮到這里，有三個原因會造成延遲：
其一是網(wǎng)絡(luò)中服務(wù)器與核心交換機之間的接口均為1000M接口，而連接線纜采用的是超五類非屏蔽雙絞線，于是，專門購買了一根7米的六類雙絞線，更換原來的超五類非屏蔽線，更換之后，發(fā)現(xiàn)變化不大。由此排除因為網(wǎng)線超頻導(dǎo)致的DNS查詢延遲問題。
其二是因為網(wǎng)絡(luò)中存在大量的廣播包，導(dǎo)致數(shù)據(jù)碰撞幾率增加。而網(wǎng)絡(luò)中的大量廣播包一般是交換機或路由器的問題所致。就再檢查交換機或路由器的配置，發(fā)現(xiàn)路由器上采用了熱備的方式將兩臺Cisco路由器連接。并且網(wǎng)線位置與熱備位置不對應(yīng)。懷疑是網(wǎng)線的位置引起，后來在下班之后，將網(wǎng)線的位置復(fù)位為原來初始化的位置，發(fā)現(xiàn)DNS查詢稍微有改善。但解析失敗依然存在。由此排除因為網(wǎng)線和交換機的配置問題引發(fā)。
其三，考慮到防火墻上的端口是否正常開啟了DNS服務(wù)需要的UDP53和TCP53端口，因為只開啟一個TCP或者UDP的端口，也會出現(xiàn)DNS查詢延遲故障。于是檢查防火墻配置，發(fā)現(xiàn)防火墻上正確的開啟了相對應(yīng)的端口。那么排除防火墻的設(shè)置故障。
結(jié)論：排除路由器與交換機和防火墻的硬件的故障和設(shè)置故障。
思考：通過數(shù)據(jù)包的查詢的流向開分析查詢失敗的故障
排錯三
首先從服務(wù)器上收集了服務(wù)器的配置狀況MPS報告（MPSRPT_NETWORK, MPS report下載地址http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en），檢查了MPS報告里的各類日志文件，DCDIAG沒有任何報錯。再檢查DNS服務(wù)器日志，在***的DNS服務(wù)器日志里，我確實發(fā)現(xiàn)了很多警告和錯誤日志，但是經(jīng)過仔細研究，認為它們跟本問題不相干（自2010以來，類似的錯誤警告就很少報告）。此外，考慮到這個是外部網(wǎng)址的解析問題，內(nèi)部沒問題，所以可以忽略這些錯誤跟警告日志。從其他的日志里，也沒有發(fā)現(xiàn)跟這個問題可能相關(guān)的錯誤。
鑒于以上方案都無法奏效，就從服務(wù)器和客戶機進行4次抓包，通過抓包分析故障原因。
從客戶機抓包來看，使用電信服務(wù)器61.134.1.4直接進行地址解析，而且發(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)任何的錯誤。
但是，當將客戶機的DNS指定為內(nèi)部服務(wù)器10.10.1.5時，發(fā)現(xiàn)當您在解析www.tudou.com，www.chinaren.com，www.sohu.com等網(wǎng)站時就出現(xiàn)超時。嘗試去通過以下步驟去比對哪一環(huán)節(jié)造成延遲：
步驟1：
在客戶機10.20.2.5抓包中，找一個DNS請求，比如說解析www.sohu.com不成功，這個請求的發(fā)送時間是Jan 13, 2010 12:23:52.823093000
然后在相同的抓包里看到來自DNS服務(wù)器10.10.1.5，結(jié)果是解析失敗，錯誤代碼是Server failure (2)，這個回復(fù)的接收時間是Jan 13, 2010 12:24:03.790867000中間的間隔大概是10秒。
步驟2：
在DNS服務(wù)器10.10.1.5的抓包中，我嘗試尋找這個對應(yīng)的來自于10.20.2.5的DNS請求，看DNS服務(wù)器是如何將這個DNS請求轉(zhuǎn)發(fā)到電信服務(wù)器61.134.1.4。但是在2010 12:23:52.823093000和2010 12:24:03.790867000這個時間段里，我沒有看到自客戶機10.20.2.5發(fā)來的包含www.sohu.com的DNS請求。與這個時間段接近的這么一個DNS請求是發(fā)生在Jan 13, 2010 12:23:47.056713000。這一點，我覺得很奇怪，我重新檢查了其他失敗的請求，也發(fā)現(xiàn)了類似的問題。所以我懷疑，DNS服務(wù)器和這個客戶機的系統(tǒng)時間沒有同步。
此外，我發(fā)現(xiàn)這臺服務(wù)器單位時間的負載非常大，也有可能是因為這臺DNS服務(wù)器過忙而導(dǎo)致無法及時響應(yīng)某些來自客戶機的地址解析請求。
然后我又檢查了剛剛抓過來的***一次抓包和nslookup的調(diào)試日志，我發(fā)現(xiàn)直接使用電信DNS服務(wù)器時，都能正常解析。但當把DNS服務(wù)器修改為內(nèi)部服務(wù)器10.10.1.5時，就發(fā)現(xiàn)很多的超時了。然后我又檢查了抓包，同樣比較客戶機抓包和服務(wù)器抓包，可以發(fā)現(xiàn)兩者之間有比較明顯的時間差。次外，還有以下發(fā)現(xiàn)：
步驟1：
在客戶機抓包中，我找到一個解析www.sina.com失敗的DNS請求，客戶機發(fā)送的時間是Jan 13, 2010 14:34:16.876351000
然后檢查相同抓包，來自DNS服務(wù)器的回復(fù)是Jan 13, 2010 14:34:21.175179000，結(jié)果是解析失敗，錯誤代碼還是Server failure (2)。這里請求和回復(fù)之間的間隔是5秒鐘，這正是DNS服務(wù)器默認的超時間隔。
步驟2
在服務(wù)器抓包中，同樣相同的來自客戶機10.20.2.5的包含www.sina.com的DNS請求包到達內(nèi)部DNS服務(wù)器10.10.1.5的時間是Jan 13, 2010 14:34:15.041088000，與客戶端那邊還是有大概1秒的時間差。然后內(nèi)部DNS服務(wù)器將這個DNS請求轉(zhuǎn)到電信服務(wù)器61.134.1.4的時間是Jan 13, 2010 14:34:15.041088000。但是，自此之后，內(nèi)部服務(wù)器就再沒從電信服務(wù)器上收到關(guān)于這個請求的回復(fù)包了。
所以，從這里的結(jié)果來看，電信服務(wù)器沒有及時響應(yīng)也是造成解析無法成功的原因之一。
通過以上分析，我有以下懷疑：
1. 確保域內(nèi)客戶機和DNS服務(wù)器時間軸保持同步
2. 檢查電信DNS服務(wù)器61.134.1.4有時候未能及時響應(yīng)，原因也可能是過于繁忙。檢查從電信到公司網(wǎng)絡(luò)的鏈路情況。
3. 增加額外的DNS服務(wù)器來進行DNS負載均衡，做成負載均衡方式。
解決方法一：
檢查了網(wǎng)絡(luò)中的客戶機的時間配置，發(fā)現(xiàn)所有客戶機的時間軸都是同步的，并不存在時間差問題。所以懷疑一被排除。
請來電信的工程師以及我們?nèi)ル娦殴緦﹄娦诺腄NS服務(wù)器進行檢查。發(fā)現(xiàn)電信的DNS服務(wù)居然沒有問題。而且電信到該集團的光纜通信也是正常的，并沒有延遲和故障點，逐排除電信DNS問題。
這時，發(fā)現(xiàn)已經(jīng)只有一種情況，就是負載過大成為故障引發(fā)原因。于是在該集團內(nèi)部的DNS服務(wù)器做了調(diào)整，把***的子機場（該集團的一個子單位）的流量全部指向正常的DNS服務(wù)器（192.168.1.9），問題果然解決。
但是正當我們準備舉杯歡慶的時候，問題又出現(xiàn)了。正常的DNS服務(wù)器（192.168.1.9）在正常工作了一個周之后又發(fā)生了與之前***臺DNS相同的故障表現(xiàn)。于是，再次對曾經(jīng)正常的DNS服務(wù)器（192.168.1.9）進行抓包，發(fā)現(xiàn)：這臺DNS服務(wù)器又出現(xiàn)了跟之前那個DNS服務(wù)器相同的問題。就是單位時間內(nèi)DNS服務(wù)器收到數(shù)量巨大的查詢包，而某些數(shù)據(jù)包無法及時的轉(zhuǎn)發(fā)成功。考慮到兩臺DNS服務(wù)器在大的流量增加時都會出現(xiàn)相同的問題，立即就考慮是不是服務(wù)器性能以及流量的問題。于是檢查兩臺DNS服務(wù)器，發(fā)現(xiàn)兩臺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ā)性能上的改進，都會大大增加DNS的轉(zhuǎn)發(fā)效率。并且考慮到該集團還有Wins服務(wù)器，可以通過Windows Server2008DNS中的GlobalNames區(qū)域功能，可以將原來的Wins與DNS服務(wù)器合并，解決單標簽訪問問題。于是想到了下列解決方法。
解決方法二：
因為考慮到在真實的網(wǎng)絡(luò)服務(wù)器上直接做調(diào)試和修改，可能會影響網(wǎng)絡(luò)的正常運行。于是，先通過微軟的SCVM2007（虛擬化技術(shù)）中的P2V的技術(shù)，將真實的物理服務(wù)器全部虛擬成一臺臺虛擬的服務(wù)器，總共虛擬了8臺。然后在虛擬的網(wǎng)絡(luò)中做壓力測試。通過虛擬的網(wǎng)絡(luò)壓力測試之后，發(fā)現(xiàn)確實存在以上的問題。于是進行方法三。
解決方法三：
1. 購置新的性能較高的IBM服務(wù)器2臺，在集團里將原來的Windows Server 2003DNS集成活動目錄升級為Windows Server 2008。
2. 將兩臺AD集成DNS服務(wù)的服務(wù)器通過Windows Server 的負載均衡功能建立起負載均衡服務(wù)器。使兩臺DNS不要像以前手工指定客戶機的DNS服務(wù)器到某個服務(wù)器，而是直接讓服務(wù)器自己進行負載。
實施方法二已經(jīng)兩個月了，兩臺DNS服務(wù)器都工作正常。至此問題才得到完全解決。
總結(jié)：
1. DNS服務(wù)器越來越重要，負載也越來越大，但是我們往往因為考慮到DNS僅僅是進行名稱解析，工作壓力不大而忽視了DNS服務(wù)器的負載問題。
2. 盡量使用最近的Windows Server網(wǎng)絡(luò)操作系統(tǒng)，性能和處理能力都得到改善。
3. 在網(wǎng)絡(luò)故障時，盡量先對網(wǎng)絡(luò)環(huán)境進行模擬，不要直接在真實服務(wù)器上修改，避免服務(wù)器故障進一步擴大。盡可能使用虛擬環(huán)境。
4. 遇到問題應(yīng)該仔細分析，小心求證。本著先軟后硬的原則。問題會得到圓滿的解決。
奇怪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ò)中命名計算機和網(wǎng)絡(luò)服務(wù)的系統(tǒng)，該系統(tǒng)將這些計算機和網(wǎng)絡(luò)服務(wù)組織到域的層次結(jié)構(gòu)中。DNS 命名通過用戶的友好名稱查找計算機和服務(wù)。當用戶在應(yīng)用程序中輸入 DNS 名稱時，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故障。為了解決這個故障，前后經(jīng)過多次的折騰，***終于“制服”這臺不“聽話”的DNS服務(wù)器。
為了表述方便以及從保密與安全角度考慮，筆者隱去了該企業(yè)的真名，稱為某集團。
我們先來看看該集團的網(wǎng)絡(luò)情況
網(wǎng)絡(luò)現(xiàn)狀
服務(wù)器現(xiàn)狀：
1、兩臺DC服務(wù)器集成DNS服務(wù)，其中一臺IP為10.10.1.5的DNS服務(wù)器作為主DNS服務(wù)器，負荷量比較大。而另一臺10.10.1.9的負荷量較小。
2、一臺OA服務(wù)器，OA服務(wù)器上安裝了有第三方公司開發(fā)的OA系統(tǒng)。操作系統(tǒng)是Windows Server 2003，使用IIS6的發(fā)布功能，將OA的系統(tǒng)發(fā)布成WEB方式。
3、一臺Exchange Server服務(wù)器，主要提供OA辦公系統(tǒng)的郵件服務(wù)。
4、一臺Web 服務(wù)器，該服務(wù)器主要提供公司內(nèi)部的WWW訪問
5、一臺OA SQL 服務(wù)器，該服務(wù)器主要是為辦公系統(tǒng)OA提供后臺數(shù)據(jù)庫支持。
6、一臺Web SQL服務(wù)器，該服務(wù)器主要作為WEB Server的后臺服務(wù)器
7、ERP服務(wù)器等，該服務(wù)器與本案無關(guān)，不予考慮。
網(wǎng)絡(luò)接入設(shè)備
1、接入層均采用Cisco交換機。
2、核心層采用Cisco核心路由器
3、各設(shè)備之間均采用超五類非屏蔽雙絞線。
4、企業(yè)網(wǎng)與公網(wǎng)之間采用飛塔防火墻做NET轉(zhuǎn)換。
網(wǎng)絡(luò)拓撲圖
網(wǎng)絡(luò)拓撲圖（部分）#p#
網(wǎng)絡(luò)故障描述
本地DNS服務(wù)器DNS01.contoso.net，該DNS服務(wù)器是臺DC（活動目錄集成DNS）。以前從中國移動接入互聯(lián)網(wǎng)，后來因為移動DNS服務(wù)器出現(xiàn)一次問題，本地的這臺DNS服務(wù)器出現(xiàn)無法解析外部地址的情況。后改為中國電信的DNS解析，依然無法很好的進行外部網(wǎng)站解析，具體問題表現(xiàn)為：
1、在服務(wù)器上使用nslookup解析內(nèi)部地址，正反向都通過，無問題。（DNS本身的簡單查詢和遞歸查詢測試也通過）
2、（在服務(wù)器上）解析外部網(wǎng)站地址，有些地址能解析，有些地址不能解析，不能解析的地址反復(fù)試好多次（多達14次）才能解析成功。問題關(guān)鍵就是這里：時而能解析到，時而解析不到。
3、（客戶端上）不能解析外部地址，IE打開那些不能解析到的網(wǎng)站就會打不開（服務(wù)器解析不到當然打不開）?？蛻舳诵枰啻嗡⑿马撁妗?/p>
排錯一：
首先：檢查了該服務(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ù)器的作為客戶機的身份的緩存清除一下。然后使用DNSCMD /clearcache命令清除了該DNS服務(wù)器本身的緩存。命令不行，就用DNS控制臺里的清除緩存，重新加載等辦法，甚至重啟服務(wù)器。結(jié)果，發(fā)現(xiàn)問題依舊。DNS日志里也沒有發(fā)現(xiàn)與外部服務(wù)器解析相關(guān)的記錄。此時同時想到了DNS緩存是不是中毒了，于是通過命令，逐條檢查緩存中的緩存記錄。發(fā)現(xiàn)緩存記錄都是正常的，并為出現(xiàn)病毒的跡象，故此排除緩存病毒問題。
第三：發(fā)現(xiàn)服務(wù)器網(wǎng)卡是千兆自適應(yīng)網(wǎng)卡，交換機也是千兆的自適應(yīng)口，而網(wǎng)線使用的是超五類的線，懷疑：兩個千兆自適應(yīng)口因為通過100M的超五類非屏蔽線時，總把超五類的線當成1000M使用，由此引發(fā)雙方通過網(wǎng)卡超頻這段超五類的非屏蔽網(wǎng)線（因為手頭一時沒有六類線），就在服務(wù)器上和交換機上都將網(wǎng)卡速度降為100M。發(fā)現(xiàn)問題依舊。
第四：又懷疑是網(wǎng)絡(luò)延遲造成。于是使用nslookup命令中的set timeout=5的方式增加了nslookup的查詢的響應(yīng)時間。結(jié)果發(fā)現(xiàn)查詢結(jié)果又是5秒超時（nslookup程序默認是2秒超時）。于是我又把時間加到10秒，又出現(xiàn)10秒超時。就是說問題根本使用增加查詢時間，都是超時。
結(jié)論：可能是網(wǎng)絡(luò)中存在導(dǎo)致DNS查詢超時的因素?？赡苁蔷W(wǎng)絡(luò)硬件引起。
排錯二：
從DNS查詢癥狀上判斷，有可能是網(wǎng)絡(luò)延遲造成的，考慮到這里，有三個原因會造成延遲：
其一是網(wǎng)絡(luò)中服務(wù)器與核心交換機之間的接口均為1000M接口，而連接線纜采用的是超五類非屏蔽雙絞線，于是，專門購買了一根7米的六類雙絞線，更換原來的超五類非屏蔽線，更換之后，發(fā)現(xiàn)變化不大。由此排除因為網(wǎng)線超頻導(dǎo)致的DNS查詢延遲問題。
其二是因為網(wǎng)絡(luò)中存在大量的廣播包，導(dǎo)致數(shù)據(jù)碰撞幾率增加。而網(wǎng)絡(luò)中的大量廣播包一般是交換機或路由器的問題所致。就再檢查交換機或路由器的配置，發(fā)現(xiàn)路由器上采用了熱備的方式將兩臺Cisco路由器連接。并且網(wǎng)線位置與熱備位置不對應(yīng)。懷疑是網(wǎng)線的位置引起，后來在下班之后，將網(wǎng)線的位置復(fù)位為原來初始化的位置，發(fā)現(xiàn)DNS查詢稍微有改善。但解析失敗依然存在。由此排除因為網(wǎng)線和交換機的配置問題引發(fā)。
其三，考慮到防火墻上的端口是否正常開啟了DNS服務(wù)需要的UDP53和TCP53端口，因為只開啟一個TCP或者UDP的端口，也會出現(xiàn)DNS查詢延遲故障。于是檢查防火墻配置，發(fā)現(xiàn)防火墻上正確的開啟了相對應(yīng)的端口。那么排除防火墻的設(shè)置故障。
結(jié)論：排除路由器與交換機和防火墻的硬件的故障和設(shè)置故障。
思考：通過數(shù)據(jù)包的查詢的流向開分析查詢失敗的故障
排錯三
首先從服務(wù)器上收集了服務(wù)器的配置狀況MPS報告（MPSRPT_NETWORK, MPS report下載地址http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en），檢查了MPS報告里的各類日志文件，DCDIAG沒有任何報錯。再檢查DNS服務(wù)器日志，在***的DNS服務(wù)器日志里，我確實發(fā)現(xiàn)了很多警告和錯誤日志，但是經(jīng)過仔細研究，認為它們跟本問題不相干（自2010以來，類似的錯誤警告就很少報告）。此外，考慮到這個是外部網(wǎng)址的解析問題，內(nèi)部沒問題，所以可以忽略這些錯誤跟警告日志。從其他的日志里，也沒有發(fā)現(xiàn)跟這個問題可能相關(guān)的錯誤。
鑒于以上方案都無法奏效，就從服務(wù)器和客戶機進行4次抓包，通過抓包分析故障原因。
從客戶機抓包來看，使用電信服務(wù)器61.134.1.4直接進行地址解析，而且發(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)任何的錯誤。
但是，當將客戶機的DNS指定為內(nèi)部服務(wù)器10.10.1.5時，發(fā)現(xiàn)當您在解析www.tudou.com，www.chinaren.com，www.sohu.com等網(wǎng)站時就出現(xiàn)超時。嘗試去通過以下步驟去比對哪一環(huán)節(jié)造成延遲：
步驟1：
在客戶機10.20.2.5抓包中，找一個DNS請求，比如說解析www.sohu.com不成功，這個請求的發(fā)送時間是Jan 13, 2010 12:23:52.823093000
然后在相同的抓包里看到來自DNS服務(wù)器10.10.1.5，結(jié)果是解析失敗，錯誤代碼是Server failure (2)，這個回復(fù)的接收時間是Jan 13, 2010 12:24:03.790867000中間的間隔大概是10秒。
步驟2：
在DNS服務(wù)器10.10.1.5的抓包中，我嘗試尋找這個對應(yīng)的來自于10.20.2.5的DNS請求，看DNS服務(wù)器是如何將這個DNS請求轉(zhuǎn)發(fā)到電信服務(wù)器61.134.1.4。但是在2010 12:23:52.823093000和2010 12:24:03.790867000這個時間段里，我沒有看到自客戶機10.20.2.5發(fā)來的包含www.sohu.com的DNS請求。與這個時間段接近的這么一個DNS請求是發(fā)生在Jan 13, 2010 12:23:47.056713000。這一點，我覺得很奇怪，我重新檢查了其他失敗的請求，也發(fā)現(xiàn)了類似的問題。所以我懷疑，DNS服務(wù)器和這個客戶機的系統(tǒng)時間沒有同步。
此外，我發(fā)現(xiàn)這臺服務(wù)器單位時間的負載非常大，也有可能是因為這臺DNS服務(wù)器過忙而導(dǎo)致無法及時響應(yīng)某些來自客戶機的地址解析請求。
然后我又檢查了剛剛抓過來的***一次抓包和nslookup的調(diào)試日志，我發(fā)現(xiàn)直接使用電信DNS服務(wù)器時，都能正常解析。但當把DNS服務(wù)器修改為內(nèi)部服務(wù)器10.10.1.5時，就發(fā)現(xiàn)很多的超時了。然后我又檢查了抓包，同樣比較客戶機抓包和服務(wù)器抓包，可以發(fā)現(xiàn)兩者之間有比較明顯的時間差。次外，還有以下發(fā)現(xiàn)：
步驟1：
在客戶機抓包中，我找到一個解析www.sina.com失敗的DNS請求，客戶機發(fā)送的時間是Jan 13, 2010 14:34:16.876351000
然后檢查相同抓包，來自DNS服務(wù)器的回復(fù)是Jan 13, 2010 14:34:21.175179000，結(jié)果是解析失敗，錯誤代碼還是Server failure (2)。這里請求和回復(fù)之間的間隔是5秒鐘，這正是DNS服務(wù)器默認的超時間隔。
步驟2
在服務(wù)器抓包中，同樣相同的來自客戶機10.20.2.5的包含www.sina.com的DNS請求包到達內(nèi)部DNS服務(wù)器10.10.1.5的時間是Jan 13, 2010 14:34:15.041088000，與客戶端那邊還是有大概1秒的時間差。然后內(nèi)部DNS服務(wù)器將這個DNS請求轉(zhuǎn)到電信服務(wù)器61.134.1.4的時間是Jan 13, 2010 14:34:15.041088000。但是，自此之后，內(nèi)部服務(wù)器就再沒從電信服務(wù)器上收到關(guān)于這個請求的回復(fù)包了。
所以，從這里的結(jié)果來看，電信服務(wù)器沒有及時響應(yīng)也是造成解析無法成功的原因之一。
通過以上分析，我有以下懷疑：
1. 確保域內(nèi)客戶機和DNS服務(wù)器時間軸保持同步
2. 檢查電信DNS服務(wù)器61.134.1.4有時候未能及時響應(yīng)，原因也可能是過于繁忙。檢查從電信到公司網(wǎng)絡(luò)的鏈路情況。
3. 增加額外的DNS服務(wù)器來進行DNS負載均衡，做成負載均衡方式。
解決方法一：
檢查了網(wǎng)絡(luò)中的客戶機的時間配置，發(fā)現(xiàn)所有客戶機的時間軸都是同步的，并不存在時間差問題。所以懷疑一被排除。
請來電信的工程師以及我們?nèi)ル娦殴緦﹄娦诺腄NS服務(wù)器進行檢查。發(fā)現(xiàn)電信的DNS服務(wù)居然沒有問題。而且電信到該集團的光纜通信也是正常的，并沒有延遲和故障點，逐排除電信DNS問題。
這時，發(fā)現(xiàn)已經(jīng)只有一種情況，就是負載過大成為故障引發(fā)原因。于是在該集團內(nèi)部的DNS服務(wù)器做了調(diào)整，把***的子機場（該集團的一個子單位）的流量全部指向正常的DNS服務(wù)器（192.168.1.9），問題果然解決。
但是正當我們準備舉杯歡慶的時候，問題又出現(xiàn)了。正常的DNS服務(wù)器（192.168.1.9）在正常工作了一個周之后又發(fā)生了與之前***臺DNS相同的故障表現(xiàn)。于是，再次對曾經(jīng)正常的DNS服務(wù)器（192.168.1.9）進行抓包，發(fā)現(xiàn)：這臺DNS服務(wù)器又出現(xiàn)了跟之前那個DNS服務(wù)器相同的問題。就是單位時間內(nèi)DNS服務(wù)器收到數(shù)量巨大的查詢包，而某些數(shù)據(jù)包無法及時的轉(zhuǎn)發(fā)成功?？紤]到兩臺DNS服務(wù)器在大的流量增加時都會出現(xiàn)相同的問題，立即就考慮是不是服務(wù)器性能以及流量的問題。于是檢查兩臺DNS服務(wù)器，發(fā)現(xiàn)兩臺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ā)性能上的改進，都會大大增加DNS的轉(zhuǎn)發(fā)效率。并且考慮到該集團還有Wins服務(wù)器，可以通過Windows Server2008DNS中的GlobalNames區(qū)域功能，可以將原來的Wins與DNS服務(wù)器合并，解決單標簽訪問問題。于是想到了下列解決方法。
解決方法二：
因為考慮到在真實的網(wǎng)絡(luò)服務(wù)器上直接做調(diào)試和修改，可能會影響網(wǎng)絡(luò)的正常運行。于是，先通過微軟的SCVM2007（虛擬化技術(shù)）中的P2V的技術(shù)，將真實的物理服務(wù)器全部虛擬成一臺臺虛擬的服務(wù)器，總共虛擬了8臺。然后在虛擬的網(wǎng)絡(luò)中做壓力測試。通過虛擬的網(wǎng)絡(luò)壓力測試之后，發(fā)現(xiàn)確實存在以上的問題。于是進行方法三。
解決方法三：
1. 購置新的性能較高的IBM服務(wù)器2臺，在集團里將原來的Windows Server 2003DNS集成活動目錄升級為Windows Server 2008。
2. 將兩臺AD集成DNS服務(wù)的服務(wù)器通過Windows Server 的負載均衡功能建立起負載均衡服務(wù)器。使兩臺DNS不要像以前手工指定客戶機的DNS服務(wù)器到某個服務(wù)器，而是直接讓服務(wù)器自己進行負載。
實施方法二已經(jīng)兩個月了，兩臺DNS服務(wù)器都工作正常。至此問題才得到完全解決。
總結(jié)：
1. DNS服務(wù)器越來越重要，負載也越來越大，但是我們往往因為考慮到DNS僅僅是進行名稱解析，工作壓力不大而忽視了DNS服務(wù)器的負載問題。
2. 盡量使用最近的Windows Server網(wǎng)絡(luò)操作系統(tǒng)，性能和處理能力都得到改善。
3. 在網(wǎng)絡(luò)故障時，盡量先對網(wǎng)絡(luò)環(huán)境進行模擬，不要直接在真實服務(wù)器上修改，避免服務(wù)器故障進一步擴大。盡可能使用虛擬環(huán)境。
4. 遇到問題應(yīng)該仔細分析，小心求證。本著先軟后硬的原則。問題會得到圓滿的解決。
【編輯推薦】
