DNSキャッシュポイズニングとは？歴史・カミンスキー攻撃・SAD DNS・DNSSEC対策を解説

はじめに

DNSキャッシュポイズニングとは、DNSキャッシュサーバーに偽の名前解決情報を記憶させ、利用者を本物とは異なるサーバーへ誘導する攻撃です。

攻撃が成功すると、利用者が正しいURLを入力しても、フィッシングサイト、マルウェア配布サイト、偽メールサーバーなどへ接続させられる可能性があります。

2008年のカミンスキー攻撃をきっかけに、DNS問い合わせの送信元ポートをランダム化する対策が広く普及しました。そのため、古典的な総当たり攻撃は難しくなりました。

しかし、DNSキャッシュポイズニングが過去の攻撃になったわけではありません。

2020年のSAD DNSでは、ICMPのレート制限をサイドチャネルとして利用し、ランダム化されたUDPポートを推測する手法が示されました。さらに2025年には、BIND 9の疑似乱数生成器や応答レコードの検証に関する脆弱性が修正されています。

結論として、現代のDNS防御では次の組み合わせが必要です。

DNSサーバーを最新版へ更新する
DNSSEC検証を有効にする
送信元ポートとDNSトランザクションIDを十分にランダム化する
不要なオープンリゾルバを廃止する
ファイアウォールやNATでランダム化を弱めない
DNSログと設定変更を監視する
HTTPS、HSTS、証明書検証も併用する

DNSSECは、正しいDNSデータであることを電子署名で検証する仕組みです。IETFはDNSSECによるDNSデータの送信元認証を、現在のベストプラクティスとして位置付けています。

結論・要点

DNSキャッシュポイズニングは、DNSリゾルバが正規の応答より先に受信した偽応答を正しい情報としてキャッシュしてしまう攻撃です。

現在では、16ビットのDNSトランザクションIDだけでなく、問い合わせ元UDPポートもランダム化されます。そのため、単純な偽応答の大量送信だけでは成功しにくくなりました。

一方で、次のような手法によってランダム化を弱めたり、検証処理の不備を突いたりする攻撃が研究されています。

ICMPレート制限を利用するSAD DNS
OSやDNSサーバーの疑似乱数生成器の状態予測
DNS応答のAdditional、Authorityセクションへの不正レコード挿入
UDPフラグメンテーションを利用した応答改ざん
NAT装置による送信元ポートの固定化・単純化
BGPハイジャックや経路上攻撃との組み合わせ
DNSサーバー、ルーター、端末の直接侵害
ドメインレジストラや権威DNSアカウントの乗っ取り

ただし、これらをすべて「DNSキャッシュポイズニング」と呼ぶのは正確ではありません。

DNSキャッシュへの偽情報注入と、DNS設定そのものの乗っ取りは区別する必要があります。

この記事で分かること

この記事では、次の内容を解説します。

DNSキャッシュポイズニングの基本原理
DNSスプーフィングとの違い
攻撃技術の歴史
カミンスキー攻撃の仕組み
SAD DNSなどの現代的な攻撃
2025年に修正されたBIND 9の脆弱性
DNSSECで防げることと防げないこと
Linux、BIND、Unbound環境での確認方法
インフラ担当者が実施すべき対策
Webアプリケーション側で必要な補助対策

対象読者・前提環境

この記事は、次の読者を対象としています。

DNSの仕組みを学びたい人
Webサーバーや社内DNSを管理している人
BIND、Unbound、dnsmasqを利用している人
Linuxサーバーのセキュリティを担当している人
基本情報技術者試験や応用情報技術者試験を学習している人
Webアプリケーションのフィッシング対策を検討している人

確認コマンドは、主にLinux環境を前提とします。

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

DNSは、ドメイン名をIPアドレスへ変換する仕組みです。

電話帳に例えると、DNSは次の対応関係を管理しています。

www.example.com
        ↓
203.0.113.10

利用者の端末は、毎回すべてのDNSサーバーへ問い合わせるわけではありません。

ISP、社内ネットワーク、ルーター、OSなどが利用するキャッシュDNSリゾルバは、一度取得した回答を一定時間保存します。

利用者
  │
  │ www.example.com はどこ？
  ▼
キャッシュDNSリゾルバ
  │
  ├─ キャッシュあり → すぐ回答
  │
  └─ キャッシュなし
       │
       ▼
   権威DNSサーバーへ問い合わせ

DNSキャッシュポイズニングでは、このキャッシュに偽情報を混入させます。

正常な状態

www.example.com → 203.0.113.10


汚染された状態

www.example.com → 198.51.100.50
                  攻撃者のサーバー

偽情報がキャッシュされると、そのDNSリゾルバを利用する複数の端末が影響を受けます。

DNSスプーフィングとの違い

DNSスプーフィングとDNSキャッシュポイズニングは、同じ意味で使われることがあります。

厳密には次のように整理できます。

用語	意味
DNSスプーフィング	DNS応答や送信元を偽装する行為全般
DNSキャッシュポイズニング	偽のDNS情報をキャッシュへ保存させる攻撃
DNSハイジャック	DNS設定、通信経路、アカウントなどを乗っ取る行為全般
ドメインハイジャック	レジストラやドメイン管理権限を奪う攻撃
DNSリバインディング	同じドメインの応答先を変化させ、ブラウザから内部ネットワークへ接続させる攻撃

DNSキャッシュポイズニングは、DNSスプーフィングの結果として発生する場合があります。

しかし、ルーターのDNS設定を書き換える攻撃や、レジストラアカウントを奪う攻撃は、通常のキャッシュポイズニングとは別の問題です。

DNSキャッシュポイズニングが成立する仕組み

正規応答との競争

従来型のDNSキャッシュポイズニングでは、攻撃者は権威DNSサーバーを装った偽応答を送信します。

キャッシュDNSリゾルバが正規応答を受け取る前に、条件が一致した偽応答を受け入れると攻撃が成功します。

