dig +trace 总是准确的吗？

Question

dig +trace 总是准确的吗？

And*_*w B 31 domain-name-system nameserver glue-record dig

当 DNS 缓存的准确性有问题时，dig +trace往往是确定面向 Internet 的 DNS 记录的权威答案的推荐方法。这在与配对时似乎特别有用+additional，这也显示了胶水记录。

有时似乎在这一点上存在一些分歧——有人说它依赖本地解析器来查找中间名称服务器的 IP 地址，但命令输出没有提供任何迹象表明这超出了 root 的初始列表名称服务器。如果目的+trace是从根服务器开始并跟踪您的方式，那么假设情况并非如此，这似乎是合乎逻辑的。（至少如果您有正确的根名称服务器列表）

是否dig +trace真的将本地解析器用于根名称服务器之外的任何内容？

Answer 1

And*_*w B 27

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

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

Run Code Online (Sandbox Code Playgroud)

对. 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)

Run Code Online (Sandbox Code Playgroud)

+trace欺骗并咨询本地解析器以获取下一跳名称服务器的IP地址，而不是咨询胶水。偷偷摸摸！

这通常“足够好”，不会对大多数人造成问题。不幸的是，存在边缘情况。如果出于某种原因，您的上游 DNS 缓存为名称服务器提供了错误的答案，则此模型将完全失效。

现实世界的例子：

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

在上述情况下，+trace将表明域所有者自己的名称服务器是问题的根源，您只需一个电话即可错误地告诉客户他们的服务器配置错误。是否可以（或愿意）做某事是另一回事，但拥有正确的信息很重要。

dig +trace 是一个很棒的工具，但与任何工具一样，您需要知道它做什么和不做什么，以及如何在证明不足时手动解决问题。

编辑：

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

如果存在胶水，这可能很难解决；这将正常工作，直到刷新 NS 记录，然后突然中断。当记录指向别名时，无胶委托总是会破坏 BIND 的递归NS。

Answer 2

Den*_*ker 11

除了查找根名称服务器之外，另一种不使用本地解析器来跟踪 DNS 解析的方法是使用dnsgraph（完全披露：我写了这个）。它有一个命令行工具和一个网络版本，你可以在http://ip.seveas.net/dnsgraph/找到一个实例

serverfault.com 的示例，它现在实际上有一个 DNS 问题：

在此处输入图片说明

我这个闷闷不乐的书呆子想说这在技术上不是一个答案。我的 DNS 管理员认为它很棒而且*完全不在乎*。 (5认同)

归档时间：	12 年，6 月前
查看次数：	20317 次
最近记录：	6 年，10 月前