はじめに
DNS、またはドメイン名システムは、ウェブサイトやサーバーの構成方法を学ぶ際に非常に難しい部分の一つです。DNSがどのように機能するかを理解することで、ウェブサイトへのアクセスを構成する際の問題を診断し、裏側で何が起こっているかを理解する幅広い知識を得ることができます。
このガイドでは、DNS構成をスムーズに始めるのに役立ついくつかの基本的なDNSの概念について説明します。このガイドを読み終えると、DigitalOceanでドメイン名を設定したり、独自のDNSサーバーを設定する準備が整った状態になるはずです。
自分自身のドメインを解決するためにサーバーを設定したり、コントロールパネルでドメインを設定する前に、実際にこれがどのように機能するかについていくつかの基本的な概念について説明しましょう。
ドメイン用語
私たちの用語を定義することから始めましょう。これらのトピックのいくつかは他の文脈で馴染みがありますが、ドメイン名やDNSについて話す際には、コンピューティングの他の分野ではあまり使われない用語が多くあります。
簡単なところから始めましょう：
ドメイン名システム
ドメイン名システム、より一般的には「DNS」として知られています。これは、人間が理解しやすい名前を一意のIPアドレスに変換するためのネットワーキングシステムです。
ドメイン名
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
URL「google.com」は、Google Inc.が所有するサーバーと関連付けられています。ドメイン名システムにより、「google.com」と入力するとGoogleサーバーにアクセスできます。
IPアドレス
IPアドレスとは、ネットワーク上のアドレス可能な場所のことを指します。各IPアドレスは、そのネットワーク内で一意でなければなりません。ウェブサイトに関しては、このネットワークはインターネット全体です。
IPv4は、最も一般的な形式のアドレスで、4つの数字のセットとして書かれており、各セットは最大3桁までの数字であり、各セットはドットで区切られています。たとえば、「111.222.111.222」は有効なIPv4 IPアドレスです。DNSを使用すると、ネットワーク上の訪問先ごとに複雑な数値セットを覚える必要がないように、名前をそのアドレスにマッピングします。
トップレベルドメイン
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
トップレベルドメインは、ドメイン名の階層のトップに位置しています。特定の団体は、ICANN（インターネット割り当て名と番号のためのインターネット協会）からトップレベルドメインの管理権を与えられます。これらの団体は、通常、ドメインレジストラを通じてTLDの下にドメイン名を配布することができます。
ホスト
ドメイン内では、ドメイン所有者が個々のホストを定義することができます。これは、ドメインを介してアクセス可能な別々のコンピュータやサービスを指します。たとえば、ほとんどのドメイン所有者は、ウェブサーバーを裸のドメイン（example.com）および「www」という「ホスト」定義（www.example.com）を介してアクセス可能にします。
一般的なドメインの下に他のホスト定義を持つことができます。例えば、「api」というホスト（api.example.com）を介してAPIアクセスを行ったり、「ftp」または「files」というホストを定義してftpアクセスを行ったりすることができます（ftp.example.comまたはfiles.example.com）。ホスト名は、ドメイン内で一意であれば任意のものを使用できます。
サブドメイン
A subject related to hosts are subdomains.
DNSは階層的に機能します。 TLD（トップレベルドメイン）には多くのドメインが含まれています。 たとえば、「com」TLDには、「google.com」と「ubuntu.com」の両方が含まれています。 「サブドメイン」は、より大きなドメインの一部である任意のドメインを指します。 この場合、「ubuntu.com」は「com」のサブドメインと言えます。 通常、これは単にドメインまたは「ubuntu」部分は SLD（セカンドレベルドメイン）と呼ばれます。
同様に、各ドメインはそれの下に位置する「サブドメイン」を制御できます。 通常、これがサブドメインという意味です。 たとえば、学校の歴史学部のためのサブドメインを「www.history.school.edu」に持つことができます。 「history」部分がサブドメインです。
ホスト名とサブドメインの違いは、ホストがコンピューターまたはリソースを定義するのに対し、サブドメインは親ドメインを拡張することです。 これはドメイン自体を細分化する方法です。
サブドメインまたはホストについて話す場合、左側の部分が最も具体的であることがわかります。 これがDNSの動作方法です: 左から右に読むと、最も具体的なものから最も一般的なものになります。
完全修飾ドメイン名（FQDN）
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
これは、TLDを含む各親ドメインを指定することを意味します。正しいFQDNは、DNS階層のルートを示すドットで終わります。FQDNの例は、「mail.google.com.」です。FQDNを要求するソフトウェアは、終わりのドットを必要としない場合がありますが、ICANNの標準に準拠するには、トレイリングドットが必要です。
ネームサーバー
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
ネームサーバーは「権威的」である場合があり、それは彼らが制御するドメインに関するクエリに答えます。そうでなければ、他のサーバーを指すか、他のネームサーバーのデータのキャッシュコピーを提供します。
ゾーンファイル
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
ゾーンファイルはネームサーバーにあり、通常は特定のドメインの下で利用可能なリソースを定義します。または、その情報を取得できる場所を定義します。
レコード
ゾーンファイル内には、レコードが保持されます。最も単純な形式では、レコードは基本的にリソースと名前の間の単一のマッピングです。これらは、ドメイン名をIPアドレスにマップしたり、ドメインのネームサーバーを定義したり、ドメインのメールサーバーを定義したりすることができます。
DNSの動作原理
DNSに関連する用語に慣れたところで、システムは実際にどのように機能するのでしょうか？
システムは、高レベルで非常にシンプルですが、詳細を見ると非常に複雑です。しかし、全体として、これは私たちが今日知っているインターネットの普及に不可欠な非常に信頼性の高いインフラです。
ルートサーバー
DNSは、その核として階層的なシステムです。このシステムのトップには「ルートサーバー」と呼ばれるものがあります。これらのサーバーは、様々な組織によって管理され、ICANN（インターネットアドレスの割り当てと管理を行う組織）によって権限が委任されます。
現在、13のルートサーバーが稼働しています。ただし、1分ごとに解決する名前の数が非常に多いため、これらのサーバーのそれぞれが実際にはミラーされています。このセットアップの興味深い点は、1つのルートサーバーの各ミラーが同じIPアドレスを共有していることです。特定のルートサーバーに対するリクエストが行われると、そのルートサーバーの最寄りのミラーにリクエストがルーティングされます。
これらのルートサーバーは何をするのでしょうか？ ルートサーバーは、トップレベルドメインに関する情報のリクエストを処理します。したがって、下位レベルの名前サーバーが解決できないもののリクエストが届くと、ドメインのためのルートサーバーにクエリが送信されます。
ルートサーバーは実際にドメインがホストされている場所を知りません。ただし、リクエスターを特定のトップレベルドメインを処理する名前サーバーに案内することができます。
したがって、「www.wikipedia.org」のリクエストがルートサーバーに対して行われると、ルートサーバーはそのレコードで結果を見つけることはありません。それは、そのゾーンファイルをチェックして、「www.wikipedia.org」に一致するリストを見つけません。
代わりに、「org」TLDのレコードを見つけ、リクエスト元に「org」アドレスを処理する名前サーバーのアドレスを提供します。
TLDサーバー
その後、リクエスターは、ルートサーバーから与えられたIPアドレスに新しいリクエストを送信します。これは、リクエストのトップレベルドメインを担当しています。
したがって、私たちの例を続けると、それは「org」ドメインに関する情報を知っている名前サーバーに「www.wikipedia.org」がどこにあるかを見るためにリクエストを送信します。
再び、リクエスターはそのゾーンファイルで「www.wikipedia.org」を探しますが、そのレコードは見つかりません。
ただし、「wikipedia.org」の名前サーバーに関連するIPアドレスのリストを見つけることができます。これは、私たちが求めている答えにかなり近づいています。
ドメインレベルの名前サーバー
この時点で、要求元はリソースの実際のIPアドレスを知っている名前サーバーのIPアドレスを持っています。それは、「www.wikipedia.org」を解決できるかどうか、再度、名前サーバーに新しいリクエストを送信します。
名前サーバーはゾーンファイルをチェックし、「wikipedia.org」に関連するゾーンファイルがあることがわかります。このファイル内には、「www」ホストのレコードがあります。このレコードには、このホストの場所が示されているIPアドレスが記載されています。名前サーバーは、要求元に最終的な回答を返します。
リゾルバー名前サーバーとは何ですか？
上記のシナリオで、「要求元」とは何ですか？
ほとんどの場合、リクエスト元は「リゾルビング名前サーバー」と呼ばれるものになります。リゾルビング名前サーバーは他のサーバーに問い合わせるように設定されています。基本的にはユーザーのための仲介者であり、以前のクエリ結果をキャッシュして速度を向上させ、既知でないものに対するリクエストを解決するためのルートサーバーのアドレスを知っています。
基本的に、ユーザーはコンピューターシステムにいくつかのリゾルビング名前サーバーを設定しています。リゾルビング名前サーバーは通常、ISPや他の組織によって提供されます。たとえば、Googleは解決DNSサーバーを提供しており、これらはコンピューターに自動的にまたは手動で設定できます。
ブラウザのアドレスバーにURLを入力すると、コンピューターはまず、リソースがどこにあるかをローカルで調べます。コンピューターの「hosts」ファイルやその他のいくつかの場所をチェックします。その後、リクエストをリゾルビング名前サーバーに送信し、リソースのIPアドレスを受信するのを待ちます。
リゾルビング名前サーバーはそのキャッシュをチェックし、答えが見つからない場合は上記の手順を実行します。
リゾルビング名前サーバーは基本的に、エンドユーザー向けのリクエスト処理を圧縮します。クライアントは単に、リソースの場所を尋ねるためにリゾルビング名前サーバーに問い合わせることを知っており、最終的な答えを調査して返すことができます。
ゾーンファイル
上記のプロセスで、「ゾーンファイル」と「レコード」の概念について触れました。
ゾーンファイルは、名前サーバーが知っているドメインに関する情報を格納する方法です。名前サーバーが知っているすべてのドメインは、ゾーンファイルに格納されます。一般的な名前サーバーに寄せられるほとんどのリクエストは、サーバーがゾーンファイルを持っていないものです。
再帰的なクエリを処理するように構成されている場合、リゾルバ名前サーバーのように、答えを見つけて返します。そうでなければ、リクエスト元に次にどこを見るべきかを伝えます。
名前サーバーが持っているゾーンファイルが多いほど、権威を持って回答できるリクエストが増えます。
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
ゾーンの$ORIGINは、デフォルトでゾーンの最高権限に等しいパラメータです。
したがって、ゾーンファイルが「example.com.」ドメインを構成するために使用される場合、$ORIGINはexample.com.に設定されます。
これは、ゾーンファイルの先頭に設定されるか、ゾーンファイルを参照するDNSサーバーの構成ファイルで定義できます。いずれの場合も、このパラメータはゾーンが権威を持つ内容を説明します。
同様に、$TTLは提供される情報の「生存時間」を設定します。基本的にはタイマーです。キャッシュ名前サーバーは、以前にクエリされた結果をTTL値が切れるまで使用して質問に答えることができます。
レコードタイプ
ゾーンファイル内には、さまざまなレコードタイプがあります。ここでは、より一般的な（または必須のタイプ）のいくつかについて説明します。
SOAレコード
スタートオブオーソリティ、またはSOA、レコードはすべてのゾーンファイルで必須のレコードです。これはファイル内で最初の実際のレコードでなければなりません（ただし、$ORIGINや$TTLの仕様は上に現れる場合があります）。また、理解するのが最も複雑なものの1つでもあります。
スタートオブオーソリティレコードは次のようになります。
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
それぞれの部分の説明をします。
-
domain.com.: これはゾーンのルートです。これは、ゾーンファイルがdomain.com.ドメイン用であることを指定します。しばしば、これは@で置き換えられます。これは、上記で学んだ$ORIGIN変数の内容を置換するだけのプレースホルダーです。 -
IN SOA: “IN” の部分はインターネットを意味します（そして多くのレコードに存在します）。 SOA は、これが権威レコードの開始であることを示すインジケーターです。
-
ns1.domain.com.: これはこのドメインのプライマリ名サーバーを定義します。 名前サーバーはプライマリまたはセカンダリのいずれかになります。動的 DNS が構成されている場合、1 台のサーバーはここに「プライマリ」にする必要があります。動的 DNS を構成していない場合、これは単にプライマリ名サーバーの 1 つです。 -
admin.domain.com.: これはこのゾーンの管理者のメールアドレスです。 メールアドレスの「@」はドットで置き換えられます。 メールアドレスの名前部分に通常ドットがある場合、この部分ではそれが「\」に置き換えられます（[email protected]がyour\name.domain.comになります）。 -
12083: これはゾーンファイルのシリアル番号です。 ゾーンファイルを編集するたびに、この番号を増やす必要があります。 セカンダリサーバーは、プライマリサーバーのゾーンのシリアル番号が自分のシステムにある番号より大きいかどうかを確認します。 大きい場合は、新しいゾーンファイルを要求します。 そうでない場合は、元のファイルを提供し続けます。
-
3h: これはゾーンの更新間隔です。 これは、セカンダリがゾーンファイルの変更をポーリングする前に待機する時間です。
-
30分：これはこのゾーンのリトライ間隔です。セカンダリがリフレッシュ期間が終了したときにプライマリに接続できない場合、この時間待機して、プライマリをポーリングし直します。
-
3週間：これは有効期限です。セカンダリ名前サーバーがこの期間プライマリに連絡できなかった場合、このゾーンの権威あるソースとして応答を返さなくなります。
-
1時間：これは、名前サーバーがこのファイルで要求された名前を見つけられない場合に、名前エラーをキャッシュする時間です。
A and AAAA Records
これらのレコードは、ホストをIPアドレスにマッピングします。 “A” レコードはホストをIPv4 IPアドレスにマッピングするために使用され、 “AAAA” レコードはホストをIPv6アドレスにマッピングするために使用されます。
これらのレコードの一般的な形式は次のとおりです：
host IN A IPv4_address
host IN AAAA IPv6_address
したがって、私たちのSOAレコードは、「ns1.domain.com」でプライマリサーバーを呼び出しているので、「ns1.domain.com」はこのファイルが定義している「domain.com」ゾーン内にあるため、これをIPアドレスにマップする必要があります。
レコードは次のようになります：
ns1 IN A 111.222.111.222
完全な名前を指定する必要はありません。FQDNなしでホストのみを指定し、DNSサーバーが残りを$ORIGINの値で埋めます。ただし、意味を持たせたい場合は完全なFQDNを使用することもできます：
ns1.domain.com. IN A 111.222.111.222
ほとんどの場合、ここでウェブサーバーを「www」として定義します：
www IN A 222.222.222.222
基本ドメインがどこに解決されるかも示さなければなりません。これは次のように行うことができます：
domain.com. IN A 222.222.222.222
代わりに「@」を使用して基本ドメインを参照することもできます：
@ IN A 222.222.222.222
明示的に定義されていないこのドメインの下のすべてのものをこのサーバーに解決させるオプションもあります。これはワイルドカード「*」を使用して行うことができます：
* IN A 222.222.222.222
これらすべてはIPv6アドレスのAAAAレコードでも同様に機能します。
CNAMEレコード
CNAMEレコードは、サーバーの正規名（AレコードまたはAAAAレコードで定義されたもの）の別名を定義します。
たとえば、A名レコードを使用して「server1」ホストを定義し、「www」をこのホストのエイリアスとして使用できます：
server1 IN A 111.111.111.111
www IN CNAME server1
これらのエイリアスは追加のサーバークエリを必要とするため、パフォーマンスの低下がありますので、その点にご注意ください。ほとんどの場合、追加のAまたはAAAAレコードを使用して同じ結果を得ることができます。
CNAMEが推奨されるケースの1つは、現在のゾーンの外部リソースのエイリアスを提供する場合です。
MXレコード
MXレコードは、ドメインに使用されるメール交換を定義するために使用されます。これにより、電子メールメッセージが正しくメールサーバーに到着します。
他の多くのレコードタイプとは異なり、メールレコードは通常、ホストを何かにマップしないので、ゾーン全体に適用されます。そのため、通常は次のようになります：
IN MX 10 mail.domain.com.
先頭にホスト名がないことに注意してください。
また、そこに余分な番号があることにも注意してください。これは、複数のメールサーバーが定義されている場合にコンピューターがどのサーバーにメールを送信するかを決定するための優先度番号です。低い番号ほど優先度が高いです。
MXレコードは通常、CNAMEで定義されたホストではなく、AまたはAAAAレコードで定義されたホストを指すべきです。
では、2つのメールサーバーがあるとします。次のようなレコードが必要になります：
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
この例では、「mail1」ホストが優先される電子メール交換サーバーです。
また、次のように書くこともできます：
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
NSレコード
このレコードタイプは、このゾーンで使用される名前サーバーを定義します。
おそらく、「ゾーンファイルが名前サーバーに存在するなら、なぜそれ自体を参照する必要があるのか？」と思っているかもしれません。DNSが非常に成功している理由の一部は、その複数レベルのキャッシングにあります。ゾーンファイル内で名前サーバーを定義する理由の1つは、ゾーンファイルが実際には別の名前サーバー上のキャッシュされたコピーから提供されている場合があるためです。名前サーバー自体で名前サーバーを定義する必要がある他の理由もありますが、ここではそれについては触れません。
MXレコードと同様に、これらはゾーン全体のパラメーターなので、ホストは取りません。一般的には、次のようになります：
IN NS ns1.domain.com.
IN NS ns2.domain.com.
各ゾーンファイルに少なくとも2つの名前サーバーが定義されている必要があります。1つのサーバーに問題がある場合に正常に動作するようにするためです。ほとんどのDNSサーバーソフトウェアは、1つの名前サーバーしかない場合にゾーンファイルを無効と見なします。
いつものように、AレコードまたはAAAAレコードを持つホストのマッピングを含めてください：
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
他にも使用できるレコードタイプはいくつかありますが、おそらくこれらが最も一般的なタイプでしょう。
PTRレコード
PTRレコードは、IPアドレスに関連付けられた名前を定義するために使用されます。PTRレコードは、AレコードまたはAAAAレコードの逆です。PTRレコードは、.arpaルートで始まり、IPアドレスの所有者に委任されるという点でユニークです。地域インターネット登録機関（RIRs）は、IPアドレスの組織とサービスプロバイダーへの委任を管理しています。地域インターネット登録機関には、APNIC、ARIN、RIPE NCC、LACNIC、AFRINICが含まれます。
こちらは、111.222.333.444のPTRレコードの例です：
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
IPv6アドレスのPTRレコードの例では、GoogleのIPv6 DNSサーバー2001:4860:4860::8888の逆のニブル形式が示されています。
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
コマンドラインツールdigを-xフラグとともに使用して、IPアドレスの逆DNS名を検索できます。
以下はdigコマンドの例です。出力を逆DNS名に簡略化するために+shortが追加されています。
上記のdigコマンドの出力は、IPアドレスのPTRレコードにおけるドメイン名になります：
google-public-dns-b.google.com.
インターネット上のサーバーは、PTRレコードを使用してログエントリ内にドメイン名を配置したり、情報を元にスパム処理の決定をしたり、他のデバイスに関する簡単に読み取れる詳細を表示したりします。
ほとんどの一般的に使用される電子メールサーバーは、受信したIPアドレスのPTRレコードを参照します。送信元のIPアドレスにPTRレコードが関連付けられていない場合、送信される電子メールはスパムと見なされて拒否される可能性があります。PTRのFQDNが送信される電子メールのドメイン名と一致している必要はありません。重要なのは、対応するかつ一致する正しいPTRレコードがあることです。
通常、インターネット上のネットワークルーターには、物理的な場所に対応するPTRレコードが与えられます。たとえば、ニューヨーク市やシカゴのルーターには「NYC」や「CHI」などの参照が表示されることがあります。これは、tracerouteやMTRを実行し、インターネットトラフィックの経路を確認する際に役立ちます。tracerouteまたはMTRを実行し、インターネットトラフィックの経路を確認する際に役立ちます。
専用サーバーやVPSサービスを提供するほとんどのプロバイダーは、顧客がIPアドレスのPTRレコードを設定できる機能を提供しています。DigitalOceanは、Dropletがドメイン名で名前を付けられている場合、DropletのPTRレコードを自動的に割り当てます。 Dropletの名前は作成時に割り当てられ、後でDropletの制御パネルの設定ページを使用して編集できます。
注意: PTRレコードのFQDNには、対応するかつ一致する正しい正引きAレコードがあることが重要です。例：111.222.333.444のPTRがserver.example.comであり、server.example.comが111.222.333.444を指すAレコードである場合。
CAAレコード
CAAレコードは、SSL/TLS証明書をドメインに発行することを許可する証明機関（CA）を指定するために使用されます。2017年9月8日以降、すべてのCAは証明書を発行する前にこれらのレコードを確認する必要があります。レコードが存在しない場合、どのCAでも証明書を発行できます。それ以外の場合、指定されたCAのみが証明書を発行できます。CAAレコードは、単一のホストまたは全体のドメインに適用できます。
以下は、CAAレコードの例です：
example.com. IN CAA 0 issue "letsencrypt.org"
ホスト、IN、レコードタイプ（CAA）は共通のDNSフィールドです。CAA固有の情報は、0 issue "letsencrypt.org" の部分です。これは3つの部分で構成されています：フラグ（0）、タグ（issue）、値（"letsencrypt.org"）。
- フラグは、CAが理解しないタグの処理方法を示す整数です。フラグが
0の場合、レコードは無視されます。1の場合、CAは証明書の発行を拒否する必要があります。 - タグは、CAAレコードの目的を示す文字列です。現在、
issueは特定のホスト名のためにCAに証明書を作成するための認可を、issuewildはワイルドカード証明書の認可を、iodefはCAがポリシー違反を報告するURLを定義するために使用できます。 - 値は、レコードのタグに関連付けられた文字列です。
issueおよびissuewildの場合、これは通常、許可を付与するCAのドメインになります。iodefの場合、これは連絡フォームのURLまたはメールフィードバック用のmailto:リンクの場合があります。
CAAレコードを取得するためにdigを使用できます。次のオプションがあります。
CAAレコードの詳細については、RFC 6844または当社のチュートリアルDigitalOcean DNSを使用してCAAレコードを作成および管理する方法
結論
DNSの仕組みがかなりわかるようになったはずです。 一般的なアイデアは、戦略に慣れると比較的簡単に理解できますが、これは未経験の管理者にとって実践するのが難しいことがあります。
概要については、DigitalOceanコントロールパネル内でドメインを設定する方法を確認してください。