キャッシュDNS
   │
   │ 問い合わせ
   ├────────────────────▶ 正規の権威DNS
   │
   │
   │ ◀── 偽応答 ───────── 攻撃者
   │
   │ ◀── 正規応答 ─────── 正規の権威DNS
   │
   ▼
先に受理した偽応答をキャッシュ

この攻撃は、正規応答と偽応答の競争です。

ただし、単に早く送ればよいわけではありません。

偽応答には、問い合わせと一致する情報が必要です。

主な一致条件は次のとおりです。

問い合わせ名
レコード種別
DNSクラス
DNSトランザクションID
問い合わせ先IPアドレス
問い合わせ元IPアドレス
UDP送信元ポート
UDP宛先ポート

RFC 5452は、偽応答に対する耐性を高めるため、応答が元の問い合わせと一致することの検証や、UDP送信元ポートのランダム化を推奨しています。

DNSトランザクションIDとは

DNSトランザクションIDは、問い合わせと応答を対応付ける16ビットの番号です。

0～65,535

問い合わせが次のIDで送られたとします。

Transaction ID: 0x4A21

リゾルバは通常、同じIDを持つ応答を待ちます。

攻撃者が通信を盗聴できないオフパス攻撃では、このIDを推測する必要があります。

16ビットしかないため、候補は65,536通りです。

現代では、送信元UDPポートのランダム化を組み合わせることで、推測対象を増やしています。

DNSトランザクションID
約65,536通り

×

UDP送信元ポート
最大約64,000通り

＝

理論上は約42億通り

ただし、実際の安全性は単純な掛け算だけでは決まりません。

NAT、ファイアウォール、OSのポート選択アルゴリズム、疑似乱数生成器の品質などによって、有効な候補数が減少する場合があります。

DNSキャッシュポイズニングの歴史

1980年代：DNSは信頼を前提に設計された

DNSの基本仕様であるRFC 1034とRFC 1035は、1987年に公開されました。

当時のインターネットは現在より小規模で、ネットワーク参加者同士の信頼を前提とした設計が多く残っていました。

通常のDNS応答には、データの送信元や完全性を暗号学的に検証する仕組みがありませんでした。

そのため、問い合わせと形式上対応している応答であれば、偽造された情報を受け入れる余地がありました。

1990年代：追加情報を悪用した初期のキャッシュ汚染

初期のDNS実装では、応答に含まれるAnswer、Authority、Additionalセクションの情報を広くキャッシュするものがありました。

攻撃者は、問い合わせとは直接関係しない偽レコードをAdditionalセクションへ混入させようとしました。

例えば、次のような応答です。

質問:
www.attacker.example のIPアドレスは？

回答:
www.attacker.example → 198.51.100.10

追加情報:
www.bank.example → 198.51.100.50

リゾルバが追加情報を無条件に信用すると、無関係なドメインまで汚染されます。

この問題への対策として、問い合わせ先の権限範囲に含まれる情報だけを受け入れる、ベイリウィックチェックが強化されました。

ベイリウィックチェックとは

ベイリウィックは、簡単にいえば「そのDNSサーバーが責任を持つ範囲」です。

例えば、example.comの権威DNSが返した次の情報は、原則として範囲内です。

www.example.com
mail.example.com
ns1.example.com

一方、次の情報は範囲外です。

www.bank.example
www.other-domain.net

範囲外の情報を不用意にキャッシュしないことで、偽レコードの混入を防ぎます。

1997年から2007年：予測可能なIDとポートが問題化

1990年代後半から2000年代にかけて、DNSトランザクションIDやUDPポートの予測可能性が繰り返し指摘されました。

RFC 9414の歴史整理では、1997年に予測可能なUDPポートとDNS IDの問題が報告され、2007年にはMicrosoft DNSやBIND系実装に関する予測攻撃が報告された経緯が記載されています。

当時の一部実装は、次のような動作をしていました。

UDP送信元ポートを固定する
DNS IDを単純に加算する
乱数の初期値が推測しやすい
少数のポートを繰り返し使う

この状態では、攻撃者が推測すべき値が少なくなります。

2008年：カミンスキー攻撃

2008年、Dan Kaminsky氏がDNSキャッシュポイズニングを現実的な時間で成功させる攻撃を公表しました。

CVE-2008-1447として広く知られています。

ISCは、この問題をDNSプロトコル自体の弱点を悪用するものと説明し、送信元ポートのランダム化を緩和策、DNSSECを完全な解決策として案内しました。

従来攻撃の制約

通常、目的のレコードがすでにキャッシュされている場合、TTLが切れるまで再問い合わせは発生しません。

www.example.com
TTL: 3,600秒

この場合、攻撃者は最大1時間待つ必要があります。

ランダムな存在しないサブドメインを利用

カミンスキー攻撃では、毎回異なるランダムなサブドメインを問い合わせます。

a81x2.example.com
k93p7.example.com
z72q1.example.com

これらはキャッシュに存在しないため、リゾルバは毎回権威DNSへ問い合わせます。

攻撃者は、そのたびに多数の偽応答を送信できます。

1回目の問い合わせ
a81x2.example.com

偽応答
TxID 00000
TxID 00001
TxID 00002
...

失敗しても、新しいサブドメインを使えば、すぐに次の試行ができます。

NSレコードを汚染する

カミンスキー攻撃の重要な点は、ランダムなサブドメインのAレコードだけを狙うのではなく、対象ゾーンのNSレコードを偽装することです。

example.com の権威DNSは
ns.attacker.example である

この情報がキャッシュされると、以後のexample.com配下の問い合わせが攻撃者のDNSサーバーへ送られる可能性があります。

example.com
 ├─ www.example.com
 ├─ mail.example.com
 ├─ login.example.com
 └─ api.example.com
        ↓
攻撃者のDNSへ問い合わせ

2008年以降：送信元ポートランダム化

