JP5499183B2 - Ｄｎｓキャッシュポイズニングを防止するための方法およびシステム - Google Patents

Description

本発明は、ドメイン名システムに関するセキュリティ技術に関する。

以下、「ドメイン名システム」または（ドメイン名システムに関する）「ＤＮＳサーバ」は、ドメイン名（すなわち、ホスト名）とＩＰアドレスとの間の対応を確立することを可能にするか、または、より一般的には、ドメイン名またはＩＰアドレスを使用して情報を見出すことを可能にする任意のシステムを意味する。

加えて、「ＤＮＳクエリ」は、ドメイン名またはＩＰアドレスの解決を要求するメッセージを意味する。ＤＮＳクエリに対する応答は、この場合、「ＤＮＳ応答」と呼ばれる。詳細には、ＤＮＳ応答は、ドメイン名、ＩＰアドレス、エラーメッセージ、またはエラーコードを含むことが可能である。ＤＮＳクエリの解決は、例えば、ウェブブラウジング、電子メール、またはＶＰＮ接続など、コンピュータネットワークを介してＤＮＳプロトコルを使用する任意のアプリケーションに関する点に留意されたい。

多数のドメイン名（または、同等に、ＩＰアドレス）のため、ＤＮＳサーバは、実際には、データの限定されたセットを表すことだけができる。したがって、ＤＮＳサーバは、すべてのドメイン名を解決することができない。そうするために、分散型ＤＮＳサーバシステムが通常優れており、このシステムでは、それぞれのＤＮＳサーバが、当該サーバが応答を有さないＤＮＳクエリを受信したとき、それぞれのＤＮＳサーバは、
− そのＤＮＳサーバに見返りとして応答を提供するために、このクエリを１つもしくは複数の他のＤＮＳサーバに中継する（再帰的方法）か、または
− このＤＮＳクエリに応答することを次いで請求される別のＤＮＳサーバを指定する（反復的方法）。

将来のＤＮＳクエリに関する応答時間を最適化するため、ならびに分散型システムにおける特定のＤＮＳサーバのオーバロードを防止するために、大部分のＤＮＳサーバは、ＤＮＳキャッシュとしても機能する。すなわち、ＤＮＳサーバは、このプロセスを後で再び実行しないように、ＤＮＳサーバ管理者によって事前に定義されたＴＴＬ（有効期間）の間、ＤＮＳクエリに関して取得された応答をメモリ内に保持する。

しかし、このＤＮＳキャッシュは、ＤＮＳキャッシュポイズニングとして一般に知られている攻撃に対して脆弱である（ＤＮＳ ２００８ ａｎｄ ｔｈｅ ｎｅｗ （ｏｌｄ）ｎａｔｕｒｅ ｏｆ ｃｒｉｔｉｃａｌ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、Ｄａｎ Ｋａｍｉｎｓｋｙ、Ｍｅｘｉｃｏ、２００９）。この攻撃は、パブリックマシン（ｐｕｂｌｉｃ ｍａｃｈｉｎｅ）の有効（実際の）ドメイン名（例えば、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ）とＤＮＳキャッシュ内に格納されることになる虚偽の情報（例えば、無効ＩＰアドレスまたは虚偽のＤＮＳ応答）との間に対応を生み出すことを目的とする。

あるドメインに関するＤＮＳクエリに対する虚偽のＤＮＳ応答がＤＮＳキャッシュ内に一度格納されると、次いで、その応答は自動的に、ＴＴＬの間、同じドメインに関する後のＤＮＳクエリに対する応答になる。したがって、このＤＮＳキャッシュのすべてのユーザは攻撃に対して脆弱である。

詳細には、ＤＮＳキャッシュポイズニングは、ユーザをそのコンテンツが悪意（例えば、ウィルス増殖、個人データを取得するためのフィッシング、またはあるサイトを別の競合するサイトもしくは存在しないサイトに宛先変更することによるプロパガンダ）を有する可能性があるサイトに宛先変更することを可能にする。

ＤＮＳ ２００８ ａｎｄ ｔｈｅ ｎｅｗ （ｏｌｄ）ｎａｔｕｒｅ ｏｆ ｃｒｉｔｉｃａｌ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、Ｄａｎ Ｋａｍｉｎｓｋｙ、Ｍｅｘｉｃｏ、２００９

本発明の１つの目的は、前述の欠点を是正することである。

