特許 6381038 通信制御装置、通信システム、名前解決方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6381038

(24)【登録日】2018年8月10日

(45)【発行日】2018年8月29日

(54)【発明の名称】通信制御装置、通信システム、名前解決方法及びプログラム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20180820BHJP

【ＦＩ】

   H04L12/70 100Z

   H04L12/70 B

【請求項の数】4

【全頁数】16

(21)【出願番号】特願2015-63739(P2015-63739)

(22)【出願日】2015年3月26日

(65)【公開番号】特開2016-184840(P2016-184840A)

(43)【公開日】2016年10月20日

【審査請求日】2016年7月8日

(73)【特許権者】

【識別番号】000227205

【氏名又は名称】ＮＥＣプラットフォームズ株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】青島 敦

【審査官】 衣鳩 文彦

(56)【参考文献】

【文献】 米国特許第０７４２６５７６（ＵＳ，Ｂ１）

【文献】 特開２００７−２５１８１８（ＪＰ，Ａ）

【文献】 山田 竜也 他，現在の名前解決システムの課題と汎用名前解決エンジンの提案，情報処理学会研究報告，日本，２００２年１０月１８日，第2002巻,第95号，p.25〜30

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

(57)【特許請求の範囲】

【請求項1】

第１のＤＮＳサーバ及び第２のＤＮＳサーバへ、名前解決要求メッセージを送信する通信部と、
前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定する状態監視部と、を備え、
前記状態監視部は、
前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバのいずれかに異常が発生していると判定した場合、正常なＤＮＳサーバから、第３のＤＮＳサーバのアドレス情報を取得し、
前記通信部は、
前記状態監視部において、異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求メッセージを送信することより、前記第２のＤＮＳサーバへ名前解決要求メッセージを送信することを優先し、前記状態監視部において、前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバのいずれかに異常が発生していると判定した場合、前記正常なＤＮＳサーバ及び前記第３のＤＮＳサーバへ、名前解決要求メッセージを送信する、通信制御装置。

【請求項2】

第１のＤＮＳサーバと、
第１のＤＮＳサーバと異なる第２のＤＮＳサーバと、
前記第１および第２のＤＮＳサーバサーバと異なる第３のＤＮＳサーバと、
前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバを用いて名前解決処理を実行する通信制御装置と、を備え、
前記通信制御装置は、
前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバへ、名前解決要求メッセージを送信する通信部と、
前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定する状態監視部と、を有し、
前記状態監視部は、
前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバのいずれかに異常が発生していると判定した場合、正常なＤＮＳサーバから、前記第３のＤＮＳサーバのアドレス情報を取得し、
前記通信部は、
前記状態監視部において、異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求メッセージを送信することより、前記第２のＤＮＳサーバへ名前解決要求メッセージを送信することを優先し、前記状態監視部において、前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバのいずれかに異常が発生していると判定した場合、前記正常なＤＮＳサーバ及び前記第３のＤＮＳサーバへ、名前解決要求メッセージを送信する、通信システム。

【請求項3】

第１のＤＮＳサーバ及び第２のＤＮＳサーバへ、名前解決要求メッセージを送信し、
前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定し、
異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求を送信することより、前記第２のＤＮＳサーバへ前記名前解決要求メッセージを送信することを優先し、前記第２のＤＮＳサーバから、第３のＤＮＳサーバのアドレス情報を取得し、
前記第２のＤＮＳサーバ及び前記第３のＤＮＳサーバへ、名前解決要求メッセージを送信する、名前解決方法。

【請求項4】

第１のＤＮＳサーバ及び第２のＤＮＳサーバへ、名前解決要求メッセージを送信し、
前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定し、
異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求を送信することより、前記第２のＤＮＳサーバへ前記名前解決要求メッセージを送信することを優先し、前記第２のＤＮＳサーバから、第３のＤＮＳサーバのアドレス情報を取得し、
前記第２のＤＮＳサーバ及び前記第３のＤＮＳサーバへ、名前解決要求メッセージを送信する、ことをコンピュータに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は通信制御装置、通信システム、名前解決方法及びプログラムに関し、例えば複数のＤＮＳサーバを用いる通信制御装置、通信システム、名前解決方法及びプログラムに関する。

【背景技術】

【0002】

通信装置がインターネットを利用してＷｅｂサーバへアクセスする場合、ＷｅｂブラウザのＩＰアドレスを取得するために、ＤＮＳ（Domain Name System）を利用した名前解決処理が行われる。ＤＮＳサーバの障害等に備えて、通信装置は、複数のＤＮＳサーバを利用することができる。通信装置は、ＤＮＳを利用した名前解決処理を行う場合、複数のＤＮＳサーバ、例えば、プライマリＤＮＳサーバ及びセカンダリＤＮＳサーバへ、名前解決処理の実行を要求するメッセージを送信する。通信装置は、プライマリＤＮＳサーバ及びセカンダリＤＮＳサーバの少なくとも一方から受信したＩＰアドレス情報を用いて、Ｗｅｂサーバへアクセスする。

【0003】

特許文献１には、ウェブサーバが一時的にダウン等しており、ウェブクライアントが、ウェブサーバから情報を受信することができない場合の動作が記載されている。具体的には、ウェブサーバは、ウェブクライアントからの要求に対応することができない場合、エラーメッセージを送信する代わりにウェブサーバが停止していること等を知らせるためのページを作成して、ウェブクライアントへウェブサーバが停止していることを通知することが記載されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００２−２５９３３８号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

