为什么dig + trace有时会对Windows Server DNS失败?

我的团队有一个服务器指向Active Directory提供的DNS,以确保它能够访问由该域pipe理的任何主机。 不幸的是,我的团队也需要经常运行dig +trace ,我们偶尔会得到奇怪的结果。 我是一个DNSpipe理员,但不是域pipe理员,但负责这些服务器的团队不知道这里发生了什么。

这个问题似乎已经在操作系统升级之间转移了,但是很难说升级过程中操作系统版本或其他设置是否被改变。

  • 当上游服务器是Windows Server 2003时, dig +trace第一步(从/etc/resolv.conf的第一个入口请求. IN NS )偶尔会返回0字节的响应。
  • 当上游服务器升级到Windows Server 2012时,零字节响应问题消失了,但是我们偶尔会得到在DNS服务器上configuration的转发器列表。

第二个问题的例子:

 $ dig +trace -x 1.2.3.4 ; <<>> DiG 9.8.2 <<>> +trace -x 1.2.3.4 ;; global options: +cmd . 3600 IN NS dns2.ad.example.com. . 3600 IN NS dns1.ad.example.com. ;; Received 102 bytes from 192.0.2.11#53(192.0.2.11) in 22 ms 1.in-addr.arpa. 84981 IN NS ns1.apnic.net. 1.in-addr.arpa. 84981 IN NS tinnie.arin.net. 1.in-addr.arpa. 84981 IN NS sec1.authdns.ripe.net. 1.in-addr.arpa. 84981 IN NS ns2.lacnic.net. 1.in-addr.arpa. 84981 IN NS ns3.apnic.net. 1.in-addr.arpa. 84981 IN NS apnic1.dnsnode.net. 1.in-addr.arpa. 84981 IN NS ns4.apnic.net. ;; Received 507 bytes from 192.0.2.228#53(192.0.2.228) in 45 ms 1.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 4827 7200 1800 604800 172800 ;; Received 127 bytes from 202.12.28.131#53(202.12.28.131) in 167 ms 

在大多数情况下,这不是问题,但如果我们在AD内部查看的域内进行跟踪,则会导致dig +trace跟踪错误的path。

为什么dig +trace失去主意? 为什么我们似乎是唯一抱怨呢?

你正在被根提示所拖曳。 这一个是棘手的故障排除,它取决于理解的. IN NS . IN NS跟踪开始处发送的. IN NS查询不会在数据包上设置RD (recursion所需)标志。

当微软的DNS服务器接收到对根名称服务器的非recursion请求时,他们可能会返回configuration的根提示。 只要你不把RD标志添加到请求中,服务器就会乐意继续每天都以固定的TTL返回相同的响应。

 $ dig @192.0.2.11 +norecurse . NS ; <<>> DiG 9.8.2 <<>> @192.0.2.11 +norecurse . NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12586 ;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 3600 IN NS dns2.ad.example.com. . 3600 IN NS dns1.ad.example.com. ;; ADDITIONAL SECTION: dns2.ad.example.com. 3600 IN A 192.0.2.228 dns1.ad.example.com. 3600 IN A 192.0.2.229 

这是大多数故障排除工作将会崩溃的地方,因为飞跃的简单假设就是dig @whatever . NS dig @whatever . NS将重现这个问题,这实际上完全掩盖了它。 当服务器获取RD标志设置的根名称服务器的请求时,它将伸出并获取真实根名称服务器的副本以及所有后续请求. NS 没有 RD标志的. NS会奇迹般地开始按预期工作。 这使得dig +trace再次开心,每个人都可以回头挠头,直到问题再次出现。

您的select是与您的域pipe理员协商不同的configuration,或解决问题。 只要在大多数情况下,有毒的根本提示已经足够好了(而且你知道它们不存在的情况:冲突的观点等),这并不是一个巨大的不便。

一些解决方法不改变根提示是:

  • 在具有较less的一组缺省parsing器的机器上运行跟踪。
  • 从一个名字服务器开始你的跟踪,该名字服务器返回互联网的根名称服务器. NS . NS 。 你也可以将这个名字服务器硬连接到${HOME}/.digrc ,但是这可能会混淆其他人在共享帐户上或在某个时候被你忘记。 dig @somethingelse +trace example.com
  • 在运行跟踪之前给根提示种子。
    dig . NS
    dig +trace example.com