特許 6861219 インテリジェントドメインネームシステム転送のための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6861219

(24)【登録日】2021年3月31日

(45)【発行日】2021年4月21日

(54)【発明の名称】インテリジェントドメインネームシステム転送のための方法および装置

(51)【国際特許分類】

   H04L 12/70 20130101AFI20210412BHJP

【ＦＩ】

   H04L12/70 B

【請求項の数】12

【全頁数】22

(21)【出願番号】特願2018-547416(P2018-547416)

(86)(22)【出願日】2017年3月9日

(65)【公表番号】特表2019-507994(P2019-507994A)

(43)【公表日】2019年3月22日

(86)【国際出願番号】US2017021514

(87)【国際公開番号】WO2017156231

(87)【国際公開日】20170914

【審査請求日】2020年3月9日

(31)【優先権主張番号】62/305,602

(32)【優先日】2016年3月9日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】518024699

【氏名又は名称】ダイナミック・ネットワーク・サービシーズ・インコーポレイテッド

【氏名又は名称原語表記】ＤＹＮＡＭＩＣ ＮＥＴＷＯＲＫ ＳＥＲＶＩＣＥＳ， ＩＮＣ．

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】リナリ，エイミー

(72)【発明者】

【氏名】リックハイト，エリック

(72)【発明者】

【氏名】ギブソン，リチャード

(72)【発明者】

【氏名】アブリー，ジョセフ

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 米国特許出願公開第２０１３／０１７３７６９（ＵＳ，Ａ１）

【文献】 国際公開第２０１３／０３５３１１（ＷＯ，Ａ１）

【文献】 特表２０１３−５０２１９０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１４／０３４４９２５（ＵＳ，Ａ１）

【文献】 国際公開第２０１４／１８６１８９（ＷＯ，Ａ１）

【文献】 中国特許出願公開第１０５２２９９９６（ＣＮ，Ａ）

【文献】 米国特許出願公開第２０１２／００９６１６６（ＵＳ，Ａ１）

【文献】 中国特許出願公開第１０１４８８９６５（ＣＮ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５

(57)【特許請求の範囲】

【請求項1】

ドメインネームシステム（ＤＮＳ）クエリに応答する方法であって、前記方法は、
プロキシサーバが、クライアントから前記ＤＮＳクエリを受信するステップと、
前記プロキシサーバが、修正されたＤＮＳクエリを生成するステップとを含み、前記修正されたＤＮＳクエリを生成することは、メタデータの要求を含めるために前記ＤＮＳクエリを修正することを含み、
前記プロキシサーバーが、前記修正されたＤＮＳクエリを権威ＤＮＳサーバに送信するステップと、
前記プロキシサーバが、前記権威ＤＮＳサーバから前記修正されたＤＮＳクエリへの応答を受信するステップとを含み、前記応答は前記メタデータを含み、前記方法はさらに、
前記プロキシサーバが、前記メタデータに少なくとも部分的に基づいて、前記修正されたＤＮＳクエリへの応答を生成するステップと、
前記プロキシサーバーが、前記ＤＮＳクエリへの前記応答を前記クライアントに送信するステップとを含み、
前記ＤＮＳクエリへの応答は、前記メタデータに含まれるプログラムと、複数のＩＰアドレスとを含む、方法。

【請求項2】

前記ＤＮＳクエリを修正するステップは、前記ＤＮＳクエリにおいてＤＮＳセキュリティ（ＤＮＳＳＥＣ）ＯＫ（ＤＯ）フラグを設定するステップを含む、請求項１に記載の方法。

【請求項3】

前記メタデータは、要求リソース署名（ＲＲＳＩＧ）レコードを含む、請求項１または２に記載の方法。

【請求項4】

前記ＤＮＳクエリへの前記応答を修正するステップは、前記メタデータに含まれるプログラムを実行するステップを含む、請求項１〜３のいずれかに記載の方法。

【請求項5】

前記メタデータに含まれるプログラムを実行するステップは、
前記複数のＩＰアドレスを並べ替えるステップと、
前記複数のＩＰアドレスをフィルタリングするステップと、
前記複数のＩＰアドレスからＩＰアドレスを選択するステップとを含む、請求項４に記載の方法。

【請求項6】

前記ＤＮＳクエリへの前記応答を生成するステップは、前記修正されたＤＮＳクエリへの前記応答から前記メタデータを除去するステップを含む、請求項１〜５のいずれかに記載の方法。

【請求項7】

前記ＤＮＳクエリへの前記応答を修正するステップは、前記応答を前記クライアントに送信するために一連の規則を適用するステップを含む、請求項１〜６のいずれかに記載の方法。

【請求項8】

複数のドメインネームシステム（ＤＮＳ）クエリに応答する方法であって、前記方法は、
プロキシサーバが、１以上のクライアントから前記複数のＤＮＳクエリを受信するステップと、
前記複数のＤＮＳクエリにおける各々個別のＤＮＳクエリについて、当該個別のＤＮＳクエリが対応するメタデータの要求を含むかどうかを判断するステップとを含み、
前記個別のＤＮＳクエリが前記対応するメタデータの要求を含む場合に、前記プロキシサーバは、当該個別のＤＮＳクエリを権威ＤＮＳサーバに送信するように構成されており、
前記１以上のクライアントの内の１つのクライアントから受信された、前記複数のＤＮＳクエリにおけるＤＮＳクエリが、メタデータを要求していないという判断に応答して、前記プロキシサーバが、修正されたＤＮＳクエリを生成するステップを含み、前記修正されたＤＮＳクエリを生成することは、前記ＤＮＳクエリを修正してメタデータの要求を含めることを含み、
前記プロキシサーバが、前記修正されたＤＮＳクエリを前記権威ＤＮＳサーバに送信するステップと、
前記プロキシサーバが、前記権威ＤＮＳサーバから、前記修正されたＤＮＳクエリへの応答を受信するステップとを含み、前記応答は前記メタデータを含み、前記方法はさらに、
前記プロキシサーバが、前記メタデータに少なくとも部分的に基づいて、前記ＤＮＳクエリへの前記応答を生成するステップと、
前記プロキシサーバが、前記ＤＮＳクエリへの前記応答を前記クライアントに送信するステップとを含み、
前記ＤＮＳクエリへの前記応答は、前記メタデータに含まれるプログラムと、複数のＩＰアドレスとを含み、
前記ＤＮＳクエリへの前記応答を生成することは、前記複数のＩＰアドレスからＩＰアドレスを選択するために、前記プログラムを実行することを含む、方法。

【請求項9】

前記ＩＰアドレスは、当該ＩＰアドレスの待ち時間、可用性、または優先度のうちの少なくとも１つに基づいて選択される、請求項８に記載の方法。

【請求項10】

前記ＤＮＳクエリに対する前記修正された応答を前記クライアントに送信する前に、前記修正されたＤＮＳクエリに対する応答から前記メタデータを除去するステップをさらに含む、請求項８または９に記載の方法。

【請求項11】

請求項１〜１０のいずれかに記載の方法をコンピュータに実行させるためのプログラム。

【請求項12】

請求項１１に記載のプログラムを格納したメモリと、
前記プログラムを実行するためプロセッサとを備える、システム。

【発明の詳細な説明】

【背景技術】

【0001】

関連出願との相互参照
この出願は、２０１６年３月９日に出願され、「インテリジェントドメインネームシステム転送のための方法および装置」（Methods and Apparatus for Intelligent Domain Name System Forwarding）と題された米国出願第６２／３０５，６０２号の、米国特許法第１１９条（ｅ）に基づく優先権利益を主張する。この出願は、その全体がここに引用により援用される。

【0002】

背景
ドメインネームシステム（Domain Name System：ＤＮＳ）とは、インターネットまたはプライベートネットワークに接続されたコンピュータ、サービス、または任意のリソースのための階層的な分散命名システムである。それは、関与するエンティティの各々に割当てられたドメイン名にさまざまな情報を関連付ける。ＤＮＳはまた、より容易に記憶されるドメイン名を、基盤ネットワークプロトコルを用いてコンピュータサービスおよびデバイスを突きとめて識別するために使用される数値インターネットプロトコル（Internet Protocol：ＩＰ）アドレスに変換する。

【0003】