カミンスキー攻撃への緊急対策として、DNSリゾルバは問い合わせごとにUDP送信元ポートを変更するようになりました。

ISCの当時の案内では、BINDの修正版は、問い合わせごとに利用可能な高位ポートからランダムに選択するよう変更されました。

問い合わせ1
192.0.2.10:42153 → 権威DNS:53

問い合わせ2
192.0.2.10:58721 → 権威DNS:53

問い合わせ3
192.0.2.10:31984 → 権威DNS:53

送信元ポートが固定されている場合、攻撃者は主に16ビットのDNS IDだけを推測すればよい状態でした。

ポートランダム化後は、IDとポートの両方を推測する必要があります。

0x20エンコーディング

DNS名は通常、大文字と小文字を区別しません。

example.com
ExAmPlE.CoM
EXAMPLE.COM

0x20エンコーディングは、問い合わせ名の大文字と小文字をランダムに変化させ、応答が同じ表記を返すか確認する方法です。

問い合わせ:
wWw.ExAmPlE.cOm

期待する応答:
wWw.ExAmPlE.cOm

文字ごとの大小表記が追加の識別情報になります。

ただし、すべてのDNS経路や実装で安定して利用できるとは限りません。DNSSECの代替でもありません。

現代のDNSキャッシュポイズニング攻撃

SAD DNS

SAD DNSは、Side-channel AttackeD DNSの略称です。

2020年のACM CCSで発表され、ICMPエラーメッセージのレート制限をサイドチャネルとして利用する攻撃が示されました。

サイドチャネルとは

金庫の暗証番号を直接見るのではなく、ボタンを押したときの音や処理時間から正解を推測するような攻撃です。

正式には、本来の通信内容ではない処理時間、エラー、共有カウンター、消費電力などの副次的な情報から、内部状態を推測する攻撃を指します。

SAD DNSの基本原理

UDPで閉じたポートへパケットが到着すると、OSはICMP Port Unreachableを返すことがあります。

一方、DNSリゾルバが問い合わせに使用中のポートは開いているため、同じ反応にならない場合があります。

OSがICMP応答数をシステム全体で制限していると、そのカウンターを観測して、どのポートが使われているかを絞り込める可能性があります。

攻撃者
  │
  ├─ ポート群へ偽UDPパケットを送信
  │
  ├─ ICMPレート制限の消費状態を確認
  │
  └─ 開いている可能性があるポートを絞り込む

送信元ポートが判明すると、攻撃者はDNSトランザクションIDの推測へ集中できます。

注意点

SAD DNSは、すべての環境で無条件に成功する攻撃ではありません。

成立条件は次の要素に依存します。

OSのICMP処理
カーネルのバージョン
ファイアウォール
ネットワーク経路
IPアドレス偽装の可否
DNSソフトウェア
レート制限の実装
攻撃者が問い合わせを誘発できるか

疑似乱数生成器の予測

現代のDNSリゾルバは、DNS IDやUDPポートを疑似乱数で選びます。

しかし、疑似乱数生成器の内部状態が推測できる場合、見かけ上ランダムでも将来の値を予測される可能性があります。

2025年のBIND 9脆弱性

2025年10月、ISCはBIND 9の疑似乱数生成器に関するCVE-2025-40780を公開しました。

特定の状況で、攻撃者がBINDの使用する送信元ポートとDNSクエリIDを予測できる可能性があり、偽応答の注入に成功するとキャッシュを汚染される問題です。

ISCは深刻度をHighと評価しています。

影響を受けるとされた主なバージョンは次のとおりです。

系列	影響範囲
BIND 9.16	9.16.0～9.16.50
BIND 9.18	9.18.0～9.18.39
BIND 9.20	9.20.0～9.20.13
BIND 9.21	9.21.0～9.21.12

修正版では、内部乱数生成器が暗号学的に安全な疑似乱数生成器へ変更されました。

2026年の研究発表

USENIX Security 2026では、「DNS Cache Poisoning Like it's 2006」と題するBIND 9研究が予定されています。

研究概要では、UDP送信元ポートとDNS IDの両方を予測し、一部の手法では攻撃者が管理する権威DNSサーバーを必要とせず、クライアント側から予測を行えると説明されています。

この研究はISCへ責任ある開示が行われ、関連するCVEと修正につながったとされています。

Gemini原稿の「2024年から2026年に発表された研究」という表現は広すぎます。

確認できる事実としては、脆弱性と修正版が2025年10月に公開され、詳細研究の発表予定がUSENIX Security 2026である、という整理が適切です。

不要な応答レコードの受け入れ

2025年には、BIND 9が問い合わせに直接必要でないレコードを寛容に受け入れる問題もCVE-2025-40778として修正されました。

特定の状況で、偽造されたレコードをキャッシュへ挿入できる可能性がありました。

影響範囲は次のように公表されています。

系列	影響範囲
BIND 9.11～9.16	9.11.0～9.16.50
BIND 9.18	9.18.0～9.18.39
BIND 9.20	9.20.0～9.20.13
BIND 9.21	9.21.0～9.21.12

修正版では、DNAMEや不要なNSレコードについて、TCP、DNS Cookie、TSIG、SIG(0)などの偽装耐性がある通信で受信した場合を除き、受け入れを制限する防御が追加されています。

この脆弱性は、1990年代から問題となってきた「どの応答レコードをキャッシュしてよいか」という境界検証が、現代でも重要であることを示しています。

UDPフラグメンテーション攻撃

DNSSECやEDNSによりDNS応答が大きくなると、UDPパケットがIPフラグメントへ分割されることがあります。

大きなDNS応答

フラグメント1
フラグメント2
フラグメント3

攻撃者が一部のフラグメントを偽造し、正規のフラグメントと誤って再構成させる攻撃が研究されています。

この手法では、完全なDNS応答全体を偽造するのではなく、一部の断片だけを差し替えることを狙います。

