一部のドメインをブラックリストに追加するためにRPZを使用しています。構成は次のとおりです。
*.com A 127.0.0.1
mydomain.net A 127.0.0.1
ドメイン名.comを照会すると正常に機能し、127.0.0.1が表示されます。
dig fun.com @localhost私の答えは次のとおりです。
;; ANSWER SECTION:
fun.com. 5 IN A 127.0.0.1
それでは、以前の設定を編集し、私の領域を次のようにしてみましょう。
*.com A 127.0.0.1
mydomain.net A 127.0.0.1
this.fun.com 127.0.0.1
プライマリサーバーはすべての場合を処理する必要があるため、これは不要です*.comが、私のドメインは複数のソースによってロードされるため、リストが自動的にコンパイルされ、このようなことが発生する可能性があります。
これは無害な変更のように見えますが、これを行うと、dig this.fun.com @localhost次のように応答します。
;; ANSWER SECTION:
this.fun.com. 5 IN A 127.0.0.1
今ルートドメインを照会すると、次のようなdig fun.com @localhost結果が得られます。
;; ANSWER SECTION:
fun.com. 86400 IN A 209.61.131.188
何のように？ここで何が起こっているのでしょうか？親パッケージ全体でthis.fun.com保護されたプライマリドメインを追加しますか？fun.com*.com
これがバインディングの望ましい動作ですか？奇妙なバグを見つけましたか？
この状況を避ける方法は？より大きなドメインに含まれるドメインを削除しながら、すべてのドメインにわたって繰り返されるスクリプトを作成する必要がありますか？ （面倒ですが可能です - より良い選択肢を探しています）
重要な要約：2番目のレベルのドメインがデフォルトのフィルタによるホワイトリストに従わないように、バインディングrpzに3番目のレベルのドメインを追加してブラックリストに追加します。
ベストアンサー1
BIND RPZの動作と正規表現：*.com以下のすべてのDNSサブドメインをブラックリストに追加しますcom。しかし、ルートドメイン自体をブラックリストに追加するには、comrpzファイルに次のものを追加する必要があります。
com
したがって、rpzリストにcomを追加しないと解決されます。あなたが説明するのは正常な行動です。
RPZブラックリストパーサーは、少なくともリソースを節約するために1つ作成することをお勧めします。 BINDはハッシュテーブルを使用するため、ランタイムへの影響は最小限に抑える必要がありますが、BINDを再起動するとき（たとえば、BINDがRPZテーブルを読み取って解析するとき）、RPZテーブルの読み込み遅延が目立って少し多くのメモリを消費します。私はまだそのようなパーサーを書いていません現在。