JP5345577B2 - 名前解決装置、名前解決方法および名前解決プログラム - Google Patents

Description

本発明は、名前解決装置、名前解決方法および名前解決プログラムに関する。

階層的に構成された名前空間を管理する名前管理システムであるＤＮＳ（Domain Name System）における応答の正当性を保証するための拡張仕様としてＤＮＳＳＥＣ（ＤＮＳSecurity Extensions）が知られている。ＤＮＳＳＥＣにおいては、正当性を保証するために電子署名が利用される。

ＤＮＳＳＥＣが有効化されている場合におけるＤＮＳの構成について図１８を参照しながら説明する。図１８には、クライアント装置１０と、ＤＮＳキャッシュサーバ２０と、ＤＮＳサーバ３０と、ＤＮＳサーバ４０と、ＤＮＳサーバ５０とが図示されている。クライアント装置１０は、名前解決によってドメイン名からＩＰアドレスを獲得してネットワーク上の各種のサービスを利用する。

ＤＮＳキャッシュサーバ２０は、クライアント装置１０とＤＮＳサーバ３０〜５０の間で名前解決に関するやりとりを中継するとともに、クライアント装置１０からの問い合わせに対するＤＮＳサーバ３０〜５０からの応答を問い合わせ結果のキャッシュ２１として記憶する。そして、クライアント装置１０からの問い合わせに対する応答が問い合わせ結果のキャッシュ２１に含まれる場合、ＤＮＳキャッシュサーバ２０は、問い合わせをＤＮＳサーバ３０〜５０へ転送する代わりに、問い合わせに対する応答が問い合わせ結果のキャッシュ２１から取得して代理応答する。

このようにＤＮＳキャッシュサーバ２０がクライアント装置１０からの問い合わせに対するＤＮＳサーバ３０〜５０からの応答を問い合わせ結果のキャッシュ２１として記憶し、それを用いて代理応答を行うことにより、ＤＮＳサーバ３０〜５０とネットワークの負荷を軽減させるとともに、問い合わせへの応答時間を短縮させることができる。

ＤＮＳサーバ３０は、ルートを管理するＤＮＳサーバであり、ＤＮＳ４０は、ルートの配下のｊｐゾーンを管理するＤＮＳサーバであり、ＤＮＳ５０は、ｊｐゾーンの配下のｅｘａｍｐｌｅ．ｊｐゾーンを管理するＤＮＳサーバである。ＤＮＳサーバ３０〜５０は、名前解決のための従来のリソースレコードに加えて、各リソースレコードの正当性を保証するための署名を保持するリソースレコードと、署名に用いられた秘密鍵に対応する公開鍵を保持するリソースレコードと、配下のゾーンの公開鍵の正当性を保証するための情報を保持するリソースレコードとを記憶する。

ＤＮＳＳＥＣにおいては、公開鍵を保持するリソースレコードの署名に用いられる秘密鍵に対応する公開鍵であるＫＳＫ（Key Signing Key）と、それ以外のリソースレコードの署名に用いられる秘密鍵に対応する公開鍵であるＺＳＫ（Zone Signing Key）という２種類の公開鍵がゾーン毎に用意される。以下では、各ゾーンのＫＳＫをそのゾーンの名称の末尾にＫＳＫを付加して表し、各ゾーンのＺＳＫをそのゾーンの名称の末尾にＺＳＫを付加して表す。

ＤＮＳ５０は、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”というドメイン名に対応するＩＰアドレスを保持するＡリソースレコード５１ａと、Ａリソースレコード５１ａの署名を保持するＲＲＳＩＧリソースレコード５１ｂと、Ａリソースレコード５１ａの署名の検証に用いられる公開鍵であるｅｘａｍｐｌｅ．ｊｐ．ＺＳＫを保持するＤＮＳＫＥＹリソースレコード５２ａと、ＤＮＳＫＥＹリソースレコード５２ａの署名を保持するＲＲＳＩＧリソースレコード５２ｂと、ＤＮＳＫＥＹリソースレコード５２ａの署名の検証に用いられる公開鍵であるｅｘａｍｐｌｅ．ｊｐ．ＫＳＫを保持するＤＮＳＫＥＹリソースレコード５３ａと、ＤＮＳＫＥＹリソースレコード５３ａの署名を保持するＲＲＳＩＧリソースレコード５３ｂとを記憶する。

ＤＮＳ４０は、ｅｘａｍｐｌｅ．ｊｐ．ＫＳＫのハッシュを保持するＤＳリソースレコード４１ａと、ＤＳリソースレコード４１ａの署名を保持するＲＲＳＩＧリソースレコード４１ｂと、ＤＳリソースレコード４１ａの署名の検証に用いられる公開鍵であるｊｐ．ＺＳＫを保持するＤＮＳＫＥＹリソースレコード４２ａと、ＤＮＳＫＥＹリソースレコード４２ａの署名を保持するＲＲＳＩＧリソースレコード４２ｂと、ＤＮＳＫＥＹリソースレコード４２ａの署名の検証に用いられる公開鍵であるｊｐ．ＫＳＫを保持するＤＮＳＫＥＹリソースレコード４３ａと、ＤＮＳＫＥＹリソースレコード５３ａの署名を保持するＲＲＳＩＧリソースレコード４３ｂとを記憶する。

ＤＮＳサーバ３０は、ｊｐ．ＫＳＫのハッシュを保持するＤＳリソースレコード３１ａと、ＤＳリソースレコード３１ａの署名を保持するＲＲＳＩＧリソースレコード３１ｂと、ＤＳリソースレコード３１ａの署名の検証に用いられる公開鍵であるルートＺＳＫを保持するＤＮＳＫＥＹリソースレコード３２ａと、ＤＮＳＫＥＹリソースレコード３２ａの署名を保持するＲＲＳＩＧリソースレコード３２ｂと、ＤＮＳＫＥＹリソースレコード３２ａの署名の検証に用いられる公開鍵であるルートＫＳＫを保持するＤＮＳＫＥＹリソースレコード３３ａと、ＤＮＳＫＥＹリソースレコード３３ａの署名を保持するＲＲＳＩＧリソースレコード３３ｂとを記憶する。

このように、リソースレコードの署名と、それを検証するための公開鍵とをリソースレコードとして保持しておくことにより、各リソースレコードの正当性を保証することができる。例えば、Ａリソースレコード５１ａの正当性は、ＲＲＳＩＧリソースレコード５１ｂに保持されている署名とＤＮＳＫＥＹリソースレコード５２ａに保持されている公開鍵によって保証される。ＤＮＳＫＥＹリソースレコード５２ａの正当性は、ＲＲＳＩＧリソースレコード５２ｂに保持されている署名とＤＮＳＫＥＹリソースレコード５３ａに保持されている公開鍵によって保証される。

そして、ＤＮＳＫＥＹリソースレコード５３ａの正当性は、ＤＮＳＫＥＹリソースレコード５３ｂ保持されている署名に加えて、ＤＮＳサーバ４０のＤＳリソースレコード４１ａによって保証される。ＤＳリソースレコード４１ａの正当性は、ＲＲＳＩＧリソースレコード４１ｂに保持されている署名とＤＮＳＫＥＹリソースレコード４２ａに保持されている公開鍵によって保証される。ＤＮＳＫＥＹリソースレコード４２ａの正当性は、ＲＲＳＩＧリソースレコード４２ｂに保持されている署名とＤＮＳＫＥＹリソースレコード４３ａに保持されている公開鍵によって保証される。

そして、ＤＮＳＫＥＹリソースレコード４３ａの正当性は、ＤＮＳＫＥＹリソースレコード４３ｂ保持されている署名に加えて、ＤＮＳサーバ３０のＤＳリソースレコード３１ａによって保証される。ＤＳリソースレコード３１ａの正当性は、ＲＲＳＩＧリソースレコード３１ｂに保持されている署名とＤＮＳＫＥＹリソースレコード３２ａに保持されている公開鍵によって保証される。ＤＮＳＫＥＹリソースレコード３２ａの正当性は、ＲＲＳＩＧリソースレコード３２ｂに保持されている署名とＤＮＳＫＥＹリソースレコード３３ａに保持されている公開鍵によって保証される。

さらに、ＤＮＳＫＥＹリソースレコード３３ａの正当性は、ＤＮＳＫＥＹリソースレコード３３ｂ保持されている署名に加えて、ＤＮＳキャッシュサーバ２０に予め配布されているルートＫＳＫのハッシュ２２によって保証される。このようにＤＮＳＳＥＣにおいては、各ゾーン内のリソースレコードの正当性が同一ゾーン内のＤＮＳＫＥＹリソースレコードに格納された公開鍵によって保証されるとともに、下位のゾーンのＤＮＳＫＥＹリソースレコードの正当性を上位のゾーンのＤＳリソースレコードが保証する信頼の連鎖が構築される（非特許文献１〜３参照）。

続いて、図１８に示した構成において、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”というドメイン名からＩＰアドレスを得る場合の処理手順について図１９を参照しながら説明する。なお、ＤＮＳキャッシュサーバ２０が保持する問い合わせ結果のキャッシュ２１は、空であるものとする。

