ＤＮＳＳＥＣインライン署名
【課題】レジストリで増分的なDNSSEC署名を実行するシステム及び方法を提供する。
【解決手段】レジストリで増分的なDNSSEC署名を実行するシステム及び方法が開示され、電子署名操作がDNS追加、更新、及び／又は削除操作などを含む単一のトランザクションの一部として実行される。例の方法がリクエスタ１００からドメインコマンドを受信するステップを含み、ドメインコマンドがドメインの識別子を含む。受信されたドメインコマンドが、ドメインのためのレジストリによって格納されたデータに関して実行される。ドメインコマンドの実行を含む個別のトランザクションの一部として、レジストリが権威サーバの秘密鍵を使用してドメインのためのDNSSECレコードに署名もする。DNSSECレコードが署名された後、レジストリが別のサーバ（DNSクラウド１４０）へ署名されたDNSSECレコードを増分的に発行する。
【解決手段】レジストリで増分的なDNSSEC署名を実行するシステム及び方法が開示され、電子署名操作がDNS追加、更新、及び／又は削除操作などを含む単一のトランザクションの一部として実行される。例の方法がリクエスタ１００からドメインコマンドを受信するステップを含み、ドメインコマンドがドメインの識別子を含む。受信されたドメインコマンドが、ドメインのためのレジストリによって格納されたデータに関して実行される。ドメインコマンドの実行を含む個別のトランザクションの一部として、レジストリが権威サーバの秘密鍵を使用してドメインのためのDNSSECレコードに署名もする。DNSSECレコードが署名された後、レジストリが別のサーバ（DNSクラウド１４０）へ署名されたDNSSECレコードを増分的に発行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はDNSSECインライン署名に関する。
【背景技術】
【０００２】
DNS（Domain Name System）は、インターネット上でTCP／IP通信を確立するのに必要とされるIP（Internet Protocol）番号へ人間が読むことができるドメイン名を翻訳するインターネット基盤の一部である。即ち、DNSのため、ユーザは、数字のIPアドレス（例えば、123.4.56.78）（インターネット上でコンピュータと通信するソフトウェアによって使用される機械可読アドレスである）より、記憶しやすいドメイン名（例えば、www.en.example.com）を使用してウェブサイト（および、他のリソース）を参照することができる。各ドメイン名が、ドットで分離された一連の文字列（ラベル）によって作成される。ドメイン名の右端のラベルが、「トップレベルドメイン」（TLD）として知られている。よく知られたTLDの例は、「.com」、「.net」、「.org」などである。各TLDは、第２レベルドメイン（TLDの左隣に記載された、例えば、「www.example.com」の「example」）をサポートする。各第２レベルドメインは、第２レベルドメインの左隣に配置された、いくつかの第３レベルドメイン（例えば、「www.en.example.com」の「en」）をサポートすることができる。付加的なレベルのドメインも存在することができる。例えば、付加的なドメインレベルを有するドメインは、「www.landscape.photos.example.com」となる。
【０００３】
単一のIPアドレス（例えば、単一のサーバに割り当てられたもの）が多数のドメイン名をサポートすることができることに注意しなければならない。即ち、異なるドメイン名が同じサーバへ解決する（次いで、リクエストされたドメイン名、及び／又は、付加的な非ドメイン情報に基づき、どのようなコンテンツを提供するかを決定することができる）。これはバーチャルホスティングと称されることがある。
【０００４】
付加的な非ドメイン情報は、ドメイン名を含むＵＲＩ（Uniform Resource Identifier）に含まれる。例えば、「パス」部分は、フォワードスラッシュ（/）で分離された一連のセグメントである。この情報は、ドメイン名の右隣に含まれ（例えば、「www.example.com/blog/today.htm」の「blog」）、かつ、具体的なコンテンツを識別および配信するため、又は、特定のコードを実行するため、サーバ又は他の受信デバイスによって使用される。非ドメイン情報の他の例はクエリーおよびフラグメントを含む（その詳細が当業者によって理解され、かつ本明細書で詳細には述べられない）。この情報の組合せが、同じページの別の部分又は別のウェブページにユーザを移動させるウェブページハイパーリンクに含まれる。
【０００５】
したがって、上記したさまざまな例で分かるように、および、当業者によって十分理解されるように、ドメイン（例えば、第２レベルドメイン「example.com」）が、異なるアドレスおよび他の識別手段を有するさまざまな異なるインターネットアクセス可能な情報を含んでもよい。
【０００６】
ドメイン名の実際の登録が、ドメイン名レジストラ（registrar）と称される企業によって実行される。レジストラがレジストリでドメイン名を登録する。例えば、エンドユーザが、登録のためのドメイン名をレジストラへ提出し、かつ、ドメイン名が解決すべきIPアドレスを提供する。レジストラは、レジストリと通信して、レジストリデータベースレコード（エンドユーザによって提供されたIPアドレスへドメイン名を解決するのに使用される）を作成し、かつ、ドメイン名が登録されたレジストラの識別を示す。レジストリにおけるドメイン名登録の期限切れを除き、一般に、レジストリでドメイン名レコードにおいて指定されたレジストラだけが、ドメイン名についてレジストリデータベース情報を修正又は削除することができる。エンドユーザは、特定のドメイン移行手順に従うことによって、レジストラを切り替えることができる。また、レジストラはホストプロバイダーとして動作し、又は、エンドユーザは別の第３者のドメインホスティングサービスによってホストされたドメインを有してもよい。
【０００７】
ゾーンファイルは、DNSゾーンと呼ばれるDNSの一部を記述するテキストファイルである。ゾーンファイルは、RR（resource records）の形態で体系化され、ドメイン名とIPアドレスと他のリソースとの間のマッピングを定義する情報を含んでいる。ゾーンファイルのフォーマットは基準によって定義され、各ラインが単一のリソースレコードを一般に定義する。ラインは、ドメイン名で始まるが、左がブランクの場合、以前に定義されたドメイン名をデフォルトにする。次のドメイン名は、TTL（time to live）、クラス（ほぼ必ず「internet」のための「IN」であり、めったに含まれていない）、リソースレコードのタイプ（Ａ，ＭＸ，ＳＯＡなど）である（次に、タイプ固有のデータ（例えば、ＡレコードのためのIPｖ４アドレス））。コメントはセミコロンを使用することで含めることができ、かつ、ラインは括弧を使用することで継続することができる。また、ドル記号で始まるキーワードでマークされるファイル指令が存在する。
【０００８】
DNSは、各ドメインに対して権威ネームサーバを指定することによって、ドメイン名の割り当て、および、これらの名前とIPアドレスとのマッピングの責任を分散する。権威ネームサーバはそれらの特定のドメインに対して責任を有するように割り当てられ、かつ、順に、それらのサブドメインに対して他の権威ネームサーバを割り当てることができる。このメカニズムは一般に、継続的に参照および更新される単一の中央レジスタの必要性を回避する助けとなる。DNS解決プロセスのため、ユーザは、リバースルックアッププロセス（それによって、ユーザが所望のドメインに入り、かつ、DNSが適したIP番号をリターンする）によって、所望のドメインへ向かうことができる。DNS解決プロセスの間、所定のドメイン名に対するリクエストは、リゾルバ（例えば、スタブリゾルバ）から適したサーバ（例えば、再帰的リゾルバ）へ送られて、IPアドレスを検索する。効率を改善し、インターネット上のDNSトラフィックを減少させ、かつ、エンドユーザのアプリケーションの性能を向上させるため、DNSは、DNSキャッシュサーバ（問題になっているドメイン名レコードのTTL（time-to-live）によって決定された期間についてDNSクエリー結果を格納する）をサポートする。一般に、そのようなキャッシングDNSサーバ（DNSキャッシュとも称される）も、クエリーされたドメインの権威ネームサーバまでDNSルートで始まる所定の名前を解決することが必要である再帰的アルゴリズムを実施する。一般にインターネットサービスプロバイダー（ＩＳＰ）は、その顧客に対して、再帰的およびキャッシングDNSサーバを提供する。加えて、ホームネットワーキングルータが、DNSキャッシュおよびプロキシを実装して、ローカルネットワークの効率を改善してもよい。
【０００９】
DNSの分散された性質がシステム全体の効率に関して重大な利点を提供するが、それは所定のタイプの機能不良、及び／又は、システムのさまざまなノードでの攻撃に対して、システムを弱くもする。発生する１つの特定の問題はDNSキャッシュポイズニングと称される。DNSキャッシュポイズニングは、権威DNSソースに由来しないDNSネームサーバのキャッシュデータベース内にデータが導入されるときに発生する。これはネームサーバに対する故意の攻撃によって生じ、又は、例えば、ミス設定されたDNSキャッシュ、又は、DNSアプリケーションの不適切なソフトウェア設計の意図的でない結果である。したがって、DNSキャッシュポイズニングは、結果的に、（１）解決リクエスト失敗（例えば、不正確又はミス設定されたIPアドレス情報が提供される）、又は、（２）リクエストしたユーザの解決リクエストの悪意のあるサイト（本物のドメインになりすまし、かつ、情報（例えば、アカウントパスワード）を不法に得るために、又は、リクエストしたユーザに配信される悪意のあるコンテンツ（例えば、コンピュータワーム又はウィルス）を配布するために使用される）への移動を生じる。
【００１０】
DNSSEC（Domain Name System Security Extensions）は、IPネットワークで使用されるようなDNSによって提供される特定の種類の情報をセキュアにするための一連のIETF（Internet Engineering Task Force）仕様書である。DNSSECは、DNS対応のゾーンファイルの署名（DNSデータに対する発信元認証およびデータ完全性を保証する）、および、認証された存在の否定を提供する。一般に、DNSSEC内で提供された回答は電子的に署名され、かつ、電子署名をチェックすることによって、DNSリゾルバは、情報が権威DNSサーバに関する情報に対応するか否かをチェックすることができる。DNSSECは電子署名および認証に対して公開鍵暗号を使用する。DNSKEYレコードが、信頼された第３者である信頼の連鎖（DNSルートゾーンについて１組の検証された公開鍵から始まる）を介して認証される。
【００１１】
DNSSECを実装するため、いくつかの新規のDNSレコードタイプが、DNSSECとともに使用するために作成又は適合された（RRSIG、DNSKEY、DS、NSEC、NSEC３、およびNSEC３ PARAMを含む）。例えば、DNSSECが使用されるとき、DNS検索への各権威回答が、リクエストされたレコードタイプに加えて、RRSIG DNSレコードを含む。RRSIGレコードは、回答のDNSリソースレコードセットの電子署名である。電子署名は、DNSKEYレコードで発見された正しい公開鍵を置くことによって、検証することができる。DSレコードは、信頼の連鎖を使用した検索手順でDNSKEYの認証において使用される。NSECおよびNSEC3レコードは、存在しないDNSレコードに対して認証された存在の否定の応答を提供するのに使用される。
【００１２】
DNSSECの要求は、異なる鍵（DNSKEYレコードの両方に格納され、かつ、信頼アンカーを形成する他のソースから）の使用を含む。例えば、KSK（Key Signing Keys）（DNSKEYレコードに署名するために使用される）およびZSK（Zone Signing Keys）（他のレコードに署名するために使用される）が存在する。ZSKは固有のDNSゾーンの制御および使用下にあるので、それらはより容易かつより頻繁に切り替えることができる。その結果、ZSKは一般にKSKより短く（バイト長に関して）、その上、容認可能なレベルの保護を提供する。
【００１３】
プロトコルはDNSSEC（KSKおよびZSKの使用を含む）の利用に対して開発されているが、レジストラおよびレジストリレベルで、大規模な使用に対して対処及び／又は最適化されていないDNSSEC使用可能なドメインを運用するさまざまな態様が存在する。例えば、短い期間に多数の署名を処理する能力が、ゾーンへの変更に基づいてゾーン全体に署名する一般的な方法に限定されている。したがって、DNSSEC管理に関する運用およびDNSSECレコードに必要な署名機能の機能性及び／又は効率性をさらに向上させる継続的な要求が存在している。
【発明の概要】
【課題を解決するための手段】
【００１４】
最新のDNSSEC技術が、DNSSECデータの「分散」署名、即ち、さまざまなユーザ、DNSプロバイダーなどに分散される署名技術を含んでいる。現在、DNSSECを採用することを望むユーザには以下の基本オプションがある。
１．１組のソフトウェア鍵又はハードウェア鍵と一緒に、第３者およびオープンリソースソフトウェアの組合せを使用した自らのDNSSECソリューションを構築する。
２．Secure64 DNS Signer、BlueCat Networks、Xelerance DNSX Secure、Singer、およびInfobloxのようなDNSSEC鍵管理および署名アプライアンスを使用する。そのようなアプライアンスは、鍵管理およびゾーン署名のさまざまな態様を提供するが、クライアントサイトにハードウェアを導入する必要がある。DNSSEC鍵管理および署名アプライアンスが、ユーザサイトでのハードウェアの実装を必要とし、鍵マテリアルのより詳細な管理を必要とし、かつ、１人より多くのユーザをサポートしないことに注意しなければならない。
３．DNSSECをサポートするように更新された管理DNSソリューションを使用する。管理DNSプロバイダーは、ゾーン管理およびゾーン発行機構を含む。DNSSECを使用可能なため、クライアントは管理DNSゾーンに対してDNSSECを「ターンオンする」ことができるが、ユーザは管理DNSプロバイダーへユーザのDNSホスティングを移行又は外部委託することを要求される。
【００１５】
また、DNSSECにサポートを追加するドメインレジストリに対する１つのアプローチは、DNSSEC DS（Delegation signer）情報を許可し、未署名のゾーンを生成し、次いで、発行のためゾーン全体に署名することである。しかし、膨大なレジストリ（例えば、.comおよび.netレジストリ）へのDNSSECの導入にともなって、DNSSECデータに対するさまざまな分散署名技術および他の署名技術における効率の悪さ（特に、大規模なゾーンに関して）が、遅延および解決失敗を含む解決に関する潜在的課題をもたらす。そのような課題が、電子商取引および他の高トラフィックサイトに大きな弊害をもたらす。本発明は、さまざまな増分署名技術（incremental signing technique）を通じて、権威ソース（例えば、ドメインに関与するレジストリ）でのDNSSEC使用可能ゾーンの効率的な署名において利点を提供する。例えば、レジストリ（又は、DNSデータにおける特定の変更に気付いている、又は、DNSデータにおける特定の変更に対して注意を喚起される他のエンティティ）の観点からアプローチしたとき、DNSデータの部分（追加、変更、及び／又は、削除操作などの対象である）が識別される（ゾーン全体に再署名せず、署名、さまざまにコミット、および報告される）。態様では、DNS更新操作および影響されるDNSSECレコードの署名が、本明細書では「インライン署名（inline signing）」と称される単一のトランザクション（例えば、極小の、一貫した、分離された、かつ、耐久性のある仕事のユニット）態様の一部として実行される。
【００１６】
態様では、DNSSECインライン署名が、ドメインコマンドでDNSSEC署名インラインを実施することを含んでいる。例えば、責任のあるレジストリが、DNSSEC DS情報を許可し、かつ、同じトランザクション内で署名されたDNSSECレコードを作成し、その後、１つの権威ソースからDNSの外部へ署名された情報を増分的に発行する。そのような権威署名は、他の分散署名技術に対して利点を提供するが、一般に、本発明のさらなる態様によって対処される拡張性において課題を呈する。本発明の態様によれば、レジストリデータベースが、DNSSECインライン署名を介して、DNSSECゾーンで発行されたレコードのすべてに対して、単一の権威ソースとして動作してもよい。
【００１７】
本明細書にさらに開示されるように、レジストリ（又は、DNSデータの特定の変更に対して気が付いているか、又は、注意喚起される他のエンティティ）における増分DNSSEC署名を実施するシステムおよび方法は、DNS追加、更新、及び／又は、削除操作などを含む単一のトランザクションの一部として、電子署名操作を実施することを含んでいる。例示的な方法は、リクエスタからドメインコマンドを受信するステップを含み、ドメインコマンドはドメインの識別子を含んでいる。受信されたドメインコマンドは、ドメインに対するレジストリによって格納されたデータに関して実行される。DNSSECデータ変更も受信されたドメインコマンドに基づき識別される。また、ドメインコマンドの実行を含む個別のトランザクションの一部として、レジストリが、秘密鍵（例えば、権威サーバの秘密鍵）を使用して、ドメインに対するDNSSECレコードに署名する。態様は、レジストリでトランザクションをコミットするステップを具備する。本明細書で使用されるように、トランザクションコミットが、トランザクションの範囲内で、すべてのデータ操作に適用し、かつ、データベースへ結果を保存する操作として、理解される。態様は、DNS基盤へコミットされたトランザクションを伝えるステップを具備する。態様では、例えば、レジストリが別のサーバへ署名されたDNSSECレコードを増分的に発行する。
【００１８】
本発明の態様によれば、態様は、リクエスタからドメインコマンドを受信することを含むレジストリでDNSSEC署名を実行するためのシステムおよび方法を含んでいる。ドメインコマンドは、ドメインの識別子、および、例えば、ドメインに関する追加、修正、及び／又は、削除コマンドのうちの少なくとも１つを具備している。態様は、ドメインについてレジストリによって格納されたデータに関して、受信されるドメインコマンドを実行するステップを具備している。ドメインコマンドの実行を含む個別のトランザクションの一部として、ドメインに対するDNSSECレコードが電子署名される（例えば、権威サーバの秘密鍵を使用して）。署名されたDNSSECレコードが別のサーバ（例えば、DNSサーバ）へ増分的に発行される。
【００１９】
態様は、ドメインコマンドが１又は複数のDNSSEC DS（Delegation Signer）要素を含むことを含む。態様では、ドメインコマンドが、１又は複数の関係するDNSSEC DS（Delegation Signer）レコードを生成する１又は複数のDNSKEY要素を含む。
【００２０】
態様では、例えば、リクエスタは、レジストラ、DNSサービスプロバイダー、又は、登録者（registrant）である。態様では、ドメインは、レジストリのトップレベルドメインの下の第２（又は、より高い）レベルドメインである。
【００２１】
態様では、方法が、レジストリの権威サーバによって、複数のレジストラからドメインに対して実行される。態様では、DNSレコードの署名が、レジストリの権威サーバによって、複数のレジストラから少なくとも２つのドメインに対して実行される。
【００２２】
態様では、DNSレコードの署名が、レジストリに対して複数の署名サーバによって実行される。
【００２３】
また、態様は、追加、更新、削除コマンドのうちの少なくとも１つに基づき、NSEC又はNSEC３連鎖へ変更をコミットするステップを具備している。
【００２４】
本発明のさらなる態様によれば、態様が、レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つの第１コマンドをリクエスタから受信するステップと、レジストリデータベースに格納されたデータを追加、更新、及び／又は削除する前記第１コマンドからの命令を実行するステップとを含む、レジストリでDNSSEC署名を実行する方法およびシステムを具備している。態様では、コマンドの実行は、電子署名データを適用するステップを含まない。態様では、レジストリ（又は、他のサービス）が、命令が実行されたことをリクエスタへ報告する。第１コマンドからの命令の実行から離れ（実行の報告の後であってもよい）、電子署名が、追加、更新、及び／又は、削除変更に基づいて生成され、かつ、電子署名がレジストリレゾリューションデータベースへコミットされる。また、態様は、DNSへ（ドメインコマンドに基づき）非DNSSEC変更、及び／又は、DNSSEC変更を発行するステップを具備している。態様では、非DNSSEC変更およびDNSSEC変更が、DNSへ非同期的にシステムによって発行される。
【００２５】
本発明のさらなる態様によれば、態様は、レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つの第１コマンドをリクエスタから受信するステップと、レジストリデータベースに格納されたデータを追加、更新、及び／又は、削除する前記第１コマンドからの命令を実行するステップと（実行は電子署名データを適用するステップを含まない）、第１コマンドに関する保留中のDNSSEC変更を示すデータベースエントリを生成するステップと、前記追加、更新、及び／又は、削除変更に基づき、電子署名を生成するステップと、データベースエントリをクリアするステップとを含む、レジストリでDNSSEC署名を実行するためのシステムおよび方法を具備している。また、態様は、DNSへデータベースエントリを発行するステップを具備している。
【００２６】
追加的な特徴、利点、および本発明の態様は、以下の詳細な説明、図面、および請求項の検討から、説明され、又は明らかである。さらに、上記した本発明の概要および以下の詳細な説明の両方が、例示であり、かつ、本発明の特許請求の範囲を限定することなくさらなる説明を提供することを意図したものであることを理解しなければならない。しかし、詳細な説明および特定の例は、単に本発明の好ましい実施例を示したものである。本発明の真の趣旨および範囲から逸脱することなく、多様な変形例および改良例が詳細な説明から当業者には明らかとなる。
【００２７】
本発明のさらなる理解を提供するよう含まれた添付の図面が、組み込まれ、本明細書の一部を構成し、本発明の実施例を図示し、詳細な説明とともに、本発明の原理を説明するのに用いられる。本発明の基本的理解および実施される多様な方法に必要であるよりもさらに詳細に本発明の構造的詳細を示していない。
【図面の簡単な説明】
【００２８】
【図１】本発明の実施例のインライン署名構成の関係図である。
【図２】本発明の実施例１のDNSSECデータに署名するステップの例のプロセスフローである。
【図３】本発明の実施例のDNSSEC使用可能署名システムのさらなる詳細図である。
【図４】本発明の実施例のDNSSEC使用可能署名システムのさらなる詳細図である。
【図５】本発明のさらなる実施例のダウンストリームレゾリューションデータベース署名構成の関係図である。
【図６】本発明のさらなる実施例のダウンストリームレゾリューションデータベース署名プロセスの例のプロセスフローである。
【図７】本発明のさらなる実施例のルックアサイドデータベース署名構成の関係図である。
【図８】本発明のさらなる実施例のルックアサイドデータベース署名プロセスの例のプロセスフローである。
【図９】本発明の実施例で使用される例のコンピュータネットワークアーキテクチャの図である。
【発明を実施するための形態】
【００２９】
本発明が本明細書に開示された特定の方法、プロトコルなどに限定されないことが理解される（当業者に理解されるようにそれらが多様に変化するため）。また、本明細書に使用された用語が特定の実施例だけを説明する目的に使用され、本発明の範囲を限定することを意図しないことを理解しなければならない。また、本明細書および特許請求の範囲に使用されるとき、単数形態”a”、“an”および“the”は、コンテキストが明確に指定しない限り、複数の言及を含むことに注意しなければならない。したがって、例えば、「サーバ」への言及は、１又は複数のサーバ、および、当業者に既知のその均等物への言及である。
【００３０】
他に定義されない限り、本明細書で使用される技術用語は、本発明が関わる当業者に一般に理解されるものと同じ意味を有する。本発明の実施例、および、多様な特徴、および、それについての利点の詳細は、添付の図面に説明及び／又は図示され、かつ、以下の説明に詳述された非限定的な実施例および実例を参照してさらに完全に説明される。図面に示された特徴は必ずしも一定の縮尺で描かれておらず、かつ、仮に本明細書に明確に述べられていなくても、１つの実施例の特徴が、当業者が理解するように他の実施例で利用されることに注意しなければならない。周知のコンポーネントおよび処理技術の記載は、本発明の実施例を不必要に分かりにくくしないように省略される。本明細書に使用された例は、単に、本発明が実施される方法の理解を助けること、および、当業者が本発明の態様を実施することをさらに可能にすることを目的としている。したがって、本明細書の実施例および実例は、本発明の範囲を限定するものとして解釈されるべきでなく、特許請求の範囲および適用される法によってのみ定義される。さらに、類似の参照数字が図面のいくつかの表示にわたって同様の部分を参照することに注意しなければならない。
【００３１】
本明細書で使用されるとき、他に限定されない限り、レジストラ（registrar）は、ドメイン名レジストリと相互作用し、かつ、登録者(registrant)がドメイン名リソースを作成および更新することを可能にするエンティティ又は組織であると理解される。
【００３２】
本明細書で使用されるとき、他に限定されない限り、登録者は、ドメイン名リソースを作成および更新するレジストラと相互作用する人又は組織であると理解される。
【００３３】
本明細書で使用されるとき、他に限定されない限り、DNSホスティングプロバイダーは、DNSプロビジョニングおよびそのコンテンツについて解決能力を提供する、登録者の代わりに、そのサーバにコンテンツをホストするエンティティ又は組織であると理解される（例えば、IPアドレスを割り当て、それが管理するそれらのIPアドレスへドメイン名を解決することができるネームサーバを運営する）。
【００３４】
本明細書で使用されるとき、他に限定されない限り、データベースは、例えば、コンピュータシステムによる使用のための離散及び／又は関係情報について格納およびアクセスするようにフォーマットされた多様な電子記憶装置アプリケーション（例えば、ローカル及び／又は分散ファイルシステム、データファイル、データウェアハウス、構造化データベース、リレーショナルデータベース、ローカル及び／又は分散データベース、ハイブリッドデータベース、データベース内の離散データ構造及び／又はスキーマなど）を含むことを広く理解しなければならない。
【００３５】
本発明の実施例によれば、DNSホスティング移行をともなうドメイン−スポンサーシップ移行をサポートするためのシステムおよび方法が、例えば、レジストラの間のドメイン移行（「ドメイン−スポンサーシップ移行」と称される）と、DNSホスティングにおける移行（「DNSホスティング移行」と称される）とを含んでもよい。ドメイン移行の場合、多くのレジストラがDNSホスティングプロバイダーであるので、両方の移行が一般に含まれ、かつ、登録者が、多くの場合、それらのレジストラによって提供されるDNSホスティングを利用する。以下の例は、同じレジストラの間のDNSホスティング移行を含むレジストラの間のドメイン−スポンサーシップ移行に含まれたステップを示している。
【００３６】
本発明の実施例は、大規模なDNSSECプロバイダー（例えば、レジストリ）が、効果的かつ一貫した方法で、多数のDNS変更（DNSSEC署名データを含む）を処理することを可能にする、多様なインライン署名技術を提供する。
【００３７】
ゾーン署名の概要
【００３８】
上記したように、DNSSECは、キャッシュポイズニング、および、一連の他のDNS脆弱性（例えば、介入者攻撃、および、権威サーバにおける不正データ修正）に対応することを意図したものである。その主な目的は、DNSデータについて発信元認証、および、完全性保護を提供することである。ＰＫＩ（Public Key Infrastructure）は、公開鍵配布の手段として使用してもよい。DNSSECは、DNSデータについて検証メカニズムを提供し、暗号化メカニズムではない。DNSSECにより、セキュリティを意識したリゾルバは、受信されたゾーンデータが秘密鍵を保持するゾーンの管理者によって署名されていることを検証することができる。
【００３９】
DNSKEYリソースレコード
【００４０】
ゾーンは、１又は複数の鍵ペアを有し、それぞれが秘密鍵と公開鍵とを含んでいる。秘密鍵は、ドメイン名データベースにセキュアに格納され、かつ、ゾーンデータに署名するのに使用される。公開鍵は、データベースに格納され、また、DNSKEYリソースレコードとして署名済みゾーンデータに格納される。公開鍵はゾーンデータを検証するのに使用される。DNSKEYレコードは、一般に以下のデータ要素を有する。
フラグ：「ゾーン鍵」および「セキュアエントリポイント」
プロトコル：３の固定値（後方互換性のため）
アルゴリズム：公開鍵の暗号化アルゴリズム
公開鍵：公開鍵データ
【００４１】
DNSKEY RR（Resource Record）は、ZSK（Zone Signing Key)又はKSK(Key Signing Key)であってもよい。KSK(Key Signing Key)はＳＥＰフラグセットを有し、したがって、それらはDNSKEY RRセットのZSKとは区別される。KSK(Key Signing Key)は、他のDNSKEYリソースレコードに署名するのに使用され、かつ、検証される必要のあるデータに対する権限の連鎖を構築するのに使用される。
【００４２】
RRSIGリソースレコード
【００４３】
RRSIGリソースレコードは、リソースレコードセット（RRセット（同じ名前、クラス、およびタイプを有する１又は複数のDNSレコード））のDNSSEC署名を保持する。DNSSEC使用可能リゾルバが、DNSKEYレコードに格納された公開鍵で、署名を検証することができる。RRSIGレコードは以下のデータ要素を有する。
カバーされるタイプ：この署名がカバーするDNSレコードタイプ
アルゴリズム：署名を作成するのに使用される暗号化アルゴリズム
ラベル：オリジナルのRRSIGレコード名のラベルの番号（ワイルドカードを検証するのに使用される）
オリジナルのTTL：カバーされたレコードセットのTTL値
署名満了：署名が満了するとき
署名開始：署名が作成されたとき
鍵タグ：この署名を検証するのに使用されるDNSKEYレコードを迅速に識別するのに役立つ短い数字の値
署名者の名前：この署名を検証するのに使用されるDNSKEYレコードの名前
署名：暗号化された署名
DNSKEY RRは、アクティブな鍵署名鍵によって署名される。他のRRセットはアクティブなゾーン署名鍵だけによって署名される。
【００４４】
NSECリソースレコード
【００４５】
NSECリソースレコードが２つの別の物をリスト化する（権威データ又は委任ポイントNS RRセットを含む次の所有者の名前（ゾーンの正規順序での）、および、NSEC RRの所有者名に存在するRRタイプのセット）（RFC3845）。ゾーンのNSEC RRの完全なセットが、どの権威RRセットがゾーンに存在し、また、ゾーンの権威所有者名の連鎖を形成するかを示す。これらレコードが、リゾルバによって使用されて、DNSSEC検証の一部として、レコード名およびタイプの非存在を検証することができる。NSECレコードは以下のデータ要素を有する。
次のドメイン名：ゾーンの次のレコード名（DNSSEC並べ替え順序）
レコードタイプ：このNSECレコードの名前について存在するDNSレコードタイプ
【００４６】
NSEC３リソースレコード
【００４７】
NSEC３ RR（Resource Record）が、DNSリソースレコードセットに対して認証された存在の否定を提供する。NSEC３ RRは、NSEC RRと同じ機能を有する（NSEC３が暗号化的にハッシュ化されたレコード名を使用して、ゾーンのレコード名の列挙をしないことを除く）。NSEC３レコードは、ゾーンの次のレコード名へリンクし（ハッシュ化された名前の並べ替え順序で）、かつ、NSEC３レコードの自らの名前の第１ラベルでのハッシュ値によってカバーされた名前のために存在するレコードタイプをリスト化する。これらレコードはリゾルバによって使用されて、DNSSEC検証の一部として、レコード名およびタイプの非存在を検証することができる。NSEC３レコードは以下のデータ要素を有する。
ハッシュアルゴリズム：使用される暗号化ハッシュアルゴリズム
フラグ：「Optアウト」（委任が署名されるか否かを示す）
繰り返し：ハッシュアルゴリズムが適用される回数
ソルト：ハッシュ計算についてのソルト値（salt value）
次のハッシュ化された所有者名：ゾーンでの次のレコードの名前（ハッシュ化された名前並べ替え順序で）
レコードタイプ：NSEC３レコードの自らの名前の第１ラベルにおいてハッシュ値によってカバーされる名前に対して存在するレコードタイプ
【００４８】
例のインライン署名構成の実施例が図１に示されている。図１に示すように、リクエスタ１００（例えば、登録者、レジストラ、又は、DNSプロバイダー）が、レジストリプロビジョニングシステム１１０と通信してもよい。リクエスタ１００が、既存又は新規のドメインに関するコマンドを通信してもよい。例えば、リクエスタ１００が、レジストリによって管理されるTLD（例えば、.com）下のドメインについて、レジストリ（例えば、DNSデータ）によって管理されるDNSデータを変更するコマンドを通信してもよい。レジストリプロビジョニングシステム１１０が、多様な方法（例えば、変更コマンドを実行する（例えば、追加、修正、又は削除コマンド）、DNSSECデータ変更を識別する、適切な鍵を識別する、電子署名を適用する、レジストリデータベース１２０へDNSおよびDNSSEC変更を保存させるなど、を含む）でリクエスタ１００からのドメインコマンドを処理してもよい。
【００４９】
実施例では、レジストリデータベース１２０へレジストリプロビジョニングシステム１１０によって提供されるデータが、ドメインのためのDNS情報、および、署名されたDNSSECデータを含んでもよい。実施例では、DNS変更およびDNSSEC変更を、単一のトランザクション内で実行してもよい。いったんドメインのためのDNS情報、および、署名されたDNSSECデータがレジストリデータベース１２０へ保存されると、トランザクションがコミットされる。トランザクションコミットの後、ドメインのためのDNS情報、および、署名されたDNSSECデータが、より広いDNSクラウド１４０（他の権威サーバ、再帰的DNSサーバなどを含む）へ伝えられる。
【００５０】
例のDNSSEC署名サービスのさらに詳細が図２および図３に示されている。図１〜３に示された署名サービス構成が本発明の実践的側面において使用されるが、本明細書に開示されるインライン署名技術が、多様な他の構成を用いた多数の異なる署名サービスに適用されることに注意しなければならない。図２に示すように、レジストリ（又は、DNSSECサービスプロバイダー）が、いくつもの署名サーバ３４２，３４６を備えてもよい。例えば、複数の署名サーバが図１に示されたプロビジョニングシステム１１０を含んでもよい。署名サーバ３４２，３４６が、適切な電子署名鍵を含む実際の電子署名機能を含むＨＳＭ（Hardware Security Module）３４４，３４８（及び／又は、ソフトウェア）をそれぞれ含んでもよい。署名サーバ３４２，３４６が、多様なアプリケーション、サービス、およびツール３１０，３２０，３３０と通信してもよい（かつ、例えば、署名されたDNSデータおよび未署名のDNSデータを交換してもよい）。各ＣＡＳ３１０、ＮＣＣプラグインビジネスサービス３２０、およびバッチ／ツール３３０コンポーネントが、署名サーバ（好ましくは、一連のそのようなサーバ）への接続を有する。署名サーバ３４２，３４６が、データベース３５０へ署名されたDNSデータを保存してもよい。アプリケーション、署名サーバ、ＨＳＭ、およびデータベースの間の例のデータフローの追加的な詳細が図３に示されている。
【００５１】
図３に示すように、例えば、クライアント５１０が、図１に示されたプロビジョニングシステム１１０のフロントエンドサービスを表す（署名サーバ５１２によって署名される必要があるDNSSECデータを識別するように構成される）。署名されるDNSSECデータが、解析され又はドメインコマンドに基づき別の方法で識別され、リンク５４１で示すように、署名サーバ５１２へ提供される。情報（例えば、バイト、鍵タイプ（ZSK、KSK）、およびTLD）を含んでもよい。署名サーバ５１２が、送信５４１から適した鍵情報、及び／又は、ＨＳＭを識別してもよく、かつ、リンク５４２で示されるように、適したＨＳＭ５１４へ未署名のデータを渡してもよい。これは、例えば、バイト、鍵エイリアス、および署名アルゴリズムを有する署名コマンドを含んでもよい。
【００５２】
署名サーバ５１２が、ＨＳＭ５１４へデータを送信するときに権威データ（使用する鍵エイリアス）についてデータベース５２０を周期的にチェックするように構成される。ＨＳＭ５１４は、初期時間でTLDごとに多数の鍵をロードし（一部はZSKであり、一部はKSKである）、かつ、各鍵がエイリアス（鍵エイリアス）によってＨＳＭ５１４に知られている。クライアント５１０が、使用する２種類の鍵（ZSK又はKSK）のどれかおよびTLDを署名サーバ５１２に教えるように構成され、かつ、署名サーバ５１２が、署名のためＨＳＭと通信するとき、その種類の鍵について現在の鍵エイリアス名を識別するように構成される。また、署名サーバ５１２が、現在の鍵エイリアスについてデータベース５２０を再チェックするようにされる。このコマンドは、例えば、ＪＭＸ管理インターフェースを介して、署名サーバ５１２へ発行される。
【００５３】
ＨＳＭ５１４は、適した鍵でDNSSECデータに署名し、かつ、リンク５４３で示されるように、署名サーバ５１２へ署名されたデータを戻す。署名サーバは、リンク５４４で示されるように、クライアント５１０へ署名されたDNSSECデータ（又は、トランザクションコミット情報などの他のデータ）を戻す。
【００５４】
本発明の実施例に従って処理される関係したドメインコマンド操作の例が以下に開示される。
【００５５】
DNSSECデータをともなうドメイン作成
【００５６】
ユーザがDNSSECデータを伝えたドメイン作成の間（これらのデータが、提出される各DS（Delegation Signer）レコードに必要である４フィールドである）、レジストリが、以下の決定を実行し、かつ、以下のアクションを行う。
DSレコード（複数可）のための電子署名を生成および格納する。
ドメインがゾーンにおける発行にふさわしいか否かを決定する。
その場合、
そのNSEC３レコードを作成する。
NSEC３レコードに署名する。
NSEC３連鎖（データベースに格納されたリンクされたリストに、類似した）におけるその正しい位置を識別し、かつ、連鎖への最小の変更でその新規NSEC３レコードを挿入する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数（１である）を固定するステップと、挿入を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を具備してもよい。
【００５７】
新規DSデータをともなうドメイン更新
【００５８】
新規DSデータをともなうドメイン更新の間、レジストラも、ドメインへの他の変更を含んでもよい。これら他の変更が、ドメインのゾーン状態を変更する。したがって、レジストリは、
DSレコード（複数可）のための電子署名を生成および格納する。
ドメインがゾーンでの発行にふさわしいか否か、および、それがすでにゾーンに存在するか否かを決定する。
ドメインがゾーンに存在せず、そして、現在ゾーンに存在する場合、
そのNSEC３レコードを作成する。
NSEC３レコードに署名する。
NSEC３レコードのための電子署名を格納する。
NSEC３連鎖におけるその正しい位置を識別し、かつ、連鎖への他の更新に関する最小の「ブロックキング」でその新規NSEC３レコードを挿入する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数を固定するステップと、挿入を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を具備してもよい。
ドメインがゾーンに存在せず、そして、現在、ゾーンに存在すべきではない場合、
NSEC３連鎖におけるドメインのレコードを位置付ける。
連鎖への他の変更に関する最小の「ブロッキング」でそのNSEC３レコードを除外する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数を固定するステップと、レコード削除を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を具備してもよい。
【００５９】
DSデータの削除をともなうドメイン更新
【００６０】
DSデータの削除をともなうドメイン更新の間、レジストラもドメインへの他の変更を含んでもよい。これら他の変更が、ドメインのゾーン状態を変更してもよい（例えば、削除の後、ドメインに残りのDSレコードがない場合、ドメインはもはやゾーンにふさわしくない）。したがって、レジストリは、
ドメインが残りのDSレコードを有するか否かを決定する。
そうでない場合、レジストリが、NSEC３連鎖からドメインを削除してもよい（ステップについて以下を参照）。また、レジストリが、削除されるDSデータのための既存の電子署名を削除してもよい。
その場合、レジストリが、残りのDSレコードのための電子署名を再生成してもよい。ドメインがゾーンにおける発行にふさわしいか否か、および、それがゾーンにすでに存在するか否かを決定する。
ドメインがゾーンに存在せず、そして、現在ゾーンに存在する場合、
そのNSEC３レコードを作成する。
NSEC３レコードに署名する。
NSEC３レコードのための電子署名を格納する。
NSEC３連鎖におけるその正しい位置を識別し、かつ、連鎖への他の更新に関する最小の「ブロッキング」でその新規NSEC３レコードを挿入する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数を固定するステップと、挿入を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を含んでもよい。
ドメインがゾーンに存在せず、そして、現在ゾーンに存在すべきでない場合、
NSEC３連鎖におけるドメインのレコードを位置付ける。
連鎖への他の更新に関する最小の「ブロッキング」でそのNSEC３レコードを削除する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小の数を固定するステップと、レコード削除を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を含んでもよい。
【００６１】
上記したプロセスの態様が一般に図４に示されている（本明細書に開示された例のインライン署名のステップを示す）。他のステップの前（又は後）に発生すると特に記載されない限り、図２に示されたステップが、本発明の範囲から逸脱することなく、多様な順序で（及び／又は、同時に）行われることに注意しなければならない。
【００６２】
方法が、ドメインコマンド（例えば、追加、修正、及び／又は、削除コマンド）が受信されるＳ１０１０で始まる。Ｓ１０２０で、ドメインコマンドが解析されて、例えば、コマンドが適用するドメイン、適用可能なTLD、コマンドのタイプ、DNS変更などを識別してもよい。方法がＳ１０２２に続く。
【００６３】
Ｓ１０２２で、ドメインコマンドで識別された変更が実行のために処理される。本明細書に述べたように、そのような変更の実行が、例えば、DNSSEC署名機能などの多数の異なるデータベース操作を含む単一のトランザクション（例えば、Ｔ１０２１）に含まれる。Ｓ１０３０およびＳ１０４０で、例のシステム（例えば、図１に示したプロビジョニングシステム１１０）が、ドメインコマンドの結果として、DNSSECデータ（実施されたか、又は実施される変更に基づき、追加及び／又は変更される、かつ／又は、署名又は再署名される必要のある）を識別してもよい。例えば、これは、DNSSEC関連の変更のためのコマンド、オペレーション、及び／又は、データを解析するステップと、署名及び／又は再署名される必要のあるDNSSECデータを識別するステップとを含んでもよい。
【００６４】
Ｓ１０５０で、適したDNSSEC鍵、署名プロトコル（及び／又は、適したＨＳＭ）が、署名される必要のあるデータに基づき識別される。その決定が、例えば、データが存在する、ドメイン、及び／又はドメインのTLDを含むさまざまな要因に基づき実施される。
【００６５】
Ｓ１０６０で、例えば、DNSSECデータが、１又は複数のＨＳＭ（例えば、図２に示されたＨＳＭ３４４，３４８、又は、図１に示されたプロビジョニングシステム１１０に含まれたＨＳＭ）によって署名される。DNSSECデータが署名され、かつ、他のDNS変更が実行されるとき、変更が、レジストリデータベースなどへ保存される。トランザクションＴ１０２１のための要求されたDNS変更、および、DNSSEC署名が完了した後、トランザクションがＳ１０７０でコミットされる。
【００６６】
Ｓ１０７０でのトランザクションコミットの後、Ｓ１０７２で、トランザクションＴ１０２１のためのDNS変更、および、DNSSEC署名が、DNSに発行される。図４に示された方法のステップが、単一のトランザクションの間に完了される関連するDNSSECおよびDNS更新機能のすべての包括的な表示ではないことに注意しなければならない。例えば、多様なDNS更新操作との関連で上記した多様なNSEC更新ステップ（および他の機能）も、当然、トランザクションＴ１０２１に含まれる。
【００６７】
発明者は、最も時間のかかる、したがって、最も最適化されるDNSSECトランザクションの部分が、NSEC３連鎖の更新のすぐ後に続く、電子署名の生成および格納であることが分かった。ドメインのTLDのためのDNSゾーンファイルの内外へドメインが移動するときにはいつでも、NSEC３連鎖の更新が発生することに注意しなければならない。TLDゾーンファイルにふさわしいためには、ドメインが、
そのために定義された委任ネームサーバを備えなければならない。
ホールド状態ではない。
レジストリから削除されない。
【００６８】
したがって、DNSSEC使用可能ドメインのどのような変更でも、そのゾーン状態を変更する可能性を有する。
【００６９】
上記したように、DNSSEC署名が、トランザクションで同時インラインに実行され、かつ、権威レジストリデータベースに保存される。DNS解決が、レジストリデータベースにおいて各コミットされたトランザクションをとることができ、かつ、DNSサーバへ増分的にそれを適用することができる。
【００７０】
本発明の実施例によれば、ドメインレジストリのドメインコマンドをともなうDNSSEC署名インラインが、例えば、レジストリデータベースがDNSにおいて発行される権威ソースを常に示すことを確実にすることによって、最高レベルのデータ完全性を維持することにおいて利点を提供する。また、データ完全性の利点に加えて、DNSSEC署名インラインは、増分更新を効率的に実施する。例えば、ゾーンの一部だけが個別のドメインコマンドによって影響を受け、したがって、ドメインコマンド更新および付加的DNSSEC更新の両方が、仕事の個別ユニット（即ち、個別のトランザクション）としてDNSへ伝搬される。これは、DNSに対するDNSSEC更新を含むドメインレジストリ更新を伝搬するステップにおいて、非常に低い遅延をもたらすことが発明者によって分かった。
【００７１】
DNSSECインライン署名の実施例の一部として、図２，３に示すようなネットワーク対応および高性能の署名サーバ群が、DNSSEC情報を署名するために設けられる。これが、最大のTLDとの関連でさえ効果があることが分かり、かつ、高レベルのデータ完全性を有するDNS伝搬ＳＬＡを維持することと同様に、ドメインレジストリ応答時間ＳＬＡを維持する。
【００７２】
ドメイン更新コマンド（DSレコードを提出するレジストラ（registrar）を含まない）の後、DNSSEC署名が発生することに注意しなければならない。例えば、DNSSEC使用可能ドメインからすべてのネームサーバを削除することは、ドメイン更新コマンドであるが（レジストラがDNSSECデータを渡さない）、それが署名を生成することをもたらす。したがって、本発明の特定の実施例がレジストラ（所定のレジストリに関する複数のレジストラを含む）からのリクエストに応答することに適用されるが、本発明はそのようなシナリオに限定されない。
【００７３】
上記したインライン署名技術に加えて、発明者は、本発明の実施例に従って実施される他の方法も確認した。例えば、発明者は、例えば、レジストリ（又は、他の管理されたサービスプロバイダー）によるDNSSEC署名操作の実施に適用される多様な「ダウンストリームレゾリューションデータベース」および「ルックアサイド」技術を開発した。例のダウンストリームレゾリューションデータベースシステムの実施例が図５を参照して説明される。
【００７４】
図５に示すように、ダウンストリームレゾリューションデータベース技術が、追加のレゾリューションデータベース２２２と、レゾリューションデータベース２２２へレジストリデータベース１２２などからDNS変更を通信するレゾリューションデータベースプロセス３３３とを備えてもよい。上記したように、本明細書で使用されるとき、「データベース」は広く理解しなければならず、かつ、データベース内の離散データスキーマ又はテーブルなどを含んでもよい。ダウンストリームレゾリューションデータベースアプローチでは、ダウンストリームレゾリューションデータベース２２２が、DNS１４０へ増分更新を提供するための権威データベースであってよい。すべての標準ドメインデータ（例えば、非DNSSECデータ）が、追加のDNSSEC処理を伴わないレジストリクライアント１１１からの入力に基づき、レジストリデータベース１２２へ書き込まれる。トランザクションが、レジストリ−レゾリューションデータベースプロセス３３３によって、レゾリューションデータベース２２２へレジストリデータベース１２２から順に伝搬される。レジストリ−レゾリューションデータベースプロセス３３３が、DNSSECに影響を及ぼすトランザクションを識別し、かつ、DNSSEC署名およびレゾリューションデータベース２２２へ書き込まれるレコード更新を実行してもよい。したがって、レゾリューションデータベース２２２が、DNSサーバのネットワークのための権威データベースであってもよい。クラウド内のDNSサーバがレゾリューションデータベース２２２に含まれるもののメモリ内表示であるので、レゾリューションデータベース２２２からDNS１４０へ一方向矢印がある。
【００７５】
そのようなアプローチの１つの利点は、DNSSECのためのレジストリクライアントにさらされる余分な時間又は従属関係がほとんど又は全く存在しないことである（DNSSECプロセスが、レジストリ−レゾリューションデータベースプロセス３３３の別のトランザクションにおいて非同期的に実行されるので）。この点について、発明者は、DNSSECデータを受け入れることができるレジストリが電子署名の時間集約的かつプロセッサ集約的な生成を実行する必要があることに注目している。このため、レジストリが、ＯＬＴＰトランザクションの外部で、これらの署名生成タスクを行うように選択してもよい。これは一般にレジストリに以下を必要とする。
１．レジストリへ／の中に／からDNSSEC関連のドメイン名を追加、更新、又は削除するコマンドを受信する。
２．電子署名データを引いた、操作に起因するデータをレジストリデータベースにコミットする。
３．要求される電子署名を生成して、ＯＬＴＰトランザクションの結果として、DNSSECデータへの変更を反映する。
４．レジストリ／レゾリューションデータベースに電子署名および他のDNSSECデータ（例えば、NSEC又はNSEC３連鎖への変更）をコミットする。
【００７６】
ステップ３，４を自らの別のデータベーストランザクションに分離することにより、レジストリは、ステップ２が完了した後、顧客へ早急な返答を送信することができる（顧客応答時間に影響を及ぼすことなく、非同期的に実行される比較的遅いステップ３，４から離れて）。
【００７７】
上記したプロセスの態様が一般に図６に示されている（本明細書に開示されるダウンストリームレゾリューションデータベースのための例の処理ステップを示す）。他のステップの前（又は後）に生じると特に説明されない限り、図６に示されたステップが、本発明の範囲を逸脱することなく、多様な順序で（及び／又は同時に）行われることに注意しなければならない。
【００７８】
方法がＳ２０１０から始まる（ドメインコマンド（例えば、追加、修正、及び／又は削除コマンド）が受信される）。Ｓ２０２０で、ドメインコマンドが解析されて、例えば、コマンドが適用するドメイン、適用可能なTLD、コマンドのタイプ、DNS変更などを識別する。方法はＳ２０２２に続く。
【００７９】
Ｓ２０２２で、ドメインで識別された変更が、関連の電子署名データを処理することなく、実行のために処理される。これは、電子署名データを引いた、操作に起因するデータをレゾリューションデータベースにコミットするステップを含んでもよい。
【００８０】
Ｓ２０３０で、レジストリが、顧客へＳ２０２２からの変更の完了を報告する（DNSSEC署名機能の状態に拘わらず実行される）。
【００８１】
Ｓ２０３２およびＳ２０４０で、例のシステム（例えば、図５に示したプロビジョニングシステム１１０）が、ドメインコマンドの結果として、実行される変更（又はすでに実行された変更）に基づき、追加及び／又は変更される、及び／又は、署名又は再署名される必要があるDNSSECデータを識別する。これは、例えば、DNSSEC関連の変更のためのコマンド、操作、及び／又はデータを解析するステップ、および、署名及び／又は再署名される必要のあるDNSSECデータを識別するステップを含んでもよい。
【００８２】
Ｓ２０５０で、適したDNSSEC鍵、署名プロトコル、及び／又は適したＨＳＭが、署名される必要のあるデータに基づき識別される。そのような決定が、例えば、ドメイン、及び／又は、ドメインのTLD（データが存在する）を含むさまざまな要因に基づき行われる。
【００８３】
Ｓ２０６０で、例えば、１又は複数のＨＳＭ（例えば、図２に示したＨＳＭ３４４，３４８）、又は、図１に示したプロビジョニングシステム１１０に含まれたＨＳＭによって、DNSSECデータが署名される。DNSSECデータが署名されるとき、変更が、レゾリューションデータベース（例えば、ダウンストリームレゾリューションデータベース２２２）へ保存される。
【００８４】
Ｓ２０７０で、新規に署名されたDNSSECデータがDNSへ発行される。
【００８５】
上記した「ルックアサイド」アプローチに戻ると、そのシステムおよび方法の実施例が図７に示されている。図７に示すように、ルックアサイドアプローチが、単一のレジストリデータベース１２２と、非同期プロセス３３５（DNSSECデータをともなう単一のレジストリデータベース１２２（真のソース）を取り込む）とで実行される（次いで、DNS１４０へ向かって増分的に発行される）。「ルックアサイド」アプローチが、DNSサーバを修正して、追加的ルールを適用するステップ（例えば、特定の保留中のトランザクションを保持すること）、および、保留中のDNSSEC変更がレジストリデータベース１２２で実行された後、リクエストされたデータとともに単に回答するステップを含んでもよい。
【００８６】
ルックアサイドアプローチが、新規のレゾリューションデータベースを追加する必要はないが、代わりに、例えば、レジストリデータベース１２２およびDNSサーバに複製される両方に、一連のルックアサイドテーブル１２４を作成する。レジストリサービス３３５が、プロセス３３５のDNSSEC部分によって処理される保留中の情報でルックアサイドを初めに取り込む追加のロジックを含んでもよい。プロセス２２５が、レジストリデータベース１２２へ書き込まれたDNSSECレコードを署名および管理するために、すべての保留中のルックアサイドトランザクションを処理してもよい。DNSサーバが、保留状態の変更を有するDNSレコードについてクライアントクエリーに回答しないように構成されている。DNSサーバが、例えば、ルックアサイドテーブル１２４の情報に基づき保留中の変更に気が付き、かつ、クリアされて、例えば、完了としてルックアサイドレコードにマークを付ける（及び／又は、ルックアサイドレコードが除去されたと認識する）プロセス３３５によって、データを返してもよい。
【００８７】
ルックアサイドアプローチの１つの利点が、第２レゾリューションデータベースで、複製の情報を必要としないことである。加えて、ルックアサイドアプローチを用いて、非DNSSECトランザクションがDNSSEC処理によって影響を受けない（それらが以前に実行したとき、それらがDNSサーバへ伝搬するので）。例えば、DNSSEC処理の停止が非DNSSEC更新を止める。
【００８８】
例のルックアサイドアプローチの実施例が一般に図８に示されている。他のステップの前（又は後）に発生すると特に説明されない限り、図８に示されたステップが、本発明の範囲を逸脱することなく、多様な順序で（及び／又は、同時に）実行されることに注意しなければならない。
【００８９】
方法がＳ３０１０から始まる（ドメインコマンド（例えば、追加、修正、及び／又は削除コマンド）が受信される）。Ｓ３０２０で、ドメインコマンドが解析されて、例えば、コマンドが適用するドメイン、適用可能なTLD、コマンドのタイプ、DNS変更などを識別する。方法はＳ３０２２に続く。
【００９０】
Ｓ３０２２で、ドメインコマンドで識別された変更が、関連の電子署名データを処理することなく、実行のために処理される。これは、電子署名データを引いた、操作に起因するデータをレジストリデータベースにコミットするステップを含んでもよい。
【００９１】
Ｓ３０３０およびＳ３０３２で、例のシステム（例えば、図５に示したプロビジョニングシステム１１０）が、ドメインコマンドの結果として、実行される（又はすでに実行された）変更に基づき、追加及び／又は変更される、及び／又は、署名又は再署名される必要のあるDNSSECデータを識別する。これは、例えば、DNSSEC関連の変更のためのコマンド、操作、及び／又はデータを解析するステップ、および、署名及び／又は再署名される必要のあるDNSSECデータを識別するステップを具備してもよい。
【００９２】
Ｓ３０４０で、データベースエントリが、例えば、ドメインコマンドに関する保留中のDNSSEC変更が存在することを示す、新規又は既存のルックアサイドテーブルの一部として、作成される。
【００９３】
Ｓ３０４２で、データベースエントリが、DNSへ発行される（例えば、新規（又は既存への更新）のルックアサイドテーブルの一部として）。
【００９４】
Ｓ３０５０で、適したDNSSEC鍵、署名プロトコル、及び／又は適したＨＳＭが、署名される必要のあるデータに基づき識別される。そのような決定が、例えば、ドメイン、及び／又は、ドメインのTLD（データが存在する）を含むさまざまな要因に基づき行われる。
【００９５】
Ｓ３０６０で、例えば、１又は複数のＨＳＭ（例えば、図２に示したＨＳＭ３４４，３４８）、又は、図１に示したプロビジョニングシステム１１０に含まれたＨＳＭによって、DNSSECデータが署名される。DNSSECデータが署名されるとき、変更が、レゾリューションデータベース（例えば、ダウンストリームレゾリューションデータベース２２２）へ保存される。
【００９６】
Ｓ３０７０で、新規に署名されたDNSSECデータがDNSへ発行される。加えて、データベースエントリが、例えば、ルックアサイドテーブルのエントリをクリアする（又は、ルックアサイドテーブルを削除する）ことによって、クリアされる。ルックアサイドテーブルへの変更もDNSへ発行される。
【００９７】
実施例では、DNSSECエンジンも、常にレゾリューションシステムのデータの一貫し、安定したイメージを提供するように構成され、かつ、これらのイベントが後のイベントによって陳腐化するとき、未処理のイベントをスキップするためのさらなる最適化アルゴリズムを含んでもよい（例えば、最新のイベントが全くレジストリシステムから削除される結果をもたらす、ドメインのための待ち行列のDNSSECイベントを処理する必要がないことを認識すること）。
【００９８】
本発明の実施例が、上記した方法をコンピュータに実行させるための命令でコード化されたコンピュータ読み取り可能な記録媒体と同様に、上記した方法を実施するためのシステムを備えることができる。例えば、図９に示すように、サーバシステム（例えば、サーバ６００，６１０、及び／又は６２０）（少なくともプロセッサ、メモリ、および電子通信デバイス（図示せず）を備える）が、ネットワーク６０５（例えば、インターネット）を介して受信されるリクエスト（例えば、本明細書に開示されたリクエスト）に関して、受信、識別、応答、及び／又は、動作するように構成される。サーバ６００，６１０、及び／又は６２０のいずれかが、例えば、本明細書に詳細に開示されたインターネットホスティングプロバイダー、レジストラ、及び／又はレジストリによって操作され、かつ、ウェブデバイス６３０によって一般的に表わされた、いくつもの再帰的DNSサーバと通信する。本明細書に開示されたように、再帰的サーバ６３０が、ホスティングプロバイダー、レジストラ、及び／又は、レジストリオペレーティングサーバ６００，６１０、および６２０のドメインのためのDNS関連のデータをキャッシュしてもよい。
【００９９】
ドメインについてDNSデータを更新するリクエストが、例えば、レジストラ、DNSサービスプロバイダー、又は、登録者に由来してもよい（多様なシステム（例えば、コンピュータ６１１，６１２）を介して、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ６１６、又は、必要な機能を備えた他のネットワーク対応デバイスと無線又は他の通信を行う別のサーバ６１３を介して）。
【０１００】
多様な通信、送信、および本明細書に開示された関連の機能が、例えば、ネットワーク６０５を介して実行され、かつ、サーバシステム（例えば、サーバ６００，６１０、および６２０）によって実行される開示された処理の結果が、既知の方法に従って、表示、格納、及び／又は、配布される。ネットワーク６０５が、いくつもの通信コンポーネント（有線、セル、衛星、光、及び／又は他の類似の通信リンクを含む）を含んでもよい。
【０１０１】
サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、第１ストレージ（図示せず、一般にランダムアクセスメモリ、又はRAM）、第２ストレージ（図示せず、一般にリードオンリーメモリ、又はROM）を含むストレージデバイスに接続されたいくつものプロセッサ（図示せず）を備えてもよい。これらストレージデバイスの両方が、適したタイプのコンピュータ読み取り可能な記録媒体（非一時的なストレージ媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、磁気テープ）、CD-ROMディスクなどの光媒体、及び／又は、光磁気媒体を含む）を含む。また、マスストレージデバイス（図示せず）が、プログラム、データなどを格納するのに使用され、かつ、一般に補助記憶媒体（例えば、主記憶装置よりも遅いハードディスク）である。好ましくは、マスストレージデバイス内に保持される情報が、仮想メモリとして、主記憶装置の一部として、一般的な方法で、組み込まれることが理解される。また、具体的なマスストレージデバイス（例えば、CD-ROM）がプロセッサへ一方向的にデータを渡してもよい。
【０１０２】
また、サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、１又は複数の入出力デバイス（例えば、ビデオモニタ、トラックボール、マウス、キーボード、マイク、タッチセンサ式のディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、又は、他の既知の入力デバイス）（他のコンピュータを含む）を含むインターフェースを備えてもよい。サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、ネットワーク接続を使用して、コンピュータ又は他の電気通信ネットワーク６０５に接続される。ネットワーク６０５が、多様な有線、光、電気、および他の既知のネットワークに接続して、サーバ６００，６１０、および６２０、コンピュータ６１１，６１２、別のサーバ６１３、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ（複数可）６１６、再帰的サーバ６３０、および、類似の機能を有する他のデバイスの間で、情報を交換することができる。そのネットワーク接続を用いて、上記した方法のステップを実行する過程で、サーバ６００，６１０、および６２０（およびコンピュータ６１１，６１２）およびそのプロセッサが、ネットワーク６０５から情報を受信するか、又は、ネットワーク６０５へ情報を出力すると考えられる。上記したデバイスおよび素材は、コンピュータハードウェアおよびソフトウェア技術の当業者によく知られており、当業者に理解されるように個別又は網羅的に示す必要はない。上記したハードウェア要素が、上記した操作を実行するための１又は複数のモジュールとして動作するように（一般的に一時的に）構成される。
【０１０３】
加えて、本発明の実施例は、さらに、本明細書に開示された多様なコンピュータ実行オペレーションを実行するためのプログラム命令を含んだコンピュータ読み取り可能な記録媒体を含む。媒体が、単独で、又はプログラム命令と組み合わせて、データファイル、データ構造、テーブルなども含んでもよい。媒体およびプログラム命令が、本発明の目的のために特に設計されかつ構成されたものであってもよく、又は、それらが、コンピュータソフトウェア技術のスキルを有する人に使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例が、磁気媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、および磁気テープ）、光媒体（例えば、CD-ROMディスク）、光磁気媒体、および、プログラム命令を格納および実行するように特に構成されたハードウェアデバイス（例えば、リードオンリーメモリデバイス（ROM）、および、ランダムアクセスメモリ（RAM））を含む。プログラム命令の例が、機械コード（例えば、コンパイラによって生成される）、および、インタプリタを使用してコンピュータによって実行される高次レベルコードを含むファイルの両方を含む。
【０１０４】
上記した説明は、単に実例であり、本発明のすべての可能性のある実施例、アプリケーション、又は、変形例の網羅的なリストであることを意図されたものではない。したがって、開示された本発明の方法およびシステムの多様な修正例および変形例が、本発明の真の趣旨及び範囲から逸脱することなく、当業者に明らかになる。本発明は特定の実施例との関連で開示されたが、請求項に係る発明がその特定の実施例に不当に限定されないことを理解しなければならない。
【符号の説明】
【０１０５】
320 NCCビジネスサービス
330 バッチ/ツール
342 署名サーバ1
346 署名サーバn
350 データベース
510 クライアント
512 署名サーバ
520 レジストリ
【技術分野】
【０００１】
本発明はDNSSECインライン署名に関する。
【背景技術】
【０００２】
DNS（Domain Name System）は、インターネット上でTCP／IP通信を確立するのに必要とされるIP（Internet Protocol）番号へ人間が読むことができるドメイン名を翻訳するインターネット基盤の一部である。即ち、DNSのため、ユーザは、数字のIPアドレス（例えば、123.4.56.78）（インターネット上でコンピュータと通信するソフトウェアによって使用される機械可読アドレスである）より、記憶しやすいドメイン名（例えば、www.en.example.com）を使用してウェブサイト（および、他のリソース）を参照することができる。各ドメイン名が、ドットで分離された一連の文字列（ラベル）によって作成される。ドメイン名の右端のラベルが、「トップレベルドメイン」（TLD）として知られている。よく知られたTLDの例は、「.com」、「.net」、「.org」などである。各TLDは、第２レベルドメイン（TLDの左隣に記載された、例えば、「www.example.com」の「example」）をサポートする。各第２レベルドメインは、第２レベルドメインの左隣に配置された、いくつかの第３レベルドメイン（例えば、「www.en.example.com」の「en」）をサポートすることができる。付加的なレベルのドメインも存在することができる。例えば、付加的なドメインレベルを有するドメインは、「www.landscape.photos.example.com」となる。
【０００３】
単一のIPアドレス（例えば、単一のサーバに割り当てられたもの）が多数のドメイン名をサポートすることができることに注意しなければならない。即ち、異なるドメイン名が同じサーバへ解決する（次いで、リクエストされたドメイン名、及び／又は、付加的な非ドメイン情報に基づき、どのようなコンテンツを提供するかを決定することができる）。これはバーチャルホスティングと称されることがある。
【０００４】
付加的な非ドメイン情報は、ドメイン名を含むＵＲＩ（Uniform Resource Identifier）に含まれる。例えば、「パス」部分は、フォワードスラッシュ（/）で分離された一連のセグメントである。この情報は、ドメイン名の右隣に含まれ（例えば、「www.example.com/blog/today.htm」の「blog」）、かつ、具体的なコンテンツを識別および配信するため、又は、特定のコードを実行するため、サーバ又は他の受信デバイスによって使用される。非ドメイン情報の他の例はクエリーおよびフラグメントを含む（その詳細が当業者によって理解され、かつ本明細書で詳細には述べられない）。この情報の組合せが、同じページの別の部分又は別のウェブページにユーザを移動させるウェブページハイパーリンクに含まれる。
【０００５】
したがって、上記したさまざまな例で分かるように、および、当業者によって十分理解されるように、ドメイン（例えば、第２レベルドメイン「example.com」）が、異なるアドレスおよび他の識別手段を有するさまざまな異なるインターネットアクセス可能な情報を含んでもよい。
【０００６】
ドメイン名の実際の登録が、ドメイン名レジストラ（registrar）と称される企業によって実行される。レジストラがレジストリでドメイン名を登録する。例えば、エンドユーザが、登録のためのドメイン名をレジストラへ提出し、かつ、ドメイン名が解決すべきIPアドレスを提供する。レジストラは、レジストリと通信して、レジストリデータベースレコード（エンドユーザによって提供されたIPアドレスへドメイン名を解決するのに使用される）を作成し、かつ、ドメイン名が登録されたレジストラの識別を示す。レジストリにおけるドメイン名登録の期限切れを除き、一般に、レジストリでドメイン名レコードにおいて指定されたレジストラだけが、ドメイン名についてレジストリデータベース情報を修正又は削除することができる。エンドユーザは、特定のドメイン移行手順に従うことによって、レジストラを切り替えることができる。また、レジストラはホストプロバイダーとして動作し、又は、エンドユーザは別の第３者のドメインホスティングサービスによってホストされたドメインを有してもよい。
【０００７】
ゾーンファイルは、DNSゾーンと呼ばれるDNSの一部を記述するテキストファイルである。ゾーンファイルは、RR（resource records）の形態で体系化され、ドメイン名とIPアドレスと他のリソースとの間のマッピングを定義する情報を含んでいる。ゾーンファイルのフォーマットは基準によって定義され、各ラインが単一のリソースレコードを一般に定義する。ラインは、ドメイン名で始まるが、左がブランクの場合、以前に定義されたドメイン名をデフォルトにする。次のドメイン名は、TTL（time to live）、クラス（ほぼ必ず「internet」のための「IN」であり、めったに含まれていない）、リソースレコードのタイプ（Ａ，ＭＸ，ＳＯＡなど）である（次に、タイプ固有のデータ（例えば、ＡレコードのためのIPｖ４アドレス））。コメントはセミコロンを使用することで含めることができ、かつ、ラインは括弧を使用することで継続することができる。また、ドル記号で始まるキーワードでマークされるファイル指令が存在する。
【０００８】
DNSは、各ドメインに対して権威ネームサーバを指定することによって、ドメイン名の割り当て、および、これらの名前とIPアドレスとのマッピングの責任を分散する。権威ネームサーバはそれらの特定のドメインに対して責任を有するように割り当てられ、かつ、順に、それらのサブドメインに対して他の権威ネームサーバを割り当てることができる。このメカニズムは一般に、継続的に参照および更新される単一の中央レジスタの必要性を回避する助けとなる。DNS解決プロセスのため、ユーザは、リバースルックアッププロセス（それによって、ユーザが所望のドメインに入り、かつ、DNSが適したIP番号をリターンする）によって、所望のドメインへ向かうことができる。DNS解決プロセスの間、所定のドメイン名に対するリクエストは、リゾルバ（例えば、スタブリゾルバ）から適したサーバ（例えば、再帰的リゾルバ）へ送られて、IPアドレスを検索する。効率を改善し、インターネット上のDNSトラフィックを減少させ、かつ、エンドユーザのアプリケーションの性能を向上させるため、DNSは、DNSキャッシュサーバ（問題になっているドメイン名レコードのTTL（time-to-live）によって決定された期間についてDNSクエリー結果を格納する）をサポートする。一般に、そのようなキャッシングDNSサーバ（DNSキャッシュとも称される）も、クエリーされたドメインの権威ネームサーバまでDNSルートで始まる所定の名前を解決することが必要である再帰的アルゴリズムを実施する。一般にインターネットサービスプロバイダー（ＩＳＰ）は、その顧客に対して、再帰的およびキャッシングDNSサーバを提供する。加えて、ホームネットワーキングルータが、DNSキャッシュおよびプロキシを実装して、ローカルネットワークの効率を改善してもよい。
【０００９】
DNSの分散された性質がシステム全体の効率に関して重大な利点を提供するが、それは所定のタイプの機能不良、及び／又は、システムのさまざまなノードでの攻撃に対して、システムを弱くもする。発生する１つの特定の問題はDNSキャッシュポイズニングと称される。DNSキャッシュポイズニングは、権威DNSソースに由来しないDNSネームサーバのキャッシュデータベース内にデータが導入されるときに発生する。これはネームサーバに対する故意の攻撃によって生じ、又は、例えば、ミス設定されたDNSキャッシュ、又は、DNSアプリケーションの不適切なソフトウェア設計の意図的でない結果である。したがって、DNSキャッシュポイズニングは、結果的に、（１）解決リクエスト失敗（例えば、不正確又はミス設定されたIPアドレス情報が提供される）、又は、（２）リクエストしたユーザの解決リクエストの悪意のあるサイト（本物のドメインになりすまし、かつ、情報（例えば、アカウントパスワード）を不法に得るために、又は、リクエストしたユーザに配信される悪意のあるコンテンツ（例えば、コンピュータワーム又はウィルス）を配布するために使用される）への移動を生じる。
【００１０】
DNSSEC（Domain Name System Security Extensions）は、IPネットワークで使用されるようなDNSによって提供される特定の種類の情報をセキュアにするための一連のIETF（Internet Engineering Task Force）仕様書である。DNSSECは、DNS対応のゾーンファイルの署名（DNSデータに対する発信元認証およびデータ完全性を保証する）、および、認証された存在の否定を提供する。一般に、DNSSEC内で提供された回答は電子的に署名され、かつ、電子署名をチェックすることによって、DNSリゾルバは、情報が権威DNSサーバに関する情報に対応するか否かをチェックすることができる。DNSSECは電子署名および認証に対して公開鍵暗号を使用する。DNSKEYレコードが、信頼された第３者である信頼の連鎖（DNSルートゾーンについて１組の検証された公開鍵から始まる）を介して認証される。
【００１１】
DNSSECを実装するため、いくつかの新規のDNSレコードタイプが、DNSSECとともに使用するために作成又は適合された（RRSIG、DNSKEY、DS、NSEC、NSEC３、およびNSEC３ PARAMを含む）。例えば、DNSSECが使用されるとき、DNS検索への各権威回答が、リクエストされたレコードタイプに加えて、RRSIG DNSレコードを含む。RRSIGレコードは、回答のDNSリソースレコードセットの電子署名である。電子署名は、DNSKEYレコードで発見された正しい公開鍵を置くことによって、検証することができる。DSレコードは、信頼の連鎖を使用した検索手順でDNSKEYの認証において使用される。NSECおよびNSEC3レコードは、存在しないDNSレコードに対して認証された存在の否定の応答を提供するのに使用される。
【００１２】
DNSSECの要求は、異なる鍵（DNSKEYレコードの両方に格納され、かつ、信頼アンカーを形成する他のソースから）の使用を含む。例えば、KSK（Key Signing Keys）（DNSKEYレコードに署名するために使用される）およびZSK（Zone Signing Keys）（他のレコードに署名するために使用される）が存在する。ZSKは固有のDNSゾーンの制御および使用下にあるので、それらはより容易かつより頻繁に切り替えることができる。その結果、ZSKは一般にKSKより短く（バイト長に関して）、その上、容認可能なレベルの保護を提供する。
【００１３】
プロトコルはDNSSEC（KSKおよびZSKの使用を含む）の利用に対して開発されているが、レジストラおよびレジストリレベルで、大規模な使用に対して対処及び／又は最適化されていないDNSSEC使用可能なドメインを運用するさまざまな態様が存在する。例えば、短い期間に多数の署名を処理する能力が、ゾーンへの変更に基づいてゾーン全体に署名する一般的な方法に限定されている。したがって、DNSSEC管理に関する運用およびDNSSECレコードに必要な署名機能の機能性及び／又は効率性をさらに向上させる継続的な要求が存在している。
【発明の概要】
【課題を解決するための手段】
【００１４】
最新のDNSSEC技術が、DNSSECデータの「分散」署名、即ち、さまざまなユーザ、DNSプロバイダーなどに分散される署名技術を含んでいる。現在、DNSSECを採用することを望むユーザには以下の基本オプションがある。
１．１組のソフトウェア鍵又はハードウェア鍵と一緒に、第３者およびオープンリソースソフトウェアの組合せを使用した自らのDNSSECソリューションを構築する。
２．Secure64 DNS Signer、BlueCat Networks、Xelerance DNSX Secure、Singer、およびInfobloxのようなDNSSEC鍵管理および署名アプライアンスを使用する。そのようなアプライアンスは、鍵管理およびゾーン署名のさまざまな態様を提供するが、クライアントサイトにハードウェアを導入する必要がある。DNSSEC鍵管理および署名アプライアンスが、ユーザサイトでのハードウェアの実装を必要とし、鍵マテリアルのより詳細な管理を必要とし、かつ、１人より多くのユーザをサポートしないことに注意しなければならない。
３．DNSSECをサポートするように更新された管理DNSソリューションを使用する。管理DNSプロバイダーは、ゾーン管理およびゾーン発行機構を含む。DNSSECを使用可能なため、クライアントは管理DNSゾーンに対してDNSSECを「ターンオンする」ことができるが、ユーザは管理DNSプロバイダーへユーザのDNSホスティングを移行又は外部委託することを要求される。
【００１５】
また、DNSSECにサポートを追加するドメインレジストリに対する１つのアプローチは、DNSSEC DS（Delegation signer）情報を許可し、未署名のゾーンを生成し、次いで、発行のためゾーン全体に署名することである。しかし、膨大なレジストリ（例えば、.comおよび.netレジストリ）へのDNSSECの導入にともなって、DNSSECデータに対するさまざまな分散署名技術および他の署名技術における効率の悪さ（特に、大規模なゾーンに関して）が、遅延および解決失敗を含む解決に関する潜在的課題をもたらす。そのような課題が、電子商取引および他の高トラフィックサイトに大きな弊害をもたらす。本発明は、さまざまな増分署名技術（incremental signing technique）を通じて、権威ソース（例えば、ドメインに関与するレジストリ）でのDNSSEC使用可能ゾーンの効率的な署名において利点を提供する。例えば、レジストリ（又は、DNSデータにおける特定の変更に気付いている、又は、DNSデータにおける特定の変更に対して注意を喚起される他のエンティティ）の観点からアプローチしたとき、DNSデータの部分（追加、変更、及び／又は、削除操作などの対象である）が識別される（ゾーン全体に再署名せず、署名、さまざまにコミット、および報告される）。態様では、DNS更新操作および影響されるDNSSECレコードの署名が、本明細書では「インライン署名（inline signing）」と称される単一のトランザクション（例えば、極小の、一貫した、分離された、かつ、耐久性のある仕事のユニット）態様の一部として実行される。
【００１６】
態様では、DNSSECインライン署名が、ドメインコマンドでDNSSEC署名インラインを実施することを含んでいる。例えば、責任のあるレジストリが、DNSSEC DS情報を許可し、かつ、同じトランザクション内で署名されたDNSSECレコードを作成し、その後、１つの権威ソースからDNSの外部へ署名された情報を増分的に発行する。そのような権威署名は、他の分散署名技術に対して利点を提供するが、一般に、本発明のさらなる態様によって対処される拡張性において課題を呈する。本発明の態様によれば、レジストリデータベースが、DNSSECインライン署名を介して、DNSSECゾーンで発行されたレコードのすべてに対して、単一の権威ソースとして動作してもよい。
【００１７】
本明細書にさらに開示されるように、レジストリ（又は、DNSデータの特定の変更に対して気が付いているか、又は、注意喚起される他のエンティティ）における増分DNSSEC署名を実施するシステムおよび方法は、DNS追加、更新、及び／又は、削除操作などを含む単一のトランザクションの一部として、電子署名操作を実施することを含んでいる。例示的な方法は、リクエスタからドメインコマンドを受信するステップを含み、ドメインコマンドはドメインの識別子を含んでいる。受信されたドメインコマンドは、ドメインに対するレジストリによって格納されたデータに関して実行される。DNSSECデータ変更も受信されたドメインコマンドに基づき識別される。また、ドメインコマンドの実行を含む個別のトランザクションの一部として、レジストリが、秘密鍵（例えば、権威サーバの秘密鍵）を使用して、ドメインに対するDNSSECレコードに署名する。態様は、レジストリでトランザクションをコミットするステップを具備する。本明細書で使用されるように、トランザクションコミットが、トランザクションの範囲内で、すべてのデータ操作に適用し、かつ、データベースへ結果を保存する操作として、理解される。態様は、DNS基盤へコミットされたトランザクションを伝えるステップを具備する。態様では、例えば、レジストリが別のサーバへ署名されたDNSSECレコードを増分的に発行する。
【００１８】
本発明の態様によれば、態様は、リクエスタからドメインコマンドを受信することを含むレジストリでDNSSEC署名を実行するためのシステムおよび方法を含んでいる。ドメインコマンドは、ドメインの識別子、および、例えば、ドメインに関する追加、修正、及び／又は、削除コマンドのうちの少なくとも１つを具備している。態様は、ドメインについてレジストリによって格納されたデータに関して、受信されるドメインコマンドを実行するステップを具備している。ドメインコマンドの実行を含む個別のトランザクションの一部として、ドメインに対するDNSSECレコードが電子署名される（例えば、権威サーバの秘密鍵を使用して）。署名されたDNSSECレコードが別のサーバ（例えば、DNSサーバ）へ増分的に発行される。
【００１９】
態様は、ドメインコマンドが１又は複数のDNSSEC DS（Delegation Signer）要素を含むことを含む。態様では、ドメインコマンドが、１又は複数の関係するDNSSEC DS（Delegation Signer）レコードを生成する１又は複数のDNSKEY要素を含む。
【００２０】
態様では、例えば、リクエスタは、レジストラ、DNSサービスプロバイダー、又は、登録者（registrant）である。態様では、ドメインは、レジストリのトップレベルドメインの下の第２（又は、より高い）レベルドメインである。
【００２１】
態様では、方法が、レジストリの権威サーバによって、複数のレジストラからドメインに対して実行される。態様では、DNSレコードの署名が、レジストリの権威サーバによって、複数のレジストラから少なくとも２つのドメインに対して実行される。
【００２２】
態様では、DNSレコードの署名が、レジストリに対して複数の署名サーバによって実行される。
【００２３】
また、態様は、追加、更新、削除コマンドのうちの少なくとも１つに基づき、NSEC又はNSEC３連鎖へ変更をコミットするステップを具備している。
【００２４】
本発明のさらなる態様によれば、態様が、レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つの第１コマンドをリクエスタから受信するステップと、レジストリデータベースに格納されたデータを追加、更新、及び／又は削除する前記第１コマンドからの命令を実行するステップとを含む、レジストリでDNSSEC署名を実行する方法およびシステムを具備している。態様では、コマンドの実行は、電子署名データを適用するステップを含まない。態様では、レジストリ（又は、他のサービス）が、命令が実行されたことをリクエスタへ報告する。第１コマンドからの命令の実行から離れ（実行の報告の後であってもよい）、電子署名が、追加、更新、及び／又は、削除変更に基づいて生成され、かつ、電子署名がレジストリレゾリューションデータベースへコミットされる。また、態様は、DNSへ（ドメインコマンドに基づき）非DNSSEC変更、及び／又は、DNSSEC変更を発行するステップを具備している。態様では、非DNSSEC変更およびDNSSEC変更が、DNSへ非同期的にシステムによって発行される。
【００２５】
本発明のさらなる態様によれば、態様は、レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つの第１コマンドをリクエスタから受信するステップと、レジストリデータベースに格納されたデータを追加、更新、及び／又は、削除する前記第１コマンドからの命令を実行するステップと（実行は電子署名データを適用するステップを含まない）、第１コマンドに関する保留中のDNSSEC変更を示すデータベースエントリを生成するステップと、前記追加、更新、及び／又は、削除変更に基づき、電子署名を生成するステップと、データベースエントリをクリアするステップとを含む、レジストリでDNSSEC署名を実行するためのシステムおよび方法を具備している。また、態様は、DNSへデータベースエントリを発行するステップを具備している。
【００２６】
追加的な特徴、利点、および本発明の態様は、以下の詳細な説明、図面、および請求項の検討から、説明され、又は明らかである。さらに、上記した本発明の概要および以下の詳細な説明の両方が、例示であり、かつ、本発明の特許請求の範囲を限定することなくさらなる説明を提供することを意図したものであることを理解しなければならない。しかし、詳細な説明および特定の例は、単に本発明の好ましい実施例を示したものである。本発明の真の趣旨および範囲から逸脱することなく、多様な変形例および改良例が詳細な説明から当業者には明らかとなる。
【００２７】
本発明のさらなる理解を提供するよう含まれた添付の図面が、組み込まれ、本明細書の一部を構成し、本発明の実施例を図示し、詳細な説明とともに、本発明の原理を説明するのに用いられる。本発明の基本的理解および実施される多様な方法に必要であるよりもさらに詳細に本発明の構造的詳細を示していない。
【図面の簡単な説明】
【００２８】
【図１】本発明の実施例のインライン署名構成の関係図である。
【図２】本発明の実施例１のDNSSECデータに署名するステップの例のプロセスフローである。
【図３】本発明の実施例のDNSSEC使用可能署名システムのさらなる詳細図である。
【図４】本発明の実施例のDNSSEC使用可能署名システムのさらなる詳細図である。
【図５】本発明のさらなる実施例のダウンストリームレゾリューションデータベース署名構成の関係図である。
【図６】本発明のさらなる実施例のダウンストリームレゾリューションデータベース署名プロセスの例のプロセスフローである。
【図７】本発明のさらなる実施例のルックアサイドデータベース署名構成の関係図である。
【図８】本発明のさらなる実施例のルックアサイドデータベース署名プロセスの例のプロセスフローである。
【図９】本発明の実施例で使用される例のコンピュータネットワークアーキテクチャの図である。
【発明を実施するための形態】
【００２９】
本発明が本明細書に開示された特定の方法、プロトコルなどに限定されないことが理解される（当業者に理解されるようにそれらが多様に変化するため）。また、本明細書に使用された用語が特定の実施例だけを説明する目的に使用され、本発明の範囲を限定することを意図しないことを理解しなければならない。また、本明細書および特許請求の範囲に使用されるとき、単数形態”a”、“an”および“the”は、コンテキストが明確に指定しない限り、複数の言及を含むことに注意しなければならない。したがって、例えば、「サーバ」への言及は、１又は複数のサーバ、および、当業者に既知のその均等物への言及である。
【００３０】
他に定義されない限り、本明細書で使用される技術用語は、本発明が関わる当業者に一般に理解されるものと同じ意味を有する。本発明の実施例、および、多様な特徴、および、それについての利点の詳細は、添付の図面に説明及び／又は図示され、かつ、以下の説明に詳述された非限定的な実施例および実例を参照してさらに完全に説明される。図面に示された特徴は必ずしも一定の縮尺で描かれておらず、かつ、仮に本明細書に明確に述べられていなくても、１つの実施例の特徴が、当業者が理解するように他の実施例で利用されることに注意しなければならない。周知のコンポーネントおよび処理技術の記載は、本発明の実施例を不必要に分かりにくくしないように省略される。本明細書に使用された例は、単に、本発明が実施される方法の理解を助けること、および、当業者が本発明の態様を実施することをさらに可能にすることを目的としている。したがって、本明細書の実施例および実例は、本発明の範囲を限定するものとして解釈されるべきでなく、特許請求の範囲および適用される法によってのみ定義される。さらに、類似の参照数字が図面のいくつかの表示にわたって同様の部分を参照することに注意しなければならない。
【００３１】
本明細書で使用されるとき、他に限定されない限り、レジストラ（registrar）は、ドメイン名レジストリと相互作用し、かつ、登録者(registrant)がドメイン名リソースを作成および更新することを可能にするエンティティ又は組織であると理解される。
【００３２】
本明細書で使用されるとき、他に限定されない限り、登録者は、ドメイン名リソースを作成および更新するレジストラと相互作用する人又は組織であると理解される。
【００３３】
本明細書で使用されるとき、他に限定されない限り、DNSホスティングプロバイダーは、DNSプロビジョニングおよびそのコンテンツについて解決能力を提供する、登録者の代わりに、そのサーバにコンテンツをホストするエンティティ又は組織であると理解される（例えば、IPアドレスを割り当て、それが管理するそれらのIPアドレスへドメイン名を解決することができるネームサーバを運営する）。
【００３４】
本明細書で使用されるとき、他に限定されない限り、データベースは、例えば、コンピュータシステムによる使用のための離散及び／又は関係情報について格納およびアクセスするようにフォーマットされた多様な電子記憶装置アプリケーション（例えば、ローカル及び／又は分散ファイルシステム、データファイル、データウェアハウス、構造化データベース、リレーショナルデータベース、ローカル及び／又は分散データベース、ハイブリッドデータベース、データベース内の離散データ構造及び／又はスキーマなど）を含むことを広く理解しなければならない。
【００３５】
本発明の実施例によれば、DNSホスティング移行をともなうドメイン−スポンサーシップ移行をサポートするためのシステムおよび方法が、例えば、レジストラの間のドメイン移行（「ドメイン−スポンサーシップ移行」と称される）と、DNSホスティングにおける移行（「DNSホスティング移行」と称される）とを含んでもよい。ドメイン移行の場合、多くのレジストラがDNSホスティングプロバイダーであるので、両方の移行が一般に含まれ、かつ、登録者が、多くの場合、それらのレジストラによって提供されるDNSホスティングを利用する。以下の例は、同じレジストラの間のDNSホスティング移行を含むレジストラの間のドメイン−スポンサーシップ移行に含まれたステップを示している。
【００３６】
本発明の実施例は、大規模なDNSSECプロバイダー（例えば、レジストリ）が、効果的かつ一貫した方法で、多数のDNS変更（DNSSEC署名データを含む）を処理することを可能にする、多様なインライン署名技術を提供する。
【００３７】
ゾーン署名の概要
【００３８】
上記したように、DNSSECは、キャッシュポイズニング、および、一連の他のDNS脆弱性（例えば、介入者攻撃、および、権威サーバにおける不正データ修正）に対応することを意図したものである。その主な目的は、DNSデータについて発信元認証、および、完全性保護を提供することである。ＰＫＩ（Public Key Infrastructure）は、公開鍵配布の手段として使用してもよい。DNSSECは、DNSデータについて検証メカニズムを提供し、暗号化メカニズムではない。DNSSECにより、セキュリティを意識したリゾルバは、受信されたゾーンデータが秘密鍵を保持するゾーンの管理者によって署名されていることを検証することができる。
【００３９】
DNSKEYリソースレコード
【００４０】
ゾーンは、１又は複数の鍵ペアを有し、それぞれが秘密鍵と公開鍵とを含んでいる。秘密鍵は、ドメイン名データベースにセキュアに格納され、かつ、ゾーンデータに署名するのに使用される。公開鍵は、データベースに格納され、また、DNSKEYリソースレコードとして署名済みゾーンデータに格納される。公開鍵はゾーンデータを検証するのに使用される。DNSKEYレコードは、一般に以下のデータ要素を有する。
フラグ：「ゾーン鍵」および「セキュアエントリポイント」
プロトコル：３の固定値（後方互換性のため）
アルゴリズム：公開鍵の暗号化アルゴリズム
公開鍵：公開鍵データ
【００４１】
DNSKEY RR（Resource Record）は、ZSK（Zone Signing Key)又はKSK(Key Signing Key)であってもよい。KSK(Key Signing Key)はＳＥＰフラグセットを有し、したがって、それらはDNSKEY RRセットのZSKとは区別される。KSK(Key Signing Key)は、他のDNSKEYリソースレコードに署名するのに使用され、かつ、検証される必要のあるデータに対する権限の連鎖を構築するのに使用される。
【００４２】
RRSIGリソースレコード
【００４３】
RRSIGリソースレコードは、リソースレコードセット（RRセット（同じ名前、クラス、およびタイプを有する１又は複数のDNSレコード））のDNSSEC署名を保持する。DNSSEC使用可能リゾルバが、DNSKEYレコードに格納された公開鍵で、署名を検証することができる。RRSIGレコードは以下のデータ要素を有する。
カバーされるタイプ：この署名がカバーするDNSレコードタイプ
アルゴリズム：署名を作成するのに使用される暗号化アルゴリズム
ラベル：オリジナルのRRSIGレコード名のラベルの番号（ワイルドカードを検証するのに使用される）
オリジナルのTTL：カバーされたレコードセットのTTL値
署名満了：署名が満了するとき
署名開始：署名が作成されたとき
鍵タグ：この署名を検証するのに使用されるDNSKEYレコードを迅速に識別するのに役立つ短い数字の値
署名者の名前：この署名を検証するのに使用されるDNSKEYレコードの名前
署名：暗号化された署名
DNSKEY RRは、アクティブな鍵署名鍵によって署名される。他のRRセットはアクティブなゾーン署名鍵だけによって署名される。
【００４４】
NSECリソースレコード
【００４５】
NSECリソースレコードが２つの別の物をリスト化する（権威データ又は委任ポイントNS RRセットを含む次の所有者の名前（ゾーンの正規順序での）、および、NSEC RRの所有者名に存在するRRタイプのセット）（RFC3845）。ゾーンのNSEC RRの完全なセットが、どの権威RRセットがゾーンに存在し、また、ゾーンの権威所有者名の連鎖を形成するかを示す。これらレコードが、リゾルバによって使用されて、DNSSEC検証の一部として、レコード名およびタイプの非存在を検証することができる。NSECレコードは以下のデータ要素を有する。
次のドメイン名：ゾーンの次のレコード名（DNSSEC並べ替え順序）
レコードタイプ：このNSECレコードの名前について存在するDNSレコードタイプ
【００４６】
NSEC３リソースレコード
【００４７】
NSEC３ RR（Resource Record）が、DNSリソースレコードセットに対して認証された存在の否定を提供する。NSEC３ RRは、NSEC RRと同じ機能を有する（NSEC３が暗号化的にハッシュ化されたレコード名を使用して、ゾーンのレコード名の列挙をしないことを除く）。NSEC３レコードは、ゾーンの次のレコード名へリンクし（ハッシュ化された名前の並べ替え順序で）、かつ、NSEC３レコードの自らの名前の第１ラベルでのハッシュ値によってカバーされた名前のために存在するレコードタイプをリスト化する。これらレコードはリゾルバによって使用されて、DNSSEC検証の一部として、レコード名およびタイプの非存在を検証することができる。NSEC３レコードは以下のデータ要素を有する。
ハッシュアルゴリズム：使用される暗号化ハッシュアルゴリズム
フラグ：「Optアウト」（委任が署名されるか否かを示す）
繰り返し：ハッシュアルゴリズムが適用される回数
ソルト：ハッシュ計算についてのソルト値（salt value）
次のハッシュ化された所有者名：ゾーンでの次のレコードの名前（ハッシュ化された名前並べ替え順序で）
レコードタイプ：NSEC３レコードの自らの名前の第１ラベルにおいてハッシュ値によってカバーされる名前に対して存在するレコードタイプ
【００４８】
例のインライン署名構成の実施例が図１に示されている。図１に示すように、リクエスタ１００（例えば、登録者、レジストラ、又は、DNSプロバイダー）が、レジストリプロビジョニングシステム１１０と通信してもよい。リクエスタ１００が、既存又は新規のドメインに関するコマンドを通信してもよい。例えば、リクエスタ１００が、レジストリによって管理されるTLD（例えば、.com）下のドメインについて、レジストリ（例えば、DNSデータ）によって管理されるDNSデータを変更するコマンドを通信してもよい。レジストリプロビジョニングシステム１１０が、多様な方法（例えば、変更コマンドを実行する（例えば、追加、修正、又は削除コマンド）、DNSSECデータ変更を識別する、適切な鍵を識別する、電子署名を適用する、レジストリデータベース１２０へDNSおよびDNSSEC変更を保存させるなど、を含む）でリクエスタ１００からのドメインコマンドを処理してもよい。
【００４９】
実施例では、レジストリデータベース１２０へレジストリプロビジョニングシステム１１０によって提供されるデータが、ドメインのためのDNS情報、および、署名されたDNSSECデータを含んでもよい。実施例では、DNS変更およびDNSSEC変更を、単一のトランザクション内で実行してもよい。いったんドメインのためのDNS情報、および、署名されたDNSSECデータがレジストリデータベース１２０へ保存されると、トランザクションがコミットされる。トランザクションコミットの後、ドメインのためのDNS情報、および、署名されたDNSSECデータが、より広いDNSクラウド１４０（他の権威サーバ、再帰的DNSサーバなどを含む）へ伝えられる。
【００５０】
例のDNSSEC署名サービスのさらに詳細が図２および図３に示されている。図１〜３に示された署名サービス構成が本発明の実践的側面において使用されるが、本明細書に開示されるインライン署名技術が、多様な他の構成を用いた多数の異なる署名サービスに適用されることに注意しなければならない。図２に示すように、レジストリ（又は、DNSSECサービスプロバイダー）が、いくつもの署名サーバ３４２，３４６を備えてもよい。例えば、複数の署名サーバが図１に示されたプロビジョニングシステム１１０を含んでもよい。署名サーバ３４２，３４６が、適切な電子署名鍵を含む実際の電子署名機能を含むＨＳＭ（Hardware Security Module）３４４，３４８（及び／又は、ソフトウェア）をそれぞれ含んでもよい。署名サーバ３４２，３４６が、多様なアプリケーション、サービス、およびツール３１０，３２０，３３０と通信してもよい（かつ、例えば、署名されたDNSデータおよび未署名のDNSデータを交換してもよい）。各ＣＡＳ３１０、ＮＣＣプラグインビジネスサービス３２０、およびバッチ／ツール３３０コンポーネントが、署名サーバ（好ましくは、一連のそのようなサーバ）への接続を有する。署名サーバ３４２，３４６が、データベース３５０へ署名されたDNSデータを保存してもよい。アプリケーション、署名サーバ、ＨＳＭ、およびデータベースの間の例のデータフローの追加的な詳細が図３に示されている。
【００５１】
図３に示すように、例えば、クライアント５１０が、図１に示されたプロビジョニングシステム１１０のフロントエンドサービスを表す（署名サーバ５１２によって署名される必要があるDNSSECデータを識別するように構成される）。署名されるDNSSECデータが、解析され又はドメインコマンドに基づき別の方法で識別され、リンク５４１で示すように、署名サーバ５１２へ提供される。情報（例えば、バイト、鍵タイプ（ZSK、KSK）、およびTLD）を含んでもよい。署名サーバ５１２が、送信５４１から適した鍵情報、及び／又は、ＨＳＭを識別してもよく、かつ、リンク５４２で示されるように、適したＨＳＭ５１４へ未署名のデータを渡してもよい。これは、例えば、バイト、鍵エイリアス、および署名アルゴリズムを有する署名コマンドを含んでもよい。
【００５２】
署名サーバ５１２が、ＨＳＭ５１４へデータを送信するときに権威データ（使用する鍵エイリアス）についてデータベース５２０を周期的にチェックするように構成される。ＨＳＭ５１４は、初期時間でTLDごとに多数の鍵をロードし（一部はZSKであり、一部はKSKである）、かつ、各鍵がエイリアス（鍵エイリアス）によってＨＳＭ５１４に知られている。クライアント５１０が、使用する２種類の鍵（ZSK又はKSK）のどれかおよびTLDを署名サーバ５１２に教えるように構成され、かつ、署名サーバ５１２が、署名のためＨＳＭと通信するとき、その種類の鍵について現在の鍵エイリアス名を識別するように構成される。また、署名サーバ５１２が、現在の鍵エイリアスについてデータベース５２０を再チェックするようにされる。このコマンドは、例えば、ＪＭＸ管理インターフェースを介して、署名サーバ５１２へ発行される。
【００５３】
ＨＳＭ５１４は、適した鍵でDNSSECデータに署名し、かつ、リンク５４３で示されるように、署名サーバ５１２へ署名されたデータを戻す。署名サーバは、リンク５４４で示されるように、クライアント５１０へ署名されたDNSSECデータ（又は、トランザクションコミット情報などの他のデータ）を戻す。
【００５４】
本発明の実施例に従って処理される関係したドメインコマンド操作の例が以下に開示される。
【００５５】
DNSSECデータをともなうドメイン作成
【００５６】
ユーザがDNSSECデータを伝えたドメイン作成の間（これらのデータが、提出される各DS（Delegation Signer）レコードに必要である４フィールドである）、レジストリが、以下の決定を実行し、かつ、以下のアクションを行う。
DSレコード（複数可）のための電子署名を生成および格納する。
ドメインがゾーンにおける発行にふさわしいか否かを決定する。
その場合、
そのNSEC３レコードを作成する。
NSEC３レコードに署名する。
NSEC３連鎖（データベースに格納されたリンクされたリストに、類似した）におけるその正しい位置を識別し、かつ、連鎖への最小の変更でその新規NSEC３レコードを挿入する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数（１である）を固定するステップと、挿入を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を具備してもよい。
【００５７】
新規DSデータをともなうドメイン更新
【００５８】
新規DSデータをともなうドメイン更新の間、レジストラも、ドメインへの他の変更を含んでもよい。これら他の変更が、ドメインのゾーン状態を変更する。したがって、レジストリは、
DSレコード（複数可）のための電子署名を生成および格納する。
ドメインがゾーンでの発行にふさわしいか否か、および、それがすでにゾーンに存在するか否かを決定する。
ドメインがゾーンに存在せず、そして、現在ゾーンに存在する場合、
そのNSEC３レコードを作成する。
NSEC３レコードに署名する。
NSEC３レコードのための電子署名を格納する。
NSEC３連鎖におけるその正しい位置を識別し、かつ、連鎖への他の更新に関する最小の「ブロックキング」でその新規NSEC３レコードを挿入する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数を固定するステップと、挿入を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を具備してもよい。
ドメインがゾーンに存在せず、そして、現在、ゾーンに存在すべきではない場合、
NSEC３連鎖におけるドメインのレコードを位置付ける。
連鎖への他の変更に関する最小の「ブロッキング」でそのNSEC３レコードを除外する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数を固定するステップと、レコード削除を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を具備してもよい。
【００５９】
DSデータの削除をともなうドメイン更新
【００６０】
DSデータの削除をともなうドメイン更新の間、レジストラもドメインへの他の変更を含んでもよい。これら他の変更が、ドメインのゾーン状態を変更してもよい（例えば、削除の後、ドメインに残りのDSレコードがない場合、ドメインはもはやゾーンにふさわしくない）。したがって、レジストリは、
ドメインが残りのDSレコードを有するか否かを決定する。
そうでない場合、レジストリが、NSEC３連鎖からドメインを削除してもよい（ステップについて以下を参照）。また、レジストリが、削除されるDSデータのための既存の電子署名を削除してもよい。
その場合、レジストリが、残りのDSレコードのための電子署名を再生成してもよい。ドメインがゾーンにおける発行にふさわしいか否か、および、それがゾーンにすでに存在するか否かを決定する。
ドメインがゾーンに存在せず、そして、現在ゾーンに存在する場合、
そのNSEC３レコードを作成する。
NSEC３レコードに署名する。
NSEC３レコードのための電子署名を格納する。
NSEC３連鎖におけるその正しい位置を識別し、かつ、連鎖への他の更新に関する最小の「ブロッキング」でその新規NSEC３レコードを挿入する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小数を固定するステップと、挿入を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を含んでもよい。
ドメインがゾーンに存在せず、そして、現在ゾーンに存在すべきでない場合、
NSEC３連鎖におけるドメインのレコードを位置付ける。
連鎖への他の更新に関する最小の「ブロッキング」でそのNSEC３レコードを削除する。これは、変更しなければならない連鎖におけるリンクを非常に迅速に識別するステップと、それらの最小の数を固定するステップと、レコード削除を実行し、かつ、本物のかつ一貫したNSEC３連鎖でエンドへ再リンクするステップと、を含んでもよい。
【００６１】
上記したプロセスの態様が一般に図４に示されている（本明細書に開示された例のインライン署名のステップを示す）。他のステップの前（又は後）に発生すると特に記載されない限り、図２に示されたステップが、本発明の範囲から逸脱することなく、多様な順序で（及び／又は、同時に）行われることに注意しなければならない。
【００６２】
方法が、ドメインコマンド（例えば、追加、修正、及び／又は、削除コマンド）が受信されるＳ１０１０で始まる。Ｓ１０２０で、ドメインコマンドが解析されて、例えば、コマンドが適用するドメイン、適用可能なTLD、コマンドのタイプ、DNS変更などを識別してもよい。方法がＳ１０２２に続く。
【００６３】
Ｓ１０２２で、ドメインコマンドで識別された変更が実行のために処理される。本明細書に述べたように、そのような変更の実行が、例えば、DNSSEC署名機能などの多数の異なるデータベース操作を含む単一のトランザクション（例えば、Ｔ１０２１）に含まれる。Ｓ１０３０およびＳ１０４０で、例のシステム（例えば、図１に示したプロビジョニングシステム１１０）が、ドメインコマンドの結果として、DNSSECデータ（実施されたか、又は実施される変更に基づき、追加及び／又は変更される、かつ／又は、署名又は再署名される必要のある）を識別してもよい。例えば、これは、DNSSEC関連の変更のためのコマンド、オペレーション、及び／又は、データを解析するステップと、署名及び／又は再署名される必要のあるDNSSECデータを識別するステップとを含んでもよい。
【００６４】
Ｓ１０５０で、適したDNSSEC鍵、署名プロトコル（及び／又は、適したＨＳＭ）が、署名される必要のあるデータに基づき識別される。その決定が、例えば、データが存在する、ドメイン、及び／又はドメインのTLDを含むさまざまな要因に基づき実施される。
【００６５】
Ｓ１０６０で、例えば、DNSSECデータが、１又は複数のＨＳＭ（例えば、図２に示されたＨＳＭ３４４，３４８、又は、図１に示されたプロビジョニングシステム１１０に含まれたＨＳＭ）によって署名される。DNSSECデータが署名され、かつ、他のDNS変更が実行されるとき、変更が、レジストリデータベースなどへ保存される。トランザクションＴ１０２１のための要求されたDNS変更、および、DNSSEC署名が完了した後、トランザクションがＳ１０７０でコミットされる。
【００６６】
Ｓ１０７０でのトランザクションコミットの後、Ｓ１０７２で、トランザクションＴ１０２１のためのDNS変更、および、DNSSEC署名が、DNSに発行される。図４に示された方法のステップが、単一のトランザクションの間に完了される関連するDNSSECおよびDNS更新機能のすべての包括的な表示ではないことに注意しなければならない。例えば、多様なDNS更新操作との関連で上記した多様なNSEC更新ステップ（および他の機能）も、当然、トランザクションＴ１０２１に含まれる。
【００６７】
発明者は、最も時間のかかる、したがって、最も最適化されるDNSSECトランザクションの部分が、NSEC３連鎖の更新のすぐ後に続く、電子署名の生成および格納であることが分かった。ドメインのTLDのためのDNSゾーンファイルの内外へドメインが移動するときにはいつでも、NSEC３連鎖の更新が発生することに注意しなければならない。TLDゾーンファイルにふさわしいためには、ドメインが、
そのために定義された委任ネームサーバを備えなければならない。
ホールド状態ではない。
レジストリから削除されない。
【００６８】
したがって、DNSSEC使用可能ドメインのどのような変更でも、そのゾーン状態を変更する可能性を有する。
【００６９】
上記したように、DNSSEC署名が、トランザクションで同時インラインに実行され、かつ、権威レジストリデータベースに保存される。DNS解決が、レジストリデータベースにおいて各コミットされたトランザクションをとることができ、かつ、DNSサーバへ増分的にそれを適用することができる。
【００７０】
本発明の実施例によれば、ドメインレジストリのドメインコマンドをともなうDNSSEC署名インラインが、例えば、レジストリデータベースがDNSにおいて発行される権威ソースを常に示すことを確実にすることによって、最高レベルのデータ完全性を維持することにおいて利点を提供する。また、データ完全性の利点に加えて、DNSSEC署名インラインは、増分更新を効率的に実施する。例えば、ゾーンの一部だけが個別のドメインコマンドによって影響を受け、したがって、ドメインコマンド更新および付加的DNSSEC更新の両方が、仕事の個別ユニット（即ち、個別のトランザクション）としてDNSへ伝搬される。これは、DNSに対するDNSSEC更新を含むドメインレジストリ更新を伝搬するステップにおいて、非常に低い遅延をもたらすことが発明者によって分かった。
【００７１】
DNSSECインライン署名の実施例の一部として、図２，３に示すようなネットワーク対応および高性能の署名サーバ群が、DNSSEC情報を署名するために設けられる。これが、最大のTLDとの関連でさえ効果があることが分かり、かつ、高レベルのデータ完全性を有するDNS伝搬ＳＬＡを維持することと同様に、ドメインレジストリ応答時間ＳＬＡを維持する。
【００７２】
ドメイン更新コマンド（DSレコードを提出するレジストラ（registrar）を含まない）の後、DNSSEC署名が発生することに注意しなければならない。例えば、DNSSEC使用可能ドメインからすべてのネームサーバを削除することは、ドメイン更新コマンドであるが（レジストラがDNSSECデータを渡さない）、それが署名を生成することをもたらす。したがって、本発明の特定の実施例がレジストラ（所定のレジストリに関する複数のレジストラを含む）からのリクエストに応答することに適用されるが、本発明はそのようなシナリオに限定されない。
【００７３】
上記したインライン署名技術に加えて、発明者は、本発明の実施例に従って実施される他の方法も確認した。例えば、発明者は、例えば、レジストリ（又は、他の管理されたサービスプロバイダー）によるDNSSEC署名操作の実施に適用される多様な「ダウンストリームレゾリューションデータベース」および「ルックアサイド」技術を開発した。例のダウンストリームレゾリューションデータベースシステムの実施例が図５を参照して説明される。
【００７４】
図５に示すように、ダウンストリームレゾリューションデータベース技術が、追加のレゾリューションデータベース２２２と、レゾリューションデータベース２２２へレジストリデータベース１２２などからDNS変更を通信するレゾリューションデータベースプロセス３３３とを備えてもよい。上記したように、本明細書で使用されるとき、「データベース」は広く理解しなければならず、かつ、データベース内の離散データスキーマ又はテーブルなどを含んでもよい。ダウンストリームレゾリューションデータベースアプローチでは、ダウンストリームレゾリューションデータベース２２２が、DNS１４０へ増分更新を提供するための権威データベースであってよい。すべての標準ドメインデータ（例えば、非DNSSECデータ）が、追加のDNSSEC処理を伴わないレジストリクライアント１１１からの入力に基づき、レジストリデータベース１２２へ書き込まれる。トランザクションが、レジストリ−レゾリューションデータベースプロセス３３３によって、レゾリューションデータベース２２２へレジストリデータベース１２２から順に伝搬される。レジストリ−レゾリューションデータベースプロセス３３３が、DNSSECに影響を及ぼすトランザクションを識別し、かつ、DNSSEC署名およびレゾリューションデータベース２２２へ書き込まれるレコード更新を実行してもよい。したがって、レゾリューションデータベース２２２が、DNSサーバのネットワークのための権威データベースであってもよい。クラウド内のDNSサーバがレゾリューションデータベース２２２に含まれるもののメモリ内表示であるので、レゾリューションデータベース２２２からDNS１４０へ一方向矢印がある。
【００７５】
そのようなアプローチの１つの利点は、DNSSECのためのレジストリクライアントにさらされる余分な時間又は従属関係がほとんど又は全く存在しないことである（DNSSECプロセスが、レジストリ−レゾリューションデータベースプロセス３３３の別のトランザクションにおいて非同期的に実行されるので）。この点について、発明者は、DNSSECデータを受け入れることができるレジストリが電子署名の時間集約的かつプロセッサ集約的な生成を実行する必要があることに注目している。このため、レジストリが、ＯＬＴＰトランザクションの外部で、これらの署名生成タスクを行うように選択してもよい。これは一般にレジストリに以下を必要とする。
１．レジストリへ／の中に／からDNSSEC関連のドメイン名を追加、更新、又は削除するコマンドを受信する。
２．電子署名データを引いた、操作に起因するデータをレジストリデータベースにコミットする。
３．要求される電子署名を生成して、ＯＬＴＰトランザクションの結果として、DNSSECデータへの変更を反映する。
４．レジストリ／レゾリューションデータベースに電子署名および他のDNSSECデータ（例えば、NSEC又はNSEC３連鎖への変更）をコミットする。
【００７６】
ステップ３，４を自らの別のデータベーストランザクションに分離することにより、レジストリは、ステップ２が完了した後、顧客へ早急な返答を送信することができる（顧客応答時間に影響を及ぼすことなく、非同期的に実行される比較的遅いステップ３，４から離れて）。
【００７７】
上記したプロセスの態様が一般に図６に示されている（本明細書に開示されるダウンストリームレゾリューションデータベースのための例の処理ステップを示す）。他のステップの前（又は後）に生じると特に説明されない限り、図６に示されたステップが、本発明の範囲を逸脱することなく、多様な順序で（及び／又は同時に）行われることに注意しなければならない。
【００７８】
方法がＳ２０１０から始まる（ドメインコマンド（例えば、追加、修正、及び／又は削除コマンド）が受信される）。Ｓ２０２０で、ドメインコマンドが解析されて、例えば、コマンドが適用するドメイン、適用可能なTLD、コマンドのタイプ、DNS変更などを識別する。方法はＳ２０２２に続く。
【００７９】
Ｓ２０２２で、ドメインで識別された変更が、関連の電子署名データを処理することなく、実行のために処理される。これは、電子署名データを引いた、操作に起因するデータをレゾリューションデータベースにコミットするステップを含んでもよい。
【００８０】
Ｓ２０３０で、レジストリが、顧客へＳ２０２２からの変更の完了を報告する（DNSSEC署名機能の状態に拘わらず実行される）。
【００８１】
Ｓ２０３２およびＳ２０４０で、例のシステム（例えば、図５に示したプロビジョニングシステム１１０）が、ドメインコマンドの結果として、実行される変更（又はすでに実行された変更）に基づき、追加及び／又は変更される、及び／又は、署名又は再署名される必要があるDNSSECデータを識別する。これは、例えば、DNSSEC関連の変更のためのコマンド、操作、及び／又はデータを解析するステップ、および、署名及び／又は再署名される必要のあるDNSSECデータを識別するステップを含んでもよい。
【００８２】
Ｓ２０５０で、適したDNSSEC鍵、署名プロトコル、及び／又は適したＨＳＭが、署名される必要のあるデータに基づき識別される。そのような決定が、例えば、ドメイン、及び／又は、ドメインのTLD（データが存在する）を含むさまざまな要因に基づき行われる。
【００８３】
Ｓ２０６０で、例えば、１又は複数のＨＳＭ（例えば、図２に示したＨＳＭ３４４，３４８）、又は、図１に示したプロビジョニングシステム１１０に含まれたＨＳＭによって、DNSSECデータが署名される。DNSSECデータが署名されるとき、変更が、レゾリューションデータベース（例えば、ダウンストリームレゾリューションデータベース２２２）へ保存される。
【００８４】
Ｓ２０７０で、新規に署名されたDNSSECデータがDNSへ発行される。
【００８５】
上記した「ルックアサイド」アプローチに戻ると、そのシステムおよび方法の実施例が図７に示されている。図７に示すように、ルックアサイドアプローチが、単一のレジストリデータベース１２２と、非同期プロセス３３５（DNSSECデータをともなう単一のレジストリデータベース１２２（真のソース）を取り込む）とで実行される（次いで、DNS１４０へ向かって増分的に発行される）。「ルックアサイド」アプローチが、DNSサーバを修正して、追加的ルールを適用するステップ（例えば、特定の保留中のトランザクションを保持すること）、および、保留中のDNSSEC変更がレジストリデータベース１２２で実行された後、リクエストされたデータとともに単に回答するステップを含んでもよい。
【００８６】
ルックアサイドアプローチが、新規のレゾリューションデータベースを追加する必要はないが、代わりに、例えば、レジストリデータベース１２２およびDNSサーバに複製される両方に、一連のルックアサイドテーブル１２４を作成する。レジストリサービス３３５が、プロセス３３５のDNSSEC部分によって処理される保留中の情報でルックアサイドを初めに取り込む追加のロジックを含んでもよい。プロセス２２５が、レジストリデータベース１２２へ書き込まれたDNSSECレコードを署名および管理するために、すべての保留中のルックアサイドトランザクションを処理してもよい。DNSサーバが、保留状態の変更を有するDNSレコードについてクライアントクエリーに回答しないように構成されている。DNSサーバが、例えば、ルックアサイドテーブル１２４の情報に基づき保留中の変更に気が付き、かつ、クリアされて、例えば、完了としてルックアサイドレコードにマークを付ける（及び／又は、ルックアサイドレコードが除去されたと認識する）プロセス３３５によって、データを返してもよい。
【００８７】
ルックアサイドアプローチの１つの利点が、第２レゾリューションデータベースで、複製の情報を必要としないことである。加えて、ルックアサイドアプローチを用いて、非DNSSECトランザクションがDNSSEC処理によって影響を受けない（それらが以前に実行したとき、それらがDNSサーバへ伝搬するので）。例えば、DNSSEC処理の停止が非DNSSEC更新を止める。
【００８８】
例のルックアサイドアプローチの実施例が一般に図８に示されている。他のステップの前（又は後）に発生すると特に説明されない限り、図８に示されたステップが、本発明の範囲を逸脱することなく、多様な順序で（及び／又は、同時に）実行されることに注意しなければならない。
【００８９】
方法がＳ３０１０から始まる（ドメインコマンド（例えば、追加、修正、及び／又は削除コマンド）が受信される）。Ｓ３０２０で、ドメインコマンドが解析されて、例えば、コマンドが適用するドメイン、適用可能なTLD、コマンドのタイプ、DNS変更などを識別する。方法はＳ３０２２に続く。
【００９０】
Ｓ３０２２で、ドメインコマンドで識別された変更が、関連の電子署名データを処理することなく、実行のために処理される。これは、電子署名データを引いた、操作に起因するデータをレジストリデータベースにコミットするステップを含んでもよい。
【００９１】
Ｓ３０３０およびＳ３０３２で、例のシステム（例えば、図５に示したプロビジョニングシステム１１０）が、ドメインコマンドの結果として、実行される（又はすでに実行された）変更に基づき、追加及び／又は変更される、及び／又は、署名又は再署名される必要のあるDNSSECデータを識別する。これは、例えば、DNSSEC関連の変更のためのコマンド、操作、及び／又はデータを解析するステップ、および、署名及び／又は再署名される必要のあるDNSSECデータを識別するステップを具備してもよい。
【００９２】
Ｓ３０４０で、データベースエントリが、例えば、ドメインコマンドに関する保留中のDNSSEC変更が存在することを示す、新規又は既存のルックアサイドテーブルの一部として、作成される。
【００９３】
Ｓ３０４２で、データベースエントリが、DNSへ発行される（例えば、新規（又は既存への更新）のルックアサイドテーブルの一部として）。
【００９４】
Ｓ３０５０で、適したDNSSEC鍵、署名プロトコル、及び／又は適したＨＳＭが、署名される必要のあるデータに基づき識別される。そのような決定が、例えば、ドメイン、及び／又は、ドメインのTLD（データが存在する）を含むさまざまな要因に基づき行われる。
【００９５】
Ｓ３０６０で、例えば、１又は複数のＨＳＭ（例えば、図２に示したＨＳＭ３４４，３４８）、又は、図１に示したプロビジョニングシステム１１０に含まれたＨＳＭによって、DNSSECデータが署名される。DNSSECデータが署名されるとき、変更が、レゾリューションデータベース（例えば、ダウンストリームレゾリューションデータベース２２２）へ保存される。
【００９６】
Ｓ３０７０で、新規に署名されたDNSSECデータがDNSへ発行される。加えて、データベースエントリが、例えば、ルックアサイドテーブルのエントリをクリアする（又は、ルックアサイドテーブルを削除する）ことによって、クリアされる。ルックアサイドテーブルへの変更もDNSへ発行される。
【００９７】
実施例では、DNSSECエンジンも、常にレゾリューションシステムのデータの一貫し、安定したイメージを提供するように構成され、かつ、これらのイベントが後のイベントによって陳腐化するとき、未処理のイベントをスキップするためのさらなる最適化アルゴリズムを含んでもよい（例えば、最新のイベントが全くレジストリシステムから削除される結果をもたらす、ドメインのための待ち行列のDNSSECイベントを処理する必要がないことを認識すること）。
【００９８】
本発明の実施例が、上記した方法をコンピュータに実行させるための命令でコード化されたコンピュータ読み取り可能な記録媒体と同様に、上記した方法を実施するためのシステムを備えることができる。例えば、図９に示すように、サーバシステム（例えば、サーバ６００，６１０、及び／又は６２０）（少なくともプロセッサ、メモリ、および電子通信デバイス（図示せず）を備える）が、ネットワーク６０５（例えば、インターネット）を介して受信されるリクエスト（例えば、本明細書に開示されたリクエスト）に関して、受信、識別、応答、及び／又は、動作するように構成される。サーバ６００，６１０、及び／又は６２０のいずれかが、例えば、本明細書に詳細に開示されたインターネットホスティングプロバイダー、レジストラ、及び／又はレジストリによって操作され、かつ、ウェブデバイス６３０によって一般的に表わされた、いくつもの再帰的DNSサーバと通信する。本明細書に開示されたように、再帰的サーバ６３０が、ホスティングプロバイダー、レジストラ、及び／又は、レジストリオペレーティングサーバ６００，６１０、および６２０のドメインのためのDNS関連のデータをキャッシュしてもよい。
【００９９】
ドメインについてDNSデータを更新するリクエストが、例えば、レジストラ、DNSサービスプロバイダー、又は、登録者に由来してもよい（多様なシステム（例えば、コンピュータ６１１，６１２）を介して、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ６１６、又は、必要な機能を備えた他のネットワーク対応デバイスと無線又は他の通信を行う別のサーバ６１３を介して）。
【０１００】
多様な通信、送信、および本明細書に開示された関連の機能が、例えば、ネットワーク６０５を介して実行され、かつ、サーバシステム（例えば、サーバ６００，６１０、および６２０）によって実行される開示された処理の結果が、既知の方法に従って、表示、格納、及び／又は、配布される。ネットワーク６０５が、いくつもの通信コンポーネント（有線、セル、衛星、光、及び／又は他の類似の通信リンクを含む）を含んでもよい。
【０１０１】
サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、第１ストレージ（図示せず、一般にランダムアクセスメモリ、又はRAM）、第２ストレージ（図示せず、一般にリードオンリーメモリ、又はROM）を含むストレージデバイスに接続されたいくつものプロセッサ（図示せず）を備えてもよい。これらストレージデバイスの両方が、適したタイプのコンピュータ読み取り可能な記録媒体（非一時的なストレージ媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、磁気テープ）、CD-ROMディスクなどの光媒体、及び／又は、光磁気媒体を含む）を含む。また、マスストレージデバイス（図示せず）が、プログラム、データなどを格納するのに使用され、かつ、一般に補助記憶媒体（例えば、主記憶装置よりも遅いハードディスク）である。好ましくは、マスストレージデバイス内に保持される情報が、仮想メモリとして、主記憶装置の一部として、一般的な方法で、組み込まれることが理解される。また、具体的なマスストレージデバイス（例えば、CD-ROM）がプロセッサへ一方向的にデータを渡してもよい。
【０１０２】
また、サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、１又は複数の入出力デバイス（例えば、ビデオモニタ、トラックボール、マウス、キーボード、マイク、タッチセンサ式のディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、又は、他の既知の入力デバイス）（他のコンピュータを含む）を含むインターフェースを備えてもよい。サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、ネットワーク接続を使用して、コンピュータ又は他の電気通信ネットワーク６０５に接続される。ネットワーク６０５が、多様な有線、光、電気、および他の既知のネットワークに接続して、サーバ６００，６１０、および６２０、コンピュータ６１１，６１２、別のサーバ６１３、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ（複数可）６１６、再帰的サーバ６３０、および、類似の機能を有する他のデバイスの間で、情報を交換することができる。そのネットワーク接続を用いて、上記した方法のステップを実行する過程で、サーバ６００，６１０、および６２０（およびコンピュータ６１１，６１２）およびそのプロセッサが、ネットワーク６０５から情報を受信するか、又は、ネットワーク６０５へ情報を出力すると考えられる。上記したデバイスおよび素材は、コンピュータハードウェアおよびソフトウェア技術の当業者によく知られており、当業者に理解されるように個別又は網羅的に示す必要はない。上記したハードウェア要素が、上記した操作を実行するための１又は複数のモジュールとして動作するように（一般的に一時的に）構成される。
【０１０３】
加えて、本発明の実施例は、さらに、本明細書に開示された多様なコンピュータ実行オペレーションを実行するためのプログラム命令を含んだコンピュータ読み取り可能な記録媒体を含む。媒体が、単独で、又はプログラム命令と組み合わせて、データファイル、データ構造、テーブルなども含んでもよい。媒体およびプログラム命令が、本発明の目的のために特に設計されかつ構成されたものであってもよく、又は、それらが、コンピュータソフトウェア技術のスキルを有する人に使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例が、磁気媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、および磁気テープ）、光媒体（例えば、CD-ROMディスク）、光磁気媒体、および、プログラム命令を格納および実行するように特に構成されたハードウェアデバイス（例えば、リードオンリーメモリデバイス（ROM）、および、ランダムアクセスメモリ（RAM））を含む。プログラム命令の例が、機械コード（例えば、コンパイラによって生成される）、および、インタプリタを使用してコンピュータによって実行される高次レベルコードを含むファイルの両方を含む。
【０１０４】
上記した説明は、単に実例であり、本発明のすべての可能性のある実施例、アプリケーション、又は、変形例の網羅的なリストであることを意図されたものではない。したがって、開示された本発明の方法およびシステムの多様な修正例および変形例が、本発明の真の趣旨及び範囲から逸脱することなく、当業者に明らかになる。本発明は特定の実施例との関連で開示されたが、請求項に係る発明がその特定の実施例に不当に限定されないことを理解しなければならない。
【符号の説明】
【０１０５】
320 NCCビジネスサービス
330 バッチ/ツール
342 署名サーバ1
346 署名サーバn
350 データベース
510 クライアント
512 署名サーバ
520 レジストリ
【特許請求の範囲】
【請求項１】
レジストリでDNSSEC署名を実行する方法であって、
リクエスタからドメインの識別子を含んだドメインコマンドを受信するステップと、
前記ドメインのためのレジストリによって格納されたデータに関して、前記受信されたドメインコマンドを実行するステップと、
DNSSECデータ変更を識別するステップと、
前記ドメインコマンドの実行を含む個別のトランザクションの一部として、権威サーバの秘密鍵を使用して、前記識別されたDNSSECデータ変更に基づき、ドメインのためのDNSSECレコードに署名するステップと、
前記レジストリでトランザクションをコミットするステップと、
DNS基盤へ前記コミットされたトランザクションを伝えるステップと
を具備する方法。
【請求項２】
前記ドメインコマンドは、１又は複数のDNSSEC DS（Delegation Signer）要素を含む請求項１に記載の方法。
【請求項３】
前記ドメインコマンドは、１又は複数の関連するDNSSEC DS（Delegation Signer）レコードを生成する１又は複数のDNSKEY要素を含む請求項１に記載の方法。
【請求項４】
別のサーバへ前記署名されたDNSSECレコードを増分的に発行するステップをさらに具備する請求項１に記載の方法。
【請求項５】
前記署名されたDNSSECレコードが、複数の別のDNSサーバへ増分的に発行される請求項４に記載の方法。
【請求項６】
前記ドメインが、レジストリのトップレベルドメインの下の少なくとも第２レベルドメインである請求項１に記載の方法。
【請求項７】
前記方法が、レジストリの権威サーバによって、複数のレジストラからのドメインについて実行される請求項１に記載の方法。
【請求項８】
DNSレコードの署名が、レジストリの権威サーバによって、複数のレジストラからの少なくとも２つのドメインについて実行される請求項１に記載の方法。
【請求項９】
DNSレコードの署名が、レジストリのための複数の署名サーバによって実行される請求項１に記載の方法。
【請求項１０】
前記ドメインコマンドが、ドメインのための追加、更新、および削除コマンドのうちの少なくとも１つである請求項１に記載の方法。
【請求項１１】
追加、更新、および削除コマンドのうちの少なくとも１つに基づき、NSEC又はNSEC３連鎖へ変更をコミットするステップをさらに具備する請求項１に記載の方法。
【請求項１２】
レジストリのためのDNSSEC署名システムであって、
プロセッサと、
前記プロセッサによって実行されたとき、
前記レジストリによってサポートされたDNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つを実行するリクエスタから第１コマンドを受信し、
レジストリデータベースに格納されたデータを追加、更新、又は削除する前記第１コマンドからの命令を実行し、
前記第１コマンドからの命令の実行を含む個別のトランザクションの一部として、追加、更新、又は削除変更に基づき、電子署名を生成し、
レジストリレゾリューションデータベースへ前記電子署名をコミットする
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備えたシステム。
【請求項１３】
前記ドメインが、レジストリのトップレベルドメインの下の少なくとも第２レベルドメインである請求項１２に記載のシステム。
【請求項１４】
前記プロセッサが、複数のレジストラからの少なくとも２つのドメインのためのDNSレコードに署名するように構成された請求項１２に記載のシステム。
【請求項１５】
前記プロセッサが、さらに、複数の別のDNSサーバへ前記署名されたDNSSECレコードを増分的に発行するように構成された請求項１２に記載のシステム。
【請求項１６】
前記レジストリのためのDNSレコードに署名するように構成された複数の署名サーバをさらに備えた請求項１２に記載のシステム。
【請求項１７】
前記プロセッサが、さらに、追加、更新、および削除コマンドのうちの少なくとも１つに基づき、NSEC又はNSEC３連鎖へ変更をコミットするように構成された請求項１２に記載のシステム。
【請求項１８】
レジストリのためのDNSSEC署名システムであって、
プロセッサと、
前記プロセッサによって実行されたとき、
前記レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つを実行するリクエスタから第１コマンドを受信し、
レジストリデータベースに格納されたデータを追加、更新、及び／又は削除する前記第１コマンドからの命令を実行し、
前記命令が実行されたことをリクエスタへ報告し、
前記追加、更新、及び／又は削除の変更に基づき、電子署名を生成し、
レジストリレゾリューションデータベースへ前記電子署名をコミットする
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備え、
前記実行が電子署名データを適用することを含まないことを特徴とするシステム。
【請求項１９】
非DNSSEC変更およびDNSSEC変更が、DNSへ非同期的に前記システムによって発行される請求項１８に記載のシステム。
【請求項２０】
前記プロセッサが、さらに、前記追加、更新、及び／又は削除変更に基づき、NSEC又はNSEC３連鎖へ変更をコミットするように構成された請求項１９に記載のシステム。
【請求項２１】
レジストリのためのDNSSEC署名システムであって、
プロセッサと、
前記プロセッサによって実行されたとき、
前記レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つを実行するリクエスタから第１コマンドを受信し、
レジストリデータベースに格納されたデータを追加、更新、及び／又は削除する前記第１コマンドからの命令を実行し、
前記第１コマンドに関する保留中のDNSSEC変更を示すデータベースエントリを生成し、
前記追加、更新、及び／又は削除変更に基づき、電子署名を生成し、かつ、
前記データベースエントリをクリアする
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備え、
前記実行が電子署名データを適用することを含まないことを特徴とするシステム。
【請求項２２】
前記プロセッサが、さらに、DNSへ前記データベースエントリを発行するように構成された請求項２１に記載のシステム。
【請求項２３】
前記プロセッサが、さらに、前記追加、更新、及び／又は削除変更に基づき、NSEC又はNSEC３連鎖へ変更をコミットするように構成された請求項２１に記載のシステム。
【請求項１】
レジストリでDNSSEC署名を実行する方法であって、
リクエスタからドメインの識別子を含んだドメインコマンドを受信するステップと、
前記ドメインのためのレジストリによって格納されたデータに関して、前記受信されたドメインコマンドを実行するステップと、
DNSSECデータ変更を識別するステップと、
前記ドメインコマンドの実行を含む個別のトランザクションの一部として、権威サーバの秘密鍵を使用して、前記識別されたDNSSECデータ変更に基づき、ドメインのためのDNSSECレコードに署名するステップと、
前記レジストリでトランザクションをコミットするステップと、
DNS基盤へ前記コミットされたトランザクションを伝えるステップと
を具備する方法。
【請求項２】
前記ドメインコマンドは、１又は複数のDNSSEC DS（Delegation Signer）要素を含む請求項１に記載の方法。
【請求項３】
前記ドメインコマンドは、１又は複数の関連するDNSSEC DS（Delegation Signer）レコードを生成する１又は複数のDNSKEY要素を含む請求項１に記載の方法。
【請求項４】
別のサーバへ前記署名されたDNSSECレコードを増分的に発行するステップをさらに具備する請求項１に記載の方法。
【請求項５】
前記署名されたDNSSECレコードが、複数の別のDNSサーバへ増分的に発行される請求項４に記載の方法。
【請求項６】
前記ドメインが、レジストリのトップレベルドメインの下の少なくとも第２レベルドメインである請求項１に記載の方法。
【請求項７】
前記方法が、レジストリの権威サーバによって、複数のレジストラからのドメインについて実行される請求項１に記載の方法。
【請求項８】
DNSレコードの署名が、レジストリの権威サーバによって、複数のレジストラからの少なくとも２つのドメインについて実行される請求項１に記載の方法。
【請求項９】
DNSレコードの署名が、レジストリのための複数の署名サーバによって実行される請求項１に記載の方法。
【請求項１０】
前記ドメインコマンドが、ドメインのための追加、更新、および削除コマンドのうちの少なくとも１つである請求項１に記載の方法。
【請求項１１】
追加、更新、および削除コマンドのうちの少なくとも１つに基づき、NSEC又はNSEC３連鎖へ変更をコミットするステップをさらに具備する請求項１に記載の方法。
【請求項１２】
レジストリのためのDNSSEC署名システムであって、
プロセッサと、
前記プロセッサによって実行されたとき、
前記レジストリによってサポートされたDNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つを実行するリクエスタから第１コマンドを受信し、
レジストリデータベースに格納されたデータを追加、更新、又は削除する前記第１コマンドからの命令を実行し、
前記第１コマンドからの命令の実行を含む個別のトランザクションの一部として、追加、更新、又は削除変更に基づき、電子署名を生成し、
レジストリレゾリューションデータベースへ前記電子署名をコミットする
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備えたシステム。
【請求項１３】
前記ドメインが、レジストリのトップレベルドメインの下の少なくとも第２レベルドメインである請求項１２に記載のシステム。
【請求項１４】
前記プロセッサが、複数のレジストラからの少なくとも２つのドメインのためのDNSレコードに署名するように構成された請求項１２に記載のシステム。
【請求項１５】
前記プロセッサが、さらに、複数の別のDNSサーバへ前記署名されたDNSSECレコードを増分的に発行するように構成された請求項１２に記載のシステム。
【請求項１６】
前記レジストリのためのDNSレコードに署名するように構成された複数の署名サーバをさらに備えた請求項１２に記載のシステム。
【請求項１７】
前記プロセッサが、さらに、追加、更新、および削除コマンドのうちの少なくとも１つに基づき、NSEC又はNSEC３連鎖へ変更をコミットするように構成された請求項１２に記載のシステム。
【請求項１８】
レジストリのためのDNSSEC署名システムであって、
プロセッサと、
前記プロセッサによって実行されたとき、
前記レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つを実行するリクエスタから第１コマンドを受信し、
レジストリデータベースに格納されたデータを追加、更新、及び／又は削除する前記第１コマンドからの命令を実行し、
前記命令が実行されたことをリクエスタへ報告し、
前記追加、更新、及び／又は削除の変更に基づき、電子署名を生成し、
レジストリレゾリューションデータベースへ前記電子署名をコミットする
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備え、
前記実行が電子署名データを適用することを含まないことを特徴とするシステム。
【請求項１９】
非DNSSEC変更およびDNSSEC変更が、DNSへ非同期的に前記システムによって発行される請求項１８に記載のシステム。
【請求項２０】
前記プロセッサが、さらに、前記追加、更新、及び／又は削除変更に基づき、NSEC又はNSEC３連鎖へ変更をコミットするように構成された請求項１９に記載のシステム。
【請求項２１】
レジストリのためのDNSSEC署名システムであって、
プロセッサと、
前記プロセッサによって実行されたとき、
前記レジストリへ、レジストリの中に、又はレジストリから、DNSSEC関連のドメイン名を追加、更新、又は削除するうちの少なくとも１つを実行するリクエスタから第１コマンドを受信し、
レジストリデータベースに格納されたデータを追加、更新、及び／又は削除する前記第１コマンドからの命令を実行し、
前記第１コマンドに関する保留中のDNSSEC変更を示すデータベースエントリを生成し、
前記追加、更新、及び／又は削除変更に基づき、電子署名を生成し、かつ、
前記データベースエントリをクリアする
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備え、
前記実行が電子署名データを適用することを含まないことを特徴とするシステム。
【請求項２２】
前記プロセッサが、さらに、DNSへ前記データベースエントリを発行するように構成された請求項２１に記載のシステム。
【請求項２３】
前記プロセッサが、さらに、前記追加、更新、及び／又は削除変更に基づき、NSEC又はNSEC３連鎖へ変更をコミットするように構成された請求項２１に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−２３５４６２（Ｐ２０１２−２３５４６２Ａ）
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１００８９６（Ｐ２０１２−１００８９６）
【出願日】平成２４年４月２６日（２０１２．４．２６）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願番号】特願２０１２−１００８９６（Ｐ２０１２−１００８９６）
【出願日】平成２４年４月２６日（２０１２．４．２６）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
[ Back to top ]