プライマリＤＮＳサーバとセカンダリＤＮＳサーバを利用することができる環境において、プライマリＤＮＳサーバに障害が発生したとしても、通信装置は、セカンダリＤＮＳサーバから送信されるＩＰアドレス情報を用いて、Ｗｅｂサーバへアクセスすることができる。しかし、一般的に、通信装置は、プライマリＤＮＳサーバに障害が発生した後の名前解決処理においても、プライマリＤＮＳサーバ及びセカンダリＤＮＳサーバへ名前解決処理の実行を要求する。

【0006】

また、特許文献１に記載されているように、装置が停止していることを示すページを用いて、装置が停止していることを周知する場合においても、停止している装置へアクセスする必要がある。そのため、特許文献１に記載されている処理をＤＮＳサーバに障害が発生した場合に実行しても、障害が発生しているプライマリＤＮＳサーバに対して、負荷がかかり続け、プライマリＤＮＳサーバの障害からの復旧が困難になるという問題が発生する。

【0007】

本発明の目的は、通信装置が利用することができる複数のＤＮＳサーバのうち一部のＤＮＳサーバに障害が発生した場合に、障害が発生したＤＮＳサーバの負荷を軽減することができる通信制御装置、通信システム、名前解決方法及びプログラムを提供することにある。

【課題を解決するための手段】

【0008】

本発明の第１の態様にかかる通信制御装置は、第１のＤＮＳサーバ及び第２のＤＮＳサーバへ、名前解決要求メッセージを送信する通信部と、前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常正常性を判定する状態監視部と、を備え、前記通信部は、前記状態監視部において、異常が発生していると判定されたＤＮＳサーバへ名前解決要求メッセージを送信することより、前記第２のＤＮＳサーバへ名前解決要求メッセージを送信することを優先するものである。

【0009】

本発明の第２の態様にかかる通信システムは、第１のＤＮＳサーバと、第１のＤＮＳサーバと異なる第２のＤＮＳサーバと、前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバを用いて名前解決処理を実行する通信制御装置と、を備え、前記通信制御装置は、前記第１のＤＮＳサーバ及び前記第２のＤＮＳサーバへ、名前解決要求メッセージを送信する通信部と、前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定する状態監視部と、を有し、前記通信部は、前記状態監視部において、異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求を送信することより前記第２のＤＮＳサーバへ前記名前解決要求メッセージを送信することを優先するものである。

【0010】

本発明の第３の態様にかかる名前解決方法は、第１のＤＮＳサーバ及び第２のＤＮＳサーバへ、名前解決要求メッセージを送信し、前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定し、異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求を送信することより、前記第２のＤＮＳサーバへ前記名前解決要求メッセージを送信することを優先するものである。

【0011】

本発明の第４の態様にかかるプログラムは第１のＤＮＳサーバ及び第２のＤＮＳサーバへ、名前解決要求メッセージを送信し、前記名前解決要求メッセージに対する前記第１のＤＮＳサーバの応答状況に応じて、前記第１のＤＮＳサーバの異常を判定し、異常が発生していると判定された前記第１のＤＮＳサーバへ名前解決要求を送信することより、前記第２のＤＮＳサーバへの前記名前解決要求メッセージの送信を優先することをコンピュータに実行させるものである。

【発明の効果】

【0012】

本発明により、通信装置が利用することができる複数のＤＮＳサーバのうち一部のＤＮＳサーバに障害が発生した場合に、障害が発生したＤＮＳサーバの負荷を軽減することができる通信制御装置、通信システム、名前解決方法及びプログラムを提供することができる。

【図面の簡単な説明】

【0013】

【図1】実施の形態１にかかる通信制御装置の構成図である。

【図2】実施の形態２にかかる通信システムの構成図である。

【図3】実施の形態２にかかるホームゲートウェイの構成図である。

【図4】実施の形態２にかかる名前解決処理の流れを示す図である。

【図5】実施の形態２にかかるホームゲートウェイの状態遷移を説明する図である。

【図6】実施の形態３にかかるホームゲートウェイの構成図である。

【図7】実施の形態４にかかる名前解決処理の流れを示す図である。

【図8】実施の形態５にかかる名前解決処理の流れを示す図である。

【図9】実施の形態６にかかる名前解決処理の流れを示す図である。

【発明を実施するための形態】

【0014】

（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。図１を用いて本発明の実施の形態１にかかる通信制御装置の構成例について説明する。通信制御装置１は、ＤＮＳサーバ４及びＤＮＳサーバ５を用いて名前解決処理を実行する。また、通信制御装置１は、プロセッサがメモリに格納されているプログラムを実行することによって動作するコンピュータ装置であってもよい。

【0015】

通信制御装置１は、状態監視部２及び通信部３を有している。状態監視部２及び通信部３は、プロセッサがメモリに格納されているプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。また、状態監視部２及び通信部３は、回路等によって行為されてもよい。

【0016】

通信部３は、ＤＮＳサーバ４及びＤＮＳサーバ５へ、名前解決要求メッセージを送信する。通信部３は、名前解決要求メッセージへ、アクセスするＷｅｂサーバ等のホスト名を設定してもよい。

【0017】

