前書き

DNS、またはドメインネームシステムは、システムが相互に接続してインターネット上で通信する方法の不可欠な部分です。 DNSがなければ、コンピューターとそれを使用するユーザーは、IPアドレスと呼ばれる数値アドレスのみを使用して接続する必要があります。

単純なタスクのために多数の複雑な数字を覚えなければならないという明らかな問題に加えて、IPアドレスを介した通信もいくつかの追加の問題を引き起こします。 Webサイトを別のホスティングプロバイダーに移動するか、サーバーを別の場所に移動するには、すべてのクライアントに新しい場所を通知する必要があります。

DNSサーバーは、アドレスの代わりに名前を使用できるシステムを形成するコンピューターであり、さまざまな機能を提供できます。各機能は、名前でサーバーにアクセスする能力に貢献できます。

https://www.digitalocean.com/community/tutorials/an-introduction-to-dns-terminology-components-and-concepts [前のガイド]で、ドメイン名システムの基本的な用語と概念のいくつかについて説明しました。 その記事で説明されている概念にある程度精通していると仮定します。 このガイドでは、さまざまな種類のDNSサーバー設定のいくつかと、それぞれの利点、使用例、およびプロパティについて説明します。

DNSクエリのパス

クライアントプログラムがドメイン名でサーバーにアクセスする場合、ドメイン名を、通信に使用できる実際のルーティング可能なアドレスに変換する方法を見つける必要があります。 サーバーに情報を取得または送信するには、この情報を知る必要があります。

ほとんどのWebブラウザを含む一部のアプリケーションは、最近のクエリの内部キャッシュを保持しています。 これは、問題のドメインのIPアドレスを見つけるために、アプリケーションがこの機能を持っているかどうかを確認する最初の場所です。 ここで質問の答えが見つからない場合、*システムリゾルバ*にドメイン名のアドレスが何かを尋ねます。

一般的に*リゾルバ*は、DNSクエリのクライアント側の参加者として機能するコンポーネントです。 システムリゾルバは、オペレーティングシステムがDNSクエリの回答を探すために使用する解決ライブラリです。 一般的に、システムリゾルバーは、システム上のいくつかの静的ファイル( `+ / etc / hosts +`ファイルなど)を検索して別のリゾルバーにリクエストを転送する以上の複雑さはないため、通常*スタブリゾルバー*と見なされます。

そのため、一般に、クエリはクライアントアプリケーションからシステムリゾルバに送られ、そこでアドレスを持つDNSサーバーに渡されます。 このDNSサーバーは、*再帰DNSサーバー*と呼ばれます。 再帰サーバーは、質問への回答が見つかるまで他のDNSサーバーに照会するように構成されたDNSサーバーです。 応答またはエラーメッセージをクライアントに返します(この場合はシステムリゾルバーがクライアントアプリケーションに渡します)。

再帰サーバーは一般にキャッシュも維持します。 最初にこのキャッシュをチェックして、クエリに対する回答が既にあるかどうかを確認します。 そうでない場合は、上位レベルのドメインコンポーネントを制御するサーバーのいずれかにアドレスがあるかどうかを確認します。 そのため、リクエストが `+ www.example.com `に対するもので、そのホストアドレスがキャッシュで見つからない場合、 ` example.com `のネームサーバーのアドレスがあるかどうか、また必要に応じて ` com + `。 次に、詳細な情報を照会するために、検索できる最も特定のドメインコンポーネントのネームサーバーに照会を送信します。

これらのドメインコンポーネントへのアドレスが見つからない場合は、*ルートネームサーバー*に照会して、階層の最上部から開始する必要があります。 ルートサーバーは、「。com +」、「。net 」、「。org 」などのゾーンを制御するすべてのTLD(トップレベルドメイン)ネームサーバーのアドレスを知っています。 それは、アドレスが「 www.example.com 」を知っているかどうかをルートサーバーに尋ねます。 ルートサーバーは再帰サーバーを ` .com +` TLDのネームサーバーに参照します。

その後、再帰サーバーは、ドメインコンポーネントの責任を委任された各連続ネームサーバーへの照会の追跡に従い、完全な答えを持っている特定のネームサーバーをゼロにすることができます。 後のクエリのためにこの回答をキャッシュに入れてから、クライアントに返します。

この例からわかるように、サーバーには多くの種類があり、それぞれが異なる役割を果たします。 さまざまな種類のDNSサーバーの詳細を見ていきましょう。

機能の違い

