JP2013093702A - 権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラム - Google Patents

Abstract

【課題】キャッシュサーバにおける署名鍵を短期間で更新する。
【解決手段】権威サーバ１００の受付部１４１は名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付け、設定部１４２は受け付けられた取得要求に対応する応答データに対して、署名鍵が更新されるまでの期間である有効期間をキャッシュサーバにキャッシュされる応答データのキャッシュ期間として設定し、送信部１４３はキャッシュ期間が設定された応答データをキャッシュサーバに送信する。
【選択図】図７

Description

本発明の実施形態は、権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムに関する。

従来、ドメイン名とＩＰアドレス（Internet Protocol Address）とを対応させる名前管理システム（ＤＮＳ：Domain Name System）が知られている。ＤＮＳは、一般的には、権威サーバ群とキャッシュサーバとから構成される。各権威サーバは、階層的な木構造を有する名前空間（「ドメイン名前空間」等とも呼ばれる）の中にある特定のゾーンを管理する。キャッシュサーバは、クライアント装置からの名前解決の依頼に応じて、権威サーバ群に問い合わせを行うとともに、権威サーバ群からの応答データをキャッシュする。

また、近年、ＤＮＳの拡張仕様として、権威サーバ群からの応答データの正当性を保証するＤＮＳＳＥＣ（ＤＮＳ Security Extensions）の普及が進められている。ＤＮＳＳＥＣにおいては、権威サーバ群からの応答データの正当性を保証するために、電子署名を用いた検証（署名検証）が行われ、最上位のルートゾーンを管理する権威サーバによって保持される署名鍵を基点として「信頼の連鎖」が構築される。

この「信頼の連鎖」について具体的に説明すると、階層的な木構造を有する名前空間上の特定のゾーンを管理する各権威サーバには、互いに上位権威サーバと下位権威サーバとの関係がある。例えば、所定の権威サーバは、かかる所定の権威サーバ自身が管理するゾーンの下位ゾーンを管理する下位権威サーバにとっての上位権威サーバとなり、かかる所定の権威サーバ自身が管理するゾーンの上位ゾーンを管理する上位権威サーバにとっての下位権威サーバとなる。このような各権威サーバは、例えばＤＮＳＳＥＣのＤＳ（Delegation Signer）方式が適用されている場合には、Ａ（Address）レコード等の一般的なＤＮＳレコード等に署名を行うためのＺＳＫ（Zone Signing Key）を保持するとともに、ＺＳＫ等のＤＮＳＫＥＹに署名を行うためのＫＳＫ（Key Signing Key）を保持する。なお、上位権威サーバは、下位権威サーバが保持するＫＳＫ（公開鍵）のハッシュ値をＤＳレコードとして保持し、かかるＤＳレコードについてもＺＳＫを用いて署名を行う。

キャッシュサーバは、このような権威サーバ群に対して名前解決を依頼した場合に、ルートゾーンを管理する最上位の権威サーバであるルートサーバによって提供されるＫＳＫ（公開鍵）を用いて、ルートサーバが保持するＺＳＫ（公開鍵）の署名検証を行う。さらに、キャッシュサーバは、検証済みのＺＳＫ（公開鍵）を用いて、ルートサーバに登録されているＤＳレコード（ルートサーバの下位に位置する下位権威サーバが保持するＫＳＫ（公開鍵）のハッシュ値）の署名検証を行う。そして、キャッシュサーバは、検証済みのＤＳレコードを用いて、下位権威サーバが保持するＫＳＫ（公開鍵）の署名検証を行い、署名検証済みのＫＳＫ（公開鍵）を用いて、かかる下位権威サーバが保持するＺＳＫ（公開鍵）等の署名検証を行う。このようにして、キャッシュサーバは、上位権威サーバに登録されているＤＳレコードを用いて、下位権威サーバが保持する署名鍵であるＫＳＫの署名検証を順次行う。そして、キャッシュサーバは、名前解決の依頼に対応する応答データを送信した下位権威サーバが保持するＺＳＫ（公開鍵）等の署名検証を行い、署名検証済みのＺＳＫ（公開鍵）を用いて、応答データの署名検証を行う。これにより、キャッシュサーバは、正当性が保証されたＩＰアドレスなどの応答データをクライアント装置に送信することが可能となる。このように、ＤＮＳＳＥＣのＤＳ方式では、最上位のルートサーバが保持する署名鍵が信頼できるという前提の下、かかる署名鍵を基点として「信頼の連鎖」が構築される。

民田雅人、他著 「実践ＤＮＳ ＤＮＳＳＥＣ時代のＤＮＳの設定を運用」ＡＳＣＩＩ

ところで、上記の従来技術において、権威サーバの管理者や運用者等は、署名鍵であるＺＳＫやＫＳＫを定期的に更新することが望ましい。これは、署名鍵が盗難するおそれや第三者によって署名鍵が解読されるおそれ等があるからである。

しかしながら、上記の従来技術では、権威サーバの管理者や運用者等が署名鍵を更新した場合であっても、かかる署名鍵がキャッシュサーバに即座に反映されることはない。具体的には、各権威サーバは、署名鍵（ＤＮＳＫＥＹレコード）をキャッシュサーバに提供する際に、キャッシュサーバが署名鍵を保持する期間を示すＴＴＬ（Time To Live）を設定する。このため、キャッシュサーバは、ＴＴＬ時間が経過しない限りは、たとえ権威サーバの署名鍵が更新された場合であっても、キャッシュ済みの古い署名鍵を用いることとなる。

例えば、非特許文献１に開示されているように、事前公開法や二重署名法等の署名鍵更新方法を行った場合、上述した信頼の連鎖が途切れないことを担保するためには、更新後の署名鍵がキャッシュサーバに反映されるまでに、ＴＴＬ（Time To Live）時間が経過してキャッシュサーバのキャッシュから古い署名鍵等が削除されるまでの時間を要する。このような古い署名鍵がキャッシュサーバにおいて使用され続けることは、セキュリティの観点から好ましくないといえる。

本願の開示する技術は、上記に鑑みてなされたものであって、キャッシュサーバにおける署名鍵を短期間で更新することができる権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムを提供することを目的とする。

実施形態に係る権威サーバは、名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第１所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部とを備えることを特徴とする。

実施形態に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムは、キャッシュサーバにおける署名鍵を短期間で更新することができるという効果を奏する。

図１は、実施例１に係る名前解決システムの構成例を示す図である。 図２は、実施例１に係る名前解決システムが有するキャッシュサーバの構成例を示す図である。 図３は、権威サーバ群に含まれる権威サーバの一例を示す図である。 図４は、ＤＮＳＳＥＣに用いられる各種データの一例を示す図である。 図５は、実施例１に係る名前解決システムが実行する署名検証処理の一例を示すシーケンス図である。 図６は、実施例１に係る名前解決システムによる鍵更新処理の一例を示す図である。 図７は、実施例１における権威サーバの構成例を示す図である。 図８は、実施例１に係る権威サーバによる処理手順を示すフローチャートである。 図９は、鍵更新プログラムを実行するコンピュータを示す図である。

