2008 の教訓 — 並行問い合わせと短期対策
2008 年に広く知られた問題を、高レベルの攻撃発想と短期対策として理解する。
前章のおさらい: 第 3 章では、応答受理条件（question / ID / address / port）と race window、そして entropy と試行回数の関係を整理しました。本章ではその枠組みを使い、2008 年に広く知られた問題が「なぜ深刻だったのか」、そして当時から続く短期対策の組み合わせを確認します。
注意: この章は歴史的な教訓と防御の意図を扱います。実環境への攻撃手順や exploit code は扱いません。
2008 年の何が深刻だったのか
DNS cache poisoning 自体は昔から知られていましたが、2008 年に Dan Kaminsky が広く周知した問題（一般に「Kaminsky 攻撃」と呼ばれます）は、「uncached な問い合わせ機会を何度も作られると、短い race window でも attempts を増やせる」という点を鮮明にしました。詳しい攻撃手順はここでは扱いませんが、高レベルの発想としては「random123.example.com のような存在しないラベルへ次々に問い合わせを発生させ、その都度 fresh miss を作って race を多数回試行する」というものです。
1 回の race が短くても、fresh miss が何度も作られれば累積の危険は上がります。RFC 5452 が attempts と outstanding queries を分けて説明しているのは、このイメージを掴んでもらうためです。
小問 4-1 — attempts を増やされると何が困るか
1 回の race が短くても、fresh miss が何度も作られれば累積の危険は上がります。
Q1. 2008 年に広く知られた DNS cache poisoning 問題の教訓として最も近いものはどれですか。
何が「試行回数」を増やしたのかがポイントです。
2008 年に広く知られた問題の教訓は、uncached な問い合わせ機会を何度も作られると、偽応答との race の試行回数が増え、危険が高まりやすいという点です。ここでは仕組みの理解だけに留めます。
Q2. 他の条件が同じで、identical outstanding queries の本数 D だけが小さな範囲で 1 から 2 に増えたとき、1 つの window あたりの spoof 成功確率は概ねどう変わりますか。
RFC 5452 は小さな D ではほぼ比例で考えられると説明しています。
他の条件が同じなら、identical outstanding queries の本数 D が増えるほど、同一 window でどれかに当たる確率は上がります。小さな D の範囲では概ね比例で見てよいので、1 から 2 ならおおむね 2 倍方向です。
open recursion と監視
小問 4-1 で見たとおり、危険を増やす最大の要因は「attempts（fresh miss の発生回数）」です。では、その attempts を誰が増やせるのでしょうか。一つの答えが open recursion です。resolver が誰からでも使える状態だと、第三者が外部から自由に query を起こせるため、結果として fresh miss と attempts を意図的に増やされやすくなります。つまり open recursion は「攻撃者にとっての attempts 増加の入口」を広げる構成と言えます。
これは負荷・観測ノイズ・race opportunity の増加という意味で exposure を広げます。運用では「random なラベルへの query 急増」「特定 zone への miss の偏り」「NAT による port entropy の劣化」などを監視指標として持つと、挙動の変化に気づきやすくなります。
小問 4-2 — open recursion と短期対策
誰でも resolver に query を起こせる状態は exposure を広げます。短期対策は一面だけでは不十分です。
Q3. open recursion が cache poisoning の観点で危険度を上げやすい理由として最も近いものはどれですか。
誰が query を起こせるか、という入口の広さを考えます。
open recursion では、誰でも resolver に query を起こしやすくなります。これにより cache miss や負荷を増やされ、race の試行機会も作られやすくなるため、露出が大きくなります。
Q4. 短期対策としてあてはまらないものはどれですか。
副作用が大きく、防御としても不十分なのはどれかを考えます。
短期対策としては patch / update、source port / transaction ID の乱数性確保、recursion を信頼済みクライアントへ制限、query 急増や random label のスパイク監視が適切な組み合わせです。TTL を無限に固定するのは運用上の副作用が大きく、防御としても不十分で、短期対策に含めるべきではありません。
Q5. 次のうち誤りはどれですか。
DNSSEC が「署名による検証」なのか「秘匿」なのかを思い出します。
誤りは 3 番目の選択肢です。DNSSEC は query 名や response 本文の秘匿を提供しません。他の 3 つはいずれも筋の通った説明で、特に patch 後も既存 cache の TTL が残れば古い答えがしばらく見えます。
第 4 章のまとめ
- 短い race window でも、fresh miss と attempts が増えると危険は累積する
- open recursion は exposure を広げるので、trusted clients に絞るのが基本
- patch / entropy / recursion control / 監視は短期 hardening の土台