怎樣解決奇怪DNS故障

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

DNS 命名通過用戶的友好名稱查找計算機和服務。當用戶在應用程序中輸入 DNS 名稱時，DNS 服務可以將此名稱解析為與此名稱相關的其他信息，如 IP 地址等。

DNS服務作為企業中非常重要的角色，承擔著企業的重要任務。越來越多的企業開始在自己的企業部署內部DNS服務器。但是，隨著網絡規模和網絡流量的增長，DNS也隨之出現了各種奇怪的故障。筆者之前就遇到一起奇怪的DNS故障。為了解決這個故障，前后經過多次的折騰，終于“制服”這臺不“聽話”的DNS服務器。

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

我們先來看看該集團的網絡情況

網絡現狀

服務器現狀：

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

2、一臺OA服務器，OA服務器上安裝了有第三方公司開發的OA系統。操作系統是Windows Server 2003，使用IIS6的發布功能，將OA的系統發布成WEB方式。

3、一臺Exchange Server服務器，主要提供OA辦公系統的郵件服務。

4、一臺Web 服務器，該服務器主要提供公司內部的WWW訪問

5、一臺OA SQL 服務器，該服務器主要是為辦公系統OA提供后臺數據庫支持。

6、一臺Web SQL服務器，該服務器主要作為WEB Server的后臺服務器

7、ERP服務器等，該服務器與本案無關，不予考慮。

網絡接入設備

1、接入層均采用Cisco交換機。

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

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

4、企業網與公網之間采用飛塔防火墻做NET轉換。

網絡拓撲圖

網絡拓撲圖（部分）

網絡故障描述

本地DNS服務器DNS01.contoso.net，該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命令中的set timeout=5的方式增加了nslookup的查詢的響應時間。結果發現查詢結果又是5秒超時（nslookup程序默認是2秒超時）。于是我又把時間加到10秒，又出現10秒超時。就是說問題根本使用增加查詢時間，都是超時。

結論：可能是網絡中存在導致DNS查詢超時的因素。可能是網絡硬件引起。

排錯二：

從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。但是，自此之后，內部服務器就再沒從電信服務器上收到關于這個請求的回復包了。

所以，從這里的結果來看，電信服務器沒有及時響應也是造成解析無法成功的原因之一。

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

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早期的服務器，性能并不高，內存也小，再加上安裝的Windows Server2003網絡操作系統，而Windows Server 2003操作系統DNS的處理轉發能力都不及Windows Server2008，尤其Windows Server 2008系統的 DNS功能在背景區域加載和DNS轉發性能上的改進，都會大大增加DNS的轉發效率。并且考慮到該集團還有Wins服務器，可以通過Windows Server2008DNS中的GlobalNames區域功能，可以將原來的Wins與DNS服務器合并，解決單標簽訪問問題。于是想到了下列解決方法。

解決方法二：

因為考慮到在真實的網絡服務器上直接做調試和修改，可能會影響網絡的正常運行。于是，先通過微軟的SCVM2007（虛擬化技術）中的P2V的技術，將真實的物理服務器全部虛擬成一臺臺虛擬的服務器，總共虛擬了8臺。然后在虛擬的網絡中做壓力測試。通過虛擬的網絡壓力測試之后，發現確實存在以上的問題。于是進行方法三。

解決方法三：

1. 購置新的性能較高的IBM服務器2臺，在集團里將原來的Windows Server 2003DNS集成活動目錄升級為Windows Server 2008。

2. 將兩臺AD集成DNS服務的服務器通過Windows Server 的負載均衡功能建立起負載均衡服務器。使兩臺DNS不要像以前手工指定客戶機的DNS服務器到某個服務器，而是直接讓服務器自己進行負載。

實施方法二已經兩個月了，兩臺DNS服務器都工作正常。至此問題才得到完全解決。

總結：

1. DNS服務器越來越重要，負載也越來越大，但是我們往往因為考慮到DNS僅僅是進行名稱解析，工作壓力不大而忽視了DNS服務器的負載問題。

2. 盡量使用最近的Windows Server網絡操作系統，性能和處理能力都得到改善。

3. 在網絡故障時，盡量先對網絡環境進行模擬，不要直接在真實服務器上修改，避免服務器故障進一步擴大。盡可能使用虛擬環境。

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