本発明の別の目的は、多くのＤＮＳキャッシュを有するコンピュータネットワークに属しているＤＮＳキャッシュのポイズニングを防止することである。

本発明の別の目的は、システムに最小量の修正を加えることによってＤＮＳキャッシュポイズニング攻撃を防止するための方法を用いて、分散型ＤＮＳキャッシュシステムを提供することである。

本発明の別の目的は、ＤＮＳキャッシュによって使用されるＤＮＳプロトコルと互換性があるＤＮＳキャッシュに対するポイズニング攻撃を防止するための方法およびシステムを提案することである。

本発明の別の目的は、ＤＮＳキャッシュポイズニング攻撃を防止するための自律的システムを提案することである。

本発明の別の目的は、インターネットサービスプロバイダネットワーク内のＤＮＳ解決の整合性を改善することである。

本発明の別の目的は、大部分のインターネットサービスプロバイダ（ＩＳＰ）ネットワークと互換性のあるＤＮＳキャッシュポイズニング攻撃を防止するための方法を提案することである。

本発明の別の目的は、コンピュータネットワーク内のＤＮＳキャッシュポイズニング攻撃に対する対抗措置を提案することである。

本発明の別の目的は、インターネットサービスプロバイダのネットワークに接続されたユーザに提供されるコンピュータセキュリティを改善することである。

このために、本発明は、第１の態様によれば、いくつかのＤＮＳキャッシュを含むコンピュータネットワーク内の少なくとも１つのＤＮＳキャッシュのポイズニングを防止するための方法であって、２つの異なるＤＮＳキャッシュから戻された、ＤＮＳクエリに対する少なくとも２つのＤＮＳ応答を比較するステップを含む方法を提案する。

第２の態様によれば、本発明は、いくつかのＤＮＳキャッシュを含むコンピュータネットワーク内の少なくとも１つのＤＮＳキャッシュのポイズニングを防止するためのシステムであって、２つの異なるＤＮＳキャッシュによって戻された、ＤＮＳクエリに対する少なくとも２つのＤＮＳ応答の解析器を備えたシステムに関する。

有利には、このシステムは、ＤＮＳクエリが関連するサービスを識別することを可能にする、ＤＮＳクエリに関する情報のデータベースを備えたＤＮＳクエリ解析器も備える。

本発明のその他の特徴および利点は、一実施形態のモジュール同士の間の相互作用をグラフで例示する図１が参照される、好ましい実施形態の以下の説明を読んだ後に、より明瞭かつより具体的に理解されよう。

一実施形態のモジュール同士の間の相互作用をグラフで例示する図である。

ＩＳＰネットワークＢは、一般に、ネットワークＢに接続されたクライアントＡに属している少なくとも１つのＤＮＳレゾルバ１から発行されたＤＮＳクエリに応答する任務を負う、いくつかのＤＮＳキャッシュ５＿１、５＿２、．．．、５＿ｎ（ｎ＞１）を備える。ＤＮＳレゾルバ１は、一般に、ネットワークＢに送信されることになるＤＮＳクエリを形成して、ＤＮＳレゾルバ１に戻されたＤＮＳ応答を解釈するクライアントプログラムである。

ＤＮＳキャッシュ５＿１、５＿２、．．．、５＿ｎ内で利用可能な情報に基づいてＤＮＳクエリに応答することができない場合、ＤＮＳ応答は、ネームサーバオペレータＣに属しているＤＮＳルートサーバ９から請求される。

ＤＮＳ応答は、一般に、この応答をそのＤＮＳクエリが発生したＤＮＳレゾルバ１に中継する任務を負うネットワークＢ上でＤＮＳレスポンダ１０に通信される。

ＤＮＳキャッシュ管理システム３は、ＤＮＳキャッシュ５＿１、５＿２、．．．、５＿ｎの同時制御または個々の制御を可能にする。例えば、管理システム３は、それぞれのＤＮＳキャッシュに関するＴＴＬを修正すること、またはＤＮＳキャッシュを動作可能／動作不可能にすることを可能にする。

ＤＮＳキャッシュ５＿１、５＿２、．．．、５＿ｎに対するポイズニング攻撃は、いくつかのＤＮＳキャッシュ、詳細には、１つがインターネットサービスプロバイダ（ＩＳＰ）に属しているＤＮＳキャッシュを備えた任意のコンピュータネットワークＢに適応され得る機能モジュールを使用することによって防止される。

