TLS 之上的 DNS 与 VPN：哪一部分受到保护

TLS 之上的 DNS 加密客户端与它所选解析器之间的交换，而解析器仍然读得到名字。这句话足以理清围绕 DoT 与 VPN 的大部分混乱。隧道决定加密后的查询走哪条路径，而解析器依然知道被问的是什么。两种机制互不替代，也都不让另一种变得多余。

四项检查决定你手上的配置是否真是你以为的那一套。

检查 1：加密覆盖了什么

DoT 把 DNS 交换包在 TLS 里，所以路径上的观察者看到的是连向某个地址和端口，而不是查询里的名字。解析器自己解密并作答。把它与 HTTPS 之上的 DNS 相比：两者都加密，但使用不同的传输，因此允许网页流量的网络不会自动允许 DoT 连接。

当强制门户或过滤中间盒放行 443 而阻断 853 时，这个区别就有意义。在那里能用的工具，并不能证明另一个也能用。

检查 2：查询走哪条路径

路径是客户端策略的问题。DoT 解析器可以从隧道内、隧道外，或随网络变化的路径到达。究竟走哪条，取决于路由，也取决于客户端是否保护自己的 DNS 套接字。捕获全部流量的隧道通常会把查询一并带走，无论解析器地址写着什么。

在测试里看到第三方解析器地址 并不能证明被绕过，看到加密也不能证明收件人就是你想要的那个。把解析器和路径分开来读，然后再判断这一对是否就是你设计的。

检查 3：内网名称

发布内网名称的组织需要一个持有这些记录的解析器。公共 DoT 服务不认识你的私有命名空间，把客户端指向它，就注定这些名称会解析失败。这是有人在受管设备上启用加密 DNS 时最常见的实际倒退。

为内网后缀保留内部解析器，并在策略要求时加密那一跳，而不是用公共提供商把它替换掉。

检查 4：失败时的行为

严格的解析器设置若没有可达的解析器，会在隧道仍然在线的情况下产生名称解析失败。此时应看平台模式及其文档化的回退，而不是去动密钥或证书。

静默改用明文 DNS 的回退是策略决定，不是便利。决定失败应当可见，还是应当降级到更弱的东西，并把这个答案写下来。

相信证书，而不是答案

使用为该服务文档化的提供商主机名和校验配置。为了让陌生解析器作答而关闭 TLS 校验，等于给你一条通往未验证端点的加密信道；它在某一点上比它取代的明文查询更糟：它看起来是安全的。DNS over TLS 规范阐明了那道校验背后的认证预期。

来自你无法认证的解析器的答案只是声称，不是结果。

这留下了什么没解释

DoT 并不向解析器隐藏名字，也不向网络隐藏连接的目的地址，更不决定查询是否走了隧道。那是三个独立的问题，有三个独立的答案。

把解析器身份、转发路径和内网名称策略写成三行。你遇到的下一个 DNS 问题，会是其中之一。