在BIND中超过32 rpz区域限制的替代方法？...without运行BIND一千次

Question

使用BIND RPZ可以让我准确地看到我想要改变查询的内容。然而，我的递归DNS服务器正在被数百个客户端使用，我正在寻找一种方法来允许每个客户端进行某种程度的定制。可能有几百个区域是客户端可能希望为数千种不同的可能组合而创建的。

看起来，我被限制在32个RPZ区域(看似无限长)，但这本身是行不通的--每个用户都需要选择进入特定区域的能力。即使每个客户都有大量的区域，它仍将达到32的极限。

我简要地看过Unbound，它似乎具有类似的RPZ设置，具有本地数据的透明度，但当我寻找一种将事物分成视图的方法时，它的乐趣似乎已经结束了，所以我只能为特定的客户提供服务。

当然，有一种方法可以做到这一点，而不需要重新发明车轮？我看到商业提供商提供类似的设置，比如OpenDNS，成千上万的客户可以在其中切换各种列表。秘方是什么？

Answer 1

首先，它有助于理解限制存在的原因。

https://kb.isc.org/docs/aa-01121 RPZ机制在BIND 9.10中没有改变。KB文章AA-00525 (构建带有响应策略区域(RPZ)的DNS防火墙(RPZ)中的文档几乎仍然是最新的。BIND 9.10中发生的变化是，现在可以在BIND的单个实例中使用多达32个单独的RPZ文件，这种绑定不会因RPZ的大量使用而明显减缓。这32个策略区域文件中的每一个都可以根据需要为多个不同的域指定策略。32的限制是独立指定的策略集合的数量，而不是它们指定策略的区域的数量。在实现RPZ的早期版本的BIND中，需要有多个RPZ区域文件才能在每个策略区域中执行单独的查找，以查看是否匹配。在BIND 9.10中，策略信息存储在一个基树中，在该树中，可以在次线性时间内执行跨所有策略区域的同时查找，该时间与最大集合(RPZ区域)中策略语句数的对数近似成正比。Vernon Schryver和Paul Vixie为BIND 9.10提供了RPZ的改进实现。它更快，因为它在策略的大小上是O(log )，而且它可以并行地查找多个数据项。32的新限制是使用32位字段标识影响查询的策略区域的结果。以前RPZ的实现是O(n)而不是O(log )。

我强调了相关的词句。改变32的限制的唯一方法是更新算法以使用更大的位域，或者完全消除优化代码。即使要将位字段的大小翻倍到64 (或者再加倍到128，等等)，您仍然在处理基树优化所施加的静态限制。因为我不熟悉这个算法的内部，所以我也不能说这种尝试会有多有效。

您可以通过使用与单个客户匹配的视图来解决这一问题，这将为每个客户提供32个RPZ区域，但这就是您不需要深入研究源代码就能得到的结果。