DNSキャッシュポイズニングとは？ わかりやすく10分で解説

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

DNSキャッシュポイズニング（DNS Cache Poisoning）とは、DNS（Domain Name System）のキャッシュに不正な名前解決結果（偽のIPアドレスなど）を混入させることで、利用者を攻撃者の用意したサーバへ誘導する攻撃です。広い意味ではDNSスプーフィング（DNS Spoofing）に含まれることが多く、結果として「本物のサイトにアクセスしたつもりなのに、偽サイトに接続してしまう」状況を引き起こします。

たとえば、利用者が狙われたドメイン名を問い合わせた際に、キャッシュが汚染されていると、DNSサーバ（または中継するリゾルバ）が偽の応答を返してしまい、ブラウザやアプリが誤った接続先へ向かいます。この攻撃が厄介なのは、汚染されたキャッシュが残る間、同じリゾルバを使う利用者にも影響が広がり得る点です。見た目が本物そっくりな偽サイトへ誘導されると、認証情報の詐取やマルウェア感染につながる恐れがあります。

• 何が起きるか：DNSリゾルバのキャッシュに偽の応答が残り、正しいドメイン名でも誤った接続先へ誘導される
• 何が危険か：フィッシング、マルウェア感染、認証情報の窃取、業務影響が同時に起こり得る
• 何を押さえるか：DNSSEC、リゾルバ側の防御、端末側の被害抑止策を分けて考える

DNSの基本概念

DNSは、ホスト名（例：www.example.com）をIPアドレス（例：203.0.113.10）に変換する仕組みです。人間に覚えやすいドメイン名でアクセスできるようにする一方、システム内部ではIPアドレスを使って通信先を特定します。

DNSの重要な特徴の一つが「キャッシュ」です。リゾルバ（DNS問い合わせを代行するサーバ）は、直近の問い合わせ結果を一定時間保存し、同じ問い合わせが来たときに素早く応答できるようにします。このキャッシュの利便性が、攻撃の標的にもなります。

DNSキャッシュポイズニングの仕組み

DNSキャッシュポイズニングでは、攻撃者がDNSリゾルバのキャッシュに偽の名前解決結果を保存させることを狙います。キャッシュが汚染されると、以後そのリゾルバを利用する端末は、同じドメイン名の問い合わせに対して誤ったIPアドレスへ誘導される可能性があります。

攻撃が成立する条件や手口は複数ありますが、要点は共通しています。すなわち、DNSが「問い合わせと応答の正当性」を十分に担保できない状態だと、攻撃者の偽応答が紛れ込み、キャッシュとして残ってしまうことがある、という点です。

DNSキャッシュポイズニングのリスク

DNSキャッシュポイズニングは、通信の入口（名前解決）を乗っ取るため、影響範囲が広がりやすい攻撃です。代表的なリスクは次の通りです。

• 偽サイト誘導（フィッシング）：正規サイトのつもりでアクセスし、ID・パスワードや決済情報を入力してしまう
• マルウェア感染：偽サイトから不正ファイルや悪意あるスクリプトを配布される
• ブランド毀損：利用者が「公式サイトが危険だった」と誤認し、信用低下につながる
• 業務影響：業務SaaSや社内システムへの接続が失敗・迂回し、業務停止や障害対応コストが発生する

DNSキャッシュポイズニングで起こり得る被害

DNSキャッシュポイズニングでは、利用者がURLを間違えたわけではなく、名前解決の段階で接続先がすり替わります。そのため、正しい操作をしていても被害に遭うおそれがあります。実務では、利用者被害に加えて、問い合わせ増加や業務停止といった影響も起こり得ます。

顧客ロイヤルティの低下

利用者が正規サイトにアクセスできず、偽サイトやエラーに遭遇すると、サービス全体への不信感が高まるおそれがあります。とくにログインや決済といった重要な導線で問題が起きると、離脱や問い合わせ増加につながり、結果として継続利用意向に影響する可能性があります。

ブランドイメージの損傷

