DNSの用語、構成要素、および概念の概要

DNS (Domain Name System) は、インターネットを動かす極めて重要なコンポーネントの1つです。DNSの仕組みを正しく理解することは、ウェブサイトの設定に関する問題を診断し、舞台裏で何が起こっているのかについての理解を深めるのに役立ちます。

このガイドでは、DNS設定を作業する際の確かな基盤を提供するために、DNSのいくつかの基本的な概念について説明します。このガイドは、独自のドメイン名やDNSサーバーをセットアップする際にも役立ちます。

始めましょう！

ドメインの用語

まず、使用する用語についての理解を確立する必要があります。すでに他の文脈からいくつかの用語に馴染みがあるかもしれません。しかし、ドメイン名やDNSについて話すときには、コンピューティングの他の分野ではあまり議論されない多くの専門用語が存在します。

• Domain Name System

ドメインネームシステム（略してDNS）は、人間にとって分かりやすいドメイン名を一意のIPアドレスに変換する、導入されているネットワークシステムです。

• ドメイン名

ドメイン名とは、インターネットリソースに関連付けるために使用される、人間にとって分かりやすい名前を指します。例えば、“cloudsigma.com” はドメイン名です。“cloudsigma” の部分だけがドメイン名であると主張する人もいるかもしれませんが、一般的には全体を指します。

URL “cloudsigma.com” は、CloudSigmaが所有するサーバーに関連付けられています。ウェブブラウザにURLを入力すると、DNSと通信してターゲットサーバーのIPアドレスに接続します。

• IPアドレス

IPアドレスは、ネットワークに接続されたデバイスのネットワークアドレスとして機能します。各IPアドレスは、ネットワーク内で一意である必要があります。ウェブサイトの文脈では、ネットワークはほとんどの場合、インターネット全体を指します。

IPアドレスには次の2つのタイプがあります。

• • IPv4: これは最も一般的な形式のIPアドレスです。4つの数字のセットとして書かれ、各セットは最大3桁です。各セットはドットで区切られます。IPv4の範囲は 0.0.0.0 から 255.255.255.255.

  • IPv6: これは、IPv4アドレスの枯渇の問題を解決するために開発された、より現代的な標準です。IPv4は最大232個の一意のアドレスをサポートするのに対し、IPv6は最大2128個のアドレスをサポートします。すべてのIPv6アドレスは16進数で書かれます。最大32桁を含めることができ、8つのセクション（各セクション4桁）に分割されます。各セクションはコロン（:）で区切られます。

トップレベルドメイン

トップレベルドメイン（略してTLD）は、ドメインの最も一般的な部分です。最も右側の部分（ドットで区切られた部分）を指します。一般的なトップレベルドメインには、次のようなものがあります。

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

ドメイン名に関して言えば、これらのドメインは階層の最上位にあります。ICANN（Internet Corporation for Assigned Names and Numbers）は、特定の関係者によるトップレベルドメインの管理を許可することができます。許可を得ることで、これらの関係者はTLDの下でドメイン名を配布できます（通常はドメインレジストラを介して）。

• ホスト

ドメイン内において、所有者は個々のホストを指定でき、これはドメインを通じてアクセス可能な個別のマシンやサービスを指します。例えば、ベアドメイン（ example.com) と“ホスト”定義の“www  ( www.example.com).

) 一般的なドメインの下に、追加のホストを持たせることも可能です。例えば、“api”ホスト ( api.example.com), “ftp”または“files”ホストを介したFTPアクセス ( ftp.example.com または files.example.com).

ドメイン内で一意である限り、ドメイン名は任意に設定できることに注意してください。

• サブドメイン

サブドメインはホストに関連するテーマです。DNSは階層構造で機能します。TLDの下には多くのドメインを配置できます。例えば、“ example.com”, “ cloudsigma.com”などはすべて“com” TLDの下にあります。その点において、サブドメインとは、ターゲットドメインの一部である任意のドメインへの参照を指します。したがって、“example.com”は“com”のサブドメインであると言うことができます。一般的に、“example”の部分はSLD（セカンドレベルドメイン）と呼ばれます。

同様に、ドメインはその下にあるすべての“サブドメイン”を制御できます。通常、“サブドメイン”という言葉はこれを指すために使用されます。たとえば、“ history.example.com”は“ のサブドメインです。example.com”.

ホスト名とサブドメインの主な違いは、ホストがコンピュータやリソースを定義するのに対し、サブドメインは親ドメインを拡張する点にあります。サブドメインやホストについて話すときはいつでも、ドメインの最も左側の部分を見ることで確認できます。そこが最も具体的な部分だからです。DNSはそのように機能します。つまり、最も具体的な部分（最も左側）から最も具体的でない部分（最も右側）へと処理されます。

