JP2012175366A - 判定方法、名前解決装置及び判定装置 - Google Patents

Abstract

【課題】攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮するとともに、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供すること。
【解決手段】要求部３３は、電子署名による検証結果が不当であった場合、問い合わせ先の権威サーバ群４０に対して、名前解決のための再問い合わせを１回要求する。そして、判定部３２は、要求部３３により行なわれた再問い合わせに対する応答が１回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する。
【選択図】図６

Description

本発明の実施の形態は、判定方法、名前解決装置及び判定装置に関する。

従来、インターネットの利用者に対して、ドメイン名とＩＰアドレス（Internet Protocol Address）とを対応させる名前管理システム（ＤＮＳ：Domain Name System）によるサービスが提供されている。ＤＮＳは、一般的には、権威サーバ群とキャッシュサーバとから構成される。権威サーバ群は、複数の権威サーバから構成され、権威サーバそれぞれは、名前空間の中にある特定のゾーンを管理する。キャッシュサーバは、クライアント装置からの名前解決の依頼に応じて、権威サーバ群に問い合わせを行なうとともに、権威サーバ群からの応答をキャッシュ可能なサーバである。

また、近年、ＤＮＳの拡張仕様として、権威サーバ群からの応答の正当性を保証するＤＮＳＳＥＣ（ＤＮＳ Security Extensions）の普及が進められている。ＤＮＳＳＥＣにおいては、権威サーバ群からの応答の正当性を保証するために、電子署名が利用される。すなわち、ＤＮＳＳＥＣが有効化されている場合、権威サーバそれぞれは、キャッシュサーバへの応答として、回答及び回答の電子署名を送信する。そして、キャッシュサーバは、電子署名を用いた検証（署名検証）を行なうことで、権威サーバ群から受信した回答の正当性を判定する。これにより、キャッシュサーバは、正当性が保証されたＩＰアドレスなどの応答データをクライアント装置に送信する。

"２ ＤＮＳＳＥＣ技術動向"、［online］、［平成２３年２月１日検索］、インターネット＜http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_02.html＞

ところで、署名検証に失敗した場合、キャッシュサーバは、クライアント装置に対して、名前解決に失敗したことを示すエラー（Server Failure）を返信する。署名検証が失敗する要因は、以下の２つに大別されると考えられる。第１の要因は、攻撃者が権威サーバの応答を偽装した偽装応答パケットをキャッシュサーバに送信するキャッシュポイズニング（cache poisoning）によるものである。また、第２の要因は、攻撃以外の理由、すなわち、ＤＮＳの運用管理における不具合によるものである。第２の要因の一例としては、ネットワーク上でのパケット送受信における負荷増大や、各サーバで設定されている現在時刻の非同期などによる「電子署名の期限切れ」が挙げられる。

従来では、キャッシュサーバは、第１の要因であっても、第２の要因であっても、クライアント装置にエラーを送信していた。このため、第２の要因により検証が失敗するケースでは、権威サーバからの応答（例えば、ＩＰアドレス）が適切であるにも関わらず、利用者に対する名前解決サービスは、停止状態となっていた。また、名前解決サービスの停止にともない、例えば、インターネットサービスにおけるＨＴＴＰ（Hypertext Transfer Protocol over Secure Socket Layer）サービスにも波及的に影響が及ぶこととなる。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮するとともに、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供することが可能となる判定方法、名前解決装置及び判定装置を提供することを目的とする。

本発明の実施の形態は、一つの態様において、名前解決のための問い合わせを問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決システムで実行される判定方法であって、電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを１回要求する要求ステップと、前記要求ステップにより行なわれた再問い合わせに対する応答が１回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定ステップと、を含んだことを特徴とする。

本発明に係る判定方法、名前解決装置及び判定装置は、攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮するとともに、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供することが可能となるという効果を奏する。

図１は、本実施例に係る名前解決システムの構成例を示す図である。 図２は、本実施例に係る名前解決システムが有するキャッシュサーバの構成例を説明するための図である。 図３は、キャッシュサーバが問い合わせを行なう権威サーバ群の一例を説明するための図である。 図４は、ＤＮＳＳＥＣに用いられるデータの一例を説明するための図である。 図５は、本実施例に係る名前解決システムが実行する署名検証処理の一例を説明するためのシーケンス図である。 図６は、本実施例に係る判定装置の構成例を説明するための図である。 図７は、再問い合わせ条件を説明するための図である。 図８は、検証結果切り替え条件を説明するための図である。 図９は、本実施例に係る名前解決システムが実行する判定方法の処理の一例を説明するためのシーケンス図である。 図１０は、図９に示すステップＳ１０６の判定処理の一例を説明するためのフローチャートである。

