DNSキャッシュポイズニングについて

DNSキャッシュポイズニングとは、DNSサーバーや端末に保存されているDNSキャッシュへ偽の情報を紛れ込ませ、ユーザーを本来とは異なる接続先へ誘導する攻撃です。

たとえば、ユーザーが正しいURLを入力しているにもかかわらず、攻撃者が用意した偽サイトにアクセスさせられる可能性があります。

DNSは、ドメイン名とIPアドレスを対応させる仕組みです。

通常、ユーザーがWebサイトへアクセスすると、DNSによってドメイン名がIPアドレスに変換されます。

example.com → 93.184.216.34

この名前解決の結果は、毎回問い合わせると時間がかかるため、一定期間キャッシュとして保存されます。

DNSキャッシュポイズニングは、このキャッシュに偽の名前解決情報を保存させることで、通信先をすり替える攻撃です。

DNSキャッシュの仕組み

DNSはドメイン名をIPアドレスに変換する仕組み

インターネット上の通信では、コンピューター同士はIPアドレスを使って通信します。

しかし、人間にとってIPアドレスを覚えるのは難しいため、通常は次のようなドメイン名を使います。

example.com

このドメイン名を、実際に通信できるIPアドレスへ変換する仕組みがDNSです。

example.com → 93.184.216.34

DNSはよく「インターネットの電話帳」と表現されます。

人間が覚えやすい名前を、コンピューターが通信できる住所へ変換する役割を持っています。

DNSキャッシュは問い合わせ結果を一時保存する

DNS問い合わせは、毎回すべてのDNSサーバーへ確認すると時間がかかります。

そのため、PC、ブラウザ、ルーター、企業のDNSサーバー、ISPのDNSサーバーなどは、過去に取得したDNS情報を一定期間保存します。

これがDNSキャッシュです。

たとえば、初回アクセス時にはDNSへ問い合わせます。

1回目：DNSへ問い合わせる
example.com → 93.184.216.34

その後、同じドメインへ再度アクセスする場合は、保存済みのキャッシュを利用します。

2回目以降：キャッシュを利用する
example.com → 93.184.216.34

DNSキャッシュにより、Webサイトの表示速度が向上し、DNSサーバーへの負荷も軽減されます。

一方で、このキャッシュに偽情報が保存されると、ユーザーは誤った接続先へ誘導されてしまいます。

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

偽のDNS応答をキャッシュさせる攻撃

DNSキャッシュポイズニングでは、攻撃者がDNSリゾルバに対して偽のDNS応答を送り込みます。

DNSリゾルバとは、ユーザーの代わりにDNS問い合わせを行うサーバーのことです。

企業ネットワークやISP、パブリックDNSサービスなどで利用されています。

本来、DNSリゾルバは正規のDNSサーバーから応答を受け取り、その結果をキャッシュします。

しかし、攻撃者が偽の応答を本物の応答より早く送り込み、DNSリゾルバがそれを正しいものと誤認すると、偽情報がキャッシュされます。

本来の情報：
bank-example.com → 正規サーバーのIPアドレス

偽の情報：
bank-example.com → 攻撃者サーバーのIPアドレス

この偽情報がキャッシュされると、そのDNSリゾルバを利用するユーザーは、正しいドメイン名を入力しているにもかかわらず、攻撃者のサーバーへ誘導されます。

攻撃の基本的な流れ

DNSキャッシュポイズニングの基本的な流れは、次の通りです。

1. DNSリゾルバが正規のDNS情報を問い合わせる
2. 攻撃者が偽のDNS応答を送り込む
3. DNSリゾルバが偽応答を本物と誤認する
4. 偽のDNS情報がキャッシュされる
5. ユーザーが偽の接続先へ誘導される

一度キャッシュが汚染されると、そのDNSリゾルバを利用している複数のユーザーに影響が広がる可能性があります。

