这是一个典型问题关于 ISC BIND 名称服务器软件中的速率限制。
最近我听说了 BIND 的速率限制功能。DNS RRL 似乎变得越来越普遍。
我有点困惑。有些文档似乎说这些功能不应与递归 DNS 服务器一起使用，但其他文档却非常具体地介绍了递归 DNS 基础架构。谁是对的？
答案1
虽然我真心希望 ISC 能够更好地记录这些功能，以便经验水平低于“专家”的用户使用，但这只是一厢情愿。截至 9.11，BIND 中有两种不同的速率限制实现，它们旨在解决两个完全不同的问题。
DNS 路由列表
第一种速率限制形式是DNS 响应速率限制，通常称为 DNS RRL。您可以阅读有关规范的更多信息这里。它由多个权威名称服务器守护进程实现，并且不特定于 ISC BIND。
DNS RRL 旨在保护权威 DNS 服务器，但 BIND 不会阻止您在递归服务器上激活此功能。许多用户偶然发现了 BIND 文档中的相关选项，并认为这些选项适用于递归 DNS 服务器。事实并非如此。请勿在递归服务器上启用此功能。
如果你正在运行提供权威数据的服务器和递归，无论如何你都不应该这么做。通过运行该配置，你已经接受了随之而来的额外问题。我们无法帮助你。
取值限制
BIND 的 fetchlimit 代码的 ISC 知识库文章标题为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 服务器上使用面向互联网的接口，在未知网络的流量到达递归服务器之前将其丢弃，等等。）速率限制是你应用的一项增值功能此外您的其他减少滥用的策略。它不能替代它们。