Split-DNS 抓包：说明每处观测是在哪里取得的

两个人在排查同一个 Split-DNS 问题，却得到不同的解析器地址。一人用了查询工具，一人在网卡上抓了包，第三人读了客户端自身的诊断。谁都没有说谎，谁也没有描述同一个阶段。给观测点命名，就把矛盾变成了地图。

一次查询，多个观测点

对同一个内部名称，至少要看五个地方：应用及其调用的解析器 API、客户端上生效的域策略、网卡或过滤器上的抓包、受控的网关边界，以及真正收到查询的解析器。

每一处回答的问题都不同，任何一处单独都不能证明查询去了哪里。

网卡上的抓包显示的是数据包，而不是意图。它不会告诉你客户端选了哪个解析器，空抓包可能意味着缓存答案或另一个解析器 API，而不是数据包被丢弃。把每处观测当作关于一个阶段的证据。然后把各阶段拼成一条路径。

客户端的过滤器位于应用与线路之间

启用 Split-DNS 的 VPN 客户端在数据包离开本机之前就做了域名匹配。隧道后缀中的名称走内部解析器，其余一律走本地解析器。过滤器就是策略，而策略会因平台和客户端版本而异。

Cisco 的《Secure Client Split-DNS 指南》涵盖了域名匹配和 Windows 过滤器，并区分了应用使用原生解析器 API 时看到的内容与 nslookup 这类工具看到的内容。这些区别正是要点。

从生效的配置文件和一次普通的应用查询开始。任何点名指定服务器的测试都是刻意的绕行；用客户端自身的诊断去解释它，不要让它成为验收标准。

nslookup 走的是与应用不同的路径

nslookup 会自行构造 DNS 查询，可以绕过操作系统的解析器策略。这使它成为向指定服务器提出指定问题的有用工具，也是测试应用实际体验时的误导性工具。

在 Windows 中，名称解析策略表决定哪个后缀使用哪台服务器。读它可以看到应用将遵循的策略，而这往往就是缺失的那一环。

读完策略，再用普通解析器问同一个问题：

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

加密解析器隐藏的是查询，而不是连接

自带 DNS-over-HTTPS 解析器的浏览器完全是另一回事。查询在 TLS 内部发出，因此抓包能看到与解析器地址的连接，却看不到所问的名称。

先弄清浏览器的受管策略，再与操作系统查询作对比。被允许自选解析器的浏览器可能根本看不到 Split-DNS 策略。

同样的谨慎适用于任何自带解析器的客户端。能识别远端连接的抓包并不是关于查询名称的证据。如果你需要名称，请从解析器自身的日志或应用诊断中获取，并遵守适用的隐私规则。

与带标记的测试作对比

为测试选一个已批准的内部名称，再加一个不含敏感含义的公共名称。对每一个，记录时间、记录类型、答案以及你预期的策略。

在允许的地方，把解析器的接收情况与一次范围很窄的客户端或网关观测作对比：

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

绝不要仅仅为了做对比就把私有名称发给无关的公共解析器，并且对你分享的任何内容做脱敏。最后，把正确的 DNS 答案与随后的服务连接区分开：解析出的私有地址仍然需要路由和应用授权。