1、DNS 是域名系統(Domain Name System)的縮寫，最早于1983 年由保羅 ?莫卡派喬斯（ Paul Mockapetris ）發明。域名系統(DNS) 是用于在TCP/IP網絡中命名計算機和網絡服務的系統，該系統將這些計算機和網絡服務組織到域的層次結構中。DNS 命名通過用戶的友好名稱查找計算機和服務。當用戶在應用程序中輸入DNS 名稱時， DNS 服務可以將此名稱解析為與此名稱相關的其他信息，如IP 地址等。DNS 服務作為企業中非常重要的角色，承擔著企業的重要任務。越來越多的企業開始在自己的企業部署部DNS 服務器。但是，隨著網絡規模和網絡流量的增長，DNS 也隨之出現了

2、各種奇怪的故障。筆者之前就遇到一起奇怪的DNS 故障。為了解決這個故障，前后經過多次的折騰，最后終于“制服 ”這臺不 “聽話 ”的 DNS 服務器。為了表述方便以及從與安全角度考慮，筆者隱去了該企業的真名，稱為某集團。我們先來看看該集團的網絡情況網絡現狀服務器現狀：1、兩臺 DC 服務器集成 DNS 服務，其中一臺 IP 為的 DNS 服務器作為主 DNS 服務器，負荷量比較大。而另一臺的負荷量較小。2、一臺 OA 服務器， OA 服務器上安裝了有第三方公司開發的OA 系統。操作系統是 Windows Server 2003 ，使用 IIS6 的發布功能，將 OA 的系統發布成 WEB 方式。

3、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 服務器，該

4、DNS 服務器是臺 DC（活動目錄集成DNS ）。以前從中國移動接入互聯網，后來因為移動 DNS 服務器出現一次問題，本地的這臺 DNS 服務器出現無法解析外部地址的情況。后改為中國電信的 DNS 解析，依然無法很好的進行外部解析，具體問題表現為：1、在服務器上使用nslookup 解析部地址，正反向都通過，無問題。（ DNS 本身的簡單查詢和遞歸查詢測試也通過）2、（在服務器上）解析外部地址，有些地址能解析，有些地址不能解析，不能解析的地址反復試好多次（多達14 次）才能解析成功。問題關鍵就是這里：時而能解析到，時而解析不到。3、（客戶端上）不能解析外部地址，IE 打開那些不能解析到的就會打

5、不開（服務器解析不到當然打不開）。客戶端需要多次刷新頁面。排錯一：首先：檢查了該服務器的配置： ip 地址、掩碼、網關、 DNS （指自己）、在 DNS 轉發器上做了一條轉發，轉發到電信的 DNS 服務器上。這些都是正確配置。其次：懷疑是緩存的問題，就使用ipconfig /flushdns命令對該服務器的作為客戶機的身份的緩存清除一下。然后使用DNSCMD/clearcache 命令清除了該DNS 服務器本身的緩存。 命令不行，就用DNS 控制臺里的清除緩存，重新加載等辦法，甚至重啟服務器。結果，發現問題依舊。 DNS 日志里也沒有發現與外部服務器解析相關的記錄。此時同時想到了DNS 緩存是

6、不是中毒了，于是通過命令，逐條檢查緩存中的緩存記錄。發現緩存記錄都是正常的， 并為出現病毒的跡象，故此排除緩存病毒問題。第三：發現服務器網卡是千兆自適應網卡，交換機也是千兆的自適應口，而網線使用的是超五類的線，懷疑：兩個千兆自適應口因為通過 100M 的超五類非屏蔽線時， 總把超五類的線當成1000M 使用，由此引發雙方通過網卡超頻這段超五類的非屏蔽網線（因為手頭一時沒有六類線），就在服務器上和交換機上都將網卡速度降為100M 。發現問題依舊。第四：又懷疑是網絡延遲造成。于是使用nslookup 命令中的 settimeout=5 的方式增加了 nslookup 的查詢的響應時間。結果發現查詢

