DNSキャッシュとは何ですか？
DNSキャッシュとは、DNSクエリの結果をローカルに保持するための一時的な保存メカニズムです。デバイスやアプリケーションが「example.com」などのドメイン名をクエリすると、DNSキャッシュはその結果として得られたIPアドレスを指定された期間保存します。この仕組みにより、同じ情報を取得するために外部のDNSサーバーに繰り返しクエリを送信する必要がなくなり、パフォーマンスが大幅に向上し、ネットワークの遅延が軽減されます。 各キャッシュエントリは、有効期限（TTL）値とともに保存されます。この値は、レコードが破棄または更新されるまでの有効期間を決定します。
DNSキャッシュは、ブラウザ、オペレーティングシステム、ルーター、再帰的リゾルバーなど、複数のレイヤーに存在します。その主な役割は、同じドメインに対するその後のDNS検索を高速化し、帯域幅の使用量を最小限に抑え、上流のDNSインフラへの負荷を軽減することです。頻繁にリクエストされるドメインとIPアドレスの対応関係をローカルストレージから提供することで、DNSキャッシュは、エンドユーザーにとってもネットワークにとっても、ウェブブラウジングやアプリケーションへのアクセスをより高速かつ効率的なものにします。
DNSキャッシュの種類：
- ブラウザのDNSキャッシュ：繰り返しアクセスするウェブサイトの表示を高速化するため、最近のドメイン検索結果をブラウザ内に保存します。
- オペレーティングシステムのDNSキャッシュ：デバイスレベルでDNSの検索結果を保存し、複数のアプリケーションが解決済みのレコードを再利用できるようにします。
- ルーターのDNSキャッシュ：ネットワークゲートウェイでDNS応答をキャッシュし、接続されたデバイスによる重複した検索を減らします。
- 再帰型DNSリゾルバーキャッシュ：ISP、企業、またはパブリックリゾルバーの各レベルでDNSレコードを保存し、多数のユーザーに対してより高速なサービスを提供する。
- アプリケーションレベルのDNSキャッシュ：パフォーマンスと制御の観点から、特定のアプリケーションがDNSの結果を個別にキャッシュできるようにします。
攻撃者がDNSキャッシュを悪用する仕組み：
- 偽造されたDNS応答：攻撃者は偽のDNS応答を送信し、それが正当な応答よりも先に受け入れられた場合、キャッシュされる可能性があります。
- リゾルバーの脆弱性：脆弱な、あるいは古いリゾルバーソフトウェアを使用していると、攻撃者がキャッシュされたDNSレコードを挿入したり改ざんしたりする可能性がある。
- 中間者攻撃：攻撃者は、DNSトラフィックがクライアントやリゾルバーに到達する前に、転送中のトラフィックを傍受し、改ざんする。
- DNSインフラの侵害：攻撃者は、権威サーバー、リゾルバー、またはDNS管理システム上のDNSレコードを改ざんする。
DNSキャッシュを消去する方法：
- Windows： コマンドプロンプトを管理者として開き、次のように入力します。
ipconfig /flushdns.
- Mac： ターミナルを開き、次のように入力します
sudo killall -HUP mDNSResponder.
- Chrome： [移動]
chrome://net-internals/#dns そして、「ホストキャッシュのクリア」をクリックします。
これは、ロードバランサーに関する一連の記事の一部です。
この記事の内容：
ブラウザのDNSキャッシュ
Webブラウザは、ユーザーが頻繁にアクセスするWebサイトのドメイン名解決を高速化するために、独自のDNSキャッシュを保持しています。ドメインが解決されると、ブラウザはその結果として得られたIPアドレスを内部キャッシュに保存し、それ以降、同じドメインへのリクエストでは、OSやネットワークレベルでのDNSクエリを省略できるようになります。このキャッシュは他のシステムキャッシュとは独立して管理されており、ブラウザを閉じたり、再起動したり、手動でキャッシュをクリアしたりすると、その内容は消去されます。
ブラウザのDNSキャッシュは、1回のブラウジングセッション中に同じウェブサイトを繰り返し訪問するユーザーにとって便利です。最近のDNSレコードを保存することで、ブラウザはページの読み込み時間を短縮し、Webアプリケーションの応答性を向上させます。ブラウザのキャッシュは一般的に有効期間が短く、その効果はユーザーの行動やブラウザ固有のキャッシュ管理ポリシーによって異なります。
オペレーティングシステムのDNSキャッシュ
オペレーティングシステム（OS）は独自のDNSキャッシュを管理しており、デバイス上で実行されているあらゆるアプリケーションから得られたクエリの結果を保存しています。このシステムレベルのキャッシュにより、一度ドメインの解決が行われれば、その後のアプリケーションは新たなクエリを実行することなく、キャッシュされたレコードを利用できるようになります。OSのキャッシュはブラウザのセッションを超えて保持され、通常、ブラウザのキャッシュよりも多くのDNSレコードを保持しています。
OSのDNSキャッシュの管理は、パフォーマンスの向上やトラブルシューティングにおいて重要です。キャッシュされたエントリにはTTLの有効期限があり、期限が切れると自動的に削除されます。ユーザーや管理者は、次のようなコマンドを使用して、OSのDNSキャッシュを手動でクリアすることができます。 ipconfig /flushdns Windows または sudo dscacheutil -flushcache macOS において、古くなった、または不正確な DNS レコードに関連する問題を解決します。これにより、システム全体で信頼性の高いドメイン解決を維持することができます。
ルーターのDNSキャッシュ
ルーターはDNSキャッシュ機能を実装し、クライアントデバイスと外部のDNSサーバーとの間の仲介役として機能します。ネットワーク上のデバイスがDNSクエリを送信すると、ルーターはリクエストを上位のサーバーに転送する前に、ローカルキャッシュに一致するエントリがないか確認します。これにより、冗長なDNSトラフィックが削減され、接続されたデバイスのドメイン解決が高速化されます。特に、多数の利用者がいたり、同様のリソースにアクセスするデバイスが多数存在する環境において、その効果が顕著です。
ルーターベースのDNSキャッシュは、複数のクライアントが同じウェブサイトにアクセスする家庭やオフィス環境で役立ちます。ネットワークゲートウェイでDNSキャッシュを一元化することで、ルーターは平均的なDNS検索時間を短縮し、帯域幅の使用量を削減できます。他のキャッシュと同様に、ルーターのDNSエントリにもTTLの有効期限があり、ルーターによってはDNSキャッシュを手動でクリアするオプションが用意されている場合があります。
再帰型DNSリゾルバーのキャッシュ
再帰型DNSリゾルバーは、多くの場合、ISPやサードパーティのDNSプロバイダーによって運用されており、クライアントに代わって解決を行うドメインについて、大規模なキャッシュを管理しています。これらのキャッシュには、権威サーバーから取得したDNSレコードが保存されており、レコードのTTLが有効な期間内に同じリクエストを行うクライアントに対して、そのレコードが提供されます。これらのリゾルバーは多くのユーザーからのクエリを処理するため、キャッシュの規模は膨大であり、上流のDNSトラフィックを削減します。
再帰型リゾルバーのキャッシュの効率は、大規模なユーザーベースにおけるDNS解決のパフォーマンスと信頼性に影響を与えます。再帰型リゾルバーは、キャッシュされた応答を返すことで、クエリの遅延を短縮し、広範なDNSインフラストラクチャで発生する一時的なサービス停止や速度低下からユーザーを保護するのに役立ちます。悪意のあるキャッシュが一度に多くのユーザーに影響を及ぼす可能性があるため、このレベルで安全かつ正確なキャッシュを維持することは極めて重要です。
関連コンテンツ：DNS応答を利用して、ユーザーをパフォーマンスが最も高いサイトへ誘導する「グローバルサーバー負荷分散」に関する記事をご覧ください。
アプリケーションレベルのDNSキャッシュ
一部のアプリケーションでは、ブラウザやオペレーティングシステムのキャッシュとは独立して、独自のDNSキャッシュ機構を実装しています。その例としては、Webサーバー、プロキシサーバー、および大量のDNSクエリを処理したり、キャッシュの動作をきめ細かく制御する必要があるカスタムネットワークツールなどが挙げられます。アプリケーションレベルのキャッシュでは、独自のTTL、キャッシュサイズ、およびキャッシュのクリアポリシーを設定することができます。
アプリケーションレベルのDNSキャッシュは、高速かつ繰り返しのドメイン検索が頻繁に行われる場合や、基盤となるシステムのキャッシュ状態にかかわらずアプリケーションが一貫したパフォーマンスを必要とする場合に有用です。しかし、複数のキャッシュ層を管理することは複雑さを増すため、古くなったレコードや矛盾するレコードが生じないよう注意を払う必要があります。開発者は、アプリケーションキャッシュがDNSのTTLを遵守し、キャッシュの無効化を行う仕組みを備えていることを確認する必要があります。
おそらく、DNSキャッシュの中で最も複雑なタイプは再帰的キャッシュであり、これは大規模な分散インフラストラクチャ全体で動作することが可能です。その仕組みを段階を追って見ていきましょう。
1. DNSクエリが送信される
クライアントがドメイン名を解決する必要がある場合、再帰型DNSリゾルバーにDNSクエリを送信します。この再帰型リゾルバーは、ISP、企業ネットワーク、またはパブリックDNSプロバイダーによって運用されている場合があります。
他のDNSサーバーに問い合わせる前に、再帰的リゾルバーは、クエリに応答できる有効なレコードがキャッシュ内にないか確認します。要求されたレコードがすでにキャッシュされており、有効期限が切れていない場合、リゾルバーは即座に応答できます。有効なキャッシュされた応答がない場合は、DNSルックアップを実行する必要があります。
2. 再帰型リゾルバーはキャッシュを確認する
再帰型リゾルバは、以前の検索で取得したDNSレコードを保存します。キャッシュされた各レコードには、リゾルバがそのレコードをいつまで使用し続けられるかを決定するTTL（Time-to-Live）値が関連付けられています。
リゾルバーはクエリを受信すると、キャッシュ内から一致するレコードを検索します。有効期限が切れていないレコードが見つかった場合、上流のDNSサーバーに問い合わせることなく、キャッシュされた結果をクライアントに返します。
これにより、DNS解決の遅延が軽減され、ルートDNSサーバー、トップレベルドメイン（TLD）サーバー、および権威DNSサーバーへのクエリ数が減少します。
3. キャッシュされたDNSレコードが返される
再帰的リゾルバーが有効なキャッシュレコードを見つけた場合、そのDNS応答をクライアントに直接返します。その後、クライアントは、AレコードやAAAAレコードから得られたIPアドレスなどの返された情報を使用して、要求されたサービスへの接続を確立し続けることができます。
リゾルバーが新たな検索を行う必要がないため、キャッシュヒットの場合、通常、完全なDNS解決よりも必要なネットワークリクエストの数が少なくて済みます。
リゾルバーは、キャッシュされたレコードの残存TTLも報告します。時間が経過するにつれて、この値はキャッシュされたエントリの有効期限が切れるまで減少していきます。
4. 必要に応じて再帰的なDNS検索が行われる
要求されたレコードがキャッシュに存在しない場合、またはそのTTLが期限切れになっている場合、再帰的リゾルバは新しい応答を取得しなければならない。
一般的なキャッシュされていない検索の場合、リゾルバーは複数のDNSサーバーにクエリを送信することがあります：
- ルートDNSサーバーは、リゾルバーを適切なTLDサーバーへと誘導します。
- TLDサーバーは、リゾルバーをそのドメインの権威DNSサーバーへと誘導します。
- 権威DNSサーバーは、要求されたDNSレコード、またはルックアップを完了するために必要なその他の情報を返します。
リゾルバーは、クライアントに返すことのできる回答が得られるまで、これらの参照をたどっていきます。
この処理の過程で、リゾルバは、NSレコードや権威ネームサーバーのアドレスレコードなど、中間情報をキャッシュする場合もあります。これらのキャッシュされたレコードにより、その後の検索に必要なクエリの数を減らすことができます。
5. DNSレコードは、TTLが切れるまでキャッシュされます
再帰的リゾルバーは、キャッシュ可能なDNSレコードを受信すると、そのTTL値に基づいてそれらを保存します。TTLはDNS応答に含まれており、レコードがキャッシュに保持される期間を指定します。
TTLが有効な間は、同じ情報に対するその後のクエリに対して、リゾルバのキャッシュから応答することができます。TTLがゼロになると、キャッシュされたレコードは新しいクエリへの応答に使用できなくなり、リゾルバは次のリクエストが到着した際に最新のDNSデータを取得する必要があります。
TTLが短いと、リゾルバーはレコードをより頻繁に更新するため、DNSの変更がより早く反映されます。TTLが長いと、レコードがキャッシュに長く保持されるため、権威DNSインフラへの繰り返しクエリが減少します。
DNSキャッシュポイズニング（DNSスプーフィングとも呼ばれる）とは、偽のDNSレコードをDNSキャッシュに挿入する攻撃のことです。悪意のあるレコードがキャッシュされると、正当なドメインをリクエストしたユーザーは、正しい宛先ではなく、攻撃者が制御するIPアドレスへと誘導されてしまいます。応答はキャッシュから提供されるため、影響を受けたユーザーは、詐欺サイトにリダイレクトされたことに気づかない可能性があります。
この攻撃は通常、再帰型DNSリゾルバー、ルーター、またはDNSレコードをキャッシュするその他のシステムを標的とします。攻撃者は、脆弱性を悪用したり、DNSトランザクションの詳細を予測したりすることで、これらのシステムを騙して偽造されたDNS応答を受け入れさせようとします。攻撃が成功すると、その偽装されたエントリはTTLが切れるか、キャッシュが手動でクリアされるまでキャッシュ内に残存するため、1回の攻撃で複数のユーザーが影響を受けることになります。
DNSキャッシュポイズニングは、フィッシング攻撃、マルウェアの配布、トラフィックの傍受を助長するために頻繁に利用されます。被害者は、知らず知らずのうちにログイン情報を入力したり、悪意のあるソフトウェアをダウンロードしたり、攻撃者が制御するサーバーに機密情報を送信したりしてしまう可能性があります。ブラウザには引き続き本来のドメイン名が表示されるため、追加のセキュリティ対策が講じられていない限り、この攻撃を検知することは困難です。
偽造されたDNS応答
攻撃者は、権威サーバーから正当な応答が届く前に、偽造されたDNS応答を送信する場合があります。リゾルバーがこの偽の応答を受け入れると、悪意のあるDNSレコードをキャッシュに保存し、その後のリクエストに対してそれを返します。これにより、リクエストされたドメイン名を変更することなく、ユーザーが攻撃者が制御するサーバーにリダイレクトされてしまいます。
最新のDNSリゾルバーは、トランザクションIDや送信元ポートをランダム化することで、偽造された応答の挿入を困難にしています。こうした保護機能により、攻撃者が偽装された応答が受け入れられるために必要な値を推測できる可能性が低くなります。一方、古くなったリゾルバーや設定が不適切なリゾルバーは、この種の攻撃に対して依然として脆弱なままです。
リゾルバーの脆弱性
DNSリゾルバーには、攻撃者がキャッシュされたレコードを改ざんしたり操作したりするために悪用できるソフトウェア上の欠陥や設定上の脆弱性が存在する可能性があります。その例としては、予測可能なクエリ識別子、不十分な応答検証、あるいはリゾルバーの実装上の脆弱性などが挙げられます。攻撃が成功すると、攻撃者は偽のDNSデータを注入したり、検証メカニズムを迂回したりすることが可能になります。
リゾルバーソフトウェアを最新の状態に保つことで、こうした攻撃を防ぐことができます。セキュリティパッチは既知の脆弱性に対処し、安全な設定手法は攻撃対象領域を縮小します。組織は、再帰型リゾルバーへのアクセスを制限し、可能な場合はDNSSEC検証などの機能を有効にする必要があります。
中間者攻撃
中間者攻撃（MITM）では、攻撃者はクライアントとリゾルバーの間、あるいはDNSサーバー間のDNSトラフィックを傍受します。転送中のDNS応答を改ざんすることで、攻撃者は正当なレコードがキャッシュされたりクライアントに配信されたりする前に、それらを悪意のあるレコードに置き換えることができます。これにより、ユーザーを偽のウェブサイトや悪意のあるサービスに誘導することが可能になります。
MITM攻撃を行うには、通常、攻撃者がネットワーク経路上の特定の位置を確保する必要があります。例えば、乗っ取られたWi-Fiネットワークや、セキュリティ侵害を受けたルーターなどを通じてです。DNS over HTTPS（DoH）やDNS over TLS（DoT）などのプロトコルを使用してDNSトラフィックを暗号化することで、権限のない第三者がDNSクエリや応答を読み取ったり改ざんしたりすることを防ぐことができます。
侵害されたDNSインフラ
攻撃者は、個々のクライアントやリゾルバーではなく、DNSインフラを標的とする場合があります。権威DNSサーバー、再帰型リゾルバー、またはDNS管理アカウントを乗っ取ることで、攻撃者はソース側で正当なDNSレコードを改ざんすることができます。こうした悪意のあるレコードは、TTL値に従って、インターネット上のリゾルバーによって配信され、キャッシュされます。
DNSインフラを保護するには、強力な認証、定期的なソフトウェアの更新、アクセス制御、および継続的な監視が必要です。DNS管理アカウントへの多要素認証、DNSSECの導入、および不正なレコード変更の迅速な検知は、インフラの侵害や悪意のあるDNSデータの拡散というリスクを低減するのに役立ちます。
関連コンテンツ： DNSフラッド攻撃に関する記事をご覧ください。
DNSキャッシュはいつクリアする必要があるのでしょうか？
キャッシュされたレコードが古くなったり、不正確になったりした場合は、DNSキャッシュをクリアする必要がある場合があります。これは、ウェブサイトのIPアドレスが変更されたり、DNSレコードが更新されたり、ドメインが別のサーバーに移行されたりした後に発生することがあります。キャッシュをクリアすると、オペレーティングシステムが最新のDNSデータを取得するよう強制されるため、ウェブサイトの読み込みに失敗したり、古いサーバーに接続が誘導されたりといったエラーを解決することができます。
セキュリティインシデントが疑われる場合、DNSキャッシュのクリアも有効な手段となります。悪意のある、あるいは偽造されたDNSレコードがキャッシュに保存されてしまうと、そのレコードの有効期限が切れるまで、リクエストが攻撃者が制御するシステムへリダイレクトされる可能性があります。キャッシュをフラッシュすることで、これらのローカルエントリは削除されますが、侵害の原因そのものが解決されるわけではありません。キャッシュポイズニングが疑われる場合、管理者はDNS設定の確認、設定されているリゾルバーのチェック、影響を受けたシステムの更新に加え、偽のレコードがどのように混入したのかを調査する必要があります。
Windows で DNS キャッシュを消去する方法
Windows は DNS レコードをオペレーティングシステムのキャッシュに保存しており、コマンドプロンプトからこのキャッシュをクリアすることができます。
- コマンドプロンプトを管理者として開きます。
- 次のコマンドを実行してください：
ipconfig /flushdns
- Enterキーを押してください。
成功した場合、Windows には「DNS リゾルバーキャッシュのクリアに成功しました」と表示されます。
ウェブサイトに再度アクセスすると、新しいDNS検索が実行されるため、キャッシュがクリアされたことを確認できます。
macOSでDNSキャッシュを消去する方法
macOS は、システムサービスを通じて DNS レコードをキャッシュします。必要なコマンドは macOS のバージョンによって若干異なりますが、以下のコマンドは現在のリリース版で動作します。
- ターミナルを開きます。
- 実行：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- プロンプトが表示されたら、管理者パスワードを入力してください。
このコマンドは、確認メッセージを表示せずに実行が完了します。
次のDNSリクエストでは、設定されたDNSリゾルバーから最新のレコードが取得されます。
Google Chrome で DNS キャッシュを消去する方法
Google Chrome は、オペレーティングシステムのキャッシュに加えて、独自の内部 DNS キャッシュを保持しています。
- Chromeを開いてください。
- アドレスバーに以下を入力してください：
chrome://net-internals/#dns
- [ホストキャッシュのクリア] をクリックします。
- ウェブサイトを再読み込みしてください。
注： 現在のChromeのバージョンでは、 chrome://net-internals/#dns Chromeのホストキャッシュをクリアするために、まだ利用可能な場合があります。その chrome://net-export このページは、DNSキャッシュを消去するための代替ツールではありません。ネットワーク診断ログを記録するために使用されます。お使いのChromeのバージョンで「ホストキャッシュを消去」オプションが利用できない場合は、代わりにオペレーティングシステムのDNSキャッシュを消去し、Chromeを再起動してください。
それでも問題が解決しない場合は、Chromeも多くのDNS処理においてシステムリゾルバーに依存しているため、オペレーティングシステムのDNSキャッシュもクリアしてください。
1. 再帰型リゾルバで DNSSEC 検証を有効にする
組織は、自組織の再帰型DNSリゾルバでDNSSEC検証を有効にする必要があります。DNSSECは暗号署名を用いて、リゾルバがDNSデータの真正性を確認し、改ざんされていないことを検証できるようにします。
検証が有効になっている場合、リゾルバーは、DNSSECで署名されたゾーンに対する偽造または改ざんされた応答を、キャッシュに保存するのではなく拒否することができます。これにより、DNSキャッシュポイズニングのリスクを低減できます。
管理者は、組織が管理するすべての再帰的リゾルバーがDNSSEC検証を実行していること、および検証の失敗がログに記録され、監視されていることを確認する必要があります。DNSSECはDNSトラフィックを暗号化しないため、機密性が求められる場合は、他の制御手段と組み合わせて使用する必要があります。
2. 承認済みリゾルバーを通じてDNS解決を一元化する
組織は、ユーザーやアプリケーションが任意の外部リゾルバーを選択することを許可するのではなく、承認された再帰的DNSリゾルバーを使用するようにエンドポイントやネットワーク機器を設定すべきです。
DNS解決を一元化することで、セキュリティポリシーの適用、DNSアクティビティの監視、フィルタリングの実施、および不審なクエリの調査が容易になります。承認されたリゾルバーは、社内で運用することも、マネージドDNSサービスから提供を受けることも可能です。
ネットワーク制御では、可能な限り、不正なDNSトラフィックがこれらのリゾルバーを迂回することを防止する必要があります。これには、ポート53でのアウトバウンドDNSトラフィックの制限や、DNS over HTTPS（DoH）やDNS over TLS（DoT）などの暗号化DNSプロトコルに対するポリシーの定義などが含まれます。
3. 再帰的リゾルバーのソフトウェアとインフラストラクチャを最新の状態に保つ
再帰型DNSサーバーおよびそれを支えるインフラストラクチャは、組織のパッチ管理プロセスに組み込むべきである。
管理者は、DNSリゾルバーソフトウェア、オペレーティングシステム、ファイアウォール、および関連するネットワークコンポーネントにセキュリティ更新プログラムを適用する必要があります。古いソフトウェアには、攻撃者が名前解決を妨害したり、保護機能を迂回したり、キャッシュされたデータを改ざんしたりすることを可能にする脆弱性が含まれている可能性があります。
また、組織はアップグレード後にリゾルバーの設定を見直し、セキュリティ設定、ログ記録、DNSSECの検証、およびアクセス制御が引き続き有効になっていることを確認する必要があります。
4. 再帰的リゾルバーへのアクセスを制限する
再帰型DNSリゾルバーは、承認されたクライアントおよびネットワークからのクエリのみを受け入れるべきである。
制限のない再帰型リゾルバは、外部の攻撃者によってDNS増幅攻撃に悪用される可能性があり、内部のDNSインフラを不必要にさらす恐れがあります。組織は、ファイアウォールルール、アクセス制御リスト、またはリゾルバの設定を用いて、再帰クエリを送信できるユーザーを制限する必要があります。
内部リゾルバーへのアクセスは、原則として、社内ネットワーク、承認済みのリモートアクセスインフラ、およびその他明示的に許可されたシステムからのみ可能とするべきです。
5. キャッシュポイズニング対策の確認
最新の再帰型リゾルバーには、ソースポートのランダム化やDNSトランザクションIDなどの保護機能が搭載されており、これにより、偽造されたDNS応答の予測や注入がより困難になっています。
管理者は、これらの保護機能が有効になっていること、およびファイアウォール、NATゲートウェイ、ロードバランサーなどのネットワーク機器が、DNSトラフィックを予測可能な方法で書き換えることによって、その有効性を損なっていないことを確認する必要があります。
これらの保護措置は、DNSSECによる検証に取って代わるものではなく、それを補完するものであるべきです。
6. リゾルバの動作とキャッシュの異常を監視する
組織は、再帰型DNSリゾルバーについて、ポイズニング、悪用、または異常な解決動作の兆候がないか監視すべきである。
関連する指標としては、解決済みのIPアドレスの急激な変化、繰り返されるDNSSEC検証の失敗、異常に多いクエリ数、予期しないドメイン、および異常な応答パターンなどが挙げられます。
DNSログは、可能な限り一元的な監視システムやSIEMシステムに転送する必要があります。アラートを活用することで、セキュリティチームは、多数の利用者に影響が及ぶ前に、侵害されたエンドポイント、悪意のあるDNSアクティビティ、またはリゾルバーの設定ミスを特定することができます。
7. キャッシュの動作とTTLの処理
組織は、再帰的リゾルバーを適切に設定し、DNSのTTL値を正しく遵守するとともに、文書化された耐障害性機能によって必要とされない限り、期限切れのレコードを意図した期間を超えて保持しないようにすべきである。
管理者は、サーブ・ステール・キャッシング、ネガティブ・キャッシング、キャッシュのプリフェッチ、およびカスタムTTLのオーバーライドといった機能についても確認する必要があります。これらの機能は可用性とパフォーマンスを向上させることができますが、設定を誤ると、古くなったレコードや誤ったレコードが引き続き使用され続ける原因となる可能性があります。
権威あるTTL値からの逸脱がある場合は、その内容を文書化し、組織内のすべてのリゾルバーで一貫して適用する必要があります。
リゾルバーレベルでのDNSキャッシュの動作を保護しても、それらのレコードを提供するDNSインフラストラクチャが稼働し続けていなければ意味がありません。DNSサーバーがサービス拒否（DoS）攻撃の被害に遭うと、ユーザーはそのサーバーに関連するウェブサイト、サービス、APIにアクセスできなくなり、アプリケーションの可用性、顧客との関係、収益に甚大な影響が及びます。
RadwareのDNS DDoS保護ソリューションは、行動ベースの検知と自動リアルタイムシグネチャを活用し、現在最も高度なDNS DDoS攻撃を特定して自動的にブロックします。DefensePro XのDNS行動ベース保護モジュールとRadwareのクラウドDDoS保護サービスを基盤とするこれらの防御機能は、適応性が高く多層的な構造を備えており、アプライアンス、クラウド、またはハイブリッドソリューションとして展開可能で、あらゆる導入アーキテクチャに対応します。
Radware DNS DDoS Protectionの主な機能：
- あらゆるDNS DDoS攻撃に対する防御：既知およびゼロデイのDNS DDoS攻撃をリアルタイムで検知・緩和し、ネットワークとサービスの可用性と耐障害性を維持します。
- DNS特有の攻撃手法への対応：DNS増幅攻撃、DNSフラッド攻撃、DNSウォーター・トーチャー／ランダムサブドメイン攻撃、およびファントムドメイン攻撃に対する防御機能を備えています。
- 自動化された機械学習による保護：攻撃キャンペーンを正確に検知・軽減しつつ、誤検知を最小限に抑える、多層的で特許取得済みの適応型ソリューションです。
- 対策までの時間（TTM）の短縮：人間の介入なしに、検知、特性分析、および対策を自律的に管理することで、対策までの総時間を短縮します。
- 総所有コスト（TCO）の削減：構成管理および継続的な攻撃への対応が完全に自動化されるため、コストを大幅に削減できます。
- 柔軟な導入：あらゆる顧客のユースケース、環境、アーキテクチャに対応するクラウドサービス、アプライアンス、およびハイブリッドソリューション。
- フルマネージド・セキュリティサービス：Radwareの緊急対応チーム（ERT）に所属する、実戦で実績のある120名のセキュリティ専門家によるリアルタイムのサポート。
RadwareのDNS DDoS保護について詳しくはこちらをご覧ください。