DNSサーバー間の違いのいくつかは、純粋に機能的です。 DNSの実装に関与するほとんどのサーバーは、特定の機能に特化しています。 選択するDNSサーバーの種類は、ニーズと解決したい問題の種類に大きく依存します。

権限のあるDNSサーバー

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

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

  • *制御するゾーンのクエリへの応答が非常に高速です。*権限のみのサーバーには、担当するドメインに関するすべての情報、または他のネームサーバーに委任されたドメイン内のゾーンの参照情報があります。

  • *再帰クエリには応答しません。*権限のみのサーバーの定義は、再帰要求を処理しないサーバーです。 これにより、サーバーのみとなり、DNSシステムのクライアントにはなりません。 権限のみのサーバーに到達する要求は、通常、それへの紹介を受け取ったリゾルバーから送信されます。つまり、権限のみのサーバーは完全な回答を取得するか、ネームサーバーに新しい紹介を渡すことができます。責任を委任したこと。

  • クエリ結果をキャッシュしません 知っているすべての情報はすでにシステムにあります。

DNSサーバーのキャッシュ

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

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

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

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

  • *パブリックDNSデータの全範囲へのアクセス。*グローバル委任ツリーにフックされたパブリックにアクセス可能なDNSサーバーが提供するすべてのゾーンデータには、キャッシュDNSサーバーが到達できます。 ルートDNSサーバーを認識しており、データを受信するときに紹介をインテリジェントに追跡できます。

  • *ダムクライアントにデータをスプーンフィードする機能。*ほとんどすべての最新のオペレーティングシステムは、スタブリゾルバーを使用して、専用の再帰サーバーにDNS解決をオフロードします。 これらの解決ライブラリは、単に再帰的なリクエストを発行し、完全な回答が返されることを期待しています。 キャッシングDNSサーバーには、これらのクライアントに対応する正確な機能があります。 再帰クエリを受け入れることにより、これらのサーバーは応答またはDNSエラーメッセージを返すことを約束します。

  • *最近リクエストされたデータのキャッシュを維持します。*クライアントリクエストのために他のDNSサーバーから収集した結果をキャッシュすることにより、キャッシュDNSサーバーは最近のDNSデータのキャッシュを構築します。 サーバーを使用するクライアントの数、キャッシュの大きさ、DNSレコード自体のTTLデータの長さに応じて、ほとんどの場合、これによりDNS解決が大幅に高速化されます。

転送DNSサーバー

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

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

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

  • *再帰自体を実行せずに再帰要求を処理する機能。転送DNSサーバーの最も基本的な特性は、解決のために別のエージェントに要求を渡すことです。 転送サーバーは最小限のリソースで済み、キャッシュを活用することで大きな価値を提供できます。

  • *より近いネットワークロケーションにローカルキャッシュを提供します。*本格的な再帰DNSソリューションの構築、維持、およびセキュリティに不安を感じる場合は、転送サーバーがパブリック再帰DNSサーバーを使用できます。 プライマリキャッシュの場所をクライアントマシンの非常に近くに移動しながら、これらのサーバーを活用できます。 これにより、応答時間が短縮される場合があります。

  • *ローカルドメインスペースを定義する際の柔軟性が向上します。*要求を異なるサーバーに条件付きで渡すことにより、転送サーバーは、外部要求がパブリックDNSを使用している間に内部要求がプライベートサーバーによって処理されることを保証できます。

組み合わせソリューション

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

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

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

関係の違い

DNSサーバー構成間の最も明らかな違いはおそらく機能的ですが、リレーショナルの違いも非常に重要です。

プライマリサーバーとセカンダリサーバー

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

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

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

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

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

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

パブリックサーバーとプライベートサーバー

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

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

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

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

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

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

結論

この段階では、DNS構成の選択にはかなりの柔軟性があることをご存知でしょう。

選択は主に組織のニーズと、選択したクライアントに対してより高速なDNS解決を提供すること(キャッシュまたは転送)か、ドメインおよびゾーン全体をインターネットに提供すること(権限のあるサーバー)かによって異なります。 組み合わせアプローチは一般的であり、最終的には、解決プロセスの両側を考慮する必要があります。

次のガイドでは、これらの構成の一部を開始する方法を示します。 howキャッシングまたは転送サーバーをセットアップするには。 後で、https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-an-authoritative-only-dns-server-on-ubuntu-14でドメインを提供する方法について説明します-04 [権限のある専用DNSサーバーのペアのセットアップ]。