域名系统 – 挖掘痕迹总是准确的吗？

发布时间：2020-12-14 04:16:07 所属栏目：大数据来源：网络整理

导读：当DNS缓存的准确性受到质疑时,挖掘跟踪往往是确定面向互联网的DNS记录的权威答案的推荐方式.当与附加配对时,这似乎特别有用,它还显示了胶水记录. 偶尔在这一点上似乎存在一些分歧 – 有些人说它依赖于本地解析器来查找中间名称服务器的IP地址,但是命令输出没

当DNS缓存的准确性受到质疑时,挖掘跟踪往往是确定面向互联网的DNS记录的权威答案的推荐方式.当与附加配对时,这似乎特别有用,它还显示了胶水记录.

偶尔在这一点上似乎存在一些分歧 – 有些人说它依赖于本地解析器来查找中间名称服务器的IP地址,但是命令输出没有表明这种情况发生在root的初始列表之外域名服务器.假设如果跟踪的目的是从根服务器开始并追溯下去,那么这似乎是合乎逻辑的. (至少如果你有正确的根名称服务器列表)

dig trace是否真的使用本地解析器来处理根名称服务器之外的任何内容？

解决方法

这显然是一个阶段性的Q& A,但 this tends to confuse people often和我无法找到涵盖该主题的规范问题.

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的.在A中,运行e.root-servers.net.,从我们刚刚获得的根名称服务器列表中随机选择.它的IP地址为192.203.230.10,由于我们有额外的启用它似乎来自胶水.
>由于它对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)

?跟踪欺骗并咨询本地解析器以获取下一跳名称服务器的IP地址,而不是咨询胶水.偷偷摸摸的！

这通常“足够好”并且不会对大多数人造成问题.不幸的是,有边缘情况.如果由于某种原因您的上游DNS缓存为名称服务器提供了错误的答案,则此模型完全崩溃.

现实世界的例子：

>域名到期
>胶水在注册商重定向名称服务器上重新命名
>为ns1和ns2.yourdomain.com缓存伪造的IP
>域恢复使用恢复的胶水
>使用伪名称服务器IP的任何缓存继续将人们发送到一个网站,该网站称该域名是待售的

在上述情况下,跟踪将表明域所有者自己的名称服务器是问题的根源,并且您只是一次呼叫,而不是错误地告诉客户他们的服务器配置错误.是否能够(或愿意)做某事是另一回事,但拥有正确的信息非常重要.

dig trace是一个很棒的工具,但是像任何工具一样,你需要知道它做了什么和不做什么,以及如何在证明不足时手动解决问题.

编辑：

还应该注意,dig trace不会警告你指向CNAMEaliases的NS记录.这是一种RFC违规,ISC BIND(可能还有其他人)不会尝试纠正. trace将非常乐意接受从本地配置的名称服务器获取的A记录,而如果BIND要执行完全递归,则它将使用SERVFAIL拒绝整个区域.

如果存在胶水,这可能很难排除故障;这将工作得很好until the NS records are refreshed,然后突然休息.当NS记录指向别名时,无柄委托将始终打破BIND的递归.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!