☰

启用清理后 DNS 中断

tag-icon • tag-icon windows-server-2016 internal-dns
启用清理后 DNS 中断

上周五，我在我的一个域控制器上启用了 DNS 清理。这样做的目的是从已退役的计算机中删除旧的未使用的 A 记录。但事实证明，我们的 DHCP（由 Meraki 硬件提供）配置错误，没有将信息转发回 DNS，因此计算机通常只在首次加入域时创建 A 记录。因此，在周六运行清理后，900 条 A 记录中有 600 条被删除。但这不是我要问的问题。

实际问题是，自从 DNS Scavenging 运行以来，许多计算机无法通过名称访问内部资源。这主要影响连接到我们 VPN 的远程工作人员笔记本电脑，但我们也有一些从未离开过我们公司网络的笔记本电脑以及一台服务器受到影响。一些更精确的症状：

受影响的计算机无法通过名称 ping 任何服务器，返回错误“Ping 请求找不到主机 x。请检查名称并重试。” 运行 wireshark 显示 ping 发起 DNS 请求，返回结果“0x8182 标准查询响应，服务器故障。” 受影响的计算机可以对我们的任何服务器运行 nslookup，返回正确的名称和 IP 地址。受影响的计算机可以通过 IP 地址 ping 任何服务器。受影响的计算机的 A 记录已从 DNS 中删除，但更多计算机的 A 记录已删除并继续正常工作。外部 DNS 对受影响的计算机正常工作。从受影响的计算机运行 ipconfig /registerdns 不会创建新的正向查找区域 A 记录。

到目前为止，我们唯一成功的解决方法是将一台计算机从我们的域中删除，然后重新添加。在大多数情况下，这可以解决问题，计算机可以成功访问网络资源。但是，这不会在 DNS 中为计算机创建新的 A 记录，并且一些受影响的计算机没有得到修复，仍然无法访问网络资源或 ping 服务器。

尝试修复：

运行各种命令以清除受影响计算机的网络设置：ipconfig /flushdns、ipconfig /registerdns、ipconfig /release、ipconfig /renew、netsh winsock reset catalog、netsh int ip reset reset.log、route /f。除了重新启动之外，这些都无法改变问题。导航到 AD 中受影响的计算机并单击重置帐户。这也没有任何变化。多次重启域控制器 - 没有变化。启用 DNS 调试日志记录 - 这表明受影响 PC 的内部 DNS 查询收到的 RCODE 为 2 的消息表明服务器出现故障。请参阅末尾的完整数据包示例。更新了正向查找区域动态更新以允许非安全和安全更新。- 没有变化。我们在 Azure 中创建了一个新的服务器 2016 虚拟域控制器，并重新配置了 DHCP 以指示一些受影响的计算机将其用作其主 DNS 服务器。- 执行此操作后，使用它作为 DNS 服务器的受影响计算机确实在 DNS 中创建新的 A 记录。它们仍然无法通过名称访问网络资源。

因此，我们仍然无法始终让每台受影响的计算机重新工作，并且不得不从我们的域中移除并重新加入许多计算机作为解决方法。如果你们知道可能导致此问题的原因或其他潜在修复，请告诉我。

返回DNS数据包示例：

5/15/2018 9:11:07 AM 17CC PACKET 00000211E32038A0 UDP Snd 10.2.151.35   aa53 R Q [8281 DR SERVFAIL] A     (7)dcazure(0)
UDP response info at 00000211E32038A0
  Socket = 724
  Remote addr 10.2.151.35, port 50641
  Time Query=40319, Queued=0, Expire=0
  Buf length = 0x0fa0 (4000)
  Msg length = 0x0019 (25)
  Message:
    XID     0xaa53
    Flags   0x8182
      QR       1 (RESPONSE)
      OPCODE   0 (QUERY)
      AA       0
      TC       0
      RD       1
      RA       1
      Z       0
      CD       0
      AD       0
      RCODE   2 (SERVFAIL)
    QCOUNT   1
    ACOUNT   0
    NSCOUNT 0
    ARCOUNT 0
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name     "(7)dcazure(0)"
      QTYPE A (1)
      QCLASS 1
    ANSWER SECTION:
      empty
    AUTHORITY SECTION:
      empty
    ADDITIONAL SECTION:
      empty

答案1

经过进一步的故障排除，我们发现这个问题是由于客户端计算机上的 Directaccess 配置错误，导致它们误以为它们不在公司网络上，而实际上它们在公司网络上。通过调整我们的 Directaccess 组策略并删除受影响客户端上的注册表项以强制它们清除现有设置，我们解决了这个问题。

相关内容