当你在浏览器里输入一个域名并按下回车，浏览器做的第一件事不是直接连接网站，而是向 DNS 服务器发起一次查询：“这个域名对应的 IP 地址是什么?”整个过程通常在几十毫秒内完成，你几乎感觉不到它的存在。

　　但如果这条查询的路径上存在一个“抢答者”，事情就变了。它可以在真正的 DNS 服务器返回正确答案之前，抢先塞给你一个错误的 IP。你对此毫无察觉，浏览器乖乖连上了那个错误地址。这就是 DNS污染最朴素的形态。

　　UDP：快，但不设防

　　DNS 查询默认走的是 UDP 协议，目标端口 53。

　　选择 UDP 是有道理的。DNS 查询的数据包很小，一个域名查询请求通常只有几十个字节，响应也不过一百多字节。用 UDP 可以省去 TCP 三次握手的开销，一次请求-响应就能完成，速度最快。

　　但 UDP 有一个致命的特性：它不验证身份。

　　TCP 连接需要握手，双方会交换序列号，你大概知道“对面是谁”。UDP 没有这个过程。你把一个查询包发出去，然后等着。任何格式正确的响应包到达你的 53 端口，只要它携带了匹配的查询 ID，DNS 解析器就会接受它——不管它来自真正的 DNS 服务器，还是来自网络上某个伪造了源 IP 的攻击者。

　　用一个不太精确但直观的比喻：你往人群里扔了一张纸条，上面写着“XX 域名的 IP 是多少?编号 12345。”然后你喊了一声：“谁回答我?”第一个举手并报出编号 12345 的人，你就信了。 你不在乎这个人是不是你原本想问的那位。

　　这就是 DNS污染能够成立的根本前提。

　　查询 ID ：从 16 位到 32 位

　　DNS 协议当然不是完全没有防伪设计。每个 DNS 查询报文里有一个 16 位的 Transaction ID(事务 ID)，响应报文必须携带相同的 ID，解析器才会认为这是“对得上”的回复。

　　16 位意味着 65,536 种可能。如果攻击者完全不知道这个 ID 是多少，纯靠猜，他每一包猜中的概率是 1/65,536。

　　这个概率听起来很低。但攻击者不需要只发一包。

　　他可以持续监听网络，一旦发现某个 DNS 查询发出(比如用户访问 example.com)，立刻向解析器的 53 端口批量发送伪造响应包。每个包携带不同的 Transaction ID 猜测值。如果他能在真正的 DNS 服务器返回结果之前，发出去足够多的伪造包，按照生日悖论，命中正确 ID 的概率会随发送数量的增加而快速上升。

　　更糟的是，早期很多 DNS 实现的 Transaction ID 是可预测的——它们使用递增序列或者弱随机数生成器。攻击者只要观察几次正常的查询-响应，就能推算出下一个查询的 ID 大概是多少，命中概率从 1/65,536 跃升到接近 100%。

　　2008 年，Dan Kaminsky 披露的那个著名漏洞，核心就是这个问题。当时几乎所有主流 DNS 实现的事务 ID 随机性都不足，攻击者可以在几秒钟内完成一次缓存投毒。

　　防御与反防御：端口随机化的博弈

　　Kaminsky 漏洞之后，DNS 社区做了一次大规模修补。核心措施有两项：

　　第一，提高 Transaction ID 的随机性。 使用密码学安全的随机数生成器，让 ID 无法被预测。

　　第二，引入源端口随机化。 以前很多 DNS 服务器从固定的源端口(通常是 53)发出查询，攻击者只需要伪造响应包发往目标服务器的 53 端口就行。现在，服务器每次查询从 64,000 多个可用端口里随机选一个作为源端口。

　　这两项措施叠加，攻击者需要猜测的组合从 16 位变成了 32 位：16 位 Transaction ID + 16 位源端口。可能性从 65,536 暴增到约 43 亿。

　　理论上，攻击者需要发送海量的伪造包，才能有一次命中。在真实的网络条件下，这个攻击成本已经高到不具备可操作性。这也是为什么在 Kaminsky 漏洞修复之后的十几年里，传统意义上的 DNS 生日攻击几乎销声匿迹。

　　但“几乎”不等于“彻底”。

　　REBIRTHDAY：生日攻击的“复活”

　　2026 年，一个名为 REBIRTHDAY 的攻击技术被公开披露，让沉寂多年的 DNS 缓存投毒重新回到了安全圈的视野。

　　REBIRTHDAY 没有去硬碰 32 位随机化这道墙，而是找到了一个协议层面的侧门。

　　这个侧门叫做 EDNS Client Subnet(ECS)。

　　ECS 是一个 DNS 扩展，原本是为了让 CDN 更智能地调度。它的工作方式是：递归 DNS 服务器在向上游查询时，把用户所在的子网信息(比如用户 IP 的前 24 位)一起带上。CDN 的权威 DNS 看到这个子网信息，就能返回离用户最近的边缘节点 IP。

　　问题出在查询聚合上。

　　正常情况下，如果短时间内有多个用户查询同一个域名，递归 DNS 服务器会把它们聚合成一次上游查询，拿回结果后分发给所有等待的用户。聚合意味着只有一个上游查询在等待响应，攻击者需要猜测的那个 32 位随机值只有一套。

