(57)【要約】      （修正有）【課題】複数の回答を提供することができるＤＮＳクエリへの高速応答を提供する。【解決手段】トラフィック・マネージメント・アルゴリズム、手順、オペレーション、ロジック、または技術（ルールと総称される）をルックアップ・テーブルで表すためのシステム、方法、およびコンピュータ・プログラム製品であって、ドメイン名サーバは、トラフィック・マネージメント要件を実施等するためにトラフィック・マネージメント・コード、スクリプトなどを実行する必要なく、トラフィック・マネージメント要件に従って所与のドメイン名およびリソース・レコード・タイプに関する正しい回答を迅速に効率よく作成する。【選択図】図２
2014183586.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング・システムを使用して実現される、ネットワーク・トラフィックを管理するための方法であって、
要求元からドメイン名およびリソース・レコード・タイプを受信するステップと、
前記コンピューティング・システムを使用して、ならびに前記ドメイン名およびリソース・レコード・タイプを検索キーとして使用して、トラフィック・マネージメント・ルールを求めてテーブルを検索するステップであり、前記トラフィック・マネージメント・ルールが、前記トラフィック・マネージメント・ルールに影響を与える変数を指定する、ステップと、
前記コンピューティング・システムを使用して、前記トラフィック・マネージメント・ルールに影響を与える前記変数に関する値を特定するステップと、
前記コンピューティング・システムを使用するとともに、前記変数に関する前記値を検索キーとして使用して、前記ドメイン名に対応する回答を求めて前記テーブルを検索するステップと、
前記回答を前記要求元に提供するステップと
を含む方法。
【請求項２】
１つのＤＮＳトラフィック・マネージメント・ルールを前記テーブル内の１つの行として表すステップをさらに含む請求項１に記載の方法。
【請求項３】
ＤＮＳトラフィック・マネージメント・ルールのセットを前記テーブル内の複数の行として表すステップをさらに含む請求項１に記載の方法。
【請求項４】
前記ドメイン名およびリソース・レコード・タイプを検索キーとして使用するとともに、ルール・タイプを検索キーとして使用して、第２のトラフィック・マネージメント・ルールを求めて前記テーブルを検索するステップをさらに含む請求項１に記載の方法。
【請求項５】
前記コンピューティング・システムを使用するとともに、前記変数に関する前記値を検索キーとして使用して、前記ドメイン名およびリソース・レコード・タイプに対応する前記回答を求めて前記テーブルを検索するステップが、
前記ドメイン名およびリソース・レコード・タイプに対応する複数のリソース・レコードを求めて前記テーブルを検索するステップを含み、
前記回答を前記要求元に提供するステップが、
前記複数のリソース・レコードを前記要求元に提供するステップを含む請求項１に記載の方法。
【請求項６】
前記変数に関する前記値を検索キーとして使用して、前記回答に追加する、前記ドメイン名およびリソース・レコード・タイプに対応する情報を求めて前記テーブルを検索するステップと、
前記情報を前記要求元に提供するステップと
をさらに含む請求項１に記載の方法。
【請求項７】
プロセッサによって実行されたときに、
要求元からドメイン名およびリソース・レコード・タイプを受信するステップと、
前記コンピューティング・システムを使用するとともに、前記ドメイン名およびリソース・レコード・タイプを検索キーとして使用して、トラフィック・マネージメント・ルールを求めてテーブルを検索するステップであり、前記トラフィック・マネージメント・ルールが、前記トラフィック・マネージメント・ルールに影響を与える変数を指定するステップと、
前記コンピューティング・システムを使用して、前記トラフィック・マネージメント・ルールに影響を与える前記変数に関する値を特定するステップと、
前記コンピューティング・システムを使用して、および前記変数に関する前記値を検索キーとして使用して、前記ドメイン名およびリソース・レコード・タイプに対応する回答を求めて前記テーブルを検索するステップと、
前記回答を前記要求元に提供するステップと
を含むオペレーションを実現する命令を含む非一時的コンピュータ可読メディア。
【請求項８】
前記オペレーションが、
１つのＤＮＳトラフィック・マネージメント・ルールを前記テーブル内の１つの行として表すステップをさらに含む請求項７に記載の非一時的コンピュータ可読メディア。
【請求項９】
前記オペレーションが、
ＤＮＳトラフィック・マネージメント・ルールのセットを前記テーブル内の複数の行として表すステップをさらに含む請求項７に記載の非一時的コンピュータ可読メディア。
【請求項１０】
前記オペレーションが、
前記ドメイン名およびリソース・レコード・タイプを検索キーとして使用するとともに、ルール・タイプを検索キーとして使用して、第２のトラフィック・マネージメント・ルールを求めて前記テーブルを検索するステップをさらに含む請求項７に記載の非一時的コンピュータ可読メディア。
【請求項１１】
前記コンピューティング・システムを使用するとともに、前記変数に関する前記値を検索キーとして使用して、前記ドメイン名に対応する前記回答を求めて前記テーブルを検索するステップが、
前記ドメイン名およびリソース・レコード・タイプに対応する複数のリソース・レコードを求めて前記テーブルを検索するステップを含み、
前記回答を前記要求元に提供するステップが、
前記複数のリソース・レコードを前記要求元に提供するステップを含む請求項７に記載の非一時的コンピュータ可読メディア。
【請求項１２】
前記オペレーションが、
前記変数に関する前記値を検索キーとして使用して、前記回答に追加する、前記ドメイン名およびリソース・レコード・タイプに対応する情報を求めて前記テーブルを検索するステップと、
前記情報を前記要求元に提供するステップと
をさらに含む請求項７に記載の非一時的コンピュータ可読メディア。
【請求項１３】
ネットワーク・トラフィックを管理するためのシステムであって、
命令を含むメモリと、
前記メモリに動作可能に接続されているプロセッサとを含み、
前記プロセッサが、
要求元からドメイン名およびリソース・レコード・タイプを受信するステップと、
前記コンピューティング・システムを使用するとともに、前記ドメイン名およびリソース・レコード・タイプを検索キーとして使用して、トラフィック・マネージメント・ルールを求めてテーブルを検索するステップであり、前記トラフィック・マネージメント・ルールが、前記トラフィック・マネージメント・ルールに影響を与える変数を指定するステップと、
前記コンピューティング・システムを使用して、前記トラフィック・マネージメント・ルールに影響を与える前記変数に関する値を特定するステップと、
前記コンピューティング・システムを使用するとともに、前記変数に関する前記値を検索キーとして使用して、前記ドメイン名およびリソース・レコード・タイプに対応する回答を求めて前記テーブルを検索するステップと、
前記回答を前記要求元に提供するステップと
を含むオペレーションを行うように前記命令を実行するシステム。
【請求項１４】
前記オペレーションが、
１つのＤＮＳトラフィック・マネージメント・ルールを前記テーブル内の１つの行として表すステップをさらに含む請求項１３に記載のシステム。
【請求項１５】
前記オペレーションが、
ＤＮＳトラフィック・マネージメント・ルールのセットを前記テーブル内の複数の行として表すステップをさらに含む請求項１３に記載のシステム。
【請求項１６】
前記オペレーションが、
前記ドメイン名およびリソース・レコード・タイプを検索キーとして使用するとともに、ルール・タイプを検索キーとして使用して、第２のトラフィック・マネージメント・ルールを求めて前記テーブルを検索するステップをさらに含む請求項１３に記載のシステム。
【請求項１７】
前記コンピューティング・システムを使用するとともに、前記変数に関する前記値を検索キーとして使用して、前記ドメイン名およびリソース・レコード・タイプに対応する前記回答を求めて前記テーブルを検索するステップが、
前記ドメイン名に対応する複数のリソース・レコードを求めて前記テーブルを検索するステップを含み、
前記回答を前記要求元に提供するステップが、
前記複数のリソース・レコードを前記要求元に提供するステップを含む請求項１３に記載のシステム。
【請求項１８】
前記オペレーションが、
前記変数に関する前記値を検索キーとして使用して、前記回答に追加する、前記ドメイン名およびリソース・レコード・タイプに対応する情報を求めて前記テーブルを検索するステップと、
前記情報を前記要求元に提供するステップと
をさらに含む請求項１３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク・トラフィック・マネージメントに関し、より詳細には、トラフィック・マネージメント基準に応じて複数の回答を提供することができるＤＮＳクエリーへの高速応答を提供することに関する。
【背景技術】
【０００２】
ドメイン名システム（「ＤＮＳ」）は、インターネットに接続されているデバイスのための階層的なネーミング・システムである。その主要な目的は、ヒューマンフレンドリーなドメイン名（たとえば、ｅｘａｍｐｌｅ．ｃｏｍ）を、インターネットに接続されているデバイスによって使用されるインターネット・プロトコル（「ＩＰ」）アドレス（たとえば、１９２．０．２．１）に変換することである。ユーザが、特定のインターネット・サイトを見つけ出すためにドメイン名を自分のブラウザに打ち込むなど、要求元が、ドメイン名のＩＰアドレス（「Ａ」レコード）を求めるＤＮＳ要求（ＤＮＳクエリーとしても知られている）を行った場合には、そのＤＮＳ要求は、再帰的なＤＮＳサーバへ送信され、次いで、その再帰的なＤＮＳサーバは、そのドメイン名に関する権威ＤＮＳサーバが探し出されるまで、サーバの階層的なシステムに要求を行う。そして、そのユーザの要求は、権威ＤＮＳサーバへ送信され、権威ＤＮＳサーバは、そのドメイン名に対応するＩＰアドレスを伴って応答する。要求されたドメイン名に関するエントリー（たとえば、ＤＮＳリソース・レコード）が見つかった場合には、ＤＮＳ返答が要求元に発行され、その返答は、要求されたドメイン名に対応するサーバまたはその他のリソースのＩＰアドレスを含む。その返答からのＩＰアドレスを使用して、要求元のコンピュータ／ブラウザは、要求されたドメイン名に関連付けられているウェブサイトをホストしているサーバに接続することができる。
【０００３】
ＤＮＳトラフィック・マネージメントは、ＤＮＳクエリーに応答して要求元に提供するためのリソース・レコードのセットを所与のドメイン名に関する複数の選択肢の中から選択することに関する。たとえば、あるドメイン名（たとえば、ｅｘａｍｐｌｅ．ｃｏｍ）に、複数のサーバ（たとえば、１９２．０．２．１および１９２．０．２．２というＩＰアドレスを有する東海岸のウェブ・サーバ、ならびに２０３．０．１１３．１というＩＰアドレスを有する西海岸のウェブ・サーバ）が関連付けられており、それらのサーバのすべてが、そのドメイン名に関するウェブサイトをホストしていると考えていただきたい。この例においては、トラフィック・マネージメントをサポートする権威ＤＮＳサーバは、「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に関連付けられているＩＰアドレスを求めるＤＮＳクエリーを受信した場合には、２つの回答のうちの１つを選択して、返す（すなわち、この例においては、１９２．０．２．１および１９２．０．２．２を返すか、または２０３．０．１１３．１を返す）。この選択は、そのドメイン名に関して指定されているトラフィック・マネージメント・ルール、基準、または要件に従って行われる。ＤＮＳは、ＩＰアドレス以外の情報を格納するために使用されることが可能である。たとえば、ＴＸＴレコードを使用してドメイン名をテキスト値に関連付けることが可能である。それぞれの要求は、返されるべき情報のタイプ（ＩＰｖ４アドレスを表す「Ａ」、または一般的なテキストを表す「ＴＸＴ」）、およびドメイン名の両方を含む。応答は、所与のドメイン名に関連付けられている指定されたタイプのすべてのリソース・レコードから構成される回答を含むことになる。記載されているトラフィック・マネージメントは、すべてのリソース・レコード・タイプに当てはまる。
【発明の概要】
【０００４】
毎日、時々刻々発生して急速に増大している膨大な数のＤＮＳクエリーのために、および最小の遅延をユーザが期待しているために、ＤＮＳシステムは、ＩＰアドレスおよびその他の必要とされる情報をＤＮＳ要求に応答して非常に迅速に提供しなければならない。しかしながら、現在のＤＮＳトラフィック・マネージメント技術およびアルゴリズムは、応答時間を遅らせている。なぜなら、複数の回答のうちのどの回答を返すべきかを選択することが、それぞれのドメイン名クエリーに関するコードまたはスクリプトを動的に起動または実行することを必要とするためである。いくつかの因子（たとえば、ロード・バランシング因子、コスト因子、地理的場所因子など）に基づき、かついくつかの別々の回答の選択を含む複雑なトラフィック・マネージメントの決定に関しては、これは、特に時間がかかる場合がある。なぜなら、最終的な回答に至るために、マルチセクションまたは複数のアルゴリズムが実行されるためである。
【０００５】
同様に、ＤＮＳクエリーへの応答時間を遅らせるその他のいかなる処理も弊害である。たとえば、ＤＮＳクエリーへの応答を暗号化することまたはそれらの応答にデジタル署名することなどのセキュリティー処理は、計算負荷が大きく、時間がかかる。
【発明が解決しようとする課題】
【０００６】
したがって、ＤＮＳクエリーへの応答のための、およびＤＮＳクエリーへの応答に関連付けられているその他の処理のためのさらに迅速でさらに効率的なトラフィック・マネージメント機能を提供するための改良されたシステム、方法、および技術を開発することが望ましい。
【課題を解決するための手段】
【０００７】
本開示は、ネットワーク・トラフィックを管理するための方法、システム、および製品の実施形態を提供する。これらの方法、システム、および製品のさまざまな実施形態は、要求元からドメイン名およびリソース・レコード・タイプを受信するステップと、そのドメイン名およびリソース・レコード・タイプを検索キーとして使用して、トラフィック・マネージメント・ルールを求めてテーブルを検索するステップとを含むオペレーションを実行することができる。さまざまな実施形態においては、トラフィック・マネージメント・ルールは、応答内に含まれる回答に影響を与える変数の値を指定する。次なるオペレーションは、受信された要求に基づいて、トラフィック・マネージメント・ルールに影響を与える変数に関する値を特定するステップと、変数に関するその値を検索キーとして使用して、ドメイン名に対応する回答を求めて、第１のオペレーションにおいて見つかったトラフィック・マネージメント・ルールを検索するステップと、その回答を要求元に提供するステップとを含む。
【０００８】
さまざまな実施形態は、やはり１つのＤＮＳトラフィック・マネージメント・ルールをテーブル内の１つの行として表すための、またはＤＮＳトラフィック・マネージメント・ルールのセットをテーブル内の複数の行として表すための手段、ステップ、アルゴリズム、およびオペレーションを含むこともできる。その他の変形形態はまた、ドメイン名を検索キーとして使用して、およびルール・タイプを検索キーとして使用して、第２のトラフィック・マネージメント・ルールを求めてテーブルを検索し、すなわち、第１のトラフィック・マネージメント・ルールの結果が、第２のトラフィック・マネージメント・ルールである。さらに他の変形形態は、ドメイン名に対応する複数のリソース・レコードを求めてテーブルを検索すること、およびそれらの複数のリソース・レコードを要求元に提供することが可能である。ある変形形態は、ＩＰアドレス（「Ａ」レコード）を検索するステップを含むことができる。別の変形形態は、テキスト（「ＴＸＴ」レコード）を検索するステップを含むことができる。さらに他の変形形態は、変数に関する値を検索キーとして使用して、ＩＰアドレスに追加する、ドメイン名に対応する情報を求めてテーブルを検索すること、およびその情報を要求元に提供することが可能である。
【０００９】
ＤＮＳシステムに、およびリソース・レコードに固有ではないその他の変形形態も可能である。
【００１０】
上述の概要および以降の詳細な説明は両方とも、例示的かつ説明的なものにすぎず、特許請求されているのと同様に本発明を限定するものではないということを理解されたい。
【００１１】
本発明と整合するさらなる特徴、実施態様、および実施形態は、以降に続く説明において部分的に示されることになるか、または本発明の実践によって理解されることが可能である。本発明の境界および範囲は、添付の特許請求の範囲において特に指摘されている要素および組合せを用いて画定されることになる。
【００１２】
添付の図面は、本明細書に組み込まれて本明細書の一部を構成しており、本発明の実施形態を例示し、記述とともに、本発明の原理を説明する役割を果たす。
【図面の簡単な説明】
【００１３】
【図１】ＤＮＳトラフィック・マネージメントを用いてＤＮＳクエリーを処理するための従来のシステムを示す図である。
【図２】本発明の原理と整合する、ＤＮＳトラフィック・マネージメントを用いてＤＮＳクエリーを処理するための例示的なシステムを示す図である。
【図３Ａ】トラフィック・マネージメント・ルールを実施する従来のスクリプトの一例である。
【図３Ｂ】本発明の原理と整合する、トラフィック・マネージメント・テーブルのセットの一例である。
【図４】本発明の原理と整合する、トラフィック・マネージメント・テーブルのセットの別の例である。
【図５】本発明の実施形態と整合する、ＤＮＳトラフィック・マネージメント・ルールのハイ・パフォーマンスの実施態様のための例示的なプロセスのフローチャートである。
【図６】本発明の実施形態と整合するシステムおよび方法を実施する上で有用な例示的なコンピューティング・システムのブロック図である。
【発明を実施するための形態】
【００１４】
次いで、本発明の例示的な実施形態に詳細に言及する。それらの実施形態の例は、添付の図面において示されている。都合のよい場合は常に、同じまたは同様の部分を指すために図面を通じて同じ参照番号が使用される。
【００１５】
本発明と整合するさまざまな実施形態は、トラフィック・マネージメント・アルゴリズム、手順、オペレーション、ロジック、または技術（ルールと総称される）をルックアップ・テーブルで表すためのシステム、方法、およびコンピュータ・プログラム製品を提供し、それによって、ドメイン名サーバは、トラフィック・マネージメント要件を実施等するためにトラフィック・マネージメント・コード、スクリプトなどを実行する必要なく、トラフィック・マネージメント要件に従って所与のドメイン名およびリソース・レコード・タイプに関する正しい回答を迅速に効率よく作成することができる。さまざまな実施形態においては、回答は、ＩＰアドレス（「Ａ」リソース・レコード・タイプ）またはテキスト（「ＴＸＴ」リソース・レコード・タイプ）であることが可能である。いくつかの実施形態においては、対応するデジタル署名などの回答に追加する情報を格納すること、ルックアップすること、およびその回答とともに返すことが可能である。
【００１６】
本明細書に記載されているさまざまな実施形態、および本発明と整合するその他の実施形態は、それぞれのゾーンに関するＤＮＳトラフィック・マネージメント要件またはルールをデータ・テーブルまたはルックアップ・テーブルのセット内の行として表すことができ、そのデータ・テーブルのセットは、それぞれの解決サイトにおける解決サーバのそれぞれのインスタンスにおいて展開されることが可能である。本発明と整合する実施形態は、ＤＮＳクエリーに応答する際の解決サーバの計算ワークロードを大幅に減らすという点で、既存のＤＮＳトラフィック・マネージメント技術に勝る著しいパフォーマンス上の利点を提供する。これは、トラフィック・マネージメント・コード、ロジック、またはスクリプトを実行する代わりに、トランザクションが、ＤＮＳクエリーによって指定されたドメイン名のトラフィック・マネージメント基準に対応する関連したテーブル行をルックアップすることまたは検索することを含むためである。
【００１７】
図１は、ＤＮＳトラフィック・マネージメントを用いてＤＮＳクエリーを処理するための従来のシステム１００を示している。示されているように、ユーザ１１０は、クライアント・コンピュータ１２０を使用することができ、クライアント・コンピュータ１２０は、（ドメイン名、たとえばｅｘａｍｐｌｅ．ｃｏｍと、ＩＰアドレスを表すリソース・レコード・タイプ「Ａ」とを指定する）ＤＮＳクエリー１２５をＤＮＳ解決サーバ１３０へ送信するためにブラウザ（図示せず）を実行していることが可能である。
【００１８】
ＤＮＳクエリー１２５を受信すると、ＤＮＳ解決サーバ１３０は、ユーザ１１０のクライアント・コンピュータ１２０へ返すための対応する回答（通常はＩＰアドレスを含む）１６０をルックアップまたは検索するよう試みる。唯一の対応する回答（図示せず）が存在する場合には、ＤＮＳ解決サーバ１３０は、ＤＮＳクエリー１２５において指定されたドメイン名によってインデックス付けされたテーブル・ルックアップを使用して、その回答を見つけ出し、返すことができる。その一方で、複数の対応する回答が存在する場合には、ＤＮＳ解決サーバ１３０は、適切な回答を選択するためにＤＮＳトラフィック・マネージメント機能を実行しなければならない。示されている例においては、ＤＮＳ解決サーバ１３０は、ＤＮＳクエリー１２５において指定されたドメイン名１３５およびリソース・レコード・タイプによってインデックス付けされたテーブル・ルックアップを最初に実行することができ、単一の回答を見つけ出す代わりに、トラフィック・マネージメント・インジケータ１４０を見つけ出すことができ、トラフィック・マネージメント・インジケータ１４０は、ドメイン名およびリソース・レコード・タイプ１３５に関連付けられている複数の可能な回答の中から返すための、正しい回答１６０を見つけ出すために、トラフィック・マネージメント処理が実行されなければならないということを示す。
【００１９】
トラフィック・マネージメント機能を提供するために、いくつかの従来のＤＮＳ解決サーバ１３０は自ら、返すための適切な回答１６０を特定するためにトラフィック・マネージメント・ルールの実行１４５を行う。このアプローチは、ＤＮＳ解決サーバ１３０の処理リソースを遅くして拘束するという欠点を有する。なぜなら、ＤＮＳ解決サーバ１３０は、トラフィック・マネージメント・コードまたはスクリプトを実行して、多くのクライアント／要求元から継続的に着信してくる新たなＤＮＳクエリーにサービス提供する自分の能力を遅くするためである。トラフィック・マネージメント・ルールの実行１４５を自ら行う代わりに、いくつかの従来のＤＮＳ解決サーバ１３０は、トラフィック・マネージメント・ルール・スクリプト・サーバ１５０への破線の矢印およびトラフィック・マネージメント・ルール・スクリプト・サーバ１５０からの破線の矢印によって示されているように、トラフィック・マネージメント・ルールの実行１４５’を実行するようトラフィック・マネージメント・ルール・スクリプト・サーバ１５０に指示する。これは、ＤＮＳ解決サーバ１３０からトラフィック・マネージメント処理をオフロードするが、要求を行っているクライアント・コンピュータ１２０へ回答１６０を返すのに、より長くかかるという欠点を有する。なぜなら、トラフィック・マネージメント・ルールの実行１４５’を行うためにトラフィック・マネージメント・コードまたはスクリプトを実行する遅延があるだけでなく、ＤＮＳ解決サーバ１３０とトラフィック・マネージメント・ルール・スクリプト・サーバ１５０との間における通信のさらなる遅延もあるためである。
【００２０】
トラフィック・マネージメント・ルールの実行１４５／１４５’は、複数の回答のうちのどの回答を返すべきかを選択するためのさまざまなトラフィック・マネージメント技術およびアルゴリズムを実行することを伴う。述べたように、これらの技術およびアルゴリズムは、典型的には、１つまたは複数の変数または因子（たとえば、要求を行っているコンピュータ１２０の地理的場所、時刻、乱数の値など）の状態または値を特定して、次いで所定のトラフィック・マネージメント基準に関連してその１つまたは複数の変数の状態または値に基づいて、返すための回答を選択するコンピュータ実行可能コードまたはコンピュータ実行可能スクリプト（など）として実施される。ドメイン名要求またはクエリー１２５に関してどの回答を返すべきかというトラフィック・マネージメントの選択は、典型的には、下記のような因子または変数に依存する。
・  要求元の地理的場所またはＩＰアドレス（たとえば、地理的に最も近いウェブ・サーバのＩＰアドレスを選択する  −  東海岸か、または西海岸か）。
・  時刻（たとえば、午前６時から午後５時５９分まではサーバ１のＩＰアドレスを選択し、午後６時から午前５時５９分まではサーバ２のＩＰアドレスを選択する）。
・  宛先へのトランザクションに関連付けられている待ち時間（たとえば、より速いネットワーク接続を提供するサーバのＩＰアドレスを選択する）。
・  宛先ＩＰアドレスのサービスを使用する金銭的コスト。これは、時間および地理的場所に基づいて変わる場合がある（たとえば、午前６時から午後５時５９分までは東海岸のサーバのＩＰアドレスを選択し、午後６時から午前５時５９分までは西海岸のサーバのＩＰアドレスを選択する）。
・  別々のウェブ・サーバの間においてクエリー・ボリューム・ロードのバランスを取ること（ＤＮＳ要求のうちの６０％に関しては、東海岸のサーバのＩＰアドレスを選択し、４０％に関しては、西海岸のアドレスを選択する）。
・  フェイル・オーバー（東海岸のサーバがダウンした場合には、常に西海岸のサーバのＩＰアドレスを選択し、その逆もまた同様である）。
【００２１】
ＤＮＳトラフィック・マネージメントを例示するために、仮想のケースについて考えていただきたい。このケースでは、「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に、３つのサーバが関連付けられており、２つのサーバは、米国の東海岸に配置されており（１９２．０．２．１というＩＰアドレスを有する東海岸の第１サーバ、および１９２．０．２．２というＩＰアドレスを有する東海岸の第２サーバ）、１つのサーバは、西海岸に配置されている（２０３．０．１１３．１というＩＰアドレスを有する西海岸のサーバ）。さらに、「ｅｘａｍｐｌｅ．ｃｏｍ」の登録者が、（３つのサーバすべてによってホストされている）自分のウェブサイトへのトラフィックを管理し、それによって下記のことを行いたいと望んでいると考えていただきたい。
１）ミシシッピー川の東に位置しているユーザは、東海岸のサーバのうちの１つへ導かれる。
２）東海岸のサーバ同士は、東海岸の第１サーバが東部のトラフィックの８０パーセントを受信して、東海岸の第２サーバが残りの２０パーセントを受信するようにロード・バランスされる。
３）ミシシッピー川の西に位置しているユーザは、西海岸のサーバへ導かれる。
４）３つのサーバのいずれかがダウンした場合には、ダウンしなかったならばそのサーバへ向かうことになっていたトラフィックは、アップしている別のサーバへ導かれる。
５）３つのサーバのすべてがダウンした場合には、トラフィックは、東海岸の第２サーバへ導かれることになる。
【００２２】
次いで図３Ａを参照すると、これらのトラフィック・マネージメント・ルールは、従来は、「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に関するＤＮＳクエリー１２５がＤＮＳ解決サーバ１３０によって受信されるたびに実行されるスクリプト３００によって実現されることが可能である。上述のように、スクリプト３００は、ＤＮＳ解決サーバ１３０そのものによって、またはトラフィック・マネージメント・ルール・スクリプト・サーバ１５０によって実行されることが可能である。しかし、いずれにしても、複数の回答のうちのどの回答を返すべきかを決定するスクリプト３００は、クエリー１２５におけるそれぞれのドメイン名要求に関して動的に起動または実行され、スクリプト３００の実行は、要求を行っているコンピュータ１２０への応答を著しく遅らせることがある。その上、トラフィック・マネージメント・ルールが複雑であればあるほど、スクリプト３００はさらに長くさらに複雑になり、スクリプト３００を実行するのにかかる時間もさらに長くなる。図３Ａについては、以降でさらに詳細に説明する。
【００２３】
再び図１を参照すると、ＤＮＳ解決サーバ１３０は、破線の形状によって表されているように、ドメイン名セキュリティー拡張（ＤＮＳＳＥＣ）を任意選択で実現することもできる。ＤＮＳＳＥＣは、パブリックキー暗号化を使用して、回答１６０（たとえば、サーバのＩＰアドレス）を構成するレコードにデジタル署名することによって機能し、ひいては、ＤＮＳ解決サーバ１３０は、自分の内部のトラフィック・マネージメント・ルールの実行１４５から返された回答１６０のデジタル署名を作成するために、または外部のトラフィック・マネージメント・ルール・スクリプト・サーバ１５０によって実行されたトラフィック・マネージメント・ルールの実行１４５’から返された回答１６０のデジタル署名を作成するために、ＤＮＳＳＥＣプライベート・キー１５７を使用して、ＤＮＳＳＥＣ署名ロジック１５５を実行することができる。ＤＮＳＳＥＣデジタル署名ロジック１５５は、集中的に処理を行っており、ＤＮＳ解決サーバ１３０の処理リソースを遅くして拘束するというマイナスの効果を有し、やはり、多くのクライアント／要求元から継続的に着信してくる新たなＤＮＳクエリーにサービス提供する自分の能力を遅くする。
【００２４】
自分のトラフィック・マネージメント基準に従って、クエリーされているドメイン名１３５に関する正しい回答１６０を識別または選択した後に、およびＤＮＳＳＥＣプライベート・キー１５７を使用して、回答１６０に任意選択でデジタル署名した後に、ＤＮＳ解決サーバ１３０は、要求を行っているクライアント・コンピュータ１２０へ回答１６０を返し、クライアント・コンピュータ１２０は、ドメイン名１３５に関連付けられているサーバ（またはその他のネットワーク・リソース）に接続するために回答１６０を使用する。
【００２５】
システム１００のコンポーネントおよび実施態様の詳細は、説明を簡潔および明確にするために提示されている簡略化された例であるということを当業者なら認識するであろう。その他のコンポーネント、実施態様の詳細、および変形形態が使用されることも可能である。たとえば、図１、および本明細書に記載されているすべての実施形態に関しては、ＤＮＳ解決サーバ１３０によって返される情報は、説明を簡潔および明確にするために単に回答１６０として記載されているが、ＤＮＳ解決サーバ１３０は、実際には、ＤＮＳ要求１２５に関連しているＤＮＳリソース・レコード・セットを処理することおよび返すことを含めて、当技術分野においてよく知られているすべての従来のＤＮＳ標準および要件を実施するということを当業者なら認識するであろう。たとえば、ＤＮＳ標準に従って、ＤＮＳ解決サーバ１３０は、要求を行っているクライアント・コンピュータ１２０への回答１６０として、ＩＰアドレスを含むＡレコードもしくはＡＡＡＡレコード、および／または対応するＤＮＳＳＥＣ署名を伴うＲＲＳＩＧレコードを返すことができる。
【００２６】
図２は、本発明の原理と整合する、改良されたＤＮＳトラフィック・マネージメントを用いてＤＮＳクエリーを処理するための例示的なシステム２００を示している。図１と同様に、ユーザ１１０は、クライアント・コンピュータ１２０を使用することができ、クライアント・コンピュータ１２０は、（ドメイン名およびリソース・レコード・タイプ１３５、たとえば、ｅｘａｍｐｌｅ．ｃｏｍに関する「Ａレコード」を指定する）ＤＮＳクエリー１２５をＤＮＳ解決サーバ２３０へサブミットするためにブラウザ（図示せず）を実行していることが可能である。
【００２７】
ＤＮＳクエリー１２５を受信すると、ＤＮＳ解決サーバ２３０は、ユーザ１１０のクライアント・コンピュータ１２０へ返すための対応するＩＰアドレス／回答１６０をルックアップまたは検索するよう試みる。さまざまな実施形態においては、クエリー１２５に含まれているドメイン名およびリソース・レコード・タイプ１３５は、このルックアップのための検索キーとして使用される。唯一の対応する回答（図示せず）が存在する場合には、ＤＮＳ解決サーバ２３０は、ＤＮＳクエリー１２５において指定されたドメイン名およびリソース・レコード・タイプ１３５によってインデックス付けされたテーブル・ルックアップを使用して、その回答を見つけ出し、返すことができる。その一方で、選択元となる複数の対応する回答が存在する場合には、ＤＮＳ解決サーバ２３０は、ドメイン名１３５およびリソース・レコード・タイプに関連付けられている複数の可能な回答の中から、返すための正しい回答１６０を見つけ出すために、トラフィック・マネージメントが実行されなければならないということを指示する、リンク、ポインタ、またはルックアップ・キーなどのインジケータ２４０を見つけ出すことができる。
【００２８】
示されている実施形態においては、ＤＮＳ解決サーバ２３０は、トラフィック・マネージメント・コード／スクリプトを実行せず、また、トラフィック・マネージメント・コード／スクリプトの計算を別のサーバへオフロードせず、その代わりに、複数の可能な回答の中から、返すための正しい回答１６０を見つけ出すために、さらなる（１つもしくは複数の）テーブル・ルックアップまたは（１つもしくは複数の）検索を実行する。それらのテーブルは、ドメイン名１３５およびリソース・レコード・タイプに関連付けられているトラフィック・マネージメント・ルールに従って適切な回答を返すように設計されている。テーブル・ルックアップは、比較的高速であり、わずかな処理リソースおよびわずかな処理時間しか必要としない。したがって、ＤＮＳ解決サーバ２３０は、図１において示されているＤＮＳ解決サーバ１３０の欠点にさいなまれることはない。そして、より高速なＤＮＳクエリー応答に加えて、ＤＮＳ解決サーバ２３０はまた、ＤＮＳ解決サーバ１３０よりも、サービス妨害（ＤＯＳ）攻撃を受けにくい。それは一部には、ＤＮＳ解決サーバ２３０が、より高速に、およびより低いプロセッサ使用度でＤＮＳクエリーに応答するためである。
【００２９】
図２に示されている実施形態においては、所与のドメイン名１３５およびリソース・レコード・タイプを解決するためのトラフィック・マネージメント・ルールは、（１つまたは複数の）トラフィック・マネージメント・テーブル２４５内の一連の行として表されており、可能なあらゆるシナリオをカバーするために行が必ず存在するようにしてある。同様に、所与のゾーン（たとえば、ＤＮＳ解決サーバ２３０によって取り扱われるすべてのドメイン名）を解決するためのトラフィック・マネージメント・ルールは、すべてのドメイン名クエリーが同じ方法で処理されるように（１つまたは複数の）トラフィック・マネージメント・テーブル２４５において表されている。
【００３０】
したがって、ＤＮＳクエリー１２５においてドメイン名およびリソース・レコード・タイプ１３５を受信すると、ＤＮＳ解決サーバ２３０は、トラフィック・マネージメント機能を表す（１つまたは複数の）トラフィック・マネージメント・テーブル２４５内の（１つまたは複数の）行へ導かれるインジケータ２４０、たとえば、リンク、検索キー、またはポインタなどを見つけ出すことができ、その場合、次いでその行は、所望の回答１６０、または、さらなるトラフィック・マネージメント機能を実行する（１つまたは複数の）トラフィック・マネージメント・テーブル２４５内の別の行のルックアップを可能にする別のリンク、ポインタ、インデックス、検索キーなどを含むことができる。述べたように、（１つまたは複数の）トラフィック・マネージメント・テーブル２４５は、ルックアップまたは検索プロセスが、可能なあらゆるトラフィック・マネージメント・シナリオをカバーする一式のまたは一連の行を通じて導かれること、およびＤＮＳ標準に従って、要求を行っているクライアント・コンピュータ１２０への回答１６０またはその他の決定的な応答へ最終的に至ることを確実にするように設計されている。
【００３１】
このアプローチでは、トラフィック・マネージメント・ルールの分岐および流れをコントロールするためにいかなるスクリプトまたはコードの実行も必要とされない。コード実行環境をセットアップすることまたは別個のサーバと通信することに関連付けられている処理オーバーヘッドもまったく存在しない。さまざまな実施形態においては、ＤＮＳ解決サーバ２３０によって行われるトラフィック・マネージメント関連の計算は、トラフィック・マネージメント機能の決定のための基準として使用される任意の変数の現在の値をフェッチおよび／または特定することだけであり、それらの変数は、いくつかの実施形態においては、テーブル・ルックアップのための検索インデックスとして使用されることまたは表されることが可能である。そのような変数の例としては、要求元の（たとえば、クライアント・コンピュータ１２０の）地理的場所、重み付けされたロード・バランシングの決定のために使用される乱数の値、ウェブ・サイト・サーバの稼働（アップ）または非稼働（ダウン）のステータスなどが含まれる。トラフィック・マネージメント・ルールまたは基準が適用されるドメイン名およびリソース・レコード・タイプを解決する際に、ＤＮＳ解決サーバ２３０は、（１つまたは複数の）トラフィック・マネージメント・テーブル２４５内の適切な（１つまたは複数の）行を順次ルックアップすることによって、適切な回答を検索して見つけ出すことまたは識別することが可能である。このアプローチのさまざまな実施形態は、それぞれのドメイン名所有者２５５に関するトラフィック・マネージメント・ルールの複雑さをサポートすることに対する実際の制限をまったく有さないことが可能である。なぜなら、トラフィック・マネージメント・ルールがより複雑になれば、その結果、可能なあらゆるルックアップ・シナリオをカバーするためにそれぞれのテーブル内の行が増えるだけであるからである。
【００３２】
示されている実施形態においては、ＤＮＳ解決サーバ２３０は、ドメイン名所有者インターフェース２５０を含み、ドメイン名所有者インターフェース２５０は、ドメイン名所有者２５５が、自分のドメイン名に適用されることになる、および（１つまたは複数の）トラフィック・マネージメント・テーブル２４５において表されるトラフィック・マネージメント・ルールを構成することを可能にする。いくつかの実施形態においては、ドメイン名所有者２５５は、トラフィック・マネージメント・ルールを（たとえば、図３Ａにおいて示されているような）スクリプトまたはその他の実行可能なもしくは解釈可能なコードもしくは疑似コードの形態で提供または入力することができ、ドメイン名所有者インターフェース２５０は、そのスクリプトまたはコードを（１つまたは複数の）トラフィック・マネージメント・テーブル２４５内の対応するエントリーへと変換することができる。その他の実施形態においては、ドメイン名所有者インターフェース２５０は、グラフィカル・ユーザ・インターフェースを提供することができ、そのグラフィカル・ユーザ・インターフェースは、ドメイン名所有者２５５が、自分のサーバ（またはその他のリソース）およびトラフィック・マネージメントに関する自分の要件を、上述のパラグラフ００２４において示されているのと同様の、より自然な言語フォーマットで入力および指定することを可能にし、それを、インターフェース２５０が、（１つまたは複数の）トラフィック・マネージメント・テーブル２４５内の対応するエントリーへと変換する。
【００３３】
ＤＮＳ解決サーバ２３０がＤＮＳＳＥＣを実装するいくつかの実施形態においては、（１つまたは複数の）トラフィック・マネージメント・テーブル２４５は、トラフィック・マネージメント・テーブル・ルックアップまたは検索から返されるそれぞれの回答１６０に関連付けられているデジタル署名を含むことができる。そのような実施形態においては、返されることが可能である有限数の回答（たとえば、図３Ａに関して提示されている例のケースにおいては、３つの別々のＩＰアドレス）が存在するため、それぞれに関するＤＮＳＳＥＣデジタル署名が、テーブル・セットアップ時に事前計算されること、次いで格納されること、および、それぞれの回答１６０がルックアップされるのと同じ様式でそれぞれのＤＮＳクエリー１２５に関して必要とされた際にルックアップされることが可能である。ＤＮＳＳＥＣデジタル署名は、別のコンピューティング・システム上でオフラインで事前計算されることが可能であるため、要求ごとに有効なデジタル署名および信頼チェーンを生成するためにプライベートＤＮＳＳＥＣキー１５７をＤＮＳ解決サーバ２３０に配布する必要がない。ＤＮＳＳＥＣ処理に関して、本出願は、弁理士整理番号１１５６９．０２１１を有する、Ｒａｍａｋａｎｔ  ＰａｎｄｒａｎｇｉおよびＤａｖｉｄ  Ｂｌａｃｋａによる、「Ｓｙｓｔｅｍｓ  ａｎｄ  Ｍｅｔｈｏｄｓ  ｆｏｒ  Ｐｒｅ−Ｓｉｇｎｉｎｇ  ｏｆ  ＤＮＳＳＥＣ  Ｅｎａｂｌｅｄ  Ｚｏｎｅｓ  ｉｎｔｏ  Ｒｅｃｏｒｄ  Ｓｅｔｓ」と題されている同時係属出願、すなわち米国特許出願第＿号明細書（出願日：２０１３年３月＿日）にいくらか関連しており、この同時係属出願は、その全体が参照によって本明細書に組み込まれている。
【００３４】
システム２００のコンポーネントおよび実施態様の詳細は、説明を簡潔および明確にするために提示されている簡略化された例であるということを当業者なら認識するであろう。その他のコンポーネント、実施態様の詳細、および変形形態が使用されることも可能である。たとえば、ドメイン名所有者インターフェース２５０は、ＤＮＳ解決サーバではない別のコンピューティング・システムへ移動されることが可能である。そのような実施形態においては、あるゾーンに関する（１つまたは複数の）トラフィック・マネージメント・テーブル２４５は、そのゾーン内のドメインを有するさまざまなドメイン名所有者からの入力を用いてオフラインで構成されることが可能であり、次いでその（１つまたは複数の）トラフィック・マネージメント・テーブル２４５は、解決サイトにおけるＤＮＳ解決サーバ２３０のそれぞれの稼働インスタンスへ展開されることが可能である。別の例に関しては、当業者なら認識するであろうが、トラフィック・マネージメント・ルールは、例示的な実施形態において説明されている（１つまたは複数の）ルックアップ・テーブル以外に、コードまたはスクリプトを実行することに勝るパフォーマンス上の利点を提供する高速データ構造内に含まれることが可能である。さらに別の例に関しては、本出願のいたるところに記載されている機能は、専用のＤＮＳ解決サーバ２３０の代わりに、クラウドによって実施されてもよい。
【００３５】
図３Ａは、トラフィック・マネージメント・ルールを実施する従来のトラフィック・マネージメント・スクリプト３００の一例である。上述のように、スクリプト３００は、スクリプト３００に関連付けられているドメイン名がクエリーされるたびに従来のＤＮＳ解決サーバ１３０または従来のトラフィック・ルール・スクリプト・サーバ１５０によって実行されることが可能である。
【００３６】
また、上述のように、スクリプト３００は、トラフィック・マネージメント要件の下記の例に関するトラフィック・マネージメント・ルールを実装する。「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に、３つのサーバが関連付けられており、２つのサーバは、米国の東海岸に配置されており（１９２．０．２．１というＩＰアドレスを有する東海岸の第１サーバ、および１９２．０．２．２というＩＰアドレスを有する東海岸の第２サーバ）、１つのサーバは、西海岸に配置されている（２０３．０．１１３．１というＩＰアドレスを有する西海岸のサーバ）。さらに、「ｅｘａｍｐｌｅ．ｃｏｍ」の登録者（たとえば、「ｅｘａｍｐｌｅ．ｃｏｍ」に関するドメイン名所有者２５５）が、自分のウェブサイトへのトラフィックを管理し、それによって下記のことを行いたいと望んでいる。
１）ミシシッピー川の東に位置しているユーザは、東海岸のサーバのうちの１つへ導かれる（「Ｓｔａｒｔ：」というラベルのところのコードを参照されたい）。
２）東海岸のサーバどうしは、東海岸の第１サーバが東部のトラフィックの８０パーセントを受信して、東海岸の第２サーバが残りの２０パーセントを受信するようにロード・バランスされる（「Ｌｏａｄ  Ｂａｌａｎｃｅ：」というラベルのところのコードを参照されたい）。
３）ミシシッピー川の西に位置しているユーザは、西海岸のサーバへ導かれる（「Ｓｔａｒｔ：」というラベルのところのＥＬＳＥのところのコードを参照されたい）。
４）３つのサーバのいずれかがダウンした場合には、ダウンしなかったならばそのサーバへ向かうことになっていたトラフィックは、アップしている別のサーバへ導かれる（「Ｆａｉｌ＿Ｏｖｅｒ＿１：」、「Ｆａｉｌ＿Ｏｖｅｒ＿２：」、および「Ｆａｉｌ＿Ｏｖｅｒ＿２１２：」というラベルのところのコードを参照されたい）。
５）３つのサーバのすべてがダウンした場合には、トラフィックは、東海岸の第２サーバへ導かれることになる。
【００３７】
図３Ｂは、図３Ａのスクリプト３００に関連している、本発明の原理と整合する、トラフィック・マネージメント・テーブルのセットの一例である。さまざまな実施形態においては、図３Ｂのトラフィック・マネージメント・テーブルは、図２において示されている（１つまたは複数の）トラフィック・マネージメント・テーブル２４５に対応することができる。
【００３８】
示されているように、図３Ｂは、「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に関するトラフィック・マネージメント・テーブルの４つの例、すなわち、ＧＥＯルール・テーブル３１０、ロード・バランス・ルール・テーブル３２０、ならびにフェイル・オーバー・ルール・テーブル３３０および３４０の２つの例を提供しており、ここでは、フェイル・オーバー・ルール・テーブル３４０は、フェイル・オーバー・ルール・テーブル３３０と同じであるが、最終的なＩＰアドレスとともにさらなる情報（この例においては、デジタル署名の情報）を提供するさらなる列３５５を有している。
【００３９】
図３Ｂのルール・テーブルは、図３Ａのトラフィック・マネージメント・スクリプト３００をルックアップ・テーブルとして表している。たとえば、図３Ｂに示されている実施形態においては、ＧＥＯルール・テーブル３１０は、図３Ａにおいて「ＳＴＡＲＴ」とラベル付けされているスクリプト・コードのセクションに対応している。
【００４０】
図２および図３Ｂを参照した使用例においては、ドメイン名１３５として「ｅｘａｍｐｌｅ．ｃｏｍ」を、およびリソース・レコード・タイプとして「Ａ」を指定しているＤＮＳクエリー１２５を受信すると、ＤＮＳ解決サーバは、ドメイン名１３５「ｅｘａｍｐｌｅ．ｃｏｍ」およびリソース・レコード・タイプ「Ａ」の最初のテーブル・ルックアップまたは検索を実行すること、ならびにトラフィック・マネージメント・インジケータ２４０を発見することが可能であり、トラフィック・マネージメント・インジケータ２４０は、（単一の回答（たとえば、単一のＩＰアドレス）を有する、および／またはトラフィック・マネージメント機能を有さないドメイン名のケースのような回答を発見することとは対照的に、）さらなる（１つもしくは複数の）トラフィックマネージメントルール・ルックアップまたは（１つもしくは複数の）検索が必要とされるということを示す。
【００４１】
トラフィック・マネージメント・インジケータ２４０によってトリガーされると、ＤＮＳ解決サーバ２３０は次に、第１および第２の列におけるドメイン名「ｅｘａｍｐｌｅ．ｃｏｍ」およびリソース・レコード・タイプ「Ａ」によってインデックス付けされているテーブルを見つけ出し、図３Ｂに示されている例においては、ＤＮＳ解決サーバは、ＧＥＯルール・テーブル３１０を見つけ出し、ＧＥＯルール・テーブル３１０は、第１の列３１１の行３１５および３１６の両方における「ｅｘａｍｐｌｅ．ｃｏｍ」と、第２の列３１７におけるリソース・レコード・タイプ「Ａ」と、ルール・タイプの列３１３におけるルール・タイプ「ＧＥＯ」とを含む。列３１３における「ＧＥＯ」のルール・タイプによってトリガーされると、ＤＮＳ解決サーバ２３０は次いで、要求を行っているクライアント・コンピュータ１２０が東（列３１２、行３１５）に配置されているか、または西（列３１２、行３１６）に配置されているかを特定する。さまざまな実施形態においては、ＤＮＳ解決サーバ２３０は、要求を行っているクライアント・コンピュータ１２０のＩＰアドレスをＤＮＳクエリー１２５から抽出すること、および地理ルックアップ・テーブルを介して、ＩＰアドレスを与えられると地理的場所を返すウェブ・サービスを介して、または当技術分野において一般に知られているその他の何らかの手段を介して、そのＩＰアドレスをその地理的場所と一致させることによって、この特定を行うことができる。
【００４２】
要求を行っているクライアント・コンピュータ１２０が東に配置されている場合には、ＤＮＳ解決サーバ２３０は、（列３１２、行３１５が「東」を含んでいるため、）行３１５との一致または行３１５のルックアップを行って、「回答または次のルール・タイプ」の列３１４の行３１５において回答を見つけ出すことを試みる。その一方で、要求を行っているクライアント・コンピュータ１２０が西に配置されている場合には、ＤＮＳ解決サーバ２３０は、（列３１２、行３１６が「西」を含んでいるため、）行３１６との一致または行３１６のルックアップを行って、「回答または次のルール・タイプ」の列３１４の行３１６において回答を見つけ出すことを試みる。
【００４３】
図３Ａに示されているスクリプト３００を表すこの例においては、列３１４の行３１５も行３１６も回答を含んでいない。なぜなら、ＧＥＯに加えて、解決するためのその他のトラフィック・マネージメント・ルールが存在するためである。ここでは、要求を行っているクライアント・コンピュータ１２０が東に配置されている場合には、図３Ａにおける「ＬＯＡＤ＿ＢＡＬＡＮＣＥ」とラベル付けされているスクリプト・コードのセクションに対応するロード・バランシング・ルールが実行されなければならない。または、要求を行っているクライアント・コンピュータ１２０が西に配置されている場合には、図３Ａにおける「ＦＡＩＬ＿ＯＶＥＲ＿２１２」とラベル付けされているスクリプト・コードのセクションに対応するフェイル・オーバー・ルールが実行されなければならない。
【００４４】
この例に関して、要求を行っているクライアント・コンピュータ１２０が東に配置されていると想定すると、ＤＮＳ解決サーバ２３０は次に、（ＧＥＯルール・テーブル３１０の列３１４、行３１５からの）ルール・タイプ＝「ＬｏａｄＢａｌ」に一致する、ならびに（ＤＮＳクエリー１２５からの）ドメイン名＝「ｅｘａｍｐｌｅ．ｃｏｍ」およびリソース・レコード・タイプ＝「Ａ」に一致するルール・テーブル行をルックアップまたは検索し、それは、列３２１、３２２、および３２３にそれぞれ基づいて、ロード・バランス・ルール・テーブル３２０へつながる。これは、図３Ｂにおける矢印３１９によって表されている。
【００４５】
列３２１における「ＬｏａｄＢａｌ」のルール・タイプによってトリガーされると、ＤＮＳ解決サーバ２３０は次いで、「クエリー％」（列３２５）に対して適用するための１〜１００の乱数を生成する。その数は、１〜８０である場合には、８０％の行（列３２５、行３２７）に一致し、８１〜１００である場合には、２０％の行（列３２５、行３２８）に一致する。
【００４６】
ロード・バランス・テーブル行３２７が一致またはルックアップされた場合には、ＤＮＳ解決サーバ２３０は、行３２７の「回答または次のルール・タイプ」の列３２６において回答を見つけ出すことを試みる。その一方で、ロード・バランス・テーブル行３２８が一致またはルックアップされた場合には、ＤＮＳ解決サーバ２３０は、行３２８の「回答または次のルール・タイプ」の列３２６において回答を見つけ出すことを試みる。
【００４７】
図３Ａに示されているスクリプト３００を表すこの例においては、列３２６の行３２７も行３２８も回答を含んでいない。なぜなら、ロード・バランシングに加えて、解決するためのその他のトラフィック・マネージメント・ルールが存在するためである。ここでは、クエリーが８０％のカテゴリー内にランダムに置かれた場合には、図３Ａにおける「ＦＡＩＬ＿ＯＶＥＲ＿１」とラベル付けされているスクリプト・コードのセクションに対応する、東部サーバ１に関するフェイル・オーバー・ルールが実行されなければならない。または、クエリーがその他の２０％のカテゴリー内にランダムに置かれた場合には、図３Ａにおける「ＦＡＩＬ＿ＯＶＥＲ＿２」とラベル付けされているスクリプト・コードのセクションに対応する、東部サーバ２に関するフェイル・オーバー・ルールが実行されなければならない。
【００４８】
この例に関して、乱数が８０未満であって、それによってロード・バランス・ルール・テーブル３２０の行３２７との検索一致が生じたと想定すると、ＤＮＳ解決サーバ２３０は次に、（ロード・バランス・ルール・テーブル３２０の列３２６、行３２７からの）ルール・タイプ＝「ＦａｉｌＯｖｅｒ  １」に一致する、ならびに（ＤＮＳクエリー１２５からの）ドメイン名＝「ｅｘａｍｐｌｅ．ｃｏｍ」およびリソース・レコード・タイプ＝「Ａ」に一致するルール・テーブル行を検索し、それは、列３３１、３３２、および３４１にそれぞれ一致することに基づいて、フェイル・オーバー・ルール・テーブル３３０へつながる。これは、図３Ｂにおける矢印３２９によって表されている。
【００４９】
列３３１、行３３５および３３６における「ＦａｉｌＯｖｅｒ  １」のルール・タイプによってトリガーされると、ＤＮＳ解決サーバ２３０は次いで、東部第１サーバのステータスを確かめる。東部第１サーバが「アップ」している場合には、ルックアップは、「東部第１アップ」の行（列３３３、行３３５）に一致し、または東部第１サーバが「ダウン」している場合には、ルックアップは、「東部第１ダウン」の行（列３３３、行３３６）に一致する。
【００５０】
この例に関して、東部第１サーバが「アップ」しており、それによってフェイル・オーバー・ルール・テーブル３２０の行３３５とのルックアップ・マッチまたは検索一致が生じていると想定すると、次いでＤＮＳ解決サーバ２３０は、「回答または次のルール・タイプ」の列３３４を検討して、次に何を行うべきかを見つけ出す。このケースにおいては、列３３４の一致している行３３５は、東海岸の第１サーバのＩＰアドレスである「１９２．０．２．１」という回答を含んでおり、これは、実際にＩＰアドレスであり、別のルールのインジケータまたはポインタではないため、ＤＮＳ解決サーバ２３０は、そのＩＰアドレス「１９２．０．２．１」をＤＮＳクエリー１２５への回答１６０として返す。
【００５１】
ＩＰアドレス「１９２．０．２．１」をＤＮＳクエリー１２５への回答１６０として返すことで終わる今しがた提示した例と同様に、ＤＮＳ解決サーバ２３０は、テーブル３１０、３２０、および３３０を通るその他の経路を同様に進んで、図３Ａにおいて示されている変数ならびにトラフィック・マネージメント・ルールおよび基準に従って、その他の２つの可能なＩＰアドレス（列３３４、行３３７、３４２における「１９２．０．２．２」、または列３３４、行３３９における「２０３．０．１１３．１」）のいずれかに到達することができる。
【００５２】
上述のように、これらの例は、本発明と整合するさまざまな実施形態を非常に明確に例示するために簡略化されている。実施態様および実施形態をＤＮＳのコンテキストにおいて機能させる際には、トラフィック・マネージメント・テーブル、および、ＤＮＳクエリー１２５に応答してＤＮＳ解決サーバ２３０によって返される情報は、完全にＤＮＳに準拠している。たとえば、「ＩＰアドレスまたは次のルール・タイプ」の列３３４は、図３Ｂの例において示されているＩＰアドレスの代わりに、そのＩＰアドレスに対応するＤＮＳリソース・レコード（たとえば、Ａリソース・レコードもしくはＡＡＡＡリソース・レコード）またはそれへのポインタを含むことができ、それによって、ＤＮＳ解決サーバ２３０は、標準的なＤＮＳ要件および手順ごとにそのリソース・レコードを返す。
【００５３】
いくつかの実施形態においては、ＩＰアドレスに伴うＤＮＳＳＥＣ情報など、ＤＮＳクエリー１２５に応答してＩＰアドレス以外のさらなる情報を返すために、さらなるテーブル、またはさらなる情報を含むテーブルが使用されることが可能である。そのような一実施形態においては、フェイル・オーバー・ルール・テーブル３３０の代わりに、フェイル・オーバー・ルール・テーブル３５０などのテーブルが使用されることが可能である。示されているように、フェイル・オーバー・ルール・テーブル３５０は、列３５４におけるそれぞれの回答に対応するＤＮＳＳＥＣデジタル署名を列３５５内に含み、ＤＮＳ解決サーバ２３０は、列３５５におけるさらなる情報をルックアップして、列３５４における回答とともに要求元へ返すことができる。簡潔および明確にするために、フェイル・オーバー・ルール・テーブル３５０の「Ｒレコード・タイプ」の列および「ＦａｉｌＯｖｅｒ  ２１３」の行は、図３Ｂから省略されているということに留意されたい。
【００５４】
図３Ｂにおけるルックアップ・テーブルのコンポーネントおよび実施態様の詳細は、説明を簡潔および明確にするために提示されている簡略化された例であるということを当業者なら認識するであろう。その他のコンポーネント、実施態様の詳細、および変形形態が使用されることも可能である。たとえば、列３３４または３５４の回答は、フェイル・オーバー・ルール・テーブル３３０および３５０に結合される代わりに、別個のテーブル内に含まれることが可能であり、それによって、所与のドメイン名１３５およびドメイン名所有者２５５のトラフィック・マネージメント要件が変わった際にルール・テーブル３１０、３２０、３３０、および３４０の生成、修正、および再構成をより容易に行うことができる。
【００５５】
図４は、本発明の原理と整合する、トラフィック・マネージメント・テーブルのセットの別の例である。さまざまな実施形態においては、図４のトラフィック・マネージメント・テーブルは、図２において示されている（１つまたは複数の）トラフィック・マネージメント・テーブル２４５に対応することができる。
【００５６】
図４の例示的な実施形態においては、「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に関するトラフィック・マネージメント・テーブルの３つの例、すなわち、ロード・バランス・ルール・テーブル４１０、リソース・レコード・テーブル４２０、およびリソース・レコード署名テーブル４３０がある。
【００５７】
図２および図４を参照してこれらのテーブルに関する使用ケースの一例を示すために、「ｅｘａｍｐｌｅ．ｃｏｍ」というドメイン名に関するドメイン名所有者２５５が、２つの別々のデータ・センター、すなわち、ＩＰアドレス「１９２．０．２．１」および「１９２．０．２．２」を有する２つのサーバを含む東海岸のデータ・センター、ならびに、ＩＰアドレス「２０３．０．１１３．２」および「２０３．０．１１３．３」を有する２つのサーバを含む西海岸のデータ・センターを有しているケースを考えていただきたい。さらに、ドメイン名所有者２５５は、自分のＤＮＳ要求のうちの６０％が東海岸のデータ・センターによって取り扱われて４０％が自分の西海岸のデータ・センターによって取り扱われるように、自分のウェブ・サイト・トラフィックを２つのデータ・センターにわたってロード・バランスしたいと望んでいる。
【００５８】
示されている実施形態においては、このロード・バランシング要件に関するトラフィック・マネージメント・ルールおよび関連付けられているロジックが、ロード・バランス・ルール・テーブル４１０内の行として表されている。ロード・バランス・ルール・テーブル４１０は、ドメイン名の列４１１（このケースにおいては、両方の行にドメイン名「ｅｘａｍｐｌｅ．ｃｏｍ」のみを含んでいる）と、データ・センターのうちのそれぞれに関するラベル（行４１６における東、および行４１７における西）を含むサイトの列４１２と、トラフィック・マネージメント・ルールのラベル（この例においては、「ロード・バランス」ルールのみが示されている）を含むルール・タイプの列４１３と、それぞれのデータ・センターへ送信するためのＤＮＳクエリー１２５のパーセンテージを指定するクエリー％の列４１４と、トラフィック・マネージメント・ルール・テーブル内の別のテーブル／行をルックアップするために使用される検索キーまたはリンクを指定するバリアントＩＤの列４１５とを含む。
【００５９】
稼働中に、ドメイン名として「ｅｘａｍｐｌｅ．ｃｏｍ」を、およびリソース・レコード・タイプ１３５として「Ａ」を指定しているＤＮＳクエリー１２５を受信すると、ＤＮＳ解決サーバは、ドメイン名およびリソース・レコード・タイプ１３５「ｅｘａｍｐｌｅ．ｃｏｍ」および「Ａ」の最初のルックアップを実行して、第１の列４１１におけるドメイン名「ｅｘａｍｐｌｅ．ｃｏｍ」および第２の列４１８におけるリソース・レコード・タイプ「Ａ」によってインデックス付けされているテーブルまたは行を検索して見つけ出すことができ、図４に示されている例においては、ＤＮＳ解決サーバは、ロード・バランス・ルール・テーブル４１０を見つけ出し、ロード・バランス・ルール・テーブル４１０は、第１の列４１１および第２の列４１８の行４１６および４１７の両方における「ｅｘａｍｐｌｅ．ｃｏｍ」および「Ａ」と、ルール・タイプの列４１３におけるルール・タイプ「ロード・バランス」とを含む。
【００６０】
列４１３における「ロード・バランス」のルール・タイプによってトリガーされると、ＤＮＳ解決サーバ２３０は次いで、「クエリー％」の列４１４に対して適用するための１〜１００の乱数を生成する。その乱数が１〜６０である場合には、ルックアップは、６０％の行（列４１４、行４１６）と一致し、その乱数が６１〜１００である場合には、ルックアップは、４０％の行（列４１４、行４１７）と一致する。
【００６１】
ロード・バランス・ルール・テーブル行４１６が一致またはルックアップされた場合には、ＤＮＳ解決サーバ２３０は、バリアントＩＤ＝０に一致するテーブル行（列４１５、行４１６）をルックアップすることを試みる。その一方で、ロード・バランス・ルール・テーブル行４１７が一致またはルックアップされた場合には、ＤＮＳ解決サーバ２３０は、バリアントＩＤ＝２１２に一致するテーブル行（列４１５、行４１７）を見つけ出すことまたはルックアップすることを試みる。
【００６２】
この例に関して、乱数が６０を超えており、それによってロード・バランス・ルール・テーブル４１０の行４１７とのルックアップ・マッチまたは検索一致が生じたと想定すると、ＤＮＳ解決サーバ２３０は次に、（ロード・バランス・ルール・テーブル４１０の行４１７からの）バリアントＩＤ＝「２１２」に一致する、ならびに（ＤＮＳクエリー１２５からの、およびロード・バランス・ルール・テーブル４１０の列４１１および４１８、行４１７からの）ドメイン名＝「ｅｘａｍｐｌｅ．ｃｏｍ」およびリソース・レコード・タイプ「Ａ」に一致するルール・テーブル行をルックアップし、それは、列４２１、４２２、および４２９の行４２７および４２８に一致することに基づいて、リソース・レコード・テーブル４２０の行４２７および４２８へつながる。これは、図４における矢印４１９によって表されている。
【００６３】
リソース・レコード・テーブル４２０は、クエリーされているＤＮＳゾーンに関するそれぞれの「バリアントＩＤ」に関連付けられている１つまたは複数の回答を定義する。これは、（さらなる検索処理をトリガーすることになる別のルール・テーブルとは対照的に）リソース・レコード・テーブルであるため、ＤＮＳ解決サーバ２３０は、２つの一致している行４２７および４２８の列４２３において列挙されている「２０３．０．１１３．２」および「２０３．０．１１３．３」という２つのＩＰアドレスをＩＰアドレス１６０として返す。ＤＮＳの技術分野において知られているように、ＤＮＳクエリー１２５は、複数のＩＰアドレスを示すアドレス・リソース・レコードを伴って回答されることが可能であり、どのＩＰアドレスを使用するかをクライアント・コンピュータ１２０上のブラウザが選択するためのさまざまなメカニズムがある。
【００６４】
ＤＮＳＳＥＣを任意選択で実施するいくつかの実施形態においては、ＤＮＳ解決サーバ２３０は、ＲＲＳＩＧレコードをルックアップして、回答とともに返すこともできる。図４の例において示されているように、ロード・バランス・ルール・テーブル４１０およびリソース・レコード・テーブル４２０において定義されている、ドメイン名からＩＰアドレスへのルックアップのうちのそれぞれは、ＤＮＳＳＥＣ標準に従って事前にデジタル署名されて、対応するＲＲＳＩＧレコードが作成され、それらのＲＲＳＩＧレコードは、別個のＲＲＳＩＧテーブル４３０において保持される。上述の例を続けると、ＤＮＳ解決サーバ２３０は、列４３１におけるバリアントＩＤ「２１２」の一致に基づいてＲＲＳＩＧテーブル４３０の行４３５をルックアップし、行４３５の列４３２および４３３からの適切なＲＲＳＩＧレコードおよび／またはＩＰアドレス・レコード・セットのダイジェストを返すことになる。前述したように、ＤＮＳＳＥＣデジタル署名を事前計算してルール・テーブル内に格納することによって、プライベートＤＮＳＳＥＣキーをＤＮＳ解決サーバ２３０へ配布する必要がなくなる。トラフィック・マネージメント・ロジックが適用されるドメイン名を解決する際に、ＤＮＳ解決サーバ２３０は、上述のテーブル内の適切な行を順次ルックアップすることによって、適切なＩＰアドレスを検索して見つけ出すこと、ならびに有効なＤＮＳＳＥＣ署名および信頼チェーンを確認することが可能である。
【００６５】
図５は、本発明の実施形態と整合する、ＤＮＳトラフィック・マネージメント・ルールのハイ・パフォーマンスの実施態様のための例示的なプロセス５００のフローチャートである。さまざまな実施形態においては、プロセス５００のいくつかまたはすべては、（１つもしくは複数のプロセッサまたは１つもしくは複数のコンピューティング・サブシステムを含むことができる）汎用コンピューティング・システム上で実行するソフトウェアによって、ハードウェアのみのシステムによって、またはそれら２つのハイブリッドであるシステムによって実行されることが可能である。さまざまな実施形態においては、プロセス５００は、図２のＤＮＳ解決サーバ２３０内に含まれているプロセッサまたは目的に合うように設計されたハードウェアによって実施されることが可能である。
【００６６】
図５に示されている実施形態においては、プロセス５００は、要求元からドメイン名およびリソース・レコード・タイプを受信すること（ステージ５１０）から開始する。さまざまな実施形態においては、ドメイン名およびリソース・レコード・タイプは、図２に関連して説明した、クライアント・コンピュータ１２０のブラウザからのＤＮＳクエリー１２５などのＤＮＳクエリーの一部であることが可能である。
【００６７】
ステージ５２０において、プロセス５００は、ドメイン名およびリソース・レコード・タイプを使用してインデックス付けされているテーブルにおいてトラフィック・マネージメント・ルールをルックアップまたは検索する。言い換えれば、この実施形態は、ドメイン名およびリソース・レコード・タイプを、トラフィック・マネージメント・ルールを見つけ出すための複合検索インデックスとして使用する。さまざまな実施形態においては、そのテーブル内に、または複数のテーブル内に、複数のトラフィック・マネージメント・ルールが存在することが可能である。さまざまな実施形態においては、そのテーブルは、図２に関連して説明したトラフィック・マネージメント・テーブル２４５、および／または図３Ｂに関連して説明したルール・テーブル３１０、３２０、３３０、もしくは３５０、および／または図４に関連して説明したルール・テーブル４１０、４２０、もしくは４３０であることが可能である。
【００６８】
プロセス５００は次に、トラフィック・マネージメント・ルールによって指定されている変数に関する値を特定する（ステージ５３０）。いくつかの実施形態においては、この変数は、たとえば、図３ＢのＧＥＯルール・テーブル３１０に関連して上述したのと同様に、要求元の地理的場所またはＩＰアドレスであることが可能である。いくつかの実施形態においては、この変数は、たとえば、図３Ｂのロード・バランス・ルール・テーブル３２０に関連して上述したのと同様に、または図４のロード・バランス・ルール・テーブル４１０に関連して上述したのと同様に、指定されている重み付けされたロード・バランシング基準（たとえば、パーセンテージ）に従って、ドメイン名に関連付けられている特定のサーバへクエリーを導くために使用される乱数またはその他のロード・バランシング変数であることが可能である。いくつかの実施形態においては、この変数は、たとえば、図３Ｂのフェイル・オーバー・ルール・テーブル３３０および３５０に関連して上述したのと同様に、ドメイン名に関連付けられているサーバの稼働（たとえば、「アップ」）または非稼働（たとえば、「ダウン」）ステータスであることが可能である。さらに他の実施形態においては、この変数は、時刻、ドメイン名に関連付けられている特定のサーバへのトランザクションに関連付けられている待ち時間、ドメイン名に関連付けられている特定のＩＰアドレスのサービスを使用する金銭的コスト、またはドメイン名に関連付けられているサーバの現在のローディングもしくは現在の利用可能なキャパシティー、またはＤＮＳクエリーに応答して返すための回答の複数の選択肢の中からトラフィック・マネージメント基準に従って選択を行うことに影響を与えるその他の任意の因子であることが可能である。さらに他の実施形態においては、トラフィック・マネージメント・ルールを満たすために変数値を特定する必要性をなくすことができ、このステージはスキップされることが可能である。
【００６９】
いくつかの実施形態においては、プロセス５００は、ドメイン名に関連付けられているサーバまたはその他のリソースの現在のまたは最近のステータスを反映する情報を保持しているデータ・ストアまたはデータベース（そこでは、それらのサーバまたはその他のリソースのＩＰアドレスが、トラフィック・マネージメント・ルールに関連付けられて（１つまたは複数の）トラフィック・マネージメント・テーブル（たとえば２４５）内に格納されている）にアクセスすることによって、トラフィック・マネージメント・ルールによって指定されている変数に関する値を特定することができる。いくつかの実施形態においては、そのデータ・ストアまたはデータベースは、ドメイン名に関連付けられているサーバまたはその他のリソースによって定期的に更新されることが可能である。その他の実施形態においては、ＤＮＳ解決サーバまたは関連付けられている補助サーバが、ドメイン名に関連付けられているサーバまたはその他のリソースから変数情報を定期的にアクティブに入手することができる。
【００７０】
ステージ５４０において、プロセス５００は、ドメイン名、リソース・レコード・タイプ、および、ステージ５３０において特定された変数に関する値に対応する回答をルックアップまたは検索する。さまざまな実施形態においては、ステージ５４０は、一致しているドメイン名、リソース・レコード・タイプ、および変数に関する値を含む（１つまたは複数の）トラフィック・マネージメント・ルール・テーブル（たとえば、図２の（１つまたは複数の）トラフィック・マネージメント・テーブル２４５）内の１つまたは複数の行（その１つまたは複数の行は、回答またはその回答への参照を含んでいる列を含む）を識別するためのキーまたはインデックスとして、ドメイン名、リソース・レコード・タイプ、および変数値を使用することによって、実施されることが可能である。さまざまな実施形態は、図４のロード・バランス・ルール・テーブル４１０およびリソース・レコード・テーブル４２０に関連して上述したのと同様の様式で、または図３Ｂのフェイル・オーバー・ルール・テーブル３３０および３５０に関連して上述したのと同様の様式で、このステージを実施することができる。
【００７１】
ステージ５５０において、プロセス５００は、ステージ５１０においてドメイン名およびリソース・レコード・タイプが受信された元である要求元、たとえば、図２のＤＮＳクエリー１２５を送信したクライアント・コンピュータ１２０などに回答を提供する。さまざまな実施形態においては、上述のように、回答は、Ａリソース・レコードまたはＡＡＡＡリソース・レコードなどのＤＮＳリソース・レコードの形態であること、またはそうしたＤＮＳリソース・レコードとともに含まれることが可能である。
【００７２】
例示的なプロセス５００は、説明を簡潔および明確にするために提示されており、本発明の原理から逸脱することなく、ステージがプロセス５００に追加されること、プロセス５００から削除されること、プロセス５００内で並べ替えられること、または修正されることが可能であるということを当業者なら認識するであろう。たとえば、可能なトラフィック・マネージメント結果のうちのすべてをカバーするために行が存在するように、ＤＮＳトラフィック・ルール、要件、コード、またはスクリプト言語をテーブル内の行として表すまたは変換するためのステージが、ステージ５１０の前に追加されることが可能である。別の例に関しては、ステージ５４０は、（回答がテーブル行内に含まれている場合には）回答をルックアップするように、または後続の（１つもしくは複数の）トラフィック・マネージメント・ルールをルックアップし、次いで、回答が見つかるまでステージ５３０および５４０を反復して、後続の（１つもしくは複数の）トラフィック・マネージメント・ルールを評価するように修正されることが可能である。さらに別の例に関しては、ステージ５４０および５５０は、たとえば、図４のロード・バランス・ルール・テーブル４１０およびリソース・レコード・テーブル４２０に関連して上述したのと同様の様式で、トラフィック・マネージメント・ルールの出力である複数のＩＰアドレスをルックアップして提供するように修正されることが可能である。さらに別の例に関しては、ステージ５４０および５５０は、図３Ｂのフェイル・オーバー・ルール・テーブル３５０および／または図４のＲＲＳＩＧテーブル４３０に関連して上述したのと同様の様式で、ドメイン名に対応する回答に加えて、たとえば、その回答に関するＤＮＳＳＥＣデジタル署名などのその他の情報をルックアップして提供するように修正されることが可能である。その他の変形形態も可能である。
【００７３】
図６は、本発明と整合する実施形態を実施するために使用されることが可能である例示的なコンピューティング・システムまたはデータ処理システム６００のブロック図である。その他のコンポーネントおよび／または構成が使用されることも可能である。いくつかの実施形態においては、コンピューティング・システム６００は、ＤＮＳ解決サーバ２３０および／またはドメイン名所有者インターフェース２５０など、図２のさまざまなコンポーネントを部分的にまたは全体的に実施するために使用されることが可能である。いくつかの実施形態においては、コンピューティング・システム６００は、とりわけ、図５のプロセス５００を部分的にまたは全体的に実施するために使用されることが可能である。
【００７４】
コンピューティング・システム６００は、中央処理装置（ＣＰＵ）６０５、メモリ６１０、（１つまたは複数の）入力／出力（Ｉ／Ｏ）デバイス６２５、および不揮発性ストレージ・デバイス６２０など、複数のコンポーネントを含む。システム６００は、さまざまな方法で実装されることが可能である。たとえば、統合されたプラットフォーム（たとえば、サーバ、ワークステーション、パーソナル・コンピュータ、ラップトップ、スマート・フォンなど）としての実施態様は、ＣＰＵ６０５、メモリ６１０、不揮発性ストレージ６２０、およびＩ／Ｏデバイス６２５を含むことができる。そのような構成においては、コンポーネント６０５、６１０、６２０、および６２５は、ローカル・データ・バスを通じて接続して通信することができ、外部Ｉ／Ｏ接続を介して（たとえば、別個のデータベース・システムとして実装されている）データベース６３０にアクセスすることができる。（１つまたは複数の）Ｉ／Ｏコンポーネント６２５は、直接通信リンク（たとえば、ハードワイヤードのもしくはローカルのｗｉｆｉ接続）を通じて、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）などのネットワークを通じて、および／またはその他の適切な接続を通じて、外部デバイスに接続することができる。システム６００は、スタンドアロンであることが可能であり、または、より大きなシステムのサブシステムであることが可能である。
【００７５】
ＣＰＵ６０５は、カリフォルニア州サンタクララのＩｎｔｅｌ（登録商標）  Ｃｏｒｐｏｒａｔｉｏｎによって製造されているＣｏｒｅ（登録商標）  ２ファミリーからのマイクロプロセッサ、またはカリフォルニア州サニーベールのＡＭＤ（登録商標）  Ｃｏｒｐｏｒａｔｉｏｎによって製造されているＡｔｈｌｏｎ（商標）ファミリーからのマイクロプロセッサなど、１つまたは複数の知られているプロセッサまたは処理デバイスであることが可能である。メモリ６１０は、本発明の実施形態に関連した特定のオペレーション、機能、方法、およびプロセスを実行するためにＣＰＵ６０５によって使用される命令および情報を格納するように構成されている１つまたは複数の高速ストレージ・デバイスであることが可能である。ストレージ６２０は、長期の格納用の、ＣＤおよびＤＶＤなどのデバイスを含む、揮発性もしくは不揮発性の、磁気、半導体、テープ、光学、またはその他のタイプのストレージ・デバイスまたはコンピュータ可読メディアであることが可能である。
【００７６】
示されている実施形態においては、メモリ６１０は、ストレージ６２０から、または、ＣＰＵ６０５によって実行されたときに本発明と整合するさまざまなオペレーション、手順、プロセス、または方法を実行するリモート・システム（図示せず）からロードされる１つまたは複数のプログラムまたはサブプログラム６１５を含む。あるいは、ＣＰＵ６０５は、システム６００からリモートに配置されている１つまたは複数のプログラムを実行することができる。たとえば、システム６００は、実行されたときに本発明の実施形態に関連した機能およびプロセスを実行する１つまたは複数のリモート・プログラムにネットワーク６３５を介してアクセスすることができる。
【００７７】
一実施形態においては、メモリ６１０は、ＤＮＳトラフィック・マネージメント・ルールおよび基準を表すテーブル・ルックアップを介してＤＮＳクエリーを処理するための（１つもしくは複数の）プログラム６１５、ならびに／または図５のプロセス５００の少なくとも一部分を実施するプログラム６１５を含むことができる。いくつかの実施形態においては、メモリ６１０は、補助的な機能を本発明に提供するその他の方法およびプロセスを実施するその他のプログラム、アプリケーション、またはデータを含むこともできる。たとえば、メモリ６１０は、本発明に関連したデータ、たとえば、変数ステータス・データ、トラフィック・マネージメント・ルール・データ、ＩＰアドレス・データ、地理的場所データ、時刻データ、サーバ待ち時間データ、サーバ・コスト・データ、サーバ・ステータスおよびロード・データなどに対してアクセス、受信、送信、収集、編成、格納、および／または生成を行うために使用されるプログラムまたはデータを含むことができる。
【００７８】
メモリ６１０は、本発明に関連していないその他のプログラム（図示せず）、および／または、ＣＰＵ６０５によって実行されたときに当技術分野においてよく知られているいくつかの機能を実行するオペレーティング・システム（図示せず）を伴って構成されることも可能である。例として、そのオペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ａｐｐｌｅ（登録商標）  Ｃｏｍｐｕｔｅｒｓのオペレーティング・システム、Ｍｉｃｒｏｓｏｆｔ（登録商標）  ＣＥなどの携帯情報端末のオペレーティング・システム、またはその他のオペレーティング・システムであることが可能である。オペレーティング・システムの選択、およびオペレーティング・システムの使用でさえ、本発明にとっては重要ではない。
【００７９】
（１つまたは複数の）Ｉ／Ｏデバイス６２５は、データがシステム６００によって受信および／または送信されることを可能にする１つまたは複数の入力／出力デバイスを含むことができる。たとえば、Ｉ／Ｏデバイス６２５は、データがユーザから入力されることを可能にする１つまたは複数の入力デバイス、たとえば、キーボード、タッチ・スクリーン、マウスなどを含むことができる。さらに、Ｉ／Ｏデバイス５２５は、データがユーザへ出力または提示されることを可能にする１つまたは複数の出力デバイス、たとえば、ディスプレイ・スクリーン、ＣＲＴモニタ、ＬＣＤモニタ、プラズマ・ディスプレイ、プリンタ、スピーカー・デバイスなどを含むことができる。Ｉ／Ｏデバイス６２５は、コンピューティング・システム６００がその他のマシンおよびデバイスと、たとえばデジタルに、通信することを可能にする１つまたは複数のデジタルおよび／またはアナログ通信入力／出力デバイスを含むこともできる。その他の構成および／または数の入力および／または出力デバイスが、Ｉ／Ｏデバイス６２５内に組み込まれることも可能である。
【００８０】
示されている実施形態においては、システム６００は、ネットワーク６３５（インターネット、プライベート・ネットワーク、仮想プライベート・ネットワーク、またはその他のネットワークなど）に接続されており、そしてネットワーク６３５は、さまざまなシステムおよびコンピューティング・マシン（図示せず）、たとえば、サーバ、パーソナル・コンピュータ、ラップトップ・コンピュータ、クライアント・デバイス（たとえば、クライアント・コンピュータ１２０）などに接続されることが可能である。一般に、システム６００は、外部マシンおよびデバイスからデータを入力すること、ならびにネットワーク６３５を介して外部マシンおよびデバイスにデータを出力することが可能である。
【００８１】
図６に示されている例示的な実施形態においては、データベース６３０は、システム６００の外部にあるスタンドアロンのデータベースである。その他の実施形態においては、データベース６３０は、システム６００によってホストされることが可能である。さまざまな実施形態においては、データベース６３０は、本発明と整合するシステムおよび方法を実施するために使用されるデータを管理および格納することができる。たとえば、データベース６３０は、トラフィック・マネージメント・テーブル２４５、ルール・テーブル３１０、３２０、３３０、もしくは３５０、および／もしくはテーブル４１０、４２０、および／もしくは４３０などを実施するデータ構造、ならびに／または、トラフィック・マネージメント・ルールによって指定されている基準に照らして評価されるステータス変数を管理および格納することができる。
【００８２】
データベース６３０は、情報を格納してシステム６００を通じてアクセスおよび／または管理される１つまたは複数のデータベースを含むことができる。例として、データベース６３０は、Ｏｒａｃｌｅ（登録商標）データベース、Ｓｙｂａｓｅ（登録商標）データベース、またはその他のリレーショナル・データベースであることが可能である。しかしながら、本発明と整合するシステムおよび方法は、別々のデータ構造もしくはデータベースに、または正式なデータベースもしくはデータ構造の使用にさえ、限定されない。
【００８３】
図６におけるシステムのコンポーネントおよび実施態様の詳細は、説明を簡潔および明確にするために提示されている例であるということを当業者なら認識するであろう。その他のコンポーネントおよび実施態様の詳細が使用されることも可能である。
【００８４】
本開示における実施形態および実施態様のうちの多くは、ＤＮＳクエリーのコンテキストにおいて説明されているが、本発明の範囲は、必ずしもＤＮＳクエリーに限定されるものではなく、複数の可能な回答のうちの１つを特定するための条件付きルールなどを含むその他のタイプのクエリーを包含することができる。
【００８５】
本発明のその他の実施形態は、本明細書を考察し、本明細書に開示されている本発明を実践すれば、当業者にとって明らかになるであろう。本明細書および例は、例示的なものにすぎないとみなされ、本発明の真の範囲および趣旨は、添付の特許請求の範囲によって示されるということが意図されている。
【図１】
2014183586.tif 000003
【図２】
2014183586.tif 000004
【図３Ａ】
2014183586.tif 000005
【図３Ｂ】
2014183586.tif 000006
【図４】
2014183586.tif 000007
【図５】
2014183586.tif 000008
【図６】
2014183586.tif 000009
【外国語明細書】
2014183586000001.pdf