01 · 研究背景与意义
1.1 明文DNS的结构性脆弱
传统DNS解析基于UDP/TCP 53端口明文传输。这意味着：在"终端—递归解析器"之间链路上的任何被动观察者（公共Wi-Fi中的同网段攻击者、恶意热点运营者、中间网络设备）都可以完整读取用户发起的全部查询内容；任何中间主动攻击者都可以在链路上篡改应答实施劫持。即便递归到权威之间的链路情况略好（QNAME最小化等缓解措施），终端到递归这一"第一跳"始终是明文暴露面最大的环节——这正是本课题所研究的三类加密协议要保护的核心区段。
需要明确界定保护边界：加密DNS保护的是"终端↔递归解析器"这一段；递归解析器本身仍然能够完整看到终端发起的每一条查询（这是协议设计的固有属性，ODoH等机制试图缓解，见第2页§04）；递归到权威之间的链路由其他机制（QNAME最小化 RFC 9156、DNSSEC等）部分覆盖。任何"加密DNS=DNS全面加密"的宣传都是不准确的。
1.2 隐私威胁模型：三个观察点
评估加密DNS的收益，必须先建立清晰的隐私威胁模型。RFC 6973（Privacy Considerations for Internet Protocols）确立的"观察者（observer）"分析框架将DNS隐私风险归纳为三类观察者：
| 观察者 | 可见内容（明文DNS下） | DoH/DoT/DoQ缓解程度 |
|---|---|---|
| 本地网络观察者 同网段/同一Wi-Fi/热点运营者 | 全部查询域名、查询时序、源IP | 强缓解：查询内容被TLS/QUIC加密，只能观察到与某解析器的连接元数据 |
| 路径中间人 运营商链路上的任意中间设备 | 全部查询，并可篡改应答实施劫持 | 强缓解（机密性）+完整性保护：篡改会导致证书校验/完整性校验失败 |
| 上游递归解析器 所选的公共/运营商递归 | 全部查询（加密前后均无变化） | 不缓解：信任从"链路上的众多观察者"转移收敛为"单一解析器运营者" |
框架来源：RFC 6973（观察者模型）、RFC 7626（DNS Privacy Considerations，dprive工作组对DNS特定隐私风险的分析）。
研究意义一句话概括：加密DNS将DNS隐私问题从"链路上人人可见"转化为"信任谁可见"，问题的性质从技术机密性问题转变为信任模型与治理问题——这就是本课题需要系统评估的根本所在：协议解决了什么、没有解决什么、新的集中化风险如何治理、企业如何在新格局下重建合规可见性。
1.3 与DNSSEC的互补关系（常见混淆点前置澄清）
加密DNS与DNSSEC（子课题02）解决的是不同维度的问题，二者互补而非替代：DNSSEC提供完整性+来源真实性（应答是否来自真正的权威、内容是否被篡改），但不提供机密性（任何人都能读取明文内容）；DoH/DoT/DoQ提供机密性+通道完整性（链路观察者看不到、改不了），但不验证应答是否来自合法权威（除非递归侧同时做DNSSEC验证）。理想状态是"加密通道+DNSSEC验证"叠加：第2页§06将给出两者的组合矩阵。
02 · 研究目标与关键问题
- 协议认知：准确、无营销滤镜地刻画DoH/DoT/DoQ/ODoH/OHTTP的技术机制、能力边界与相互差异（第2页）。
- 生态摸底：盘点公共递归、操作系统、浏览器、网络设备侧的部署现状与默认化趋势（第3页）。
- 风险量化：建立加密DNS的收益—风险对照模型，覆盖隐私、安全、可用性、滥用四个维度（第4页）。
- 治理平衡：在《网络安全法》等国内法规框架下提出企业可控、监管可接受的加密DNS治理方案（第5、6页）。
- 测量能力：建立可复现的加密DNS采用率与解析质量测量方法学（第7页）。
2.1 三个关键研究问题
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 隐私收益的真实性 | 加密DNS究竟把"谁看得见"从哪些观察者转移到哪个主体？对最终用户的真实隐私收益如何量化，是否存在被高估的宣传成分？ | 第1/4页 |
| KQ-2 | 集中化的系统性风险 | 解析流量向少数云厂商公共递归集中，带来的单点故障、司法管辖、信任与反垄断维度风险如何评估与缓释？ | 第3/4页 |
| KQ-3 | 合规可见性重建 | 国内法规要求网络日志留存与安全审计，而加密DNS天然削弱企业侧DNS可见性，企业如何在"加密"与"可审计"之间取得工程可行的平衡？ | 第5/6页 |
2.2 研究范围界定
- 协议范围：以RFC 7858（DoT）、RFC 8484（DoH）、RFC 9250（DoQ）三大标准协议为主体，兼顾RFC 9230（ODoH）、RFC 9292（OHTTP）、RFC 9460（SVCB/HTTPS RR）、RFC 9463（DDR）等配套机制；对尚处草案阶段的方案（如 oblivious HTTP变体演进、后量子迁移）仅作趋势跟踪。
- 区段范围：聚焦终端到递归段；递归到权威段的加密与最小化（RFC 9156）仅作关联引用，不展开。
- 立场范围：本课题以防御与治理为导向，不提供规避监管的实操指引；涉及攻击面分析仅用于理解威胁与构建防御。
03 · 加密DNS协议全景对比
三大主流协议的标准化轨迹与核心参数如下（均为IETF已发布RFC，可直接溯源）：
| 维度 | DoT | DoH | DoQ |
|---|---|---|---|
| 标准 | RFC 7858（2016-05） | RFC 8484（2018-10） | RFC 9250（2022-05） |
| 传输层 | TCP之上的TLS 1.3（RFC 8446） | HTTPS（HTTP/2 RFC 9113 / HTTP/3 RFC 9114） | QUIC v1（RFC 9000）之上的TLS 1.3 |
| 默认端口 | TCP 853（IANA已分配"dns-tls"） | TCP/UDP 443（与HTTPS共端口） | UDP 853（IANA已分配"dns-quic"） |
| 报文封装 | 2字节长度前缀 + DNS wire format | application/dns-message媒体类型；GET（base64url）或POST | QUIC STREAM帧承载DNS报文（一查询一流） |
| 0-RTT | 不支持（TCP握手+TLS握手固有延迟） | 依赖TLS 1.3 early data（受服务端策略限制） | 原生支持（QUIC 0-RTT）——冷启动延迟最优 |
| 网络可识别性 | 高：专用853端口，易被策略识别与阻断 | 低：与HTTPS Web流量同端口同协议栈，难以区分（双刃剑：隐私强/管控难） | 中：UDP 853专用端口，可识别但具备QUIC的抗阻断特征 |
| 队头阻塞 | 存在（TCP层） | HTTP/2存在（TCP层）；HTTP/3缓解 | 无（QUIC流级多路复用） |
| 典型部署方 | Android"私人DNS"、企业网关 | 主流浏览器、Cloudflare/Google公共递归 | 新兴公共递归（如Cloudflare、AdGuard等提供DoQ服务） |
总体判断（第8页将展开论证）：DoH赢得了生态与默认化之战（浏览器与云厂商合力），DoT赢得管控与识别便利（专用端口利于企业策略），DoQ代表性能演进方向（0-RTT+无队头阻塞，随QUIC普及而增长）。三协议并非替代关系，而是在不同约束下的并存选项。
04 · 本子课题的八页研究框架
与其他子课题的衔接：加密DNS是子课题01（劫持检测）中"链路中间人篡改"类劫持的根本性缓解手段之一；与子课题02（DNSSEC）构成"机密性×完整性"互补矩阵（详见第2页§06）；其集中化趋势又是子课题06（解析基础设施韧性）中递归集中度风险的重要输入。
05 · 核心研究内容总览
| 编号 | 研究内容 | 要点 | 展开位置 |
|---|---|---|---|
| E1 | 协议机制深度解析 | 三协议握手、封装、0-RTT、队头阻塞、降级与容错；认证模式（RFC 8310） | 第2页 |
| E2 | 隐私增强架构 | ODoH（RFC 9230）目标-中继信任分离、OHTTP（RFC 9292）、ECH（RFC 9849）联动 | 第2页 |
| E3 | 发现机制 | SVCB/HTTPS RR（RFC 9460）、DDR（RFC 9463）、ADN验证与降级策略 | 第2/3页 |
| E4 | 部署生态摸底 | 公共递归图谱、OS/浏览器支持矩阵、默认化策略与争议事件 | 第3页 |
| E5 | 收益—风险对照模型 | 观察者消除矩阵、中心化风险、恶意滥用、协议攻击面、故障域 | 第4页 |
| E6 | 监管映射与治理框架 | 国内法规条款映射、国际治理样本、企业合规冲突与平衡框架 | 第5页 |
| E7 | 企业管控工程 | 识别技术清单、三类管控架构、自建加密递归、检测工程、路线图 | 第6页 |
| E8 | 测量方法学 | 采用率与性能测量、解析质量指标、研究伦理与可复现性 | 第7页 |
06 · 常见认知误区与术语辨析
| 误区/混淆 | 辨析 |
|---|---|
| "加密DNS=匿名上网" | 错误。递归解析器仍可见全部查询；目标网站仍可见你的IP；连接时序与流量规模仍可被流量分析。加密DNS消除的是特定链路上的明文暴露，不是匿名性。 |
| "加密DNS可以替代DNSSEC" | 错误。两者正交：DNSSEC防的是应答篡改与伪造来源（完整性与真实性），加密DNS防的是链路窃听与中间人篡改（机密性与通道完整性）。详见第2页§06互补矩阵。 |
| "DoH比DoT更安全" | 错误（作为无条件命题）。两者密码学强度一致（均基于TLS 1.3）；DoH的优势是流量形态隐蔽（混入Web流量），劣势同样是难以被企业策略识别与管控。"更安全"取决于威胁模型中的观察者是谁。 |
| "用了加密DNS就不会被劫持了" | 错误。本地hosts篡改、路由器DNS被改、恶意软件直接写入系统解析结果、递归本身作恶或被攻陷，均不受加密DNS保护——这正是子课题01检测体系仍需存在的原因。 |
| "公共递归=中立基础设施" | 错误。公共递归是商业或准商业实体运营的服务，受其隐私政策、司法辖区、经营状态约束；"换用8.8.8.8/1.1.1.1"本质是把信任从运营商转移给云厂商，而非消除信任。 |
| "阻断853/443上的DoH就能管住" | 错误。与Web同端口的DoH难以与正常HTTPS区分；粗暴阻断可能误伤正常网站；且存在回落到明文53的降级风险——第6页将给出工程上更优的管控架构。 |
6.1 核心术语速查
| 术语 | 释义 |
|---|---|
| DoH / DoT / DoQ | DNS over HTTPS（RFC 8484）/ over TLS（RFC 7858）/ over QUIC（RFC 9250），三大加密解析协议 |
| ODoH | Oblivious DNS over HTTPS（RFC 9230）：经由中继转发、由目标加密应答，使目标不知客户端IP、中继不知查询内容 |
| OHTTP | Oblivious HTTP（RFC 9292）：将ODoH思想推广到任意HTTP请求的通用中继隐私架构（基于HPKE加密） |
| SVCB / HTTPS RR | 服务绑定/HTTPS资源记录（RFC 9460）：在DNS中公告某域名的服务 endpoint、ALPN、IP提示、ECH配置等参数 |
| DDR / ADN | 网络指定解析器的发现机制（RFC 9463）/ 认证域名（Authentication Domain Name）：用于验证加密解析器身份的域名 |
| HPKE | 混合公钥加密（RFC 9180）：ODoH/OHTTP的底层加密原语 |
| 0-RTT | 零往返时间握手：复用先前会话参数在首个数据包中携带应用数据，显著降低冷查询延迟（DoQ原生支持） |
07 · 研究边界与合规声明
合规与伦理声明：①本课题全部内容以防御、评估与治理为目的，严格遵守《网络安全法》《数据安全法》《个人信息保护法》等法律法规；②课题仅对公共基础设施（公共递归服务、公开协议）进行测量研究，不涉及对任何个人用户的定向观测；③攻击面分析仅用于理解威胁与构建防御，不对外提供可直接复用的攻击实现或规避监管的操作指引；④所有事实性表述均可溯源至公开RFC、IETF文档、监管文件或公开报道，引用处均标注来源；⑤涉及国内监管要求的解读为学术研究性分析，不构成法律意见，合规结论以主管部门正式解释为准。
知识产权边界：文中引用的RFC文本遵循IETF Trust的许可条款（IETF贡献可按其许可政策复制使用）；ODoH/OHTTP等术语与机制描述以RFC原文为准；浏览器与云厂商相关策略描述基于其公开发布的官方文档与公告。
08 · 预期成果与交付物
- 《加密DNS协议安全评估》研究报告一份（含协议全景对比、收益—风险对照模型、监管映射表）
- 公共加密递归服务生态图谱与选型核查清单（协议支持、隐私政策要点、司法辖区）
- 企业加密DNS治理实施方案模板（三类管控架构+自建网关配置基线+日志合规要点）
- 加密DNS测量工具包与数据集说明（可复现的采用率/性能/质量测量脚本）
- 面向培训场景的误区辨析速查表（与识别指南联动）
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF RFC、IETF Trust文档），用于支撑本页事实性表述。
RFC 7858, Specification for DNS over Transport Layer Security (TLS)（2016）：rfc-editor.org/rfc/rfc7858
RFC 8484, DNS Queries over HTTPS (DoH)（2018）：rfc-editor.org/rfc/rfc8484
RFC 9250, DNS over Dedicated QUIC Connections（2022）：rfc-editor.org/rfc/rfc9250
RFC 7626, DNS Privacy Considerations（2015，dprive工作组）：rfc-editor.org/rfc/rfc7626
RFC 6973, Privacy Considerations for Internet Protocols（2013，观察者框架出处）：rfc-editor.org/rfc/rfc6973
RFC 8310, Usage Profiles for DNS over TLS and DNS over DTLS（2018，认证与严格/机会模式）：rfc-editor.org/rfc/rfc8310
RFC 9156, DNS Query Name Minimisation to Improve Privacy（2021）：rfc-editor.org/rfc/rfc9156
IETF DPRIVE工作组主页：datatracker.ietf.org/wg/dprive