対策には次の方法があります。

DNSソフトウェアとOSを更新する
適切なEDNSバッファサイズを設定する
Path MTUを考慮する
必要に応じてTCPへフォールバックする
DNSSEC検証を行う
不審なフラグメントを監視する

ただし、UDP断片化をすべて遮断すると、正常なDNSSEC応答まで壊す可能性があります。

単純な全遮断ではなく、環境に応じた調整が必要です。

NATによるランダム化の弱体化

DNSリゾルバ自身が送信元ポートをランダムに選んでいても、NAT装置が外部側のポートを連番へ変換する場合があります。

DNSリゾルバ側

42153
58721
31984

       ↓ NAT変換

外部側

40001
40002
40003

この状態では、外部から見たポートの予測が容易になります。

RFC 5452も、NAT装置がUDP送信元ポートを直列化したり、使用可能なポート数を制限したりすると、ポートランダム化の効果が大幅に低下する可能性を指摘しています。

DNSサーバーだけでなく、経路上のファイアウォールやNAT装置も確認する必要があります。

BGPハイジャックとの組み合わせ

BGPハイジャックでは、攻撃者が不正な経路情報を広告し、特定のIPアドレス宛ての通信を一時的に自分のネットワークへ引き込みます。

DNSキャッシュポイズニングとは別の攻撃ですが、組み合わせると脅威が増します。

経路上に入れる攻撃者は、オフパス攻撃者より有利です。

通常

DNSリゾルバ ─────────▶ 正規権威DNS


経路乗っ取り時

DNSリゾルバ ─────▶ 攻撃者 ─────▶ 正規権威DNS

この状態では、攻撃者が問い合わせや応答を観測、遅延、遮断、改変できる可能性があります。

DNSSEC検証が正しく有効であれば、署名付きゾーンに対する偽データは原則として検証に失敗します。

DNSサーバーや端末の直接侵害

実際の攻撃では、高度なパケット競争を行わず、管理権限を奪ってDNS情報を書き換える手法もあります。

代表例は次のとおりです。

家庭用ルーターの管理画面を乗っ取る
DHCPで偽DNSサーバーを配布する
マルウェアが端末のDNS設定を変更する
/etc/hostsを書き換える
Active DirectoryのDNSを侵害する
クラウドDNSのAPIキーを盗む
レジストラアカウントを乗っ取る
権威DNSの管理画面を乗っ取る

これらは広義にはDNSハイジャックですが、通常のオフパス型キャッシュポイズニングとは区別すべきです。

攻撃の種類を整理

分類	攻撃対象	主な手法	キャッシュ汚染
オフパス偽応答	再帰DNS	ID・ポートを推測して偽応答送信	あり
カミンスキー型	再帰DNS	ランダムサブドメインとNS偽装	あり
SAD DNS	OS・再帰DNS	ICMPサイドチャネルでポート推測	あり
PRNG予測	DNS実装・OS	乱数状態からIDとポートを予測	あり
不要レコード注入	DNS実装	Authority・Additional情報の検証不備	あり
フラグメント注入	IP・UDP・DNS	DNS応答断片の差し替え	あり得る
オンパス改ざん	通信経路	DNS応答の盗聴・変更	あり得る
ルーター侵害	端末のDNS設定	DHCP、DNS設定を書き換え	通常はなし
権威DNS侵害	DNSゾーン	正規レコード自体を書き換え	通常はなし
レジストラ侵害	ドメイン委任	NSレコードや委任先を変更	通常はなし

DNSキャッシュポイズニングの影響

フィッシングサイトへの誘導

利用者が正しいドメインを入力しても、攻撃者のサーバーへ誘導されます。

利用者が入力
https://bank.example

DNS応答
bank.example → 攻撃者IP

ただし、HTTPS証明書を攻撃者が取得できない場合、ブラウザは証明書エラーを表示します。

利用者が警告を無視しなければ、被害を防げる可能性があります。

メールの盗聴や配送先変更

MXレコードが汚染されると、メール配送先を攻撃者のサーバーへ向けられる可能性があります。

example.com MX
mail.example.com

        ↓ 汚染

mail.attacker.example

ただし、実際の影響は送信側のDNSSEC検証、MTA-STS、DANE、TLS設定などに左右されます。

証明書発行への影響

認証局がドメイン所有確認にDNSを利用している場合、DNS情報の改ざんが証明書の不正発行につながる可能性があります。

ただし、現在の認証局では複数地点からの検証、CAA、DNSSECなどの防御が利用される場合があります。

DNSキャッシュポイズニングだけで必ず証明書を取得できるわけではありません。

ソフトウェア更新の改ざん

更新サーバーのDNS応答を偽装し、悪意あるファイルを配布する攻撃が考えられます。

ただし、更新パッケージがコード署名され、クライアントが署名を正しく検証していれば、DNSが改ざんされても不正パッケージを拒否できます。

DNSだけに依存せず、署名検証を組み合わせることが重要です。

自分の環境に関係するか

次のいずれかに該当する場合は、確認を推奨します。

BIND 9を運用している
Unboundやdnsmasqを社内DNSとして利用している
DNSサーバーを長期間更新していない
DNSSEC検証が無効
インターネットから再帰問い合わせを受け付けている
DNSサーバーがNAT配下にある
ファイアウォールでDNSの送信元ポートを狭く制限している
家庭用ルーターを長期間更新していない
DHCPで配布されるDNSサーバーを監視していない
権威DNSの管理アカウントに多要素認証を設定していない

特にBIND 9を利用している場合は、CVE-2025-40778とCVE-2025-40780の修正版が適用されているか確認してください。

確認方法

BINDのバージョンを確認する

目的

CVE-2025-40778、CVE-2025-40780などの影響を受ける可能性があるバージョンか確認します。

実行場所

BINDを稼働させているLinuxサーバーで実行します。

named -V

パッケージ情報も確認します。