状態監視部２は、通信部３によって送信された名前解決要求メッセージに対するＤＮＳサーバ４及びＤＮＳサーバ５の応答状況に応じて、ＤＮＳサーバ４及びＤＮＳサーバ５の正常性を判定する。もしくは、状態監視部２は、名前解決要求メッセージに対するＤＮＳサーバ４の応答状況に応じて、ＤＮＳサーバ４の異常を判定する。ＤＮＳサーバ４及びＤＮＳサーバ５の応答状況とは、例えば、ＤＮＳサーバ４及びＤＮＳサーバ５がどのような応答メッセージを送信するか、もしくは、ＤＮＳサーバ４及びＤＮＳサーバ５から応答メッセージを受信したか、等であってもよい。

【0018】

例えば、ＤＮＳサーバ４及びＤＮＳサーバ５は、ホスト名が設定された名前解決要求メッセージを受信すると、正常であれば、ホスト名に関連付けられたＩＰアドレス情報を設定した応答メッセージを通信制御装置１へ送信する。

【0019】

しかし、ＤＮＳサーバ４及びＤＮＳサーバ５は、異常が発生している場合、通信制御装置１へ、エラーメッセージを送信する、応答メッセージを送信するまでの時間が長い、もしくは、エラーメッセージ及び応答メッセージを送信することができない、等の事象が発生する。

【0020】

そのため、状態監視部２は、ＤＮＳサーバ４及びＤＮＳサーバ５の応答状況を確認することによって、ＤＮＳサーバ４及びＤＮＳサーバ５の正常性を判定することができる。

【0021】

ここで、状態監視部２において、ＤＮＳサーバ４及びＤＮＳサーバ５のいずれかに異常が発生していると判定された場合の通信部３の動作について説明する。ここでは、ＤＮＳサーバ４に異常が発生していると判定されたとする。ＤＮＳサーバ４に異常が発生しているとは、例えば、ＤＮＳサーバ４に障害が発生したこと、ＤＮＳサーバ４が輻輳状態であること、もしくは、通信制御装置１とＤＮＳサーバ４との間の通信経路に障害が発生したこと等の事象を含んでもよい。

【0022】

通信部３は、状態監視部２においてＤＮＳサーバ４に異常が発生していると判定された場合、所定期間、ＤＮＳサーバ４へ名前解決要求メッセージを送信することなく、正常であるＤＮＳサーバ５へ名前解決要求メッセージを送信する。所定期間は、例えば、通信制御装置１の管理者等によって任意に設定された期間であってもよく、任意のタイミングに変更可能な期間であってもよい。つまり、通信部３は、異常が発生しているＤＮＳサーバ４へ名前解決要求メッセージを送信することよりも、ＤＮＳサーバ５へ名前解決要求メッセージを送信することを優先する。

【0023】

以上説明したように、図１の通信制御装置１は、最初にＤＮＳサーバ４及びＤＮＳサーバ５へ名前解決要求メッセージを送信した後、ＤＮＳサーバ４に異常が発生していると判定した場合、その後の名前解決要求メッセージをＤＮＳサーバ５のみへ送信する。そのため、異常が発生しているＤＮＳサーバ４へは、通信制御装置１から名前解決要求メッセージは送信されることがないため、異常が発生しているＤＮＳサーバ４に負荷がかかり続けることを防止することができる。

【0024】

（実施の形態２）
続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、ＨＧＷ（ホームゲートウェイ）１１、ＰＣ（Personal Computer）１２、ＤＮＳサーバ１３、ＤＮＳサーバ１４及びＷｅｂサーバ１５を有している。また、ＨＧＷ１１、ＤＮＳサーバ１３、ＤＮＳサーバ１４及びＷｅｂサーバ１５は、インターネット網１６を介して通信を行う。ＰＣ１２は、例えば、インターネット網１６に接続しないローカルネットワークを介してＨＧＷ１１と通信を行ってもよく、ケーブル等を利用して物理的にＨＧＷ１１と接続して、通信を行ってもよい。

【0025】

ＨＧＷ１１は、図１の通信制御装置１に相当する。ＤＮＳサーバ１３及びＤＮＳサーバ１４は、図１のＤＮＳサーバ４及びＤＮＳサーバ５に相当する。例えば、ＨＧＷ１１は、ＤＮＳサーバ１３をプライマリＤＮＳサーバとし、ＤＮＳサーバ１４をセカンダリＤＮＳサーバとして利用してもよい。

【0026】

続いて、図３を用いて本発明の実施の形態２にかかるＨＧＷ１１の構成例について説明する。ＨＧＷ１１は、ＬＡＮ（Local Area Network）インタフェース１１１、ＷＡＮ（Wide Area Network）インタフェース１１２、Ｐｒｏｘｙ ＤＮＳ制御部２１１、ＤＮＳリゾルバ処理部２１２及び状態監視部２１３を有している。状態監視部２１３は、図１の状態監視部２に相当するため、図１と同様の内容については詳細な説明を省略する。

【0027】

ＬＡＮインタフェース１１１は、例えばイーサネット（登録商標）等を介して、ＰＣ１２と通信を行うために用いられるインタフェースである。ＷＡＮインタフェース１１２は、例えば、光回線等を介してインターネット網１６へ接続し、ＤＮＳサーバ１３及びＤＮＳサーバ１４と通信を行うために用いられるインタフェースである。ＷＡＮインタフェース１１２は、図１の通信部３に相当する。

【0028】

Ｐｒｏｘｙ ＤＮＳ制御部２１１は、ＰＣ１２から送信されたＤＮＳ問い合わせに関するメッセージを受信する。さらに、Ｐｒｏｘｙ ＤＮＳ制御部２１１は、受信したＤＮＳ問い合わせに関するメッセージをＤＮＳリゾルバ処理部２１２へ出力する。

