"名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第1の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第2の権威サーバとを含む名前解決システムであって、前記第1の権威サーバは、新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第2の権威サーバに通知する通知部を備え、前記第2の権威サーバは、前記通知部によって通知された場合に、前記第1の権威サーバから前記新署名鍵を取得する取得部と、前記取得部によって取得された新署名鍵に対応する特定データである新特定データを生成する生成部とを備えたことを特徴とする名前解決システム。前記第1の権威サーバは、前記生成部によって前記新特定データが生成された場合に、前記新署名鍵が登録される前の署名鍵である旧署名鍵を削除する第1の更新部をさらに備え、前記第2の権威サーバは、前記第1の更新部によって前記旧署名鍵が削除された場合に、該旧署名鍵に対応する特定データを削除する第2の更新部をさらに備えたことを特徴とする請求項1に記載の名前解決システム。前記第2の権威サーバは、前記通知部によって通知された場合に、前記新特定データを生成するタイミングを前記第1の権威サーバに通知する待機通知部をさらに備え、前記取得部は、前記待機通知部によって通知されたタイミングになった場合に、前記第1の権威サーバから前記新署名鍵を取得し、前記第1の更新部は、前記待機通知部によって通知されたタイミングになった場合に、前記第2の権威サーバに問い合わせることにより前記新特定データが生成されたか否かを判定し、前記新特定データが生成された場合に、前記旧署名鍵を削除することを特徴とする請求項2に記載の名前解決システム。前記第1の権威サーバは、前記新署名鍵が登録された場合に、前記新署名鍵が登録される前の署名鍵である旧署名鍵を用いて、前記新署名鍵及び前記旧署名鍵の電子署名を作成する作成部をさらに備え、前記取得部は、前記通知部によって通知された場合に、前記第1の権威サーバから、前記新署名鍵と前記旧署名鍵と前記作成部によって作成された電子署名とを取得し、前記第2の権威サーバは、前記旧署名鍵に対応する特定データを用いて、前記取得部によって取得された前記旧署名鍵の正当性を検証し、前記旧署名鍵の検証が成功した場合に、前記取得部によって取得された電子署名を用いて、前記新署名鍵及び前記旧署名鍵の正当性を検証する検証部をさらに備え、前記生成部は、前記検証部による検証が成功した場合に、前記取得部によって取得された新署名鍵に対応する前記新特定データを生成することを特徴とする請求項1~3のいずれか一つに記載の名前解決システム。前記第1の権威サーバは、名前解決の結果の電子署名を作成するための秘密鍵に対応する公開鍵を署名するための署名用秘密鍵及び署名用公開鍵を前記署名鍵として保持し、前記第2の権威サーバは、前記署名用公開鍵のハッシュ値を前記特定データとして保持することを特徴とする請求項1~4のいずれか一つに記載の名前解決システム。名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第1の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第2の権威サーバとを含む名前解決システムで実行される鍵更新方法であって、前記第1の権威サーバに新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第1の権威サーバから前記第2の権威サーバに通知する通知工程と、前記通知工程によって新署名鍵が登録された旨を前記第2の権威サーバに通知された場合に、前記第2の権威サーバが前記第1の権威サーバから前記新署名鍵を取得する取得工程と、前記取得工程によって取得された新署名鍵に対応する特定データである新特定データを生成する生成工程とを含んだことを特徴とする鍵更新方法。ところで、DNSSECが適用されているDNSにおいて、ネットワーク管理者は、ZSKやKSKを定期的に更新することが望ましい。これは、第三者によってZSKやKSKが解読されるおそれがあるからである。ここで、上位権威サーバが下位権威サーバのKSK公開鍵に対応するDSレコードを保持するので、下位権威サーバのネットワーク管理者は、かかる下位権威サーバが保持するKSKを更新する場合に、上位権威サーバのDSレコードについても更新することを要する。しかしながら、ネットワーク管理者が、更新対象のKSKに対応するDSレコードを常に正しく更新できるとは限らない。例えば、ネットワーク管理者の操作ミス等により誤ったDSレコードが上位権威サーバに登録される場合もある。かかる場合には、キャッシュサーバは、署名検証に失敗し、クライアント装置に対して、名前解決に失敗したことを示すエラーServerFailureを返信することになる。そこで、本発明は、上述した従来技術の課題を解決するためになされたものであり、鍵の更新誤りを防止することができる名前解決システム及び鍵更新方法を提供することを目的とする。実施形態に係る名前解決システムは、名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第1の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第2の権威サーバとを含む名前解決システムであって、前記第1の権威サーバは、新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第2の権威サーバに通知する通知部を備え、前記第2の権威サーバは、前記通知部によって通知された場合に、前記第1の権威サーバから前記新署名鍵を取得する取得部と、前記取得部によって取得された新署名鍵に対応する特定データである新特定データを生成する生成部とを備えたことを特徴とする。実施形態に係る名前解決システム及び鍵更新方法は、鍵の更新誤りを防止することができるという効果を奏する。以下に、本発明に係る名前解決システム及び鍵更新方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。まず、図1を用いて、実施例1に係る名前解決システムについて説明する。図1は、実施例1に係る名前解決システムの構成例を示す図である。図1に示す名前解決システム1は、クライアント装置10、キャッシュサーバ20、権威サーバ群30、管理装置110、120及び130を有する。ここで、図1に示す各装置は、インターネットを介して通信可能な状態で接続される。クライアント装置10は、例えば、PCPersonalComputer、携帯電話機、PDAPersonalDigitalAssistant等であり、キャッシュサーバ20に対して、名前解決の依頼を送信する。なお、図1では、キャッシュサーバ20に接続されるクライアント装置10を一台のみ示しているが、実際には、キャッシュサーバ20には複数台のクライアント装置が接続される。キャッシュサーバ20は、クライアント装置10から所定のドメイン名例えば、wwwexamplejpの名前解決の依頼を受け付ける。そして、キャッシュサーバ20は、権威サーバ群30に、依頼されたドメイン名の名前解決のための問い合わせを行うとともに、権威サーバ群30からの応答をキャッシュする機能を有する。権威サーバ群30は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。図1に示した例では、権威サーバ群30には、権威サーバ31、32及び33が含まれる。なお、図1では、権威サーバ群30に3台の権威サーバが含まれる例を示したが、権威サーバ群30には、4台以上の権威サーバが含まれてもよい。これらの権威サーバ31、32及び33は、DNSSECのDSDelegationSigner方式が適用されており、自身が管理するゾーンに関する情報に署名を行うための公開鍵及び秘密鍵のペアであるZSKや、ZSKに署名を行うための公開鍵及び秘密鍵のペアであるKSKや、下位の権威サーバが保持するKSKの公開鍵のハッシュ値であるDSレコード等を保持する。なお、以下では、各権威サーバが保持するZSK公開鍵、KSK公開鍵、DSレコード、及び、後述するAAddressレコードやNSレコード等を含むデータ群をゾーンデータと表記する場合がある。管理装置110、120、130は、権威サーバ群30のゾーンデータを管理するための装置である。図1に示した例では、管理装置110は、権威サーバ31を管理するネットワーク管理者によって用いられる。実施例1における管理装置110は、権威サーバ31が保持するZSK公開鍵及び秘密鍵やKSK公開鍵及び秘密鍵やDSレコード等のゾーンデータを保持しているものとする。そして、管理装置110は、ネットワーク管理者による指示に従って、かかるゾーンデータを更新し、更新後のゾーンデータを権威サーバ31に反映する。また、管理装置120は、権威サーバ32を管理するネットワーク管理者によって用いられ、権威サーバ32のゾーンデータを更新及び反映する。また、管理装置130は、権威サーバ33を管理するネットワーク管理者によって用いられ、権威サーバ33のゾーンデータを更新及び反映する。ここで、図2~図5を用いて、キャッシュサーバ20と権威サーバ群30とにより実行されるDNSSECの処理の一例を説明する。その後に、図6~図15を用いて、施例1における管理装置110、120、130について説明する。図2は、実施例1に係る名前解決システム1が有するキャッシュサーバの構成例を示す図である。図2に例示するように、実施例1におけるキャッシュサーバ20は、応答部21と、検証部22と、キャッシュ部23と、要求部24とを有する。応答部21は、クライアント装置10との間で通信を行う。要求部24は、権威サーバ群30との間で通信を行う。また、要求部24は、権威サーバ群から受信した応答データをキャッシュ部23に格納する。検証部22は、キャッシュ部23に格納された権威サーバ群30からの応答内容及び応答内容の電子署名を用いて検証を行う。キャッシュ部23は、署名検証に成功した応答内容をキャッシュする。具体的には、キャッシュ部23は、署名検証に成功した場合、名前解決を依頼されたドメイン名と、ドメイン名のIPアドレスとを対応付けた情報をキャッシュする。ここで、応答部21は、クライアント装置10から名前解決を依頼された場合、依頼されたドメイン名のIPアドレスが、キャッシュ部23にキャッシュ情報として既に格納されているか否かを判定する。応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として既に格納されている場合、クライアント装置10に対してIPアドレスを返信する。一方、応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部24に転送する。そして、要求部24は、依頼内容に基づいて、権威サーバ群30に問い合わせを行う。ここで、図3を用いて、キャッシュサーバ20が、クライアント装置10からキャッシュ情報として格納されていないwwwexamplejpの名前解決の依頼を受け付けた場合に、権威サーバ群30に対してwwwexamplejpに関する問い合わせを行う例について説明する。図3は、権威サーバ群30が有する権威サーバの一例を示す図である。なお、以下では、クライアント装置10がIPv4InternetProtocolversion4アドレスを要求している場合について説明する。図3に示した例のように、キャッシュサーバ20は、wwwexamplejpの名前解決を行う場合に、権威サーバ31ここではルートサーバ31であるものとする、権威サーバ32ここではjpサーバ32であるものとする、権威サーバ33ここではexamplejpサーバ33であるものとするに対して問い合わせを行う。ルートサーバ31は、名前空間の最上位に設置されるサーバであり、jpやcomなど、一番上位のドメイン名TLD:TopLevelDomainを管理するサーバのインターネット上の位置IPアドレスを管理する。また、jpサーバ32は、jpのTLDサーバであり、jpで管理されるexamplejpやadjpなどのインターネット上の位置IPアドレスを管理する。また、examplejpサーバ33は、自身が管理する名前空間の中にあるホスト、例えば、wwwexamplejpやftpexamplejpのインターネット上の位置IPアドレスを管理する。なお、上位の権威サーバは、自身が管理する下位の権威サーバのドメイン名をNSNameServerレコードとして保持し、かかる下位の権威サーバのIPアドレスをAレコード又はAAAAレコードクワッドAレコードとして保持する。例えば、jpサーバ32は、下位のexamplejpサーバ33のNSレコードやAレコード等を保持する。これらのルートサーバ31、jpサーバ32及びexamplejpサーバ33は、DNSSECに対応しており、ZSK及びKSKを保持する。図3に示した例では、ルートサーバ31は、ZSKとして、ZSK-A公開鍵及びZSK-A秘密鍵を保持し、KSKとして、KSK-A公開鍵及びKSK-A秘密鍵を保持する。また、jpサーバ32は、ZSKとして、ZSK-B公開鍵及びZSK-B秘密鍵を保持し、KSKとして、KSK-B公開鍵及びKSK-B秘密鍵を保持する。また、examplejpサーバ33は、ZSKとして、ZSK-C公開鍵及びZSK-C秘密鍵を保持し、KSKとして、KSK-C公開鍵及びKSK-C秘密鍵を保持する。なお、図3に示した例では、ルートサーバ31、jpサーバ32及びexamplejpサーバ33が、ZSK及びKSKの秘密鍵を保持する例を示した。しかし、実際には、ルートサーバ31、jpサーバ32及びexamplejpサーバ33は、ZSK及びKSKの秘密鍵については、自装置内に保持しない。これらのZSK及びKSKの秘密鍵は、ルートサーバ31等がアクセスできるが一般ユーザからアクセスできない別装置によって管理される。そして、ルートサーバ31、jpサーバ32及びexamplejpサーバ33は、この別装置によってZSK及びKSKの秘密鍵を用いて生成されたゾーンデータ例えば、NSレコードやAレコード等をかかる別装置から受け取り、受け取ったゾーンデータを保持する。ただし、このような別装置が存在しないシステムの場合には、ルートサーバ31、jpサーバ32及びexamplejpサーバ33は、図3に示した例のように、ZSK及びKSKの秘密鍵を保持してもよい。ここで、DNSSECでは、ルートサーバ31、jpサーバ32、examplejpサーバ33及びキャッシュサーバ20は、同一のハッシュ関数を用いてハッシュ値を計算する。また、DS方式では、下位の権威サーバは、上位の権威サーバに、自身のKSKの公開鍵のハッシュ値であるDSレコードを予め通知している。すなわち、examplejpサーバ33は、自身のDSレコードをjpサーバ32に通知し、jpサーバ32は、自身のDSレコードをルートサーバ31に通知する。そして、ルートサーバ31は、自身のDSレコードをキャッシュサーバ20に通知する。そして、ルートサーバ31、jpサーバ32、examplejpサーバ33及びキャッシュサーバ20は、図4に例示するデータを用いて、DNSSECにおける電子署名を用いた署名検証を実現する。図4は、DNSSECに用いられるゾーンデータの一例を示す図である。図4Aに示すように、examplejpサーバ33は、wwwexamplejpのIPv4アドレスの情報を含むAレコードのデータ33aを保持する。なお、クライアント装置10がIPv6InternetProtocolversion6アドレスを要求している場合には、DNSSECに用いられるデータは、wwwexamplejpのIPv6アドレスの情報を含むAAAAレコードとなる。また、図4Aに示すように、examplejpサーバ33は、Aレコードのハッシュ値をZSK-C秘密鍵で暗号化した電子署名であるデータ33bを保持する。また、図4Aに示すように、examplejpサーバ33は、ZSK-C公開鍵のデータ33cと、KSK-C公開鍵のデータ33dと、ZSK-C公開鍵及びKSK-C公開鍵のハッシュ値をKSK-C秘密鍵で暗号化した電子署名であるデータ33eを保持する。このように、ZSK-C公開鍵及びKSK-C公開鍵であるDNSKEYについては、ZSK-C公開鍵とKSK-C公開鍵とが統合されたデータに対して1つの電子署名データ33eが作成される。すなわち、examplejpサーバ33は、wwwexamplejpのAレコード及びAレコードの署名として、データ33a及びデータ33bを保持する。また、examplejpサーバ33は、自身のDNSKEYとして、データ33c及びデータ33dを保持する。また、examplejpサーバ33は、DNSKEYの署名として、データ33eを保持する。また、examplejpサーバ33は、自身よりも下位の権威サーバが存在する場合には、かかる下位の権威サーバのDSレコード下位の権威サーバのKSK公開鍵のハッシュ値を保持する。また、図4Bに示すように、jpサーバ32は、examplejpサーバ33のDSレコード、すなわち、KSK-C公開鍵のハッシュ値であるデータ32aと、DSレコードKSK-C公開鍵のハッシュ値をZSK-B秘密鍵で暗号化した電子署名であるデータ32bを保持する。また、図4Bに示すように、jpサーバ32は、ZSK-B公開鍵のデータ32cと、KSK-B公開鍵のデータ32dと、ZSK-B公開鍵及びKSK-B公開鍵のハッシュ値をKSK-B秘密鍵で暗号化した電子署名であるデータ32eを保持する。すなわち、jpサーバ32は、examplejpサーバ33のDSレコード及びDSレコードの署名として、データ32a及びデータ32bを保持する。また、jpサーバ32は、自身のDNSKEYとして、データ32c及びデータ32dを保持する。また、jpサーバ32は、DNSKEYの署名として、データ32eを保持する。また、図4Cに示すように、ルートサーバ31は、jpサーバ32のDSレコード、すなわち、KSK-B公開鍵のハッシュ値であるデータ31aと、DSレコードKSK-B公開鍵のハッシュ値をZSK-A秘密鍵で暗号化した電子署名であるデータ31bを保持する。また、図4Cに示すように、ルートサーバ31は、ZSK-A公開鍵のデータ31cと、KSK-A公開鍵のデータ31dと、ZSK-A公開鍵及びKSK-A公開鍵のハッシュ値をKSK-A秘密鍵で暗号化した電子署名であるデータ31eを保持する。すなわち、ルートサーバ31は、jpサーバ32のDSレコード及びDSレコードの署名として、データ31a及びデータ31bを保持する。また、ルートサーバ31は、自身のDNSKEYとして、データ31c及びデータ31dを保持する。また、ルートサーバ31は、DNSKEYの署名として、データ31eを保持する。そして、図4Dに示すように、キャッシュサーバ20は、ルートサーバ31のDSレコード、すなわち、KSK-A公開鍵のハッシュ値であるデータ23aをキャッシュ部23内に保持する。なお、図4では、キャッシュサーバ20が、ルートサーバ31のDSレコードであるKSK-A公開鍵のハッシュ値をキャッシュ部23に保持する例を示した。しかし、キャッシュサーバ20は、DSレコードではなく、KSK-A公開鍵自体をキャッシュ部23に保持してもよい。具体的には、キャッシュサーバ20は、ルートサーバ31によって保持されているデータ31eと比較した後のKSK-A公開鍵キャッシュ部23に保持してもよい。図4に例示したデータを用いて、実施例1に係る名前解決システム1が実行する署名検証処理について、図5を用いて説明する。図5は、実施例1に係る名前解決システム1が実行する署名検証処理の一例を示すシーケンス図である。図5に示すように、クライアント装置10は、キャッシュサーバ20の応答部21に対して、wwwexamplejpのAレコードを問い合わせる名前解決の依頼を行うステップS1。名前解決の依頼を受け付けた応答部21は、要求部24に名前解決の依頼内容を転送しステップS2、要求部24は、ルートサーバ31にAレコードを問い合わせるステップS3。wwwexamplejpのAレコードの問い合わせを受け付けたルートサーバ31は、NSレコードを参照して、jpサーバ32に問い合わせて下さいと要求部24に返信するステップS4。具体的には、ルートサーバ31は、jpサーバ32のIPアドレスを要求部24に返信する。そして、要求部24は、jpサーバ32にAレコードを問い合わせるステップS5。wwwexamplejpのAレコードの問い合わせを受け付けたjpサーバ32は、NSレコードを参照して、examplejpサーバ33に問い合わせて下さいと要求部24に返信するステップS6。すなわち、jpサーバ32は、examplejpサーバ33のIPアドレスを要求部24に返信する。そして、要求部24は、examplejpサーバ33にAレコードを問い合わせるステップS7。wwwexamplejpのAレコードの問い合わせを受け付けたexamplejpサーバ33は、wwwexamplejpのAレコード及びAレコードの署名を要求部24に返信するステップS8。すなわち、examplejpサーバ33は、図4Aに示すデータ33a及びデータ33bを返信する。そして、要求部24は、examplejpサーバ33に対して、examplejpサーバ33のDNSKEY及びDNSKEYの署名を問い合わせステップS9、examplejpサーバ33は、DNSKEY及びDNSKEYの署名を要求部24に返信するステップS10。すなわち、examplejpサーバ33は、図4Aに示すデータ33c及びデータ33dと、データ33eとを返信する。そして、要求部24は、ルートサーバ31にexamplejpサーバ33のDSレコードを問い合わせるステップS11、ルートサーバ31は、NSレコードを参照して、jpサーバ32に問い合わせて下さいと要求部24に返信するステップS12。そして、要求部24は、jpサーバ32にexamplejpサーバ33のDSレコードを問い合わせステップS13、jpサーバ32は、examplejpサーバ33のDSレコード及びDSレコードの署名を要求部24に返信するステップS14。すなわち、jpサーバ32は、図4Bに示すデータ32a及びデータ32bを返信する。そして、要求部24は、jpサーバ32にjpサーバ32のDNSKEYを問い合わせステップS15、jpサーバ32は、自身のDNSKEY及び署名を返信するステップS16。すなわち、examplejpサーバ33は、図4Bに示すデータ32c及びデータ32dと、データ32eとを返信する。そして、要求部24は、ルートサーバ31にjpサーバ32のDSレコードを問い合わせステップS17、ルートサーバ31は、jpサーバ32のDSレコード及びDSレコードの署名を返信するステップS18。すなわち、ルートサーバ31は、図4Cに示すデータ31a及びデータ31bを返信する。そして、要求部24は、ルートサーバ31にルートサーバ31のDNSKEYを問い合わせステップS19、ルートサーバ31は、自身のDNSKEY及び署名を返信するステップS20。すなわち、ルートサーバ31は、図4Cに示すデータ31c及びデータ31dと、データ31eとを返信する。そして、要求部24は、各権威サーバからの一連の応答データをキャッシュ部23に格納しステップS21、検証部22にキャッシュ部23が記憶する応答データの署名検証を依頼するステップS22。そして、検証部22は、検証処理を行うステップS23。具体的には、検証部22は、データ31dのハッシュ値とデータ23aとを比較することにより、データ31dの正当性を検証する。すなわち、検証部22は、キャッシュ部23が保持するDSレコードを用いてKSK-A公開鍵の正当性を検証する。また、検証部22は、データ31c及びデータ31dのハッシュ値と、データ31eをデータ31dで復号した結果とを比較することにより、データ31c及びデータ31dの正当性を検証する。また、検証部22は、データ31aと、データ31bをデータ31cで復号した結果とを比較することにより、データ31aの正当性を検証する。また、検証部22は、データ32dのハッシュ値とデータ31aとを比較することにより、データ32dの正当性を検証する。すなわち、検証部22は、ルートサーバ31が保持するDSレコードを用いてKSK-B公開鍵の正当性を検証する。また、検証部22は、データ32c及びデータ32dのハッシュ値と、データ32eをデータ32dで復号した結果とを比較することにより、データ32c及びデータ32dの正当性を検証する。さらに、検証部22は、データ32aと、データ32bをデータ32cで復号した結果とを比較することにより、データ32aの正当性を検証する。また、検証部22は、データ33dのハッシュ値とデータ32aとを比較することにより、データ33dの正当性を検証する。すなわち、検証部22は、jpサーバ32が保持するDSレコードを用いてKSK-C公開鍵の正当性を検証する。また、検証部22は、データ33c及びデータ33dのハッシュ値と、データ33eをデータ33dで復号した結果とを比較することにより、データ33c及びデータ33dの正当性を検証する。さらに、検証部22は、データ33aのハッシュ値と、データ33bをデータ33cで復号した結果とを比較することにより、データ33aの正当性を検証する。そして、検証部22は、全ての比較結果が一致する場合、権威サーバ群30からの応答内容が正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部21は、クライアント装置10に対して、データ33aを返信する。一方、検証部22は、全ての比較結果が一致しない場合、権威サーバ群30からの応答内容が不当であり、署名検証が失敗したと判定する。上述してきた各権威サーバexamplejpサーバ33等が保持するKSKや、上位の権威サーバjpサーバ32等が保持する当該KSK公開鍵に対応するDSレコードは、定期的に更新されることが望ましい。しかし、異なる権威サーバに跨って保持されるKSK及びDSレコードをネットワーク管理者が更新する場合には、操作ミス等により、相互の対応に誤りのあるKSKやDSレコードが各権威サーバに登録されるおそれがある。KSKやDSレコードの登録ミスが発生した場合、キャッシュサーバ20は、署名検証に失敗し、クライアント装置10に対して、名前解決に失敗したことを示すエラーを返信することになる。そこで、実施例1に係る名前解決システム1は、システム管理者によって新たなKSKが登録された場合に、かかるKSKに対応するDSレコードを自動生成することにより、相互の対応に誤りのないKSK及びDSレコードを各権威サーバに登録することを可能にする。この点について、図6を用いて簡単に説明する。図6は、実施例1に係る名前解決システム1による鍵更新処理の一例を示す図である。なお、以下では、権威サーバ32、権威サーバ33、管理装置120及び管理装置130を例に挙げて、実施例1に係る名前解決システム1による鍵更新処理について説明する。また、以下では、権威サーバ33に対して上位の権威サーバとなる権威サーバ32を上位権威サーバ32と表記し、権威サーバ32に対して下位の権威サーバとなる権威サーバ33を下位権威サーバ33と表記する場合がある。また、上位権威サーバ32を管理する管理装置120を上位管理装置120と表記し、下位権威サーバ33を管理する管理装置130を下位管理装置130と表記する場合がある。図6に示した例において、下位管理装置130は、下位権威サーバ33によって行われる名前解決の結果に電子署名を付与する際に用いる署名鍵KSK等を保持する。また、上位管理装置120は、下位管理装置130が保持する署名鍵KSK等の正当性を検証する際に用いられるデータであって、かかる署名鍵KSK等を特定するための特定データであるDSレコードを保持する。このような下位管理装置130は、下位権威サーバ33を管理するネットワーク管理者から、下位権威サーバ33のKSKを更新する操作を受け付けるステップS101。例えば、下位管理装置130は、下位権威サーバ33に格納する新たなKSKをアップロードされる。なお、以下では、新たなKSKを新KSKと表記し、新KSKが登録される前の古いKSKを旧KSKと表記する場合がある。下位管理装置130は、ネットワーク管理者から受け付けた新KSKを下位権威サーバ33のゾーンデータに登録するステップS102。そして、下位管理装置130は、下位権威サーバ33のゾーンデータに新KSKを登録した後に、新KSKを登録した旨の登録通知を上位管理装置120に送信するステップS103。上位管理装置120は、下位管理装置130から新KSKの登録通知を受信した場合に、下位権威サーバ33から新KSKの公開鍵を取得するステップS104。そして、上位管理装置120は、下位権威サーバ33から取得した新KSKの公開鍵のハッシュ値を計算することにより、新KSKの公開鍵に対応するDSレコードを生成する。なお、以下では、新KSKの公開鍵に対応するDSレコードを新DSレコードと表記し、旧KSKの公開鍵に対応するDSレコードを旧DSレコードと表記する場合がある。そして、上位管理装置120は、新DSレコードを上位権威サーバ32に送信することにより、上位権威サーバ32のゾーンデータに新DSレコードを登録するステップS105。このように、実施例1に係る名前解決システム1では、下位権威サーバ33に新KSKが登録された場合に、下位管理装置130が登録通知を上位管理装置120に送信する。そして、登録通知を受信した上位管理装置120が下位権威サーバ33から新KSKの公開鍵を取得し、取得した新KSKの公開鍵から新DSレコードを生成し、生成した新DSレコードを上位権威サーバ32に登録する。これにより、実施例1に係る名前解決システム1では、新KSKが登録された場合に、かかる新KSKに対応する新DSレコードを自動的に更新するので、相互の対応に誤りのあるKSKやDSレコードが各権威サーバに登録されることを防止できる。以下に、このような上位管理装置120や下位管理装置130について詳細に説明する。なお、ここでは説明を簡単にするために、下位管理装置130が下位管理装置に特化した処理部のみを有し、上位管理装置120が上位管理装置に特化した処理部のみを有するものとして説明する。ただし、実際には、上位管理装置120及び下位管理装置130は、互いに同様の処理部を有する。これは、上位管理装置120は、下位管理装置130に対して上位管理装置に該当するが、管理装置110に対しては下位管理装置に該当するからである。まず、図7を用いて、下位管理装置130について説明する。図7は、実施例1における下位管理装置130の構成例を示す図である。図7に例示するように、実施例1における下位管理装置130は、受付部131と、更新部132と、通知部133とを有する。なお、図7では図示することを省略したが、下位管理装置130は、下位権威サーバ33や上位管理装置120等との間で各種データを送受するためのIFinterfaceを有する。また、下位管理装置130は、各種情報や操作指示を入力するための入力部キーボード、マウス等や、各種情報を表示する表示デバイス液晶表示装置等を有してもよい。受付部131は、ネットワーク管理者から入力部を介して各種操作を受け付ける。例えば、受付部131は、新KSKを受け付けるとともに、かかる新KSKを下位権威サーバ33に登録する旨の操作を受け付ける。更新部132は、下位権威サーバ33が保持するゾーンデータKSK等を更新する。具体的には、更新部132は、下位管理装置130が保持する下位権威サーバ33のゾーンデータを更新し、更新後のゾーンデータを下位権威サーバ33に反映する。例えば、更新部132は、受付部131によって新KSKが受け付けられた場合に、下位権威サーバ33のゾーンデータに新KSKを更新する。また、例えば、更新部132は、上位管理装置120から新DSレコードが登録された旨の登録通知を受け付けた場合に、下位権威サーバ33のゾーンデータから旧KSKを削除する。なお、更新部132によるゾーンデータの更新処理については、図9及び図10を用いて詳述する。通知部133は、更新部132によって下位権威サーバ33のゾーンデータが更新された場合に、下位権威サーバ33のゾーンデータが更新された旨を上位管理装置120に通知する。例えば、通知部133は、更新部132によって下位権威サーバ33のゾーンデータに新KSKが登録された場合に、新KSKが登録された旨の登録通知を上位管理装置120に送信する。また、例えば、通知部133は、更新部132によって下位権威サーバ33のゾーンデータから旧KSKが削除された場合に、旧KSKが削除された旨の削除通知を上位管理装置120に送信する。次に、図8を用いて、上位管理装置120について説明する。図8は、実施例1における上位管理装置120の構成例を示す図である。図8に例示するように、実施例1における上位管理装置120は、取得部121と、検証部122と、生成部123と、更新部124と、通知部125とを有する。なお、図8では図示することを省略したが、上位管理装置120は、上位権威サーバ32や下位権威サーバ33や下位管理装置130等との間で各種データを送受するためのIFを有する。また、上位管理装置120は、各種情報や操作指示を入力するための入力部キーボード、マウス等や、各種情報を表示する表示デバイス液晶表示装置等を有してもよい。取得部121は、下位権威サーバ33からDNSKEYを取得する。具体的には、取得部121は、DNSプロトコルを用いて、下位権威サーバ33に対してDNSKEYを問い合わせ、かかる問い合わせに応答した下位権威サーバ33から送信されるDNSKEYを取得する。例えば、取得部121は、下位管理装置130の通知部133から、下位権威サーバ33のゾーンデータが更新された旨を通知された場合に、下位権威サーバ33からDNSKEYを取得する。検証部122は、取得部121によって取得されたDNSKEYの署名検証を行う。なお、検証部122による処理については、図9及び図10を用いて詳述する。生成部123は、下位権威サーバ33のゾーンデータに新KSKが登録された場合に、かかる新KSKに対応する新DSレコードを生成する。具体的には、生成部123は、新KSK公開鍵のハッシュ値を計算することにより、新KSK公開鍵に対応する新DSレコードを生成する。更新部124は、上位権威サーバ32が保持するゾーンデータDSレコード等を更新する。具体的には、更新部124は、上位管理装置120が保持する上位権威サーバ32のゾーンデータを更新し、更新後のゾーンデータを上位権威サーバ32に反映する。例えば、更新部124は、生成部123によって新DSレコードが生成された場合に、上位権威サーバ32のZSK秘密鍵を用いて、新DSレコード及び旧DSレコードを含むデータを暗号化することにより、新DSレコード及び旧DSレコードに対応する電子署名を生成する。そして、更新部124は、新DSレコードと、新DSレコード及び旧DSレコードに対応する電子署名を上位権威サーバ32のゾーンデータに登録する。また、例えば、更新部124は、下位権威サーバ33のゾーンデータから旧KSKが削除された場合に、上位権威サーバ32のゾーンデータから旧DSレコードを削除する処理を行う。なお、更新部124によるゾーンデータの更新処理については、図9及び図10を用いて詳述する。通知部125は、更新部124によって上位権威サーバ32のゾーンデータが更新された場合に、上位権威サーバ32のゾーンデータが更新された旨を下位管理装置130に通知する。例えば、通知部125は、更新部124によって上位権威サーバ32のゾーンデータに新DSレコードが登録された場合に、新DSレコードが登録された旨の登録通知を下位管理装置130に送信する。また、例えば、通知部125は、更新部124によって上位権威サーバ32のゾーンデータから旧DSレコードが削除された場合に、旧DSレコードが削除された旨の削除通知を下位管理装置130に送信する。次に、図9~図15を用いて、実施例1に係る名前解決システム1による鍵更新処理の手順について説明する。図9及び図10は、実施例1に係る名前解決システム1による鍵更新処理手順を示すシーケンス図である。また、図11~図15は、実施例1における信頼の連鎖の一例を示す図である。以下では、図11~図15に示した信頼の連鎖の一例を用いながら、図9及び図10に示したシーケンスについて説明する。まず、図9及び図10に示したシーケンスが開始される前において、各権威サーバにおける信頼の連鎖は図11に示した状態であるものとする。具体的には、図11に示すように、上位権威サーバ32が保持するKSKは、権威サーバ31図3に示したルートサーバ31であるものとするが保持するKSKによって信頼性が保証される。なお、ルートサーバ31である権威サーバ31は、トラストアンカーとも呼ばれる。また、図11に示すように、上位権威サーバ32が保持するZSKは、かかるZSKに署名を行う上位権威サーバ32のKSKによって信頼性が保証される。また、上位権威サーバ32は、下位権威サーバ33のKSK更新前のKSKなので旧KSKとするに対応する旧DSレコードを保持するが、かかる旧DSレコードは、かかる旧DSレコードに署名を行う上位権威サーバ32のZSKによって信頼性が保証される。また、図11に示すように、下位権威サーバ33が保持する旧KSKは、上位権威サーバ32が保持する旧DSレコードによって信頼性が保証される。また、下位権威サーバ33が保持するZSKは、かかるZSKに署名を行う下位権威サーバ33の旧KSKによって信頼性が保証される。さらに、下位権威サーバ33が保持する一般データは、かかる一般データに署名を行う下位権威サーバ33のZSKによって信頼性が保証される。なお、ここでいう一般データとは、AレコードやAAAAレコードやNSレコード等を示すものとする。このような状態において、下位権威サーバ33に新KSKが登録されたものとする。具体的には、図9に示すように、下位管理装置130は、下位権威サーバ33に新たに登録するKSK公開鍵及び秘密鍵である新KSKを作成するステップS201。なお、ここでは、下位管理装置130が新KSKを作成することとしたが、実際には、下位管理装置130の受付部131が、下位権威サーバ33を管理するネットワーク管理者から新KSKを受け付けることにより、新KSKを作成することとなる。続いて、下位管理装置130の更新部132は、新KSK秘密鍵を用いて、下位権威サーバ33の旧KSK公開鍵とZSK公開鍵と新KSK公開鍵とを含むDNSKEYの電子署名を作成するステップS202。具体的には、更新部132は、下位権威サーバ33のDNSKEYのハッシュ値を新KSK秘密鍵で暗号化した電子署名を作成する。また、更新部132は、下位権威サーバ33の旧KSK秘密鍵を用いて、下位権威サーバ33の旧KSK公開鍵とZSK公開鍵と新KSK公開鍵とを含むDNSKEYの電子署名を作成するステップS203。具体的には、更新部132は、下位権威サーバ33のDNSKEYのハッシュ値を旧KSK秘密鍵で暗号化した電子署名を作成する。なお、更新部132が旧KSK秘密鍵を用いてDNSKEYの電子署名を作成する理由については後述する。続いて、更新部132は、下位管理装置130が保持する下位権威サーバ33のゾーンデータに対して、新KSK秘密鍵を用いて作成したDNSKEYの電子署名以下、新電子署名と表記する場合があると、旧KSK秘密鍵を用いて作成したDNSKEYの電子署名以下、旧電子署名と表記する場合があると、新KSKとを登録し、登録後のゾーンデータを下位権威サーバ33に反映するステップS204。具体的には、更新部132による更新処理の前の状態では、下位権威サーバ33のゾーンデータには、旧KSK、ZSK、旧KSK公開鍵及びZSK公開鍵の電子署名等が含まれる。更新部132は、かかるゾーンデータに新KSKを追加する。さらに、更新部132は、かかるゾーンデータにステップS202において作成した新電子署名と、ステップS203において作成した旧電子署名とを追加する。このようにして、更新部132は、下位権威サーバ33のゾーンデータを更新する。なお、更新部132は、ゾーンデータから旧KSK公開鍵及びZSK公開鍵の電子署名を削除してもよい。なお、更新部132は、この段階では旧KSKを削除しない。これは、新KSKに対応する新DSレコードが上位権威サーバ32に登録されていないので、旧KSKを削除した場合には信頼の連鎖を構築することができないからである。言い換えれば、実施例1における更新部132は、この段階において旧KSKを削除しないことで、信頼の連鎖を構築することを可能にする。続いて、下位管理装置130の通知部133は、下位権威サーバ33のゾーンデータに新KSKが登録された旨の登録通知を上位管理装置120に送信するステップS205。このとき、通知部133は、DNSプロトコルを用いて、DSレコードを問い合わせる形式により登録通知を上位管理装置120に送信してもよいし、DNSNotifyにより登録通知を上位管理装置120に送信してもよい。この段階においては、各権威サーバにおける信頼の連鎖は図11に示した状態から図12に示した状態に変化する。なお、図11に示したトラストアンカーとKSK上位ゾーン:権威サーバ31との間における信頼性の保証、及び、KSK上位ゾーン:権威サーバ31とZSK上位ゾーン:権威サーバ31との間における信頼性の保証については変化しないので、以下では説明を省略する。具体的には、図12に示すように、上位権威サーバ32が保持する旧DSレコードは、図11に示した例と同様に、上位権威サーバ32のZSKによって信頼性が保証される。また、下位権威サーバ33が保持する旧KSKは、図11に示した例と同様に、上位権威サーバ32が保持する旧DSレコードによって信頼性が保証される。また、図12に示すように、下位権威サーバ33が保持するZSKは、かかるZSKに署名を行う下位権威サーバ33の新KSKによって信頼性が保証されるとともに、下位権威サーバ33の旧KSKによっても信頼性が保証される。これは、ステップS202において新KSKを用いてDNSKEYの電子署名が作成され、ステップS203において旧KSKを用いてDNSKEYの電子署名が作成されたからである。さらに、下位権威サーバ33が保持する一般データは、図11に示した例と同様に、下位権威サーバ33のZSKによって信頼性が保証される。図12に示したように、実施例1に係る名前解決システム1では、新KSKが登録された段階で旧KSKを削除しないので、信頼の連鎖を実現することができる。図9の説明に戻って、上位管理装置120の取得部121は、下位管理装置130の通知部133から登録通知を受信した場合に、DNSプロトコルを用いて、下位権威サーバ33にDNSKEYを問い合わせるステップS206。下位権威サーバ33は、かかる問い合わせに応答して、自身が保持するDNSKEYと、DNSKEYの電子署名を上位管理装置120に送信するステップS207。これにより、取得部121は、下位権威サーバ33のDNSKEYとして、ZSK公開鍵、旧KSK公開鍵及び新KSK公開鍵を取得し、DNSKEYの電子署名として、旧電子署名及び新電子署名を取得する。続いて、上位管理装置120の検証部122は、取得部121によって取得されたDNSKEYの署名検証を行う。具体的には、検証部122は、DNSKEYに含まれる旧KSK公開鍵のハッシュ値を計算し、計算した旧KSK公開鍵のハッシュ値と、かかる旧KSK公開鍵に対応する旧DSレコードとを比較することにより、旧KSK公開鍵の正当性を検証するステップS208。続いて、検証部122は、旧KSK公開鍵の署名検証が成功した場合に、かかる旧KSK公開鍵を用いて、下位権威サーバ33から取得したDNSKEY全体の署名検証を行うステップS209。具体的には、検証部122は、下位権威サーバ33から取得したDNSKEYのハッシュ値と、旧電子署名を旧KSK公開鍵により復号した結果とを比較することにより、DNSKEY全体の正当性を検証する。このように、上位権威サーバ32が下位権威サーバ33の旧KSK公開鍵に対応する旧DSレコードを保持するので、検証部122は、旧KSK公開鍵の正当性を検証することができる。さらに、下位管理装置130が旧KSK秘密鍵を用いてDNSKEYの旧電子署名を作成することにより、検証部122は、旧KSK公開鍵を用いて、下位権威サーバ33から取得したDNSKEY全体の署名検証を行うことができる。言い換えれば、下位管理装置130がステップS204の段階において旧KSKを削除しないことにより、検証部122は、下位権威サーバ33から取得したDNSKEY全体の署名検証を行うことが可能になる。続いて、上位管理装置120の生成部123は、検証部122によるDNSKEY全体の署名検証が成功した場合に、かかるDNSKEYに含まれる新KSK公開鍵に対応する新DSレコードを生成するステップS210。具体的には、生成部123は、新KSK公開鍵のハッシュ値を計算することにより、新DSレコードを生成する。続いて、上位管理装置120の更新部124は、生成部123によって生成された新DSレコードと、旧DSレコードとに対応する電子署名を作成するステップS211。具体的には、更新部124は、上位権威サーバ32のZSK秘密鍵により、新DSレコードと旧DSレコードとを統合したデータのハッシュ値を暗号化することで、新DSレコード及び旧DSレコードに対応する電子署名を作成する。このように、更新部124は、複数のDSレコードが存在する場合には、かかる複数のDSレコードを統合したデータに対して1つの電子署名を作成する。続いて、更新部124は、上位管理装置120が保持する上位権威サーバ32のゾーンデータに対して、生成部123によって生成された新DSレコードと、新DSレコード及び旧DSレコードに対応する電子署名とを登録し、登録後のゾーンデータを上位権威サーバ32に反映するステップS212。具体的には、更新部124による更新処理の前の状態では、上位権威サーバ32のゾーンデータには、KSK,ZSK、旧DSデータ、旧DSデータの電子署名等が含まれる。更新部124は、かかるゾーンデータに新DSデータとステップS211において作成した電子署名とを追加する。このようにして、更新部124は、上位権威サーバ32のゾーンデータを更新する。なお、更新部124は、ゾーンデータから旧DSデータの電子署名を削除してもよい。続いて、上位管理装置120の通知部125は、上位権威サーバ32のゾーンデータに新DSレコードが登録された旨の登録通知を下位管理装置130に送信するステップS213。このとき、通知部125は、DNSプロトコルを用いて、DSレコードを問い合わせる形式により登録通知を下位管理装置130に送信してもよいし、DNSNotifyにより登録通知を下位管理装置130に送信してもよい。この段階においては、各権威サーバにおける信頼の連鎖は図12に示した状態から図13に示した状態に変化する。具体的には、図13に示すように、上位権威サーバ32が保持する旧DSレコード及び新DSレコードは、上位権威サーバ32のZSKによって信頼性が保証される。これは、ステップS211において上位権威サーバ32のZSKを用いて、新DSレコード及び旧DSレコードの電子署名が作成されたからである。また、図13に示すように、下位権威サーバ33が保持する旧KSKは、図12に示した例と同様に、上位権威サーバ32が保持する旧DSレコードによって信頼性が保証される。また、下位権威サーバ33が保持する新KSKは、上位権威サーバ32が保持する新DSレコードによって信頼性が保証される。また、下位権威サーバ33が保持するZSKは、図12に示した例と同様に、下位権威サーバ33の新KSKによって信頼性が保証されるとともに、下位権威サーバ33の旧KSKによっても信頼性が保証される。さらに、下位権威サーバ33が保持する一般データは、図12に示した例と同様に、下位権威サーバ33のZSKによって信頼性が保証される。続いて、図10に示すように、下位管理装置130の更新部132は、上位管理装置120の通知部125から登録通知を受信した場合に、下位管理装置130が保持する下位権威サーバ33のゾーンデータから旧KSKを削除するステップS214。続いて、更新部132は、新KSKを用いて、下位権威サーバ33のZSK公開鍵と新KSK公開鍵とを含むDNSKEYの電子署名を作成するステップS215。すなわち、更新部132は、DNSKEYから旧KSKを削除したので、かかるDNSKEYの電子署名を新たに作成する。続いて、更新部132は、下位管理装置130が保持する下位権威サーバ33のゾーンデータに対して、ステップS215において作成したDNSKEYの電子署名を登録し、登録後のゾーンデータを下位権威サーバ33に反映するステップS216。続いて、下位管理装置130の通知部133は、DNSプロトコルを用いて、下位権威サーバ33のゾーンデータから旧KSKが削除された旨の削除通知を上位管理装置120に送信するステップS217。この段階においては、各権威サーバにおける信頼の連鎖は図13に示した状態から図14に示した状態に変化する。具体的には、図14に示すように、上位権威サーバ32が保持する旧DSレコード及び新DSレコードは、図13に示した例と同様に、上位権威サーバ32のZSKによって信頼性が保証される。また、図14に示すように、下位権威サーバ33が保持する新KSKは、図13に示した例と同様に、上位権威サーバ32が保持する新DSレコードによって信頼性が保証される。また、下位権威サーバ33が保持するZSKは、下位権威サーバ33の新KSKのみによって信頼性が保証される。さらに、下位権威サーバ33が保持する一般データは、図13に示した例と同様に、下位権威サーバ33のZSKによって信頼性が保証される。すなわち、ステップS214において旧KSKが削除されたことによって、旧KSKによって信頼性が保証されることがなくなる。図10の説明に戻って、上位管理装置120の取得部121は、下位管理装置130の通知部133から削除通知を受信した場合に、DNSプロトコルを用いて、下位権威サーバ33にDNSKEYを問い合わせるステップS218。下位権威サーバ33は、かかる問い合わせに応答して、自身が保持するDNSKEYと、DNSKEYの電子署名を上位管理装置120に送信するステップS219。これにより、取得部121は、下位権威サーバ33のDNSKEYとして、ZSK公開鍵及び新KSK公開鍵を取得するとともに、ステップS215において作成されたDNSKEYの電子署名を取得する。続いて、上位管理装置120の検証部122は、取得部121によって取得されたDNSKEYの署名検証を行う。具体的には、検証部122は、DNSKEYに含まれる新KSK公開鍵のハッシュ値を計算し、計算した新KSK公開鍵のハッシュ値と、かかる新KSK公開鍵に対応する新DSレコードとを比較することにより、新KSK公開鍵の正当性を検証するステップS220。続いて、検証部122は、新KSK公開鍵の署名検証が成功した場合に、かかる新KSK公開鍵を用いて、下位権威サーバ33から取得したDNSKEY全体の署名検証を行うステップS221。具体的には、検証部122は、下位権威サーバ33から取得したDNSKEYのハッシュ値と、かかるDNSKEYの電子署名を新KSK公開鍵により復号した結果とを比較することにより、DNSKEY全体の正当性を検証する。続いて、上位管理装置120の更新部124は、検証部122によるDNSKEY全体の署名検証が成功した場合に、上位権威サーバ32のゾーンデータから旧DSレコードを削除するステップS222。続いて、更新部124は、上位権威サーバ32のZSK秘密鍵を用いて、新DSレコードに対応する電子署名を作成するステップS223。具体的には、上位権威サーバ32のゾーンデータには新DSレコード及び旧DSレコードに対応する電子署名が登録されているが、更新部124は、旧DSレコードを削除したので、新DSレコードのみに対応する電子署名を作成し、作成した電子署名を上位権威サーバ32のゾーンデータに追加する。このとき、更新部124は、新DSレコード及び旧DSレコードに対応する電子署名を削除してもよい。続いて、更新部124は、上位管理装置120が保持する上位権威サーバ32のゾーンデータに対して、ステップS223において作成した電子署名を登録し、登録後のゾーンデータを上位権威サーバ32に反映するステップS224。続いて、上位管理装置120の通知部125は、DNSプロトコルを用いて、上位権威サーバ32のゾーンデータから旧DSレコードが削除された旨の削除通知を下位管理装置130に送信するステップS225。これにより、各権威サーバにおける信頼の連鎖は図14に示した状態から図15に示した状態に変化する。具体的には、図15に示すように、上位権威サーバ32が保持する新DSレコードは、上位権威サーバ32のZSKによって信頼性が保証される。また、下位権威サーバ33が保持する新KSKは、上位権威サーバ32が保持する新DSレコードによって信頼性が保証される。また、下位権威サーバ33が保持するZSKは、下位権威サーバ33の新KSKによって信頼性が保証される。さらに、下位権威サーバ33が保持する一般データは、下位権威サーバ33のZSKによって信頼性が保証される。このように、図11と図15とを比較すると、下位権威サーバ33が保持する旧KSKが新KSKに更新されており、さらに、上位権威サーバ32が保持する旧DSレコードが新DSレコードに更新されていることが分かる。上述してきたように、実施例1に係る名前解決システム1は、下位権威サーバ33に新KSKが登録された場合に、下位管理装置130が登録通知を上位管理装置120に送信する。そして、登録通知を受信した上位管理装置120が下位権威サーバ33から新KSKの公開鍵を取得し、取得した新KSKの公開鍵から新DSレコードを生成し、生成した新DSレコードを上位権威サーバ32に登録する。これにより、実施例1に係る名前解決システム1では、新KSKが登録された場合に、かかる新KSKに対応する新DSレコードを自動的に更新するので、相互の対応に誤りのあるKSKやDSレコードが各権威サーバに登録されることを防止できる。例えば、権威サーバが保持するKSK等を更新するために、EPPExtensibleProvisioningProtocolを用いることも考えられる。しかし、EPPを用いた場合であっても、ネットワーク管理者の操作ミスにより、相互の対応に誤りのあるKSKやDSレコードが各権威サーバに登録されるおそれがある。実施例1に係る名前解決システム1は、新KSKが登録された場合に、かかる新KSKに対応する新DSレコードを自動生成するので、相互の対応に誤りのないKSK及びDSレコードを各権威サーバに登録することができる。また、EPPやKSK更新用の独自プロトコルを用いてKSK及びDSレコードを更新する場合には、ネットワーク管理者の操作ミスによる問題の他に、EPPや独自プロトコルの脆弱性を攻撃する攻撃者によって、不正なKSK及びDSレコードが各権威サーバに登録されるおそれがある。実施例1に係る名前解決システム1では、図9及び図10を用いて説明したように、DNSプロトコルを用いる。DNSプロトコルは、枯れたプロトコルとも呼ばれており、ファイアフォール等のセキュリティ製品が充実している。このため、実施例1に係る名前解決システム1では、このようなセキュリティ製品が充実しているDNSプロトコルを用いて各装置間で各種データを送受するので、攻撃者に攻撃されることを防止することができる。また、実施例1に係る名前解決システム1は、上位管理装置120において新DSレコードが生成された後に、下位管理装置130が旧KSKを削除するので、信頼の連鎖が途切れる期間を発生させずに、KSK及びDSレコードを更新することができる。また、実施例1に係る名前解決システム1は、図9のステップS208及びS209、図10のステップS220及びS221を用いて説明したように、上位管理装置120が下位権威サーバ33から取得したDNSKEYの正当性を検証するので、信頼性の高いDNSSECを用いて、KSK及びDSレコードを更新することができる。また、実施例1に係る名前解決システム1は、図10のステップS217~S222を用いて説明したように、下位管理装置130が旧KSKを削除した後に、上位管理装置120が旧DSレコードを削除するので、下位管理装置130の管理者が新KSKを削除した場合や、新KSKの生成にミスがあった場合や、鍵更新処理中に下位管理装置130が故障した場合等でも、旧KSK及び旧DSレコードにより信頼の連鎖を維持することができる。具体的には、下位管理装置130の管理者は、誤った新KSKを登録した際に新KSKを削除したり、単なる操作ミスにより新KSKを削除したりすることが考えられる。実施例1に係る名前解決システム1では、旧KSKが削除されない限り、旧KSKに対応する旧DSレコードが削除されないので、仮に新KSKが削除された場合であっても、信頼の連鎖を維持することができる。また、故障が発生した下位管理装置130をバックアップデータから復旧させた場合に、かかる下位管理装置130には、旧KSKしか登録されていない可能性がある。実施例1に係る名前解決システム1では、旧KSKが削除されない限り、旧KSKに対応する旧DSレコードが削除されないので、仮に下位管理装置130に旧KSKしか登録されていない状態になったとしても、信頼の連鎖を維持することができる。上記実施例1では、上位管理装置120が、下位管理装置130から新KSKの登録通知を受信した場合に、新KSKの取得処理や新DSレコードの生成処理を行う例を示した。しかし、上位ゾーンを管理する上位権威サーバ32の上位管理装置120は、複数の下位管理装置130から略同一のタイミングで新KSKの登録通知を受信する場合も考えられる。かかる場合に、上位管理装置120による処理負荷が増大するとも考えられる。そこで、上位管理装置120は、下位管理装置130から新KSKの登録通知を受信した場合であっても、所定の時間が経過した後に、新DSレコードの生成処理等を行ってもよい。実施例2では、このような上位管理装置120について説明する。まず、図16を用いて、実施例2における上位管理装置について説明する。図16は、実施例2における上位管理装置の構成例を示す図である。なお、実施例2における下位管理装置130の構成は、図7に例示した構成と同様であるので、説明を省略する。また、以下では、既に示した構成部位と同様の機能を有する部位には同一符号を付すこととして、その詳細な説明を省略する。図16に例示するように、実施例2における上位管理装置220は、待機通知部221を有する。待機通知部221は、下位管理装置130から、新KSKが登録された旨の登録通知や旧KSKが削除された旨の削除通知を受け付けた場合に、上位管理装置220の処理負荷が所定の閾値以上であるか否かを判定する。例えば、待機通知部221は、現在時刻を含む所定の時間内に、下位管理装置から受信した登録通知や削除通知の数が所定の閾値以上であるか否かを判定する。また、例えば、待機通知部221は、上位管理装置220のCPU負荷等が所定の閾値以上であるか否かを判定する。そして、待機通知部221は、上位管理装置220の処理負荷が所定の閾値以上である場合には、新DSレコードの生成処理等を行う時刻以下、対応時刻と表記する場合があるを決定し、決定した対応時刻を下位管理装置130に通知する。そして、待機通知部221は、かかる対応時刻になるまで待機し、対応時刻となった場合に、取得部121に対してDNSKEYの取得処理を行うように指示する。次に、図17及び図18を用いて、実施例2に係る名前解決システム1による鍵更新処理の手順について説明する。図17及び図18は、実施例2に係る名前解決システム1による鍵更新処理手順を示すシーケンス図である。図17に示したステップS301~S305における処理手順は、図9に示したステップS201~S205における処理手順と同様であるので、説明を省略する。図17に示すように、実施例2における上位管理装置220の待機通知部221は、下位管理装置130の通知部133から登録通知を受信した場合に、上位管理装置220の処理負荷が所定の閾値以上であるか否かを判定する。ここでは、待機通知部221は、上位管理装置220の処理負荷が所定の閾値以上であると判定するものとする。かかる場合に、待機通知部221は、対応時刻を下位管理装置130に送信するステップS306。そして、待機通知部221は、かかる対応時刻になるまで待機するステップS307。続いて、上位管理装置220の取得部121は、待機通知部221によって決定された対応時刻になった場合に、DNSプロトコルを用いて、下位権威サーバ33にDNSKEYを問い合わせるステップS308。なお、図17に示したステップS308~S314による処理手順は、図9に示したステップS206~S212による処理手順と同様であるので、説明を省略する。続いて、下位管理装置130は、上位管理装置220の待機通知部221から受信した対応時刻になった場合に、DNSプロトコルを用いて、上位権威サーバ32に対してDSレコードを問い合わせるステップS315。上位権威サーバ32は、かかる問い合わせに応答して、自身が保持するDSレコードを下位管理装置130に送信するステップS316。これにより、下位管理装置130は、上位権威サーバ32に新レコードが生成されたか否かを判定することができる。なお、図17では、下位管理装置130が上位権威サーバ32にDSレコードを問い合わせる例を示した。しかし、図9に示した例と同様に、上位管理装置220が、上位権威サーバ32のゾーンデータに新DSレコードが登録された旨の登録通知を下位管理装置130に送信してもよい図9のステップS213参照。ただし、図17に示した例のように、下位管理装置130が、上位管理装置220を介さずに、上位権威サーバ32にアクセスして新DSレコードの生成有無を判定することで、上位管理装置220による処理負荷を低減することができる。すなわち、上位管理装置220が対応時刻を送信した場合には、上位管理装置220の処理負荷が増大しているとも言える。そこで、実施例2における下位管理装置130は、対応時刻を通知された場合には、上位管理装置220を介さずに新DSレコードの生成有無を判定することで、上位管理装置220の処理負荷を低減することができる。続いて、図18に示すように、下位管理装置130の更新部132は、上位権威サーバ32に新DSレコードが生成されている場合に、下位管理装置130が保持する下位権威サーバ33のゾーンデータから旧KSKを削除するステップS317。なお、図18に示したステップS318~S320における処理手順は、図10に示したステップS215~S217における処理手順と同様であるので、説明を省略する。続いて、上位管理装置220の待機通知部221は、下位管理装置130の通知部133から削除通知を受信した場合に、上位管理装置220の処理負荷が所定の閾値以上であるか否かを判定する。ここでは、待機通知部221は、上位管理装置220の処理負荷が所定の閾値以上であると判定するものとする。かかる場合に、待機通知部221は、対応時刻を下位管理装置130に送信するステップS321。そして、待機通知部221は、かかる対応時刻になるまで待機するステップS322。続いて、上位管理装置220の取得部121は、待機通知部221によって決定された対応時刻になった場合に、DNSプロトコルを用いて、下位権威サーバ33にDNSKEYを問い合わせるステップS323。なお、図18に示したステップS323~S329による処理手順は、図10に示したステップS218~S224による処理手順と同様であるので、説明を省略する。続いて、下位管理装置130は、上位管理装置220の待機通知部221から受信した対応時刻になった場合に、DNSプロトコルを用いて、上位権威サーバ32に対してDSレコードを問い合わせるステップS330。上位権威サーバ32は、かかる問い合わせに応答して、自身が保持するDSレコードを下位管理装置130に送信するステップS331。これにより、下位管理装置130は、上位権威サーバ32から旧レコードが削除されたか否かを判定することができる。上記例と同様に、下位管理装置130は、上位管理装置220を介さずに、上位権威サーバ32にアクセスして旧DSレコードの削除有無を判定することで、上位管理装置220による処理負荷を低減することができる。上述してきたように、実施例2に係る名前解決システム1は、上位管理装置120は、自身の処理負荷が高い場合に、所定の時間が経過した後に新DSレコードの生成処理等を行う。これにより、実施例2に係る名前解決システム1は、複数の下位管理装置によって新KSKを登録する処理が所定時間に集中した場合であっても、上位管理装置120の処理負荷を一時的に増大させることなく、KSK及びDSレコードを更新することができる。ところで、本発明に係る名前解決システム及び鍵更新方法は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例3では、本発明に係る名前解決システム及び鍵更新方法の他の実施例について説明する。[処理主体]上記実施例では、上位管理装置120と下位管理装置130とを分別して説明した。しかし、上述したように、上位管理装置120は下位管理装置となる場合もあり、下位管理装置130は上位管理装置となる場合もある。したがって、上述した各管理装置は、図7に示した各処理部と、図8に示した各処理部との双方を有する。なお、下位管理装置にしかなり得ない管理装置は、図7に示した各処理部のみを有してもよいし、上位管理装置にしかなり得ない管理装置は、図8に示した各処理部のみを有してもよい。また、上記実施例では、各権威サーバを管理装置によって管理する例を示した。しかし、権威サーバと管理装置とは一体化されてもよい。例えば、権威サーバ31と管理装置110とが一体化されてもよいし、上位権威サーバ32と上位管理装置120とが一体化されてもよい。すなわち、上記実施例では、権威サーバと管理装置とを分別して説明したが、本発明は、権威サーバと管理装置との双方を権威サーバとする場合にも適用することができる。[KSKの数]また、上記実施例では、権威サーバが保持する旧KSKの数が1個である場合を例に挙げて説明した。しかし、本発明は、権威サーバが2個以上の旧KSK保持する場合にも適用することができる。例えば、下位権威サーバ33が2個の旧KSKを保持し、1個の新KSKが登録されたものとする。かかる場合には、下位権威サーバ33は、3個のKSK公開鍵を含むDNSKEYを上位管理装置120に送信する。そして、上位管理装置120は、各KSKに対応する3個のDSレコードを保持することになる。[システム構成]また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図4等に例示した各種情報は、あくまで一例であって任意の情報に変更することができる。また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。[プログラム]また、上記実施例において説明した上位管理装置120、下位管理装置130又は上位管理装置220が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例1における上位管理装置120、下位管理装置130又は上位管理装置220が実行する処理をコンピュータが実行可能な言語で記述した鍵更新プログラムを作成することもできる。この場合、コンピュータが鍵更新プログラムを実行することにより、上記実施例と同様の効果を得ることができる。さらに、かかる鍵更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された鍵更新プログラムをコンピュータに読み込ませて実行することにより上記実施例と同様の処理を実現してもよい。以下に、図7及び図8に示した上位管理装置120及び下位管理装置130と同様の機能を実現する鍵更新プログラムを実行するコンピュータの一例を説明する。図19は、鍵更新プログラムを実行するコンピュータ1000を示す図である。図19に例示するように、コンピュータ1000は、例えば、メモリ1010と、CPU1020と、ハードディスクドライブインタフェース1030と、ディスクドライブインタフェース1040と、シリアルポートインタフェース1050と、ビデオアダプタ1060と、ネットワークインタフェース1070とを有し、これらの各部はバス1080によって接続される。メモリ1010は、図19に例示するように、ROMReadOnlyMemory1011及びRAMRandomAccessMemory1012を含む。ROM1011は、例えば、BIOSBasicInputOutputSystem等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、図19に例示するように、ハードディスクドライブ1031に接続される。ディスクドライブインタフェース1040は、図19に例示するように、ディスクドライブ1041に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース1050は、図19に例示するように、例えばマウス1051、キーボード1052に接続される。ビデオアダプタ1060は、図19に例示するように、例えばディスプレイ1061に接続される。ここで、図19に例示するように、ハードディスクドライブ1031は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、上記の鍵更新プログラムは、コンピュータ1000によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ1031に記憶される。例えば、図7に例示した受付部131、更新部132、通知部133、及び、図8に例示した取得部121、検証部122、生成部123、更新部124、通知部125と同様の情報処理を実行する処理手順とが記述されたプログラムモジュール1093が、ハードディスクドライブ1031に記憶される。また、上記実施例で説明した上位管理装置120及び下位管理装置130が保持する各種データは、プログラムデータとして、例えばメモリ1010やハードディスクドライブ1031に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1031に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出し、各種処理手順を実行する。なお、鍵更新プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1031に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してCPU1020によって読み出されてもよい。あるいは、鍵更新プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ネットワークLANLocalAreaNetwork、WANWideAreaNetwork等を介して接続された他のコンピュータに記憶され、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。"