そのため、DNSキャッシュポイズニングは、個人だけでなく企業やサービス運営者にとっても重要なセキュリティリスクです。

DNSキャッシュポイズニングが危険な理由

正しいURLでも偽サイトへ誘導される可能性がある

DNSキャッシュポイズニングの怖さは、ユーザーが不審なURLをクリックしていなくても被害に遭う可能性がある点です。

通常のフィッシングでは、攻撃者が偽メールや偽SMS、偽広告などを使って、ユーザーに偽URLをクリックさせます。

一方、DNSキャッシュポイズニングでは、ユーザーが正しいURLを入力しても、DNSの名前解決結果が改ざんされているため、偽サイトへ誘導される可能性があります。

ユーザーの操作：
正しいURLを入力する

DNSキャッシュの状態：
偽のIPアドレスが保存されている

結果：
攻撃者のサーバーへ接続される

このため、ユーザー自身がURLを確認していても、攻撃に気づきにくい場合があります。

複数のユーザーに影響が広がる

DNSキャッシュポイズニングは、共有DNSリゾルバが攻撃された場合に影響範囲が広がります。

たとえば、企業のDNSサーバー、学校や公共施設のネットワーク、ISPのDNSサーバーなどが汚染されると、そのDNSを利用する多くのユーザーが同じ偽情報を参照してしまいます。

1台のDNSリゾルバのキャッシュが汚染される
↓
そのDNSリゾルバを使う複数のユーザーが影響を受ける

攻撃者にとっては、個別ユーザーを一人ずつだますよりも効率的な攻撃になります。

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

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

DNSキャッシュポイズニングにより、ユーザーが正規サイトへアクセスしたつもりでも、偽サイトへ誘導される可能性があります。

特に金融機関、ECサイト、クラウドサービス、社内システムなどのログインページが偽装されると、深刻な被害につながります。

認証情報の窃取

偽サイトへ誘導されたユーザーがログイン情報を入力すると、攻撃者にIDやパスワードを盗まれる可能性があります。

被害の対象になる情報には、次のようなものがあります。

ログインID
パスワード
ワンタイムパスワード
認証コード
クレジットカード情報
個人情報

多要素認証を導入していても、リアルタイム型のフィッシングと組み合わせられると、認証コードが悪用されるリスクがあります。

マルウェア感染

攻撃者が用意した偽サイトへ誘導されることで、不正なファイルのダウンロードやマルウェア感染につながる場合があります。

たとえば、偽のアップデート画面や偽のセキュリティ警告を表示し、ユーザーに不正ソフトウェアをインストールさせる手口が考えられます。

メール配送先のすり替え

DNSでは、WebサイトのIPアドレスだけでなく、メール配送に使われるMXレコードも管理されています。

DNSキャッシュが汚染され、MXレコードが偽の値に置き換えられると、メール配送先が攻撃者の管理するサーバーへ向けられる可能性があります。

ただし、現代のメール環境ではTLS、SPF、DKIM、DMARC、MTA-STS、DANEなど複数の仕組みが関係します。

そのため、単純にすべてのメールが盗聴・改ざんされるとは限りません。

より正確には、メール配送先のすり替え、配送妨害、情報窃取のリスクが生じると考えるべきです。

ブランド毀損や売上機会の損失

Webサイト運営者や企業にとっては、DNSキャッシュポイズニングはブランド毀損にもつながります。

ユーザーが正規サイトにアクセスしたつもりで偽サイトに誘導され、被害に遭った場合、企業への信頼が大きく低下します。

また、ECサイトや問い合わせサイトでは、購入・申し込み・資料請求などのコンバージョン機会が失われる可能性もあります。

DNSキャッシュポイズニングとフィッシングの違い

フィッシングはユーザーをだます攻撃

フィッシングは、偽メール、偽SMS、偽広告、SNS投稿などを使って、ユーザーを偽サイトへ誘導する攻撃です。