以下に、本発明に係る判定方法、名前解決装置及び判定装置の実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。また、以下では、本発明に係る判定方法を実行する名前解決システム（ＤＮＳ：Domain Name System）を実施例として説明する。

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

図１に示す権威サーバ群４０は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。また、図１に示すキャッシュサーバ２０は、クライアント装置１０から所定のドメイン名（例えば、「www.exaple.jp」）の名前解決の依頼を受け付ける。そして、キャッシュサーバ２０は、権威サーバ群４０に、依頼されたドメイン名の名前解決のための問い合わせを行なうとともに、権威サーバ群４０からの応答をキャッシュする機能を有する名前解決装置としてのサーバである。

ここで、図１に示す名前解決システムは、キャッシュサーバ２０が、クライアント装置１０から依頼された名前解決のための問い合わせを問い合わせ先の権威サーバ群４０に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証するシステムである。すなわち、図１に示す名前解決システムは、ＤＮＳＳＥＣ（ＤＮＳ Security Extensions）を実行するシステムである。

そして、図１に示すように、本実施例に係る名前解決システムには、キャッシュサーバ２０及び権威サーバ群４０それぞれと通信可能に接続される判定装置３０が設置される。

以下では、キャッシュサーバ２０と権威サーバ群４０とにより実行されるＤＮＳＳＥＣの処理の一例を説明した後に、本実施例に係る判定装置３０が実行する判定方法について説明する。

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

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

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

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

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

図３に示すように、「www.exaple.jp」の名前解決に際し、要求部２４が問い合わせを行なうサーバは、「ルートサーバ４１」、「jp.サーバ４２」及び「example.jp.サーバ４３」となる。ルートサーバ４１は、名前空間の最上位に設置されるサーバであり、「jp」や「com」など、一番上位のドメイン名（ＴＬＤ：Top Level Domain）を管理するサーバのインターネット上の位置（ＩＰアドレス）を管理するサーバである。

また、jp.サーバ４２は、「jp」のＴＬＤサーバであり、「jp」で管理される「example.jp」や「ad.jp」などのインターネット上の位置（ＩＰアドレス）を管理するサーバである。また、example.jp.サーバ４３は、自身が管理する名前空間の中にあるホスト、例えば、「www.exaple.jp」や「ftp.example.jp」のインターネット上の位置（ＩＰアドレス）を管理するサーバである。なお、上位の権威サーバは、自身が管理する下位の権威サーバのＩＰアドレスなどを、ＮＳレコードとして保持している。

ここで、ＤＮＳＳＥＣが実行される場合、権威サーバ群４０それぞれには、自身が管理するゾーンに関する情報（ゾーン情報）に署名を行なうための公開鍵及び秘密鍵のペアであるＺＳＫ（Zone Signing Key）が、管理者により設定される。また、権威サーバ群４０それぞれには、ＺＳＫに署名を行なうための公開鍵及び秘密鍵のペアであるＫＳＫ（Key Signing Key）が、管理者により設定される。

図３に示す一例では、ルートサーバ４１は、ＺＳＫとして、「ＺＳＫ−Ａ（公開）及びＺＳＫ−Ａ（秘密）」を保持し、ＫＳＫとして、「ＫＳＫ−Ａ（公開）及びＫＳＫ−Ａ（秘密）」を保持する。また、図３に示す一例では、jp.サーバ４２は、ＺＳＫとして、「ＺＳＫ−Ｂ（公開）及びＺＳＫ−Ｂ（秘密）」を保持し、ＫＳＫとして、「ＫＳＫ−Ｂ（公開）及びＫＳＫ−Ｂ（秘密）」を保持する。また、図３に示す一例では、example.jp.サーバ４３は、ＺＳＫとして、「ＺＳＫ−Ｃ（公開）及びＺＳＫ−Ｃ（秘密）」を保持し、ＫＳＫとして、「ＫＳＫ−Ｃ（公開）及びＫＳＫ−Ｃ（秘密）」を保持する。

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

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

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

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

