DNS 欺骗与缓存投毒：实用概览

DNS 在设计之初，没有任何办法验证一个响应是否真的来自它所声称的域名服务器。这个缺口使欺骗成为可能：处于能够拦截 DNS 查询或抢先应答位置的攻击者，可以发回一个伪造的响应，把受害者指向由攻击者选定的地址，常被用来把流量重定向到冒充合法网站的恶意服务器。

缓存投毒：同样的思路，规模更大

缓存投毒沿用同样的伪造响应思路，但攻击目标是共享的解析器，而不是单个受害者。如果攻击者能把伪造的应答塞进某个被广泛使用的递归解析器的缓存，那么该解析器此后的每一位用户，在应答过期之前得到的都是被污染的应答。这样一次成功的伪造，就变成了针对所有共用该解析器的人的攻击，而无需逐个拦截他们各自的查询。

现代 DNS 如何防御

这些防御措施都没有被普遍部署，尤其是 DNSSEC，在构成互联网的各个域名中仍然只有部分采用。即便没有启用 DNSSEC，使用运营良好、注重安全的公共解析器，并在遇到意料之外或可疑的解析结果时，用第二个独立的解析器再核对一次，仍然是合理的实用预防措施。

改变人们重视程度的那个漏洞

缓存投毒在 2008 年不再只是理论上的担忧。那一年，安全研究员 Dan Kaminsky 披露了一个影响当时几乎所有 DNS 解析器的根本性缺陷：攻击者需要猜测的事务 ID 与源端口的取值空间太小，在高速连接下几秒钟就能暴力破解，使攻击者能够为整个域名而不只是某一条记录投毒解析器的缓存。这次披露促成了一次异常协调的同步补丁发布，涵盖所有主要的 DNS 软件厂商，源端口随机化几乎在一夜之间成为标准，上表所列的各项防御措施之所以呈现现在的形态，这也是很大的原因。

为什么修复已过去二十年，DNSSEC 的普及仍然滞后

DNSSEC 解决底层信任问题的方式远比单靠端口随机化彻底，它提供的是密码学证明，而不只是一场更难猜的猜谜游戏。它推广缓慢，更多是因为运维复杂，而非对其价值存疑：正确地为区域签名、按计划轮换密钥而不破坏验证，并让从根到具体域名的整条信任链保持完整，要做对比添加一条未签名的 A 记录难得多。这一过程中只要出现一处失误，就会触发本系列文章其他篇目所讲的那种 SERVFAIL 故障，这本身就让没有专职 DNS 人员的小型域名运营者望而却步。“理论上已解决”与“实际上处处部署”之间的差距，在安全基础设施中十分常见，DNSSEC 就是一个典型的例子。