BINDで32rpzゾーン制限を超える別の方法はありますか？ ... BINDを1000回実行せずに
BIND RPZを使用すると、クエリを変更するために探しているものが正確に得られます。ただし、私の再帰DNSサーバーは何百ものクライアントで使用されており、各クライアントにある程度のカスタマイズを許可する方法を探しています。クライアントが数千の異なる可能な組み合わせを作成できるようにしたい場合は、おそらく数百のゾーンがあります。
私は32のRPZゾーン（一見無限の長さ）に制限されているようですが、それだけでは機能しません。各ユーザーは特定のゾーンにオプトインする機能が必要です。クライアントごとに大規模なゾーンがある場合でも、32の制限に達します。
ローカルデータの透過性を備えた同様の種類のRPZセットアップがあるように見えるUnboundを簡単に見てきましたが、特定のクライアントにのみ提供できるようにビューに分割する方法を探すと、楽しみは終わったようです。
確かに、車輪の再発明なしでこれを達成する方法はありますか？たとえば、何千もの顧客がさまざまなリストを切り替えることができるOpenDNSのように、同様のセットアップを提供している商用プロバイダーを目にします。秘伝のタレは？
まず、制限が存在する理由を理解するのに役立ちます。
RPZメカニズムはBIND9.10で変更されていません。 KB記事AA-00525（応答ポリシーゾーン（RPZ）を使用したDNSファイアウォールの構築）のドキュメントはまだほぼ最新です。BIND9.10で変更されたのは、1つのインスタンスで最大32個の個別のRPZファイルを使用できるようになったことです。 BIND、およびそのBINDは、RPZのこのような頻繁な使用によって大幅に遅くなることはありません。これらの32のポリシーゾーンファイルのそれぞれは、必要な数の異なるドメインのポリシーを指定できます。32の制限は、個別に指定されたポリシーコレクションの数とポリシーを指定するゾーンの数ではありません。
RPZが実装された以前のバージョンのBINDでは、複数のRPZゾーンファイルがあると、BINDは各ポリシーゾーンで個別のルックアップを実行して、一致するかどうかを確認する必要がありました。 BIND 9.10では、ポリシー情報は基数木に格納されます。基数木では、最大のコレクション（RPZゾーン）内のポリシーステートメントの数の対数にほぼ比例するサブリニア時間で、すべてのポリシーゾーンにわたる同時ルックアップを実行できます。 ）。
BIND 9.10のRPZの改善された実装は、VernonSchryverとPaulVixieによって提供されました。ポリシーのサイズがO（log n）であり、複数のデータ項目を並行して検索できるため、高速です。 32の新しい制限は、クエリに影響を与えるポリシーゾーンを識別するために32ビットビットフィールドを使用した結果です。 RPZの以前の実装は、O（log n）ではなくO(n)）でした。
関連する言い回しを強調しました。 32の制限を変更する唯一の方法は、より大きなビットフィールドを使用するようにアルゴリズムを更新するか、最適化コードを完全に消化することです。ビットフィールドのサイズを2倍の64に（または2倍に128になど）したとしても、基数木の最適化によって課せられる静的な制限に対処していることになります。私はこのアルゴリズムの内部に精通していないので、そのような試みが最初からどれほど効果的であるかについても言えません。
個々の顧客に一致するビューを使用することでこれを回避できます。これにより、顧客ごとに32のRPZゾーンが提供されますが、ソースコードに飛び込むことなく取得できる範囲です。