【0029】

ＤＮＳリゾルバ処理部２１２は、ＰＣ１２が指定したホスト名に関する名前解決処理を実行するために、ＤＮＳサーバ１３及びＤＮＳサーバ１４へ、ＤＮＳ Ｑｕｅｒｙメッセージを送信する。もしくは、ＤＮＳリゾルバ処理部２１２は、状態監視部２１３におけるＤＮＳサーバ１３及びＤＮＳサーバ１４の正常性判定結果に応じて、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかにＤＮＳ Ｑｕｅｒｙメッセージを送信する。

【0030】

ＤＮＳリゾルバ処理部２１２は、送信したＤＮＳ Ｑｕｅｒｙメッセージへの応答メッセージとして、ＤＮＳ Ａｎｓｗｅｒメッセージを受信する。ＤＮＳリゾルバ処理部２１２は、ＤＮＳ Ｑｕｅｒｙメッセージを送信したこと及びＤＮＳ Ａｎｓｗｅｒメッセージを受信したことを、状態監視部２１３へ通知する。

【0031】

状態監視部２１３は、ＤＮＳリゾルバ処理部２１２がＤＮＳ Ｑｕｅｒｙメッセージを送信してからＤＮＳ Ａｎｓｗｅｒメッセージを送信するまでの待ち時間を計測する。状態監視部２１３は、計測した時間に基づいてＤＮＳサーバ１３及びＤＮＳサーバ１４の状態を判定する。状態監視部２１３は、判定結果に応じて、ＤＮＳリゾルバ処理部２１２へ、使用するＤＮＳサーバを通知する。状態監視部２１３は、例えば、予め定められた時間を定めた閾値を超えてＤＮＳ Ａｎｓｗｅｒメッセージを受信した場合、もしくは、ＤＮＳ Ａｎｓｗｅｒメッセージを受信しない場合、ＤＮＳサーバに異常が発生していると判定してもよい。

【0032】

続いて、図４を用いて本発明の実施の形態２にかかる名前解決処理の流れについて説明する。本図においては、ＤＮＳサーバ１３に障害が発生していることを前提とする。

【0033】

はじめに、ＰＣ１２は、ＨＧＷ１１へＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ１１）。ＤＮＳ Ｑｕｅｒｙメッセージには、ＰＣ１２が通信を行うＷｅｂサーバ１５のホスト名もしくはドメイン名等が設定されている。ＨＧＷ１１は、Ｐｒｏｘｙ ＤＮＳ制御部２１１にてＤＮＳ Ｑｕｅｒｙメッセージを受信すると、受信したＤＮＳ ＱｕｅｒｙメッセージをＤＮＳリゾルバ処理部２１２へ出力する。

【0034】

次に、ＨＧＷ１１のＤＮＳリゾルバ処理部２１２は、インターネット網１６上のＤＮＳサーバ１３及びＤＮＳサーバ１４に対して名前解決の問い合わせを行う。具体的には、ＨＧＷ１１のＤＮＳリゾルバ処理部２１２は、ＤＮＳサーバ１３及びＤＮＳサーバ１４へ、ＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ１２及びＳ１３）。

【0035】

ここで、ＤＮＳサーバ１３には障害が発生しているため、ＤＮＳサーバ１３は、ＤＮＳ Ｑｕｅｒｙメッセージに対する応答メッセージを送信することができない。そのため、ＨＧＷ１１は、ＤＮＳサーバ１４からのみＤＮＳ Ｑｕｅｒｙメッセージに対する応答メッセージとして、ＤＮＳ Ａｎｓｗｅｒメッセージを受信する（Ｓ１４）。ＤＮＳ Ａｎｓｗｅｒメッセージには、ＰＣ１２が通信を行うＷｅｂサーバ１５のＩＰアドレスが設定されている。

【0036】

次に、Ｐｒｏｘｙ ＤＮＳ制御部２１１は、ＤＮＳサーバ１４から送信されたＤＮＳ ＡｎｓｗｅｒメッセージをＰＣ１２へ送信する（Ｓ１５）。次に、ＰＣ１２は、Ｗｅｂサーバ１５と通信を行うために、ＤＮＳ Ａｎｓｗｅｒメッセージにおいて指定されたＩＰアドレスに対して、ＨＴＴＰ（Hypertext Transfer Protocol）要求メッセージを送信する（Ｓ１６）。次に、Ｗｅｂサーバ１５は、ＨＴＴＰ要求メッセージに対する応答メッセージとして、ＨＴＴＰ応答メッセージをＰＣ１２へ送信する（Ｓ１７）。

【0037】

ＨＧＷ１１の状態監視部２１３は、ＤＮＳ ＱｕｅｒｙメッセージをＤＮＳサーバ１３及びＤＮＳサーバ１４へ送信してから、ＤＮＳサーバ１３及びＤＮＳサーバ１４からＤＮＳ Ａｎｓｗｅｒメッセージを受信するまでの応答時間を計測している。本図においては、状態監視部２１３は、ＤＮＳサーバ１３から、予め定められた応答時間を設定した閾値を超えてもＤＮＳ Ａｎｓｗｅｒメッセージを受信しないため、ＤＮＳサーバ１３が応答不能な状態になっていると判定する。

【0038】