詳細には、これらのモジュールは、
− ＤＮＳレゾルバ１から送信されたＤＮＳクエリをどのように処理するかを決定するＤＮＳクエリ解析器２と、
− いくつかのＤＮＳキャッシュにサービス提供するＤＮＳクエリデコンセントレータ６（ｄｅｃｏｎｃｅｎｔｒａｔｏｒ）と、
− いくつかのＤＮＳキャッシュから取得されたＤＮＳ応答の比較器７と、
− いくつかのＤＮＳキャッシュから取得されたＤＮＳ応答の解析器８と、
− ＤＮＳキャッシュ５＿１、．．．、５＿ｎに関するポイズニング攻撃防止システムを支援する、いくつかの拡張可能な情報データベースとを備える。

ＤＮＳクエリ解析器２がＤＮＳレゾルバ１から発行されたＤＮＳクエリを受信するとき（図１上のリンク１２）、ＤＮＳクエリ解析器２は、このＤＮＳクエリを解決するためにどの処理を実行するかを決定する。この決定は、以下から取り出された情報に基づいて行われる：すなわち、
− ＤＮＳクエリが関連する、サービス（例えば、ブラウジング、電子メール、ストリーミング、電子商取引、およびｅラーニング）ならびに／またはプロトコル（例えば、ＨＴＴＰ、ＨＴＴＰＳ、ＰＯＰ３、ＦＴＰ、もしくはＳＭＴＰ）など、ＤＮＳクエリに関する情報を伴うデータベース４、
− 無効ＤＮＳ応答のデータベース１１、および
− ネットワークＢの管理者によって構成され得るＤＮＳキャッシュ５＿１、５＿２、．．．、５＿ｎに関する管理システム３である。

ＤＮＳクエリに関する情報のデータベース４は、このＤＮＳクエリが関連するサービスを識別するために、ＤＮＳクエリのコンテンツ（詳細には、ドメイン名、例えば、ｅｂａｙ．ｃｏｍまたはｇｏｏｇｌｅ．ｃｏｍ、およびトランスポートプロトコル、例えば、ＨＴＴＰ、ＨＴＴＰＳ、またはＳＭＴＰ）を使用する。例えば、ＤＮＳクエリが、
ドメイン名「ｅｂａｙ．ｃｏｍ」を含む場合、情報データベース４は、このドメイン名を識別して、それを電子商取引サービスと関連付ける、
ドメイン名「ｈｏｍｅ．ａｍｅｒｉｃａｎｅｘｐｒｅｓｓ．ｃｏｍ」を含む場合、情報データベースは、このドメイン名を識別して、それを電子銀行業務サービスと関連付ける、
ＳＭＴＰプロトコルを含む場合、情報データベースはこのクエリを電子メールアプリケーションと関連付ける。

情報データベース４のコンテンツは、予め手動で確立されることが可能であり、かつ／または受信されたＤＮＳクエリ内に含まれた情報を用いて、自動的に改善されることが可能である（自動学習）。情報データベース４は、これにより、ネットワークＢの管理者によって決定的に重要と思われるＤＮＳクエリ（例えば、電子商取引／電子銀行業務サービスまたは電子メールシステム）を区別することを可能にする。

一実施形態では、ＤＮＳクエリ解析器２は、情報データベース４によって識別されたサービスに基づいて、重要性のレベル（例えば、「決定的に重要」、「重要」、「並」、または１から１０の間の数）によって、それぞれのＤＮＳクエリをラベル付する。

ＤＮＳクエリを解決するために実行されることになる処理の選択は、例えば、以下に基づいて、ＤＮＳキャッシュ管理システム３からプログラムされ得る点に留意されたい。すなわち、
− 時間：ピーク時であるか否か、
− ＤＮＳキャッシュの利用可能性：保守、オーバラン、
− ＤＮＳクエリのソース：異なるタイプの加入を有するクライアント、
− ＤＮＳクエリが関連するサービス、例えば、電子商取引、電子銀行業務、電子メール、またはＶＰＮ、である。

一実施形態では、ＤＮＳクエリを解決するために、３つの可能な処理モードが区別され得る：
− ＤＮＳクエリが単一のＤＮＳキャッシュに送信される（例えば、図１に示される、ＤＮＳキャッシュ５＿１：リンク２５）、
− ＤＮＳクエリがＤＮＳクエリデコンセントレータ６に送信される（図１のリンク２６）、または
− ＤＮＳクエリがＤＮＳルートサーバ９に直接送信される（図１のリンク２９）。

