在NS記錄中找到權威伺服器時，是否檢查A記錄的ip地址？

我試圖了解什麼是 NS 記錄，粘合記錄如何構成它的一部分以及之後會發生什麼？據我了解，NS 記錄包含權威名稱伺服器的主機名或可能保存有關在何處找到它的資訊的主機名。假設沒有記憶體：

1.) 遞歸器如何知道 NS 記錄是指向權威名稱伺服器還是將遞歸器指向另一個名稱伺服器？還是兩者都一樣？我的意思是 NS 記錄中的條目只是“盡力而為”的名稱伺服器，它們可能具有權威名稱伺服器的主機名，或者可能指向可能具有或不具有有關權威名稱伺服器的 IP 地址資訊的名稱伺服器？

2.) 一旦遞歸器在特定名稱伺服器（例如 TLD 名稱伺服器）的 NS 記錄中找到條目，它是檢查 A 記錄以找到相應的 IP 地址還是再次重複整個 DNS 過程（查詢根名稱伺服器，然後是 TLD 名稱伺服器等）？

3.）“粘合”究竟是如何工作的，我知道它與避免遞歸查詢有關，但是否在 A 記錄中找到粘合 IP 地址？在沒有粘合的情況下，這是否意味著對於 2.) 整個 DNS 過程為該主機名重新開始（我猜來自 NS 記錄）？

4.) 在 Cloudfare 對 NS 記錄的解釋中，該範例包含一個 @ 並且我在此範例區域 DNS、範例區域文件中也看到了它，@ 或將該列留空實際上是什麼意思？

如果有人能幫助我理解這一點，我將非常感激，因為我很難弄清楚。先感謝您。

我試圖了解什麼是 NS 記錄，粘合記錄如何構成它的一部分以及之後會發生什麼？

膠水記錄不是記錄的一部分NS。

膠水記錄或膠水是A和AAAA記錄，唯一不同的是它們是在代表團的父方發布而不是（實際上是另外）在權威方發布，即代表團的孩子。

你的大部分問題都很難回答，因為你沒有使用具體的例子。如果您查詢權威或遞歸名稱伺服器，事情取決於很多，所以不清楚您在做什麼。

1.) 遞歸器如何知道 NS 記錄是指向權威名稱伺服器還是將遞歸器指向另一個名稱伺服器？

NS記錄總是指向權威的域名伺服器，這是他們的定義。

RFC 1034 §3.6：

            NS
           the authoritative name server for the domain

（當然，客戶端無法檢查這是否正確，因為如果沒有 DNSSEC，這可能會在路徑中或通過您正在查詢的遞歸解析器進行更改）。

我的意思是 NS 記錄中的條目只是“盡力而為”的名稱伺服器

不。我不知道你從哪裡得到“盡力而為”的東西，但NS記錄是權威的名稱伺服器，僅此而已。

2.) 一旦遞歸器在特定名稱伺服器（例如 TLD 名稱伺服器）的 NS 記錄中找到條目，它是檢查 A 記錄以找到相應的 IP 地址還是再次重複整個 DNS 過程（查詢根名稱伺服器，然後是 TLD 名稱伺服器等）？

一條NS記錄給出了一個名字。該名稱需要解析為一個或多個 IPv4 或 IPv6 地址，因此該名稱的任何使用者（客戶端）都需要將該名稱解析為 IP，這通過與其他任何東西完全相同的機制發生，當然除了記憶體在那裡被大量使用（因此主要的名稱伺服器名稱在全球範圍內被許多域使用，因此它們的 IP 不經常被解析）。所以，是的，它從根源開始……當然，除了存在布魯斯，以及何時可以接受。

3.）“粘合”究竟是如何工作的，我知道它與避免遞歸查詢有關，但是否在 A 記錄中找到粘合 IP 地址？在沒有粘合的情況下，這是否意味著對於 2.) 整個 DNS 過程為該主機名重新開始（我猜來自 NS 記錄）？

簡單的。想像一下你有一個example.com域，它是從com. 所以.com名稱伺服器有NS指向example.com其名稱伺服器的記錄。現在想像一下，您選擇“在轄區內”的情況，其中域名伺服器本身位於域“下”，也就是域名伺服器是ns1.example.comand ns2.example.com。那些將是NS父母的記錄。但是，儘管如此，解決方案是不可能的。你問父母“誰負責（權威）example.com”，然後你得到“聯繫人ns1.example.com和ns2.example.com”，但要做到這一點，你需要解決這兩個名字，因此，再次從根開始，你又回到“誰負責（權威）example.com“如此無盡的循環。