Ubuntu、Debian系では次を実行します。

apt-cache policy bind9

RHEL、Rocky Linux、AlmaLinux、Oracle Linux系では次を実行します。

rpm -q bind bind-utils

正常例

BIND 9.18.40

ただし、ディストリビューションはセキュリティ修正をバックポートする場合があります。

バージョン番号だけでは判断せず、パッケージの変更履歴やベンダーアドバイザリも確認してください。

注意が必要な例

BIND 9.18.39

ISCが公開した上流版の範囲では、CVE-2025-40778とCVE-2025-40780の影響範囲に含まれます。

ただし、ディストリビューション独自の修正が適用済みの場合もあります。

判断方法

次の三点を確認します。

ISCが示す修正版以上か
OSベンダーが修正済みとしているか
パッケージのchangelogにCVE番号が記載されているか

BIND設定の構文を確認する

目的

設定ミスや廃止されたオプションがないか確認します。

実行場所

BINDサーバー上で実行します。

sudo named-checkconf

正常例

何も表示されず、終了コードが0になります。

echo $?

異常例

/etc/bind/named.conf.options:12: unknown option 'query-source'

判断方法

エラーが表示された場合は、該当行を修正してからBINDを再起動します。

設定変更前にはバックアップを取得してください。

sudo cp -a /etc/bind /etc/bind.backup.$(date +%Y%m%d-%H%M%S)

オープンリゾルバになっていないか確認する

目的

外部の第三者から再帰問い合わせを受け付けていないか確認します。

実行場所

管理対象ネットワークの外部にある端末から実行します。

dig @DNSサーバーの公開IP example.com A +recurse

正常例

外部向け再帰問い合わせを許可していない場合、次のような応答になります。

status: REFUSED

またはタイムアウトします。

異常例

status: NOERROR
flags: qr rd ra

外部から任意ドメインを再帰解決できる場合、オープンリゾルバになっている可能性があります。

判断方法

権威DNSと再帰DNSを兼用している場合は、問い合わせ元に応じて再帰を制限してください。

DNSSEC検証を確認する

目的

利用中のDNSリゾルバがDNSSEC署名を検証しているか確認します。

実行場所

DNSクライアントまたはDNSサーバー上で実行します。

dig dnssec-failed.org A

正常例

DNSSEC検証が有効で、署名検証に失敗した応答を拒否する場合です。

status: SERVFAIL

異常例

status: NOERROR

検証に失敗するよう用意されたドメインが通常解決できる場合、DNSSEC検証が無効である可能性があります。

追加確認

dig cloudflare.com A +dnssec

応答にadフラグが含まれる場合があります。

flags: qr rd ra ad

ただし、adフラグだけを無条件に信用してはいけません。

RFC 4035は、ADビットを安全な通信経路なしに信頼することへ注意を求めています。

クライアントと検証リゾルバ間が攻撃者に改ざんされないことも必要です。

使用中のDNSサーバーを確認する

systemd-resolved環境

resolvectl status

正常例

DNS Servers: 192.0.2.53
DNSSEC setting: yes

注意が必要な例

DNS Servers: 192.168.1.1

家庭用ルーターをDNSとして利用している場合、ルーターのDNS転送先、ファームウェア、管理画面のパスワードも確認します。

DNS応答を複数リゾルバで比較する

目的

利用中のDNSリゾルバだけが異なる応答を返していないか確認します。

実行場所

任意のLinux端末で実行します。

dig @利用中のDNS example.com A +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

正常例

CDNやGeoDNSによる差異を除き、想定範囲のIPアドレスが返ります。

異常例

利用中のDNSだけ、所有者不明のIPアドレスを返します。

判断方法

IPアドレスが異なるだけでは攻撃と断定できません。

CDN、負荷分散、地域別配信、Anycastによって正常に異なることがあります。

次の情報と合わせて調査します。

ASN
証明書
HTTPレスポンス
権威DNSへの直接問い合わせ
DNSSEC検証結果
TTL
問い合わせ時刻

権威DNSへ段階的に問い合わせる

目的

どのDNS階層で想定外の応答になっているか確認します。

実行場所

Linux端末で実行します。

dig example.com A +trace

正常例

ルートDNS、TLD DNS、対象ドメインの権威DNSの順に解決されます。

異常例

想定外のNSへ委任される
不明な権威DNSが返る
DNSSEC検証エラーがある
問い合わせごとに不自然な委任先へ変わる

注意事項

+traceは通常のローカルキャッシュDNSを経由せず、段階的に問い合わせます。

社内限定DNSやスプリットDNSの確認には適さない場合があります。

キャッシュを確認する

BINDでは、キャッシュ内容をダンプできます。

目的

不審なレコードがキャッシュされていないか確認します。

実行場所

BINDサーバー上で実行します。

sudo rndc dumpdb -cache

一般的な出力先を確認します。

sudo find /var -name named_dump.db -o -name cache_dump.db 2>/dev/null

確認例

sudo grep -n "example.com" /var/cache/bind/named_dump.db

注意事項

キャッシュダンプには大量のドメイン情報が含まれる可能性があります。

外部へ公開しないでください。

対処方法

最優先：DNSソフトウェアを更新する

BIND、Unbound、dnsmasq、PowerDNS Recursor、Windows DNSなどを、ベンダーが提供する修正版へ更新します。

Ubuntu、Debian系の例です。

sudo apt update
sudo apt install --only-upgrade bind9 bind9-utils dnsutils

RHEL系の例です。

sudo dnf update bind bind-utils

注意事項

更新前に、次を確認してください。

設定ファイルのバックアップ
セカンダリDNSの稼働状態
パッケージ変更内容
廃止設定の有無
更新後の再起動影響
DNSSEC鍵やトラストアンカーの状態

DNSSEC検証を有効にする

DNSSECは、DNSデータに付与された電子署名を検証し、正規のゾーン管理者が提供したデータであることと、途中で変更されていないことを確認します。

