JP2012199607A - Ｄｎｓｓｅｃ代理装置 - Google Patents

Abstract

【課題】ＤＮＳＳＥＣに非対応なＤＮＳ権威サーバを変更することなしに、ＤＮＳ権威サーバにＤＮＳＳＥＣを容易に適用させることができるＤＮＳＳＥＣ代理装置を提供すること。
【解決手段】ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバと、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバとの間に設けられたＤＮＳＳＥＣ代理装置５が、ＤＮＳ権威サーバからＤＮＳキャッシュサーバに送信された情報にＤＮＳＳＥＣに準拠した電子署名を付加する署名付加部１３を備える。
【選択図】図２

Description

本発明は、ＤＮＳＳＥＣ（Domain Name System Security Extension）に非対応のＤＮＳ権威サーバに対してＤＮＳＳＥＣ機能を代理するＤＮＳＳＥＣ代理装置に関する。

ＤＮＳは、ドメインネームとＩＰアドレスとの対応を表す情報を提供するために、インターネット上に構築された階層型の分散型データベースシステムである。ドメインネームとＩＰアドレスとの対応情報のデータベースは、インターネット上に分散して配置され、論理的にルートゾーンを頂点として階層的に構成されている。

ドメインネームは、その階層構造がそのまま反映されている。例えば、図６に示すように、ドメインネームが「www.example.com」の場合を例に説明すると、「www.example.com」とＩＰアドレスの対応情報を管理しているのはexample.comゾーンのデータベースであり、example.comゾーンは、comゾーンの子ゾーンの１であり、comゾーンは、階層の頂点にあるルートゾーンの子ゾーンの１つである。

ＤＮＳサーバには権威サーバとキャッシュサーバの機能がある。両者は一台のサーバ上で、同時に運用されることもあるし単一の機能で運用されることもある。各ゾーンのデータベースは、権威サーバによって管理される。各権威サーバは、少なくとも１つのゾーンのデータベースを格納している。

権威サーバは、上述したデータベースを管理するようになっている。キャッシュサーバは、個別のホストから問い合わせを受けて、この問い合わせを権威サーバ群に送り、ドメインネームとＩＰアドレスの対応情報を探し出す名前解決を実行するようになっている。また、キャッシュサーバは、名前解決の結果をキャッシュするようになっている。

具体的には、権威サーバは、管理対象のゾーンのドメインネームと、当該権威サーバのＩＰアドレスとの対応情報を親ゾーンの権威サーバに予め登録しておく。ここで、キャッシュサーバは、ホストから「www.example.com」の名前解決の要求を受けると、まず、ルートサーバに「www.example.com」のドメインネームの問い合わせを送る。

ルートサーバは、example.comゾーンの情報を持っていないが、comゾーンの権威サーバについての情報は持っているのでそれを回答とする。次に、キャッシュサーバは、comゾーンの権威サーバに問い合わせを送り、example.comゾーンの権威サーバについての情報を得る。最後に、キャッシュサーバは、example.comの権威サーバに問い合わせると、「www.example.com」のＩＰアドレスを得ることができるので、これをホストに回答する。

ここで、キャッシュサーバは、この回答をキャッシュし、その回答の中でＴＴＬ（Time To Live）として指定された時刻が経過するまでは、「www.example.com」の名前解決の要求に対してキャッシュの内容を答える。

ＤＮＳは、情報のやりとりを行う際にその情報の出自を確認する機能が実装されていない。このため、攻撃者によって偽の権威サーバから偽の回答をキャッシュサーバにキャッシュさせるポイズニング攻撃の可能性が以前より指摘されていた。

しかし、キャッシュサーバは、上述したように、ＴＴＬで指定された時刻が経過するまでは、新しい情報を取りに行かないため、ポイズニング攻撃は、実行できる機会が少なく、有効な攻撃とはならなかった。このため、ＤＮＳサーバを管理しているオペレータの多くは、ポイズニング攻撃に対して、あまり危機感を持っていなかった。

