服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 挖+追踪总是准确的？
Intereting Posts
Hyper-V Guest RDP不断提问错误凭据 Windows 2012 Server DHCP忽略保留 无法获得RT的新实例启动 apache2 tomcat6单个实例或多个实例 安全访问EventLog 我可以使用通配符木偶包确保覆盖多个版本 Cisco IOS：显示传入的Telnet会话 pipe理打印作业 – 将不同用户的作业输出到不同的纸盒 NGINX不caching内容 虚拟化Linux + Windows Server Microsoft Azure AD Connect – 可信域的密码同步 卸载设备或资源繁忙; 已经尝试过：mount，lsof，fuser，exportfs，ps axf networking负载平衡Windows服务器2008 检查是否从bash脚本安装了ruby gem GPO授予用户安装允许的软件的权限

挖+追踪总是准确的？

当DNS高速caching的准确性存在问题时， dig +trace往往是确定面向互联网的DNSlogging的权威答案的推荐方式。 这也似乎是特别有用的时候也配对+additional ，这也显示胶水logging。

偶尔在这一点上似乎有一些分歧 – 有些人说它依靠本地的parsing器来查找中间名称服务器的IP地址，但是命令输出并没有提供这种情况，这是超出最初的根目录域名服务器。 假设如果+trace的目的是从根服务器开始并追踪你的方向，情况就不是这样。 （至less如果你有根名称服务器的正确名单）

dig +trace是否真的使用本地parsing器来处理超过根名称服务器的任何事情？

    这显然是一个阶段性的问答，但是这往往会使人们经常感到困惑，而我无法find一个涵盖这个话题的规范性问题。

    dig +trace是一个很好的诊断工具，但是其devise的一个方面被广泛地误解了： 每个要查询的服务器的IP都是从parsing器库中获得的 。 这很容易被忽略，而且当你的本地caching对caching的域名服务器有错误的答案时，往往只会成为一个问题。

    详细的分析

    用输出样本更容易分解; 我会忽略第一个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 . IN NS （根名称服务器）命中本地parsing器，在这种情况下是Comcast。 （ 75.75.75.75 ）这很容易被发现。
    • 下一个查询是为serverfault.com. IN A serverfault.com. IN A和运行反对e.root-servers.net. ，从我们刚刚得到的根名称服务器列表中随机select。 它有一个IP地址192.203.230.10 ，因为我们有+additional启用它似乎来自胶水。
    • 由于它不是serverfault.com的权威，因此将其委托给com. TLD名称服务器。
    • 从这里输出不明显的是， dig并没有得到e.root-servers.net.的IP地址e.root-servers.net. 从胶水。

    在后台，这是真正发生的事情： 

     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欺骗，并咨询本地parsing器获取下一跳名称服务器的IP地址，而不是咨询胶水。 偷偷摸摸的！

    这通常是“足够好”，不会给大多数人造成问题。 不幸的是，有边缘情况。 如果由于某种原因你的上游DNScaching为名称服务器提供了错误的答案，那么这个模型就会完全崩溃。

    现实世界的例子：

    • 域到期
    • 胶在注册商redirect名称服务器被重新命名
    • 伪造的IP被caching了ns1和ns2.yourdomain.com
    • 域被更新与恢复胶水
    • 任何具有虚假名称服务器IP的caching都会继续将人员发送到说明该域名正在出售的网站

    在上面的例子中， +trace会表明域名所有者自己的域名服务器是问题的根源，而您却错误地告诉客户他们的服务器configuration错误。 无论是你能够（或愿意）做的事情都是另一回事，但拥有正确的信息是很重要的。

    dig +trace是一个很好的工具，但是和其他工具一样，你需要知道它做了什么，不知道怎么做，以及如何解决这个问题。

    编辑：

    还应该注意， dig +trace不会警告你指向CNAME别名的NSlogging。 这是ISC BIND（可能还有其他）不会尝试更正的RFC违规。 +trace将完全乐意接受从本地configuration的域名服务器获得的Alogging，而如果BIND要执行完整recursion，则将使用SERVFAIL拒绝整个区域。

    如果胶水存在，这可能是棘手的疑难解答; 这将工作得很好， 直到NSlogging刷新 ，然后突然中断。 当一个NSlogging指向一个别名时，无缝授权总是会打破BIND的recursion。

    除了查找根名称服务器之外，不使用本地parsing器来追踪DNSparsing的另一种方法是使用dnsgraph （完全公开：我写了这个）。 它有一个命令行工具和一个web版本，你可以在http://ip.seveas.net/dnsgraph/find一个实例&#x3002;

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

    在这里输入图像描述