使用 BIND RPZ 可以让我完全按照自己的意愿更改查询。但是，我的递归 DNS 服务器正在被数百个客户端使用，我正在寻找一种方法来允许每个客户端进行一定程度的自定义。客户端可能需要启用数百个区域，从而形成数千种不同的可能组合。
看来我被限制为 32 个 RPZ 区域（长度似乎无限），但仅此而已是行不通的——每个用户都需要能够选择加入特定区域。即使每个客户端都有大量区域，它仍然会达到 32 个的限制。
我曾简单了解过 Unbound，它似乎具有类似的 RPZ 设置和本地数据透明度，但当我寻找一种将事物分离到视图中的方法时，乐趣似乎已经结束了，这样我只能将它们提供给特定的客户。
肯定有办法实现这一点，而不用重新发明轮子？我看到商业提供商提供类似的设置，例如 OpenDNS，成千上万的客户可以切换各种列表。秘诀是什么？
答案1
首先，它有助于理解为什么存在这种限制。
https://kb.isc.org/docs/aa-01121
BIND 9.10 中的 RPZ 机制没有改变。知识库文章 AA-00525（使用响应策略区域 (RPZ) 构建 DNS 防火墙）中的文档几乎仍是最新的。BIND 9.10 中的变化是，现在可以在单个 BIND 实例中使用多达 32 个单独的 RPZ 文件，并且 BIND 不会因大量使用 RPZ 而明显变慢。这 32 个策略区域文件中的每一个都可以根据需要为尽可能多的不同域指定策略。32 的限制是针对独立指定的策略集合的数量，而不是它们为其指定策略的区域的数量。
在实施 RPZ 的 BIND 早期版本中，如果存在多个 RPZ 区域文件，则 BIND 需要在每个策略区域中执行单独的查找以查看是否存在匹配项。在 BIND 9.10 中，策略信息存储在基数树中，其中可以在亚线性时间内同时查找所有策略区域，该时间大约与最大集合（RPZ 区域）中策略语句数量的对数成正比。
Vernon Schryver 和 Paul Vixie 为 BIND 9.10 提供了改进的 RPZ 实现。它的速度更快，因为它的策略大小为 O(log n)，并且可以并行查找多个数据项。新的 32 限制是使用 32 位位域来标识影响查询的策略区域的结果。RPZ 的先前实现是 O(n)，而不是 O(log n)。
我强调了相关的措辞。改变 32 的限制的唯一方法是更新算法以使用更大的位域，或者完全删除优化代码。即使你将位域的大小加倍到 64（或再加倍到 128，等等），你仍然要处理基数树优化施加的静态限制。由于我不熟悉这个算法的内部结构，所以我也不能说这样的尝试一开始会有多有效。
您可以使用与您的个人客户相匹配的视图来解决这个问题，这将为您提供每个客户 32 个 RPZ 区域，但这是您如果不深入研究源代码所能获得的最大限度。