　　但 ECS 打破了聚合。 如果两个用户的子网不同，递归服务器会认为“他们需要的结果可能不一样”，于是拆分成两个独立的上游查询。每个查询有自己独立的 Transaction ID 和源端口。

　　REBIRTHDAY 的攻击逻辑就是：人为制造大量差异化的 ECS 查询，迫使递归服务器同时发起几十个甚至上百个并发的上游查询。

　　每个并发查询都对应一套独立的 32 位随机值。攻击者不需要精确猜中某一个，他只需要向这几十个查询的“随机值空间”里批量注入伪造响应。只要其中任何一个恰好命中了某个正在等待的查询，投毒就成功了。

　　生日悖论在这里被反向利用：并发的查询数量越多，攻击者“蒙中一个”的概率就越高。 防护机制中“每个查询独立随机”的设计，在 ECS 造成的“查询碎片化”场景下，反而成了攻击者的杠杆。

　　BIND、Unbound、PowerDNS、思科和 TP-Link 等设备的内置 DNS 解析组件，都在受影响范围内。

　　污染之后：你感受到的“故障”从何而来

　　投毒成功意味着什么?

　　攻击者把一条错误的记录写入了递归 DNS 服务器的缓存。这条记录的 TTL(生存时间)决定了它会在缓存里停留多久。在 TTL 过期之前，所有向这台递归服务器查询该域名的用户，都会拿到那个错误的 IP。

　　错误的 IP 通常指向几类地址：一个是根本不存在的“黑洞”地址，连接直接超时;一个是 127.0.0.1 或类似的本地回环地址，让请求“原地打转”;或者是一个攻击者控制的服务器，上面可能挂着钓鱼页面、恶意脚本。

　　联通曾发生过一次大规模的 DNS 故障，攻击者把大量域名的解析结果指向了 127.0.0.2——一个本地环回地址的变体。用户访问任何被污染的域名，数据包都“消失”在本机，页面完全打不开。更麻烦的是，即使攻击停止、根服务器修复，各地递归服务器的缓存刷新周期不同(从几分钟到几十小时不等)，导致故障在部分省份持续了超过一天。

　　为什么加密 DNS 能防

　　理解了 DNS污染的机制，加密 DNS(DoT 和 DoH)的作用就很好理解了。

　　污染的成立有两个前提：响应可以被伪造，以及解析器会接受“先到者”。UDP 明文传输让伪造变得容易，无身份校验让接受变得自然。

　　DoT和 DoH做的事情是把 DNS 查询和响应封装进 TLS 加密隧道。数据包被加密后，中间设备看不到里面的内容，不知道你在查询什么域名，也不知道 Transaction ID 是多少，自然无法伪造一个“匹配的”响应。

　　但这并不意味着 DoH/DoT 能解决所有问题。加密保护的是传输过程，不能改变解析结果。如果你连接的 DoH 服务器本身返回的就是被污染的结果，加密隧道保护的就是一个错误的答案。海外 DoH 服务在国内的可用性也参差不齐，延迟和连接稳定性都是现实问题。

　　DNS污染的本质，是互联网基础协议在“信任”问题上的历史欠账。UDP 的设计哲学是“快速、简单、假设网络是善意的”，而生日攻击利用的正是这种信任假设。REBIRTHDAY 的出现说明，即使打了补丁，只要协议还在演进、还在引入新功能，新的攻击面就会不断出现。

　　常见问答

　　问：DNS污染和 DNS 劫持是一回事吗?

　　经常混用，但严格来说有区别。“劫持”范围更广，可以是运营商或路由器直接篡改你的 DNS 设置，把你的查询导向他们指定的服务器;“污染”特指在 DNS 查询-响应过程中，通过伪造响应包抢先注入错误结果。污染是劫持的一种技术手段，但劫持不一定是通过污染实现的。

　　问：为什么改了 DNS 服务器地址还是被污染?

　　因为你连接的递归 DNS 服务器本身被污染了。你换了服务器地址，只是换了一个“被投毒的对象”。如果新的 DNS 服务器缓存里已经被写入了错误记录，你通过它查询同样会拿到错误结果。换 DNS 只在旧服务器被污染、新服务器恰好没被污染时有效，不是根本解决方案。

　　问：DNS污染的 IP 是固定的吗?

　　不固定，取决于攻击者的策略。有些污染会返回固定的“黑洞 IP”(比如 127.0.0.2、0.0.0.0 或某个特定的保留地址)，这种情况下可以通过 hosts 或过滤规则绕过。有些污染会返回随机的 IP，或者每次查询返回不同的地址，这种情况更难通过简单规则规避。

　　问：TCP 模式的 DNS 查询能绕过污染吗?

　　部分场景下可以，但不稳定。传统污染主要针对 UDP 53 端口，因为伪造 UDP 响应不需要建立连接。走 TCP 53 端口查询时，攻击者需要先完成 TCP 握手，难度高得多。但网络中间设备可以对 TCP 53 的查询进行干扰或阻断，所以 TCP DNS 并不是一个可靠的绕过手段。

　　问：普通用户需要担心 DNS污染吗?

　　日常上网中，主流网站、银行、支付平台的 DNS 通常有较强的保护，被大规模污染的概率很低。你更可能遇到的“污染”其实是运营商为了插入广告而做的 DNS 重定向，或者公共 Wi-Fi 的 DNS 篡改。真正需要警惕 DNS污染的场景，是访问那些本身就被“特殊关照”的境外服务。