権威ネームサーバまたはオーソリテイティブとしても知られる権威ＤＮＳサーバは、数値ＩＰアドレスへのドメイン名のマッピングについてのクエリに、また、メールエクスチェンジャー（mail exchanger：ＭＸ）レコードといった他のリソースレコード（resource record：ＲＲ）についての要求に応答する。これらのクエリに応答するために、各オーソリテイティブはそれ自体のＤＮＳレコードのＤＮＳデータベースを有する。ＤＮＳデータベースに格納されるよくあるタイプのレコードは、ＩＰアドレス（ＡおよびＡＡＡＡ）、簡易メール転送プロトコル（Simple Mail Transfer Protocol：ＳＭＴＰ）ＭＸレコード、および、対応するドメインについてのネームサーバ（name server：ＮＳ）レコードを含む。ＤＮＳデータベースはまた、ＤＮＳレコードを認証するために使用され得る、ドメイン名エイリアス（ＣＮＡＭＥ）およびＤＮＳセキュリティ拡張（DNS Security Extension：ＤＮＳＳＥＣ）レコードを含む、他のタイプのデータについてのレコードを格納することができる。

【0004】

インターネットに新しいドメインを追加するために、基本ＤＮＳ規格は、ドメイン所有者すなわち登録者に、登録機関からドメイン名を購入し、新しいドメインについてのクエリに回答するために使用される権威ＤＮＳサーバの名前を特定するよう要求する。登録者は、権威ＤＮＳプロバイダ（ニューハンプシャー州（ＮＨ）マンチェスター（Manchester）のダイナミック・ネットワーク・サービシーズ・インコーポレイテッド（Dynamic Network Services Inc.）など）から権威ＤＮＳサービスを取得し、そのドメイン名（より正確にはゾーン）についてのレコードを権威ＤＮＳプロバイダを用いて構成する。エンドユーザのマシンが新しいドメイン名へのアクセスを試みると、それは再帰的（recursive）ＤＮＳサーバに、新しいドメインについてのＤＮＳレコード、最も一般的にはＡまたはＡＡＡＡ（ＩＰｖ４またはＩＰｖ６アドレス）を検索すよう依頼する。再帰的サーバは、権威ＤＮＳプロバイダによって保持された権威ＤＮＳサーバを突きとめ、次に、ＤＮＳレコードについて権威ＤＮＳサーバに問合せる。再帰的ＤＮＳサーバは、権威ＤＮＳサーバの回答をエンドユーザのマシンへ返す。再帰的ＤＮＳサーバはまた、その有効時間（time to live：ＴＴＬ）に従って回答をキャッシュに入れてもよい。エンドユーザのマシンは次に、権威ＤＮＳサーバによって提供されるＤＮＳレコードを使用してドメインへのアクセスを試みる。

【発明の概要】

【0005】

概要
本技術の実施形態は、ＤＮＳクエリに応答する方法を含む。例示的な方法は、プロキシサーバでクライアントからＤＮＳクエリを受信するステップを備える。プロキシサーバは、メタデータについての要求を含むようにＤＮＳクエリを修正し、ＤＮＳクエリを権威ＤＮＳサーバに送信する。プロキシサーバは権威ＤＮＳサーバからＤＮＳクエリへの応答を権威ＤＮＳサーバから受信し、応答はメタデータを含む。プロキシサーバは、メタデータに少なくとも部分的に基づいてＤＮＳクエリへの応答を修正し、ＤＮＳクエリへの応答をプロキシサーバからクライアントに送信する。

【0006】

プロキシサーバは、ＤＮＳクエリにおいてＤＮＳセキュリティ（ＤＮＳＳＥＣ）ＯＫ（ＤＯ）フラグを設定することにより、ＤＮＳクエリを修正することができる。メタデータは、要求リソース署名（Requested Resource Signature：ＲＲＳＩＧ）レコードであり得る。プロキシサーバによって受信されたＤＮＳクエリへの応答は、プログラムを含むメタデータを受信することと、複数のＩＰアドレスを受信することとを含み得る。この場合、プロキシサーバは、プログラムを実行することにより、ＤＮＳクエリへの応答を修正する。実行中、プロキシサーバは、複数のＩＰアドレスを並べ替え、複数のＩＰアドレスをフィルタリングし、複数のＩＰアドレスからＩＰアドレスを選択してもよい。いくつかの実施形態では、プロキシサーバは、ＤＮＳクエリへの応答からメタデータを除去することによってＤＮＳクエリへの応答を修正し、次に応答をクライアントに送信する。プロキシサーバは、応答をクライアントに送信するために一連の規則を適用することにより、ＤＮＳクエリへの応答を修正することができる。

【0007】

本技術の他の実施形態は、ＤＮＳクエリへの複数の応答を生成するためのシステムを含む。例示的なシステムは、ＤＮＳ権威サーバおよびクライアントデバイスとデジタル通信するプロキシサーバを備える。プロキシサーバは、クライアントデバイスからＤＮＳクエリを受信するように構成されている。プロキシサーバは、メタデータについての要求を含むようにＤＮＳクエリを修正し、ＤＮＳクエリを権威ＤＮＳサーバに送信し、権威ＤＮＳサーバからＤＮＳクエリへの応答を受信することができ、応答はメタデータを含む。プロキシサーバは、メタデータに少なくとも部分的に基づいてＤＮＳクエリへの応答を修正し、ＤＮＳクエリへの応答をクライアントに送信することができる。

【0008】

プロキシサーバは、ＤＮＳクエリにおいてＤＮＳセキュリティ（ＤＮＳＳＥＣ）ＯＫ（ＤＯ）フラグを設定することにより、ＤＮＳクエリを修正するように構成され得る。メタデータは、ＲＲＳＩＧであり得る。権威ＤＮＳサーバからのＤＮＳクエリへの応答は、プログラムと、複数のＩＰアドレスとを含み得る。この場合、プロキシサーバは、プログラムを実行するように構成されている。プロキシサーバは、複数のＩＰアドレスを並べ替え、複数のＩＰアドレスをフィルタリングし、複数のＩＰアドレスからＩＰアドレスを選択することにより、プログラムを実行することができる。プロキシサーバは、応答をクライアントデバイスに送信する前にＤＮＳクエリへの応答からメタデータを除去するように構成され得る。プロキシサーバは、応答をクライアントデバイスに送信するために一連の規則を適用することにより、ＤＮＳクエリへの応答を修正するように構成され得る。

【0009】

本技術のさらに他の実施形態は、ＤＮＳクエリに応答するための方法を含む。例示的な方法は、プロキシサーバでクライアントからＤＮＳクエリを受信するステップを備える。プロキシサーバは、ＤＮＳクエリがメタデータについての要求を含むかどうかを判断する。ＤＮＳクエリがメタデータについての要求を含むという判断に応答して、プロキシサーバは、ＤＮＳクエリをプロキシサーバから権威ＤＮＳサーバに送信する。ＤＮＳクエリがメタデータについての要求を含んでいないという判断に応答して、プロキシサーバは、メタデータについての要求を含むようにＤＮＳクエリを修正し、ＤＮＳクエリをプロキシサーバから権威ＤＮＳサーバに送信する。プロキシサーバは、権威ＤＮＳサーバからＤＮＳクエリへの応答を受信し、応答はメタデータを含む。プロキシサーバは、メタデータに少なくとも部分的に基づいてＤＮＳクエリへの応答を修正し、ＤＮＳクエリへの応答をプロキシサーバからクライアントに送信する。

【0010】

権威ＤＮＳサーバから受信されたＤＮＳクエリへの応答は、メタデータに含まれるプログラムと、複数のＩＰアドレスとを含み得る。ＤＮＳクエリへの応答を修正するステップは、プロキシサーバで、複数のＩＰアドレスからＩＰアドレスを選択するために、プログラムを実行するステップを含み得る。ＤＮＳクエリへの応答を修正するステップは、プロキシサーバが、ＩＰアドレスの待ち時間、可用性、または優先度のうちの少なくとも１つに基づいてＩＰアドレスを選択するステップを含み得る。ＤＮＳクエリがメタデータについての要求を含んでいないという判断に応答して、プロキシサーバは、応答をクライアントに送信する前に応答からメタデータを除去することができる。

【0011】

前述の概念および以下により詳細に説明される追加の概念（そのような概念は互いに矛盾していないと仮定する）のすべての組合せは、ここに開示される本発明の主題の一部であると考えられる、ということが理解されるべきである。特に、本開示の最後に現われる請求される主題のすべての組合せは、ここに開示される本発明の主題の一部であると考えられる。引用により援用される開示にも現われ得る、ここに明示的に採用された用語は、ここに開示される特定の概念と最も一貫する意味を与えられるべきである、ということも理解されるべきである。

【0012】

図面の簡単な説明
図面は主として例示のためのものであり、ここに説明される本発明の主題の範囲を限定するよう意図されてはいないということを、当業者であれば理解するであろう。図面は必ずしも縮尺通りではなく、場合によっては、ここに開示される本発明の主題のさまざまな局面は、異なる特徴の理解を容易にするために、図面において誇張または拡大して示されることがある。図面では、同様の参照符号は概して、同様の特徴（たとえば、機能的に同様の、および／または構造的に同様の要素）を指す。

【図面の簡単な説明】

【0013】