通常のDNS

ドメイン名 ──▶ IPアドレス
正しいか暗号的に確認できない


DNSSEC

ドメイン名 ──▶ IPアドレス
        ＋
      電子署名
        ＋
    信頼の連鎖

IETFのRFC 9364は、DNSSECをDNSデータの送信元認証に関するベストカレントプラクティスとしています。

BINDの設定例

options {
    dnssec-validation auto;
};

設定後に確認します。

sudo named-checkconf
sudo systemctl reload named

Ubuntuではサービス名がbind9の場合があります。

sudo systemctl reload bind9

Unboundの設定例

多くのディストリビューションでは、ルートトラストアンカーを設定するとDNSSEC検証を利用できます。

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

設定確認を行います。

sudo unbound-checkconf

DNSSECで防げること

DNSSEC検証が正しく行われている署名済みゾーンでは、次のような偽造を検知できます。

A、AAAAレコードの改ざん
MXレコードの改ざん
NSレコードの改ざん
CNAMEレコードの改ざん
存在しない名前を存在すると偽る応答
存在する名前を存在しないと偽る応答

署名検証に失敗したデータは、通常SERVFAILとして拒否されます。

DNSSECで防げないこと

DNSSECは暗号化ではありません。

問い合わせるドメイン名を隠しません。

また、次の攻撃を単独で完全に防ぐものではありません。

DNSへのDoS攻撃
DNSリゾルバの停止
権威DNSの停止
正規のゾーン署名鍵そのものの窃取
レジストラアカウントの乗っ取り
正規管理者による誤設定
DNSSEC未署名ゾーンへの偽応答
端末のhostsファイル改ざん
ブラウザやOSの侵害
正規サーバー自体の侵害
フィッシング用の類似ドメイン

DNSSECを導入しても、HTTPS、HSTS、多要素認証、EDRなどは引き続き必要です。

再帰問い合わせを制限する

BINDでは、再帰問い合わせを社内ネットワークや許可済みクライアントだけに制限します。

acl trusted_clients {
    127.0.0.1;
    192.0.2.0/24;
    2001:db8:100::/48;
};

options {
    recursion yes;
    allow-recursion {
        trusted_clients;
    };

    allow-query-cache {
        trusted_clients;
    };
};

インターネット公開の権威DNSでは、原則として再帰を無効化します。

options {
    recursion no;
};

権威DNSと再帰DNSは、可能であれば役割を分離します。

UDP送信元ポートを狭く固定しない

古い設定では、DNS問い合わせ元ポートを固定している場合があります。

query-source port 53;

このような固定設定は避けます。

また、ファイアウォールで外向きDNS通信の送信元ポートを53番だけに制限しないでください。

誤った考え方

DNSだから送信元も宛先も53番だけ許可する


正しい考え方

宛先は通常53番
送信元はエフェメラルポートを利用する

DNSサーバーから外部の権威DNSへ送信する通信では、広い範囲のUDP送信元ポートが必要です。

NATのポート変換を確認する

DNSサーバーがNAT配下にある場合、外部側のポートが単純な連番や固定値になっていないか確認します。

必要に応じて、次の対策を検討します。

DNSリゾルバへグローバルIPを直接割り当てる
NAT装置のポートランダム化を有効にする
DNS向けのポート保持機能を見直す
古いルーターやファイアウォールを更新する
DNSリゾルバを信頼できるマネージドサービスへ移行する

DNS Cookieを利用する

DNS Cookieは、DNS問い合わせと応答にクライアントCookieとサーバーCookieを付与し、偽装応答への耐性を高める仕組みです。

ただし、相手側のDNSサーバーも対応している必要があります。

DNSSECの代替ではなく、追加防御として利用します。

TCPへのフォールバックを妨げない

大きなDNS応答や切り詰められた応答では、UDPからTCPへ切り替わる場合があります。

ファイアウォールではUDP 53だけでなく、必要なTCP 53通信も許可します。

DNS通信

UDP 53
＋
TCP 53

TCPを無条件に遮断すると、DNSSEC応答や大きなレコードの取得に失敗する可能性があります。

IPアドレス偽装を防ぐ

DNSキャッシュポイズニングでは、攻撃者が権威DNSサーバーのIPアドレスを装って偽応答を送信する場合があります。

ネットワーク事業者や組織では、送信元アドレス検証を実施します。

BCP 38に基づく出口フィルタリング
uRPF
ACL
内部ネットワークからの不正送信元IPの遮断
境界ルーターでのbogonフィルタリング

ただし、非対称ルーティング環境で厳格なuRPFを有効にすると、正常通信を遮断することがあります。

事前検証が必要です。

権威DNSの管理を強化する

DNSキャッシュポイズニングだけでなく、DNS設定そのものの乗っ取りも防ぐ必要があります。

レジストラに多要素認証を設定する
レジストリロックを利用する
DNS管理APIキーを定期的に更新する
APIキーの権限を最小化する
ゾーン変更を監査ログへ記録する
NS、MX、CAAレコードの変更を監視する
DNSSEC鍵を適切に保護する
KSK、ZSKのロールオーバー手順を整備する
権威DNSを複数事業者へ分散する

HTTPSとHSTSを併用する

DNSが偽装されても、攻撃者が正規ドメインのTLS証明書を持っていなければ、HTTPS接続時に証明書エラーが発生します。

そのため、次の対策が重要です。

全通信をHTTPS化する
HTTPからHTTPSへリダイレクトする
HSTSを設定する
証明書エラーを無視しない
CookieにSecure属性を設定する
サービス間通信でも証明書を検証する

HSTS preloadを利用すると、初回アクセスからHTTPSを強制できます。

ただし、設定を誤ると長期間アクセス不能になる可能性があります。サブドメインを含める前に影響を確認してください。

動作確認

DNSサービスの状態を確認する

sudo systemctl status named

