我的团队有一个服务器指向Active Directory提供的DNS,以确保它能够访问由该域pipe理的任何主机。 不幸的是,我的团队也需要经常运行dig +trace
,我们偶尔会得到奇怪的结果。 我是一个DNSpipe理员,但不是域pipe理员,但负责这些服务器的团队不知道这里发生了什么。
这个问题似乎已经在操作系统升级之间转移了,但是很难说升级过程中操作系统版本或其他设置是否被改变。
dig +trace
第一步(从/etc/resolv.conf
的第一个入口请求. IN NS
)偶尔会返回0字节的响应。 第二个问题的例子:
$ 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,或解决问题。 只要在大多数情况下,有毒的根本提示已经足够好了(而且你知道它们不存在的情况:冲突的观点等),这并不是一个巨大的不便。
一些解决方法不改变根提示是:
. NS
. NS
。 你也可以将这个名字服务器硬连接到${HOME}/.digrc
,但是这可能会混淆其他人在共享帐户上或在某个时候被你忘记。 dig @somethingelse +trace example.com
dig . NS
dig +trace example.com