多くの場合、攻撃者は正規サイトに似たURLやデザインを用意し、ユーザーにログイン情報や決済情報を入力させようとします。

DNSキャッシュポイズニングは名前解決をだます攻撃

DNSキャッシュポイズニングは、ユーザーの判断ではなく、DNSの名前解決の仕組みを悪用します。

ユーザーが正しいURLを入力しても、DNSキャッシュに偽情報が保存されていれば、攻撃者のサーバーへ誘導される可能性があります。

項目	フィッシング	DNSキャッシュポイズニング
主な攻撃対象	ユーザー心理	DNSの名前解決
誘導方法	偽メール・偽SMS・偽広告など	偽のDNS情報
URL	偽URLを使うことが多い	正しいURLでも被害に遭う可能性がある
気づきやすさ	URL確認で気づける場合がある	気づきにくい場合がある
影響範囲	個別ユーザー中心	DNSリゾルバ利用者全体に広がる可能性がある

DNSキャッシュポイズニングが成立する主な要因

従来型DNSには暗号学的な応答認証がない

従来型のDNSでは、DNS応答が本当に正規のDNSサーバーから返されたものかを、電子署名によって検証する仕組みが標準ではありません。

通常のDNS応答では、主に次のような情報を照合します。

トランザクションID
問い合わせ名
問い合わせタイプ
送信元・宛先
UDPポート

しかし、これらは暗号学的な真正性確認ではありません。

そのため、攻撃者が条件に合う偽応答を送り込むことができれば、DNSリゾルバが偽情報を受け入れてしまう可能性があります。

UDPの特性が悪用されやすい

DNSでは、伝統的にUDPが多く使われてきました。

UDPは高速で軽量ですが、TCPのような接続確立がありません。

そのため、偽装された応答を送り込みやすい面があります。

ただし、問題の本質は「UDPだから危険」という単純な話ではありません。

正確には、次の要素が組み合わさることで、DNSキャッシュポイズニングのリスクが高まります。

DNSがUDPを多用する
UDPはコネクションレスである
従来型DNSには暗号学的な応答認証がない
トランザクションIDや送信元ポートを推測される可能性がある

つまり、UDP利用そのものではなく、DNSの応答検証の弱さと組み合わさることで問題になります。

トランザクションIDや送信元ポートの推測

DNS問い合わせには、問い合わせと応答を対応させるためのトランザクションIDがあります。

古いDNS実装では、このIDが予測しやすい場合がありました。

攻撃者が正しいトランザクションIDを推測できると、偽応答が受け入れられる可能性が高まります。

また、DNS問い合わせに使う送信元ポートが固定されていたり、予測しやすかったりすると、攻撃成功率が上がります。

そのため、現在では多くのDNSリゾルバで、トランザクションIDや送信元ポートのランダム化が行われています。

Kaminsky攻撃とは

DNSキャッシュポイズニングを現実的な脅威として広めた攻撃

Kaminsky攻撃とは、2008年に広く知られるようになったDNSキャッシュポイズニングの手法です。

この攻撃では、ランダムなサブドメインへの問い合わせを大量に発生させることで、攻撃者が偽応答を送り込む機会を増やします。

たとえば、次のような存在しないサブドメインを大量に問い合わせさせます。

aaa.example.com
bbb.example.com
random123.example.com
random456.example.com

問い合わせのたびに、攻撃者は偽のDNS応答を大量に送信します。

NSレコードの汚染を狙う点が重要

Kaminsky攻撃で重要なのは、単に特定のAレコードを偽装するだけではなく、NSレコードなどの権威DNSサーバー情報を汚染する点です。

たとえば、攻撃者は次のような偽情報をキャッシュさせようとします。

example.com の権威DNSサーバーは攻撃者のサーバーである

これが成功すると、example.com 配下の多くの名前解決が攻撃者の影響下に置かれる可能性があります。

Kaminsky攻撃をきっかけに、DNSリゾルバでは送信元ポートのランダム化などの対策が広く導入されました。