Ubuntuでは次の場合があります。

sudo systemctl status bind9

正常例です。

Active: active (running)

異常例です。

Active: failed

失敗している場合はログを確認します。

sudo journalctl -u named -n 100 --no-pager

設定変更後に名前解決を確認する

dig @127.0.0.1 example.com A

正常例です。

status: NOERROR

続けてDNSSEC検証を確認します。

dig @127.0.0.1 dnssec-failed.org A

正常な検証リゾルバでは、通常次のようになります。

status: SERVFAIL

TCPでの名前解決を確認する

dig @127.0.0.1 example.com A +tcp

正常例です。

status: NOERROR

TCPだけ失敗する場合は、ファイアウォールやセキュリティグループでTCP 53が遮断されていないか確認します。

キャッシュを消去する

BINDでは次のコマンドを使用できます。

sudo rndc flush

特定のドメインだけ消去する例です。

sudo rndc flushname example.com

注意事項

全キャッシュを消去すると、一時的に外部DNSへの問い合わせが増加します。

大規模環境では負荷増加を考慮してください。

インシデント発生時の対応

DNSキャッシュポイズニングが疑われる場合は、次の順番で対応します。

1. 影響範囲を確認する

どのDNSサーバーが不正応答を返しているか
何件のクライアントが利用しているか
どのドメインとレコードが影響を受けたか
いつから発生したか
キャッシュだけか、ゾーン自体が変更されたか

2. DNSサーバーを隔離する

必要に応じて、問題のあるリゾルバへの新規問い合わせを停止し、セカンダリや代替リゾルバへ切り替えます。

3. 証拠を保存する

キャッシュを消去する前に、次を保存します。

DNSキャッシュダンプ
namedログ
systemd journal
ファイアウォールログ
パケットキャプチャ
設定ファイル
パッケージバージョン
プロセス情報
管理画面の監査ログ

4. 脆弱性と侵入経路を確認する

DNSソフトウェアの脆弱性
OSカーネルの脆弱性
不正な設定変更
管理アカウント侵害
DHCP改ざん
ルーター侵害
レジストラ侵害
NATやファイアウォールの設定

5. 更新・修正する

DNSソフトウェアを更新
OSを更新
管理認証情報を変更
APIキーを失効
多要素認証を有効化
再帰問い合わせを制限
DNSSEC検証を有効化

6. キャッシュを消去する

証拠保存後に、不正なキャッシュを消去します。

7. 動作確認する

複数の外部DNS、権威DNS、DNSSEC検証結果を比較します。

8. 利用者へ通知する

フィッシングサイトや偽メールサーバーへ誘導された可能性がある場合は、次も検討します。

パスワード変更
セッショントークン失効
APIキー更新
証明書の確認
マルウェアスキャン
不審な送金やログイン履歴の確認

再発防止

DNSサーバー更新を定例化する

最低限、次の情報を定期確認します。

ISC BINDセキュリティアドバイザリ
Unboundのセキュリティ情報
OSベンダーのアドバイザリ
CISA Known Exploited Vulnerabilities Catalog
CVE情報
DNS-OARCの発表

BIND 9では、2025年にもキャッシュポイズニングに関係する複数の問題が修正されました。「送信元ポートランダム化を導入済みだから安全」と判断せず、継続的な更新が必要です。

DNSSECを監視する

DNSSECは設定して終わりではありません。

次を監視します。

RRSIGの有効期限
DSレコードの整合性
DNSKEYの公開状態
KSK、ZSKロールオーバー
署名処理の失敗
時刻同期
検証失敗率

署名期限切れやDSレコードの不整合が起きると、正規のドメインがSERVFAILになる可能性があります。

DNSログを集中管理する

次のイベントを監視します。

短時間に大量のランダムサブドメイン問い合わせ
同一ゾーンへの大量NXDOMAIN
異常に多いNS問い合わせ
DNSSEC検証失敗
不要なAdditionalレコード
応答元IPの変化
不自然に短いTTLや長いTTL
管理者によるゾーン変更
送信元ポートの偏り
大量のICMP Port Unreachable

ただし、CDN、セキュリティスキャナー、メール検証、存在しない名前を利用するサービスなどでも大量のNXDOMAINが発生します。

単一指標だけで攻撃と断定しないでください。

権威DNSと再帰DNSを分離する

インターネット向け

権威DNS
recursion no


社内向け

再帰DNS
許可済みネットワークのみ利用可能
DNSSEC validation on

役割を分離すると、設定ミスや攻撃の影響範囲を限定しやすくなります。

冗長化と複数事業者の利用

権威DNSを複数リージョン、複数ネットワーク、場合によっては複数事業者へ分散します。

ただし、複数事業者を利用する場合は、次を統一する必要があります。

ゾーンデータ
DNSSEC署名
TTL
変更手順
監査ログ
障害時の切り替え手順

注意点・よくある誤解

「HTTPSならDNS攻撃は関係ない」は誤り

HTTPSは非常に重要ですが、DNS攻撃の影響を完全に消すものではありません。

攻撃者が正規証明書を取得できない場合、ブラウザの警告が防御になります。

一方で、次の状況では追加リスクがあります。

利用者が証明書警告を無視する
正規証明書が不正発行される
HTTP通信が残っている
内部システムで証明書検証を無効化している
独自クライアントがTLS検証を実装していない

「DNS over HTTPSならキャッシュポイズニングを防げる」は不完全

DoHは、端末とDoHリゾルバ間の通信をHTTPSで暗号化します。

これにより、ローカルネットワーク上での盗聴や改ざんを防ぎやすくなります。

しかし、DoHリゾルバ自身が偽応答をキャッシュした場合や、上流のDNS処理が侵害された場合には解決しません。

端末
  │ 暗号化
  ▼
DoHリゾルバ
  │ 通常のDNS解決
  ▼
権威DNS

DoHは通信経路の保護です。

