DNSSEC 与 VPN：谁真正隐藏了你的 DNS 查询

两种机制被赋予了同一项任务，而两者都没有真正完成它。DNSSEC 回答的是你收到的数据是否确实来自发布它的那个区，VPN 决定你的数据包走哪条路径。两者都不能在所有情况下隐藏你查询的名字，而那些看起来应该能做到的设置，通常管的是传输或路由，而不是校验。先把层次说清楚，含糊的隐私问题才会变成具体的问题。

三种被混为一谈的说法

真实性说的是：回答确实由该区发布，且途中没有被改动。机密性说的是：路径上没有人能读到查询或回答。路由说的是：数据包沿着你选择的路径走，而这正是隧道提供的东西。

DNSSEC 处理第一种，对其余两种只字不提。DoT 和 DoH 处理到解析器这一段路上的第二种。VPN 处理第三种，也可能影响第二种，但那只是流量去向带来的副作用。

应用流量是第四种情况：HTTPS 保护并认证你的客户端与网站之间的网页交换，没有任何 DNS 层能替代它。

签名验证能做什么，不能做什么

执行校验的解析器会检查从该区一直到已配置信任锚的签名链，校验通过后返回带有已认证数据标记的回答。这个标记是关于数据的证据，而不是关于连接或目标意图的证据。

它无法阻止一个合法区主为你不该信任的服务发布真实记录。来自被攻陷域名的正确签名回答依然是正确签名的，而 DNSSEC 对你是否该把凭据交给这个域名不作判断。

它也什么都不隐藏。除非另一层保护了传输，查询和回答都会以解析器和该路径上任何观察者都能读取的形式穿过网络。签名回答和私密回答是两种不同的属性，一次部署可能只有其中一种。两者只要有一个对你重要，就都测一遍。

机密性究竟来自哪里

到解析器的加密传输把 DNS 交换包在 TLS 里，因此解析器仍然看得见问题，但你我之间的路径看不见。这是把信任挪了位置，而不是把它取消：你更信任解析器，更不信任本地网络。

VPN 可以把查询带到另一侧的解析器，这同时改变了路径和看见查询的解析器。这是一个带来隐私后果的路由决定，而在受管理的网络里，内部解析器可能是唯一能回答内部名称的那个。

人们真正想要的组合通常同时包含三件事：开启校验、把加密传输送到自己选择的解析器、在目标上使用应用层 TLS。三者各自独立，少做一项就会留下另一种缺口。

分别检查校验和传输

两个测试能解决大部分困惑。第一个问解析器有没有校验这个回答；第二个问传输有没有受到保护。它们的失败方式不同，也互不蕴含。

这些命令会打印一次校验型查询的标记、在关闭检查的情况下重做查询，并用 delv 执行本地校验：

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

带有已认证数据标记、并且存在签名的回答，说明该解析器完成了校验。用 delv 出现校验失败，说明该区与信任锚之间某处的链断了，这属于 发布侧的问题，而不是隧道的问题。完全没有标记的超时是传输或可达性问题，把它当成签名失败会把你引向错误的层次。

VPN 破坏解析时该怎么办

如果解析在隧道建立前正常、建立后停止，就比较每条路径各自使用的解析器。分离隧道、只能经隧道到达的内部解析器，以及会改写解析器设置的客户端，都会在不触碰 DNSSEC 的情况下改变回答。

全局关闭校验是错误的第一个动作，因为它去掉了唯一会报告篡改的机制，也修不好一个无法到达的解析器。先把故障范围缩小：解析、传输、校验，然后才是策略。只有第三项属于 DNSSEC，只有第二项属于加密传输。