DNSキャッシュポイズニングと関連用語の違い

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

DNSスプーフィングとは、偽のDNS応答を使って、ユーザーやDNSリゾルバを誤った接続先へ誘導する攻撃の総称です。

DNSキャッシュポイズニングは、DNSスプーフィングの代表的な手法の一つです。

DNSスプーフィング：偽のDNS応答を使う攻撃全般
DNSキャッシュポイズニング：DNSキャッシュに偽情報を保存させる攻撃

DNSハイジャックとの違い

DNSハイジャックは、DNSの設定や名前解決の流れを不正に乗っ取り、通信先を変える広い概念です。

DNSハイジャックには、次のようなものが含まれます。

レジストラアカウントの乗っ取り
DNSホスティングサービスの不正操作
ルーターのDNS設定改ざん
マルウェアによる端末のDNS設定変更
DNSキャッシュポイズニング

つまり、DNSキャッシュポイズニングはDNSスプーフィングの一種であり、広義にはDNSハイジャックに含めて説明されることもあります。

ドメインハイジャックとの違い

ドメインハイジャックは、ドメインの管理権限そのものを奪われる攻撃です。

たとえば、レジストラアカウントが乗っ取られ、ネームサーバー設定やDNSレコードを不正に変更されるケースが該当します。

DNSキャッシュポイズニングはキャッシュの汚染を狙う攻撃であり、ドメイン管理権限そのものを奪う攻撃ではありません。

HTTPSがあればDNSキャッシュポイズニングは防げるのか

HTTPSは強力な防御層になる

現在のWebサイトではHTTPSが広く利用されています。

HTTPSでは、TLS証明書によって接続先の正当性を確認します。

そのため、DNSキャッシュポイズニングによって攻撃者のサーバーへ誘導されても、攻撃者が正規ドメインの有効なTLS証明書を持っていなければ、ブラウザは証明書エラーを表示します。

つまり、HTTPSはDNSキャッシュポイズニング後の被害を抑える重要な防御層です。

HTTPSだけで完全に安全とは言えない

ただし、HTTPSはDNSキャッシュポイズニングそのものを防ぐ仕組みではありません。

DNSの名前解決が改ざんされること自体は、HTTPSでは防げません。

また、次のようなケースでは被害につながる可能性があります。

ユーザーが証明書警告を無視する
HTTPのみのサービスが利用されている
社内システムや古いアプリケーションがHTTPSに対応していない
メールやAPI通信などWeb以外の通信でDNSが使われる
端末に不正なルート証明書がインストールされている
TLS証明書の不正発行など別の問題と組み合わされる

したがって、HTTPSは重要ですが、DNS側の対策もあわせて必要です。

DNSSECによる対策

DNSSECはDNS応答の正当性を検証する仕組み

DNSSECは、DNS応答に電子署名を付けることで、DNS情報が正当なものかどうかを検証する仕組みです。

通常のDNSでは、応答が本当に正規の管理者によるものかを暗号学的に確認できません。

DNSSECを利用すると、リゾルバは次のような確認を行えます。

このDNS応答は正規の管理者によって署名されているか
途中で改ざんされていないか
親ゾーンから信頼の連鎖がつながっているか

これにより、攻撃者が偽のDNS応答を送り込んでも、署名検証に失敗すれば、その応答は拒否されます。

DNSSECは正しく運用されて初めて効果を発揮する

DNSSECはDNSキャッシュポイズニングに対する強力な対策ですが、導入すれば自動的にすべて安全になるわけではありません。

DNSSECが有効に機能するには、次の条件が必要です。

対象ドメインのゾーンがDNSSEC署名されている
親ゾーンとの信頼の連鎖が正しく構成されている
利用者側のリゾルバがDNSSEC検証を行っている
検証失敗時に不正な応答を拒否する
鍵管理や鍵のロールオーバーが適切に行われている

