主页 / server / 问题 / 605081
Accepted
Andrew B
Asked: 2014-06-14 16:44:30 +0800 CST

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

  • 772

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

问题似乎在操作系统升级之间转移，但很难说这是操作系统版本的特征还是升级过程中更改的其他设置。

  • 当上游服务器是 Windows Server 2003 时，第一步（来自第一个条目的dig +trace请求）偶尔会返回 0 字节响应。. IN NS/etc/resolv.conf
  • 当上游服务器升级到 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失去理智？为什么我们似乎是唯一抱怨的人？

domain-name-system

1 个回答

  1. Best Answer

    你被根提示控制了。这个解决起来很棘手，它取决于理解. 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
    • 6

相关问题