【図1】インテリジェントＤＮＳ転送を容易にするプロキシサーバを含むシステムを示す図である。

【図2】（未修正の）権威ＤＮＳサーバを用いて先進的（advanced）ＤＮＳサービスを提供するプロキシサーバを示す図である。

【図3】プロキシサーバによるインテリジェントＤＮＳ転送の方法を示すフロー図である。

【図4】権威ＤＮＳサーバからのメタデータを処理するための方法を示すフロー図である。

【図5】プロキシサーバによる例示的なインテリジェントＤＮＳ転送を示す図である。

【発明を実施するための形態】

【0014】

詳細な説明
権威ＤＮＳサーバは、ウェブサイトの名前についてのクエリに、そのウェブサイトを指し示すＩＰアドレスを返すことによって応答する。通常、権威ＤＮＳサーバは、ＩＰアドレスは変わっていないと仮定して、所与のウェブサイトに向けられたクエリについて毎回同じＩＰアドレスを与えるべきである。しかし、権威ＤＮＳサーバが所与のドメイン名について問合された際に異なる応答（たとえばＩＰアドレス）を返すこと、すなわち、権威ＤＮＳサーバが同じクエリに異なる回答を与えることが有利になると思われる場合がある（この挙動は一般に「先進的ＤＮＳサービス」と呼ばれる）。たとえば、異なるエンドユーザを異なるＩＰアドレスに向けることをディレクトリレベルでの負荷分散のために使用して、各エンドユーザが最も近いサーバ（たとえば、最低の待ち時間または最短の地理的距離を有するサーバ）によってサービス提供されることを保証するか、もしくは、エイリアス機能性またはＣＮＡＭＥ平坦化（別名ＡＬＩＡＳ）を提供してＤＮＳ規格自体の制限を回避してもよい。同様に、権威ＤＮＳサーバがリカーサの地理に依存して異なる他の名前を指し示すＣＮＡＭＥを返すことが有用であり得る。

【0015】

残念ながら、ＤＮＳ規格は、同じクエリに異なる応答を提供しない。この制限を回避するために、権威ＤＮＳサーバは、たとえば所与のクエリを行なう再帰的サーバのＩＰアドレスまたは時刻に依存して、当該クエリに異なる応答を提供するように修正されてもよい。それらの応答はまた、複数のサーバにわたって負荷を分散させるために、より大きい集合からランダムに選択されてもよい。典型的には、修正は、登録者によって提供される情報またはアルゴリズムまたはコードに基づく。たとえば、権威ＤＮＳサーバは、問題になっているドメインについての所望の挙動を特殊レコードタイプとしてＤＮＳデータ内に格納し、それを修正されたコードに従って返すように修正されてもよい。

【0016】

しかし、これらの修正は概してカスタムであり、また、権威ＤＮＳサーバの複雑性に一部起因して貧弱なスケールになる傾向がある。伝統的に、権威ＤＮＳサーバは通常、ある使用事例について最適化されているため、カスタム回答を提供するようにそれを修正することはスケーリング問題をしばしばもたらす。それらのスケーリング問題のうちの一例は、インメモリサーバを選択したためにメモリにロードし過ぎることである。メモリにロードすることは、多数のレコードのために不都合に長い時間を要し得る。オーソリテイティブのスケーリングまたは他の特性を、異なるものとの交換によって変更することは、カスタム作業をやり直すこと、およびおそらくは、異なるシステムにおいて異なるバージョンを維持することをしばしばもたらす。また、これらのシステムは複雑であり、維持することが難しい。カスタマイズされた権威ＤＮＳサーバを維持することもまた、特にレコードが時間とともに変化する場合、複雑であり得る。

【0017】

本技術は、権威ＤＮＳサーバを修正する代わりに、権威ＤＮＳサーバに結合されたプロキシサーバを使用して、同じクエリへの異なる応答を生成するやり方を提供する。その結果、プロキシサーバは顧客データまたは先進的サービス仕様を保持する必要がないため、それは、そのデータのスケーリングまたはそれへのアクセスパターンによる影響を受けない。

【0018】

インテリジェントＤＮＳ転送のためのシステム
図ｌは、インテリジェントＤＮＳ転送を提供するために、クライアントデバイス１２０からのＤＮＳクエリを検出し、権威ＤＮＳリゾルバ１１０からの応答を処理するように構成された、ＤＮＳプロキシサーバまたはＤＮＳプロキシとも呼ばれるプロキシサーバ１３０を含む、システム１００の図である（図ｌは、理解を容易にするための簡略バージョンである）。システム１００はまた、権威ＤＮＳリゾルバ１１０と、エイリアスリゾルバ１３５と、ネットワークリソース（メモリ）１９９とを含む。これらのデバイスとプロキシサーバ１３０とはＤＮＳエッジ１０１に位置し、（たとえばインターネットを介して）トランス１７０に動作可能に結合されており、トランス１７０は次に、ポリシーマスタ１６０およびポリシーコンパイラ１５０に結合される。

【0019】

当業者には容易に理解されるように、プロキシサーバ１３０、権威サーバ１１０、再帰的リゾルバ１３５、ポリシーコンパイラ１５０、ポリシーマスタ１６０、およびトランス１７０は各々、コンピュータ読取可能不揮発性メモリに格納され、プロセッサによって実行される、コンピュータ実行可能コードとして実現され得る。それらは、好適なハードウェアおよび接続を使用して、要望通り配列または分散され得る。同様に、ネットワークリソース１９９は、プロキシサーバ１３０およびトランス１７０に通信可能に結合された任意の好適なタイプのコンピュータ読取可能不揮発性メモリとして実現され得る。

【0020】

以下により詳細に説明されるように、顧客１４０は、従来のシステムと全く同様に、そのドメイン名についてのＤＮＳレコードを権威ＤＮＳリゾルバ１１０を用いて構成する。これらのドメイン名は、コンテンツ配信ネットワーク（content delivery network：ＣＤＮ）などの１つ以上の顧客アセット１４５ａ〜１４５ｃ（まとめて顧客アセット１４５）に関連付けられてもよく、それらは各々、異なるＩＰアドレスを有しており、所与のドメイン名に対応するＩＰアドレスとして解決され得る。顧客１４０は、ユーザ１２１からのドメイン名クエリに応答して、これらのＩＰアドレスにトラフィックを向けるための１つ以上のダイナミックステアリングポリシーを設定する。たとえば、顧客１４０は、エンドユーザ１２１からの所与のＤＮＳクエリに応答して、どのＩＰアドレスを供給するかを判断するための待ち時間、可用性、地理的位置、および他の基準を特定するために、ウェブベースのインターフェイスを使用してもよい。ネットワークリソース１９９は、インテリジェントＤＮＳ転送におけるプロキシサーバ１３０による使用のために、これらの基準に対応するリンクデータ１８０、サブネットデータ１９０、および／またはアセットデータ１９５を格納してもよい（リンクデータ１８０およびサブネットデータ１９０はまた、プロキシ１３０に対してローカルであるメモリデータ構造に格納され得る）。より一般的には、ダイナミックステアリングポリシーは、顧客のドメイン名のうちの１つについてのＤＮＳクエリに応答してＩＰアドレスを供給するための、顧客１４０からの、およびおそらくはエンドユーザ１２１からの基準、データ、および規則を含む。

【0021】

ポリシーマスタ１６０は、顧客１４０からのダイナミックステアリングポリシーを、たとえば正式のコンピュータ言語で書かれた１つ以上の関数として格納する。ポリシーマスタ１６０は、これらの関数を含むプログラムを、ポリシーコンパイラ１５０を用いて生成する。ポリシーコンパイラ１５０は、ダイナミックステアリングポリシーを含む関数がプロキシサーバ１３０によって解釈され得るようにこれらのプログラムを構築するように構成された、単純な実行可能ラッパーとして実現され得る。ポリシーマスタ１６０は、図１に示すように、（たとえば、要求リソース署名（ＲＲＳＩＧ）レコードにおけるプログラムとしての）先進的サービスの顧客構成を権威ＤＮＳリゾルバ１１０に供給してもよい。

【0022】

ポリシーマスタ１６０からのダイナミックステアリングポリシーと、リンクデータ１８０、サブネットデータ１９０、およびアセットデータ１９５などの添付データとは、トランス１７０を介してネットワークリソース１９９に送信される。トランス１７０は、動的データ（たとえば、リンクデータ１８０、サブネットデータ１９０、アセットデータ１９５など）をエッジ１０１に伝播する。トランス１７０は、さまざまなチャネルにおけるイベントをリッスンし、それらを、「192.0.2.0/24におけるリゾルバの背後からExampleCDNまでの平均待ち時間は４２ミリ秒です」、または「198.51.100.0/24はフランスにあります」、または「webserver2.example.comはダウンしています」といった宣言的情報になるよう処理することによって、そのデータを得る。

