DNSサーバーの種類の比較：適切なDNS構成を選択する方法

権限のみのDNSサーバーは、自身が担当するゾーンのクエリへの応答にのみ関与するサーバーです。 外部ゾーンのクエリの解決には役立たないため、通常は非常に高速で、多くの要求を効率的に処理できます。

権限のみのサーバーには次のプロパティがあります。

キャッシュDNSサーバーは、クライアントからの再帰的な要求を処理するサーバーです。 オペレーティングシステムのスタブリゾルバが接続するほぼすべてのDNSサーバーは、キャッシングDNSサーバーになります。

キャッシュサーバーには、クライアントからの再帰的な要求に応答するという利点があります。 権限のあるサーバーは特定のゾーン情報を提供するのに理想的かもしれませんが、クライアントの観点からはDNSサーバーのキャッシングがより広く役立ちます。 それらは、世界のDNSシステムを、かなり愚かなクライアントインターフェイスからアクセス可能にします。

再帰的要求を受信するたびに他のDNSサーバーに複数の反復要求を発行することによるパフォーマンスヒットを回避するために、サーバーはその結果をキャッシュします。 これにより、最近のリクエストを非常に迅速に処理しながら、広範なDNS情報（世界中で公開されているDNS）にアクセスできます。

キャッシュDNSサーバーには次のプロパティがあります。

クライアントマシンのキャッシュを開発する別の方法は、転送DNSサーバーを使用することです。 このアプローチは、すべての要求を再帰的な機能を持つ別のDNSサーバー（キャッシュDNSサーバーなど）に単に渡す転送サーバーを実装することにより、DNS解決のチェーンに追加のリンクを追加します。

このシステムの利点は、再帰的な作業を行わずにローカルアクセス可能なキャッシュの利点を提供できることです（追加のネットワークトラフィックが発生し、トラフィックの多いサーバーでかなりのリソースを占有する可能性があります）。 また、これにより、異なるサーバーに転送することにより、プライベートトラフィックとパブリックトラフィックを分割する際の興味深い柔軟性が得られます。

転送DNSサーバーには次のプロパティがあります。

上記のソリューションは非常に具体的な目的を念頭に置いて構築されていますが、多くの場合、それぞれの利点を組み合わせてDNSサーバーをセットアップすることが望まれます。

DNSサーバーは、選択した数のローカルクライアントに対して再帰的なキャッシュサーバーとして機能し、他のクライアントからの反復的で信頼できる要求にのみ応答するように構成できます。 これは、ドメインのグローバルリクエストに応答できると同時に、ローカルクライアントが再帰的な解決のためにサーバーを利用できるため、一般的な構成です。

特定のDNSソフトウェアは特定の1つの役割を満たすように特別に設計されていますが、Bindなどのアプリケーションは非常に柔軟であり、ハイブリッドソリューションとして使用できます。 単一のサーバーで多すぎるサービスを提供しようとすると、パフォーマンスが低下する場合がありますが、多くの場合、特に小規模なインフラストラクチャの場合、単一のオールインワンソリューションを維持するのが最も理にかなっています。

サービスおよびネットワーク全体をアクセス可能にする際のDNSの重要性を考えると、ゾーンに対して権限を持つほとんどのDNSサーバーには組み込みの冗長性があります。 これらのサーバー間の関係にはさまざまな用語がありますが、通常、サーバーは構成内でprimaryまたはsecondaryのいずれかになります。

プライマリサーバーとセカンダリサーバーはどちらも、処理するゾーンに対して権限があります。 プライマリは、セカンダリよりもゾーンに対して電力を消費しません。 プライマリサーバーとセカンダリサーバーの唯一の差別化要因は、ゾーンファイルの読み取り元です。

プライマリサーバーは、システムのディスク上のファイルからゾーンファイルを読み取ります。 これらは通常、ゾーン管理者が元のゾーンファイルを追加、編集、または転送する場所です。

セカンダリサーバーは、ゾーンのプライマリサーバーのいずれかからのゾーン転送を通じて権限のあるゾーンを受け取ります。 これらのゾーンを取得すると、それらをキャッシュに配置します。 再起動する必要がある場合は、まずキャッシュをチェックして、内部のゾーンが最新かどうかを確認します。 そうでない場合は、更新された情報をプライマリサーバーに要求します。

サーバーは、処理するすべてのゾーンのプライマリまたはセカンダリにのみ委任されません。 プライマリステータスまたはセカンダリステータスはゾーンごとに割り当てられるため、サーバーは一部のゾーンではプライマリになり、他のゾーンではセカンダリになることができます。

DNSゾーンには通常、少なくとも2つのネームサーバーがあります。 インターネットルーティング可能ゾーンmustを担当するゾーンには、少なくとも2つのネームサーバーがあります。 多くの場合、負荷を分散して冗長性を高めるために、さらに多くのネームサーバーが維持されます。

多くの場合、組織は外部と内部の両方でDNSを使用します。 ただし、これらの両方の領域で使用可能にする必要がある情報は、しばしば大きく異なります。

組織は、外部で使用可能な権限のみのDNSサーバーを維持して、処理するドメインおよびゾーンのパブリックDNSクエリを処理する場合があります。 内部ユーザーに対して、組織は、パブリックDNSが提供する信頼できる情報と、内部ホストおよびサービスに関する追加情報を含む別のDNSサーバーを使用する場合があります。 また、内部クライアントの再帰やキャッシングなどの追加機能も提供する場合があります。

上記の「組み合わせ」サーバーでこれらすべてのタスクを単一のサーバーで処理する機能について説明しましたが、ワークロードを分割することには明確な利点があります。 実際、互いに知識のない完全に別個のサーバー（内部と外部）を維持することが望ましい場合がよくあります。 セキュリティの観点から、パブリックサーバーにプライベートの相手のレコードがないことが特に重要です。 これは、パブリックゾーンファイルにNSレコードを持つプライベートネームサーバーをリストしないことを意味します。

留意すべき追加の考慮事項がいくつかあります。 パブリックサーバーとプライベートサーバーが従来のプライマリとセカンダリの関係で共通のゾーンデータを共有する方が簡単かもしれませんが、これによりプライベートインフラストラクチャに関する情報が荒れ狂う可能性があります。

プライベートサーバーをゾーンファイル（本質的にはパブリックに検索可能なエンティティ）から除外するだけでなく、通常、パブリックサーバーの構成ファイル内のプライベートサーバーへの参照も削除することをお勧めします。 これは、転送、通知、およびプライマリ構成の詳細を削除することを意味します。これにより、パブリックサーバーが侵害されても、内部のネームサーバーが突然公開されることはありません。

これは、それぞれに個別のゾーンファイルを維持することを意味し、余分な作業になる可能性があります。 ただし、これは絶対的な分離とセキュリティのために必要な場合があります。