すなわち、example.jp.サーバ４３は、「www.exaple.jp」のＡレコード及び当該Ａレコードの署名として、データ４３ａ及びデータ４３ｂを保持する。また、example.jp.サーバ４３は、自身のＤＮＳＫＥＹとして、データ４３ｃ及びデータ４３ｅを保持する。また、example.jp.サーバ４３は、ＤＮＳＫＥＹの署名として、データ４３ｄ及びデータ４３ｆを保持する。

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

また、jp.サーバ４２は、図４の（Ｂ）に示すように、「ＺＳＫ−Ｂ（公開）」のデータ４２ｃと、「ＺＳＫ−Ｂ（公開）のハッシュ値をＫＳＫ−Ｂ（秘密）で暗号化した電子署名」であるデータ４２ｄを保持する。また、jp.サーバ４２は、図４の（Ｂ）に示すように、「ＫＳＫ−Ｂ（公開）」のデータ４２ｅと、「ＫＳＫ−Ｂ（公開）のハッシュ値をＫＳＫ−Ｂ（秘密）で暗号化した電子署名」であるデータ４２ｆを保持する。

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

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

また、ルートサーバ４１は、図４の（Ｃ）に示すように、「ＺＳＫ−Ａ（公開）」のデータ４１ｃと、「ＺＳＫ−Ａ（公開）のハッシュ値をＫＳＫ−Ａ（秘密）で暗号化した電子署名」であるデータ４１ｄを保持する。また、ルートサーバ４１は、図４の（Ｃ）に示すように、「ＫＳＫ−Ａ（公開）」のデータ４１ｅと、「ＫＳＫ−Ａ（公開）のハッシュ値をＫＳＫ−Ａ（秘密）で暗号化した電子署名」であるデータ４１ｆを保持する。

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

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

図４に例示したデータを用いて、本実施例に係る名前解決システムが実行する署名検証処理について、図５を用いて説明する。図５は、本実施例に係る名前解決システムが実行する署名検証処理の一例を説明するためのシーケンス図である。なお、図５に示すシーケンス図において、装置間での情報の送受信は、ＵＤＰ（User Datagram Protocol）パケットにより行なわれる。ただし、図５に示すシーケンス図において、装置間での情報の送受信は、ＴＣＰ（Transmission Control Protocol）パケットにより行なわれる場合であっても良い。

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

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

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

「www.exaple.jp」のＡレコードの問い合わせを受け付けたexample.jp.サーバ４３は、「www.exaple.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.サーバ４２が保持するＤＳレコードを用いて検証する。

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

また、検証部２２は、データ４１ａの正当性を、データ４１ａと、データ４１ｂをデータ４１ｃで復号した結果とを比較することで検証する。また、検証部２２は、データ４１ｃの正当性を、データ４１ｃのハッシュ値と、データ４１ｄをデータ４１ｅで復号した結果とを比較することで検証する。更に、検証部２２は、データ４１ｅの正当性を、データ４１ｆをデータ４１ｅで復号した結果と、データ２３ａとを比較することで検証する。すなわち、検証部２２は、ＫＳＫ−Ａ（公開）の正当性を、キャッシュ部２３が保持するＤＳレコードを用いて検証する。

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

ここで、従来では、署名検証が失敗した場合、応答部２１は、クライアント装置１０に対して、名前解決に失敗したことを示すエラー（Server Failure）を返信していた。署名検証が失敗する要因には、攻撃者が権威サーバの応答を偽装した偽装応答パケットをキャッシュサーバ２０に送信するキャッシュポイズニング（cache poisoning）がある。

一方、署名検証が失敗する要因には、攻撃以外の理由、すなわち、ＤＮＳの運用管理における不具合によるものがある。かかる要因の一例としては、「電子署名の期限切れ」がある。電子署名には、有効期限が設定されており、例えば、各装置で設定されている現在時刻の非同期などが発生した場合、「電子署名の期限切れ」が発生する場合がある。また、ＺＳＫやＫＳＫは、各権威サーバの管理者により、随時更新される。しかし、上位の権威サーバに更新後のＤＳレコードが通知されていない場合や、そもそもＤＳレコードが格納されていない場合は、署名検証は、失敗となる。

