以下是我的问题：
- 为什么要
dig +trace忽略 Glue Records？ - 此行为是否特定于
dig或dig +trace，或者递归名称服务器是否也“手动验证”其收到的粘合记录？
以下是更详细的解释：
这是完整的截图引发这些问题的 DNS 事务。
我正在使用 dig +trace 跟踪 DNS 过程，以对 进行简单的 A 记录解析www.pizza.com。正如预期的那样，第一个请求是发给我的 DNS 服务器，寻找根名称服务器（数据包 #1）。然后我的 DNS 服务器响应所有 13 个名称服务器的列表（数据包 #2）：
请注意，在数据包#2 中，没有包含任何附加记录。这提示我的客户端查找每个提供的根名称服务器的 A 记录。这发生在数据包 3 到 28 中：
到目前为止，这都是意料之中的事。但接下来会变得有趣。
数据包 29 是我的客户端，它向 192.5.5.241 (f.root-servers.net) 发出请求，查找 www.pizza.com 的 A 记录。显然，Root NS 不知道 A 记录，因此改为提供.comTLD 名称服务器的 FQDN（a.gtld-servers.net、b.gtld-servers.net 等）。请注意，F Root NS 还提供“附加记录”，即与每个 .com TLD 名称服务器 FQDN 对应的 A 记录：
接下来就是我的问题所在。即使我的客户端收到了与 .com TLD 名称服务器相关的 A 记录。它仍然决定为每个 .com TLD 名称服务器发出 A 记录请求（数据包 31-56）：
当我的客户端向 .com TLD 名称服务器请求 www.pizza.com 的 A 记录并收到 Pizza.com 域的权威 NS 记录时，同样的事情发生了（数据包 57-66）。.com TLD 名称服务器提供了粘合记录，但我的客户端仍然会手动解析每个 NS 服务器的 A 记录。
我的问题是：
- 为什么要
dig +trace忽略 Glue Records？ - 此行为是否特定于
dig或dig +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 将首先请求对根 (“.”) 具有权威性的服务器的 NS 记录。这些记录可能带有或不带有胶水 - 即可用于 dig 必须发送的下一个查询的 A 和 AAAA 记录。如果未提供胶水，无论是在对根名称服务器的初始查询中，还是在委派之后，dig 将恢复为递归查询 /etc/resolv.conf 中列出的服务器以获取所需的 A/AAAA RRset。
指定@server 不会改变此行为 - 以这种方式指定的服务器将仅查询对根（“。”）具有权威性的服务器的 NS 记录。
这可能是错误的文档或挖掘中的一个错误。