当 DNS 缓存的准确性受到质疑时，dig +trace这往往是确定面向 Internet 的 DNS 记录的权威答案的推荐方法。这似乎在与 配对时特别有用+additional，它也显示胶水记录。
有时似乎在这一点上存在一些分歧——有人说它依赖于本地解析器来查找中间名称服务器的 IP 地址，但命令输出没有提供任何迹象表明这发生在根目录的初始列表之外名称服务器。+trace如果 的目的是从根服务器开始并向下追踪，那么假设情况并非如此似乎是合乎逻辑的。（至少如果你有正确的根名称服务器列表）
是否dig +trace真的将本地解析器用于根名称服务器之后的任何内容？
这显然是一个分阶段的问答，但这往往会使人感到困惑，而且我找不到涵盖该主题的规范问题。
dig +trace是一个很好的诊断工具，但其设计的一个方面被广泛误解：将要查询的每台服务器的 IP 都是从您的解析器库中获得的。这很容易被忽视，并且通常只会在您的本地缓存对缓存的名称服务器有错误答案时才成为问题。详细分析
这更容易用输出样本分解；我将省略第一个 NS 代表团之后的所有内容。
. IN NS命中本地解析器，在本例中为 Comcast。(75.75.75.75) 这很容易发现。serverfault.com. IN A并运行的e.root-servers.net.，它是从我们刚刚获得的根名称服务器列表中随机选择的。它的 IP 地址为192.203.230.10，并且由于我们+additional启用了它，它似乎来自胶水。com.TLD 名称服务器。dig没有e.root-servers.net.从胶水中获取 IP 地址。在后台，这是真正发生的事情：
+trace欺骗并咨询本地解析器以获取下一跳名称服务器的 IP 地址，而不是咨询胶水。鬼鬼祟祟的！这通常是“足够好”并且不会对大多数人造成问题。不幸的是，有一些极端情况。如果出于某种原因您的上游 DNS 缓存为名称服务器提供了错误的答案，则此模型将完全崩溃。
现实世界的例子：
在上述情况下，
+trace将建议域所有者自己的名称服务器是问题的根源，并且您只需一个电话就可以错误地告诉客户他们的服务器配置错误。您是否可以（或愿意）做某事是另一回事，但拥有正确的信息很重要。dig +trace是一个很棒的工具，但与任何工具一样，您需要知道它能做什么和不能做什么，以及当它证明不够用时如何手动解决问题。编辑：
还应该注意的是，
dig +trace不会警告您有关NS指向CNAME别名的记录。这是 ISC BIND（可能还有其他人）不会尝试纠正的 RFC 违规行为。+trace将非常乐意接受A它从本地配置的名称服务器获取的记录，而如果 BIND 要执行完全递归，它将拒绝整个区域并返回 SERVFAIL。如果存在胶水，这可能很难排除故障；这将正常工作，直到 NS 记录被刷新，然后突然中断。当记录指向别名时，无胶委托总是会破坏 BIND 的递归。
NS另一种跟踪 DNS 解析的方法是使用dnsgraph（完全披露：我写了这个），而不使用本地解析器来查找根名称服务器。它有一个命令行工具和一个网络版本，您可以在http://ip.seveas.net/dnsgraph/找到一个实例
以 serverfault.com 为例，它现在实际上有一个 DNS 问题：
这个线程很晚，但我认为关于为什么 dig +trace 对本地解析器使用递归查询的问题部分没有得到直接解释，这个解释与 dig +trace 结果的准确性有关。
在对根区域的 NS 记录进行初始递归查询后，dig 可能会在以下条件下向本地解析器发出后续查询：
由于下一次迭代查询的响应大小超过 512 字节，引用响应被截断
dig 从引用响应的 AUTHORITY 部分中选择一个 NS 记录，其相应的 A 记录（胶水）在 ADDITIONAL 部分中丢失
因为 dig 只有来自 NS 记录的域名，所以 dig 必须通过查询本地 DNS 服务器将名称解析为 IP 地址。这是根本原因（双关语，抱歉）。
AndrewB 有一个与我刚才描述的不完全一致的示例，因为选择的根区域 NS 记录：
. 121459 IN NS e.root-servers.net.有对应的A记录：
e.root-servers.net. 354907 IN A 192.203.230.10但是请注意，e-root 没有相应的 AAAA 记录，其他一些根服务器也没有 AAAA 记录。
另外，请注意响应的大小：
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms496 字节是已被截断的响应的常见大小（即下一个粘合记录将大于 16 字节，从而使响应超过 512 字节）。换句话说，在查询 root 的 NS 记录时，完整的 AUTHORITY 和完整的 ADDITIONAL（A 和 AAAA 记录）将超过 512 字节，因此任何未通过 EDNS0 选项指定更大查询大小的基于 UDP 的查询将得到一个在 ADDITIONAL 部分某处被截断的响应，如上面的跟踪所示（只有 f、h、i、j 和 k 有 A 和 AAAA 粘合记录）。
缺少 e.root-servers.net 的 AAAA 记录以及对“NS”的响应大小。查询强烈建议下一个递归查询是出于我声称的原因而完成的。也许客户端 O/S 支持 IPv6，并且更喜欢 AAAA 记录——或者其他一些原因。
但无论如何，在读完这个帖子后，我研究了 dig +trace 在对 root 的初始查询之后执行递归查询的现象。根据我的经验，选择没有相应胶合 A/AAAA 记录的 NS 记录与挖掘然后将该记录的递归查询发送到本地 DNS 之间的对应关系是 100%。而反之亦然——我还没有看到从referral中选出的NS记录有对应的胶水记录时的递归查询。