導入 — DNSキャッシュポイズニングとは何か
共有リゾルバが偽の RRset を覚えると、利用者全員が同じ誤答を見る構図を掴む。
最初に持ちたい図
| 登場人物 | 役割 |
|---|---|
| 利用者 / browser | 名前を引く側。resolver の答えを信じる。 |
| shared recursive resolver | ここに cache がある。複数利用者で共有される。 |
| authoritative servers | 各ゾーンの正規データを持つ。 |
誤った RRset が shared recursive resolver の cache に残ると、その resolver を使う利用者全体へ同じ誤答が配られます。
DNS キャッシュポイズニングは「共有の記憶の改ざん」
DNS で危険なのは、利用者の端末 1 台だけが一時的に勘違いすることではなく、shared recursive resolver が偽の RRset を覚えてしまい、それを何度も再利用することです。利用者から見ると resolver は「答えを知っている主体」に見えますが、その答えが本物か cache かは見えません。
そのため troubleshooting では、まず「いま見えている答えは authoritative か、cache か、それとも referral の途中なのか」を分けて考える必要があります。
小問 1-1 — まずは shared cache を主役に置く
権威サーバの compromise と、shared recursive resolver の poisoning は似て見えることがあります。しかし防御・観測で最初に追うべき場所は違います。
Q1. DNSキャッシュポイズニングで中心的に問題になる状態はどれですか。
問題の中心は「共有リゾルバが何を覚えてしまったか」です。
DNSキャッシュポイズニングでは、再帰リゾルバが偽の RRset を受理して cache に残し、それを利用者へ再配布することが問題の中心です。権威ゾーンそのものの改ざんとは区別して考えます。
Q2. 1 台の共有再帰リゾルバが poison されると影響が広がりやすい主な理由はどれですか。
「1 台が何人に返すか」を考えると整理しやすいです。
共有再帰リゾルバは多くの利用者へ同じ cache 結果を返します。したがって 1 台の誤受理が、同じ resolver を使う利用者全体へ波及しやすくなります。
TTL があるので、誤答は「しばらく残る」
poisoned な RRset は、受理された瞬間に永続化されるのではなく、TTL の有効期限のあいだだけ shared cache に残ります。したがって patch を当てても、すでに残っている cache entry の寿命が尽きるまでは同じ誤答が見えることがあります。
観測では「残り TTL が似ているか」「同じ resolver を使う複数利用者で同じ値が見えるか」を見ると、browser 個別の問題との切り分けがしやすくなります。
小問 1-2 — 誤答は TTL の間だけ残る
poisoned な RRset は TTL の有効期限のあいだ shared cache に残ります。残り秒数を追えると、観測や切り分けがしやすくなります。
Q3. 共有リゾルバが 09:00:00 に TTL 300 秒の誤答を受け入れました。09:03:00 時点の残り TTL は何秒ですか。
09:00:00 から 09:03:00 までは 180 秒経過です。
300 秒から経過 180 秒を引くので、残り TTL は 120 秒です。poisoning でも stale cache でも、残り TTL を数字で追えることが観測の第一歩です。
見え方の似た現象を混同しない
internal DNS、split-horizon、negative caching、browser の HTTP cache は、利用者の目から見ると「名前解決が変」に見えることがあります。だからこそ「どの層の cache か」を先に固定し、次に authoritative path と affected resolver の差を見るのが大切です。
split-horizon とは: 同じ名前に対して、社内向け resolver と社外（public）resolver で意図的に異なる答えを返す DNS の運用設計です。たとえば社内からは内部 IP、社外からは公開 IP を返す、といった構成が典型です。詳細は第 6 章で扱いますが、Q4 の選択肢を読む際はこの「設計上の差分」がありうることを念頭に置いてください。
小問 1-3 — 見え方の似た現象を混同しない
internal DNS、split-horizon、negative caching、browser の HTTP cache は見え方が似ることがあります。どの層の cache かを先に固定します。
Q4. 「同じ社内名が社内 resolver と public resolver で違って見える」状況として最もありうる説明はどれですか。
見え方が違うだけで、直ちに攻撃と断定できるとは限りません。
社内向けと社外向けで別の答えを返す split-horizon / internal DNS は普通にあります。違いが見えたときは、まず設計差なのか異常なのかを切り分けます。
Q5. DNSキャッシュポイズニングと HTTP キャッシュの取り違えを避けるうえで正しい説明はどれですか。
DNS の TTL と HTTP の cache-control は別の層です。
DNSキャッシュポイズニングは名前解決結果の共有 cache が問題で、HTTP や CDN の cache とは別に考える必要があります。DNS の TTL を変えても browser の HTTP cache が自動で消えるわけではありません。
第 1 章のまとめ
- DNS キャッシュポイズニングは shared recursive resolver の記憶 が主戦場
- 誤答は TTL のあいだ残るので、patch と cache 寿命は分けて考える
- split-horizon や HTTP cache など、見え方の似た現象と混同しない