DNSキャッシュポイズニング：仕組み、攻撃手法、実践的な防御

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 目的と要点：なぜ今も重要か

DNSキャッシュポイズニングは、キャッシュDNSサーバ（フルリゾルバ） が保持する名前解決結果に偽のリソースレコードを混入させ、利用者を攻撃者の用意したIPアドレスへ誘導する攻撃である。2008年の Kaminsky型 攻撃の公表以降、送信元ポートランダム化 や 0x20ビット（大文字小文字）エンコーディング、そして DNSSEC（DNS Security Extensions） が対策として広く導入され、難易度は上がった。しかし2020年の “Cache Poisoning Reloaded” や “Poison Over Troubled Forwarders” などの研究により、設定不備のフォワーダや実装スタックの隙を突く手法は依然として成立し得ることが示されている。運用チームは、プロトコルが提供する真正性（DNSSEC） と 実装・運用上のエントロピー確保 を併用して、段階的に防御を固める必要がある。(IETF Datatracker)

2. 脅威モデルと基礎：どこに偽応答が入るのか

2.1 役者とデータフロー

スタブリゾルバ：エンド端末の名前解決ライブラリ。
キャッシュ（フル）リゾルバ：再帰問い合わせを行い結果をキャッシュ。
権威DNSサーバ：ゾーンの正解を保持。

通信は通常、スタブ→リゾルバ→（ルート→TLD→権威DNS）→リゾルバ→スタブという段階を踏む。攻撃者は オフパス（off-path） でも、トランザクションID（TXID）、送信元ポート、問い合わせ名の大文字小文字パターン（0x20）などの 応答照合に使われる値 を推測して偽応答を大量送出し、正規応答より先に リゾルバへ到達させることを狙う。(JPNIC)

2.2 攻撃成功確率の概念

単純化すると、1パケットあたりの成功確率 \(p\) は次の積に近い：

\[
p \approx \frac{1}{2^{16}} \times \frac{1}{N_{\text{port}}} \times \frac{1}{2^{b_{\text{0x20}}}}
\]

\(2^{16}\)：TXIDの空間
\(N_{\text{port}}\)：実効的なランダムUDPポート数（NATや実装で減る場合がある）
\(b_{\text{0x20}}\)：問い合わせ名の英字数（0x20によるケースランダム化）

送信元ポートランダム化（RFC5452）と 0x20 を併用すると、推測空間は増え、偽応答が先着する確率 を大幅に下げられる。(IETF Datatracker)
※ 実際の成功確率はNAT実装、同時並行クエリ数、EDNS(0)の挙動、実装固有のランダム性などに依存する。(IETF Datatracker)

3. 歴史的経緯と代表的手法

3.1 Kaminsky型（2008）

問い合わせをトリガに多数の偽応答を 名前委任（NS/A/GLUE）連鎖 部分へ投射することで、待ち時間をほぼゼロにして 試行回数を稼ぐ発想が広く注目された。これを契機に ベンダ横断の緊急パッチ と 送信元ポートランダム化の徹底 が推進された。(JPCERT)

3.2 0x20ビット・エンコーディング（2008）

問い合わせ名の大文字小文字をランダム化し、応答側もそれを反映するという非暗号的だが有効な追加エントロピー。実装負荷が低く、Google Public DNSなどで採用されている。ただし真正性の担保はしないため、最終的な解 はDNSSECである。(COEUS)

3.3 再燃（2020以降）

Cache Poisoning Reloaded（2020）：実装スタックの複合的不具合により古典的攻撃の再活性化を報告。(par.nsf.gov)
Poison Over Troubled Forwarders（2020）：DNSフォワーダ経路での汚染。支社ルータ等フォワーダ機器の挙動が弱点。(ICANN)
最近の概説（2025）：フォワーダ攻撃脅威の整理が継続。(netlas.io)

4. 可視化：偽応答が先着するまで

sequenceDiagram participant Client as クライアント participant Res as キャッシュDNS(リゾルバ) participant Auth as 権威DNSサーバ participant Att as 攻撃者(オフパス) Client->>Res: www.example.com の問い合わせ Res->>Auth: 再帰問い合わせ (TXID=?, SrcPort=?, 0x20パターン=?) Att-->>Res: 偽応答を大量送出 (TXID/Port/0x20 を推測) Auth-->>Res: 正規応答 (NS/A/GLUE/TTL) alt 偽応答が先着・照合一致 Res->>Res: キャッシュ汚染（誤ったA/NS等を保存） else 正規応答が先着 Res->>Res: 正常キャッシュ end Res-->>Client: キャッシュからの応答

この「先着勝負」を破るには、照合条件のエントロピー増加（TXID・ポート・0x20・クエリ予測難度）と 応答真正性検証（DNSSEC） の併用が基本。(IETF Datatracker)

5. 実践的な対策（推奨設定と検証の流れ）

5.1 政策レベル（優先順）