攻撃がDNSやネットワーク側の問題であっても、利用者からは「その会社のサイトが危険だった」と受け取られるおそれがあります。SNS等での拡散や風評が起きれば、復旧後もしばらく不信感が残り、ブランドイメージに影響する可能性があります。

マルウェアのインストール

偽サイトに誘導された結果、端末にマルウェアが入ると、個人端末の被害に留まらず、組織ネットワークへの侵入や横展開の起点になる可能性があります。感染の疑いが出るだけでも、調査・隔離・復旧の負荷が発生します。

クレデンシャルの盗難

最も深刻になりやすいのが認証情報の詐取です。偽のログイン画面に誘導され、ID・パスワード、ワンタイムコード、あるいは個人情報を入力してしまうと、アカウント乗っ取りや二次被害につながります。

DNSキャッシュポイズニングはどう起きるか

DNSキャッシュポイズニングは「DNSの応答が信用される」ことを悪用します。典型的なパターンでは、攻撃者が偽のDNS応答を紛れ込ませ、正規ドメイン名が攻撃者のサーバIPに解決される状態を作ります。その後、利用者は普段どおりURLを入力しても偽サイトに到達します。

ここで重要なのは、攻撃がDNSというインフラ層で起きると、Webブラウザやメールクライアントなど複数の利用経路に波及し得る点です。影響が「そのサイトだけ」に見えて、実際は「そのDNSを使う利用者全体」に及ぶ可能性があります。

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

DNSスプーフィングは、DNS応答を偽装して利用者を誤った接続先へ導く行為全般を指す広い呼び方として使われます。一方、DNSキャッシュポイズニングは、その中でもDNSリゾルバのキャッシュに偽情報が残り、影響が継続しやすい点に焦点を当てた表現です。

違いを押さえておくと、単発の偽応答と、キャッシュ汚染によって同じリゾルバを使う利用者へ影響が広がるケースを切り分けやすくなります。本記事では後者を中心に扱います。

DNSキャッシュポイズニングへの対策

DNSキャッシュポイズニングは、一つの対策だけで防ぎ切れる攻撃ではありません。DNSの設計、リゾルバ運用、端末側の防御を組み合わせて被害を抑える必要があります。ここでは主な対策を順に見ていきます。

整理すると、対策は大きく①偽応答を受け入れにくくする対策 ②改ざんされた応答を検証する対策 ③誤誘導が起きた後の被害を抑える対策に分けられます。どれか一つだけで十分と考えるのではなく、どの層を強化する施策なのかを切り分けて読むと判断しやすくなります。

DNSSECの導入（署名と検証の両方）

DNSSEC（Domain Name System Security Extensions）は、DNS応答に電子署名を付与し、受け取った側が「改ざんされていない正当な応答か」を検証できるようにする仕組みです。権威DNS側で署名し、リゾルバ側で検証できる環境では、DNS応答の改ざん検知や偽応答混入の抑止に有効です。

ただし、DNSSECは権威DNS（ドメインを管理する側）での署名と、リゾルバ側での検証が揃ってはじめて効果が出ます。導入時は運用設計（鍵管理、ロールオーバー、障害時の影響）まで含めた検討が必要です。

リゾルバ側の防御（キャッシュ汚染を起こしにくくする）

組織で利用するDNSリゾルバ（社内DNS、フォワーダ、セキュアDNS等）について、キャッシュ汚染が起こりにくい設定・実装になっていることが重要です。例として、問い合わせと応答の関連付け強化、不要な再帰設定の見直し、外部公開範囲の最小化などが挙げられます。

DNS通信の盗聴・改ざん対策（経路保護）

DNSキャッシュポイズニングそのものは「偽応答を混ぜる」問題ですが、ネットワーク上でDNS通信が覗かれたり改ざんされたりする環境だと、攻撃が成立しやすくなる場合があります。環境に応じて、DNSの通信経路を保護する選択肢（例：組織標準のセキュアDNSの利用等）を検討します。

エンドポイント対策（被害の顕在化を抑える）

