現在我正在參加 Linux 系統管理員的線上課程，有人問了我一個我通常不明白的問題。我知道如何搜尋名稱伺服器，如果我是正確的，至少它使用 dig 命令來查找附加部分命令中的位址，但是當被問到以下問題時，我有點迷失了。
假設您設定的網域名稱伺服器沒有任何快取結果可供使用，您的網域伺服器必須查詢多少網域伺服器才能解析maps.google.com？您將使用什麼命令來查找所有這些名稱伺服器？列出每個級別中的一個並解釋為什麼需要該級別。
我不想要答案，我只想知道我被要求做什麼。
答案1
假設您設定的網域名稱伺服器沒有任何快取結果可供使用，您的網域伺服器必須查詢多少網域伺服器才能解析maps.google.com？您將使用什麼命令來查找所有這些名稱伺服器？列出每個級別中的一個並解釋為什麼需要該級別。
好吧，讓我們把這個分開。
“假設您配置的名稱伺服器沒有任何快取結果可供使用”-- 首先，如果有的話不如果根本沒有快取數據，那麼它就無法解決任何問題。為了填充解析器的緩存，您需要擁有.（AKA 根）區域的 NS 和位址（A、AAAA）記錄。這是在區域中找到的根名稱伺服器root-servers.net.。該區域或那些 DNS 伺服器並沒有什麼神奇之處。然而，這些資料通常是「帶外」提供給 DNS 解析器的，正是為了填充解析器的快取。僅限權威的名稱伺服器不需要此數據，但解析名稱伺服器需要。
另外，「決心」什麼？該名稱有任何 RRtype 嗎？ RR A？還是其他東西？什麼類別（CH/Chaosnet、IN/Internet、...）？確切的過程會有所不同，但整體思路保持不變。
如果我們可以假設我們知道如何找到根名稱伺服器，但僅此而已，並且「解析」意味著取得IN A與該名稱關聯的任何 RR 的內容，那麼它就會變得更加實用。
要解析 DNS 名稱，您基本上會將名稱拆分為標籤，然後從右到左進行解析。不要忘記.最後的；你真的會解決maps.google.com.而不是maps.google.com。這讓我們需要解析（我們知道這一點，但 DNS 解析器實作可能不會）：
.com.google.com.maps.google.com.
首先弄清楚在哪裡詢問 的內容.。這很容易;我們已經有了該資訊：根名稱伺服器名稱和 IP 位址。所以我們有一個根名稱伺服器。假設我們決定使用 198.41.0.4 （a.root-servers.net也包括 2001:503:ba3e::2:30）來繼續名稱解析。在實踐中，解析器要做的第一件事可能是使用提供的根伺服器資料向根區域伺服器之一詢問根區域的名稱伺服器的準確列表，從而確保如果其中任何一個名稱和IP 位址有效且可訪問，解析開始時它將擁有根區域的完整且完整的資料集。
發出對maps.google.com. IN A198.41.0.4 的 DNS 查詢。它會告訴你「不，不會這樣做，但這裡有人可能知道」；這是一個轉介。它包含NS相關伺服器所知道的最近區域的記錄，以及伺服器碰巧可用的任何黏合記錄。如果沒有可用的黏合數據，您首先必須解析您選擇的 NS 記錄中指定的主機，因此產生一個單獨的名稱解析來取得 IP 位址；如果黏合資料可用，您將獲得至少「更接近」答案的名稱伺服器的 IP 位址。在本例中，這將是該區域的一組伺服器com.，並且還提供黏合資料。
重複此過程，向其中一台com.名稱伺服器詢問相同的問題。他們也不知道，但會向您推薦 Google 的權威名稱伺服器。此時，一般情況下，無論是否提供黏合數據，都會出現問題；例如，沒有什麼可以阻止com網域僅在 中擁有名稱伺服器nl，在這種情況下，不太可能從 gTLD 伺服器獲得黏合資料。提供的膠水數據也可能不完整，或者如果您真的不走運，它甚至可能不正確！你必須總是準備好產生我上面提到的單獨的名稱解析。
基本上，您會繼續下去，直到您獲得設置了（權威答案）標誌的答案aa。該答案將告訴您您要求什麼，或您要求的 RR 不存在（或者NXDOMAIN，或NOERROR具有零回應資料記錄）。繼續尋找類似的回應SERVFAIL（如果得到一個，則後退一步並嘗試另一台伺服器；如果所有命名伺服器都返回SERVFAIL，則名稱解析過程失敗並將SERVFAIL自己返回到客戶端）。
從每個伺服器請求完整 RRname 的另一種方法（這可能被認為是不好的做法）是使用我們之前確定的標籤拆分列表，向伺服器提供的名稱伺服器進一步詢問 和IN NS/ IN ARRIN AAAA的根該標籤，並使用它們來進一步進行名稱解析過程。這在實踐中只是略有不同，並且相同的過程仍然適用。
+trace您可以使用實用程式的選項來模擬整個過程dig，該實用程式是 BINDset debug或nslookup.
還值得記住的是，某些 RR 類型（特別是 RR 類型NS，MX以及其他一些；而且，A6已經相當好地使用了一段時間，但已被棄用）可以並且確實引用其他 RR。在這種情況下，您可能需要生成完後還有名稱解析過程，為您的客戶提供完整且有用的答案。
答案2
有一個dnstracer命令（您可能需要安裝它，至少在 Debian 上，這也是套件名稱）將追蹤名稱解析。您也可以（正如 Koveras 在評論中指出的那樣）使用dig.
這是 dnstracer。-s .意思是從根開始；-4意味著使用 IPv4（v6 在這裡被破壞了...）；-o意味著在最後實際顯示解析的IP位址（我省略了輸出的這一部分，有很多）。
anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ m.gtld-servers.net [com] (192.55.83.30)
| |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer
| |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer
| |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer
| \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer
⋮
該輸出繼續，因為 dnstracer 會追蹤所有路徑（因此您可以查看某些名稱伺服器是否具有過時的區域）。
因此，您可以看到需要對根名稱伺服器進行一次查詢，然後對 gtld-servers（.com 區域的伺服器）進行一次查詢，最後對 Google 名稱伺服器進行一次查詢。
使用dig，產出會更加冗長（因此我會進行大量刪減）：
dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
. 425379 IN NS b.root-servers.net.
⋮
com. 172800 IN NS f.gtld-servers.net.
⋮
google.com. 172800 IN NS ns2.google.com.
⋮
maps.google.com. 300 IN A 74.125.228.70
⋮
dig另外也顯示它執行了一個查詢來取得目前的根名稱伺服器清單。 DNS 伺服器通常很少執行此操作。所以我不確定你是否將其計入冷緩存案例中。
當然，您也可以使用例如 在線觀看實際查詢wireshark。