クライアント装置１０は、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”というドメイン名に対応するＩＰアドレスを得るため、予め知っているＤＮＳキャッシュサーバ２０に対して、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”に対応するＡリソースレコードを問い合わせる（ステップＳ１０）。

問い合わせを受けたＤＮＳキャッシュサーバ２０は、まず、予め知っているＤＮＳサーバ３０に対して、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”に対応するＡリソースレコードを問い合わせる（ステップＳ１１）。ＤＮＳサーバ３０は、図示しないＮＳリソースレコードを参照して、ｊｐゾーンの権威をもつＤＮＳサーバ４０に問い合わせるべき旨を応答する（ステップＳ１２）。

続いて、ＤＮＳキャッシュサーバ２０は、応答で示されたＤＮＳサーバ４０に対して、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”に対応するＡリソースレコードを問い合わせる（ステップＳ１３）。ＤＮＳサーバ４０は、図示しないＮＳリソースレコードを参照して、ｅｘａｍｐｌｅ．ｊｐゾーンの権威をもつＤＮＳサーバ５０に問い合わせるべき旨を応答する（ステップＳ１４）。

続いて、ＤＮＳキャッシュサーバ２０は、応答で示されたＤＮＳサーバ５０に対して、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”に対応するＡリソースレコードを問い合わせる（ステップＳ１５）。ＤＮＳサーバ５０は、”ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ”に対応するＡリソースレコード５１ａの内容（”１９２．１６８．１００．１”）と、Ａリソースレコード５１ａの署名を保持するＲＲＳＩＧリソースレコード５１ｂの内容（”ＺＺＺ”）を応答する（ステップＳ１６）。

応答を受けたＤＮＳキャッシュサーバ２０は、応答内容を検証するため、ＤＮＳサーバ５０に対して、ｅｘａｍｐｌｅ．ｊｐゾーンのＤＮＳＫＥＹを問い合せる（ステップＳ１７）。ＤＮＳサーバ５０は、ＤＮＳＫＥＹリソースレコード５２ａの内容（ｅｘａｍｐｌｅ．ｊｐ．ＺＳＫ）と、ＤＮＳＫＥＹリソースレコード５３ａの内容（ｅｘａｍｐｌｅ．ｊｐ．ＫＳＫ）と、それらのリソースレコードの署名を保持するＲＲＳＩＧリソースレコードの内容を応答する（ステップＳ１８）。

ＤＮＳキャッシュサーバ２０は、応答されたＫＳＫの正当性を検証するため、ＤＮＳサーバ３０に対して、ｅｘａｍｐｌｅ．ｊｐゾーンのＤＳリソースレコードを問い合わせる（ステップＳ１９）。ＤＮＳサーバ３０は、図示しないＮＳリソースレコードを参照して、ｊｐゾーンの権威をもつＤＮＳサーバ４０に問い合わせるべき旨を応答する（ステップＳ２０）。

続いて、ＤＮＳキャッシュサーバ２０は、ＤＮＳサーバ４０に対して、ｅｘａｍｐｌｅ．ｊｐゾーンのＤＳリソースレコードを問い合わせる（ステップＳ２１）。ＤＮＳサーバ４０は、ＤＳリソースレコード４１ａの内容（”ａａａ”）と、ＤＳリソースレコード４１ａの署名を保持するＲＲＳＩＧリソースレコード４１ｂの内容（”ＸＸＸ”）を応答する（ステップＳ２２）。

応答を受けたＤＮＳキャッシュサーバ２０は、応答内容を検証するため、ＤＮＳサーバ４０に対して、ｊｐゾーンのＤＮＳＫＥＹを問い合せる（ステップＳ２３）。ＤＮＳサーバ４０は、ＤＮＳＫＥＹリソースレコード４２ａの内容（ｊｐ．ＺＳＫ）と、ＤＮＳＫＥＹリソースレコード４３ａの内容（ｊｐ．ＫＳＫ）と、それらのリソースレコードの署名を保持するＲＲＳＩＧリソースレコードの内容を応答する（ステップＳ２４）。

ＤＮＳキャッシュサーバ２０は、応答されたＫＳＫの正当性を検証するため、ＤＮＳサーバ３０に対して、ｊｐゾーンのＤＳリソースレコードを問い合わせる（ステップＳ２５）。ＤＮＳサーバ３０は、ＤＳリソースレコード３１ａの内容（”ｂｂｂ”）と、ＤＳリソースレコード３１ａの署名を保持するＲＲＳＩＧリソースレコード３１ｂの内容（”ＶＶＶ”）を応答する（ステップＳ２６）。

応答を受けたＤＮＳキャッシュサーバ２０は、応答内容を検証するため、ＤＮＳサーバ３０に対して、ルートゾーンのＤＮＳＫＥＹを問い合せる（ステップＳ２７）。ＤＮＳサーバ３０は、ＤＮＳＫＥＹリソースレコード３２ａの内容（ルートＺＳＫ）と、ＤＮＳＫＥＹリソースレコード３３ａの内容（ルートＫＳＫ）と、それらのリソースレコードの署名を保持するＲＲＳＩＧリソースレコードの内容を応答する（ステップＳ２８）。

ＤＮＳキャッシュサーバ２０は、Ａリソースレコード５１ａの正当性をＤＮＳＫＥＹリソースレコード５２ａに含まれるｅｘａｍｐｌｅ．ｊｐ．ＺＳＫを用いて検証するとともに、ＤＮＳＫＥＹリソースレコード５２ａの正当性をＤＮＳＫＥＹリソースレコード５３ａに含まれるｅｘａｍｐｌｅ．ｊｐ．ＫＳＫを用いて検証する。さらに、ＤＮＳキャッシュサーバ２０は、ＤＮＳＫＥＹリソースレコード５３ａの正当性を、ルートゾーンのＤＮＳサーバ３０から、Ａリソースレコード５１ａを取得したＤＮＳサーバ５０の上位のＤＮＳサーバ４０まで、再帰的に問い合わせを行って取得したリソースレコードの内容に基づいて検証する。

そして全ての検証が成功すると、ＤＮＳキャッシュサーバ２０は、Ａリソースレコード５１ａの内容をクライアント装置１０に応答する（ステップＳ２９）。

"DNS Security Introduction and Requirements"、［online］、［平成２２年２月１２日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc4033.txt＞ "Resource Records for the DNS Security Extensions"、［online］、［平成２２年２月１２日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc4034.txt＞ "Protocol Modifications for the DNS Security Extensions"、［online］、［平成２２年２月１２日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc4035.txt＞

ＤＮＳにＤＮＳＳＥＣを有効化した場合、応答の正当性が保証される反面で、問い合わせの効率が低下するおそれがある。その理由の１つは、図１９のステップＳ１９〜ステップＳ２８のように、ＤＮＳＫＥＹの正当性を検証するために上位のＤＮＳサーバに複数の問い合わせを行う必要があるためである。他の理由は、名前解決のための従来のリソースレコードに加えて、ＤＮＳＫＥＹやＤＳ等のＤＮＳＳＥＣで用いられるリソースレコードがＤＮＳキャッシュサーバにキャッシュされることになるため、キャッシュが溢れやすくなり、キャッシュミスが発生することが多くなるためである。

本発明は、上記に鑑みてなされたものであって、名前解決のための問い合わせを効率よく行うことができる名前解決装置、名前解決方法および名前解決プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る名前解決装置は、階層的に構成された名前空間を管理する名前管理システムに対する問い合わせへの応答内容をキャッシュするキャッシュ部を有する名前解決装置であって、名前解決のための問い合わせへの応答内容の正当性を、該問い合わせの問い合わせ先の階層のサーバから得られた第１の検証情報を用いて検証するとともに、前記第１の検証情報の正当性を、前記名前管理システムの最上位の階層から該問い合わせの問い合わせ先の階層の上位の階層までの各階層のサーバに対して問い合わせて得られた第２の検証情報を用いて検証し、正当性が検証された前記第１の検証情報を前記キャッシュ部に記憶させて再利用する検証部と、前記キャッシュ部に空き領域を作成する場合に、前記第１の検証情報を前記キャッシュ部に残すように制御するキャッシュ制御部とを備えることを特徴とする。

また、本発明に係る名前解決方法は、階層的に構成された名前空間を管理する名前管理システムに対する問い合わせへの応答内容をキャッシュするキャッシュ部を有する名前解決装置によって実行される名前解決方法であって、前記名前解決装置が、名前解決のための問い合わせへの応答内容の正当性を、該問い合わせの問い合わせ先の階層のサーバから得られた第１の検証情報を用いて検証する第１の検証工程と、前記名前解決装置が、前記第１の検証情報の正当性を、前記名前管理システムの最上位の階層から該問い合わせの問い合わせ先の階層の上位の階層までの各階層のサーバに対して問い合わせて得られた第２の検証情報を用いて検証する第２の検証工程と、前記名前解決装置が、前記第２の検証工程において正当性が検証された前記第１の検証情報を再利用のために前記キャッシュ部に記憶させる保管工程と、前記名前解決装置が、前記キャッシュ部に空き領域を作成する場合に、前記第１の検証情報を前記キャッシュ部に残すように制御するキャッシュ解放工程とを含むことを特徴とする。

また、本発明に係る名前解決プログラムは、コンピュータを、上記の名前解決方法を実行する名前解決装置として機能させることを特徴とする。