しかしながら、このＴＴＬによる制約を受けないカミンスキーアタックが２００８年に提案されたことをきっかけに回答の出自を検証できる機能の重要性が高まってきた。これにより、ＤＮＳサーバ間で情報のやりとりを行う際にその情報の出自を確認することができるＤＮＳＳＥＣが注目されてきた（例えば、非特許文献１乃至３参照）。

R. Arends, et al. "DNS Security Introduction and Requirements", IETF RFC 4033, 2005． R. Arends, et al. "Resource Records for the DNS Security Extensions", IETF RFC 4034, 2005． R. Arends, et al. "Protocol Modifications for the DNS Security Extensions", IETF RFC 4035, 2005．

しかしながら、運用中のサーバに新たなソフトウェアを導入することによって、当該サーバのリソースが消費されることや、当該サーバの検証作業等の新たな手間が発生するため、ＤＮＳ権威サーバをＤＮＳＳＥＣに対応させることが依然として困難であるという課題があった。

本発明は、このような課題を解決するためになされたもので、ＤＮＳＳＥＣに非対応なＤＮＳ権威サーバを変更することなしに、ＤＮＳ権威サーバにＤＮＳＳＥＣを容易に適用させることができるＤＮＳＳＥＣ代理装置を提供することを目的とする。

本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバ（１ｃ）と、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバ（２）との間に設けられたＤＮＳＳＥＣ代理装置であって、前記ＤＮＳ権威サーバから前記ＤＮＳキャッシュサーバに送信された情報に前記ＤＮＳＳＥＣに準拠した電子署名を付加する署名付加部（１３）と、前記電子署名が付加された情報に含まれる送信元ＩＰアドレスを変更することなく該情報を前記ＤＮＳキャッシュサーバに送信する通信部（１０）とを備えた構成を有している。

この構成により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバと、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバとの間に接続するだけで、ＤＮＳキャッシュサーバに対して、ＤＮＳ権威サーバがＤＮＳＳＥＣに対応しているように動作するため、ＤＮＳ権威サーバを変更することなしに、ＤＮＳ権威サーバにＤＮＳＳＥＣを容易に適用させることができる。

なお、本発明のＤＮＳＳＥＣ代理装置は、前記ＤＮＳキャッシュサーバから名前解決の要求を受けて、前記ＤＮＳ権威サーバが該要求に応じられなかった場合に、前記ＤＮＳキャッシュサーバに応答するための不在証明を生成する不在証明生成部（１４）を備えるようにしてもよい。

この構成により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳキャッシュサーバから受けた名前解決の要求にＤＮＳ権威サーバが応じられなかった場合に、ＤＮＳキャッシュサーバに不在証明を送信することができるため、ＤＮＳキャッシュサーバに名前解決ができなかったことを知らせることができる。

また、前記署名付加部は、前記ＤＮＳＳＥＣに準拠した電子署名を前記不在証明に付加するようにしてもよい。

この構成により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳキャッシュサーバに不在証明を検証させることができる。

また、本発明のＤＮＳＳＥＣ代理装置は、前記電子署名を生成するための秘密鍵を少なくとも格納する鍵情報格納部（１１）を備えるようにしてもよい。

この構成により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳ権威サーバから送信された情報をＤＮＳキャッシュサーバに検証させることができる。

本発明のＤＮＳＳＥＣ代理方法は、ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバ（１ｃ）と、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバ（２）との間に設けられたＤＮＳＳＥＣ代理装置（５）を用いたＤＮＳＳＥＣ代理方法であって、前記ＤＮＳ権威サーバから前記ＤＮＳキャッシュサーバに送信された情報に前記ＤＮＳＳＥＣに準拠した電子署名を付加する署名付加ステップと、前記電子署名が付加された情報に含まれる送信元ＩＰアドレスを変更することなく該情報を前記ＤＮＳキャッシュサーバに送信するトランスペアレント送信ステップとを有する。

この方法により、本発明のＤＮＳＳＥＣ代理方法は、ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバと、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバとの間に接続するだけで、ＤＮＳキャッシュサーバに対して、ＤＮＳ権威サーバがＤＮＳＳＥＣに対応しているように動作するため、ＤＮＳ権威サーバを変更することなしに、ＤＮＳ権威サーバにＤＮＳＳＥＣを容易に適用させることができる。

