ＤＮＳＳＥＣ署名サーバ
【課題】DNSSEC署名を実施するためのシステムおよび方法を提供する。
【解決手段】DNSSEC署名を実施するためのシステムおよび方法が開示され、別のクライアントアプリケーションと相互作用するように構成されたネットワークアクセス可能な署名サーバによって、電子署名操作が実行される。例の方法が、第１データを署名するクライアントアプリケーションから署名サーバで署名リクエストを受信するステップを含む。署名サーバが、第１データに対するアクティブなKSK及び／又はアクティブなZSKを決定する。次いで、第１データが署名サーバによって電子署名モジュールへ転送され、例えば、ハードウェアサポートモジュール又はソフトウェア署名アプリケーションを含む。署名サーバが、電子署名モジュールから電子的に署名されたバージョンの第１データを受信し、かつ、クライアントアプリケーションへ署名された第１データを提供する。
【解決手段】DNSSEC署名を実施するためのシステムおよび方法が開示され、別のクライアントアプリケーションと相互作用するように構成されたネットワークアクセス可能な署名サーバによって、電子署名操作が実行される。例の方法が、第１データを署名するクライアントアプリケーションから署名サーバで署名リクエストを受信するステップを含む。署名サーバが、第１データに対するアクティブなKSK及び／又はアクティブなZSKを決定する。次いで、第１データが署名サーバによって電子署名モジュールへ転送され、例えば、ハードウェアサポートモジュール又はソフトウェア署名アプリケーションを含む。署名サーバが、電子署名モジュールから電子的に署名されたバージョンの第１データを受信し、かつ、クライアントアプリケーションへ署名された第１データを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は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およびNSEC３レコードは、存在しないDNSレコードに対して認証された存在の否定の応答を提供するのに使用される。
【００１２】
DNSSECの要求は、異なる鍵（DNSKEYレコードの両方に格納され、かつ、信頼アンカーを形成する他のソースから）の使用を含む。例えば、KSK（Key Signing Keys）（他のDNSKEYレコードに署名するために使用される）およびZSK（Zone Signing Keys）（他のレコードに署名するために使用される）が存在する。ZSKは固有のDNSゾーンの制御および使用下にあるので、それらはより容易かつより頻繁に切り替えることができる。その結果、ZSKは一般にKSKより短く（バイト長に関して）、その上、容認可能なレベルの保護を提供する。
【００１３】
プロトコルはDNSSEC（KSKおよびZSKの使用を含む）の利用に対して開発されているが、レジストラおよびレジストリレベルで、大規模な使用に対して対処及び／又は最適化されていないDNSSEC使用可能なドメインを運用するさまざまな態様が存在する。例えば、短い期間に多数の署名を処理する能力が、スタンドアローン署名システムを使用すること、および、ゾーンへの変更に基づいてゾーン全体に署名することの一般的な方法に限定されている。加えて、多くのソリューションが、個別のユーザ、又は、特定のDNSプロバイダーによって管理される限定された数のドメインなどに限定されている。したがって、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ホスティングを移行又は外部委託することを要求される。
【００１５】
しかし、膨大なレジストリ（例えば、.comおよび.netレジストリ）へのDNSSECの導入にともなって、DNSSECデータに対するさまざまな署名技術における効率の悪さ（特に、大規模なゾーンに関して）が、遅延および解決失敗を含む解決に関する潜在的課題をもたらす。そのような課題が、電子商取引および他の高トラフィックサイトに大きな弊害をもたらす。
【００１６】
本発明は、リモートアプリケーションに対して署名を管理することを可能し、かつ、必要に応じてゾーンデータの一部にリモートに署名することを可能にするネットワークアクセス可能な署名サーバの使用を通じて、DNSSEC使用可能なゾーンの効率的な署名において利点を提供する。本発明の態様によれば、ネットワークアクセス可能な署名サーバの使用により、これら機能が本質的にマージされる他の方法に比べて（例えば、ネームサーバが署名を実行する方法において、又は、特定のゾーン管理デバイスが署名する場合において）、署名メカニズムから、ゾーン管理およびゾーンサービングアプリケーションの分離を提供する。
【００１７】
また、例えば、拡張可能な、ネットワークアクセス可能な署名サーバの使用を通じて、例の構成が、他の既知の方法に比べて、署名サーバの多様な機能を手動設定する必要を減らす（又は、取り除く）。また、ネットワークアクセス可能な署名サーバが、手動設定を必要とせず、以下を含む幅広いDNSSECアプリケーションのサポートを提供してもよい。
１．大量のDNSSECアプリケーションのリソースレコードのインライン署名（例えば、ＴＬＤレジストリ）
２．動的な鍵の作成、鍵のローディング、鍵の非ローディング、および、多くの鍵およびゾーンを有するDNSSECアプリケーションのゾーンデータに署名する鍵の使用
３．オフライン／バッチDNSSECアプリケーションのゾーン全体の署名（例えば、ルートゾーン）
【００１８】
態様では、DNSSEC署名を実行するためのシステムおよび方法が、別のクライアントアプリケーションと相互作用するように構成された署名サーバによって実行される。例の方法が、一般に、第１データを署名するクライアントアプリケーションから署名サーバで署名リクエストを受信するステップを含んでもよい。署名サーバが、第１データに対して、適した署名鍵及び／又はプロトコルを決定してもよい。次いで、第１データが、署名サーバによって電子署名モジュールへ転送され、例えば、ハードウェアサポートモジュール、又は、ソフトウェア署名アプリケーションを含む。署名サーバが、電子署名モジュールから、電子的に署名されたバージョンの第１データを受信し、かつ、クライアントアプリケーションへ署名された第１データを提供する。
【００１９】
本発明の第１態様によれば、DNSSEC署名サーバが、少なくとも１つのDNSSECクライアントアプリケーション、および、電子署名モジュールと相互作用するように構成されている。例えば、DNSSEC署名サーバが、プロセッサ、および、プロセッサによって実行されたとき、第１データを署名する少なくとも１つのクライアントアプリケーションから署名リクエストを受信するように構成された権威署名サーバとして、署名サーバを動作させるコンピュータ読み取り可能なコードを含むストレージデバイスを含んでもよい。例えば、第１データがDNSデータを含む。
【００２０】
態様では、署名サーバが、第１データに対して、適した署名鍵（例えば、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つ）を決定してもよい。適した鍵（例えば、少なくとも１つのアクティブなKSKおよびアクティブなZSK）が、例えば、署名リクエストに含まれたTLD識別子に基づき決定される。態様では、署名サーバが、第１データに対して、１つより多くのアクティブな署名鍵、及び／又は、アクティブな署名アルゴリズムを決定するように構成され、かつ、１つより多くのアクティブな署名鍵、及び／又は、アクティブな署名アルゴリズムに基づき、第１データに対する複数の異なる署名をリクエストしてもよい。
【００２１】
態様では、署名サーバが、複数の電子署名モジュールのうちの１つへ第１データを転送し、かつ、電子署名モジュールから、電子的に署名されたバージョンの第１データを受信してもよい。また、署名サーバが、クライアントアプリケーションへ署名された第１データを提供するように構成される。
【００２２】
態様では、署名サーバが、署名リクエストに含まれたサービスタイプ識別子に基づき、複数の異なる電子署名機能の中から、リクエストされた署名機能を区別し、かつ、サービスタイプ識別子に基づき、非DNSSEC電子署名モジュールへ非DNSSEC署名リクエストを送るように構成される。
【００２３】
本発明のさらなる態様によれば、また、署名サーバが、第２データに署名するリクエストを、同じ署名リクエストの一部として、受信するように構成される。第２データが、例えば、DNSデータ又は他のデータである。署名サーバが、第２データに対して、適した署名鍵（例えば、アクティブなKSKおよびアクティブなＺＫＳのうちの少なくとも１つ）を決定し、第１データで使用される鍵とは異なる。例えば、署名サーバが、第１データに対する第１セットの鍵、および、第２データに対する第２セットの鍵を決定してもよい。
【００２４】
態様では、署名サーバが、複数の電子署名モジュールのうちの１つへ、第２データを転送してもよく、かつ、電子署名モジュールから、電子的に署名されたバージョンの第２データを受信してもよい。また、署名サーバが、クライアントアプリケーションへ署名された第２データを提供するように構成される。
【００２５】
態様が、単一のリクエストパケットの一部として複数の署名リクエストを受信し、かつ、リクエストパケットを解析して、相互に異なるアクティブなKSK、アクティブなZSK、および署名プロトコルのうちの少なくとも１つを有する異なる署名リクエストを識別するように構成された、署名サーバを備えてもよい。
【００２６】
態様では、電子署名モジュールが、ゾーン全体に署名せず、DNSSECプロトコルに従って、DNSデータの特定の部分に署名するように構成される。
【００２７】
態様では、また、署名サーバが、追加的な非DNSSEC電子署名機能を提供するように構成される。
【００２８】
態様では、電子署名モジュールのそれぞれが、ＨＳＭ（Hardware Support Module）を備え、署名サーバのプロセッサから物理的に離れ、かつ、署名サーバによって提供されたデータに電子的に署名するように構成される。
【００２９】
態様では、ＨＳＭが、エイリアス識別子によって識別された複数の鍵を具備している。署名サーバが、電子署名モジュールへ少なくとも１つのKSKおよびZSKを渡さず、電子署名モジュールへ使用される適した鍵のためのエイリアス識別子（例えば、DNSデータに対するKSKおよびZSKのうちの少なくとも１つ）を渡すように構成される。
【００３０】
態様では、署名サーバが、アクティブな鍵（例えば、アクティブなKSK又はZSK）のデータベースを周期的にチェックするように構成され、かつ、データベースから受信された情報に基づき、所定の時間にわたりどのエイリアス識別子がアクティブであるかを決定するように構成される。態様では、電子署名モジュールに渡されたエイリアス識別子が、アクティブなエイリアス識別子である。
【００３１】
態様では、署名サーバが、少なくとも１つのアクティブなKSK及び／又はアクティブなZSKに基づき、特定のＨＳＭを識別して、第１データを送信するように構成される。
【００３２】
態様では、署名サーバが、異なるTLDの下のドメインに関するリクエストを処理するように構成される。
【００３３】
態様では、署名サーバが、複数のレジストラによって管理された少なくとも２つのドメインに関するリクエストを処理するように構成される。
【００３４】
態様では、クライアントと署名サーバとの間の通信が、例えば、２方向ＳＳＬを介して、実行される。
【００３５】
本明細書に述べるように、例の署名サーバが、無数の異なるシステムによって実施される、例えば、DNSSEC署名機能、他の管理DNSサービス、リモート署名、ルートゾーン署名などを含む、多様なDNS署名操作をサポートしてもよい。態様では、例えば、例の署名サーバが、本明細書では「インライン署名（inline signing）」と称される単一のトランザクション（例えば、極小の、一貫した、分離された、かつ、耐久性のある仕事のユニット）態様の一部として、影響されるDNSSECレコードの署名をサポートするように構成される。
【００３６】
追加的な特徴、利点、および本発明の態様は、以下の詳細な説明、図面、および請求項の検討から、説明され、又は明らかである。さらに、上記した本発明の概要および以下の詳細な説明の両方が、例示であり、かつ、本発明の特許請求の範囲を限定することなくさらなる説明を提供することを意図したものであることを理解しなければならない。しかし、詳細な説明および特定の例は、単に本発明の好ましい実施例を示したものである。本発明の真の趣旨および範囲から逸脱することなく、多様な変形例および改良例が詳細な説明から当業者には明らかとなる。
【００３７】
本発明のさらなる理解を提供するよう含まれた添付の図面が、組み込まれ、本明細書の一部を構成し、本発明の実施例を図示し、詳細な説明とともに、本発明の原理を説明するのに用いられる。本発明の基本的理解および実施される多様な方法に必要であるよりもさらに詳細に本発明の構造的詳細を示していない。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施例の例のDNSSEC使用可能な署名システムの詳細図である。
【図２】本発明の実施例の例のDNSSEC使用可能な署名システムのさらなる詳細図である。
【図３】本発明の実施例の例の署名リクエストプロトコルである。
【図４】本発明の実施例の例の署名リクエストデータプロトコルである。
【図５】本発明の実施例の別の例の署名リクエストデータプロトコルである。
【図６】本発明の実施例の例の署名応答プロトコルである。
【図７】本発明の実施例の例の署名応答データプロトコルである。
【図８】本発明の実施例の別の例の署名応答データプロトコルである。
【図９】本発明の実施例の例のリクエスト、リクエストデータ、応答、および応答データの関係図である。
【図１０】本発明の実施例の署名サービスクライアントプールマネージャを含む例のDNSSEC使用可能な署名システムのさらなる詳細図である。
【図１１】本発明の実施例に従ってサポートされるDNSSEC署名のための例のインライン署名方法のための概略システム構成である。
【図１２】本発明の実施例で使用される例のコンピュータネットワークアーキテクチャの図である。
【発明を実施するための形態】
【００３９】
本発明が本明細書に開示された特定の方法、プロトコルなどに限定されないことが理解される（当業者に理解されるようにそれらが多様に変化するため）。また、本明細書に使用された用語が特定の実施例だけを説明する目的に使用され、本発明の範囲を限定することを意図しないことを理解しなければならない。また、本明細書および特許請求の範囲に使用されるとき、単数形態”a”、“an”および“the”は、コンテキストが明確に指定しない限り、複数の言及を含むことに注意しなければならない。したがって、例えば、「サーバ」への言及は、１又は複数のサーバ、および、当業者に既知のその均等物への言及である。
【００４０】
他に定義されない限り、本明細書で使用される技術用語は、本発明が関わる当業者に一般に理解されるものと同じ意味を有する。本発明の実施例、および、多様な特徴、および、それについての利点の詳細は、添付の図面に説明及び／又は図示され、かつ、以下の説明に詳述された非限定的な実施例および実例を参照してさらに完全に説明される。図面に示された特徴は必ずしも一定の縮尺で描かれておらず、かつ、仮に本明細書に明確に述べられていなくても、１つの実施例の特徴が、当業者が理解するように他の実施例で利用されることに注意しなければならない。周知のコンポーネントおよび処理技術の記載は、本発明の実施例を不必要に分かりにくくしないように省略される。本明細書に使用された例は、単に、本発明が実施される方法の理解を助けること、および、当業者が本発明の態様を実施することをさらに可能にすることを目的としている。したがって、本明細書の実施例および実例は、本発明の範囲を限定するものとして解釈されるべきでなく、特許請求の範囲および適用される法によってのみ定義される。さらに、類似の参照数字が図面のいくつかの表示にわたって同様の部分を参照することに注意しなければならない。
【００４１】
本明細書で使用されるとき、他に限定されない限り、レジストラ（registrar）は、ドメイン名レジストリと相互作用し、かつ、登録者(registrant)がドメイン名リソースを作成および更新することを可能にするエンティティ又は組織であると理解される。
【００４２】
本明細書で使用されるとき、他に限定されない限り、登録者は、ドメイン名リソースを作成および更新するレジストラと相互作用する人又は組織であると理解される。
【００４３】
本明細書で使用されるとき、他に限定されない限り、DNSホスティングプロバイダーは、DNSプロビジョニングおよびそのコンテンツについて解決能力を提供する、登録者の代わりに、そのサーバにコンテンツをホストするエンティティ又は組織であると理解される（例えば、IPアドレスを割り当て、それが管理するそれらのIPアドレスへドメイン名を解決することができるネームサーバを運営する）。
【００４４】
本発明の実施例が、大規模なDNSSECプロバイダー（例えば、レジストリ）により、効果的かつ一貫した方法で、多様なソースからの多数のDNS変更（DNSSEC署名データを含む）を処理することができる、ネットワークアクセス可能な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は、アクティブなKSKおよびZSKの両方によって署名される。他のRRセットはアクティブなZSKだけによって署名される。
【００５３】
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３レコードの自らの名前の第１ラベルにおいてハッシュ値によってカバーされる名前に対して存在するレコードタイプ
【００５７】
例の署名サーバ構成が図１に示されている。図１に示すように、レジストリ（又は、DNSSECサービスプロバイダー）が、いくつもの署名サーバ１４２，１４６を備えてもよい。例えば、複数の署名サーバが、レジストリプロビジョニングシステムを含んでもよい。署名サーバ１４２，１４６が、適切な電子署名鍵を含む実際の電子署名機能を含むＨＳＭ（Hardware Security Module）１４４，１４８（及び／又は、ソフトウェア）をそれぞれ含んでもよい。署名サーバ１４２，１４６が、多様なアプリケーション、サービス、およびツール１１０，１２０，１３０と通信してもよい（かつ、例えば、署名されたDNSデータおよび未署名のDNSデータを交換してもよい）。各ＣＡＳ１１０、ＮＣＣプラグインビジネスサービス１２０、およびバッチ／ツール１３０コンポーネントが、署名サーバ（好ましくは、一連のそのようなサーバ）への接続を有する。署名サーバ１４２，１４６が、データベース１５０へ署名されたDNSデータを保存してもよい。アプリケーション、署名サーバ、ＨＳＭ、およびデータベースの間の例のデータフローの追加的な詳細が図２に示されている。
【００５８】
図２に示すように、例えば、クライアント２１０が、プロビジョニングシステムのフロントエンドサービスを表す（署名サーバ２１２によって署名される必要があるDNSSECデータを識別するように構成される）。署名されるデータが、例えば、DNS変更（例えば、ドメインに対する追加、更新、削除コマンド）によって影響されるゾーンデータの一部であってもよい。署名されるDNSSECデータ（又は、他のデータ）が、解析され、又は、例えば、ドメインコマンドに基づき別の方法で識別され、リンク２４１で示すように、署名サーバ２１２へ提供される。例えば、クライアント２１０と署名サーバ２１２との間の通信が、２方向ＳＳＬトンネルによって行われてもよい。情報（例えば、バイト、鍵タイプ（ZSK、KSK）、およびTLD）をリクエストに含んでもよい。署名サーバ２１２が、送信２４１から適した鍵情報、及び／又は、ＨＳＭを識別してもよく、かつ、リンク２４２で示されるように、適したＨＳＭ２１４へ未署名のデータを渡してもよい。これは、例えば、バイト、鍵エイリアス、および署名アルゴリズムを有する署名コマンドを含んでもよい。
【００５９】
実施例では、署名サーバ２１２も、（同じ署名リクエストの一部として）他のデータを署名するリクエストを受信してもよい。署名サーバ２１２が、他のデータのための適した鍵情報を決定してもよい。実施例では（かつ、本明細書にさらに開示されるように）、他のデータのための鍵情報が、同じ署名リクエストに含まれた第１データのための鍵情報とは異なってもよい。
【００６０】
署名サーバ２１２へのクライアント２１０からのリクエスト２４１が、SSP（Signing Server Protocol）に従ってフォーマットされる。実施例では、例のプロトコルが、「ボックスカー」フォーマットを含み（複数の署名リクエストが単一のプロトコルリクエストの中にパッケージ化される）、したがって、性能劣化ネットワーク往復および帯域幅利用を最適化する。加えて、SSPは内臓の診断機構（各サービスモジュールが付着する）を含んでよく、クライアントはサービスの使用可能状態および新しい課題を決定することができる。実施例では、本明細書に開示されたプロトコルが、特に、転送プロトコル自体への変更なしに、署名サーバに加えられた新規のサービスモジュールによって要求される、新規のデータ転送パケット構成の即時のプラグ可能性を可能にさせる。例のSSPが図３に示され、かつ、以下に詳細に説明される。
【００６１】
図３に示すように、クライアントからの署名サーバリクエストプロトコル３００が以下のフィールドを含んでもよい。
パケット長：：＝整数（パケットの合計長）
プロトコルバージョン：：＝バイト（プロトコルのバージョン）
サービスタイプ：：＝バイト（例えば、シンプル（一般的署名に対して）；DNSSEC（DNSSEC署名に対して）；公開鍵検索（鍵エイリアスを所与として、公開鍵をリターンする））
トランザクションID：：＝長整数（リクエストを認識する固有ＩＤ）
フラグ：：＝整数（フラグにおいてリクエストを通過させるフィールド（サービスにとらわれない））
セッションID：：＝長整数（リクエストを送信するセッションID、監査目的のために使用される）
アカウントID：：＝長整数（リクエストを送信するアカウントID、監査目的のために使用される）
レコード数：：＝バイト（リクエストデータの数（即ち、サービスが行動を起こす必要のある全リクエストに含まれたパケットの数）
署名リクエストデータ１〜ｎ−行動する必要のあるデータのパケット（複数可）、一般に、これは署名されるデータを含む。
【００６２】
クライアント２１０が、クライアントのリクエスト３００の中のペイロードとして、署名リクエストデータを送信してもよい。実施例では、署名サーバ２１２が、異なるサービスリクエストに関して認識および行動し、かつ、例えば、関連するコーデックに基づきデータペイロードを解釈するように構成される。実施例では、データが、例えば、以下に詳述されるシンプル署名リクエストデータ、RRSIG署名リクエストデータ、又は、公開鍵検索リクエストデータを含む、多様な形態（「著リクエストデータプロトコル」と称される）で構成される。
【００６３】
図４が、例のシンプル署名リクエスト署名リクエストデータプロトコルを示している。図４に示すように、シンプル署名リクエスト３１０が以下を含んでもよい。
長さ：：＝整数（データの長さ）
アルゴリズム：：＝文字列（署名アルゴリズム）
鍵エイリアス：：＝文字列（署名に使用されるのに必要な鍵エイリアス）
リクエストデータ長：：＝整数（リクエストデータフィールドの長さ）
リクエストデータ：：＝バイト（署名サーバによって署名される必要のあるデータ）
【００６４】
上記したように、クライアント２１０、署名サーバ２１２、およびＨＳＭ２１４が、鍵エイリアスを使用して、特定の鍵を識別する。したがって、多様なコンポーネントが実際の鍵を交換する必要がない（鍵マテリアルのセキュリティを維持することにおいて有利である）（特に、本質的にアクセス不可能な状態（即ち、ネットワークを介してアクセス不可能な）において、特定のコンポーネント（例えば、ＨＳＭ２１４）において維持される鍵）。
【００６５】
RRSIG署名リクエストデータ（例えば、図５に示した）が、シンプル署名リクエストと類似の方法で、署名リクエストデータを実施するのに使用される。例えば、RRSIG署名リクエストデータが、データビーン（data bean）（クライアントによって取り込まれ、署名される必要のあるRRSIGレコードについて情報を保持する）であってもよい。以下に詳述するように、リクエストの各クラスが、対応する応答２４４として署名サーバ２１２によってリターンされる。署名サーバ２１２がリクエスト２４１を受信するとき、それがそれ自体のDNSSEC関連のデータ（又は他のデータ）を有するリクエストデータを増大させることに注意しなければならない。
【００６６】
RRSIG署名リクエストデータ３２０が以下を含んでもよい。
長さ：：＝整数（データの長さ）
RRSIG ID：：＝長整数（RRSIG署名リクエストデータの固有ID）
ドメイン名：：＝文字列（ドメインの名前）
ドメインID：：＝長整数（ドメインのID）
親ドメイン：：＝文字列（親ドメイン）
カバーされるタイプ：：＝整数（リソースレコードタイプ）
ラベルの数：：＝整数（ドメイン名におけるラベルの数）
Orig TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
RR開始時間：：＝長整数（RRSIG開始時間のエポック時間）
RRSetバイト長：：＝整数（RRSetバイトの長さ）
RRSetバイト：：＝バイト（署名サーバによって署名される必要のあるデータ）
【００６７】
したがって、図３に示された署名サーバリクエストプロトコル３００、図４に示されたシンプル署名リクエストデータ３１０、および図５に示されたＲＲＳｉｇ署名リクエストデータ３２０の組合せを考慮して、適切に構成された署名サーバが、複数の署名リクエストデータム、潜在的に異なる署名アルゴリズムを有する各署名リクエストデータ、鍵エイリアスなどを有する単一の署名リクエスト（例えば、署名サーバリクエストプロトコル３００を介して）を受け入れてもよい。本明細書にさらに開示されるように、RR署名データの場合、適したアルゴリズム、及び／又は、鍵が、例えば、識別されたドメイン（及び／又は、リクエストに関連付けられたTLD）に基づいてもよい。実施例では、署名サーバが、本明細書に開示されたリクエストおよびデータパッケージの解析を通じて、異なるTLDの下のドメインに関するリクエストを処理する（かつ／又は、複数のレジストラによって管理される少なくとも２つのドメインに関するリクエストを処理する）ように構成される。
【００６８】
また、署名リクエストデータプロトコルが、以下のフィールドを含む公開鍵リクエストデータ（図示せず）を含んでもよい。
長さ：：＝整数（データの長さ）
鍵エイリアス：：＝文字列（公開鍵を検索するための鍵エイリアス）
【００６９】
署名サーバ２１２が、権威データについてデータベース２２０を周期的にチェックするように構成される（ＨＳＭ２１４へデータを送信するときに使用する鍵エイリアス）。また、署名サーバ２１２が、特定のＨＳＭを識別して、アクティブなKSK及び／又はアクティブなZSKに基づきデータパッケージを送信するように構成される。ＨＳＭ２１４が、初期時間でTLDごとに多くの鍵がロードされ（一部がZSKであり、一部がKSKであってもよい）、かつ、各鍵が、エイリアス（鍵エイリアス）によってＨＳＭ２１４に知られている。クライアント２１０が、使用する２種類の鍵（ZSK又はKSK）およびTLDのどれかを署名サーバ２１２に教えるように構成され、かつ、署名サーバ２１２が、署名のためＨＳＭと通信するとき、その種類の鍵について現在の鍵エイリアス名を識別するように構成される。また、署名サーバ２１２が、現在の鍵エイリアスについてデータベース２２０を再チェックするようにされる。例えば、このコマンドを、ＪＭＸ管理インターフェースを介して、署名サーバ２１２へ発行することができる。したがって、署名サーバ２１２が、「DNSSECを意識した」ものとして理解される。
【００７０】
署名サーバをDNSSECを意識したものにすることの１つの利点は、データの整列および未整列をセーブすることである（そうでなければ、クライアントが、それらのデータが変わらないにも拘らず、ほぼすべての署名リクエストで、通過しなければならない）。即ち、頻繁に変わらないデータは、リクエスト２４１ごとに、クライアント２１０によって知られる必要がなく、又は、クライアント２１０によって送信される必要がない。むしろ、これらデータが、署名サーバ２１２自体によって知られ、かつ、キャッシュされることができる。
【００７１】
また、その上、署名サーバ２１２が、一般の署名能力を提供するように構成される。実施例が、管理されたDNSサービスのために多様な署名を作成するように（ルートゾーン署名など）、大規模な数の鍵およびゾーン（何千又は何百万）を有する管理されたDNSサービスとともに使用するために、署名サーバを構成するステップを含んでもよい。実施例では、クライアントが、署名に使用される鍵を動的にロードおよびアンロードする能力に加えて、署名パラメータを提供するように構成される。「一般の署名」署名サーバ（複数のタイプの署名トランザクションを実施可能な）が、例えば、大規模な、多機能の、管理されたDNSサービスとともに使用するために、柔軟性のあるアプリケーションを提供してもよい。したがって、例えば、署名サーバ２１２が、サーバが入ってくるリクエストを取り扱うために頼りにするランタイム設定可能なプラグイン（サービス）を介して、DNSSECを意識してもよい（かつ、他の署名目的に作用可能であってもよい）。本発明の態様によれば、図２に示したような署名サーバフレームワークにより、多様なパーティが、さまざまなブランドのハードウェア又はソフトウェア署名アプリケーションと通信する、異なるパラメータおよび鍵を含む、サービスモジュールを書くことができる。追加的な機能が、プロトコルに加えられて、既存のクライアントを妨げることなく、新しい特徴をサポートすることができる。署名サーバと署名サーバプロトコルとの設定により、例えば、DNSSECアプリケーションが、下層の署名に影響を及ぼすことなく、他の多様に定義されたエンドユーザインターフェース（例えば、Ｗｅｂサービス、ＥＰＰ、ＲＥＳＴ）を含んでもよい。
【００７２】
実施例が、署名設定パラメータのキャッシングおよび非キャッシィングの組合せを提供するサービスモジュールとともに、署名サーバコードベースを含んでもよい。したがって、サービスモジュールが、その必要性に従って、これらのキャッシングおよび非キャッシング特徴を再使用してもよい。キャッシングが、比較的安定した鍵および署名設定を有するサービスモジュールの性能を向上させるために使用され、一方で、非キャッシングが、オフラインで格納され、かつ、署名のときにだけ起動される大量の鍵およびパラメータを必然的にともなう状況のために、鍵および署名パラメータのオンデマンドのローディングを促進してもよい。加えて、個別のサービスモジュールが正常に機能しないか、又は、使用不可能になるとき、異なるプロトコルおよび鍵で発生するので、署名サーバ自体がロバストなままであり、かつ、その他のモジュールがサービスリクエストを継続することを可能にする。そのような柔軟性により、例えば、現在のスタンドアローンDNSSEC署名アプリケーションによって実行可能な無数の選択肢を提供することができる。
【００７３】
非キャッシングアプローチ（例えば、すべての使用可能な鍵がＨＳＭ又は他の署名モジュールにキャッシュされていない）の１つの特徴的な利点は、電子的に包まれた鍵を、より費用のかからない、かつ、より高度に使用可能なリポジトリ（例えば、データセンターなどで複製しやすいデータベース）に格納することができることである。したがって、ＨＳＭ又は他の署名モジュールが、必要に応じて、データを署名する鍵を検索してもよい。実際の鍵のそのような別のストレージ（および、必要に応じたローディング）が、発明者によって発見されて、ＨＳＭの実行能力、又は使用されるデータベースの使用可能性を犠牲にせず、本明細書に開示された全署名サービスが、より大量の鍵へ拡大することを可能にする。これは、何千から何百万のゾーンのための鍵にアクセスする必要のある非常に拡大されたDNSサービス（例えば、レジストリによって提供される）との関連で特に有用であるであることが分かった。
【００７４】
実施例では、ＨＳＭ又は他の署名モジュールが、ＨＳＭ又は他の署名モジュールの秘密鍵とともに、データベースに格納された関連の鍵を暗号化してもよい。本明細書にさらに開示されるように、各鍵が、鍵エイリアスによって識別可能であり、かつ、検索されたとき、秘密鍵を使用して、ＨＳＭ又は他の署名モジュールによって復号される。
【００７５】
図２に戻ると、ＨＳＭ２１４が、適した鍵で、例えば、リクエスト２４２で受信されるようにDNSSECデータに署名し、かつ、リンク２４３によって示されるように署名サーバ２１２へ署名されたデータを戻してもよい。実施例では、そのような署名が、例えば、適した鍵の識別、及び／又は、リクエストに含まれた鍵エイリアスなどからのプロトコルに基づいてもよい。代わりに、ＨＳＭ（又は、他の署名アプリケーション）が、予め定められた鍵、及び／又は、パラメータを有して、直接それらへ署名リクエストを適用してもよい。署名リクエストに含まれた別々に識別されるデータパケットを含む本発明の実施例によれば、パケットを非同期的に処理することができ、その結果、クライアントが署名応答を遮らず、クライアントが処理を続けることができることに注意しなければならない。さらに、単一の署名サーバが、リクエストに応じて、受信および動作して、アプリケーションを横断した、およびゾーンを横断したデータに同時に署名することができる。即ち、単一のサーバが、単一のリクエストパケットコマンドにおいて受信して、ゾーン及び／又はアプリケーションを横断した相互に関連していないデータに署名することができる。
【００７６】
加えて、署名サーバ２１２が、単一のデータパケットに対して複数の署名をリクエストおよび提供するように構成される。例えば、署名サーバ２１２が、特定のデータに適用される１つより多くのアクティブな鍵及び／又はアルゴリズムを認識し、かつ、１つより多くのアクティブ鍵及び／又はアルゴリズムに基づき、ＨＳＭ又は他の署名モジュールからの複数の署名をリクエストする。実施例では、署名サーバ２１２が、例えば、第１アルゴリズムによる第１鍵で第１データの署名と、第２アルゴリズムによる第２鍵で第１データの署名とをリクエストおよび報告するように構成される。例えば、複数のアクティブな鍵および署名が、ユーザの要求に従って、鍵ロールオーバとの関連で、及び／又は、DNSSECのために適用されて、アルゴリズムロール（例えば、SHA-1からSHA-2）を効果的に実施する。
【００７７】
ＨＳＭ２１４が、署名サーバ２１２のプロセッサから物理的に分離されて、かつ、例えば、ＨＳＭ２１４に格納された鍵を保護する追加的なセキュリティプロトコルを備えてもよい。例えば、ＨＳＭ２１４が、そこに格納される鍵を保護する物理的ローディング手順のみを介して、特定の鍵情報を交換するように構成される（特に、長いサービスライフ又は広い使用可能性を有する鍵）（例えば、KSK）。実施例では、ＨＳＭが、１又は複数の鍵（および、そこに格納された鍵を識別する１又は複数のエイリアス識別子）を具備してもよい。
【００７８】
署名サーバ２１２が、署名されたデータ（例えば、DNSSEC又は他の電子的に署名されたデータ）（又は、トランザクションコミット情報などの他のデータ）を、リンク２４４によって示した通りクライアント２１０へ戻してもよい。
【００７９】
上記したように、リクエストの各クラスが、対応する応答２４４として署名サーバ２１２によってリターンされる。署名サーバ２１２によってリターンされる応答２４４が、図６に示された署名サーバ応答プロトコルに従うように構成される。
【００８０】
図６に示すように、署名サーバ応答プロトコル４００が例えば以下を含んでもよい。
パケット長：：＝整数（パケットの全長）
プロトコルバーション：：＝バイト（リクエストで送信されたものと同じ）
サービスタイプ：：＝バイト（リクエストで送信されたものと同じ）
トランザクションID：：＝長整数（リクエストで送信されたものと同じ）
フラグ：：＝整数（フラグにおいてリクエストが通過することができるフィールド（サービスにとらわれない））
応答コード：：＝バイト（リクエストを処理した後の応答コード。署名サーバによってリターンされる応答コードについては以下を参照。）
応答メッセージ長：：＝整数（サーバによってリターンされる応答について詳細な応答メッセージの長さ）
応答メッセージ文字型：：文字型（応答メッセージ文字型）
レコード数：：＝バイト（応答データの数（即ち、サービスが行われる必要のある全リクエストに含まれるパケットの数））
署名応答データ１〜ｎ
【００８１】
例の署名応答コードを表１に示す。
【００８２】
【表１】
【００８３】
例えば、署名応答データが、リクエスト（即ち、シンプル署名リクエストデータ、RRSIG署名リクエストデータ、又は、公開鍵検索リクエストデータ）に対応するシンプル署名応答データ、RRSIG署名応答データ、又は、公開鍵検索応答データを含んでもよい。実施例では、リクエストで送信される各リクエスト−データパケットに対して、１つの応答データオブジェクトが存在してもよい。
【００８４】
例のシンプル署名応答データ４１０が、図７に示され、例えば、シンプル署名リクエスト（例えば、図４に示された）への応答として、署名サーバ２１２によってリターンされる。図７に示すように、シンプル署名リクエストデータ４１０のフィールドが以下を含んでもよい。
長さ：：＝整数（データの長さ）
署名されたデータ長：：＝整数（署名されたデータフィールドの長さ）
署名されたデータ：：＝バイト（署名サーバによって署名される必要のあるデータ）
【００８５】
図８がRRSIG署名応答データ４２０の例を示し、図５に示されたようなRRSIG関連のリクエストに起因した各応答−データパケットのために使用される。RRSIG署名応答データ４２０のフィールドが以下を含んでもよい。
長さ：：＝整数（データの長さ）
RRSIG ID：：＝長整数（RRSIG署名リクエストデータの固有ID）
ドメイン名：：＝文字列（ドメインの名前）
ドメインID：：＝長整数（ドメインのID）
親ドメイン：：＝文字列（親ドメイン）
カバーされるタイプ：：＝整数（リソースレコードタイプ）
ラベルの数：：＝整数（ドメイン名のラベルの数）
Orig TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
RR開始時間：：＝長整数（RRSIG開始時間のエポック時間）
鍵タグ：：＝整数（このリクエストに署名するのに使用された鍵の鍵タグ）
アルゴリズムID：：＝整数（このリクエストに署名するのに使用されたアルゴリズムID）
署名：：＝文字列（リクエストに署名することによって生成されたベース６４エンコード署名）
RR終了時間：：＝長整数（RRSIG終了時間のエポック時間）
【００８６】
また、署名応答データが、以下のフィールドを含む公開鍵応答データ（図示せず）を含んでもよい。
ラベル：：＝整数（データの長さ）
鍵エイリアス：：＝文字列（リクエストで送信される鍵エイリアス）
公開鍵：：＝文字列（鍵エイリアスを使用して検索される鍵のベース６４エンコード公開鍵）
【００８７】
いったん署名されたデータがクライアント２１０へリターンされると、クライアントが、要求に応じて（例えば、DNS又は他のサービスへ）署名されたデータを配布し、かつ／又は、必要に応じて確認メッセージを送信してもよい。実施例では、クライアント２１０が、実行されるのに必要な適したDNSSEC機能を決定することができるのと同様に、DNS変更などに関して識別および行動することができるDNSSECアプリケーションとして構成される。したがって、署名サーバ２１２が、DNSSEC固有のアプリケーションプログラミングおよび機能のうちの多数から解放される。DNSSECアプリケーション（例えば、クライアント２１０）が、署名パラメータの詳細にかかわる必要がなく、かつ、処理および組立のネットワークコストを負担する必要がなく、署名サーバ２１２へ追加的な情報を伝えず、DNSSECビジネスロジック（どのようなリソースレコードが署名される必要があるかなど）に集中することができる。さらに、上記したように、多様なリクエストおよび応答プロトコルにより、DNSSECアプリケーションが、比較的小規模な署名リクエストのすべて（多様なDNSSEC署名パラメータおよび鍵情報は全くなく）を単一のパケットに結合することができ、したがって、ネットワーク負荷およびオーバーヘッドを大きく減らす。最後に、クライアント２１０もＨＳＭインターフェース詳細から全く解放することができる。
【００８８】
図９が、クライアントとサーバとの間で共有される、上記した例のリクエストと応答プロトコルとの関係を図示している。上記したプロトコル（および特定の内容）が本来は例であり、かつ、そのような特定のプロトコルに本発明の範囲が限定されないことに注意しなければならない。例えば、インテリジェント署名サーバの能力を十分に利用する他のプロトコルを実装してもよい（例えば、鍵スケジュールが署名サーバにロードされ、かつ、クライアントが、正しい鍵を自動的に選択する署名サーバのために、適した識別子とともに署名するデータを渡しさえすればよい）。
【００８９】
本発明のさらなる実施例によれば、クライアントおよび署名サーバ群が、本明細書に開示されるように、負荷バランシングおよび署名システムの応答性を改善するように管理される。例えば、図１０に示すように、実施例では、各署名サーバ８０１〜８０１ｎについて、特定の署名サーバのためのリクエストを取り扱う署名サーバクライアント８１０の１つのインスタンスがある。また、署名サーバクライアント８１０の上に、署名サーバクライアントのインスタンスを管理する署名サーバクライアントプール８２０が存在してもよい。署名サーバクライアントプール８２０が、いくつもの署名サーバクライアントに接続され、かつ、例えば、ラウンドロビン法で多様な署名サーバへバランスリクエストをロードするように構成され、それが接続された署名サーバがダウンしている等の場合、署名サーバクライアントのインスタンスをローテーションから出すように構成される。
【００９０】
各署名サーバクライアント８１０が、署名サーバとともに、ソケット接続８１２のプールを維持するように構成され、このサービスがダウンする場合、署名サーバクライアントプール８２０に通知し、かつ、健全チェックスレッドを開始するように構成され、かつ／又は、署名サーバに接続するよう継続的に試行し、かつ、署名サーバが再作動した後、このサービスをローテーションに戻すように署名サービスクライアントプール８２０に通知するように構成される。
【００９１】
したがって、全システムが、クライアント側およびサーバ側の故障に適応してもよい。例えば、クライアント側のサービスが、署名サーバのリストを維持し、かつ、これらサーバからの識別された「致命的」例外／エラー応答に反応する。クライアント側が、これらの故障した署名サーバをラウンドロビンローテーションから除外し、かつ、いつサーバがオンラインに戻るかを継続的に認識するようにしてもよい。署名サーバが、「ピング」をサポートするように構成され、その結果、クライアントがその健全性をチェックすることができる。
【００９２】
クライアント側の署名サーバがその署名サーバのすべてがダウンしていると分かった場合、何かを署名するリクエストを受信したとき、迅速に例外をリターンしてもよい。クライアントが、署名サーバのうちの少なくとも１つが使用可能になるまで、これを継続してもよい。
【００９３】
署名サーバ側からの故障シナリオが、その従属関係（例えば、ＨＳＭ又は鍵データベース）の使用不可を含んでもよい。ＨＳＭが使用不可である場合、署名サーバが、これを示すエラー応答を報告する。署名サーバが、例えば、ＪＭＸおよびログエントリを介して、この状況に関して警告する。署名サーバも、ＨＳＭがオンラインに戻ったか否かを検出することを継続的に試みる。鍵データベースが鍵データのリフレッシュのために使用不可になる場合、署名サーバが、データを署名するリクエストを断るように構成される（例えば、間違った鍵で署名するリスクがあるので）。署名サーバが、署名応答としてこのエラーを報告するように構成され、かつ、鍵データベースへの再接続を継続的に試行してもよい。
【００９４】
他のオプションは、サービスが正しく機能していないとき、クライアント接続を「落とす（drop）」、及び／又は、特定のサービスに対する新規の接続のためのリスニングを停止するように署名サーバを設定することである。そのような設定によって、例えば、クライアントが、サービスを現在実行することができる署名サーバにだけサービスリクエストを向けることができ、署名サービスネットワークの状態の監視を向上させ、クライアントに戻って報告されるエラーの数を減らし、かつ、クライアントの全体効率を向上させる利点がある。また、そのような設定により、署名サーバが、問題が解決されるまで、機能しないサービスのためのエラーとの遭遇及び／又は報告の負担なしに、他の動作可能なサービスで、継続することができる。同様の設定が、署名サーバと複数のサポーティングＨＳＭ又は他の署名モジュールとの間で適用される。
【００９５】
図１，２，１０に示された構成（および、上に詳細に記されたリクエストおよび応答プロトコルの実施例）によれば、クライアント（例えば、クライアント２１０）が、方法およびクライアント−ユーティリティライブラリを利用して、負荷バランシング、および、高可用性特徴を提供してもよい。例えば、クライアント−ユーティリティライブラリが、使用しているサーバの中のどのサービスモジュールかに拘わらず、署名サーバと相互作用してもよい。クライアント−ユーティリティライブラリが、それらの特徴セットの部分として、自動再接続およびファストフェイル（fast-fail）（サービス使用不可の時間において）を提供してもよい。また、クライアント−ユーティリティライブラリの負荷バランシング特徴が、いくつもの署名サーバが使用可能および使用不可能であろうとも、および、いくつものクライアントが常にこれらのサーバに接続されていようとも、負荷が、自動的にアクティブなサーバ間で、比較的一様に分散されることを確実にする助けとなってもよい。
【００９６】
実施例では、署名サーバのためのサービスモジュールプラグが、１又は複数のTLD（例えば、.com、.net、.eduなど）のためのモジュールを含んでもよい。実施例では、複数のTLDが、異なるTLDのための多様な鍵スケジュール、及び／又は、プロトコルを認識している単一のサービスモジュールによってサポートされる。サービスモジュールが、例えば、署名が適用するTLD、および、鍵ロールオーバのためのアカウンティング、どのハードウェア又はソフトウェアの署名者がそのTLDの署名を生成すべきか、署名を生成するときに使用するTLD固有のパラメータ（ソルト、ハッシュアルゴリズム、署名アルゴリズム、署名期間などを含む）を仮定すると、どのZSKが要求に応じて電子署名を生成するために使用されるかを提供するように構成される。実施例では、署名サーバが、データベースからこれらの設定を自動的かつ周期的にリロードするように構成され、したがって、再起動なしに、通常の操作の間に、変更を捕らえることができる。
【００９７】
このアプローチの格別な利点は、TLDごとに一貫した署名作成を確実にする集中型の権威設定を提供することである。さらに、TLDのためのレジストリアプリケーション自体がこれらのポリシーを直接知る必要はなく、むしろ、TLD単位で、署名サーバにリクエストしてデータに署名し、かつ、そうするとき、署名サーバに依存して必須のポリシーおよびパラメータを適用することを意味する。この方法が、例えば、レジストリアプリケーションインスタンスが存在するより、署名サーバがはるかに少なく存在するので、これらのデータが通常の操作の間に変更するとき、署名設定データに関して有効期限が切れるレジストリのリスクを全体として減らす。加えて、署名サーバに対するクライアントが、TLD固有の署名パラメータをロードすることに関連した追加的な設定およびアプリケーションロジックを備える必要がない（アプリケーションの複雑性を増大させ、かつミス設定のリスクを増大させ、電子署名失敗を生じさせる）。最後に、クライアントが、各リクエストとともにTLD固有の署名パラメータを署名サーバに向かって渡す必要がない（ネットワーク負荷低下およびスループット向上を意味する）。
【００９８】
さらに一般的に言えば、本発明の態様によれば、署名サーバが、開発者が「スマート」サービスを組み込むことができるように構成される（それ自体がこの情報を有していない、署名リクエストの関連に基づき、サービスがどの鍵がアクティブであるかについて知識を有し、どのアルゴリズムが使用されるかなど）。これが、クライアントが可能な限り「データ処理能力のない」ものであることを意図される関連で、特に好ましい。これが、例えば、より小さなパケットを実装し、クライアントが期限切れの情報で操作する、又は鍵の状態と同期されていない危険性を減らし、かつ、より少ない量のクライアントコードおよびより脆弱ではないクライアントコードを提供するのに使用される。
【００９９】
上記したように、本明細書に開示された署名サーバの方法および装置が、無数のDNS（および他の署名）サービスに対して、適用可能性を見出してもよく、かつ、互換性があってもよい。例えば、ネットワークアクセス可能な、設定可能な署名サーバを提供することによって、多様なリモート署名プロトコルおよび設定が直ちにサポートされる。サポートされる１つのそのような非限定的な例が、図１１にその詳細を示し、本明細書に開示されたDNSSEC署名機能のために使用される「インライン署名」構成を含む。図１１に示すように、リクエスタ１０００（例えば、登録者、レジストラ又はDNSプロバイダー）が、レジストリプロビジョニングシステム１１００と通信してもよい。リクエスタ１０００が、既存又は新規のドメインに関するコマンドを通信してもよい。例えば、リクエスタ１０００が、レジストリによって管理されるDNS（レジストリによって管理されるTLD（例えば、.com）の下のドメインのためのDNSデータ）を変更するコマンドを通信してもよい。レジストリプロビジョニングシステム１１００が、例えば、変更コマンド（例えば、追加、修正、又は削除コマンド）を実行するステップ、DNSSECデータ変更を識別するステップ、適した鍵を識別するステップ、電子署名を適用するステップ、レジストリデータベース１２００へDNSおよびDNSSEC変更を保存するステップなどを含む多様な方法で、リクエスタ１０００からのドメインコマンドを処理してもよい。
【０１００】
レジストリデータベース１２０へレジストリプロビジョニングシステム１１００によって提供されるデータが、ドメインのためのDNS情報および署名されたDNSSECデータを含んでもよい。実施例では、例えば、例の署名サーバが、単一のトランザクションの中のDNS変更およびDNSSEC変更を実施する方法をサポートしてもよい。
【０１０１】
上記したように、DNSSEC署名が、トランザクションでインラインに同期して、署名サーバによって実行される。別のサービスが、レジストリデータベースに各コミットされるトランザクションをとり、かつ、DNSサーバへそれを増加的に適用するために使用される。
【０１０２】
ドメインレジストリのドメインコマンドをともなうDNSSEC署名インラインが、例えば、DNSにおいて何が発行されるかについてレジストリデータベースが常に権威ソースを示すことを確実にすることによって、最も高いレベルのデータ完全性を維持することにおいて、利点を提供する。
【０１０３】
DNSSECインライン署名を実施する一部として、ネットワーク対応および高性能署名サーバ群が（例えば、図１，２に示したような）、DNSSEC情報に署名するために提供される。これが、最も大規模なTLDとの関連でさえ有効であることが分かり、かつ、電子署名を必要とするクライアントからの1,000以上の同時に起こる接続を供給するときでさえ、高いレベルのデータ完全性を有するDNS伝搬ＳＬＡを維持することと同様に、ドメインレジストリ応答時間ＳＬＡを維持する。
【０１０４】
本発明の実施例が、上記した方法をコンピュータに実行させるための命令でコード化されたコンピュータ読み取り可能な記録媒体と同様に、上記した方法を実施するためのシステムを備えることができる。例えば、図１２に示すように、サーバシステム（例えば、サーバ６００，６１０、及び／又は６２０）（少なくともプロセッサ、メモリ、および電子通信デバイス（図示せず）を備える）が、ネットワーク６０５（例えば、インターネット）を介して受信されるリクエスト（例えば、本明細書に開示されたリクエスト）に関して、受信、識別、応答、及び／又は、動作するように構成される。サーバ６００，６１０、及び／又は６２０のいずれかが、例えば、本明細書に詳細に開示されたインターネットホスティングプロバイダー、レジストラ、及び／又はレジストリによって操作され、かつ、ウェブデバイス６３０によって一般的に表わされた、いくつもの再帰的DNSサーバと通信する。本明細書に開示されたように、再帰的サーバ６３０が、ホスティングプロバイダー、レジストラ、及び／又は、レジストリオペレーティングサーバ６００，６１０、および６２０のドメインのためのDNS関連のデータをキャッシュしてもよい。
【０１０５】
ドメインについてDNSデータを更新するリクエストが、例えば、レジストラ、DNSサービスプロバイダー、又は、登録者に由来してもよい（多様なシステム（例えば、コンピュータ６１１，６１２）を介して、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ６１６、又は、必要な機能を備えた他のネットワーク対応デバイスと無線又は他の通信を行う別のサーバ６１３を介して）。
【０１０６】
多様な通信、送信、および本明細書に開示された関連の機能が、例えば、ネットワーク６０５を介して実行され、かつ、サーバシステム（例えば、サーバ６００，６１０、および６２０）によって実行される開示された処理の結果が、既知の方法に従って、表示、格納、及び／又は、配布される。ネットワーク６０５が、いくつもの通信コンポーネント（有線、セル、衛星、光、及び／又は他の類似の通信リンクを含む）を含んでもよい。
【０１０７】
サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、第１ストレージ（図示せず、一般にランダムアクセスメモリ、又はRAM）、第２ストレージ（図示せず、一般にリードオンリーメモリ、又はROM）を含むストレージデバイスに接続されたいくつものプロセッサ（図示せず）を備えてもよい。これらストレージデバイスの両方が、適したタイプのコンピュータ読み取り可能な記録媒体（非一時的なストレージ媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、磁気テープ）、CD-ROMディスクなどの光媒体、及び／又は、光磁気媒体を含む）を含む。また、マスストレージデバイス（図示せず）が、プログラム、データなどを格納するのに使用され、かつ、一般に補助記憶媒体（例えば、主記憶装置よりも遅いハードディスク）である。好ましくは、マスストレージデバイス内に保持される情報が、仮想メモリとして、主記憶装置の一部として、一般的な方法で、組み込まれることが理解される。また、具体的なマスストレージデバイス（例えば、CD-ROM）がプロセッサへ一方向的にデータを渡してもよい。
【０１０８】
また、サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、１又は複数の入出力デバイス（例えば、ビデオモニタ、トラックボール、マウス、キーボード、マイク、タッチセンサ式のディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、又は、他の既知の入力デバイス）（他のコンピュータを含む）を含むインターフェースを備えてもよい。サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、ネットワーク接続を使用して、コンピュータ又は他の電気通信ネットワーク６０５に接続される。ネットワーク６０５が、多様な有線、光、電気、および他の既知のネットワークに接続して、サーバ６００，６１０、および６２０、コンピュータ６１１，６１２、別のサーバ６１３、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ（複数可）６１６、再帰的サーバ６３０、および、類似の機能を有する他のデバイスの間で、情報を交換することができる。そのネットワーク接続を用いて、上記した方法のステップを実行する過程で、サーバ６００，６１０、および６２０（およびコンピュータ６１１，６１２）およびそのプロセッサが、ネットワーク６０５から情報を受信するか、又は、ネットワーク６０５へ情報を出力すると考えられる。上記したデバイスおよび素材は、コンピュータハードウェアおよびソフトウェア技術の当業者によく知られており、当業者に理解されるように個別又は網羅的に示す必要はない。上記したハードウェア要素が、上記した操作を実行するための１又は複数のモジュールとして動作するように（一般的に一時的に）構成される。
【０１０９】
加えて、本発明の実施例は、さらに、本明細書に開示された多様なコンピュータ実行オペレーションを実行するためのプログラム命令を含んだコンピュータ読み取り可能な記録媒体を含む。媒体が、単独で、又はプログラム命令と組み合わせて、データファイル、データ構造、テーブルなども含んでもよい。媒体およびプログラム命令が、本発明の目的のために特に設計されかつ構成されたものであってもよく、又は、それらが、コンピュータソフトウェア技術のスキルを有する人に使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例が、磁気媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、および磁気テープ）、光媒体（例えば、CD-ROMディスク）、光磁気媒体、および、プログラム命令を格納および実行するように特に構成されたハードウェアデバイス（例えば、リードオンリーメモリデバイス（ROM）、および、ランダムアクセスメモリ（RAM））を含む。プログラム命令の例が、機械コード（例えば、コンパイラによって生成される）、および、インタプリタを使用してコンピュータによって実行される高次レベルコードを含むファイルの両方を含む。
【０１１０】
上記した説明は、単に実例であり、本発明のすべての可能性のある実施例、アプリケーション、又は、変形例の網羅的なリストであることを意図されたものではない。したがって、開示された本発明の方法およびシステムの多様な修正例および変形例が、本発明の真の趣旨及び範囲から逸脱することなく、当業者に明らかになる。本発明は特定の実施例との関連で開示されたが、請求項に係る発明がその特定の実施例に不当に限定されないことを理解しなければならない。
【符号の説明】
【０１１１】
110 CAS１〜ｎ
120 NCCビジネスサービス
130 バッチ/ツール
142 署名サーバ1
144, 148 ＨＳＭ
146 署名サーバn
150 データベース
【技術分野】
【０００１】
本発明は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およびNSEC３レコードは、存在しないDNSレコードに対して認証された存在の否定の応答を提供するのに使用される。
【００１２】
DNSSECの要求は、異なる鍵（DNSKEYレコードの両方に格納され、かつ、信頼アンカーを形成する他のソースから）の使用を含む。例えば、KSK（Key Signing Keys）（他のDNSKEYレコードに署名するために使用される）およびZSK（Zone Signing Keys）（他のレコードに署名するために使用される）が存在する。ZSKは固有のDNSゾーンの制御および使用下にあるので、それらはより容易かつより頻繁に切り替えることができる。その結果、ZSKは一般にKSKより短く（バイト長に関して）、その上、容認可能なレベルの保護を提供する。
【００１３】
プロトコルはDNSSEC（KSKおよびZSKの使用を含む）の利用に対して開発されているが、レジストラおよびレジストリレベルで、大規模な使用に対して対処及び／又は最適化されていないDNSSEC使用可能なドメインを運用するさまざまな態様が存在する。例えば、短い期間に多数の署名を処理する能力が、スタンドアローン署名システムを使用すること、および、ゾーンへの変更に基づいてゾーン全体に署名することの一般的な方法に限定されている。加えて、多くのソリューションが、個別のユーザ、又は、特定のDNSプロバイダーによって管理される限定された数のドメインなどに限定されている。したがって、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ホスティングを移行又は外部委託することを要求される。
【００１５】
しかし、膨大なレジストリ（例えば、.comおよび.netレジストリ）へのDNSSECの導入にともなって、DNSSECデータに対するさまざまな署名技術における効率の悪さ（特に、大規模なゾーンに関して）が、遅延および解決失敗を含む解決に関する潜在的課題をもたらす。そのような課題が、電子商取引および他の高トラフィックサイトに大きな弊害をもたらす。
【００１６】
本発明は、リモートアプリケーションに対して署名を管理することを可能し、かつ、必要に応じてゾーンデータの一部にリモートに署名することを可能にするネットワークアクセス可能な署名サーバの使用を通じて、DNSSEC使用可能なゾーンの効率的な署名において利点を提供する。本発明の態様によれば、ネットワークアクセス可能な署名サーバの使用により、これら機能が本質的にマージされる他の方法に比べて（例えば、ネームサーバが署名を実行する方法において、又は、特定のゾーン管理デバイスが署名する場合において）、署名メカニズムから、ゾーン管理およびゾーンサービングアプリケーションの分離を提供する。
【００１７】
また、例えば、拡張可能な、ネットワークアクセス可能な署名サーバの使用を通じて、例の構成が、他の既知の方法に比べて、署名サーバの多様な機能を手動設定する必要を減らす（又は、取り除く）。また、ネットワークアクセス可能な署名サーバが、手動設定を必要とせず、以下を含む幅広いDNSSECアプリケーションのサポートを提供してもよい。
１．大量のDNSSECアプリケーションのリソースレコードのインライン署名（例えば、ＴＬＤレジストリ）
２．動的な鍵の作成、鍵のローディング、鍵の非ローディング、および、多くの鍵およびゾーンを有するDNSSECアプリケーションのゾーンデータに署名する鍵の使用
３．オフライン／バッチDNSSECアプリケーションのゾーン全体の署名（例えば、ルートゾーン）
【００１８】
態様では、DNSSEC署名を実行するためのシステムおよび方法が、別のクライアントアプリケーションと相互作用するように構成された署名サーバによって実行される。例の方法が、一般に、第１データを署名するクライアントアプリケーションから署名サーバで署名リクエストを受信するステップを含んでもよい。署名サーバが、第１データに対して、適した署名鍵及び／又はプロトコルを決定してもよい。次いで、第１データが、署名サーバによって電子署名モジュールへ転送され、例えば、ハードウェアサポートモジュール、又は、ソフトウェア署名アプリケーションを含む。署名サーバが、電子署名モジュールから、電子的に署名されたバージョンの第１データを受信し、かつ、クライアントアプリケーションへ署名された第１データを提供する。
【００１９】
本発明の第１態様によれば、DNSSEC署名サーバが、少なくとも１つのDNSSECクライアントアプリケーション、および、電子署名モジュールと相互作用するように構成されている。例えば、DNSSEC署名サーバが、プロセッサ、および、プロセッサによって実行されたとき、第１データを署名する少なくとも１つのクライアントアプリケーションから署名リクエストを受信するように構成された権威署名サーバとして、署名サーバを動作させるコンピュータ読み取り可能なコードを含むストレージデバイスを含んでもよい。例えば、第１データがDNSデータを含む。
【００２０】
態様では、署名サーバが、第１データに対して、適した署名鍵（例えば、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つ）を決定してもよい。適した鍵（例えば、少なくとも１つのアクティブなKSKおよびアクティブなZSK）が、例えば、署名リクエストに含まれたTLD識別子に基づき決定される。態様では、署名サーバが、第１データに対して、１つより多くのアクティブな署名鍵、及び／又は、アクティブな署名アルゴリズムを決定するように構成され、かつ、１つより多くのアクティブな署名鍵、及び／又は、アクティブな署名アルゴリズムに基づき、第１データに対する複数の異なる署名をリクエストしてもよい。
【００２１】
態様では、署名サーバが、複数の電子署名モジュールのうちの１つへ第１データを転送し、かつ、電子署名モジュールから、電子的に署名されたバージョンの第１データを受信してもよい。また、署名サーバが、クライアントアプリケーションへ署名された第１データを提供するように構成される。
【００２２】
態様では、署名サーバが、署名リクエストに含まれたサービスタイプ識別子に基づき、複数の異なる電子署名機能の中から、リクエストされた署名機能を区別し、かつ、サービスタイプ識別子に基づき、非DNSSEC電子署名モジュールへ非DNSSEC署名リクエストを送るように構成される。
【００２３】
本発明のさらなる態様によれば、また、署名サーバが、第２データに署名するリクエストを、同じ署名リクエストの一部として、受信するように構成される。第２データが、例えば、DNSデータ又は他のデータである。署名サーバが、第２データに対して、適した署名鍵（例えば、アクティブなKSKおよびアクティブなＺＫＳのうちの少なくとも１つ）を決定し、第１データで使用される鍵とは異なる。例えば、署名サーバが、第１データに対する第１セットの鍵、および、第２データに対する第２セットの鍵を決定してもよい。
【００２４】
態様では、署名サーバが、複数の電子署名モジュールのうちの１つへ、第２データを転送してもよく、かつ、電子署名モジュールから、電子的に署名されたバージョンの第２データを受信してもよい。また、署名サーバが、クライアントアプリケーションへ署名された第２データを提供するように構成される。
【００２５】
態様が、単一のリクエストパケットの一部として複数の署名リクエストを受信し、かつ、リクエストパケットを解析して、相互に異なるアクティブなKSK、アクティブなZSK、および署名プロトコルのうちの少なくとも１つを有する異なる署名リクエストを識別するように構成された、署名サーバを備えてもよい。
【００２６】
態様では、電子署名モジュールが、ゾーン全体に署名せず、DNSSECプロトコルに従って、DNSデータの特定の部分に署名するように構成される。
【００２７】
態様では、また、署名サーバが、追加的な非DNSSEC電子署名機能を提供するように構成される。
【００２８】
態様では、電子署名モジュールのそれぞれが、ＨＳＭ（Hardware Support Module）を備え、署名サーバのプロセッサから物理的に離れ、かつ、署名サーバによって提供されたデータに電子的に署名するように構成される。
【００２９】
態様では、ＨＳＭが、エイリアス識別子によって識別された複数の鍵を具備している。署名サーバが、電子署名モジュールへ少なくとも１つのKSKおよびZSKを渡さず、電子署名モジュールへ使用される適した鍵のためのエイリアス識別子（例えば、DNSデータに対するKSKおよびZSKのうちの少なくとも１つ）を渡すように構成される。
【００３０】
態様では、署名サーバが、アクティブな鍵（例えば、アクティブなKSK又はZSK）のデータベースを周期的にチェックするように構成され、かつ、データベースから受信された情報に基づき、所定の時間にわたりどのエイリアス識別子がアクティブであるかを決定するように構成される。態様では、電子署名モジュールに渡されたエイリアス識別子が、アクティブなエイリアス識別子である。
【００３１】
態様では、署名サーバが、少なくとも１つのアクティブなKSK及び／又はアクティブなZSKに基づき、特定のＨＳＭを識別して、第１データを送信するように構成される。
【００３２】
態様では、署名サーバが、異なるTLDの下のドメインに関するリクエストを処理するように構成される。
【００３３】
態様では、署名サーバが、複数のレジストラによって管理された少なくとも２つのドメインに関するリクエストを処理するように構成される。
【００３４】
態様では、クライアントと署名サーバとの間の通信が、例えば、２方向ＳＳＬを介して、実行される。
【００３５】
本明細書に述べるように、例の署名サーバが、無数の異なるシステムによって実施される、例えば、DNSSEC署名機能、他の管理DNSサービス、リモート署名、ルートゾーン署名などを含む、多様なDNS署名操作をサポートしてもよい。態様では、例えば、例の署名サーバが、本明細書では「インライン署名（inline signing）」と称される単一のトランザクション（例えば、極小の、一貫した、分離された、かつ、耐久性のある仕事のユニット）態様の一部として、影響されるDNSSECレコードの署名をサポートするように構成される。
【００３６】
追加的な特徴、利点、および本発明の態様は、以下の詳細な説明、図面、および請求項の検討から、説明され、又は明らかである。さらに、上記した本発明の概要および以下の詳細な説明の両方が、例示であり、かつ、本発明の特許請求の範囲を限定することなくさらなる説明を提供することを意図したものであることを理解しなければならない。しかし、詳細な説明および特定の例は、単に本発明の好ましい実施例を示したものである。本発明の真の趣旨および範囲から逸脱することなく、多様な変形例および改良例が詳細な説明から当業者には明らかとなる。
【００３７】
本発明のさらなる理解を提供するよう含まれた添付の図面が、組み込まれ、本明細書の一部を構成し、本発明の実施例を図示し、詳細な説明とともに、本発明の原理を説明するのに用いられる。本発明の基本的理解および実施される多様な方法に必要であるよりもさらに詳細に本発明の構造的詳細を示していない。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施例の例のDNSSEC使用可能な署名システムの詳細図である。
【図２】本発明の実施例の例のDNSSEC使用可能な署名システムのさらなる詳細図である。
【図３】本発明の実施例の例の署名リクエストプロトコルである。
【図４】本発明の実施例の例の署名リクエストデータプロトコルである。
【図５】本発明の実施例の別の例の署名リクエストデータプロトコルである。
【図６】本発明の実施例の例の署名応答プロトコルである。
【図７】本発明の実施例の例の署名応答データプロトコルである。
【図８】本発明の実施例の別の例の署名応答データプロトコルである。
【図９】本発明の実施例の例のリクエスト、リクエストデータ、応答、および応答データの関係図である。
【図１０】本発明の実施例の署名サービスクライアントプールマネージャを含む例のDNSSEC使用可能な署名システムのさらなる詳細図である。
【図１１】本発明の実施例に従ってサポートされるDNSSEC署名のための例のインライン署名方法のための概略システム構成である。
【図１２】本発明の実施例で使用される例のコンピュータネットワークアーキテクチャの図である。
【発明を実施するための形態】
【００３９】
本発明が本明細書に開示された特定の方法、プロトコルなどに限定されないことが理解される（当業者に理解されるようにそれらが多様に変化するため）。また、本明細書に使用された用語が特定の実施例だけを説明する目的に使用され、本発明の範囲を限定することを意図しないことを理解しなければならない。また、本明細書および特許請求の範囲に使用されるとき、単数形態”a”、“an”および“the”は、コンテキストが明確に指定しない限り、複数の言及を含むことに注意しなければならない。したがって、例えば、「サーバ」への言及は、１又は複数のサーバ、および、当業者に既知のその均等物への言及である。
【００４０】
他に定義されない限り、本明細書で使用される技術用語は、本発明が関わる当業者に一般に理解されるものと同じ意味を有する。本発明の実施例、および、多様な特徴、および、それについての利点の詳細は、添付の図面に説明及び／又は図示され、かつ、以下の説明に詳述された非限定的な実施例および実例を参照してさらに完全に説明される。図面に示された特徴は必ずしも一定の縮尺で描かれておらず、かつ、仮に本明細書に明確に述べられていなくても、１つの実施例の特徴が、当業者が理解するように他の実施例で利用されることに注意しなければならない。周知のコンポーネントおよび処理技術の記載は、本発明の実施例を不必要に分かりにくくしないように省略される。本明細書に使用された例は、単に、本発明が実施される方法の理解を助けること、および、当業者が本発明の態様を実施することをさらに可能にすることを目的としている。したがって、本明細書の実施例および実例は、本発明の範囲を限定するものとして解釈されるべきでなく、特許請求の範囲および適用される法によってのみ定義される。さらに、類似の参照数字が図面のいくつかの表示にわたって同様の部分を参照することに注意しなければならない。
【００４１】
本明細書で使用されるとき、他に限定されない限り、レジストラ（registrar）は、ドメイン名レジストリと相互作用し、かつ、登録者(registrant)がドメイン名リソースを作成および更新することを可能にするエンティティ又は組織であると理解される。
【００４２】
本明細書で使用されるとき、他に限定されない限り、登録者は、ドメイン名リソースを作成および更新するレジストラと相互作用する人又は組織であると理解される。
【００４３】
本明細書で使用されるとき、他に限定されない限り、DNSホスティングプロバイダーは、DNSプロビジョニングおよびそのコンテンツについて解決能力を提供する、登録者の代わりに、そのサーバにコンテンツをホストするエンティティ又は組織であると理解される（例えば、IPアドレスを割り当て、それが管理するそれらのIPアドレスへドメイン名を解決することができるネームサーバを運営する）。
【００４４】
本発明の実施例が、大規模なDNSSECプロバイダー（例えば、レジストリ）により、効果的かつ一貫した方法で、多様なソースからの多数のDNS変更（DNSSEC署名データを含む）を処理することができる、ネットワークアクセス可能な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は、アクティブなKSKおよびZSKの両方によって署名される。他のRRセットはアクティブなZSKだけによって署名される。
【００５３】
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３レコードの自らの名前の第１ラベルにおいてハッシュ値によってカバーされる名前に対して存在するレコードタイプ
【００５７】
例の署名サーバ構成が図１に示されている。図１に示すように、レジストリ（又は、DNSSECサービスプロバイダー）が、いくつもの署名サーバ１４２，１４６を備えてもよい。例えば、複数の署名サーバが、レジストリプロビジョニングシステムを含んでもよい。署名サーバ１４２，１４６が、適切な電子署名鍵を含む実際の電子署名機能を含むＨＳＭ（Hardware Security Module）１４４，１４８（及び／又は、ソフトウェア）をそれぞれ含んでもよい。署名サーバ１４２，１４６が、多様なアプリケーション、サービス、およびツール１１０，１２０，１３０と通信してもよい（かつ、例えば、署名されたDNSデータおよび未署名のDNSデータを交換してもよい）。各ＣＡＳ１１０、ＮＣＣプラグインビジネスサービス１２０、およびバッチ／ツール１３０コンポーネントが、署名サーバ（好ましくは、一連のそのようなサーバ）への接続を有する。署名サーバ１４２，１４６が、データベース１５０へ署名されたDNSデータを保存してもよい。アプリケーション、署名サーバ、ＨＳＭ、およびデータベースの間の例のデータフローの追加的な詳細が図２に示されている。
【００５８】
図２に示すように、例えば、クライアント２１０が、プロビジョニングシステムのフロントエンドサービスを表す（署名サーバ２１２によって署名される必要があるDNSSECデータを識別するように構成される）。署名されるデータが、例えば、DNS変更（例えば、ドメインに対する追加、更新、削除コマンド）によって影響されるゾーンデータの一部であってもよい。署名されるDNSSECデータ（又は、他のデータ）が、解析され、又は、例えば、ドメインコマンドに基づき別の方法で識別され、リンク２４１で示すように、署名サーバ２１２へ提供される。例えば、クライアント２１０と署名サーバ２１２との間の通信が、２方向ＳＳＬトンネルによって行われてもよい。情報（例えば、バイト、鍵タイプ（ZSK、KSK）、およびTLD）をリクエストに含んでもよい。署名サーバ２１２が、送信２４１から適した鍵情報、及び／又は、ＨＳＭを識別してもよく、かつ、リンク２４２で示されるように、適したＨＳＭ２１４へ未署名のデータを渡してもよい。これは、例えば、バイト、鍵エイリアス、および署名アルゴリズムを有する署名コマンドを含んでもよい。
【００５９】
実施例では、署名サーバ２１２も、（同じ署名リクエストの一部として）他のデータを署名するリクエストを受信してもよい。署名サーバ２１２が、他のデータのための適した鍵情報を決定してもよい。実施例では（かつ、本明細書にさらに開示されるように）、他のデータのための鍵情報が、同じ署名リクエストに含まれた第１データのための鍵情報とは異なってもよい。
【００６０】
署名サーバ２１２へのクライアント２１０からのリクエスト２４１が、SSP（Signing Server Protocol）に従ってフォーマットされる。実施例では、例のプロトコルが、「ボックスカー」フォーマットを含み（複数の署名リクエストが単一のプロトコルリクエストの中にパッケージ化される）、したがって、性能劣化ネットワーク往復および帯域幅利用を最適化する。加えて、SSPは内臓の診断機構（各サービスモジュールが付着する）を含んでよく、クライアントはサービスの使用可能状態および新しい課題を決定することができる。実施例では、本明細書に開示されたプロトコルが、特に、転送プロトコル自体への変更なしに、署名サーバに加えられた新規のサービスモジュールによって要求される、新規のデータ転送パケット構成の即時のプラグ可能性を可能にさせる。例のSSPが図３に示され、かつ、以下に詳細に説明される。
【００６１】
図３に示すように、クライアントからの署名サーバリクエストプロトコル３００が以下のフィールドを含んでもよい。
パケット長：：＝整数（パケットの合計長）
プロトコルバージョン：：＝バイト（プロトコルのバージョン）
サービスタイプ：：＝バイト（例えば、シンプル（一般的署名に対して）；DNSSEC（DNSSEC署名に対して）；公開鍵検索（鍵エイリアスを所与として、公開鍵をリターンする））
トランザクションID：：＝長整数（リクエストを認識する固有ＩＤ）
フラグ：：＝整数（フラグにおいてリクエストを通過させるフィールド（サービスにとらわれない））
セッションID：：＝長整数（リクエストを送信するセッションID、監査目的のために使用される）
アカウントID：：＝長整数（リクエストを送信するアカウントID、監査目的のために使用される）
レコード数：：＝バイト（リクエストデータの数（即ち、サービスが行動を起こす必要のある全リクエストに含まれたパケットの数）
署名リクエストデータ１〜ｎ−行動する必要のあるデータのパケット（複数可）、一般に、これは署名されるデータを含む。
【００６２】
クライアント２１０が、クライアントのリクエスト３００の中のペイロードとして、署名リクエストデータを送信してもよい。実施例では、署名サーバ２１２が、異なるサービスリクエストに関して認識および行動し、かつ、例えば、関連するコーデックに基づきデータペイロードを解釈するように構成される。実施例では、データが、例えば、以下に詳述されるシンプル署名リクエストデータ、RRSIG署名リクエストデータ、又は、公開鍵検索リクエストデータを含む、多様な形態（「著リクエストデータプロトコル」と称される）で構成される。
【００６３】
図４が、例のシンプル署名リクエスト署名リクエストデータプロトコルを示している。図４に示すように、シンプル署名リクエスト３１０が以下を含んでもよい。
長さ：：＝整数（データの長さ）
アルゴリズム：：＝文字列（署名アルゴリズム）
鍵エイリアス：：＝文字列（署名に使用されるのに必要な鍵エイリアス）
リクエストデータ長：：＝整数（リクエストデータフィールドの長さ）
リクエストデータ：：＝バイト（署名サーバによって署名される必要のあるデータ）
【００６４】
上記したように、クライアント２１０、署名サーバ２１２、およびＨＳＭ２１４が、鍵エイリアスを使用して、特定の鍵を識別する。したがって、多様なコンポーネントが実際の鍵を交換する必要がない（鍵マテリアルのセキュリティを維持することにおいて有利である）（特に、本質的にアクセス不可能な状態（即ち、ネットワークを介してアクセス不可能な）において、特定のコンポーネント（例えば、ＨＳＭ２１４）において維持される鍵）。
【００６５】
RRSIG署名リクエストデータ（例えば、図５に示した）が、シンプル署名リクエストと類似の方法で、署名リクエストデータを実施するのに使用される。例えば、RRSIG署名リクエストデータが、データビーン（data bean）（クライアントによって取り込まれ、署名される必要のあるRRSIGレコードについて情報を保持する）であってもよい。以下に詳述するように、リクエストの各クラスが、対応する応答２４４として署名サーバ２１２によってリターンされる。署名サーバ２１２がリクエスト２４１を受信するとき、それがそれ自体のDNSSEC関連のデータ（又は他のデータ）を有するリクエストデータを増大させることに注意しなければならない。
【００６６】
RRSIG署名リクエストデータ３２０が以下を含んでもよい。
長さ：：＝整数（データの長さ）
RRSIG ID：：＝長整数（RRSIG署名リクエストデータの固有ID）
ドメイン名：：＝文字列（ドメインの名前）
ドメインID：：＝長整数（ドメインのID）
親ドメイン：：＝文字列（親ドメイン）
カバーされるタイプ：：＝整数（リソースレコードタイプ）
ラベルの数：：＝整数（ドメイン名におけるラベルの数）
Orig TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
RR開始時間：：＝長整数（RRSIG開始時間のエポック時間）
RRSetバイト長：：＝整数（RRSetバイトの長さ）
RRSetバイト：：＝バイト（署名サーバによって署名される必要のあるデータ）
【００６７】
したがって、図３に示された署名サーバリクエストプロトコル３００、図４に示されたシンプル署名リクエストデータ３１０、および図５に示されたＲＲＳｉｇ署名リクエストデータ３２０の組合せを考慮して、適切に構成された署名サーバが、複数の署名リクエストデータム、潜在的に異なる署名アルゴリズムを有する各署名リクエストデータ、鍵エイリアスなどを有する単一の署名リクエスト（例えば、署名サーバリクエストプロトコル３００を介して）を受け入れてもよい。本明細書にさらに開示されるように、RR署名データの場合、適したアルゴリズム、及び／又は、鍵が、例えば、識別されたドメイン（及び／又は、リクエストに関連付けられたTLD）に基づいてもよい。実施例では、署名サーバが、本明細書に開示されたリクエストおよびデータパッケージの解析を通じて、異なるTLDの下のドメインに関するリクエストを処理する（かつ／又は、複数のレジストラによって管理される少なくとも２つのドメインに関するリクエストを処理する）ように構成される。
【００６８】
また、署名リクエストデータプロトコルが、以下のフィールドを含む公開鍵リクエストデータ（図示せず）を含んでもよい。
長さ：：＝整数（データの長さ）
鍵エイリアス：：＝文字列（公開鍵を検索するための鍵エイリアス）
【００６９】
署名サーバ２１２が、権威データについてデータベース２２０を周期的にチェックするように構成される（ＨＳＭ２１４へデータを送信するときに使用する鍵エイリアス）。また、署名サーバ２１２が、特定のＨＳＭを識別して、アクティブなKSK及び／又はアクティブなZSKに基づきデータパッケージを送信するように構成される。ＨＳＭ２１４が、初期時間でTLDごとに多くの鍵がロードされ（一部がZSKであり、一部がKSKであってもよい）、かつ、各鍵が、エイリアス（鍵エイリアス）によってＨＳＭ２１４に知られている。クライアント２１０が、使用する２種類の鍵（ZSK又はKSK）およびTLDのどれかを署名サーバ２１２に教えるように構成され、かつ、署名サーバ２１２が、署名のためＨＳＭと通信するとき、その種類の鍵について現在の鍵エイリアス名を識別するように構成される。また、署名サーバ２１２が、現在の鍵エイリアスについてデータベース２２０を再チェックするようにされる。例えば、このコマンドを、ＪＭＸ管理インターフェースを介して、署名サーバ２１２へ発行することができる。したがって、署名サーバ２１２が、「DNSSECを意識した」ものとして理解される。
【００７０】
署名サーバをDNSSECを意識したものにすることの１つの利点は、データの整列および未整列をセーブすることである（そうでなければ、クライアントが、それらのデータが変わらないにも拘らず、ほぼすべての署名リクエストで、通過しなければならない）。即ち、頻繁に変わらないデータは、リクエスト２４１ごとに、クライアント２１０によって知られる必要がなく、又は、クライアント２１０によって送信される必要がない。むしろ、これらデータが、署名サーバ２１２自体によって知られ、かつ、キャッシュされることができる。
【００７１】
また、その上、署名サーバ２１２が、一般の署名能力を提供するように構成される。実施例が、管理されたDNSサービスのために多様な署名を作成するように（ルートゾーン署名など）、大規模な数の鍵およびゾーン（何千又は何百万）を有する管理されたDNSサービスとともに使用するために、署名サーバを構成するステップを含んでもよい。実施例では、クライアントが、署名に使用される鍵を動的にロードおよびアンロードする能力に加えて、署名パラメータを提供するように構成される。「一般の署名」署名サーバ（複数のタイプの署名トランザクションを実施可能な）が、例えば、大規模な、多機能の、管理されたDNSサービスとともに使用するために、柔軟性のあるアプリケーションを提供してもよい。したがって、例えば、署名サーバ２１２が、サーバが入ってくるリクエストを取り扱うために頼りにするランタイム設定可能なプラグイン（サービス）を介して、DNSSECを意識してもよい（かつ、他の署名目的に作用可能であってもよい）。本発明の態様によれば、図２に示したような署名サーバフレームワークにより、多様なパーティが、さまざまなブランドのハードウェア又はソフトウェア署名アプリケーションと通信する、異なるパラメータおよび鍵を含む、サービスモジュールを書くことができる。追加的な機能が、プロトコルに加えられて、既存のクライアントを妨げることなく、新しい特徴をサポートすることができる。署名サーバと署名サーバプロトコルとの設定により、例えば、DNSSECアプリケーションが、下層の署名に影響を及ぼすことなく、他の多様に定義されたエンドユーザインターフェース（例えば、Ｗｅｂサービス、ＥＰＰ、ＲＥＳＴ）を含んでもよい。
【００７２】
実施例が、署名設定パラメータのキャッシングおよび非キャッシィングの組合せを提供するサービスモジュールとともに、署名サーバコードベースを含んでもよい。したがって、サービスモジュールが、その必要性に従って、これらのキャッシングおよび非キャッシング特徴を再使用してもよい。キャッシングが、比較的安定した鍵および署名設定を有するサービスモジュールの性能を向上させるために使用され、一方で、非キャッシングが、オフラインで格納され、かつ、署名のときにだけ起動される大量の鍵およびパラメータを必然的にともなう状況のために、鍵および署名パラメータのオンデマンドのローディングを促進してもよい。加えて、個別のサービスモジュールが正常に機能しないか、又は、使用不可能になるとき、異なるプロトコルおよび鍵で発生するので、署名サーバ自体がロバストなままであり、かつ、その他のモジュールがサービスリクエストを継続することを可能にする。そのような柔軟性により、例えば、現在のスタンドアローンDNSSEC署名アプリケーションによって実行可能な無数の選択肢を提供することができる。
【００７３】
非キャッシングアプローチ（例えば、すべての使用可能な鍵がＨＳＭ又は他の署名モジュールにキャッシュされていない）の１つの特徴的な利点は、電子的に包まれた鍵を、より費用のかからない、かつ、より高度に使用可能なリポジトリ（例えば、データセンターなどで複製しやすいデータベース）に格納することができることである。したがって、ＨＳＭ又は他の署名モジュールが、必要に応じて、データを署名する鍵を検索してもよい。実際の鍵のそのような別のストレージ（および、必要に応じたローディング）が、発明者によって発見されて、ＨＳＭの実行能力、又は使用されるデータベースの使用可能性を犠牲にせず、本明細書に開示された全署名サービスが、より大量の鍵へ拡大することを可能にする。これは、何千から何百万のゾーンのための鍵にアクセスする必要のある非常に拡大されたDNSサービス（例えば、レジストリによって提供される）との関連で特に有用であるであることが分かった。
【００７４】
実施例では、ＨＳＭ又は他の署名モジュールが、ＨＳＭ又は他の署名モジュールの秘密鍵とともに、データベースに格納された関連の鍵を暗号化してもよい。本明細書にさらに開示されるように、各鍵が、鍵エイリアスによって識別可能であり、かつ、検索されたとき、秘密鍵を使用して、ＨＳＭ又は他の署名モジュールによって復号される。
【００７５】
図２に戻ると、ＨＳＭ２１４が、適した鍵で、例えば、リクエスト２４２で受信されるようにDNSSECデータに署名し、かつ、リンク２４３によって示されるように署名サーバ２１２へ署名されたデータを戻してもよい。実施例では、そのような署名が、例えば、適した鍵の識別、及び／又は、リクエストに含まれた鍵エイリアスなどからのプロトコルに基づいてもよい。代わりに、ＨＳＭ（又は、他の署名アプリケーション）が、予め定められた鍵、及び／又は、パラメータを有して、直接それらへ署名リクエストを適用してもよい。署名リクエストに含まれた別々に識別されるデータパケットを含む本発明の実施例によれば、パケットを非同期的に処理することができ、その結果、クライアントが署名応答を遮らず、クライアントが処理を続けることができることに注意しなければならない。さらに、単一の署名サーバが、リクエストに応じて、受信および動作して、アプリケーションを横断した、およびゾーンを横断したデータに同時に署名することができる。即ち、単一のサーバが、単一のリクエストパケットコマンドにおいて受信して、ゾーン及び／又はアプリケーションを横断した相互に関連していないデータに署名することができる。
【００７６】
加えて、署名サーバ２１２が、単一のデータパケットに対して複数の署名をリクエストおよび提供するように構成される。例えば、署名サーバ２１２が、特定のデータに適用される１つより多くのアクティブな鍵及び／又はアルゴリズムを認識し、かつ、１つより多くのアクティブ鍵及び／又はアルゴリズムに基づき、ＨＳＭ又は他の署名モジュールからの複数の署名をリクエストする。実施例では、署名サーバ２１２が、例えば、第１アルゴリズムによる第１鍵で第１データの署名と、第２アルゴリズムによる第２鍵で第１データの署名とをリクエストおよび報告するように構成される。例えば、複数のアクティブな鍵および署名が、ユーザの要求に従って、鍵ロールオーバとの関連で、及び／又は、DNSSECのために適用されて、アルゴリズムロール（例えば、SHA-1からSHA-2）を効果的に実施する。
【００７７】
ＨＳＭ２１４が、署名サーバ２１２のプロセッサから物理的に分離されて、かつ、例えば、ＨＳＭ２１４に格納された鍵を保護する追加的なセキュリティプロトコルを備えてもよい。例えば、ＨＳＭ２１４が、そこに格納される鍵を保護する物理的ローディング手順のみを介して、特定の鍵情報を交換するように構成される（特に、長いサービスライフ又は広い使用可能性を有する鍵）（例えば、KSK）。実施例では、ＨＳＭが、１又は複数の鍵（および、そこに格納された鍵を識別する１又は複数のエイリアス識別子）を具備してもよい。
【００７８】
署名サーバ２１２が、署名されたデータ（例えば、DNSSEC又は他の電子的に署名されたデータ）（又は、トランザクションコミット情報などの他のデータ）を、リンク２４４によって示した通りクライアント２１０へ戻してもよい。
【００７９】
上記したように、リクエストの各クラスが、対応する応答２４４として署名サーバ２１２によってリターンされる。署名サーバ２１２によってリターンされる応答２４４が、図６に示された署名サーバ応答プロトコルに従うように構成される。
【００８０】
図６に示すように、署名サーバ応答プロトコル４００が例えば以下を含んでもよい。
パケット長：：＝整数（パケットの全長）
プロトコルバーション：：＝バイト（リクエストで送信されたものと同じ）
サービスタイプ：：＝バイト（リクエストで送信されたものと同じ）
トランザクションID：：＝長整数（リクエストで送信されたものと同じ）
フラグ：：＝整数（フラグにおいてリクエストが通過することができるフィールド（サービスにとらわれない））
応答コード：：＝バイト（リクエストを処理した後の応答コード。署名サーバによってリターンされる応答コードについては以下を参照。）
応答メッセージ長：：＝整数（サーバによってリターンされる応答について詳細な応答メッセージの長さ）
応答メッセージ文字型：：文字型（応答メッセージ文字型）
レコード数：：＝バイト（応答データの数（即ち、サービスが行われる必要のある全リクエストに含まれるパケットの数））
署名応答データ１〜ｎ
【００８１】
例の署名応答コードを表１に示す。
【００８２】
【表１】
【００８３】
例えば、署名応答データが、リクエスト（即ち、シンプル署名リクエストデータ、RRSIG署名リクエストデータ、又は、公開鍵検索リクエストデータ）に対応するシンプル署名応答データ、RRSIG署名応答データ、又は、公開鍵検索応答データを含んでもよい。実施例では、リクエストで送信される各リクエスト−データパケットに対して、１つの応答データオブジェクトが存在してもよい。
【００８４】
例のシンプル署名応答データ４１０が、図７に示され、例えば、シンプル署名リクエスト（例えば、図４に示された）への応答として、署名サーバ２１２によってリターンされる。図７に示すように、シンプル署名リクエストデータ４１０のフィールドが以下を含んでもよい。
長さ：：＝整数（データの長さ）
署名されたデータ長：：＝整数（署名されたデータフィールドの長さ）
署名されたデータ：：＝バイト（署名サーバによって署名される必要のあるデータ）
【００８５】
図８がRRSIG署名応答データ４２０の例を示し、図５に示されたようなRRSIG関連のリクエストに起因した各応答−データパケットのために使用される。RRSIG署名応答データ４２０のフィールドが以下を含んでもよい。
長さ：：＝整数（データの長さ）
RRSIG ID：：＝長整数（RRSIG署名リクエストデータの固有ID）
ドメイン名：：＝文字列（ドメインの名前）
ドメインID：：＝長整数（ドメインのID）
親ドメイン：：＝文字列（親ドメイン）
カバーされるタイプ：：＝整数（リソースレコードタイプ）
ラベルの数：：＝整数（ドメイン名のラベルの数）
Orig TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
TTL：：＝長整数（署名サーバによって署名される必要のあるデータ）
RR開始時間：：＝長整数（RRSIG開始時間のエポック時間）
鍵タグ：：＝整数（このリクエストに署名するのに使用された鍵の鍵タグ）
アルゴリズムID：：＝整数（このリクエストに署名するのに使用されたアルゴリズムID）
署名：：＝文字列（リクエストに署名することによって生成されたベース６４エンコード署名）
RR終了時間：：＝長整数（RRSIG終了時間のエポック時間）
【００８６】
また、署名応答データが、以下のフィールドを含む公開鍵応答データ（図示せず）を含んでもよい。
ラベル：：＝整数（データの長さ）
鍵エイリアス：：＝文字列（リクエストで送信される鍵エイリアス）
公開鍵：：＝文字列（鍵エイリアスを使用して検索される鍵のベース６４エンコード公開鍵）
【００８７】
いったん署名されたデータがクライアント２１０へリターンされると、クライアントが、要求に応じて（例えば、DNS又は他のサービスへ）署名されたデータを配布し、かつ／又は、必要に応じて確認メッセージを送信してもよい。実施例では、クライアント２１０が、実行されるのに必要な適したDNSSEC機能を決定することができるのと同様に、DNS変更などに関して識別および行動することができるDNSSECアプリケーションとして構成される。したがって、署名サーバ２１２が、DNSSEC固有のアプリケーションプログラミングおよび機能のうちの多数から解放される。DNSSECアプリケーション（例えば、クライアント２１０）が、署名パラメータの詳細にかかわる必要がなく、かつ、処理および組立のネットワークコストを負担する必要がなく、署名サーバ２１２へ追加的な情報を伝えず、DNSSECビジネスロジック（どのようなリソースレコードが署名される必要があるかなど）に集中することができる。さらに、上記したように、多様なリクエストおよび応答プロトコルにより、DNSSECアプリケーションが、比較的小規模な署名リクエストのすべて（多様なDNSSEC署名パラメータおよび鍵情報は全くなく）を単一のパケットに結合することができ、したがって、ネットワーク負荷およびオーバーヘッドを大きく減らす。最後に、クライアント２１０もＨＳＭインターフェース詳細から全く解放することができる。
【００８８】
図９が、クライアントとサーバとの間で共有される、上記した例のリクエストと応答プロトコルとの関係を図示している。上記したプロトコル（および特定の内容）が本来は例であり、かつ、そのような特定のプロトコルに本発明の範囲が限定されないことに注意しなければならない。例えば、インテリジェント署名サーバの能力を十分に利用する他のプロトコルを実装してもよい（例えば、鍵スケジュールが署名サーバにロードされ、かつ、クライアントが、正しい鍵を自動的に選択する署名サーバのために、適した識別子とともに署名するデータを渡しさえすればよい）。
【００８９】
本発明のさらなる実施例によれば、クライアントおよび署名サーバ群が、本明細書に開示されるように、負荷バランシングおよび署名システムの応答性を改善するように管理される。例えば、図１０に示すように、実施例では、各署名サーバ８０１〜８０１ｎについて、特定の署名サーバのためのリクエストを取り扱う署名サーバクライアント８１０の１つのインスタンスがある。また、署名サーバクライアント８１０の上に、署名サーバクライアントのインスタンスを管理する署名サーバクライアントプール８２０が存在してもよい。署名サーバクライアントプール８２０が、いくつもの署名サーバクライアントに接続され、かつ、例えば、ラウンドロビン法で多様な署名サーバへバランスリクエストをロードするように構成され、それが接続された署名サーバがダウンしている等の場合、署名サーバクライアントのインスタンスをローテーションから出すように構成される。
【００９０】
各署名サーバクライアント８１０が、署名サーバとともに、ソケット接続８１２のプールを維持するように構成され、このサービスがダウンする場合、署名サーバクライアントプール８２０に通知し、かつ、健全チェックスレッドを開始するように構成され、かつ／又は、署名サーバに接続するよう継続的に試行し、かつ、署名サーバが再作動した後、このサービスをローテーションに戻すように署名サービスクライアントプール８２０に通知するように構成される。
【００９１】
したがって、全システムが、クライアント側およびサーバ側の故障に適応してもよい。例えば、クライアント側のサービスが、署名サーバのリストを維持し、かつ、これらサーバからの識別された「致命的」例外／エラー応答に反応する。クライアント側が、これらの故障した署名サーバをラウンドロビンローテーションから除外し、かつ、いつサーバがオンラインに戻るかを継続的に認識するようにしてもよい。署名サーバが、「ピング」をサポートするように構成され、その結果、クライアントがその健全性をチェックすることができる。
【００９２】
クライアント側の署名サーバがその署名サーバのすべてがダウンしていると分かった場合、何かを署名するリクエストを受信したとき、迅速に例外をリターンしてもよい。クライアントが、署名サーバのうちの少なくとも１つが使用可能になるまで、これを継続してもよい。
【００９３】
署名サーバ側からの故障シナリオが、その従属関係（例えば、ＨＳＭ又は鍵データベース）の使用不可を含んでもよい。ＨＳＭが使用不可である場合、署名サーバが、これを示すエラー応答を報告する。署名サーバが、例えば、ＪＭＸおよびログエントリを介して、この状況に関して警告する。署名サーバも、ＨＳＭがオンラインに戻ったか否かを検出することを継続的に試みる。鍵データベースが鍵データのリフレッシュのために使用不可になる場合、署名サーバが、データを署名するリクエストを断るように構成される（例えば、間違った鍵で署名するリスクがあるので）。署名サーバが、署名応答としてこのエラーを報告するように構成され、かつ、鍵データベースへの再接続を継続的に試行してもよい。
【００９４】
他のオプションは、サービスが正しく機能していないとき、クライアント接続を「落とす（drop）」、及び／又は、特定のサービスに対する新規の接続のためのリスニングを停止するように署名サーバを設定することである。そのような設定によって、例えば、クライアントが、サービスを現在実行することができる署名サーバにだけサービスリクエストを向けることができ、署名サービスネットワークの状態の監視を向上させ、クライアントに戻って報告されるエラーの数を減らし、かつ、クライアントの全体効率を向上させる利点がある。また、そのような設定により、署名サーバが、問題が解決されるまで、機能しないサービスのためのエラーとの遭遇及び／又は報告の負担なしに、他の動作可能なサービスで、継続することができる。同様の設定が、署名サーバと複数のサポーティングＨＳＭ又は他の署名モジュールとの間で適用される。
【００９５】
図１，２，１０に示された構成（および、上に詳細に記されたリクエストおよび応答プロトコルの実施例）によれば、クライアント（例えば、クライアント２１０）が、方法およびクライアント−ユーティリティライブラリを利用して、負荷バランシング、および、高可用性特徴を提供してもよい。例えば、クライアント−ユーティリティライブラリが、使用しているサーバの中のどのサービスモジュールかに拘わらず、署名サーバと相互作用してもよい。クライアント−ユーティリティライブラリが、それらの特徴セットの部分として、自動再接続およびファストフェイル（fast-fail）（サービス使用不可の時間において）を提供してもよい。また、クライアント−ユーティリティライブラリの負荷バランシング特徴が、いくつもの署名サーバが使用可能および使用不可能であろうとも、および、いくつものクライアントが常にこれらのサーバに接続されていようとも、負荷が、自動的にアクティブなサーバ間で、比較的一様に分散されることを確実にする助けとなってもよい。
【００９６】
実施例では、署名サーバのためのサービスモジュールプラグが、１又は複数のTLD（例えば、.com、.net、.eduなど）のためのモジュールを含んでもよい。実施例では、複数のTLDが、異なるTLDのための多様な鍵スケジュール、及び／又は、プロトコルを認識している単一のサービスモジュールによってサポートされる。サービスモジュールが、例えば、署名が適用するTLD、および、鍵ロールオーバのためのアカウンティング、どのハードウェア又はソフトウェアの署名者がそのTLDの署名を生成すべきか、署名を生成するときに使用するTLD固有のパラメータ（ソルト、ハッシュアルゴリズム、署名アルゴリズム、署名期間などを含む）を仮定すると、どのZSKが要求に応じて電子署名を生成するために使用されるかを提供するように構成される。実施例では、署名サーバが、データベースからこれらの設定を自動的かつ周期的にリロードするように構成され、したがって、再起動なしに、通常の操作の間に、変更を捕らえることができる。
【００９７】
このアプローチの格別な利点は、TLDごとに一貫した署名作成を確実にする集中型の権威設定を提供することである。さらに、TLDのためのレジストリアプリケーション自体がこれらのポリシーを直接知る必要はなく、むしろ、TLD単位で、署名サーバにリクエストしてデータに署名し、かつ、そうするとき、署名サーバに依存して必須のポリシーおよびパラメータを適用することを意味する。この方法が、例えば、レジストリアプリケーションインスタンスが存在するより、署名サーバがはるかに少なく存在するので、これらのデータが通常の操作の間に変更するとき、署名設定データに関して有効期限が切れるレジストリのリスクを全体として減らす。加えて、署名サーバに対するクライアントが、TLD固有の署名パラメータをロードすることに関連した追加的な設定およびアプリケーションロジックを備える必要がない（アプリケーションの複雑性を増大させ、かつミス設定のリスクを増大させ、電子署名失敗を生じさせる）。最後に、クライアントが、各リクエストとともにTLD固有の署名パラメータを署名サーバに向かって渡す必要がない（ネットワーク負荷低下およびスループット向上を意味する）。
【００９８】
さらに一般的に言えば、本発明の態様によれば、署名サーバが、開発者が「スマート」サービスを組み込むことができるように構成される（それ自体がこの情報を有していない、署名リクエストの関連に基づき、サービスがどの鍵がアクティブであるかについて知識を有し、どのアルゴリズムが使用されるかなど）。これが、クライアントが可能な限り「データ処理能力のない」ものであることを意図される関連で、特に好ましい。これが、例えば、より小さなパケットを実装し、クライアントが期限切れの情報で操作する、又は鍵の状態と同期されていない危険性を減らし、かつ、より少ない量のクライアントコードおよびより脆弱ではないクライアントコードを提供するのに使用される。
【００９９】
上記したように、本明細書に開示された署名サーバの方法および装置が、無数のDNS（および他の署名）サービスに対して、適用可能性を見出してもよく、かつ、互換性があってもよい。例えば、ネットワークアクセス可能な、設定可能な署名サーバを提供することによって、多様なリモート署名プロトコルおよび設定が直ちにサポートされる。サポートされる１つのそのような非限定的な例が、図１１にその詳細を示し、本明細書に開示されたDNSSEC署名機能のために使用される「インライン署名」構成を含む。図１１に示すように、リクエスタ１０００（例えば、登録者、レジストラ又はDNSプロバイダー）が、レジストリプロビジョニングシステム１１００と通信してもよい。リクエスタ１０００が、既存又は新規のドメインに関するコマンドを通信してもよい。例えば、リクエスタ１０００が、レジストリによって管理されるDNS（レジストリによって管理されるTLD（例えば、.com）の下のドメインのためのDNSデータ）を変更するコマンドを通信してもよい。レジストリプロビジョニングシステム１１００が、例えば、変更コマンド（例えば、追加、修正、又は削除コマンド）を実行するステップ、DNSSECデータ変更を識別するステップ、適した鍵を識別するステップ、電子署名を適用するステップ、レジストリデータベース１２００へDNSおよびDNSSEC変更を保存するステップなどを含む多様な方法で、リクエスタ１０００からのドメインコマンドを処理してもよい。
【０１００】
レジストリデータベース１２０へレジストリプロビジョニングシステム１１００によって提供されるデータが、ドメインのためのDNS情報および署名されたDNSSECデータを含んでもよい。実施例では、例えば、例の署名サーバが、単一のトランザクションの中のDNS変更およびDNSSEC変更を実施する方法をサポートしてもよい。
【０１０１】
上記したように、DNSSEC署名が、トランザクションでインラインに同期して、署名サーバによって実行される。別のサービスが、レジストリデータベースに各コミットされるトランザクションをとり、かつ、DNSサーバへそれを増加的に適用するために使用される。
【０１０２】
ドメインレジストリのドメインコマンドをともなうDNSSEC署名インラインが、例えば、DNSにおいて何が発行されるかについてレジストリデータベースが常に権威ソースを示すことを確実にすることによって、最も高いレベルのデータ完全性を維持することにおいて、利点を提供する。
【０１０３】
DNSSECインライン署名を実施する一部として、ネットワーク対応および高性能署名サーバ群が（例えば、図１，２に示したような）、DNSSEC情報に署名するために提供される。これが、最も大規模なTLDとの関連でさえ有効であることが分かり、かつ、電子署名を必要とするクライアントからの1,000以上の同時に起こる接続を供給するときでさえ、高いレベルのデータ完全性を有するDNS伝搬ＳＬＡを維持することと同様に、ドメインレジストリ応答時間ＳＬＡを維持する。
【０１０４】
本発明の実施例が、上記した方法をコンピュータに実行させるための命令でコード化されたコンピュータ読み取り可能な記録媒体と同様に、上記した方法を実施するためのシステムを備えることができる。例えば、図１２に示すように、サーバシステム（例えば、サーバ６００，６１０、及び／又は６２０）（少なくともプロセッサ、メモリ、および電子通信デバイス（図示せず）を備える）が、ネットワーク６０５（例えば、インターネット）を介して受信されるリクエスト（例えば、本明細書に開示されたリクエスト）に関して、受信、識別、応答、及び／又は、動作するように構成される。サーバ６００，６１０、及び／又は６２０のいずれかが、例えば、本明細書に詳細に開示されたインターネットホスティングプロバイダー、レジストラ、及び／又はレジストリによって操作され、かつ、ウェブデバイス６３０によって一般的に表わされた、いくつもの再帰的DNSサーバと通信する。本明細書に開示されたように、再帰的サーバ６３０が、ホスティングプロバイダー、レジストラ、及び／又は、レジストリオペレーティングサーバ６００，６１０、および６２０のドメインのためのDNS関連のデータをキャッシュしてもよい。
【０１０５】
ドメインについてDNSデータを更新するリクエストが、例えば、レジストラ、DNSサービスプロバイダー、又は、登録者に由来してもよい（多様なシステム（例えば、コンピュータ６１１，６１２）を介して、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ６１６、又は、必要な機能を備えた他のネットワーク対応デバイスと無線又は他の通信を行う別のサーバ６１３を介して）。
【０１０６】
多様な通信、送信、および本明細書に開示された関連の機能が、例えば、ネットワーク６０５を介して実行され、かつ、サーバシステム（例えば、サーバ６００，６１０、および６２０）によって実行される開示された処理の結果が、既知の方法に従って、表示、格納、及び／又は、配布される。ネットワーク６０５が、いくつもの通信コンポーネント（有線、セル、衛星、光、及び／又は他の類似の通信リンクを含む）を含んでもよい。
【０１０７】
サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、第１ストレージ（図示せず、一般にランダムアクセスメモリ、又はRAM）、第２ストレージ（図示せず、一般にリードオンリーメモリ、又はROM）を含むストレージデバイスに接続されたいくつものプロセッサ（図示せず）を備えてもよい。これらストレージデバイスの両方が、適したタイプのコンピュータ読み取り可能な記録媒体（非一時的なストレージ媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、磁気テープ）、CD-ROMディスクなどの光媒体、及び／又は、光磁気媒体を含む）を含む。また、マスストレージデバイス（図示せず）が、プログラム、データなどを格納するのに使用され、かつ、一般に補助記憶媒体（例えば、主記憶装置よりも遅いハードディスク）である。好ましくは、マスストレージデバイス内に保持される情報が、仮想メモリとして、主記憶装置の一部として、一般的な方法で、組み込まれることが理解される。また、具体的なマスストレージデバイス（例えば、CD-ROM）がプロセッサへ一方向的にデータを渡してもよい。
【０１０８】
また、サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、１又は複数の入出力デバイス（例えば、ビデオモニタ、トラックボール、マウス、キーボード、マイク、タッチセンサ式のディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、又は、他の既知の入力デバイス）（他のコンピュータを含む）を含むインターフェースを備えてもよい。サーバ６００，６１０、および６２０（および、コンピュータ６１１，６１２）が、ネットワーク接続を使用して、コンピュータ又は他の電気通信ネットワーク６０５に接続される。ネットワーク６０５が、多様な有線、光、電気、および他の既知のネットワークに接続して、サーバ６００，６１０、および６２０、コンピュータ６１１，６１２、別のサーバ６１３、モバイルデバイス（複数可）６１４、ピコセルネットワークデバイス６１５、モバイルコンピュータ（複数可）６１６、再帰的サーバ６３０、および、類似の機能を有する他のデバイスの間で、情報を交換することができる。そのネットワーク接続を用いて、上記した方法のステップを実行する過程で、サーバ６００，６１０、および６２０（およびコンピュータ６１１，６１２）およびそのプロセッサが、ネットワーク６０５から情報を受信するか、又は、ネットワーク６０５へ情報を出力すると考えられる。上記したデバイスおよび素材は、コンピュータハードウェアおよびソフトウェア技術の当業者によく知られており、当業者に理解されるように個別又は網羅的に示す必要はない。上記したハードウェア要素が、上記した操作を実行するための１又は複数のモジュールとして動作するように（一般的に一時的に）構成される。
【０１０９】
加えて、本発明の実施例は、さらに、本明細書に開示された多様なコンピュータ実行オペレーションを実行するためのプログラム命令を含んだコンピュータ読み取り可能な記録媒体を含む。媒体が、単独で、又はプログラム命令と組み合わせて、データファイル、データ構造、テーブルなども含んでもよい。媒体およびプログラム命令が、本発明の目的のために特に設計されかつ構成されたものであってもよく、又は、それらが、コンピュータソフトウェア技術のスキルを有する人に使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例が、磁気媒体（例えば、フラッシュドライブ、ハードディスク、フロッピー（登録商標)ディスク、および磁気テープ）、光媒体（例えば、CD-ROMディスク）、光磁気媒体、および、プログラム命令を格納および実行するように特に構成されたハードウェアデバイス（例えば、リードオンリーメモリデバイス（ROM）、および、ランダムアクセスメモリ（RAM））を含む。プログラム命令の例が、機械コード（例えば、コンパイラによって生成される）、および、インタプリタを使用してコンピュータによって実行される高次レベルコードを含むファイルの両方を含む。
【０１１０】
上記した説明は、単に実例であり、本発明のすべての可能性のある実施例、アプリケーション、又は、変形例の網羅的なリストであることを意図されたものではない。したがって、開示された本発明の方法およびシステムの多様な修正例および変形例が、本発明の真の趣旨及び範囲から逸脱することなく、当業者に明らかになる。本発明は特定の実施例との関連で開示されたが、請求項に係る発明がその特定の実施例に不当に限定されないことを理解しなければならない。
【符号の説明】
【０１１１】
110 CAS１〜ｎ
120 NCCビジネスサービス
130 バッチ/ツール
142 署名サーバ1
144, 148 ＨＳＭ
146 署名サーバn
150 データベース
【特許請求の範囲】
【請求項１】
少なくとも１つのDNSSECクライアントアプリケーションおよび複数の電子署名モジュールと相互作用するように構成されたDNSSEC署名サーバであって、DNSSEC署名サーバが、
プロセッサと、
前記プロセッサによって実行されたとき、
第１データに署名する前記少なくとも１つクライアントアプリケーションから署名リクエストを受信し、
前記第１データについて、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定し、
前記複数の電子署名モジュールのうちの１つへ第１データを転送し、
前記電子署名モジュールから電子的に署名されたバージョンの第１データを受信し、
前記クライアントアプリケーションへ署名された第１データを提供する
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備えたサーバ。
【請求項２】
前記署名サーバが、さらに、
同じ署名リクエストの一部として、第２データに署名するリクエストを受信し、
前記第２データについて、前記第１データに対する少なくとも１つのアクティブなKSK及び／又はアクティブなZSKとは異なる、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定し、
前記複数の電子署名モジュールのうちの１つへ第２データを転送し、
前記電子署名モジュールから電子的に署名されたバージョンの第２データを受信し、
前記クライアントアプリケーションへ署名された第２データを提供する
ように構成された請求項１に記載のサーバ。
【請求項３】
前記第１データがDNSデータを含み、かつ、
前記電子署名モジュールが、ゾーン全体に署名せず、DNSSECプロトコルに従って、DNSデータの特定の部分に署名するように構成された請求項１に記載のサーバ。
【請求項４】
前記署名サーバが、さらに、追加的な非DNSSEC電子署名機能を提供するように構成された請求項３に記載のサーバ。
【請求項５】
前記署名サーバが、さらに、
単一のリクエストパケットの一部として複数の署名リクエストを受信し、かつ、
前記リクエストパケットを解析して、相互に異なるアクティブなKSK、アクティブなZSK、および署名プロトコルのうちの少なくとも１つを有する異なる署名リクエストを識別する
ように構成された請求項１に記載のサーバ。
【請求項６】
前記少なくとも１つのアクティブなKSKおよびアクティブなZSKが、署名リクエストに含まれたTLD識別子に基づいて決定される請求項１に記載のサーバ。
【請求項７】
前記署名サーバが、さらに、
前記署名リクエストに含まれたサービスタイプ識別子に基づき、複数の異なる電子署名機能の中から、リクエストされた署名機能を区別し、かつ、
前記サービスタイプ識別子に基づき、非DNSSEC電子署名モジュールへ非DNSSEC電子署名リクエストを送る
ように構成された請求項６に記載のサーバ。
【請求項８】
前記電子署名モジュールのそれぞれが、前記署名サーバのプロセッサから物理的に離れており、かつ、署名サーバによって提供されるデータに電子的に署名するように構成された、ＨＳＭ（Hardware Security Module）を含む請求項１に記載のサーバ。
【請求項９】
前記ＨＳＭが、エイリアス識別子によって識別された複数の鍵を含み、かつ、
前記署名サーバが、さらに、電子署名モジュールへ少なくとも１つのKSKおよびZSKを渡さず、電子署名モジュールへDNSデータのためのKSKおよびZSKのうちの少なくとも１つに対するエイリアス識別子を渡すように構成された請求項８に記載のサーバ。
【請求項１０】
前記署名サーバが、さらに、アクティブなKSK又はZSKのデータベースを周期的にチェックし、かつ、データベースから受信した情報に基づき、どのエイリアス識別子が所定時間にわたりアクティブであるかを決定するように構成され、かつ、
前記電子署名モジュールへ渡されたエイリアス識別子が、アクティブなエイリアス識別子である請求項９に記載のサーバ。
【請求項１１】
前記サーバが、さらに、前記少なくとも１つのアクティブなKSK及び／又はZSKに基づき、第１データを送信する特定のＨＳＭを識別するように構成された請求項９に記載のサーバ。
【請求項１２】
前記署名サーバが、さらに、異なるトップレベルドメインの下のドメインに関するリクエストを処理するように構成された請求項１に記載のサーバ。
【請求項１３】
前記署名が、さらに、複数のレジストラによって管理された少なくとも２つのドメインに関するリクエストを処理するように構成された請求項１に記載のサーバ。
【請求項１４】
前記クライアントと署名サーバとの間の通信が２方向ＳＳＬを介して実行される請求項１に記載のサーバ。
【請求項１５】
前記署名が、さらに、
前記第１データについて、１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムを決定し、
前記１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムに対する識別子を電子署名モジュールへ転送し、
前記電子署名モジュールから複数の電子的に署名されたバージョンの第１データを受信し、かつ、
前記複数の電子的に署名されたバージョンの第１データをクライアントアプリケーションへ提供する
ように構成された請求項１に記載のサーバ。
【請求項１６】
前記電子署名モジュールが、前記第１データの受信に応答して、データベースから、第１データのためのアクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを動的にロードする請求項１に記載のサーバ。
【請求項１７】
少なくとも１つのDNSSECクライアントアプリケーションおよび複数の電子署名モジュールと相互作用するように構成されたDNSSEC署名サーバによって、DNS情報を暗号化する方法であって、方法が、
第１データに署名する前記少なくとも１つのクライアントアプリケーションから署名リクエストを受信するステップと、
前記第１データについて、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定するステップと、
前記複数の電子署名モジュールのうちの１つへ第１データを転送するステップと、
前記電子署名モジュールから、電子的に署名されたバージョンの第１データを受信するステップと、
前記クライアントアプリケーションへ署名された第１データを提供するステップと
を含む方法。
【請求項１８】
同じ署名リクエストの一部として、第２データに署名するリクエストを受信するステップと、
前記第２データについて、前記第１データに対する少なくとも１つのアクティブなKSK及び／又はアクティブなZSKとは異なる、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定するステップと、
前記複数の電子署名モジュールのうちの１つへ第２データを転送するステップと、
前記電子署名モジュールから電子的に署名されたバージョンの第２データを受信するステップと、
前記クライアントアプリケーションへ署名された第２データを提供するステップと
をさらに含む請求項１７に記載の方法。
【請求項１９】
前記第１データがDNSデータを含み、かつ、
前記電子署名モジュールが、ゾーン全体に署名せず、DNSSECプロトコルに従って、DNSデータの特定の部分に署名するように構成された請求項１７に記載の方法。
【請求項２０】
前記署名サーバが、さらに、追加的な非DNSSEC電子署名機能を提供するように構成された請求項１９に記載の方法。
【請求項２１】
複数の署名リクエストが単一のリクエストパケットの一部として受信され、方法が、さらに、
前記リクエストパケットを解析して、相互に異なるアクティブなKSK、アクティブなZSK、および署名プロトコルのうちの少なくとも１つを有する異なる署名リクエストを識別するステップ
を含む請求項１７に記載の方法。
【請求項２２】
前記少なくとも１つのアクティブなKSKおよびアクティブなZSKが、署名リクエストに含まれたTLD識別子に基づいて決定される請求項１７に記載の方法。
【請求項２３】
前記署名リクエストに含まれたサービスタイプ識別子に基づき、複数の異なる電子署名機能の中から、リクエストされた署名機能を区別するステップと、
前記サービスタイプ識別子に基づき、非DNSSEC電子署名モジュールへ非DNSSEC電子署名リクエストを送るステップと
をさらに含む請求項２２に記載の方法。
【請求項２４】
前記電子署名モジュールのそれぞれが、前記署名サーバのプロセッサから物理的に離れており、かつ、署名サーバによって提供されるデータに電子的に署名するように構成された、ＨＳＭ（Hardware Security Module）を含む請求項１７に記載の方法。
【請求項２５】
前記ＨＳＭが、エイリアス識別子によって識別された複数の鍵を含み、かつ、
方法が、さらに、電子署名モジュールへ少なくとも１つのKSKおよびZSKを渡さず、電子署名モジュールへDNSデータのためのKSKおよびZSKのうちの少なくとも１つに対するエイリアス識別子を渡すステップを含む請求項２４に記載の方法。
【請求項２６】
アクティブなKSK又はZSKのデータベースを周期的にチェックして、データベースから受信した情報に基づき、どのエイリアス識別子が所定時間にわたりアクティブであるかを決定するステップをさらに含み、
前記電子署名モジュールへ渡されたエイリアス識別子が、アクティブなエイリアス識別子である請求項２５に記載の方法。
【請求項２７】
前記少なくとも１つのアクティブなKSK及び／又はZSKに基づき、第１データに送信する特定のＨＳＭを識別するステップをさらに含む請求項２５に記載の方法。
【請求項２８】
異なるトップレベルドメインの下のドメインに関するリクエストを処理するステップをさらに含む請求項１７に記載の方法。
【請求項２９】
複数のレジストラによって管理された少なくとも２つのドメインに関するリクエストを処理するステップをさらに含む請求項１７に記載の方法。
【請求項３０】
前記クライアントと署名サーバとの間の通信が２方向ＳＳＬを介して実行される請求項１７に記載の方法。
【請求項３１】
前記第１データについて、１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムを決定するステップと、
前記１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムに対する識別子を電子署名モジュールへ転送するステップと、
前記電子署名モジュールから複数の電子的に署名されたバージョンの第１データを受信するステップと、
前記複数の電子的に署名されたバージョンの第１データをクライアントアプリケーションへ提供するステップと
をさらに含む請求項１７に記載の方法。
【請求項３２】
前記電子署名モジュールで、前記第１データの受信に応答して、データベースから、第１データのためのアクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを動的にロードするステップをさらに含む請求項１７に記載の方法。
【請求項１】
少なくとも１つのDNSSECクライアントアプリケーションおよび複数の電子署名モジュールと相互作用するように構成されたDNSSEC署名サーバであって、DNSSEC署名サーバが、
プロセッサと、
前記プロセッサによって実行されたとき、
第１データに署名する前記少なくとも１つクライアントアプリケーションから署名リクエストを受信し、
前記第１データについて、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定し、
前記複数の電子署名モジュールのうちの１つへ第１データを転送し、
前記電子署名モジュールから電子的に署名されたバージョンの第１データを受信し、
前記クライアントアプリケーションへ署名された第１データを提供する
ように、権威サーバとして署名サーバを動作させるコンピュータ読み取り可能なコードを含む、ストレージデバイスと
を備えたサーバ。
【請求項２】
前記署名サーバが、さらに、
同じ署名リクエストの一部として、第２データに署名するリクエストを受信し、
前記第２データについて、前記第１データに対する少なくとも１つのアクティブなKSK及び／又はアクティブなZSKとは異なる、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定し、
前記複数の電子署名モジュールのうちの１つへ第２データを転送し、
前記電子署名モジュールから電子的に署名されたバージョンの第２データを受信し、
前記クライアントアプリケーションへ署名された第２データを提供する
ように構成された請求項１に記載のサーバ。
【請求項３】
前記第１データがDNSデータを含み、かつ、
前記電子署名モジュールが、ゾーン全体に署名せず、DNSSECプロトコルに従って、DNSデータの特定の部分に署名するように構成された請求項１に記載のサーバ。
【請求項４】
前記署名サーバが、さらに、追加的な非DNSSEC電子署名機能を提供するように構成された請求項３に記載のサーバ。
【請求項５】
前記署名サーバが、さらに、
単一のリクエストパケットの一部として複数の署名リクエストを受信し、かつ、
前記リクエストパケットを解析して、相互に異なるアクティブなKSK、アクティブなZSK、および署名プロトコルのうちの少なくとも１つを有する異なる署名リクエストを識別する
ように構成された請求項１に記載のサーバ。
【請求項６】
前記少なくとも１つのアクティブなKSKおよびアクティブなZSKが、署名リクエストに含まれたTLD識別子に基づいて決定される請求項１に記載のサーバ。
【請求項７】
前記署名サーバが、さらに、
前記署名リクエストに含まれたサービスタイプ識別子に基づき、複数の異なる電子署名機能の中から、リクエストされた署名機能を区別し、かつ、
前記サービスタイプ識別子に基づき、非DNSSEC電子署名モジュールへ非DNSSEC電子署名リクエストを送る
ように構成された請求項６に記載のサーバ。
【請求項８】
前記電子署名モジュールのそれぞれが、前記署名サーバのプロセッサから物理的に離れており、かつ、署名サーバによって提供されるデータに電子的に署名するように構成された、ＨＳＭ（Hardware Security Module）を含む請求項１に記載のサーバ。
【請求項９】
前記ＨＳＭが、エイリアス識別子によって識別された複数の鍵を含み、かつ、
前記署名サーバが、さらに、電子署名モジュールへ少なくとも１つのKSKおよびZSKを渡さず、電子署名モジュールへDNSデータのためのKSKおよびZSKのうちの少なくとも１つに対するエイリアス識別子を渡すように構成された請求項８に記載のサーバ。
【請求項１０】
前記署名サーバが、さらに、アクティブなKSK又はZSKのデータベースを周期的にチェックし、かつ、データベースから受信した情報に基づき、どのエイリアス識別子が所定時間にわたりアクティブであるかを決定するように構成され、かつ、
前記電子署名モジュールへ渡されたエイリアス識別子が、アクティブなエイリアス識別子である請求項９に記載のサーバ。
【請求項１１】
前記サーバが、さらに、前記少なくとも１つのアクティブなKSK及び／又はZSKに基づき、第１データを送信する特定のＨＳＭを識別するように構成された請求項９に記載のサーバ。
【請求項１２】
前記署名サーバが、さらに、異なるトップレベルドメインの下のドメインに関するリクエストを処理するように構成された請求項１に記載のサーバ。
【請求項１３】
前記署名が、さらに、複数のレジストラによって管理された少なくとも２つのドメインに関するリクエストを処理するように構成された請求項１に記載のサーバ。
【請求項１４】
前記クライアントと署名サーバとの間の通信が２方向ＳＳＬを介して実行される請求項１に記載のサーバ。
【請求項１５】
前記署名が、さらに、
前記第１データについて、１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムを決定し、
前記１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムに対する識別子を電子署名モジュールへ転送し、
前記電子署名モジュールから複数の電子的に署名されたバージョンの第１データを受信し、かつ、
前記複数の電子的に署名されたバージョンの第１データをクライアントアプリケーションへ提供する
ように構成された請求項１に記載のサーバ。
【請求項１６】
前記電子署名モジュールが、前記第１データの受信に応答して、データベースから、第１データのためのアクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを動的にロードする請求項１に記載のサーバ。
【請求項１７】
少なくとも１つのDNSSECクライアントアプリケーションおよび複数の電子署名モジュールと相互作用するように構成されたDNSSEC署名サーバによって、DNS情報を暗号化する方法であって、方法が、
第１データに署名する前記少なくとも１つのクライアントアプリケーションから署名リクエストを受信するステップと、
前記第１データについて、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定するステップと、
前記複数の電子署名モジュールのうちの１つへ第１データを転送するステップと、
前記電子署名モジュールから、電子的に署名されたバージョンの第１データを受信するステップと、
前記クライアントアプリケーションへ署名された第１データを提供するステップと
を含む方法。
【請求項１８】
同じ署名リクエストの一部として、第２データに署名するリクエストを受信するステップと、
前記第２データについて、前記第１データに対する少なくとも１つのアクティブなKSK及び／又はアクティブなZSKとは異なる、アクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを決定するステップと、
前記複数の電子署名モジュールのうちの１つへ第２データを転送するステップと、
前記電子署名モジュールから電子的に署名されたバージョンの第２データを受信するステップと、
前記クライアントアプリケーションへ署名された第２データを提供するステップと
をさらに含む請求項１７に記載の方法。
【請求項１９】
前記第１データがDNSデータを含み、かつ、
前記電子署名モジュールが、ゾーン全体に署名せず、DNSSECプロトコルに従って、DNSデータの特定の部分に署名するように構成された請求項１７に記載の方法。
【請求項２０】
前記署名サーバが、さらに、追加的な非DNSSEC電子署名機能を提供するように構成された請求項１９に記載の方法。
【請求項２１】
複数の署名リクエストが単一のリクエストパケットの一部として受信され、方法が、さらに、
前記リクエストパケットを解析して、相互に異なるアクティブなKSK、アクティブなZSK、および署名プロトコルのうちの少なくとも１つを有する異なる署名リクエストを識別するステップ
を含む請求項１７に記載の方法。
【請求項２２】
前記少なくとも１つのアクティブなKSKおよびアクティブなZSKが、署名リクエストに含まれたTLD識別子に基づいて決定される請求項１７に記載の方法。
【請求項２３】
前記署名リクエストに含まれたサービスタイプ識別子に基づき、複数の異なる電子署名機能の中から、リクエストされた署名機能を区別するステップと、
前記サービスタイプ識別子に基づき、非DNSSEC電子署名モジュールへ非DNSSEC電子署名リクエストを送るステップと
をさらに含む請求項２２に記載の方法。
【請求項２４】
前記電子署名モジュールのそれぞれが、前記署名サーバのプロセッサから物理的に離れており、かつ、署名サーバによって提供されるデータに電子的に署名するように構成された、ＨＳＭ（Hardware Security Module）を含む請求項１７に記載の方法。
【請求項２５】
前記ＨＳＭが、エイリアス識別子によって識別された複数の鍵を含み、かつ、
方法が、さらに、電子署名モジュールへ少なくとも１つのKSKおよびZSKを渡さず、電子署名モジュールへDNSデータのためのKSKおよびZSKのうちの少なくとも１つに対するエイリアス識別子を渡すステップを含む請求項２４に記載の方法。
【請求項２６】
アクティブなKSK又はZSKのデータベースを周期的にチェックして、データベースから受信した情報に基づき、どのエイリアス識別子が所定時間にわたりアクティブであるかを決定するステップをさらに含み、
前記電子署名モジュールへ渡されたエイリアス識別子が、アクティブなエイリアス識別子である請求項２５に記載の方法。
【請求項２７】
前記少なくとも１つのアクティブなKSK及び／又はZSKに基づき、第１データに送信する特定のＨＳＭを識別するステップをさらに含む請求項２５に記載の方法。
【請求項２８】
異なるトップレベルドメインの下のドメインに関するリクエストを処理するステップをさらに含む請求項１７に記載の方法。
【請求項２９】
複数のレジストラによって管理された少なくとも２つのドメインに関するリクエストを処理するステップをさらに含む請求項１７に記載の方法。
【請求項３０】
前記クライアントと署名サーバとの間の通信が２方向ＳＳＬを介して実行される請求項１７に記載の方法。
【請求項３１】
前記第１データについて、１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムを決定するステップと、
前記１つより多くのアクティブな鍵、及び／又は、アクティブなアルゴリズムに対する識別子を電子署名モジュールへ転送するステップと、
前記電子署名モジュールから複数の電子的に署名されたバージョンの第１データを受信するステップと、
前記複数の電子的に署名されたバージョンの第１データをクライアントアプリケーションへ提供するステップと
をさらに含む請求項１７に記載の方法。
【請求項３２】
前記電子署名モジュールで、前記第１データの受信に応答して、データベースから、第１データのためのアクティブなKSKおよびアクティブなZSKのうちの少なくとも１つを動的にロードするステップをさらに含む請求項１７に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−２３５４６４（Ｐ２０１２−２３５４６４Ａ）
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１０２５６２（Ｐ２０１２−１０２５６２）
【出願日】平成２４年４月２７日（２０１２．４．２７）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願番号】特願２０１２−１０２５６２（Ｐ２０１２−１０２５６２）
【出願日】平成２４年４月２７日（２０１２．４．２７）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
[ Back to top ]