以下に、本願に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムが限定されるものではない。

まず、図１を用いて、実施例１に係る名前解決システムについて説明する。図１は、実施例１に係る名前解決システムの構成例を示す図である。図１に示す名前解決システム１は、クライアント装置１０、キャッシュサーバ２０、権威サーバ群１００を有する。ここで、図１に示す各装置は、インターネットを介して通信可能な状態で接続される。

クライアント装置１０は、例えば、ＰＣ（Personal Computer）、携帯電話機、ＰＤＡ（Personal Digital Assistant）等であり、キャッシュサーバ２０に対して、名前解決の依頼を送信する。具体的には、クライアント装置１０は、キャッシュサーバ２０に対して、ホスト名を通知することでＩＰアドレスの検索を要求したり、その逆にＩＰアドレスを通知することでホスト名の検索を要求したりする。このようなクライアント装置１０で動作するプログラムは「リゾルバ」と呼ばれる。なお、図１では、キャッシュサーバ２０に接続されるクライアント装置１０を一台のみ示しているが、実際には、キャッシュサーバ２０には複数台のクライアント装置が接続される。

キャッシュサーバ２０は、クライアント装置１０から所定のドメイン名（例えば、「www.example.jp」）の名前解決の依頼を受け付ける。そして、キャッシュサーバ２０は、権威サーバ群１００に、依頼されたドメイン名の名前解決のための問い合わせを行うとともに、権威サーバ群１００からの応答データをキャッシュする機能を有する。

権威サーバ群１００は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。図１に示した例では、権威サーバ群１００には、権威サーバ１００_１、１００_２及び１００_３が含まれる。なお、図１では、権威サーバ群１００に３台の権威サーバが含まれる例を示したが、権威サーバ群１００には、２台以下の権威サーバや４台以上の権威サーバが含まれてもよい。

ここで、図２〜図５を用いて、キャッシュサーバ２０と権威サーバ群１００とにより実行されるＤＮＳＳＥＣの処理の一例を説明する。その後に、図６〜図８を用いて、実施例１に係る権威サーバ群１００について説明する。

図２は、実施例１に係る名前解決システム１が有するキャッシュサーバ２０の構成例を示す図である。図２に例示するように、実施例１におけるキャッシュサーバ２０は、応答部２１と、検証部２２と、キャッシュ部２３と、要求部２４とを有する。

応答部２１は、クライアント装置１０との間で通信を行う。要求部２４は、権威サーバ群１００との間で通信を行う。また、要求部２４は、権威サーバ群１００から受信した応答データをキャッシュ部２３に格納する。検証部２２は、キャッシュ部２３に格納された権威サーバ群１００からの応答データを用いて署名検証を行う。キャッシュ部２３は、署名検証に成功した応答データをキャッシュする。具体的には、キャッシュ部２３は、署名検証に成功した場合、名前解決を依頼されたドメイン名とドメイン名のＩＰアドレスとを対応付けた情報、署名鍵としてのＤＳレコードやＤＮＳＫＥＹレコード等をキャッシュする。

ここで、応答部２１は、クライアント装置１０から名前解決を依頼された場合、依頼されたドメイン名のＩＰアドレスが、キャッシュ部２３にキャッシュ情報として既に格納されているか否かを判定する。応答部２１は、依頼されたドメイン名のＩＰアドレスがキャッシュ情報として既に格納されている場合、クライアント装置１０に対してＩＰアドレスを返信する。

一方、応答部２１は、依頼されたドメイン名のＩＰアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部２４に転送する。そして、要求部２４は、依頼内容に基づいて、権威サーバ群１００に問い合わせを行う。

ここで、図３〜図５を用いて、キャッシュサーバ２０が、クライアント装置１０からキャッシュ情報として格納されていない「www.example.jp」の名前解決の依頼を受け付けた場合に、権威サーバ群１００に対して「www.example.jp」に関する問い合わせを行う例について説明する。図３は、権威サーバ群１００に含まれる権威サーバの一例を示す図である。なお、以下では、クライアント装置１０がＩＰｖ４（Internet Protocol version 4）アドレスを要求している場合について説明する。

図３に示した例のように、キャッシュサーバ２０は、「www.example.jp」の名前解決を行う場合に、権威サーバ１００_１（ここでは「ルートサーバ１００_１」であるものとする）、権威サーバ１００_２（ここでは「jp.サーバ１００_２」であるものとする）、権威サーバ１００_３（ここでは「example.jp.サーバ１００_３」であるものとする）に対して問い合わせを行う。

ルートサーバ１００_１は、階層的な木構造を有する名前空間のうち最上位ゾーンであるルートゾーンを管理するサーバであり、例えば「jp」や「com」等のドメイン名（ＴＬＤ：Top Level Domain）を管理するサーバのインターネット上の位置（ＩＰアドレス）を管理する。また、jp.サーバ１００_２は、「jp」のＴＬＤサーバであり、「jp」で管理される「example.jp」や「ad.jp」などのインターネット上の位置（ＩＰアドレス）を管理する。また、example.jp.サーバ１００_３は、example.jp.サーバ１００_３自身が管理する名前空間の中にあるホスト、例えば、「www.example.jp」や「ftp.example.jp」のインターネット上の位置（ＩＰアドレス）を管理する。なお、上位権威サーバは、上位権威サーバ自身が管理するゾーンの下位ゾーンを管理する下位権威サーバのドメイン名をＮＳ（Name Server）レコードとして保持し、かかる下位権威サーバのＩＰアドレスをＡレコード又はＡＡＡＡレコード（クワッドＡレコード）として保持する。例えば、jp.サーバ１００_２は、下位権威サーバであるexample.jp.サーバ１００_３のＮＳレコードやＡレコード等を保持する。

これらのルートサーバ１００_１、jp.サーバ１００_２及びexample.jp.サーバ１００_３は、ＤＮＳＳＥＣが有効化されており、ＺＳＫ及びＫＳＫを保持する。図３に示した例では、ルートサーバ１００_１は、ＺＳＫとして「ＺＳＫ−Ａ（公開鍵）及びＺＳＫ−Ａ（秘密鍵）」を保持し、ＫＳＫとして「ＫＳＫ−Ａ（公開鍵）及びＫＳＫ−Ａ（秘密鍵）」を保持する。また、jp.サーバ１００_２は、ＺＳＫとして「ＺＳＫ−Ｂ（公開鍵）及びＺＳＫ−Ｂ（秘密鍵）」を保持し、ＫＳＫとして「ＫＳＫ−Ｂ（公開鍵）及びＫＳＫ−Ｂ（秘密鍵）」を保持する。また、example.jp.サーバ１００_３は、ＺＳＫとして「ＺＳＫ−Ｃ（公開鍵）及びＺＳＫ−Ｃ（秘密鍵）」を保持し、ＫＳＫとして「ＫＳＫ−Ｃ（公開鍵）及びＫＳＫ−Ｃ（秘密鍵）」を保持する。

