為了將主機名稱解析為其 IP 位址，可以查詢多個 DNS 伺服器。假設沒有發生緩存，它來自發出請求的人（客戶端）、遞歸 DNS、根 DNS、TLD DNS，最後是權威名稱伺服器。
我的訂單正確嗎？請求是否被轉發，或者伺服器是否僅回覆客戶端應聯繫的下一級伺服器的 IP 位址？例如，遞歸名稱伺服器是否在根伺服器上進行實際查詢，或只是傳遞根伺服器的 IP 位址？我猜這是第一個用於緩存目的的。另外，快取可以在哪些階段發生，例如根伺服器是否會快取來自 TLD 伺服器的回應？由於只有 13 個唯一的根伺服器，那麼擁有該等級而不是直接存取 TLD 伺服器有什麼意義呢？
答案1
所以這是一個很深的話題，所以這只是表面，但請考慮有幾種方法可以回答查詢。
一般來說，可用的查詢類型將決定客戶端需要發出多少個請求來解析類似a.b.c.com.
對於遞歸解析，客戶端查詢伺服器一次，以取得正在尋找的全名。伺服器將處理對根伺服器的查詢，然後解析名稱伺服器C，B然後查詢B主機名稱A。然後本地伺服器會發回一個單身的對客戶的回應。
對於非遞歸解析，客戶端將發送請求，詢問 的名稱伺服器C.com，然後在該伺服器中查詢 的名稱伺服器B.C.com，然後在這些伺服器中查詢主機A。這就是我們一直想要的實際答案。但在這種情況下，客戶必須進行 3 個單獨的查詢為拿到它，為實現它。
有一個相關的「轉發器」概念，其中本機解析器可以將未知（非本機）查詢轉送到另一台伺服器進行解析。本機伺服器和上游解析器之間的互動可能是遞歸的，也可能不是遞歸的，但結果會作為單一回應傳送回客戶端，因此從客戶端的角度來看它是遞歸的。
現在討論快取的主題，從網路效能的角度來看，快取離客戶端越近，就越有價值。儘管如此，權衡是，如果快取太接近，並且代表一組不太多樣化的快取答案，則快取可能不會被充分使用。將快取放置在上游一兩層，以便快取代表更多使用者的組合結果，因此更有可能獲得有價值的答案。
答案2
我的訂單正確嗎？
一般順序是的，但它不是一條直線：根伺服器不會將您的查詢轉發到其他任何地方，它會透過引用回應反彈回解析器（告訴解析器在其他地方查詢）。 TLD 伺服器和網域伺服器也是如此。
請求是否被轉發，或者伺服器是否僅回覆客戶端應聯繫的下一級伺服器的 IP 位址？
這兩種行為都會發生，但發生在不同的地方。
例如，遞歸名稱伺服器是否在根伺服器上進行實際查詢，或只是傳遞根伺服器的 IP 位址？
遞歸伺服器執行實際的查詢。從字面上看，這就是它成為遞歸伺服器的原因：在它接受了客戶端的查詢之後，它自己會進行進一步的查詢，直到它可以傳回最終結果。 （這是因為在作業系統上運行的客戶端只是一個存根解析器，不具備所有必要的功能。）
然而，根/TLD/網域伺服器不是遞歸的－它們只回答它們有權威的網域，並且只為其餘網域提供重新導向（引用）。他們從不自己進一步詢問。
另外，快取可以在哪些階段發生，例如根伺服器是否會快取來自 TLD 伺服器的回應？
快取發生在發送查詢和接收回應的系統上。這意味著只有遞歸解析器才執行緩存，因為它們從其他人那裡接收可緩存的資訊。
另一方面，根/TLD/網域伺服器從不處理遞歸查詢——它們不查詢任何其他內容，因此它們不需要快取任何內容。 （他們只回答他們所在的域權威性關於。
由於只有 13 個唯一的根伺服器，那麼擁有該等級而不是直接存取 TLD 伺服器有什麼意義呢？
每個人的解析器如何知道 TLD 伺服器的位置？
請記住，不存在“該”TLD 伺服器。每個 TLD 都有 TLD 伺服器 - 例如，comTLD 有一組伺服器，euTLD 有另一組伺服器。實際上有數百個 TLD，因此靜態清單是行不通的。
DNS 根簡化了這個問題 - 不是所有 TLD 及其伺服器的列表，而是只有一個根網域及其伺服器，這導致初始列表要小得多，並且列表會發生變化非常很少，因此解析器軟體實際上可以包含它的副本。大多數遞歸解析器都包含“根提示”的副本。
（另外，請注意，有13 個根伺服器位址，因為在早期，一個位址僅意味著一台主機，但現在情況已不再如此– Internet 支援選播路由，因此幾乎每個位址實際上都對應於數百個唯一實例事實上。