設定ミスがあると、正規のドメインであっても名前解決に失敗する可能性があります。

そのため、DNSSECは非常に有効な対策である一方、正しい設計と運用が必要です。

管理者が行うべきDNSキャッシュポイズニング対策

DNSSEC検証を有効にする

DNSリゾルバ側でDNSSEC検証を有効にすると、署名検証に失敗した不正なDNS応答を拒否できます。

企業ネットワークやISP、組織内DNSを運用している場合は、DNSSEC検証に対応したリゾルバを使用し、正しく設定することが重要です。

DNSサーバーを最新状態に保つ

DNSソフトウェアには、BIND、Unbound、PowerDNS、dnsmasqなどがあります。

これらのソフトウェアに脆弱性があると、キャッシュポイズニングやその他のDNS攻撃のリスクが高まります。

そのため、DNSサーバーは常に最新のセキュリティパッチを適用し、古いバージョンを放置しないことが重要です。

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

DNSキャッシュポイズニングの成功率を下げるには、トランザクションIDと送信元ポートのランダム化が有効です。

攻撃者が偽応答を成功させるには、問い合わせに対応する正しい値を推測する必要があります。

ランダム化によって推測すべき値が増えるため、攻撃成功率を大幅に下げられます。

ただし、ランダム化は万能ではありません。

NAT機器やDNSフォワーダーの実装によっては、ポートランダム化の効果が弱まる場合があります。

Bailiwick checkingを適切に行う

Bailiwick checkingとは、DNS応答に含まれる追加情報が、そのDNSサーバーの権限範囲内の情報かどうかを確認する仕組みです。

たとえば、あるドメインについて問い合わせた際に、関係のない別ドメインの情報が追加で返された場合、それを安易にキャッシュしないようにします。

これにより、攻撃者が不正な追加レコードをキャッシュさせるリスクを下げられます。

オープンリゾルバを避ける

誰でも外部から利用できるDNSリゾルバは、攻撃の踏み台や悪用対象になる可能性があります。

社内用DNSリゾルバは、許可されたネットワークからのみ利用できるように制限すべきです。

社内ネットワークからのみ利用可能にする
アクセス制御リストを設定する
不要な外部公開を避ける
ログを監視する

DNSログと名前解決結果を監視する

DNSキャッシュポイズニングを早期に検知するには、DNSログや名前解決結果の監視が重要です。

監視すべきポイントには、次のようなものがあります。

想定外のIPアドレスが返っていないか
不審なNSレコードが含まれていないか
TTLが不自然に長くないか
急に名前解決先が変わっていないか
特定ネットワークだけ異なる結果になっていないか

特に重要なドメインについては、複数のDNSリゾルバから名前解決結果を確認すると、異常を検知しやすくなります。

サイト運営者が行うべき対策

常時HTTPSを導入する

Webサイト運営者は、すべてのページでHTTPSを利用するべきです。

HTTPSを導入していれば、DNSキャッシュポイズニングによって偽サーバーへ誘導された場合でも、正規のTLS証明書がなければブラウザが警告を表示します。

ログインページ、決済ページ、問い合わせフォームだけでなく、サイト全体をHTTPS化することが重要です。

HSTSを設定する

HSTSは、ブラウザに対して「このドメインには必ずHTTPSで接続する」と指示する仕組みです。

HSTSを設定すると、ユーザーがHTTPでアクセスしようとしても、ブラウザが自動的にHTTPS接続を行います。

ただし、HSTSはDNSキャッシュポイズニングそのものを防ぐものではありません。

HSTSの主な役割は、HTTPへのダウングレードを防ぎ、偽サイト誘導後の被害を抑えることです。

DNSレコードを監視する

サイト運営者は、自社ドメインのDNSレコードを定期的に監視することが重要です。

特に、次のレコードは重要です。

