公共 DNS 能正常工作，并不意味着能找到 Active Directory

VPN 连上了，浏览器也打开了公共网站，笔记本却仍然登不进域。常见的结论是：既然名字能解析，DNS 就没问题。事实并非如此，原因在于浏览器测试只走了域内客户端所需查询链中的一环。域发现先查询服务记录，再查询这些记录所指控制器的地址，最后还要求到这些控制器监听端口的路由。一个公共响应这几步一步也满足不了。

误区：名字能解析，DNS 就算完成了

公共网站能解析，只能说明某个解析器回答了对公共区域中某个名字的一次 A 或 AAAA 查询。Active Directory 用同一套协议问的是另一个问题：域的服务在哪里，这台客户端该用哪个控制器。这个问题以域名之下区域的 SRV 记录来表达，而递归的公共解析器没有理由保存它们。

记录缺失时，解析器返回否定应答，这是有效的 DNS 响应而不是故障。客户端随后退回到缓存的控制器信息，这也正是台式机可以几小时看起来正常、却在重启或改密码之后失败的原因。

域客户端究竟按什么顺序提问

对于像 corp.example 这样的域，通用定位查询是 _ldap._tcp.dc._msdcs.corp.example。SRV 应答给出候选控制器及其端口，随后客户端还需要这些主机名的地址记录才能建立连接。站点感知发现会在站点子域之下追加查询，而应答决定的是哪些控制器更受偏好，哪个并非强制。

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

按这个顺序、从问题发生的网络里逐段追踪这条链。解析到不可达地址的主机名是路由故障，不是 DNS 故障。定位记录缺失但可达的控制器是 DNS 故障，不是路由故障。两者产生的用户抱怨相似，修复方式却完全不同。

为什么公共解析器明明应答，登录还是坏

如果适配器给客户端一个公共解析器，公共名字能用，内部命名空间不能用。再加一个公共解析器也没用，因为两者都不持有该区域。常见的“先内部、后公共”列表同样不按逐域规则行事：第一个服务器的否定应答是合法应答，客户端不会仅因为应答为空就重试第二个服务器。

两台内部解析器（如果你运行两台）都必须持有 AD 命名空间，并且能从客户端当前网络到达。分隧道设计破坏的正是这一点：VPN 可能承载隧道子网，而内部解析器位于隧道不路由的前缀上，于是查询落到了一个答不上来的解析器手里。

Windows 还会应用名称解析策略，可以把特定命名空间指向特定服务器，而适配器显示的 DNS 地址并不是全部。只改适配器列表而不改那份策略，实际生效的配置可能纹丝不动，这就是看起来已经生效的修复毫无作用的原因。

让隧道的 DNS 与它的路由保持一致

只推送解析器却不推送包含它的前缀，会造出客户端够不着的解析器；只推送前缀却不推送解析器，则让客户端去问本地解析器。把这一对当作一个配置项，每次改配置后都检查两边，因为推送顺序改变或新的分隧道策略都可能把它们拆开。

还要检查客户端怎么处理被推送的设置。有些客户端只把 DNS 服务器应用到隧道接口，物理适配器的解析器原封不动，于是谁生效取决于接口跃点数和所查询的名字。如果只有禁用物理适配器时内部应答才回来，那么要修的是这个机制，不是域记录。

用一次发现调用加一次真实操作来验收

有用的验收测试先跑定位查询，再做一次真正的已认证操作，例如打开目录支持的共享或申请票据。要在 VPN 切换前后各做一次，同一台机器，中间不重启。缓存的凭据和已打开的会话会欣然让坏掉的路径看起来健康，所以桌面登录成功并不是这项测试。

Microsoft 的 DNS 客户端建议 在解析内部命名空间与向上转发公共查询之间划了同一条线，引入 VPN 时应当保留的正是这种安排。

如果故障只是慢而不是失败，就把延迟与诊断分开。发现阶段的超时可能来自不可达的控制器、被拦截的端口或应答很晚的解析器，单靠等待哪一条都证明不了。改解析器设置之前，先把实际查询、它的应答和连接尝试记录下来。