對於所有基於Windows系統的網絡來說，DNS都屬於最重要的服務之一。在沒有DNS支持的情況下，活動目錄就不能正常工作，並且它使用到的功能也比任何其它類型的網絡都多。因此，在DNS出現問題時盡快解決就成為一項非常關鍵的工作。幸運的是，在通常情況下這一過程是比較容易的。在本文中，作者就列出了自己最喜歡的十項DNS故障排除技術。
1：對網絡連接情況進行驗證
當發現DNS服務出現問題時，應該做的第一件事情就是對DNS服務器的網絡連接情況進行驗證。畢竟，如果實際問題僅僅是一塊網卡出現了故障，耗費在從頭開始對設備進行全面檢查的大量時間就可以都省下來了。
對連接情況進行驗證的最簡單方法就是登錄到DNS服務器上，並利用ping命令檢查與其它機器的連接狀態。還應該做的就是，嘗試利用隨機機器來ping連接DNS服務器。請務必牢記，只有在防火牆的配置裡容許網際消息控制協議(ICMP)數據包通過的情況下，ping命令才能發揮作用。
2：確定問題波及的范圍
在確定基本連接正常的情況下，下一步要做的工作就是確定問題波及的范圍。實際情況是互聯網名稱解析服務失敗，還是本地名稱解析服務失敗呢?對於不同的問題來說，采取的解決方法也是有很大區別的。舉例來說，如果本地名稱解析服務正常，而互聯網名稱解析服務失敗的話，問題可能就是出在互聯網服務供應商的DNS服務器上。
3:確認是否所有用戶都受到影響
接下來要考慮的另一件事情就是是否網絡上的所有用戶都受到了影響，或者是僅僅限於部分用戶。如果確認只有部分用戶受到影響的話，請對這些用戶所在的網絡段位置進行檢查，確認他們是否屬於同一范圍。如果答案是確定的話，問題可能與路由器故障或動態主機配置協議(DHCP)配置錯誤有關。
4：確認DNS服務器上是否運行了負載均衡處理技術
某些情況中，公司對網絡服務器資源的極大需求會導致DNS服務器被分散到多台相同的網絡服務器上利用DNS輪循技術實現工作量的負載平衡技術被投入使用。該技術中存在的一個典型問題就是，在其中一台服務器已經宕機的情況下，DNS服務器不會了解到實際情況發生了變化。因此，盡管其中的一台服務器已經處於脫機狀態，但輸入流量依然被平均分配給循環中的所有服務器。由此導致的結果就是負載平衡資源在連接間歇性方面出現問題。
5：對DNS服務器轉發器進行檢查
如果已經確認本地名稱解析服務運行正常，但互聯網名稱解析服務無法工作的話，下面要檢查的就是DNS服務器是否在使用轉發器。盡管很多DNS服務器都利用根提示來提供互聯網名稱解析服務，但也有一些使用轉發器連接到互聯網服務供應商的DNS服務器上。如果互聯網服務供應商的DNS服務器出現了問題，在解析器緩存中條目過期的情況下，互聯網名稱解析服務將失敗。如果確認DNS服務器沒有使用轉發器，還可以嘗試一下對服務器進行ping檢測，以了解它是否在線。可能需要做的還包括致電互聯網服務供應商，來了解那裡是否存在任何DNS方面的問題，並確保在轉發器中使用的網絡IP地址仍然屬於有效的。
6：嘗試利用一台主機進行ping測試 如果本地網絡中的名稱解析服務出現問題，就應該選擇嘗試對網絡中的其它服務器進行ping測試。首先，可以利用服務器的網絡IP地址進行ping測試。這樣的話，就可以確認該服務器是否依然可以連接。接下來，要做的就是利用計算機名稱和服務器的完全合格域名進行ping測試。 如果網絡IP地址可以通過ping測試，但域名無法通過的話，就應該對DNS服務器進行檢查，以確保主機(A)記錄的存在。如果沒有主機(A)記錄的話，DNS服務器將無法解析主機的名稱。 7：使用NSLookup查詢域名命令 對於排除DNS故障來說，最方便的工具之一就是NSLookup查詢域名命令。它可以在Windows命令提示符窗口中使用。只要輸入NSLookup加上需要測試名稱解析服務的主機名稱，Windows就可以返回DNS服務器的網絡IP地址和解析名稱(盡管在通常情況下，DNS服務器名稱顯示的是為未知)。它也可以提供指定主機的完全合格域名和網絡IP地址。 對於兩件事情來說，NSLOOKUP命令非常有用。首先，它可以容許對名稱解析服務是否正常進行驗證。其次，如果名稱解析服務無法正常工作，它可以幫助確認使用的服務器是哪一台。請務必牢記，Nslookup的查詢結果中只列出它最初連接到的DNS服務器。如果名稱解析請求被轉發到其它DNS服務器的話，這些服務器是不會被列出的。 8：嘗試使用一台備用DNS服務器 大多數公司都擁有至少兩台DNS服務器。如果主DNS服務器出現了問題，請嘗試使用備用DNS服務器。如果在切換DNS服務器後，名稱解析服務可以正常工作，就可以確認該問題確實是涉及到DNS服務器，而不是一些外部因素。 9：掃描病毒 大約一星期前，有人向我求助。他們的網絡中出現了問題，現象是每當試圖訪問特定網站的時間，就會被重定向到一家惡意站點上。我最早的懷疑是DNS中毒攻擊，但在發現實際情況是只有一台計算機受到影響後，這種可能性被排除了。 最後，我發現問題是一種病毒占據了TCP/IP協議棧，對所有名稱解析請求進行攔截。盡管這一問題在最初看起來似乎是DNS的問題，但實際上病毒需要承擔最終的責任。 10：重新啟動DNS服務器 我知道這種措施看上去很象陳詞濫調，但當所有解決方案都沒有成功的時間，選擇重新啟動DNS服務器也是一條出路。在這麼多年的工作經歷中，我見到多起由於未知原因導致名稱解析服務失敗，但在重新啟動DNS服務器後一切就正常的情況。 同樣，我遇到過至少兩起消費級路由器出現停止轉發DNS請求而其它類型流量依然正常的情況。在其中一起案例中，重新啟動路由器就可以解決該問題。而在另一起案例中，就必須更換路由器。據分析，該路由器可能是在前一天發生的停電事故中損壞。