7、結果又是 5 秒超時（ nslookup 程序默認是 2 秒超時）。于是我又把時間加到 10 秒，又出現 10 秒超時。就是說問題根本使用增加查詢時間，都是超時。結論：可能是網絡中存在導致 DNS 查詢超時的因素。可能是網絡硬件引起。排錯二：從 DNS 查詢癥狀上判斷，有可能是網絡延遲造成的，考慮到這里，有三個原因會造成延遲：其一是網絡中服務器與核心交換機之間的接口均為1000M 接口，而連接線纜采用的是超五類非屏蔽雙絞線，于是，專門購買了一根 7 米的六類雙絞線，更換原來的超五類非屏蔽線，更換之后，發現變化不大。由此排除因為網線超頻導致的 DNS 查詢延遲問題。其二是因為網絡中存在大量的廣播

8、包，導致數據碰撞幾率增加。而網絡中的大量廣播包一般是交換機或路由器的問題所致。 就再檢查交換機或路由器的配置，發現路由器上采用了熱備的方式將兩臺 Cisco 路由器連接。并且網線位置與熱備位置不對應。懷疑是網線的位置引起，后來在下班之后，將網線的位置復位為原來初始化的位置，發現 DNS 查詢稍微有改善。但解析失敗依然存在。由此排除因為網線和交換機的配置問題引發。其三，考慮到防火墻上的端口是否正常開啟了DNS 服務需要的UDP53 和 TCP53 端口，因為只開啟一個TCP 或者 UDP 的端口，也會出現 DNS 查詢延遲故障。于是檢查防火墻配置，發現防火墻上正確的開啟了相對應的端口。那么排除防

9、火墻的設置故障。結論：排除路由器與交換機和防火墻的硬件的故障和設置故障。思考：通過數據包的查詢的流向開分析查詢失敗的故障排錯三：首先從服務器上收集了服務器的配置狀況MPS 報告（MPSRPT_NETWORK, MPS report下載地址.microsoft./downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en），檢查了 MPS 報告里的各類日志文件， DCDIAG 沒有任何報錯。再檢查DNS 服務器日志，在最新的 DNS 服務器日志里，我確實發現了很多警告和錯誤日志，但

10、是經過仔細研究，認為它們跟本問題不相干（自2010 以來，類似的錯誤警告就很少報告）。此外，考慮到這個是外部網址的解析問題，部沒問題，所以可以忽略這些錯誤跟警告日志。從其他的日志里，也沒有發現跟這個問題可能相關的錯誤。鑒于以上方案都無法奏效，就從服務器和客戶機進行4 次抓包，通過抓包分析故障原因。從客戶機抓包來看， 使用電信服務器直接進行地址解析，而且發現解析全部成功，包括.sina. ，.sohu. ，.google. ，.tudou. ，.xiaoli.cc ，.hao123. ，.chinaren. ，沒有發現任何的錯誤。但是，當將客戶機的 DNS 指定為部服務器時，發現當您在解析 .t

11、udou. ，.chinaren. ，.sohu. 等時就出現超時。嘗試去通過以下步驟去比對哪一環節造成延遲：步驟 1：在客戶機抓包中，找一個 DNS 請求，比如說解析 .sohu. 不成功，這個請求的發送時間是 Jan 13, 2010 12:23:52.823093000然后在相同的抓包里看到來自DNS 服務器，結果是解析失敗，錯誤代碼是 Server failure (2) ，這個回復的接收時間是Jan 13,2010 12:24:03.790867000中間的間隔大概是10 秒。步驟 2：在 DNS 服務器的抓包中，我嘗試尋找這個對應的來自于的 DNS 請求，看 DNS 服務器是如何將

12、這個 DNS 請求轉發到電信服務器。但是在 2010 12:23:52.823093000和 2010 12:24:03.790867000 這個時間段里，我沒有看到自客戶機發來的包含 .sohu. 的 DNS 請求。與這個時間段接近的這么一個 DNS 請發生在 Jan 13, 2010 12:23:47.056713000。這一點，我覺得很奇怪，我重新檢查了其他失敗的請求，也發現了類似的問題。所以我懷疑， DNS 服務器和這個客戶機的系統時間沒有同步。此外，我發現這臺服務器單位時間的負載非常大，也有可能是因為這臺 DNS 服務器過忙而導致無法及時響應某些來自客戶機的地址解析請求。然后我又檢查