なお、図３に示した例では、ルートサーバ１００_１、jp.サーバ１００_２及びexample.jp.サーバ１００_３が、ＺＳＫ（秘密鍵）及びＫＳＫ（秘密鍵）を保持する例を示した。しかし、実際には、ルートサーバ１００_１、jp.サーバ１００_２及びexample.jp.サーバ１００_３は、ＺＳＫ（秘密鍵）及びＫＳＫ（秘密鍵）については自装置内に保持しない。これらのＺＳＫ（秘密鍵）及びＫＳＫ（秘密鍵）は、ルートサーバ１００_１、jp.サーバ１００_２及びexample.jp.サーバ１００_３がアクセスできるが一般ユーザからアクセスできない別装置によって管理される。そして、ルートサーバ１００_１、jp.サーバ１００_２及びexample.jp.サーバ１００_３は、この別装置によってＺＳＫ（秘密鍵）及びＫＳＫ（秘密鍵）を用いて生成された電子署名をかかる別装置から受け取り、受け取った電子署名を保持する。ただし、このような別装置が存在しないシステムの場合には、ルートサーバ１００_１、jp.サーバ１００_２及びexample.jp.サーバ１００_３は、ＺＳＫ（秘密鍵）及びＫＳＫ（秘密鍵）を保持してもよい。

ここで、ＤＮＳＳＥＣでは、ルートサーバ１００_１、jp.サーバ１００_２、example.jp.サーバ１００_３及びキャッシュサーバ２０は、同一のハッシュ関数を用いてハッシュ値を計算する。また、ＤＳ方式では、下位権威サーバは、上位権威サーバに対して、かかる下位権威サーバが保持するＫＳＫ（公開鍵）のハッシュ値であるＤＳレコードを予め通知している。すなわち、example.jp.サーバ１００_３は、自身のＤＳレコードをjp.サーバ１００_２に通知し、jp.サーバ１００_２は、自身のＤＳレコードをルートサーバ１００_１に通知する。そして、ルートサーバ１００_１は、自身のＤＳレコードをキャッシュサーバ２０に通知する。

これらのルートサーバ１００_１、jp.サーバ１００_２、example.jp.サーバ１００_３及びキャッシュサーバ２０は、図４に例示するデータを用いて、ＤＮＳＳＥＣにおける電子署名を用いた署名検証を実現する。図４は、ＤＮＳＳＥＣに用いられる各種データの一例を示す図である。

図４（Ａ）に示すように、example.jp.サーバ１００_３は、「www.example.jp」のＩＰｖ４アドレスの情報を含む「Ａレコード」のデータ３３ａを保持する。なお、クライアント装置１０がＩＰｖ６（Internet Protocol version 6）アドレスを要求している場合には、ＤＮＳＳＥＣに用いられるデータは、「www.example.jp」のＩＰｖ６アドレスの情報を含むＡＡＡＡレコードとなる。

また、図４（Ａ）に示すように、example.jp.サーバ１００_３は、「Ａレコードのハッシュ値をＺＳＫ−Ｃ（秘密鍵）で暗号化した電子署名」であるデータ３３ｂを保持する。また、図４（Ａ）に示すように、example.jp.サーバ１００_３は、「ＺＳＫ−Ｃ（公開鍵）」のデータ３３ｃと、「ＫＳＫ−Ｃ（公開鍵）」のデータ３３ｄと、「ＺＳＫ−Ｃ（公開鍵）及びＫＳＫ−Ｃ（公開鍵）のハッシュ値をＫＳＫ−Ｃ（秘密鍵）で暗号化した電子署名」であるデータ３３ｅを保持する。このように、ＺＳＫ−Ｃ（公開鍵）及びＫＳＫ−Ｃ（公開鍵）であるＤＮＳＫＥＹについては、ＺＳＫ−Ｃ（公開鍵）とＫＳＫ−Ｃ（公開鍵）とが統合されたデータに対して１つの電子署名（データ３３ｅ）が作成される。

すなわち、example.jp.サーバ１００_３は、「www.example.jp」のＡレコード及びＡレコードの署名として、データ３３ａ及びデータ３３ｂを保持する。また、example.jp.サーバ１００_３は、ＤＮＳＫＥＹとしてデータ３３ｃ及びデータ３３ｄを保持する。また、example.jp.サーバ１００_３は、ＤＮＳＫＥＹの署名としてデータ３３ｅを保持する。また、図４（Ａ）では図示していないが、example.jp.サーバ１００_３は、下位権威サーバが存在する場合には、かかる下位権威サーバのＤＳレコード（下位権威サーバのＫＳＫ（公開鍵）のハッシュ値）を保持する。

また、図４（Ｂ）に示すように、jp.サーバ１００_２は、example.jp.サーバ１００_３のＤＳレコード、すなわち、「ＫＳＫ−Ｃ（公開鍵）のハッシュ値」であるデータ３２ａと、「ＤＳレコード（ＫＳＫ−Ｃ（公開鍵）のハッシュ値）をＺＳＫ−Ｂ（秘密鍵）で暗号化した電子署名」であるデータ３２ｂとを保持する。また、図４（Ｂ）に示すように、jp.サーバ１００_２は、「ＺＳＫ−Ｂ（公開鍵）」のデータ３２ｃと、「ＫＳＫ−Ｂ（公開鍵）」のデータ３２ｄと、「ＺＳＫ−Ｂ（公開鍵）及びＫＳＫ−Ｂ（公開鍵）のハッシュ値をＫＳＫ−Ｂ（秘密鍵）で暗号化した電子署名」であるデータ３２ｅを保持する。

すなわち、jp.サーバ１００_２は、example.jp.サーバ１００_３のＤＳレコード及びＤＳレコードの署名として、データ３２ａ及びデータ３２ｂを保持する。また、jp.サーバ１００_２は、ＤＮＳＫＥＹとしてデータ３２ｃ及びデータ３２ｄを保持する。また、jp.サーバ１００_２は、ＤＮＳＫＥＹの署名としてデータ３２ｅを保持する。

また、図４（Ｃ）に示すように、ルートサーバ１００_１は、jp.サーバ１００_２のＤＳレコード、すなわち、「ＫＳＫ−Ｂ（公開鍵）のハッシュ値」であるデータ３１ａと、「ＤＳレコード（ＫＳＫ−Ｂ（公開鍵）のハッシュ値）をＺＳＫ−Ａ（秘密鍵）で暗号化した電子署名」であるデータ３１ｂを保持する。また、図４（Ｃ）に示すように、ルートサーバ１００_１は、「ＺＳＫ−Ａ（公開鍵）」のデータ３１ｃと、「ＫＳＫ−Ａ（公開鍵）」のデータ３１ｄと、「ＺＳＫ−Ａ（公開鍵）及びＫＳＫ−Ａ（公開鍵）のハッシュ値をＫＳＫ−Ａ（秘密鍵）で暗号化した電子署名」であるデータ３１ｅとを保持する。

