DNS用語整理

DNS周辺ででてくる用語を整理してみます。
前段は「インターネット」に直接は限らない用語、後段に「インターネット」におけるDNSで使われる用語をまとめてあります。

※なおあくまで書いた時点での自分の理解ですので、間違いがある可能性があります。ご指摘いただけると幸いです。

随時、追加・修正します。

最終更新日

2014.04.28.

役割の名称

DNSはクライアント/サーバモデルでできている名前解決の仕組みです。
問い合わせ（クエリ)を送るクライアントと、回答を送るサーバがあります。

コンテンツサーバ

ゾーン（後述）についての情報を保持しているサーバ（DBサーバ）。
問い合わせに対し、その問い合わせに対応する情報を保有している場合その保有している情報を回答する。
問い合わせ自体の回答の他に、関連する情報を返すこともある。

キャッシュサーバ

キャッシュサーバ自体にゾーンについての情報を持っておらず、コンテンツサーバに問い合わせ得た回答をしばらく保持（キャッシュ）している。
キャッシュされている情報に当てはまる問い合わせがあった際はコンテンツサーバに再問い合わせせずにキャッシュから回答を返す。
キャッシュされている情報に当てはまる問い合わせがない場合は、リゾルバとして名前解決（多くの場合後述の「反復問い合わせ」）を行い後述の「再帰問い合わせ」を行う。
コンテンツサーバへの負荷軽減やパフォーマンスの改善を目的にしている。
コンテンツサーバ側で指定したTTLを上限にキャッシュすることを許されている。

リゾルバ（DNSクライアント）

問い合わせ（クエリ)を送る側。
OSレベルでの機能でもあるが、アプリケーションレベル（ブラウザなど）での個別に実装されている場合もある。
下記のスタブリゾルバ、フル（サービス)リゾルバがある。

スタブリゾルバ

指定されたコンテンツサーバ/キャッシュサーバに対して問い合わせを送りその回答を得るだけのリゾルバ。
さらにキャッシュしてそのキャッシュを利用する場合もある。
多くの場合、後述の「キャッシュサーバ」に対して問い合わせをする。
Windows の設定でいう「DNSサーバ」、Linux系の /etc/resolv.conf などはOSレベルのリゾルバが問い合わせる先として利用される。
dig や nslookup はスタブリゾルバと言える。

フル（サービス）リゾルバ

スタブリゾルバの機能に後述の反復問い合わせを含む名前解決を行えるリゾルバ。

リゾルバの問い合わせ方法

反復問い合わせ（検索）

問い合わせた名前の解決にあたり、ルートサーバから順に問い合わせていき、委任をたどりながら問い合わせた名前にたどり着くまで検索する問い合わせ方法。
フルリゾルバで行う検索方法。

再帰問い合わせ（検索）

キャッシュサーバのように問い合わせを行ったリゾルバの代わりに反復問い合わせを行い、最終的に得た結果を問い合わせを行ったリゾルバに返す問い合わせ方法。

「ドメイン（という用語)」に関わる用語

参考） JPNIC ドメイン名のしくみ: https://www.nic.ad.jp/ja/dom/system.html
※ただし、例えば「名前解決の流れ」の画像内に「co.jpのネームサーバ」が存在する（実際はない）など、不正確な部分があるようです。用語や構造・経緯・歴史などのレベルの参考としてご覧ください。

ドメイン

複数のリソース（ホスト名など）をグループ化して捉えたもの。
本来は「領域」「一括り」程度の意味。よく見かける example.co.jp などは「ドメイン名」。
同じドメイン名でつけられたホスト名同士を「同一ドメインのホスト」などという。
参照） ドメイン

ドメイン名

ドメインに対してつけた名前。階層的につけられており、各階層の区切りは「 . （ドット）」で表す。
階層の最上位は「（長さ0の文字列）」で表され「ルート」などと呼ばれる。

スーパードメイン（親ドメイン）

あるドメイン名の1つ上の階層のドメイン。