次に、ＰＣ１２は、Ｗｅｂサーバ１５とは異なるＷｅｂサーバ１５＿１と通信を行うために、Ｗｅｂサーバ１５＿１のホスト名を設定したＤＮＳ ＱｕｅｒｙメッセージをＨＧＷ１１へ送信する（Ｓ１８）。ここで、ＨＧＷ１１の状態監視部２１３は、ＤＮＳサーバ１３について、応答不能な状態であると判定している。そのため、Ｗｅｂサーバ１５＿１に関する名前解決処理を行う際に、ＤＮＳ ＱｕｅｒｙメッセージをＤＮＳサーバ１４のみに送信する（Ｓ１９）。次に、ＨＧＷ１１は、ＤＮＳサーバ１４からＤＮＳ Ａｎｓｗｅｒメッセージを受信する。その後の処理は、ステップＳ１５〜Ｓ１７と同様であるため詳細な説明を省略する。

【0039】

状態監視部２１３は、ＤＮＳサーバ１３が応答不能な状態であると判定してから、所定期間経過した後に、ＰＣ１２から受信したＤＮＳ ＱｕｅｒｙメッセージをＤＮＳサーバ１３及びＤＮＳサーバ１４へ送信できるようにしてもよい。具体的には、状態監視部２１３は、ＤＮＳサーバ１３が応答不能な状態であると判定してから、所定期間経過後に、ＤＮＳリゾルバ処理部２１２へ、ＤＮＳサーバ１３に対するＤＮＳ Ｑｕｅｒｙメッセージの送信停止を解除することを通知するメッセージを出力する。

【0040】

ＤＮＳサーバ１３に対するＤＮＳ Ｑｕｅｒｙメッセージの送信停止を解除された後、ＤＮＳリゾルバ処理部２１２は、ＤＮＳサーバ１３へＤＮＳ Ｑｕｅｒｙメッセージを送信することができる。ここで、状態監視部２１３は、ＤＮＳサーバ１３から、ＤＮＳ Ａｎｓｗｅｒメッセージが送信されてこないと判定した場合、再度、所定期間の間ＤＮＳサーバ１３へのＤＮＳ Ｑｕｅｒｙメッセージの送信を停止してもよい。また、状態監視部２１３は、ＤＮＳサーバ１３が応答不能であると１回目に判定した際に設定した、ＤＮＳサーバ１３へのＤＮＳ Ｑｕｅｒｙメッセージの送信停止期間よりも、ＤＮＳサーバ１３が応答不能であると２回目に判定した際に設定したＤＮＳサーバ１３へのＤＮＳ Ｑｕｅｒｙメッセージの送信停止期間を長くしてもよく、もしくは短くしてもよい。

【0041】

ここで、図５を用いて本発明の実施の形態２にかかるＨＧＷ１１の状態遷移について説明する。ＨＧＷ１１は、通常状態においては、ＰＣ１２から送信されたＤＮＳ Ｑｕｅｒｙメッセージを、ＤＮＳサーバ１３及びＤＮＳサーバ１４へ送信する。

【0042】

状態監視部２１３は、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかに発生した異常を検知すると、ＤＮＳ送信抑制状態へ遷移する。ＨＧＷ１１は、ＤＮＳ送信抑制状態においては、ＰＣ１２から送信されたＤＮＳ Ｑｕｅｒｙメッセージを、正常に動作しているいずれかのＤＮＳサーバへ送信する。

【0043】

所定期間経過すると、ＨＧＷ１１は、ＤＮＳ復旧確認状態へ遷移する。ここで、ＨＧＷ１１は、ＰＣ１２から送信されたＤＮＳ Ｑｕｅｒｙメッセージを、ＤＮＳサーバ１３及びＤＮＳサーバ１４へ送信する。ＨＧＷ１１は、ＤＮＳサーバ１３及びＤＮＳサーバ１４からＤＮＳ Ａｎｓｗｅｒメッセージを受信すると、通常状態へ遷移する。ＨＧＷ１１は、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかからＤＮＳ Ａｎｓｗｅｒメッセージが送信されてこない場合、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかに異常が発生したと判定し、ＤＮＳ送信抑制状態へ遷移する。

【0044】

以上説明したように、本発明の実施の形態２にかかるＨＧＷ１１を用いることによって、以下の効果を有する。

【0045】

第１の効果として、ＨＧＷ１１は、障害発生中のＤＮＳサーバへの問合せを減らすことができる。つまり、ＨＧＷ１１は、インターネット網との末端でＤＮＳサーバへの問合せをブロックしている。そのため、障害時にＰＣ等からのＤＮＳサーバへのＤＮＳ Ｑｕｅｒｙメッセージの再送などによって、ＤＮＳサーバの障害時には平常時よりも多く送信されてしまうインターネット網へトラフィックを減らすことが可能となる。

【0046】

第２の効果として、インターネット網側は特別な装置や機能を追加することなく、障害発生中のＤＮＳサーバへの問合せを減らすことが可能となる。

【0047】

第３の効果として、ＨＧＷ１１は、障害発生中のＤＮＳサーバに対して問合せを実施しない。そのため、障害発生中のＤＮＳサーバからの応答を待っている時間が無くなる。よって、ＰＣ等が、インターネットアクセスする際にスムーズに名前解決を行うことができるため、ユーザに対して快適なインターネットアクセスを提供できる。

【0048】

第４の効果として、ＨＧＷ１１は、ＰｒｏｘｙＤＮＳ機能を有することによりユーザが使用しているＰＣには何も設定変更が必要なく、ユーザによる特別な操作が行われなくとも障害発生サーバに対する問合せ抑制が実施される。

