網(wǎng)絡(luò)故障描述
本地DNS服務(wù)器DNS01.contoso.net，該DNS服務(wù)器是臺DC（活動目錄集成DNS）。以前從中國移動接入互聯(lián)網(wǎng)，后來因?yàn)橐苿覦NS服務(wù)器出現(xiàn)一次問題，本地的這臺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)鍵就是這里：時而能解析到，時而解析不到。
3、（客戶端上）不能解析外部地址，IE打開那些不能解析到的網(wǎng)站就會打不開（服務(wù)器解析不到當(dāng)然打不開）?？蛻舳诵枰啻嗡⑿马撁?。
排錯一：
首先：檢查了該服務(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控制臺里的清除緩存，重新加載等辦法，甚至重啟服務(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)卡，交換機(jī)也是千兆的自適應(yīng)口，而網(wǎng)線使用的是超五類的線，懷疑：兩個千兆自適應(yīng)口因?yàn)橥ㄟ^100M的超五類非屏蔽線時，總把超五類的線當(dāng)成1000M使用，由此引發(fā)雙方通過網(wǎng)卡超頻這段超五類的非屏蔽網(wǎng)線（因?yàn)槭诸^一時沒有六類線），就在服務(wù)器上和交換機(jī)上都將網(wǎng)卡速度降為100M。發(fā)現(xiàn)問題依舊。
第四：又懷疑是網(wǎng)絡(luò)延遲造成。于是使用nslookup命令中的set timeout=5的方式增加了nslookup的查詢的響應(yīng)時間。結(jié)果發(fā)現(xiàn)查詢結(jié)果又是5秒超時（nslookup程序默認(rèn)是2秒超時）。于是我又把時間加到10秒，又出現(xiàn)10秒超時。就是說問題根本使用增加查詢時間，都是超時。
結(jié)論：可能是網(wǎng)絡(luò)中存在導(dǎo)致DNS查詢超時的因素。可能是網(wǎng)絡(luò)硬件引起。
排錯二：
從DNS查詢癥狀上判斷，有可能是網(wǎng)絡(luò)延遲造成的，考慮到這里，有三個原因會造成延遲：
其一是網(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)路由器上采用了熱備的方式將兩臺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)橹婚_啟一個TCP或者UDP的端口，也會出現(xiàn)DNS查詢延遲故障。于是檢查防火墻配置，發(fā)現(xiàn)防火墻上正確的開啟了相對應(yīng)的端口。那么排除防火墻的設(shè)置故障。
結(jié)論：排除路由器與交換機(jī)和防火墻的硬件的故障和設(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ù)器日志里，我確實(shí)發(fā)現(xiàn)了很多警告和錯誤日志，但是經(jīng)過仔細(xì)研究，認(rèn)為它們跟本問題不相干（自2010以來，類似的錯誤警告就很少報告）。此外，考慮到這個是外部網(wǎng)址的解析問題，內(nèi)部沒問題，所以可以忽略這些錯誤跟警告日志。從其他的日志里，也沒有發(fā)現(xiàn)跟這個問題可能相關(guān)的錯誤。
鑒于以上方案都無法奏效，就從服務(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)任何的錯誤。
但是，當(dāng)將客戶機(jī)的DNS指定為內(nèi)部服務(wù)器10.10.1.5時，發(fā)現(xiàn)當(dāng)您在解析www.tudou.com，www.chinaren.com，www.sohu.com等網(wǎng)站時就出現(xiàn)超時。嘗試去通過以下步驟去比對哪一環(huán)節(jié)造成延遲：
步驟1：
在客戶機(jī)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這個時間段里，我沒有看到自客戶機(jī)10.20.2.5發(fā)來的包含www.sohu.com的DNS請求。與這個時間段接近的這么一個DNS請求是發(fā)生在Jan 13, 2010 12:23:47.056713000。這一點(diǎn)，我覺得很奇怪，我重新檢查了其他失敗的請求，也發(fā)現(xiàn)了類似的問題。所以我懷疑，DNS服務(wù)器和這個客戶機(jī)的系統(tǒng)時間沒有同步。
此外，我發(fā)現(xiàn)這臺服務(wù)器單位時間的負(fù)載非常大，也有可能是因?yàn)檫@臺DNS服務(wù)器過忙而導(dǎo)致無法及時響應(yīng)某些來自客戶機(jī)的地址解析請求。
然后我又檢查了剛剛抓過來的最后一次抓包和nslookup的調(diào)試日志，我發(fā)現(xiàn)直接使用電信DNS服務(wù)器時，都能正常解析。但當(dāng)把DNS服務(wù)器修改為內(nèi)部服務(wù)器10.10.1.5時，就發(fā)現(xiàn)很多的超時了。然后我又檢查了抓包，同樣比較客戶機(jī)抓包和服務(wù)器抓包，可以發(fā)現(xiàn)兩者之間有比較明顯的時間差。次外，還有以下發(fā)現(xiàn)：
步驟1：
在客戶機(jī)抓包中，我找到一個解析www.sina.com失敗的DNS請求，客戶機(jī)發(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ù)器默認(rèn)的超時間隔。
步驟2
在服務(wù)器抓包中，同樣相同的來自客戶機(jī)10.20.2.5的包含www.sina.com的DNS請求包到達(dá)內(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)客戶機(jī)和DNS服務(wù)器時間軸保持同步
2.檢查電信DNS服務(wù)器61.134.1.4有時候未能及時響應(yīng)，原因也可能是過于繁忙。檢查從電信到公司網(wǎng)絡(luò)的鏈路情況。
3.增加額外的DNS服務(wù)器來進(jìn)行DNS負(fù)載均衡，做成負(fù)載均衡方式。
解決方法一：
檢查了網(wǎng)絡(luò)中的客戶機(jī)的時間配置，發(fā)現(xiàn)所有客戶機(jī)的時間軸都是同步的，并不存在時間差問題。所以懷疑一被排除。
請來電信的工程師以及我們?nèi)ル娦殴緦﹄娦诺腄NS服務(wù)器進(jìn)行檢查。發(fā)現(xiàn)電信的DNS服務(wù)居然沒有問題。而且電信到該集團(tuán)的光纜通信也是正常的，并沒有延遲和故障點(diǎn)，逐排除電信DNS問題。
這時，發(fā)現(xiàn)已經(jīng)只有一種情況，就是負(fù)載過大成為故障引發(fā)原因。于是在該集團(tuán)內(nèi)部的DNS服務(wù)器做了調(diào)整，把最大的子機(jī)場（該集團(tuán)的一個子單位）的流量全部指向正常的DNS服務(wù)器（192.168.1.9），問題果然解決。
但是正當(dāng)我們準(zhǔn)備舉杯歡慶的時候，問題又出現(xiàn)了。正常的DNS服務(wù)器（192.168.1.9）在正常工作了一個周之后又發(fā)生了與之前第一臺DNS相同的故障表現(xiàn)。于是，再次對曾經(jīng)正常的DNS服務(wù)器（192.168.1.9）進(jìn)行抓包，發(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ā)性能上的改進(jìn)，都會大大增加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)試和修改，可能會影響網(wǎng)絡(luò)的正常運(yùn)行。于是，先通過微軟的SCVM2007（虛擬化技術(shù)）中的P2V的技術(shù)，將真實(shí)的物理服務(wù)器全部虛擬成一臺臺虛擬的服務(wù)器，總共虛擬了8臺。然后在虛擬的網(wǎng)絡(luò)中做壓力測試。通過虛擬的網(wǎng)絡(luò)壓力測試之后，發(fā)現(xiàn)確實(shí)存在以上的問題。于是進(jìn)行方法三。
解決方法三：
1.購置新的性能較高的IBM服務(wù)器2臺，在集團(tuán)里將原來的Windows Server 2003DNS集成活動目錄升級為Windows Server 2008。
2.將兩臺AD集成DNS服務(wù)的服務(wù)器通過Windows Server 的負(fù)載均衡功能建立起負(fù)載均衡服務(wù)器。使兩臺DNS不要像以前手工指定客戶機(jī)的DNS服務(wù)器到某個服務(wù)器，而是直接讓服務(wù)器自己進(jìn)行負(fù)載。
實(shí)施方法二已經(jīng)兩個月了，兩臺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ò)故障時，盡量先對網(wǎng)絡(luò)環(huán)境進(jìn)行模擬，不要直接在真實(shí)服務(wù)器上修改，避免服務(wù)器故障進(jìn)一步擴(kuò)大。盡可能使用虛擬環(huán)境。
4.遇到問題應(yīng)該仔細(xì)分析，小心求證。本著先軟后硬的原則。問題會得到圓滿的解決。
