DNS 解析器與 NS 記錄 TTL

Question

當 DNS 解析器在網域/區域中尋找權威名稱伺服器時，它是否會取得所有 6 筆記錄並循環遍歷它們？

是的，正確的遞歸名稱伺服器會考慮所有名稱伺服器，並且每次都會嘗試查詢最快的名稱伺服器。

粗略的演算法是這樣的：

從冷啟動（無快取）開始，隨機嘗試所有這些，記錄它們回應的速度（您可能需要將 UDP 情況與 TCP 情況分開）
一段時間後，開始更頻繁地使用根據先前的回覆最快的一個
但請注意，您需要確保不要無限期地堅持使用任何給定的名稱伺服器，您也必須「不時」嘗試其他名稱伺服器。為什麼？因為網路拓撲以及名稱伺服器本身都可能會變更。ns3對於您的特定有利位置來說，今天可能會更快，但也許明天就會ns5相反；因此，您必須使用最快的一個，但並非總是如此，只是為了確保能夠自動發現比您現在認為最快的那個更快的其他任何一個。

如果解析器使用第一個 NS 伺服器

停在這裡。記錄是一組記錄，而不是清單。也就是說，DNS 中沒有固有的順序。當然，線路或顯示表示中有一個順序，但它不是來自協定。

記錄集是袋子：您無需訂單即可獲得記錄。事實上，您可以看到許多名稱伺服器，對於完全相同的查詢，如果回復中有多個記錄，每次查詢時都會對記錄進行不同的排序，這正是為了對抗僅考慮第一項和無視其他人。

當權威名稱伺服器沒有回應時

請參閱上面的演算法：如果集合中的其中一個名稱伺服器NS沒有回應，您可以將其視為與「從任何其他名稱伺服器回覆最慢」相同。用戶端 DNS 具有逾時功能，因此它不會無限等待，但會標記該特定名稱伺服器速度太慢，並將切換到其他名稱伺服器。因此，第一次您會受到懲罰，因為系統必須嘗試聯繫該名稱伺服器，等待一會兒（幾秒鐘），重試並在某個時候停止使用該名稱伺服器。在這個斜坡之後，它將使用其他名稱伺服器，事情會很快。但是，當您第一次真正嘗試聯繫給定的名稱伺服器時，發現它很慢/沒有回應，您無法在不嘗試的情況下推斷出問題。

這是否意味著我需要為 NS 記錄設定短 TTL？

也許吧，但這大多是無關緊要的。為什麼？因為您的NS記錄發佈在您網域的父區域中，以確保 DNS 委派。當然，它們是透過 TTL 發布的，因為所有記錄都附加了 TTL，但它們發佈在您無法控制的區域中，因此您無法選擇它們的 TTL 值！

（這裡有一個關於這些記錄的複雜/未完全完成的討論，就像NS存在於兩個部分：父級和子級，問題是「哪一個才是真正權威的」？如果父級記錄的 TTL 為 1NS週並且您所在區域中的相同NS記錄的 TTL 為 1 秒，遞歸名稱伺服器應該做什麼？以家長為中心”，即他們使用家長端的數據，因此1 週獲勝）

TTL 始終是一種權衡。一旦知道，有些人會立即得出這樣的結論：TTL 非常低時效果會更好……這對於某些情況是正確的，而對於其他情況則不然。快取很好，如果它們不存在（又名：沒有使用足夠大的 TTL），您就無法抵禦任何小問題，這將使一切消失，因為快取的名稱已經過期。

此外，TTL 值對上述演算法在所有名稱伺服器上循環、嘗試逾時並收斂於最快的名稱伺服器時沒有（或幾乎沒有）影響。

因此，如果您查看 TLD 網域伺服器（託管NS該 TLD 下所有網域的記錄）或各種建議中發生的情況，通常會看到NSTTL 為 1 或 2 天的記錄。

關於解析器 DNS 如何與非響應 NS 及其 TTL 配合使用有什麼建議嗎？

每個解析器都有自己的:-) 這不是由協定真正指定的，它是一個實作細節。您可以研究可安裝的原始程式碼，但可能無法從大型公共遞歸 DNS 提供者收集有關該原始程式碼的詳細資訊。