【0023】

よって、ネットワークリソース１９９は、顧客１４０によって提供されたデータ、または、ＤＮＳクエリへの応答を判断するために使用される待ち時間、健全性、地理的位置、可用性、および他の基準に関して取得されたデータを格納する。たとえば、リンクデータ１８０は、権威ＤＮＳリゾルバ１１０によって（たとえば５分ごとに）集計され得る、加工された（cooked）待ち時間パフォーマンスデータを格納する。サブネットデータ１９０は、顧客アセット１４５ごとに、およびおそらくはクライアント１２０ごとに、地理的位置データを格納する。アセットデータ１９５は、ＩＰアドレスの健全性といった可用性データを含む。

【0024】

動作時、プロキシサーバ１３０は、顧客１４０によって定義され、とりわけリンクデータ１８０、サブネットデータ１９０、および／またはアセットデータ１９５に基づいたポリシーを使用して、クライアント１２０を適切な顧客アセット１４５ａ、１４５ｂまたは１４５ｃへ導く。プロキシサーバ１３０は、クライアント１２０からＤＮＳサーバ１１０についてのクエリを受信し、それらがＤＮＳＳＥＣ情報などのメタデータについての要求を含むかどうかを確かめるためにそれらを検査する。クエリがＤＮＳＳＥＣ情報についての要求を含む場合、プロキシサーバ１３０はクエリを権威ＤＮＳサーバ１１０へ渡し、含んでいない場合、プロキシサーバ１３０は、権威ＤＮＳサーバ１１０からＤＮＳＳＥＣ情報を検索するために、クエリにおいてＤＮＳＳＥＣ ＯＫ（ＤＯ）フラグを設定する。権威ＤＮＳサーバ１１０は、ＤＮＳ規格に従ってプロキシサーバ１３０に応答する。プロキシサーバ１３０は、ＤＮＳＳＥＣ情報、元のクエリ、クエリソース（ＩＰアドレス）、時刻などに基づいて権威ＤＮＳサーバ１１０からの応答を修正し、次に、修正された応答を、要求を行なった再帰的ＤＮＳサーバに送信する。

【0025】

プロキシサーバ１３０は、クライアント１２０によって要求されていないＤＮＳＳＥＣ関連ＲＲなどのメタデータを検索するかもしれないため、要求されなかった場合、それは応答からメタデータを除去する。関連して、そのＤＯフラグはＯＰＴと呼ばれるレコードの内部にあり、いくつかのクライアントはそれも要求せず、その場合、それも同様に除去される。より一般的には、クライアントクエリへの修正は、それらの結果を逆にしてからクライアントに返す。さまざまな状況で使用される修正は、（１）ＯＰＴレコードが存在しない場合、ＯＰＴレコードを追加すること；（２）ＤＯが設定されていない場合、ＤＯを設定すること；および（３）クライアントソースＩＰアドレスを有するクライアントサブネットオプションを追加すること、を含む。プロキシサーバはまた、レガシーインフラストラクチャからの移行をよりシームレスにするようにクライアントソースＩＰを渡すために、ＥＤＮＳ０プロキシオプション（EDNS0 Proxy Option：ＥＰＯ）と呼ばれるカスタムオプションを追加することができる。修正された権威ＤＮＳサーバと連携する場合、ＥＰＯは有用である。これらすべてのうち、ＯＰＴおよびＤＯ部分のみが、ＲＲＳＩＧアプローチにとって必須である。

【0026】

いくつかの実現化例では、プロキシサーバ１３０は、権威ＤＮＳサーバ１１０上のＤＮＳＳＥＣレコードに格納された要求リソース署名（ＲＲＳＩＧ）と呼ばれる暗号署名情報に従って、権威ＤＮＳサーバ１１０からの応答を修正する。プロキシサーバ１３０は、ＲＲＳＩＧと、クエリソースのＩＰアドレスなどのクエリにおいて符号化された情報との双方を使用して、クエリへの応答を修正するかどうか、およびクエリへの応答をどのように修正するかを判断する。いくつかの点では、このアプローチは、権威ＤＮＳサーバ１１０をＲＲＳＩＧ用の「メモリ」として扱うことを伴う。プロキシサーバ１３０はＤＮＳＳＥＣレコードを返すようにクエリを修正するため、プロキシサーバ１３０はＲＲＳＩＧについて別個の要求を行なう必要はない。そして、クエリ応答を修正するためのこの手法は余分のクエリを伴なわないため、それは、ＲＲＳＩＧについて別個のクエリを行なう場合よりも、権威ＤＮＳサーバ１１０にかかる処理負担を小さくする。すなわち、権威ＤＮＳサーバ１１０は、プロキシサーバ１３０からの（場合によっては修正された）単一の要求を、それが２つの別個の要求を処理し得る場合よりも効率的に処理することができる。

【0027】

にもかかわらず、ＤＮＳクエリへの応答を修正するためにプロキシサーバ１３０を使用しない明白な理由がいくつかある。プロキシサーバ１３０を追加することは余分なレイヤーをネットワークに追加し、それは待ち時間、コスト、および複雑性を増加させる。プロキシサーバ１３０を使用することはまた、ネットワークトラフィックの量を倍にする。しかし、修正された権威ＤＮＳサーバ１１０を使用することとは異なり、プロキシサーバ１３０を使用することは、ルーチンＤＮＳサービスを提供する機能性から先進的ＤＮＳ機能性を分離する。それは、それらの機能性をともに混合することとは対照的である。プロキシサーバ１３０を使用することはまた、先進的ＤＮＳ機能性を提供するためのフレキシビリティを高める。そして、プロキシサーバは機能開発のために構築可能であるため、プロキシサーバにおいて新機能を実現することがより容易でより迅速であるかもしれない。プロキシサーバ１３０はまた、プロキシサーバ自体への、または権威ＤＮＳサーバへの更新を行なうことなく、多くの新機能がリリースされ得ることを十分に一般化する言語を使用できる。それはまた、すでに構築されたかもしれない大抵のＤＮＳＳＥＣ対応の権威ＤＮＳシステムに、修正をほとんど加えることなく、先進的機能をオーバーレイすることを実用的にする。

【0028】

権威ＤＮＳサーバ１１０とともにプロキシサーバ１３０を使用することはまた、サーバ間の一貫性を維持することを単純化する。いくつかのプロキシサーバ１３０は、たとえばウェブサイト用の構成データを保持するが、この構成データは、実際のコンテンツサーバ上の構成データと慎重に同期されなければならない。所望の先進的機能挙動とデータとの双方を同じゾーンに保持することは、これらが標準的なゾーン更新メカニズムを使用して同期したまま保持されることを可能にする。これが、全く別のアプローチではなく、カスタムＲＲタイプが一般に使用される理由である。なぜなら、別個のデータベースが先進的機能を包含し得るものの、それを同期したまま保持することは問題になるためである。ここに開示されるプロキシアプローチは、実現部を分離しつつ、このゾーン内特性を保っており、それはかなりまれである。

【0029】

プロキシサーバ１３０が権威ＤＮＳサーバ１１０に結合された状態では、オープンソースまたは内部で開発された権威サーバの実装への変化を維持する必要はない。プロキシサーバ１３０を使用することはまた、各権威ＤＮＳサーバ内で機能を再開発することなく、異なる権威ＤＮＳサーバ実現を使用するためのフレキシビリティを提供する。そのフレキシビリティは、機能群（feature set）が、非常に異なるパフォーマンス特性およびスケーリング特性を有するデプロイメントにおいて使用されることを可能にする。現在、異なる権威サーバ実現を使用してこれらの異なるマーケットにサービス提供するシステムが複数ある。これらのシステムのうちの一部のみが先進的機能を提供してもよく、残りは、非常に多くの（たとえば何百万もの）ゾーンが存在し、パフォーマンスがそれほど敏感ではない、バルクホスティングマーケットなどのマーケットに対処する。

【0030】

次に、これらのシステムのすべてが先進的機能を提供してもよい。たとえば、企業ＤＮＳは概してパフォーマンスに敏感であり、一方、バルクＤＮＳは、アクセス頻度が低い非常に多くのゾーンへのスケーリングにより関与する傾向がある。それらの異なるアクセスパターンは、異なる権威ＤＮＳサーバによってより良好にサービス提供され得る。加えて、オペレータは、自分のネットワークをよりレジリエントにするために、２つ以上の権威ＤＮＳサーバ実現を使用したいかもしれず、それは本来なら、先進的機能が２つの異なる実現に行なわれるのをサポートするための修正を要求するかもしれない。

【0031】

