☰

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

tag-icon • tag-icon domain-name-system windows-server-2003 windows-server-2012 dig
为什么 dig +trace 有时会对 Windows Server DNS 失败？

我的团队有一台指向 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

相关内容