従来では、応答部２１は、署名検証失敗と検証部２２が判定すると、一様に、「Server Failure」を返信していた。かかる場合、ＤＮＳの管理者は、例えば、データ４３ａとして受信したデータが正しい応答内容であるにも関わらず、署名検証が失敗した要因を特定したうえで、復旧作業を行なう必要がある。すなわち、従来では、応答（ＩＰアドレス）が適切であるにも関わらず、利用者に対するインターネットサービスは、停止状態となっていた。

そこで、本実施例に係る名前解決システムには、図１に示すように、キャッシュサーバ２０及び権威サーバ群４０と接続される判定装置３０が設置される。図６は、本実施例に係る判定装置の構成例を説明するための図である。

図６に示すように、本実施例に係る判定装置３０は、応答部３１と、判定部３２と、要求部３３とを有する。

応答部３１は、署名検証に失敗した情報を応答部２１から受信する。具体的には、応答部２１は、検証結果が不当と判定された権威サーバ群４０からの一連の応答データをキャッシュ部２３から取得する。そして、応答部２１は、取得した応答データを、クライアント装置１０からの依頼内容と、クライアント装置１０から依頼されたタイプとともに、応答部３１に送信する。例えば、応答部２１は、応答データを、「依頼ドメイン名：www.exaple.jp」及び「タイプ：ＩＰｖ４アドレス」とともに、応答部３１に送信する。そして、応答部３１は、応答部２１から受信した情報を要求部３３に転送する。

そして、図６に示す要求部３３は、電子署名による検証結果が不当であった場合、問い合わせ先の権威サーバ群４０に対して、名前解決のための再問い合わせを１回要求する。例えば、要求部３３は、「www.exaple.jp」の名前解決に際し、検証部２２の検証結果が失敗であった場合、「www.exaple.jp」の名前解決の再問い合わせを、ルートサーバ４１から順に一回のみ行なう。

ここで、要求部３３が実行する再問い合わせの条件は、以下に示すように、判定装置３０の管理者により設定することができる。図７は、再問い合わせ条件を説明するための図である。まず、図７に示すように、判定装置３０が行なう再問い合わせの回数は、「１回」に固定される。

そして、図７に示すように、管理者は、再問い合わせ条件として、判定装置３０が再問い合わせを行なうトリガーを、２つのパターンのいずれかにより設定する。第１のトリガーパターンは、図７に示すように、「検証結果が失敗するごと」に、要求部３３が再問い合わせを一回実行すると設定するものである。第１のトリガーパターンが設定された場合、要求部３３は、検証結果が失敗するごとに、再問い合わせを１回実行する。また、第２のトリガーパターンは、図７に示すように、「同一のドメイン名に対する検証結果がＴ秒間内にＮ回以上失敗」であった場合に、要求部３３が再問い合わせを１回実行すると設定するものである。「Ｔ」及び「Ｎ」の値は、管理者により設定される。すなわち、「Ｔ秒間」を設定時間、「Ｎ回」を設定回数と定義すると、第２のトリガーパターンが設定された場合、要求部３３は、同一の名前解決のための問い合わせに対する検証結果が、設定時間内にて設定回数以上で不当であった場合に、再問い合わせを１回行なう。換言すると、第２のトリガーパターンは、同一ドメイン名に対する署名検証が多発したことを契機として、再問い合わせを行なうものである。なお、判定装置３０が再問い合わせを行なうトリガーは、判定装置３０の管理者が任意のタイミングで再問い合わせ要求を行なった時点である場合であっても良い。