本発明に係る名前解決装置、名前解決方法および名前解決プログラムは、名前解決のための問い合わせを効率よく行うことができるという効果を奏する。

図１は、実施例１に係る名前解決装置の構成を示す図である。 図２は、実施例１における名前解決処理の処理手順を示す図である。 図３は、実施例１におけるキャッシュ解放処理の処理手順を示す図である。 図４は、実施例２に係る名前解決装置の構成を示す図である。 図５は、深度情報の一例を示す図である。 図６は、深度情報の他の例を示す図である。 図７は、実施例２における名前解決処理の処理手順を示す図である。 図８は、実施例２におけるキャッシュ解放処理の処理手順を示す図である。 図９は、実施例３に係る名前解決装置の構成を示す図である。 図１０は、頻度情報の一例を示す図である。 図１１は、実施例３における名前解決処理の処理手順を示す図である。 図１２は、実施例３におけるキャッシュ解放処理の処理手順を示す図である。 図１３は、実施例４に係る名前解決装置の構成を示す図である。 図１４は、頻度情報の一例を示す図である。 図１５は、実施例４における名前解決処理の処理手順を示す図である。 図１６は、実施例４におけるキャッシュ解放処理の処理手順を示す図である。 図１７は、名前解決プログラムを実行するコンピュータを示す機能ブロック図である。 図１８は、ＤＮＳＳＥＣが有効化されている場合におけるＤＮＳの構成の一例を示す機能ブロック図である。 図１９は、ＤＮＳＳＥＣが有効化されている場合における名前解決の処理手順の一例を示す機能ブロック図である。 図２０は、ＤＮＳＫＥＹがキャッシュされている場合における名前解決の処理手順の一例を示す機能ブロック図である。

以下に、本発明に係る名前解決装置、名前解決方法および名前解決プログラムの実施例を図面に基づいて詳細に説明する。なお、以下の例では、階層的に構成された名前空間を管理する名前管理システムの例としてＤＮＳを示すが、ＬＤＡＰ（Lightweight Directory Access Protocol）のような階層的に構成された名前空間を管理する他の名前管理システムにも本発明を適用することができる。

本実施例に係る名前解決装置１００は、ＤＮＳ９０に対して問い合わせを行って名前を解決する装置であり、名前解決のための従来のリソースレコードに加えて、ＤＮＳＳＥＣにおいて追加されたリソースレコードのうち、検証済みのＤＮＳＫＥＹリソースレコードのみをキャッシュする。そして、名前解決装置１００は、ＤＮＳＫＥＹリソースレコードができるだけ長くキャッシュに残るようにキャッシュ制御を行う。

このように検証済みのＤＮＳＫＥＹリソースレコードを優先的にキャッシュすることにより、ＤＮＳＳＥＣが有効化されている場合でも、名前解決の完了までの時間をＤＮＳＳＥＣが有効化されていない場合とほぼ同等にすることができる。

例えば、Ａリソースレコードがキャッシュされていない場合でも、そのＡリソースレコードが属するゾーンの検証済みのＤＮＳＫＥＹリソースレコードがキャッシュされていれば、図２０に示すように、ＤＮＳＫＥＹを検証するためのＤＳリソースレコード等を上位のゾーンのＤＮＳサーバに再帰的に問い合わせる処理（図１９のステップＳ１９〜ステップＳ２７）が不要となるため、名前解決の完了までの時間とやりとりされる情報の量は、ＤＮＳＳＥＣが有効化されていない場合とほぼ同等となる。

また、ゾーン内のネットワークインターフェース毎に存在するＡリソースレコード等と異なり、ＤＮＳＫＥＹリソースレコードは、ゾーン毎に比較的少数（例えば、２つ程度）しか存在しないため、優先的にキャッシュしたとしてもＤＮＳＫＥＹリソースレコードがキャッシュ領域に占める割合は比較的小さく、キャッシュミスが多くなることはない。

なお、名前解決装置１００は、図１８に示したＤＮＳキャッシュサーバ２０のようにＤＮＳへの問い合わせを中継する装置であってもよいし、ＤＮＳキャッシュサーバ２０のような装置を介さずに、権威をもつＤＮＳサーバへ直接に問い合わせを行うクライアント装置であってもよい。また、以下の説明では、説明を簡単にするため、ＴＴＬ（Time To Live）等の有効期間については考慮しないこととする。

次に、図１を参照しながら、本実施例に係る名前解決装置１００の構成について説明する。図１に示すように、名前解決装置１００は、名前解決部１０１と、問合せ部１０２と、キャッシュ部１０３と、キャッシュ制御部１０４と、検証部１０５とを有する。名前解決部１０１は、名前解決のための問い合わせの生成と、問い合わせに対する応答の解析を行う。

問合せ部１０２は、名前解決部１０１によって生成された問い合わせをＤＮＳ９０へ送信し、ＤＮＳ９０から返信された応答を名前解決部１０１に引き渡すとともにキャッシュ部１０３に記憶させる。そして、名前解決部１０１によって新たに生成された問い合わせに対応する応答がキャッシュ部１０３に記憶されている場合、問合せ部１０２は、その問い合わせをＤＮＳ９０へ送信せずに、その問い合わせに対応する応答をキャッシュ部１０３から取得して名前解決部１０１に引き渡す。

問い合わせ先のゾーンでＤＮＳＳＥＣが有効化されている場合、問合せ部１０２は、名前解決部１０１によって生成された問い合わせに対応する応答の正当性を検証部１０５に検証させ、正当性の検証が成功した場合にのみ応答を名前解決部１０１に引き渡すとともにキャッシュ部１０３に記憶させる。正当性が確認された応答をキャッシュ部１０３に記憶させることにより、キャッシュ部１０３から取得した応答を利用するたびに正当性を確認することが不要となる。なお、問い合わせ先のゾーンでＤＮＳＳＥＣが有効化されているか否かは、応答に含まれる所定のビットの値やＲＲＳＩＧリソースレコードの有無等から判断することができる。

キャッシュ部１０３は、名前解決のための問い合わせに対する応答と、検証部１０５によって正当性が検証されたＤＮＳＫＥＹリソースレコードとを記憶する。キャッシュ制御部１０４は、問合せ部１０２および検証部１０５の要求に応じて、キャッシュ部１０３に記憶されている情報の検索と、キャッシュ部１０３への情報の格納を行う。また、キャッシュ制御部１０４は、キャッシュ部１０３へ新たな情報を格納するにあたって、キャッシュ部１０３の使用量を確認し、使用量が閾値を超過している場合には、新たな情報を格納する領域を確保するために、キャッシュ部１０３に記憶されている情報を削除する。なお、削除される情報は、新たな情報を格納する領域が確保されることを条件として、なるべく少ないことが好ましい。

キャッシュ制御部１０４は、キャッシュ部１０３に記憶されている情報を削除する場合に、記憶されているＤＮＳＫＥＹリソースレコードを優先的に残して、他の種類のリソースレコードを削除する。なお、キャッシュ部１０３へ新たな情報を格納するタイミングだけでなく、定期的にキャッシュ部１０３の使用量を確認して使用量が閾値を超過している場合にはキャッシュ部１０３に記憶されている情報を削除するようにキャッシュ制御部１０４を構成してもよい。

また、使用量に関する閾値とキャッシュ部１０３に記憶されている情報を削除する量については、適宜決定することができ、キャッシュ部１０３へ新たな情報を格納する場合と定期的にキャッシュ部１０３の使用量を確認する場合とで値が異なっていてもよい。例えば、キャッシュ部１０３へ新たな情報を格納する場合における使用量に関する閾値は、解放によって失われる情報量を最小にするために、キャッシュがフルに使用されていることを示す値に設定し、定期的にキャッシュ部１０３の使用量を確認する場合における使用量に関する閾値は、新たな情報を格納するたびに空き領域を作成することによる負荷の増大を防止するために、ある程度まとまった空き領域を用意できるようにキャッシュ容量の９割程度の値に設定することとしてもよい。

検証部１０５は、ＤＮＳＳＥＣが有効化されているゾーンに対して行われた名前解決のための問い合わせに対する応答の正当性を確認する。具体的には、検証部１０５は、問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードを問合せ部１０２に取得させ、取得されたＤＮＳＫＥＹリソースレコードに含まれる公開鍵（ＺＳＫ）を用いて、応答されたリソースレコードの署名を検証する。さらに、検証部１０５は、取得されたＤＮＳＫＥＹリソースレコードに含まれる公開鍵（ＫＳＫ）を用いて、ＤＮＳＫＥＹリソースレコードの署名を検証するとともに、最上位のゾーンから、問い合わせが行われたゾーンの上位のゾーンまで、問合せ部１０２に再帰的に問い合わせを行わせ、取得されたＤＳリソースレコード等を用いて、ＤＮＳＫＥＹリソースレコードに含まれる公開鍵（ＫＳＫ）を含む信頼の連鎖を検証する。

