① 同一局域网内的人
同一个 Wi-Fi 下的其他设备、提供 Wi-Fi 的场所。明文 DNS 在这里是广播式的，抓包即可看到全部查询。
能做什么：被动记录，甚至伪造响应（example.com 指向它自己的机器）。
防住它：任何加密都够用，因为威胁离你最近。
BASICS
基础与威胁模型
先把两件事讲清楚：DNS 在访问流程里处于什么位置，以及链路上究竟有谁在看。这两点定了，后面选协议才不会盲选。
DNS 发生在最前面，所以它暴露得最早
访问一个网站要经过四步，DNS 是第一步 —— 而这决定了它与 HTTPS 的隐私性质完全不同。
① 解析
DNS：example.com 的 IP 是什么？
这一步没有 HTTPS 保护
② 连接
TCP 三次握手 → 目标 IP
此时目标 IP 已经暴露
③ 加密
TLS 握手（SNI 通常为明文）
域名又暴露一次
④ 请求
HTTP 请求
到这里内容才真正被加密
你只问了一次，但背后发生了四次往返
递归解析器替你跑腿（这叫迭代查询）。理解这一点，才能理解为什么首次查询慢、为什么缓存重要。
① 你发出唯一一次查询
你的设备（stub resolver）只做一件事：把问题交给配置里指定的递归解析器，然后等回答。它不关心、也不知道背后发生了什么。
这一步通常走明文 UDP 53 —— 也就是说，链路上的观察者此刻已经能看到你在问什么。
② 递归解析器先查自己的缓存
如果最近有人问过同一个域名且 TTL 未过期，它直接回答你 —— 这就是「第二次访问同一个网站感觉更快」的原因。
没命中才继续。此刻它需要自己去找答案，而它不知道谁来负责 example.com，所以必须从根开始问。
③ 问根服务器：谁来管 .com？
根服务器不回答具体域名，它只回答「去问谁」：.com 的顶级域服务器地址。
这一步的回应叫 referral（引荐）。注意：根服务器看不到你要查的完整域名以外的信息，但它确实知道你问过 example.com —— 这也是隐私讨论里的一部分。
④ 问 .com 顶级域：谁来管 example.com？
同样只得到引荐：example.com 的权威服务器地址。此时才第一次知道最终该问谁。
到这里已经用掉三次往返，而你的设备对此一无所知 —— 它始终只是在等第一个回答。
⑤ 问权威服务器，拿到答案
权威服务器是唯一真正持有这个域名记录的机器。它返回 IP 地址。
递归解析器把结果按 TTL 缓存下来（下次别人问就能直接答），再把结果返回给你的设备。你只等了这一次往返，但网络上发生了四次。
由此可以引出三个实际结论： （1）缓存决定了体验 —— 冷缓存时要跑四次往返，热缓存时一次都不用； （2）链路上不止一个观察者 —— 递归解析器、根、TLD、权威都在查询路径上； （3）加密 DNS 保护的是「你到递归解析器」这一段，而不是整条链路的每一跳。 最后一点经常被误解，展开见下一节。
链路上有谁在看
「别人能看到我的 DNS」这句话太笼统。具体分四类，各自能做什么并不相同。
② 你的网络运营商
具备全量流量视角，可长期记录并按用户关联。这不是理论威胁，而是多数地区事实上存在的能力。
能做什么：记录、按政策过滤、劫持错误响应到广告页。
防住它：加密内容 + 让查询混进普通流量（DoH/DoH3 在这一项上更强）。
③ 路径上的任意中转节点
骨干网上的设备、透明代理、你公司出口的网关。位置不固定，你通常不知道有哪些。
能做什么：与运营商类似，但权限更零散、更难追责。
防住它：同上一类。这一类的存在说明「我信任我的运营商」不足以作为安全假设。
④ 递归解析器本身
前三类都能被加密挡在门外，这一类挡不住 —— 它必须看懂你的查询才能回答。
能做什么：记录全部查询、构建画像、按政策返回不同结果。
怎么办：只能靠选址与制度（选谁、它的日志政策是什么），或引入中继（见 ODoH）。
前三类与第四类的区别，是理解 DNS 隐私的分水岭：加密能把「链路上任何人」挡掉，但挡不掉「你主动交给的那一方」。
所以加密 DNS 的收益是真实的，但它的上限也在这里 —— 后面「风险与治理」与「协议选型」都建立在这个前提上。
你选的解析器，往往不是某一台机器
主流公共解析器普遍使用 anycast：同一个 IP 地址在多处同时宣告，由路由决定你去哪一台。
切换你的位置看路由结果：
把威胁拆成四类，才能看清各自防得住什么
笼统说「不安全」无法指导决策。四类攻击的难度、目标与对策都不一样。
| 攻击类型 | 攻击者要做什么 | 典型后果 | 难度 |
|---|---|---|---|
| 被动监听 | 只读流量，不修改任何数据 | 完整掌握你访问了哪些域名 | 低（同一 Wi-Fi 即可） |
| 响应伪造 | 抢在真实响应前回一个假的 | 你被导向攻击者的服务器，而浏览器地址栏可能完全正常（若证书也能伪造则更糟） | 中（需抢时序，明文 UDP 下仍常见） |
| 阻断 | 丢弃或拒绝特定查询 | 域名「打不开」，表现为超时而非错误页 | 低 |
| 关联分析 | 不读内容，只看流量大小与时间规律 | 即使内容加密，也能推断出你在做什么 | 中高（需要较长时间样本） |
注意最后一行：加密内容不等于隐藏行为。DNS 查询通常很小、模式规整，恰好是最容易被指纹化的流量类型之一 —— 这也是 RFC 8484 里专门讨论填充（padding）的原因，虽然目前实际部署中很少启用。
最容易混淆的一点：DNSSEC 不等同于加密 DNS
两者常被当成同类方案，实际上解决的问题完全不同，且不能互相替代。这不是本站的说法，是两条 RFC 的原文结论。
| 攻击 / 风险 | 加密 DNS （DoT / DoH / DoH3 / DoQ） |
DNSSEC |
|---|---|---|
| 链路上被窃听查询内容 | ✓能防住 TLS / QUIC 加密了这一段 | ✗防不住 DNSSEC 不加密，查询仍是明文 |
| 响应被中途篡改（指向假 IP） | ✓能防住 传输层完整性校验会发现改动 | ✓能防住 签名验证直接识别伪造 |
| 解析器缓存被投毒 | ~只保护一段 管不到解析器向外查的过程 | ✓能防住 数据有签名，投毒也验不过 |
| 域名被要求封锁 | ~有时能绕 DoH / DoH3 更难被单独拦，整体封锁仍会生效 | ✗防不住 不解决可用性问题 |
| 查询内容被解析器长期记录 | ✗防不住 解析器必须看懂查询才能回答 | ✗防不住 与 DNSSEC 无关 |
两条 RFC 说得更直接：
RFC 8484（DoH）原文 ——
「The HTTPS connection provides transport security... but it does not provide the response integrity of DNS data provided by DNSSEC. DNSSEC and DoH are independent and fully compatible protocols, each solving different problems.」
RFC 7858（DoT）原文 ——
「DNSSEC and DNS over TLS are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.」
NIST SP 800-81r3 则从另一端表述：DNSSEC 可以保证响应的完整性，但它
「does not protect the confidentiality of DNS」。
结论：不是二选一，而是都要。
加密 DNS 解决「谁看得到」，DNSSEC 解决「数据是否可信」。
实际做法通常是：用加密 DNS 连接到一个会做 DNSSEC 校验的解析器，
这样既加密了链路，也让返回的结果经过了签名验证。
要真正把「你访问了谁」藏起来，需要三层叠加
前面几节分别提到了它们。三层各自补一个不同的漏洞，缺一层就漏一处。
| 层 | 补的是哪个漏洞 | 规范 | 现状 |
|---|---|---|---|
| 加密 DNS | 链路上不该看到「你在问什么」 | RFC 7858 / 8484 / 9250 | 浏览器与系统普遍支持 |
| DNSSEC | 返回的答案不该被伪造或投毒 | RFC 4033–4035 | 需解析器配合；终端侧校验并不普遍 |
| ECH | TLS 握手里的 SNI 会暴露目标域名 | RFC 9849（配置经 RFC 9848 通过 SVCB 发布） | 已标准化，但需要服务端部署支持，覆盖率仍有限 |
顺序上也有依赖：ECH 的配置是通过 DNS 记录（SVCB）发布的。若这一条 DNS 查询被篡改，客户端可能拿不到正确的 ECH 密钥 —— 这又是一个「DNS 的可信性是其它保护的前提」的例子。
加密 DNS 明确做不到的事
把边界写清楚，比夸大收益更有用 —— 这四条常被误解成「加密后就没有了」。
隐藏你连到了哪个 IP
知道域名之后必然要连过去，目标 IP 在流量里是明文可见的。除非再叠加代理或 Tor，否则这一步无法隐藏。
隐藏 SNI（不叠加 ECH 时）
TLS 握手里的 SNI 通常明文携带目标域名，等于把 DNS 层刚藏起来的信息又暴露一次。需要 ECH 才能补上。
抵御流量关联分析
加密只改变内容，不改变包的大小与时间分布。长期观察仍可推断行为模式，这也是填充（padding）提议存在的原因。
替代终端安全与 HTTPS
它保护的只是一次域名解析。若终端已被植入恶意程序，或站点本身证书错误，加密 DNS 都无能为力。
三个最常见的误区
它们不属于「做不到」，而是「理解偏了」—— 后者更麻烦，因为它会让人对现状产生虚假的安全感。
把加密 DNS 等同于匿名方案
它保护的只是「你到解析器」这一段链路。目标 IP、TLS 握手里的 SNI、流量形状都还在， 而且解析器本身看得到你的全部查询。
「匿名」需要的是另一类工具（如 Tor），加密 DNS 不承担这个目标。
只看协议名称，不验证服务器可信度
DoH 与 DoT 只保证「这一段链路是加密的」，不保证对面是谁（除非启用严格的身份校验）。
所以「我用了加密 DNS」并不等于「我的查询没被记录」—— 真正决定这件事的是解析器是谁、它的日志政策是什么。
忽略日志策略与运维成本
把加密DNS 当成一次性配置：装完就没人管了。实际成本主要在长期—— 证书到期、上游变更、监控与回滚能力都需要持续投入。
这也是为什么风险与治理把「治理能力」也列为一种资产。
接下来
基础与威胁模型到这里够了。下一步是具体协议各自怎么解决这些问题。