域名系统 – 为什么挖掘跟踪有时会对Windows Server DNS失败？

发布时间：2020-12-14 04:30:52 所属栏目：大数据来源：网络整理

导读：我的团队有一台服务器指向Active Directory提供的DNS,以确保它能够访问域管理的任何主机.不幸的是,我的团队还需要经常进行挖掘跟踪,我们偶尔会得到奇怪的结果.我是DNS管理员但不是域管理员,但负责这些服务器的团队也不确定这里发生了什么. 这个问题似乎已经

我的团队有一台服务器指向Active Directory提供的DNS,以确保它能够访问域管理的任何主机.不幸的是,我的团队还需要经常进行挖掘跟踪,我们偶尔会得到奇怪的结果.我是DNS管理员但不是域管理员,但负责这些服务器的团队也不确定这里发生了什么.

这个问题似乎已经在操作系统升级之间发生了转变,但很难说这是操作系统版本的特征还是在升级过程中其他设置发生了变化.

>当上游服务器是Windows Server 2003时,挖掘跟踪的第一步(从/etc/resolv.conf中的第一个条目请求.IN NS)偶尔会返回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

在大多数情况下,这不是问题,但如果我们在AD具有内部视图的域内进行跟踪,则会导致挖掘跟踪遵循错误的路径.

为什么挖掘痕迹会失去理智？为什么我们似乎是唯一抱怨的人呢？

解决方法

你被根提示所拖累.这个很难排除故障,它取决于理解.在跟踪开始时发送的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

这是大多数故障排除工作都会崩溃的地方,因为跳过的简单假设就是挖掘@whatever. NS将重现这个问题,实际上它完全掩盖了它.当服务器获得设置了RD标志的根名称服务器请求时,它将伸出并获取真实根名称服务器的副本以及所有后续请求.没有RD标志的NS将神奇地开始按预期工作.这使挖掘痕迹再次开心,每个人都可以回头摸不着头,直到问题重新出现.

您可以选择与域管理员协商不同的配置,或者解决问题.只要中毒的根提示在大多数情况下都足够好(并且你知道它们不存在的情况：相互矛盾的观点等),这不是一个巨大的不便.

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

>在具有较少坚果组默认解析器的计算机上运行跟踪.>从名称服务器开始跟踪,该名称服务器返回互联网的根名称服务器以响应. NS.您也可以将此名称服务器硬连线到${HOME} /.digrc,但这可能会使其他人在共享帐户上感到困惑,或者在某些时候被您遗忘.挖掘@somethingelse trace example.com>在运行跟踪之前自己播种根提示.挖. NS挖掘跟踪example.com

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!