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

Question

我的团队有一个指向 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失去理智？为什么我们似乎是唯一抱怨的人？

Answer 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高兴了，每个人都可以继续摸不着头脑，直到问题再次出现。

您的选择是与域管理员协商不同的配置，或者解决问题。只要中毒的根提示在大多数情况下足够好（并且您知道它们不是的情况：观点冲突等），这并不是一个巨大的不便。

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

• 在具有较少疯狂的默认解析器集的机器上运行您的跟踪。
• 从名称服务器开始跟踪，该名称服务器返回 Internet 的根名称服务器以响应. NS. 您也可以将此名称服务器硬连接到${HOME}/.digrc，但这可能会使共享帐户上的其他人感到困惑或在某些时候被您遗忘。 dig @somethingelse +trace example.com
• 在运行跟踪之前，自己为根提示播种。
  dig . NS
dig +trace example.com