在這種情況下，需要有粘合劑，即父級的A/AAAA記錄，客戶端在收到NS回复的同時返回。

讓我們舉一個真實的例子，帶有現在的痕跡，域icann.org。

首先什麼是.org域名伺服器？

$ dig org. NS +short
c0.org.afilias-nst.info.
d0.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
a0.org.afilias-nst.info.

讓我們選擇其中任何一個並要求提供以下NS記錄icann.org：

$ dig @b2.org.afilias-nst.org. icann.org NS

; <<>> DiG 9.18.4 <<>> @b2.org.afilias-nst.org. icann.org NS
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62392
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 4c1ae1af0f0d1e3f
;; QUESTION SECTION:
;icann.org.     IN NS

;; QUERY SIZE: 50

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62392
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;icann.org.     IN NS

;; AUTHORITY SECTION:
icann.org.      1h IN NS a.icann-servers.net.
icann.org.      1h IN NS b.icann-servers.net.
icann.org.      1h IN NS c.icann-servers.net.
icann.org.      1h IN NS ns.icann.org.

;; ADDITIONAL SECTION:
ns.icann.org.       1h IN A 199.4.138.53
ns.icann.org.       1h IN AAAA 2001:500:89::53

正如預期的那樣，該AUTHORITY部分為您提供了NS記錄列表。但是這裡有一個ADDITIONAL部分。為什麼？因為 4 個名稱伺服器之一icann.org是ns.icann.org在轄區內。為了能夠解決它，父級（.orgnamesevers）也必鬚髮布膠水，它們是A/AAAA記錄……並且它們在該ADDITIONAL部分中，因此客戶端現在可以立即聯繫ns.icann.org而無需進一步的 DNS 查詢，因為它已經有了 IP地址。

看著那個可能會想知道為什麼不是每個人都只使用膠水而不使用其他東西，因為它看起來“更好”（更快，沒有依賴性等）？事實上，它並沒有更好，它有優點和缺點（這就是為什麼在大多數情況下，一個好的域會使用一些在轄區內的名稱伺服器和一些在轄區外的名稱伺服器）。缺點：

• IP 地址必須在系統資料庫中進行管理；如果它們發生變化，則需要由域的註冊商代表客戶進行更改（在 DNS 之外，通常使用 EPP）；這經常被遺忘並產生很多問題
• 即使icann.org完全啟用了 DNSSEC，來自.org權威名稱伺服器的回復也不會簽署該ADDITIONAL部分中的記錄，這意味著它們可以在路徑上更改而不會檢測到更改

4.) 在 Cloudfare 對 NS 記錄的解釋中，該範例包含一個 @ 並且我在此範例區域 DNS、範例區域文件中也看到了它，@ 或將該列留空實際上是什麼意思？

兩者都不是真正的 DNS 的一部分，而是稱為“主區域文件格式”的約定，在 RFC1035 的 §5 中鬆散地定義：

最後兩種形式代表 RR。如果 RR 的條目以空白開頭，則假定 RR 歸最後聲明的所有者所有。

和

@ 一個獨立的@ 用於表示目前原點。

這只是意味著，如果您正在為 zone 編寫example.com任何記錄的 zonefile，您可以編寫example.com.（這裡最後一個點非常重要，如果您忘記它，它表示相對，因此example.com該文件中的 name 真正表示example.com.example.com.）或者@它是同樣的事情，所以由你決定你選擇哪一個。為什麼有用？因為對於某些通用區域，您可以為多個區域擁有完全相同的區域內容。如果您編寫區域內容，@因此不必在區域文件中寫下區域名稱，您可以為多個區域重複使用同一個文件，從而簡化維護。

至於“將”列再次留空，這是您可以使用或不使用的快捷方式。

下面兩個是一樣的：

foobar IN A 192.0.2.42
foobar IN TXT "I am foobar"

和

foobar IN A 192.0.2.42
      IN TXT "I am foobar"

（空格數量僅用於對齊，不需要具體數量）

甚至：

foobar IN TXT "I am foobar"
IN A 192.0.2.42

在第二種情況下你可以寫的更少，但缺點是你不能再輕鬆地寫更多的行，因為第二行需要第一行的上下文。

這是第一個名稱伺服器（綁定）的實現細節，並描述了區域的內容如何寫入所謂的文本區域文件中。其他名稱伺服器必須遵循該約定並支持相同的格式。

但是您永遠不會對空名稱進行 DNS 查詢@（這種情況甚至是不可能的）。所以所有這些都隱藏在名稱伺服器中。

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