名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第1所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部とを備えたことを特徴とする権威サーバ。前記設定部は、前記有効期間が第2所定期間以上である場合には、当該第2所定期間を前記キャッシュ期間として前記応答データに設定し、前記有効期間が前記第2所定期間よりも小さい場合には、当該有効期間又は当該有効期間より第1所定期間長い期間を前記キャッシュ期間として前記応答データに設定することを特徴とする請求項1に記載の権威サーバ。前記設定部は、前記署名鍵が更新される日時と、前記受付部によって取得要求が受け付けられた日時との差分を前記有効期間として算出することを特徴とする請求項1又は2に記載の権威サーバ。前記設定部は、前記署名鍵が更新される日時と、現在日時との差分を前記有効期間として算出することを特徴とする請求項1又は2に記載の権威サーバ。前記設定部は、前記受付部によって複数のキャッシュサーバから前記取得要求が受け付けられる場合には、当該複数のキャッシュサーバのそれぞれに応じて互いに異なるキャッシュ期間を前記応答データに設定することを特徴とする請求項1~4のいずれか一つに記載の権威サーバ。権威サーバとキャッシュサーバとを含む名前解決システムであって、前記権威サーバは、名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第1所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部とを備えたことを特徴とする名前解決システム。権威サーバが実行する鍵更新方法であって、名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付工程と、前記受付工程によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第1所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定工程と、前記設定工程によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信工程とを含んだことを特徴とする鍵更新方法。名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付手順と、前記受付手順によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第1所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定手順と、前記設定手順によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信手順とをコンピュータに実行させることを特徴とする鍵更新プログラム。ところで、上記の従来技術において、権威サーバの管理者や運用者等は、署名鍵であるZSKやKSKを定期的に更新することが望ましい。これは、署名鍵が盗難するおそれや第三者によって署名鍵が解読されるおそれ等があるからである。しかしながら、上記の従来技術では、権威サーバの管理者や運用者等が署名鍵を更新した場合であっても、かかる署名鍵がキャッシュサーバに即座に反映されることはない。具体的には、各権威サーバは、署名鍵DNSKEYレコードをキャッシュサーバに提供する際に、キャッシュサーバが署名鍵を保持する期間を示すTTLTimeToLiveを設定する。このため、キャッシュサーバは、TTL時間が経過しない限りは、たとえ権威サーバの署名鍵が更新された場合であっても、キャッシュ済みの古い署名鍵を用いることとなる。例えば、非特許文献1に開示されているように、事前公開法や二重署名法等の署名鍵更新方法を行った場合、上述した信頼の連鎖が途切れないことを担保するためには、更新後の署名鍵がキャッシュサーバに反映されるまでに、TTLTimeToLive時間が経過してキャッシュサーバのキャッシュから古い署名鍵等が削除されるまでの時間を要する。このような古い署名鍵がキャッシュサーバにおいて使用され続けることは、セキュリティの観点から好ましくないといえる。本願の開示する技術は、上記に鑑みてなされたものであって、キャッシュサーバにおける署名鍵を短期間で更新することができる権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムを提供することを目的とする。実施形態に係る権威サーバは、名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第1所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部とを備えることを特徴とする。実施形態に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムは、キャッシュサーバにおける署名鍵を短期間で更新することができるという効果を奏する。以下に、本願に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムが限定されるものではない。まず、図1を用いて、実施例1に係る名前解決システムについて説明する。図1は、実施例1に係る名前解決システムの構成例を示す図である。図1に示す名前解決システム1は、クライアント装置10、キャッシュサーバ20、権威サーバ群100を有する。ここで、図1に示す各装置は、インターネットを介して通信可能な状態で接続される。クライアント装置10は、例えば、PCPersonalComputer、携帯電話機、PDAPersonalDigitalAssistant等であり、キャッシュサーバ20に対して、名前解決の依頼を送信する。具体的には、クライアント装置10は、キャッシュサーバ20に対して、ホスト名を通知することでIPアドレスの検索を要求したり、その逆にIPアドレスを通知することでホスト名の検索を要求したりする。このようなクライアント装置10で動作するプログラムはリゾルバと呼ばれる。なお、図1では、キャッシュサーバ20に接続されるクライアント装置10を一台のみ示しているが、実際には、キャッシュサーバ20には複数台のクライアント装置が接続される。キャッシュサーバ20は、クライアント装置10から所定のドメイン名例えば、wwwexamplejpの名前解決の依頼を受け付ける。そして、キャッシュサーバ20は、権威サーバ群100に、依頼されたドメイン名の名前解決のための問い合わせを行うとともに、権威サーバ群100からの応答データをキャッシュする機能を有する。権威サーバ群100は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。図1に示した例では、権威サーバ群100には、権威サーバ1001、1002及び1003が含まれる。なお、図1では、権威サーバ群100に3台の権威サーバが含まれる例を示したが、権威サーバ群100には、2台以下の権威サーバや4台以上の権威サーバが含まれてもよい。ここで、図2~図5を用いて、キャッシュサーバ20と権威サーバ群100とにより実行されるDNSSECの処理の一例を説明する。その後に、図6~図8を用いて、実施例1に係る権威サーバ群100について説明する。図2は、実施例1に係る名前解決システム1が有するキャッシュサーバ20の構成例を示す図である。図2に例示するように、実施例1におけるキャッシュサーバ20は、応答部21と、検証部22と、キャッシュ部23と、要求部24とを有する。応答部21は、クライアント装置10との間で通信を行う。要求部24は、権威サーバ群100との間で通信を行う。また、要求部24は、権威サーバ群100から受信した応答データをキャッシュ部23に格納する。検証部22は、キャッシュ部23に格納された権威サーバ群100からの応答データを用いて署名検証を行う。キャッシュ部23は、署名検証に成功した応答データをキャッシュする。具体的には、キャッシュ部23は、署名検証に成功した場合、名前解決を依頼されたドメイン名とドメイン名のIPアドレスとを対応付けた情報、署名鍵としてのDSレコードやDNSKEYレコード等をキャッシュする。ここで、応答部21は、クライアント装置10から名前解決を依頼された場合、依頼されたドメイン名のIPアドレスが、キャッシュ部23にキャッシュ情報として既に格納されているか否かを判定する。応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として既に格納されている場合、クライアント装置10に対してIPアドレスを返信する。一方、応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部24に転送する。そして、要求部24は、依頼内容に基づいて、権威サーバ群100に問い合わせを行う。ここで、図3~図5を用いて、キャッシュサーバ20が、クライアント装置10からキャッシュ情報として格納されていないwwwexamplejpの名前解決の依頼を受け付けた場合に、権威サーバ群100に対してwwwexamplejpに関する問い合わせを行う例について説明する。図3は、権威サーバ群100に含まれる権威サーバの一例を示す図である。なお、以下では、クライアント装置10がIPv4InternetProtocolversion4アドレスを要求している場合について説明する。図3に示した例のように、キャッシュサーバ20は、wwwexamplejpの名前解決を行う場合に、権威サーバ1001ここではルートサーバ1001であるものとする、権威サーバ1002ここではjpサーバ1002であるものとする、権威サーバ1003ここではexamplejpサーバ1003であるものとするに対して問い合わせを行う。ルートサーバ1001は、階層的な木構造を有する名前空間のうち最上位ゾーンであるルートゾーンを管理するサーバであり、例えばjpやcom等のドメイン名TLD:TopLevelDomainを管理するサーバのインターネット上の位置IPアドレスを管理する。また、jpサーバ1002は、jpのTLDサーバであり、jpで管理されるexamplejpやadjpなどのインターネット上の位置IPアドレスを管理する。また、examplejpサーバ1003は、examplejpサーバ1003自身が管理する名前空間の中にあるホスト、例えば、wwwexamplejpやftpexamplejpのインターネット上の位置IPアドレスを管理する。なお、上位権威サーバは、上位権威サーバ自身が管理するゾーンの下位ゾーンを管理する下位権威サーバのドメイン名をNSNameServerレコードとして保持し、かかる下位権威サーバのIPアドレスをAレコード又はAAAAレコードクワッドAレコードとして保持する。例えば、jpサーバ1002は、下位権威サーバであるexamplejpサーバ1003のNSレコードやAレコード等を保持する。これらのルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003は、DNSSECが有効化されており、ZSK及びKSKを保持する。図3に示した例では、ルートサーバ1001は、ZSKとしてZSK-A公開鍵及びZSK-A秘密鍵を保持し、KSKとしてKSK-A公開鍵及びKSK-A秘密鍵を保持する。また、jpサーバ1002は、ZSKとしてZSK-B公開鍵及びZSK-B秘密鍵を保持し、KSKとしてKSK-B公開鍵及びKSK-B秘密鍵を保持する。また、examplejpサーバ1003は、ZSKとしてZSK-C公開鍵及びZSK-C秘密鍵を保持し、KSKとしてKSK-C公開鍵及びKSK-C秘密鍵を保持する。なお、図3に示した例では、ルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003が、ZSK秘密鍵及びKSK秘密鍵を保持する例を示した。しかし、実際には、ルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003は、ZSK秘密鍵及びKSK秘密鍵については自装置内に保持しない。これらのZSK秘密鍵及びKSK秘密鍵は、ルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003がアクセスできるが一般ユーザからアクセスできない別装置によって管理される。そして、ルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003は、この別装置によってZSK秘密鍵及びKSK秘密鍵を用いて生成された電子署名をかかる別装置から受け取り、受け取った電子署名を保持する。ただし、このような別装置が存在しないシステムの場合には、ルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003は、ZSK秘密鍵及びKSK秘密鍵を保持してもよい。ここで、DNSSECでは、ルートサーバ1001、jpサーバ1002、examplejpサーバ1003及びキャッシュサーバ20は、同一のハッシュ関数を用いてハッシュ値を計算する。また、DS方式では、下位権威サーバは、上位権威サーバに対して、かかる下位権威サーバが保持するKSK公開鍵のハッシュ値であるDSレコードを予め通知している。すなわち、examplejpサーバ1003は、自身のDSレコードをjpサーバ1002に通知し、jpサーバ1002は、自身のDSレコードをルートサーバ1001に通知する。そして、ルートサーバ1001は、自身のDSレコードをキャッシュサーバ20に通知する。これらのルートサーバ1001、jpサーバ1002、examplejpサーバ1003及びキャッシュサーバ20は、図4に例示するデータを用いて、DNSSECにおける電子署名を用いた署名検証を実現する。図4は、DNSSECに用いられる各種データの一例を示す図である。図4Aに示すように、examplejpサーバ1003は、wwwexamplejpのIPv4アドレスの情報を含むAレコードのデータ33aを保持する。なお、クライアント装置10がIPv6InternetProtocolversion6アドレスを要求している場合には、DNSSECに用いられるデータは、wwwexamplejpのIPv6アドレスの情報を含むAAAAレコードとなる。また、図4Aに示すように、examplejpサーバ1003は、Aレコードのハッシュ値をZSK-C秘密鍵で暗号化した電子署名であるデータ33bを保持する。また、図4Aに示すように、examplejpサーバ1003は、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サーバ1003は、wwwexamplejpのAレコード及びAレコードの署名として、データ33a及びデータ33bを保持する。また、examplejpサーバ1003は、DNSKEYとしてデータ33c及びデータ33dを保持する。また、examplejpサーバ1003は、DNSKEYの署名としてデータ33eを保持する。また、図4Aでは図示していないが、examplejpサーバ1003は、下位権威サーバが存在する場合には、かかる下位権威サーバのDSレコード下位権威サーバのKSK公開鍵のハッシュ値を保持する。また、図4Bに示すように、jpサーバ1002は、examplejpサーバ1003のDSレコード、すなわち、KSK-C公開鍵のハッシュ値であるデータ32aと、DSレコードKSK-C公開鍵のハッシュ値をZSK-B秘密鍵で暗号化した電子署名であるデータ32bとを保持する。また、図4Bに示すように、jpサーバ1002は、ZSK-B公開鍵のデータ32cと、KSK-B公開鍵のデータ32dと、ZSK-B公開鍵及びKSK-B公開鍵のハッシュ値をKSK-B秘密鍵で暗号化した電子署名であるデータ32eを保持する。すなわち、jpサーバ1002は、examplejpサーバ1003のDSレコード及びDSレコードの署名として、データ32a及びデータ32bを保持する。また、jpサーバ1002は、DNSKEYとしてデータ32c及びデータ32dを保持する。また、jpサーバ1002は、DNSKEYの署名としてデータ32eを保持する。また、図4Cに示すように、ルートサーバ1001は、jpサーバ1002のDSレコード、すなわち、KSK-B公開鍵のハッシュ値であるデータ31aと、DSレコードKSK-B公開鍵のハッシュ値をZSK-A秘密鍵で暗号化した電子署名であるデータ31bを保持する。また、図4Cに示すように、ルートサーバ1001は、ZSK-A公開鍵のデータ31cと、KSK-A公開鍵のデータ31dと、ZSK-A公開鍵及びKSK-A公開鍵のハッシュ値をKSK-A秘密鍵で暗号化した電子署名であるデータ31eとを保持する。すなわち、ルートサーバ1001は、jpサーバ1002のDSレコード及びDSレコードの署名として、データ31a及びデータ31bを保持する。また、ルートサーバ1001は、DNSKEYとしてデータ31c及びデータ31dを保持する。また、ルートサーバ1001は、DNSKEYの署名としてデータ31eを保持する。そして、図4Dに示すように、キャッシュサーバ20は、例えば、ルートサーバ1001のDSレコード、すなわち、KSK-A公開鍵であるデータ23aをキャッシュ部23内に保持する。なお、図4では、キャッシュサーバ20が、ルートサーバ1001のKSK-A公開鍵をキャッシュ部23に保持する例を示した。しかし、キャッシュサーバ20は、KSK-A公開鍵ではなく、KSK-A公開鍵のキャッシュ値であるDSレコードをキャッシュ部23に保持してもよい。具体的には、キャッシュサーバ20は、ルートサーバ1001によって保持されているデータ31eと比較した後のKSK-A公開鍵のキャッシュ値をキャッシュ部23に保持してもよい。図4に例示したデータを用いて、実施例1に係る名前解決システム1が実行する署名検証処理について、図5を用いて説明する。図5は、実施例1に係る名前解決システム1が実行する署名検証処理の一例を示すシーケンス図である。図5に示すように、クライアント装置10は、キャッシュサーバ20の応答部21に対して、wwwexamplejpのAレコードを問い合わせる名前解決の依頼を行うステップS1。名前解決の依頼を受け付けた応答部21は、要求部24に名前解決の依頼内容を転送しステップS2、要求部24は、ルートサーバ1001にAレコードを問い合わせるステップS3。wwwexamplejpのAレコードの問い合わせを受け付けたルートサーバ1001は、NSレコードを参照して、jpサーバ1002に問い合わせて下さいと要求部24に返信するステップS4。具体的には、ルートサーバ1001は、jpサーバ1002のIPアドレスを要求部24に返信する。そして、要求部24は、jpサーバ1002にAレコードを問い合わせるステップS5。wwwexamplejpのAレコードの問い合わせを受け付けたjpサーバ1002は、NSレコードを参照して、examplejpサーバ1003に問い合わせて下さいと要求部24に返信するステップS6。すなわち、jpサーバ1002は、examplejpサーバ1003のIPアドレスを要求部24に返信する。そして、要求部24は、examplejpサーバ1003にAレコードを問い合わせるステップS7。wwwexamplejpのAレコードの問い合わせを受け付けたexamplejpサーバ1003は、wwwexamplejpのAレコード及びAレコードの署名を要求部24に返信するステップS8。すなわち、examplejpサーバ1003は、図4Aに示すデータ33a及びデータ33bを返信する。そして、要求部24は、examplejpサーバ1003に対して、examplejpサーバ1003のDNSKEY及びDNSKEYの署名を問い合わせステップS9、examplejpサーバ1003は、DNSKEY及びDNSKEYの署名を要求部24に返信するステップS10。すなわち、examplejpサーバ1003は、図4Aに示すデータ33c及びデータ33dと、データ33eとを返信する。そして、要求部24は、ルートサーバ1001にexamplejpサーバ1003のDSレコードを問い合わせるステップS11、ルートサーバ1001は、NSレコードを参照して、jpサーバ1002に問い合わせて下さいと要求部24に返信するステップS12。そして、要求部24は、jpサーバ1002にexamplejpサーバ1003のDSレコードを問い合わせステップS13、jpサーバ1002は、examplejpサーバ1003のDSレコード及びDSレコードの署名を要求部24に返信するステップS14。すなわち、jpサーバ1002は、図4Bに示すデータ32a及びデータ32bを返信する。そして、要求部24は、jpサーバ1002にjpサーバ1002のDNSKEYを問い合わせステップS15、jpサーバ1002は、自身のDNSKEY及び署名を返信するステップS16。すなわち、jpサーバ1002は、図4Bに示すデータ32c及びデータ32dと、データ32eとを返信する。そして、要求部24は、ルートサーバ1001にjpサーバ1002のDSレコードを問い合わせステップS17、ルートサーバ1001は、jpサーバ1002のDSレコード及びDSレコードの署名を返信するステップS18。すなわち、ルートサーバ1001は、図4Cに示すデータ31a及びデータ31bを返信する。そして、要求部24は、ルートサーバ1001にルートサーバ1001のDNSKEYを問い合わせステップS19、ルートサーバ1001は、自身のDNSKEY及び署名を返信するステップS20。すなわち、ルートサーバ1001は、図4Cに示すデータ31c及びデータ31dと、データ31eとを返信する。そして、要求部24は、各権威サーバからの一連の応答データをキャッシュ部23に格納しステップS21、検証部22にキャッシュ部23が記憶する応答データの署名検証を依頼するステップS22。そして、検証部22は、検証処理を行うステップS23。具体的には、検証部22は、データ31dのハッシュ値とデータ23aのハッシュ値とを比較することにより、データ31dの正当性を検証する。また、検証部22は、データ31c及びデータ31dのハッシュ値と、データ31eをデータ31dで復号した結果とを比較することにより、データ31c及びデータ31dの正当性を検証する。また、検証部22は、データ31aと、データ31bをデータ31cで復号した結果とを比較することにより、データ31aの正当性を検証する。また、検証部22は、データ32dのハッシュ値とデータ31aとを比較することにより、データ32dの正当性を検証する。すなわち、検証部22は、ルートサーバ1001が保持するDSレコードを用いてKSK-B公開鍵の正当性を検証する。また、検証部22は、データ32c及びデータ32dのハッシュ値と、データ32eをデータ32dで復号した結果とを比較することにより、データ32c及びデータ32dの正当性を検証する。さらに、検証部22は、データ32aと、データ32bをデータ32cで復号した結果とを比較することにより、データ32aの正当性を検証する。また、検証部22は、データ33dのハッシュ値とデータ32aとを比較することにより、データ33dの正当性を検証する。すなわち、検証部22は、jpサーバ1002が保持するDSレコードを用いてKSK-C公開鍵の正当性を検証する。また、検証部22は、データ33c及びデータ33dのハッシュ値と、データ33eをデータ33dで復号した結果とを比較することにより、データ33c及びデータ33dの正当性を検証する。さらに、検証部22は、データ33aのハッシュ値と、データ33bをデータ33cで復号した結果とを比較することにより、データ33aの正当性を検証する。そして、検証部22は、全ての比較結果が一致する場合、権威サーバ群100からの応答データが正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部21は、クライアント装置10に対して、データ33aを返信する。一方、検証部22は、全ての比較結果が一致しない場合、権威サーバ群100からの応答データが不当であり、署名検証が失敗したと判定する。なお、図5に示した例において、ルートサーバ1001、jpサーバ1002及びexamplejpサーバ1003は、Aレコードや各電子署名やDNSKEY等の各種応答データをキャッシュサーバ20に送信する際にTTLを設定する。これにより、キャッシュサーバ20は、TTLに設定されている時間が経過するまで各種応答データをキャッシュすることとなる。ところで、上述してきた各権威サーバが保持する署名鍵であるZSKやKSKは、定期的に更新されることが望ましい。しかし、キャッシュサーバ20は、TTL時間が経過するまで各権威サーバから取得した署名鍵等をキャッシュ部23に保持する。このため、各権威サーバの署名鍵が更新された場合であっても、更新後の署名鍵がキャッシュサーバ20に即座に反映されないと考えられる。そこで、実施例1に係る権威サーバ群100は、権威サーバの管理者や運用者等によって署名鍵が更新された場合に、古い署名鍵の有効期限に応じてTTLの設定値を変動させることにより、更新後の署名鍵がキャッシュサーバ20に即座に反映されることを可能にする。この点について、図6を用いて簡単に説明する。図6は、実施例1に係る名前解決システム1による鍵更新処理の一例を示す図である。ここでは、権威サーバ1001、キャッシュサーバ20a及び20bを例に挙げて、実施例1に係る名前解決システム1による鍵更新処理について説明する。なお、キャッシュサーバ20a及び20bは、図2に例示したキャッシュサーバ20に対応する。また、以下では、権威サーバ1001によって設定されるTTLの通常値デフォルト値は、86400[秒]=24時間1日であるものとする。まず、権威サーバの管理者や運用者等が、新しい署名鍵を権威サーバ1001に登録したものとする。このとき、権威サーバの管理者や運用者等は、古い署名鍵を削除することなく新しい署名鍵を登録し、さらに、古い署名鍵から新しい署名鍵に更新される鍵更新日時を設定する。例えば、権威サーバの管理者や運用者等は、新しい署名鍵が有効となる開始日時等を設定する。このような状況において、図6に示した例のように、キャッシュサーバ20aが権威サーバ1001に対して名前解決に関する問い合わせを行ったものとするステップS31。この名前解決に関する問い合わせとは、図5に示したステップS3、S17、S19等における各種問い合わせであって、権威サーバ1001から名前解決の結果や署名鍵等の取得要求に該当する。このとき、実施例1に係る権威サーバ1001は、問い合わせを受け付けた日時から鍵更新日時までの時間を算出し、算出した時間がTTLの通常値86400以上であるか否かを判定する。ここでは、算出した時間がTTLの通常値86400以上であるものとする。かかる場合に、権威サーバ1001は、ステップS31において受け付けた問い合わせに対応する応答データのTTLに86400を設定し、かかる応答データをキャッシュサーバ20aに送信するステップS32。この送信処理は、図5に示したステップS18、S20等に該当する。これにより、キャッシュサーバ20aは、TTL時間である86400[秒]が経過するまでは権威サーバ1001から受け付けた応答データをキャッシュ部23に保持する。同様に、キャッシュサーバ20bが、鍵更新日時の1日以上前に、権威サーバ1001に対して名前解決に関する問い合わせを行ったものとするステップS33。この場合においても、権威サーバ1001は、応答データのTTLを86400に設定し、かかる応答データをキャッシュサーバ20bに送信するステップS34。これにより、キャッシュサーバ20bは、TTL時間である86400[秒]が経過するまでは応答データをキャッシュ部23に保持する。続いて、図6に示した例のように、キャッシュサーバ20aが、鍵更新日時の1時間前に、権威サーバ1001に対して名前解決に関する問い合わせを行ったものとするステップS35。かかる場合に、実施例1に係る権威サーバ1001は、問い合わせを受け付けた日時から鍵更新日時までの時間3600[秒]=1時間を算出し、算出した時間3600がTTLの通常値86400以上であるか否かを判定する。ここでは、算出した時間3600がTTLの通常値86400よりも小さいので、権威サーバ1001は、応答データのTTLに3600を設定し、かかる応答データをキャッシュサーバ20aに送信するステップS36。これにより、キャッシュサーバ20aは、TTL時間である3600[秒]が経過するまでは応答データをキャッシュ部23に保持する。すなわち、キャッシュサーバ20aは、TTL時間3600[秒]が経過した後に、クライアント装置10から名前解決の問い合わせを受け付けた場合には、キャッシュ部23から署名鍵等の応答データが削除されているので、権威サーバ1001に対して名前解決に関する問い合わせを行うステップS37。言い換えれば、キャッシュサーバ20aは、TTLに3600[秒]が設定されていることにより、権威サーバ1001において署名鍵が更新された後にクライアント装置10から名前解決の問い合わせを受け付けた場合には、権威サーバ1001から新しい署名鍵を取得して署名検証を行うこととなる。このため、権威サーバ1001は、署名鍵が更新された後には、更新後の新しい署名鍵をキャッシュサーバ20aに用いさせることができるので、キャッシュサーバ20aにおける署名鍵を短期間で更新することができる。なお、ステップS37において問い合わせを受け付けた権威サーバ1001は、問い合わせを受け付けた日時から鍵更新日時までの時間を算出し、算出した時間がTTLの通常値以上であるか否かを判定する。ここでは、算出した時間がTTLの通常値以上であるものとする。すなわち、権威サーバ1001は、応答データのTTLに86400を設定し、かかる応答データをキャッシュサーバ20aに送信するステップS38。続いて、図6に示した例のように、キャッシュサーバ20bが、鍵更新日時の20分前に、権威サーバ1001に対して名前解決に関する問い合わせを行ったものとするステップS39。かかる場合に、実施例1に係る権威サーバ1001は、問い合わせを受け付けた日時から鍵更新日時までの時間1200[秒]=20分を算出し、算出した時間1200を応答データのTTLに設定し、かかる応答データをキャッシュサーバ20bに送信するステップS40。これにより、キャッシュサーバ20bは、TTL時間である1200[秒]が経過するまでは応答データをキャッシュ部23に保持する。すなわち、キャッシュサーバ20bは、TTL時間1200[秒]が経過した後に、クライアント装置10から名前解決の問い合わせを受け付けた場合には、キャッシュ部23から署名鍵が削除されているので、権威サーバ1001に対して名前解決に関する問い合わせを行うステップS41。これにより、キャッシュサーバ20bは、権威サーバ1001において署名鍵が更新された後には、更新後の新しい署名鍵を用いて署名検証を行うことができる。なお、ここの例では、権威サーバ1001によって問い合わせを受け付けられた日時から鍵更新日時までの時間がTTLの通常値86400以上であるものとする。すなわち、権威サーバ1001は、応答データのTTLに86400を設定し、かかる応答データをキャッシュサーバ20bに送信するステップS42。このように、実施例1に係る名前解決システム1では、権威サーバ1001が鍵更新日時までの時間をTTLに設定するので、更新後の署名鍵をキャッシュサーバ20に即座に反映することができる。なお、図6に示した例では、権威サーバ1001とキャッシュサーバ20との間における処理の一例について説明したが、実施例1に係る権威サーバ1002や権威サーバ1003についてもキャッシュサーバ20との間で図6に例示した処理と同様の処理を行うことができる。以下に、このような権威サーバ1001、1002及び1003の構成について説明する。なお、実施例に係る権威サーバ1001、1002及び1003の構成のうち、図6に例示した処理を実現するための構成については同様である。したがって、以下では、権威サーバ1001を例に挙げて説明する。図7を用いて、権威サーバ1001の構成について説明する。図7は、実施例1における権威サーバ1001の構成例を示す図である。図7に例示するように、実施例1における権威サーバ1001は、IFinterface部110と、記憶部120と、管理部130と、問合せ処理部140とを有する。なお、図7では図示することを省略したが、権威サーバ1001は、各種情報や操作指示を入力するための入力部キーボード、マウス等や、各種情報を表示する表示デバイス液晶表示装置等を有してもよい。IF部110は、キャッシュサーバ20等の外部装置との間で各種データを送受信するNICNetworkInterfaceCard等である。例えば、IF部110は、キャッシュサーバ20から名前解決のための依頼等を受信する。また、例えば、IF部110は、名前解決のための依頼に対応する応答をキャッシュサーバ20に送信する。記憶部120は、RAMRandomAccessMemory、フラッシュメモリFlashMemory等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置であり、図4に例示した各種情報を記憶する。例えば、権威サーバ1001の記憶部120は、図4に例示したデータ31a、31b、31c、31d及び31e等を記憶する。また、記憶部120は、権威サーバの管理者や運用者等によって登録される新しい署名鍵を記憶する。管理部130は、署名鍵が新たな署名鍵に更新される日時である有効期限を管理する。具体的には、記憶部120に記憶されている署名鍵KSKやZSKには有効期限が設定されている。このため、管理部130は、記憶部120に記憶されている古い署名鍵や新しい署名鍵に設定されている有効期限を参照することにより、古い署名鍵が新しい署名鍵に更新される鍵更新日時を取得する。問合せ処理部140は、キャッシュサーバ20から送信される名前解決に関する問い合わせに対して各種応答処理を行う。具体的には、問合せ処理部140は、図5に示したステップS4、S12、S18及びS20等における処理を行う。このような問合せ処理部140は、図7に例示するように、受付部141と、設定部142と、送信部143とを有する。受付部141は、キャッシュサーバ20から名前解決に関する各種問い合わせを受け付ける。具体的には、実施例1における受付部141は、名前解決に関する各種問い合わせとして、名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバ20から受け付ける。例えば、受付部141は、図5に示したステップS3、S11、S17及びS19等における複数種類の取得要求を受け付ける。設定部142は、受付部141によって受け付けられた取得要求に対応する応答データに対して、署名鍵が新たな署名鍵に更新される鍵更新日時までの期間である有効期間を、キャッシュサーバ20にキャッシュされる応答データのキャッシュ期間TTLとして設定する。具体的には、設定部142は、受付部141によって各種取得要求が受け付けられた場合に、取得要求を受け付けた日時から管理部130によって管理されている鍵更新日時までの時間である有効期間を算出する。そして、設定部142は、算出した有効期間がTTLの通常値上記例では86400以上であるか否かを判定する。そして、設定部142は、有効期間が通常値以上である場合には、応答データのTTLに通常値を設定し、有効期間が通常値よりも小さい場合には、応答データのTTLに有効期間を設定する。送信部143は、受付部141によって各種取得要求が受け付けられた場合に、設定部142によってTTLが設定された応答データをキャッシュサーバ20に送信する。なお、上記の管理部130及び問合せ処理部140は、例えば、CPUCentralProcessingUnitやMPUMicroProcessingUnit等によって、図示しない記憶装置に記憶されているプログラムがRAMRandomAccessMemoryを作業領域として実行されることにより実現される。また、例えば、管理部130及び問合せ処理部140は、ASICApplicationSpecificIntegratedCircuitやFPGAFieldProgrammableGateArray等の集積回路により実現される。次に、図8を用いて、実施例1に係る権威サーバ1001による処理の手順について説明する。図8は、実施例1に係る権威サーバ1001による処理手順を示すフローチャートである。図8に示すように、権威サーバ1001の受付部141は、キャッシュサーバ20から名前解決に関する各種取得要求を受け付けたか否かを判定するステップS101。そして、受付部141は、キャッシュサーバ20から各種取得要求を受け付けない場合にはステップS101否定、キャッシュサーバ20から取得要求を受け付けるまで待機する。一方、受付部141によってキャッシュサーバ20から取得要求が受け付けられた場合にはステップS101肯定、設定部142は、かかる取得要求を受け付けた日時から鍵更新日時までの時間である有効期間を算出しステップS102、算出した有効期間がTTLの通常値以上であるか否かを判定するステップS103。そして、設定部142は、有効期間が通常値以上である場合にはステップS103肯定、応答データのTTLに通常値を設定しステップS104、有効期間が通常値よりも小さい場合にはステップS103否定、応答データのTTLにかかる有効期間を設定するステップS105。そして、送信部143は、設定部142によってTTLが設定された応答データをキャッシュサーバ20に送信するステップS106。上述してきたように、実施例1に係る権威サーバ群100は、名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバ20から受け付ける受付部141と、受付部141によって受け付けられた取得要求に対応する応答データに対して、署名鍵が新たな署名鍵に更新されるまでの期間である有効期間をTTLとして設定する設定部142と、設定部142によってTTLが設定された応答データをキャッシュサーバ20に送信する送信部143とを有する。これにより、実施例1に係る権威サーバ群100は、署名鍵が更新されるタイミングと略同一のタイミングで、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を削除させることができる。この結果、権威サーバ群100は、署名鍵が更新された後には、更新後の新しい署名鍵をキャッシュサーバ20に用いさせることができるので、キャッシュサーバ20における署名鍵を短期間で更新することができる。また、実施例1に係る権威サーバ群100において、設定部142は、署名鍵の有効期間が通常値以上である場合には、かかる通常値を応答データのTTLに設定し、署名鍵の有効期間が通常値よりも小さい場合には、かかる有効期間を応答データのTTLに設定する。これにより、実施例1に係る権威サーバ群100は、署名鍵の更新タイミングまで長期間ある場合には、キャッシュサーバ20におけるキャッシュ部23から署名鍵等が短期間で削除されることを防止でき、署名鍵の更新タイミングが近づいてきた場合には、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を通常時よりも短期間で削除させることで、キャッシュサーバ20における署名鍵を短期間で更新することができる。また、実施例1に係る権威サーバ群100において、設定部142は、署名鍵が新たな署名鍵に更新される日時と、受付部141によって取得要求が受け付けられた日時との差分を有効期間として算出する。これにより、実施例1に係る権威サーバ群100は、署名鍵の更新タイミングと、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を削除させるタイミングとを一致させることができる。ここで、従来の名前解決システムと比較して、実施例1に係る権威サーバ群100における効果の一例を説明する。例えば、従来の名前解決システムにおいて権威サーバが保持するZSKやKSK等の署名鍵を更新する場合や、署名鍵の更新に伴って電子署名を更新する場合には、権威サーバの管理者や運用者等は、古い署名鍵や古い電子署名を削除することなく新しい署名鍵や古い電子署名を権威サーバに追加する。例えば、権威サーバの管理者や運用者等が権威サーバに新しい署名鍵を追加したものとする。この段階では、権威サーバは、新しい署名鍵を保持しているだけであって、かかる新しい署名鍵と対になる電子署名を保持していないので、古い署名鍵を用いて署名を実施する。この例では、権威サーバは、まず新しい署名鍵をキャッシュサーバに保持させてから、新しい署名鍵と対になる電子署名を検証させられる状態をつくるからである。そして、キャッシュサーバは、TTL時間が経過したキャッシュが削除され、クライアント装置から問い合わせがあった場合に、権威サーバから署名鍵を取得する。ここでは、権威サーバに古い署名鍵と新しい署名鍵の双方が登録されているので、キャッシュサーバは、権威サーバから古い署名鍵と新しい署名鍵との双方を取得する。その後、権威サーバは、十分に時間が経過して古い署名鍵と新しい署名鍵の双方がキャッシュサーバに伝播した場合に、新しい署名鍵を用いて署名を実施する。ただし、この段階では、キャッシュサーバは、権威サーバから古い署名鍵と新しい署名鍵の双方を取得した際の各種データがキャッシュされているので、権威サーバから新しい署名鍵に対応する署名を取得しない。そして、キャッシュサーバは、TTL時間が経過したキャッシュが削除され、クライアント装置から問い合わせがあった場合に、権威サーバから署名鍵等を取得する。この後に、権威サーバの管理者や運用者等は、権威サーバから古い署名鍵や古い電子署名を削除することが可能となる。このように、従来の名前解決システムにおいては、権威サーバの署名鍵を更新する場合には、TTL時間が経過するまで待機するステップが複数存在するので、キャッシュサーバにおける署名鍵を短期間で更新することができない。一方で、実施例1に係る権威サーバ群100においては、権威サーバ群100の署名鍵が更新されるタイミングと略同一のタイミングで、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を削除させることができるので、キャッシュサーバ20における署名鍵を短期間で更新することができる。上述した名前解決システム1は、上記実施例以外にも種々の異なる形態にて実施されてよい。そこで、実施例2では、上記の名前解決システム1の他の実施例について説明する。[TTLの設定値]上記実施例1では、設定部142が、新たな署名鍵に更新されるまでの署名鍵の有効期間がTTLの通常値よりも小さい場合には、かかる有効期間を応答データのTTLとして設定する例を示した。しかし、設定部142は、有効期間と同一の期間をTTLに設定しなくてもよい。具体的には、設定部142は、通常値よりも短く、かつ、有効期間よりも所定期間だけ長い期間をTTLとして設定してもよい。例えば、署名鍵が新たな署名鍵に更新されるまでの有効期間が1200[秒]であるものとする。かかる場合に、設定部142は、有効期間1200より大きく、かつ、通常値86400よりも小さい値例えば、1201、1800、3600等をTTLに設定してもよい。[キャッシュサーバに応じたTTLの設定]また、権威サーバに複数のキャッシュサーバが接続されており、かかる権威サーバの受付部141によって複数のキャッシュサーバから各種取得要求が受け付けられる場合には、設定部142は、キャッシュサーバに応じて異なるTTLを応答データに設定してもよい。例えば、署名鍵の有効期間が1200であるものとする。かかる場合に、設定部142は、例えば、キャッシュサーバ20aに送信する応答データに対しては有効期間1200をTTLに設定し、キャッシュサーバ20bに送信する応答データに対しては1800をTTLに設定し、キャッシュサーバ20cに送信する応答データに対しては3600をTTLに設定してもよい。これにより、キャッシュサーバによってキャッシュ部23から各種情報が削除されるタイミングが異なるので、各キャッシュサーバから権威サーバ群100に名前解決のための問い合わせが行われるタイミングもキャッシュサーバによって変動する。これにより、権威サーバ群100による名前解決のための処理にかかる負荷を分散することができる。また、設定部142は、署名鍵の有効期間がTTLの通常値よりも小さい場合に、特定のキャッシュサーバに送信する応答データに対してのみ、有効期間をTTLに設定してもよい。例えば、署名鍵の更新を短期間で更新することが望まれている特定のキャッシュサーバが予め決められている場合等に、設定部142は、かかる特定のキャッシュサーバに送信する応答データに対してのみ、有効期間をTTLに設定してもよい。[有効期間の算出]また、上記実施例1では、設定部142が、受付部141によって各種取得要求が受け付けられた場合に、管理部130によって管理されている鍵更新日時と、受付部141によって取得要求が受け付けられた日時との差分を署名鍵の有効期間として算出する例を示した。しかし、設定部142は、他の手法によって署名鍵の有効期間を算出してもよい。例えば、設定部142は、管理部130によって管理されている鍵更新日時と、現在日時との差分を署名鍵の有効期間として算出してもよい。[システム構成]また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図3、図4に示した各種情報は一例であって任意に変更することができる。また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。例えば、図7に例示した管理部130と設定部142とは統合されてもよい。[プログラム]また、上記実施例において説明した各権威サーバ権威サーバ1001、1002及び1003が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例1に係る権威サーバが実行する処理をコンピュータが実行可能な言語で記述した鍵更新プログラムを作成することもできる。この場合、コンピュータが鍵更新プログラムを実行することにより、上記実施例1と同様の効果を得ることができる。さらに、かかる鍵更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された鍵更新プログラムをコンピュータに読み込ませて実行することにより上記実施例1と同様の処理を実現してもよい。以下に、図7に示した権威サーバと同様の機能を実現する鍵更新プログラムを実行するコンピュータの一例を説明する。図9は、鍵更新プログラムを実行するコンピュータ1000を示す図である。図9に例示するように、コンピュータ1000は、例えば、メモリ1010と、CPU1020と、ハードディスクドライブインタフェース1030と、ディスクドライブインタフェース1040と、シリアルポートインタフェース1050と、ビデオアダプタ1060と、ネットワークインタフェース1070とを有し、これらの各部はバス1080によって接続される。メモリ1010は、図9に例示するように、ROMReadOnlyMemory1011及びRAM1012を含む。ROM1011は、例えば、BIOSBasicInputOutputSystem等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、図9に例示するように、ハードディスクドライブ1031に接続される。ディスクドライブインタフェース1040は、図9に例示するように、ディスクドライブ1041に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース1050は、図9に例示するように、例えばマウス1051、キーボード1052に接続される。ビデオアダプタ1060は、図9に例示するように、例えばディスプレイ1061に接続される。ここで、図9に例示するように、ハードディスクドライブ1031は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、上記の鍵更新プログラムは、コンピュータ1000によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ1031に記憶される。例えば、図7に例示した管理部130と同様の情報処理を実行する管理手順と、問合せ処理部140と同様の情報処理を実行する問合せ処理手順と、受付部141と同様の情報処理を実行する受付手順と、設定部142と同様の情報処理を実行する設定手順と、送信部143と同様の情報処理を実行する送信手順とが記述されたプログラムモジュール1093が、ハードディスクドライブ1031に記憶される。また、上記実施例で説明した記憶部120が保持する各種データは、プログラムデータとして、例えばメモリ1010やハードディスクドライブ1031に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1031に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出し、管理手順、問合せ処理手順、受付手順、設定手順、送信手順を実行する。なお、鍵更新プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1031に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してCPU1020によって読み出されてもよい。あるいは、鍵更新プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ネットワークLANLocalAreaNetwork、WANWideAreaNetwork等を介して接続された他のコンピュータに記憶され、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。