为什么 dig +trace 似乎忽略了 DNS 粘合记录？
Edd*_*die 6 domain-name-system glue-record dig
这是我的问题：
- 为什么
dig +trace忽略 Glue 记录？ - 此行为是否特定于
digordig +trace，或者递归名称服务器是否也“手动验证”它收到的粘合记录？
这是更长的解释：
这是引发这些问题的 DNS 事务的完整捕获。
我正在使用 dig +trace 来跟踪 DNS 过程，以进行简单的 A 记录解析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 根 NS 还提供“附加记录”，即与每个 .com TLD 名称服务器 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
官方文档称，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