名前解決のための問い合わせを問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決システムで実行される判定方法であって、電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを1回要求する要求ステップと、前記要求ステップにより行なわれた再問い合わせに対する応答が1回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定ステップと、を含んだことを特徴とする判定方法。前記判定ステップは、検証結果が不当である要因が攻撃以外の要因によると判定した場合、再問い合わせ前の応答内容が正当であると判定することを特徴とする請求項1に記載の判定方法。前記判定ステップは、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定し、一致している場合、再問い合わせ前の応答内容が正当であると判定することを特徴とする請求項1に記載の判定方法。前記要求ステップは、同一の名前解決のための問い合わせに対する検証結果が、設定時間内にて設定回数以上で不当であった場合に、再問い合わせを1回行なうことを特徴とする請求項1~3のいずれか一つに記載の判定方法。前記要求ステップは、応答内容とともに電子署名を要求する再問い合わせを行なうことを特徴とする請求項1~3のいずれか一つに記載の判定方法。前記要求ステップは、電子署名による検証結果が不当であると判定された時点から、予め設定された時間が経過した時点で、再問い合わせを行なうことを特徴とする請求項1~3のいずれか一つに記載の判定方法。名前解決のための問い合わせを、問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決装置であって、電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを1回要求する要求部と、前記要求部により行なわれた再問い合わせに対する応答が1回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定部と、前記判定部の判定結果に基づいて、名前解決を依頼したクライアント装置に応答を行なう応答部と、を備えたことを特徴とする名前解決装置。名前解決のための問い合わせを、問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決装置に接続される判定装置であって、電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを1回要求する要求部と、前記要求部により行なわれた再問い合わせに対する応答が1回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定部と、を備えたことを特徴とする判定装置。ところで、署名検証に失敗した場合、キャッシュサーバは、クライアント装置に対して、名前解決に失敗したことを示すエラーServerFailureを返信する。署名検証が失敗する要因は、以下の2つに大別されると考えられる。第1の要因は、攻撃者が権威サーバの応答を偽装した偽装応答パケットをキャッシュサーバに送信するキャッシュポイズニングcachepoisoningによるものである。また、第2の要因は、攻撃以外の理由、すなわち、DNSの運用管理における不具合によるものである。第2の要因の一例としては、ネットワーク上でのパケット送受信における負荷増大や、各サーバで設定されている現在時刻の非同期などによる電子署名の期限切れが挙げられる。従来では、キャッシュサーバは、第1の要因であっても、第2の要因であっても、クライアント装置にエラーを送信していた。このため、第2の要因により検証が失敗するケースでは、権威サーバからの応答例えば、IPアドレスが適切であるにも関わらず、利用者に対する名前解決サービスは、停止状態となっていた。また、名前解決サービスの停止にともない、例えば、インターネットサービスにおけるHTTPHypertextTransferProtocoloverSecureSocketLayerサービスにも波及的に影響が及ぶこととなる。そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮するとともに、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供することが可能となる判定方法、名前解決装置及び判定装置を提供することを目的とする。本発明の実施の形態は、一つの態様において、名前解決のための問い合わせを問い合わせ先の権威サーバ群に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証する名前解決システムで実行される判定方法であって、電子署名による検証結果が不当であった場合、前記問い合わせ先の権威サーバ群に対して、名前解決のための再問い合わせを1回要求する要求ステップと、前記要求ステップにより行なわれた再問い合わせに対する応答が1回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する判定ステップと、を含んだことを特徴とする。本発明に係る判定方法、名前解決装置及び判定装置は、攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮するとともに、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供することが可能となるという効果を奏する。以下に、本発明に係る判定方法、名前解決装置及び判定装置の実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。また、以下では、本発明に係る判定方法を実行する名前解決システムDNS:DomainNameSystemを実施例として説明する。まず、図1を用いて、本実施例に係る名前解決システムについて説明する。図1は、本実施例に係る名前解決システムの構成例を示す図である。図1に示す名前解決システムは、クライアント装置10、キャッシュサーバ20、判定装置30及び権威サーバ群40を有する。ここで、図1に示す各装置は、インターネットを介して通信可能な状態で接続される。なお、図1では、キャッシュサーバ20に接続されるクライアント装置10を一台のみ示しているが、実際には、キャッシュサーバ20は、複数台のクライアント装置10と接続される。図1に示す権威サーバ群40は、名前空間の中にある特定のゾーンを管理する複数のサーバから構成される。また、図1に示すキャッシュサーバ20は、クライアント装置10から所定のドメイン名例えば、wwwexaplejpの名前解決の依頼を受け付ける。そして、キャッシュサーバ20は、権威サーバ群40に、依頼されたドメイン名の名前解決のための問い合わせを行なうとともに、権威サーバ群40からの応答をキャッシュする機能を有する名前解決装置としてのサーバである。ここで、図1に示す名前解決システムは、キャッシュサーバ20が、クライアント装置10から依頼された名前解決のための問い合わせを問い合わせ先の権威サーバ群40に対して行ない、受信した応答内容の正当性を当該応答内容の電子署名により検証するシステムである。すなわち、図1に示す名前解決システムは、DNSSECDNSSecurityExtensionsを実行するシステムである。そして、図1に示すように、本実施例に係る名前解決システムには、キャッシュサーバ20及び権威サーバ群40それぞれと通信可能に接続される判定装置30が設置される。以下では、キャッシュサーバ20と権威サーバ群40とにより実行されるDNSSECの処理の一例を説明した後に、本実施例に係る判定装置30が実行する判定方法について説明する。図2は、本実施例に係る名前解決システムが有するキャッシュサーバの構成例を説明するための図である。図2に示すように、本実施例に係るキャッシュサーバ20は、応答部21と、検証部22と、キャッシュ部23と、要求部24とを有する。応答部21は、クライアント装置10との間で通信を行なう。要求部24は、権威サーバ群40との間で通信を行なう。また、要求部24は、権威サーバ群から受信した応答データをキャッシュ部23に格納する。検証部22は、キャッシュ部23に格納された権威サーバ群40からの応答内容及び当該応答内容の電子署名を用いて検証を行なう。キャッシュ部23は、署名検証に成功した応答内容をキャッシュする。具体的には、キャッシュ部23は、署名検証に成功した場合、名前解決を依頼されたドメイン名と、当該ドメイン名のIPアドレスとを対応付けた情報をキャッシュする。ここで、応答部21は、クライアント装置10から名前解決を依頼された場合、依頼されたドメイン名のIPアドレスが、キャッシュ部23にキャッシュ情報として既に格納されているか否かを判定する。応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として既に格納されている場合、クライアント装置10に対してIPアドレスを返信する。一方、応答部21は、依頼されたドメイン名のIPアドレスがキャッシュ情報として格納されていない場合、名前解決の依頼内容を要求部24に転送する。そして、要求部24は、依頼内容に基づいて、権威サーバ群40に問い合わせを行なう。例えば、クライアント装置10からキャッシュ情報として格納されていないwwwexaplejpの名前解決の依頼を受け付けた場合、要求部24は、権威サーバ群40に対して、wwwexaplejpに関する問い合わせを行なう。図3は、キャッシュサーバが問い合わせを行なう権威サーバ群の一例を説明するための図である。なお、以下では、DNSSECの方式として、DSDelegationSigner方式を用いる場合について説明する。また、以下では、クライアント装置10がIPv4InternetProtocolversion4アドレスを要求している場合について説明する。図3に示すように、wwwexaplejpの名前解決に際し、要求部24が問い合わせを行なうサーバは、ルートサーバ41、jpサーバ42及びexamplejpサーバ43となる。ルートサーバ41は、名前空間の最上位に設置されるサーバであり、jpやcomなど、一番上位のドメイン名TLD:TopLevelDomainを管理するサーバのインターネット上の位置IPアドレスを管理するサーバである。また、jpサーバ42は、jpのTLDサーバであり、jpで管理されるexamplejpやadjpなどのインターネット上の位置IPアドレスを管理するサーバである。また、examplejpサーバ43は、自身が管理する名前空間の中にあるホスト、例えば、wwwexaplejpやftpexamplejpのインターネット上の位置IPアドレスを管理するサーバである。なお、上位の権威サーバは、自身が管理する下位の権威サーバのIPアドレスなどを、NSレコードとして保持している。ここで、DNSSECが実行される場合、権威サーバ群40それぞれには、自身が管理するゾーンに関する情報ゾーン情報に署名を行なうための公開鍵及び秘密鍵のペアであるZSKZoneSigningKeyが、管理者により設定される。また、権威サーバ群40それぞれには、ZSKに署名を行なうための公開鍵及び秘密鍵のペアであるKSKKeySigningKeyが、管理者により設定される。図3に示す一例では、ルートサーバ41は、ZSKとして、ZSK-A公開及びZSK-A秘密を保持し、KSKとして、KSK-A公開及びKSK-A秘密を保持する。また、図3に示す一例では、jpサーバ42は、ZSKとして、ZSK-B公開及びZSK-B秘密を保持し、KSKとして、KSK-B公開及びKSK-B秘密を保持する。また、図3に示す一例では、examplejpサーバ43は、ZSKとして、ZSK-C公開及びZSK-C秘密を保持し、KSKとして、KSK-C公開及びKSK-C秘密を保持する。ここで、DNSSECでは、ルートサーバ41、jpサーバ42、examplejpサーバ43及びキャッシュサーバ20それぞれは、同一のハッシュ関数を用いてハッシュ値を計算する。また、DS方式では、下位の権威サーバは、上位の権威サーバに、自身のKSKの公開鍵のハッシュ値であるDSレコードを予め通知している。すなわち、examplejpサーバ43は、自身のDSレコードをjpサーバ42に通知し、jpサーバ42は、自身のDSレコードをルートサーバ41に通知する。そして、ルートサーバ41は、自身のDSレコードをキャッシュサーバ20に通知する。そして、ルートサーバ41、jpサーバ42、examplejpサーバ43及びキャッシュサーバ20は、図4に例示するデータを用いて、DNSSECにおける電子署名を用いた署名検証を実現する。図4は、DNSSECに用いられるデータの一例を説明するための図である。examplejpサーバ43は、図4のAに示すように、wwwexamplejpのIPv4アドレスの情報を含むAAddressレコードのデータ43aを保持する。なお、クライアント装置10がIPv6InternetProtocolversion6アドレスを要求している場合、DNSSECに用いられるデータは、wwwexamplejpのIPv6アドレスの情報を含むAAAAレコードクワッドAレコードとなる。また、examplejpサーバ43は、図4のAに示すように、Aレコードのハッシュ値をZSK-C秘密で暗号化した電子署名であるデータ43bを保持する。また、examplejpサーバ43は、図4のAに示すように、ZSK-C公開のデータ43cと、ZSK-C公開のハッシュ値をKSK-C秘密で暗号化した電子署名であるデータ43dを保持する。また、examplejpサーバ43は、図4のAに示すように、KSK-C公開のデータ43eと、KSK-C公開のハッシュ値をKSK-C秘密で暗号化した電子署名であるデータ43fを保持する。すなわち、examplejpサーバ43は、wwwexaplejpのAレコード及び当該Aレコードの署名として、データ43a及びデータ43bを保持する。また、examplejpサーバ43は、自身のDNSKEYとして、データ43c及びデータ43eを保持する。また、examplejpサーバ43は、DNSKEYの署名として、データ43d及びデータ43fを保持する。jpサーバ42は、図4のBに示すように、examplejpサーバ43のDSレコード、すなわち、KSK-C公開のハッシュ値であるデータ42aと、KSK-C公開のハッシュ値をZSK-B秘密で暗号化した電子署名であるデータ42bを保持する。また、jpサーバ42は、図4のBに示すように、ZSK-B公開のデータ42cと、ZSK-B公開のハッシュ値をKSK-B秘密で暗号化した電子署名であるデータ42dを保持する。また、jpサーバ42は、図4のBに示すように、KSK-B公開のデータ42eと、KSK-B公開のハッシュ値をKSK-B秘密で暗号化した電子署名であるデータ42fを保持する。すなわち、jpサーバ42は、examplejpサーバ43のDSレコード及び当該DSレコードの署名として、データ42a及びデータ42bを保持する。また、jpサーバ42は、自身のDNSKEYとして、データ42c及びデータ42eを保持する。また、jpサーバ42は、DNSKEYの署名として、データ42d及びデータ42fを保持する。ルートサーバ41は、図4のCに示すように、jpサーバ42のDSレコード、すなわち、KSK-B公開のハッシュ値であるデータ41aと、KSK-B公開のハッシュ値をZSK-A秘密で暗号化した電子署名であるデータ41bを保持する。また、ルートサーバ41は、図4のCに示すように、ZSK-A公開のデータ41cと、ZSK-A公開のハッシュ値をKSK-A秘密で暗号化した電子署名であるデータ41dを保持する。また、ルートサーバ41は、図4のCに示すように、KSK-A公開のデータ41eと、KSK-A公開のハッシュ値をKSK-A秘密で暗号化した電子署名であるデータ41fを保持する。すなわち、ルートサーバ41は、jpサーバ42のDSレコード及び当該DSレコードの署名として、データ41a及びデータ41bを保持する。また、ルートサーバ41は、自身のDNSKEYとして、データ41c及びデータ41eを保持する。また、ルートサーバ41は、DNSKEYの署名として、データ41d及びデータ41fを保持する。そして、キャッシュサーバ20は、図4のDに示すように、ルートサーバ41のDSレコード、すなわち、KSK-A公開のハッシュ値であるデータ23aをキャッシュ部23内に保持する。図4に例示したデータを用いて、本実施例に係る名前解決システムが実行する署名検証処理について、図5を用いて説明する。図5は、本実施例に係る名前解決システムが実行する署名検証処理の一例を説明するためのシーケンス図である。なお、図5に示すシーケンス図において、装置間での情報の送受信は、UDPUserDatagramProtocolパケットにより行なわれる。ただし、図5に示すシーケンス図において、装置間での情報の送受信は、TCPTransmissionControlProtocolパケットにより行なわれる場合であっても良い。図5に示すように、クライアント装置10は、キャッシュサーバ20の応答部21に対して、wwwexaplejpのAレコードを問い合わせる名前解決の依頼を行なうステップS1。名前解決の依頼を受け付けた応答部21は、要求部24に名前解決の依頼内容を転送しステップS2、要求部24は、ルートサーバ41にAレコードを問い合わせるステップS3。wwwexaplejpのAレコードの問い合わせを受け付けたルートサーバ41は、NSレコードを参照して、jpサーバ42に問い合わせて下さいと要求部24に返信するステップS4。具体的には、ルートサーバ41は、jpサーバ42のIPアドレスを要求部24に返信する。そして、要求部24は、jpサーバ42にAレコードを問い合わせるステップS5。wwwexaplejpのAレコードの問い合わせを受け付けたjpサーバ42は、NSレコードを参照して、examplejpサーバ43に問い合わせて下さいと要求部24に返信するステップS6。すなわち、jpサーバ42は、examplejpサーバ43のIPアドレスを要求部24に返信する。そして、要求部24は、examplejpサーバ43にAレコードを問い合わせるステップS7。wwwexaplejpのAレコードの問い合わせを受け付けたexamplejpサーバ43は、wwwexaplejpのAレコード及び当該Aレコードの署名を要求部24に返信するステップS8。すなわち、examplejpサーバ43は、図4のAに示すデータ43a及びデータ43bを返信する。そして、要求部24は、examplejpサーバ43に対して、examplejpサーバ43のDNSKEY及び当該DNSKEYの署名を問い合わせステップS9、examplejpサーバ43は、DNSKEY及び当該DNSKEYの署名を要求部24に返信するステップS10。すなわち、examplejpサーバ43は、図4のAに示すデータ43c及びデータ43eと、図4のAに示すデータ43d及びデータ43fとを返信する。そして、要求部24は、ルートサーバ41にexamplejpサーバ43のDSレコードを問い合わせるステップS11、ルートサーバ41は、NSレコードを参照して、jpサーバ42に問い合わせて下さいと要求部24に返信するステップS12。そして、要求部24は、jpサーバ42にexamplejpサーバ43のDSレコードを問い合わせステップS13、jpサーバ42は、examplejpサーバ43のDSレコード及び当該DSレコードの署名を要求部24に返信するステップS14。すなわち、jpサーバ42は、図4のBに示すデータ42a及びデータ42bを返信する。そして、要求部24は、jpサーバ42にjpサーバ42のDNSKEYを問い合わせステップS15、jpサーバ42は、自身のDNSKEY及び署名を返信するステップS16。すなわち、examplejpサーバ43は、図4のBに示すデータ42c及びデータ42eと、図4のBに示すデータ42d及びデータ42fとを返信する。そして、要求部24は、ルートサーバ41にjpサーバ42のDSレコードを問い合わせステップS17、ルートサーバ41は、jpサーバ42のDSレコード及び当該DSレコードの署名を返信するステップS18。すなわち、ルートサーバ41は、図4のCに示すデータ41a及びデータ41bを返信する。そして、要求部24は、ルートサーバ41にルートサーバ41のDNSKEYを問い合わせステップS19、ルートサーバ41は、自身のDNSKEY及び署名を返信するステップS20。すなわち、ルートサーバ41は、図4のCに示すデータ41c及びデータ41eと、図4のCに示すデータ41d及びデータ41fとを返信する。そして、要求部24は、各権威サーバからの一連の応答データをキャッシュ部23に格納しステップS21、検証部22にキャッシュ部23が記憶する応答データの署名検証を依頼するステップS22。そして、検証部22は、検証処理を行なうステップS23。具体的には、検証部23は、データ43aの正当性を、データ43aのハッシュ値と、データ43bをデータ43cで復号した結果とを比較することで検証する。また、検証部22は、データ43cの正当性を、データ43cのハッシュ値と、データ43dをデータ43eで復号した結果とを比較することで検証する。更に、検証部22は、データ43eの正当性を、データ43fをデータ43eで復号した結果と、データ42aとを比較することで検証する。すなわち、検証部22は、KSK-C公開の正当性を、jpサーバ42が保持するDSレコードを用いて検証する。また、検証部22は、データ42aの正当性を、データ42aと、データ42bをデータ42cで復号した結果とを比較することで検証する。また、検証部22は、データ42cの正当性を、データ42cのハッシュ値と、データ42dをデータ42eで復号した結果とを比較することで検証する。更に、検証部22は、データ42eの正当性を、データ42fをデータ42eで復号した結果と、データ41aとを比較することで検証する。すなわち、検証部22は、KSK-B公開の正当性を、ルートサーバ41が保持するDSレコードを用いて検証する。また、検証部22は、データ41aの正当性を、データ41aと、データ41bをデータ41cで復号した結果とを比較することで検証する。また、検証部22は、データ41cの正当性を、データ41cのハッシュ値と、データ41dをデータ41eで復号した結果とを比較することで検証する。更に、検証部22は、データ41eの正当性を、データ41fをデータ41eで復号した結果と、データ23aとを比較することで検証する。すなわち、検証部22は、KSK-A公開の正当性を、キャッシュ部23が保持するDSレコードを用いて検証する。そして、検証部22は、全ての比較結果が一致する場合、権威サーバ群40からの応答内容、すなわち、データ43a、データ43c、データ43e、データ42a、データ42c、データ42e、データ41a、データ41c及びデータ41eが正当であり、署名検証が成功したと判定する。署名検証が成功した場合、応答部21は、クライアント装置10に対して、データ43aを返信する。一方、検証部22は、全ての比較結果が一致しない場合、権威サーバ群40からの応答内容が不当であり、署名検証が失敗したと判定する。ここで、従来では、署名検証が失敗した場合、応答部21は、クライアント装置10に対して、名前解決に失敗したことを示すエラーServerFailureを返信していた。署名検証が失敗する要因には、攻撃者が権威サーバの応答を偽装した偽装応答パケットをキャッシュサーバ20に送信するキャッシュポイズニングcachepoisoningがある。一方、署名検証が失敗する要因には、攻撃以外の理由、すなわち、DNSの運用管理における不具合によるものがある。かかる要因の一例としては、電子署名の期限切れがある。電子署名には、有効期限が設定されており、例えば、各装置で設定されている現在時刻の非同期などが発生した場合、電子署名の期限切れが発生する場合がある。また、ZSKやKSKは、各権威サーバの管理者により、随時更新される。しかし、上位の権威サーバに更新後のDSレコードが通知されていない場合や、そもそもDSレコードが格納されていない場合は、署名検証は、失敗となる。従来では、応答部21は、署名検証失敗と検証部22が判定すると、一様に、ServerFailureを返信していた。かかる場合、DNSの管理者は、例えば、データ43aとして受信したデータが正しい応答内容であるにも関わらず、署名検証が失敗した要因を特定したうえで、復旧作業を行なう必要がある。すなわち、従来では、応答IPアドレスが適切であるにも関わらず、利用者に対するインターネットサービスは、停止状態となっていた。そこで、本実施例に係る名前解決システムには、図1に示すように、キャッシュサーバ20及び権威サーバ群40と接続される判定装置30が設置される。図6は、本実施例に係る判定装置の構成例を説明するための図である。図6に示すように、本実施例に係る判定装置30は、応答部31と、判定部32と、要求部33とを有する。応答部31は、署名検証に失敗した情報を応答部21から受信する。具体的には、応答部21は、検証結果が不当と判定された権威サーバ群40からの一連の応答データをキャッシュ部23から取得する。そして、応答部21は、取得した応答データを、クライアント装置10からの依頼内容と、クライアント装置10から依頼されたタイプとともに、応答部31に送信する。例えば、応答部21は、応答データを、依頼ドメイン名:wwwexaplejp及びタイプ:IPv4アドレスとともに、応答部31に送信する。そして、応答部31は、応答部21から受信した情報を要求部33に転送する。そして、図6に示す要求部33は、電子署名による検証結果が不当であった場合、問い合わせ先の権威サーバ群40に対して、名前解決のための再問い合わせを1回要求する。例えば、要求部33は、wwwexaplejpの名前解決に際し、検証部22の検証結果が失敗であった場合、wwwexaplejpの名前解決の再問い合わせを、ルートサーバ41から順に一回のみ行なう。ここで、要求部33が実行する再問い合わせの条件は、以下に示すように、判定装置30の管理者により設定することができる。図7は、再問い合わせ条件を説明するための図である。まず、図7に示すように、判定装置30が行なう再問い合わせの回数は、1回に固定される。そして、図7に示すように、管理者は、再問い合わせ条件として、判定装置30が再問い合わせを行なうトリガーを、2つのパターンのいずれかにより設定する。第1のトリガーパターンは、図7に示すように、検証結果が失敗するごとに、要求部33が再問い合わせを一回実行すると設定するものである。第1のトリガーパターンが設定された場合、要求部33は、検証結果が失敗するごとに、再問い合わせを1回実行する。また、第2のトリガーパターンは、図7に示すように、同一のドメイン名に対する検証結果がT秒間内にN回以上失敗であった場合に、要求部33が再問い合わせを1回実行すると設定するものである。T及びNの値は、管理者により設定される。すなわち、T秒間を設定時間、N回を設定回数と定義すると、第2のトリガーパターンが設定された場合、要求部33は、同一の名前解決のための問い合わせに対する検証結果が、設定時間内にて設定回数以上で不当であった場合に、再問い合わせを1回行なう。換言すると、第2のトリガーパターンは、同一ドメイン名に対する署名検証が多発したことを契機として、再問い合わせを行なうものである。なお、判定装置30が再問い合わせを行なうトリガーは、判定装置30の管理者が任意のタイミングで再問い合わせ要求を行なった時点である場合であっても良い。また、図7に示すように、管理者は、再問い合わせ条件として、再問い合わせを行なう際に判定装置30がDNSSECを有効ONとするか、無効OFFとするかを選択可能である。すなわち、DNSSEC:ONが選択された場合、要求部33は、電子署名を用いた検証を有効とした状態で、再問い合わせを行なう。具体的には、DNSSEC:ONが選択された場合、要求部33は、問い合わせ先の権威サーバ群40に対して、応答内容とともに電子署名を要求する再問い合わせを行なう。例えば、要求部33は、権威サーバ群40との間で、図5に例示したステップS3、S5、S7、S9、S11、S13、S15、S17及びS19の一連の問い合わせを再度1回のみ行なう。また、DNSSEC:OFFが選択された場合、要求部33は、電子署名を用いた検証を無効とした状態で、再問い合わせを行なう。例えば、要求部33は、権威サーバ群40との間で、図5に例示したステップS3、S5及びS7の一連の問い合わせを再度1回のみ行なう。かかる場合、examplejpサーバ43は、ステップS8においてAレコードのみを返信する。また、図7に示すように、管理者は、再問い合わせ条件として、判定装置30が再問い合わせを行なうタイミングを設定することができる。すなわち、管理者は、トリガー発生後、t秒後に、要求部33が再問い合わせを一回実行すると設定する。tの値は、管理者により設定される。すなわち、t秒間を予め設定された時間と定義すると、要求部33は、電子署名による検証結果が不当であると判定された時点から、予め設定された時間が経過した時点で、再問い合わせを行なう。なお、第2のトリガーパターンが設定されている場合、要求部33は、同一のドメイン名に対する検証結果の失敗が、T秒間内にN回発生した時点から、予め設定された時間が経過した時点で、再問い合わせを行なう。換言すると、本実施例では、キャッシュサーバ20と権威サーバ群との間で従来行なわれていた問い合わせ及び応答のタイミングと関係なく、判定装置30が権威サーバ群との間で行なう問い合わせ及び応答のタイミングが独自に設定される。図6に戻って、判定部32は、要求部33により行なわれた再問い合わせに対する応答が1回だけである場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する。そして、判定部32は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、管理者により設定された検証結果切り替え条件により、検証部22による検証結果を切り替える。図8は、検証結果切り替え条件を説明するための図である。図8に示すように、管理者は、検証結果切り替え条件として、回答が1回とする第1の切り替え条件、又は、回答が1回、かつ、再問い合わせ前後の応答データが一致とする第2の切り替え条件を選択する。すなわち、第1の切り替え条件が設定された場合、判定部32は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、再問い合わせ前の応答内容が正当であると判定する。DNSにおいては、1回の問い合わせに対して、権威サーバ群40からの応答シーケンスが正しく1回確認されるならば、正しい応答とみなすことができる。或いは、DNSにおいては、1回の問い合わせに対して、権威サーバ群40からの最終的な応答が1回であれば正当であるといえる。キャッシュポイズニングの特徴は、不要なパケットを多量に送りつけることにある。従って、問合せにおける1シーケンス内の、送信と応答の数が明らかに違えば、攻撃であるとみなすことができる。又は、第2の切り替え条件が設定された場合、判定部32は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定し、一致している場合、再問い合わせ前の応答内容が正当であると判定する。例えば、判定部32は、図4のA~Cに示すデータ群が、再問い合わせ前後で一致している場合、再問い合わせ前の応答内容が正当であると判定する。なお、判定部32は、再問い合わせに対する回答が複数である場合、検証結果が攻撃によるものであり、再問い合わせ前の応答内容が不当であると判定する。また、判定部32は、第2の切り替え条件が設定されている場合、再問い合わせ前後で応答データが不一致の場合も、再問い合わせ前の応答内容が不当であると判定する。そして、判定部32は、判定結果をキャッシュ部23に格納し、キャッシュ部23に格納した判定結果をクライアント装置10に通知する旨の依頼を応答部21に依頼する。応答部21は、キャッシュ部23に格納された判定結果に基づいて、IPアドレス又は、エラーを返信する。すなわち、判定結果が正当である場合、応答部21は、キャッシュ部23に格納済みの再問い合わせ前のIPアドレス例えば、Aレコードをクライアント装置10に返信する。また、判定結果が不当である場合、応答部21は、ServerFailureをクライアント装置10に返信する。続いて、図9及び図10を用いて、本実施例に係る名前解決システムが実行する判定処理方法の手順について説明する。図9は、本実施例に係る名前解決システムが実行する判定方法の処理の一例を説明するためのシーケンス図である。また、図10は、図9に示すステップS106の判定処理の一例を説明するためのフローチャートである。なお、図9では、トリガーパターンとして第1のトリガーパターンが設定され、再問い合わせ時のDNSSECが有効と設定され、再問い合わせを行なうタイミングとしてt=0が設定され、更に、第2の切り替え条件が設定されている場合を説明する。また、図9では、署名検証が失敗した時点以降の処理について説明する。また、図9に示すシーケンス図において、装置間での情報の送受信は、図5と同様に、UDPパケットにより行なわれる場合であっても良い。なお、図6に示すシーケンス図においても、装置間での情報の送受信は、TCPパケットにより行なわれる場合であっても良い。ただし、TCPでは、再送が行なわれるので、本実施例において、判定装置30と権威サーバ群40との間で行なわれる情報の送受信は、UDPパケットにより行なわれることが望ましい。図9に示すように、応答部21は、署名検証に失敗した情報を応答部31に転送するステップS101。そして、応答部31は、署名検証に失敗した情報を要求部33に転送するステップS102。そして、要求部33は、権威サーバ群40に対して、再問い合わせを1回要求しステップS103、権威サーバ群40は、応答データを返信するステップS104。すなわち、要求部33は、要求部24と権威サーバ群40との間で行なわれた処理例えば、図5に示すステップS3~ステップS20の一連のシーケンスを、1回のみ、権威サーバ群40との間で再度実行する。例えば、要求部33は、ルートサーバ41から順に、wwwexaplejpのAレコードの問い合わせを行なう。そして、要求部33は、wwwexaplejpのDNSKEYの問い合わせを行なった後に、ルートサーバ41から順に、DSレコードの問い合わせを行なう。そして、要求部33は、受信した応答データを判定部32に転送しステップS105、判定部32は、判定処理を行なうステップS106。すなわち、図10に示すように、判定部32は、再問い合わせ要求に対する応答が1回であるか否かを判定するステップS201。ここで、再問い合わせ要求に対する応答が1回でない場合ステップS201否定、判定部32は、再問い合わせ前の応答内容を不当と判定しステップS204、判定処理を終了する。一方、再問い合わせ要求に対する応答が1回である場合ステップS201肯定、判定部32は、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定するステップS202。ここで、再問い合わせ前後で応答データが不一致の場合ステップS202否定、判定部32は、再問い合わせ前の応答内容を不当と判定しステップS204、判定処理を終了する。一方、再問い合わせ前後で応答データが一致の場合ステップS202肯定、判定部32は、再問い合わせ前の応答内容を正当と判定しステップS203、判定処理を終了する。図9に戻って、図10の判定処理を完了した判定部32は、判定結果をキャッシュ部23に格納しステップS107、応答部21に対して、判定結果の通知依頼を行なうステップS108。そして、応答部21は、判定結果に基づいて、IPアドレス又は、エラーを返信しステップS109、処理を終了する。すなわち、応答部21は、ステップS109において、ServerFailureを返信する。上述してきたように、本実施例では、要求部33は、電子署名による検証結果が不当であった場合、問い合わせ先の権威サーバ群40に対して、名前解決のための再問い合わせを1回要求する。そして、判定部32は、要求部33により行なわれた再問い合わせに対する応答が1回である場合に、検証結果が不当であった要因が攻撃以外の要因であると判定する。要求部33と権威サーバ群40とは、UDPパケットにより通信を行なうが、問い合わせに用いられるポート数と、各データの送受信に割り振られる16ビットのトランザクションIDとの組み合わせは、約5000億通りとなる。ここで、攻撃者が、約5000億通りの組み合わせから適切な組み合わせを選択したうえで、要求部33が行なう1回の再問い合わせに対して、偽装応答パケットを1回のみ、タイミング良くキャッシュサーバ20に送出することは、確率的に略不可能である。すなわち、ルートサーバ41から行なう1回の再問い合わせに対して、1回のみの回答が受信された場合、再問い合わせに応答したのは権威サーバ群40である可能性が高い。そこで、本実施例では、1回の再問い合わせに対する回答の回数をカウントすることで、署名検証の失敗の要因が攻撃である場合と、攻撃でない要因による場合とを切り分ける。その結果、本実施例では、検証失敗の要因特定に要する時間、すなわち、名前解決システムの復旧作業に要する時間を短縮することができる。本実施例では、攻撃以外の要因により署名検証の失敗が発生する場合、例えば、権威サーバ群40における電子署名関連の設定に不具合が起こっているのであろうという仮定のもと、1回の再問い合わせに対して1回のみの回答が受信されたのであれば、キャッシュサーバ20は、本来、権威サーバ群40が正しく動作していれば返せていたはずの回答をクライアント装置10に返すことができる。すなわち、本実施例では、権威サーバ群40側での復旧時間を無視して名前解決サービスを提供することができる。このようなことから、本実施例によれば、攻撃以外の要因により署名検証の失敗が発生した場合に、名前解決サービスの停止時間を短縮することが可能となる。また、名前解決サービスの停止にともない、例えば、インターネットサービスにおけるHTTPサービスにも波及的に影響が及ぶことを回避できる。更に、本実施例では、DNSSECを有効にしたときのセキュリティ性はないものの、DNSSECを有効にしていない場合と比べて、セキュリティ性が高い状態で名前解決サービスを提供できる。すなわち、本実施例によれば、署名検証を行なわない場合と比較してセキュリティ性が高い状態で名前解決サービスを提供することが可能となる。また、本実施例では、判定部32は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、以下のいずれかの検証結果切り替え条件により、検証部22による検証結果を切り替える。第1の切り替え条件では、判定部32は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、再問い合わせ前の応答内容が正当であると判定する。或いは、第2の切り替え条件では、判定部32は、検証結果が不当である要因が攻撃以外の要因によると判定した場合、更に、再問い合わせ前と再問い合わせ後とで応答データが一致しているか否かを判定し、一致している場合、再問い合わせ前の応答内容が正当であると判定する。すなわち、第1の切り替え条件では、管理運用上の要因で署名検証が失敗したのであれば、再問い合わせ前の応答内容が正しいデータである可能性が高いことから、ただちに、再問い合わせ前の応答内容を正当と切り替えてクライアント装置10に送信する。よって、第1の切り替え条件では、攻撃以外の要因により署名検証の失敗が発生した場合に、停止時間を極力短縮したうえで、名前解決サービスを継続して提供することができる。一方、第2の切り替え条件では、再問い合わせ前の応答内容の正当性を確実に検証するために、更に、応答データが再問い合わせ前後で一致していることを確認し、一致である場合のみ、再問い合わせ前の応答内容を正当と切り替えてクライアント装置10に送信する。よって、第2の切り替え条件では、攻撃以外の要因により署名検証の失敗が発生した場合に、停止時間を短縮したうえで、DNSSECが無効の場合と比べてセキュアな回答を返すことができる。また、本実施例では、要求部33は、同一の名前解決のための問い合わせに対する検証結果が、設定時間内にて設定回数以上で不当であった場合に、再問い合わせを1回行なう場合であっても良い。すなわち、本実施例は、署名検証が多発した場合に、要求部33及び判定部32の処理を開始する場合であっても良く、かかる設定により、判定装置30にかかる負荷を低減することができる。また、本実施例では、要求部33は、応答内容とともに電子署名を要求する再問い合わせを行なう場合であっても良い。本実施例は、DNSSECを無効とした状態で、再問い合わせを行なっても良いが、DNSSECを有効として、電子署名のデータも一連のシーケンスで1回受信したことを確認するほうが、要因判定処理の信頼性を強固にするためには望ましい。また、本実施例では、要求部33は、電子署名による検証結果が不当であると判定された時点から、予め設定された時間が経過した時点で、再問い合わせを行なう。すなわち、本実施例では、判定装置30が権威サーバ群との間で行なう問い合わせ及び応答のタイミングを、独自に設定することができる。すなわち、本実施例では、1回の再問い合わせに合わせて、偽装応答パケットを偶発的に受信する可能性を低減することができ、検証結果が不当である要因が攻撃以外の要因によるか否かの判定結果の信頼性を向上させることが可能となる。なお、上記の実施例では、判定装置30が1台のキャッシュサーバ20と接続される場合について説明した。しかし、判定装置30は、複数台のキャッシュサーバ20と接続される場合であっても良い。かかる場合、判定装置30は、自身に接続される各キャッシュサーバにおける署名検証の要因や、応答内容の正当性について、判定処理を行なう。また、上記の実施例では、キャッシュサーバ20と接続される判定装置30が再問い合わせ要求処理及び再問い合わせに対する応答を用いた判定処理を行なう場合について説明した。しかし、上記の実施例で説明した再問い合わせ要求処理及び再問い合わせに対する応答を用いた判定処理は、キャッシュサーバ20が実行する場合であっても良い。すなわち、上記の実施例は、判定部32がキャッシュサーバ20に組み込まれ、要求部24が要求部33の処理を実行する場合であっても良い。かかる場合、応答部21は、判定部32の判定結果に基づいて、名前解決を依頼したクライアント装置10に応答を行なう。なお、判定装置30がキャッシュサーバ20と独立して設置する場合であっても、判定装置30がキャッシュサーバ20に組み込まれる場合であっても、本実施例の判定機能は、外部に対しては秘匿とされる。また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。例えば、図6に例示した要求部33と判定部32とは統合されてもよい。また、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUCentralProcessingUnitおよび該CPUにて解析実行されるプログラムにて実現され、或いは、ワイヤードロジックによるハードウェアとして実現され得る。例えば、図6に例示した判定部32は、プログラムにて実現される場合であっても、ワイヤードロジックによるハードウェアとして実現される場合であっても良い。なお、上記実施例で説明した判定方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのIPネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク、CD-ROMCompactDiskReadOnlyMemory、MOMagnetoOpticaldisk、DVDDigitalVersatileDiskなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。