RFC 3833 — IETF 第一次正式承认 DNS 不安全

是什么

RFC 3833 是 IETF 2004 年发的一份威胁分析报告，把当时 DNS 协议在设计层面所有”能被攻击的地方”系统列了一遍。

日常类比：你家小区的快递柜用了 20 年，从来没人系统盘点过它”有几种被偷的姿势”。某天物业请了个安全公司，写了份报告——「门锁是机械锁可撬」「短信验证码可拦截」「快递员私单可冒领」「夜班无监控」……这份报告本身不解决问题，但它把所有威胁说清楚，下一步设计电子锁、视频监控才有靶子。

RFC 3833 就是 DNS 的这份盘点报告。它不修任何漏洞，但它为 DNSSEC 立靶子——半年后发布的 RFC 4033/4034/4035 直接引用它作为威胁模型。

为什么重要

不读 RFC 3833，下面这些问题答不出来：

为什么 DNS 1983 年设计时不加密、不签名？——当时假设网络可信
为什么 2008 年 Kaminsky 攻击能把整条 zone 在几秒内污染？——RFC 3833 第 2.2 节生日攻击的实例
为什么 DNSSEC 解决了”假应答”但没解决”被偷看查询”？——RFC 3833 明确把机密性划在范围外
为什么现代 DNS 安全栈是 DNSSEC + DoT + DoH 三层叠加？——每层解决 RFC 3833 列出的不同威胁

这份 RFC 短，不到 20 页，但它定义了”DNS 安全”这个词的边界。

核心要点

RFC 3833 把 DNS 威胁拆成 6 大类：

包拦截（packet interception）：路径上的攻击者直接看到 / 改写 UDP 报文。DNS 默认明文，路由器 / WiFi 热点都能干。
包猜测（query ID guessing）：DNS 用 16 位事务 ID 关联请求和应答。攻击者抢在真实应答前，伪造一个 ID 匹配的假应答塞给 resolver——这就是后来 Kaminsky 攻击的核心。
名字链攻击（name chaining）：恶意服务器在应答里塞 additional section，把”www.bank.com”指向自己的 IP。早期 resolver 不加区分就缓存。
跨域信任攻击（betrayal by trusted server）：你信任的递归 resolver 本身被攻陷，给你回伪造数据。
拒绝服务（DoS）：超载 authoritative server，让合法用户解析不出来。RFC 3833 说这是另一类威胁，点到即止。
区数据被篡改（authoritative data corruption）：攻击者直接改 zone 文件或攻破私钥。再多签名也救不了。

实践案例

案例 1：Kaminsky 2008 是 RFC 3833 第 2.2 节的实例化

2008 年 7 月，Dan Kaminsky 公布了一个让人震惊的攻击：

攻击者向受害 resolver 反复查 random1.bank.com / random2.bank.com / ...
每个查询，攻击者同时发大量伪造应答（猜 16 位 query ID + 端口）
应答里塞 authority section 把 bank.com 整个 NS 指向攻击者
受害 resolver 一旦命中，整个 bank.com 的所有子域被污染

RFC 3833 第 2.2 节早就把这个威胁原理写清楚了——生日悖论 + 信任 authority section。Kaminsky 只是把它工程化、量化（几秒就能成功）。

案例 2：DNSSEC 怎么对症下药

RFC 4033 引用 RFC 3833 时是这么对应的：

RFC 3833 威胁	DNSSEC 解决吗
包拦截（看）	不解决——签名不加密
包拦截（改）	解决——签名能验出篡改
包猜测	解决——伪造应答签名对不上
名字链攻击	解决——additional section 必须有签名
跨域信任	部分——客户端可自己验签
区数据篡改	不解决——私钥被偷就完了

这张表是读 DNSSEC 系列 RFC 的钥匙。

案例 3：现代 DNS 安全栈三层对照

应用层 (浏览器)
   ↓ DoH (RFC 8484, 2018)         ← 解决 "包拦截看" 威胁
递归 resolver
   ↓ DNSSEC (RFC 4033, 2005)      ← 解决 "包拦截改 + 包猜测 + 名字链" 威胁
authoritative server
   ↑ HSM 私钥保护                  ← 解决 "区数据篡改" 威胁

每一层都来自 RFC 3833 某一类威胁的回应。所以读这份 RFC 的最佳姿势是：对照现代 DNS 安全栈每一层，看它是为了挡住哪一类威胁出现的。

踩过的坑