インテリジェントＤＮＳ転送のためのプロキシサーバ
図２は、ＤＮＳサーバ２１０（たとえば、権威ＤＮＳサーバ、またはバックエンド再帰的ＤＮＳサーバ）の前に位置するＤＮＳプロキシサーバ２３０を示す。動作時、それは、クライアント２２０（たとえば再帰的サーバ）から転送制御プロトコル（Transmission Control Protocol：ＴＣＰ）２０７およびユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）２０５のＤＮＳクエリ（たとえば、ＤＮＳクエリ２３３ａおよび２３３ｂ）を受入れ、ＤＮＳクエリ（たとえば、２３３ｃおよび２３３ｄ）をＤＮＳサーバ２１０へ発行する。ＤＮＳプロキシサーバ２３０は、クライアントのクエリへのさまざまな動的応答を一般的なやり方で提供するために、それらの動的応答に関する構成を必ずしも格納することなく、権威ＤＮＳサーバ２１０からの応答に埋込まれた命令を解釈して、同期の懸念を減少させるかまたは排除する。それは、権威ＤＮＳサーバからの応答を必ずしもキャッシュに入れず、また、優れたパフォーマンスまたは正しい挙動について必ずしもキャッシュに依存しない。

【0032】

より具体的には、ＤＮＳプロキシサーバ２３０は、クライアント２２０からのクエリ２３３ａおよび／または２３３ｂを（何らかの軽微な修正を加えて）ＤＮＳサーバ２１０へ渡し、返答を待つ。ＤＮＳプロキシサーバ２３０は、クエリ２３３を取扱う（それらを修正し、それらを権威または再帰的サーバ２１０へ送信し、結果を処理し、クライアント２２０に応答する）ための１つ以上のクエリ処理ワーカ２３２を含む。実際には、プロキシサーバ２３０は、均一のワーカ２３２の大きい集合を保持し、クエリが到着するとそれらにクエリ２３３を手渡してもよく、各ワーカ２３２は一度に１つのクエリ２３３に専念する。応答が送信されるやいなや、ワーカ２３２は、次のクエリ２３２に対する準備ができている。

【0033】

ＴＣＰバックエンド２３６における１つ以上のＴＣＰクライアント２３４は、ワーカ２３２からサーバ２１０への、および反対方向のメッセージを、同様の一度に１つの態様で調整するが、効率のためにサーバ２１０への持続接続を維持することができる。各ＴＣＰバックエンド２３６は、同じサーバ２１０専用のＴＣＰクライアント２３４のプールである。多くの別個のサーバ２１０があってもよく、それらの各々は、ＴＣＰクライアント２３４のプールを有する対応するＴＣＰバックエンド２３６を有する。

【0034】

ＤＮＳサーバ２３０からの返答（たとえば、２３７ａおよび２３７ｂ）は、クエリについての回答レコードを包含していてもよく、オプションで１つ以上のＲＲＳＩＧレコードも包含していてもよい。その挙動は、どのＤＮＳＳＥＣ準拠ＤＮＳサーバにも存在し、ＲＲＳＩＧレコードの意図された用途と矛盾しない。ＲＲＳＩＧレコードは、標準化されたカスタム暗号化タイプを使用するものを含んでいてもよく、それは次に、特定の所有者まで追跡可能であり、ひいては一意的である名前によって明確にされる。

【0035】

その名前の後に、ＲＲＳＩＧレコードは、所望の挙動を作り出すためにより小さい関数をともに構成するのに十分精巧な言語で書かれた埋込まれたプログラムを含む任意のデータを担持していてもよい。それはまた、プログラムで命名されている各機能の劣化ケースなどの挙動／機能ごとに特定のＲＲタイプを使用することができる。たとえば、劣化ケースは、人間が読める形で、Alias(“domain.com”)として表現されてもよい。および、より多くの原始関数（非常に近似的）を構成するより精巧な表現：ReplaceRR(Qname(), Qtype(), LookupRecursive("domain.com"))として表現されてもよい。それは、適切なＲＲＳＩＧレコードをゾーンに追加することによって権威メモリに入れられる。

【0036】

ＤＮＳプロキシサーバ２３０は埋込まれたプログラムを監視し、それを実行して、クライアント２２０の元のクエリへの修正された応答を生成する。ＤＮＳプロキシサーバ２３０がクライアント２２０にどの応答を送信すべきか判断する過程で、ＤＮＳプロキシサーバ２３０は、ＤＮＳまたは他のプロトコルを使用して他のシステムへの追加のクエリを発行してもよく、または他のローカルデータを調べてもよい。最後に、プロキシサーバ２３０は、結果（たとえば、２３７ｃおよび／または２３７ｄ）をクライアント２２０に返す。

【0037】

最も一般的な場合、ＲＲＳＩＧレコードにはプログラムが埋込まれておらず、そのため、ＤＮＳプロキシサーバ２３０は、たった１つのクエリを権威ＤＮＳサーバ２１０へ渡すことによって、クライアントのクエリへの応答を生成することができる。反対に、カスタムタイプにプログラムを埋込むことは、２つのクエリを必要とするであろう。一方のクエリは、プログラムがあるかどうかをカスタムタイプが確かめるためのものであり、もう一方のクエリは、要求されたデータのためのものである。ＲＲＳＩＧ実現のために、ＤＮＳプロキシサーバ２３０は、アプリケーション特有の挙動が実現されることに依存して、最初のクエリを超えた追加のクエリを行なってもよい。

【0038】

ポリシーマスタおよびポリシーコンパイラ
ポリシーマスタは、顧客からのダイナミックステアリングポリシーおよび添付データを格納することを担当する。ポリシーマスタは、ポリシーコンパイラを用いてプログラムを生成し、ポリシーコンパイラは、プロキシサーバによって解釈され得るプログラムを構築するように構成された単純な実行可能ラッパとして実現され得る。ポリシーコンパイラは、プログラムを構築するように構成された関数を提供する。ポリシーコンパイラに追加されるいくつかの例示的な関数は、ＤＮＳクエリに応答して供給され得る可能なすべてのＩＰアドレスの中からＩＰアドレスを選択するためのフィルタ関数およびソーティング関数を含む。

【0039】

一実現化例では、ポリシーコンパイラは、最終応答に入るかもしれないリソースレコードのリストを得るBuildResponse関数と、レコードのリストをソートすることおよび／または減少させることによって当該リストを変更することができる規則関数とを含む。そのような関数は、ソーティングまたはフィルタリングを行なうための引数に加えて、規則関数も得る。このように、１つのポリシーに複数の規則を適用することができる。適用される必要がある一連の規則を終了するために、特殊関数Endを使用することができる。規則をすべて適用した後で、BuildResponse関数は、レコードの（減少した）リストをシャッフルしてＤＮＳ応答を構築することができる。BuildResponseプログラムの一例は、以下の通りである：

【0040】

【数1】

【0041】

この例では、Available、Performance、およびPriorityは、ソーティングおよびフィルタリングを行なうための規則である。これらの規則を以下にさらに説明する。

【0042】

関数Available [av1, av2, ...]は、各要素が提案されたリソースレコードのリストにおけるリソースレコードindexをアセット識別子にマッピングするアセットマッピングのリストに基づいて、リソースレコードのリストをフィルタリングすることができる。アセット識別子は、ネットワークリソースから可用性データをルックアップするために使用され得る。利用できないアセットに対応するレコードは、リストから除去される。そのため、以下の例における"0:asset9998"は、アセット"asset9998"についての可用性をルックアップし、そのアセットが利用できないとマークされている場合にリソースレコード"rr0"を取り除く、ということを意味する。この規則はリストを空のままにせず、すべてのレコードが除去された場合、フィルタリングは行なわれない。
例：

【0043】

【数2】

【0044】

関数Performance [lp1, lp2, ...]タイプは、各要素が提案されたリソースレコードのリストにおけるリソースレコードindexをアセット識別子にマッピングするアセットマッピングのリストに基づいて、リソースレコードのリストをフィルタリングすることができる。アセット識別子は、リンクの待ち時間データをルックアップするために使用され得る。待ち時間データがないアセットは、最大の待ち時間を有すると考えられる。長い待ち時間を有するアセットに対応するレコードは、リストから除去される。そのため、以下の例における"1:asset1001"は、アセット"asset1001"についてのリンクパフォーマンスデータをルックアップし、そのアセットが有する待ち時間が長すぎる場合にリソースレコード"rr1"を取り除く、ということを意味する。この規則はリストを空のままにせず、すべてのレコードが除去された場合、フィルタリングは行なわれない。

【0045】