また、図７に示すように、管理者は、再問い合わせ条件として、再問い合わせを行なう際に判定装置３０がＤＮＳＳＥＣを有効（ＯＮ）とするか、無効（ＯＦＦ）とするかを選択可能である。すなわち、「ＤＮＳＳＥＣ：ＯＮ」が選択された場合、要求部３３は、電子署名を用いた検証を有効とした状態で、再問い合わせを行なう。具体的には、「ＤＮＳＳＥＣ：ＯＮ」が選択された場合、要求部３３は、問い合わせ先の権威サーバ群４０に対して、応答内容とともに電子署名を要求する再問い合わせを行なう。例えば、要求部３３は、権威サーバ群４０との間で、図５に例示したステップＳ３、Ｓ５、Ｓ７、Ｓ９、Ｓ１１、Ｓ１３、Ｓ１５、Ｓ１７及びＳ１９の一連の問い合わせを再度１回のみ行なう。また、「ＤＮＳＳＥＣ：ＯＦＦ」が選択された場合、要求部３３は、電子署名を用いた検証を無効とした状態で、再問い合わせを行なう。例えば、要求部３３は、権威サーバ群４０との間で、図５に例示したステップＳ３、Ｓ５及びＳ７の一連の問い合わせを再度１回のみ行なう。かかる場合、example.jp.サーバ４３は、ステップＳ８においてＡレコードのみを返信する。

また、図７に示すように、管理者は、再問い合わせ条件として、判定装置３０が再問い合わせを行なうタイミングを設定することができる。すなわち、管理者は、「トリガー発生後、ｔ秒後」に、要求部３３が再問い合わせを一回実行すると設定する。「ｔ」の値は、管理者により設定される。すなわち、「ｔ秒間」を「予め設定された時間」と定義すると、要求部３３は、電子署名による検証結果が不当であると判定された時点から、予め設定された時間が経過した時点で、再問い合わせを行なう。なお、第２のトリガーパターンが設定されている場合、要求部３３は、「同一のドメイン名に対する検証結果の失敗が、Ｔ秒間内にＮ回発生した」時点から、予め設定された時間が経過した時点で、再問い合わせを行なう。換言すると、本実施例では、キャッシュサーバ２０と権威サーバ群との間で従来行なわれていた問い合わせ及び応答のタイミングと関係なく、判定装置３０が権威サーバ群との間で行なう問い合わせ及び応答のタイミングが独自に設定される。

図６に戻って、判定部３２は、要求部３３により行なわれた再問い合わせに対する応答が１回だけである場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する。そして、判定部３２は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、管理者により設定された検証結果切り替え条件により、検証部２２による検証結果を切り替える。図８は、検証結果切り替え条件を説明するための図である。

図８に示すように、管理者は、検証結果切り替え条件として、「回答が１回」とする第１の切り替え条件、又は、「回答が１回、かつ、再問い合わせ前後の応答データが一致」とする第２の切り替え条件を選択する。すなわち、第１の切り替え条件が設定された場合、判定部３２は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、再問い合わせ前の応答内容が正当であると判定する。ＤＮＳにおいては、１回の問い合わせに対して、権威サーバ群４０からの応答シーケンスが正しく１回確認されるならば、正しい応答とみなすことができる。或いは、ＤＮＳにおいては、１回の問い合わせに対して、権威サーバ群４０からの最終的な応答が１回であれば正当であるといえる。キャッシュポイズニングの特徴は、不要なパケットを多量に送りつけることにある。従って、問合せにおける１シーケンス内の、送信と応答の数が明らかに違えば、攻撃であるとみなすことができる。

又は、第２の切り替え条件が設定された場合、判定部３２は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定し、一致している場合、再問い合わせ前の応答内容が正当であると判定する。例えば、判定部３２は、図４の（Ａ）〜（Ｃ）に示すデータ群が、再問い合わせ前後で一致している場合、再問い合わせ前の応答内容が正当であると判定する。

なお、判定部３２は、再問い合わせに対する回答が複数である場合、検証結果が攻撃によるものであり、再問い合わせ前の応答内容が不当であると判定する。また、判定部３２は、第２の切り替え条件が設定されている場合、再問い合わせ前後で応答データが不一致の場合も、再問い合わせ前の応答内容が不当であると判定する。

そして、判定部３２は、判定結果をキャッシュ部２３に格納し、キャッシュ部２３に格納した判定結果をクライアント装置１０に通知する旨の依頼を応答部２１に依頼する。

応答部２１は、キャッシュ部２３に格納された判定結果に基づいて、ＩＰアドレス又は、エラーを返信する。すなわち、判定結果が正当である場合、応答部２１は、キャッシュ部２３に格納済みの再問い合わせ前のＩＰアドレス（例えば、Ａレコード）をクライアント装置１０に返信する。また、判定結果が不当である場合、応答部２１は、「Server Failure」をクライアント装置１０に返信する。