なお、本発明のＤＮＳＳＥＣ代理方法は、前記ＤＮＳキャッシュサーバから名前解決の要求を受けて、前記ＤＮＳ権威サーバが該要求に応じられなかった場合に、前記ＤＮＳキャッシュサーバに応答するための不在証明を生成する不在証明生成ステップを有してもよい。

この方法により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳキャッシュサーバから受けた名前解決の要求にＤＮＳ権威サーバが応じられなかった場合に、ＤＮＳキャッシュサーバに不在証明を送信することができるため、ＤＮＳキャッシュサーバに名前解決ができなかったことを知らせることができる。

また、前記署名付加ステップでは、前記ＤＮＳＳＥＣに準拠した電子署名を前記不在証明に付加してもよい。

この方法により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳキャッシュサーバに不在証明を検証させることができる。

また、本発明のＤＮＳＳＥＣ代理方法は、前記署名付加ステップで前記電子署名を生成するための秘密鍵を記憶媒体から取得する鍵取得ステップを有してもよい。

この方法により、本発明のＤＮＳＳＥＣ代理装置は、ＤＮＳ権威サーバから送信された情報をＤＮＳキャッシュサーバに検証させることができる。

本発明は、ＤＮＳＳＥＣに非対応なＤＮＳ権威サーバを変更することなしに、ＤＮＳ権威サーバにＤＮＳＳＥＣを容易に適用させることができるＤＮＳＳＥＣ代理装置を提供することができる。

本発明の実施の形態に係るＤＮＳＳＥＣ代理装置を備えたシステムのブロック図である。 本発明の実施の形態に係るＤＮＳＳＥＣ代理装置のブロック図である。 （ａ）は、本発明の実施の形態に係るＤＮＳＳＥＣ代理装置を構成する通信部が権威サーバから受信した、ＩＰアドレスの回答を含むパケットの模式図であり、（ｂ）は、このパケットを受信した通信部がキャッシュサーバ２に対して送信する、ＩＰアドレスの回答を含むパケットの模式図である。 本発明の実施の形態に係るＤＮＳＳＥＣ代理装置を備えたシステムの動作例を示すシーケンス図である。 本発明の実施の形態に係るＤＮＳＳＥＣ代理装置を備えたシステムの他の態様を示すブロック図である。 ドメインネームの階層構造を示す概念図である。

以下、本発明の実施の形態について、図面を参照して説明する。

図１に示すように、本発明の実施の形態に係るＤＮＳＳＥＣ代理装置を備えたシステムは、権威サーバ１ａ〜１ｃと、キャッシュサーバ２とを備えている。権威サーバ１ａ、１ｂおよびキャッシュサーバ２は、インターネット３に接続可能に設けられている。

権威サーバ１ｃは、ゾーン４内に設けられ、ゾーン４内には、権威サーバ１ｃとインターネット３との間に設けられたＤＮＳＳＥＣ代理装置５と、サーバ６とがインターネット３に接続可能に設けられている。

キャッシュサーバ２は、ＩＳＰ（Internet Service Provider）網７内でインターネット３に接続可能に設けられ、ＩＳＰ網７内には、ホスト８がインターネット３に接続可能に設けられている。

本実施の形態において、権威サーバ１ａ、１ｂおよびキャッシュサーバ２は、ＤＮＳＳＥＣに対応し、権威サーバ１ｃは、ＤＮＳＳＥＣに対応していないものとする。また、権威サーバ１ａは、ルートゾーンの権威サーバを構成し、権威サーバ１ｂは、comゾーンの権威サーバを構成し、権威サーバ１ｃは、example.comゾーンの権威サーバを構成するものとする。また、サーバ６には、「www.example.com」のドメインネームが割り当てられているものとする。

なお、図１に示すネットワーク構成は、本発明を限定するものではなく、本発明においては、ＤＮＳにおいてＤＮＳＳＥＣに対応していない権威サーバがＤＮＳＳＥＣ代理装置を介してインターネットに接続されていればよい。