【0049】

第５の効果として、ＨＧＷ１１が応答時間を計測することによって、ＤＮＳサーバが応答不能になる前に異常を感知することも可能である。そのため、ＤＮＳ Ｑｕｅｒｙメッセージの送信を抑制するタイミングを早め、ＤＮＳサーバがＤＮＳ Ｑｕｅｒｙメッセージの受信負荷によってダウンすることを未然に防ぐこともできる。

【0050】

（実施の形態３）
続いて、図６を用いて本発明の実施の形態３にかかるＨＧＷ２１の構成例について説明する。図６は、図３のＨＧＷ２１に、ＩＣＭＰ（Internet Control Message Protocol）処理部２２４が追加された構成となる。ＨＧＷ２１におけるＩＣＭＰ処理部２２４以外の構成については、図３のＨＧＷ１１と同様であるため詳細な説明を省略する。

【0051】

ＩＣＭＰ処理部２２４は、ＷＡＮインタフェース１１２を介して、ＤＮＳサーバ１３及びＤＮＳサーバ１４へＩＣＭＰメッセージを送信する。ＩＣＭＰ処理部２２４は、ＩＣＭＰメッセージへの応答としてエラーメッセージ（Type3 Destination Unreachable）を受信すると、状態監視部２１３へエラーメッセージを出力する。ここで、エラーメッセージは、ＤＮＳサーバ１３もしくはＤＮＳサーバ１４が送信する場合もあれば、ＨＧＷ２１と、ＤＮＳサーバ１３及びＤＮＳサーバ１４との間のルータ装置等が送信する場合もある。

【0052】

また、ＩＣＭＰ処理部２２４は、定期的にＩＣＭＰ（Type8 echo）を用いた、ＤＮＳサーバ１３及びＤＮＳサーバ１４の死活監視を行ってもよい。

【0053】

状態監視部２１３は、ＩＣＭＰ処理部２２４からエラーメッセージが出力された場合に、ＤＮＳサーバ１３もしくはＤＮＳサーバ１４のいずれかに異常が発生しているか否かを判定する。

【0054】

状態監視部２１３は、ＩＣＭＰ処理部２２４から出力されたエラーメッセージが、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかから送信されたかを判定する。状態監視部２１３は、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかから送信されたエラーメッセージであると判定すると、エラーメッセージを送信してきたＤＮＳサーバへのＤＮＳ Ｑｕｅｒｙメッセージの送信を停止させる。

【0055】

また、状態監視部２１３は、エラーメッセージが、ＨＧＷ２１と、ＤＮＳサーバ１３及びＤＮＳサーバ１４との経路上のルータ装置等から送信され、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかとの通信ができないと判定した場合であっても、通信不能のＤＮＳサーバへのＤＮＳ Ｑｕｅｒｙメッセージの送信を停止させてもよい。

【0056】

また、状態監視部２１３は、ＤＮＳ送信抑制状態において、異常が発生したＤＮＳサーバが復旧したか否かを確認するために、ＩＣＭＰ処理部２２４へＩＣＭＰメッセージを、異常が発生したＤＮＳサーバへ送信することを指示してもよい。ここで、ＩＣＭＰ処理部２２４が、ＤＮＳサーバが正常であることを示すＩＣＭＰ（Type0 echo Reply）を受信すると、異常が発生したＤＮＳサーバが復旧したと判定してもよい。また、状態監視部２１３は、ＤＮＳサーバに異常が発生したと判定した後にも定期的にＩＣＭＰメッセージをＤＮＳサーバへ送信し、ＤＮＳサーバの死活監視を行ってもよい。

【0057】

また、図６においては、ＩＣＭＰを用いる場合について説明したが、ＤＮＳサーバに対して死活監視を行うことができる他のプロトコルを用いてＤＮＳサーバを監視してもよい。

【0058】

以上説明したように、実施の形態３にかかるＨＧＷ２１は、ＩＣＭＰを用いて定期的にＤＮＳサーバの死活監視を実施することができる。これより、ＨＧＷ２１は、ＩＣＭＰのエラーメッセージを用いて、ＤＮＳサーバに障害が発生しているか否かを判定し、その判定結果に応じて、ＤＮＳサーバへのＤＮＳ Ｑｕｅｒｙメッセージの送信停止もしくは送信停止の解除を判定することができる。

【0059】

また、ＨＧＷ２１は、実施の形態２において説明した、ＤＮＳ Ａｎｓｗｅｒメッセージの受信状況に応じた障害検知方法も、ＩＣＭＰを用いた障害検知方法と組み合わせて実施してもよい。例えば、状態監視部２１３は、ＤＮＳ Ａｎｓｗｅｒメッセージが閾値に設定した時間が経過しても送信されてこない場合もしくはＩＣＭＰにてエラーメッセージが送信されてきた場合のいずれかに該当する場合、ＤＮＳサーバ１３及びＤＮＳサーバ１４のいずれかに障害が発生していると判定してもよい。

【0060】

