使用BIND RPZs给了我正在寻找什么来改变查询。 但是，我的recursionDNS服务器已被数百个客户端使用，我正在寻找一种方法来允许每个客户端进行一定程度的自定义。 可能有几百个区域，客户可能希望使成千上万个不同的可能组合成为可能。
看起来我只限于32个RPZ区域（看似无限长度），但是单靠这一点是行不通的 – 每个用户都需要selectjoin特定区域的能力。 即使每个客户端都有大量的区域，它仍然会达到32个限制。
我简单地看了一下Unbound，看起来有一个与本地数据透明度类似的RPZ设置，但是当寻找将事物分解成视图的方式时，乐趣似乎已经结束了，所以我只能把它们提供给特定的客户端。
当然，有一种方法可以在不重新发明轮子的情况下完成这个任务。 我看到商业提供商提供类似的设置，例如OpenDNS，其中成千上万的客户可以切换各种列表。 秘诀是什么？
首先，它有助于理解为什么存在限制。
BIND 9.10中的RPZ机制没有改变。 知识库文章AA-00525（构build带有响应策略域的DNS防火墙（RPZ））中的文档仍然几乎是最新的.BIND 9.10中的变化是现在可以在单个实例中使用多达32个独立的RPZ文件BIND，而且这种大量使用RPZ的速度并没有显着减慢BIND，这32个策略域文件中的每一个都可以根据需要为不同的域指定策略，其中32个限制是独立指定策略集合的数量，而不是他们指定政策的区域数量。
在实施RPZ的早期BIND版本中，具有多个RPZ区域文件需要BIND在每个策略区域中执行单独的查找以查看是否存在匹配。 在BIND 9.10中，策略信息存储在一个基数树中，在这个树中所有策略域的同时查询可以在亚线性时间执行，与最大集合中的策略语句的数量的对数大致成比例（RPZ区域）。
BIND 9.10的RPZ的改进由Vernon Schryver和Paul Vixie提供。 它的速度更快，因为它的策略大小是O（log n），并且它可以并行查找多个数据项。 由于使用32位位域来标识影响查询的策略区域，所以新的32个限制是结果。 以前RPZ的实现是O（n）而不是O（log n）。
我强调了相关的措辞。 要更改32的限制，唯一的方法是更新algorithm以使用更大的位域，或完全切割优化代码。 即使你将位域的大小加倍到64（或重新加倍到128等等），你仍然在处理由基数树优化施加的静态限制。 由于我不熟悉这个algorithm的内部，所以我也不能说这样的尝试将是多么有效。
您可以通过使用与您的个人客户相匹配的视图来解决这个问题，这将为您提供每个客户32个RPZ区域，但是就像您将不会潜入源代码一样。