すなわち、ルートサーバ１００_１は、jp.サーバ１００_２のＤＳレコード及びＤＳレコードの署名として、データ３１ａ及びデータ３１ｂを保持する。また、ルートサーバ１００_１は、ＤＮＳＫＥＹとしてデータ３１ｃ及びデータ３１ｄを保持する。また、ルートサーバ１００_１は、ＤＮＳＫＥＹの署名としてデータ３１ｅを保持する。

そして、図４（Ｄ）に示すように、キャッシュサーバ２０は、例えば、ルートサーバ１００_１のＤＳレコード、すなわち、「ＫＳＫ−Ａ（公開鍵）」であるデータ２３ａをキャッシュ部２３内に保持する。

なお、図４では、キャッシュサーバ２０が、ルートサーバ１００_１の「ＫＳＫ−Ａ（公開鍵）」をキャッシュ部２３に保持する例を示した。しかし、キャッシュサーバ２０は、「ＫＳＫ−Ａ（公開鍵）」ではなく、ＫＳＫ−Ａ（公開鍵）のキャッシュ値であるＤＳレコードをキャッシュ部２３に保持してもよい。具体的には、キャッシュサーバ２０は、ルートサーバ１００_１によって保持されているデータ３１ｅと比較した後のＫＳＫ−Ａ（公開鍵）のキャッシュ値をキャッシュ部２３に保持してもよい。

図４に例示したデータを用いて、実施例１に係る名前解決システム１が実行する署名検証処理について、図５を用いて説明する。図５は、実施例１に係る名前解決システム１が実行する署名検証処理の一例を示すシーケンス図である。

図５に示すように、クライアント装置１０は、キャッシュサーバ２０の応答部２１に対して、「www.example.jp」のＡレコードを問い合わせる名前解決の依頼を行う（ステップＳ１）。名前解決の依頼を受け付けた応答部２１は、要求部２４に名前解決の依頼内容を転送し（ステップＳ２）、要求部２４は、ルートサーバ１００_１にＡレコードを問い合わせる（ステップＳ３）。

「www.example.jp」のＡレコードの問い合わせを受け付けたルートサーバ１００_１は、ＮＳレコードを参照して、「jp.サーバ１００_２に問い合わせて下さい」と要求部２４に返信する（ステップＳ４）。具体的には、ルートサーバ１００_１は、jp.サーバ１００_２のＩＰアドレスを要求部２４に返信する。そして、要求部２４は、jp.サーバ１００_２にＡレコードを問い合わせる（ステップＳ５）。

「www.example.jp」のＡレコードの問い合わせを受け付けたjp.サーバ１００_２は、ＮＳレコードを参照して、「example.jp.サーバ１００_３に問い合わせて下さい」と要求部２４に返信する（ステップＳ６）。すなわち、jp.サーバ１００_２は、example.jp.サーバ１００_３のＩＰアドレスを要求部２４に返信する。そして、要求部２４は、example.jp.サーバ１００_３にＡレコードを問い合わせる（ステップＳ７）。

「www.example.jp」のＡレコードの問い合わせを受け付けたexample.jp.サーバ１００_３は、「www.example.jp」のＡレコード及びＡレコードの署名を要求部２４に返信する（ステップＳ８）。すなわち、example.jp.サーバ１００_３は、図４（Ａ）に示すデータ３３ａ及びデータ３３ｂを返信する。

そして、要求部２４は、example.jp.サーバ１００_３に対して、example.jp.サーバ１００_３のＤＮＳＫＥＹ及びＤＮＳＫＥＹの署名を問い合わせ（ステップＳ９）、example.jp.サーバ１００_３は、ＤＮＳＫＥＹ及びＤＮＳＫＥＹの署名を要求部２４に返信する（ステップＳ１０）。すなわち、example.jp.サーバ１００_３は、図４（Ａ）に示すデータ３３ｃ及びデータ３３ｄと、データ３３ｅとを返信する。

そして、要求部２４は、ルートサーバ１００_１にexample.jp.サーバ１００_３のＤＳレコードを問い合わせる（ステップＳ１１）、ルートサーバ１００_１は、ＮＳレコードを参照して、「jp.サーバ１００_２に問い合わせて下さい」と要求部２４に返信する（ステップＳ１２）。

そして、要求部２４は、jp.サーバ１００_２にexample.jp.サーバ１００_３のＤＳレコードを問い合わせ（ステップＳ１３）、jp.サーバ１００_２は、example.jp.サーバ１００_３のＤＳレコード及びＤＳレコードの署名を要求部２４に返信する（ステップＳ１４）。すなわち、jp.サーバ１００_２は、図４（Ｂ）に示すデータ３２ａ及びデータ３２ｂを返信する。

そして、要求部２４は、jp.サーバ１００_２にjp.サーバ１００_２のＤＮＳＫＥＹを問い合わせ（ステップＳ１５）、jp.サーバ１００_２は、自身のＤＮＳＫＥＹ及び署名を返信する（ステップＳ１６）。すなわち、jp.サーバ１００_２は、図４（Ｂ）に示すデータ３２ｃ及びデータ３２ｄと、データ３２ｅとを返信する。

そして、要求部２４は、ルートサーバ１００_１にjp.サーバ１００_２のＤＳレコードを問い合わせ（ステップＳ１７）、ルートサーバ１００_１は、jp.サーバ１００_２のＤＳレコード及びＤＳレコードの署名を返信する（ステップＳ１８）。すなわち、ルートサーバ１００_１は、図４（Ｃ）に示すデータ３１ａ及びデータ３１ｂを返信する。

そして、要求部２４は、ルートサーバ１００_１にルートサーバ１００_１のＤＮＳＫＥＹを問い合わせ（ステップＳ１９）、ルートサーバ１００_１は、自身のＤＮＳＫＥＹ及び署名を返信する（ステップＳ２０）。すなわち、ルートサーバ１００_１は、図４（Ｃ）に示すデータ３１ｃ及びデータ３１ｄと、データ３１ｅとを返信する。

そして、要求部２４は、各権威サーバからの一連の応答データをキャッシュ部２３に格納し（ステップＳ２１）、検証部２２にキャッシュ部２３が記憶する応答データの署名検証を依頼する（ステップＳ２２）。

