DNSキャッシュポイズニングとは？仕組み・被害事例・対策をわかりやすく解説

「DNSサーバーを乗っ取られると、正規のURLを入力しても偽サイトに誘導されるらしい」——そんな話を耳にして不安になった方もいるのではないでしょうか。特に中小企業で自前のDNSサーバーを運用している場合、DNSキャッシュポイズニングは知らないうちに被害が拡大しやすい攻撃です。

この記事では、DNSキャッシュポイズニング（DNSキャッシュ汚染）の仕組み、過去の被害事例、そして情シス1人でも実施できる具体的な防御手順を、現場で使えるレベルで解説します。攻撃の詳細な手順は掲載しませんが、「なぜ防げるのか」を理解できる構成にしています。

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

DNSキャッシュポイズニングは、DNSキャッシュサーバー（ドメイン名からIPアドレスを引く問い合わせ結果を一時保存する仕組み）に偽のIPアドレス情報を書き込ませ、利用者を攻撃者の用意した偽サイトへ誘導する攻撃です。「DNSスプーフィング」と呼ばれることもあります。

被害を受けた利用者は、ブラウザのアドレスバーに正しいドメイン（例: www.example.co.jp）を入力しているにもかかわらず、偽のWebサーバーへ接続してしまいます。URLが正規のままなので、利用者が攻撃に気づくのは極めて困難です。

なぜ今も警戒すべきなのか

DNSキャッシュポイズニングは2008年にダン・カミンスキー氏が発表した脆弱性（Kaminsky Attack）で広く知られるようになりました。多くのDNSサーバーで対策（送信元ポートのランダム化等）が施されましたが、2020年には「SAD DNS」（CVE-2020-25705、NVD: https://nvd.nist.gov/vuln/detail/CVE-2020-25705）という新たな攻撃手法が報告され、対策が不十分なサーバーは今なお狙われています。

攻撃の仕組み（敵を知る）

DNSキャッシュポイズニングを理解するには、まずDNSの基本的な動きを押さえる必要があります。

1. 通常のDNS問い合わせの流れ

利用者がブラウザで「www.example.co.jp」にアクセスしたとき、内部では次の流れで名前解決が行われます。

・ブラウザ: OSのDNSリゾルバに問い合わせ
・社内DNSキャッシュサーバー: キャッシュになければ外部の権威DNSサーバーへ問い合わせ
・権威DNSサーバー: 正しいIPアドレスを応答
・社内DNSキャッシュサーバー: 結果をキャッシュし、利用者に応答

2. 攻撃者が狙うポイント

攻撃者は、社内DNSキャッシュサーバーが権威DNSサーバーへ問い合わせている短い時間の間に、偽の応答パケットを先回りして送り込もうとします。社内DNSキャッシュサーバーが偽の応答を「正規の応答」と誤認してキャッシュに保存すると、そのキャッシュの有効期間（TTL）が切れるまで、社内の全利用者が偽IPアドレスへ誘導され続けます。

3. 偽応答を通してしまう条件

本来、偽応答はトランザクションIDと送信元ポート番号で弾かれる仕組みです。しかし次の条件が揃うと攻撃が成立しやすくなります。

・送信元ポートが固定: 毎回同じポートだと推測されやすい
・トランザクションIDが予測可能: 連番や低エントロピーだと総当たりされる
・DNSSECが未導入: 応答の真正性（電子署名による改ざん検知）が検証されない

過去の被害事例

DNSキャッシュポイズニングによる実被害は国内外で複数報告されています。一例を挙げます。

・2008年 Kaminsky Attack: 多くのDNSサーバーで脆弱性が発覚し、世界規模で緊急パッチ適用が行われた
・2014年 ブラジルの大手銀行: 同国内の家庭用ルーターのDNS設定が書き換えられ、オンラインバンキング利用者が偽サイトへ誘導された事例が報告された
・2020年 SAD DNS: Linuxカーネルのサイドチャネルを悪用し、送信元ポートのランダム化を部分的に回避できることが実証された

いずれも「正規ドメインにアクセスしているつもりが、偽サイトへ誘導される」という点で共通しており、利用者側の気づきが極めて難しい攻撃です。

具体的な防御手順

1. DNSSECを検証有効化する

DNSSEC（DNS Security Extensions）は、DNS応答に電子署名を付与し、改ざん検知を可能にする仕組みです。社内DNSキャッシュサーバー側で「署名検証を有効化」することで、偽応答の多くを水際で弾けます。

BIND 9（Linuxで広く使われる代表的なDNSサーバー）の場合、named.confに以下を記述します。

