你的 VPN 推送三个 DNS 服务器：哪个在回答？
多出来的条目可能是备用、按域名的路由，或物理链路的残留。在把这份列表称为泄漏之前，先给每一条对上作用域。
连接后打开设置页，会列出三个 DNS 地址；审计的问题是哪一个处理了你的最后一次查询。只看数量什么都回答不了，因为客户端推送、物理网卡和按域名的策略都写进同一个视图。这些条目带着不同的作用域，决定谁在应答的是作用域而不是位置。先把来源分开，再测试拥有你关心那个名字的来源。
为什么列表比你的配置文件更长
VPN 客户端为隧道链路推送解析器地址，操作系统把它们保留在物理网卡原有地址旁边。路由器、企业 DHCP 租约、第二个 VPN 和按域名的策略各自贡献一条。 因此页面上的三个地址可能意味着三个作用域，而不是同一项工作的三个候选。把数量当作泄漏的证据，是这次审计的第一个错误。
在同一个网卡内，客户端确实会按顺序尝试服务器，所以有序列表并非没有意义。不是队列的是合并视图，配置文件、物理链路和按域名规则的条目并排放在一起，却没有统一排序。这个区别决定了测什么：顺序解释一个作用域内的行为，作用域解释其余一切。
加密 DNS 从应用内部打破这张图。带自己 DNS-over-HTTPS 解析器的浏览器或聊天客户端会把查询完全绕过操作系统列表，所以设置页上的地址描述的是应用从未产生的流量。在因名字解析错误而责怪配置文件之前，先检查应用自己的解析器设置。
三项检查各自说明什么
每个来源在不同地方留下痕迹，没有一条命令能全部显示。这是值得放在设置页旁边的对应关系：
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
在使用 systemd-resolved 的系统上，resolvectl status 是权威的，因为它按链路报告 DNS 以及路由域名。macOS 通过 scutil --dns 作答，它按尝试顺序列出带作用域的解析器。Windows 把两半分开：Get-DnsClientServerAddress 用于每块网卡的服务器，Get-DnsClientNrptPolicy 用于后缀规则。要运行属于实际所用解析器的命令，因为同时装有容器运行时和桌面解析器的机器可能不止一个。
一个无法为你所在区域作答的备用解析器
第二条通常是为了可用性而存在，而可用性只有在备用解析器认识这些名字时才成立。向公共解析器查询内部主机名，它会返回 NXDOMAIN，或给出与你毫无关系的搜索域的通配答案。没人验证过的故障转移，恰恰会在最需要它的时刻造成中断。
Split DNS 就是为了防止这种情况：公司后缀交给持有该区域的解析器，公共名字留在默认路径上。设计本身是可靠的，它取决于后缀列表是否完整。Microsoft 记录了在 Windows 上驱动这一点的按后缀解析器策略，同样的思路出现在 systemd-resolved 的路由域名和 macOS 的带作用域解析器中。
把备用解析器可以作答的区域与策略中存在的后缀相比较。这个比较会在用户报告某个内网站点在隧道变更后停止解析之前，先找到缺口。
通过策略查询，而不是绕过它
通过操作系统的解析器查询，因为直接向服务器查询会绕过策略，只报告那台服务器会说的话。 两个答案之间的差距就是全部要点：
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53如果系统查询返回私有地址而直接查询返回 NXDOMAIN，说明策略在工作，弱点是备用解析器。如果两者返回相同的公共答案，名字正在你预期的作用域之外被解析，后缀列表就是该看的地方。两个输出都留着，因为解析器的争论用两行比用设置页截图解决得更快。
然后演练失败路径，因为没人测试过的备用只是一个假设。把首选解析器对一次查询变成黑洞，看哪个地址回来：
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32查询一结束就删掉那条路由，否则下一个人会继承一个谜团。如果那段时间内内部名字仍能解析，说明有作用域之外的东西回答了它们。如果它们反而超时，说明备用缺失或已被正确限定，解析器自己的日志会告诉你究竟是哪一种。
决定：保留、限定还是移除
当备用解析器能回答你需要的命名空间并且在配置之下仍然可达时，就保留它。当它只该看到一个后缀而不该看别的时，就限定它；当它既没有作用域也没有书面目的时，就移除它。没有工作的条目是毫无收益的未来泄漏，供应商默认值不是目的。
把结果记成四列：后缀、解析器、接口和负责人。那一行比任何截图都更快回答下一次审计问题，而且能经受住悄悄重排列表的客户端更新。