您可以在這裡找到更多詳細資訊：

RFC 1034 §5.3.3 也提供了一些資訊（另請注意，它考慮了您忘記的一種情況：給定的名稱伺服器可能有多個IP 位址- 今天甚至應該始終如此，一個IPv4 和一個IPv6 -並且不能保證您在每個時間段內獲得結果）：

除了伺服器的名稱和位址之外，還可以對SLIST資料結構進行排序，以首先使用最好的伺服器，並確保以循環方式使用所有伺服器的所有位址。排序可以是優先選擇本地網路上的位址而不是其他位址的簡單功能，也可以涉及過去事件的統計數據，例如先前的回應時間和成功率。

步驟 3 發出查詢，直到收到回應。此策略是循環所有伺服器的所有位址，並在每次傳輸之間設定逾時。實際上，使用多宿主主機的所有位址非常重要，當多個解析器爭用相同名稱伺服器時，甚至偶爾爭用單一解析器時，過於激進的重傳策略實際上會減慢回應速度。 SLIST 通常包含用於控制逾時並追蹤先前傳輸的資料值。

RFC 1035 §7.2 有這樣的規定：

為了完成 SLIST 的初始化，解析器將其擁有的任何歷史資訊附加到 SLIST 中的每個位址。這通常包括地址回應時間的某種加權平均值和地址的成功率（即地址回應請求的頻率）。請注意，此資訊應以每個位址為基礎保存，而不是以每個名稱伺服器為基礎，因為特定伺服器的回應時間和成功率可能會因位址而異。另請注意，此資訊實際上特定於解析器位址/伺服器位址對，因此具有多個位址的解析器可能想要為其每個位址保留單獨的歷史記錄。此步驟的一部分必須處理沒有此類歷史記錄的地址；在這種情況下，預計往返時間為 5-10 秒應該是最壞的情況，對於同一本地網路等的估計值較低。

請注意，每當遵循委託時，解析器演算法都會重新初始化 SLIST。

此資訊建立了可用名稱伺服器位址的部分排名。每次選擇一個地址時，都應更改狀態以防止再次選擇該地址，直到嘗試了所有其他地址為止。每次傳輸的超時應比平均預測值大 50-100%，以允許響應差異。

也要結束並更具體地說明這一點：

正如 imperva 的這篇文章所示

您引用的這篇文章討論了使用 Dyn 網域伺服器的人在發生中斷時發生的問題。那麼，是的，如果您僅使用 Dyn 名稱伺服器，則會遇到問題。即使您將區域變更為使用其他區域，NS記錄 TTL 也意味著您的變更不會立即被看到。但實際上，這並沒有說明很多關於TTL 的問題，而只是說明了很多關於DNS 管理的問題：如果您想要具有彈性，對於重要區域，不要使用單一DNS 提供者，而是使用多個DNS 提供商（這當然要求之間進行一些協調）您不能隨意混合和匹配提供者 X 和 Y，如果您透過 DNSSEC 進行混合，情況會更加複雜，但這是可能的）。這樣，正是由於上面快速起草的演算法，即使五分之二的網域伺服器無法完全回复，因為這個特定的提供者有問題，另一個將承擔負載並使您的網域正常工作。訪客的每個新查詢可能會出現額外的延遲（因為所有遞歸名稱伺服器無法立即了解它們必須切換到特定名稱伺服器，因為5 個名稱伺服器中的2 個已關閉），並且還會出現更多延遲，因為其他3 個名稱伺服器被更多的資訊淹沒查詢比正常情況要多（DNS 預設是負載平衡的，因此理論上每個名稱伺服器都會獲得大致相同的查詢量），但仍然會給出答。

PS：沒有要求，但由於有時不清楚，給定記錄集中的所有記錄都必須具有相同的 TTL。 TTL 是每筆記錄的，但在給定的記錄集中需要相同，這意味著對於給定的（名稱，記錄類型）元組[和類，但沒有人使用除IN類之外的任何東西]

Answer 1