• 完全修飾ドメイン名

完全修飾ドメイン名（略してFQDN）とは、絶対ドメイン名のことです。DNSシステムでは、ドメインを互いに相対的に指定することができます。これにより、ある程度の曖昧さが生じる可能性があります。しかし、FQDNはドメイン名システムの絶対的なルートを指す絶対的な名前です。

これは、FQDNがTLDを含む各親ドメインを指定することを意味します。適切な例としては、“ mail.google.com”が挙げられます。特定のケースでは、FQDNの末尾にドットがない場合もありますが、本来は末尾にドットが必要です（ICANN標準で義務付けられています）。

• ネームサーバー

ネームサーバーとは、ドメイン名をIPアドレスに変換するための専用のコンピュータです。ネームサーバーは、DNSシステムにおける負荷の大部分を担っています。ドメイン変換要求の総数は単一のサーバーで処理するには多すぎるため、負荷を軽減するために要求は他のネームサーバーにリダイレクトされることがよくあります。

ネームサーバーは“権威（オーソリティ）”を持つことができます。これは、自身が管理するドメインに関する問い合わせに対してのみ回答することを意味します。このようなサーバーは、要求を他のネームサーバーに中継したり、他のネームサーバーのデータのキャッシュコピーを提供したりできます。

• ゾーンファイル

ゾーンファイルは、ドメイン名とIPアドレスのマッピングを含むテキストファイルです。これはDNSシステムのデータベースとして機能します。これは、特定のドメイン名に対するユーザーの要求を処理する際に、DNSがどのIPアドレスに接続すべきかを特定するために使用するカタログです。

一般的に、ネームサーバーはゾーンファイルをホストし、単一のドメインの下で利用可能なリソースを定義します。また、その情報を取得するためにどこにアクセスすべきかに関する情報を保持することもできます。

• レコード

ゾーンファイルは多数のレコードで構成されています。ここで、レコードとはリソースと名前の間の単一のマッピングとして定義されます。レコードには、IPアドレスにマッピングされたドメイン名、特定のドメインの下で利用可能なリソース、または情報を取得する場所への参照などがあります。

DNSの仕組み

ここまでは、DNSに関連するいくつかの一般的な用語について説明してきました。しかし、このシステムは実際にどのように機能しているのでしょうか？全体像を見ると、システムは非常にシンプルに見えるかもしれません。それにもかかわらず、詳細を掘り下げていくと、その真の複雑さが明らかになります。全体として、DNSシステムはインターネットの普及において重要な役割を果たしています。

• ルートサーバー

DNSは、その核心において階層構造で機能します。システムの最上位には“ルートサーバー”が存在します。これらのサーバーは、さまざまな組織の管理下にあります。これらのサーバーの権限は、ICANN（Internet Corporation for Assigned Names and Numbers）によって委任されています。

現在、約13台のルートサーバーが稼働しています。しかし、負荷の関係上、これらのサーバーはそれぞれミラーリングされています。すべてのミラーサーバーがルートサーバーと同じIPアドレスを共有していることに注意することが重要です。ルートサーバーに対して要求が行われると、その要求はそのサーバーの最も近いミラーにリダイレクトされます。

ルートサーバーの役割は何でしょうか？これらはトップレベルドメインに関する情報を提供します。下位のネームサーバーが要求を解決できない場合、その要求はドメインのルートサーバーにリダイレクトされます。

しかし、ルートサーバーは実際にはドメインの場所を知りません。具体的に要求されたトップレベルドメインを処理するリクエストを転送するだけです。例えば、“ blog.cloudsigma.com”に対してリクエストが行われた場合、ルートサーバーはそのレコードを保持していません。ゾーンファイルを検索しますが、レコードは見つかりません。代わりに、“com” TLDを認識し、リクエスト元のエンティティを“com”アドレスを処理するネームサーバーにリダイレクトします。

• TLDサーバー

前述の例の続きとして、リクエスト元のエンティティは（ルートサーバーから提供された）IPアドレスにリクエストを送信します。“ blog.cloudsigma.com”の場合、“com”ネームサーバーは自身のゾーンファイル内のレコードを検索します。

リクエストに対応するレコードはありません。しかし、以下のドメインを担当するネームサーバーのIPアドレスを記載したレコードが見つかります：“ cloudsigma.com”.

• ドメインレベルネームサーバー

