在不泄露内部名称的前提下测试分离 DNS

向公共解析器查询内部名称会泄露该名称，并跳过你本想测试的规则。查询会到达你无法控制的服务器，答案来自本不该看到它的命名空间，结果也无法说明分离 DNS 是否工作。测试分离 DNS，意味着测试应用程序实际使用的解析器路径。这条路径由操作系统选择，由 VPN 配置文件中的域列表选择，有时也由浏览器选择。

先选定两个名称，并预测两个答案

向网络负责人索取一个已记录在案的内部测试名称，再选一个与组织毫无关系的普通公共名称。在运行任何命令之前，先写下两者各自应当发生什么：内部名称应当到达隧道的解析器并返回内部地址，而公共名称应当通过系统通常使用的解析器解析。这两条预测就是测试本身，因为没有它们，任何结果都能在事后被合理化。多次运行时保持这一对名称不变，后续比较才有意义。

检查实际生效的规则，而不是设想的规则。附加在 VPN 连接上的域列表决定哪些后缀走哪个解析器，而该列表中的一处笔误会产生看似合理却错误的分流。在受管设备上，请使用管理员的诊断路径，因为本地覆盖可能在下次检查时被策略重置。

把预测和观察到的答案写在同一张工单里，紧挨着。没有预测的测试不会失败，而不会失败的测试什么也教不了。

测试应用程序实际使用的路径，而不是你自己选的一台服务器

显式指定解析器的命令只测试那一个解析器，别的什么也不测。它能告诉你内部服务器是否响应，这有用，但它不能告诉你应用程序是否把名称发到那里。先按常规路径测试：以应用程序的方式解析内部名称，再用同样的方式解析公共名称。只有在这之后，才去查询具体服务器，找出行为在哪里出现分歧。

浏览器会让情况更复杂，因为安全 DNS 设置可能完全绕过系统解析器。配置了自有加密解析器的浏览器永远看不到分流，故障看起来就像 VPN 配置文件坏了。改动隧道之前，先检查这项设置。

如果问题在于恢复，就在重新连接之后重复查询。重连之前缓存的答案，会让一个正确恢复的分流看起来比实际更好或更差。

记录答案的类别，而不是只记成功或失败

写下四种情况中的哪一种发生了：内部地址、公共地址、否定答案，还是超时。每一种含义都不同。内部名称得到内部地址是预期中的成功；内部名称得到公共地址说明查询离开了隧道；权威服务器的否定答案指向记录缺失，而不是路由故障；超时则说明存在可达性问题，或解析器根本没收到查询。成功与失败太粗糙，无法据此行动。

在解释为何没有新的查询之前，先考虑缓存，因为缓存中的否定答案与一个不存在的名称看起来完全一样。在用受支持的手段清除任何东西之前，先把响应留存下来，因为第一个答案就是证据。

不要猜，分别解释两条分支

如果内部名称解析正确而应用程序仍然失败，说明解析器已经尽责，接下来的怀疑对象是资源本身的路由和权限。如果私有名称到达了公共解析器，说明分流规则没有作用于那次查询，因此要和命名空间的负责人一起复查域列表以及任何浏览器策略。这两条分支的负责人不同，所以记录你看到的是哪一条，比记录某个东西坏了更重要。

共享输出时要遮蔽敏感内容，但保留结构：哪个命名空间、哪条规则、哪类答案。解析器的响应可能带有内部地址和主机名，而工单是两者长久留存的家。

然后把结果交给命名空间的负责人，附上你观察到的两个类别，并去掉名称。那是一次五分钟的对话，而不是一周的猜测。