DNS注入能成功，入原根本原因在于DNS查询默认走UDP、理详无连接、入原无加密。理详攻击者只要能在用户和递归解析器之间插入一个伪造的入原响应包，而且比真实服务器的理详应答先到，解析器就会采信这个假答案。入原这不是理详理论漏洞，是入原协议设计时对效率的妥协留下的口子。

2008年Dan Kaminsky公开的理详那个DNS缓存投毒漏洞，核心手法就是入原抢跑。他让递归解析器去查询一个不存在的理详主机名，然后在真实应答回来之前，入原伪造大量响应包灌进去。理详每个包里的入原Transaction ID有16位，端口号当时也基本固定，暴力猜中的概率并不低。一旦猜中，攻击者就能把整个域的NS记录指向自己的服务器。后来RFC 5452要求随机化源端口，把熵从16位提到32位左右，抢跑难度才大幅上升。但注意，这只是提高了门槛，没有堵死。

中间人场景下，连猜都不用猜

如果攻击者已经坐在链路中间——比如公共WiFi、被劫持的路由器、ARP欺骗后的局域网——那Transaction ID和源端口都能直接看到。这时候伪造响应就是明牌打。我见过一个实验环境里的演示：一台笔记本连上伪造的AP，访问任意域名，返回的IP全指向一个本地Web服务器。用户浏览器地址栏显示的是正常域名，页面内容却被替换了。整个过程不需要任何漏洞利用，纯粹是DNS明文传输的必然结果。

DNS over HTTPS和DNS over TLS正在改变这个局面。DoH把查询塞进HTTPS隧道，中间人看不到内容，也改不了。但DoH本身也有争议——它把DNS流量集中到了少数几家解析服务商手里，企业内网的域名策略可能被绕过。这是另一个话题了。

防御不能只靠一层

DNSSEC解决的是完整性和来源认证问题。它用数字签名保证响应确实来自域名的合法管理者，且内容未被篡改。但DNSSEC的部署率一直上不去，原因很实际：签名轮换麻烦、老旧设备不支持、运营商觉得没动力。很多顶级域虽然签了，下面大量二级域名根本没启用。所以现实中，DNSSEC更像一道可选加固，不是默认防线。

真正有效的做法是分层。递归解析器强制源端口随机化，加上0x20编码（在查询名里随机改变大小写，增加攻击者猜测难度），再配合响应速率限制。终端侧尽量用DoH或DoT，至少保证最后一公里不被窥探。企业内网如果条件允许，把内部域名和公共域名分离解析，减少缓存投毒的影响面。

我个人的判断是：DNS注入不会消失，因为协议本身的信任模型就是“先到先得”。只要还有明文UDP查询在跑，中间人就有操作空间。加密和签名是方向，但迁移速度取决于运维成本和兼容性博弈。对普通用户来说，换一个支持DoH的解析器，比如Cloudflare的1.1.1.1或Google的8.8.8.8，已经能挡掉大部分链路层攻击。剩下的，靠协议演进慢慢补。