ＤＮＳ応答は、以下のようにネットワークＢから取得され得る点に留意されたい。
− 再帰的：ＤＮＳクエリの受信時に、ＤＮＳサーバは、このクエリに関してそのローカルＤＮＳキャッシュ５＿ｊ（１≦ｊ≦ｎ）（例えば、図１に示されるＤＮＳキャッシュ５＿１）に問い合わせる。そのキャッシュがこのクエリに対する応答をローカルに有する場合、この応答はＤＮＳ応答モジュール１０に送信される（図１のリンク５１）。そうでない場合、ＤＮＳサーバは、レゾルバの役割を担い、要求された情報を有する可能性がより高い別のＤＮＳサーバ（すなわち、それが要求された情報を有する確率が十分に高いＤＮＳサーバ）にＤＮＳクエリを送信する。いずれのＤＮＳサーバもその応答を有さない場合、そのクエリは、そこからＤＮＳ応答のコピー（図１のリンク９５）がＴＴＬの間、ＤＮＳキャッシュ内に格納されることになるＤＮＳルートサーバ９に最終的に送信される（図１のリンク５９）、または
− 反復的：ＤＮＳキャッシュがＤＮＳクエリに対するローカルな応答を有さない場合、そのＤＮＳキャッシュは、要求された情報を有する可能性がより高い別のＤＮＳサーバにそのクエリを直接送信するようＤＮＳレゾルバ１に要求する。いずれのＤＮＳサーバもその応答を有さない場合、そのクエリは、最終的にＤＮＳルートサーバ９に送信される（図１のリンク２９）。ＤＮＳルートサーバ９によって戻されたＤＮＳ応答は、ＤＮＳレスポンダ１０に通信される（図１のリンク９１）。

別の実施形態では、ＤＮＳ応答は、以下のように、いくつかのＤＮＳキャッシュから統合された形で取得される：
− ＤＮＳクエリがＤＮＳクエリデコンセントレータ６に到着するとすぐ、そのＤＮＳクエリは、データベース６１内に格納された配信基準に従って、ＤＮＳキャッシュのリストに送信される（図１のリンク６５）。
− ＤＮＳキャッシュのリストによって取得されたＤＮＳ応答は、すべてＤＮＳ応答比較器７に送信される（図１のリンク５７）。
− 取得されたＤＮＳ応答に基づいて、比較器７は、情報データベース７０によって援助されて、
ＤＮＳ応答をＤＮＳレスポンダ１０に送信する（図１のリンク７１）、
または、取得された結果をＤＮＳ応答解析器８に送信する。
− ＤＮＳ応答解析器８は、ＤＮＳ応答を調査し、次いで、１つの単一のＤＮＳ応答をＤＮＳレスポンダ１０に送信する（図１のリンク８１）。

デコンセントレータ６による、ＤＮＳキャッシュのリストに対するＤＮＳクエリの配信は、データベース６１から取り出された情報に基づいて実行される点に留意されたい。データベース６１は、コンテンツの数、トポロジ、地理的位置、ＩＰアドレス、サイズ、およびＤＮＳキャッシュ５＿１、．．．、５＿ｎに接続されたユーザの数など、ネットワークＢ上のＤＮＳキャッシュ５＿１、５＿２、．．．、５＿ｎに関する情報を含む。

有利には、データベース６１内で利用可能なデータに基づいて、デコンセントレータ６は、関連すると見なされるＤＮＳキャッシュだけにＤＮＳクエリを中継することが可能である。実際に、一実施形態では、デコンセントレータ６によってＤＮＳクエリが中継されることになるＤＮＳキャッシュのリストは、以下に基づいて選択される：
− ＤＮＳサーバの位置など、データベース６１から取り出された情報。例えば、２つの空間的に遠いＤＮＳキャッシュの同じ無効データによるポイズニングのリスクはより少ないと仮定することによって、その場合：ＤＮＳキャッシュサーバがさらに分離されればされるほど、遠隔ＤＮＳキャッシュによって戻されたＤＮＳ応答と（比較器７によって決定された）同一である、ローカルＤＮＳキャッシュによって戻されたＤＮＳ応答が有効（正確）である可能性はより高くなる。特に、これは、コンピュータネットワークＢのトポロジに依存する、および／または
− ＤＮＳクエリ解析器２によって提供された情報：例えば、ＤＮＳ解析器２がＤＮＳクエリを「決定的に重要」とマーキングした場合、好ましくは、より多くの数のＤＮＳキャッシュが問い合わされることになる。すなわち、問い合わされることになるＤＮＳキャッシュの数は、好ましくは、ＤＮＳクエリが関連するサービスに依存する。これは、ＤＮＳ応答検証プロセスのパフォーマンスを最適化することをやはり可能にする。

