內容簡介：上節裏，我們用文字的形式大致描述了DNS解析的過程，爲了更好的幫助大家理解整個解析過程，我做了一張DNS域名解析的分步圖，如下： 在這個圖裏，通過8個步驟的解析過程就使得客戶端可以順利訪問www.163.com 這個域...
本章正文：
上節裏，我們用文字的形式大致描述了DNS解析的過程，爲了更好的幫助大家理解整個解析過程，我做了一張DNS域名解析的分步圖，如下：
在這個圖裏，通過8個步驟的解析過程就使得客戶端可以順利訪問www.163.com 這個域名，但實際應用中，通常這個過程是非常迅速的，主要由幾個方面的原因所決定。1、客戶端網絡狀況是否良好，2、與本地DNS連接的速度是否優秀， 3、本地DNS上是否有訪問地址的緩存等等，如果以上的因素答案都是肯定的，那麼訪問就會很迅速，上圖的步驟也會驟減至2個，因爲有緩存，所以本地 DNS服務器會很快告之域名對應的IP而實現迅速訪問。
上圖中出現了2個陌生的列表，下面就說說這兩張表的來歷。這裏我們結合第九章的內容繼續講解DNS的高級屬性，如下圖：
可以看到，在【根提示】選項卡中列出了13臺根服務器，分別是
(a~m).root-servers.net和對應的IP地址，有的是2個IP，後面那個是備選地址，我們可以手動修改這些地址，但一般情況下，建議不要去動它。如果不小心更改或者刪除，我們還是有幾個辦法修復的。因爲這些服務器的地址列表是整個互聯網共享的，所以我們可以在網絡上找到最新的根服務器列表。通常在這個鏈接裏：
在服務器IP地址裏，我們可以輸入13個地址中的任意一個，確定後系統會自動連接到該服務器上更新列表。也並非13個地址中的一個，如果同網段內有冗餘 DNS，這裏就可以輸入那臺DNS的地址，也是可以更新的。前提是，兩臺DNS服務器都必須連接到互聯網。當然在DNS的安裝目錄下的 CACHE.DNS文件中也是可以找到的，具體路徑如下：C:\WINDOWS\system32\dns\CACHE.DNS。以上的方法都可以恢復這個列表。
在回到第一個圖中，當本地DNS服務器向根DNS查詢時，它會搜索自己的根DNS服務器列表，找到一個連接的地址，比如 d.root- servers.net，這樣就聯繫到了根服務器，當然，連接其他的也可以，沒有太大區別。根服務器檢測到是.com域名後，就返回給本地DNS服務器一個IP地址，這個IP就是負責.com頂級域名的其中一個服務器，我這裏選的是c.gtld-servers.net，同樣的，一共有13臺這樣的服務器負責.com域名的解析，即(a~m).gtld-servers.net。可能有的朋友疑問，這個是這麼知道？OK，要解這部分內容，我們需要用到另一個工具dig，這個原本是Linux下的DNS服務器的調試工具，類似windows下的nslookup，但功能上比後者強很多，我們先做個演示，至於如何使用，後面會有章節來描述。
我們用dig命令來跟蹤一下到www.163.com網站的整個過程，如下圖：
圖中提到的gTLD，其實這是頂級域名的一個分類，除此之外還有ccTLD，也就是國家及地區代碼頂級域名，即CountryCodeTLD，比如. cn表示中國.hk，表示香港等。上圖的4個過程其實就是我們從提交請求，到正常訪問的過程。上圖中還有很多參數沒有說明，這部分會再後面章節有詳述。
現在我們再來說一下遞歸查詢和迭代查詢。
在本節的第一張圖中，當本地的DNS服務器幫助客戶端解析www.163.com這個地址的IP地址的過程中，其實有已經包含了這2類查詢。從客戶端到本地DNS服務器是屬於遞歸查詢。而DNS服務器之間就是的交互查詢就是迭代查詢。
我們模擬一個場景。比如你的老闆要去喜來登大酒店，但不知道怎麼走，於是問你（你是他的祕書），此時你也不知道，於是問張三，張三也不清楚，讓說讓你去問李四，於是你問李四，李四正好知道，然後把線路告訴你，然後你把結果告訴你老闆，這樣整個問詢就完成了。那麼這就是個遞歸的過程。在這個過程中，老闆始終在等待你的答案，而自己卻絲毫不關心這檔子事，而你就充當了一個代理和中間人的角色，來全權負責此時，你的目的是要把答案找到並反饋給老闆。
你、張三、李四這三個人之間的信息傳遞，就是迭代的過程，因爲你在問張三的時候，張三並沒有像你代替你老闆一樣去問別人，而只是返回給你一個參考答案。這樣的問詢方式，我們就稱之爲迭代查詢。
在默認情況下DNS服務器可以接受來自其他客戶機（或其他DNS服務器）的迭代或遞歸查詢，如果流量較大的服務器通常都只接受迭代查詢，比如13臺根服務器。因爲如果它們對每一個解析請求都代爲查詢的話，那將會消耗極大的服務器資源，可能會導致服務器過載甚至崩潰。
關於DNS的迭代和遞歸查詢我們先聊到這裏。下節繼續討論DNS服務器高級屬性的其他選項卡，敬請期待！