そして、検証部２２は、検証処理を行う（ステップＳ２３）。具体的には、検証部２２は、データ３１ｄのハッシュ値とデータ２３ａのハッシュ値とを比較することにより、データ３１ｄの正当性を検証する。また、検証部２２は、データ３１ｃ及びデータ３１ｄのハッシュ値と、データ３１ｅをデータ３１ｄで復号した結果とを比較することにより、データ３１ｃ及びデータ３１ｄの正当性を検証する。また、検証部２２は、データ３１ａと、データ３１ｂをデータ３１ｃで復号した結果とを比較することにより、データ３１ａの正当性を検証する。

また、検証部２２は、データ３２ｄのハッシュ値とデータ３１ａとを比較することにより、データ３２ｄの正当性を検証する。すなわち、検証部２２は、ルートサーバ１００_１が保持するＤＳレコードを用いてＫＳＫ−Ｂ（公開鍵）の正当性を検証する。また、検証部２２は、データ３２ｃ及びデータ３２ｄのハッシュ値と、データ３２ｅをデータ３２ｄで復号した結果とを比較することにより、データ３２ｃ及びデータ３２ｄの正当性を検証する。さらに、検証部２２は、データ３２ａと、データ３２ｂをデータ３２ｃで復号した結果とを比較することにより、データ３２ａの正当性を検証する。

また、検証部２２は、データ３３ｄのハッシュ値とデータ３２ａとを比較することにより、データ３３ｄの正当性を検証する。すなわち、検証部２２は、jp.サーバ１００_２が保持するＤＳレコードを用いてＫＳＫ−Ｃ（公開鍵）の正当性を検証する。また、検証部２２は、データ３３ｃ及びデータ３３ｄのハッシュ値と、データ３３ｅをデータ３３ｄで復号した結果とを比較することにより、データ３３ｃ及びデータ３３ｄの正当性を検証する。さらに、検証部２２は、データ３３ａのハッシュ値と、データ３３ｂをデータ３３ｃで復号した結果とを比較することにより、データ３３ａの正当性を検証する。

そして、検証部２２は、全ての比較結果が一致する場合、権威サーバ群１００からの応答データが正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部２１は、クライアント装置１０に対して、データ３３ａを返信する。一方、検証部２２は、全ての比較結果が一致しない場合、権威サーバ群１００からの応答データが不当であり、署名検証が失敗したと判定する。

なお、図５に示した例において、ルートサーバ１００_１、jp.サーバ１００_２及びexamp le.jp.サーバ１００_３は、Ａレコードや各電子署名やＤＮＳＫＥＹ等の各種応答データをキャッシュサーバ２０に送信する際にＴＴＬを設定する。これにより、キャッシュサーバ２０は、ＴＴＬに設定されている時間が経過するまで各種応答データをキャッシュすることとなる。

ところで、上述してきた各権威サーバが保持する署名鍵であるＺＳＫやＫＳＫは、定期的に更新されることが望ましい。しかし、キャッシュサーバ２０は、ＴＴＬ時間が経過するまで各権威サーバから取得した署名鍵等をキャッシュ部２３に保持する。このため、各権威サーバの署名鍵が更新された場合であっても、更新後の署名鍵がキャッシュサーバ２０に即座に反映されないと考えられる。

そこで、実施例１に係る権威サーバ群１００は、権威サーバの管理者や運用者等によって署名鍵が更新された場合に、古い署名鍵の有効期限に応じてＴＴＬの設定値を変動させることにより、更新後の署名鍵がキャッシュサーバ２０に即座に反映されることを可能にする。この点について、図６を用いて簡単に説明する。図６は、実施例１に係る名前解決システム１による鍵更新処理の一例を示す図である。ここでは、権威サーバ１００_１、キャッシュサーバ２０ａ及び２０ｂを例に挙げて、実施例１に係る名前解決システム１による鍵更新処理について説明する。なお、キャッシュサーバ２０ａ及び２０ｂは、図２に例示したキャッシュサーバ２０に対応する。また、以下では、権威サーバ１００_１によって設定されるＴＴＬの通常値（デフォルト値）は、「８６４００［秒］＝２４時間（１日）」であるものとする。

まず、権威サーバの管理者や運用者等が、新しい署名鍵を権威サーバ１００_１に登録したものとする。このとき、権威サーバの管理者や運用者等は、古い署名鍵を削除することなく新しい署名鍵を登録し、さらに、古い署名鍵から新しい署名鍵に更新される鍵更新日時を設定する。例えば、権威サーバの管理者や運用者等は、新しい署名鍵が有効となる開始日時等を設定する。

このような状況において、図６に示した例のように、キャッシュサーバ２０ａが権威サーバ１００_１に対して名前解決に関する問い合わせを行ったものとする（ステップＳ３１）。この名前解決に関する問い合わせとは、図５に示したステップＳ３、Ｓ１７、Ｓ１９等における各種問い合わせであって、権威サーバ１００_１から名前解決の結果や署名鍵等の取得要求に該当する。このとき、実施例１に係る権威サーバ１００_１は、問い合わせを受け付けた日時から鍵更新日時までの時間を算出し、算出した時間がＴＴＬの通常値「８６４００」以上であるか否かを判定する。ここでは、算出した時間がＴＴＬの通常値「８６４００」以上であるものとする。かかる場合に、権威サーバ１００_１は、ステップＳ３１において受け付けた問い合わせに対応する応答データのＴＴＬに「８６４００」を設定し、かかる応答データをキャッシュサーバ２０ａに送信する（ステップＳ３２）。この送信処理は、図５に示したステップＳ１８、Ｓ２０等に該当する。これにより、キャッシュサーバ２０ａは、ＴＴＬ時間である「８６４００［秒］」が経過するまでは権威サーバ１００_１から受け付けた応答データをキャッシュ部２３に保持する。

同様に、キャッシュサーバ２０ｂが、鍵更新日時の１日以上前に、権威サーバ１００_１に対して名前解決に関する問い合わせを行ったものとする（ステップＳ３３）。この場合においても、権威サーバ１００_１は、応答データのＴＴＬを「８６４００」に設定し、かかる応答データをキャッシュサーバ２０ｂに送信する（ステップＳ３４）。これにより、キャッシュサーバ２０ｂは、ＴＴＬ時間である「８６４００［秒］」が経過するまでは応答データをキャッシュ部２３に保持する。

続いて、図６に示した例のように、キャッシュサーバ２０ａが、鍵更新日時の１時間前に、権威サーバ１００_１に対して名前解決に関する問い合わせを行ったものとする（ステップＳ３５）。かかる場合に、実施例１に係る権威サーバ１００_１は、問い合わせを受け付けた日時から鍵更新日時までの時間「３６００［秒］＝１時間」を算出し、算出した時間「３６００」がＴＴＬの通常値「８６４００」以上であるか否かを判定する。ここでは、算出した時間「３６００」がＴＴＬの通常値「８６４００」よりも小さいので、権威サーバ１００_１は、応答データのＴＴＬに「３６００」を設定し、かかる応答データをキャッシュサーバ２０ａに送信する（ステップＳ３６）。これにより、キャッシュサーバ２０ａは、ＴＴＬ時間である「３６００［秒］」が経過するまでは応答データをキャッシュ部２３に保持する。

