導入 — DNS は何に答えているか
DNS を「名前 + 型」への問い合わせに答える分散データベースとして捉え、4 つの登場人物の役割分担をつかむ。
「サーバは動いているのに、つながらない」
Web サイトの移転直後に一部のユーザーだけ旧サーバへ飛び続ける。新しく作ったサブドメインが「存在しない」と言われる。メールだけが届かない。— こうした不調の多くは、アプリでもネットワーク機器でもなく、名前解決のどこかで起きています。
DNS の代表的な説明は「www.example.com のような名前を IP アドレスに変換する仕組み」ですが、その理解だけで止まると上のようなトラブルで手が出ません。DNS はもっと広く、「この名前について、どんな型の情報を知りたいか」という問いに答える分散データベースです。
Web の行き先を知りたければ A / AAAA、メールの配送先なら MX、ドメインの所有確認なら TXT。つまり DNS への問いは、つねに名前と型のセットでできています。
www.example.com — どのドメイン名について聞くか小問 1-1 — 問いを『名前 + 型』で組み立てる
DNS への問い合わせが何で構成されているかを、手を動かして確認します。
Q1. ブラウザが www.example.com の IPv4 アドレスを知りたいとき、DNS への問いとして正しい組み合わせはどれですか。
DNS への問いは「どの名前について」「どの型の情報を知りたいか」のセットです。IPv4 アドレスを知りたいなら、名前 www.example.com に型 A を組み合わせます。IP アドレスは答えとして返る側であって、問いの側に置くものではありません。
Q2. ある名前について IPv4（A）と IPv6（AAAA）の両方を確認したいとき、最低何種類の問い合わせ型が必要ですか。
A と AAAA は別のレコード型です。同じ名前でも、型が違えば別の問いになります。「名前 + 型」で 1 つの問い、という感覚をここでつかんでください。
まず区別したい 4 人の登場人物
名前解決には役割の違う 4 人が関わります。ここで押さえたいのは 1 点だけ — 利用者が話している相手と、正解を持っている相手は別だということです。
| 登場人物 | 何をするか | ここでの見方 |
|---|---|---|
| ブラウザ / アプリ | 名前を使いたい側。名前解決を依頼する | 自分で root まで辿ることは通常ない |
| OS のスタブリゾルバ | アプリからの問い合わせの窓口 | ほとんどの場合、近くの再帰リゾルバへ転送するだけ |
| 再帰リゾルバ | 利用者の代わりに答えを集めて返す。結果をキャッシュする | 利用者からは「答えの出どころ」に見えるが、実際は代理人 |
| 権威サーバ | 担当ゾーンの正規データを持ち、その範囲だけ答える | 担当外のことは「次の行き先」を案内する（referral） |
「DNS サーバ」という言葉は再帰リゾルバと権威サーバのどちらも指しうるため、実務の会話では混乱のもとになります。この講座では必ず区別して呼びます。
利用者に見えているのは再帰リゾルバまで。その先の旅（root → TLD → 権威）は再帰リゾルバが代行します。以降の章では、返ってきた答えを見るたびに「いま誰が返しているか」を確認します。
小問 1-2 — 誰がどこまで知っているか
登場人物の役割を取り違えると、以降の章すべてが読みにくくなります。ここで固めておきましょう。
Q3. 利用者の代わりに root / TLD / 権威サーバを順に辿り、最終的な答えを集めてくる役割はどれですか。
再帰リゾルバは利用者に代わって root → TLD → 権威サーバと辿り、集めた結果を TTL のあいだキャッシュしながら返します。ブラウザやスタブリゾルバは依頼する側、権威サーバは自分の担当分だけを答える側です。
Q4. この章の説明に照らして、DNS で引ける情報としてあてはまらないものはどれですか。
DNS は A / AAAA / MX / TXT など多様な型のデータを引ける分散データベースです。一方で、通信の中身（TLS で暗号化されたペイロードなど）を運ぶのは DNS の仕事ではありません。
Q5. 再帰リゾルバから答えが返ってきました。この答えについて正しく言えるものはどれですか。
再帰リゾルバは一度得た答えを TTL のあいだキャッシュし、期限内は権威サーバに聞き直さずそのまま返します。つまり利用者に届いた答えは「いま権威が言ったこと」とは限りません。この区別が、第 5 章のキャッシュとTTL、そして実務のトラブルシュートの土台になります。
hosts ファイルと比べると、DNS の設計が見える
OS には hosts ファイルという「名前 ↔ IP」の静的な対応表があります（Linux / macOS の /etc/hosts、Windows の C:\Windows\System32\drivers\etc\hosts）。もし世界中の名前と IP の対応が固定で、全マシンに同じ表を配って済むなら、DNS は要りません。実際そうなっていないのは、次の 3 つの要求があるからです。
- 値は変わる — サーバ移転や負荷分散で IP は変わります。静的な表では追いつけません。
- IP 以外も引きたい — メール配送先、所有確認トークンなど、「名前に紐づく情報」は IP だけではありません。
- 管理は分けたい — 各組織が自分の名前空間を自分で管理したい。中央の巨大な一枚表では回りません。
この 3 つに答えるのが、DNS の設計です。データを型で区別し、管理をゾーン単位で分け（第 2 章）、変化に追従しながらもキャッシュで速さを保つ（第 5 章）。この講座の残りの章は、この設計を 1 つずつ分解していきます。
この講座の合言葉: 答えが返ってきたら、そこで思考を止めずに問いかけてください — この答えは、権威データか？ キャッシュか？ それとも「次はあちらへ」という案内（referral）か？
この章で持ち帰ること
- DNS への問いは「名前 + 型」のセット。名前 → IP は数ある型のひとつにすぎない
- 利用者・スタブ・再帰リゾルバ・権威サーバは役割が違う。話す相手と正解の持ち主は別
- 再帰リゾルバの答えはキャッシュかもしれない。「誰が正規の答えを持つか」を軸に次章へ進む