dig + trace总是准确的吗？

当对DNS缓存的准确性提出疑问时，它dig +trace往往是确定面向Internet的DNS记录的权威性答案的推荐方法。当与配合使用时+additional，这似乎特别有用，该工具还显示了粘合记录。

有时，在这一点上似乎存在一些分歧-有人说它依赖于本地解析器来查找中间名称服务器的IP地址，但是命令输出没有提供任何迹象表明这正在超出根目录的初始列表名称服务器。似乎合理的假设是，如果这样做的目的+trace不是要在根服务器上启动并向下追溯。（至少如果您具有正确的根名称服务器列表）

dig +trace对于根名称服务器以外的内容，是否真的使用本地解析器？

这显然是一个阶段性的问答环节，但这往往会使人们感到困惑，而且我找不到涵盖该主题的规范问题。

dig +trace虽然它是一种出色的诊断工具，但其设计的一个方面却被广泛误解：要查询的每台服务器的IP都是从您的解析器库中获得的。这很容易被忽略，并且通常只会在您的本地缓存对缓存的名称服务器有错误答案时才成为问题。

详细分析

用输出样本更容易分解。我将忽略第一个NS代表团之后的所有事情。

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• . IN NS（根名称服务器）的初始查询命中本地解析器，在本例中为Comcast。（75.75.75.75）这很容易发现。
• 下一个查询serverfault.com. IN A针对e.root-servers.net.，并针对进行查询，该查询是从我们刚获得的根名称服务器列表中随机选择的。它的IP地址为192.203.230.10，并且由于我们已+additional启用，因此它似乎是来自胶水的。
• 由于对于serverfault.com而言不是权威，因此将其委派给com.TLD名称服务器。
• 从这里的输出中不明显的是，dig没有e.root-servers.net.从胶水获得IP地址。

在后台，这是实际发生的情况：

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+trace作弊并咨询了本地解析器，以获取下一个跃点名称服务器的IP地址，而不是咨询胶水。鬼！

这通常“足够好”，不会对大多数人造成问题。不幸的是，有一些极端的情况。如果出于任何原因，您的上游DNS缓存为名称服务器提供了错误的答案，则此模型将完全崩溃。

真实的例子：

• 域过期
• 胶水指向注册商重定向名称服务器
• 为ns1和ns2缓存了虚假IP。yourdomain.com
• 使用恢复的胶水更新域
• 带有虚假名称服务器IP的所有缓存都会继续将人们带到一个表示该域名正在出售的网站

在上述情况下，+trace将提示域所有者自己的名称服务器是问题的根源，而您与错误地告诉客户其服务器配置错误的距离仅一个电话之遥。是否可以（或愿意）做某事是另一个故事，但是拥有正确的信息很重要。

dig +trace 是一个很棒的工具，但是像其他任何工具一样，您需要了解它的作用和不作用，以及在证明不足时如何手动解决问题。

编辑：

还应注意，它dig +trace不会对NS指向CNAME别名的记录发出警告。这是RFC违规，ISC BIND（可能还有其他）将不会尝试更正。+trace我们将非常乐意接受A从您本地配置的名称服务器获取的记录，而如果BIND要执行完全递归，它将使用SERVFAIL拒绝整个区域。

如果存在胶水，要排除故障可能很棘手。直到刷新NS记录，然后突然中断，它才能正常工作。当记录指向别名时，无胶委托将始终破坏BIND的递归NS。

除了查找根名称服务器之外，不使用本地解析器进行任何其他操作来跟踪DNS解析的另一种方法是使用dnsgraph（完整披露：我写了这篇文章）。它具有命令行工具和Web版本，您可以在http://ip.seveas.net/dnsgraph/中找到其实例。

serverfault.com的示例，目前实际上存在DNS问题：

对该线程的讨论很晚，但是我认为关于dig + trace为什么对本地解析器使用递归查询的问题的一部分尚未得到直接解释，并且这种解释与dig + trace的结果的准确性有关。

在对根区域的NS记录进行初始递归查询后，dig可以在以下情况下向本地解析器发出后续查询：

1. 由于下一个迭代查询的响应大小超过512个字节，因此引用响应被截断

2. dig从推荐响应的AUTHORITY部分中选择一个NS记录，在ADDITIONAL部分中缺少相应的A记录（胶水）

由于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 ms

496字节是已被截断的响应的常用大小（即，下一个粘合记录将大于16字节，从而使响应超过512字节）。换句话说，在查询根的NS记录时，完整的AUTHORITY和完整的ADDITIONAL（A和AAAA记录）都将超过512字节，因此，任何未通过EDNS0选项指定较大查询大小的基于UDP的查询都将如上面的迹线所示（在f，h，i，j和k中只有A和AAAA胶水记录），在ADDITIONAL部分的某个地方截取了一个响应。

缺少e.root-servers.net的AAAA记录以及对“ NS”的响应大小。查询强烈建议下一个递归查询是出于我声称的原因而完成的。客户端O / S可能支持IPv6，并且更喜欢AAAA记录-或其他原因。

但是无论如何，在阅读了该线程之后，我研究了dig + trace在针对root的初始查询之后执行递归查询的现象。根据我的经验，选择没有相应A / AAAA粘合记录的NS记录与挖掘然后向该DNS发送该记录的递归查询之间的对应关系是100％。反之亦然-当从引用中选择的NS记录具有相应的粘合记录时，我还没有看到递归查询。