権威サーバ１ａ〜１ｃ、キャッシュサーバ２、サーバ６およびホスト８は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスク装置およびネットワークモジュール等を有する一般的なコンピュータ装置によって構成される。

図２に示すように、ＤＮＳＳＥＣ代理装置５は、権威サーバ１ｃおよびキャッシュサーバ２と通信するための通信部１０と、電子署名等に用いる鍵情報を格納する鍵情報格納部１１と、キャッシュサーバ２に送信する情報を生成する情報生成部１２と、キャッシュサーバ２に送信する情報に電子署名を付加する署名付加部１３とを備えている。

本実施の形態において、ＤＮＳＳＥＣ代理装置５は、ＣＰＵ、ＲＯＭ、ＲＡＭ、フラッシュメモリおよびネットワークモジュール等を有するアプライアンスによって構成されているものとする。

ＲＯＭおよびフラッシュメモリには、当該アプライアンスをＤＮＳＳＥＣ代理装置５として機能させるためのプログラムが記憶されている。すなわち、ＣＰＵがＲＡＭを作業領域としてＲＯＭに記憶されたプログラムを実行することにより、当該アプライアンスは、ＤＮＳＳＥＣ代理装置５として機能する。

通信部１０は、ＣＰＵおよびネットワークモジュールによって構成され、鍵情報格納部１１は、フラッシュメモリによって構成され、情報生成部１２および署名付加部１３は、ＣＰＵによって構成される。

なお、ＤＮＳＳＥＣ代理装置５は、ＬＳＩ（Large Scale Integration）やＩＣ（Integrated Circuit）等を用いたハードウェアによって構成してもよく、協働するソフトウェアとハードウェアとによって構成してもよい。

通信部１０は、キャッシュサーバ２から情報を受信し、受信した情報の種別に応じて、当該情報を情報生成部１２に出力したり、権威サーバ１ｃに送信したりするようになっている。また、通信部１０は、権威サーバ１ｃから情報を受信し、受信した情報を情報生成部１２に出力するようになっている。

例えば、通信部１０は、キャッシュサーバ２から受信した情報が名前解決の要求を表す場合には、当該情報をそのまま権威サーバ１ｃに送信するようになっている。また、通信部１０は、キャッシュサーバ２から受信した情報が鍵情報の要求を表す場合には、当該情報を情報生成部１２に出力するようになっている。

鍵情報格納部１１には、電子署名用の第１の鍵ペアと、第１の鍵ペアの公開鍵に署名するための第２の鍵ペアが格納されている。第１の鍵ペアは、ＺＳＫ（Zone Signing Key）と呼ばれ、数ヶ月程度の間隔で更新される。第２の鍵ペアは、ＫＳＫ（Key Signing Key）と呼ばれ、ＺＳＫの更新間隔より長い１年程度の間隔で更新される。

なお、権威サーバ１ｂが管理するゾーン名と、権威サーバ１ｂのＫＳＫの公開鍵のダイジェスト（以下、単に「公開鍵ダイジェスト」という）とは、権威サーバ１ａにアウトバンドで事前に登録され、権威サーバ１ｃが管理するゾーン名と、ＤＮＳＳＥＣ代理装置５の公開鍵ダイジェストとは、権威サーバ１ｂにアウトバンドで事前に登録される。また、権威サーバ１ａのＫＳＫの公開鍵と、権威サーバ１ａのＩＰアドレスは、キャッシュサーバ２にアウトバンドで事前に登録される。

情報生成部１２は、通信部１０から鍵情報の要求を表す情報を受信した場合には、鍵情報格納部１１に格納されたＫＳＫの公開鍵およびＺＳＫの公開鍵を含む情報（以下、単に「公開鍵情報」という）を生成し、生成した公開鍵情報を署名付加部１３に出力するようになっている。

また、情報生成部１２は、通信部１０から出力された情報が名前解決の回答を表し、この回答にサーバ６のＩＰアドレスが含まれている場合には、当該情報（以下、単に「アドレス情報」という）をそのまま署名付加部１３に出力するようになっている。