このタイプの引数は、リンクパフォーマンスフィルタリングがどのように適用されるかを定義する。それは、リンクパフォーマンスフィルタオプションへの非負整数値Ｎのマッピングであると定義される。これらのオプションは、以下のものを含んでいてもよい：
・"count"：最低の待ち時間を有する最大でＮ個のアセットを返す。どのレコードにも待ち時間データがない場合を除き、待ち時間データがないレコードは含まれないであろう；
・"absolute"：最低の待ち時間を有するアセットと、Ｎミリ秒以内の待ち時間を有するすべてのアセットとを返す；
・"relative"：最低の待ち時間を有するアセットと、所与のレベルのＮパーセント以内の待ち時間を有するすべてのアセットとを返す。

【0046】

【数3】

【0047】

関数Priority [pf1, pf2, ...]は、各要素が提案されたリソースレコードのリストにおけるリソースレコードindexを優先順位にマッピングする優先度マッピングの所与のリストに基づいて、リソースレコードのリストをソートすることができる。そのため、以下の例における"0:20"および"1:10"は、"rr1"が"rr0"よりも好まれるということを意味する。レコードが同じ順位を有する（同点である）場合、プロキシサーバは順序をランダムに定めることができる。優先度が割当てられていないレコードは、無限の優先度を与えられるであろう。空のリストは、優先度がなく、最終応答がシャッフルされるであろうということを意味する。順位は、１６ビットの符号なし整数等価物（16-bit unsigned integer equivalent：ｕｉｎｔ１６）として特定される。

【0048】

【数4】

【0049】

規則の他の例は、リソースレコードのリストをランダムにシャッフルするためのBias、リソースレコードのリストを制限するためのMax num、および特定のリソースレコードを除去するためのRejectなどの関数を含み得る。規則に加えて、条件付きの状態でプログラムを設定する、BuildResponseとEndとの間の関数がある場合がある。プログラムが条件付きの状態にある場合、規則関数は、規則を適用すべきか否かを判断するために条件付きの状態を評価するであろう。いくつかの例は、Switch、Case、Default、およびEndSwitchを含む。

【0050】

プロキシサーバを使用するＤＮＳ転送
図３は、プロキシサーバを使用してインテリジェントＤＮＳ転送を提供するためのプロセス３００を示すフロー図である。このプロセス３００は、図１に示すシステム１００、もしくは、図２のプロキシサーバ１３０などのプロキシサーバを含む任意の他の好適なシステムまたはネットワークを使用して実現され得る。プロセス３００は、インテリジェントＤＮＳ転送を提供するために、クライアントデバイスからのＤＮＳクエリを検出し、権威ＤＮＳサーバからの応答を処理することを伴う。

【0051】

クライアントデバイスがドメインへのアクセスを試みると、ステップ３１０で、それはＤＮＳクエリをＤＮＳプロキシに送信する。ステップ３２０で、ＤＮＳプロキシはＤＮＳクエリを分析して、ＤＮＳクエリがメタデータについての要求を含むかどうかを判断する。一実現化例では、ＤＮＳプロキシはＤＮＳクエリを検査して、ＤＮＳクエリがＤＮＳＳＥＣ情報またはＯＰＴレコードなどのメタデータについての要求を含むかどうかを判断する。ＤＮＳクエリがメタデータについての要求（たとえば、ＤＮＳＳＥＣ情報についての要求）を含む場合、ステップ３３０で、ＤＮＳプロキシはＤＮＳクエリを権威ＤＮＳサーバへ渡す。ＤＮＳクエリがメタデータについての要求を含んでいない場合、ステップ３４０で、ＤＮＳクエリはメタデータについての要求を含むように更新される。一実現化例では、ＤＮＳプロキシは、権威ＤＮＳサーバからＤＮＳＳＥＣ情報を検索するために、ＤＮＳクエリにおいてＤＮＳＳＥＣ ＯＫ（ＤＯ）フラグを設定する。別の実現化例では、ＤＮＳプロキシは、権威ＤＮＳサーバからＯＰＴレコードを検索するために、ＯＰＴレコードＤＯ＝１を設定する。ステップ３３０で、ＤＮＳプロキシは、更新されたＤＮＳクエリを権威ＤＮＳサーバへ渡す。

【0052】

ステップ３５０で、ＤＮＳプロキシは、権威ＤＮＳサーバからの応答がメタデータを含むかどうかを判断する。一実現化例では、ＤＮＳプロキシは、応答がメタデータ、たとえば、ＤＮＳＳＥＣレコードに格納されたＲＲＳＩＧを含むかどうかを判断する。別の実現化例では、ＤＮＳプロキシは、応答がＯＰＴレコードを含むかどうかを判断する。権威ＤＮＳサーバからの応答がメタデータを含んでいない場合、ステップ３６０で、権威ＤＮＳサーバからのＤＮＳ応答メッセージがクライアントデバイスに送信される。すなわち、プロキシサーバは、権威ＤＮＳサーバからのドメイン名に対応する１つ以上のＩＰアドレスを有するＤＮＳレコードを検索し、それをクライアントデバイスに送信する。しかしながら、権威ＤＮＳサーバからの応答がメタデータ（たとえばＲＲＳＩＧ）を含む場合、ＤＮＳプロキシはメタデータをさらに処理して、権威ＤＮＳサーバからのＩＰアドレスのうちの１つを含む修正された応答を生成する。ステップ３７０で、プロキシサーバによって生成されたこの修正された応答が、クライアントデバイスに送信される。

【0053】

図４は、プロキシサーバで権威ＤＮＳサーバからのメタデータを処理する方法４００を示すフロー図である。ステップ４１０で、ＤＮＳプロキシは、権威ＤＮＳサーバからの応答を受信する。この応答は、メタデータと、１つ以上のＩＰアドレスとを含む。ステップ４２０で、ＤＮＳプロキシは、メタデータに埋込まれた１つ以上のプログラムを処理する。メタデータに埋込まれたプログラムは、ドメイン名に関連付けられた最適なＩＰアドレスを判断するためのダイナミックステアリングポリシーおよび規則を定義する。一実現化例では、ＤＮＳプロキシは、ＲＲＳＩＧに埋込まれた１つ以上の関数を処理する。ステップ４３０で、ＤＮＳプロキシは、メタデータにおける埋込まれた規則および関数に基づいてネットワークリソースをルックアップする。一実現化例では、ＤＮＳプロキシは、ＲＲＳＩＧにおける埋込まれたプログラムを実行し、ＲＲＳＩＧにおける規則に依存して、ＤＮＳプロキシは、リンクデータ、サブネットデータ、およびアセットデータなどのネットワークリソースをルックアップする。リンクデータ、サブネットデータ、およびアセットデータは、待ち時間、パフォーマンス、健全性についての情報、ならびにコンテンツＩＰアドレスおよびクライアントＩＰアドレスに関する他の情報を含む。

【0054】

ステップ４３０で、ドメイン名に関連付けられた１つの最適なＩＰアドレスを判断するために、ネットワークリソースからのデータは並べ替えられ、ソートされ、フィルタリングされる。たとえば、クライアントデバイスからコンテンツ配信ネットワークまでの経路が、それらの待ち時間に基づいてソートされてもよく、ＩＰオリジンが、それらの健全性に基づいてソートされ、並べ替えられてもよい。このように、権威サーバからのＤＮＳ応答は、ＤＮＳプロキシによって生成された最適な回答を含むように修正される。修正されたＤＮＳ応答メッセージは、クライアントデバイスに送信される。クライアントデバイスからのＤＮＳクエリがメタデータについての要求を含まなかった場合、修正されたＤＮＳ応答メッセージにおけるメタデータは、それがクライアントデバイスに送信される前に除去され得る。

【0055】

図５は、プロキシサーバ５３０によるインテリジェントＤＮＳ転送のより具体的な一例を示す。プロキシサーバ５３０は、図１に示すプロキシサーバ１３０および図２に示すプロキシサーバ２３０と機能的に同じとは言えないまでも似ている。クライアントデバイス５２０は、ＤＮＳクエリ５１２を権威ＤＮＳサーバ５１０に送信することによってドメイン名へのアクセスを試みる。プロキシサーバ５３０はＤＮＳクエリ５１２を受入れ、ＤＮＳクエリ５１２が、応答に含まれるべきメタデータについての要求を含むかどうかを判断する。ＤＮＳクエリ５１２がこの要求を含んでいないと判断すると、クエリ５１２は、メタデータについての要求を反映するように更新される。更新されたＤＮＳ要求５１６は、ドメイン名についてのＤＮＳレコードを検索するために、ＤＮＳ権威サーバ５１０に送信される。ＤＮＳ権威サーバ５１０が要求されたドメインについてのメタデータを含んでいない場合、ＤＮＳ権威サーバ５１０は、プログラムなし応答５１８をプロキシサーバ５３０に送信する。プログラムなし応答５１８は、メタデータがないドメイン名のためのターゲットＩＰアドレスである。５２２で、プロキシサーバ５３０は、このプログラムなし応答５１８をクライアントにマッピングする。そして５２４で、プロキシサーバ５３０は、ドメインのＡまたはＡＡＡＡ（ＩＰｖ４またはＩＰｖ６アドレス）をクライアントデバイス５２０に返す。