以为 DNSSEC 加密了 DNS——它只签名，不加密。路径上的人仍能看到你查 bank.com。要保密用 DoT/DoH。
以为部署 DNSSEC 就万事大吉——大多数浏览器 / 操作系统的 stub resolver 不验签。递归 resolver 验完后，回送给客户端的”最后一公里”还是普通 UDP。攻击者只要在最后一公里上动手脚，前面所有签名白做。
忽视 RFC 3833 第 4 节——它单独列了”区数据被篡改”威胁。再硬的密码学也救不了被偷的私钥。HSM、密钥轮转、离线签名是配套。
把缓存污染当成单一漏洞——它实际是”包猜测 + 信任 additional section”两类威胁的组合。早期 BIND 修了一个不够，要两个一起修。
把 NXDOMAIN 当无害——RFC 3833 提到 wildcard 和 NXDOMAIN 应答可被滥用做 zone enumeration（枚举一个域有哪些子域），后来 NSEC3 (RFC 5155) 才补丁。

适用 vs 不适用场景

适用：

学 DNSSEC 之前的必读前置——先理解威胁，再看签名设计就有的放矢
做 DNS resolver / authoritative server 时的威胁清单
评估企业 DNS 安全方案（DNSSEC + DoT + 防火墙）覆盖了哪些威胁面

不适用：

不是密码学教程——不讲签名算法
不是部署手册——不教你配 BIND / Unbound
不覆盖 DDoS 攻击细节——RFC 3833 明说 DDoS 是另一份文档的事
不覆盖隐私威胁——查询被偷看这一面到 RFC 7626 (2015) 才系统讨论

历史小故事（可跳过）

1983-1987：RFC 882/883/1034/1035 定义 DNS——零安全考量，假设网络可信
1990s：DNSSEC 早期草案 RFC 2065/2535——部署困难，作用域不清，几乎没人用
2004-08：RFC 3833 发布——IETF 第一次系统盘点 DNS 威胁
2005-03：RFC 4033/4034/4035 DNSSEC-bis——直接引用 RFC 3833 作为威胁模型
2008-07：Kaminsky 公开攻击——RFC 3833 第 2.2 节的真实样本，推动 DNSSEC 加速部署
2016/2018：RFC 7858 DoT、RFC 8484 DoH——补 RFC 3833 没覆盖的机密性

学到什么

设计安全协议先列威胁清单——RFC 3833 这种”先写威胁报告再做设计”是 IETF 安全协议的标准流程，工业里做安全评审同样套路
威胁分类决定方案边界——DNSSEC 只解决”真实性 + 完整性”，因为 RFC 3833 把机密性划在范围外。范围决定后续 10 年的协议演进路线
协议遗留问题不是技术债——是当年假设变了。1983 年互联网是学术圈节点之间互信，2004 年成了攻击战场
报告本身不修漏洞——但它让”DNS 安全”这个词从模糊变清晰，下游所有方案都建在它上面
威胁模型 ≠ 攻击列表——RFC 3833 列的是协议层面的威胁面，不是具体 CVE。Kaminsky 这种”具体攻击”是把”威胁面”实例化的产物

关联

dns —— RFC 3833 是 DNS 协议的威胁补丁集合，要先懂 DNS 才能看威胁
mockapetris-1988-dns —— 设计者讲为什么 DNS 当年不考虑安全，与 RFC 3833 形成”原因 → 后果”对照
heartbleed-2014 —— 同样是协议漏洞被工程化利用的案例，思路与 Kaminsky 攻击呼应
[[oauth-2.1-rfc]] —— OAuth 同样走”先列威胁再写规范”路线，RFC 6819 之于 OAuth 类似 RFC 3833 之于 DNS
jwt-rfc-7519 —— 签名而非加密的同款思路：JWT 默认只签不加密，与 DNSSEC 同源

反向链接

amplification-hell-2014 —— Amplification Hell 2014 — 把家用宽带放大成几百 Gbps 的反射攻击
codons-2004 —— CoDoNS — 用 P2P 哈希表替代分层 DNS 的实验
dns —— DNS — 把全球域名解析切成一棵可分布维护的树
dot-doh-perf-2020 —— DoT/DoH 性能 — 给 DNS 加密之后网页变快还是变慢
jwt-rfc-7519 —— JWT RFC 7519 — 把身份证装进一段可校验的字符串
mockapetris-1988-dns —— Mockapetris 1988 DNS — 设计者亲口讲为什么 DNS 长这样