総合演習と全問レビュー
ケース問題 8 問で、bailiwick・entropy・NAT・DNSSEC・運用の視点をまたいで仕上げる。
ここで仕上げる
この章ではケース問題 8 問を通して、glue / entropy / NAT / AD bit / negative caching / split-horizon を横断して解きます。1 章ごとの知識ではなく、複数の章を組み合わせた視点で判断できるかを確認します。
合格の目安: ケース問題 8 問のうち 6 問以上正解できていれば、cache poisoning の防御・観測で現場の一次切り分けに十分使える状態です。
総合演習で使う視点
| 章 | この章で使う見方 |
|---|---|
| 第 1 章 | 「誰の cache に誰が答えを入れたか」を分ける |
| 第 2 章 | in-bailiwick glue と out-of-bailiwick additional の違い |
| 第 3 章 | ID / source port / question / time window の一致と entropy |
| 第 4 章 | 2008 の教訓と、patch / recursion control の短期対策 |
| 第 5 章 | DNSSEC の守備範囲と last-hop の trust 問題 |
| 第 6 章 | dig・ログ・negative caching / split-horizon の切り分け |
総合演習 7-1 — bailiwick・entropy・DNSSEC（仕組み軸）
referral の扱い、port entropy、AD bit と last hop など、「仕組みでどこまで守れるか」をケースで確認します。
Q1. 親ゾーンの referral で NS ns1.shop.example.com と A ns1.shop.example.com 192.0.2.53 が一緒に返ってきました。最も妥当な扱いはどれですか。
これは子ゾーンへ辿るための in-bailiwick glue として限定的に使うのが妥当です。shop.example.com 配下の任意名に対する一般の最終 answer と同一視はしません。
Q2. referral に NS ns.partner.net と A ns.partner.net 198.51.100.10 が Additional で付いてきました。最も安全側の判断はどれですか。
out-of-bailiwick の可能性を意識し、必要なら ns.partner.net 自体を別解決するのが安全側です。referral に混ざった追加データを全面的に信じるのは危険です。
Q3. resolver が NAT 配下にあり、外向き source port が実質 256 通りの連番に丸められています。このとき最も正しい説明はどれですか。
port entropy が大きく減少し、spoof 耐性が弱まりやすいという説明が最も近いです。source port randomization は「外から見えている多様さ」が重要です。
Q4. stub resolver が AD=1 の応答を受け取りましたが、その upstream recursive resolver も通信路も十分に信頼していません。このときの解釈として最も適切なのはどれですか。
AD=1 は有用なヒントですが、その recursive resolver や通信路を十分に信頼していないなら、万能のエンドツーエンド証明とは見なせません。last hop の信頼問題を忘れないことが大切です。
Q5. 対象 zone が unsigned です。最も正しい説明はどれですか。
unsigned zone では DNSSEC validation だけで守ることはできません。そのため query matching、entropy、glue hardening、recursion control など、他の hardening も引き続き重要です。
総合演習 7-2 — 運用・監視・総合方針（運用軸）
監視シグナル、cache TTL の寿命、組織方針まで「現場でどう回すか」を確認します。
Q6. ある zone に対し、短時間に大量の random な存在しないラベルへの query が続いています。cache poisoning 観点で気にする理由として最も近いものはどれですか。
random な存在しないラベルへの query が増えると、uncached な問い合わせ機会が増え、miss と負荷が増します。race の試行回数が増えうるため、監視上のシグナルになります。
Q7. patch を適用した直後なのに、同じ resolver を使う利用者があと 2 分ほど同じ誤答を見ると予想されます。最も直接の理由はどれですか。
既に入っている cache entry の TTL がまだ残っているためです。ソフトウェアを直しても、既存の stale / poisoned data の寿命が残っていれば、見え方はすぐには変わりません。
Q8. 組織の recursive resolver に対する総合方針として最も適切なものはどれですか。
最も適切なのは、patch/update、ID/port entropy、glue/bailiwick hardening、trusted clients への recursion 制限、DNSSEC validation、監視を組み合わせる方針です。単独の設定だけに依存しないのが重要です。
この講座の着地点
- shared recursive resolver の cache に誤った RRset が残る と、利用者全体に同じ誤答が配られる構図を説明できる。
- referral / final answer / glue を分け、in-bailiwick / out-of-bailiwick を意識して扱える。
- 応答受理条件（question / ID / address / port）と、entropy と試行回数 の関係を式と数字で捉えられる。
- DNSSEC の origin authentication / integrity / authenticated denial of existence と、confidentiality は別物であることを説明できる。
- AD bit の意味を last hop の trust 問題 と合わせて読める。
- トラブル時にまず
dig @resolver/dig +trace/dig +dnssecで応答を観察し、negative caching や split-horizon を先に除外できる。 - 最終的には patch・entropy・bailiwick・DNSSEC・運用監視 を組み合わせて考えられる。
次にやると定着しやすいこと
- 自分の管理 resolver で
dig +traceとdig +dnssecを実行し、referral と署名検証の出力を目で確認する。 - unsigned zone と signed zone を 1 件ずつ選んで
adflag の差を観察する。 - negative caching の TTL が残っている状況を意図的に作り、「作ったのに見えない」の典型を手で体験する。
- 運用側では、random label の急増や署名検証 failure のログを拾う監視があるかを確認する。