続いて、図９及び図１０を用いて、本実施例に係る名前解決システムが実行する判定処理方法の手順について説明する。図９は、本実施例に係る名前解決システムが実行する判定方法の処理の一例を説明するためのシーケンス図である。また、図１０は、図９に示すステップＳ１０６の判定処理の一例を説明するためのフローチャートである。

なお、図９では、トリガーパターンとして第１のトリガーパターンが設定され、再問い合わせ時のＤＮＳＳＥＣが有効と設定され、再問い合わせを行なうタイミングとして「ｔ＝０」が設定され、更に、第２の切り替え条件が設定されている場合を説明する。また、図９では、署名検証が失敗した時点以降の処理について説明する。また、図９に示すシーケンス図において、装置間での情報の送受信は、図５と同様に、ＵＤＰパケットにより行なわれる場合であっても良い。なお、図６に示すシーケンス図においても、装置間での情報の送受信は、ＴＣＰパケットにより行なわれる場合であっても良い。ただし、ＴＣＰでは、再送が行なわれるので、本実施例において、判定装置３０と権威サーバ群４０との間で行なわれる情報の送受信は、ＵＤＰパケットにより行なわれることが望ましい。

図９に示すように、応答部２１は、署名検証に失敗した情報を応答部３１に転送する（ステップＳ１０１）。そして、応答部３１は、署名検証に失敗した情報を要求部３３に転送する（ステップＳ１０２）。

そして、要求部３３は、権威サーバ群４０に対して、再問い合わせを１回要求し（ステップＳ１０３）、権威サーバ群４０は、応答データを返信する（ステップＳ１０４）。すなわち、要求部３３は、要求部２４と権威サーバ群４０との間で行なわれた処理（例えば、図５に示すステップＳ３〜ステップＳ２０の一連のシーケンス）を、１回のみ、権威サーバ群４０との間で再度実行する。例えば、要求部３３は、ルートサーバ４１から順に、「www.exaple.jp」のＡレコードの問い合わせを行なう。そして、要求部３３は、「www.exaple.jp」のＤＮＳＫＥＹの問い合わせを行なった後に、ルートサーバ４１から順に、ＤＳレコードの問い合わせを行なう。

そして、要求部３３は、受信した応答データを判定部３２に転送し（ステップＳ１０５）、判定部３２は、判定処理を行なう（ステップＳ１０６）。すなわち、図１０に示すように、判定部３２は、再問い合わせ要求に対する応答が１回であるか否かを判定する（ステップＳ２０１）。ここで、再問い合わせ要求に対する応答が１回でない場合（ステップＳ２０１否定）、判定部３２は、再問い合わせ前の応答内容を不当と判定し（ステップＳ２０４）、判定処理を終了する。

一方、再問い合わせ要求に対する応答が１回である場合（ステップＳ２０１肯定）、判定部３２は、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定する（ステップＳ２０２）。ここで、再問い合わせ前後で応答データが不一致の場合（ステップＳ２０２否定）、判定部３２は、再問い合わせ前の応答内容を不当と判定し（ステップＳ２０４）、判定処理を終了する。

一方、再問い合わせ前後で応答データが一致の場合（ステップＳ２０２肯定）、判定部３２は、再問い合わせ前の応答内容を正当と判定し（ステップＳ２０３）、判定処理を終了する。

図９に戻って、図１０の判定処理を完了した判定部３２は、判定結果をキャッシュ部２３に格納し（ステップＳ１０７）、応答部２１に対して、判定結果の通知依頼を行なう（ステップＳ１０８）。

そして、応答部２１は、判定結果に基づいて、ＩＰアドレス又は、エラーを返信し（ステップＳ１０９）、処理を終了する。すなわち、応答部２１は、ステップＳ１０９において、「Server Failure」を返信する。

上述してきたように、本実施例では、要求部３３は、電子署名による検証結果が不当であった場合、問い合わせ先の権威サーバ群４０に対して、名前解決のための再問い合わせを１回要求する。そして、判定部３２は、要求部３３により行なわれた再問い合わせに対する応答が１回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する。

