服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 为什么dig + trace有时会对Windows Server DNS失败？
Intereting Posts
RDP农场 – 外部连接 另存为…导致XP MSOffice 2003/2007应用程序挂起 Linux工具重置英特尔X25固态硬盘磨损平衡表？ 组策略 – WSUS OSX 10.6客户端的Samba性能很慢 有人可以解释一下关于Unix文件夹的权限和安全吗？ 如何将Ubuntu Hardy（8.04）上的OpenSSH Server从v4.7升级到CURRENT？ 是否可以阻止在NIC的IP访问 Redis vs Memcache dynamic子域，mod_python和trac 平均。 磁盘队列长度计数器使用外部RAID磁盘arrays时？ KVM：哪些CPUfunction使虚拟机运行更好？ Google应用云 – redirect到裸域 多个用户通过互联网共享的文件夹 使用nginx服务器支持js / css / image降级

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

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

这个问题似乎已经在操作系统升级之间转移了，但是很难说升级过程中操作系统版本或其他设置是否被改变。

  • 当上游服务器是Windows Server 2003时， dig +trace第一步（从/etc/resolv.conf的第一个入口请求. IN NS ）偶尔会返回0字节的响应。
  • 当上游服务器升级到Windows Server 2012时，零字节响应问题消失了，但是我们偶尔会得到在DNS服务器上configuration的转发器列表。

第二个问题的例子： 

 $ 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内部查看的域内进行跟踪，则会导致dig +trace跟踪错误的path。

为什么dig +trace失去主意？ 为什么我们似乎是唯一抱怨呢？

你正在被根提示所拖曳。 这一个是棘手的故障排除，它取决于理解的. IN NS . IN NS跟踪开始处发送的. IN NS查询不会在数据包上设置RD （recursion所需）标志。

当微软的DNS服务器接收到对根名称服务器的非recursion请求时，他们可能会返回configuration的根提示。 只要你不把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 dig @whatever . NS将重现这个问题，这实际上完全掩盖了它。 当服务器获取RD标志设置的根名称服务器的请求时，它将伸出并获取真实根名称服务器的副本以及所有后续请求. NS 没有 RD标志的. NS会奇迹般地开始按预期工作。 这使得dig +trace再次开心，每个人都可以回头挠头，直到问题再次出现。

您的select是与您的域pipe理员协商不同的configuration，或解决问题。 只要在大多数情况下，有毒的根本提示已经足够好了（而且你知道它们不存在的情况：冲突的观点等），这并不是一个巨大的不便。

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

  • 在具有较less的一组缺省parsing器的机器上运行跟踪。
  • 从一个名字服务器开始你的跟踪，该名字服务器返回互联网的根名称服务器. NS . NS 。 你也可以将这个名字服务器硬连接到${HOME}/.digrc ，但是这可能会混淆其他人在共享帐户上或在某个时候被你忘记。 dig @somethingelse +trace example.com
  • 在运行跟踪之前给根提示种子。
    dig . NS
    dig +trace example.com