DNS
Domain Name System
「IP アドレス」と「ドメイン名」を変換（名前解決）するための仕組み。
IP アドレスやドメイン名は、ネットワーク上に存在するリソースを識別するため識別子としての役割を持つ。
また DNS は 分散型システム である。中央集権型ではないため、1 台のサーバが故障しても別のサーバによってシステム全体が稼働し続ける。
DNS の目的は ドメイン名 と IPアドレス の変換
IP アドレス
ネットワーク上のデータ配達プロトコル（IP）において、住所として使用される情報。
1 台のコンピュータが用途別に複数の IP アドレスを持つこともある。
ネットワーク上の住所としては重複が許されない一方で、IPv4（version 4）では 32bit、IPv6（version 6）では 128 bit と決まっていて、発行可能な数に限りがある。以降の説明ではIPv4を扱う。
IPv4 では、割り当てることができるアドレスの数が 43 億個程度であり、世界中でネットワークに接続する機器が爆発的に増えたことで枯渇問題が発生し、128 bitのサイズの IP アドレス IPv6 が登場した。
IPv4 と IPv6 には互換性がない。
現在は、IPv6 に移行する過程にあり、さまざまな工夫のもとで両者が共存している状態にある。
IPv4 アドレスを 2 進数で表現すると、以下のようになる。
11000110 00110011 01100100 00000001
ただこれでは扱いづらいため、一般的には 10 進数を用いて、さらに 8 bit ごとにドットで区切って表現される。
198.51.100.1
ネットワークアドレス
IP アドレスは ネットワーク部 と ホスト部 から構成される。
ホスト部を全て 0 で表現した IP アドレスを ネットワークアドレス と言う。
ネットワークアドレスは、スイッチングハブやルータによって分割されたセグメント自体を表現することができる。
ホスト名
ネットワーク上の機器（またはサービス）を識別するための名前。
慣習的に Web サーバには www、DNS サーバには ns（Name Server）、メールサーバにはmx（Mail Exchanger） などのホスト名が使われる。
例えば example.co.jp（ドメイン名）を運用するサーバが Web サーバとメールサーバの2つのサービスを提供する場合、www と mx という別々のホスト名を利用して www.example.co.jp なのか、mx.example.co.jp なのかで両者のサービスを区別できるすることができる（ドメイン名部分は同じ）。
また www.co.jp、www.co.us などのように異なるドメイン間で同じホスト名が利用できるのもメリットとして挙げられる。
ドメイン名
ネットワーク上で、特定の組織、ネットワーク、個人を識別するための識別子（例：www.example.com、example.com、com）。
DNS によって、ドメイン名は特定の IP アドレスと紐づいているため、「IP アドレスの別名」と説明されることもある。
ドメインは名前空間上に 階層構造 を持っていて、全体としては .（ルートドメイン）を頂点としたツリー構造を持つ。
- ルートドメイン
.
- トップレベルドメイン（TLD：Top Level Domain）
-
jp、us、com（Commercial）、org（Organization）など
-
- セカンドレベルドメイン（SLD：Second Level Domain）
-
co.jp、or.jp、go.jp（Government）、ne.jp、ac.jp（Academic）
-
- ...
FQDN
Full Qualified Domain Name
ルートドメイン（.）まで完全に記述したドメイン名（例：www.example.co.jp.）。
完全修飾ドメイン名とも呼ばれる。
FQDN は DNS によって特定の IP アドレスと紐づけられている ため、DNS に対して FQDN で問い合わせをすれば、紐づく IP アドレスが回答される。
正確には DNS は「FQDN」と「IP アドレス」を変換する。
DNS は FQDN と IP アドレスを変換している
ネームサーバ
ドメイン名、IP アドレスの対応情報を管理するサーバは DNS サーバ または ネームサーバ と呼ばれる。
ルート DNS サーバ
ルートドメイン（.）を管理するサーバは ルート DNS サーバ と呼ばれる。
キャッシュ DNS サーバが一番最初に問い合わせを行うコンテンツサーバ（権威サーバ）。
ゾーン
ネームサーバは複数のドメイン名を管理することかできる。
一つのネームサーバが管理する複数のドメイン名を ドメイン領域 と呼び、これをゾーンと言う。
リゾルバ
DNS サーバに対して、IP アドレスの問い合わせを行うクライアント側のソフトウェアを リゾルバ という。
通常リゾルバは OS に標準で搭載されているため、開発者がソフトウェアとしてインストールしたり直接操作したりとリゾルバを意識する機会はあまりない。
Linux では BIND と呼ばれるサーバソフトウェアが広く利用されている。
プライマリ DNS サーバ / セカンダリ DNS サーバ
DNS サーバは可用性を高めることを目的として通常は 2 台以上設置される。
通常時に機能するものは プライマリ DNS サーバ、異常発生時などにバックアップとして機能するものは セカンダリ DNS サーバ と呼ばれる。
ゾーン転送
DNS サーバが保持する設定ファイルを ゾーンファイル と呼ぶため、プライマリ DNS サーバからセカンダリ DNS サーバへの同期は ゾーン転送 と呼ばれる。
コンテンツ DNS サーバ / キャッシュ DNS サーバ
DNS サーバには コンテンツ DNS サーバ と キャッシュ DNS サーバ がある。
コンテンツ DNS サーバは 権威 DNS サーバ とも呼ばれる。
コンテンツ DNS サーバは自身で FQDN と IP アドレスの紐付け情報（ゾーンファイル）を管理する。
一方、キャッシュ DNS サーバは、コンテンツ DNS サーバに対して問い合わせた結果を一時的にキャッシュとして保管する。キャッシュは一定時間（TTL：Time To Live。単位は秒数。）が経過すると削除される。
キャッシュ DNS サーバを使用することによって、同じ問い合わせを都度、権威サーバに問い合わせないので、高速回答が可能となる。
キャッシュ DNS サーバは、自身がキャッシュを保持していない情報についてはクライアントに代わって権威サーバに問い合わせをすることから フルサービスリゾルバ とも呼ばれる。
権威 DNS サーバは自身が知らない情報は「知らない」としか回答しないのに対して、フルサービスリゾルバは、自身が知らない情報を他の権威 DNS サーバに問い合わせて解決してくれる。
この挙動は 再帰問い合わせ（recursive query）と呼ばれる。
権威 DNS サーバは、自身が管理するゾーン内の情報だけではなく下位の権威 DNS サーバの情報など、他のゾーンに関する情報も保持していて、問い合わせを受けた FQDN に対応する IP アドレスを回答することはできないが、IP アドレスを知っていそうな他の権威サーバを回答することはできる。
例えば www.example.co.jp. という FQDN に対する問い合わせをリゾルバが名前解決しようと試みているとする。
この時リゾルバは、自身の端末に設定された DNS サーバ（キャッシュ DNS サーバ）に問い合わせを行う。
【リゾルバ】
「www.example.co.jp.のIPアドレスを教えて」
フルサービスリゾルバは、www.example.co.jp.のIPアドレスを保持していない時、まずルートDNSサーバに問い合わせを行う。
【フルサービスリゾルバ】
「www.example.co.jp.のIPアドレスを教えて」
ルート DNS サーバは www.example.co.jp. の IP アドレスを知らない。ただし、jp ドメインを管理している下位の権威サーバは知っている。そこで、TLD である jp を管理する権威 DNS サーバの IP アドレスを回答する。
【ルートDNSサーバ】
「私は www.example.co.jp. を知らないから jp の権威サーバに聞いてください」
フルサービスリゾルバは jp を管理する権威 DNS サーバに対して、ルート DNS への問い合わせと同じ問い合わせを行う。これを反復問い合わせ、再帰問い合わせと呼ぶ。
【フルサービスリゾルバ】
「www.example.co.jp. の IP アドレスを教えて」
www.example.co.jp は jp のゾーンでもないため、jp も IP アドレスを知らない。そこで jp の権威 DNS サーバは、下位の co.jp を管理する権威 DNS サーバの IP アドレスを回答する。
【DNS サーバ（jp）】
「私は www.example.co.jp. を知らないから co.jp の権威サーバに聞いてください」
フルサービスリゾルバは co.jp を管理する権威 DNS サーバの IP アドレスに再度、反復問い合わせを行う。
【フルサービスリゾルバ】
「www.example.co.jp. の IP アドレスを教えて」
しかし、co.jp を管理する権威 DNS サーバのゾーンにも www.example.co.jp. は含まれていないため、さらに下位の example.co.jp の権威 DNS サーバの IP アドレスが回答される。
【DNS サーバ（co.jp）】
「私は www.example.co.jp. を知らないから example.co.jp に聞いてください」
フルサービスリゾルバは、example.co.jp を管理する権威 DNS サーバに対して、再度問い合わせを行う。
【フルサービスリゾルバ】
「www.example.co.jp. の IP アドレスを教えて」
www.example.co.jp. は example.co.jp を管理する権威 DNS サーバのゾーン範囲内になるため、ここでようやく www.example.co.jp. に紐づく IP アドレスが回答される。
【DNS サーバ（example.co.jp）】
「www.example.co.jp. の IP アドレスは 198.51.100.1 です」
これらの流れの中で権威 DNS サーバは自身のゾーン内のドメインに紐づく IP アドレスのみではなく、下位の権威 DNS サーバの IP アドレスも保持していて、ゾーン同士が連携しているように見える点がポイント。
コンテンツ DNS サーバ ＝ 権威サーバ
キャッシュ DNS サーバ ＝ フルサービスリゾルバ
ゾーンファイル
権威サーバが「権威を持つドメイン」について、回答するための保持する情報（リソースレコード）が記述されたファイル。
ゾーンファイルにはリソースレコードの他に $ORIGIN ディレクティブ、$TTL ディレクティブなどが含まれている。
$ORIGIN：ドメイン名が明示されていないレコードのドメイン名を補完する。
$TTL：ゾーン情報をキャッシュ保持時間（秒数）。記述した行以降のレコードに適用される。
リソースレコード
DNS は IP アドレスとドメイン名を変換する役割を持つが、実態としては複数のサーバによって構成される分散型のシステムであり大量のドメイン名・IP アドレス情報を管理する分散型データベースとみなすこともできる。
DNS サーバには権威 DNS サーバとフルサービスリゾルバの２種類があり、権威 DNS サーバはフルサービスリゾルバからの問い合わせを自身の管理する情報から回答する。
このとき、それぞれの権威 DNS サーバで管理されている情報は リソースレコード と呼ばれる。
リソースレコードは、DNSサーバの設定ファイル（ゾーンファイル）などに記載される。リソースレコードにはいくつかの種類がある。
リソースレコード中の @ は自身のドメインを表す。
ドメイン名を記載する際は必ず FQDN で記載する。つまり末尾の . を忘れないようにする。. を付与しない場合、意図していなくても $ORIGIN のドメイン名が末尾に自動補完されてしまう。
; の後ろはコメント扱いになる。
A レコード
Address Record
ホスト名に対応する IPv4 アドレス。
ホスト名 IN A IPアドレス
www IN A 198.51.100.0
上記は www というホスト名が IPv4 アドレス 198.51.100.0 であることを示す。
AAAA レコード
IPv6 Address Record
ホスト名に対応する IPv6 アドレス。
ホスト名 IN AAAA IPアドレス
www IN AAAA 2001:db8::1
上記は www というホストが IPv6 アドレス 2001:db8::1 であることを示す。
CNAME レコード
Canonical Name Record、canonical=標準的、正規の
ホスト名（FQDN）にエイリアス（別名）を指定することで、1 つのホスト名に複数のドメイン名を紐づけることができる。
エイリアス名 IN CNAME 正規のドメイン名(FQDN)
www.example.com. IN CNAME example.com.
上記は www.example.com. への問い合わせは example.com. へ転送されるということを示している。この場合、正規名 examole.com. は A レコード を持っている必要がある。
CNAME レコードで設定した「エイリアス」は、挙動としては問い合わせを別の FQDN へ転送するだけなので、「エイリアス」に対して他のレコードを設定してはいけない。
例えば、正規名ではなく、「エイリアス」に対して A レコードを設定したり、「エイリアス」に対して MX レコードを設定することは RFC（Request for Comments）で禁止されている。
MX レコード
Mail Exchanger Record
メール送信において、メールサーバが参照するレコード。そのゾーンのメールサーバを指定する。
宛先メールアドレスのドメインと紐づくメールサーバおよび優先度を指定する。優先度は小さいものほど優先される。
ドメイン名 IN MX 優先度 メールサーバのFQDN
example.com. IN MX 10 mail.example.com.
上記は example.com ドメイン宛のメールは、優先度 10 の mail.example.com. サーバに転送されることを示している。
NS レコード
Name Server Record
そのゾーンを管理する権威サーバ。
ドメイン名 IN NS 権威サーバのFQDN
example.com. IN NS ns1.otherdns.com.
example.com. IN NS ns2.otherdns.com.
上記は example.com の下位には ns1.otherdns.com.、ns2.otherdns.com. という権威サーバがいることを示している。権威サーバの IP アドレスは別途 A レコード （もしくは AAAA レコード）で保持される。
PTR レコード
Pointer Record
逆引きルックアップのために使用される。IPアドレスからホスト名への逆引き情報を提供する。
逆引き用のIPアドレス IN PTR 対応するFQDN
192.0.2.10 に対応する FQDN host1.example.com を記述する場合、以下のようにする。
10.2.0.192.in-addr.arpa. IN PTR host1.example.com.
IPv6 アドレス（2001:db8::1）の場合、以下のようにする。
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR host1.example.com.
SOA レコード
Start Of Authority Record
その DNS サーバが管理する領域(ゾーン)に関する情報。
ゾーンの身分証明書的な役割を果たす。
ゾーン名 IN SOA 権威DNS名 管理者メールアドレス (
シリアル番号;
リフレッシュ間隔;
リトライ間隔;
有効期限;
最小TTL;
)
| 設定値 | 意味 |
|---|---|
ゾーン名 |
ゾーンの名前。通常は @ で省略される。@ で省略された場合、/etc/named.conf の zone ステートメントで定義したゾーン名に置き換わる。 |
IN |
クラス名を記載するが、通常 Internet クラス（IN）。 |
権威DNS名 |
権威 DNS サーバのホスト名（FQDN）。 |
管理者メールアドレス |
管理者のメールアドレス。 リソースレコード中の @ は自身のドメインを表す特殊記号のため、メールアドレスの @ の代わりに . を使う点に注意。例: admin@example.com → admin.example.com.
|
シリアル番号 |
ゾーンファイルの更新を表す番号。 セカンダリサーバがプライマリサーバから ゾーン転送 の際に比較される。 日付 + 連番 の YYYYMMDDnn がよく利用される。 |
リフレッシュ間隔 |
セカンダリサーバがプライマリサーバにゾーンファイルの更新有無を問い合わせる間隔（秒）。 |
リトライ間隔 |
セカンダリサーバがプライマリサーバに接続できなかった場合、再試行するまでの間隔（秒）。 |
有効期限 |
セカンダリサーバがプライマリサーバに接続できなかったとき、キャッシュを破棄するまでの最大時間（秒）。 |
最小TTL |
ネガティブキャッシュ（「そのドメインに紐づく IP アドレスは存在しない」という問い合わせに対する応答のキャッシュ）の保持時間。 |
@ IN SOA ns1.example.com. admin.example.com. (
2024041301 ; シリアル番号
3600 ; リフレッシュ間隔
600 ; リトライ間隔
604800 ; 有効期限
86400 ; 最小TTL
)
上記は自身のドメイン（example.com.）は ns1.example.com. が権威サーバであり、admin.example.com. が管理者メールであることを表している。
DNS ラウンドロビン
複数の DNS サーバが同じドメイン名を共有し、各 DNS サーバに対して負荷を分散するための仕組み。
例えば１台の DNS サーバの A レコードに対して、X と Yの２台分の DNS サーバの IP アドレスを設定しておくと、１回目の問い合わせは X に、２回目の問い合わせは Y に、といった具合に、処理を分散させることができる。
ロードバランサーなどの負荷分散装置を使用せずに、容易に負荷分散が実現できる反面、問い合わせを割り振る際に、割り振り先の処理能力（スペック）や、負荷状況を考慮することはできない。
仮想ホスト
1台のサーバで仮想的に複数のドメイン名を運用すること。サーバソフトウェアの機能として提供され、主にメールサーバ、Web サーバで利用される。
1台のサーバで運用されるドメイン名に、異なるホスト名をつけることを仮想ホストと言う事もある。
IPアドレスベースの仮想ホスト
ドメインごとに IP アドレスを設定する方式。1 台のサーバが複数の IP アドレスを持つことになる。
ドメイン名ベースの仮想ホスト
1つの IP アドレスに複数のドメイン名、ホスト名を割り当てることで、1台のサーバがそれぞれのドメインに紐づく複数のサービスを提供する。
参考
・ネスペの基礎力 -プラス20点の午後対策 (情報処理技術者試験)
・ストーリーで学ぶネットワークの基本
・ネットワークスペシャリスト試験に出るところだけを厳選! 左門至峰による ネスペ教科書 改訂第2版