「ドメイン名からIPアドレスを調べる」——この名前解決には、役割の違う3人の登場人物と、2種類の問合せが出てきます。ここを登場人物で押さえると、穴埋め設問で「誰に・何を聞くか」を取り違えなくなります。
つまずきポイント
「DNSサーバに聞けばIPが返ってくる」——ざっくりはその通りですが、聞かれた1台がすべて知っているわけではありません。自社側で問合せを代行するサーバと、そのドメインの正解を持つサーバは別物です。
登場人物と流れ
1端末はまず自社のリゾルバに丸投げ
PCスタブリゾルバ（頼む側）
↓再帰的クエリ「答えまで調べて持ってきて」
自社の外部DNSサーバフルサービスリゾルバ（代行者）
2リゾルバが元をたどって聞きに行く
自社の外部DNSサーバ
↓反復問合せ「次はどこに聞けばいい？」を繰り返す
上位のDNS（最上位 → 分野別）「そのドメインの担当はあっち」と案内
↓
権威DNSサーバそのドメインの正解を持つ最終地点
↑IPアドレスが確定 → リゾルバ経由でPCへ返る
動きで見る
番号順に追うと、内部環境 → DMZ → 外部（インターネット）の間を、誰が・何を聞き・何を知るかが見えます。例として www.example.jp のIPを調べます。（図は横スクロールできます）
内部環境
DMZ
外部（インターネット）
💻PCスタブリゾルバ
🖥️自社DNSリゾルバ（代行者）
🌐上位DNSルート→分野別 の案内役
📁権威DNSexample.jp の正解を持つ
✉️
3つの役割
スタブリゾルバ
- 端末（PC）側の役
- 自分では調べない
- リゾルバに丸投げする
フルサービスリゾルバ
- 自社の外部DNSサーバの役
- 端末の代わりに調べ回る
- 結果を一時保存（キャッシュ）
権威DNSサーバ
- そのドメインの正解を持つ
- ドメインごとに存在
- 最終的な答えの出どころ
2種類の問合せ
再帰的クエリ
- PC → リゾルバ
- 「最終的な答えまで持ってきて」と丸投げ
反復問合せ
- リゾルバ → 各DNS
- 「次はどこに聞けばいい？」を辿る
なぜ「ドメイン名」と「担当サーバ」が別なのか
ドメイン名はただの名前で、それ自体はサーバではありません。「このドメインのDNSはこの担当サーバに聞いてね」という指名（NSの登録）が別にあり、そこをたどって初めて権威DNSサーバに届きます。だから流れは必ず「名前 → 担当サーバの指名 → 権威サーバ」の順になります。
見抜きどころ
穴埋めでは一般論の言葉（リゾルバ・パブリックDNS）ではなく、その問題の構成図に載っている機器名で答えさせることが多いです。「代行して調べる役＝自社の外部DNSサーバ」「正解を持つ役＝権威DNSサーバ」と、役割を構成図の固有名に当てはめるのが決め手。
SC向け：名前解決を狙う攻撃と守り
名前解決は「相手のIPを教える入口」なので、偽の答えを信じ込ませる・他人への攻撃の踏み台にするという2方向で狙われます。SC/NW午後では、この仕組みの弱点と対策がそのまま問われます。
攻撃・リスク
- キャッシュポイズニング：本物の応答より先に偽の応答を注入し、キャッシュに嘘の対応を覚えさせて別のサーバへ誘導する
- オープンリゾルバの悪用：送信元を詐称した問合せで大きな応答を第三者へ向け、リフレクション/増幅型のDDoSに使われる
効く対策
- 問合せIDと送信元ポートのランダム化で、偽応答を当てにくくする
- DNSSEC：応答に署名を付け、改ざん・偽応答を検証で弾く
- リゾルバを外部に開かない（オープンリゾルバにしない）
- キャッシュDNSと権威DNSの分離で役割と公開範囲を切り分ける
午後では「なぜ偽の応答が刺さるのか（先着・当てやすさ）」「DNSSEC／ポート・IDランダム化の狙い」がねらわれます。