すなわち、キャッシュサーバ２０ａは、ＴＴＬ時間「３６００［秒］」が経過した後に、クライアント装置１０から名前解決の問い合わせを受け付けた場合には、キャッシュ部２３から署名鍵等の応答データが削除されているので、権威サーバ１００_１に対して名前解決に関する問い合わせを行う（ステップＳ３７）。言い換えれば、キャッシュサーバ２０ａは、ＴＴＬに「３６００［秒］」が設定されていることにより、権威サーバ１００_１において署名鍵が更新された後にクライアント装置１０から名前解決の問い合わせを受け付けた場合には、権威サーバ１００_１から新しい署名鍵を取得して署名検証を行うこととなる。このため、権威サーバ１００_１は、署名鍵が更新された後には、更新後の新しい署名鍵をキャッシュサーバ２０ａに用いさせることができるので、キャッシュサーバ２０ａにおける署名鍵を短期間で更新することができる。

なお、ステップＳ３７において問い合わせを受け付けた権威サーバ１００_１は、問い合わせを受け付けた日時から鍵更新日時までの時間を算出し、算出した時間がＴＴＬの通常値以上であるか否かを判定する。ここでは、算出した時間がＴＴＬの通常値以上であるものとする。すなわち、権威サーバ１００_１は、応答データのＴＴＬに「８６４００」を設定し、かかる応答データをキャッシュサーバ２０ａに送信する（ステップＳ３８）。

続いて、図６に示した例のように、キャッシュサーバ２０ｂが、鍵更新日時の２０分前に、権威サーバ１００_１に対して名前解決に関する問い合わせを行ったものとする（ステップＳ３９）。かかる場合に、実施例１に係る権威サーバ１００_１は、問い合わせを受け付けた日時から鍵更新日時までの時間「１２００［秒］＝２０分」を算出し、算出した時間「１２００」を応答データのＴＴＬに設定し、かかる応答データをキャッシュサーバ２０ｂに送信する（ステップＳ４０）。これにより、キャッシュサーバ２０ｂは、ＴＴＬ時間である「１２００［秒］」が経過するまでは応答データをキャッシュ部２３に保持する。

すなわち、キャッシュサーバ２０ｂは、ＴＴＬ時間「１２００［秒］」が経過した後に、クライアント装置１０から名前解決の問い合わせを受け付けた場合には、キャッシュ部２３から署名鍵が削除されているので、権威サーバ１００_１に対して名前解決に関する問い合わせを行う（ステップＳ４１）。これにより、キャッシュサーバ２０ｂは、権威サーバ１００_１において署名鍵が更新された後には、更新後の新しい署名鍵を用いて署名検証を行うことができる。

なお、ここの例では、権威サーバ１００_１によって問い合わせを受け付けられた日時から鍵更新日時までの時間がＴＴＬの通常値「８６４００」以上であるものとする。すなわち、権威サーバ１００_１は、応答データのＴＴＬに「８６４００」を設定し、かかる応答データをキャッシュサーバ２０ｂに送信する（ステップＳ４２）。

このように、実施例１に係る名前解決システム１では、権威サーバ１００_１が鍵更新日時までの時間をＴＴＬに設定するので、更新後の署名鍵をキャッシュサーバ２０に即座に反映することができる。

なお、図６に示した例では、権威サーバ１００_１とキャッシュサーバ２０との間における処理の一例について説明したが、実施例１に係る権威サーバ１００_２や権威サーバ１００_３についてもキャッシュサーバ２０との間で図６に例示した処理と同様の処理を行うことができる。以下に、このような権威サーバ１００_１、１００_２及び１００_３の構成について説明する。なお、実施例に係る権威サーバ１００_１、１００_２及び１００_３の構成のうち、図６に例示した処理を実現するための構成については同様である。したがって、以下では、権威サーバ１００_１を例に挙げて説明する。

図７を用いて、権威サーバ１００_１の構成について説明する。図７は、実施例１における権威サーバ１００_１の構成例を示す図である。図７に例示するように、実施例１における権威サーバ１００_１は、ＩＦ（interface）部１１０と、記憶部１２０と、管理部１３０と、問合せ処理部１４０とを有する。なお、図７では図示することを省略したが、権威サーバ１００_１は、各種情報や操作指示を入力するための入力部（キーボード、マウス等）や、各種情報を表示する表示デバイス（液晶表示装置等）を有してもよい。

ＩＦ部１１０は、キャッシュサーバ２０等の外部装置との間で各種データを送受信するＮＩＣ（Network Interface Card）等である。例えば、ＩＦ部１１０は、キャッシュサーバ２０から名前解決のための依頼等を受信する。また、例えば、ＩＦ部１１０は、名前解決のための依頼に対応する応答をキャッシュサーバ２０に送信する。

記憶部１２０は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置であり、図４に例示した各種情報を記憶する。例えば、権威サーバ１００_１の記憶部１２０は、図４に例示したデータ３１ａ、３１ｂ、３１ｃ、３１ｄ及び３１ｅ等を記憶する。また、記憶部１２０は、権威サーバの管理者や運用者等によって登録される新しい署名鍵を記憶する。

管理部１３０は、署名鍵が新たな署名鍵に更新される日時である有効期限を管理する。具体的には、記憶部１２０に記憶されている署名鍵（ＫＳＫやＺＳＫ）には有効期限が設定されている。このため、管理部１３０は、記憶部１２０に記憶されている古い署名鍵や新しい署名鍵に設定されている有効期限を参照することにより、古い署名鍵が新しい署名鍵に更新される鍵更新日時を取得する。

問合せ処理部１４０は、キャッシュサーバ２０から送信される名前解決に関する問い合わせに対して各種応答処理を行う。具体的には、問合せ処理部１４０は、図５に示したステップＳ４、Ｓ１２、Ｓ１８及びＳ２０等における処理を行う。このような問合せ処理部１４０は、図７に例示するように、受付部１４１と、設定部１４２と、送信部１４３とを有する。

受付部１４１は、キャッシュサーバ２０から名前解決に関する各種問い合わせを受け付ける。具体的には、実施例１における受付部１４１は、名前解決に関する各種問い合わせとして、名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバ２０から受け付ける。例えば、受付部１４１は、図５に示したステップＳ３、Ｓ１１、Ｓ１７及びＳ１９等における複数種類の取得要求を受け付ける。

