保护我的绑定DNS服务器缓慢kaminsky风格caching中毒攻击

Dan Kaminsky描述了DNS服务器如何被欺骗性的DNS响应中毒[1]。据我所知，问题是Kaminskyfind了一种解决DNS查询中大多数其他随机来源的方法，这样攻击者的主要障碍是在生成欺骗时猜测DNS查询ID（熵的16位）响应。平均而言，攻击者可以在32K猜测内欺骗回应。所以，推荐的缓解措施是随机化源端口，每个人都应用他们的补丁，一切都很好。

除了这个数字只是从32k到134m到4b之间。当然，这不可能很快完成，但病人攻击者仍然可以这么做 – 事实上，伯特·休伯特（Bert Hubert）计算出在100周内发起攻击在6周内有50％的成功几率。 [2]

我没有足够的声誉发布更多的链接。但是，我发现在tools.ietf.org，RFC5452以及Google上已经考虑了许多技术方法，例如draft-wijngaards-dnsext-resolver-side-mitigation-01和draft-vixie-dnsext-dns0x20-00公共DNS安全文档：

DNS标签位0x20（即cAsE.gAmEs）
- 绑定做这个？我不能相信绑定不会实现Vixie提出的东西
- 但是，攻击可能会迫使查询不能显着消失的域名。例如。 “d293823。”
RTT绑定，IPv4 / IPv6select，源地址随机化（来自wijngaards）
- 我不认为这会增加显着的熵，但如果绑定可以，我会这样做。
（来自wijngaards）推荐的NS / nameserver / A / AAAA的权限查询
- 这似乎是一个优雅的解决scheme。不明白它的问题。这可能不是大规模部署的首选解决scheme，但对我的网站似乎是合理的。可以绑定吗？
攻击模式故障计数器
- 可以绑定吗？
- 但是，如果我在DNS服务器前有一个有状态的防火墙，那么DNS服务器的问题计数器将永远不会看到有错误的目标端口到达的欺骗性响应？
回退到TCP（特别是进入攻击模式后）
询问两次/三次（特别是进入攻击模式后）
删除重复的查询（来自Google公共DNS）

不幸的是，即使在最新版本的Bind中，我也没有看到任何configuration选项。

所以我想问问还有什么可以做的，以防止这种欺骗攻击风格，特别是当我运行绑定。如果缓解措施仍然是一个概率性的事情，那么我希望把这个可能性与一百万年来成功的攻击结合起来。

[1] http://s3.amazonaws.com/dmk/DMK_BO2K8.ppt

[2] http://ds9a.nl/har-presentation-bert-hubert-3.pdf slide 24。

大多数TTL不到30天，对吧？每个月清理caching。

没有办法阻止某人侵入你的服务器。
安全方面，99.9％的人放弃了足够的障碍。

您也可以尝试在您的DNS之前放置一个IPS，例如Snort，并创build规则，以便在X时间内有人使X过量的DNS查询时提醒您。

只要你知道，我已经运行了数百个区域的DNS服务器集群。这些服务器不仅是权威的，而且是recursion的。他们已经被用于DNS放大攻击，但并不是一次就存在caching中毒的问题。他们已经跑了15年了。
其中之一是域控制器。是的，这是荒谬的。我没有devise它。

虽然我认识到DNSSEC并不是普遍存在的，但签名区域应该增加另一层复杂性，如第30-31页的Bert所述，与更高版本的Bind相比，这很容易实现（尽pipe您的日志可能会有点冗长与不支持DNSSEC的服务器通话）。