DNS 快取 - 迭代與遞歸

DNS 快取 - 迭代與遞歸

在迭代 DNS 架構中,本機 DNS 伺服器具有緩存,基本上可以跳過與根伺服器和 TLD 伺服器的聯繫。

在遞歸模式中,本機 DNS 伺服器聯絡一台 DNS 伺服器,該伺服器遞歸地取得結果並回覆所要求的資源。

從快取的角度來看,迭代 DNS 和遞歸 DNS 有什麼不同?

本地DNS伺服器還能在遞歸架構走捷徑嗎?

答案1

從快取的角度來看,迭代 DNS 和遞歸 DNS 有什麼不同?

沒有差別。來自權威伺服器的生存時間 (TTL) 以及本地策略將指示記錄將在快取中保存和提供的時間。

本地DNS伺服器還能在遞歸架構走捷徑嗎?

如果本機 DNS 不是僅轉送 DNS,那麼是的,而且這種情況經常發生。一旦您知道如何取得特定網域的答案,當資訊位於快取中時,您將不會再一路回到根目錄。由於原始 TTL 已過期,或本機配置對快取大小或 TTL 設定了限制,資料可能會從快取中刪除。例如bind,這將是max-cache-ttl.

答案2

現在有一個關於 DNS 術語的規範文件:

RFC 8499 又稱 BCP 219

以下是其相關定義,略有刪節並重新排序:

  • “遞歸解析器:以遞歸模式運行的解析器。[..] [RFC4697] 試圖區分遞歸解析器和迭代解析器。”

  • 「遞歸模式:伺服器的一種解析模式,它接收 DNS 查詢,然後從本地快取回應這些查詢,或將查詢發送到其他伺服器,以獲得原始查詢的最終答案。”

  • “迭代解析:名稱伺服器可能會收到只能由其他伺服器回答的查詢。處理此問題的兩種通用方法是“遞歸”,其中第一個伺服器代表客戶端執行查詢在另一台伺服器上,並且是“迭代”,其中伺服器將客戶端引導到另一台伺服器並讓客戶端在​​那裡進行查詢(請參閱[RFC1034] 的第2.3 節。)

    In iterative resolution, the client repeatedly makes non-recursive
    queries and follows referrals and/or aliases.  The iterative
    resolution algorithm is described in Section 5.3.3 of [RFC1034]."
    

上面引用的 RFC 4697 是這樣說的:

本備忘錄主要關注迭代
解析器的行為,迭代解析器通常是遞歸名稱
伺服器的一部分。本備忘錄使用更精確的術語“迭代解析器”,
因為焦點通常集中在該元件上。在
需要提及該實體的名稱伺服器角色的情況下,本備忘錄
使用術語「遞歸名稱伺服器」。作為差異的範例
,遞歸名稱伺服器的名稱伺服器元件
接收 DNS 查詢,而迭代解析器元件會傳送
查詢。

在我看來,RFC 1034 對此更加不清楚,或者更準確地說,更加過時:

  • 在任何具有分散式資料庫的系統中,特定的名稱伺服器可能會收到只能由其他伺服器回答的查詢。處理此問題的兩種通用方法是“遞歸”,其中第一個伺服器在另一台伺服器上執行客戶端的查詢;以及“迭代”,其中伺服器將客戶端引用到另一台伺服器並讓客戶端執行查詢詢問。兩種方法都有優點和缺點,但對於資料封包樣式的訪問,迭代方法是首選。域系統需要迭代方法的實現,但允許遞歸方法作為選項。

回到你的問題:

從快取的角度來看,迭代 DNS 和遞歸 DNS 有什麼不同?

根據我對事物在野外如何運作的理解(與上面的定義不完全一致),遞歸名稱伺服器透過迭代查詢來解析客戶端請求的任何名稱,因此沒有差異。

並為

本地DNS伺服器還能在遞歸架構走捷徑嗎?

基本上任何不權威的東西都可以有一個緩存,只要它遵守從先前收到的回復中獲得的 TTL,它就在協議的範圍內工作。

請注意,將來事情可能會變得更加混亂:一些提案(例如ANAME特定實現)可能需要權威名稱伺服器在給定查詢到來時也變得遞歸/迭代,以便能夠解析目標。

相關內容