ISC BIND 提供了哪些速率限制选项？

Question

这是一个关于 ISC BIND 名称服务器软件中速率限制的规范问题。

最近我听说了 BIND 的速率限制功能。尤其是 DNS RRL 似乎变得越来越普遍。

我有点困惑。一些文档似乎说这些功能不应该与递归 DNS 服务器一起使用，但其他文档非常明确地解决了递归 DNS 基础设施。谁是对的？

Answer 1

虽然我非常希望 ISC 能够更好地记录这些功能，以帮助经验水平低于“专家”的用户，但这是一厢情愿的想法。从 9.11 开始，BIND 中有两个单独的速率限制实现，它们旨在解决两个完全不同的问题。

DNS RRL

第一种速率限制形式是DNS 响应速率限制，通常称为 DNS RRL。您可以在此处阅读有关规范的更多信息。它由多个权威名称服务器守护进程实现，并不特定于 ISC BIND。

DNS RRL 旨在保护权威 DNS 服务器，但 BIND 不会阻止您在递归服务器上激活此功能。许多用户偶然发现了 BIND 文档中的相关选项，并假设这些选项旨在与递归 DNS 服务器一起使用。不是这种情况。不要在递归服务器上启用它。

如果您正在运行提供权威数据和递归的服务器，则无论如何都不应该这样做。通过运行该配置，您已经接受了随之而来的其他问题。我们帮不了你。

取值限制

BIND 的 fetchlimit 代码的 ISC 知识库文章的标题是Recursive Client Rate Limiting in BIND 9.9.8 和 9.10.3，这让事情变得混乱。这与 DNS RRL 无关。

与 DNS RRL 不同，fetchlimit 代码旨在解决导致递归服务器参与对权威服务器的攻击的 DNS 攻击策略。具体而言，这些选项旨在减少您的递归服务器对单个权威 DNS 服务器 IP 和/或单个 DNS 域进行的同时查询的数量。这使得您的服务器在用于伪随机子域攻击（针对其他人）中的吸引力降低，并且还有助于限制在此类攻击中使用您自己的 DNS 服务器时对它们的影响。（短暂的端口耗尽等）

免责声明

虽然提供此问答是为了帮助澄清 ISC BIND 提供的速率限制代码中经常混淆的差异，但这些都不是滥用递归 DNS 服务器的综合解决方案。只有后者旨在与递归 DNS 服务器一起使用，即使如此，它也旨在解决经常困扰高容量递归 DNS 环境的运营商的特定形式的攻击。

如果您的递归 DNS 环境被用于攻击他人，除非您已经实施了所有其他最佳实践，否则BIND 的速率限制功能就是一个红鲱鱼。（不要运行开放式解析器，一般避免递归 DNS 服务器上面向 Internet 的接口，在到达递归服务器之前丢弃来自未知网络的流量等。）速率限制是一种附加值，除了您的其他滥用之外，您还可以应用减少策略。它不是它们的替代品。