説明

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

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

【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムに関する。
【背景技術】
【0002】
従来、ドメイン名とIPアドレス(Internet Protocol Address)とを対応させる名前管理システム(DNS:Domain Name System)が知られている。DNSは、一般的には、権威サーバ群とキャッシュサーバとから構成される。各権威サーバは、階層的な木構造を有する名前空間(「ドメイン名前空間」等とも呼ばれる)の中にある特定のゾーンを管理する。キャッシュサーバは、クライアント装置からの名前解決の依頼に応じて、権威サーバ群に問い合わせを行うとともに、権威サーバ群からの応答データをキャッシュする。
【0003】
また、近年、DNSの拡張仕様として、権威サーバ群からの応答データの正当性を保証するDNSSEC(DNS Security Extensions)の普及が進められている。DNSSECにおいては、権威サーバ群からの応答データの正当性を保証するために、電子署名を用いた検証(署名検証)が行われ、最上位のルートゾーンを管理する権威サーバによって保持される署名鍵を基点として「信頼の連鎖」が構築される。
【0004】
この「信頼の連鎖」について具体的に説明すると、階層的な木構造を有する名前空間上の特定のゾーンを管理する各権威サーバには、互いに上位権威サーバと下位権威サーバとの関係がある。例えば、所定の権威サーバは、かかる所定の権威サーバ自身が管理するゾーンの下位ゾーンを管理する下位権威サーバにとっての上位権威サーバとなり、かかる所定の権威サーバ自身が管理するゾーンの上位ゾーンを管理する上位権威サーバにとっての下位権威サーバとなる。このような各権威サーバは、例えばDNSSECのDS(Delegation Signer)方式が適用されている場合には、A(Address)レコード等の一般的なDNSレコード等に署名を行うためのZSK(Zone Signing Key)を保持するとともに、ZSK等のDNSKEYに署名を行うためのKSK(Key Signing Key)を保持する。なお、上位権威サーバは、下位権威サーバが保持するKSK(公開鍵)のハッシュ値をDSレコードとして保持し、かかるDSレコードについてもZSKを用いて署名を行う。
【0005】
キャッシュサーバは、このような権威サーバ群に対して名前解決を依頼した場合に、ルートゾーンを管理する最上位の権威サーバであるルートサーバによって提供されるKSK(公開鍵)を用いて、ルートサーバが保持するZSK(公開鍵)の署名検証を行う。さらに、キャッシュサーバは、検証済みのZSK(公開鍵)を用いて、ルートサーバに登録されているDSレコード(ルートサーバの下位に位置する下位権威サーバが保持するKSK(公開鍵)のハッシュ値)の署名検証を行う。そして、キャッシュサーバは、検証済みのDSレコードを用いて、下位権威サーバが保持するKSK(公開鍵)の署名検証を行い、署名検証済みのKSK(公開鍵)を用いて、かかる下位権威サーバが保持するZSK(公開鍵)等の署名検証を行う。このようにして、キャッシュサーバは、上位権威サーバに登録されているDSレコードを用いて、下位権威サーバが保持する署名鍵であるKSKの署名検証を順次行う。そして、キャッシュサーバは、名前解決の依頼に対応する応答データを送信した下位権威サーバが保持するZSK(公開鍵)等の署名検証を行い、署名検証済みのZSK(公開鍵)を用いて、応答データの署名検証を行う。これにより、キャッシュサーバは、正当性が保証されたIPアドレスなどの応答データをクライアント装置に送信することが可能となる。このように、DNSSECのDS方式では、最上位のルートサーバが保持する署名鍵が信頼できるという前提の下、かかる署名鍵を基点として「信頼の連鎖」が構築される。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】民田雅人、他著 「実践DNS DNSSEC時代のDNSの設定を運用」ASCII
【発明の概要】
【発明が解決しようとする課題】
【0007】
ところで、上記の従来技術において、権威サーバの管理者や運用者等は、署名鍵であるZSKやKSKを定期的に更新することが望ましい。これは、署名鍵が盗難するおそれや第三者によって署名鍵が解読されるおそれ等があるからである。
【0008】
しかしながら、上記の従来技術では、権威サーバの管理者や運用者等が署名鍵を更新した場合であっても、かかる署名鍵がキャッシュサーバに即座に反映されることはない。具体的には、各権威サーバは、署名鍵(DNSKEYレコード)をキャッシュサーバに提供する際に、キャッシュサーバが署名鍵を保持する期間を示すTTL(Time To Live)を設定する。このため、キャッシュサーバは、TTL時間が経過しない限りは、たとえ権威サーバの署名鍵が更新された場合であっても、キャッシュ済みの古い署名鍵を用いることとなる。
【0009】
例えば、非特許文献1に開示されているように、事前公開法や二重署名法等の署名鍵更新方法を行った場合、上述した信頼の連鎖が途切れないことを担保するためには、更新後の署名鍵がキャッシュサーバに反映されるまでに、TTL(Time To Live)時間が経過してキャッシュサーバのキャッシュから古い署名鍵等が削除されるまでの時間を要する。このような古い署名鍵がキャッシュサーバにおいて使用され続けることは、セキュリティの観点から好ましくないといえる。
【0010】
本願の開示する技術は、上記に鑑みてなされたものであって、キャッシュサーバにおける署名鍵を短期間で更新することができる権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムを提供することを目的とする。
【課題を解決するための手段】
【0011】
実施形態に係る権威サーバは、名前解決の結果の取得要求、又は、当該名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバから受け付ける受付部と、前記受付部によって受け付けられた取得要求に対応する応答データに対して、前記署名鍵が更新されるまでの期間である有効期間又は当該有効期間より第1所定期間長い期間を、前記キャッシュサーバにキャッシュされる当該応答データのキャッシュ期間として設定する設定部と、前記設定部によってキャッシュ期間が設定された応答データを前記キャッシュサーバに送信する送信部とを備えることを特徴とする。
【発明の効果】
【0012】
実施形態に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムは、キャッシュサーバにおける署名鍵を短期間で更新することができるという効果を奏する。
【図面の簡単な説明】
【0013】
【図1】図1は、実施例1に係る名前解決システムの構成例を示す図である。
【図2】図2は、実施例1に係る名前解決システムが有するキャッシュサーバの構成例を示す図である。
【図3】図3は、権威サーバ群に含まれる権威サーバの一例を示す図である。
【図4】図4は、DNSSECに用いられる各種データの一例を示す図である。
【図5】図5は、実施例1に係る名前解決システムが実行する署名検証処理の一例を示すシーケンス図である。
【図6】図6は、実施例1に係る名前解決システムによる鍵更新処理の一例を示す図である。
【図7】図7は、実施例1における権威サーバの構成例を示す図である。
【図8】図8は、実施例1に係る権威サーバによる処理手順を示すフローチャートである。
【図9】図9は、鍵更新プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【0014】
以下に、本願に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願に係る権威サーバ、名前解決システム、鍵更新方法及び鍵更新プログラムが限定されるものではない。
【実施例1】
【0015】
まず、図1を用いて、実施例1に係る名前解決システムについて説明する。図1は、実施例1に係る名前解決システムの構成例を示す図である。図1に示す名前解決システム1は、クライアント装置10、キャッシュサーバ20、権威サーバ群100を有する。ここで、図1に示す各装置は、インターネットを介して通信可能な状態で接続される。
【0016】
クライアント装置10は、例えば、PC(Personal Computer)、携帯電話機、PDA(Personal Digital Assistant)等であり、キャッシュサーバ20に対して、名前解決の依頼を送信する。具体的には、クライアント装置10は、キャッシュサーバ20に対して、ホスト名を通知することでIPアドレスの検索を要求したり、その逆にIPアドレスを通知することでホスト名の検索を要求したりする。このようなクライアント装置10で動作するプログラムは「リゾルバ」と呼ばれる。なお、図1では、キャッシュサーバ20に接続されるクライアント装置10を一台のみ示しているが、実際には、キャッシュサーバ20には複数台のクライアント装置が接続される。
【0017】
キャッシュサーバ20は、クライアント装置10から所定のドメイン名(例えば、「www.example.jp」)の名前解決の依頼を受け付ける。そして、キャッシュサーバ20は、権威サーバ群100に、依頼されたドメイン名の名前解決のための問い合わせを行うとともに、権威サーバ群100からの応答データをキャッシュする機能を有する。
【0018】
権威サーバ群100は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。図1に示した例では、権威サーバ群100には、権威サーバ100、100及び100が含まれる。なお、図1では、権威サーバ群100に3台の権威サーバが含まれる例を示したが、権威サーバ群100には、2台以下の権威サーバや4台以上の権威サーバが含まれてもよい。
【0019】
ここで、図2〜図5を用いて、キャッシュサーバ20と権威サーバ群100とにより実行されるDNSSECの処理の一例を説明する。その後に、図6〜図8を用いて、実施例1に係る権威サーバ群100について説明する。
【0020】
図2は、実施例1に係る名前解決システム1が有するキャッシュサーバ20の構成例を示す図である。図2に例示するように、実施例1におけるキャッシュサーバ20は、応答部21と、検証部22と、キャッシュ部23と、要求部24とを有する。
【0021】
応答部21は、クライアント装置10との間で通信を行う。要求部24は、権威サーバ群100との間で通信を行う。また、要求部24は、権威サーバ群100から受信した応答データをキャッシュ部23に格納する。検証部22は、キャッシュ部23に格納された権威サーバ群100からの応答データを用いて署名検証を行う。キャッシュ部23は、署名検証に成功した応答データをキャッシュする。具体的には、キャッシュ部23は、署名検証に成功した場合、名前解決を依頼されたドメイン名とドメイン名のIPアドレスとを対応付けた情報、署名鍵としてのDSレコードやDNSKEYレコード等をキャッシュする。
【0022】
ここで、応答部21は、クライアント装置10から名前解決を依頼された場合、依頼されたドメイン名のIPアドレスが、キャッシュ部23にキャッシュ情報として既に格納されているか否かを判定する。応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として既に格納されている場合、クライアント装置10に対してIPアドレスを返信する。
【0023】
一方、応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部24に転送する。そして、要求部24は、依頼内容に基づいて、権威サーバ群100に問い合わせを行う。
【0024】
ここで、図3〜図5を用いて、キャッシュサーバ20が、クライアント装置10からキャッシュ情報として格納されていない「www.example.jp」の名前解決の依頼を受け付けた場合に、権威サーバ群100に対して「www.example.jp」に関する問い合わせを行う例について説明する。図3は、権威サーバ群100に含まれる権威サーバの一例を示す図である。なお、以下では、クライアント装置10がIPv4(Internet Protocol version 4)アドレスを要求している場合について説明する。
【0025】
図3に示した例のように、キャッシュサーバ20は、「www.example.jp」の名前解決を行う場合に、権威サーバ100(ここでは「ルートサーバ100」であるものとする)、権威サーバ100(ここでは「jp.サーバ100」であるものとする)、権威サーバ100(ここでは「example.jp.サーバ100」であるものとする)に対して問い合わせを行う。
【0026】
ルートサーバ100は、階層的な木構造を有する名前空間のうち最上位ゾーンであるルートゾーンを管理するサーバであり、例えば「jp」や「com」等のドメイン名(TLD:Top Level Domain)を管理するサーバのインターネット上の位置(IPアドレス)を管理する。また、jp.サーバ100は、「jp」のTLDサーバであり、「jp」で管理される「example.jp」や「ad.jp」などのインターネット上の位置(IPアドレス)を管理する。また、example.jp.サーバ100は、example.jp.サーバ100自身が管理する名前空間の中にあるホスト、例えば、「www.example.jp」や「ftp.example.jp」のインターネット上の位置(IPアドレス)を管理する。なお、上位権威サーバは、上位権威サーバ自身が管理するゾーンの下位ゾーンを管理する下位権威サーバのドメイン名をNS(Name Server)レコードとして保持し、かかる下位権威サーバのIPアドレスをAレコード又はAAAAレコード(クワッドAレコード)として保持する。例えば、jp.サーバ100は、下位権威サーバであるexample.jp.サーバ100のNSレコードやAレコード等を保持する。
【0027】
これらのルートサーバ100、jp.サーバ100及びexample.jp.サーバ100は、DNSSECが有効化されており、ZSK及びKSKを保持する。図3に示した例では、ルートサーバ100は、ZSKとして「ZSK−A(公開鍵)及びZSK−A(秘密鍵)」を保持し、KSKとして「KSK−A(公開鍵)及びKSK−A(秘密鍵)」を保持する。また、jp.サーバ100は、ZSKとして「ZSK−B(公開鍵)及びZSK−B(秘密鍵)」を保持し、KSKとして「KSK−B(公開鍵)及びKSK−B(秘密鍵)」を保持する。また、example.jp.サーバ100は、ZSKとして「ZSK−C(公開鍵)及びZSK−C(秘密鍵)」を保持し、KSKとして「KSK−C(公開鍵)及びKSK−C(秘密鍵)」を保持する。
【0028】
なお、図3に示した例では、ルートサーバ100、jp.サーバ100及びexample.jp.サーバ100が、ZSK(秘密鍵)及びKSK(秘密鍵)を保持する例を示した。しかし、実際には、ルートサーバ100、jp.サーバ100及びexample.jp.サーバ100は、ZSK(秘密鍵)及びKSK(秘密鍵)については自装置内に保持しない。これらのZSK(秘密鍵)及びKSK(秘密鍵)は、ルートサーバ100、jp.サーバ100及びexample.jp.サーバ100がアクセスできるが一般ユーザからアクセスできない別装置によって管理される。そして、ルートサーバ100、jp.サーバ100及びexample.jp.サーバ100は、この別装置によってZSK(秘密鍵)及びKSK(秘密鍵)を用いて生成された電子署名をかかる別装置から受け取り、受け取った電子署名を保持する。ただし、このような別装置が存在しないシステムの場合には、ルートサーバ100、jp.サーバ100及びexample.jp.サーバ100は、ZSK(秘密鍵)及びKSK(秘密鍵)を保持してもよい。
【0029】
ここで、DNSSECでは、ルートサーバ100、jp.サーバ100、example.jp.サーバ100及びキャッシュサーバ20は、同一のハッシュ関数を用いてハッシュ値を計算する。また、DS方式では、下位権威サーバは、上位権威サーバに対して、かかる下位権威サーバが保持するKSK(公開鍵)のハッシュ値であるDSレコードを予め通知している。すなわち、example.jp.サーバ100は、自身のDSレコードをjp.サーバ100に通知し、jp.サーバ100は、自身のDSレコードをルートサーバ100に通知する。そして、ルートサーバ100は、自身のDSレコードをキャッシュサーバ20に通知する。
【0030】
これらのルートサーバ100、jp.サーバ100、example.jp.サーバ100及びキャッシュサーバ20は、図4に例示するデータを用いて、DNSSECにおける電子署名を用いた署名検証を実現する。図4は、DNSSECに用いられる各種データの一例を示す図である。
【0031】
図4(A)に示すように、example.jp.サーバ100は、「www.example.jp」のIPv4アドレスの情報を含む「Aレコード」のデータ33aを保持する。なお、クライアント装置10がIPv6(Internet Protocol version 6)アドレスを要求している場合には、DNSSECに用いられるデータは、「www.example.jp」のIPv6アドレスの情報を含むAAAAレコードとなる。
【0032】
また、図4(A)に示すように、example.jp.サーバ100は、「Aレコードのハッシュ値をZSK−C(秘密鍵)で暗号化した電子署名」であるデータ33bを保持する。また、図4(A)に示すように、example.jp.サーバ100は、「ZSK−C(公開鍵)」のデータ33cと、「KSK−C(公開鍵)」のデータ33dと、「ZSK−C(公開鍵)及びKSK−C(公開鍵)のハッシュ値をKSK−C(秘密鍵)で暗号化した電子署名」であるデータ33eを保持する。このように、ZSK−C(公開鍵)及びKSK−C(公開鍵)であるDNSKEYについては、ZSK−C(公開鍵)とKSK−C(公開鍵)とが統合されたデータに対して1つの電子署名(データ33e)が作成される。
【0033】
すなわち、example.jp.サーバ100は、「www.example.jp」のAレコード及びAレコードの署名として、データ33a及びデータ33bを保持する。また、example.jp.サーバ100は、DNSKEYとしてデータ33c及びデータ33dを保持する。また、example.jp.サーバ100は、DNSKEYの署名としてデータ33eを保持する。また、図4(A)では図示していないが、example.jp.サーバ100は、下位権威サーバが存在する場合には、かかる下位権威サーバのDSレコード(下位権威サーバのKSK(公開鍵)のハッシュ値)を保持する。
【0034】
また、図4(B)に示すように、jp.サーバ100は、example.jp.サーバ100のDSレコード、すなわち、「KSK−C(公開鍵)のハッシュ値」であるデータ32aと、「DSレコード(KSK−C(公開鍵)のハッシュ値)をZSK−B(秘密鍵)で暗号化した電子署名」であるデータ32bとを保持する。また、図4(B)に示すように、jp.サーバ100は、「ZSK−B(公開鍵)」のデータ32cと、「KSK−B(公開鍵)」のデータ32dと、「ZSK−B(公開鍵)及びKSK−B(公開鍵)のハッシュ値をKSK−B(秘密鍵)で暗号化した電子署名」であるデータ32eを保持する。
【0035】
すなわち、jp.サーバ100は、example.jp.サーバ100のDSレコード及びDSレコードの署名として、データ32a及びデータ32bを保持する。また、jp.サーバ100は、DNSKEYとしてデータ32c及びデータ32dを保持する。また、jp.サーバ100は、DNSKEYの署名としてデータ32eを保持する。
【0036】
また、図4(C)に示すように、ルートサーバ100は、jp.サーバ100のDSレコード、すなわち、「KSK−B(公開鍵)のハッシュ値」であるデータ31aと、「DSレコード(KSK−B(公開鍵)のハッシュ値)をZSK−A(秘密鍵)で暗号化した電子署名」であるデータ31bを保持する。また、図4(C)に示すように、ルートサーバ100は、「ZSK−A(公開鍵)」のデータ31cと、「KSK−A(公開鍵)」のデータ31dと、「ZSK−A(公開鍵)及びKSK−A(公開鍵)のハッシュ値をKSK−A(秘密鍵)で暗号化した電子署名」であるデータ31eとを保持する。
【0037】
すなわち、ルートサーバ100は、jp.サーバ100のDSレコード及びDSレコードの署名として、データ31a及びデータ31bを保持する。また、ルートサーバ100は、DNSKEYとしてデータ31c及びデータ31dを保持する。また、ルートサーバ100は、DNSKEYの署名としてデータ31eを保持する。
【0038】
そして、図4(D)に示すように、キャッシュサーバ20は、例えば、ルートサーバ100のDSレコード、すなわち、「KSK−A(公開鍵)」であるデータ23aをキャッシュ部23内に保持する。
【0039】
なお、図4では、キャッシュサーバ20が、ルートサーバ100の「KSK−A(公開鍵)」をキャッシュ部23に保持する例を示した。しかし、キャッシュサーバ20は、「KSK−A(公開鍵)」ではなく、KSK−A(公開鍵)のキャッシュ値であるDSレコードをキャッシュ部23に保持してもよい。具体的には、キャッシュサーバ20は、ルートサーバ100によって保持されているデータ31eと比較した後のKSK−A(公開鍵)のキャッシュ値をキャッシュ部23に保持してもよい。
【0040】
図4に例示したデータを用いて、実施例1に係る名前解決システム1が実行する署名検証処理について、図5を用いて説明する。図5は、実施例1に係る名前解決システム1が実行する署名検証処理の一例を示すシーケンス図である。
【0041】
図5に示すように、クライアント装置10は、キャッシュサーバ20の応答部21に対して、「www.example.jp」のAレコードを問い合わせる名前解決の依頼を行う(ステップS1)。名前解決の依頼を受け付けた応答部21は、要求部24に名前解決の依頼内容を転送し(ステップS2)、要求部24は、ルートサーバ100にAレコードを問い合わせる(ステップS3)。
【0042】
「www.example.jp」のAレコードの問い合わせを受け付けたルートサーバ100は、NSレコードを参照して、「jp.サーバ100に問い合わせて下さい」と要求部24に返信する(ステップS4)。具体的には、ルートサーバ100は、jp.サーバ100のIPアドレスを要求部24に返信する。そして、要求部24は、jp.サーバ100にAレコードを問い合わせる(ステップS5)。
【0043】
「www.example.jp」のAレコードの問い合わせを受け付けたjp.サーバ100は、NSレコードを参照して、「example.jp.サーバ100に問い合わせて下さい」と要求部24に返信する(ステップS6)。すなわち、jp.サーバ100は、example.jp.サーバ100のIPアドレスを要求部24に返信する。そして、要求部24は、example.jp.サーバ100にAレコードを問い合わせる(ステップS7)。
【0044】
「www.example.jp」のAレコードの問い合わせを受け付けたexample.jp.サーバ100は、「www.example.jp」のAレコード及びAレコードの署名を要求部24に返信する(ステップS8)。すなわち、example.jp.サーバ100は、図4(A)に示すデータ33a及びデータ33bを返信する。
【0045】
そして、要求部24は、example.jp.サーバ100に対して、example.jp.サーバ100のDNSKEY及びDNSKEYの署名を問い合わせ(ステップS9)、example.jp.サーバ100は、DNSKEY及びDNSKEYの署名を要求部24に返信する(ステップS10)。すなわち、example.jp.サーバ100は、図4(A)に示すデータ33c及びデータ33dと、データ33eとを返信する。
【0046】
そして、要求部24は、ルートサーバ100にexample.jp.サーバ100のDSレコードを問い合わせる(ステップS11)、ルートサーバ100は、NSレコードを参照して、「jp.サーバ100に問い合わせて下さい」と要求部24に返信する(ステップS12)。
【0047】
そして、要求部24は、jp.サーバ100にexample.jp.サーバ100のDSレコードを問い合わせ(ステップS13)、jp.サーバ100は、example.jp.サーバ100のDSレコード及びDSレコードの署名を要求部24に返信する(ステップS14)。すなわち、jp.サーバ100は、図4(B)に示すデータ32a及びデータ32bを返信する。
【0048】
そして、要求部24は、jp.サーバ100にjp.サーバ100のDNSKEYを問い合わせ(ステップS15)、jp.サーバ100は、自身のDNSKEY及び署名を返信する(ステップS16)。すなわち、jp.サーバ100は、図4(B)に示すデータ32c及びデータ32dと、データ32eとを返信する。
【0049】
そして、要求部24は、ルートサーバ100にjp.サーバ100のDSレコードを問い合わせ(ステップS17)、ルートサーバ100は、jp.サーバ100のDSレコード及びDSレコードの署名を返信する(ステップS18)。すなわち、ルートサーバ100は、図4(C)に示すデータ31a及びデータ31bを返信する。
【0050】
そして、要求部24は、ルートサーバ100にルートサーバ100のDNSKEYを問い合わせ(ステップS19)、ルートサーバ100は、自身のDNSKEY及び署名を返信する(ステップS20)。すなわち、ルートサーバ100は、図4(C)に示すデータ31c及びデータ31dと、データ31eとを返信する。
【0051】
そして、要求部24は、各権威サーバからの一連の応答データをキャッシュ部23に格納し(ステップS21)、検証部22にキャッシュ部23が記憶する応答データの署名検証を依頼する(ステップS22)。
【0052】
そして、検証部22は、検証処理を行う(ステップS23)。具体的には、検証部22は、データ31dのハッシュ値とデータ23aのハッシュ値とを比較することにより、データ31dの正当性を検証する。また、検証部22は、データ31c及びデータ31dのハッシュ値と、データ31eをデータ31dで復号した結果とを比較することにより、データ31c及びデータ31dの正当性を検証する。また、検証部22は、データ31aと、データ31bをデータ31cで復号した結果とを比較することにより、データ31aの正当性を検証する。
【0053】
また、検証部22は、データ32dのハッシュ値とデータ31aとを比較することにより、データ32dの正当性を検証する。すなわち、検証部22は、ルートサーバ100が保持するDSレコードを用いてKSK−B(公開鍵)の正当性を検証する。また、検証部22は、データ32c及びデータ32dのハッシュ値と、データ32eをデータ32dで復号した結果とを比較することにより、データ32c及びデータ32dの正当性を検証する。さらに、検証部22は、データ32aと、データ32bをデータ32cで復号した結果とを比較することにより、データ32aの正当性を検証する。
【0054】
また、検証部22は、データ33dのハッシュ値とデータ32aとを比較することにより、データ33dの正当性を検証する。すなわち、検証部22は、jp.サーバ100が保持するDSレコードを用いてKSK−C(公開鍵)の正当性を検証する。また、検証部22は、データ33c及びデータ33dのハッシュ値と、データ33eをデータ33dで復号した結果とを比較することにより、データ33c及びデータ33dの正当性を検証する。さらに、検証部22は、データ33aのハッシュ値と、データ33bをデータ33cで復号した結果とを比較することにより、データ33aの正当性を検証する。
【0055】
そして、検証部22は、全ての比較結果が一致する場合、権威サーバ群100からの応答データが正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部21は、クライアント装置10に対して、データ33aを返信する。一方、検証部22は、全ての比較結果が一致しない場合、権威サーバ群100からの応答データが不当であり、署名検証が失敗したと判定する。
【0056】
なお、図5に示した例において、ルートサーバ100、jp.サーバ100及びexamp le.jp.サーバ100は、Aレコードや各電子署名やDNSKEY等の各種応答データをキャッシュサーバ20に送信する際にTTLを設定する。これにより、キャッシュサーバ20は、TTLに設定されている時間が経過するまで各種応答データをキャッシュすることとなる。
【0057】
ところで、上述してきた各権威サーバが保持する署名鍵であるZSKやKSKは、定期的に更新されることが望ましい。しかし、キャッシュサーバ20は、TTL時間が経過するまで各権威サーバから取得した署名鍵等をキャッシュ部23に保持する。このため、各権威サーバの署名鍵が更新された場合であっても、更新後の署名鍵がキャッシュサーバ20に即座に反映されないと考えられる。
【0058】
そこで、実施例1に係る権威サーバ群100は、権威サーバの管理者や運用者等によって署名鍵が更新された場合に、古い署名鍵の有効期限に応じてTTLの設定値を変動させることにより、更新後の署名鍵がキャッシュサーバ20に即座に反映されることを可能にする。この点について、図6を用いて簡単に説明する。図6は、実施例1に係る名前解決システム1による鍵更新処理の一例を示す図である。ここでは、権威サーバ100、キャッシュサーバ20a及び20bを例に挙げて、実施例1に係る名前解決システム1による鍵更新処理について説明する。なお、キャッシュサーバ20a及び20bは、図2に例示したキャッシュサーバ20に対応する。また、以下では、権威サーバ100によって設定されるTTLの通常値(デフォルト値)は、「86400[秒]=24時間(1日)」であるものとする。
【0059】
まず、権威サーバの管理者や運用者等が、新しい署名鍵を権威サーバ100に登録したものとする。このとき、権威サーバの管理者や運用者等は、古い署名鍵を削除することなく新しい署名鍵を登録し、さらに、古い署名鍵から新しい署名鍵に更新される鍵更新日時を設定する。例えば、権威サーバの管理者や運用者等は、新しい署名鍵が有効となる開始日時等を設定する。
【0060】
このような状況において、図6に示した例のように、キャッシュサーバ20aが権威サーバ100に対して名前解決に関する問い合わせを行ったものとする(ステップS31)。この名前解決に関する問い合わせとは、図5に示したステップS3、S17、S19等における各種問い合わせであって、権威サーバ100から名前解決の結果や署名鍵等の取得要求に該当する。このとき、実施例1に係る権威サーバ100は、問い合わせを受け付けた日時から鍵更新日時までの時間を算出し、算出した時間がTTLの通常値「86400」以上であるか否かを判定する。ここでは、算出した時間がTTLの通常値「86400」以上であるものとする。かかる場合に、権威サーバ100は、ステップS31において受け付けた問い合わせに対応する応答データのTTLに「86400」を設定し、かかる応答データをキャッシュサーバ20aに送信する(ステップS32)。この送信処理は、図5に示したステップS18、S20等に該当する。これにより、キャッシュサーバ20aは、TTL時間である「86400[秒]」が経過するまでは権威サーバ100から受け付けた応答データをキャッシュ部23に保持する。
【0061】
同様に、キャッシュサーバ20bが、鍵更新日時の1日以上前に、権威サーバ100に対して名前解決に関する問い合わせを行ったものとする(ステップS33)。この場合においても、権威サーバ100は、応答データのTTLを「86400」に設定し、かかる応答データをキャッシュサーバ20bに送信する(ステップS34)。これにより、キャッシュサーバ20bは、TTL時間である「86400[秒]」が経過するまでは応答データをキャッシュ部23に保持する。
【0062】
続いて、図6に示した例のように、キャッシュサーバ20aが、鍵更新日時の1時間前に、権威サーバ100に対して名前解決に関する問い合わせを行ったものとする(ステップS35)。かかる場合に、実施例1に係る権威サーバ100は、問い合わせを受け付けた日時から鍵更新日時までの時間「3600[秒]=1時間」を算出し、算出した時間「3600」がTTLの通常値「86400」以上であるか否かを判定する。ここでは、算出した時間「3600」がTTLの通常値「86400」よりも小さいので、権威サーバ100は、応答データのTTLに「3600」を設定し、かかる応答データをキャッシュサーバ20aに送信する(ステップS36)。これにより、キャッシュサーバ20aは、TTL時間である「3600[秒]」が経過するまでは応答データをキャッシュ部23に保持する。
【0063】
すなわち、キャッシュサーバ20aは、TTL時間「3600[秒]」が経過した後に、クライアント装置10から名前解決の問い合わせを受け付けた場合には、キャッシュ部23から署名鍵等の応答データが削除されているので、権威サーバ100に対して名前解決に関する問い合わせを行う(ステップS37)。言い換えれば、キャッシュサーバ20aは、TTLに「3600[秒]」が設定されていることにより、権威サーバ100において署名鍵が更新された後にクライアント装置10から名前解決の問い合わせを受け付けた場合には、権威サーバ100から新しい署名鍵を取得して署名検証を行うこととなる。このため、権威サーバ100は、署名鍵が更新された後には、更新後の新しい署名鍵をキャッシュサーバ20aに用いさせることができるので、キャッシュサーバ20aにおける署名鍵を短期間で更新することができる。
【0064】
なお、ステップS37において問い合わせを受け付けた権威サーバ100は、問い合わせを受け付けた日時から鍵更新日時までの時間を算出し、算出した時間がTTLの通常値以上であるか否かを判定する。ここでは、算出した時間がTTLの通常値以上であるものとする。すなわち、権威サーバ100は、応答データのTTLに「86400」を設定し、かかる応答データをキャッシュサーバ20aに送信する(ステップS38)。
【0065】
続いて、図6に示した例のように、キャッシュサーバ20bが、鍵更新日時の20分前に、権威サーバ100に対して名前解決に関する問い合わせを行ったものとする(ステップS39)。かかる場合に、実施例1に係る権威サーバ100は、問い合わせを受け付けた日時から鍵更新日時までの時間「1200[秒]=20分」を算出し、算出した時間「1200」を応答データのTTLに設定し、かかる応答データをキャッシュサーバ20bに送信する(ステップS40)。これにより、キャッシュサーバ20bは、TTL時間である「1200[秒]」が経過するまでは応答データをキャッシュ部23に保持する。
【0066】
すなわち、キャッシュサーバ20bは、TTL時間「1200[秒]」が経過した後に、クライアント装置10から名前解決の問い合わせを受け付けた場合には、キャッシュ部23から署名鍵が削除されているので、権威サーバ100に対して名前解決に関する問い合わせを行う(ステップS41)。これにより、キャッシュサーバ20bは、権威サーバ100において署名鍵が更新された後には、更新後の新しい署名鍵を用いて署名検証を行うことができる。
【0067】
なお、ここの例では、権威サーバ100によって問い合わせを受け付けられた日時から鍵更新日時までの時間がTTLの通常値「86400」以上であるものとする。すなわち、権威サーバ100は、応答データのTTLに「86400」を設定し、かかる応答データをキャッシュサーバ20bに送信する(ステップS42)。
【0068】
このように、実施例1に係る名前解決システム1では、権威サーバ100が鍵更新日時までの時間をTTLに設定するので、更新後の署名鍵をキャッシュサーバ20に即座に反映することができる。
【0069】
なお、図6に示した例では、権威サーバ100とキャッシュサーバ20との間における処理の一例について説明したが、実施例1に係る権威サーバ100や権威サーバ100についてもキャッシュサーバ20との間で図6に例示した処理と同様の処理を行うことができる。以下に、このような権威サーバ100、100及び100の構成について説明する。なお、実施例に係る権威サーバ100、100及び100の構成のうち、図6に例示した処理を実現するための構成については同様である。したがって、以下では、権威サーバ100を例に挙げて説明する。
【0070】
図7を用いて、権威サーバ100の構成について説明する。図7は、実施例1における権威サーバ100の構成例を示す図である。図7に例示するように、実施例1における権威サーバ100は、IF(interface)部110と、記憶部120と、管理部130と、問合せ処理部140とを有する。なお、図7では図示することを省略したが、権威サーバ100は、各種情報や操作指示を入力するための入力部(キーボード、マウス等)や、各種情報を表示する表示デバイス(液晶表示装置等)を有してもよい。
【0071】
IF部110は、キャッシュサーバ20等の外部装置との間で各種データを送受信するNIC(Network Interface Card)等である。例えば、IF部110は、キャッシュサーバ20から名前解決のための依頼等を受信する。また、例えば、IF部110は、名前解決のための依頼に対応する応答をキャッシュサーバ20に送信する。
【0072】
記憶部120は、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置であり、図4に例示した各種情報を記憶する。例えば、権威サーバ100の記憶部120は、図4に例示したデータ31a、31b、31c、31d及び31e等を記憶する。また、記憶部120は、権威サーバの管理者や運用者等によって登録される新しい署名鍵を記憶する。
【0073】
管理部130は、署名鍵が新たな署名鍵に更新される日時である有効期限を管理する。具体的には、記憶部120に記憶されている署名鍵(KSKやZSK)には有効期限が設定されている。このため、管理部130は、記憶部120に記憶されている古い署名鍵や新しい署名鍵に設定されている有効期限を参照することにより、古い署名鍵が新しい署名鍵に更新される鍵更新日時を取得する。
【0074】
問合せ処理部140は、キャッシュサーバ20から送信される名前解決に関する問い合わせに対して各種応答処理を行う。具体的には、問合せ処理部140は、図5に示したステップS4、S12、S18及びS20等における処理を行う。このような問合せ処理部140は、図7に例示するように、受付部141と、設定部142と、送信部143とを有する。
【0075】
受付部141は、キャッシュサーバ20から名前解決に関する各種問い合わせを受け付ける。具体的には、実施例1における受付部141は、名前解決に関する各種問い合わせとして、名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバ20から受け付ける。例えば、受付部141は、図5に示したステップS3、S11、S17及びS19等における複数種類の取得要求を受け付ける。
【0076】
設定部142は、受付部141によって受け付けられた取得要求に対応する応答データに対して、署名鍵が新たな署名鍵に更新される鍵更新日時までの期間である有効期間を、キャッシュサーバ20にキャッシュされる応答データのキャッシュ期間(TTL)として設定する。具体的には、設定部142は、受付部141によって各種取得要求が受け付けられた場合に、取得要求を受け付けた日時から管理部130によって管理されている鍵更新日時までの時間である有効期間を算出する。そして、設定部142は、算出した有効期間がTTLの通常値(上記例では「86400」)以上であるか否かを判定する。そして、設定部142は、有効期間が通常値以上である場合には、応答データのTTLに通常値を設定し、有効期間が通常値よりも小さい場合には、応答データのTTLに有効期間を設定する。
【0077】
送信部143は、受付部141によって各種取得要求が受け付けられた場合に、設定部142によってTTLが設定された応答データをキャッシュサーバ20に送信する。
【0078】
なお、上記の管理部130及び問合せ処理部140は、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、図示しない記憶装置に記憶されているプログラムがRAM(Random Access Memory)を作業領域として実行されることにより実現される。また、例えば、管理部130及び問合せ処理部140は、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
【0079】
次に、図8を用いて、実施例1に係る権威サーバ100による処理の手順について説明する。図8は、実施例1に係る権威サーバ100による処理手順を示すフローチャートである。
【0080】
図8に示すように、権威サーバ100の受付部141は、キャッシュサーバ20から名前解決に関する各種取得要求を受け付けたか否かを判定する(ステップS101)。そして、受付部141は、キャッシュサーバ20から各種取得要求を受け付けない場合には(ステップS101否定)、キャッシュサーバ20から取得要求を受け付けるまで待機する。
【0081】
一方、受付部141によってキャッシュサーバ20から取得要求が受け付けられた場合には(ステップS101肯定)、設定部142は、かかる取得要求を受け付けた日時から鍵更新日時までの時間である有効期間を算出し(ステップS102)、算出した有効期間がTTLの通常値以上であるか否かを判定する(ステップS103)。
【0082】
そして、設定部142は、有効期間が通常値以上である場合には(ステップS103肯定)、応答データのTTLに通常値を設定し(ステップS104)、有効期間が通常値よりも小さい場合には(ステップS103否定)、応答データのTTLにかかる有効期間を設定する(ステップS105)。そして、送信部143は、設定部142によってTTLが設定された応答データをキャッシュサーバ20に送信する(ステップS106)。
【0083】
上述してきたように、実施例1に係る権威サーバ群100は、名前解決の結果の取得要求、又は、名前解決の結果に対する署名検証時に用いる署名鍵の取得要求を含む複数種類の取得要求をキャッシュサーバ20から受け付ける受付部141と、受付部141によって受け付けられた取得要求に対応する応答データに対して、署名鍵が新たな署名鍵に更新されるまでの期間である有効期間をTTLとして設定する設定部142と、設定部142によってTTLが設定された応答データをキャッシュサーバ20に送信する送信部143とを有する。
【0084】
これにより、実施例1に係る権威サーバ群100は、署名鍵が更新されるタイミングと略同一のタイミングで、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を削除させることができる。この結果、権威サーバ群100は、署名鍵が更新された後には、更新後の新しい署名鍵をキャッシュサーバ20に用いさせることができるので、キャッシュサーバ20における署名鍵を短期間で更新することができる。
【0085】
また、実施例1に係る権威サーバ群100において、設定部142は、署名鍵の有効期間が通常値以上である場合には、かかる通常値を応答データのTTLに設定し、署名鍵の有効期間が通常値よりも小さい場合には、かかる有効期間を応答データのTTLに設定する。これにより、実施例1に係る権威サーバ群100は、署名鍵の更新タイミングまで長期間ある場合には、キャッシュサーバ20におけるキャッシュ部23から署名鍵等が短期間で削除されることを防止でき、署名鍵の更新タイミングが近づいてきた場合には、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を通常時よりも短期間で削除させることで、キャッシュサーバ20における署名鍵を短期間で更新することができる。
【0086】
また、実施例1に係る権威サーバ群100において、設定部142は、署名鍵が新たな署名鍵に更新される日時と、受付部141によって取得要求が受け付けられた日時との差分を有効期間として算出する。これにより、実施例1に係る権威サーバ群100は、署名鍵の更新タイミングと、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を削除させるタイミングとを一致させることができる。
【0087】
ここで、従来の名前解決システムと比較して、実施例1に係る権威サーバ群100における効果の一例を説明する。例えば、従来の名前解決システムにおいて権威サーバが保持するZSKやKSK等の署名鍵を更新する場合や、署名鍵の更新に伴って電子署名を更新する場合には、権威サーバの管理者や運用者等は、古い署名鍵や古い電子署名を削除することなく新しい署名鍵や古い電子署名を権威サーバに追加する。例えば、権威サーバの管理者や運用者等が権威サーバに新しい署名鍵を追加したものとする。この段階では、権威サーバは、新しい署名鍵を保持しているだけであって、かかる新しい署名鍵と対になる電子署名を保持していないので、古い署名鍵を用いて署名を実施する。この例では、権威サーバは、まず新しい署名鍵をキャッシュサーバに保持させてから、新しい署名鍵と対になる電子署名を検証させられる状態をつくるからである。そして、キャッシュサーバは、TTL時間が経過したキャッシュが削除され、クライアント装置から問い合わせがあった場合に、権威サーバから署名鍵を取得する。ここでは、権威サーバに古い署名鍵と新しい署名鍵の双方が登録されているので、キャッシュサーバは、権威サーバから古い署名鍵と新しい署名鍵との双方を取得する。その後、権威サーバは、十分に時間が経過して古い署名鍵と新しい署名鍵の双方がキャッシュサーバに伝播した場合に、新しい署名鍵を用いて署名を実施する。ただし、この段階では、キャッシュサーバは、権威サーバから古い署名鍵と新しい署名鍵の双方を取得した際の各種データがキャッシュされているので、権威サーバから新しい署名鍵に対応する署名を取得しない。そして、キャッシュサーバは、TTL時間が経過したキャッシュが削除され、クライアント装置から問い合わせがあった場合に、権威サーバから署名鍵等を取得する。この後に、権威サーバの管理者や運用者等は、権威サーバから古い署名鍵や古い電子署名を削除することが可能となる。このように、従来の名前解決システムにおいては、権威サーバの署名鍵を更新する場合には、TTL時間が経過するまで待機するステップが複数存在するので、キャッシュサーバにおける署名鍵を短期間で更新することができない。
【0088】
一方で、実施例1に係る権威サーバ群100においては、権威サーバ群100の署名鍵が更新されるタイミングと略同一のタイミングで、キャッシュサーバ20におけるキャッシュ部23から署名鍵等を削除させることができるので、キャッシュサーバ20における署名鍵を短期間で更新することができる。
【実施例2】
【0089】
上述した名前解決システム1は、上記実施例以外にも種々の異なる形態にて実施されてよい。そこで、実施例2では、上記の名前解決システム1の他の実施例について説明する。
【0090】
[TTLの設定値]
上記実施例1では、設定部142が、新たな署名鍵に更新されるまでの署名鍵の有効期間がTTLの通常値よりも小さい場合には、かかる有効期間を応答データのTTLとして設定する例を示した。しかし、設定部142は、有効期間と同一の期間をTTLに設定しなくてもよい。具体的には、設定部142は、通常値よりも短く、かつ、有効期間よりも所定期間だけ長い期間をTTLとして設定してもよい。例えば、署名鍵が新たな署名鍵に更新されるまでの有効期間が「1200[秒]」であるものとする。かかる場合に、設定部142は、有効期間「1200」より大きく、かつ、通常値「86400」よりも小さい値(例えば、「1201」、「1800」、「3600」等)をTTLに設定してもよい。
【0091】
[キャッシュサーバに応じたTTLの設定]
また、権威サーバに複数のキャッシュサーバが接続されており、かかる権威サーバの受付部141によって複数のキャッシュサーバから各種取得要求が受け付けられる場合には、設定部142は、キャッシュサーバに応じて異なるTTLを応答データに設定してもよい。例えば、署名鍵の有効期間が「1200」であるものとする。かかる場合に、設定部142は、例えば、キャッシュサーバ20aに送信する応答データに対しては有効期間「1200」をTTLに設定し、キャッシュサーバ20bに送信する応答データに対しては「1800」をTTLに設定し、キャッシュサーバ20cに送信する応答データに対しては「3600」をTTLに設定してもよい。これにより、キャッシュサーバによってキャッシュ部23から各種情報が削除されるタイミングが異なるので、各キャッシュサーバから権威サーバ群100に名前解決のための問い合わせが行われるタイミングもキャッシュサーバによって変動する。これにより、権威サーバ群100による名前解決のための処理にかかる負荷を分散することができる。
【0092】
また、設定部142は、署名鍵の有効期間がTTLの通常値よりも小さい場合に、特定のキャッシュサーバに送信する応答データに対してのみ、有効期間をTTLに設定してもよい。例えば、署名鍵の更新を短期間で更新することが望まれている特定のキャッシュサーバが予め決められている場合等に、設定部142は、かかる特定のキャッシュサーバに送信する応答データに対してのみ、有効期間をTTLに設定してもよい。
【0093】
[有効期間の算出]
また、上記実施例1では、設定部142が、受付部141によって各種取得要求が受け付けられた場合に、管理部130によって管理されている鍵更新日時と、受付部141によって取得要求が受け付けられた日時との差分を署名鍵の有効期間として算出する例を示した。しかし、設定部142は、他の手法によって署名鍵の有効期間を算出してもよい。例えば、設定部142は、管理部130によって管理されている鍵更新日時と、現在日時との差分を署名鍵の有効期間として算出してもよい。
【0094】
[システム構成]
また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図3、図4に示した各種情報は一例であって任意に変更することができる。
【0095】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図7に例示した管理部130と設定部142とは統合されてもよい。
【0096】
[プログラム]
また、上記実施例において説明した各権威サーバ(権威サーバ100、100及び100)が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例1に係る権威サーバが実行する処理をコンピュータが実行可能な言語で記述した鍵更新プログラムを作成することもできる。この場合、コンピュータが鍵更新プログラムを実行することにより、上記実施例1と同様の効果を得ることができる。さらに、かかる鍵更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された鍵更新プログラムをコンピュータに読み込ませて実行することにより上記実施例1と同様の処理を実現してもよい。以下に、図7に示した権威サーバと同様の機能を実現する鍵更新プログラムを実行するコンピュータの一例を説明する。
【0097】
図9は、鍵更新プログラムを実行するコンピュータ1000を示す図である。図9に例示するように、コンピュータ1000は、例えば、メモリ1010と、CPU1020と、ハードディスクドライブインタフェース1030と、ディスクドライブインタフェース1040と、シリアルポートインタフェース1050と、ビデオアダプタ1060と、ネットワークインタフェース1070とを有し、これらの各部はバス1080によって接続される。
【0098】
メモリ1010は、図9に例示するように、ROM(Read Only Memory)1011及びRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、図9に例示するように、ハードディスクドライブ1031に接続される。ディスクドライブインタフェース1040は、図9に例示するように、ディスクドライブ1041に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース1050は、図9に例示するように、例えばマウス1051、キーボード1052に接続される。ビデオアダプタ1060は、図9に例示するように、例えばディスプレイ1061に接続される。
【0099】
ここで、図9に例示するように、ハードディスクドライブ1031は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、上記の鍵更新プログラムは、コンピュータ1000によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ1031に記憶される。例えば、図7に例示した管理部130と同様の情報処理を実行する管理手順と、問合せ処理部140と同様の情報処理を実行する問合せ処理手順と、受付部141と同様の情報処理を実行する受付手順と、設定部142と同様の情報処理を実行する設定手順と、送信部143と同様の情報処理を実行する送信手順とが記述されたプログラムモジュール1093が、ハードディスクドライブ1031に記憶される。
【0100】
また、上記実施例で説明した記憶部120が保持する各種データは、プログラムデータとして、例えばメモリ1010やハードディスクドライブ1031に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1031に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出し、管理手順、問合せ処理手順、受付手順、設定手順、送信手順を実行する。
【0101】
なお、鍵更新プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1031に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してCPU1020によって読み出されてもよい。あるいは、鍵更新プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ネットワーク(LAN(Local Area Network)、WAN(Wide Area Network)等)を介して接続された他のコンピュータに記憶され、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。
【符号の説明】
【0102】
1 名前解決システム
10 クライアント装置
20 キャッシュサーバ
21 応答部
22 検証部
23 キャッシュ部
24 要求部
100 権威サーバ群
120 記憶部
130 管理部
140 問合せ処理部
141 受付部
142 設定部
143 送信部

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2013−93702(P2013−93702A)
【公開日】平成25年5月16日(2013.5.16)
【国際特許分類】
【出願番号】特願2011−233861(P2011−233861)
【出願日】平成23年10月25日(2011.10.25)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】