これで、リクエスト元のエンティティは、実際に以下の情報をホストしているネームサーバーのIPアドレスを取得したことになります：“ blog.cloudsigma.com”。次に、サーバーに新しいリクエストを送信し、“www.cloudsigma.com”の解決を要求します。

以前と同様に、ネームサーバーはゾーンファイルをチェックし、以下に関連付けられているファイルを見つけます：“ cloudsigma.com”。このファイル内には、“www”ホストのエントリが存在します。このレコードは、ホストがどこに位置しているかを示しています。その後、最終的な回答がリクエスト元のエンティティに転送されます。

• リゾルビングネームサーバー

例の中で、リクエスト元のエンティティについて言及しました。それは何でしょうか？ほとんどの場合、リクエスト元は“リゾルビングネームサーバー”です。これは、他のサーバーに問い合わせを行うように設定されたサーバーです。ユーザーの中継サーバーとして機能します。速度を向上させるために結果をキャッシュします。

通常、どのユーザーもシステムにいくつかのリゾルビングネームサーバーが設定されています。一般的に、リゾルビングネームサーバーはISPやその他の組織によって提供されます。例えば、Googleは、問い合わせ用のパブリックリゾルビングDNSサーバーを提供しています。システムに手動で設定することも可能です。

ウェブブラウザにURLを入力すると、リソースの場所が検索されます。まず、ローカルで検索が行われます。これには“hosts”ファイル（およびその他のいくつかの場所）が含まれます。見つからない場合、リクエストはリゾルビングネームサーバーに送信されます。リクエストを受信すると、リゾルビングネームサーバーはキャッシュから回答を検索します。見つからない場合は、前述の手順を実行します。

リゾルビングネームサーバーは、エンドユーザーのリクエストプロセスを簡素化します。クライアントはリゾルビングネームサーバーにリソースの場所を問い合わせるだけです。ネームサーバーが調査を行い、最終的な回答を返します。

• ゾーンファイル

すでに“ゾーンファイル”と“レコード”の概念について説明しました。では、これらはどのように動作するのでしょうか？

ゾーンファイルはネームサーバーのデータベースとして機能し、ネームサーバーが認識しているドメインに関する情報を保存します。ネームサーバーが認識しているすべてのドメインは、そのゾーンファイルに保存されます。しかし、ネームサーバーに届くほとんどのリクエストは、ゾーンファイルによって解決されるわけではありません。サーバーの設定が再帰的問い合わせを処理するようになっている場合（例えばリゾルビングネームサーバーなど）、回答を返します。そうでない場合は、リクエスト元を次に探すべき別の場所にリダイレクトします。

ネームサーバーがホストするゾーンファイルが多いほど、その回答の権威（信頼性）が高くなります。ゾーンファイルはDNS“ゾーン”（DNSネーミングシステム全体のサブセット）を記述します。一般的に、ゾーンファイルには単一のドメインの設定データのみが含まれます。対象のドメインのリソースの場所を定義する多数のレコードを含めることができます。

ゾーンの $ORIGINパラメータは、そのゾーンの最高レベルの権威に等しくなります。例えば、“ cloudsigma.com”のゾーンファイルは、その $ORIGINを“ cloudsigma.com”。このパラメータの値は、ゾーンファイルの先頭、またはDNSサーバーの構成に保存できます。いずれにしても、このパラメータはファイルがどのゾーンに対して権限を持っているかを記述します。

The $TTL パラメータは、提供する結果の“time to live”（生存時間）情報を設定します。これは、キャッシュサーバーがキャッシュされた応答の有効性を追跡するために使用できるタイマーとして説明できます。TTL値が切れると、その応答は無効になり破棄されます。

• レコードタイプ

ゾーンファイルは多数のレコードで構成されています。レコードにはさまざまなタイプがあります。次に、最も一般的（かつ必須）なレコードタイプをいくつか見ていきましょう。

SOAレコード

Start of Authority（略してSOA）レコードは、すべてのゾーンファイルで必須です。これはファイル内の最初の実際のレコードである必要があります。ただし、次のようなエントリは $ORIGIN または $TTL が事前に表示されることは許可されています。

SOAレコードは、より複雑なレコードタイプの1つです。その構造は次のようになります。

細かく分解してみましょう：