ＤＮＳＫＥＹリソースレコードの正当性が検証されると、検証部１０５は、正当性が確認されたＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に記憶させる。そして、ＳＳＥＣが有効化されているゾーンに対して行われた名前解決のための問い合わせに対する応答の正当性を新たに検証する場合、問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に記憶されていれば、検証部１０５は、キャッシュ部１０３に記憶されているＤＮＳＫＥＹリソースレコードに含まれる公開鍵（ＺＳＫ）を用いて、応答されたリソースレコードの署名を検証し、ＤＳリソースレコード等を取得するための再帰的な問い合わせを問合せ部１０２に行わせない。

このように、正当性が検証されたＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に記憶させ、優先的にキャッシュ部１０３に残すことにより、図１９のステップＳ１９〜ステップＳ２８のような上位のゾーンへの再帰的な問い合わせの発生を抑止し、名前解決の完了までの時間を短縮するとともにやりとりされる情報の量を削減することができる。

次に、図２を参照しながら名前解決装置１００による名前解決処理の処理手順について説明する。図２に示すように、名前解決部１０１が、名前解決のための問い合わせを生成し、問合せ部１０２に送信を依頼すると（ステップＳ１０１）、キャッシュ制御部１０４が、その問い合わせに対応する応答であるリソースレコードをキャッシュ部１０３から検索する（ステップＳ１０２）。ここで、該当するリソースレコードが存在した場合（ステップＳ１０３肯定）、問合せ部１０２は、検索されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ１１３）。

一方、該当するリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ１０３否定）、問合せ部１０２がＤＮＳ９０に対して問い合わせを送信し、応答を受信する（ステップＳ１０４）。ここで、ＤＮＳＳＥＣが有効でない場合（ステップＳ１０５否定）、キャッシュ制御部１０４が、応答されたリソースレコードをキャッシュ部１０３に記憶させる（ステップＳ１１２）。そして、問合せ部１０２は、応答されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ１１３）。

ＤＮＳＳＥＣが有効な場合（ステップＳ１０５肯定）、キャッシュ制御部１０４が、問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から検索する（ステップＳ１０６）。ここで、該当するＤＮＳＫＥＹリソースレコードが存在した場合（ステップＳ１０７肯定）、検証部１０５が、そのＤＮＳＫＥＹリソースレコードを用いて、ステップＳ１０４で得られたリソースレコードの正当性を検証する（ステップＳ１１１）。

そして、正当性の検証が成功したならば、キャッシュ制御部１０４が、ステップＳ１０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ１１２）。そして、問合せ部１０２は、ステップＳ１０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ１１３）。

一方、該当するＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ１０７否定）、問合せ部１０２は、ステップＳ１０４で問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードを取得する（ステップＳ１０８）。さらに、問合せ部１０２は、最上位のゾーンから、ステップＳ１０４で問い合わせが行われたゾーンの上位のゾーンまで、再帰的に問い合わせを行ってＤＳリソースレコードとＤＮＳＫＥＹリソースレコードを取得し、取得されたＤＳリソースレコード等を用いて、検証部１０５が、ステップＳ１０８で取得されたＤＮＳＫＥＹリソースレコードの正当性を検証する（ステップＳ１０９）。この再帰的な問い合わせにおいて、取得すべきＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在する場合、問合せ部１０２は、そのＤＮＳＫＥＹリソースレコードをＤＮＳ９０から取得する代わりに、キャッシュ部１０３から取得する。

そして、正当性の検証が成功したならば、キャッシュ制御部１０４が、ステップＳ１０８で得られたＤＮＳＫＥＹリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ１１０）。続いて、検証部１０５が、正当性が検証されたＤＮＳＫＥＹリソースレコードを用いて、ステップＳ１０４で得られたリソースレコードの正当性を検証する（ステップＳ１１１）。

そして、正当性の検証が成功したならば、キャッシュ制御部１０４が、ステップＳ１０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ１１２）。そして、問合せ部１０２は、ステップＳ１０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ１１３）。

次に、図３を参照しながら、キャッシュ制御部１０４が、新たな情報をキャッシュ部１０３に格納するタイミング、あるいは、定期的なタイミングで実行するキャッシュ解放処理の処理手順について説明する。キャッシュ制御部１０４は、キャッシュ部１０３の使用量を確認し（ステップＳ２０１）、使用量が閾値を超過していなければ（ステップＳ２０２否定）、特に処理を行うことなくキャッシュ解放処理を終了する。

一方、使用量が閾値を超過していれば（ステップＳ２０２肯定）、キャッシュ制御部１０４は、ＤＮＳＫＥＹリソースレコードを優先的に残しつつ、キャッシュ部１０３に記憶されているリソースレコードを削除して領域を解放する（ステップＳ２０３）。

上述してきたように、本実施例では、検証済みのＤＮＳＫＥＹリソースレコードを優先的にキャッシュすることとしたので、ＤＮＳＳＥＣが有効化されている場合でも、ＤＮＳＳＥＣが有効化されていない場合とほぼ同等の効率で名前解決を実行することができる。

本実施例では、キャッシュ容量等の問題からキャッシュされているＤＮＳＫＥＹリソースレコードの一部を削除する例について説明する。なお、以下の説明では、既に説明した部分と同様の部分には、既に説明した部分と同一の符号を付すこととし、重複する説明を省略することとする。

まず、図４を参照しながら、本実施例に係る名前解決装置２００の構成について説明する。図４に示すように、名前解決装置２００は、名前解決部１０１と、問合せ部１０２と、キャッシュ部１０３と、キャッシュ制御部２０４と、検証部１０５と、深度情報記憶部２０８とを有する。

深度情報記憶部２０８は、キャッシュ部１０３に記憶されている各ＤＮＳＫＥＹリソースレコードに対応するゾーンの階層の深さを深度情報として保持する。深度情報の一例を図５に示す。図５の例が示すように、深度情報は、ゾーンや深度といった項目を有する。ゾーンの項目は、ＤＮＳＫＥＹリソースレコードに対応するゾーンの名称が格納される項目である。深度の項目は、ＤＮＳＫＥＹリソースレコードに対応するゾーンが、ルートからみて何番目の階層にあたるかを示す値が格納される項目である。

図５に示す深度情報の１行目には、ゾーンの項目に”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”が設定され、深度の項目に”４”が設定されている。これは、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンのＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に記憶されており、そのゾーンは、ルートからみて４番目の階層にあたることを示している。

なお、深度情報は、キャッシュ部１０３におけるＤＮＳＫＥＹリソースレコードの格納位置等の他の属性情報を含んでもよい。また、深度情報は、同じ深度のゾーンを連結させたリスト（図６参照）のような他の形式で構成されていてもよい。

キャッシュ制御部２０４は、問合せ部１０２および検証部１０５の要求に応じて、キャッシュ部１０３に記憶されている情報の検索と、キャッシュ部１０３への情報の格納を行う。キャッシュ制御部２０４は、キャッシュ部１０３へ新たなＤＮＳＫＥＹリソースレコードを格納する場合、そのＤＮＳＫＥＹリソースレコードに対応するゾーンの深度を取得して、求めた深度をゾーンの名称と対応付けて深度情報記憶部２０８に記録する。

ゾーンの深度は、ゾーンの名称に含まれるラベルの数から取得することができる。例えば、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”というゾーンの名称には、”ｔｏｋｙｏ”、”ｋａｎｔｏ”、”ｅｘａｍｐｌｅ”、”ｊｐ”という４つのラベルが含まれるため、このゾーンの深度は”４”となる。なお、ゾーンの深度は、ＤＮＳＫＥＹリソースレコードの正当性を検証するために再帰的に問い合わせを行った階層の深さから取得してもよい。

また、キャッシュ制御部２０４は、キャッシュ部１０３へ新たな情報を格納するにあたって、キャッシュ部１０３の使用量を確認し、使用量が閾値を超過している場合には、新たな情報を格納する領域を確保するために、キャッシュ部１０３に記憶されている情報を削除する。なお、削除される情報は、新たな情報を格納する領域が確保されることを条件として、なるべく少ないことが好ましい。

キャッシュ制御部２０４は、キャッシュ部１０３に記憶されている情報を削除する場合に、記憶されているＤＮＳＫＥＹリソースレコードを優先的に残して、他の種類のリソースレコードを削除する。そして、他の種類のリソースレコードを削除してもキャッシュ部１０３の使用量が閾値を超過している場合には、キャッシュ制御部２０４は、深度情報記憶部２０８を参照して、深度の値が小さいゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除するとともに、削除したＤＮＳＫＥＹリソースレコードに対応するゾーンの情報を深度情報記憶部２０８から削除する。

ここで、「深度の値が小さいゾーンのＤＮＳＫＥＹリソースレコードを削除する」とは、例えば、深度の値が最も小さいゾーンのＤＮＳＫＥＹリソースレコードを削除することでもよいし、深度の値が最も大きいゾーンのＤＮＳＫＥＹリソースレコードを残して他のＤＮＳＫＥＹリソースレコードを削除することでもよいし、深度の値が所定値よりも小さいゾーンのＤＮＳＫＥＹリソースレコードを削除することでもよいし、キャッシュ部１０３の使用量が所定値を下回るまで深度の値が小さい順にＤＮＳＫＥＹリソースレコードを削除することでもよい。