設定部１４２は、受付部１４１によって受け付けられた取得要求に対応する応答データに対して、署名鍵が新たな署名鍵に更新される鍵更新日時までの期間である有効期間を、キャッシュサーバ２０にキャッシュされる応答データのキャッシュ期間（ＴＴＬ）として設定する。具体的には、設定部１４２は、受付部１４１によって各種取得要求が受け付けられた場合に、取得要求を受け付けた日時から管理部１３０によって管理されている鍵更新日時までの時間である有効期間を算出する。そして、設定部１４２は、算出した有効期間がＴＴＬの通常値（上記例では「８６４００」）以上であるか否かを判定する。そして、設定部１４２は、有効期間が通常値以上である場合には、応答データのＴＴＬに通常値を設定し、有効期間が通常値よりも小さい場合には、応答データのＴＴＬに有効期間を設定する。

送信部１４３は、受付部１４１によって各種取得要求が受け付けられた場合に、設定部１４２によってＴＴＬが設定された応答データをキャッシュサーバ２０に送信する。

なお、上記の管理部１３０及び問合せ処理部１４０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、図示しない記憶装置に記憶されているプログラムがＲＡＭ（Random Access Memory）を作業領域として実行されることにより実現される。また、例えば、管理部１３０及び問合せ処理部１４０は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

次に、図８を用いて、実施例１に係る権威サーバ１００_１による処理の手順について説明する。図８は、実施例１に係る権威サーバ１００_１による処理手順を示すフローチャートである。

図８に示すように、権威サーバ１００_１の受付部１４１は、キャッシュサーバ２０から名前解決に関する各種取得要求を受け付けたか否かを判定する（ステップＳ１０１）。そして、受付部１４１は、キャッシュサーバ２０から各種取得要求を受け付けない場合には（ステップＳ１０１否定）、キャッシュサーバ２０から取得要求を受け付けるまで待機する。

一方、受付部１４１によってキャッシュサーバ２０から取得要求が受け付けられた場合には（ステップＳ１０１肯定）、設定部１４２は、かかる取得要求を受け付けた日時から鍵更新日時までの時間である有効期間を算出し（ステップＳ１０２）、算出した有効期間がＴＴＬの通常値以上であるか否かを判定する（ステップＳ１０３）。

そして、設定部１４２は、有効期間が通常値以上である場合には（ステップＳ１０３肯定）、応答データのＴＴＬに通常値を設定し（ステップＳ１０４）、有効期間が通常値よりも小さい場合には（ステップＳ１０３否定）、応答データのＴＴＬにかかる有効期間を設定する（ステップＳ１０５）。そして、送信部１４３は、設定部１４２によってＴＴＬが設定された応答データをキャッシュサーバ２０に送信する（ステップＳ１０６）。

上述してきたように、実施例１に係る権威サーバ群１００は、名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバ２０から受け付ける受付部１４１と、受付部１４１によって受け付けられた取得要求に対応する応答データに対して、署名鍵が新たな署名鍵に更新されるまでの期間である有効期間をＴＴＬとして設定する設定部１４２と、設定部１４２によってＴＴＬが設定された応答データをキャッシュサーバ２０に送信する送信部１４３とを有する。

これにより、実施例１に係る権威サーバ群１００は、署名鍵が更新されるタイミングと略同一のタイミングで、キャッシュサーバ２０におけるキャッシュ部２３から署名鍵等を削除させることができる。この結果、権威サーバ群１００は、署名鍵が更新された後には、更新後の新しい署名鍵をキャッシュサーバ２０に用いさせることができるので、キャッシュサーバ２０における署名鍵を短期間で更新することができる。

また、実施例１に係る権威サーバ群１００において、設定部１４２は、署名鍵の有効期間が通常値以上である場合には、かかる通常値を応答データのＴＴＬに設定し、署名鍵の有効期間が通常値よりも小さい場合には、かかる有効期間を応答データのＴＴＬに設定する。これにより、実施例１に係る権威サーバ群１００は、署名鍵の更新タイミングまで長期間ある場合には、キャッシュサーバ２０におけるキャッシュ部２３から署名鍵等が短期間で削除されることを防止でき、署名鍵の更新タイミングが近づいてきた場合には、キャッシュサーバ２０におけるキャッシュ部２３から署名鍵等を通常時よりも短期間で削除させることで、キャッシュサーバ２０における署名鍵を短期間で更新することができる。

また、実施例１に係る権威サーバ群１００において、設定部１４２は、署名鍵が新たな署名鍵に更新される日時と、受付部１４１によって取得要求が受け付けられた日時との差分を有効期間として算出する。これにより、実施例１に係る権威サーバ群１００は、署名鍵の更新タイミングと、キャッシュサーバ２０におけるキャッシュ部２３から署名鍵等を削除させるタイミングとを一致させることができる。

ここで、従来の名前解決システムと比較して、実施例１に係る権威サーバ群１００における効果の一例を説明する。例えば、従来の名前解決システムにおいて権威サーバが保持するＺＳＫやＫＳＫ等の署名鍵を更新する場合や、署名鍵の更新に伴って電子署名を更新する場合には、権威サーバの管理者や運用者等は、古い署名鍵や古い電子署名を削除することなく新しい署名鍵や古い電子署名を権威サーバに追加する。例えば、権威サーバの管理者や運用者等が権威サーバに新しい署名鍵を追加したものとする。この段階では、権威サーバは、新しい署名鍵を保持しているだけであって、かかる新しい署名鍵と対になる電子署名を保持していないので、古い署名鍵を用いて署名を実施する。この例では、権威サーバは、まず新しい署名鍵をキャッシュサーバに保持させてから、新しい署名鍵と対になる電子署名を検証させられる状態をつくるからである。そして、キャッシュサーバは、ＴＴＬ時間が経過したキャッシュが削除され、クライアント装置から問い合わせがあった場合に、権威サーバから署名鍵を取得する。ここでは、権威サーバに古い署名鍵と新しい署名鍵の双方が登録されているので、キャッシュサーバは、権威サーバから古い署名鍵と新しい署名鍵との双方を取得する。その後、権威サーバは、十分に時間が経過して古い署名鍵と新しい署名鍵の双方がキャッシュサーバに伝播した場合に、新しい署名鍵を用いて署名を実施する。ただし、この段階では、キャッシュサーバは、権威サーバから古い署名鍵と新しい署名鍵の双方を取得した際の各種データがキャッシュされているので、権威サーバから新しい署名鍵に対応する署名を取得しない。そして、キャッシュサーバは、ＴＴＬ時間が経過したキャッシュが削除され、クライアント装置から問い合わせがあった場合に、権威サーバから署名鍵等を取得する。この後に、権威サーバの管理者や運用者等は、権威サーバから古い署名鍵や古い電子署名を削除することが可能となる。このように、従来の名前解決システムにおいては、権威サーバの署名鍵を更新する場合には、ＴＴＬ時間が経過するまで待機するステップが複数存在するので、キャッシュサーバにおける署名鍵を短期間で更新することができない。

一方で、実施例１に係る権威サーバ群１００においては、権威サーバ群１００の署名鍵が更新されるタイミングと略同一のタイミングで、キャッシュサーバ２０におけるキャッシュ部２３から署名鍵等を削除させることができるので、キャッシュサーバ２０における署名鍵を短期間で更新することができる。

