この記事では、DNSキャッシュポイズニングについて分かりやすく解説します。仕組みや攻撃シナリオ、対策などを順を追って説明します。
先に結論をお伝えすると、DNSキャッシュポイズニングは「DNSサーバに偽の住所録を覚えさせ、正しいURLを入力した利用者まで偽サイトへ連れて行く攻撃」です。DNSサーバ側の対策の柱は「ソースポートのランダム化」と「DNSSEC（署名の検証）」、利用者側では「HTTPSの証明書警告を無視しない」ことが最も効果的な自衛策になります。
DNSキャッシュポイズニングとは？
DNSキャッシュポイズニングは、DNSサーバが保持しているキャッシュ情報に偽のDNS情報を注入し、ユーザが本来とは異なるIPアドレスへ誘導されてしまう攻撃手法です。「ポイズニング（poisoning）」は「毒を盛る」という意味で、キャッシュを毒で汚染することから「DNSキャッシュ汚染」とも呼ばれます。
たとえば、私たちが普段Yahooのサイトにアクセスする時、「yahoo.com」といったドメインにアクセスしますが、裏側の処理としてはDNSサーバーで「yahoo.com」に対応するIPアドレスが呼び出され、実際にはそのIPアドレスのサーバーにアクセスしていることになります。
しかしDNSキャッシュポイズニングが成功してしまうと、攻撃者が用意した悪意のあるサーバ（フィッシングサイトなど）に接続するよう誤誘導されます。ブラウザのアドレスバーには正しいドメイン名が表示されたままなので、URLを見ても偽サイトだと気づきにくいのが、この攻撃の厄介な点です。
DNSスプーフィング・ファーミングとの違い
似た言葉がいくつかあるので、関係を整理しておきます。
| 用語 | 意味 |
|---|---|
| DNSスプーフィング | DNSの応答を偽装する攻撃の総称。DNSキャッシュポイズニングはその代表的な手口の1つ |
| DNSキャッシュポイズニング | DNSサーバ（リゾルバ）のキャッシュに偽の情報を覚えさせる攻撃。そのサーバを使う全員が影響を受ける |
| ファーミング（pharming） | 正しいURLを入力した利用者を偽サイトへ誘導する詐欺の総称。DNSキャッシュポイズニングのほか、パソコンのhostsファイルやルータのDNS設定の書き換えでも起こる |
通常のフィッシング詐欺は「偽のURLをクリックさせる」ことで成り立ちますが、DNSキャッシュポイズニングを使ったファーミングでは、利用者が正しいURLを自分で入力しても偽サイトに着いてしまいます。
DNSの基本的な仕組みとキャッシュ
DNS（Domain Name System）は、ドメイン名（例: example.com）をIPアドレス（例: 192.0.2.1）に変換する仕組みです。インターネットの「住所録」や「電話帳」にたとえられます。主な流れは以下のとおりです。
- DNSリゾルバ（DNSサーバ）に問い合わせ
クライアント（PCやスマートフォンなど）は、インターネットプロバイダ（ISP）や社内のDNSリゾルバに「example.comのIPアドレスを教えてほしい」と問い合わせます。 - DNSリゾルバによるキャッシュ確認
DNSリゾルバは、まず自分がもつキャッシュに「example.com」の情報があるかどうかを確認します。- キャッシュにあれば、それを返答して終わりです。
- キャッシュになければ、ルートDNSサーバや権威DNSサーバに問い合わせを進めます。
- キャッシュの保持（TTL）
DNSリゾルバは、取得した名前解決情報を一定時間（TTL: Time To Live）キャッシュしておきます。次回同じ問い合わせが来たときは、キャッシュからすぐに返答できるため通信の効率が上がります。
登場するDNSサーバは、役割によって次の2種類に分かれます。
| 種類 | 役割 | キャッシュポイズニングとの関係 |
|---|---|---|
| キャッシュDNSサーバ（フルリゾルバ） | 利用者からの問い合わせを受け、ほかのDNSサーバに聞いて回って答えを返す。結果をキャッシュする | 攻撃の標的。ISPや企業内に置かれていることが多い |
| 権威DNSサーバ | 自分が管理するドメインの正しい情報を持ち、問い合わせに答える | なりすまされる側。DNSSECで署名を付けると、偽の応答を見分けてもらえる |
DNSキャッシュポイズニングは、このDNSリゾルバが持つキャッシュの情報を偽装することで起きる攻撃です。1台のリゾルバを数千〜数万人が共有していることも珍しくないため、1回の汚染で多くの利用者が一斉に影響を受けます。
なお、パソコンやスマートフォン自身もDNSの結果を一時的にキャッシュしています。Macでこのキャッシュを消す方法は、次の記事で紹介しています。
MacのDNSキャッシュをクリアする方法｜バージョン別コマンドDNSキャッシュポイズニングの仕組み
DNSキャッシュポイズニングが成功すると、DNSキャッシュ内の情報が攻撃者によって書き換えられ（偽のIPアドレスに差し替えられ）、ユーザが意図せず攻撃者の管理するサイトへ誘導される可能性があります。一般的な手口は次のような流れです。
- リゾルバへの攻撃
攻撃者はDNSリゾルバに多数の偽の応答を送りつけます。リゾルバが正規サーバからの応答を待っている間に、攻撃者の偽応答を受け取ってしまうと、誤った情報がキャッシュされる可能性があります。DNSの問い合わせは主にUDPという、送信元を偽りやすい通信方式で行われるため、攻撃者は権威DNSサーバになりすまして応答を送れます。 - クエリIDやソースポートの推測
DNSリゾルバが名前解決のために送信するDNSクエリには「クエリID」という識別子が含まれており、これが一致した応答を「正当な応答」として処理します。- クエリIDは16ビット（約6万5千通り）しかなく、大量の偽応答を送れば当てられる可能性がある大きさです。
- ソースポート（問い合わせを送る通信の出口番号）も固定・予測可能なケースでは、攻撃者はクエリIDだけを当てればよいため、さらに攻撃が容易になります。
- キャッシュの書き換え
攻撃者がDNSリゾルバのクエリIDやソースポートをうまく推測しながら偽のDNS応答をリゾルバに届けると、正規サーバからの応答より先に受理されることがあります。リゾルバはこの偽情報を正しいものとしてキャッシュし、一定期間それをユーザに返すようになります。
このように、一時的でも攻撃者の偽応答が正規応答より先に「正しい応答」としてリゾルバに認識されると、キャッシュ内に誤った情報が格納され、ユーザは攻撃者の狙いどおりに誘導されてしまいます。
カミンスキー型攻撃（2008年）で脅威が一気に高まった
従来のキャッシュポイズニングは、狙ったドメインの情報がキャッシュに残っている間（TTLの間）は再挑戦できず、攻撃のチャンスが限られていました。ところが2008年7月、セキュリティ研究者のダン・カミンスキー氏が、この制約を回避する手法を発表します。
この「カミンスキー型攻撃」では、abc123.bank.example.com のような存在しないサブドメインへの問い合わせをリゾルバに次々と発生させます。存在しない名前はキャッシュにないため、リゾルバは毎回新しい問い合わせを送り、攻撃者はそのたびに偽応答を送り込むチャンスを得られます。偽応答の中に「bank.example.com の権威DNSサーバは攻撃者のサーバだ」という情報を紛れ込ませることで、ドメイン全体を乗っ取れてしまうのです。
この発表を受けて、各DNSソフトウェアはソースポートのランダム化に対応し、日本でもJPRS（日本レジストリサービス）などが対策の適用を呼びかけました。JPRSは2014年にも、国内の大手ISPでカミンスキー型攻撃と思われるアクセスが増えているとして、改めて緊急の注意喚起を行っています。
ランダム化を破る新しい攻撃も見つかっている（SAD DNS）
ソースポートのランダム化で攻撃は格段に難しくなりましたが、2020年11月には「SAD DNS」と呼ばれる手法が研究者によって発表されました。これは、OSが返すエラー通知（ICMPメッセージ）の数の制限を手がかりに、リゾルバが使っているソースポートを割り出すものです。ポートが分かってしまえば、残りはクエリIDを当てるだけになり、ランダム化の効果が打ち消されてしまいます。
LinuxカーネルやDNSソフトウェア側で緩和策が取られましたが、DNSのソフトウェア開発元であるNLnet Labsは、こうした緩和策はDNSの根本的な弱点を解決するものではなく、根本的な対策はDNSSECによる検証だと説明しています。「ランダム化すれば安全」ではなく、複数の対策を重ねる必要があることを示した事例です。
攻撃が成功するとどうなるのか？（シチュエーション例）
例：フィッシングサイトへの誘導
- ユーザが「bank.example.com」へアクセスしようとする。
- 企業やISPのDNSサーバが、bank.example.comを解決しようと権威サーバに問い合わせを始める。
- 攻撃者が、正規サーバの応答を待っている間に偽のDNS応答を送りつける。
- DNSサーバが誤って偽応答を受け取り、「bank.example.com」のIPアドレスとして攻撃者のフィッシングサイトをキャッシュしてしまう。
- その後、同じDNSサーバを利用しているユーザ全員が「bank.example.com」を開くと、攻撃者のサイトに誘導される。
- 見た目は本物そっくりのログインページだが、入力するとIDやパスワードが盗まれる。
例：マルウェア配布サイトへの誘導
- ユーザが正規のソフトウェア配布サイトへアクセスしようとする。
- 上記と同様の手口でDNSのキャッシュ情報が書き換えられる。
- ユーザがアクセスすると、実際には攻撃者が用意したマルウェア配布サイトへ誘導され、偽のソフトウェアをダウンロードしてしまう。
例：メールの盗み見・なりすまし
DNSはWebサイトだけでなく、メールの配送先（MXレコード）を調べるのにも使われています。メールサーバが参照するDNSが汚染されると、本来の宛先ではなく攻撃者のサーバにメールが届けられ、内容を盗み見られる恐れがあります。ブラウザと違って画面に警告が出ないため、気づきにくい被害です。
いずれの場合も、キャッシュが汚染されたDNSサーバを使うユーザは、正しいサイトにアクセスしていると信じてしまうため、被害が拡大しやすい点が特徴です。
攻撃を防ぐ対策（DNSサーバ管理者向け）
DNSキャッシュポイズニングを防ぐためには、複数の対策が考えられます。まず全体像を表で整理します。
| 対策 | 主に実施する人 | 効果 |
|---|---|---|
| ソースポートランダム化 | キャッシュDNSサーバの管理者 | 偽応答を当てる難しさを大きく上げる |
| DNSSECの署名 | ドメインの管理者（権威DNSサーバ） | 自分のドメインの情報に署名を付け、偽造を見分けられるようにする |
| DNSSECの検証 | キャッシュDNSサーバの管理者 | 署名が正しくない応答を受け取らない（根本的な対策） |
| ソフトウェアの最新化 | DNSサーバの管理者 | 既知の脆弱性をふさぐ |
| アクセス制限（オープンリゾルバ対策） | キャッシュDNSサーバの管理者 | 外部から問い合わせを受け付けず、攻撃のきっかけを減らす |
| ネットワーク機器での監視 | ネットワーク管理者 | 異常なDNS通信を検知・遮断する |
ソースポートランダム化
- ソースポートをランダム化し、攻撃者がクエリIDと合わせて推測しにくくする。クエリID（約6万5千通り）にソースポートの組み合わせが掛け算で加わるため、当てずっぽうで正解する確率は大きく下がります。
- 現在の多くのDNSソフトウェアはデフォルトで対応していますが、古い環境では設定が必要な場合があります。また、途中のファイアウォールやNAT（アドレス変換）装置がポート番号を連番に書き換えてしまい、ランダム化の効果が失われるケースもあるため、外から見て実際にランダムになっているかを確認しましょう。
DNSSECの導入
- DNSSEC（DNS Security Extensions）を導入すると、DNS応答が署名され、正当性を検証できるようになります。
- DNSSECでは応答にデジタル署名がつくため、偽の応答が送り込まれても検証に失敗し、キャッシュ汚染を防ぎやすくなります。
- 効果を発揮するには、ドメイン側の「署名」とキャッシュDNSサーバ側の「検証」の両方がそろう必要があります。どちらか一方だけでは偽の応答を見分けられません。
- 導入コストや運用面の課題もあるため、すべてのドメインで導入されているわけではありませんが、近年は徐々に普及が進んでいます。署名用の鍵の更新を失敗すると、正しい応答まで検証に失敗し、ドメインにアクセスできなくなる点には注意が必要です。
短いTTLの活用
- DNSレコードのTTL（キャッシュとして保持される有効期限）を短く設定し、キャッシュが長期間保持されないようにすることで、キャッシュ汚染の影響を小さくできます。
- ただしTTLが短すぎると問い合わせが増え、パフォーマンスに影響する場合があります。また、問い合わせの回数が増えるぶん、攻撃者が偽応答を送り込む機会も増えるため、TTLを短くすること自体は攻撃を防ぐ対策ではなく、被害が続く時間を短くするための調整と考えましょう。
DNSサーバソフトウェアの最新化
- DNSサーバソフトウェア（BINDやUnboundなど）を最新バージョンに保つことにより、既知の脆弱性を修正し、より安全な実装を利用できます。
- 古いバージョンではソースポート固定などの問題が残っている可能性があるため注意が必要です。SAD DNSのように新しい攻撃手法が見つかるたびに修正が出るため、JPRSやソフトウェア開発元の脆弱性情報を定期的に確認しましょう。
外部からの問い合わせを制限する（オープンリゾルバ対策）
- 社内用のキャッシュDNSサーバが、インターネット上の誰からの問い合わせにも答える「オープンリゾルバ」の状態になっていると、攻撃者は自由に問い合わせを発生させられ、キャッシュポイズニングを仕掛けやすくなります。
- 問い合わせを受け付ける範囲を社内ネットワークなどに限定し、権威DNSサーバとキャッシュDNSサーバは別々に運用するのが基本です。
ネットワーク機器での防御
- ルータやファイアウォールなど、ネットワーク機器でDNSトラフィックを監視し、不正なDNS応答をブロックする仕組みを整える。
- IDS/IPS（侵入検知システム/侵入防止システム）でDNSトラフィックを監視し、怪しい通信を検知・ブロックする対策も有効です。短時間に大量のDNS応答が届く、存在しないサブドメインへの問い合わせが急増するといった動きは、攻撃の兆候です。
一般の利用者ができる対策
DNSキャッシュポイズニングは主にDNSサーバ側の問題ですが、利用者側でも被害を避けるためにできることがあります。
- HTTPSの証明書警告を無視しない
偽サイトに誘導されても、攻撃者は本物のドメインの正しいSSL/TLS証明書を通常は持っていません。そのため、HTTPSのサイトであれば、ブラウザに「この接続ではプライバシーが保護されません」などの警告が表示されます。警告が出たら先に進まず、ページを閉じましょう。HTTPSの仕組みは「HTTP/HTTPSとは？ステータスコード・ヘッダー・TLSの仕組み」で解説しています。 - DNSSECを検証するDNSサービスを使う
Google Public DNS（8.8.8.8）、Cloudflare（1.1.1.1）、Quad9（9.9.9.9）などの主要なパブリックDNSは、DNSSECの検証に対応しています。プロバイダのDNSに不安がある場合は、利用を検討してもよいでしょう。 - ルータのファームウェアを更新し、管理画面のパスワードを変える
家庭用ルータのDNS設定が書き換えられると、キャッシュポイズニングと同じように偽サイトへ誘導されます。初期パスワードのまま使わず、ファームウェアも最新にしておきましょう。 - ログインはブックマークや公式アプリから行い、多要素認証を有効にする
万一偽サイトでIDとパスワードを入力してしまっても、多要素認証を設定していれば不正ログインの被害を防ぎやすくなります。
なお、DNS over HTTPS（DoH）やDNS over TLS（DoT）といった「DNSの暗号化」は、パソコンとDNSサーバの間の通信を盗み見や改ざんから守る技術です。DNSサーバ自体のキャッシュが汚染された場合は防げないため、DNSSECとは役割が異なる点に注意しましょう。
DNSキャッシュポイズニング対策を強化すべき理由
- 不正サイトへの誘導は被害が大きい
フィッシング詐欺やマルウェア配布など、多くのユーザが一度に被害を受けるリスクがあります。 - DNSはインフラの根幹
DNSはインターネット通信の基盤技術であり、多くのサービスに影響を与えます。 - 攻撃コストが比較的低い
過去にはクエリIDやソースポートを予測しやすい実装が多く、攻撃者の手間がそれほどかからない時期もありました。現在はランダム化などで対策が進んでいますが、SAD DNSのようにランダム化を回避する手法も見つかっており、油断は禁物です。
DNSキャッシュポイズニングに関するよくある質問
Q. 自分が攻撃を受けているかどうかは分かりますか？
A. 見た目だけで判断するのは困難です。手がかりになるのは、いつも使っているHTTPSのサイトで証明書の警告が出る、ログイン画面のデザインや動きがいつもと違う、といった違和感です。気になる場合は、スマートフォンのモバイル回線など別のネットワークから同じサイトにアクセスして比べる方法もあります。
Q. 自分のパソコンのDNSキャッシュを消せば安全になりますか？
A. 汚染されているのがプロバイダなどのDNSサーバであれば、手元のキャッシュを消しても、再びそのサーバから偽の情報を受け取ってしまいます。手元のキャッシュを消すのは、DNSサーバ側の問題が解消されたあとに、古い情報を早く捨てたいときに有効です。
Q. HTTPSのサイトなら被害を受けませんか？
A. HTTPSは大きな防御になりますが、利用者が証明書の警告を無視して進んでしまうと意味がありません。また、HTTPSに対応していないサイトや、メールのようにブラウザを介さない通信は守れません。DNSサーバ側の対策と、利用者側の注意の両方が必要です。
まとめ
- DNSキャッシュポイズニングはDNSサーバ（リゾルバ）のキャッシュに偽の情報を注入し、ユーザを悪意のあるサイトに誘導する攻撃です。正しいURLを入力しても偽サイトに着いてしまう点が、通常のフィッシングとの違いです。
- 攻撃者はクエリIDやソースポートを推測して偽のDNS応答を送り込み、正規応答より先にDNSサーバが受理するとキャッシュが汚染されます。2008年のカミンスキー型攻撃や2020年のSAD DNSなど、攻撃手法は進化を続けています。
- 対策としては、ソースポートのランダム化・DNSSECの導入・ソフトウェアの最新化・オープンリゾルバ対策・ネットワーク機器での監視などが挙げられます。
- 利用者側では、HTTPSの証明書警告を無視しないこと、DNSSECを検証するDNSサービスの利用、ルータの管理などが有効です。
DNSはインターネット利用に欠かせない仕組みであり、その脆弱性を突いた攻撃は大きな被害につながります。管理者の方は日頃からDNSサーバの設定やバージョンを確認し、必要に応じてDNSSECの導入などセキュリティ対策を実施することが重要です。
サニタイズとは？エスケープ・バリデーションとの違いと実装方法を解説