深度の値が小さいゾーンのＤＮＳＫＥＹリソースレコードは、キャッシュ部１０３から削除されても、ルートからの階層が少ないので、少ないコストで正当性を検証することができる。例えば、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称をもつ深度４のゾーンのＤＮＳＫＥＹリソースレコードの正当性を検証するには、ルート、”ｊｐ．”、”ｅｘａｍｐｌｅ．ｊｐ．”、”ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という４つの階層からＤＳリソースレコード等を取得する必要があるが、”ｊｐ．”という名称をもつ深度１のゾーンのＤＮＳＫＥＹリソースレコードの正当性を検証するには、ルートという１つの階層からＤＳリソースレコード等を取得すればよい。

このため、階層が深いゾーンのＤＮＳＫＥＹリソースレコードを優先的に残すことにより、ＤＮＳＫＥＹリソースレコードの正当性の検証に必要な問い合わせを最小限に抑えて、名前解決の完了までの時間を短くすることができる。

なお、キャッシュ部１０３へ新たな情報を格納するタイミングだけでなく、定期的にキャッシュ部１０３の使用量を確認して使用量が閾値を超過している場合にはキャッシュ部１０３に記憶されている情報を削除するようにキャッシュ制御部２０４を構成してもよい。また、使用量に関する閾値とキャッシュ部１０３に記憶されている情報を削除する量については、適宜決定することができ、キャッシュ部１０３へ新たな情報を格納する場合と定期的にキャッシュ部１０３の使用量を確認する場合とで値が異なっていてもよい。また、どの階層までのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除するかについては、予め決めておいてもよいし、削除されるＤＮＳＫＥＹリソースレコードが最少で済むように動的に決定してもよい。

次に、図７を参照しながら名前解決装置２００による名前解決処理の処理手順について説明する。図７に示すように、名前解決部１０１が、名前解決のための問い合わせを生成し、問合せ部１０２に送信を依頼すると（ステップＳ３０１）、キャッシュ制御部２０４が、その問い合わせに対応する応答であるリソースレコードをキャッシュ部１０３から検索する（ステップＳ３０２）。ここで、該当するリソースレコードが存在した場合（ステップＳ３０３肯定）、問合せ部１０２は、検索されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ３１４）。

一方、該当するリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ３０３否定）、問合せ部１０２がＤＮＳ９０に対して問い合わせを送信し、応答を受信する（ステップＳ３０４）。ここで、ＤＮＳＳＥＣが有効でない場合（ステップＳ３０５否定）、キャッシュ制御部２０４が、応答されたリソースレコードをキャッシュ部１０３に記憶させる（ステップＳ３１３）。そして、問合せ部１０２は、応答されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ３１４）。

ＤＮＳＳＥＣが有効な場合（ステップＳ３０５肯定）、キャッシュ制御部２０４が、問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から検索する（ステップＳ３０６）。ここで、該当するＤＮＳＫＥＹリソースレコードが存在した場合（ステップＳ３０７肯定）、検証部１０５が、そのＤＮＳＫＥＹリソースレコードを用いて、ステップＳ３０４で得られたリソースレコードの正当性を検証する（ステップＳ３１２）。

そして、正当性の検証が成功したならば、キャッシュ制御部２０４が、ステップＳ３０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ３１３）。そして、問合せ部１０２は、ステップＳ３０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ３１４）。

一方、該当するＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ３０７否定）、問合せ部１０２は、ステップＳ３０４で問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードを取得する（ステップＳ３０８）。さらに、問合せ部１０２は、最上位のゾーンから、ステップＳ３０４で問い合わせが行われたゾーンの上位のゾーンまで、再帰的に問い合わせを行ってＤＳリソースレコードとＤＮＳＫＥＹリソースレコードを取得し、取得されたＤＳリソースレコード等を用いて、検証部１０５が、ステップＳ３０８で取得されたＤＮＳＫＥＹリソースレコードの正当性を検証する（ステップＳ３０９）。この再帰的な問い合わせにおいて、取得すべきＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在する場合、問合せ部１０２は、そのＤＮＳＫＥＹリソースレコードをＤＮＳ９０から取得する代わりに、キャッシュ部１０３から取得する。

そして、正当性の検証が成功したならば、キャッシュ制御部２０４が、ステップＳ３０８で得られたＤＮＳＫＥＹリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させるとともに（ステップＳ３１０）、そのＤＮＳＫＥＹリソースレコードを取得したゾーンの深度を深度情報記憶部２０８に記録する（ステップＳ３１１）。続いて、検証部１０５が、正当性が検証されたＤＮＳＫＥＹリソースレコードを用いて、ステップＳ３０４で得られたリソースレコードの正当性を検証する（ステップＳ３１２）。

そして、正当性の検証が成功したならば、キャッシュ制御部２０４が、ステップＳ３０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ３１３）。そして、問合せ部１０２は、ステップＳ３０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ３１４）。

次に、図８を参照しながら、キャッシュ制御部２０４が、新たな情報をキャッシュ部１０３に格納するタイミング、あるいは、定期的なタイミングで実行するキャッシュ解放処理の処理手順について説明する。キャッシュ制御部２０４は、キャッシュ部１０３の使用量を確認し（ステップＳ４０１）、使用量が閾値を超過していなければ（ステップＳ４０２否定）、特に処理を行うことなくキャッシュ解放処理を終了する。

一方、使用量が閾値を超過していれば（ステップＳ４０２肯定）、キャッシュ制御部２０４は、ＤＮＳＫＥＹリソースレコードを優先的に残しつつ、キャッシュ部１０３に記憶されている他の種類のリソースレコードを削除して領域を解放する（ステップＳ４０３）。そして、解放によって、キャッシュ部１０３の使用量が閾値以下となれば（ステップＳ２０４否定）、キャッシュ制御部２０４は、キャッシュ解放処理を終了する。

解放後もキャッシュ部１０３の使用量が閾値を超過している場合（ステップＳ２０４肯定）、キャッシュ制御部２０４は、深度情報記憶部２０８を参照して、上述したように、深度の値が小さいゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除して領域を解放するとともに、削除したＤＮＳＫＥＹリソースレコードに対応するゾーンの情報を深度情報記憶部２０８から削除する（ステップＳ４０５）。

上述してきたように、本実施例では、階層が深いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に優先的に残すこととしたので、ＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除することの影響を小さく抑えることができる。

本実施例では、キャッシュ容量等の問題からキャッシュされているＤＮＳＫＥＹリソースレコードの一部を削除する他の例について説明する。

まず、図９を参照しながら、本実施例に係る名前解決装置３００の構成について説明する。図９に示すように、名前解決装置３００は、名前解決部１０１と、問合せ部１０２と、キャッシュ部１０３と、キャッシュ制御部３０４と、検証部１０５と、頻度情報記憶部３０９とを有する。

頻度情報記憶部３０９は、キャッシュ部１０３に記憶されている各ＤＮＳＫＥＹリソースレコードに対応する問い合わせの頻度を頻度情報として保持する。頻度情報の一例を図１０に示す。図１０の例が示すように、頻度情報は、ゾーンや問い合わせ回数といった項目を有する。ゾーンの項目は、ＤＮＳＫＥＹリソースレコードに対応するゾーンの名称が格納される項目である。問い合わせ回数の項目は、ＤＮＳＫＥＹリソースレコードに対応するゾーンに対して問い合わせが行われた回数が格納される項目であり、定期的に０にリセットされる。

図１０に示す頻度情報の１行目には、ゾーンの項目に”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”が設定され、問い合わせ回数の項目に”１”が設定されている。これは、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンのＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に記憶されており、そのゾーンに対して問い合わせが４回行われたことを示している。

なお、頻度情報は、キャッシュ部１０３におけるＤＮＳＫＥＹリソースレコードの格納位置等の他の属性情報を含んでもよい。また、頻度情報は、他の形式で構成されていてもよい。

キャッシュ制御部３０４は、問合せ部１０２および検証部１０５の要求に応じて、キャッシュ部１０３に記憶されている情報の検索と、キャッシュ部１０３への情報の格納を行う。キャッシュ制御部３０４は、問合せ部１０２からキャッシュ部１０３に記憶されている情報の検索を要求されると、要求された情報に対応するゾーンに頻度情報の問い合わせ回数を１を加算する。なお、問い合わせ回数の加算は、名前解決部１０１や問合せ部１０２が行ってもよい。

また、キャッシュ制御部３０４は、キャッシュ部１０３へ新たな情報を格納するにあたって、キャッシュ部１０３の使用量を確認し、使用量が閾値を超過している場合には、新たな情報を格納する領域を確保するために、キャッシュ部１０３に記憶されている情報を削除する。なお、削除される情報は、新たな情報を格納する領域が確保されることを条件として、なるべく少ないことが好ましい。

キャッシュ制御部３０４は、キャッシュ部１０３に記憶されている情報を削除する場合に、記憶されているＤＮＳＫＥＹリソースレコードを優先的に残して、他の種類のリソースレコードを削除する。そして、他の種類のリソースレコードを削除してもキャッシュ部１０３の使用量が閾値を超過している場合には、キャッシュ制御部３０４は、頻度情報記憶部３０９を参照して、問い合わせ回数の値が小さいゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除するとともに、削除したＤＮＳＫＥＹリソースレコードに対応するゾーンの情報を頻度情報記憶部３０９から削除する。