（実施の形態４）
続いて、図７を用いて本発明の実施の形態４にかかる名前解決処理の流れについて説明する。また、図７においては、図３において説明したＨＧＷ１１を用いるとする。図７においては、ＤＮＳサーバ１３をプライマリＤＮＳサーバとし、ＤＮＳサーバ１４をセカンダリＤＮＳサーバとする。ステップＳ２１〜Ｓ２３は、図４のステップＳ１１〜Ｓ１３と同様であるため詳細な説明を省略する。ＨＧＷ１１は、ステップＳ２２において、ＤＮＳサーバ１３へＤＮＳ Ｑｕｅｒｙメッセージを送信した後に、ステップＳ２３において、ＤＮＳサーバ１４へＤＮＳ Ｑｕｅｒｙメッセージを送信する。

【0061】

次に、ＨＧＷ１１は、後から送信したＤＮＳサーバ１４へのＤＮＳ Ｑｕｅｒｙメッセージに対する応答メッセージであるＤＮＳ Ａｎｓｗｅｒメッセージを受信する（Ｓ２４）。次に、ＨＧＷ１１は、ＤＮＳサーバ１４からＤＮＳ Ａｎｓｗｅｒメッセージを受信した後に、ＤＮＳサーバ１３からＤＮＳ Ａｎｓｗｅｒメッセージを受信する（Ｓ２５）。ここで、ＨＧＷ１１は、ＤＮＳサーバ１３の応答時間Ｔ１及びＤＮＳサーバ１４の応答時間Ｔ２をメモリ等に保存する。また、ＨＧＷ１１の状態監視部２１３は、ＤＮＳサーバ１４の応答時間Ｔ２のほうがＤＮＳサーバ１３の応答時間Ｔ１よりも短いと判定する。

【0062】

ステップＳ２６〜Ｓ２９は、図４のステップＳ１５〜Ｓ１８と同様であるため詳細な説明を省略する。

【0063】

ＨＧＷ１１は、ステップＳ２９において、ＤＮＳ Ｑｕｅｒｙメッセージを受信すると、ＤＮＳサーバ１４の応答時間Ｔ２が、ＤＮＳサーバ１３の応答時間Ｔ１よりも短いことを考慮して、ＤＮＳサーバ１４を、プライマリＤＮＳサーバ、ＤＮＳサーバ１３をセカンダリＤＮＳサーバとして、名前解決処理を行ってもよい。つまり、ＨＧＷ１１は、ＤＮＳ Ｑｕｅｒｙメッセージを最初にＤＮＳサーバ１４へ送信し（Ｓ３０）、次に、ＤＮＳ ＱｕｅｒｙメッセージをＤＮＳサーバ１３へ送信する（Ｓ３１）。

【0064】

以上説明したように、本発明の実施の形態４にかかる名前解決処理の流れを実行することによって、名前解決の応答時間を判断し、プライマリＤＮＳサーバとセカンダリＤＮＳサーバとを入れ替えることができる。これより、応答が早いＤＮＳサーバを常にプライマリＤＮＳサーバとすることができる。また、ＤＮＳサーバ自体の障害とは異なる障害によって応答時間の遅延が発生した場合も、ＨＧＷは、応答時間の早いＤＮＳサーバをプライマリＤＮＳサーバとすることができる。これより、ＨＧＷの内部処理にてＤＮＳサーバの優先度を変更することができるため、ＰＣを使用するユーザは、ＤＮＳサーバの優先度を変更するための特定の操作を行う必要がない。

【0065】

（実施の形態５）
続いて、図８を用いて本発明の実施の形態５にかかる名前解決処理の流れについて説明する。本図においては、プライマリＤＮＳサーバもしくはセカンダリＤＮＳサーバに障害が発生したした場合に、３つめのＤＮＳサーバを用いるために実行する処理を示している。

【0066】

また、本図においては、図４のステップＳ１１〜Ｓ１７が既に実行され、ＨＧＷ１１は、ＤＮＳサーバ１３に障害が発生していることを検出しているとする。

【0067】

ＨＧＷ１１は、ＤＮＳサーバ１３に障害が発生した場合、状態監視部２１３が、ＤＮＳリゾルバ処理部２１２へ、ＤＮＳ Ｑｕｅｒｙメッセージを送信することを指示する。ここで、状態監視部２１３によって送信することを指示されたＤＮＳ Ｑｕｅｒｙメッセージは、レコードタイプとしてＰＴＲ（PoinTeR record）を設定することが指示され、ドメイン名の逆引きを行うために用いられる。また、逆引き対象のアドレスは、セカンダリＤＮＳサーバであるＤＮＳサーバ１４のＩＰアドレスとする。例えば、逆引き対象のＩＰアドレスを192.0.2.2とする。

【0068】

はじめに、ＨＧＷ１１は、レコードタイプにＰＲＴが設定されたＤＮＳ ＱｕｅｒｙメッセージをＤＮＳサーバ１４へ送信する（Ｓ４１）。次に、ＤＮＳサーバ１４は、自装置のＩＰアドレスの逆引きを行うＤＮＳ Ｑｕｅｒｙメッセージを受信すると、ＤＮＳサーバ１４のＦＱＤＮ（Fully Qualified Domain Name）を設定したＤＮＳ ＡｎｓｗｅｒメッセージをＨＧＷ１１へ送信する（Ｓ４２）。ＦＱＤＮは、例えば、secondary.exampleとする。

【0069】

次に、ＨＧＷ１１の状態監視部２１３は、受信したＦＱＤＮであるsecondary.exampleに関して、名前解決を行うことをＤＮＳリゾルバ処理部２１２へ指示する。ＤＮＳリゾルバ処理部２１２は、状態監視部２１３からの指示に応じて、ＤＮＳサーバ１４へ、ＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ４３）。ＤＮＳリゾルバ処理部２１２は、レコードタイプＡ（Address record）及び問い合わせるＦＱＤＮとしてsecondary.exampleを設定したＤＮＳ Ｑｕｅｒｙメッセージを送信する。

