位於 DNS 域頂端的 NS 記錄的作用是什麼？

$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                     1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

NS 記錄在域頂點下的作用是眾所周知的。它們的存在是為了將子域的權限委託給另一個名稱伺服器。上述範例包括 和 的 NSsub1記錄sub2。這些允許名稱伺服器分發它不認為自己具有權威性的域部分的引用。

NS 記錄在域頂點的​​目的，ns1在ns2這種情況下，整個網際網路似乎不太了解。我的理解（可能不是整體的）如下：

1. 記憶體 DNS 伺服器不使用它們來確定域的權威伺服器。這由在註冊商級別定義的名稱伺服器粘合處理。註冊商從不使用此資訊來生成粘合記錄。
2. 它們不用於將整個域的權限委託給其他名稱伺服器。嘗試使用 ISC BIND 等軟體這樣做根本不會導致“預期的”引用行為，因為名稱伺服器將繼續認為自己對該區域具有權威性。
3. 名稱伺服器不使用它們來確定它是否應該返回權威響應（AA標誌集）；該行為由軟體被告知是該區域的主機還是從機來定義。大多數域名伺服器軟體很樂意為與上游粘合記錄所包含的資訊不一致的頂級 NS 記錄提供服務，這反過來會導致知名的 DNS 驗證網站為域生成警告。

既然如此，我們還剩下什麼？如果這些資訊似乎沒有被整個 Internet 上的 DNS 伺服器記憶體所消耗，我們為什麼要定義這些資訊？

下屬標識

主伺服器使用 Apex 級別的 NS 記錄來辨識其下屬。當權威名稱伺服器上的數據發生變化時，它將通過DNS NOTIFY消息 ( RFC 1996 ) 向該列表中的所有對等方通告這一點。這些伺服器將依次呼叫SOA記錄請求（包含序列號），並決定是否下載該區域的更新副本。

• 可以將這些消息發送到該NS部分中未列出的伺服器，但這需要特定於伺服器的配置指令（例如 ISC BINDalso-notify指令）。頂點 NS 記錄包含在預設配置下要通知的伺服器的基本列表。
• 值得注意的是，輔助伺服器也會根據這些NS記錄相互發送 NOTIFY 消息，通常會導致記錄拒絕。這可以通過指示伺服器僅發送他們作為主控的區域的通知來禁用 (BIND: notify master;)，或者完全跳過NS基於通知的通知，以支持在配置中明確定義的通知。（綁定notify explicit;：）

權威定義

上面的問題包含一個謬誤：

記憶體 DNS 伺服器不使用它們來確定域的權威伺服器。這由在註冊商級別定義的名稱伺服器粘合處理。註冊商從不使用此資訊來生成粘合記錄。

這是一個容易得出的結論，但並不准確。NS記錄和粘合記錄數據（例如在您的註冊商帳戶中定義的數據）不具有權威性。理所當然地，它們不能被認為比駐留在被授權的伺服器上的數據“更權威”。推薦人沒有設置aa（權威答案）標誌這一事實強調了這一點。

為了顯示：

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

請注意上述回復中缺少aa標誌。推薦本身並不權威。另一方面，被引用的伺服器上的數據是權威的。

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

也就是說，這種關係可能會變得非常混亂，因為如果沒有在推薦的父方定義NS的非權威記錄，就不可能了解這些記錄的權威版本。NS如果他們不同意會發生什麼？

• 簡短的回答是“不一致的行為”。
• 長答案是，名稱伺服器最初會將引用（和粘合）的所有內容存根到空記憶體上，但是這些NS,A和AAAA記錄最終可能會在刷新時被替換。刷新發生在這些臨時記錄上的 TTL 到期時，或者當有人明確請求這些記錄的答案時。
• A和區域外AAAA數據的記錄（即為區域外數據定義粘合的名稱com伺服器，如. （RFC 2181）com``example.net
• 當NS引用的父方和子方之間的記錄值不同時（例如輸入註冊商控制面板的名稱伺服器與NS位於相同伺服器上的記錄不同），所經歷的行為將不一致，直至並包括子NS記錄被完全忽略。這是因為標準沒有很好地定義行為，並且實現在不同的遞歸伺服器實現之間有所不同。換句話說，只有當域的名稱伺服器定義在引用的父方和子方之間保持一致時，才能期望在 Internet 上保持一致的行為。

總而言之，如果在引用的父端定義的記錄與這些記錄的權威版本不一致，整個網際網路的遞歸 DNS 伺服器將在目的地之間反彈。最初，推薦中存在的數據將是首選，僅由權威定義替換。由於網際網路上不斷地從頭開始重建記憶體，因此網際網路不可能使用這種配置來解決單一版本的現實。如果根據標準，權威記錄正在做一些非法的事情，例如將NS記錄指向由 a 定義的別名CNAME，這變得更加難以排除故障；對於拒絕違規的軟體，域將在工作和損壞之間交替。（即 ISC BIND/命名）

RFC 2181 §5.4.1為該數據的可信度提供了一個排名表，並明確指出與引用和粘合相關的記憶體數據不能作為對它們引用的記錄的顯式請求的答案返回。

5.4.1. Ranking data

  When considering whether to accept an RRSet in a reply, or retain an
  RRSet already in its cache instead, a server should consider the
  relative likely trustworthiness of the various data.  An
  authoritative answer from a reply should replace cached data that had
  been obtained from additional information in an earlier reply.
  However additional information from a reply will be ignored if the
  cache contains data from an authoritative answer or a zone file.

  The accuracy of data available is assumed from its source.
  Trustworthiness shall be, in order from most to least:

    + Data from a primary zone file, other than glue data,
    + Data from a zone transfer, other than glue,
    + The authoritative data included in the answer section of an
      authoritative reply.
    + Data from the authority section of an authoritative answer,
    + Glue from a primary zone, or glue from a zone transfer,
    + Data from the answer section of a non-authoritative answer, and
      non-authoritative data from the answer section of authoritative
      answers,
    + Additional information from an authoritative answer,
      Data from the authority section of a non-authoritative answer,
      Additional information from non-authoritative answers.

  <snip>

  Unauthenticated RRs received and cached from the least trustworthy of
  those groupings, that is data from the additional data section, and
  data from the authority section of a non-authoritative answer, should
  not be cached in such a way that they would ever be returned as
  answers to a received query.  They may be returned as additional
  information where appropriate.  Ignoring this would allow the
  trustworthiness of relatively untrustworthy data to be increased
  without cause or excuse.

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