三个发布者都能把域控制器的 VPN 地址写进 DNS

多宿主域控制器上有三个不同的组件都会把同一个 VPN 地址写进 DNS，而且它们彼此独立地失效。比起相信只控制其中一个的适配器复选框，不如直接比较三者各自发布了什么。症状在任何情况下都一样：客户端能解析名称，拿到隧道地址，却连不上域控制器。是谁发布的，决定了该怎么制止。

一个设置、一个服务、一个角色；三个发布者，三个开关。

先看记录，别先看复选框

通过客户端实际使用的DNS 服务器查询受影响服务器的完整名称，并记录返回的每一个地址。把每个返回地址与服务器真实的 LAN 和隧道接口对照，也与客户端所在的网段对照。某个地址在本地完全有效，却可能对关键客户端不可达。间歇性的身份验证失败是常见症状，因为客户端在不同尝试中会收到或选中不同的地址。

机器能正确解析自己的名称，几乎说明不了什么。真正该做的测试，是从客户端的网段发起。

适配器只是其中一个发布者

适配器的 TCP/IP 属性里有一个复选框，用于注册该连接的地址，取消勾选只会让其中一个发布者闭嘴。它拦不住其他发布者，所以重启之后记录可能再次出现。如果域控制器同时运行 DNS 服务，该服务有自己的侦听配置，也有自己的名称服务器记录。微软关于多宿主环境的指南，把接口行为、DNS 服务和 Netlogon 视为三个独立的发布者。

三个开关、三方归属，而只有一个在适配器的属性页上。

DNS 服务有自己的地址

被要求侦听某个 VPN 地址的 DNS 服务器，不管适配器复选框怎么说，都会继续在自己的记录里发布该地址。把服务的侦听地址调整为目标接口，同时检查区域的名称服务器条目。改动侦听地址可能中断正在使用你即将移除地址的客户端，所以先弄清谁依赖哪一个。仅仅因为那是 VPN 地址就删掉侦听，反而会切断你本想帮助的客户端。

Netlogon 以及一般的域控制器发现流程，也会作为自身职责的一部分注册地址。不要在整域范围内压制注册，也不要照搬旧式的远程访问注册方案而不确认它适用于你的版本和角色。

先定归属，再动手清理

先修好发布者，再删记录，否则下一次注册事件又把它写回来，整套动作再来一遍。按 DNS 所有者的流程清除过期条目，并考虑缓存与老化。从客户端网段验证，覆盖域发现以及最初失败的那个应用，然后触发当初产生该地址的同一次 VPN 事件。

最终你要的是一个已知的已发布地址与侦听地址集合，而日常的域注册照常工作。手工清理之后名字恰好能正确解析的机器，并不是那个状态。

记下是哪个发布者负责、哪些记录变了、测过哪些客户端。下一台多宿主服务器，还是同样三个嫌疑对象。