また、情報生成部１２は、権威サーバ１ｃが名前解決の要求に応じられなかった場合に、不在証明を生成する不在証明生成部１４を有している。不在証明生成部１４は、通信部１０から出力された情報が名前解決の回答を表し、この回答にサーバ６のＩＰアドレスが含まれていない場合、すなわち、問い合わされたサーバが存在しなかった旨を当該回答が表す場合には、問い合わされたサーバが存在しない旨を表す所定の内容を含む不在証明を生成するようになっている。情報生成部１２は、不在証明生成部１４によって生成された不在証明を署名付加部１３に出力するようになっている。

署名付加部１３は、鍵情報格納部１１に格納されたＫＳＫの秘密鍵を用いて、情報生成部１２から出力された公開鍵情報の電子署名を生成し、生成した電子署名を公開鍵情報に付加するようになっている。

また、署名付加部１３は、鍵情報格納部１１に格納されたＺＳＫの秘密鍵を用いて、情報生成部１２から出力されたアドレス情報の電子署名を生成し、生成した電子署名をアドレス情報に付加するようになっている。

また、署名付加部１３は、鍵情報格納部１１に格納されたＺＳＫの秘密鍵を用いて、情報生成部１２から出力された不在証明の電子署名を生成し、生成した電子署名を不在証明に付加するようになっている。

このように、署名付加部１３によって電子署名が付加された各情報は、通信部１０によってキャッシュサーバ２に送信される。

なお、一般的なパケット中継装置には、ユニークなＩＰアドレスが付与されているが、ＤＮＳＳＥＣ代理装置５には、ＩＰアドレスが付与されていない。そのため、一般的なパケット中継装置は、受信したパケットを別の装置に対して送信する前に一度ＩＰヘッダ等を除去してから自分自身のＩＰアドレスを含むＩＰヘッダ等を付加するが、通信部１０は、受信したパケットに含まれるＩＰアドレスを変更することなくそのまま転送するようになっている。

従って、キャッシュサーバ２にとってみれば、パケットがＤＮＳＳＥＣ代理装置５から送信されているにもかかわらず、権威サーバ１ｃから送信されたように見える（トランスペアレント）。このため、ＤＮＳＳＥＣ代理装置５を導入する際に、親ゾーンの権威サーバ１ｂに登録してある権威サーバ１ｃのＩＰアドレスの情報や、権威サーバ１ｃ自身の設定等を変更する必要はない。

ここで、図３を用いて、ＤＮＳＳＥＣ代理装置５のトランスペアレントについて説明する。図３（ａ）は、通信部１０が権威サーバ１ｃから受信した、ＩＰアドレスの回答を含むパケット２０の模式図である。

このパケット２０は、ＩＰヘッダ２１、ＵＤＰ（User Datagram Protocol）ヘッダ２２およびＤＮＳデータ２３から構成されている。ＩＰヘッダ２１は、ＩＰパケット長フィールド２１１およびチェックサムフィールド２１２を含んでいる。

ＵＤＰヘッダ２２は、ＵＤＰパケット長フィールド２２１およびチェックサムフィールド２２２を含んでいる。ＤＮＳデータ２３は、レコード数２３１と、１つ以上の回答レコード２３２と、ＥＤＮＳ０拡張リソースレコード２３４とを含んでいる。

図３（ｂ）は、パケット２０を受信した通信部１０がキャッシュサーバ２に対して送信しようとする、ＩＰアドレスの回答を含むパケット２０ｂの模式図である。

まず、通信部１０は、署名付加部１３が付加した署名レコード２３３を回答レコード２３２に付加する。その後、通信部１０は、レコード数２３１を新たなレコード数２３１ｂに更新し、ＥＤＮＳ０拡張リソースレコード２３４中のＤＮＳＳＥＣ対応を表すフラグをたてて新たなＥＤＮＳ０拡張リソースレコード２３４ｂに更新し、新たなＤＮＳデータ２３ｂを作成する。

