2019年，全解FireEye披露了一起针对中东地区政府的全解DNS劫持事件。攻击者入侵了目标网络的全解DNS注册商账户，把原本指向政府邮件服务器的全解A记录改成了一个仿冒IP。整个过程不到十分钟，全解邮件流量就被无声无息地导走了。全解没有恶意软件，全解没有钓鱼附件，全解仅仅是全解改了几条DNS记录。这件事让我意识到，全解DNS安全长期被低估了——大多数人把它当成一个"配好就不用管"的全解基础设施，而攻击者早就把它当成了首选入口。全解

DNS的全解设计年代决定了它的安全短板。1983年Paul Mockapetris设计DNS时，全解互联网还只是全解几百台机器的实验网络，信任是默认前提。查询和响应走UDP、明文传输、无身份验证——任何能截获流量的人都可以伪造响应。DNS缓存投毒就是利用这一点：攻击者抢在真实服务器之前，向递归解析器注入伪造记录。2008年Dan Kaminsky发现的漏洞更狠，攻击者只需在递归查询过程中猜中事务ID和源端口，就能让解析器缓存一条假记录。当时几乎所有主流DNS软件都受影响，厂商被迫在几周内紧急打补丁。Kaminsky那招的精妙之处在于，他找到了一种让攻击成功率从几亿分之一飙升到几乎必中的方法，具体细节至今看起来仍然漂亮。

加密能解决一部分问题。DNS over HTTPS（DoH）和DNS over TLS（DoT）把查询内容塞进加密隧道，中间人看不到你在查什么，也改不了响应。Firefox和Chrome已经默认启用DoH，Cloudflare的1.1.1.1和Google的8.8.8.8都支持。但加密只保护传输链路，不解决上游的问题。如果权威DNS服务器本身被攻破，或者域名注册商账户被盗，加密毫无意义。前面提到的FireEye案例就是这种情况——攻击发生在注册商层面，跟传输加密没有半点关系。

DNSSEC是另一条路线。它用数字签名给DNS响应做认证，解析器可以验证返回的记录确实来自域名的合法管理者，且未被篡改。理论上很完美，实际部署率却一直上不去。根区和顶级域基本都签了，但大量二级域名没有启用。原因不复杂：配置复杂、密钥轮换麻烦、一旦签名过期整个域名直接解析失败。我见过运维因为DNSSEC配置失误导致全站不可用的案例，修复窗口以小时计。这种"配错了比不配还惨"的特性，让很多团队选择观望。

真正让我觉得有意思的是DNS作为攻击通道的隐蔽性。传统防火墙和IDS对DNS流量的审查通常很宽松——毕竟哪个网络没有DNS查询？攻击者把C2指令编码进DNS查询的子域名里，数据藏在TXT记录中，流量看起来完全正常。2017年的DNSMessenger恶意软件就是这么干的，通过DNS TXT记录接收指令，在受害者网络中潜伏了数月才被发现。检测这类攻击需要深度包检测和DNS行为基线分析，大部分中小型网络根本不具备这个能力。

防御层面，几件事值得做。递归解析器别用运营商默认的，换成支持DoH/DoT的公共解析服务，至少能防住本地链路上的窃听和篡改。域名注册商账户开双因素认证，别用同一个密码——注册商被攻破意味着攻击者可以直接改你的NS记录，后面所有防护都白搭。监控DNS查询日志，尤其是那些高频、长随机子域名的查询，这往往是DNS隧道的外在特征。DNSSEC如果团队有能力维护密钥生命周期，该上就上；没这个精力，至少把CAA记录配好，限制哪些CA可以给你的域名签发证书。

DNS安全没有一劳永逸的方案。它是一个持续对抗的领域，攻击面从协议设计缺陷延伸到注册商账户管理，再到终端解析器配置。每一层都有对应的攻击手法和缓解措施，漏掉任何一环，整条链路的安全性就打折扣。Kaminsky漏洞过去十五年了，DNS的核心协议没怎么变，变的是攻击者的耐心和创造力。