上述した名前解決システム１は、上記実施例以外にも種々の異なる形態にて実施されてよい。そこで、実施例２では、上記の名前解決システム１の他の実施例について説明する。

［ＴＴＬの設定値］
上記実施例１では、設定部１４２が、新たな署名鍵に更新されるまでの署名鍵の有効期間がＴＴＬの通常値よりも小さい場合には、かかる有効期間を応答データのＴＴＬとして設定する例を示した。しかし、設定部１４２は、有効期間と同一の期間をＴＴＬに設定しなくてもよい。具体的には、設定部１４２は、通常値よりも短く、かつ、有効期間よりも所定期間だけ長い期間をＴＴＬとして設定してもよい。例えば、署名鍵が新たな署名鍵に更新されるまでの有効期間が「１２００［秒］」であるものとする。かかる場合に、設定部１４２は、有効期間「１２００」より大きく、かつ、通常値「８６４００」よりも小さい値（例えば、「１２０１」、「１８００」、「３６００」等）をＴＴＬに設定してもよい。

［キャッシュサーバに応じたＴＴＬの設定］
また、権威サーバに複数のキャッシュサーバが接続されており、かかる権威サーバの受付部１４１によって複数のキャッシュサーバから各種取得要求が受け付けられる場合には、設定部１４２は、キャッシュサーバに応じて異なるＴＴＬを応答データに設定してもよい。例えば、署名鍵の有効期間が「１２００」であるものとする。かかる場合に、設定部１４２は、例えば、キャッシュサーバ２０ａに送信する応答データに対しては有効期間「１２００」をＴＴＬに設定し、キャッシュサーバ２０ｂに送信する応答データに対しては「１８００」をＴＴＬに設定し、キャッシュサーバ２０ｃに送信する応答データに対しては「３６００」をＴＴＬに設定してもよい。これにより、キャッシュサーバによってキャッシュ部２３から各種情報が削除されるタイミングが異なるので、各キャッシュサーバから権威サーバ群１００に名前解決のための問い合わせが行われるタイミングもキャッシュサーバによって変動する。これにより、権威サーバ群１００による名前解決のための処理にかかる負荷を分散することができる。

また、設定部１４２は、署名鍵の有効期間がＴＴＬの通常値よりも小さい場合に、特定のキャッシュサーバに送信する応答データに対してのみ、有効期間をＴＴＬに設定してもよい。例えば、署名鍵の更新を短期間で更新することが望まれている特定のキャッシュサーバが予め決められている場合等に、設定部１４２は、かかる特定のキャッシュサーバに送信する応答データに対してのみ、有効期間をＴＴＬに設定してもよい。

［有効期間の算出］
また、上記実施例１では、設定部１４２が、受付部１４１によって各種取得要求が受け付けられた場合に、管理部１３０によって管理されている鍵更新日時と、受付部１４１によって取得要求が受け付けられた日時との差分を署名鍵の有効期間として算出する例を示した。しかし、設定部１４２は、他の手法によって署名鍵の有効期間を算出してもよい。例えば、設定部１４２は、管理部１３０によって管理されている鍵更新日時と、現在日時との差分を署名鍵の有効期間として算出してもよい。

［システム構成］
また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図３、図４に示した各種情報は一例であって任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図７に例示した管理部１３０と設定部１４２とは統合されてもよい。

［プログラム］
また、上記実施例において説明した各権威サーバ（権威サーバ１００_１、１００_２及び１００_３）が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例１に係る権威サーバが実行する処理をコンピュータが実行可能な言語で記述した鍵更新プログラムを作成することもできる。この場合、コンピュータが鍵更新プログラムを実行することにより、上記実施例１と同様の効果を得ることができる。さらに、かかる鍵更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された鍵更新プログラムをコンピュータに読み込ませて実行することにより上記実施例１と同様の処理を実現してもよい。以下に、図７に示した権威サーバと同様の機能を実現する鍵更新プログラムを実行するコンピュータの一例を説明する。

図９は、鍵更新プログラムを実行するコンピュータ１０００を示す図である。図９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図９に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図９に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図９に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図９に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図９に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の鍵更新プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。例えば、図７に例示した管理部１３０と同様の情報処理を実行する管理手順と、問合せ処理部１４０と同様の情報処理を実行する問合せ処理手順と、受付部１４１と同様の情報処理を実行する受付手順と、設定部１４２と同様の情報処理を実行する設定手順と、送信部１４３と同様の情報処理を実行する送信手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、上記実施例で説明した記憶部１２０が保持する各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、管理手順、問合せ処理手順、受付手順、設定手順、送信手順を実行する。

なお、鍵更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、鍵更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１ 名前解決システム
１０ クライアント装置
２０ キャッシュサーバ
２１ 応答部
２２ 検証部
２３ キャッシュ部
２４ 要求部
１００ 権威サーバ群
１２０ 記憶部
１３０ 管理部
１４０ 問合せ処理部
１４１ 受付部
１４２ 設定部
１４３ 送信部

Claims (8)

1. 名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、
   前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第１所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、
   前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部と
   を備えたことを特徴とする権威サーバ。
2. 前記設定部は、
   前記有効期間が第２所定期間以上である場合には、当該第２所定期間を前記キャッシュ期間として前記応答データに設定し、前記有効期間が前記第２所定期間よりも小さい場合には、当該有効期間又は当該有効期間より第１所定期間長い期間を前記キャッシュ期間として前記応答データに設定する
   ことを特徴とする請求項１に記載の権威サーバ。
3. 前記設定部は、
   前記署名鍵が更新される日時と、前記受付部によって取得要求が受け付けられた日時との差分を前記有効期間として算出する
   ことを特徴とする請求項１又は２に記載の権威サーバ。
4. 前記設定部は、
   前記署名鍵が更新される日時と、現在日時との差分を前記有効期間として算出する
   ことを特徴とする請求項１又は２に記載の権威サーバ。
5. 前記設定部は、
   前記受付部によって複数のキャッシュサーバから前記取得要求が受け付けられる場合には、当該複数のキャッシュサーバのそれぞれに応じて互いに異なるキャッシュ期間を前記応答データに設定する
   ことを特徴とする請求項１〜４のいずれか一つに記載の権威サーバ。
6. 権威サーバとキャッシュサーバとを含む名前解決システムであって、
   前記権威サーバは、
   名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、
   前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第１所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、
   前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部と
   を備えたことを特徴とする名前解決システム。
7. 権威サーバが実行する鍵更新方法であって、
   名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付工程と、
   前記受付工程によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第１所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定工程と、
   前記設定工程によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信工程と
   を含んだことを特徴とする鍵更新方法。
8. 名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付手順と、
   前記受付手順によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第１所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定手順と、
   前記設定手順によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信手順と
   をコンピュータに実行させることを特徴とする鍵更新プログラム。

Images