次に、通信部１０は、付加された署名レコード２３３の分だけ増加した新たなＵＤＰパケット長を計算してＵＤＰパケット長フィールド２２１とチェックサムフィールド２２２とを新たなＵＤＰパケット長フィールド２２１ｂとチェックサムフィールド２２２ｂとにそれぞれ更新し、新たなＵＤＰヘッダ２２ｂをＤＮＳデータ２３ｂに付加する。

更に、通信部１０は、ＩＰパケット長フィールド２１１とチェックサムフィールド２１２とを新たなＩＰパケット長フィールド２１１ｂとチェックサムフィールド２１２ｂとにそれぞれ更新し、新たなＩＰヘッダ２１ｂをＵＤＰヘッダ２２ｂに付加する。

ここで、通信部１０は、ＩＰヘッダ２１に含まれていた送信元ＩＰアドレスフィールド（不図示）の値を変更しないでそのままＩＰヘッダ２１ｂに転記する。このように作成された新たなパケット２０ｂは、通信部１０からキャッシュサーバ２に送信される。

以上のように構成されたシステムについて図４を用いてその動作例を説明する。なお、以下に説明する動作例は、ドメインネームが「www.example.com」であるサーバ６の名前解決がホスト８によって要求されたときに開始される。

まず、ホスト８からキャッシュサーバ２にサーバ６の名前解決が要求されると、この要求がキャッシュサーバ２から権威サーバ１ａに送信される（ステップＳ１）。なお、ここでサーバ６のＩＰアドレスがキャッシュサーバ２にキャッシュされている場合には、キャッシュサーバ２がサーバ６のＩＰアドレスをホスト８に送信することにより本動作は終了するが、本動作例においては、サーバ６のＩＰアドレスがキャッシュサーバ２にキャッシュされていないものとする。

次に、名前解決の要求を受けた権威サーバ１ａからキャッシュサーバ２にcomゾーンの権威サーバ１ｂのドメインネームとＩＰアドレスとが送信される（ステップＳ２）。なお、図４において、ドメインネームは、「ＮＳ」と表記され、ＩＰアドレスは、「ＩＰ」と表記されている。

次に、名前解決の要求は、ステップＳ２で得られたＩＰアドレスに基づいて、キャッシュサーバ２から権威サーバ１ｂに送信され（ステップＳ３）、この要求を受けた権威サーバ１ｂからキャッシュサーバ２にexample.comゾーンの権威サーバ１ｃのドメインネームとＩＰアドレスとが送信される（ステップＳ４）。

次に、名前解決の要求は、ステップＳ４で得られたＩＰアドレスに基づいて、キャッシュサーバ２から権威サーバ１ｃにＤＮＳＳＥＣ代理装置５を経由して送信される（ステップＳ５）。この要求を受けた権威サーバ１ｃからキャッシュサーバ２に向けてサーバ６のＩＰアドレスが回答されるが（ステップＳ６）、この回答は、ＤＮＳＳＥＣ代理装置５を経由して、ＤＮＳＳＥＣ代理装置５のＺＳＫを用いて生成された電子署名が付加されてキャッシュサーバ２に送信される（ステップＳ７）。

なお、ステップＳ６において、サーバ６が存在しなかった旨の回答がＤＮＳＳＥＣ代理装置５に受信された場合には、ＤＮＳＳＥＣ代理装置５の不在証明生成部１４によって不在証明が生成され、生成された不在証明が署名付加部１３によって電子署名が付加され、電子署名が付加された不在証明がキャッシュサーバ２に送信され、本動作は終了するが、本動作例においては、権威サーバ１ｃからサーバ６のＩＰアドレスがＤＮＳＳＥＣ代理装置５に回答されるものとする。

次に、キャッシュサーバ２から権威サーバ１ｃに向けて鍵情報が要求される（ステップＳ８）。この要求は、ＤＮＳＳＥＣ代理装置５によって受信され、この要求を受けたＤＮＳＳＥＣ代理装置５によって、ＤＮＳＳＥＣ代理装置５のＫＳＫおよびＺＳＫの秘密鍵を用いてそれぞれ生成された電子署名が付加されたＤＮＳＳＥＣ代理装置５の公開鍵情報がキャッシュサーバ２に送信される（ステップＳ９）。