【0056】

権威ＤＮＳサーバ５１０が要求されたドメインについてのメタデータを含む場合、権威ＤＮＳサーバ５１０は、ドメイン５２６ａに関するＩＰアドレスを含むＤＮＳレコードを、要求されたメタデータ５２６ｂとともに、プロキシサーバ５３０に提供する。５２６ａにおける"example.com. A 0.0.0.0"は、５２６ｂにおける動的処理命令によって閉塞されるであろう「ダミーの」回答である。ＲＲＳＩＧレコードの基本特性は、それらがbaseデータを増大させるメタデータであるということである。図５のこの局面は、回答データは、オーバーライドメタデータを伴うためにプロキシ５３０によって無視されても、オーソリテイティブ５１０からの応答の中に存在する、ということを示す。

【0057】

メタデータは、所望の挙動を作り出すための１つ以上の埋込まれたプログラムを含む。プロキシサーバ５３０は、メタデータ５２６ｂにおける埋込まれたプログラムを実行し、修正された応答を生成するためのインタープリタを含む。処理中、プロキシサーバ５３０は、待ち時間、パフォーマンス、健全性、または他のそのような基準に関する情報を得るために、サブネットデータ５９０および／またはリンクデータ５８０をルックアップする。サブネットデータ５９０およびリンクデータ５８０は、ルックアップ要求（たとえば５２８および５３６）に基づいて回答（たとえば５３２および５３８）をプロキシサーバ５３０に提供するネットワークリソースである。プロキシサーバ５３０は、これらの回答に基づいてＩＰアドレスのリストを並べ替え、フィルタリングし、減少させて、１つの最適なＩＰアドレスを判断する。回答はクライアントにマッピングされ、修正されたＤＮＳ応答メッセージ５４６がクライアント３２０に送信される。クライアント３２０からのＤＮＳクエリがメタデータについての要求を包含していなかった場合、プロキシサーバ５３０はＤＮＳ応答メッセージからメタデータを除去し、ＩＰアドレスのみを有する修正されたＤＮＳ応答メッセージ５４６をクライアントデバイス３２０に送信する。

【0058】

この例では、ＩＰアドレス203.0.113.1を有するクライアントデバイス３２０が、ドメイン“example.com A”へのアクセスを試みる。“example.com A”へのアクセスを要求するＤＮＳクエリ５１２が、プロキシサーバ５３０に送信される。ＤＮＳクエリ５１２はメタデータについての要求を含んでいないため、すなわち、ＤＮＳクエリはＤＮＳＳＥＣレコードについての要求を含んでいないため、クエリ５１２は５１４でＤＮＳＳＥＣ ＤＯフラグを設定することによって更新される。更新された要求５１６が、権威ＤＮＳサーバ５１０に送信される。第１のシナリオでは、権威ＤＮＳサーバ５１０が“example.com”についてのメタデータを含んでいないと仮定して、権威ＤＮＳサーバ５１０は、ドメインに対応するＣＤＮのＩＰアドレス（たとえばexample.com A 192.0.2.1）を有するプログラムなし応答５１８を返す。プログラムなし応答５１８はクライアントにマッピングされ、ＩＰアドレス（example.com A 192.0.2.1）５２４はクライアントに送信される。

【0059】

第２のシナリオでは、権威ＤＮＳサーバ５１０がメタデータを含むと仮定して、権威ＤＮＳサーバ５１０は、ＤＮＳＳＥＣレコードに格納されたＲＲＳＩＧ５２６ｂをプロキシサーバ５３０に提供する。プロキシサーバ５３０は、ＲＲＳＩＧに含まれる"BuildResponse"関数を実行する。"BuildResponse"関数は、ドメインについてのダイナミックステアリングポリシーを格納するために１人以上の顧客によってポリシーマスタに追加された規則関数である。この例では、"BuildResponse"関数は、地理的位置データ（ジオデータ）および待ち時間についての引数を含む。５３４で、プロキシサーバ５３０は、ルックアップ要求５２８をサブネットに送信することによって、クライアント３２０についてのジオデータをルックアップする。サブネットは５３２で、クライアントについてのジオデータ（dyngeo=UK）を返す。プロキシサーバ５３０はジオデータを分析して、ＲＲＳＩＧにおけるジオデータがクライアントジオデータと整合するかどうかを判断する。プロキシサーバ５３０は次に、待ち時間ルックアップ要求５３６をリンクデータ５８０に送信することによって、ＲＲＳＩＧにおいて列挙されたコンテンツ配信ネットワーク（ＣＤＮ）（[0:cdnl, 1:cdn2]）についてのパフォーマンスデータをルックアップする。リンクデータ５８０は、cdn1およびcdn2についての待ち時間を返す。この例では、cdn1についての待ち時間はcdn1について１８０ミリ秒、cdn2についての待ち時間は１４２ミリ秒である。５４２でパフォーマンスフィルタ関数を適用することにより、プロキシサーバ５３０は長い待ち時間レコードを取り除き、それによって回答をcdn2に減少させる。５４４で、プロキシサーバ５３０は応答をクライアントにマッピングし、次に、cdn2のＩＰアドレス（example.com a 198.51.100.1）を含むＤＮＳ応答メッセージ５４６をクライアント３２０に送信する。

【0060】

正規名（ＣＮＡＭＥ）レコードを使用するインテリジェントなデータなしＤＮＳ転送
先進的ＤＮＳサービスにはまた、権威ＤＮＳサーバからの正規名（Canonical Name：ＣＮＡＭＥ）応答のターゲット名における命令を探すプロキシサーバも提供され得る。当業者であれば理解するように、ＣＮＡＭＥレコードは、あるドメイン名が、別のドメイン名、すなわち「正規」ドメイン用のエイリアスであるということを特定する。正規ドメインは、サブドメイン、ＩＰアドレスなどを含む、別のドメインについてのすべての情報を定義する。

【0061】

結論
さまざまな本発明の実施形態がここに説明され例示されてきたが、当業者であれば、ここに説明された機能を行なうための、ならびに／もしくは、結果および／または利点の１つ以上を得るためのさまざまな他の手段および／または構造を容易に思い描くであろう。また、そのような変形および／または修正の各々は、ここに説明された本発明の実施形態の範囲内にあると考えられる。より一般的には、ここに説明されたすべてのパラメータ、寸法、材料、および構成は例示的であるよう意図されていること、ならびに、実際のパラメータ、寸法、材料、および／または構成は本発明の教示が用いられる特定の用途に依存するであろうということを、当業者であれば容易に理解するであろう。当業者であれば、ここに説明された具体的な本発明の実施形態の多くの均等物を認識し、または日常の実験のみを用いて確かめることができるであろう。したがって、前述の実施形態は単なる例として提示されていること、ならびに、添付された請求項およびその均等物の範囲内で、本発明の実施形態は、具体的に説明され請求されたもの以外の態様で実践され得ることが理解されるべきである。本開示の発明の実施形態は、ここに説明された個々の特徴、システム、物品、材料、キット、および／または方法に向けられている。加えて、２つ以上のそのような特徴、システム、物品、材料、キット、および／または方法の任意の組合せは、そのような特徴、システム、物品、材料、キット、および／または方法が互いに矛盾しない場合、本開示の発明の範囲内に含まれる。

【0062】

上述の実施形態は、多くのやり方のうちのいずれでも実現され得る。たとえば、ここに開示された技術を設計し構築する実施形態は、ハードウェア、ソフトウェア、またはそれらの組合せを使用して実現されてもよい。ソフトウェアで実現される場合、ソフトウェアコードは、単一のコンピュータにおいて提供されようと、複数のコンピュータ中に分散されようと、任意の好適なプロセッサまたはプロセッサの集合上で実行され得る。

【0063】

また、コンピュータは、ラックマウント型コンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、またはタブレットコンピュータといった多くの形態のうちのいずれで具体化されてもよい、ということが理解されるべきである。加えて、コンピュータは、携帯情報端末（ＰＤＡ）、スマートフォン、もしくは任意の他の好適な携帯または固定電子デバイスを含む、コンピュータとは通常見なされないものの好適な処理能力を有するデバイスに埋込まれてもよい。

【0064】

また、コンピュータは、１つ以上の入力および出力デバイスを有していてもよい。これらのデバイスはとりわけ、ユーザインターフェイスを提示するために使用され得る。ユーザインターフェイスを提供するために使用され得る出力デバイスの例は、出力の視覚表現のためのプリンタまたはディスプレイスクリーンと、出力の可聴表現のためのスピーカまたは他の音声生成デバイスとを含む。ユーザインターフェイスのために使用され得る入力デバイスの例は、キーボードと、マウス、タッチパッド、およびデジタル化タブレットなどのポインティングデバイスとを含む。別の例として、コンピュータは、音声認識を通して、または他の可聴フォーマットで入力情報を受信してもよい。

