DNSアーキテクチャのサニティチェック

Question

ネットワーク用のDNSサービスを設計していますが、アーキテクチャに関する質問がいくつかありました。 O'Reilly/Cricket Liu DNSブックおよび NIST DNSセキュリティガイドは、非常に一般的な方法を除いて、これらの質問に対処しません。

これが提案されたネットワークであり、内部（RFC 1918スペース）とDMZセグメント（DNSサーバーだけでなく複数のサーバーを含む）、および外部コロにメールサーバーとwwwサーバーがあります。DNSサーバーは青いボックスです。

Candidate DNS network

要件は次のとおりです。

DNSSECサポート
内部ネットワークでは、RFC1918スペースの内部ゾーンへの委任
権限のあるサーバーと再帰的なサーバーを分離する
非表示のマスター（別名非表示のプライマリ）は、スレーブへのゾーン転送を許可しますが、要求は解決しません
すべてのネームサーバーはchrootされて実行されます（FreeBSDのBindのデフォルト）

これが私の質問です：

このデザインについて明らかに壊れているものはありますか？
ここに欠落している要素や無関係な要素はありますか？
内部スレーブサーバーと同じサブネット上で非表示のマスターを実行してもよろしいですか？
内部ネットワークとDMZ）ネットワークでのDNSトラフィックが比較的軽い（<1 Mbps）場合、権限のあるサーバーでキャッシング専用サーバーをjail（BSD-VMの場合）で実行することにはセキュリティ上の問題がありますか？？それとも専用のマシン上にあるべきですか？

前もって感謝します！

Daniel Widrick · Accepted Answer

これが私の質問です：

1）このデザインについて何か明らかに壊れていますか？

何もありません明らかに間違っています。 ..少なくとも私が見ることができること。

2）ここに欠落している要素や無関係な要素はありますか？

行方不明：隠されたマスターのホットスタンバイがないのは快適ですか？システムは、単一のプライマリホストに依存するようにかなり設計されているようです（ユースケースを見ずに過剰に設計されているとは言いたくありません）。これは図の範囲外ですが、プライマリマスターが爆破したときの緊急時対応計画はありますか[not if]？

Extraneous：ミックスに追加するすべてのDNSサーバーは、管理する必要のある別のサーバーであることに注意してください。あなたの使用法を考えると、これほど多くのDNSサーバーを持つことが重要ですか？

3）内部スレーブサーバーと同じサブネット上で隠しマスターを実行しても大丈夫ですか？

私は隠されたマスターと権威あるDNSスレーブがdmzにあることを期待します。マスターを適切にロックダウンします。内部スレーブareインターネットからのゾーンの信頼できるルックアップに答えるのは正しいですか？内部スレーブが内部ホストからのゾーンのクエリにのみ応答する場合は、[〜＃〜]巨大な[〜＃〜]ゾーン、愚かな内部の数のいずれかが必要です。内部ゾーンへのルックアップ（ホスト/ワークステーションレベルでのDNSサーバーのキャッシュを検討してください）、または内部DNSに過剰な馬力を与えています。彼らがインターネットからの質問に答えているのなら、私は彼らがDMZにいることを期待します。自由にラベルを付けることができます。

マスターがスレーブと同じサブネット上にある限り、ロックダウンします。問題にはならないはずです（そして、ゾーンxfer時間のルーティングオーバーヘッドを節約できます）。

4）内部ネットワークとDMZネットワーク）で比較的軽いDNSトラフィック（<1 Mbps）がある場合、キャッシング専用サーバーをジェイル（BSD-VMの場合）で実行することにはセキュリティ上の問題がありますか？信頼できるサーバーですか？それとも専用マシン上にあるべきですか？

はい。常にセキュリティの問題があります。内部キャッシュのみのサーバーが内部ソースからのトラフィックのみを受け入れるようにロックダウンされている場合、それらはおそらくBSD環境の刑務所に入れられ、定期的に更新および監視されます...ハッカーは環境を悪用するためにやるべきことがたくさんあります。

あなたの最大のリスク（参照：notプロのリスクアナリスト）は、ハッカーが一気に奇跡を起こす可能性があり、権威あるDNSスレーブの1人が乗っ取られる可能性があります。部分的な改ざんが発生する可能性があります。または、攻撃者が本当に優秀な場合は、「中毒」や情報の盗難が発生する可能性があります（SSL/TLSを参照してください）。

次に大きいのは（参照：notプロのリスクアナリスト）、再インストール/復元が必要なスレーブOSの破損です。

最終的に：

これはかなり堅実な設計であり、ネットワークを視野に入れなければ（私たちに提供することは期待できません）、設計の欠点や欠点を見つけるのは非常に困難です。はっきりと目立つのは、ここにはたくさんの部品、複雑なセットアップ、そしてたくさんのエンジニアリングがあるということだけです...それのためのビジネスがあることを確認してください。

例：Bind9をAuthoritative Slaveとして実行できます。これは、再帰的/転送ルックアップを実行し、すべてを1つのデーモンにキャッシュします。（そして、マルチホーミング/ポートフォワーディング/その他のネットワークの魔法を節約して、2つのDNSデーモンが同じボックスで応答するようにします）。