次いで、ＤＮＳ応答比較器７は、問い合わされた（すなわち、ＤＮＳクエリデコンセントレータ６によって指定された）ＤＮＳキャッシュのリストから取得されたすべてのＤＮＳ応答を集中させて比較することを可能にする。

すべてのＤＮＳ応答が同一である場合、このＤＮＳ応答は、次いで、そのＤＮＳ応答をＤＮＳレゾルバ１に送信することになるＤＮＳレスポンダ１０に直接送信されることになる（図１のリンク７１）か、または（ＤＮＳレスポンダ１０を介さずに）ＤＮＳレゾルバ１に直接送信されることになる。

いくつかのドメインは、２つ以上のＩＰアドレス（または、その逆、すなわち、２つ以上のドメイン名に対応する１つのＩＰアドレス）を有し、この場合、（既に会社、例えば、ｅｂａｙ（ＴＭ）、Ｍｉｃｒｏｓｏｆｔ（ＴＭ）、ＨＳＢＣ（ＴＭ）、またはＹｏｕＴｕｂｅ（ＴＭ）に割り当てられている）データベース７０内に格納されたＩＰプレフィックスに対するアクセスを有する比較器７は、同一のドメイン名を区別するためにサブネットワークのＩＰアドレスを比較することが可能であることに留意されたい。ＤＮＳ応答がデータベース７０内で識別されていないＩＰアドレスを含む場合、そのＤＮＳ応答は、潜在的に無効ＤＮＳ応答であり得る。

２つの異なるＤＮＳキャッシュによって戻された２つのＤＮＳ応答を比較するために、ＤＮＳの逆引き解決を使用することも可能である：ＤＮＳキャッシュ（例えば、５＿１）を介して、別のＤＮＳキャッシュ（例えば、５＿２）によって戻されたＩＰアドレスに関連するドメイン名の逆引き解決（ｒｅｖｅｒｓｅ ｒｅｓｏｌｕｔｉｏｎ）を必要とする。２つのＤＮＳ応答同士の間の差異は、それら２つのＤＮＳキャッシュのうちの少なくとも１つのポイズニングを証明する。

それらのＤＮＳ応答が異なる場合、それらのＤＮＳ応答は、ＤＮＳ応答解析器８に送信される。ＤＮＳ応答解析器８は、
− ＤＮＳ応答の比率を計算する、
− その比率によってＤＮＳ応答を分類する、および
− それに応じて、以下のように動作する：
ＤＮＳレスポンダ１０に送信される（図１のリンク８１）ことになるか、もしくはレゾルバ１に直接送信されて、少なくとも問い合わされたＤＮＳキャッシュによって確認される（図１のリンク８５）ことになるＤＮＳ応答を保持する、または
問題が検出された場合、レゾルバ１にＤＮＳキャッシュポイズニング攻撃について通知するか、エラーをレゾルバ１に送信するか、レゾルバ１に何も送信しないか、またはＤＮＳキャッシュポイズニングの潜在的なリスクが存在することを示す内部警告をネットワークＢの管理者に送信することをトリガする等の動作をトリガする。

有利には、ＤＮＳ応答解析器８は、ネットワークＢの管理者によって構成／セットアップされ得る（例えば、しきい比率、またはＤＮＳキャッシュポイズニング問題が検出された場合にトリガされることになる動作）。

例示のための一例として、そのうちの４つが同一である５つのＤＮＳ応答が存在する場合、ＤＮＳ応答解析器８は、ＤＮＳレスポンダ１０に送信されることになるか、またはレゾルバ１に直接送信されることになる主応答（ｄｏｍｉｎａｎｔ ｒｅｓｐｏｎｓｅ）の存在を推定する。