ここで、「問い合わせ回数の値が小さいゾーンのＤＮＳＫＥＹリソースレコードを削除する」とは、例えば、問い合わせ回数の値が最も小さいゾーンのＤＮＳＫＥＹリソースレコードを削除することでもよいし、問い合わせ回数の値が最も大きいゾーンのＤＮＳＫＥＹリソースレコードを残して他のＤＮＳＫＥＹリソースレコードを削除することでもよいし、問い合わせ回数の値が所定値よりも小さいゾーンのＤＮＳＫＥＹリソースレコードを削除することでもよいし、キャッシュ部１０３の使用量が所定値を下回るまで問い合わせ回数の値が小さい順にＤＮＳＫＥＹリソースレコードを削除することでもよい。

問い合わせの頻度が高いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から頻繁に削除すると、ＤＮＳＫＥＹリソースレコードの正当性を確認するために再帰的な問い合わせを行ってＤＳリソースレコード等を取得する処理を頻繁に行うことが必要となり、名前解決の完了までに要する時間が長くなるおそれがある。問い合わせの頻度が低いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除しても、そのような状況が発生する機会は少なくて済む。

このため、問い合わせの頻度が高いゾーンのＤＮＳＫＥＹリソースレコードを優先的に残すことにより、ＤＮＳＫＥＹリソースレコードの正当性の検証に必要な問い合わせを最小限に抑えて、名前解決の完了までの時間を短くすることができる。

なお、キャッシュ部１０３へ新たな情報を格納するタイミングだけでなく、定期的にキャッシュ部１０３の使用量を確認して使用量が閾値を超過している場合にはキャッシュ部１０３に記憶されている情報を削除するようにキャッシュ制御部３０４を構成してもよい。また、使用量に関する閾値とキャッシュ部１０３に記憶されている情報を削除する量については、適宜決定することができ、キャッシュ部１０３へ新たな情報を格納する場合と定期的にキャッシュ部１０３の使用量を確認する場合とで値が異なっていてもよい。また、どの問い合わせ回数までのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除するかについては、予め決めておいてもよいし、削除されるＤＮＳＫＥＹリソースレコードが最少で済むように動的に決定してもよい。

次に、図１１を参照しながら名前解決装置３００による名前解決処理の処理手順について説明する。図１１に示すように、名前解決部１０１が、名前解決のための問い合わせを生成し、問合せ部１０２に送信を依頼すると（ステップＳ５０１）、キャッシュ制御部３０４が、その問い合わせに対応するゾーンの頻度情報の問い合わせ回数の値に１を加算するとともに（ステップＳ５０２）、その問い合わせに対応する応答であるリソースレコードをキャッシュ部１０３から検索する（ステップＳ５０３）。なお、問い合わせに対応するゾーンが頻度情報に存在しない場合、キャッシュ制御部３０４は、そのゾーンを頻度情報に追加し、問い合わせ回数として１を設定する。

ここで、該当するリソースレコードが存在した場合（ステップＳ５０４肯定）、問合せ部１０２は、検索されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ５１４）。

一方、該当するリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ５０４否定）、問合せ部１０２がＤＮＳ９０に対して問い合わせを送信し、応答を受信する（ステップＳ５０５）。ここで、ＤＮＳＳＥＣが有効でない場合（ステップＳ５０６否定）、キャッシュ制御部３０４が、応答されたリソースレコードをキャッシュ部１０３に記憶させる（ステップＳ５１３）。そして、問合せ部１０２は、応答されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ５１４）。

ＤＮＳＳＥＣが有効な場合（ステップＳ５０６肯定）、キャッシュ制御部３０４が、問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から検索する（ステップＳ５０７）。ここで、該当するＤＮＳＫＥＹリソースレコードが存在した場合（ステップＳ５０８肯定）、検証部１０５が、そのＤＮＳＫＥＹリソースレコードを用いて、ステップＳ５０５で得られたリソースレコードの正当性を検証する（ステップＳ５１２）。

そして、正当性の検証が成功したならば、キャッシュ制御部３０４が、ステップＳ５０５で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ５１３）。そして、問合せ部１０２は、ステップＳ５０５で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ５１４）。

一方、該当するＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ５０８否定）、問合せ部１０２は、ステップＳ５０５で問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードを取得する（ステップＳ５０９）。さらに、問合せ部１０２は、最上位のゾーンから、ステップＳ３０４で問い合わせが行われたゾーンの上位のゾーンまで、再帰的に問い合わせを行ってＤＳリソースレコードとＤＮＳＫＥＹリソースレコードを取得し、取得されたＤＳリソースレコード等を用いて、検証部１０５が、ステップＳ５０９で取得されたＤＮＳＫＥＹリソースレコードの正当性を検証する（ステップＳ５１０）。この再帰的な問い合わせにおいて、取得すべきＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在する場合、問合せ部１０２は、そのＤＮＳＫＥＹリソースレコードをＤＮＳ９０から取得する代わりに、キャッシュ部１０３から取得する。

そして、正当性の検証が成功したならば、キャッシュ制御部３０４が、ステップＳ５０９で得られたＤＮＳＫＥＹリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ５１１）続いて、検証部１０５が、正当性が検証されたＤＮＳＫＥＹリソースレコードを用いて、ステップＳ５０５で得られたリソースレコードの正当性を検証する（ステップＳ５１２）。

そして、正当性の検証が成功したならば、キャッシュ制御部３０４が、ステップＳ５０５で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ５１３）。そして、問合せ部１０２は、ステップＳ５０５で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ５１４）。

次に、図１２を参照しながら、キャッシュ制御部３０４が、新たな情報をキャッシュ部１０３に格納するタイミング、あるいは、定期的なタイミングで実行するキャッシュ解放処理の処理手順について説明する。キャッシュ制御部３０４は、キャッシュ部１０３の使用量を確認し（ステップＳ６０１）、使用量が閾値を超過していなければ（ステップＳ６０２否定）、特に処理を行うことなくキャッシュ解放処理を終了する。

一方、使用量が閾値を超過していれば（ステップＳ６０２肯定）、キャッシュ制御部３０４は、ＤＮＳＫＥＹリソースレコードを優先的に残しつつ、キャッシュ部１０３に記憶されている他の種類のリソースレコードを削除して領域を解放する（ステップＳ６０３）。そして、解放によって、キャッシュ部１０３の使用量が閾値以下となれば（ステップＳ６０４否定）、キャッシュ制御部３０４は、キャッシュ解放処理を終了する。

解放後もキャッシュ部１０３の使用量が閾値を超過している場合（ステップＳ６０４肯定）、キャッシュ制御部３０４は、頻度情報記憶部３０９を参照して、上述したように、問い合わせ回数が少ないゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除して領域を解放するとともに、削除したＤＮＳＫＥＹリソースレコードに対応するゾーンの情報を頻度情報記憶部３０９から削除する（ステップＳ６０５）。

上述してきたように、本実施例では、問い合わせの頻度が高いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に優先的に残すこととしたので、ＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除することの影響を小さく抑えることができる。

なお、本実施例では、問い合わせの頻度が高いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に優先的に残すこととしたが、ＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に格納されている各ゾーンのうち、最近問い合わせを行った日時が現在日時と近いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に優先的に残すこととしても同様の効果を得ることができる。

本実施例では、キャッシュ容量等の問題からキャッシュされているＤＮＳＫＥＹリソースレコードの一部を削除するさらに他の例について説明する。

まず、図１３を参照しながら、本実施例に係る名前解決装置４００の構成について説明する。図１３に示すように、名前解決装置４００は、名前解決部１０１と、問合せ部１０２と、キャッシュ部１０３と、キャッシュ制御部４０４と、検証部１０５と、下位ゾーン数算出部４１０と、下位ゾーン数記憶部４１１とを有する。

下位ゾーン数記憶部４１１は、キャッシュ部１０３に記憶されている各ＤＮＳＫＥＹリソースレコードに対応するゾーンよりも下の階層に存在するゾーンの数を下位ゾーン数情報として保持する。下位ゾーン数情報の一例を図１４に示す。図１４の例が示すように、下位ゾーン数情報は、ゾーンや下位ゾーン数といった項目を有する。ゾーンの項目は、ＤＮＳＫＥＹリソースレコードに対応するゾーンの名称が格納される項目である。下位ゾーン数の項目は、ＤＮＳＫＥＹリソースレコードに対応するゾーンよりも下の階層に存在するゾーンの数が格納される項目である。

図１４に示す下位ゾーン数情報の４行目には、ゾーンの項目に”ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”が設定され、下位ゾーン数の項目に”２”が設定されている。これは、”ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンよりも下に、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋａｎａｇａｗａ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンが存在するためである。

また、図１４に示す下位ゾーン数情報の３行目には、ゾーンの項目に”ｅｘａｍｐｌｅ．ｊｐ．”が設定され、下位ゾーン数の項目に”５”が設定されている。これは、”ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンよりも下に、”ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋａｎａｇａｗａ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋａｎｓａｉ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋｙｏｔｏ．ｋａｎｓａｉ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンが存在するためである。

なお、下位ゾーン数情報は、キャッシュ部１０３におけるＤＮＳＫＥＹリソースレコードの格納位置等の他の属性情報を含んでもよい。また、下位ゾーン数情報は、他の形式で構成されていてもよい。

