澄清為什麼 DNS 區域文件需要 NS 記錄

這個問題最初是在這裡問的： 為什麼 DNS 區域文件需要 NS 記錄？

總結一下：“當我去我的註冊商購買 example.com 時，我會告訴我的註冊商我的域名伺服器是 ns1.example.org 和 ns2.example.org”。

但是請有人澄清以下內容：

註冊後，.com 系統資料庫現在將有一條記錄，告訴解析器需要訪問 ns1.example.org 或 ns2.example.org 才能找到 example.com 的 IP 地址。IP 地址位於 ns1.example.org 上區域文件的 A 記錄中，並且在 ns2.example.org 上具有相同的副本。

但是，在此文件中，還必須有 2 條 NS 記錄，將 ns1.example.org 和 ns2.example.org 列為名稱伺服器。但由於我們已經在其中一台伺服器上，這似乎是重複的資訊。

最初對該問題給出的答案是，區域文件中列出的名稱伺服器是“權威的”。如果名稱伺服器不匹配，則權威名稱伺服器將優先。這一切都很好，但是解析器使用*.com 系統資料庫中列出*的名稱伺服器到達名稱伺服器，如果名稱伺服器不匹配，那麼解析器將在錯誤的名稱伺服器上查找區域文件並且不會找不到它。

還是 .com 系統資料庫從區域文件 ns 記錄中提取名稱伺服器資訊的情況？（但我想如果你在不告訴系統資料庫的情況下更改區域文件的 ns 記錄，那麼它將無法知道在哪裡查找。）

謝謝

讓我們稍微分解一下。

TLD 區域中的 NS 記錄（例如example.com NS ...in com）是授權記錄。

TLD 區域（例如ns1.example.com A ...in com）中的 A 和 AAAA 記錄是粘合記錄。

區域本身（即example.com NS ...in example.com）中的 NS 記錄是規範記錄。

ns1.example.com A ...區域本身（ in example.com）中的 A 和 AAAA 記錄是地址記錄，簡單明了。

當（遞歸）解析器開始時沒有您的區域數據的記憶體並且只有根區域記憶體（用於引導名稱解析過程），它將首先轉到.，然後com.。com伺服器將使用權限部分響應進行響應，該響應基本上說“我不知道，但在這裡尋找知道的人”，與.do about的伺服器相同com。此查詢響應不具有權威性，並且不包括填充的答案部分。它還可能包括所謂的附加部分給出特定伺服器知道的任何主機名的地址映射（來自膠水記錄，或者在遞歸解析器的情況下，來自先前記憶體的數據）。解析器將接受此委託響應，如有必要，解析 NS 記錄的主機名，並繼續查詢已被委託的 DNS 伺服器。如果您的委託層次結構較深，此過程可能會重複多次，但最終會導致查詢響應設置為“權威答案”標誌。

重要的是要注意，解析器（通常，希望如此）不會嘗試分解要解析的主機名來逐個詢問它，而只是將其全部發送到它所知道的“最佳”伺服器。由於 Internet 上的普通權威名稱伺服器對於絕大多數有效 DNS 名稱都是非權威的，因此響應將是指向其他 DNS 伺服器的非權威委託響應。

現在，不必在任何地方的授權或權限記錄中命名伺服器即可對區域具有權威性。例如考慮私有主伺服器的情況；在這種情況下，存在一個權威 DNS 伺服器，只有該區域的從屬 DNS 伺服器的管理員知道該伺服器。*如果通過某種機制，DNS 伺服器對某個區域具有權威性，它認為它對所討論的區域具有完整和準確的知識。*例如，如果在 SOA 記錄中定義為到期時間的時間限制內無法到達配置的主伺服器，則通常具有權威性的 DNS 伺服器可能會變為非權威性。

只有權威的答案才應該被認為是正確的查詢響應；其他一切要麼是委託，要麼是某種錯誤。對非權威伺服器的委託稱為“蹩腳”委託，這意味著解析器必須回溯一步並嘗試使用其他命名的 DNS 伺服器。如果委託中不存在權威的可訪問名稱伺服器，則名稱解析失敗（否則，它只會比正常速度慢）。

這很重要，因為非權威數據不能被記憶體。怎麼可能，因為非權威伺服器沒有全貌？因此，權威伺服器必須能夠自行回答“誰應該是權威的，為了什麼？”的問題。這是區域內 NS 記錄提供的資訊。

在許多邊緣情況下，這實際上會產生重大影響，主要集中在單個區域內的多個主機名標籤（可能相當常見，例如反向 DNS 區域，特別是對於大型動態 IP 範圍）或名稱伺服器列表不同時父區域和有問題的區域（這很可能是一個錯誤，但也可以故意這樣做）。

---

dig您可以使用它的+norec（不請求遞歸）和@伺服器說明符功能更詳細地了解它是如何工作的。**以下是實際解析 DNS 伺服器如何工作的說明。**查詢unix.stackexchange.com從例如開始的 A 記錄a.root-servers.net：

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

仔細查看flags每個部分的計數。qr是查詢響應，aa是權威答案。請注意，您只被委派給com伺服器。手動遵循該委託（在現實生活中，遞歸解析器將使用附加部分中的 IP 地址（如果提供），或者如果委託響應中未提供 IP，則啟動其中一個命名名稱伺服器的單獨名稱解析，但我們將為了簡潔起見，跳過該部分並返回到作業系統的正常解析器）：

$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec

現在您看到它stackexchange.com被委託給 (以及其他) ns1.serverfault.com，您仍然沒有得到權威的答案。再次跟隨代表團：

$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;unix.stackexchange.com. IN A

;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16

答對了！我們得到了答案，因為aa標誌已設置，並且它恰好包含我們希望找到的 IP 地址。順便說一句，值得注意的是，至少在我寫這篇文章的時候，委派給和列出的授權名稱伺服器列表是不同的，這表明兩者不需要相同。我上面舉例說明的基本上是任何解析器所做的工作，除了任何實際的解析器也會一路記憶體響應，因此它不必每次都訪問根伺服器。

從上面的範例可以看出，委託和粘合記錄的用途與區域本身的權限和地址記錄不同。

記憶體、解析名稱伺服器通常還會對返回的數據進行一些健全性檢查，以防止記憶體中毒。*例如，*它可能會拒絕記憶體一個答案，該答案命名權威伺服器com的來源不是已被父區域命名為 deleged-to 的來源com。詳細資訊取決於伺服器，但目的是盡可能多地記憶體，同時不打開允許 Internet 上的任何隨機名稱伺服器覆蓋其“管轄範圍”之外的任何內容的委託記錄的穀倉門。

引用自：https://serverfault.com/questions/526278