经 DNS 的 VPN 与 VPN 的 DNS 服务器不是一回事

经 DNS 的 VPN 描述的是一种传输思路，并不等于把设备指向自定义解析器。能澄清混乱的问题很简单：DNS 报文实际承载的是什么？普通 VPN 可能安装解析器，让被覆盖的应用找到私有名称，而更换该解析器只改变名称解析。请按顺序执行下面的检查，因为三种安排只共用术语，别的几乎毫不相干。

把三种安排分开

第一种安排中，VPN 提供解析器或名称策略设置。应用数据仍走自己的网络连接，隧道只影响由哪台服务器回答查询。

第二种安排中，加密 DNS 保护 DNS 交换本身。DNS over HTTPS 与 DNS over TLS 把查询封装到所选解析器，且不承载任何其他应用的数据包。它们也不会对你所选解析器隐藏查询名，这与对本地网络隐藏查询名是不同的信任边界。

第三种安排中，协作的客户端把其他数据编码进 DNS 报文，协作的端点再把它还原。普通的解析器路径成了传输通道，解析器此时是数据路径的组成部分，而不是名称服务。

更换解析器，观察应用的流量路径是否改变。如果应用仍通过相同套接字连接相同地址，你改变的只是名称解析。

由 DNS 承载的隧道需要服务器端有对应的安排。Iodine 是一个有文档的例子：其项目文档描述了穿过 DNS 的 IP 隧道，并要求有理解编码的服务器组件。在 Android 里填入公共解析器地址并不会提供那个端点，而两个产品共用的营销术语也不是协议规范。

抓包是决定性的检查。如果只看到发往解析器的普通查询而没有别的，就没有隧道。如果看到查询名和响应里编码着载荷，你找到了承载者，下一个问题就是它能搬多少。

DNS 是为查询与应答设计的，不是为批量交付。编码开销、报文大小限制和解析器行为都会占去标称路径的一份，因此可用容量低于底层链路给人的印象。凡是没在自己路径上测过的吞吐数字，都应视为假设而非预算。两个方向都要测，因为在请求-应答型承载上，上传与下载可能撞上不同的限制。

客户端还得决定哪些流量进入隧道。本地 VPN 服务接口可以收集数据包，但接口本身对远端传输如何保护或转发这些包一无所知。当承载者是请求-应答协议而不是流时，分片与重传的表现不同，而一条保持打开的连接对交互延迟说明不了多少。

用你打算承载的流量来测。对周期性心跳很合适的隧道，放到交互式会话里可能完全不可用，反过来也一样。

不要以为 DNS 封装就提供了机密性或强认证。解析器路径和隧道端点能看到实现所暴露的东西，而暴露程度因设计而异。

加密与承载者的选择是两回事。隧道可以在普通 IP 路径上加密，而经 DNS 承载的隧道可以带载荷保护，也可以不带。无论如何都要保住应用的 HTTPS，并评估隧道真实的安全设计，而不是它的名字。

如果需求是对本地网络保密，加密 DNS 与数据隧道回答的是其中不同部分。选定一种之前，先写下你要防的是哪个观察者。

对普通的慢速 VPN 来说，换成经 DNS 承载的隧道只是在问题上又叠了一层受限的传输。它修不好无线质量、拥塞或服务器负载，通常还让这些更显眼。

遇到私有名称故障，先看预期的解析器策略：该由哪台服务器回答、哪些名称在范围内、客户端是否被允许使用。然后再挑与需求相符的获准传输方式，并把解析器配置写进变更记录，免得下一次事故又从头查起。

清单很短：确定属于哪种安排，确认报文承载什么，测容量，然后复核信任。任何与症状对不上的步骤，都说明另外两种安排仍在起作用。