下位ゾーン数算出部４１０は、指定されたゾーンよりも下の階層に存在するゾーンの数を算出し、下位ゾーン数記憶部４１１に登録する。下位ゾーン数算出部４１０は、キャッシュ部１０３に格納されているＤＮＳＫＥＹリソースレコードの名称に基づいて各ゾーンの階層関係を判断し、指定されたゾーンよりも下の階層に存在するゾーンの数を算出する。

例えば、”ｊｐ．”という名称のゾーンと、”ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｔｏｋｙｏ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋａｎａｇａｗａ．ｋａｎｔｏ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋａｎｓａｉ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンと、”ｋｙｏｔｏ．ｋａｎｓａｉ．ｅｘａｍｐｌｅ．ｊｐ．”という名称のゾーンのＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に格納されている場合、下位ゾーン数算出部４１０は、図１４の例に示したように各ゾーンの下位ゾーン数を算出する。

この方式では、各ゾーンの下位ゾーン数を厳密に取得することはできないものの、名前解決装置４００は、ＤＮＳＫＥＹリソースレコードを優先的にキャッシュ部１０３に残すように構成されているため、各ゾーンよりも下の階層に存在するゾーンのうち、ＤＮＳＳＥＣが有効化されており、問い合わせを行う可能性があるゾーンの数をほぼ漏れなく取得することができる。

キャッシュ制御部４０４は、問合せ部１０２および検証部１０５の要求に応じて、キャッシュ部１０３に記憶されている情報の検索と、キャッシュ部１０３への情報の格納を行う。キャッシュ制御部４０４は、キャッシュ部１０３へ新たなＤＮＳＫＥＹリソースレコードを格納する場合、そのＤＮＳＫＥＹリソースレコードに対応するゾーンの下位ゾーン数を算出し下位ゾーン数記憶部４１１に格納する処理を下位ゾーン数算出部４１０に実行させる。また、キャッシュ制御部４０４は、キャッシュ部１０３からＤＮＳＫＥＹリソースレコードが削除された場合、キャッシュ部１０３に記憶されているＤＮＳＫＥＹリソースレコードに対応する各ゾーンの下位ゾーン数を算出し直して下位ゾーン数記憶部４１１を更新する処理を下位ゾーン数算出部４１０に実行させる。

また、キャッシュ制御部４０４は、キャッシュ部１０３へ新たな情報を格納するにあたって、キャッシュ部１０３の使用量を確認し、使用量が閾値を超過している場合には、新たな情報を格納する領域を確保するために、キャッシュ部１０３に記憶されている情報を削除する。なお、削除される情報は、新たな情報を格納する領域が確保されることを条件として、なるべく少ないことが好ましい。

キャッシュ制御部４０４は、キャッシュ部１０３に記憶されている情報を削除する場合に、記憶されているＤＮＳＫＥＹリソースレコードを優先的に残して、他の種類のリソースレコードを削除する。そして、他の種類のリソースレコードを削除してもキャッシュ部１０３の使用量が閾値を超過している場合には、キャッシュ制御部４０４は、下位ゾーン数記憶部４１１を参照して、下位ゾーン数の値が小さいゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除するとともに、削除したＤＮＳＫＥＹリソースレコードに対応するゾーンの情報を下位ゾーン数記憶部４１１から削除する。

ここで、「下位ゾーン数の値が小さいゾーンのＤＮＳＫＥＹリソースレコードを削除する」とは、例えば、下位ゾーン数の値が最も小さいゾーンのＤＮＳＫＥＹリソースレコードを削除することでもよいし、下位ゾーン数の値が最も大きいゾーンのＤＮＳＫＥＹリソースレコードを残して他のＤＮＳＫＥＹリソースレコードを削除することでもよいし、下位ゾーン数の値が所定値よりも小さいゾーンのＤＮＳＫＥＹリソースレコードを削除することでもよいし、キャッシュ部１０３の使用量が所定値を下回るまで下位ゾーン数の値が小さい順にＤＮＳＫＥＹリソースレコードを削除することでもよい。

下位ゾーン数が多いゾーンのＤＮＳＫＥＹリソースレコードは、いずれかの下位ゾーンのＤＮＳＫＥＹリソースレコードの正当性を検証する場合に必要になる。このため、下位ゾーン数が多いゾーンのＤＮＳＫＥＹリソースレコードを優先的に残すことにより、ＤＮＳＫＥＹリソースレコードを問い合わせる頻度を最小限に抑えて、名前解決の完了までの時間を短くすることができる。

なお、キャッシュ部１０３へ新たな情報を格納するタイミングだけでなく、定期的にキャッシュ部１０３の使用量を確認して使用量が閾値を超過している場合にはキャッシュ部１０３に記憶されている情報を削除するようにキャッシュ制御部４０４を構成してもよい。また、使用量に関する閾値とキャッシュ部１０３に記憶されている情報を削除する量については、適宜決定することができ、キャッシュ部１０３へ新たな情報を格納する場合と定期的にキャッシュ部１０３の使用量を確認する場合とで値が異なっていてもよい。また、どの下位ゾーン数までのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除するかについては、予め決めておいてもよいし、削除されるＤＮＳＫＥＹリソースレコードが最少で済むように動的に決定してもよい。

次に、図１５を参照しながら名前解決装置４００による名前解決処理の処理手順について説明する。図１５に示すように、名前解決部１０１が、名前解決のための問い合わせを生成し、問合せ部１０２に送信を依頼すると（ステップＳ７０１）、キャッシュ制御部４０４が、その問い合わせに対応する応答であるリソースレコードをキャッシュ部１０３から検索する（ステップＳ７０２）。ここで、該当するリソースレコードが存在した場合（ステップＳ７０３肯定）、問合せ部１０２は、検索されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ７１４）。

一方、該当するリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ７０３否定）、問合せ部１０２がＤＮＳ９０に対して問い合わせを送信し、応答を受信する（ステップＳ７０４）。ここで、ＤＮＳＳＥＣが有効でない場合（ステップＳ７０５否定）、キャッシュ制御部４０４が、応答されたリソースレコードをキャッシュ部１０３に記憶させる（ステップＳ７１３）。そして、問合せ部１０２は、応答されたリソースレコードを名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ７１４）。

ＤＮＳＳＥＣが有効な場合（ステップＳ７０５肯定）、キャッシュ制御部４０４が、問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から検索する（ステップＳ７０６）。ここで、該当するＤＮＳＫＥＹリソースレコードが存在した場合（ステップＳ７０７肯定）、検証部１０５が、そのＤＮＳＫＥＹリソースレコードを用いて、ステップＳ７０４で得られたリソースレコードの正当性を検証する（ステップＳ７１２）。

そして、正当性の検証が成功したならば、キャッシュ制御部４０４が、ステップＳ７０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ７１３）。そして、問合せ部１０２は、ステップＳ７０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ７１４）。

一方、該当するＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在しない場合（ステップＳ７０７否定）、問合せ部１０２は、ステップＳ７０４で問い合わせが行われたゾーンのＤＮＳＫＥＹリソースレコードを取得する（ステップＳ７０８）。さらに、問合せ部１０２は、最上位のゾーンから、ステップＳ７０４で問い合わせが行われたゾーンの上位のゾーンまで、再帰的に問い合わせを行ってＤＳリソースレコードとＤＮＳＫＥＹリソースレコードを取得し、取得されたＤＳリソースレコード等を用いて、検証部１０５が、ステップＳ３０８で取得されたＤＮＳＫＥＹリソースレコードの正当性を検証する（ステップＳ７０９）。この再帰的な問い合わせにおいて、取得すべきＤＮＳＫＥＹリソースレコードがキャッシュ部１０３に存在する場合、問合せ部１０２は、そのＤＮＳＫＥＹリソースレコードをＤＮＳ９０から取得する代わりに、キャッシュ部１０３から取得する。

そして、正当性の検証が成功したならば、キャッシュ制御部４０４が、ステップＳ７０８で得られたＤＮＳＫＥＹリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させるとともに（ステップＳ７１０）、そのＤＮＳＫＥＹリソースレコードを取得したゾーンの下位ゾーン数を下位ゾーン数記憶部１０１に記録する（ステップＳ７１１）。続いて、検証部１０５が、正当性が検証されたＤＮＳＫＥＹリソースレコードを用いて、ステップＳ７０４で得られたリソースレコードの正当性を検証する（ステップＳ７１２）。

そして、正当性の検証が成功したならば、キャッシュ制御部４０４が、ステップＳ７０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）をキャッシュ部１０３に記憶させる（ステップＳ７１３）。そして、問合せ部１０２は、ステップＳ７０４で得られたリソースレコード（ただし、ＲＲＳＩＧを除く）を名前解決部１０１に引き渡し、名前解決部１０１は、引き渡されたリソースレコードの内容を解析する（ステップＳ７１４）。

次に、図１６を参照しながら、キャッシュ制御部４０４が、新たな情報をキャッシュ部１０３に格納するタイミング、あるいは、定期的なタイミングで実行するキャッシュ解放処理の処理手順について説明する。キャッシュ制御部４０４は、キャッシュ部１０３の使用量を確認し（ステップＳ８０１）、使用量が閾値を超過していなければ（ステップＳ８０２否定）、特に処理を行うことなくキャッシュ解放処理を終了する。