DNSSECはDNSデータの真正性検証です。

目的が異なります。

「DNSSECを設定すれば通信も暗号化される」は誤り

DNSSECは署名検証を行いますが、DNS問い合わせ内容を暗号化しません。

プライバシー保護には、DoH、DoT、DoQなどを組み合わせます。

技術	主な目的
DNSSEC	DNSデータの真正性・完全性
DoH	DNS通信のHTTPS暗号化
DoT	DNS通信のTLS暗号化
DoQ	DNS通信のQUIC暗号化
HTTPS	Web通信の暗号化とサーバー認証

「パブリックDNSを使えば絶対安全」は誤り

パブリックDNSは、一般に更新や監視が充実しています。

しかし、次の点は別途確認が必要です。

DNSSEC検証の有無
ログとプライバシーポリシー
社内限定DNSとの互換性
障害時の影響
DoHによる社内セキュリティ監視の迂回
マルウェア対策DNSとの競合

「DNS応答のIPが違えば攻撃」は誤り

CDN、GeoDNS、Anycast、負荷分散により、問い合わせ場所や時間によってIPアドレスが変わることがあります。

確認時は、IPアドレスだけでなく次も比較します。

ASN
証明書
HTTPヘッダー
権威DNS応答
TTL
DNSSEC
CDN事業者の公開情報

まとめ

DNSキャッシュポイズニングは、DNSリゾルバへ偽の名前解決情報を記憶させる攻撃です。

1990年代には、DNS応答のAdditionalセクションなどを過度に信用する実装が狙われました。

2008年のカミンスキー攻撃では、ランダムな存在しないサブドメインを使って問い合わせを繰り返し発生させ、DNSトランザクションIDを総当たりする手法が大きな問題となりました。

その後、問い合わせごとのUDP送信元ポートランダム化が普及しました。

しかし、2020年のSAD DNSは、ICMPレート制限を利用してポート情報を推測するサイドチャネルを示しました。

さらに2025年には、BIND 9の疑似乱数生成器と、不要な応答レコードの受け入れに関するキャッシュポイズニング脆弱性が修正されています。

現代の対策は、単独の機能に依存してはいけません。

次の多層防御が必要です。

DNSソフトウェア更新
        │
        ▼
ポート・IDランダム化
        │
        ▼
厳格な応答検証
        │
        ▼
DNSSEC検証
        │
        ▼
再帰問い合わせ制限
        │
        ▼
NAT・FW設定確認
        │
        ▼
HTTPS・HSTS
        │
        ▼
ログ監視・変更監査

特に重要なのは、DNSSEC検証と継続的なアップデートです。

送信元ポートランダム化は重要な緩和策ですが、疑似乱数生成器、OS、NAT、DNS応答処理に弱点があれば、効果が低下する可能性があります。

FAQ

Q1. DNSキャッシュポイズニングは現在でも発生しますか？

発生する可能性があります。

古典的な総当たり攻撃は難しくなりましたが、サイドチャネル、疑似乱数予測、実装上の検証不備、ルーター侵害、DNS管理アカウント侵害など、複数の攻撃経路があります。

Q2. カミンスキー攻撃は現在でも有効ですか？

当時と同じ単純な形では成功しにくくなっています。

問い合わせごとのUDP送信元ポートランダム化により、推測対象が大幅に増えたためです。

ただし、ポートを特定するサイドチャネルや、疑似乱数生成器の予測と組み合わせると、同様の攻撃構造が再び成立する可能性があります。

Q3. DNSSECを有効にすれば完全に防げますか？

署名済みゾーンに対する偽DNSデータの検出には非常に有効です。

ただし、DoS、レジストラ侵害、署名鍵の窃取、正規管理者の誤設定、端末侵害などは別途対策が必要です。

Q4. DoHとDNSSECはどちらを使うべきですか？

両方を利用することが理想です。

DoHは端末とDNSリゾルバ間の通信を暗号化します。

DNSSECはDNSデータの署名を検証します。

守る対象が異なります。

Q5. 家庭用ルーターも影響しますか？

影響します。

ルーターがDNSプロキシやキャッシュとして動作している場合、ルーターの脆弱性や管理画面の乗っ取りによって、不正なDNSサーバーを利用させられる可能性があります。

ファームウェア更新、強固な管理パスワード、外部管理の無効化を確認してください。

Q6. Webアプリケーション側でできる対策はありますか？

次の対策が有効です。

HTTPSを必須化する
HSTSを設定する
TLS証明書を正しく検証する
証明書エラーを無視しない
メール送信でMTA-STSやDANEを検討する
ソフトウェア更新ファイルへコード署名を行う
外部API接続で証明書検証を無効化しない
高リスク操作に多要素認証を要求する

CSRFトークンはDNSキャッシュポイズニングへの直接対策ではありません。

CSRFは、認証済みブラウザに意図しないHTTPリクエストを送らせるアプリケーション層の攻撃です。DNSキャッシュポイズニングとは、対象レイヤーと防御方法が異なります。

参考情報

RFC 1034: Domain Names - Concepts and Facilities
RFC 1035: Domain Names - Implementation and Specification
RFC 4033: DNS Security Introduction and Requirements
RFC 4034: Resource Records for DNSSEC
RFC 4035: Protocol Modifications for DNSSEC
RFC 5452: Measures for Making DNS More Resilient against Forged Answers
RFC 5452では、DNS応答の照合、送信元ポートのランダム化、NATやファイアウォールによるポート制限の問題などが扱われています。
RFC 8198: Aggressive Use of DNSSEC-Validated Cache
RFC 9364: DNS Security Extensions
RFC 9414: Unfortunate History of Transient Numeric Identifiers
ISC CVE-2008-1447
ISC CVE-2025-40778
ISC CVE-2025-40780
SAD DNS: DNS Cache Poisoning Attack Reloaded
USENIX Security 2026: DNS Cache Poisoning Like it's 2006