DNS 解析器與 NS 記錄 TTL
如果一個區域有 6 條 NS 記錄
當 DNS 解析器為權威名稱伺服器查找域/區域時，它是否會獲取所有 6 條記錄並循環遍歷它們？
如果解析器使用第一個 NS 伺服器並根據其 TTL 對其進行記憶體 - 當該權威名稱伺服器沒有響應時，解析器是否仍然尊重 NS 記錄的 TTL？
正如imperva 的這篇文章所示 - 即使權威名稱伺服器沒有響應 - 解析器仍然會嘗試使用它，直到其 TTL 過期 - 這有多真實？
基本上，在網站有多個 NS 記錄的情況下，它們之間的解析受到 DNS 解析器工作方式的阻礙。只要解析器記憶體的 NS 記錄是最新的，解析器就可以嘗試訪問不活動的 Dyn 伺服器，直到 NS 記錄的 TTL 過期之前都是如此
這是否意味著我需要為 NS 記錄設置短 TTL？
關於解析器 DNS 如何與無響應的 NS 及其 TTL 一起工作的任何建議？
謝謝
當 DNS 解析器為權威名稱伺服器查找域/區域時，它是否會獲取所有 6 條記錄並循環遍歷它們？
是的，一個適當的遞歸名稱伺服器會考慮所有的名稱伺服器，並會在以後每次嘗試查詢最快的一個。
粗略的算法是這樣的：
- 從冷啟動（無記憶體）開始，隨機嘗試所有這些，記錄它們的回复速度（您可能需要將 UDP 案例與 TCP 案例分開）
- 一段時間後，根據之前的回復開始更頻繁地使用最快的
- 但請注意，您需要確保不要無限期地堅持使用任何給定的名稱伺服器，您也必須“不時地”嘗試其他名稱伺服器。為什麼？因為網路拓撲可以改變，名稱伺服器本身也是如此。
ns3對於您的特定有利位置，今天可能是更快的，但也許明天它會ns5代替；所以你必須使用最快的，但並非總是如此，只是為了確保能夠自動發現任何其他的，比你認為現在最快的更快。如果解析器使用第一個 NS 伺服器
停在這裡。記錄是以一組的形式出現的，而不是一個列表。也就是說，DNS 中沒有固有的順序。當然，線路或顯示表示中有一個命令，但它不是來自協議。
記錄集是袋子：你得到記錄，沒有訂單。事實上，您可以看到許多名稱伺服器，對於完全相同的查詢，如果回復中有多條記錄，每次查詢時都會對記錄進行不同的排序，這正是為了對抗只考慮第一項和無視其他人。
當該權威名稱伺服器沒有響應時
請參閱上面的算法：如果
NS集合中的一個名稱伺服器沒有響應，您可以認為它與“從任何其他名稱伺服器響應最慢”相同。客戶端 DNS 有超時，因此它不會無限等待，而是標記此特定名稱伺服器太慢，並將切換到其他名稱伺服器。因此，第一次您會受到懲罰，因為系統必須嘗試聯繫該名稱伺服器，稍等（幾秒鐘），重試並在某個時候停止使用該名稱伺服器。在那個斜坡之後，它將使用其他名稱伺服器，事情會很快。但是，當您第一次必須通過真正嘗試聯繫它來發現給定名稱伺服器很慢/沒有響應時，如果不嘗試就無法推斷出問題。這是否意味著我需要為 NS 記錄設置短 TTL？
也許吧，但這幾乎是無關緊要的。為什麼？因為您的
NS記錄發佈在您域的父區域中，以確保 DNS 委派。當然，它們是帶有 TTL 的，因為所有記錄都附加了一個 TTL，但是它們是在您無法控制的區域中發布的，因此您不能選擇它們的 TTL 值！（這裡有一個關於這些記錄的複雜/未完全完成的討論，比如
NS存在於兩部分：父母和孩子，問題是“哪一個是真正權威的”？如果父母在NS記錄上的 TTL 為 1 週並且您在您的區域中相同的NS記錄的 TTL 為 1 秒，遞歸名稱伺服器應該做什麼？人們可能會得出這樣的結論，通常委託的子部分是權威的，所以 1 秒在這裡獲勝；實際上是多個 DNS 實現是“以父母為中心”的，也就是說他們使用父母一方的數據，所以在那裡贏了 1 週）TTL 始終是一種權衡。一旦知道，有些人會立即得出結論，在非常低的 TTL 下事情會更好地工作……這在某些情況下是正確的，而在其他情況下則不然。記憶體很好，如果它們不存在（又名：沒有使用足夠大的 TTL），您將無法應對任何小問題，這將使一切都消失，因為記憶體已經使名稱過期。
此外，在沿所有名稱伺服器循環、嘗試超時並收斂於最快的名稱伺服器時，TTL 值對上述算法沒有（或幾乎沒有）影響。
因此，如果您查看 TLD 名稱伺服器（託管
NS該 TLD 下所有域的記錄）或各種建議中發生的情況，您通常會看到NSTTL 為 1 或 2 天的記錄。關於解析器 DNS 如何與無響應的 NS 及其 TTL 一起工作的任何建議？
每個解析器都有自己的 :-) 這實際上並沒有由協議指定，它是一個實現細節。您可以研究可以安裝的原始碼，但可能無法從大型公共遞歸 DNS 提供商那裡收集有關該原始碼的詳細資訊。
您可以在此處找到更多詳細資訊：
- https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/
- https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf
RFC 1034 §5.3.3 也確實提供了一些資訊（另請注意，它考慮了您忘記的一種情況：給定的名稱伺服器可能有多個 IP 地址 - 今天甚至應該始終如此，一個 IPv4 和一個 IPv6 - 和不能保證每次都能在相同的時間內獲得結果）：
除了伺服器的名稱和地址之外，SLIST 資料結構還可以進行排序以優先使用最好的伺服器，並確保所有伺服器的所有地址都以循環方式使用。排序可以是優先選擇本地網路上的地址而不是其他地址的簡單功能，或者可能涉及來自過去事件的統計數據，例如以前的響應時間和擊球平均值。
步驟 3 發出查詢，直到收到響應。該策略是循環遍歷所有伺服器的所有地址，每次傳輸之間有一個超時。在實踐中，使用多宿主主機的所有地址很重要，並且當多個解析器競爭同一個名稱伺服器甚至偶爾使用單個解析器時，過於激進的重傳策略實際上會減慢響應速度。SLIST 通常包含用於控制超時和跟踪先前傳輸的數據值。
RFC 1035 §7.2 有這樣的說法：
為了完成 SLIST 的初始化，解析器將它擁有的任何歷史資訊附加到 SLIST 中的每個地址。這通常包括地址響應時間的某種加權平均值，以及地址的成功率（即地址對請求做出響應的頻率）。請注意，此資訊應按地址保存，而不是按名稱伺服器保存，因為特定伺服器的響應時間和平均成功率可能因地址而異。另請注意，此資訊實際上特定於解析器地址/伺服器地址對，因此具有多個地址的解析器可能希望為其每個地址保留單獨的歷史記錄。此步驟的一部分必須處理沒有此類歷史記錄的地址；
請注意，無論何時遵循委託，解析器算法都會重新初始化 SLIST。
該資訊建立了可用名稱伺服器地址的部分排名。每次選擇一個地址時，應更改狀態以防止再次選擇它，直到嘗試了所有其他地址。每次傳輸的超時時間應比平均預測值大 50-100%，以允許響應變化。
還要完成，更具體地說：
正如 imperva 的這篇文章所示
您引用的這篇文章討論了使用 Dyn 名稱伺服器的人在出現中斷時發生的問題。那麼，是的，如果您只使用 Dyn 名稱伺服器，您就會遇到問題。即使您將您的區域更改為使用其他區域，
NS記錄 TTL 意味著您的更改不會立即被看到。但實際上這並沒有對 TTL 有太多說明，而只是對 DNS 管理有很多說明：如果您想要有彈性，對於重要區域，不要使用單個 DNS 提供程序，而是使用多個（這當然需要在你不能隨意混合和匹配提供商 X 和 Y，如果你通過 DNSSEC 進入混合，那就更複雜了，但這是可能的）。這樣，正是由於上面快速起草的算法，即使 5 個中有 2 個讓我們說名稱伺服器由於該特定提供商有問題而無法完全回复，另一個將承擔負載並使您的域正常工作。PS：沒有要求，但有時不清楚，給定記錄集中的所有記錄都必須具有相同的 TTL。TTL 是每條記錄的，但在給定的記錄集中需要相同，這意味著對於（名稱，記錄類型）的給定元組 [和類，但除了
IN作為類之外沒有人使用任何東西]