• • example.com：この部分はゾーンのルートを定義します。この例では、ゾーンファイルはドメイン“ example.com”用です。場合によっては、この値が @（ の値を置き換えるためのプレースホルダー）$ORIGIN).

  • IN SOA：“IN”という用語は“internet”を意味します。これは多くのレコードで見られます。“SOA”という用語は、それがSOAレコードであることを示します。

  • ns1.example.com：この値は、ドメイン“ example.com”のプライマリネームサーバーを保持します。ネームサーバーはプライマリまたはセカンダリのいずれかになります。ダイナミックDNSで構成されている場合は、1つの“プライマリ”サーバーが必要です。ダイナミックDNSが構成されていない場合は、プライマリネームサーバーのいずれかになります。

  • admin.example.com：ここにゾーン管理者のメールアドレスが入ります。なお、 @ は に置き換えられます。.。元のメールアドレスにドットが含まれている場合は、 に置き換えられます。\。たとえば、“ my.domain@example.com” は “ my\domain.example.com”.

  • 12083：ゾーンファイルのシリアル番号です。ゾーンファイルが編集されるたびに、ファイルが適切に伝播されるように番号を更新する必要があります。セカンダリサーバーは、このシリアル番号を使用して、自身のゾーンファイルが最新であるかどうかを追跡します。

  • 3h：ゾーンのリフレッシュ間隔を表します。セカンダリサーバーは、ゾーンファイルの更新を確認する前に、この時間だけ待機します。

  • 30m：この値はゾーンのリトライ間隔を表します。リフレッシュ期間が経過した後にセカンダリサーバーがプライマリサーバーへの接続に失敗した場合、プライマリサーバーに再度ポーリングする前にこの時間だけ待機します。

  • 3w：この値は有効期限を表します。セカンダリサーバーがこの期間中プライマリサーバーへの接続に失敗した場合、“権威ある（authoritative）”応答を返すのを停止します。

  • 1h：この値は、ゾーンファイルで見つからなかった場合に、ネームサーバーが名前エラーをキャッシュする時間を表します。

AおよびAAAAレコード

これらのレコードは、ホストとIPアドレスの間のマッピングを確立します。ここで、“A”レコードはホストへのIPv4マッピングを示し、AAAAはIPv6マッピングを示します。

以下は、AおよびAAAAレコードの基本的な構造です。

SOAレコードの例では、ネームサーバーを“ ns1.exampel.com”と呼びました。ネームサーバーはドメイン“ example.com”に属します。そのAレコードは次のようになります：

フルネームを指定する必要はなかったことに注意してください。ホスト名（FQDNなし）だけで、DNSサーバーは残りの部分を $ORIGINの値で補完できます。ただし、次のようにFQDNを使用することもできます：

Webサーバーを“www”として定義する方法は次のとおりです：

ベースドメインへのマッピングも含める必要があります。エントリは次のようになります：

あるいは、 @ 記号を使用して（フルネームの代わりに）ベースドメインを表すこともできます：

明示的に定義されていないこのドメイン配下のすべてを解決できるようにするワイルドカードエントリを含めることは、優れたプラクティスです：

同じ構造がAAAAレコードにも適用されます。唯一の違いはIPv6アドレスである点です。

CNAME Records

CNAMEレコードは、サーバーの正規名（AまたはAAAAレコードで定義）のエイリアスとして機能します。次の例を見てみましょう：

ここでは、“www”という名前を定義するためのエイリアスとして“server1”を使用しました。このようなショートカットを使用すると、サーバーが最終的な回答を得るために追加のクエリを実行する必要があるため、パフォーマンスコストが発生することに注意してください。エイリアスのレイヤー数によっては、これが原因でパフォーマンスが大幅に低下する可能性があります。ただし、CNAMEエイリアスの恩恵を受ける特定のケースが1つあります。たとえば、現在のゾーンの外部にあるリソースを提供する場合などです。

MX Records

MXレコードは、ドメインのメールエクスチェンジャーを定義します。これにより、メールがサーバーに正しく届くようになります。他のレコードとは異なり、MXレコードはゾーン全体に適用されるため、ホストを何かにマッピングすることはありません。そのため、MXレコードは次のようになります：

エントリの先頭にホスト名がないことに注意してください。また、行内に追加の値があることにも気づくでしょう。これは、どのサーバーにメールを送信するかを決定するのに役立つ優先度番号です（複数のメールサーバーが定義されている場合）。数値が小さいほど、優先度が高くなります。

MXレコードは、AまたはAAAAレコードで定義されたホストを指す必要があります（CNAMEではありません）。それを念頭に置いて、2つのメールサーバーが構成されている場合、レコードは次のようになります：

この例では、優先度番号から判断して、“mail1”が“mail2”よりも優先されるサーバーです。完全なドメイン名を省略することで、コードをさらに短縮できます：

NS Records

これらのレコードは、特定のゾーンの名前サーバーを定義します。ここで当然の疑問が生じます。ゾーンファイルが名前サーバー内にあるのに、なぜ自分自身への参照が必要なのでしょうか？その疑問に対する1つの答えは、DNSシステムの複数のキャッシュメカニズムです。ゾーンファイルは、実際には他のサーバー上のキャッシュされたコピーである可能性があります。

