为什么 DNS 里的国家标签不能证明 VPN 泄漏

看起来像境外的解析器地址会不断出现在 DNS 测试结果里，而人们得出的结论总是同一条：查询一定跑出了隧道。有时确实如此。更常见的情况是，报告说明的是哪个递归服务作了应答、数据库认为该地址位于何处，这讲的是基础设施，而不是你的数据包。要把观察和推论分开，需要三个事实：谁作了应答、名字经过了怎样的路径，以及你实际配置了什么策略。

看清测试究竟观察到了什么

大多数测试页面的做法相同：让客户端解析一个唯一主机名，然后看是哪个解析器取到了它；或者干脆把它声称的解析器地址回显出来。这能识别出一个递归服务，如果查询带了客户端子网信息，还能给出粗略的网络位置。它不能证明查询离开了设备、走到了隧道之外，更不能证明每个名字都走了同一条路径。一次查询的一次观察，被推广成了关于全部流量的结论。

显示解析器地址的测试比国家徽章更有用，因为可以把该地址与客户端实际收到的解析器列表作对比。

anycast 与转发解释了大多数意外

大型公共解析器会从许多地点宣告同一地址，网络则把每次查询路由到路由意义上最近的那一处。随后地理定位数据库把这个地址映射到单一地点，而它可能是另一个大洲上的公司注册地址，也可能是并非应答方的数据中心。RFC 4786 讨论了 anycast 服务的运维实践，以及把这类地址绑定到单一物理位置的困难。地图是对路由决策的简化，而且它简化的方向恰好会产出耸人的结果。

转发又加了一层。本地 stub 解析器、路由器或运营商解析器都可能把查询转给上游服务，测试里出现的名字反映的是这条链上最后一环的运营者，而不是第一环。客户端子网扩展可以让上游的应答贴合你的网络，同时又让报告出来的位置看起来像你从没去过的地方。

因此，配置好的解析器可能完全正确，却仍产出看似境外的结果；而你本国的解析器也可能是错的那个，因为它属于你并未选择的第三方。

名字被谁收到，走的哪条路

两个问题回答实务部分：客户端用的是哪台服务器，以及到那台服务器是否经由隧道。在就路由下结论之前，先把解析器列表与测试结果中的地址对照，再确认发往该地址的查询是从隧道接口出去的。如果两个地址不一致，真正有意思的发现是：有东西改写了或绕过了本该使用的解析器，这比国家名字更值得细看。

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

第一条命令显示某个名字由哪台服务器应答，第二条显示已配置的列表及其作用范围，第三条报告公共服务所看到的解析器地址。三者一致时，无论国家标签怎么说，策略都在按其配置发挥作用。

与你选择的策略对照

强推解析器的 VPN、配置为使用自家加密 DNS 的浏览器，以及偏好某一接口设置的操作系统，单独看都可能正确，合在一起却互相冲突。现代浏览器可能通过加密传输把查询发给浏览器内选定的服务商，这会有意绕过系统的解析器列表。这并非隧道破裂意义上的泄漏；这是别处选定的策略，找出它在哪被选定才是真正的工作。

工作设备还会加域规则：内部名字必须交给组织解析器，其余走默认。因为测试页面显示了意外国家就替换掉这套安排，正是让整个团队的内部名字解析不了的原因。

让测试保持窄而安全

向公共测试服务查询内部主机名，等于把这个名字泄露给不该看到它的第三方，而得到的答案并不比本地读一遍解析器列表更多。

改用能暴露基础设施的名字，记录解析器地址、作用范围和所用接口，再把这份记录与文档化的意图对照。地图标签是对话的背景，不是通过或不通过的判据；把它当作判决，只会带来配置改动而不是诊断。