【0070】

次に、ＤＮＳサーバ１４は、受信したＤＮＳ Ｑｕｅｒｙメッセージに対して、２つのＩＰアドレスを設定したＤＮＳ Ａｎｓｗｅｒメッセージを送信する（Ｓ４４）。ＤＮＳサーバ１４は、ＤＮＳサーバ１４自体のＩＰアドレスである192.0.2.2と、障害時用のＤＮＳサーバのＩＰアドレスである192.0.2.3をＤＮＳ Ａｎｓｗｅｒメッセージに設定する。

【0071】

状態監視部２１３は、ＤＮＳリゾルバ処理部２１２に対して、192.0.2.2及び192.0.2.3をＤＮＳサーバとして使用するように指示する。

【0072】

以上説明したように、本発明の実施の形態５にかかる名前解決処理の流れを実行することによって、ＨＧＷ１１が名前解決の正引き及び逆引きの仕組みを利用することによって、ＤＮＳサーバの障害検出からＤＮＳサーバの変更までを、ＨＧＷ１１が自動的に実施することができる。これより、ＤＮＳサーバに障害が発生したさいに、ＤＨＣＰ（Dynamic Host Configuration Protocol）オプション等を利用して障害発生用のＨＧＷへＤＮＳサーバアドレスを通知する必要がなくなる。

【0073】

（実施の形態６）
続いて、図９を用いて本発明の実施の形態６にかかる名前解決処理の流れについて説明する。実施の形態１〜５においては、ＤＮＳリゾルバ処理部２１２が、スタブリゾルバを実行する動作について説明した。スタブリゾルバは、フルサービスリゾルバを実行するＤＮＳサーバ等へ、名前解決の要求メッセージを送信し、名前解決の実行をＤＮＳサーバ等へ依頼する処理である。これに対して、フルサービスリゾルバは、ルートサーバ等に対して名前解決処理を行い、ホスト名に対するＩＰアドレスを検出するまで、名前解決処理を繰り返す処理である。

【0074】

図９においては、ＨＧＷ１１がＤＮＳサーバ１３に発生した障害を検出後、ＨＧＷ１１のＤＮＳリゾルバ処理部２１２が、フルサービスリゾルバを実行する動作について説明する。

【0075】

本図においては、図４のステップＳ１１〜Ｓ１７が既に実行され、ＨＧＷ１１は、ＤＮＳサーバ１３に障害が発生していることを検出しているとする。

【0076】

はじめに、ＰＣ１２は、ＨＧＷ１１へＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ５１）。ＤＮＳ Ｑｕｅｒｙメッセージには、ＰＣ１２が通信を行うＷｅｂサーバ１５のホスト名として、abc.exampleが設定されている。

【0077】

次に、ＨＧＷ１１は、ＤＮＳサーバ１３及びＤＮＳサーバ１４等へ、ＤＮＳ Ｑｕｅｒｙメッセージを送信することなく、ルートサーバへＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ５２）。次に、ルートサーバは、exampleドメインを管理するexampleサーバのＩＰアドレスに関する情報をＨＧＷ１１へ送信する（Ｓ５３）。

【0078】

次に、ＨＧＷ１１は、exampleサーバに対して、ホスト名としてabc.exampleを設定したＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ５４）。次に、exampleサーバは、ＨＧＷ１１へabc.exampleドメインを管理するabc.exampleサーバのＩＰアドレスに関する情報を送信する（Ｓ５５）。

【0079】

次に、ＨＧＷ１１は、abc.exampleサーバに対して、ホスト名としてabc.exampleを設定したＤＮＳ Ｑｕｅｒｙメッセージを送信する（Ｓ５６）。次に、abc.exampleサーバは、ホスト名としてabc.exampleサーバに対応付けられたＩＰアドレスに関する情報をＨＧＷ１１へ送信する（Ｓ５７）。ＨＧＷ１１は、abc.exampleサーバから受信したabc.exampleのＩＰアドレスを設定したＤＮＳ ＡｎｓｗｅｒメッセージをＰＣ１２へ送信する（Ｓ５８）。

【0080】

以上説明したように、本発明の実施の形態５にかかる名前解決処理の流れを実行することによって、障害が発生したＤＮＳサーバを経由せずに名前解決を行うことが可能となる。これより、障害発生中のＤＮＳサーバへの問い合わせが行われなくなるため、障害発生中のＤＮＳサーバへの負荷を軽減することが可能となり、障害発生中のＤＮＳサーバの早期復旧が可能となる。

【0081】

上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、ホームゲートウェイにおける処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。）

【0082】

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0083】

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

【符号の説明】

【0084】

１ 通信制御装置
２ 状態監視部
３ 通信部
４ ＤＮＳサーバ
５ ＤＮＳサーバ
１１ ＨＧＷ
１２ ＰＣ
１３ ＤＮＳサーバ
１４ ＤＮＳサーバ
１５ Ｗｅｂサーバ
１６ インターネット網
２１ ＨＧＷ
１１１ ＬＡＮインタフェース
１１２ ＷＡＮインタフェース
２１１ Ｐｒｏｘｙ ＤＮＳ制御部
２１２ ＤＮＳリゾルバ処理部
２１３ 状態監視部
２２４ ＩＣＭＰ処理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】