MXレコードと同様に、NSレコードはゾーン全体に適用されます。したがって、デフォルトでは特定のホストを持ちません。NSレコードのエントリは次のようになります：

1つのサーバーが正常に動作しなくなった場合に備えて、2つの名前サーバーを定義することをお勧めします。さらに、ほとんどのDNSサーバーは、名前サーバーが1つしか含まれていない場合、ゾーンファイルを拒否します。

また、AまたはAAAAレコードを使用したホストのマッピングも含める必要があります：

PTRレコード

PTRレコードは、従来のAレコードまたはAAAAレコードの逆の役割を果たします。これらのレコードは、IPアドレスに関連付けられた名前を定義するために使用されます。これらのレコードには、 から始まるというユニークな特性があります。.arpa ルートから始まり、IPアドレスの所有者を表します。組織やサービスプロバイダーにIPアドレスを分配するのは、RIR（地域インターネットレジストリ）です。RIRには、APNIC、AFRINIC、LACNIC、RIPE NCC、ARINなどがあります。

たとえば、 のPTRレコードは111.222.333.444 以下のようになります。

次のPTRレコードの例では、GoogleのIPv6 DNSサーバー を見てみましょう。2001:4860:4860::8888:

digツールにフラグ -xを指定して、IPアドレスの逆引きDNS名を検索できます。たとえば、 の逆引きDNS IPアドレスを確認してみましょう。8.8.4.4:

インターネットサーバーは、ログエントリ内のドメイン名を追跡したり、情報に基づいたスパム処理の決定を行ったり、他のデバイスに関する読みやすい情報を表示したりするためにPTRレコードを使用します。

一般的に使用されるメールサーバーは、メールの送信元IPアドレスのPTRレコードを検索します。PTRレコードが空の場合、そのメールがスパムである可能性が高くなります（したがって拒否されます）。FQDNとPTRレコードのドメイン名が一致しているかどうかは問題ではないことに注意してください。重要な要素は、有効なPTRレコードが、一致する対応する正引きAレコードに関連付けられているかどうかです。

一般的に、インターネット上のネットワークルーターには、その物理的な場所に対応するPTRレコードがあります。たとえば、“NYC”や“CHI”は、ニューヨークとシカゴにあるルーターの有効な参照先です。この手法は、tracerouteやMTRを実行してパケットが通過する経路を確認する際に役立ちます。

CAAレコード

これらのレコードは、ドメインのSSL/TLS証明書を発行できるCA（認証局）を指定します。2017年9月8日以降、すべてのCAは証明書を発行する前にCAAレコードを確認することが義務付けられています。CAAレコードが存在しない場合、どのCAでも証明書を発行できます。存在する場合は、特定のCAのみが証明書の発行を許可されます。CAAレコードは、単一のホストまたはドメイン全体に適用できます。

以下はCAAレコードの例です。

エントリのCAA固有の部分は、 0 issue "letsencrypt.org"です。この部分には3つの要素が含まれています。

• フラグ：CAが理解できないタグをどのように処理すべきかを示す整数値です。フラグの値が0に設定されている場合、レコードは無視されます。値が1の場合、CAは証明書の発行を拒否しなければなりません。
• タグ：CAAレコードの目的を示す文字列です。現時点で有効な値には、 issue（特定のドメインに対して証明書を発行する権限をCAに与える）、 issuewild（ワイルドカード証明書を許可する）、および iodef （CAがポリシー違反を報告するURLを定義する）があります。
• 値：レコードのタグに関連付けられた文字列です。タグが issueまたは issuewildの場合、値は通常、許可を与えるCAのドメインになります。タグが iodefの場合、問い合わせフォームのURLまたは mailto: メールフィードバック用のリンクになります。

digツールを使用してCAAレコードを取得できます。

CAAレコードの詳細については、RFC 6844.

最後に

このガイドでは、DNSに関連するさまざまな用語について説明します。また、すべてのコンポーネントがどのように連携するのかについても説明します。この詳細な概要を念頭に置くことで、DNSシステムの機能を十分に理解できるはずです。一般的な概念はシンプルで理解しやすいものですが、その詳細は非常に急速に複雑になります。経験の浅い管理者にとって、これらの概念や戦略を適用することは難しい場合があります。

CloudSigmaのお客様ですか？それなら、CloudSigmaインフラストラクチャの逆引きDNS/PTRレコードの管理と更新.

ハッピーコンピューティング！