web-dev-qa-db-ja.com

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

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

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

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

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

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

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

6
John Greene

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

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

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

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

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

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

server <netprefix> {
   ...
};

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

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

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

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

7
Tommiie