総合演習 — ケースで仕上げる
障害調査を模したケース問題 8 問で、委任・TTL・レコード型・DNSSEC・切り分け手順を一気に使う。
最終章 — 知識を「調査の動き」に変える
この章は新しい知識を足しません。代わりに、実務で遭遇する形のケース問題 8 問を解きます。各問題は障害調査の一場面を切り取ったもので、答えるにはここまでの複数の章を組み合わせて使う必要があります。
合格の目安: 8 問中 6 問以上。届かなかった場合も全部やり直す必要はなく、間違えた問題の解説に書かれた章だけ戻って復習すれば十分です。
解く前に — 応答を読む 3 つの問い
この講座で繰り返してきた見方を、調査のチェックリストとして 1 枚にまとめます。ケース問題でも実務でも、迷ったらここへ戻ってください。
| 問い | 確かめること | 対応する章 |
|---|---|---|
| 誰が答えたか | 権威か、キャッシュか、referral か。いまこの名前の権威はどのゾーンか（zone cut はどこか） | 第 1〜3 章 |
| 何が返ったか | 期待した型か。NXDOMAIN か NODATA か。CNAME で本名へ飛んでいないか。MX なら 2 段目まで追ったか | 第 3〜4 章 |
| いつまで有効か | expires_at = fetched_at + TTL。否定応答のキャッシュも含めて、旧い答えの残存時間を計算したか | 第 5 章 |
そして観察の道具は dig です: dig 名前 型 → dig ゾーン NS → 必要なら dig +trace（第 6 章）。
総合演習 7-1 — 委任・TTL・MX を横断する
章単位の知識ではなく、複数の章をまたいだ判断ができるかを確かめます。
Q35. shop.example.com は別ゾーンに委任済みです。api.shop.example.com A を親ゾーンの権威サーバに聞いたとき、最も起こりやすい返し方はどれですか。
委任点の先は子ゾーンの責任範囲なので、親は referral で案内します（第 2〜3 章）。「親に聞いても最終答えは出ない」ことを異常だと勘違いしない — 調査時の基本姿勢です。
Q36. 09:55 に TTL 600 秒の旧 A レコードを取得した再帰リゾルバがあり、権威側は 10:00 に新しい A へ切り替わりました。10:00 時点から、この再帰リゾルバで旧値が返りうる最大時間は何分ですか。
失効時刻は 09:55 + 600 秒 = 10:05。10:00 から見て最大 5 分です（第 5 章）。切り替え作業の影響時間は、この計算を利用者側のリゾルバごとに考えれば見積もれます。
Q37. example.com MX 10 mail.example.net を得ました。配送先 IP を知るために、次に引くべきものはどれですか。
MX が返すのはホスト名なので、2 段目として mail.example.net の A / AAAA を引きます（第 4 章）。この例のように MX が自ゾーン外（.net）のホストを指すことも普通にあります。
Q38. dig www.example.com A の結果が status: NOERROR、ANSWER は空、AUTHORITY に SOA が載っていました。なお www.example.com には AAAA だけが存在します。最も近い解釈はどれですか。
NOERROR + ANSWER 空 + AUTHORITY に SOA は NODATA の典型形です（第 3・6 章）。名前は存在する（NXDOMAIN ではない）が、聞かれた型のデータがない。IPv6 専用ホストに A を聞くと、まさにこうなります。
総合演習 7-2 — キャッシュ・DNSSEC・切り分けの仕上げ
最後は「どこから調べ始めるか」の判断まで含めて確認します。
Q39. 50 件の同一の問い合わせが 1 つの再帰リゾルバに届き、すべてが 1 つの TTL の内側で発生しました。最初はキャッシュが空です。この RRset について権威サーバへ届く問い合わせは何回ですか。
初回の miss で取得したあとは、TTL 内の 49 件すべてがキャッシュヒットです（第 3・5 章）。権威側から見ると、TTL はアクセス集中の防波堤として働いていることが分かります。
Q40. DNSSEC の検証チェーンに直接関係する要素にあてはまらないものはどれですか。
検証チェーンは「親の DS → 子の DNSKEY → RRset に付く RRSIG」でつながります（第 6 章）。MX はメール配送先を示すデータであり、チェーンの構成要素ではありません（MX 自体が署名で守られる対象ではあります）。
Q41. zone apex に plain CNAME を置けない理由として最も近いものはどれですか。
apex には SOA と NS が必ず置かれ（第 2 章）、CNAME は同居禁止（第 4 章）。2 つのルールの衝突が apex CNAME 問題の正体です。ALIAS / ANAME はこれをプロバイダ独自機能で回避しています。
Q42. 「レコードは変更したはずなのに、まだ古い IP が見える」。最初の切り分けとして最も良いものはどれですか。
まず「現実に何が返っているか」を dig で観察し、権威は正しいか（委任）、キャッシュが残っていないか（TTL）を切り分けます（第 6 章）。ブラウザの連打が無意味なのは、リゾルバ側のキャッシュ TTL が切れない限り何度引いても同じ答えが返るからです。
この講座の着地点
すべて解き終えたら、次のことができるようになっているはずです。
- DNS 応答を見て、権威 / キャッシュ / referral / 否定応答を区別して読める。
expires_at = fetched_at + TTLを使って、残り TTL・miss の回数・変更の反映時間を秒単位で計算できる。- MX の 2 段階解決、CNAME の同居禁止と apex 問題など、レコード型ごとの落とし穴を避けられる。
- DNSSEC の守備範囲（起源認証・完全性・改ざん検知）と、秘匿は別物であることを説明できる。
- トラブル時に
dig 名前 型→dig ゾーン NS→dig +traceという決まった入口から動ける。
次にやると定着しやすいこと
- 自分が管理する（または勤務先の）ドメインで
dig NS、dig SOA、dig +traceを実行し、この講座の図と同じ流れが実物で起きることを確認する。 - 変更しても困らないテスト用レコードを 1 つ作り、TTL を事前に下げてから値を変え、あとで戻す運用を一度通しで体験する。反映のタイミングを事前に計算し、実測と照らし合わせる。
- メールを受けているドメインがあるなら、MX → 配送先ホストの A / AAAA の 2 段を dig で実際に辿り、紙に書き出してみる。
この 3 つを済ませれば、講座の内容は「読んだ知識」から「使った経験」に変わります。