導入 — DNS は何をしているか
DNS を「名前 + 型」の問い合わせと、役割分担の連鎖として捉える。
DNS は「名前を IP に変える」だけではない
DNS の代表例は www.example.com のような名前を IP アドレスへ引くことです。ただし、その理解だけで終わらせると実務で困ります。DNS はもっと広く、「この名前について、どんな型の情報を、誰が正規に持っているかを問い合わせる分散データベース」です。
たとえば Web なら A / AAAA、メール配送なら MX、所有確認なら TXT を引きます。つまり DNS は 名前 と 問いの種類 をセットで扱います。
www.example.com小問 1-1 — まずは『名前 + 型』で考える
DNS の問いが何で構成されているかを確認します。
Q1. ブラウザが www.example.com の IPv4 アドレスを知りたいとき、DNS の問いとして最も正しい組み合わせはどれですか。
A レコードは名前に対応する IPv4 を返します。DNS では『どの名前について』『どの型を知りたいか』をセットで指定します。
Q2. ある名前について A と AAAA の両方を確認したいとき、最低何種類の問い合わせ型が必要ですか。
A と AAAA は別々の RR type なので、両方を見たいなら最低 2 種類の問いが必要です。
まず区別したい 4 人の登場人物
| 登場人物 | 何をするか | ここでの見方 |
|---|---|---|
| ブラウザ / アプリ | URL やホスト名を使いたい側 | 通常は自分で root まで辿らない |
| OS のスタブリゾルバ | アプリからの問い合わせの入口 | 近くの再帰リゾルバへ依頼することが多い |
| 再帰リゾルバ | 利用者の代わりに最終答えを集めて返す | キャッシュがあるので、利用者からは『答えの出どころ』に見える |
| 権威サーバ | あるゾーンの正規データを持つ | 担当範囲外は referral で次の行き先を案内する |
この講座では、返ってきた答えを見るたびに『いま誰が返しているか』を確認します。
小問 1-2 — 誰がどこまで知っているか
役割分担を取り違えると、dig の出力や TTL の意味が読みにくくなります。
Q3. 利用者の代わりに root / TLD / 権威サーバを辿って最終答えを集める役割はどれですか。
再帰リゾルバは、利用者に代わって root → TLD → 権威サーバと辿り、得た結果を TTL の間キャッシュしながら最終答えを返します。
Q4. この章の説明に照らして、DNS で引ける情報としてあてはまらないものはどれですか。
DNS では A / AAAA / MX / TXT など多様な情報を引けます。一方で TLS 通信の本文や暗号化されたペイロードは DNS の守備範囲ではありません。
Q5. 返ってきた DNS 応答を見たとき、最初に意識すると理解が進みやすい軸はどれですか。
DNS の理解で大切なのは、『その答えは権威データか、キャッシュか、referral か』を見分けることです。UI より先に、誰が正規の答えを持つかを見ます。
なぜ hosts ファイルだけでは足りないのか
ここでいう hosts ファイル とは、OS が持つ「名前 ↔ IP」の静的な対応表（たとえば Linux / macOS の /etc/hosts、Windows の C:\Windows\System32\drivers\etc\hosts）のことです。もしすべての名前と IP の対応が固定で、全マシンに同じ表を配って済むなら DNS は不要です。ですが実際には、IP は変わり、メール配送先や所有確認トークンなど IP 以外の情報も引きたくなります。
さらに、組織ごとに自分の名前空間を管理したいので、中央の巨大な静的テーブル より、権限ごとに分けて管理し、必要なときに問い合わせるほうが自然です。
この章の視点: 「DNS サーバが答えを返した」という理解で思考を止めず、その答えは権威データか / キャッシュか / referral か を必ず意識してください。
この章で持ち帰ること
- DNS は『名前 + 型』への問い合わせとして見ると整理しやすい
- 利用者・スタブ・再帰リゾルバ・権威サーバの役割は違う
- 以後の章では、誰が正規の答えを持っているか を軸に進める