はじめに

本記事では、DNSキャッシュポイズニング（DNS Cache Poisoning）の仕組みと攻撃の流れ、対策について、図解付きで分かりやすく解説します。

🧠 DNSキャッシュポイズニングとは？

DNSキャッシュポイズニングとは、DNSキャッシュサーバに偽のDNS情報を注入する攻撃手法です。
この攻撃が成功すると、利用者が正規のドメイン名（例：example.com）にアクセスしたつもりでも、攻撃者が用意した偽のIPアドレスに誘導されてしまうことがあります。

💥 攻撃の流れを図解で理解する

以下のMermaid図で、攻撃の流れを示します。

DNS応答パケットの内容について以下に補足します。どのようにDNSキャッシュポイズニングが成立するかを理解するために重要なのでぜひ一読してください

DNS応答パケットの内容

✅ DNS応答パケットの内容

例えば、クライアントが example.com のIPアドレスを知りたくて送信したクエリに対し、以下のような応答を返します：

Transaction ID: 0x1234
Flags: 0x8180 (標準的な応答)
Questions: 1
Answer RRs: 1

Answers:
  Name: example.com
  Type: A (IPv4アドレス)
  Class: IN
  TTL: 300
  Data length: 4
  Address: 6.6.6.6

ここで重要なのは：

項目	意味
Transaction ID	問い合わせに対応する識別子。これが一致しないと応答として認識されない。
example.com → 6.6.6.6	ドメイン名に対して返されたIPアドレス（偽のもの）
TTL（Time to Live）	キャッシュサーバに保存される時間。長く設定されていると攻撃効果が持続する。

🧨 攻撃者が送る「偽の応答」の特徴

攻撃者は、以下のように作った大量の偽の応答パケットをリゾルバに送りつけます：

example.com の応答に見せかける
Transaction ID を総当たり（0x0000～0xFFFF）
IPアドレスを攻撃者のサーバ（例：6.6.6.6）
権威サーバからの応答に見せかける

イメージ（攻撃者の偽応答）：

Transaction ID: 0x39af（予測値）
Name: example.com
Address: 6.6.6.6（攻撃者のIP）

→ これがたまたま正しいTransaction IDと一致し、正規の応答より先に届くと、DNSキャッシュサーバはこれを正規の応答として記録してしまいます。

🔁 攻撃をテキストでまとめると…

クライアントがDNSキャッシュサーバに名前解決要求
DNSキャッシュサーバが権威DNSサーバに問い合わせ
攻撃者が予測したトランザクションIDを使って偽の応答を大量送信
偽応答が正規応答より先に届き、IDが一致すると、DNSキャッシュに偽IPが保存される
クライアントは偽IPを使って攻撃者のサーバにアクセスさせられる

🎯 攻撃を成功させる条件

条件	内容
トランザクションID一致	問い合わせと同じ識別子の応答を攻撃者が生成
UDP利用	DNSがUDPを使うことで偽装が容易になる
キャッシュサーバに到達可能	攻撃者の偽応答がDNSキャッシュサーバに届く必要あり
正規応答より先に届く	タイミング勝負（race condition）

🛡 有効な対策

対策	内容
✅ DNSSEC	応答に電子署名を付与して真正性を検証
✅ ソースポートのランダム化	攻撃者が当てにくくなる（ID＋ポート両方必要）
✅ TTL長めに設定	キャッシュの再取得頻度を減らして攻撃機会を減らす
✅ TCPに切替	UDPより偽装が難しい（ただし処理が重くなる）

DNSSECについて以下で補足します

DNSSECとは

DNSSECとは

DNSSECは、「DNS応答に電子署名をつけて真正性を検証する仕組み」
つまり、攻撃者がいくら偽の応答を送っても、「正規の署名がない＝改ざんされている」と判断して破棄できます。

🔁 例：通常の応答 vs DNSSECあり

🔸 通常のDNS応答（改ざん可能）：

example.com → 6.6.6.6 （偽のIP）

🔹 DNSSECあり：

example.com → 192.0.2.1 （正しいIP）
署名：RRSIG（正規の署名）
🔍 DNSリゾルバ：署名を検証 → OK → キャッシュ

→ 偽の応答では署名検証に失敗するため、受け取らない！

RRSIG（Resource Record Signature）レコードは、DNS応答の正当性（改ざんされていないこと）を保証する電子署名データです

📝 まとめ

DNSキャッシュポイズニングは、DNSの仕組みそのものを悪用した本質的な脅威
攻撃に成功すると、HTTPSでも信頼できない相手に誘導される可能性がある（証明書未検証時）
DNSSECやランダム化による多層防御が必須

🧪 補足：HTTPSが守ってくれるのか？

HTTPSを正しく実装していれば、偽のDNS応答で攻撃者サーバに誘導されても、証明書の正当性検証で接続は拒否されます。

しかし、以下のような場合は危険です：

証明書の検証をスキップしている（例：自己署名でも許可）
ユーザが警告を無視してアクセスしてしまう
アプリやIoT機器で証明書検証が適切でない実装

💬 おわりに

DNSキャッシュポイズニングは古典的でありながら、いまだにIoT機器や簡易実装されたサービスで狙われる攻撃手法です。
「DNSの仕組みを信じすぎない設計」が今後ますます重要になります。