為什麼 dig +trace 似乎忽略了 DNS 粘合記錄？
以下是我的問題：
- 為什麼
dig +trace忽略 Glue 記錄？- 這種行為是否特定於
digordig +trace，或者遞歸名稱伺服器是否也“手動驗證”它接收的粘合記錄？這是更長的解釋：
這是引發這些問題的 DNS 事務的完整擷取。
我正在使用 dig +trace 來跟踪 DNS 流程，以便為
www.pizza.com. 正如預期的那樣，第一個請求是對我的 DNS 伺服器，尋找根名稱伺服器（數據包 #1）。然後，我的 DNS 伺服器以所有 13 個名稱伺服器的列表（數據包 #2）進行響應：
請注意，在 Packet#2 中，沒有包含附加記錄。這會提示我的客戶查找每個提供的根名稱伺服器的 A 記錄。這發生在數據包 3 到 28 中：
到目前為止，這是意料之中的。但接下來它變得有趣了。
數據包 29 是我的客戶端，向 192.5.5.241 (f.root-servers.net) 發出請求，尋找 www.pizza.com 的 A 記錄。顯然，根 NS 不知道 A 記錄，因此提供了
.comTLD 名稱伺服器的 FQDN（a.gtld-servers.net、b.gtld-servers.net 等）。注意，F Root NS 還提供了“Additional Records”，即與每個 .com TLD Name Server FQDN 對應的 A 記錄：
接下來是我的問題圍繞的問題。即使我的客戶收到了與 .com TLD 名稱伺服器相關的 A 記錄。它仍然決定為每個 .com TLD 名稱伺服器（數據包 31-56）發出 A 記錄請求：
當我的客戶向 .com TLD 名稱伺服器詢問 www.pizza.com 的 A 記錄並接收 Pizza.com 域的權威 NS 記錄時，同樣的事情發生在更遠一點（數據包 57-66）。.com TLD 名稱伺服器提供膠水記錄，但我的客戶端仍然出去手動解析每個 NS 伺服器的 A 記錄。
所以我的問題是：
- 為什麼
dig +trace忽略 Glue 記錄？- 這種行為是否特定於
digordig +trace，或者遞歸名稱伺服器是否也“手動驗證”它接收的粘合記錄？我正在使用這個版本的 Dig：
DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1並執行以下命令：
$ dig www.pizza.com +trace -4編輯 1：也在頂部添加了問題，以便更容易理解我在詢問的內容
編輯2： 這個問題與我的相似，但不完全相同。在這個問題中，@Andrew B 確認了我看到的相同行為：
+trace欺騙並諮詢本地解析器以獲取下一跳名稱伺服器的IP地址，而不是諮詢膠水。但我的問題是具體為什麼
dig +trace要這樣做？有什麼好處？它試圖提供什麼？這似乎只是更多的工作，有時甚至會導致 dig 如何解析地址以及實際 DNS 如何解析地址的不准確（如另一個問題所示）。然而，另一個問題似乎確實回答了我的第二個問題。似乎這種忽略粘合記錄的行為是特定於探勘的，而不是“正常”遞歸名稱伺服器的行為方式。
官方文件說 dig 可以使用粘合記錄進行後續查詢，但如果沒有提供粘合記錄，可能會恢復為遞歸查詢
$$ 1 $$:
當使用 +trace 時，dig 仍可能向 /etc/resolv.conf 中列出的伺服器發送查詢當按照 +trace 選項的指定迭代地遵循委派時，dig 將首先請求具有 root 權限的伺服器的 NS 記錄（“。” ）。這些可能會或可能不會提供膠水 - 即 A 和 AAAA 記錄可用於 dig 必鬚髮送的下一個查詢。如果沒有提供膠水，無論是在對根名稱伺服器的初始查詢中，還是稍後在進行委託時，dig 將恢復為遞歸查詢 /etc/resolv.conf 中列出的伺服器以獲得所需的 A/AAAA RRset。
指定@server 不會更改此行為 - 以這種方式指定的伺服器只會被查詢以獲取具有 root 權限的伺服器（“.”）的 NS 記錄。
這可能是錯誤的文件或探勘中的錯誤。
$$ 1 $$ https://kb.isc.org/docs/aa-00208