５つのＤＮＳ応答のうち３つのＤＮＳ応答だけが同一であり、他の２つのＤＮＳ応答が異なる場合など、問い合わされたＤＮＳキャッシュによって戻されたＤＮＳ応答の間に整合性が存在しない場合、ＤＮＳ応答解析器８は、有効ＤＮＳ応答が存在するという結論を下すことができない。この場合、以下の動作が開始され得る：
− 潜在的なセキュリティ問題についてレゾルバ１に通知する。この情報は、ドメインに関する記述的情報を含むＤＮＳ応答の「ＴＸＴ」フィールド内に組み込まれることが可能である、
− 無効ＤＮＳ応答（例えば、低い比率を持つＤＮＳ応答）を無効ＤＮＳ応答１１のデータベース内に格納する、
− 潜在的なＤＮＳキャッシュポイズニング攻撃についてネットワークＢの管理者に通知する。

一実施形態では、ＤＮＳキャッシュによって戻されたＤＮＳ応答のセットのうち最高比率を有するＤＮＳ応答がＤＮＳクエリに対するＤＮＳ応答と見なされる。

無効ＤＮＳ応答が確認された場合、それが無効ＤＮＳ応答１１のデータベースに追加される（図１のリンク８２）。これは、後のＤＮＳクエリを解決するときに、ＤＮＳキャッシュに警告することを可能にする。

通信プロトコルは、ＤＮＳ応答解析器８からＤＮＳレスポンダ１０に（または、同等に、ＤＮＳレゾルバ１に）エラー通知を送信することに関する、ＩＥＴＦからのＲＦＣ５５０７に従って定義されることが可能である。

ＤＮＳ応答の比率に基づいて、１つまたは複数のＤＮＳキャッシュに関してポイズニング問題が推定される場合、当該ＤＮＳキャッシュのＴＴＬを０に削減する（例えば、ＤＮＳ応答のセットの中で低い比率を有するＤＮＳ応答を戻したＤＮＳキャッシュのＴＴＬを削減する）ためのコマンドが開始／プログラムされ得る。このコマンドは、即時であってよい：このコマンドは、ＴＴＬを即時に０に設定することからなる。あるいは、このコマンドは、算術的であってよい：このコマンドは、所定の減分（例えば、１秒または２秒）だけＴＴＬの継続的な削減を命令することからなってよい。あるいは、このコマンドは、幾何的であってよく、例えば、問題のＤＮＳキャッシュのＴＴＬが半分に分割されるよう命令することからなってよい。このコマンドは、ＤＮＳキャッシュにそのキャッシュを強制的に更新させることが意図される。例えば、３６００秒のＴＴＬを有するＤＮＳキャッシュ内のエントリは、０秒に設定されることが可能であり、これにより、無効になる。

ＤＮＳ応答の比率に基づいて、１つまたは複数のＤＮＳキャッシュに伴うポイズニング問題を推定する場合の代替の対策は、例えば、ＤＮＳゾーンの失効、またはその問題によって影響を受けるＤＮＳキャッシュ内の持続性のＤＮＳエントリの構成である。これは、その原因とされるＤＮＳキャッシュが後で問い合わされた場合、それらのＤＮＳキャッシュが有効値を戻すのを保証することを可能にする。この対策は、一時的であり、ＤＮＳキャッシュデータベースの動的構成を可能にするために後で削除されなければならない。

一実施形態では、ＤＮＳ応答比較器７およびＤＮＳ応答解析器は、結合されて単一の機能モジュールを形成する。

有利には、これにより取得されたＤＮＳ応答は、いくつかのＤＮＳキャッシュを通じて統合される。

有利には、ここで説明された方法は、ＩＳＰネットワーク内に既に存在しているＤＮＳキャッシュサーバのインテリジェントな使用を介して、ＤＮＳキャッシュポイズニング攻撃を防止することを可能にする。

別の実施形態では、ＤＮＳクエリデコンセントレータ６は、
− 少なくとも１つのＤＮＳキャッシュ（例えば、ＤＮＳキャッシュ５＿１）に、
− 少なくとも１つのＤＮＳルートサーバ９に
ＤＮＳクエリを中継して、次いで、当該ＤＮＳキャッシュおよび当該ＤＮＳサーバが戻すＤＮＳ応答を比較する。これはＤＮＳ応答比較器７に関して１つの追加のエントリを有することを可能にする。

