公開された権威あるスレーブ上の隠しマスターのステルスDNSサーバーの公開

Question

典型的な隠しマスターDNSネットワークレイアウトには、基本的に2つのコンポーネントがあります。

非表示のマスターDNSサーバー、NATまたはファイアウォールの背後にあるか、完全に公開されている可能性があります
スレーブの信頼できる非再帰DNSサーバー

スレーブDNSサーバー上のゾーンファイルには、この非表示のマスターDNSサーバーへの情報が含まれていない（および含まれていないはずです）ことがよくあります。ただし、これらの同じスレーブDNSサーバーでは、server、allow-update、allow-transfer、一部のACLなどの特定のDNSオプションを使用する必要があります。

最初は、必要なserverとallow-updateには、IPアドレス一致リストが必要なようです。これにより、named.confはそのようなステルス情報（つまり、隠しマスターのIPアドレス）の主要なソースとして残ります。

隠しマスターDNSサーバーへのIPアドレスの公開を、named.confファイル内のIPアドレスを使用せず、代わりにキーを使用することでさらに制限できますか？

私が求めている主な答えは、ゾーンデータベースだけでなく、構成ファイルのレベルでも隠しマスターの露出を最小限にできるかどうかです。

Tommiie · Accepted Answer

スレーブDNSサーバー上のゾーンファイルには、この非表示のマスターDNSサーバーへの情報が含まれていない（および含まれていないはずです）ことがよくあります。

この非表示のDNSマスターサーバーを指すように、ゾーンファイルにAレコードを含めることができます。サーバーが「隠されている」と呼ばれるのは、誰もそれを知ることができないからではなく、NSレコードを使用してどこにもリストされていないため、クライアントがそれらをクエリできないためです。

編集：構成ファイルからこの非表示のマスターへのすべての参照を回避しようとしても意味がありません。誰かがこのファイルにアクセスできるようになると、とにかくサーバーにアクセスできると想定します。それは、隠しマスターのIPアドレスを知っているよりも大きな問題のように聞こえます。

ただし、これらの同じスレーブDNSサーバーでは、サーバー、許可更新、許可転送、一部のACLなどの特定のDNSオプションを使用する必要があります。

スレーブDNSサーバーは、非表示のDNSサーバーの存在を知っている必要があります。キーのみを使用してmastersを定義し、allow-notify etcステートメントでそれらのmastersを参照することが可能です。これにより、非表示のマスターサーバーのIPアドレスを指定する必要がなくなります。

serverステートメントは次のようになります。

server <netprefix> { ... };

したがって、非表示のマスターのIPアドレスが必要です。

ただし、allow-update、allow-transferなどのステートメントにはaddress_match_listが必要であるようです（BIND 9.11.4-P1ドキュメント、51ページ）。

（...）は、1つ以上のip_addr、ip_prefix、key_id、またはacl_name要素のリストです。セクション6.1を参照してください。

したがって、これらのコマンドではキーのみを入力でき、構成のこれらの部分から非表示のマスターのIPアドレスを除外します。