13、了剛剛抓過來的最后一次抓包和 nslookup 的調試日志，我發現直接使用電信 DNS 服務器時，都能正常解析。但當把 DNS 服務器修改為部服務器時，就發現很多的超時了。 然后我又檢查了抓包， 同樣比較客戶機抓包和服務器抓包， 可以發現兩者之間有比較明顯的時間差。次外，還有以下發現：步驟 1：在客戶機抓包中，我找到一個解析 .sina. 失敗的 DNS 請求，客戶機發送的時間是 Jan 13, 2010 14:34:16.876351000然后檢查相同抓包，來自 DNS 服務器的回復是 Jan 13, 2010 14:34:21.175179000 ，結果是解析失敗，錯誤代碼還是 Serve

14、r failure(2)。這里請求和回復之間的間隔是5 秒鐘，這正是 DNS 服務器默認的超時間隔。步驟 2在服務器抓包中，同樣相同的來自客戶機的包含 .sina.的 DNS 請求包到達部 DNS 服務器的時間是 Jan 13, 2010 14:34:15.041088000 ，與客戶端那邊還是有大概 1 秒的時間差。然后部 DNS 服務器將這個 DNS 請求轉到電信服務器的時間是 Jan 13, 2010 14:34:15.041088000 。但是，自此之后，部服務器就再沒從電信服務器上收到關于這個請求的回復包了。所以，從這里的結果來看，電信服務器沒有及時響應也是造成解析無法成功的原因之一

15、。通過以上分析，我有以下懷疑：1.確保域客戶機和DNS 服務器時間軸保持同步2.檢查電信 DNS 服務器有時候未能及時響應，原因也可能是過于繁忙。檢查從電信到公司網絡的鏈路情況。3.增加額外的 DNS 服務器來進行 DNS 負載均衡，做成負載均衡方式。解決方法一：檢查了網絡中的客戶機的時間配置，發現所有客戶機的時間軸都是同步的，并不存在時間差問題。所以懷疑一被排除。請來電信的工程師以及我們去電信公司對電信的DNS 服務器進行檢查。發現電信的DNS 服務居然沒有問題。而且電信到該集團的光纜通信也是正常的， 并沒有延遲和故障點， 逐排除電信 DNS 問題。這時，發現已經只有一種情況， 就是負載過大

16、成為故障引發原因。于是在該集團部的 DNS 服務器做了調整，把最大的子機場（該集團的一個子單位） 的流量全部指向正常的 DNS 服務器（），問題果然解決。但是正當我們準備舉杯歡慶的時候，問題又出現了。 正常的 DNS服務器（）在正常工作了一個周之后又發生了與之前第一臺 DNS 相同的故障表現。于是，再次對曾經正常的DNS 服務器（ ）進行抓包，發現：這臺 DNS服務器又出現了跟之前那個 DNS 服務器相同的問題。就是單位時間DNS 服務器收到數量巨大的查詢包，而某些數據包無法及時的轉發成功。 考慮到兩臺 DNS服務器在大的流量增加時都會出現相同的問題，立即就考慮是不是服務

17、器性能以及流量的問題。 于是檢查兩臺 DNS 服務器，發現兩臺 DNS 服務器都是 IBM 早期的服務器，性能并不高，存也小，再加上安裝的 Windows Server2003 網絡操作系統，而 Windows Server 2003操作系統 DNS 的處理轉發能力都不及Windows Server2008 ，尤其Windows Server 2008系統的DNS 功能在背景區域加載和DNS 轉發性能上的改進，都會大大增加 DNS 的轉發效率。并且考慮到該集團還有 Wins 服務器，可以通過 Windows Server2008DNS 中的 GlobalNames 區域功能，可以將原來的 Wi

18、ns 與 DNS 服務器合并，解決單標簽訪問問題。于是想到了下列解決方法。解決方法二：因為考慮到在真實的網絡服務器上直接做調試和修改，可能會影響網絡的正常運行。于是，先通過微軟的SCVM2007 （虛擬化技術）中的 P2V 的技術，將真實的物理服務器全部虛擬成一臺臺虛擬的服務器，總共虛擬了 8 臺。然后在虛擬的網絡中做壓力測試。通過虛擬的網絡壓力測試之后，發現確實存在以上的問題。于是進行方法三。解決方法三：1.購置新的性能較高的IBM 服務器 2 臺，在集團里將原來的Windows Server 2003DNS集成活動目錄升級為Windows Server2008 。2.將兩臺 AD 集成 DNS 服務的服務器通過Windows Server的負載均衡功能建立起負載均衡服務器。使兩臺DNS 不要像以前手工指定客戶