你的 VPN DNS 后备解析：查询究竟走了哪条路

解析器设置从内网地址切到公共地址，结论立刻就来了：隧道在泄漏。有时确实如此。但更多时候，后备查询仍然走在隧道里，到达的是管理员选定的解析器，这就属于策略决定，而不是缺陷。要区分这两种情况，需要三个事实而不是一个，第一个就是谁收到了查询。弄清谁接收了查询、走的是哪条路、问的是哪些名字。

后备是一种策略，而不是单一行为

当首选解析器停止响应时，每个客户端都要决定怎么办。它可以阻断解析、重试、使用已配置的替代方案，或者交给操作系统，从隐私角度看这是四种不同的产品。读设置界面只知道配置了哪种行为，不知道实际发生了哪一种。只有一个开关的界面，并不描述四种可能。

浏览器会加上自己的一层。启用了安全 DNS 的浏览器即使操作系统指向别处，也能通过它自己选择的提供商解析名字，这意味着你真正在意的那些请求，可能从来没有经过隧道客户端的策略。要检查发起请求的应用，而不只是系统设置。

替代解析器的身份是第一个值得确认的事实。属于你本来就信任的提供商的公共解析器，和当前网络直接下发的地址，是两种不同的情况。光看地址本身，很少能分辨是哪一种。

接收方和路径彼此独立，只有两者合起来才说明暴露面。经由隧道到达的公共解析器永远看不到你的接入网地址，而同一个解析器被直接访问时就能看到。两种情况都会返回结果，只报告解析器地址的泄漏测试会把它们描述成一模一样。读结果时除了地址，还要问接口。

内部名字让这个区别变得具体。公共解析器通常无法回答分离视图的名字，于是查询失败，但这个名字已经暴露给了一个本不该看到它的对象。所以在这里，可用性和隐私是同向的，而不是互相交换。

隧道也可能把查询送到并非 VPN 提供商运营的解析器，因为隧道做的是转发而不是解析。转发方看到明文查询，然后自己再向外发起连接，这保护了下一跳，却没有保护第一跳。

观察数据包，而不是配置。先问系统会用哪个解析器，再确认查询确实从预期的接口发往预期的地址。

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

如果抓包显示隧道处于连接状态时，查询却从物理接口发出，那么不管解析器列表怎么写，后备都绕过了隧道。如果它出现在隧道接口上，问题就变成远端由谁运营、保留了什么。

用一个内部名字和一个公共名字各测一次。内部查询往往正是后备配置自我暴露的地方，因为答不出来的解析器仍然会收到问题。

如果要求是首选解析器不可用时解析必须停止，那就配置一条失败时关闭的执行策略，并接受后果：故障期间名字解析不了。这是有意的可用性权衡，而不是故障，设计文档应该在故障发生前就这么写。

如果要求只是查询不得走出隧道，那么经由隧道到达的公共解析器可以接受，前提是理解运营方及其保留策略。这种接受是对第三方的判断，而不是关于密码学的结论，它属于持有隐私主张的人。如果内部名字必须继续可用，后备就必须是掌握内部区域的解析器，这通常意味着后备目标是另一台服务器，而不是另一个地址族。

把结果写成一句关于行为的话：正常运行时由哪个解析器接收查询，故障之后由哪个接收，第二种情况下内部名字是否还能解析。一个最后能打开页面的泄漏测试，证明的东西比这句话更少，因为页面也可能经由一个本不该被询问的解析器打开。