名前解決システム及び鍵更新方法
【課題】鍵の更新誤りを防止すること。
【解決手段】実施形態に係る名前解決システムは、名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、署名鍵の正当性を検証する際に用いられるデータであって署名鍵を特定する特定データを保持する第２の権威サーバとを含む。第１の権威サーバは、新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を第２の権威サーバに通知する。また、第２の権威サーバは、第１の権威サーバから通知された場合に、かかる第１の権威サーバから新署名鍵を取得し、取得した新署名鍵に対応する特定データである新特定データを生成する。
【解決手段】実施形態に係る名前解決システムは、名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、署名鍵の正当性を検証する際に用いられるデータであって署名鍵を特定する特定データを保持する第２の権威サーバとを含む。第１の権威サーバは、新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を第２の権威サーバに通知する。また、第２の権威サーバは、第１の権威サーバから通知された場合に、かかる第１の権威サーバから新署名鍵を取得し、取得した新署名鍵に対応する特定データである新特定データを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、名前解決システム及び鍵更新方法に関する。
【背景技術】
【０００２】
従来、ドメイン名とＩＰアドレス（Internet Protocol Address）とを対応させる名前管理システム（ＤＮＳ：Domain Name System）が知られている。ＤＮＳは、一般的には、権威サーバ群とキャッシュサーバとから構成される。権威サーバ群は、複数の権威サーバから構成され、各権威サーバは、名前空間の中にある特定のゾーンを管理する。キャッシュサーバは、クライアント装置からの名前解決の依頼に応じて、権威サーバ群に問い合わせを行うとともに、権威サーバ群からの応答をキャッシュ可能なサーバである。
【０００３】
また、近年、ＤＮＳの拡張仕様として、権威サーバ群からの応答の正当性を保証するＤＮＳＳＥＣ（ＤＮＳ Security Extensions）の普及が進められている。ＤＮＳＳＥＣにおいては、権威サーバ群からの応答の正当性を保証するために、電子署名を用いた検証（署名検証）が行われる。
【０００４】
例えば、ＤＮＳＳＥＣのＤＳ（Delegation Signer）方式が適用されている権威サーバ（権威サーバＡ１とする）は、権威サーバＡ１自身が管理するゾーンに関する情報に署名を行うための公開鍵及び秘密鍵のペアであるＺＳＫ（Zone Signing Key）を保持するとともに、ＺＳＫに署名を行うための公開鍵及び秘密鍵のペアであるＫＳＫ（Key Signing Key）を保持する。そして、かかる権威サーバＡ１は、権威サーバＡ１が管理するゾーンの上位のゾーンを管理する上位権威サーバ（上位権威サーバＡ２とする）に対して、ＫＳＫの公開鍵のハッシュ値であるＤＳレコードを予め通知する。
【０００５】
このような権威サーバＡ１は、キャッシュサーバから名前解決の依頼を受け付けた場合に、かかる依頼に対応する応答内容と、ＺＳＫ（秘密鍵）を用いて作成した応答内容の電子署名と、ＫＳＫ（秘密鍵）を用いて作成したＺＳＫ（公開鍵）の電子署名とをキャッシュサーバに送信する。そして、キャッシュサーバは、上位権威サーバＡ２が保持するＤＳレコードを用いて、権威サーバＡ１が保持するＫＳＫ（公開鍵）の署名検証を行う。また、キャッシュサーバは、署名検証済みのＫＳＫ（公開鍵）を用いて、ＺＳＫ（公開鍵）の署名検証を行う。そして、キャッシュサーバは、署名検証済みのＺＳＫ（公開鍵）を用いて、権威サーバＡ１から受信した応答内容の署名検証を行う。これにより、キャッシュサーバは、正当性が保証されたＩＰアドレスなどの応答データをクライアント装置に送信する。このように、ＤＮＳＳＥＣのＤＳ方式では、上位権威サーバが下位権威サーバのＫＳＫ（公開鍵）に対応するＤＳレコードを保持することで、「信頼の連鎖」を実現している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】“DNSSEC Operational Practices”、O.Kolkman、R.Gieben、RFC4641、［online］、［平成２３年５月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc4641.txt＞
【非特許文献２】“Domain Name System （DNS） Security Extensions Mapping for the Extensible Provisioning Protocol （EPP）”、J.Gould、S.Hollenbeck、RFC5910、［online］、［平成２３年５月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc5910.txt＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、ＤＮＳＳＥＣが適用されているＤＮＳにおいて、ネットワーク管理者は、ＺＳＫやＫＳＫを定期的に更新することが望ましい。これは、第三者によってＺＳＫやＫＳＫが解読されるおそれがあるからである。ここで、上位権威サーバが下位権威サーバのＫＳＫ（公開鍵）に対応するＤＳレコードを保持するので、下位権威サーバのネットワーク管理者は、かかる下位権威サーバが保持するＫＳＫを更新する場合に、上位権威サーバのＤＳレコードについても更新することを要する。
【０００８】
しかしながら、ネットワーク管理者が、更新対象のＫＳＫに対応するＤＳレコードを常に正しく更新できるとは限らない。例えば、ネットワーク管理者の操作ミス等により誤ったＤＳレコードが上位権威サーバに登録される場合もある。かかる場合には、キャッシュサーバは、署名検証に失敗し、クライアント装置に対して、名前解決に失敗したことを示すエラー（Server Failure）を返信することになる。
【０００９】
そこで、本発明は、上述した従来技術の課題を解決するためになされたものであり、鍵の更新誤りを防止することができる名前解決システム及び鍵更新方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
実施形態に係る名前解決システムは、名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第２の権威サーバとを含む名前解決システムであって、前記第１の権威サーバは、新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第２の権威サーバに通知する通知部を備え、前記第２の権威サーバは、前記通知部によって通知された場合に、前記第１の権威サーバから前記新署名鍵を取得する取得部と、前記取得部によって取得された新署名鍵に対応する特定データである新特定データを生成する生成部とを備えたことを特徴とする。
【発明の効果】
【００１１】
実施形態に係る名前解決システム及び鍵更新方法は、鍵の更新誤りを防止することができるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係る名前解決システムの構成例を示す図である。
【図２】図２は、実施例１に係る名前解決システムが有するキャッシュサーバの構成例を示す図である。
【図３】図３は、権威サーバ群が有する権威サーバの一例を示す図である。
【図４】図４は、ＤＮＳＳＥＣに用いられるゾーンデータの一例を示す図である。
【図５】図５は、実施例１に係る名前解決システムが実行する署名検証処理の一例を示すシーケンス図である。
【図６】図６は、実施例１に係る名前解決システムによる鍵更新処理の一例を示す図である。
【図７】図７は、実施例１における下位管理装置の構成例を示す図である。
【図８】図８は、実施例１における上位管理装置の構成例を示す図である。
【図９】図９は、実施例１に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１０】図１０は、実施例１に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１１】図１１は、実施例１における信頼の連鎖の一例を示す図である。
【図１２】図１２は、実施例１における信頼の連鎖の一例を示す図である。
【図１３】図１３は、実施例１における信頼の連鎖の一例を示す図である。
【図１４】図１４は、実施例１における信頼の連鎖の一例を示す図である。
【図１５】図１５は、実施例１における信頼の連鎖の一例を示す図である。
【図１６】図１６は、実施例２における上位管理装置の構成例を示す図である。
【図１７】図１７は、実施例２に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１８】図１８は、実施例２に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１９】図１９は、鍵更新プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１３】
以下に、本発明に係る名前解決システム及び鍵更新方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。
【実施例１】
【００１４】
まず、図１を用いて、実施例１に係る名前解決システムについて説明する。図１は、実施例１に係る名前解決システムの構成例を示す図である。図１に示す名前解決システム１は、クライアント装置１０、キャッシュサーバ２０、権威サーバ群３０、管理装置１１０、１２０及び１３０を有する。ここで、図１に示す各装置は、インターネットを介して通信可能な状態で接続される。
【００１５】
クライアント装置１０は、例えば、ＰＣ（Personal Computer）、携帯電話機、ＰＤＡ（Personal Digital Assistant）等であり、キャッシュサーバ２０に対して、名前解決の依頼を送信する。なお、図１では、キャッシュサーバ２０に接続されるクライアント装置１０を一台のみ示しているが、実際には、キャッシュサーバ２０には複数台のクライアント装置が接続される。
【００１６】
キャッシュサーバ２０は、クライアント装置１０から所定のドメイン名（例えば、「www.example.jp」）の名前解決の依頼を受け付ける。そして、キャッシュサーバ２０は、権威サーバ群３０に、依頼されたドメイン名の名前解決のための問い合わせを行うとともに、権威サーバ群３０からの応答をキャッシュする機能を有する。
【００１７】
権威サーバ群３０は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。図１に示した例では、権威サーバ群３０には、権威サーバ３１、３２及び３３が含まれる。なお、図１では、権威サーバ群３０に３台の権威サーバが含まれる例を示したが、権威サーバ群３０には、４台以上の権威サーバが含まれてもよい。
【００１８】
これらの権威サーバ３１、３２及び３３は、ＤＮＳＳＥＣのＤＳ（Delegation Signer）方式が適用されており、自身が管理するゾーンに関する情報に署名を行うための公開鍵及び秘密鍵のペアであるＺＳＫや、ＺＳＫに署名を行うための公開鍵及び秘密鍵のペアであるＫＳＫや、下位の権威サーバが保持するＫＳＫの公開鍵のハッシュ値であるＤＳレコード等を保持する。なお、以下では、各権威サーバが保持するＺＳＫ（公開鍵）、ＫＳＫ（公開鍵）、ＤＳレコード、及び、後述する「Ａ（Address）レコード」やＮＳレコード等を含むデータ群を「ゾーンデータ」と表記する場合がある。
【００１９】
管理装置１１０、１２０、１３０は、権威サーバ群３０のゾーンデータを管理するための装置である。図１に示した例では、管理装置１１０は、権威サーバ３１を管理するネットワーク管理者によって用いられる。実施例１における管理装置１１０は、権威サーバ３１が保持するＺＳＫ（公開鍵及び秘密鍵）やＫＳＫ（公開鍵及び秘密鍵）やＤＳレコード等のゾーンデータを保持しているものとする。そして、管理装置１１０は、ネットワーク管理者による指示に従って、かかるゾーンデータを更新し、更新後のゾーンデータを権威サーバ３１に反映する。また、管理装置１２０は、権威サーバ３２を管理するネットワーク管理者によって用いられ、権威サーバ３２のゾーンデータを更新及び反映する。また、管理装置１３０は、権威サーバ３３を管理するネットワーク管理者によって用いられ、権威サーバ３３のゾーンデータを更新及び反映する。
【００２０】
ここで、図２〜図５を用いて、キャッシュサーバ２０と権威サーバ群３０とにより実行されるＤＮＳＳＥＣの処理の一例を説明する。その後に、図６〜図１５を用いて、施例１における管理装置１１０、１２０、１３０について説明する。
【００２１】
図２は、実施例１に係る名前解決システム１が有するキャッシュサーバの構成例を示す図である。図２に例示するように、実施例１におけるキャッシュサーバ２０は、応答部２１と、検証部２２と、キャッシュ部２３と、要求部２４とを有する。
【００２２】
応答部２１は、クライアント装置１０との間で通信を行う。要求部２４は、権威サーバ群３０との間で通信を行う。また、要求部２４は、権威サーバ群から受信した応答データをキャッシュ部２３に格納する。検証部２２は、キャッシュ部２３に格納された権威サーバ群３０からの応答内容及び応答内容の電子署名を用いて検証を行う。キャッシュ部２３は、署名検証に成功した応答内容をキャッシュする。具体的には、キャッシュ部２３は、署名検証に成功した場合、名前解決を依頼されたドメイン名と、ドメイン名のＩＰアドレスとを対応付けた情報をキャッシュする。
【００２３】
ここで、応答部２１は、クライアント装置１０から名前解決を依頼された場合、依頼されたドメイン名のＩＰアドレスが、キャッシュ部２３にキャッシュ情報として既に格納されているか否かを判定する。応答部２１は、依頼されたドメイン名のＩＰアドレスがキャッシュ情報として既に格納されている場合、クライアント装置１０に対してＩＰアドレスを返信する。
【００２４】
一方、応答部２１は、依頼されたドメイン名のＩＰアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部２４に転送する。そして、要求部２４は、依頼内容に基づいて、権威サーバ群３０に問い合わせを行う。
【００２５】
ここで、図３を用いて、キャッシュサーバ２０が、クライアント装置１０からキャッシュ情報として格納されていない「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.サーバ３３は、自身が管理する名前空間の中にあるホスト、例えば、「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.サーバ３３及びキャッシュサーバ２０は、同一のハッシュ関数を用いてハッシュ値を計算する。また、ＤＳ方式では、下位の権威サーバは、上位の権威サーバに、自身のＫＳＫの公開鍵のハッシュ値であるＤＳレコードを予め通知している。すなわち、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.サーバ３２は、自身のＤＮＳＫＥＹ及び署名を返信する（ステップＳ１６）。すなわち、example.jp.サーバ３３は、図４（Ｂ）に示すデータ３２ｃ及びデータ３２ｄと、データ３２ｅとを返信する。
【００５０】
そして、要求部２４は、ルートサーバ３１にjp.サーバ３２のＤＳレコードを問い合わせ（ステップＳ１７）、ルートサーバ３１は、jp.サーバ３２のＤＳレコード及びＤＳレコードの署名を返信する（ステップＳ１８）。すなわち、ルートサーバ３１は、図４（Ｃ）に示すデータ３１ａ及びデータ３１ｂを返信する。
【００５１】
そして、要求部２４は、ルートサーバ３１にルートサーバ３１のＤＮＳＫＥＹを問い合わせ（ステップＳ１９）、ルートサーバ３１は、自身のＤＮＳＫＥＹ及び署名を返信する（ステップＳ２０）。すなわち、ルートサーバ３１は、図４（Ｃ）に示すデータ３１ｃ及びデータ３１ｄと、データ３１ｅとを返信する。
【００５２】
そして、要求部２４は、各権威サーバからの一連の応答データをキャッシュ部２３に格納し（ステップＳ２１）、検証部２２にキャッシュ部２３が記憶する応答データの署名検証を依頼する（ステップＳ２２）。
【００５３】
そして、検証部２２は、検証処理を行う（ステップＳ２３）。具体的には、検証部２２は、データ３１ｄのハッシュ値とデータ２３ａとを比較することにより、データ３１ｄの正当性を検証する。すなわち、検証部２２は、キャッシュ部２３が保持するＤＳレコードを用いてＫＳＫ−Ａ（公開鍵）の正当性を検証する。また、検証部２２は、データ３１ｃ及びデータ３１ｄのハッシュ値と、データ３１ｅをデータ３１ｄで復号した結果とを比較することにより、データ３１ｃ及びデータ３１ｄの正当性を検証する。また、検証部２２は、データ３１ａと、データ３１ｂをデータ３１ｃで復号した結果とを比較することにより、データ３１ａの正当性を検証する。
【００５４】
また、検証部２２は、データ３２ｄのハッシュ値とデータ３１ａとを比較することにより、データ３２ｄの正当性を検証する。すなわち、検証部２２は、ルートサーバ３１が保持するＤＳレコードを用いてＫＳＫ−Ｂ（公開鍵）の正当性を検証する。また、検証部２２は、データ３２ｃ及びデータ３２ｄのハッシュ値と、データ３２ｅをデータ３２ｄで復号した結果とを比較することにより、データ３２ｃ及びデータ３２ｄの正当性を検証する。さらに、検証部２２は、データ３２ａと、データ３２ｂをデータ３２ｃで復号した結果とを比較することにより、データ３２ａの正当性を検証する。
【００５５】
また、検証部２２は、データ３３ｄのハッシュ値とデータ３２ａとを比較することにより、データ３３ｄの正当性を検証する。すなわち、検証部２２は、jp.サーバ３２が保持するＤＳレコードを用いてＫＳＫ−Ｃ（公開鍵）の正当性を検証する。また、検証部２２は、データ３３ｃ及びデータ３３ｄのハッシュ値と、データ３３ｅをデータ３３ｄで復号した結果とを比較することにより、データ３３ｃ及びデータ３３ｄの正当性を検証する。さらに、検証部２２は、データ３３ａのハッシュ値と、データ３３ｂをデータ３３ｃで復号した結果とを比較することにより、データ３３ａの正当性を検証する。
【００５６】
そして、検証部２２は、全ての比較結果が一致する場合、権威サーバ群３０からの応答内容が正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部２１は、クライアント装置１０に対して、データ３３ａを返信する。一方、検証部２２は、全ての比較結果が一致しない場合、権威サーバ群３０からの応答内容が不当であり、署名検証が失敗したと判定する。
【００５７】
上述してきた各権威サーバ（example.jp.サーバ３３等）が保持するＫＳＫや、上位の権威サーバ（jp.サーバ３２等）が保持する当該ＫＳＫ（公開鍵）に対応するＤＳレコードは、定期的に更新されることが望ましい。しかし、異なる権威サーバに跨って保持されるＫＳＫ及びＤＳレコードをネットワーク管理者が更新する場合には、操作ミス等により、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されるおそれがある。ＫＳＫやＤＳレコードの登録ミスが発生した場合、キャッシュサーバ２０は、署名検証に失敗し、クライアント装置１０に対して、名前解決に失敗したことを示すエラーを返信することになる。
【００５８】
そこで、実施例１に係る名前解決システム１は、システム管理者によって新たなＫＳＫが登録された場合に、かかるＫＳＫに対応するＤＳレコードを自動生成することにより、相互の対応に誤りのないＫＳＫ及びＤＳレコードを各権威サーバに登録することを可能にする。この点について、図６を用いて簡単に説明する。図６は、実施例１に係る名前解決システム１による鍵更新処理の一例を示す図である。
【００５９】
なお、以下では、権威サーバ３２、権威サーバ３３、管理装置１２０及び管理装置１３０を例に挙げて、実施例１に係る名前解決システム１による鍵更新処理について説明する。また、以下では、権威サーバ３３に対して上位の権威サーバとなる権威サーバ３２を「上位権威サーバ３２」と表記し、権威サーバ３２に対して下位の権威サーバとなる権威サーバ３３を「下位権威サーバ３３」と表記する場合がある。また、上位権威サーバ３２を管理する管理装置１２０を「上位管理装置１２０」と表記し、下位権威サーバ３３を管理する管理装置１３０を「下位管理装置１３０」と表記する場合がある。
【００６０】
図６に示した例において、下位管理装置１３０は、下位権威サーバ３３によって行われる名前解決の結果に電子署名を付与する際に用いる署名鍵（ＫＳＫ等）を保持する。また、上位管理装置１２０は、下位管理装置１３０が保持する署名鍵（ＫＳＫ等）の正当性を検証する際に用いられるデータであって、かかる署名鍵（ＫＳＫ等）を特定するための特定データであるＤＳレコードを保持する。
【００６１】
このような下位管理装置１３０は、下位権威サーバ３３を管理するネットワーク管理者から、下位権威サーバ３３のＫＳＫを更新する操作を受け付ける（ステップＳ１０１）。例えば、下位管理装置１３０は、下位権威サーバ３３に格納する新たなＫＳＫをアップロードされる。なお、以下では、新たなＫＳＫを「新ＫＳＫ」と表記し、新ＫＳＫが登録される前の古いＫＳＫを「旧ＫＳＫ」と表記する場合がある。
【００６２】
下位管理装置１３０は、ネットワーク管理者から受け付けた新ＫＳＫを下位権威サーバ３３のゾーンデータに登録する（ステップＳ１０２）。そして、下位管理装置１３０は、下位権威サーバ３３のゾーンデータに新ＫＳＫを登録した後に、新ＫＳＫを登録した旨の登録通知を上位管理装置１２０に送信する（ステップＳ１０３）。
【００６３】
上位管理装置１２０は、下位管理装置１３０から新ＫＳＫの登録通知を受信した場合に、下位権威サーバ３３から新ＫＳＫの公開鍵を取得する（ステップＳ１０４）。そして、上位管理装置１２０は、下位権威サーバ３３から取得した新ＫＳＫの公開鍵のハッシュ値を計算することにより、新ＫＳＫの公開鍵に対応するＤＳレコードを生成する。なお、以下では、新ＫＳＫの公開鍵に対応するＤＳレコードを「新ＤＳレコード」と表記し、旧ＫＳＫの公開鍵に対応するＤＳレコードを「旧ＤＳレコード」と表記する場合がある。
【００６４】
そして、上位管理装置１２０は、新ＤＳレコードを上位権威サーバ３２に送信することにより、上位権威サーバ３２のゾーンデータに新ＤＳレコードを登録する（ステップＳ１０５）。
【００６５】
このように、実施例１に係る名前解決システム１では、下位権威サーバ３３に新ＫＳＫが登録された場合に、下位管理装置１３０が登録通知を上位管理装置１２０に送信する。そして、登録通知を受信した上位管理装置１２０が下位権威サーバ３３から新ＫＳＫの公開鍵を取得し、取得した新ＫＳＫの公開鍵から新ＤＳレコードを生成し、生成した新ＤＳレコードを上位権威サーバ３２に登録する。これにより、実施例１に係る名前解決システム１では、新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを自動的に更新するので、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されることを防止できる。
【００６６】
以下に、このような上位管理装置１２０や下位管理装置１３０について詳細に説明する。なお、ここでは説明を簡単にするために、下位管理装置１３０が下位管理装置に特化した処理部のみを有し、上位管理装置１２０が上位管理装置に特化した処理部のみを有するものとして説明する。ただし、実際には、上位管理装置１２０及び下位管理装置１３０は、互いに同様の処理部を有する。これは、上位管理装置１２０は、下位管理装置１３０に対して上位管理装置に該当するが、管理装置１１０に対しては下位管理装置に該当するからである。
【００６７】
まず、図７を用いて、下位管理装置１３０について説明する。図７は、実施例１における下位管理装置１３０の構成例を示す図である。図７に例示するように、実施例１における下位管理装置１３０は、受付部１３１と、更新部１３２と、通知部１３３とを有する。なお、図７では図示することを省略したが、下位管理装置１３０は、下位権威サーバ３３や上位管理装置１２０等との間で各種データを送受するためのＩＦ（interface）を有する。また、下位管理装置１３０は、各種情報や操作指示を入力するための入力部（キーボード、マウス等）や、各種情報を表示する表示デバイス（液晶表示装置等）を有してもよい。
【００６８】
受付部１３１は、ネットワーク管理者から入力部を介して各種操作を受け付ける。例えば、受付部１３１は、新ＫＳＫを受け付けるとともに、かかる新ＫＳＫを下位権威サーバ３３に登録する旨の操作を受け付ける。
【００６９】
更新部１３２は、下位権威サーバ３３が保持するゾーンデータ（ＫＳＫ等）を更新する。具体的には、更新部１３２は、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータを更新し、更新後のゾーンデータを下位権威サーバ３３に反映する。例えば、更新部１３２は、受付部１３１によって新ＫＳＫが受け付けられた場合に、下位権威サーバ３３のゾーンデータに新ＫＳＫを更新する。また、例えば、更新部１３２は、上位管理装置１２０から新ＤＳレコードが登録された旨の登録通知を受け付けた場合に、下位権威サーバ３３のゾーンデータから旧ＫＳＫを削除する。なお、更新部１３２によるゾーンデータの更新処理については、図９及び図１０を用いて詳述する。
【００７０】
通知部１３３は、更新部１３２によって下位権威サーバ３３のゾーンデータが更新された場合に、下位権威サーバ３３のゾーンデータが更新された旨を上位管理装置１２０に通知する。例えば、通知部１３３は、更新部１３２によって下位権威サーバ３３のゾーンデータに新ＫＳＫが登録された場合に、新ＫＳＫが登録された旨の登録通知を上位管理装置１２０に送信する。また、例えば、通知部１３３は、更新部１３２によって下位権威サーバ３３のゾーンデータから旧ＫＳＫが削除された場合に、旧ＫＳＫが削除された旨の削除通知を上位管理装置１２０に送信する。
【００７１】
次に、図８を用いて、上位管理装置１２０について説明する。図８は、実施例１における上位管理装置１２０の構成例を示す図である。図８に例示するように、実施例１における上位管理装置１２０は、取得部１２１と、検証部１２２と、生成部１２３と、更新部１２４と、通知部１２５とを有する。なお、図８では図示することを省略したが、上位管理装置１２０は、上位権威サーバ３２や下位権威サーバ３３や下位管理装置１３０等との間で各種データを送受するためのＩＦを有する。また、上位管理装置１２０は、各種情報や操作指示を入力するための入力部（キーボード、マウス等）や、各種情報を表示する表示デバイス（液晶表示装置等）を有してもよい。
【００７２】
取得部１２１は、下位権威サーバ３３からＤＮＳＫＥＹを取得する。具体的には、取得部１２１は、ＤＮＳプロトコルを用いて、下位権威サーバ３３に対してＤＮＳＫＥＹを問い合わせ、かかる問い合わせに応答した下位権威サーバ３３から送信されるＤＮＳＫＥＹを取得する。例えば、取得部１２１は、下位管理装置１３０の通知部１３３から、下位権威サーバ３３のゾーンデータが更新された旨を通知された場合に、下位権威サーバ３３からＤＮＳＫＥＹを取得する。
【００７３】
検証部１２２は、取得部１２１によって取得されたＤＮＳＫＥＹの署名検証を行う。なお、検証部１２２による処理については、図９及び図１０を用いて詳述する。
【００７４】
生成部１２３は、下位権威サーバ３３のゾーンデータに新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを生成する。具体的には、生成部１２３は、新ＫＳＫ（公開鍵）のハッシュ値を計算することにより、新ＫＳＫ（公開鍵）に対応する新ＤＳレコードを生成する。
【００７５】
更新部１２４は、上位権威サーバ３２が保持するゾーンデータ（ＤＳレコード等）を更新する。具体的には、更新部１２４は、上位管理装置１２０が保持する上位権威サーバ３２のゾーンデータを更新し、更新後のゾーンデータを上位権威サーバ３２に反映する。例えば、更新部１２４は、生成部１２３によって新ＤＳレコードが生成された場合に、上位権威サーバ３２のＺＳＫ（秘密鍵）を用いて、新ＤＳレコード及び旧ＤＳレコードを含むデータを暗号化することにより、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を生成する。そして、更新部１２４は、新ＤＳレコードと、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を上位権威サーバ３２のゾーンデータに登録する。また、例えば、更新部１２４は、下位権威サーバ３３のゾーンデータから旧ＫＳＫが削除された場合に、上位権威サーバ３２のゾーンデータから旧ＤＳレコードを削除する処理を行う。なお、更新部１２４によるゾーンデータの更新処理については、図９及び図１０を用いて詳述する。
【００７６】
通知部１２５は、更新部１２４によって上位権威サーバ３２のゾーンデータが更新された場合に、上位権威サーバ３２のゾーンデータが更新された旨を下位管理装置１３０に通知する。例えば、通知部１２５は、更新部１２４によって上位権威サーバ３２のゾーンデータに新ＤＳレコードが登録された場合に、新ＤＳレコードが登録された旨の登録通知を下位管理装置１３０に送信する。また、例えば、通知部１２５は、更新部１２４によって上位権威サーバ３２のゾーンデータから旧ＤＳレコードが削除された場合に、旧ＤＳレコードが削除された旨の削除通知を下位管理装置１３０に送信する。
【００７７】
次に、図９〜図１５を用いて、実施例１に係る名前解決システム１による鍵更新処理の手順について説明する。図９及び図１０は、実施例１に係る名前解決システム１による鍵更新処理手順を示すシーケンス図である。また、図１１〜図１５は、実施例１における信頼の連鎖の一例を示す図である。以下では、図１１〜図１５に示した信頼の連鎖の一例を用いながら、図９及び図１０に示したシーケンスについて説明する。
【００７８】
まず、図９及び図１０に示したシーケンスが開始される前において、各権威サーバにおける信頼の連鎖は図１１に示した状態であるものとする。具体的には、図１１に示すように、上位権威サーバ３２が保持するＫＳＫは、権威サーバ３１（図３に示した「ルートサーバ３１」であるものとする）が保持するＫＳＫによって信頼性が保証される。なお、ルートサーバ３１である権威サーバ３１は、「トラストアンカー」とも呼ばれる。
【００７９】
また、図１１に示すように、上位権威サーバ３２が保持するＺＳＫは、かかるＺＳＫに署名を行う上位権威サーバ３２のＫＳＫによって信頼性が保証される。また、上位権威サーバ３２は、下位権威サーバ３３のＫＳＫ（更新前のＫＳＫなので「旧ＫＳＫ」とする）に対応する旧ＤＳレコードを保持するが、かかる旧ＤＳレコードは、かかる旧ＤＳレコードに署名を行う上位権威サーバ３２のＺＳＫによって信頼性が保証される。
【００８０】
また、図１１に示すように、下位権威サーバ３３が保持する旧ＫＳＫは、上位権威サーバ３２が保持する旧ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、かかるＺＳＫに署名を行う下位権威サーバ３３の旧ＫＳＫによって信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、かかる一般データに署名を行う下位権威サーバ３３のＺＳＫによって信頼性が保証される。なお、ここでいう「一般データ」とは、「Ａレコード」や「ＡＡＡＡレコード」や「ＮＳレコード」等を示すものとする。
【００８１】
このような状態において、下位権威サーバ３３に新ＫＳＫが登録されたものとする。具体的には、図９に示すように、下位管理装置１３０は、下位権威サーバ３３に新たに登録するＫＳＫ（公開鍵及び秘密鍵）である新ＫＳＫを作成する（ステップＳ２０１）。なお、ここでは、下位管理装置１３０が新ＫＳＫを作成することとしたが、実際には、下位管理装置１３０の受付部１３１が、下位権威サーバ３３を管理するネットワーク管理者から新ＫＳＫを受け付けることにより、新ＫＳＫを作成することとなる。
【００８２】
続いて、下位管理装置１３０の更新部１３２は、新ＫＳＫ（秘密鍵）を用いて、下位権威サーバ３３の旧ＫＳＫ（公開鍵）とＺＳＫ（公開鍵）と新ＫＳＫ（公開鍵）とを含むＤＮＳＫＥＹの電子署名を作成する（ステップＳ２０２）。具体的には、更新部１３２は、下位権威サーバ３３のＤＮＳＫＥＹのハッシュ値を新ＫＳＫ（秘密鍵）で暗号化した電子署名を作成する。
【００８３】
また、更新部１３２は、下位権威サーバ３３の旧ＫＳＫ（秘密鍵）を用いて、下位権威サーバ３３の旧ＫＳＫ（公開鍵）とＺＳＫ（公開鍵）と新ＫＳＫ（公開鍵）とを含むＤＮＳＫＥＹの電子署名を作成する（ステップＳ２０３）。具体的には、更新部１３２は、下位権威サーバ３３のＤＮＳＫＥＹのハッシュ値を旧ＫＳＫ（秘密鍵）で暗号化した電子署名を作成する。なお、更新部１３２が旧ＫＳＫ（秘密鍵）を用いてＤＮＳＫＥＹの電子署名を作成する理由については後述する。
【００８４】
続いて、更新部１３２は、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータに対して、新ＫＳＫ（秘密鍵）を用いて作成したＤＮＳＫＥＹの電子署名（以下、「新電子署名」と表記する場合がある）と、旧ＫＳＫ（秘密鍵）を用いて作成したＤＮＳＫＥＹの電子署名（以下、「旧電子署名」と表記する場合がある）と、新ＫＳＫとを登録し、登録後のゾーンデータを下位権威サーバ３３に反映する（ステップＳ２０４）。
【００８５】
具体的には、更新部１３２による更新処理の前の状態では、下位権威サーバ３３のゾーンデータには、旧ＫＳＫ、ＺＳＫ、旧ＫＳＫ（公開鍵）及びＺＳＫ（公開鍵）の電子署名等が含まれる。更新部１３２は、かかるゾーンデータに新ＫＳＫを追加する。さらに、更新部１３２は、かかるゾーンデータにステップＳ２０２において作成した新電子署名と、ステップＳ２０３において作成した旧電子署名とを追加する。このようにして、更新部１３２は、下位権威サーバ３３のゾーンデータを更新する。なお、更新部１３２は、ゾーンデータから旧ＫＳＫ（公開鍵）及びＺＳＫ（公開鍵）の電子署名を削除してもよい。
【００８６】
なお、更新部１３２は、この段階では旧ＫＳＫを削除しない。これは、新ＫＳＫに対応する新ＤＳレコードが上位権威サーバ３２に登録されていないので、旧ＫＳＫを削除した場合には信頼の連鎖を構築することができないからである。言い換えれば、実施例１における更新部１３２は、この段階において旧ＫＳＫを削除しないことで、信頼の連鎖を構築することを可能にする。
【００８７】
続いて、下位管理装置１３０の通知部１３３は、下位権威サーバ３３のゾーンデータに新ＫＳＫが登録された旨の登録通知を上位管理装置１２０に送信する（ステップＳ２０５）。このとき、通知部１３３は、ＤＮＳプロトコルを用いて、ＤＳレコードを問い合わせる形式により登録通知を上位管理装置１２０に送信してもよいし、ＤＮＳ Ｎｏｔｉｆｙにより登録通知を上位管理装置１２０に送信してもよい。
【００８８】
この段階においては、各権威サーバにおける信頼の連鎖は図１１に示した状態から図１２に示した状態に変化する。なお、図１１に示した「トラストアンカー」と「ＫＳＫ（上位ゾーン：権威サーバ３１）」との間における信頼性の保証、及び、「ＫＳＫ（上位ゾーン：権威サーバ３１）」と「ＺＳＫ（上位ゾーン：権威サーバ３１）」との間における信頼性の保証については変化しないので、以下では説明を省略する。
【００８９】
具体的には、図１２に示すように、上位権威サーバ３２が保持する旧ＤＳレコードは、図１１に示した例と同様に、上位権威サーバ３２のＺＳＫによって信頼性が保証される。また、下位権威サーバ３３が保持する旧ＫＳＫは、図１１に示した例と同様に、上位権威サーバ３２が保持する旧ＤＳレコードによって信頼性が保証される。
【００９０】
また、図１２に示すように、下位権威サーバ３３が保持するＺＳＫは、かかるＺＳＫに署名を行う下位権威サーバ３３の新ＫＳＫによって信頼性が保証されるとともに、下位権威サーバ３３の旧ＫＳＫによっても信頼性が保証される。これは、ステップＳ２０２において新ＫＳＫを用いてＤＮＳＫＥＹの電子署名が作成され、ステップＳ２０３において旧ＫＳＫを用いてＤＮＳＫＥＹの電子署名が作成されたからである。さらに、下位権威サーバ３３が保持する一般データは、図１１に示した例と同様に、下位権威サーバ３３のＺＳＫによって信頼性が保証される。図１２に示したように、実施例１に係る名前解決システム１では、新ＫＳＫが登録された段階で旧ＫＳＫを削除しないので、信頼の連鎖を実現することができる。
【００９１】
図９の説明に戻って、上位管理装置１２０の取得部１２１は、下位管理装置１３０の通知部１３３から登録通知を受信した場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ２０６）。下位権威サーバ３３は、かかる問い合わせに応答して、自身が保持するＤＮＳＫＥＹと、ＤＮＳＫＥＹの電子署名を上位管理装置１２０に送信する（ステップＳ２０７）。これにより、取得部１２１は、下位権威サーバ３３のＤＮＳＫＥＹとして、ＺＳＫ（公開鍵）、旧ＫＳＫ（公開鍵）及び新ＫＳＫ（公開鍵）を取得し、ＤＮＳＫＥＹの電子署名として、旧電子署名及び新電子署名を取得する。
【００９２】
続いて、上位管理装置１２０の検証部１２２は、取得部１２１によって取得されたＤＮＳＫＥＹの署名検証を行う。具体的には、検証部１２２は、ＤＮＳＫＥＹに含まれる旧ＫＳＫ（公開鍵）のハッシュ値を計算し、計算した旧ＫＳＫ（公開鍵）のハッシュ値と、かかる旧ＫＳＫ（公開鍵）に対応する旧ＤＳレコードとを比較することにより、旧ＫＳＫ（公開鍵）の正当性を検証する（ステップＳ２０８）。
【００９３】
続いて、検証部１２２は、旧ＫＳＫ（公開鍵）の署名検証が成功した場合に、かかる旧ＫＳＫ（公開鍵）を用いて、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行う（ステップＳ２０９）。具体的には、検証部１２２は、下位権威サーバ３３から取得したＤＮＳＫＥＹのハッシュ値と、旧電子署名を旧ＫＳＫ（公開鍵）により復号した結果とを比較することにより、ＤＮＳＫＥＹ全体の正当性を検証する。
【００９４】
このように、上位権威サーバ３２が下位権威サーバ３３の旧ＫＳＫ（公開鍵）に対応する旧ＤＳレコードを保持するので、検証部１２２は、旧ＫＳＫ（公開鍵）の正当性を検証することができる。さらに、下位管理装置１３０が旧ＫＳＫ（秘密鍵）を用いてＤＮＳＫＥＹの旧電子署名を作成することにより、検証部１２２は、旧ＫＳＫ（公開鍵）を用いて、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行うことができる。言い換えれば、下位管理装置１３０がステップＳ２０４の段階において旧ＫＳＫを削除しないことにより、検証部１２２は、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行うことが可能になる。
【００９５】
続いて、上位管理装置１２０の生成部１２３は、検証部１２２によるＤＮＳＫＥＹ全体の署名検証が成功した場合に、かかるＤＮＳＫＥＹに含まれる新ＫＳＫ（公開鍵）に対応する新ＤＳレコードを生成する（ステップＳ２１０）。具体的には、生成部１２３は、新ＫＳＫ（公開鍵）のハッシュ値を計算することにより、新ＤＳレコードを生成する。
【００９６】
続いて、上位管理装置１２０の更新部１２４は、生成部１２３によって生成された新ＤＳレコードと、旧ＤＳレコードとに対応する電子署名を作成する（ステップＳ２１１）。具体的には、更新部１２４は、上位権威サーバ３２のＺＳＫ（秘密鍵）により、新ＤＳレコードと旧ＤＳレコードとを統合したデータのハッシュ値を暗号化することで、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を作成する。このように、更新部１２４は、複数のＤＳレコードが存在する場合には、かかる複数のＤＳレコードを統合したデータに対して１つの電子署名を作成する。
【００９７】
続いて、更新部１２４は、上位管理装置１２０が保持する上位権威サーバ３２のゾーンデータに対して、生成部１２３によって生成された新ＤＳレコードと、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名とを登録し、登録後のゾーンデータを上位権威サーバ３２に反映する（ステップＳ２１２）。
【００９８】
具体的には、更新部１２４による更新処理の前の状態では、上位権威サーバ３２のゾーンデータには、ＫＳＫ，ＺＳＫ、旧ＤＳデータ、旧ＤＳデータの電子署名等が含まれる。更新部１２４は、かかるゾーンデータに新ＤＳデータとステップＳ２１１において作成した電子署名とを追加する。このようにして、更新部１２４は、上位権威サーバ３２のゾーンデータを更新する。なお、更新部１２４は、ゾーンデータから旧ＤＳデータの電子署名を削除してもよい。
【００９９】
続いて、上位管理装置１２０の通知部１２５は、上位権威サーバ３２のゾーンデータに新ＤＳレコードが登録された旨の登録通知を下位管理装置１３０に送信する（ステップＳ２１３）。このとき、通知部１２５は、ＤＮＳプロトコルを用いて、ＤＳレコードを問い合わせる形式により登録通知を下位管理装置１３０に送信してもよいし、ＤＮＳ Ｎｏｔｉｆｙにより登録通知を下位管理装置１３０に送信してもよい。
【０１００】
この段階においては、各権威サーバにおける信頼の連鎖は図１２に示した状態から図１３に示した状態に変化する。具体的には、図１３に示すように、上位権威サーバ３２が保持する旧ＤＳレコード及び新ＤＳレコードは、上位権威サーバ３２のＺＳＫによって信頼性が保証される。これは、ステップＳ２１１において上位権威サーバ３２のＺＳＫを用いて、新ＤＳレコード及び旧ＤＳレコードの電子署名が作成されたからである。
【０１０１】
また、図１３に示すように、下位権威サーバ３３が保持する旧ＫＳＫは、図１２に示した例と同様に、上位権威サーバ３２が保持する旧ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持する新ＫＳＫは、上位権威サーバ３２が保持する新ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、図１２に示した例と同様に、下位権威サーバ３３の新ＫＳＫによって信頼性が保証されるとともに、下位権威サーバ３３の旧ＫＳＫによっても信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、図１２に示した例と同様に、下位権威サーバ３３のＺＳＫによって信頼性が保証される。
【０１０２】
続いて、図１０に示すように、下位管理装置１３０の更新部１３２は、上位管理装置１２０の通知部１２５から登録通知を受信した場合に、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータから旧ＫＳＫを削除する（ステップＳ２１４）。
【０１０３】
続いて、更新部１３２は、新ＫＳＫを用いて、下位権威サーバ３３のＺＳＫ（公開鍵）と新ＫＳＫ（公開鍵）とを含むＤＮＳＫＥＹの電子署名を作成する（ステップＳ２１５）。すなわち、更新部１３２は、ＤＮＳＫＥＹから旧ＫＳＫを削除したので、かかるＤＮＳＫＥＹの電子署名を新たに作成する。
【０１０４】
続いて、更新部１３２は、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータに対して、ステップＳ２１５において作成したＤＮＳＫＥＹの電子署名を登録し、登録後のゾーンデータを下位権威サーバ３３に反映する（ステップＳ２１６）。
【０１０５】
続いて、下位管理装置１３０の通知部１３３は、ＤＮＳプロトコルを用いて、下位権威サーバ３３のゾーンデータから旧ＫＳＫが削除された旨の削除通知を上位管理装置１２０に送信する（ステップＳ２１７）。
【０１０６】
この段階においては、各権威サーバにおける信頼の連鎖は図１３に示した状態から図１４に示した状態に変化する。具体的には、図１４に示すように、上位権威サーバ３２が保持する旧ＤＳレコード及び新ＤＳレコードは、図１３に示した例と同様に、上位権威サーバ３２のＺＳＫによって信頼性が保証される。また、図１４に示すように、下位権威サーバ３３が保持する新ＫＳＫは、図１３に示した例と同様に、上位権威サーバ３２が保持する新ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、下位権威サーバ３３の新ＫＳＫのみによって信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、図１３に示した例と同様に、下位権威サーバ３３のＺＳＫによって信頼性が保証される。すなわち、ステップＳ２１４において旧ＫＳＫが削除されたことによって、旧ＫＳＫによって信頼性が保証されることがなくなる。
【０１０７】
図１０の説明に戻って、上位管理装置１２０の取得部１２１は、下位管理装置１３０の通知部１３３から削除通知を受信した場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ２１８）。下位権威サーバ３３は、かかる問い合わせに応答して、自身が保持するＤＮＳＫＥＹと、ＤＮＳＫＥＹの電子署名を上位管理装置１２０に送信する（ステップＳ２１９）。これにより、取得部１２１は、下位権威サーバ３３のＤＮＳＫＥＹとして、ＺＳＫ（公開鍵）及び新ＫＳＫ（公開鍵）を取得するとともに、ステップＳ２１５において作成されたＤＮＳＫＥＹの電子署名を取得する。
【０１０８】
続いて、上位管理装置１２０の検証部１２２は、取得部１２１によって取得されたＤＮＳＫＥＹの署名検証を行う。具体的には、検証部１２２は、ＤＮＳＫＥＹに含まれる新ＫＳＫ（公開鍵）のハッシュ値を計算し、計算した新ＫＳＫ（公開鍵）のハッシュ値と、かかる新ＫＳＫ（公開鍵）に対応する新ＤＳレコードとを比較することにより、新ＫＳＫ（公開鍵）の正当性を検証する（ステップＳ２２０）。
【０１０９】
続いて、検証部１２２は、新ＫＳＫ（公開鍵）の署名検証が成功した場合に、かかる新ＫＳＫ（公開鍵）を用いて、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行う（ステップＳ２２１）。具体的には、検証部１２２は、下位権威サーバ３３から取得したＤＮＳＫＥＹのハッシュ値と、かかるＤＮＳＫＥＹの電子署名を新ＫＳＫ（公開鍵）により復号した結果とを比較することにより、ＤＮＳＫＥＹ全体の正当性を検証する。
【０１１０】
続いて、上位管理装置１２０の更新部１２４は、検証部１２２によるＤＮＳＫＥＹ全体の署名検証が成功した場合に、上位権威サーバ３２のゾーンデータから旧ＤＳレコードを削除する（ステップＳ２２２）。
【０１１１】
続いて、更新部１２４は、上位権威サーバ３２のＺＳＫ（秘密鍵）を用いて、新ＤＳレコードに対応する電子署名を作成する（ステップＳ２２３）。具体的には、上位権威サーバ３２のゾーンデータには新ＤＳレコード及び旧ＤＳレコードに対応する電子署名が登録されているが、更新部１２４は、旧ＤＳレコードを削除したので、新ＤＳレコードのみに対応する電子署名を作成し、作成した電子署名を上位権威サーバ３２のゾーンデータに追加する。このとき、更新部１２４は、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を削除してもよい。
【０１１２】
続いて、更新部１２４は、上位管理装置１２０が保持する上位権威サーバ３２のゾーンデータに対して、ステップＳ２２３において作成した電子署名を登録し、登録後のゾーンデータを上位権威サーバ３２に反映する（ステップＳ２２４）。
【０１１３】
続いて、上位管理装置１２０の通知部１２５は、ＤＮＳプロトコルを用いて、上位権威サーバ３２のゾーンデータから旧ＤＳレコードが削除された旨の削除通知を下位管理装置１３０に送信する（ステップＳ２２５）。
【０１１４】
これにより、各権威サーバにおける信頼の連鎖は図１４に示した状態から図１５に示した状態に変化する。具体的には、図１５に示すように、上位権威サーバ３２が保持する新ＤＳレコードは、上位権威サーバ３２のＺＳＫによって信頼性が保証される。また、下位権威サーバ３３が保持する新ＫＳＫは、上位権威サーバ３２が保持する新ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、下位権威サーバ３３の新ＫＳＫによって信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、下位権威サーバ３３のＺＳＫによって信頼性が保証される。このように、図１１と図１５とを比較すると、下位権威サーバ３３が保持する旧ＫＳＫが新ＫＳＫに更新されており、さらに、上位権威サーバ３２が保持する旧ＤＳレコードが新ＤＳレコードに更新されていることが分かる。
【０１１５】
上述してきたように、実施例１に係る名前解決システム１は、下位権威サーバ３３に新ＫＳＫが登録された場合に、下位管理装置１３０が登録通知を上位管理装置１２０に送信する。そして、登録通知を受信した上位管理装置１２０が下位権威サーバ３３から新ＫＳＫの公開鍵を取得し、取得した新ＫＳＫの公開鍵から新ＤＳレコードを生成し、生成した新ＤＳレコードを上位権威サーバ３２に登録する。これにより、実施例１に係る名前解決システム１では、新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを自動的に更新するので、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されることを防止できる。
【０１１６】
例えば、権威サーバが保持するＫＳＫ等を更新するために、ＥＰＰ（Extensible Provisioning Protocol）を用いることも考えられる。しかし、ＥＰＰを用いた場合であっても、ネットワーク管理者の操作ミスにより、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されるおそれがある。実施例１に係る名前解決システム１は、新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを自動生成するので、相互の対応に誤りのないＫＳＫ及びＤＳレコードを各権威サーバに登録することができる。
【０１１７】
また、ＥＰＰやＫＳＫ更新用の独自プロトコルを用いてＫＳＫ及びＤＳレコードを更新する場合には、ネットワーク管理者の操作ミスによる問題の他に、ＥＰＰや独自プロトコルの脆弱性を攻撃する攻撃者によって、不正なＫＳＫ及びＤＳレコードが各権威サーバに登録されるおそれがある。実施例１に係る名前解決システム１では、図９及び図１０を用いて説明したように、ＤＮＳプロトコルを用いる。ＤＮＳプロトコルは、枯れたプロトコルとも呼ばれており、ファイアフォール等のセキュリティ製品が充実している。このため、実施例１に係る名前解決システム１では、このようなセキュリティ製品が充実しているＤＮＳプロトコルを用いて各装置間で各種データを送受するので、攻撃者に攻撃されることを防止することができる。
【０１１８】
また、実施例１に係る名前解決システム１は、上位管理装置１２０において新ＤＳレコードが生成された後に、下位管理装置１３０が旧ＫＳＫを削除するので、信頼の連鎖が途切れる期間を発生させずに、ＫＳＫ及びＤＳレコードを更新することができる。
【０１１９】
また、実施例１に係る名前解決システム１は、図９のステップＳ２０８及びＳ２０９、図１０のステップＳ２２０及びＳ２２１を用いて説明したように、上位管理装置１２０が下位権威サーバ３３から取得したＤＮＳＫＥＹの正当性を検証するので、信頼性の高いＤＮＳＳＥＣを用いて、ＫＳＫ及びＤＳレコードを更新することができる。
【０１２０】
また、実施例１に係る名前解決システム１は、図１０のステップＳ２１７〜Ｓ２２２を用いて説明したように、下位管理装置１３０が旧ＫＳＫを削除した後に、上位管理装置１２０が旧ＤＳレコードを削除するので、下位管理装置１３０の管理者が新ＫＳＫを削除した場合や、新ＫＳＫの生成にミスがあった場合や、鍵更新処理中に下位管理装置１３０が故障した場合等でも、旧ＫＳＫ及び旧ＤＳレコードにより信頼の連鎖を維持することができる。
【０１２１】
具体的には、下位管理装置１３０の管理者は、誤った新ＫＳＫを登録した際に新ＫＳＫを削除したり、単なる操作ミスにより新ＫＳＫを削除したりすることが考えられる。実施例１に係る名前解決システム１では、旧ＫＳＫが削除されない限り、旧ＫＳＫに対応する旧ＤＳレコードが削除されないので、仮に新ＫＳＫが削除された場合であっても、信頼の連鎖を維持することができる。また、故障が発生した下位管理装置１３０をバックアップデータから復旧させた場合に、かかる下位管理装置１３０には、旧ＫＳＫしか登録されていない可能性がある。実施例１に係る名前解決システム１では、旧ＫＳＫが削除されない限り、旧ＫＳＫに対応する旧ＤＳレコードが削除されないので、仮に下位管理装置１３０に旧ＫＳＫしか登録されていない状態になったとしても、信頼の連鎖を維持することができる。
【実施例２】
【０１２２】
上記実施例１では、上位管理装置１２０が、下位管理装置１３０から新ＫＳＫの登録通知を受信した場合に、新ＫＳＫの取得処理や新ＤＳレコードの生成処理を行う例を示した。しかし、上位ゾーンを管理する上位権威サーバ３２の上位管理装置１２０は、複数の下位管理装置１３０から略同一のタイミングで新ＫＳＫの登録通知を受信する場合も考えられる。かかる場合に、上位管理装置１２０による処理負荷が増大するとも考えられる。そこで、上位管理装置１２０は、下位管理装置１３０から新ＫＳＫの登録通知を受信した場合であっても、所定の時間が経過した後に、新ＤＳレコードの生成処理等を行ってもよい。実施例２では、このような上位管理装置１２０について説明する。
【０１２３】
まず、図１６を用いて、実施例２における上位管理装置について説明する。図１６は、実施例２における上位管理装置の構成例を示す図である。なお、実施例２における下位管理装置１３０の構成は、図７に例示した構成と同様であるので、説明を省略する。また、以下では、既に示した構成部位と同様の機能を有する部位には同一符号を付すこととして、その詳細な説明を省略する。
【０１２４】
図１６に例示するように、実施例２における上位管理装置２２０は、待機通知部２２１を有する。待機通知部２２１は、下位管理装置１３０から、新ＫＳＫが登録された旨の登録通知や旧ＫＳＫが削除された旨の削除通知を受け付けた場合に、上位管理装置２２０の処理負荷が所定の閾値以上であるか否かを判定する。例えば、待機通知部２２１は、現在時刻を含む所定の時間内に、下位管理装置から受信した登録通知や削除通知の数が所定の閾値以上であるか否かを判定する。また、例えば、待機通知部２２１は、上位管理装置２２０のＣＰＵ負荷等が所定の閾値以上であるか否かを判定する。
【０１２５】
そして、待機通知部２２１は、上位管理装置２２０の処理負荷が所定の閾値以上である場合には、新ＤＳレコードの生成処理等を行う時刻（以下、「対応時刻」と表記する場合がある）を決定し、決定した対応時刻を下位管理装置１３０に通知する。そして、待機通知部２２１は、かかる対応時刻になるまで待機し、対応時刻となった場合に、取得部１２１に対してＤＮＳＫＥＹの取得処理を行うように指示する。
【０１２６】
次に、図１７及び図１８を用いて、実施例２に係る名前解決システム１による鍵更新処理の手順について説明する。図１７及び図１８は、実施例２に係る名前解決システム１による鍵更新処理手順を示すシーケンス図である。図１７に示したステップＳ３０１〜Ｓ３０５における処理手順は、図９に示したステップＳ２０１〜Ｓ２０５における処理手順と同様であるので、説明を省略する。
【０１２７】
図１７に示すように、実施例２における上位管理装置２２０の待機通知部２２１は、下位管理装置１３０の通知部１３３から登録通知を受信した場合に、上位管理装置２２０の処理負荷が所定の閾値以上であるか否かを判定する。ここでは、待機通知部２２１は、上位管理装置２２０の処理負荷が所定の閾値以上であると判定するものとする。かかる場合に、待機通知部２２１は、対応時刻を下位管理装置１３０に送信する（ステップＳ３０６）。そして、待機通知部２２１は、かかる対応時刻になるまで待機する（ステップＳ３０７）。
【０１２８】
続いて、上位管理装置２２０の取得部１２１は、待機通知部２２１によって決定された対応時刻になった場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ３０８）。なお、図１７に示したステップＳ３０８〜Ｓ３１４による処理手順は、図９に示したステップＳ２０６〜Ｓ２１２による処理手順と同様であるので、説明を省略する。
【０１２９】
続いて、下位管理装置１３０は、上位管理装置２２０の待機通知部２２１から受信した対応時刻になった場合に、ＤＮＳプロトコルを用いて、上位権威サーバ３２に対してＤＳレコードを問い合わせる（ステップＳ３１５）。上位権威サーバ３２は、かかる問い合わせに応答して、自身が保持するＤＳレコードを下位管理装置１３０に送信する（ステップＳ３１６）。これにより、下位管理装置１３０は、上位権威サーバ３２に新レコードが生成されたか否かを判定することができる。
【０１３０】
なお、図１７では、下位管理装置１３０が上位権威サーバ３２にＤＳレコードを問い合わせる例を示した。しかし、図９に示した例と同様に、上位管理装置２２０が、上位権威サーバ３２のゾーンデータに新ＤＳレコードが登録された旨の登録通知を下位管理装置１３０に送信してもよい（図９のステップＳ２１３参照）。ただし、図１７に示した例のように、下位管理装置１３０が、上位管理装置２２０を介さずに、上位権威サーバ３２にアクセスして新ＤＳレコードの生成有無を判定することで、上位管理装置２２０による処理負荷を低減することができる。すなわち、上位管理装置２２０が対応時刻を送信した場合には、上位管理装置２２０の処理負荷が増大しているとも言える。そこで、実施例２における下位管理装置１３０は、対応時刻を通知された場合には、上位管理装置２２０を介さずに新ＤＳレコードの生成有無を判定することで、上位管理装置２２０の処理負荷を低減することができる。
【０１３１】
続いて、図１８に示すように、下位管理装置１３０の更新部１３２は、上位権威サーバ３２に新ＤＳレコードが生成されている場合に、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータから旧ＫＳＫを削除する（ステップＳ３１７）。なお、図１８に示したステップＳ３１８〜Ｓ３２０における処理手順は、図１０に示したステップＳ２１５〜Ｓ２１７における処理手順と同様であるので、説明を省略する。
【０１３２】
続いて、上位管理装置２２０の待機通知部２２１は、下位管理装置１３０の通知部１３３から削除通知を受信した場合に、上位管理装置２２０の処理負荷が所定の閾値以上であるか否かを判定する。ここでは、待機通知部２２１は、上位管理装置２２０の処理負荷が所定の閾値以上であると判定するものとする。かかる場合に、待機通知部２２１は、対応時刻を下位管理装置１３０に送信する（ステップＳ３２１）。そして、待機通知部２２１は、かかる対応時刻になるまで待機する（ステップＳ３２２）。
【０１３３】
続いて、上位管理装置２２０の取得部１２１は、待機通知部２２１によって決定された対応時刻になった場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ３２３）。なお、図１８に示したステップＳ３２３〜Ｓ３２９による処理手順は、図１０に示したステップＳ２１８〜Ｓ２２４による処理手順と同様であるので、説明を省略する。
【０１３４】
続いて、下位管理装置１３０は、上位管理装置２２０の待機通知部２２１から受信した対応時刻になった場合に、ＤＮＳプロトコルを用いて、上位権威サーバ３２に対してＤＳレコードを問い合わせる（ステップＳ３３０）。上位権威サーバ３２は、かかる問い合わせに応答して、自身が保持するＤＳレコードを下位管理装置１３０に送信する（ステップＳ３３１）。これにより、下位管理装置１３０は、上位権威サーバ３２から旧レコードが削除されたか否かを判定することができる。上記例と同様に、下位管理装置１３０は、上位管理装置２２０を介さずに、上位権威サーバ３２にアクセスして旧ＤＳレコードの削除有無を判定することで、上位管理装置２２０による処理負荷を低減することができる。
【０１３５】
上述してきたように、実施例２に係る名前解決システム１は、上位管理装置１２０は、自身の処理負荷が高い場合に、所定の時間が経過した後に新ＤＳレコードの生成処理等を行う。これにより、実施例２に係る名前解決システム１は、複数の下位管理装置によって新ＫＳＫを登録する処理が所定時間に集中した場合であっても、上位管理装置１２０の処理負荷を一時的に増大させることなく、ＫＳＫ及びＤＳレコードを更新することができる。
【実施例３】
【０１３６】
ところで、本発明に係る名前解決システム及び鍵更新方法は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例３では、本発明に係る名前解決システム及び鍵更新方法の他の実施例について説明する。
【０１３７】
［処理主体］
上記実施例では、上位管理装置１２０と下位管理装置１３０とを分別して説明した。しかし、上述したように、上位管理装置１２０は下位管理装置となる場合もあり、下位管理装置１３０は上位管理装置となる場合もある。したがって、上述した各管理装置は、図７に示した各処理部と、図８に示した各処理部との双方を有する。なお、下位管理装置にしかなり得ない管理装置は、図７に示した各処理部のみを有してもよいし、上位管理装置にしかなり得ない管理装置は、図８に示した各処理部のみを有してもよい。
【０１３８】
また、上記実施例では、各権威サーバを管理装置によって管理する例を示した。しかし、権威サーバと管理装置とは一体化されてもよい。例えば、権威サーバ３１と管理装置１１０とが一体化されてもよいし、上位権威サーバ３２と上位管理装置１２０とが一体化されてもよい。すなわち、上記実施例では、権威サーバと管理装置とを分別して説明したが、本発明は、権威サーバと管理装置との双方を権威サーバとする場合にも適用することができる。
【０１３９】
［ＫＳＫの数］
また、上記実施例では、権威サーバが保持する旧ＫＳＫの数が１個である場合を例に挙げて説明した。しかし、本発明は、権威サーバが２個以上の旧ＫＳＫ保持する場合にも適用することができる。例えば、下位権威サーバ３３が２個の旧ＫＳＫを保持し、１個の新ＫＳＫが登録されたものとする。かかる場合には、下位権威サーバ３３は、３個のＫＳＫ（公開鍵）を含むＤＮＳＫＥＹを上位管理装置１２０に送信する。そして、上位管理装置１２０は、各ＫＳＫに対応する３個のＤＳレコードを保持することになる。
【０１４０】
［システム構成］
また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図４等に例示した各種情報は、あくまで一例であって任意の情報に変更することができる。
【０１４１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【０１４２】
［プログラム］
また、上記実施例において説明した上位管理装置１２０、下位管理装置１３０又は上位管理装置２２０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例１における上位管理装置１２０、下位管理装置１３０又は上位管理装置２２０が実行する処理をコンピュータが実行可能な言語で記述した鍵更新プログラムを作成することもできる。この場合、コンピュータが鍵更新プログラムを実行することにより、上記実施例と同様の効果を得ることができる。さらに、かかる鍵更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された鍵更新プログラムをコンピュータに読み込ませて実行することにより上記実施例と同様の処理を実現してもよい。以下に、図７及び図８に示した上位管理装置１２０及び下位管理装置１３０と同様の機能を実現する鍵更新プログラムを実行するコンピュータの一例を説明する。
【０１４３】
図１９は、鍵更新プログラムを実行するコンピュータ１０００を示す図である。図１９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。
【０１４４】
メモリ１０１０は、図１９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１９に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１９に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図１９に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１９に例示するように、例えばディスプレイ１０６１に接続される。
【０１４５】
ここで、図１９に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の鍵更新プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。例えば、図７に例示した受付部１３１、更新部１３２、通知部１３３、及び、図８に例示した取得部１２１、検証部１２２、生成部１２３、更新部１２４、通知部１２５と同様の情報処理を実行する処理手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。
【０１４６】
また、上記実施例で説明した上位管理装置１２０及び下位管理装置１３０が保持する各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。
【０１４７】
なお、鍵更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、鍵更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【０１４８】
１ 名前解決システム
２０ キャッシュサーバ
３０ 権威サーバ群
３１〜３３ 権威サーバ
１１０、１２０、１３０ 管理装置
１２１ 取得部
１２２ 検証部
１２３ 生成部
１２４ 更新部
１２５ 通知部
１３１ 受付部
１３２ 更新部
１３３ 通知部
２２１ 待機通知部
【技術分野】
【０００１】
本発明の実施形態は、名前解決システム及び鍵更新方法に関する。
【背景技術】
【０００２】
従来、ドメイン名とＩＰアドレス（Internet Protocol Address）とを対応させる名前管理システム（ＤＮＳ：Domain Name System）が知られている。ＤＮＳは、一般的には、権威サーバ群とキャッシュサーバとから構成される。権威サーバ群は、複数の権威サーバから構成され、各権威サーバは、名前空間の中にある特定のゾーンを管理する。キャッシュサーバは、クライアント装置からの名前解決の依頼に応じて、権威サーバ群に問い合わせを行うとともに、権威サーバ群からの応答をキャッシュ可能なサーバである。
【０００３】
また、近年、ＤＮＳの拡張仕様として、権威サーバ群からの応答の正当性を保証するＤＮＳＳＥＣ（ＤＮＳ Security Extensions）の普及が進められている。ＤＮＳＳＥＣにおいては、権威サーバ群からの応答の正当性を保証するために、電子署名を用いた検証（署名検証）が行われる。
【０００４】
例えば、ＤＮＳＳＥＣのＤＳ（Delegation Signer）方式が適用されている権威サーバ（権威サーバＡ１とする）は、権威サーバＡ１自身が管理するゾーンに関する情報に署名を行うための公開鍵及び秘密鍵のペアであるＺＳＫ（Zone Signing Key）を保持するとともに、ＺＳＫに署名を行うための公開鍵及び秘密鍵のペアであるＫＳＫ（Key Signing Key）を保持する。そして、かかる権威サーバＡ１は、権威サーバＡ１が管理するゾーンの上位のゾーンを管理する上位権威サーバ（上位権威サーバＡ２とする）に対して、ＫＳＫの公開鍵のハッシュ値であるＤＳレコードを予め通知する。
【０００５】
このような権威サーバＡ１は、キャッシュサーバから名前解決の依頼を受け付けた場合に、かかる依頼に対応する応答内容と、ＺＳＫ（秘密鍵）を用いて作成した応答内容の電子署名と、ＫＳＫ（秘密鍵）を用いて作成したＺＳＫ（公開鍵）の電子署名とをキャッシュサーバに送信する。そして、キャッシュサーバは、上位権威サーバＡ２が保持するＤＳレコードを用いて、権威サーバＡ１が保持するＫＳＫ（公開鍵）の署名検証を行う。また、キャッシュサーバは、署名検証済みのＫＳＫ（公開鍵）を用いて、ＺＳＫ（公開鍵）の署名検証を行う。そして、キャッシュサーバは、署名検証済みのＺＳＫ（公開鍵）を用いて、権威サーバＡ１から受信した応答内容の署名検証を行う。これにより、キャッシュサーバは、正当性が保証されたＩＰアドレスなどの応答データをクライアント装置に送信する。このように、ＤＮＳＳＥＣのＤＳ方式では、上位権威サーバが下位権威サーバのＫＳＫ（公開鍵）に対応するＤＳレコードを保持することで、「信頼の連鎖」を実現している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】“DNSSEC Operational Practices”、O.Kolkman、R.Gieben、RFC4641、［online］、［平成２３年５月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc4641.txt＞
【非特許文献２】“Domain Name System （DNS） Security Extensions Mapping for the Extensible Provisioning Protocol （EPP）”、J.Gould、S.Hollenbeck、RFC5910、［online］、［平成２３年５月２４日検索］、インターネット＜http://www.ietf.org/rfc/rfc5910.txt＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、ＤＮＳＳＥＣが適用されているＤＮＳにおいて、ネットワーク管理者は、ＺＳＫやＫＳＫを定期的に更新することが望ましい。これは、第三者によってＺＳＫやＫＳＫが解読されるおそれがあるからである。ここで、上位権威サーバが下位権威サーバのＫＳＫ（公開鍵）に対応するＤＳレコードを保持するので、下位権威サーバのネットワーク管理者は、かかる下位権威サーバが保持するＫＳＫを更新する場合に、上位権威サーバのＤＳレコードについても更新することを要する。
【０００８】
しかしながら、ネットワーク管理者が、更新対象のＫＳＫに対応するＤＳレコードを常に正しく更新できるとは限らない。例えば、ネットワーク管理者の操作ミス等により誤ったＤＳレコードが上位権威サーバに登録される場合もある。かかる場合には、キャッシュサーバは、署名検証に失敗し、クライアント装置に対して、名前解決に失敗したことを示すエラー（Server Failure）を返信することになる。
【０００９】
そこで、本発明は、上述した従来技術の課題を解決するためになされたものであり、鍵の更新誤りを防止することができる名前解決システム及び鍵更新方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
実施形態に係る名前解決システムは、名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第２の権威サーバとを含む名前解決システムであって、前記第１の権威サーバは、新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第２の権威サーバに通知する通知部を備え、前記第２の権威サーバは、前記通知部によって通知された場合に、前記第１の権威サーバから前記新署名鍵を取得する取得部と、前記取得部によって取得された新署名鍵に対応する特定データである新特定データを生成する生成部とを備えたことを特徴とする。
【発明の効果】
【００１１】
実施形態に係る名前解決システム及び鍵更新方法は、鍵の更新誤りを防止することができるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係る名前解決システムの構成例を示す図である。
【図２】図２は、実施例１に係る名前解決システムが有するキャッシュサーバの構成例を示す図である。
【図３】図３は、権威サーバ群が有する権威サーバの一例を示す図である。
【図４】図４は、ＤＮＳＳＥＣに用いられるゾーンデータの一例を示す図である。
【図５】図５は、実施例１に係る名前解決システムが実行する署名検証処理の一例を示すシーケンス図である。
【図６】図６は、実施例１に係る名前解決システムによる鍵更新処理の一例を示す図である。
【図７】図７は、実施例１における下位管理装置の構成例を示す図である。
【図８】図８は、実施例１における上位管理装置の構成例を示す図である。
【図９】図９は、実施例１に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１０】図１０は、実施例１に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１１】図１１は、実施例１における信頼の連鎖の一例を示す図である。
【図１２】図１２は、実施例１における信頼の連鎖の一例を示す図である。
【図１３】図１３は、実施例１における信頼の連鎖の一例を示す図である。
【図１４】図１４は、実施例１における信頼の連鎖の一例を示す図である。
【図１５】図１５は、実施例１における信頼の連鎖の一例を示す図である。
【図１６】図１６は、実施例２における上位管理装置の構成例を示す図である。
【図１７】図１７は、実施例２に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１８】図１８は、実施例２に係る名前解決システムによる鍵更新処理手順を示すシーケンス図である。
【図１９】図１９は、鍵更新プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１３】
以下に、本発明に係る名前解決システム及び鍵更新方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。
【実施例１】
【００１４】
まず、図１を用いて、実施例１に係る名前解決システムについて説明する。図１は、実施例１に係る名前解決システムの構成例を示す図である。図１に示す名前解決システム１は、クライアント装置１０、キャッシュサーバ２０、権威サーバ群３０、管理装置１１０、１２０及び１３０を有する。ここで、図１に示す各装置は、インターネットを介して通信可能な状態で接続される。
【００１５】
クライアント装置１０は、例えば、ＰＣ（Personal Computer）、携帯電話機、ＰＤＡ（Personal Digital Assistant）等であり、キャッシュサーバ２０に対して、名前解決の依頼を送信する。なお、図１では、キャッシュサーバ２０に接続されるクライアント装置１０を一台のみ示しているが、実際には、キャッシュサーバ２０には複数台のクライアント装置が接続される。
【００１６】
キャッシュサーバ２０は、クライアント装置１０から所定のドメイン名（例えば、「www.example.jp」）の名前解決の依頼を受け付ける。そして、キャッシュサーバ２０は、権威サーバ群３０に、依頼されたドメイン名の名前解決のための問い合わせを行うとともに、権威サーバ群３０からの応答をキャッシュする機能を有する。
【００１７】
権威サーバ群３０は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。図１に示した例では、権威サーバ群３０には、権威サーバ３１、３２及び３３が含まれる。なお、図１では、権威サーバ群３０に３台の権威サーバが含まれる例を示したが、権威サーバ群３０には、４台以上の権威サーバが含まれてもよい。
【００１８】
これらの権威サーバ３１、３２及び３３は、ＤＮＳＳＥＣのＤＳ（Delegation Signer）方式が適用されており、自身が管理するゾーンに関する情報に署名を行うための公開鍵及び秘密鍵のペアであるＺＳＫや、ＺＳＫに署名を行うための公開鍵及び秘密鍵のペアであるＫＳＫや、下位の権威サーバが保持するＫＳＫの公開鍵のハッシュ値であるＤＳレコード等を保持する。なお、以下では、各権威サーバが保持するＺＳＫ（公開鍵）、ＫＳＫ（公開鍵）、ＤＳレコード、及び、後述する「Ａ（Address）レコード」やＮＳレコード等を含むデータ群を「ゾーンデータ」と表記する場合がある。
【００１９】
管理装置１１０、１２０、１３０は、権威サーバ群３０のゾーンデータを管理するための装置である。図１に示した例では、管理装置１１０は、権威サーバ３１を管理するネットワーク管理者によって用いられる。実施例１における管理装置１１０は、権威サーバ３１が保持するＺＳＫ（公開鍵及び秘密鍵）やＫＳＫ（公開鍵及び秘密鍵）やＤＳレコード等のゾーンデータを保持しているものとする。そして、管理装置１１０は、ネットワーク管理者による指示に従って、かかるゾーンデータを更新し、更新後のゾーンデータを権威サーバ３１に反映する。また、管理装置１２０は、権威サーバ３２を管理するネットワーク管理者によって用いられ、権威サーバ３２のゾーンデータを更新及び反映する。また、管理装置１３０は、権威サーバ３３を管理するネットワーク管理者によって用いられ、権威サーバ３３のゾーンデータを更新及び反映する。
【００２０】
ここで、図２〜図５を用いて、キャッシュサーバ２０と権威サーバ群３０とにより実行されるＤＮＳＳＥＣの処理の一例を説明する。その後に、図６〜図１５を用いて、施例１における管理装置１１０、１２０、１３０について説明する。
【００２１】
図２は、実施例１に係る名前解決システム１が有するキャッシュサーバの構成例を示す図である。図２に例示するように、実施例１におけるキャッシュサーバ２０は、応答部２１と、検証部２２と、キャッシュ部２３と、要求部２４とを有する。
【００２２】
応答部２１は、クライアント装置１０との間で通信を行う。要求部２４は、権威サーバ群３０との間で通信を行う。また、要求部２４は、権威サーバ群から受信した応答データをキャッシュ部２３に格納する。検証部２２は、キャッシュ部２３に格納された権威サーバ群３０からの応答内容及び応答内容の電子署名を用いて検証を行う。キャッシュ部２３は、署名検証に成功した応答内容をキャッシュする。具体的には、キャッシュ部２３は、署名検証に成功した場合、名前解決を依頼されたドメイン名と、ドメイン名のＩＰアドレスとを対応付けた情報をキャッシュする。
【００２３】
ここで、応答部２１は、クライアント装置１０から名前解決を依頼された場合、依頼されたドメイン名のＩＰアドレスが、キャッシュ部２３にキャッシュ情報として既に格納されているか否かを判定する。応答部２１は、依頼されたドメイン名のＩＰアドレスがキャッシュ情報として既に格納されている場合、クライアント装置１０に対してＩＰアドレスを返信する。
【００２４】
一方、応答部２１は、依頼されたドメイン名のＩＰアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部２４に転送する。そして、要求部２４は、依頼内容に基づいて、権威サーバ群３０に問い合わせを行う。
【００２５】
ここで、図３を用いて、キャッシュサーバ２０が、クライアント装置１０からキャッシュ情報として格納されていない「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.サーバ３３は、自身が管理する名前空間の中にあるホスト、例えば、「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.サーバ３３及びキャッシュサーバ２０は、同一のハッシュ関数を用いてハッシュ値を計算する。また、ＤＳ方式では、下位の権威サーバは、上位の権威サーバに、自身のＫＳＫの公開鍵のハッシュ値であるＤＳレコードを予め通知している。すなわち、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.サーバ３２は、自身のＤＮＳＫＥＹ及び署名を返信する（ステップＳ１６）。すなわち、example.jp.サーバ３３は、図４（Ｂ）に示すデータ３２ｃ及びデータ３２ｄと、データ３２ｅとを返信する。
【００５０】
そして、要求部２４は、ルートサーバ３１にjp.サーバ３２のＤＳレコードを問い合わせ（ステップＳ１７）、ルートサーバ３１は、jp.サーバ３２のＤＳレコード及びＤＳレコードの署名を返信する（ステップＳ１８）。すなわち、ルートサーバ３１は、図４（Ｃ）に示すデータ３１ａ及びデータ３１ｂを返信する。
【００５１】
そして、要求部２４は、ルートサーバ３１にルートサーバ３１のＤＮＳＫＥＹを問い合わせ（ステップＳ１９）、ルートサーバ３１は、自身のＤＮＳＫＥＹ及び署名を返信する（ステップＳ２０）。すなわち、ルートサーバ３１は、図４（Ｃ）に示すデータ３１ｃ及びデータ３１ｄと、データ３１ｅとを返信する。
【００５２】
そして、要求部２４は、各権威サーバからの一連の応答データをキャッシュ部２３に格納し（ステップＳ２１）、検証部２２にキャッシュ部２３が記憶する応答データの署名検証を依頼する（ステップＳ２２）。
【００５３】
そして、検証部２２は、検証処理を行う（ステップＳ２３）。具体的には、検証部２２は、データ３１ｄのハッシュ値とデータ２３ａとを比較することにより、データ３１ｄの正当性を検証する。すなわち、検証部２２は、キャッシュ部２３が保持するＤＳレコードを用いてＫＳＫ−Ａ（公開鍵）の正当性を検証する。また、検証部２２は、データ３１ｃ及びデータ３１ｄのハッシュ値と、データ３１ｅをデータ３１ｄで復号した結果とを比較することにより、データ３１ｃ及びデータ３１ｄの正当性を検証する。また、検証部２２は、データ３１ａと、データ３１ｂをデータ３１ｃで復号した結果とを比較することにより、データ３１ａの正当性を検証する。
【００５４】
また、検証部２２は、データ３２ｄのハッシュ値とデータ３１ａとを比較することにより、データ３２ｄの正当性を検証する。すなわち、検証部２２は、ルートサーバ３１が保持するＤＳレコードを用いてＫＳＫ−Ｂ（公開鍵）の正当性を検証する。また、検証部２２は、データ３２ｃ及びデータ３２ｄのハッシュ値と、データ３２ｅをデータ３２ｄで復号した結果とを比較することにより、データ３２ｃ及びデータ３２ｄの正当性を検証する。さらに、検証部２２は、データ３２ａと、データ３２ｂをデータ３２ｃで復号した結果とを比較することにより、データ３２ａの正当性を検証する。
【００５５】
また、検証部２２は、データ３３ｄのハッシュ値とデータ３２ａとを比較することにより、データ３３ｄの正当性を検証する。すなわち、検証部２２は、jp.サーバ３２が保持するＤＳレコードを用いてＫＳＫ−Ｃ（公開鍵）の正当性を検証する。また、検証部２２は、データ３３ｃ及びデータ３３ｄのハッシュ値と、データ３３ｅをデータ３３ｄで復号した結果とを比較することにより、データ３３ｃ及びデータ３３ｄの正当性を検証する。さらに、検証部２２は、データ３３ａのハッシュ値と、データ３３ｂをデータ３３ｃで復号した結果とを比較することにより、データ３３ａの正当性を検証する。
【００５６】
そして、検証部２２は、全ての比較結果が一致する場合、権威サーバ群３０からの応答内容が正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部２１は、クライアント装置１０に対して、データ３３ａを返信する。一方、検証部２２は、全ての比較結果が一致しない場合、権威サーバ群３０からの応答内容が不当であり、署名検証が失敗したと判定する。
【００５７】
上述してきた各権威サーバ（example.jp.サーバ３３等）が保持するＫＳＫや、上位の権威サーバ（jp.サーバ３２等）が保持する当該ＫＳＫ（公開鍵）に対応するＤＳレコードは、定期的に更新されることが望ましい。しかし、異なる権威サーバに跨って保持されるＫＳＫ及びＤＳレコードをネットワーク管理者が更新する場合には、操作ミス等により、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されるおそれがある。ＫＳＫやＤＳレコードの登録ミスが発生した場合、キャッシュサーバ２０は、署名検証に失敗し、クライアント装置１０に対して、名前解決に失敗したことを示すエラーを返信することになる。
【００５８】
そこで、実施例１に係る名前解決システム１は、システム管理者によって新たなＫＳＫが登録された場合に、かかるＫＳＫに対応するＤＳレコードを自動生成することにより、相互の対応に誤りのないＫＳＫ及びＤＳレコードを各権威サーバに登録することを可能にする。この点について、図６を用いて簡単に説明する。図６は、実施例１に係る名前解決システム１による鍵更新処理の一例を示す図である。
【００５９】
なお、以下では、権威サーバ３２、権威サーバ３３、管理装置１２０及び管理装置１３０を例に挙げて、実施例１に係る名前解決システム１による鍵更新処理について説明する。また、以下では、権威サーバ３３に対して上位の権威サーバとなる権威サーバ３２を「上位権威サーバ３２」と表記し、権威サーバ３２に対して下位の権威サーバとなる権威サーバ３３を「下位権威サーバ３３」と表記する場合がある。また、上位権威サーバ３２を管理する管理装置１２０を「上位管理装置１２０」と表記し、下位権威サーバ３３を管理する管理装置１３０を「下位管理装置１３０」と表記する場合がある。
【００６０】
図６に示した例において、下位管理装置１３０は、下位権威サーバ３３によって行われる名前解決の結果に電子署名を付与する際に用いる署名鍵（ＫＳＫ等）を保持する。また、上位管理装置１２０は、下位管理装置１３０が保持する署名鍵（ＫＳＫ等）の正当性を検証する際に用いられるデータであって、かかる署名鍵（ＫＳＫ等）を特定するための特定データであるＤＳレコードを保持する。
【００６１】
このような下位管理装置１３０は、下位権威サーバ３３を管理するネットワーク管理者から、下位権威サーバ３３のＫＳＫを更新する操作を受け付ける（ステップＳ１０１）。例えば、下位管理装置１３０は、下位権威サーバ３３に格納する新たなＫＳＫをアップロードされる。なお、以下では、新たなＫＳＫを「新ＫＳＫ」と表記し、新ＫＳＫが登録される前の古いＫＳＫを「旧ＫＳＫ」と表記する場合がある。
【００６２】
下位管理装置１３０は、ネットワーク管理者から受け付けた新ＫＳＫを下位権威サーバ３３のゾーンデータに登録する（ステップＳ１０２）。そして、下位管理装置１３０は、下位権威サーバ３３のゾーンデータに新ＫＳＫを登録した後に、新ＫＳＫを登録した旨の登録通知を上位管理装置１２０に送信する（ステップＳ１０３）。
【００６３】
上位管理装置１２０は、下位管理装置１３０から新ＫＳＫの登録通知を受信した場合に、下位権威サーバ３３から新ＫＳＫの公開鍵を取得する（ステップＳ１０４）。そして、上位管理装置１２０は、下位権威サーバ３３から取得した新ＫＳＫの公開鍵のハッシュ値を計算することにより、新ＫＳＫの公開鍵に対応するＤＳレコードを生成する。なお、以下では、新ＫＳＫの公開鍵に対応するＤＳレコードを「新ＤＳレコード」と表記し、旧ＫＳＫの公開鍵に対応するＤＳレコードを「旧ＤＳレコード」と表記する場合がある。
【００６４】
そして、上位管理装置１２０は、新ＤＳレコードを上位権威サーバ３２に送信することにより、上位権威サーバ３２のゾーンデータに新ＤＳレコードを登録する（ステップＳ１０５）。
【００６５】
このように、実施例１に係る名前解決システム１では、下位権威サーバ３３に新ＫＳＫが登録された場合に、下位管理装置１３０が登録通知を上位管理装置１２０に送信する。そして、登録通知を受信した上位管理装置１２０が下位権威サーバ３３から新ＫＳＫの公開鍵を取得し、取得した新ＫＳＫの公開鍵から新ＤＳレコードを生成し、生成した新ＤＳレコードを上位権威サーバ３２に登録する。これにより、実施例１に係る名前解決システム１では、新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを自動的に更新するので、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されることを防止できる。
【００６６】
以下に、このような上位管理装置１２０や下位管理装置１３０について詳細に説明する。なお、ここでは説明を簡単にするために、下位管理装置１３０が下位管理装置に特化した処理部のみを有し、上位管理装置１２０が上位管理装置に特化した処理部のみを有するものとして説明する。ただし、実際には、上位管理装置１２０及び下位管理装置１３０は、互いに同様の処理部を有する。これは、上位管理装置１２０は、下位管理装置１３０に対して上位管理装置に該当するが、管理装置１１０に対しては下位管理装置に該当するからである。
【００６７】
まず、図７を用いて、下位管理装置１３０について説明する。図７は、実施例１における下位管理装置１３０の構成例を示す図である。図７に例示するように、実施例１における下位管理装置１３０は、受付部１３１と、更新部１３２と、通知部１３３とを有する。なお、図７では図示することを省略したが、下位管理装置１３０は、下位権威サーバ３３や上位管理装置１２０等との間で各種データを送受するためのＩＦ（interface）を有する。また、下位管理装置１３０は、各種情報や操作指示を入力するための入力部（キーボード、マウス等）や、各種情報を表示する表示デバイス（液晶表示装置等）を有してもよい。
【００６８】
受付部１３１は、ネットワーク管理者から入力部を介して各種操作を受け付ける。例えば、受付部１３１は、新ＫＳＫを受け付けるとともに、かかる新ＫＳＫを下位権威サーバ３３に登録する旨の操作を受け付ける。
【００６９】
更新部１３２は、下位権威サーバ３３が保持するゾーンデータ（ＫＳＫ等）を更新する。具体的には、更新部１３２は、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータを更新し、更新後のゾーンデータを下位権威サーバ３３に反映する。例えば、更新部１３２は、受付部１３１によって新ＫＳＫが受け付けられた場合に、下位権威サーバ３３のゾーンデータに新ＫＳＫを更新する。また、例えば、更新部１３２は、上位管理装置１２０から新ＤＳレコードが登録された旨の登録通知を受け付けた場合に、下位権威サーバ３３のゾーンデータから旧ＫＳＫを削除する。なお、更新部１３２によるゾーンデータの更新処理については、図９及び図１０を用いて詳述する。
【００７０】
通知部１３３は、更新部１３２によって下位権威サーバ３３のゾーンデータが更新された場合に、下位権威サーバ３３のゾーンデータが更新された旨を上位管理装置１２０に通知する。例えば、通知部１３３は、更新部１３２によって下位権威サーバ３３のゾーンデータに新ＫＳＫが登録された場合に、新ＫＳＫが登録された旨の登録通知を上位管理装置１２０に送信する。また、例えば、通知部１３３は、更新部１３２によって下位権威サーバ３３のゾーンデータから旧ＫＳＫが削除された場合に、旧ＫＳＫが削除された旨の削除通知を上位管理装置１２０に送信する。
【００７１】
次に、図８を用いて、上位管理装置１２０について説明する。図８は、実施例１における上位管理装置１２０の構成例を示す図である。図８に例示するように、実施例１における上位管理装置１２０は、取得部１２１と、検証部１２２と、生成部１２３と、更新部１２４と、通知部１２５とを有する。なお、図８では図示することを省略したが、上位管理装置１２０は、上位権威サーバ３２や下位権威サーバ３３や下位管理装置１３０等との間で各種データを送受するためのＩＦを有する。また、上位管理装置１２０は、各種情報や操作指示を入力するための入力部（キーボード、マウス等）や、各種情報を表示する表示デバイス（液晶表示装置等）を有してもよい。
【００７２】
取得部１２１は、下位権威サーバ３３からＤＮＳＫＥＹを取得する。具体的には、取得部１２１は、ＤＮＳプロトコルを用いて、下位権威サーバ３３に対してＤＮＳＫＥＹを問い合わせ、かかる問い合わせに応答した下位権威サーバ３３から送信されるＤＮＳＫＥＹを取得する。例えば、取得部１２１は、下位管理装置１３０の通知部１３３から、下位権威サーバ３３のゾーンデータが更新された旨を通知された場合に、下位権威サーバ３３からＤＮＳＫＥＹを取得する。
【００７３】
検証部１２２は、取得部１２１によって取得されたＤＮＳＫＥＹの署名検証を行う。なお、検証部１２２による処理については、図９及び図１０を用いて詳述する。
【００７４】
生成部１２３は、下位権威サーバ３３のゾーンデータに新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを生成する。具体的には、生成部１２３は、新ＫＳＫ（公開鍵）のハッシュ値を計算することにより、新ＫＳＫ（公開鍵）に対応する新ＤＳレコードを生成する。
【００７５】
更新部１２４は、上位権威サーバ３２が保持するゾーンデータ（ＤＳレコード等）を更新する。具体的には、更新部１２４は、上位管理装置１２０が保持する上位権威サーバ３２のゾーンデータを更新し、更新後のゾーンデータを上位権威サーバ３２に反映する。例えば、更新部１２４は、生成部１２３によって新ＤＳレコードが生成された場合に、上位権威サーバ３２のＺＳＫ（秘密鍵）を用いて、新ＤＳレコード及び旧ＤＳレコードを含むデータを暗号化することにより、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を生成する。そして、更新部１２４は、新ＤＳレコードと、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を上位権威サーバ３２のゾーンデータに登録する。また、例えば、更新部１２４は、下位権威サーバ３３のゾーンデータから旧ＫＳＫが削除された場合に、上位権威サーバ３２のゾーンデータから旧ＤＳレコードを削除する処理を行う。なお、更新部１２４によるゾーンデータの更新処理については、図９及び図１０を用いて詳述する。
【００７６】
通知部１２５は、更新部１２４によって上位権威サーバ３２のゾーンデータが更新された場合に、上位権威サーバ３２のゾーンデータが更新された旨を下位管理装置１３０に通知する。例えば、通知部１２５は、更新部１２４によって上位権威サーバ３２のゾーンデータに新ＤＳレコードが登録された場合に、新ＤＳレコードが登録された旨の登録通知を下位管理装置１３０に送信する。また、例えば、通知部１２５は、更新部１２４によって上位権威サーバ３２のゾーンデータから旧ＤＳレコードが削除された場合に、旧ＤＳレコードが削除された旨の削除通知を下位管理装置１３０に送信する。
【００７７】
次に、図９〜図１５を用いて、実施例１に係る名前解決システム１による鍵更新処理の手順について説明する。図９及び図１０は、実施例１に係る名前解決システム１による鍵更新処理手順を示すシーケンス図である。また、図１１〜図１５は、実施例１における信頼の連鎖の一例を示す図である。以下では、図１１〜図１５に示した信頼の連鎖の一例を用いながら、図９及び図１０に示したシーケンスについて説明する。
【００７８】
まず、図９及び図１０に示したシーケンスが開始される前において、各権威サーバにおける信頼の連鎖は図１１に示した状態であるものとする。具体的には、図１１に示すように、上位権威サーバ３２が保持するＫＳＫは、権威サーバ３１（図３に示した「ルートサーバ３１」であるものとする）が保持するＫＳＫによって信頼性が保証される。なお、ルートサーバ３１である権威サーバ３１は、「トラストアンカー」とも呼ばれる。
【００７９】
また、図１１に示すように、上位権威サーバ３２が保持するＺＳＫは、かかるＺＳＫに署名を行う上位権威サーバ３２のＫＳＫによって信頼性が保証される。また、上位権威サーバ３２は、下位権威サーバ３３のＫＳＫ（更新前のＫＳＫなので「旧ＫＳＫ」とする）に対応する旧ＤＳレコードを保持するが、かかる旧ＤＳレコードは、かかる旧ＤＳレコードに署名を行う上位権威サーバ３２のＺＳＫによって信頼性が保証される。
【００８０】
また、図１１に示すように、下位権威サーバ３３が保持する旧ＫＳＫは、上位権威サーバ３２が保持する旧ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、かかるＺＳＫに署名を行う下位権威サーバ３３の旧ＫＳＫによって信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、かかる一般データに署名を行う下位権威サーバ３３のＺＳＫによって信頼性が保証される。なお、ここでいう「一般データ」とは、「Ａレコード」や「ＡＡＡＡレコード」や「ＮＳレコード」等を示すものとする。
【００８１】
このような状態において、下位権威サーバ３３に新ＫＳＫが登録されたものとする。具体的には、図９に示すように、下位管理装置１３０は、下位権威サーバ３３に新たに登録するＫＳＫ（公開鍵及び秘密鍵）である新ＫＳＫを作成する（ステップＳ２０１）。なお、ここでは、下位管理装置１３０が新ＫＳＫを作成することとしたが、実際には、下位管理装置１３０の受付部１３１が、下位権威サーバ３３を管理するネットワーク管理者から新ＫＳＫを受け付けることにより、新ＫＳＫを作成することとなる。
【００８２】
続いて、下位管理装置１３０の更新部１３２は、新ＫＳＫ（秘密鍵）を用いて、下位権威サーバ３３の旧ＫＳＫ（公開鍵）とＺＳＫ（公開鍵）と新ＫＳＫ（公開鍵）とを含むＤＮＳＫＥＹの電子署名を作成する（ステップＳ２０２）。具体的には、更新部１３２は、下位権威サーバ３３のＤＮＳＫＥＹのハッシュ値を新ＫＳＫ（秘密鍵）で暗号化した電子署名を作成する。
【００８３】
また、更新部１３２は、下位権威サーバ３３の旧ＫＳＫ（秘密鍵）を用いて、下位権威サーバ３３の旧ＫＳＫ（公開鍵）とＺＳＫ（公開鍵）と新ＫＳＫ（公開鍵）とを含むＤＮＳＫＥＹの電子署名を作成する（ステップＳ２０３）。具体的には、更新部１３２は、下位権威サーバ３３のＤＮＳＫＥＹのハッシュ値を旧ＫＳＫ（秘密鍵）で暗号化した電子署名を作成する。なお、更新部１３２が旧ＫＳＫ（秘密鍵）を用いてＤＮＳＫＥＹの電子署名を作成する理由については後述する。
【００８４】
続いて、更新部１３２は、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータに対して、新ＫＳＫ（秘密鍵）を用いて作成したＤＮＳＫＥＹの電子署名（以下、「新電子署名」と表記する場合がある）と、旧ＫＳＫ（秘密鍵）を用いて作成したＤＮＳＫＥＹの電子署名（以下、「旧電子署名」と表記する場合がある）と、新ＫＳＫとを登録し、登録後のゾーンデータを下位権威サーバ３３に反映する（ステップＳ２０４）。
【００８５】
具体的には、更新部１３２による更新処理の前の状態では、下位権威サーバ３３のゾーンデータには、旧ＫＳＫ、ＺＳＫ、旧ＫＳＫ（公開鍵）及びＺＳＫ（公開鍵）の電子署名等が含まれる。更新部１３２は、かかるゾーンデータに新ＫＳＫを追加する。さらに、更新部１３２は、かかるゾーンデータにステップＳ２０２において作成した新電子署名と、ステップＳ２０３において作成した旧電子署名とを追加する。このようにして、更新部１３２は、下位権威サーバ３３のゾーンデータを更新する。なお、更新部１３２は、ゾーンデータから旧ＫＳＫ（公開鍵）及びＺＳＫ（公開鍵）の電子署名を削除してもよい。
【００８６】
なお、更新部１３２は、この段階では旧ＫＳＫを削除しない。これは、新ＫＳＫに対応する新ＤＳレコードが上位権威サーバ３２に登録されていないので、旧ＫＳＫを削除した場合には信頼の連鎖を構築することができないからである。言い換えれば、実施例１における更新部１３２は、この段階において旧ＫＳＫを削除しないことで、信頼の連鎖を構築することを可能にする。
【００８７】
続いて、下位管理装置１３０の通知部１３３は、下位権威サーバ３３のゾーンデータに新ＫＳＫが登録された旨の登録通知を上位管理装置１２０に送信する（ステップＳ２０５）。このとき、通知部１３３は、ＤＮＳプロトコルを用いて、ＤＳレコードを問い合わせる形式により登録通知を上位管理装置１２０に送信してもよいし、ＤＮＳ Ｎｏｔｉｆｙにより登録通知を上位管理装置１２０に送信してもよい。
【００８８】
この段階においては、各権威サーバにおける信頼の連鎖は図１１に示した状態から図１２に示した状態に変化する。なお、図１１に示した「トラストアンカー」と「ＫＳＫ（上位ゾーン：権威サーバ３１）」との間における信頼性の保証、及び、「ＫＳＫ（上位ゾーン：権威サーバ３１）」と「ＺＳＫ（上位ゾーン：権威サーバ３１）」との間における信頼性の保証については変化しないので、以下では説明を省略する。
【００８９】
具体的には、図１２に示すように、上位権威サーバ３２が保持する旧ＤＳレコードは、図１１に示した例と同様に、上位権威サーバ３２のＺＳＫによって信頼性が保証される。また、下位権威サーバ３３が保持する旧ＫＳＫは、図１１に示した例と同様に、上位権威サーバ３２が保持する旧ＤＳレコードによって信頼性が保証される。
【００９０】
また、図１２に示すように、下位権威サーバ３３が保持するＺＳＫは、かかるＺＳＫに署名を行う下位権威サーバ３３の新ＫＳＫによって信頼性が保証されるとともに、下位権威サーバ３３の旧ＫＳＫによっても信頼性が保証される。これは、ステップＳ２０２において新ＫＳＫを用いてＤＮＳＫＥＹの電子署名が作成され、ステップＳ２０３において旧ＫＳＫを用いてＤＮＳＫＥＹの電子署名が作成されたからである。さらに、下位権威サーバ３３が保持する一般データは、図１１に示した例と同様に、下位権威サーバ３３のＺＳＫによって信頼性が保証される。図１２に示したように、実施例１に係る名前解決システム１では、新ＫＳＫが登録された段階で旧ＫＳＫを削除しないので、信頼の連鎖を実現することができる。
【００９１】
図９の説明に戻って、上位管理装置１２０の取得部１２１は、下位管理装置１３０の通知部１３３から登録通知を受信した場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ２０６）。下位権威サーバ３３は、かかる問い合わせに応答して、自身が保持するＤＮＳＫＥＹと、ＤＮＳＫＥＹの電子署名を上位管理装置１２０に送信する（ステップＳ２０７）。これにより、取得部１２１は、下位権威サーバ３３のＤＮＳＫＥＹとして、ＺＳＫ（公開鍵）、旧ＫＳＫ（公開鍵）及び新ＫＳＫ（公開鍵）を取得し、ＤＮＳＫＥＹの電子署名として、旧電子署名及び新電子署名を取得する。
【００９２】
続いて、上位管理装置１２０の検証部１２２は、取得部１２１によって取得されたＤＮＳＫＥＹの署名検証を行う。具体的には、検証部１２２は、ＤＮＳＫＥＹに含まれる旧ＫＳＫ（公開鍵）のハッシュ値を計算し、計算した旧ＫＳＫ（公開鍵）のハッシュ値と、かかる旧ＫＳＫ（公開鍵）に対応する旧ＤＳレコードとを比較することにより、旧ＫＳＫ（公開鍵）の正当性を検証する（ステップＳ２０８）。
【００９３】
続いて、検証部１２２は、旧ＫＳＫ（公開鍵）の署名検証が成功した場合に、かかる旧ＫＳＫ（公開鍵）を用いて、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行う（ステップＳ２０９）。具体的には、検証部１２２は、下位権威サーバ３３から取得したＤＮＳＫＥＹのハッシュ値と、旧電子署名を旧ＫＳＫ（公開鍵）により復号した結果とを比較することにより、ＤＮＳＫＥＹ全体の正当性を検証する。
【００９４】
このように、上位権威サーバ３２が下位権威サーバ３３の旧ＫＳＫ（公開鍵）に対応する旧ＤＳレコードを保持するので、検証部１２２は、旧ＫＳＫ（公開鍵）の正当性を検証することができる。さらに、下位管理装置１３０が旧ＫＳＫ（秘密鍵）を用いてＤＮＳＫＥＹの旧電子署名を作成することにより、検証部１２２は、旧ＫＳＫ（公開鍵）を用いて、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行うことができる。言い換えれば、下位管理装置１３０がステップＳ２０４の段階において旧ＫＳＫを削除しないことにより、検証部１２２は、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行うことが可能になる。
【００９５】
続いて、上位管理装置１２０の生成部１２３は、検証部１２２によるＤＮＳＫＥＹ全体の署名検証が成功した場合に、かかるＤＮＳＫＥＹに含まれる新ＫＳＫ（公開鍵）に対応する新ＤＳレコードを生成する（ステップＳ２１０）。具体的には、生成部１２３は、新ＫＳＫ（公開鍵）のハッシュ値を計算することにより、新ＤＳレコードを生成する。
【００９６】
続いて、上位管理装置１２０の更新部１２４は、生成部１２３によって生成された新ＤＳレコードと、旧ＤＳレコードとに対応する電子署名を作成する（ステップＳ２１１）。具体的には、更新部１２４は、上位権威サーバ３２のＺＳＫ（秘密鍵）により、新ＤＳレコードと旧ＤＳレコードとを統合したデータのハッシュ値を暗号化することで、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を作成する。このように、更新部１２４は、複数のＤＳレコードが存在する場合には、かかる複数のＤＳレコードを統合したデータに対して１つの電子署名を作成する。
【００９７】
続いて、更新部１２４は、上位管理装置１２０が保持する上位権威サーバ３２のゾーンデータに対して、生成部１２３によって生成された新ＤＳレコードと、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名とを登録し、登録後のゾーンデータを上位権威サーバ３２に反映する（ステップＳ２１２）。
【００９８】
具体的には、更新部１２４による更新処理の前の状態では、上位権威サーバ３２のゾーンデータには、ＫＳＫ，ＺＳＫ、旧ＤＳデータ、旧ＤＳデータの電子署名等が含まれる。更新部１２４は、かかるゾーンデータに新ＤＳデータとステップＳ２１１において作成した電子署名とを追加する。このようにして、更新部１２４は、上位権威サーバ３２のゾーンデータを更新する。なお、更新部１２４は、ゾーンデータから旧ＤＳデータの電子署名を削除してもよい。
【００９９】
続いて、上位管理装置１２０の通知部１２５は、上位権威サーバ３２のゾーンデータに新ＤＳレコードが登録された旨の登録通知を下位管理装置１３０に送信する（ステップＳ２１３）。このとき、通知部１２５は、ＤＮＳプロトコルを用いて、ＤＳレコードを問い合わせる形式により登録通知を下位管理装置１３０に送信してもよいし、ＤＮＳ Ｎｏｔｉｆｙにより登録通知を下位管理装置１３０に送信してもよい。
【０１００】
この段階においては、各権威サーバにおける信頼の連鎖は図１２に示した状態から図１３に示した状態に変化する。具体的には、図１３に示すように、上位権威サーバ３２が保持する旧ＤＳレコード及び新ＤＳレコードは、上位権威サーバ３２のＺＳＫによって信頼性が保証される。これは、ステップＳ２１１において上位権威サーバ３２のＺＳＫを用いて、新ＤＳレコード及び旧ＤＳレコードの電子署名が作成されたからである。
【０１０１】
また、図１３に示すように、下位権威サーバ３３が保持する旧ＫＳＫは、図１２に示した例と同様に、上位権威サーバ３２が保持する旧ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持する新ＫＳＫは、上位権威サーバ３２が保持する新ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、図１２に示した例と同様に、下位権威サーバ３３の新ＫＳＫによって信頼性が保証されるとともに、下位権威サーバ３３の旧ＫＳＫによっても信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、図１２に示した例と同様に、下位権威サーバ３３のＺＳＫによって信頼性が保証される。
【０１０２】
続いて、図１０に示すように、下位管理装置１３０の更新部１３２は、上位管理装置１２０の通知部１２５から登録通知を受信した場合に、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータから旧ＫＳＫを削除する（ステップＳ２１４）。
【０１０３】
続いて、更新部１３２は、新ＫＳＫを用いて、下位権威サーバ３３のＺＳＫ（公開鍵）と新ＫＳＫ（公開鍵）とを含むＤＮＳＫＥＹの電子署名を作成する（ステップＳ２１５）。すなわち、更新部１３２は、ＤＮＳＫＥＹから旧ＫＳＫを削除したので、かかるＤＮＳＫＥＹの電子署名を新たに作成する。
【０１０４】
続いて、更新部１３２は、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータに対して、ステップＳ２１５において作成したＤＮＳＫＥＹの電子署名を登録し、登録後のゾーンデータを下位権威サーバ３３に反映する（ステップＳ２１６）。
【０１０５】
続いて、下位管理装置１３０の通知部１３３は、ＤＮＳプロトコルを用いて、下位権威サーバ３３のゾーンデータから旧ＫＳＫが削除された旨の削除通知を上位管理装置１２０に送信する（ステップＳ２１７）。
【０１０６】
この段階においては、各権威サーバにおける信頼の連鎖は図１３に示した状態から図１４に示した状態に変化する。具体的には、図１４に示すように、上位権威サーバ３２が保持する旧ＤＳレコード及び新ＤＳレコードは、図１３に示した例と同様に、上位権威サーバ３２のＺＳＫによって信頼性が保証される。また、図１４に示すように、下位権威サーバ３３が保持する新ＫＳＫは、図１３に示した例と同様に、上位権威サーバ３２が保持する新ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、下位権威サーバ３３の新ＫＳＫのみによって信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、図１３に示した例と同様に、下位権威サーバ３３のＺＳＫによって信頼性が保証される。すなわち、ステップＳ２１４において旧ＫＳＫが削除されたことによって、旧ＫＳＫによって信頼性が保証されることがなくなる。
【０１０７】
図１０の説明に戻って、上位管理装置１２０の取得部１２１は、下位管理装置１３０の通知部１３３から削除通知を受信した場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ２１８）。下位権威サーバ３３は、かかる問い合わせに応答して、自身が保持するＤＮＳＫＥＹと、ＤＮＳＫＥＹの電子署名を上位管理装置１２０に送信する（ステップＳ２１９）。これにより、取得部１２１は、下位権威サーバ３３のＤＮＳＫＥＹとして、ＺＳＫ（公開鍵）及び新ＫＳＫ（公開鍵）を取得するとともに、ステップＳ２１５において作成されたＤＮＳＫＥＹの電子署名を取得する。
【０１０８】
続いて、上位管理装置１２０の検証部１２２は、取得部１２１によって取得されたＤＮＳＫＥＹの署名検証を行う。具体的には、検証部１２２は、ＤＮＳＫＥＹに含まれる新ＫＳＫ（公開鍵）のハッシュ値を計算し、計算した新ＫＳＫ（公開鍵）のハッシュ値と、かかる新ＫＳＫ（公開鍵）に対応する新ＤＳレコードとを比較することにより、新ＫＳＫ（公開鍵）の正当性を検証する（ステップＳ２２０）。
【０１０９】
続いて、検証部１２２は、新ＫＳＫ（公開鍵）の署名検証が成功した場合に、かかる新ＫＳＫ（公開鍵）を用いて、下位権威サーバ３３から取得したＤＮＳＫＥＹ全体の署名検証を行う（ステップＳ２２１）。具体的には、検証部１２２は、下位権威サーバ３３から取得したＤＮＳＫＥＹのハッシュ値と、かかるＤＮＳＫＥＹの電子署名を新ＫＳＫ（公開鍵）により復号した結果とを比較することにより、ＤＮＳＫＥＹ全体の正当性を検証する。
【０１１０】
続いて、上位管理装置１２０の更新部１２４は、検証部１２２によるＤＮＳＫＥＹ全体の署名検証が成功した場合に、上位権威サーバ３２のゾーンデータから旧ＤＳレコードを削除する（ステップＳ２２２）。
【０１１１】
続いて、更新部１２４は、上位権威サーバ３２のＺＳＫ（秘密鍵）を用いて、新ＤＳレコードに対応する電子署名を作成する（ステップＳ２２３）。具体的には、上位権威サーバ３２のゾーンデータには新ＤＳレコード及び旧ＤＳレコードに対応する電子署名が登録されているが、更新部１２４は、旧ＤＳレコードを削除したので、新ＤＳレコードのみに対応する電子署名を作成し、作成した電子署名を上位権威サーバ３２のゾーンデータに追加する。このとき、更新部１２４は、新ＤＳレコード及び旧ＤＳレコードに対応する電子署名を削除してもよい。
【０１１２】
続いて、更新部１２４は、上位管理装置１２０が保持する上位権威サーバ３２のゾーンデータに対して、ステップＳ２２３において作成した電子署名を登録し、登録後のゾーンデータを上位権威サーバ３２に反映する（ステップＳ２２４）。
【０１１３】
続いて、上位管理装置１２０の通知部１２５は、ＤＮＳプロトコルを用いて、上位権威サーバ３２のゾーンデータから旧ＤＳレコードが削除された旨の削除通知を下位管理装置１３０に送信する（ステップＳ２２５）。
【０１１４】
これにより、各権威サーバにおける信頼の連鎖は図１４に示した状態から図１５に示した状態に変化する。具体的には、図１５に示すように、上位権威サーバ３２が保持する新ＤＳレコードは、上位権威サーバ３２のＺＳＫによって信頼性が保証される。また、下位権威サーバ３３が保持する新ＫＳＫは、上位権威サーバ３２が保持する新ＤＳレコードによって信頼性が保証される。また、下位権威サーバ３３が保持するＺＳＫは、下位権威サーバ３３の新ＫＳＫによって信頼性が保証される。さらに、下位権威サーバ３３が保持する一般データは、下位権威サーバ３３のＺＳＫによって信頼性が保証される。このように、図１１と図１５とを比較すると、下位権威サーバ３３が保持する旧ＫＳＫが新ＫＳＫに更新されており、さらに、上位権威サーバ３２が保持する旧ＤＳレコードが新ＤＳレコードに更新されていることが分かる。
【０１１５】
上述してきたように、実施例１に係る名前解決システム１は、下位権威サーバ３３に新ＫＳＫが登録された場合に、下位管理装置１３０が登録通知を上位管理装置１２０に送信する。そして、登録通知を受信した上位管理装置１２０が下位権威サーバ３３から新ＫＳＫの公開鍵を取得し、取得した新ＫＳＫの公開鍵から新ＤＳレコードを生成し、生成した新ＤＳレコードを上位権威サーバ３２に登録する。これにより、実施例１に係る名前解決システム１では、新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを自動的に更新するので、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されることを防止できる。
【０１１６】
例えば、権威サーバが保持するＫＳＫ等を更新するために、ＥＰＰ（Extensible Provisioning Protocol）を用いることも考えられる。しかし、ＥＰＰを用いた場合であっても、ネットワーク管理者の操作ミスにより、相互の対応に誤りのあるＫＳＫやＤＳレコードが各権威サーバに登録されるおそれがある。実施例１に係る名前解決システム１は、新ＫＳＫが登録された場合に、かかる新ＫＳＫに対応する新ＤＳレコードを自動生成するので、相互の対応に誤りのないＫＳＫ及びＤＳレコードを各権威サーバに登録することができる。
【０１１７】
また、ＥＰＰやＫＳＫ更新用の独自プロトコルを用いてＫＳＫ及びＤＳレコードを更新する場合には、ネットワーク管理者の操作ミスによる問題の他に、ＥＰＰや独自プロトコルの脆弱性を攻撃する攻撃者によって、不正なＫＳＫ及びＤＳレコードが各権威サーバに登録されるおそれがある。実施例１に係る名前解決システム１では、図９及び図１０を用いて説明したように、ＤＮＳプロトコルを用いる。ＤＮＳプロトコルは、枯れたプロトコルとも呼ばれており、ファイアフォール等のセキュリティ製品が充実している。このため、実施例１に係る名前解決システム１では、このようなセキュリティ製品が充実しているＤＮＳプロトコルを用いて各装置間で各種データを送受するので、攻撃者に攻撃されることを防止することができる。
【０１１８】
また、実施例１に係る名前解決システム１は、上位管理装置１２０において新ＤＳレコードが生成された後に、下位管理装置１３０が旧ＫＳＫを削除するので、信頼の連鎖が途切れる期間を発生させずに、ＫＳＫ及びＤＳレコードを更新することができる。
【０１１９】
また、実施例１に係る名前解決システム１は、図９のステップＳ２０８及びＳ２０９、図１０のステップＳ２２０及びＳ２２１を用いて説明したように、上位管理装置１２０が下位権威サーバ３３から取得したＤＮＳＫＥＹの正当性を検証するので、信頼性の高いＤＮＳＳＥＣを用いて、ＫＳＫ及びＤＳレコードを更新することができる。
【０１２０】
また、実施例１に係る名前解決システム１は、図１０のステップＳ２１７〜Ｓ２２２を用いて説明したように、下位管理装置１３０が旧ＫＳＫを削除した後に、上位管理装置１２０が旧ＤＳレコードを削除するので、下位管理装置１３０の管理者が新ＫＳＫを削除した場合や、新ＫＳＫの生成にミスがあった場合や、鍵更新処理中に下位管理装置１３０が故障した場合等でも、旧ＫＳＫ及び旧ＤＳレコードにより信頼の連鎖を維持することができる。
【０１２１】
具体的には、下位管理装置１３０の管理者は、誤った新ＫＳＫを登録した際に新ＫＳＫを削除したり、単なる操作ミスにより新ＫＳＫを削除したりすることが考えられる。実施例１に係る名前解決システム１では、旧ＫＳＫが削除されない限り、旧ＫＳＫに対応する旧ＤＳレコードが削除されないので、仮に新ＫＳＫが削除された場合であっても、信頼の連鎖を維持することができる。また、故障が発生した下位管理装置１３０をバックアップデータから復旧させた場合に、かかる下位管理装置１３０には、旧ＫＳＫしか登録されていない可能性がある。実施例１に係る名前解決システム１では、旧ＫＳＫが削除されない限り、旧ＫＳＫに対応する旧ＤＳレコードが削除されないので、仮に下位管理装置１３０に旧ＫＳＫしか登録されていない状態になったとしても、信頼の連鎖を維持することができる。
【実施例２】
【０１２２】
上記実施例１では、上位管理装置１２０が、下位管理装置１３０から新ＫＳＫの登録通知を受信した場合に、新ＫＳＫの取得処理や新ＤＳレコードの生成処理を行う例を示した。しかし、上位ゾーンを管理する上位権威サーバ３２の上位管理装置１２０は、複数の下位管理装置１３０から略同一のタイミングで新ＫＳＫの登録通知を受信する場合も考えられる。かかる場合に、上位管理装置１２０による処理負荷が増大するとも考えられる。そこで、上位管理装置１２０は、下位管理装置１３０から新ＫＳＫの登録通知を受信した場合であっても、所定の時間が経過した後に、新ＤＳレコードの生成処理等を行ってもよい。実施例２では、このような上位管理装置１２０について説明する。
【０１２３】
まず、図１６を用いて、実施例２における上位管理装置について説明する。図１６は、実施例２における上位管理装置の構成例を示す図である。なお、実施例２における下位管理装置１３０の構成は、図７に例示した構成と同様であるので、説明を省略する。また、以下では、既に示した構成部位と同様の機能を有する部位には同一符号を付すこととして、その詳細な説明を省略する。
【０１２４】
図１６に例示するように、実施例２における上位管理装置２２０は、待機通知部２２１を有する。待機通知部２２１は、下位管理装置１３０から、新ＫＳＫが登録された旨の登録通知や旧ＫＳＫが削除された旨の削除通知を受け付けた場合に、上位管理装置２２０の処理負荷が所定の閾値以上であるか否かを判定する。例えば、待機通知部２２１は、現在時刻を含む所定の時間内に、下位管理装置から受信した登録通知や削除通知の数が所定の閾値以上であるか否かを判定する。また、例えば、待機通知部２２１は、上位管理装置２２０のＣＰＵ負荷等が所定の閾値以上であるか否かを判定する。
【０１２５】
そして、待機通知部２２１は、上位管理装置２２０の処理負荷が所定の閾値以上である場合には、新ＤＳレコードの生成処理等を行う時刻（以下、「対応時刻」と表記する場合がある）を決定し、決定した対応時刻を下位管理装置１３０に通知する。そして、待機通知部２２１は、かかる対応時刻になるまで待機し、対応時刻となった場合に、取得部１２１に対してＤＮＳＫＥＹの取得処理を行うように指示する。
【０１２６】
次に、図１７及び図１８を用いて、実施例２に係る名前解決システム１による鍵更新処理の手順について説明する。図１７及び図１８は、実施例２に係る名前解決システム１による鍵更新処理手順を示すシーケンス図である。図１７に示したステップＳ３０１〜Ｓ３０５における処理手順は、図９に示したステップＳ２０１〜Ｓ２０５における処理手順と同様であるので、説明を省略する。
【０１２７】
図１７に示すように、実施例２における上位管理装置２２０の待機通知部２２１は、下位管理装置１３０の通知部１３３から登録通知を受信した場合に、上位管理装置２２０の処理負荷が所定の閾値以上であるか否かを判定する。ここでは、待機通知部２２１は、上位管理装置２２０の処理負荷が所定の閾値以上であると判定するものとする。かかる場合に、待機通知部２２１は、対応時刻を下位管理装置１３０に送信する（ステップＳ３０６）。そして、待機通知部２２１は、かかる対応時刻になるまで待機する（ステップＳ３０７）。
【０１２８】
続いて、上位管理装置２２０の取得部１２１は、待機通知部２２１によって決定された対応時刻になった場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ３０８）。なお、図１７に示したステップＳ３０８〜Ｓ３１４による処理手順は、図９に示したステップＳ２０６〜Ｓ２１２による処理手順と同様であるので、説明を省略する。
【０１２９】
続いて、下位管理装置１３０は、上位管理装置２２０の待機通知部２２１から受信した対応時刻になった場合に、ＤＮＳプロトコルを用いて、上位権威サーバ３２に対してＤＳレコードを問い合わせる（ステップＳ３１５）。上位権威サーバ３２は、かかる問い合わせに応答して、自身が保持するＤＳレコードを下位管理装置１３０に送信する（ステップＳ３１６）。これにより、下位管理装置１３０は、上位権威サーバ３２に新レコードが生成されたか否かを判定することができる。
【０１３０】
なお、図１７では、下位管理装置１３０が上位権威サーバ３２にＤＳレコードを問い合わせる例を示した。しかし、図９に示した例と同様に、上位管理装置２２０が、上位権威サーバ３２のゾーンデータに新ＤＳレコードが登録された旨の登録通知を下位管理装置１３０に送信してもよい（図９のステップＳ２１３参照）。ただし、図１７に示した例のように、下位管理装置１３０が、上位管理装置２２０を介さずに、上位権威サーバ３２にアクセスして新ＤＳレコードの生成有無を判定することで、上位管理装置２２０による処理負荷を低減することができる。すなわち、上位管理装置２２０が対応時刻を送信した場合には、上位管理装置２２０の処理負荷が増大しているとも言える。そこで、実施例２における下位管理装置１３０は、対応時刻を通知された場合には、上位管理装置２２０を介さずに新ＤＳレコードの生成有無を判定することで、上位管理装置２２０の処理負荷を低減することができる。
【０１３１】
続いて、図１８に示すように、下位管理装置１３０の更新部１３２は、上位権威サーバ３２に新ＤＳレコードが生成されている場合に、下位管理装置１３０が保持する下位権威サーバ３３のゾーンデータから旧ＫＳＫを削除する（ステップＳ３１７）。なお、図１８に示したステップＳ３１８〜Ｓ３２０における処理手順は、図１０に示したステップＳ２１５〜Ｓ２１７における処理手順と同様であるので、説明を省略する。
【０１３２】
続いて、上位管理装置２２０の待機通知部２２１は、下位管理装置１３０の通知部１３３から削除通知を受信した場合に、上位管理装置２２０の処理負荷が所定の閾値以上であるか否かを判定する。ここでは、待機通知部２２１は、上位管理装置２２０の処理負荷が所定の閾値以上であると判定するものとする。かかる場合に、待機通知部２２１は、対応時刻を下位管理装置１３０に送信する（ステップＳ３２１）。そして、待機通知部２２１は、かかる対応時刻になるまで待機する（ステップＳ３２２）。
【０１３３】
続いて、上位管理装置２２０の取得部１２１は、待機通知部２２１によって決定された対応時刻になった場合に、ＤＮＳプロトコルを用いて、下位権威サーバ３３にＤＮＳＫＥＹを問い合わせる（ステップＳ３２３）。なお、図１８に示したステップＳ３２３〜Ｓ３２９による処理手順は、図１０に示したステップＳ２１８〜Ｓ２２４による処理手順と同様であるので、説明を省略する。
【０１３４】
続いて、下位管理装置１３０は、上位管理装置２２０の待機通知部２２１から受信した対応時刻になった場合に、ＤＮＳプロトコルを用いて、上位権威サーバ３２に対してＤＳレコードを問い合わせる（ステップＳ３３０）。上位権威サーバ３２は、かかる問い合わせに応答して、自身が保持するＤＳレコードを下位管理装置１３０に送信する（ステップＳ３３１）。これにより、下位管理装置１３０は、上位権威サーバ３２から旧レコードが削除されたか否かを判定することができる。上記例と同様に、下位管理装置１３０は、上位管理装置２２０を介さずに、上位権威サーバ３２にアクセスして旧ＤＳレコードの削除有無を判定することで、上位管理装置２２０による処理負荷を低減することができる。
【０１３５】
上述してきたように、実施例２に係る名前解決システム１は、上位管理装置１２０は、自身の処理負荷が高い場合に、所定の時間が経過した後に新ＤＳレコードの生成処理等を行う。これにより、実施例２に係る名前解決システム１は、複数の下位管理装置によって新ＫＳＫを登録する処理が所定時間に集中した場合であっても、上位管理装置１２０の処理負荷を一時的に増大させることなく、ＫＳＫ及びＤＳレコードを更新することができる。
【実施例３】
【０１３６】
ところで、本発明に係る名前解決システム及び鍵更新方法は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例３では、本発明に係る名前解決システム及び鍵更新方法の他の実施例について説明する。
【０１３７】
［処理主体］
上記実施例では、上位管理装置１２０と下位管理装置１３０とを分別して説明した。しかし、上述したように、上位管理装置１２０は下位管理装置となる場合もあり、下位管理装置１３０は上位管理装置となる場合もある。したがって、上述した各管理装置は、図７に示した各処理部と、図８に示した各処理部との双方を有する。なお、下位管理装置にしかなり得ない管理装置は、図７に示した各処理部のみを有してもよいし、上位管理装置にしかなり得ない管理装置は、図８に示した各処理部のみを有してもよい。
【０１３８】
また、上記実施例では、各権威サーバを管理装置によって管理する例を示した。しかし、権威サーバと管理装置とは一体化されてもよい。例えば、権威サーバ３１と管理装置１１０とが一体化されてもよいし、上位権威サーバ３２と上位管理装置１２０とが一体化されてもよい。すなわち、上記実施例では、権威サーバと管理装置とを分別して説明したが、本発明は、権威サーバと管理装置との双方を権威サーバとする場合にも適用することができる。
【０１３９】
［ＫＳＫの数］
また、上記実施例では、権威サーバが保持する旧ＫＳＫの数が１個である場合を例に挙げて説明した。しかし、本発明は、権威サーバが２個以上の旧ＫＳＫ保持する場合にも適用することができる。例えば、下位権威サーバ３３が２個の旧ＫＳＫを保持し、１個の新ＫＳＫが登録されたものとする。かかる場合には、下位権威サーバ３３は、３個のＫＳＫ（公開鍵）を含むＤＮＳＫＥＹを上位管理装置１２０に送信する。そして、上位管理装置１２０は、各ＫＳＫに対応する３個のＤＳレコードを保持することになる。
【０１４０】
［システム構成］
また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図４等に例示した各種情報は、あくまで一例であって任意の情報に変更することができる。
【０１４１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【０１４２】
［プログラム］
また、上記実施例において説明した上位管理装置１２０、下位管理装置１３０又は上位管理装置２２０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例１における上位管理装置１２０、下位管理装置１３０又は上位管理装置２２０が実行する処理をコンピュータが実行可能な言語で記述した鍵更新プログラムを作成することもできる。この場合、コンピュータが鍵更新プログラムを実行することにより、上記実施例と同様の効果を得ることができる。さらに、かかる鍵更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された鍵更新プログラムをコンピュータに読み込ませて実行することにより上記実施例と同様の処理を実現してもよい。以下に、図７及び図８に示した上位管理装置１２０及び下位管理装置１３０と同様の機能を実現する鍵更新プログラムを実行するコンピュータの一例を説明する。
【０１４３】
図１９は、鍵更新プログラムを実行するコンピュータ１０００を示す図である。図１９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。
【０１４４】
メモリ１０１０は、図１９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１９に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１９に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図１９に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１９に例示するように、例えばディスプレイ１０６１に接続される。
【０１４５】
ここで、図１９に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の鍵更新プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。例えば、図７に例示した受付部１３１、更新部１３２、通知部１３３、及び、図８に例示した取得部１２１、検証部１２２、生成部１２３、更新部１２４、通知部１２５と同様の情報処理を実行する処理手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。
【０１４６】
また、上記実施例で説明した上位管理装置１２０及び下位管理装置１３０が保持する各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。
【０１４７】
なお、鍵更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、鍵更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【０１４８】
１ 名前解決システム
２０ キャッシュサーバ
３０ 権威サーバ群
３１〜３３ 権威サーバ
１１０、１２０、１３０ 管理装置
１２１ 取得部
１２２ 検証部
１２３ 生成部
１２４ 更新部
１２５ 通知部
１３１ 受付部
１３２ 更新部
１３３ 通知部
２２１ 待機通知部
【特許請求の範囲】
【請求項１】
名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第２の権威サーバとを含む名前解決システムであって、
前記第１の権威サーバは、
新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第２の権威サーバに通知する通知部
を備え、
前記第２の権威サーバは、
前記通知部によって通知された場合に、前記第１の権威サーバから前記新署名鍵を取得する取得部と、
前記取得部によって取得された新署名鍵に対応する特定データである新特定データを生成する生成部と
を備えたことを特徴とする名前解決システム。
【請求項２】
前記第１の権威サーバは、
前記生成部によって前記新特定データが生成された場合に、前記新署名鍵が登録される前の署名鍵である旧署名鍵を削除する第１の更新部
をさらに備え、
前記第２の権威サーバは、
前記第１の更新部によって前記旧署名鍵が削除された場合に、該旧署名鍵に対応する特定データを削除する第２の更新部
をさらに備えたことを特徴とする請求項１に記載の名前解決システム。
【請求項３】
前記第２の権威サーバは、
前記通知部によって通知された場合に、前記新特定データを生成するタイミングを前記第１の権威サーバに通知する待機通知部をさらに備え、
前記取得部は、
前記待機通知部によって通知されたタイミングになった場合に、前記第１の権威サーバから前記新署名鍵を取得し、
前記第１の更新部は、
前記待機通知部によって通知されたタイミングになった場合に、前記第２の権威サーバに問い合わせることにより前記新特定データが生成されたか否かを判定し、前記新特定データが生成された場合に、前記旧署名鍵を削除する
ことを特徴とする請求項２に記載の名前解決システム。
【請求項４】
前記第１の権威サーバは、
前記新署名鍵が登録された場合に、前記新署名鍵が登録される前の署名鍵である旧署名鍵を用いて、前記新署名鍵及び前記旧署名鍵の電子署名を作成する作成部
をさらに備え、
前記取得部は、
前記通知部によって通知された場合に、前記第１の権威サーバから、前記新署名鍵と前記旧署名鍵と前記作成部によって作成された電子署名とを取得し、
前記第２の権威サーバは、
前記旧署名鍵に対応する特定データを用いて、前記取得部によって取得された前記旧署名鍵の正当性を検証し、前記旧署名鍵の検証が成功した場合に、前記取得部によって取得された電子署名を用いて、前記新署名鍵及び前記旧署名鍵の正当性を検証する検証部
をさらに備え、
前記生成部は、
前記検証部による検証が成功した場合に、前記取得部によって取得された新署名鍵に対応する前記新特定データを生成する
ことを特徴とする請求項１〜３のいずれか一つに記載の名前解決システム。
【請求項５】
前記第１の権威サーバは、
名前解決の結果の電子署名を作成するための秘密鍵に対応する公開鍵を署名するための署名用秘密鍵及び署名用公開鍵を前記署名鍵として保持し、
前記第２の権威サーバは、
前記署名用公開鍵のハッシュ値を前記特定データとして保持する
ことを特徴とする請求項１〜４のいずれか一つに記載の名前解決システム。
【請求項６】
名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第２の権威サーバとを含む名前解決システムで実行される鍵更新方法であって、
前記第１の権威サーバに新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第１の権威サーバから前記第２の権威サーバに通知する通知工程と、
前記通知工程によって新署名鍵が登録された旨を前記第２の権威サーバに通知された場合に、前記第２の権威サーバが前記第１の権威サーバから前記新署名鍵を取得する取得工程と、
前記取得工程によって取得された新署名鍵に対応する特定データである新特定データを生成する生成工程と
を含んだことを特徴とする鍵更新方法。
【請求項１】
名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第２の権威サーバとを含む名前解決システムであって、
前記第１の権威サーバは、
新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第２の権威サーバに通知する通知部
を備え、
前記第２の権威サーバは、
前記通知部によって通知された場合に、前記第１の権威サーバから前記新署名鍵を取得する取得部と、
前記取得部によって取得された新署名鍵に対応する特定データである新特定データを生成する生成部と
を備えたことを特徴とする名前解決システム。
【請求項２】
前記第１の権威サーバは、
前記生成部によって前記新特定データが生成された場合に、前記新署名鍵が登録される前の署名鍵である旧署名鍵を削除する第１の更新部
をさらに備え、
前記第２の権威サーバは、
前記第１の更新部によって前記旧署名鍵が削除された場合に、該旧署名鍵に対応する特定データを削除する第２の更新部
をさらに備えたことを特徴とする請求項１に記載の名前解決システム。
【請求項３】
前記第２の権威サーバは、
前記通知部によって通知された場合に、前記新特定データを生成するタイミングを前記第１の権威サーバに通知する待機通知部をさらに備え、
前記取得部は、
前記待機通知部によって通知されたタイミングになった場合に、前記第１の権威サーバから前記新署名鍵を取得し、
前記第１の更新部は、
前記待機通知部によって通知されたタイミングになった場合に、前記第２の権威サーバに問い合わせることにより前記新特定データが生成されたか否かを判定し、前記新特定データが生成された場合に、前記旧署名鍵を削除する
ことを特徴とする請求項２に記載の名前解決システム。
【請求項４】
前記第１の権威サーバは、
前記新署名鍵が登録された場合に、前記新署名鍵が登録される前の署名鍵である旧署名鍵を用いて、前記新署名鍵及び前記旧署名鍵の電子署名を作成する作成部
をさらに備え、
前記取得部は、
前記通知部によって通知された場合に、前記第１の権威サーバから、前記新署名鍵と前記旧署名鍵と前記作成部によって作成された電子署名とを取得し、
前記第２の権威サーバは、
前記旧署名鍵に対応する特定データを用いて、前記取得部によって取得された前記旧署名鍵の正当性を検証し、前記旧署名鍵の検証が成功した場合に、前記取得部によって取得された電子署名を用いて、前記新署名鍵及び前記旧署名鍵の正当性を検証する検証部
をさらに備え、
前記生成部は、
前記検証部による検証が成功した場合に、前記取得部によって取得された新署名鍵に対応する前記新特定データを生成する
ことを特徴とする請求項１〜３のいずれか一つに記載の名前解決システム。
【請求項５】
前記第１の権威サーバは、
名前解決の結果の電子署名を作成するための秘密鍵に対応する公開鍵を署名するための署名用秘密鍵及び署名用公開鍵を前記署名鍵として保持し、
前記第２の権威サーバは、
前記署名用公開鍵のハッシュ値を前記特定データとして保持する
ことを特徴とする請求項１〜４のいずれか一つに記載の名前解決システム。
【請求項６】
名前解決の結果に電子署名を付与する際に用いる署名鍵を保持する第１の権威サーバと、前記署名鍵の正当性を検証する際に用いられるデータであって前記署名鍵を特定する特定データを保持する第２の権威サーバとを含む名前解決システムで実行される鍵更新方法であって、
前記第１の権威サーバに新たな署名鍵である新署名鍵が登録された場合に、新署名鍵が登録された旨を前記第１の権威サーバから前記第２の権威サーバに通知する通知工程と、
前記通知工程によって新署名鍵が登録された旨を前記第２の権威サーバに通知された場合に、前記第２の権威サーバが前記第１の権威サーバから前記新署名鍵を取得する取得工程と、
前記取得工程によって取得された新署名鍵に対応する特定データである新特定データを生成する生成工程と
を含んだことを特徴とする鍵更新方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１２−２５３５３９（Ｐ２０１２−２５３５３９Ａ）
【公開日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願番号】特願２０１１−１２４１６６（Ｐ２０１１−１２４１６６）
【出願日】平成２３年６月２日（２０１１．６．２）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願日】平成２３年６月２日（２０１１．６．２）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]