DNSSEC検証を有効化したバリデーティング・リゾルバ採用
RFC4033/4034/4035。権威側署名と検証により応答改ざんを暗号的に排除。(RFC エディタ) 国内普及率は十分でないとの指摘もあり、利用者側バリデーションが重要。(dnsops.jp)
送信元ポートランダム化（SPR）の徹底
RFC5452で重要性が整理。NATやフォワーダにより実効エントロピー低下がないか点検。(IETF Datatracker)
0x20エンコーディング（ケースランダム化）の有効化
非暗号エントロピー。採用例多数。(SIDN - Het bedrijf achter .nl)
EDNS(0)の適正実装運用
RFC6891。フラグメントや再送制御特性が成功確率に影響し得る。(IETF Datatracker)

5.2 代表的リゾルバ（例：Unbound）

Unboundは広く使われるバリデーティング・キャッシュ。設定例（バージョン差異は必ず最新マニュアルで確認）。(unbound.docs.nlnetlabs.nl)

# /etc/unbound/unbound.conf（例）
server:
  auto-trust-anchor-file: "/var/lib/unbound/root.key"    # DNSSEC検証
  use-caps-for-id: yes                                   # 0x20ケースランダム化
  harden-referral-path: yes                              # 委任連鎖の厳格化
  harden-below-nxdomain: yes                             # 不要問い合わせ抑制
  # 送信元ポートは既定でランダム化。NAT/フォワーダ影響を監査

5.3 運用チェックリスト

フォワーダ乱用抑制：支社ルータ等フォワーダ挙動棚卸し。(ICANN)
オープンリゾルバ排除：ACL厳格化。(セキュアヴェイル)
DNSSECバリデーション監視：鍵更新失敗や失効検知。(RFC エディタ)
NAT/ファイアウォールのポート割当特性確認：連続割当回避。(IETF Datatracker)

5.4 動作検証ヒント

ケースランダム化有効性やポートエントロピー評価は公開検査サービスやベンダ資料参照。具体的手順は運用ポリシー準拠。(JPCERT)

6. 攻撃者視点の防御設計翻訳

6.1 偽応答が通る場所（委任連鎖）

権威が返す 委任応答（NS＋GLUE） を誤誘導できれば、以後の問い合わせは攻撃者支配の権威へ向かい、A/AAAA/MX 等を任意配布可能。RFC5452は GLUE取り扱い厳格化 を推奨。(IETF Datatracker)

6.2 フォワーダ網の不可視な空隙

拠点ルータやUTMのDNSフォワーダは、SPRや0x20を無力化、並列クエリ処理不備 などでエントロピー低下要因となり得る。対策：バリデーティング・フルリゾルバ直接参照（DoT/DoH含む） またはフォワーダ特性の監査。(ICANN)

6.3 再燃研究の教訓

2020年研究群は古典要素（ID/クエリ推測）に加え実装相互作用 が新攻撃面を生むことを示した。よって「DNSSECによる暗号的検証」「SPR/0x20の非暗号エントロピー」「実装健全性」三位一体で評価。(par.nsf.gov)

7. よくある誤りと対処

「DNSSECは権威側未対応だから無意味」
誤り。検証側の有効化だけでも、署名済みゾーンの保護効果を即時に取り込める。署名未対応ゾーンには直接効かないが、中核ドメインやTLDの整合性が守られる波及効果 はある。(RFC エディタ)
「既定設定なら常に安全」
誤り。NATやフォワーダの性質 がエントロピーを削ることがある。併せて確認が必要。(IETF Datatracker)
「0x20さえ入れれば実用上十分」
誤り。0x20は真正性を証明しない。最終的な改ざん検出はDNSSEC が担う。(COEUS)

8. まとめ：設計原則

第一原則：改ざん検出主体はDNSSEC。常時オン。(RFC エディタ)
第二原則：エントロピー最大化（送信元ポートランダム化＋0x20）。NAT/フォワーダで低下していないか監査。(IETF Datatracker)
第三原則：委任連鎖（NS/GLUE）厳格化と実装健全性維持。(IETF Datatracker)
現在地：国内DNSSEC検証普及は十分でないとの指摘。自組織リゾルバで検証を有効化し、フォワーダ/NAT挙動を監査することが最大効果。(dnsops.jp)

A. 参考サイト

RFC 5452: Measures for Making DNS More Resilient against Forged Answers（英語原文 / 日本語抄訳あり）(IETF Datatracker)
RFC 4033 / 4034 / 4035（DNSSECプロトコル）(RFC エディタ)
RFC 6891: EDNS(0)（拡張）(IETF Datatracker)
JPCERT/CC「DNSキャッシュポイズニング脆弱性について」/ 注意喚起 (JPCERT)
JPNIC「インターネット10分講座：DNSキャッシュポイズニング」(JPNIC)
0x20ビット耐性向上論文（Increased DNS Forgery Resistance Through 0x20-Bit …）(COEUS)
Cache Poisoning Reloaded（2020）(par.nsf.gov)
Forwarders Cache Attack（2021）(ICANN)
DNS Cache Poisoning – 概説（2025）(netlas.io)