加密 DNS 总览
加密 DNS 解决的是“路上的人能看到、能改你的查询”这个问题。它不解决“解析器本身看得到一切”，也不会自动让你的上网行为隐身。弄清楚它保护的是哪一段，才谈得上怎么选。
明文 DNS 的问题#
传统 DNS 查询以明文走 UDP/53。同一网络里的任何人、你的运营商、沿途的设备，都能看到你在查哪些名字，并且可以：
- 记录：查询记录几乎就是浏览记录的目录；
- 篡改：把应答改成别的地址，或改成“不存在”；
- 抢答：不拦截原报文，而是抢在真实应答之前注入一个伪造应答——UDP 上谁先到客户端就信谁。
DNSSEC 能让客户端发现应答被篡改（前提是客户端或它信任的解析器做验证），但它不加密任何内容，也挡不住“丢弃应答”这种干扰。加密 DNS 与 DNSSEC 解决的是不同的问题，两者互补而不是互相替代。
两段路径#
一次解析涉及两段通信，加密的进展很不一样：
- 设备 → 递归解析器
- 这是 DoT、DoH、DoQ 主要保护的一段，客户端和服务器都已普遍支持。
- 递归解析器 → 权威服务器
- 大部分仍是明文。RFC 9539（实验性，2024 年）描述了“单方面机会式加密”：解析器探测权威服务器是否在 853 端口提供 DoT 或 DoQ，能用就用，不能用就回到明文，不要求对方事先配置什么。部署还很有限。
所以即使你用了加密 DNS，解析器去问权威服务器时，沿途仍可能看到查询的名字（只是看不到来自哪个用户），QNAME 最小化在这一段能减少暴露，见隐私页。
几种方案对比#
| 方案 | 传输 | 端口 | 规范 | 特点 |
|---|---|---|---|---|
| DoT | TLS / TCP | 853 | RFC 7858 | 结构最简单，独立端口，容易被识别和单独封锁；Android“私人 DNS”使用它。 |
| DoH | HTTP/2、HTTP/3 | 443 | RFC 8484 | 和网页共用端口与协议，难以单独区分；浏览器内置支持最广；多了一层 HTTP 开销。 |
| DoQ | QUIC | 853/UDP | RFC 9250 | 没有队头阻塞，握手快，可迁移连接；客户端支持面比前两者窄。 |
| DNS over DTLS | DTLS / UDP | 853/UDP | RFC 8094 | 实验性，基本没有实现，可视为被 DoQ 取代。 |
| DNSCrypt | UDP 或 TCP | 通常 443 | 社区规范 | 早于 IETF 方案出现，用自己的密码学封装而非 TLS；有一批客户端和公共服务器，但不是 IETF 标准。 |
| Oblivious DoH（ODoH） | HTTPS 经中继 | 443 | RFC 9230 | 实验性。代理知道你是谁但看不到查询，目标解析器看到查询但不知道你是谁，前提是两者不串通。 |
对多数用户来说，差别主要不在密码学强度上——它们最终都依赖 TLS 1.3 或同级别的加密——而在于能否穿过所在网络、系统和应用是否支持、出问题时能否排查。
严格模式与机会模式#
加密只在你确认对方身份时才有意义，否则中间人可以自己终结 TLS 再转发。RFC 8310 定义了两种使用方式：
- 严格模式（Strict）：客户端事先知道解析器的认证名（比如
dns.example）或公钥指纹，验证不过就不用，宁可解析失败。 - 机会模式（Opportunistic）：能加密就加密，验证不了也照样用，甚至退回明文。它能防被动窃听，防不了主动攻击。
Android 的“私人 DNS”选“自动”时是机会模式，填入主机名时是严格模式。Windows 和各浏览器在手动填写 DoH 模板时，都会校验证书。
解析器怎样被发现：DDR 与 DNR#
网络通过 DHCP 或路由器通告下发的通常只是一个 IP 地址，客户端并不知道这个地址是否支持加密、用什么名字验证证书。两种标准化的办法：
- DDR（Discovery of Designated Resolvers，RFC 9462）：客户端向已知的明文解析器查询
_dns.resolver.arpa的 SVCB 记录，得到它“指定”的加密解析器。为防被冒充，指定解析器的证书必须同时覆盖原来那个明文解析器的 IP 地址。 - DNR（Discovery of Network-designated Resolvers，RFC 9463）：直接在 DHCPv4、DHCPv6 或 IPv6 路由器通告里携带加密解析器的名字、地址和参数。
两者都使用 RFC 9461 定义的 SVCB 参数：alpn 标明协议（dot、h2、h3、doq），dohpath 给出 DoH 的 URI 模板。例如：
SVCB 记录
_dns.resolver.arpa. 300 IN SVCB 1 dns.example.net. alpn="dot,doq" port=853
_dns.resolver.arpa. 300 IN SVCB 2 dns.example.net. alpn="h2,h3" dohpath="/dns-query{?dns}"加密 DNS 做不到什么#
- 解析器全都看得见。你把信任从网络运营者转给了解析器运营者。选谁，取决于你更信任哪一方，以及对方公开的日志策略。
- 连接本身还会说话。拿到地址以后，你还要去连接它。目标 IP 是明文的，TLS 握手里的 SNI 默认也是明文的。TLS Encrypted Client Hello（ECH，RFC 9849，2026 年 3 月发布）把 SNI 也加密了，但需要服务器支持，而且它的配置本身通过 DNS 的 HTTPS 记录分发——这又回到了 DNS 需要被保护的问题。
- 长度和时序会泄露信息。加密后报文长度仍然可见，不同名字的查询和应答长度不同。填充（RFC 7830、RFC 8467）缓解这个问题，但不能消除时序特征。
- 可能绕过本地策略。应用自带的 DoH 会绕过家长控制、企业内网解析、内部域名，这既是优点也是麻烦。Firefox 为此约定：若网络的解析器对
use-application-dns.net回答 NXDOMAIN，就不默认启用 DoH。
怎么选#
没有放之四海皆准的答案，但有几条比较稳的经验：
- 优先用系统层面的设置，而不是每个应用各开各的。这样所有程序走同一个解析器，出问题只需要查一处。
- 在会干扰 853 端口的网络里，DoH 往往是唯一能用的；在网络正常、设备支持的情况下，DoT 或 DoQ 更简单，排错也更直接。
- 用严格模式。一个“能退回明文”的加密配置，面对有意的干扰时和没加密差不多。
- 别忘了 DNSSEC。加密保护的是你到解析器这一段；解析器拿到的数据是否被权威侧之外的人篡改过，要靠验证来确认。