サブドメイン（子ドメイン）

あるドメイン名の1つ下の階層のドメイン。
ドメインは任意にサブドメインを作ることができ、そのサブドメインの管理を別のコンテンツサーバに委任することができる（委任するかしないかは任意)。

ルートドメイン

ドメインの階層の最上位。ドメイン名は長さ0の文字列。¹

TLD（Top Level Domain）

ルート直下のドメイン。例えば example.co.jp の jp にあたるドメイン。
以降、 2nd Level Domain 、 3rd Level Domain、と続く。

FQDN（Fully Qualified Domain Name：完全修飾ドメイン名）

あるドメイン内のリソースをTLDまで記載したもの。
例） example.co.jp ドメイン内のホスト host1 のFQDNは host1.example.co.jp（もしくは host1.example.co.jp.） となる。

ネームサーバ

あるゾーンについてのコンテンツサーバ。
必ずしも1台である必要はないが、すべてで情報が一致していない場合は異常。

ルートサーバ

ルートドメインのネームサーバ

ゾーン

あるネームサーバが管理するドメイン。
委任ごとに分割したドメインのグループ。
※「ドメイン」はサブドメインはスーパードメインに包含される関係（example.co.jpはco.jpドメインでもある）だが、ゾーンは重なり合わない。
参照） ゾーン

委任（委譲)

あるドメイン名についての情報管理（ネームサーバ）を別のコンテンツサーバに任せること。
これによりゾーンが分割される。

権威サーバ（authoritative name server）

あるドメイン名について、ルートサーバから階層連鎖的に委任を受けているネームサーバをそのゾーンに対する権威を持っている、権威サーバである、という。
参考） JPNIC 権威DNSサーバ(authoritative name server)とは https://www.nic.ad.jp/ja/basics/terms/authoritative-nameserver.html
※ただし、「権威ネームサーバやコンテンツサーバとも呼ばれます」と書かれているが、実際は権威がなくともコンテンツサーバではあることはできるなど、気にかかる表現はある。

リソースレコード（RR）

コンテンツサーバに登録するデータの1つ1つ。
あるリソースに対して、その名前（ラベル）、リソースの種類（RR Type²）、データを登録する。

実際はBIND用語だと思うDNS周辺用語

マスター/スレイブ

BINDでは複数のコンテンツサーバを利用する場合に、MySQLなどのDBのレプリケーションのような仕組みを利用してゾーン情報の書き換えを1つで済ませるようにすることができる。
その際の修正対象とする1台を「マスター」、マスターからゾーン情報を取得する側のコンテンツサーバを「スレイブ」という。

ゾーン転送

マスターからスレイブにゾーン情報を転送すること。
実際の動作は、
1. マスターで修正したゾーン情報を有効にすると、マスターでゾーン情報に登録されているスレイブに対し通知（notify）を送る。
2. notifyを受信したスレイブはマスターに問い合わせ（AXFR）、ゾーンの全情報を回答として得る。
というように動作する。

プロトコル周りの用語

EDNS0

JPNIC EDNS0とは: https://www.nic.ad.jp/ja/basics/terms/edns0.html

TCPフォールバック

UDPでの通信³で何らかの理由で失敗した場合に、TCPを使って再度問い合わせること。

「インターネット」で出てくる用語

「インターネット」で利用できるドメイン名は ICANN が管理している。

root-servers

インターネットにおけるルートサーバ。ICANNが
TLDのネームサーバについての情報（NSレコードとそのグルー）を保持している。
[a～m].root-servers.net. として公開されている。⁴, ⁵

レジストリ

それぞれのTLDのネームサーバ（権威サーバ)の管理・運用を行っている事業者（例えば jp はJPNIC・JPRS:この辺の関係は理解できていない）。

レジストラ（JPNIC/JPRSでは指定事業者）

TLDのネームサーバへのレコード（実質はドメイン名のNSレコードとそのグルー）の登録・編集・削除を委託されている事業者。