次に、キャッシュサーバ２から権威サーバ１ｂに権威サーバ１ｃの公開鍵ダイジェストが要求され（ステップＳ１０）、権威サーバ１ｂのＺＳＫの秘密鍵を用いて生成された電子署名が付加された権威サーバ１ｃの公開鍵ダイジェストが権威サーバ１ｂからキャッシュサーバ２に送信される（ステップＳ１１）。

次に、キャッシュサーバ２から権威サーバ１ｂに鍵情報が要求され（ステップＳ１２）、権威サーバ１ｂのＫＳＫおよびＺＳＫの秘密鍵を用いてそれぞれ生成された電子署名が付加された権威サーバ１ｂの公開鍵情報がキャッシュサーバ２に送信される（ステップＳ１３）。

次に、キャッシュサーバ２から権威サーバ１ａに権威サーバ１ｂの公開鍵ダイジェストが要求され（ステップＳ１４）、権威サーバ１ａのＺＳＫの秘密鍵を用いて生成された電子署名が付加された権威サーバ１ｂの公開鍵ダイジェストが権威サーバ１ａからキャッシュサーバ２に送信される（ステップＳ１５）。

次に、キャッシュサーバ２から権威サーバ１ａに鍵情報が要求され（ステップＳ１６）、権威サーバ１ａのＫＳＫおよびＺＳＫの秘密鍵を用いてそれぞれ生成された電子署名が付加された権威サーバ１ａの公開鍵情報がキャッシュサーバ２に送信される（ステップＳ１７）。なお、ステップＳ９、ステップＳ１３、およびステップＳ１７においては、ＺＳＫの秘密鍵を用いて生成された電子署名は必ずしも必要ではなく、これらの電子署名が付加されていなくとも後述の検証は可能である。

ここで、キャッシュサーバ２は、公知のＤＮＳＳＥＣの手順に準拠して、予め登録された権威サーバ１ａのＫＳＫの公開鍵に基づいて、権威サーバ１ａのＺＳＫ公開鍵を検証し、そのＺＳＫ公開鍵によって権威サーバ１ｂの公開鍵ダイジェストを検証し、その公開鍵ダイジェストによって権威サーバ１ｂのＫＳＫ公開鍵を検証し、そのＫＳＫ公開鍵によって権威サーバ１ｂのＺＳＫ公開鍵を検証する。

さらに、キャッシュサーバ２は、権威サーバ１ｂのＺＳＫ公開鍵によってＤＮＳＳＥＣ代理装置５の公開鍵ダイジェストを検証し、その公開鍵ダイジェストによってＤＮＳＳＥＣ代理装置５のＫＳＫ公開鍵を検証し、そのＫＳＫ公開鍵によってＤＮＳＳＥＣ代理装置５のＺＳＫ公開鍵を検証する。

このように、キャッシュサーバ２は、権威サーバ１ａと１ｂ、およびＤＮＳＳＥＣ代理装置５から受け取った公開鍵が信頼できるものであることを確認し、検証されたＤＮＳＳＥＣ代理装置５のＺＳＫ公開鍵を用いて、ステップＳ７でＤＮＳＳＥＣ代理装置５によって送信されたサーバ６のＩＰアドレスを検証する。

キャッシュサーバ２は、ＤＮＳＳＥＣ代理装置５によって送信されたサーバ６のＩＰアドレスが信頼できるものと検証された場合には、サーバ６のＩＰアドレスをホスト８に送信すると共に、キャッシュする。

以上に説明したように、本発明の実施の形態のＤＮＳＳＥＣ代理装置５は、ＤＮＳＳＥＣ非対応の権威サーバ１ｃと、キャッシュサーバ２との間に接続するだけで、キャッシュサーバ２に対して、権威サーバ１ｃがＤＮＳＳＥＣに対応しているように動作するため、権威サーバ１ｃを変更することなしに、権威サーバ１ｃにＤＮＳＳＥＣを容易に適用させることができる。