要求部３３と権威サーバ群４０とは、ＵＤＰパケットにより通信を行なうが、問い合わせに用いられるポート数と、各データの送受信に割り振られる１６ビットのトランザクションＩＤとの組み合わせは、約５０００億通りとなる。ここで、攻撃者が、約５０００億通りの組み合わせから適切な組み合わせを選択したうえで、要求部３３が行なう１回の再問い合わせに対して、偽装応答パケットを１回のみ、タイミング良くキャッシュサーバ２０に送出することは、確率的に略不可能である。

すなわち、ルートサーバ４１から行なう１回の再問い合わせに対して、１回のみの回答が受信された場合、再問い合わせに応答したのは権威サーバ群４０である可能性が高い。そこで、本実施例では、１回の再問い合わせに対する回答の回数をカウントすることで、署名検証の失敗の要因が攻撃である場合と、攻撃でない要因による場合とを切り分ける。その結果、本実施例では、検証失敗の要因特定に要する時間、すなわち、名前解決システムの復旧作業に要する時間を短縮することができる。本実施例では、攻撃以外の要因により署名検証の失敗が発生する場合、例えば、権威サーバ群４０における電子署名関連の設定に不具合が起こっているのであろうという仮定のもと、１回の再問い合わせに対して１回のみの回答が受信されたのであれば、キャッシュサーバ２０は、本来、権威サーバ群４０が正しく動作していれば返せていたはずの回答をクライアント装置１０に返すことができる。すなわち、本実施例では、権威サーバ群４０側での復旧時間を無視して名前解決サービスを提供することができる。このようなことから、本実施例によれば、攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮することが可能となる。また、名前解決サービスの停止にともない、例えば、インターネットサービスにおけるＨＴＴＰサービスにも波及的に影響が及ぶことを回避できる。更に、本実施例では、ＤＮＳＳＥＣを有効にしたときのセキュリティ性はないものの、ＤＮＳＳＥＣを有効にしていない場合と比べて、セキュリティ性が高い状態で名前解決サービスを提供できる。すなわち、本実施例によれば、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供することが可能となる。

また、本実施例では、判定部３２は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、以下のいずれかの検証結果切り替え条件により、検証部２２による検証結果を切り替える。第１の切り替え条件では、判定部３２は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、再問い合わせ前の応答内容が正当であると判定する。或いは、第２の切り替え条件では、判定部３２は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定し、一致している場合、再問い合わせ前の応答内容が正当であると判定する。

すなわち、第１の切り替え条件では、管理運用上の要因で署名検証が失敗したのであれば、再問い合わせ前の応答内容が正しいデータである可能性が高いことから、ただちに、再問い合わせ前の応答内容を正当と切り替えてクライアント装置１０に送信する。よって、第１の切り替え条件では、攻撃以外の要因により署名検証の失敗が発生した場合に、停止時間を極力短縮したうえで、名前解決サービスを継続して提供することができる。

一方、第２の切り替え条件では、再問い合わせ前の応答内容の正当性を確実に検証するために、更に、応答データが再問い合わせ前後で一致していることを確認し、一致である場合のみ、再問い合わせ前の応答内容を正当と切り替えてクライアント装置１０に送信する。よって、第２の切り替え条件では、攻撃以外の要因により署名検証の失敗が発生した場合に、停止時間を短縮したうえで、ＤＮＳＳＥＣが無効の場合と比べてセキュア(信頼性の高い)な回答を返すことができる。

また、本実施例では、要求部３３は、同一の名前解決のための問い合わせに対する検証結果が、設定時間内にて設定回数以上で不当であった場合に、再問い合わせを１回行なう場合であっても良い。すなわち、本実施例は、署名検証が多発した場合に、要求部３３及び判定部３２の処理を開始する場合であっても良く、かかる設定により、判定装置３０にかかる負荷を低減することができる。

また、本実施例では、要求部３３は、応答内容とともに電子署名を要求する再問い合わせを行なう場合であっても良い。本実施例は、ＤＮＳＳＥＣを無効とした状態で、再問い合わせを行なっても良いが、ＤＮＳＳＥＣを有効として、電子署名のデータも一連のシーケンスで１回受信したことを確認するほうが、要因判定処理の信頼性を強固にするためには望ましい。