レコード	役割
A	ドメイン名をIPv4アドレスに対応させる
AAAA	ドメイン名をIPv6アドレスに対応させる
CNAME	別名を設定する
MX	メールサーバーを指定する
TXT	SPF、DKIM、DMARC、所有確認などに使う
NS	権威DNSサーバーを指定する

ただし、DNSキャッシュポイズニングでは、権威DNSの正規レコードが変更されていなくても、特定のDNSリゾルバのキャッシュだけが汚染される可能性があります。

そのため、権威DNSレコードの監視だけでなく、複数のDNSリゾルバから名前解決結果を確認することも重要です。

レジストラアカウントを保護する

DNSキャッシュポイズニングとは直接異なりますが、ドメイン管理アカウントが乗っ取られると、DNS設定そのものを改ざんされる可能性があります。

そのため、レジストラやDNSホスティングサービスのアカウント保護も重要です。

多要素認証を有効にする
強固なパスワードを使う
管理権限を最小限にする
退職者や不要アカウントを削除する
DNS変更通知を有効にする
レジストラロックを利用する

メール認証を設定する

メール関連のDNSレコードも保護が必要です。

SPF、DKIM、DMARCを適切に設定することで、なりすましメールや不正送信のリスクを下げられます。

また、必要に応じてMTA-STSやDANEの導入も検討できます。

DNSキャッシュポイズニングが疑われるサイン

正しいURLなのに見慣れないサイトが表示される

ユーザーが正しいURLにアクセスしているにもかかわらず、いつもと違う画面が表示される場合は注意が必要です。

特に、ログイン画面、決済画面、管理画面などのデザインが急に変わった場合は、偽サイトへ誘導されている可能性があります。

証明書エラーが表示される

DNSキャッシュポイズニングによって偽サーバーへ誘導された場合、攻撃者が正規のTLS証明書を持っていなければ、ブラウザに証明書エラーが表示されます。

証明書エラーは重要な警告です。安易に無視してアクセスを続けるべきではありません。

ネットワークによって表示結果が異なる

次のような場合は、特定のDNSリゾルバやネットワークに問題がある可能性があります。

自宅Wi-Fiでは正常だが会社ネットワークでは異常
スマートフォン回線では正常だが公共Wi-Fiでは異常
特定の地域やISPからだけ別サイトに見える
社内DNSを使ったときだけ異なるIPが返る

ただし、CDNを利用しているサイトでは、地域やDNSリゾルバによって異なるIPアドレスが返ることがあります。

そのため、IPアドレスが違うだけで攻撃と断定するのではなく、正規のCDNやホスティング環境の範囲内かどうかを確認する必要があります。

DNSキャッシュポイズニングの確認方法

複数のDNSリゾルバで名前解決結果を比較する

DNSキャッシュポイズニングが疑われる場合は、複数のDNSリゾルバで名前解決結果を比較します。

確認対象の例は次のとおりです。

社内DNS
ISPのDNS
信頼できるパブリックDNS
権威DNSサーバーへの直接問い合わせ

複数のリゾルバで結果を比較することで、特定のDNSキャッシュだけが異常な値を返していないかを確認できます。

権威DNSの正規レコードを確認する

DNSキャッシュの問題なのか、そもそも権威DNSの設定が変更されているのかを切り分けるには、権威DNSサーバーの情報を確認します。

権威DNSの情報が正しいにもかかわらず、特定のリゾルバだけ異なる結果を返す場合、そのリゾルバのキャッシュ汚染や設定ミスが疑われます。

CDNやロードバランサーの影響も確認する

CDNやロードバランサーを利用している場合、名前解決結果がアクセス元によって変わることがあります。

これは正常な挙動である場合も多いため、次の点を確認します。

返ってきたIPアドレスが正規CDNの範囲内か
CNAME先が正規のCDNドメインか
TLS証明書が正しいか
HTTPレスポンスの内容が正しいか
想定外の国やAS番号に向いていないか

Webサイト運営・マーケティングへの影響

ブランド信頼の低下