【0065】

そのようなコンピュータは、ローカルエリアネットワーク、またはワイドエリアネットワーク、たとえば企業ネットワーク、インテリジェントネットワーク（intelligent network：ＩＮ）、またはインターネットを含む１つ以上のネットワークによって、任意の好適な形態で相互接続されてもよい。そのようなネットワークは、任意の好適な技術に基づいていてもよく、任意の好適なプロトコルに従って動作してもよく、無線ネットワーク、有線ネットワーク、または光ファイバーネットワークを含んでいてもよい。

【0066】

ここに概説された。（たとえば上に開示された技術を設計し構築する）さまざまな方法またはプロセスは、さまざまなオペレーティングシステムまたはプラットフォームのうちのいずれか１つを採用する１つ以上のプロセッサ上で実行可能なソフトウェアとして符号化されてもよい。加えて、そのようなソフトウェアは、数々の好適なプログラミング言語および／またはプログラミングツールまたはスクリプト作成ツールのうちのいずれかを使用して書かれてもよく、フレームワークまたは仮想マシン上で実行される実行可能な機械語コードまたは中間コードとしてコンパイルされてもよい。

【0067】

この点で、さまざまな本発明の概念は、１つ以上のコンピュータまたは他のプロセッサ上で実行されると上述の本発明のさまざまな実施形態を実現する方法を行なう１つ以上のプログラムを用いて符号化されたコンピュータ読取可能記憶媒体（または複数のコンピュータ読取可能記憶媒体）（たとえば、コンピュータメモリ、１つ以上のフロッピー（登録商標）ディスク、コンパクトディスク、光ディスク、磁気テープ、フラッシュメモリ、フィールドプログラマブルゲートアレイまたは他の半導体装置における回路構成、もしくは他の非一時的媒体または有形コンピュータ記憶媒体）として具現されてもよい。コンピュータ読取可能媒体は、そこに格納されたプログラムが、上述のような本発明のさまざまな局面を実現するために１つ以上の異なるコンピュータまたは他のプロセッサにロードされ得るように、運搬可能であってもよい。

【0068】

「プログラム」または「ソフトウェア」という用語は、上述のような実施形態のさまざまな局面を実現するようにコンピュータまたは他のプロセッサをプログラムするために採用され得る任意のタイプのコンピュータコード、またはコンピュータ実行可能命令の集合を指すよう、包括的な意味でここに使用される。加えて、一局面によれば、実行されると本発明の方法を行なう１つ以上のコンピュータプログラムは、本発明のさまざまな局面を実現するために、単一のコンピュータまたはプロセッサ上に存在する必要はなく、数々の異なるコンピュータまたはプロセッサ中にモジュール式に分散されてもよい、ということが理解されるべきである。

【0069】

コンピュータ実行可能命令は、１つ以上のコンピュータまたは他のデバイスによって実行されるプログラムモジュールといった多くの形態を取ってもよい。一般に、プログラムモジュールは、特定のタスクを行なうかまたは特定の抽象データ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。典型的には、プログラムモジュールの機能性は、さまざまな実施形態において所望されるように組合され、または分散されてもよい。

【0070】

また、データ構造は、任意の好適な形態でコンピュータ読取可能媒体に格納されてもよい。例示を簡潔にするために、データ構造は、データ構造における場所を通して関係付けられたフィールドを有するように示されてもよい。そのような関係は、フィールド間の関係を伝えるコンピュータ読取可能媒体における場所にフィールドのためのストレージを割当てることによって、同様に達成されてもよい。しかしながら、データ要素間の関係を構築するポインタ、タグ、または他のメカニズムを使用することを含む、任意の好適なメカニズムが、データ構造のフィールドにおける情報間の関係を構築するために使用されてもよい。

【0071】

また、さまざまな本発明の概念は１つ以上の方法として具現されてもよく、それらの例が提供されてきた。方法の一部として行なわれる行為は、任意の好適なやり方で順序付けられてもよい。したがって、例示されたものとは異なる順序で行為が行なわれる実施形態が構築されてもよく、それは、例示的な実施形態ではいくつかの行為が連続する行為として示された場合であっても、いくつかの行為を同時に行なうことを含んでいてもよい。

【0072】

ここに定義され使用されるようなすべての定義は、辞書での定義、引用により援用された文書での定義、および／または定義された用語の通常の意味を統括すると理解されるべきである。

【0073】

明細書および請求項でここに使用されるような不定冠詞「ａ」および「ａｎ」は、明らかに逆の指示がない限り、「少なくとも１つ」を意味すると理解されるべきである。

【0074】

明細書および請求項でここに使用されるような「および／または」という句は、そのように等位結合された要素、すなわち、ある場合には接続して存在し、他の場合には分離して存在する要素の「いずれかまたは双方」を意味すると理解されるべきである。「および／または」を用いて列挙された複数の要素は、同じように、すなわち、そのように等位結合された要素のうちの「１つ以上」と解釈されるべきである。「および／または」という句によって具体的に識別された要素以外の他の要素が、具体的に識別されたそれらの要素に関係していようとなかろうと、オプションで存在していてもよい。このため、非限定的な一例として、「Ａおよび／またはＢ」への言及は、「備える」などのオープンエンドの文言とともに使用される場合、一実施形態ではＡのみ（オプションでＢ以外の要素を含む）を指し、別の実施形態ではＢのみ（オプションでＡ以外の要素を含む）を指し、さらに別の実施形態ではＡおよびＢの双方（オプションで他の要素を含む）を指す場合がある。

【0075】

明細書および請求項でここに使用されるように、「または」は、上に定義されたような「および／または」と同じ意味を有すると理解されるべきである。たとえば、リストにおける項目を分ける場合、「または」もしくは「および／または」は包括的である、すなわち、数々の要素、または要素のリストのうちの少なくとも１つだけでなく２つ以上、およびオプションで列挙されていない追加の項目を含む、と解釈されるものとする。「のうちの１つのみ」または「のうちのまさしく１つ」、もしくは、請求項で使用される場合、「からなる」といった、明らかに逆を示す用語だけが、数々の要素、または要素のリストのうちのまさしく１つの要素を含むことを指すであろう。一般に、ここに使用されるような「または」という用語は、「のいずれか」、「のうちの１つ」、「のうちの１つのみ」、または「のうちのまさしく１つ」といった排他性の用語が後にくる場合、排他的代替物（すなわち「一方または他方であるが、双方ではない」）を示すとのみ解釈されるものとする。「主として…からなる」は、請求項で使用される場合、特許法の分野で使用されるようなその通常の意味を有するものとする。

【0076】

明細書および請求項でここに使用されるように、１つ以上の要素のリストに関する「少なくとも１つ」という句は、要素のリストにおける要素のうちのいずれか１つ以上から選択された少なくとも１つの要素を意味するものの、要素のリスト内に具体的に列挙された１つ１つの要素のうちの少なくとも１つを必ずしも含まず、要素のリストにおける要素の任意の組合せを除外しないと理解されるべきである。この定義はまた、「少なくとも１つ」という句が指す要素のリスト内で具体的に識別された要素以外の要素が、具体的に識別されたそれらの要素に関係していようとなかろうと、オプションで存在していてもよい、ということを可能にする。このため、非限定的な一例として、「ＡおよびＢの少なくとも１つ」（もしくは同等に「ＡまたはＢの少なくとも１つ」、もしくは同等に「Ａおよび／またはＢの少なくとも１つ」）は、一実施形態ではＡが少なくとも１つ（オプションで２つ以上を含む）、Ｂは存在しない（およびオプションでＢ以外の要素を含む）ことを指し、別の実施形態ではＢが少なくとも１つ（オプションで２つ以上を含む）、Ａは存在しない（およびオプションでＡ以外の要素を含む）ことを指し、さらに別の実施形態ではＡが少なくとも１つ（オプションで２つ以上を含む）、Ｂが少なくとも１つ（オプションで２つ以上を含む）（およびオプションで他の要素を含む）を指す、などとなっている。

【0077】

請求項および上述の明細書において、「…を備える」、「含む」、「担持する」、「有する」、「包含する」、「伴う」、「保持する」、「から構成される」などの移行句はすべて、オープンエンドである、すなわち、「…を含むもののそれに限定されない」ということを意味すると理解されるべきである。「からなる」および「主として…からなる」という移行句のみが、米国特許庁特許審査便覧の第２１１１．０３節に述べられているように、それぞれクローズドまたはセミクローズドの移行句である。

【図1】

【図2】

【図3】

【図4】

【図5】