Dan Kaminsky 描述了 DNS 服务器如何被伪造的 DNS 响应毒害 [1]。据我了解，问题在于 Kaminsky 找到了一种方法来解释 DNS 查询中的大多数其他随机源，这样攻击者的主要障碍就是在生成伪造响应时猜测 DNS 查询 ID（16 位熵）。攻击者平均可以在 32k 次猜测内伪造响应。因此，建议的缓解措施是随机化源端口，每个人都应用了他们的补丁，一切就都好了。
只不过，这只会将猜测次数从 32k 提高到 134m 到 4b 之间。当然，这不可能很快完成，但有耐心的攻击者仍然可以慢慢做到这一点 - 事实上，Bert Hubert 计算出，100qps 的攻击在 6 周内有 50% 的成功率。[2]
我的声誉不足以发布更多链接。但是，我看到已经考虑了许多技术方法，例如 tools.ietf.org 上的 draft-wijngaards-dnsext-resolver-side-mitigation-01 和 draft-vixie-dnsext-dns0x20-00、RFC5452 以及 Google 公共 DNS 安全文档：
DNS 标签位 0x20（即 cAsE.gAmEs）
- Bind 能做到这一点吗？我不敢相信 Bind 不会实现 Vixie 提出的建议
- 尽管如此，攻击仍可能强制查询那些大小写不能被严重混淆的域名。例如“d293823”。
RTT 分段、IPv4/IPv6 选择、源地址随机化（来自 wijngaards）
- 我不认为这会增加显著的熵，但如果 Bind 可以的话我会这样做。
转介后对 NS/nameserver/A/AAAA 的权限查询（来自 wijngaards）
- 这似乎是一个优雅的解决方案。不明白其中的问题。对于大规模部署，这可能不是首选解决方案，但对我的网站来说似乎合理。Bind 能做到这一点吗？
攻击模式故障计数器
- Bind 能做到这一点吗？
- 但是，如果我在 DNS 服务器前面有一个状态防火墙，DNS 服务器的故障计数器就永远不会看到通过错误目标端口到达的欺骗响应，对吗？
回退到 TCP（尤其是进入攻击模式后）
询问两次/三次（特别是进入攻击模式后）
删除重复查询（来自 Google 公共 DNS）
不幸的是，即使在最新版本的 Bind 中我也没有看到任何可以打开这些功能的配置选项。
所以我想问一下，还有什么可以做来防止这种欺骗攻击，特别是当我运行 Bind 时。如果缓解措施仍然是一个概率问题，我希望这种攻击在一百万年内成功的几率很小。
答案1
大多数 TTL 都少于 30 天，对吗？每月清除缓存。
没有办法阻止有人入侵您的服务器。
安全性只是设置了足够多的障碍，让 99.9% 的人放弃。
您还可以尝试在 DNS 前面放置一个 IPS（例如 Snort），并创建规则，当有人在 X 时间内进行过多的 X 次 DNS 查询时向您发出警报。
你知道吗，我运行了一个包含数百个区域的 DNS 服务器集群。这些服务器不仅具有权威性，而且是递归的。它们曾被用于 DNS 放大攻击，但从未发生过一次缓存中毒问题。它们已经运行了 15 年。
其中一个是域控制器。是的，这太荒谬了。我没有设计它。
答案2
虽然我意识到 DNSSEC 并不是无处不在的，但签名区域应该会增加另一层复杂性，正如 Bert 在第 30-31 页提到的那样，使用 Bind 的更高版本，它非常容易实现（尽管在与未启用 DNSSEC 的服务器通信时，您的日志可能会变得有点冗长）。