一方、使用量が閾値を超過していれば（ステップＳ８０２肯定）、キャッシュ制御部４０４は、ＤＮＳＫＥＹリソースレコードを優先的に残しつつ、キャッシュ部１０３に記憶されている他の種類のリソースレコードを削除して領域を解放する（ステップＳ８０３）。そして、解放によって、キャッシュ部１０３の使用量が閾値以下となれば（ステップＳ８０４否定）、キャッシュ制御部４０４は、キャッシュ解放処理を終了する。

解放後もキャッシュ部１０３の使用量が閾値を超過している場合（ステップＳ８０４肯定）、キャッシュ制御部４０４は、下位ゾーン数記憶部４１１を参照して、上述したように、下位ゾーン数が少ないゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除して領域を解放するとともに、削除したＤＮＳＫＥＹリソースレコードに対応するゾーンの情報を下位ゾーン数記憶部４１１から削除し、下位ゾーン数を更新させる（ステップＳ８０５）。

上述してきたように、本実施例では、下位のゾーン数が多いゾーンのＤＮＳＫＥＹリソースレコードをキャッシュ部１０３に優先的に残すこととしたので、ＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除することの影響を小さく抑えることができる。

上述した各実施例における名前解決装置の構成は、要旨を逸脱しない範囲で種々に変更することができる。例えば、一部のＤＮＳＫＥＹリソースレコードをキャッシュ部１０３から削除することについて実施例２〜４で示した各方式を何らかの優先順位を付けて組み合わせて用いることができる。

優先順位を付けて各方式を組み合わせる例を示す。キャッシュ部１０３にＤＮＳＫＥＹリソースレコードが格納されているゾーンごとに、深度と、問い合わせ回数および下位ゾーン数を保持し、キャッシュ部１０３の使用量が閾値を超えていれば、まず、下位ゾーン数の値が最も小さいＤＮＳＫＥＹリソースレコードを削除する。そして、キャッシュ部１０３の使用量が依然として閾値を超えていれば、深度の値が最も小さいＤＮＳＫＥＹリソースレコードを削除する。そして、キャッシュ部１０３の使用量が依然として閾値を超えていれば、問い合わせ回数の値が所定値よりも小さいＤＮＳＫＥＹリソースレコードを削除する。

また、上述した各実施例における名前解決装置の機能をソフトウェアとして実装し、これをコンピュータで実行することにより、上述した各実施例における名前解決装置と同等の機能を実現することもできる。以下に、名前解決装置１００の機能をソフトウェアとして実装した名前解決プログラム１０７１を実行するコンピュータの一例を示す。

図１７は、名前解決プログラム１０７１を実行するコンピュータ１０００を示す機能ブロック図である。このコンピュータ１０００は、各種演算処理を実行するＣＰＵ（Central Processing Unit）１０１０と、ユーザからのデータの入力を受け付ける入力装置１０２０と、各種情報を表示するモニタ１０３０と、記録媒体からプログラム等を読み取る媒体読取り装置１０４０と、ネットワークを介して他のコンピュータとの間でデータの授受を行うネットワークインターフェース装置１０５０と、各種情報を一時記憶するＲＡＭ（Random Access Memory）１０６０と、ハードディスク装置１０７０とをバス１０８０で接続して構成される。

そして、ハードディスク装置１０７０には、図１に示した名前解決装置１００各機能部と同様の機能を有する名前解決プログラム１０７１と、図１に示したキャッシュ部１０３に記憶される各種情報に対応するキャッシュデータ１０７２とが記憶される。

そして、ＣＰＵ１０１０が名前解決プログラム１０７１をハードディスク装置１０７０から読み出してＲＡＭ１０６０に展開することにより、名前解決プログラム１０７１は、名前解決プロセス１０６１として機能するようになる。そして、名前解決プロセス１０６１は、キャッシュデータ１０７２から読み出した情報等を適宜ＲＡＭ１０６０上の自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種データ処理を実行する。

なお、上記の名前解決プログラム１０７１は、必ずしもハードディスク装置１０７０に格納されている必要はなく、ＣＤ−ＲＯＭ等の記憶媒体に記憶されたこのプログラムを、コンピュータ１０００が読み出して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等を介してコンピュータ１０００に接続される他のコンピュータ（またはサーバ）等にこのプログラムを記憶させておき、コンピュータ１０００がこれらからプログラムを読み出して実行するようにしてもよい。

１０ クライアント装置
２０ ＤＮＳキャッシュサーバ
３０〜５０ ＤＮＳサーバ
９０ ＤＮＳ
１００、２００、３００、４００ 名前解決装置
１０１ 名前解決部
１０２ 問合せ部
１０３ キャッシュ部
１０４ キャッシュ制御部
１０５ 検証部
２０８ 深度情報記憶部
３０４ キャッシュ制御部
３０９ 頻度情報記憶部
４０４ キャッシュ制御部
４１０ 下位ゾーン数算出部
４１１ 下位ゾーン数記憶部
１０００ コンピュータ
１０１０ ＣＰＵ
１０２０ 入力装置
１０３０ モニタ
１０４０ 媒体読取り装置
１０５０ ネットワークインターフェース装置
１０６０ ＲＡＭ
１０６１ 名前解決プロセス
１０７０ ハードディスク装置
１０７１ 名前解決プログラム
１０７２ キャッシュデータ
１０８０ バス

Claims (11)

1. 階層的に構成された名前空間を管理する名前管理システムに対する問い合わせへの応答内容をキャッシュするキャッシュ部を有する名前解決装置であって、
   名前解決のための問い合わせへの応答内容の正当性を、該問い合わせの問い合わせ先の階層のサーバから得られた第１の検証情報を用いて検証するとともに、前記第１の検証情報の正当性を、前記名前管理システムの最上位の階層から該問い合わせの問い合わせ先の階層の上位の階層までの各階層のサーバに対して問い合わせて得られた第２の検証情報を用いて検証し、正当性が検証された前記第１の検証情報を前記キャッシュ部に記憶させて再利用する検証部と、
   前記キャッシュ部に空き領域を作成する場合に、前記キャッシュ部にキャッシュされた前記応答内容および前記第１の検証情報のうち、前記第１の検証情報を優先的に前記キャッシュ部に残すように制御するキャッシュ制御部と
   を備えることを特徴とする名前解決装置。
2. 前記キャッシュ制御部は、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の正当性を検証するために前記第２の検証情報を取得することが少なくて済むものを優先して削除することを特徴とする請求項１に記載の名前解決装置。
3. 前記キャッシュ制御部は、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の取得元の階層の深さが浅いものを優先して削除することを特徴とする請求項２に記載の名前解決装置。
4. 前記キャッシュ制御部は、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の取得元の階層についての問い合わせが少ないものを優先して削除することを特徴とする請求項２に記載の名前解決装置。
5. 前記キャッシュ制御部は、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の取得元の階層よりも下の階層が少ないものを優先して削除することを特徴とする請求項２に記載の名前解決装置。
6. 階層的に構成された名前空間を管理する名前管理システムに対する問い合わせへの応答内容をキャッシュするキャッシュ部を有する名前解決装置によって実行される名前解決方法であって、
   前記名前解決装置が、名前解決のための問い合わせへの応答内容の正当性を、該問い合わせの問い合わせ先の階層のサーバから得られた第１の検証情報を用いて検証する第１の検証工程と、
   前記名前解決装置が、前記第１の検証情報の正当性を、前記名前管理システムの最上位の階層から該問い合わせの問い合わせ先の階層の上位の階層までの各階層のサーバに対して問い合わせて得られた第２の検証情報を用いて検証する第２の検証工程と、
   前記名前解決装置が、前記第２の検証工程において正当性が検証された前記第１の検証情報を再利用のために前記キャッシュ部に記憶させる保管工程と、
   前記名前解決装置が、前記キャッシュ部に空き領域を作成する場合に、前記キャッシュ部にキャッシュされた前記応答内容および前記第１の検証情報のうち、前記第１の検証情報を優先的に前記キャッシュ部に残すように制御するキャッシュ解放工程と
   を含むことを特徴とする名前解決方法。
7. 前記名前解決装置は、前記キャッシュ解放工程において、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の正当性を検証するために前記第２の検証情報を取得することが少なくて済むものを優先して削除することを特徴とする請求項６に記載の名前解決方法。
8. 前記名前解決装置は、前記キャッシュ解放工程において、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の取得元の階層の深さが浅いものを優先して削除することを特徴とする請求項７に記載の名前解決方法。
9. 前記名前解決装置は、前記キャッシュ解放工程において、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の取得元の階層についての問い合わせが少ないものを優先して削除することを特徴とする請求項７に記載の名前解決方法。
10. 前記名前解決装置は、前記キャッシュ解放工程において、前記キャッシュ部に所定の空き領域を作成するために前記第１の検証情報を前記キャッシュ部から削除することが必要になった場合に、前記第１の検証情報のうち、該第１の検証情報の取得元の階層よりも下の階層が少ないものを優先して削除することを特徴とする請求項７に記載の名前解決方法。
11. コンピュータを請求項６〜１０のいずれか１つに記載の名前解決装置として機能させることを特徴とする名前解決プログラム。
    

Images