我的团队有一台指向 Active Directory 提供的 DNS 的服务器,以确保它能够访问域管理的任何主机。不幸的是,我的团队也需要dig +trace
频繁运行,我们偶尔会得到奇怪的结果。我是 DNS 管理员,但不是域管理员,但负责这些服务器的团队也不确定这里发生了什么。
该问题似乎在操作系统升级之间发生了变化,但很难说这是操作系统版本的特性还是升级过程中其他设置的改变。
- 当上游服务器是 Windows Server 2003 时,第一步
dig +trace
(. IN NS
从中的第一个条目发出请求/etc/resolv.conf
)偶尔会返回 0 字节响应。 - 当上游服务器升级到 Windows Server 2012 时,零字节响应问题消失了,但取而代之的是我们会偶尔获取 DNS 服务器上配置的转发器列表的问题。
第二个问题的示例:
$ 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
在大多数情况下这不是问题,但dig +trace
如果我们在 AD 具有内部视图的域内进行跟踪,则会导致遵循错误的路径。
为什么会dig +trace
失去理智?为什么我们似乎是唯一在抱怨的人?
答案1
你被根提示所欺骗。这个问题很难解决,它取决于理解. IN NS
在跟踪开始时发送的查询才不是RD
在数据包上设置(需要递归)标志。
当 Microsoft 的 DNS 服务器收到针对根名称服务器的非递归请求时,它们可能会返回已配置的根提示。只要您不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
将重现问题,而这实际上完全掩盖了问题。当服务器收到设置了标志的根名称服务器请求时RD
,它将伸手获取真实的根域名服务器,以及所有后续请求. NS
没有标志RD
将神奇地开始按预期工作。这dig +trace
又让人高兴了,每个人都可以继续挠头,直到问题再次出现。
您的选择是与域管理员协商不同的配置,或者解决问题。只要毒根提示在大多数情况下足够好(并且您知道它们不够好的情况:相互冲突的观点等),这就不会造成很大的不便。
一些不改变根提示的解决方法是:
- 在具有一组不太复杂的默认解析器的机器上运行您的跟踪。
- 从响应 而返回互联网根名称服务器的名称服务器开始跟踪
. NS
。您也可以将此名称服务器硬连线到${HOME}/.digrc
,但这可能会使共享帐户上的其他人感到困惑,或者您有时会忘记。dig @somethingelse +trace example.com
- 在运行跟踪之前,自己播下根提示的种子。
dig . NS
dig +trace example.com