奇怪DNS故障之***解決

西北工業大學微軟高級技術培訓中心

講師：張馳 MCP ID：3098942

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

DNS服務作為企業中非常重要的角色，承擔著企業的重要任務。越來越多的企業開始在自己的企業部署內部DNS服務器。但是，隨著網絡規模和網絡流量的增長，DNS也隨之出現了各種奇怪的故障。筆者之前就遇到一起奇怪的DNS故障。為了解決這個故障，前后經過多次的折騰，***終于“制服”這臺不“聽話”的DNS服務器。

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

我們先來看看該集團的網絡情況

網絡現狀

服務器現狀：

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

2、一臺OA服務器，OA服務器上安裝了有第三方公司開發的OA系統。操作系統是Windows Server 2003，使用IIS6的發布功能，將OA的系統發布成WEB方式。

3、一臺Exchange Server服務器，主要提供OA辦公系統的郵件服務。

4、一臺Web 服務器，該服務器主要提供公司內部的WWW訪問

5、一臺OA SQL 服務器，該服務器主要是為辦公系統OA提供后臺數據庫支持。

6、一臺Web SQL服務器，該服務器主要作為WEB Server的后臺服務器

7、ERP服務器等，該服務器與本案無關，不予考慮。

網絡接入設備

1、接入層均采用Cisco交換機。

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

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

4、企業網與公網之間采用飛塔防火墻做NET轉換。

網絡拓撲圖

網絡拓撲圖（部分）

網絡故障描述

本地DNS服務器DNS01.contoso.net，該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命令中的set timeout=5的方式增加了nslookup的查詢的響應時間。結果發現查詢結果又是5秒超時（nslookup程序默認是2秒超時）。于是我又把時間加到10秒，又出現10秒超時。就是說問題根本使用增加查詢時間，都是超時。

結論：可能是網絡中存在導致DNS查詢超時的因素。可能是網絡硬件引起。

排錯二：

從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。但是，自此之后，內部服務器就再沒從電信服務器上收到關于這個請求的回復包了。

所以，從這里的結果來看，電信服務器沒有及時響應也是造成解析無法成功的原因之一。

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

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早期的服務器，性能并不高，內存也小，再加上安裝的Windows Server2003網絡操作系統，而Windows Server 2003操作系統DNS的處理轉發能力都不及Windows Server2008，尤其Windows Server 2008系統的 DNS功能在背景區域加載和DNS轉發性能上的改進，都會大大增加DNS的轉發效率。并且考慮到該集團還有Wins服務器，可以通過Windows Server2008DNS中的GlobalNames區域功能，可以將原來的Wins與DNS服務器合并，解決單標簽訪問問題。于是想到了下列解決方法。

解決方法二：

因為考慮到在真實的網絡服務器上直接做調試和修改，可能會影響網絡的正常運行。于是，先通過微軟的SCVM2007（虛擬化技術）中的P2V的技術，將真實的物理服務器全部虛擬成一臺臺虛擬的服務器，總共虛擬了8臺。然后在虛擬的網絡中做壓力測試。通過虛擬的網絡壓力測試之后，發現確實存在以上的問題。于是進行方法三。

解決方法三：

1. 購置新的性能較高的IBM服務器2臺，在集團里將原來的Windows Server 2003DNS集成活動目錄升級為Windows Server 2008。

2. 將兩臺AD集成DNS服務的服務器通過Windows Server 的負載均衡功能建立起負載均衡服務器。使兩臺DNS不要像以前手工指定客戶機的DNS服務器到某個服務器，而是直接讓服務器自己進行負載。

實施方法二已經兩個月了，兩臺DNS服務器都工作正常。至此問題才得到完全解決。

總結：

1. DNS服務器越來越重要，負載也越來越大，但是我們往往因為考慮到DNS僅僅是進行名稱解析，工作壓力不大而忽視了DNS服務器的負載問題。

2. 盡量使用最近的Windows Server網絡操作系統，性能和處理能力都得到改善。

3. 在網絡故障時，盡量先對網絡環境進行模擬，不要直接在真實服務器上修改，避免服務器故障進一步擴大。盡可能使用虛擬環境。

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

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