DNSキャッシュポイズニングによってユーザーが偽サイトに誘導されると、企業やサービスへの信頼が低下します。

ユーザーから見ると、正しいURLにアクセスしたつもりで被害に遭うため、サービス側への不信感が強くなりやすいです。

コンバージョン機会の損失

ECサイト、予約サイト、資料請求サイト、会員登録サイトなどでは、DNSキャッシュポイズニングによってユーザーが正規サイトへ到達できなくなる可能性があります。

その結果、購入、問い合わせ、申し込み、会員登録などのコンバージョンが失われる恐れがあります。

広告効果への悪影響

広告から正規ドメインへ誘導していても、DNSの名前解決が汚染されていれば、ユーザーが偽サイトへ誘導される可能性があります。

この場合、広告費をかけて集客しても、成果につながらないだけでなく、ユーザー被害によってブランド価値が損なわれる可能性があります。

SEOへの間接的な影響

DNSキャッシュポイズニング自体が直接検索順位を下げるとは限りません。

しかし、偽サイト誘導、マルウェア警告、サイト停止、セキュリティインシデント、ユーザー離脱などが発生すると、検索流入やブランド検索、指名検索、ユーザー行動に悪影響を与える可能性があります。

DNSキャッシュポイズニング対策チェックリスト

DNS管理者向けチェックリスト

項目	確認内容
DNSSEC検証	リゾルバでDNSSEC検証を有効にしているか
ソフトウェア更新	DNSサーバーを最新状態に保っているか
ポートランダム化	送信元ポートがランダム化されているか
IDランダム化	トランザクションIDが予測困難になっているか
Bailiwick checking	不正な追加情報を安易にキャッシュしない設定か
アクセス制御	オープンリゾルバになっていないか
ログ監視	不審なDNS応答や急な変化を監視しているか
キャッシュ管理	異常時にキャッシュをクリアする手順があるか

サイト運営者向けチェックリスト

項目	確認内容
HTTPS	全ページをHTTPS化しているか
HSTS	HSTSを適切に設定しているか
DNSSEC	重要ドメインでDNSSEC導入を検討しているか
DNS監視	A、AAAA、CNAME、MX、TXT、NSを監視しているか
複数リゾルバ確認	複数のDNSリゾルバから名前解決結果を確認しているか
証明書監視	TLS証明書の期限・発行元を監視しているか
レジストラ保護	MFAやレジストラロックを設定しているか
権限管理	DNS変更権限を必要最小限にしているか
メール認証	SPF、DKIM、DMARCを設定しているか
変更通知	DNS変更時の通知を有効にしているか

まとめ

DNSキャッシュポイズニングとは、DNSリゾルバなどに保存されているDNSキャッシュへ偽の名前解決情報を保存させ、ユーザーを本来とは異なる接続先へ誘導する攻撃です。

通常のフィッシングとは異なり、ユーザーが正しいURLを入力していても被害に遭う可能性があるため、非常に気づきにくい攻撃です。

特に、企業DNS、ISPのDNS、共有ネットワークのDNSキャッシュが汚染された場合、そのDNSを利用する複数のユーザーに影響が広がる恐れがあります。

対策としては、DNSSEC、DNSサーバーの更新、トランザクションIDや送信元ポートのランダム化、Bailiwick checking、オープンリゾルバの防止、DNS監視などが重要です。

また、Webサイト運営者は、HTTPS、HSTS、DNSレコード監視、複数リゾルバからの確認、レジストラアカウント保護、メール認証などを組み合わせて、被害を防ぐ必要があります。

DNSキャッシュポイズニングは、単にユーザーをだます攻撃ではなく、インターネットの名前解決の仕組みそのものをだまして、通信先をすり替える攻撃です。

サイト運営者やネットワーク管理者は、DNSをインフラの一部として継続的に管理・監視することが重要です。

以上、DNSキャッシュポイズニングについてでした。

最後までお読みいただき、ありがとうございました。