BIND - 複数のゾーンで使用されるフォワーダーのリスト

BIND - 複数のゾーンで使用されるフォワーダーのリスト

BIND (v9.16) ネームサーバーを設定しています。

その主な目的は、内部ホストの通常の再帰として機能することです。ただし、いくつかの特定のゾーン (私たちがホストしているゾーン) については、フォワーダーとして設定する必要があります。目標は、ルートおよび TLD DNS サーバーへの依存関係を作成しないようにし、外部ネットワーク接続が利用できない場合でも内部サービスを引き続き使用できるようにすることです。

セットアップは簡単でした。私の設定の関連部分は次のとおりです。

options {
    allow-recursion {
        // Here comes the list of our inside networks
    };

};

zone "somedomain.example" IN {
    type forward;
    forward first;
    forwarders {
        // Here comes the list of the primary servers for this zone
    };
// ... repeated for all forward zones

この設定は期待通りに動作しますが、少し不便です。プライマリ サーバーのリストは、すべての「転送」ゾーンに対して繰り返す必要があります。転送ゾーンは数多くあり、すべて IPv4 と IPv6 アドレスを持っています。^C/^V ですべてのゾーンにリストするのは、私が見た中で最もエレガントなものではなく、DRY 準拠でもありません。

forwardersこのステートメントはグローバル セクションにも含めることができることは知っていますoptionsが、基本的な実験から、このステートメントは転送ゾーンには適用されず、転送専用のネーム サーバーのみを対象としていることを理解しています (ドキュメントは明確ではありませんが、「forwardersステートメントが存在しない場合は、[...] ステートメント内のすべてのフォワーダーの効果をキャンセルしますoptions」と記載されています)。

ACL を作成するのとほぼ同じ方法で、フォワーダーの名前付きリストを作成し、forwarders関連するゾーン内のステートメントでこのシンボリック名を使用する方法はありますか?

答え1

他の多くのデーモンやサービスと同様に、ISC Bindはinclude設定ファイルにディレクティブを追加します。

これにより、構成設定とディレクティブのリストを別のファイルに移動し、必要な場所でそのインクルードを参照できるようになります。

これにより、フォワーダーのリストを 1 か所で管理するだけで済むため、管理上の負担が軽減され、必要な場所に参照をコピーするだけで済みます。

// "/var/named/includes/forwarders.conf"
// master list of forwarders

forwarders {
            192.0.2.21;
            192.0.2.88;
};

そして、named.conf で次の操作を実行します。

zone "somedomain.example" IN {
    type forward;
    forward first;
    include "/var/named/includes/forwarders.conf";
}
zone "otherdomain.example" IN {
    type forward;
    forward first;
    include "/var/named/includes/forwarders.conf";
}

関連情報