ＤＮＳキャッシュポイズニングを防止することを可能にする別の実施形態は、ＤＮＳキャッシュコンテンツの有効性が検証される様式を変更する。すなわち、ＤＮＳプロトコルを使用して情報を交換する代わりに、別のＤＮＳキャッシュコンテンツ検証プロトコルが開発される。

有利には、ここで説明された実施形態は、大部分のＩＳＰネットワーク内で既に使用中である分散型ＤＮＳキャッシュシステムを使用する。

ここで説明された実施形態は、ネットワークＢに接続されたクライアントＡによって使用されるオペレーティングシステムに依存しない点に留意されたい。

別の実施形態では、ＤＮＳモジュール１０はオプションであり、ＤＮＳ応答は、したがって、ＤＮＳレゾルバ１に直接送信される。

別の実施形態では、そのカスタマの住居に設置されたＩＳＰの住宅用ゲートウェイは、ＤＮＳキャッシュである。オペレータのネットワークに接続されたこれらの住居用ゲートウェイは、次いで、モジュール２、６、５＿ｉ、および、オプションで、７、８、１０、ならびに、オプションで、これらのモジュールに関連するデータベースを結合させることが可能である。

Claims (9)

1. いくつかのＤＮＳキャッシュ（５＿１、５＿ｉ、５＿ｎ）を含むコンピュータネットワーク（Ｂ）内の少なくとも１つのＤＮＳキャッシュ（５＿ｉ）のポイズニングを防止するための方法であって、２つの異なるＤＮＳキャッシュによって戻された、ＤＮＳクエリに対する少なくとも２つのＤＮＳ応答を比較するステップと、ＤＮＳキャッシュに問い合わせる前に、ＤＮＳクエリを解析して、前記ＤＮＳクエリが関連するサービスを識別することを可能にするステップとを含み、
   問い合わされるＤＮＳキャッシュの数が、ＤＮＳクエリが関連するサービスに依存する、方法。
2. ＤＮＳ応答を比較するステップが、少なくとも１つのＤＮＳキャッシュによってＤＮＳクエリを逆引き解決するステップを含むことを特徴とする、請求項１に記載の方法。
3. ＤＮＳ応答を比較するステップが、ＤＮＳ応答の比率を計算するステップを含むことを特徴とする、請求項１に記載の方法。
4. ＤＮＳキャッシュによって戻されたＤＮＳ応答のセットのうち最高比率を有するＤＮＳ応答がＤＮＳクエリに対するＤＮＳ応答であることを特徴とする、請求項３に記載の方法。
5. ＤＮＳキャッシュによって戻されたＤＮＳ応答の間の不整合が以下の動作、すなわち、
   − セキュリティ問題についてＤＮＳクエリのソースに通知すること、
   − 少なくとも１つのＤＮＳキャッシュに対する潜在的なポイズニング攻撃についてコンピュータネットワーク（Ｂ）の管理者に通知すること、
   − これらのＤＮＳ応答のうちの少なくとも１つをデータベース（１１）内に格納すること
   のうちの少なくとも１つをトリガすることを特徴とする、請求項１に記載の方法。
6. ＤＮＳキャッシュのセットによって戻された応答のうち低い比率を有するＤＮＳ応答を戻すＤＮＳキャッシュの有効期間が、０に削減されることを特徴とする、請求項３に記載の方法。
7. ＤＮＳ応答が、ＤＮＳルートサーバ（９）によって戻されたＤＮＳ応答を含むことを特徴とする、請求項１から６のいずれかに記載の方法。
8. いくつかのＤＮＳキャッシュを含むコンピュータネットワーク内の少なくとも１つのＤＮＳキャッシュのポイズニングを防止するためのシステムであって、２つの異なるＤＮＳキャッシュによって戻された、ＤＮＳクエリに対する少なくとも２つのＤＮＳ応答の解析器と、ＤＮＳキャッシュに問い合わせる前に、ＤＮＳクエリに関連するサービスを識別することを可能にする、ＤＮＳクエリに関する情報のデータベース（４）を備えたＤＮＳクエリ解析器（２）とを備え、
   問い合わされるＤＮＳキャッシュの数が、ＤＮＳクエリが関連するサービスに依存する、システム。
9. ＤＮＳ応答が、ＤＮＳルートサーバ（９）によって戻されたＤＮＳ応答を含むことを特徴とする、請求項８に記載のシステム。

Images