1. 序章

IPアドレス名前空間を使用した、グローバルに配置されたネットワークデバイス間の信頼性の高い通信は、インターネットの基盤です。 ただし、人間が数字よりも短い名前で物事を覚えるのは自然なことです。

ドメインネームシステム（DNS）は、IPアドレスの代わりにgoogle.comなどの名前でインターネットアドレスにアクセスできるようにすることで、この問題を解決します。 このチュートリアルを通じて、DNSのコアコンセプトと動作原理についての理解を深めます。

2. DNSの基本

DNSの基本から始めましょう。

2.1. ルックアップ機能

インターネットブラウザは、インターネット上のWebサイトにアクセスできるようにするために、WebサーバーのIPアドレスを見つけるためのルックアップシステムを必要とします。

まず、ブラウザはWebサイトのIPアドレスのルックアップ要求を送信します。 2番目のステップでは、ルックアップシステムはドメインのIPアドレスを含む回答で応答します。 最後に、3番目のステップで、ブラウザはIPアドレスを使用してWebサイトに接続できるようになります。

このようなルックアップシステムは、インターネット上の何十億ものアクティブなWebサイトに対応するレコードを保存できなければなりません。 ただし、インターネット上のすべてのデバイスがこのような大量のマッピングのセットをローカルに保存することは不可能です。

さらに、このようなルックアップは、インターネットが効率的に機能するために重要です。 したがって、すべてのユーザーが確実にインターネットにアクセスできるように、DNSは分散データベースシステムとして設計されています。

2.2. 分散システム

信頼性を高めるには、DNSの可用性が高く、一貫性があり、ネットワークパーティションの障害に対する耐性が必要です。 ただし、 CAP定理が示すように、すべてを同時に持つことはできません。

したがって、部分的なネットワーク障害が発生した場合、DNSは可用性または整合性のいずれかを危険にさらす必要があります。 当然のことながら、インターネットが常に機能するためには、高可用性システムになるように設計されています。

DNSは整合性よりも可用性を優先しますが、結果整合性のあるシステムであることに注意することが重要です。 したがって、時間の経過とともに、矛盾があったとしても、それはなくなります。

さらに調査を続けながら、これらの設計上の決定を念頭に置いてみましょう。 これにより、関連するすべての概念をより深く理解できるようになります。

3. ドメイン名前空間

ドメイン名前空間は、アクセスしやすいようにドメインを整理します。 さらに、ドメイン名前空間の構造は、DNSの各コンポーネントの内部構造と特定の機能に影響を与えます。 それでは、先に進んでこの概念を理解しましょう。

3.1. 階層構造

DNSを数十億のドメインレコードを保存できる分散システムとして設計するには、ドメイン名前空間全体を複数のノードに分散する論理的な方法を見つける必要があります。 したがって、インターネットドメイン名前空間は、順序付けられていないコレクションを持つ代わりに、各ノードが事実上ドメイン名である階層的なツリーのような構造として認識されます。

ここでの考え方は、所属や目的など、いくつかの特性を共有するドメインのグループが同じファミリーに属するということです。

 

ドメイン名前空間を上から下に解析する場合、最初のレベルにあるものはトップレベルドメイン（TLD）と呼ばれます。 大まかに言えば、TLDには2つのタイプがあります。

  • com （商用）、 edu （教育）、 org （非営利）などのジェネリックトップレベルドメイン（gTLD）
  • us 、 uk 、 in などの国別コードトップレベルドメイン（ccTLD）

次に、TLDのすぐ下に、そのドメインが属する組織を通常示すセカンドレベルドメインがあります。 同様に、セカンドレベルドメインのすぐ下には、同じ組織に属するインターネットアドレスをさらに整理するのに役立つセカンドレベルドメインがあります。

そのため、ルートドメインを除いて、他のすべてのドメインは親ドメインのサブドメインとも呼ばれます。 ただし、コンテキストが特定の組織に限定されている場合、第3レベルのドメインは、要するにサブドメインと呼ばれます。