また、本実施例では、要求部３３は、電子署名による検証結果が不当であると判定された時点から、予め設定された時間が経過した時点で、再問い合わせを行なう。すなわち、本実施例では、判定装置３０が権威サーバ群との間で行なう問い合わせ及び応答のタイミングを、独自に設定することができる。すなわち、本実施例では、１回の再問い合わせに合わせて、偽装応答パケットを偶発的に受信する可能性を低減することができ、検証結果が不当である要因が攻撃以外の要因によるか否かの判定結果の信頼性を向上させることが可能となる。

なお、上記の実施例では、判定装置３０が１台のキャッシュサーバ２０と接続される場合について説明した。しかし、判定装置３０は、複数台のキャッシュサーバ２０と接続される場合であっても良い。かかる場合、判定装置３０は、自身に接続される各キャッシュサーバにおける署名検証の要因や、応答内容の正当性について、判定処理を行なう。

また、上記の実施例では、キャッシュサーバ２０と接続される判定装置３０が再問い合わせ要求処理及び再問い合わせに対する応答を用いた判定処理を行なう場合について説明した。しかし、上記の実施例で説明した再問い合わせ要求処理及び再問い合わせに対する応答を用いた判定処理は、キャッシュサーバ２０が実行する場合であっても良い。すなわち、上記の実施例は、判定部３２がキャッシュサーバ２０に組み込まれ、要求部２４が要求部３３の処理を実行する場合であっても良い。かかる場合、応答部２１は、判定部３２の判定結果に基づいて、名前解決を依頼したクライアント装置１０に応答を行なう。なお、判定装置３０がキャッシュサーバ２０と独立して設置する場合であっても、判定装置３０がキャッシュサーバ２０に組み込まれる場合であっても、本実施例の判定機能は、外部に対しては秘匿とされる。

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

また、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central Processing Unit）および該ＣＰＵにて解析実行されるプログラムにて実現され、或いは、ワイヤードロジックによるハードウェアとして実現され得る。例えば、図６に例示した判定部３２は、プログラムにて実現される場合であっても、ワイヤードロジックによるハードウェアとして実現される場合であっても良い。

なお、上記実施例で説明した判定方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのＩＰネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＭＯ（Magneto-Optical disk）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１０ クライアント装置
２０ キャッシュサーバ
２１ 応答部
２２ 検証部
２３ キャッシュ部
２４ 要求部
３０ 判定装置
３１ 応答部
３２ 判定部
３３ 要求部
４０ 権威サーバ群
４１ ルートサーバ
４２ jp.サーバ
４３ example.ｊp.サーバ

Claims (8)

1. 名前解決のための問い合わせを問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決システムで実行される判定方法であって、
   電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを１回要求する要求ステップと、
   前記要求ステップにより行なわれた再問い合わせに対する応答が１回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定ステップと、
   を含んだことを特徴とする判定方法。
2. 前記判定ステップは、検証結果が不当である要因が攻撃以外の要因によると判定した場合、再問い合わせ前の応答内容が正当であると判定することを特徴とする請求項１に記載の判定方法。
3. 前記判定ステップは、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定し、一致している場合、再問い合わせ前の応答内容が正当であると判定することを特徴とする請求項１に記載の判定方法。
4. 前記要求ステップは、同一の名前解決のための問い合わせに対する検証結果が、設定時間内にて設定回数以上で不当であった場合に、再問い合わせを１回行なうことを特徴とする請求項１〜３のいずれか一つに記載の判定方法。
5. 前記要求ステップは、応答内容とともに電子署名を要求する再問い合わせを行なうことを特徴とする請求項１〜３のいずれか一つに記載の判定方法。
6. 前記要求ステップは、電子署名による検証結果が不当であると判定された時点から、予め設定された時間が経過した時点で、再問い合わせを行なうことを特徴とする請求項１〜３のいずれか一つに記載の判定方法。
7. 名前解決のための問い合わせを、問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決装置であって、
   電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを１回要求する要求部と、
   前記要求部により行なわれた再問い合わせに対する応答が１回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定部と、
   前記判定部の判定結果に基づいて、名前解決を依頼したクライアント装置に応答を行なう応答部と、
   を備えたことを特徴とする名前解決装置。
8. 名前解決のための問い合わせを、問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決装置に接続される判定装置であって、
   電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを１回要求する要求部と、
   前記要求部により行なわれた再問い合わせに対する応答が１回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定部と、
   を備えたことを特徴とする判定装置。

Images