なお、本実施の形態においては、ＤＮＳＳＥＣ代理装置５が１つのＤＮＳ権威サーバ１ｃに対してＤＮＳＳＥＣ機能を代理する例について示したが、本発明においては、図５に示すように、ＤＮＳＳＥＣ代理装置５がＤＮＳＳＥＣに非対応で異なるゾーンを持つ複数のＤＮＳ権威サーバ３０ａ〜３０ｃに対してＤＮＳＳＥＣ機能を代理するようにしてもよい。

この場合には、ＤＮＳＳＥＣ代理装置５は、それぞれのゾーンに対応した複数の鍵を鍵情報格納部１１に格納しておき、署名付加部１３にてどのゾーンからの回答かを判定して、対応する鍵を鍵情報格納部１１から呼び出して署名に利用する事もできる。

１ａ〜１ｃ、３０ａ〜３０ｃ 権威サーバ
２ キャッシュサーバ
３ インターネット
４ ゾーン
５ ＤＮＳＳＥＣ代理装置
６ サーバ
７ ＩＳＰ網
８ ホスト
１０ 通信部
１１ 鍵情報格納部
１２ 情報生成部
１３ 署名付加部
１４ 不在証明生成部

Claims (8)

1. ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバ（１ｃ）と、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバ（２）との間に設けられたＤＮＳＳＥＣ代理装置であって、
   前記ＤＮＳ権威サーバから前記ＤＮＳキャッシュサーバに送信された情報に前記ＤＮＳＳＥＣに準拠した電子署名を付加する署名付加部（１３）と、
   前記電子署名が付加された情報に含まれる送信元ＩＰアドレスを変更することなく該情報を前記ＤＮＳキャッシュサーバに送信する通信部（１０）と
   を備えたＤＮＳＳＥＣ代理装置。
2. 前記ＤＮＳキャッシュサーバから名前解決の要求を受けて、前記ＤＮＳ権威サーバが該要求に応じられなかった場合に、前記ＤＮＳキャッシュサーバに応答するための不在証明を生成する不在証明生成部（１４）を備えたことを特徴とする請求項１に記載のＤＮＳＳＥＣ代理装置。
3. 前記署名付加部は、前記ＤＮＳＳＥＣに準拠した電子署名を前記不在証明に付加することを特徴とする請求項２に記載のＤＮＳＳＥＣ代理装置。
4. 前記電子署名を生成するための秘密鍵を少なくとも格納する鍵情報格納部（１１）を備えたことを特徴とする請求項１乃至請求項３の何れかに記載のＤＮＳＳＥＣ代理装置。
5. ＤＮＳＳＥＣ非対応のＤＮＳ権威サーバ（１ｃ）と、ＤＮＳＳＥＣ対応のＤＮＳキャッシュサーバ（２）との間に設けられたＤＮＳＳＥＣ代理装置（５）を用いたＤＮＳＳＥＣ代理方法であって、
   前記ＤＮＳ権威サーバから前記ＤＮＳキャッシュサーバに送信された情報に前記ＤＮＳＳＥＣに準拠した電子署名を付加する署名付加ステップと、
   前記電子署名が付加された情報に含まれる送信元ＩＰアドレスを変更することなく該情報を前記ＤＮＳキャッシュサーバに送信するトランスペアレント送信ステップと
   を有するＤＮＳＳＥＣ代理方法。
6. 前記ＤＮＳキャッシュサーバから名前解決の要求を受けて、前記ＤＮＳ権威サーバが該要求に応じられなかった場合に、前記ＤＮＳキャッシュサーバに応答するための不在証明を生成する不在証明生成ステップを有することを特徴とする請求項５に記載のＤＮＳＳＥＣ代理方法。
7. 前記署名付加ステップでは、前記ＤＮＳＳＥＣに準拠した電子署名を前記不在証明に付加することを特徴とする請求項６に記載のＤＮＳＳＥＣ代理方法。
8. 前記署名付加ステップで前記電子署名を生成するための秘密鍵を記憶媒体から取得する鍵取得ステップを有することを特徴とする請求項５乃至請求項７の何れかに記載のＤＮＳＳＥＣ代理方法。

Images