3.2. 完全修飾ドメイン名（FQDN）

ドメイン名前空間内の任意のノードから、ルートノードまでトラバースすると、その絶対パスが取得されます。

親ドメインに相対的なサブドメインの概念とは異なり、絶対パスは明確です。 したがって、ドットで区切られたこのパスを書き留めると、DNSが内部で使用できる完全修飾ドメイン名（FQDN）が取得されます。

有効なドメインの命名規則に関しては、いくつかのガイドラインがあります。

  • 使用できるのは、数字（ 0-9 ）、文字（ az、AZ）、またはハイフン（ – ）のみです。
  • ドメイン名をハイフンで始めることはできません
  • FQDNは255文字を超えることはできず、個々の部分は63文字を超えてはなりません。

これらの制限を設定すると、FQDNの解析と、TLDやプリンシパルドメインなどの個々の文字列の抽出が容易になります。

3.3. ゾーン

ドメイン名前空間ツリーを見ると、リーフ以外のノードは、FQDNに同じ右側を持つドメインアドレスのファミリーを表すと考えることができます。 その上、ゾーンは、同じドメインネームサーバーによって管理されるドメイン名前空間内のドメインアドレスのグループです。

google.com 、 docs.google.com 、および sheets.google.com に関連する情報が、単一のDNSサーバーによって維持されていると想像してみてください。 dns.google.comは別のDNSサーバーによって管理されています。

 

したがって、ここには2つのDNSゾーン、つまりZONE-1とZONE-2が表示されます。 これらの中で、 ZONE-2 はドメインのサブドメイン（ dns.google.com ）、 google.com、にスコープされており、そのようなゾーンは広く知られています従属ゾーンとして。

4. DNSクライアントサーバーアーキテクチャ

高レベルの抽象化では、DNSはクライアントサーバーアーキテクチャモデルに基づいて構築されています。

クライアント/サーバーモデルで発生するように、ドメイン名解決要求はDNSクライアントによって開始されます。これは一般にDNSリゾルバーとして知られています。 その見返りとして、DNSの分散ネットワークがクライアントに応答します。

ただし、DNSは本質的に階層型分散システムであるため、正確なフローはここで見られるほど単純ではありません。

理解しておくべき重要なことの1つは、データが複数のサーバーに分散しているため、クエリを最初に取得したサーバーがそれ自体でクエリに応答できない可能性があることです。 そのため、別のDNSサーバーから回答を求める可能性があり、その間、DNSリゾルバーの役割を果たします。

5. ネームサーバー（NS）

ネームサーバーは、ドメイン名をIPアドレスに（またはその逆に）変換するために必要な関連情報を格納するため、DNSのコア機能コンポーネントです。 また、保存する情報の種類に応じて、さまざまな種類に分類できます。 それらについてもっと学びましょう。

5.1. 権威あるネームサーバー

管理の観点から、権限のあるネームサーバーは、ゾーンの信頼できるデータソースを保持するように管理者によって構成されます。 したがって、そのゾーン内のドメインのDNSクエリに応答するには、他のすべてのネームサーバーは、ある時点でこのネームサーバーに直接または間接的に問い合わせる必要があります。

ドメイン名前空間と同様に、権限のあるネームサーバーは階層的な順序に従い、ルートゾーンの権限のあるネームサーバーはツリーの最上部に配置されます。 一般的に、ゾーンという用語はしばしば削除されるため、ルートゾーンのDNSサーバーはルートサーバーと呼ばれることが多く、TLDゾーンのDNSサーバーはTLDサーバーなどと呼ばれます。

5.2. ネームサーバーのキャッシュ

ドメイン情報は変更可能ですが、それでもほとんどの場合 IPアドレスなど、この情報の多くはかなりの時間変更されません。 したがって、キャッシュは、信頼できるネームサーバーに送信されるDNSクエリの数を減らすのに役立つ便利な選択肢です。

