常见攻击与防护
DNS 的大多数攻击都利用同一个事实：UDP 上的应答没有可靠的来源证明，而 DNS 又是几乎所有网络服务的前提。下面按“骗解析器”“借 DNS 打别人”“打 DNS 本身”“绕过 DNS 协议”四类整理。
缓存投毒#
解析器向权威服务器发出查询后，会接受第一个“看起来对得上”的应答：源地址、端口、报文 ID 和问题一致即可。旁路攻击者如果能在真实应答到达之前猜中这些值，伪造的应答就会被缓存，影响所有用这台解析器的用户。
2008 年公开的 Kaminsky 攻击（CVE-2008-1447）让这件事变得现实：攻击者不断查询目标域下不存在的随机子域，每一次都是一个新的猜测机会，不必等缓存过期；伪造的应答在授权节里塞入一条把整个域指向攻击者服务器的 NS 记录。当时只有 16 位的报文 ID 是随机的，几秒钟到几分钟就能命中。
防护是叠加的：
- 源端口随机化（RFC 5452）：再增加约 16 位熵，是当年各厂商紧急发布的修复。
- 0x20 编码：随机改变查询名字的大小写，要求应答原样带回，名字越长额外的熵越多。它是一份 2008 年的草案提出的办法，并非 RFC 标准，但很多解析器默认启用。
- DNS Cookie（RFC 7873、RFC 9018）：见下文。
- DNSSEC：唯一能从根本上让伪造数据失效的手段，前提是被查询的区签了名且解析器做验证。
SAD DNS#
2020 年的 SAD DNS 研究表明，源端口随机化可以被侧信道削弱：利用操作系统对 ICMP“端口不可达”消息的全局速率限制，攻击者可以逐段探测解析器当前打开的是哪个端口，把问题重新降回只需要猜 16 位 ID。Linux 内核随后修改了 ICMP 速率限制的实现（CVE-2020-25705）。这个例子说明，防护措施的强度取决于整个系统，而不只是 DNS 软件本身。
反射与放大#
攻击者伪造受害者的源地址，向开放的解析器或权威服务器发送小查询，引出大得多的应答砸向受害者。DNSSEC 签名、ANY 查询、长 TXT 记录都能把放大倍数推得很高。
- 源地址验证（BCP 38，RFC 2827）：网络在出口处丢弃源地址不属于自己的数据包。这是根本办法，但要靠全网的运营者共同落实。
- 响应速率限制（RRL）：权威服务器对同一网段、同一应答的发送速率设上限，超出部分丢弃或回一个截断应答，迫使真实客户端改用 TCP（伪造源地址无法完成 TCP 握手）。BIND、Knot、NSD 等都实现了它，但它不是 RFC 标准。
- 精简 ANY 应答（RFC 8482）：服务器对 ANY 查询只返回一小部分数据，或者一条 HINFO。
- 不做开放递归：递归解析器只为自己的用户服务；真要公开服务，就需要完善的限速与容量规划。
DNS Cookie#
DNS Cookie 是一种轻量的“你确实在这个地址上”证明。客户端在查询中带一个客户端 Cookie；服务器在应答中返回由密钥、客户端 IP 和客户端 Cookie 计算出的服务器 Cookie。之后客户端每次都带上它，服务器就能识别出真实来源，对没有有效 Cookie 的来源采取更严格的限制。RFC 9018 统一了服务器 Cookie 的算法，让同一个任播地址背后的多台服务器能互相认出对方签发的 Cookie。
随机子域攻击#
大量查询 随机串.victim.example：每个名字都不在缓存里，解析器只好全部转给受害域的权威服务器，权威服务器被压垮，顺带拖累中间的解析器。RFC 8198 的“积极使用 NSEC 缓存”对签了名的区很有效：一条 NSEC 证明了一整段名字都不存在，解析器可以直接回答后续的随机查询。没有签名的区，只能靠解析器侧的限速和权威侧的扩容。
NXNSAttack#
2020 年公开的 NXNSAttack 利用转介应答：攻击者控制的权威服务器返回一个包含大量 NS 名字、却不带胶水地址的转介，解析器为了找到这些名字服务器的地址，会向受害的权威服务器发出成倍的查询。修复方式是限制解析器为单个转介解析的 NS 名字数量。它是“正常协议行为被成倍放大”的典型例子。
KeyTrap#
2024 年 2 月公开的 KeyTrap（CVE-2023-50387）针对 DNSSEC 验证器：一个精心构造的区可以包含大量密钥标签相同的 DNSKEY 和大量签名，规范要求验证器逐个尝试匹配，于是一次查询就能让验证器做海量的签名校验，长时间占满 CPU。同期还有一个利用 NSEC3 散列计算的变种（CVE-2023-50868）。各主流解析器随后加入了对单次验证工作量的上限。
绕过协议的劫持#
- 注册商或托管账户被盗：攻击者直接修改 NS 或记录，所有技术防护都失效。开启注册商锁、双因素认证，并监控 NS 和 DS 的变化。
- BGP 劫持：2018 年 4 月，攻击者通过 BGP 劫持了 Amazon Route 53 的一段地址，把 myetherwallet.com 的解析导向自己的服务器。路由安全（RPKI）和 DNSSEC 都能削弱这类攻击。
- 途中篡改：中间设备拦截 UDP/53 并伪造应答。加密 DNS 能让篡改无法实施，DNSSEC 能让篡改被发现。
悬空记录与子域接管#
某个子域的 CNAME 指向一项已经停用的云服务（存储桶、应用托管、CDN 配置），而那个名字可以被任何人重新注册。攻击者注册之后，就能在你的子域上提供任意内容，甚至申请到证书。定期清点所有指向外部服务的记录，服务下线时先删 DNS 记录，再释放资源。