DNSレイヤで誤誘導が起きても、最終的な被害（マルウェア実行、認証情報入力）を止められることがあります。端末側では、脅威対策製品の更新、ブラウザ保護、危険サイトブロック、資格情報保護、OS・アプリのアップデートを継続することが重要です。

※誤解されやすい点：MTA-STSは一般的なDNSキャッシュポイズニング対策の主軸ではない

MTA-STSは、SMTPのメール配送で、送信側MTAが受信側ドメインのポリシーに基づいてTLS利用や証明書要件を確認するための仕組みです。SMTPに関するダウングレードやMX関連の誤誘導リスク低減には役立ちますが、Web閲覧を含む一般的なDNSキャッシュポイズニング対策そのものではありません。DNSキャッシュポイズニング全般の主対策は、DNSSECやリゾルバ側の防御です。

DNSキャッシュポイズニングを疑うサイン

DNSキャッシュポイズニングは、利用者から見ると「URLは正しいのに挙動がおかしい」という形で現れやすい攻撃です。次のような兆候がある場合は、DNSレイヤの問題も視野に入れて確認します。

• 特定サイトだけ接続先や表示内容が不自然に変わる
• 別の端末や別回線では正常に利用できる
• TLS証明書の警告やログイン画面の違和感が出る
• 社内で同じドメインに関する問い合わせや障害報告が急に増える

これらの兆候だけでDNSキャッシュポイズニングと断定はできませんが、端末だけの問題か、利用中のリゾルバやDNS経路まで調べるべきかを切り分ける手がかりになります。

DNSキャッシュポイズニングを防ぐための運用ポイント

適切なセキュリティポリシーの確立

DNSは普段は意識されにくい基盤です。そのぶん後回しになりやすいため、リゾルバの管理責任、利用するDNSの標準、監視・ログ保全、障害時の切り戻し手順をあらかじめ決め、例外運用を増やさないことが欠かせません。

定期的なセキュリティチェックとアップデート

DNSサーバ（リゾルバ／権威DNS）、境界機器、端末のアップデートを継続し、既知の脆弱性を残さないことが基本です。加えて、DNS関連ログ（名前解決の失敗、異常な応答、急増する特定ドメイン問い合わせ等）を見られる状態にしておくと、異常検知が容易になります。

インシデントレスポンス計画

疑わしい兆候が出た際に、どのDNSを切り替えるのか、キャッシュをどう扱うのか、利用者に何を案内するのか、関係部署へどう連絡するのかを事前に決めておきます。DNSは影響範囲が広いので、初動の遅れが被害拡大につながりやすい領域です。

教育とトレーニング

利用者向けには「URLが正しいのに挙動がおかしい」「証明書警告が出る」「ログイン画面が不自然」などの気づきポイントを周知します。運用者向けには、DNSの基礎、ログの見方、切り分け手順、DNSSECの運用要点などを定期的に確認しておくと、対応の質が上がります。

DNS運用が複雑になるほど対策の抜けが生まれやすい

攻撃者は、フィッシングやマルウェア配布の成功率を高めるため、利用者を誤った接続先へ誘導できる経路を狙います。DNSもその一つです。クラウド利用、リモートワーク、拠点増加によってDNSの経路や運用が複雑になるほど、設定不備や例外運用が攻撃の足がかりになりやすくなります。

一方で、防御側にもDNSSECやリゾルバの防御機能といった選択肢があります。DNSを後回しにせず、誰が管理し、何を監視し、異常時にどう切り替えるかを平時から決めておくことが、対策の抜けを減らす近道です。

まとめ

DNSキャッシュポイズニングは、DNSのキャッシュに偽の名前解決結果を混入させ、利用者を偽サイトや攻撃者のサーバへ誘導する攻撃です。被害はフィッシングやマルウェア感染、認証情報の窃取、ブランド毀損など多岐にわたります。

対策の柱は、DNSSEC、リゾルバ側の防御、ログ監視、アップデート、そしてインシデント対応体制の整備です。DNSは普段は目立ちませんが、ひとたび問題が起きると影響が広がりやすい基盤です。異常時に慌てて判断しないよう、平時のうちに運用手順と監視体制を具体化しておく必要があります。