一方では、キャッシングはDNS のパフォーマンスを向上させ、ほとんどのインターネット向けアプリケーションはこれから恩恵を受けます。 一方、それはまた、権威あるネームサーバーがいくつかの情報を変更したシステムに矛盾の可能性をもたらします。 ただし、キャッシングネームサーバーは、キャッシュされた結果を使用して応答します。

不整合の問題は、権限のあるネームサーバーによってそのレコードに対して構成された TTL （存続時間）値に基づいて、キャッシュされた結果を期限切れにするメカニズムによってある程度解決されます。 その結果、DNSは強一貫性のあるシステムではありませんが、結果整合性を提供します。

6. DNS解決

ここまでは順調ですね！ これで、DNSシステムのコアコンポーネントを正しく理解できました。 したがって、次のステップとして、これらのコンポーネントがどのように連携してDNSクエリに応答するかを見てみましょう。

6.1. 再帰的および非再帰的クエリ

DNSは、翻訳クエリに回答するために、ドメイン名前空間と権限のあるネームサーバーの階層構造を利用します。

DNSクエリを作成している間、クライアントは再帰的クエリと非再帰的クエリのどちらかを柔軟に選択できます。 前者の場合、サーバーがクエリに対して明確な回答を提供することを期待しています。 ただし、後者の場合、明確な回答または回答を保持する可能性のある紹介ネームサーバーのいずれかが必要です。

要求を処理するために、DNSリゾルバーはFQDNを右から左に解析し、その個々の部分を分離します。  次に、ルートサーバーから始まるいくつかの非再帰クエリを呼び出します。 それに応じて、次にクエリする必要のある回答または紹介ネームサーバーがあります。

最後に、最後の応答がクライアントに返されます。 この一連のイベント全体で、通常、リゾルバーにはルートサーバーのハードコードされたアドレスがあり、これはサーバーツリーのルートノードに到達するのに役立ちます。 その後、紹介はツリートラバーサルの目的を果たします。

6.2. フォワーダーとリカーサー

DNSリゾルバーは、再帰的クエリと非再帰的クエリのどちらを開始するかを決定できますが、DNSサーバーにも同様の柔軟性があります。

  • フォワーダーサーバーは、DNSクエリを別のDNSサーバーに転送できます
  • RecursorサーバーはDNSクエリをすべて単独で解決します

DNSクエリの解決は、1つ以上のDNSフォワーダーで始まり、DNSリカーサーで終わることに注意する必要があります。

当然、再帰クエリを提供するには、非再帰クエリを提供するよりもサーバーによる作業が多くなります。 したがって、再帰サーバーをセットアップする必要がある場合は、これを考慮に入れる必要があります。 ただし、ほとんどの一般的な目的では、GoogleやCloudflareなどのインターネット大手が提供するパブリックDNSリゾルバーを使用できます。

7. DNSリソースレコード

これまでのところ、議論はドメイン名からIPアドレスへの変換に限定していました。 ただし、 DNSは、インターネットドメインの他のいくつかの種類のリソースレコードを保存できます。

  • AレコードはIPv4アドレスにマップされます
  • AAAAレコードはIPv6アドレスにマップされます
  • CNAME レコードはエイリアスとして機能し、正規のドメイン名にマップされます
  • MX レコードは、ドメインに代わってメールを送受信できるメールサーバーにマップされます
  • NS レコードは、ゾーンの権限のあるネームサーバーにマップされます

これらは最も一般的に使用されるレコードであることに注意する必要があります。 さらに言えば、マイクロサービスベースの分散システムのユースケースを取り上げると、 SRVレコードは、IPアドレスとポートをサービス名にマップできるため、サービス検出において重要な役割を果たします。

8. 結論

このチュートリアルでは、ドメインの名前空間、ネームサーバー、DNSの背後にあるアーキテクチャなどのさまざまなトピックについて学びました。 DNSクエリ解決のプロセスを明確に理解するために、各トピックに飛び込みました。