# /etc/named.conf のoptionsブロックに追記
# dnssec-validation は BIND 9.5 以降デフォルトでauto、明示推奨
options {
    recursion yes;
    allow-recursion { 192.168.0.0/16; };    # 社内からの問い合わせのみ許可
    dnssec-validation auto;                  # DNSSEC検証を有効化
    querylog yes;                             # 問い合わせログを記録
};

2. 送信元ポートとトランザクションIDをランダム化する

現代のDNSサーバー実装では、送信元ポートのランダム化は初期値で有効になっていることが多いですが、古いバージョンや独自のファイアウォール設定で意図せず固定化されるケースがあります。BIND 9では次のように明示確認すると安心です。

# query-source を明示しないのが推奨（固定ポート化を避ける）
# NGな例: query-source address * port 53;   ← ポート53に固定されてしまう
# OKな例: query-source address *;           ← ポートはランダム（デフォルト）

# 確認コマンド: BINDが待ち受けているポートを見る
# （短時間で複数のUDPポートが使われていれば正常）
ss -u -a -n | grep named

3. 再帰問い合わせを社内限定にする

DNSキャッシュサーバーがインターネット全体からの再帰問い合わせに応答していると、攻撃の踏み台にされるリスクが高まります。allow-recursionで社内セグメントに限定しましょう。

・allow-recursion: 再帰問い合わせを許可する送信元を社内ネットワークに限定
・allow-query: 問い合わせ自体を許可する送信元を制限
・ファイアウォール併用: UDP/TCP 53ポートの外部公開は必要最小限に

4. パッチ適用とバージョン管理

BINDをはじめとするDNSサーバーソフトには、定期的にセキュリティアップデートが提供されます。古いバージョンを放置すると、既知の脆弱性を突かれる可能性があります。Linuxの自動アップデート設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

中小企業でも今日からできること

予算や人手が限られていても、DNSキャッシュポイズニングのリスクは実務レベルで大きく下げられます。優先度順に整理しました。

「自前でDNSキャッシュサーバーを運用していない」企業も安心はできません。家庭用ルーターやONUのDNS設定が書き換えられる事例もあるため、機器の管理画面パスワードを初期値から変更し、ファームウェアを最新に保つことが第一歩です。

よくある誤解と注意点

誤解1: HTTPSだから偽サイトには飛ばされない

HTTPSは「通信の暗号化」と「通信相手のサーバー証明書検証」を担いますが、DNSが汚染されると、そもそもブラウザが偽のIPアドレスに接続します。偽サーバー側が適切な証明書を持っていなければブラウザは警告を出しますが、警告を無視する利用者は一定数存在します。HTTPSは最後の砦であり、DNS保護の代替にはなりません。

誤解2: DNSSECを有効にすれば100%防げる

DNSSECは強力ですが、署名していない多くのドメインに対しては効果が限定的です。また、キャッシュサーバー側の検証設定が中途半端だと素通りします。「100%安全」ではなく、「多層防御の1層」として位置付けるのが現実的です。

誤解3: 小さな会社は狙われない

DNSキャッシュポイズニングは、踏み台として悪用されることが少なくありません。攻撃者は「守りの薄い中小企業のDNS」を経由して、大手顧客企業や取引先を狙います。結果的に自社が加害側になり、取引先から責任を問われるリスクがあるのです。

注意: 攻撃実験は法律に触れる可能性

他人が管理するDNSサーバーや、許可を得ていないネットワーク上で攻撃を試す行為は、不正アクセス禁止法等に抵触する可能性があります。検証は必ず自社管理下の閉じた環境で行ってください。詳細は法律の専門家にご確認ください。

本記事のまとめ

DNSキャッシュポイズニングは、利用者が気づきにくい一方、対策の基本が整っていれば成立しにくい攻撃です。最後に押さえておきたいポイントを整理します。

・攻撃の本質: DNSキャッシュに偽のIP情報を書き込ませ、利用者を偽サイトへ誘導する
・攻撃の前提条件: 送信元ポートの固定化、トランザクションIDの予測可能性、DNSSEC未適用
・最優先の防御: DNSSEC検証の有効化、再帰問い合わせの社内限定、DNSサーバーソフトのアップデート
・HTTPSは代替にならない: DNS保護とサーバー証明書検証は別レイヤーの防御
・中小企業も標的: 踏み台化されて取引先被害に繋がるリスクがある

「明日から何をすればいいのか」を整理し、小さく始めて多層防御を積み上げていくことが、現実的で効果の高いアプローチです。

関連記事

• TLS・SSLとは？仕組み・HTTPS化・証明書の種類をわかりやすく解説
• WAFとは？Webアプリケーションファイアウォールの仕組み・選び方・導入手順をわかりやすく解説
• VPNとは？仕組み・種類・安全な選び方をわかりやすく解説