リソースレコード制御システム、リソースレコード制御方法、アプリケーション判別方法およびプログラム
【課題】ＩＰｖ６に未対応のアプリケーションプログラムが内在するデュアルスタック端末を調べたり、このような端末に対して適切なリソースレコードでＤＮＳ応答が可能なシステム、方法およびプログラムを得ること。
【解決手段】デュアルスタック端末１１がＤＮＳサーバ１２に対して名前解決要求を行うと、ゲートウェイ１３はＤＮＳサーバ１２の応答したリソースコードをリソースレコード制御ポリシテーブル１３ｃの参照によって制限する形でデュアルスタック端末１１に返答する。これによりデュアルスタック端末１１の適切な通信が確保される。ゲートウェイ１３はデュアルスタック端末１１がフォールバック事象を発生させているかも判別する。
【解決手段】デュアルスタック端末１１がＤＮＳサーバ１２に対して名前解決要求を行うと、ゲートウェイ１３はＤＮＳサーバ１２の応答したリソースコードをリソースレコード制御ポリシテーブル１３ｃの参照によって制限する形でデュアルスタック端末１１に返答する。これによりデュアルスタック端末１１の適切な通信が確保される。ゲートウェイ１３はデュアルスタック端末１１がフォールバック事象を発生させているかも判別する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末がインターネットプロトコルを用いて通信を開始する際に相手装置と通信不能となる状態を回避するようにしたリソースレコード制御システム、リソースレコード制御方法およびリソースレコード制御プログラムならびに端末装置のアプリケーション判別方法およびアプリケーション判別プログラムに関する。
【背景技術】
【０００２】
インターネットプロトコルとしてのＩＰｖ４（Internet Protocol version 4）プロトコルとＩＰｖ６（Internet Protocol version 6）プロトコルの双方を実装したパーソナルコンピュータや情報家電等のデュアルスタック端末が数多く存在している。このような端末のＯＳ（Operating System）におけるＤＮＳリゾルバ（Domain Name System resolver）は、名前からアドレスを割り出す際にＤＮＳサーバに対してＡリソースレコードとＡＡＡＡリソースレコードを問合せることが一般的である。
【０００３】
ここでＡリソースレコードは完全修飾ドメイン名に対するＩＰｖ４アドレスを指定するＤＮＳレコードである。また、ＡＡＡＡリソースレコードは、１２８ビット長のＩＰｖ６アドレスをサポートする点で、Ａリソースレコードと異なる。
【０００４】
ＡリソースレコードとＡＡＡＡリソースレコードの問合せに対してＤＮＳサーバからこれら両方の応答が得られた場合、その端末はＡＡＡＡリソースレコードを自身の稼働中のアプリケーションプログラムに優先して応答するのが通常である。ところが、その端末の稼働中のアプリケーションプログラムがＩＰｖ６に対応していないという場合がある。この場合には、そのアプリケーションプログラムが、名前解決を行った相手装置と通信を開始しようとしてもＡＡＡＡリソースレコードを解釈することができない。この結果、通信を開始することができずにアプリケーションプログラムが使用不可能となる問題が発生する。
【０００５】
また、このような問題発生を回避するために通信端末によってはＩＰｖ４への通信にフォールバック（fallback）して通信を試みるようにしている。しかしながら、この手法を採用するためには、まずＩＰｖ６による通信ができないことをタイムアウトになるまで待って確認する必要がある。このため、ＩＰｖ４による通信が開始するまでにタイムアウト待ちによる通信遅延が発生するという問題が生じる。
【０００６】
そこで、本発明に関連する関連技術として、ＩＰｖ４アドレスからＩＰｖ６アドレス、またはＩＰｖ６アドレスからＩＰｖ４アドレスへの変換を行うトランスレータ装置をネットワーク上に設けることが提案されている（たとえば特許文献１参照）。この関連技術で、ＩＰｖ４−ＩＰｖ６トランスレータ装置は通信端末（ユーザ端末）から所定のＦＱＤＮ（Fully Qualified Domain Name：完全修飾ドメイン名）に対するＩＰｖ６アドレス解決の問合せを受け、ＤＮＳサーバに当該ＦＱＤＮのＩＰｖ４アドレスとＩＰｖ６アドレスの名前解決について問合せを行う。
【０００７】
名前解決の結果、ＩＰｖ６アドレスとＩＰｖ４アドレスが取得できた場合に、取得したＩＰｖ６アドレスと併せて、予め設定されたダミープレフィックスに当該ＩＰｖ４アドレスを埋め込んだダミーＩＰｖ６アドレスを通信端末側に返答する。そして、通信端末と通信相手との間の通信に使用するアドレスとしてＩＰｖ４アドレス、あるいは、ＩＰｖ６アドレスのいずれを優先するか判断する。この結果、通信端末と通信相手との間の通信に使用するアドレスとしてＩＰｖ４アドレスを優先する場合にはグローバルＩＰｖ６アドレスを、また、ＩＰｖ６アドレスを優先する場合はユニークローカルＩＰｖ６ユニキャストアドレスを、ダミープレフィックスとして使用する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−２０６５６２号公報（第０００５段落、第００２１段落、図１）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
この関連技術によれば、通信端末がＩＰｖ４アドレスとＩＰｖ６アドレスの両方に対応したデュアルスタックホストと通信を行う際に、ＩＰｖ４アドレスでの通信を優先するか、あるいは、ＩＰｖ６アドレスでの通信を優先するかを、ＩＰｖ４−ＩＰｖ６トランスレータにおいて制卸が可能である。したがって、ＩＰｖ４−ＩＰｖ６トランスレータ装置の負荷を軽減し、かつ、通信の冗長性を保つことが可能となる。
【００１０】
しかしながら、この関連技術では、ＤＮＳサーバの他にＩＰｖ４−ＩＰｖ６トランスレータ装置という特別の装置をネットワーク上に必要とする。また、通信端末はＩＰｖ４−ＩＰｖ６トランスレータ装置からＩＰｖ６に関する２種類のアドレスを受け取り、ロンゲストマッチ方式でこれらのうちの１つを選択する処理が必要となる。このため、通信端末側の処理も複雑化する。
【００１１】
また、デュアルスタック端末であっても、通信相手との関係で適用されるアプリケーションプログラムがＩＰｖ６に対応していない場合がある。このような場合、前記した関連技術では、通信端末のアプリケーションプログラム側でＡＡＡＡリソースレコードを取り扱うことができないという問題を解決することができない。
【００１２】
そこで本発明の目的は、ＩＰｖ６に対応していないアプリケーションプログラムが内在する端末に対して、ＤＮＳサーバがＤＮＳ応答に際して適切なリソースレコードで応答することのできるリソースレコード制御システム、方法およびプログラムを提供することにある。
【００１３】
本発明の他の目的は、端末側のアプリケーションプログラムがＩＰｖ６に対応しているかどうかを判別することのできるアプリケーション判別方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
本発明では、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末と、（ロ）所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答するＤＮＳ（Domain Name System）サーバと、（ハ）前記したデュアルスタック端末から名前解決要求が送られてきたときこれを受信して前記したＤＮＳサーバに送信する名前解決要求送信手段と、この名前解決要求送信手段の送信した名前解決要求に対して前記したＤＮＳサーバから返答として送られてくるリソースレコードを受信するリソースレコード受信手段と、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルと、前記したリソースレコード受信手段の受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブルを参照し前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答手段とを備えたゲートウェイとをリソースレコード制御システムが具備する。
【００１５】
また、本発明では、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、（ロ）この名前解決要求送信ステップで送信した名前解決要求の返答として前記したＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信ステップと、（ハ）このリソースレコード受信ステップで受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答ステップとをリソースレコード制御方法が具備する。
【００１６】
更に本発明では、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、（ロ）この名前解決要求送信ステップで送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信ステップと、（ハ）このＤＮＳ応答返信ステップで返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別ステップと、（ニ）この通信有無判別ステップで前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別ステップと、（ホ）前記した通信有無判別ステップで前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別ステップと、（へ）このフォールバック事象発生有無判別ステップでフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別ステップとをアプリケーション判別方法が具備する。
【００１７】
更にまた本発明では、ゲートウェイのコンピュータに、リソースレコード制御プログラムとして、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、（ロ）この名前解決要求送信処理で送信した名前解決要求の返答としてＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信処理と、（ハ）このリソースレコード受信処理で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答処理とを実行させることを特徴としている。
【００１８】
また、本発明では、ゲートウェイのコンピュータに、アプリケーション判別プログラムとして、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、（ロ）この名前解決要求送信処理で送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信処理と、（ハ）このＤＮＳ応答返信処理で返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別処理と、（ニ）この通信有無判別処理で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別処理と、（ホ）前記した通信有無判別処理で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別処理と、（へ）このフォールバック事象発生有無判別処理でフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別処理とを実行させることを特徴としている。
【発明の効果】
【００１９】
以上説明したように本発明によれば、ＩＰｖ４プロトコルスタックとＩＰｖ６プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたとき、これを受信したゲートウェイがリソースレコード制御ポリシテーブルを参照して、ＤＮＳサーバの応答結果を必要により限定してデュアルスタック端末に返答することにした。これにより、該当するデュアルスタック端末にＩＰｖ６に対応していないアプリケーションが内在していた場合でも、適切なリソースレコードを応答することで通信不能となる状態を回避することが可能になる。
【００２０】
また、本発明によれば、デュアルスタック端末がＩＰｖ６からＩＰｖ４へのフォールバック事象を発生させることで、見かけ上、ＩＰｖ６プロトコルに対応する場合であっても、ゲートウェイ側がフォールバック事象の発生の有無を判別することにした。これにより、デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していないと判別される場合には、ＩＰｖ４通信の対象となる通信相手の選択が可能になる。
【図面の簡単な説明】
【００２１】
【図１】本発明のリソースレコード制御システムのクレーム対応図である。
【図２】本発明のリソースレコード制御方法のクレーム対応図である。
【図３】本発明のアプリケーション判別方法のクレーム対応図である。
【図４】本発明のリソースレコード制御プログラムのクレーム対応図である。
【図５】本発明のアプリケーション判別プログラムのクレーム対応図である。
【図６】本発明の実施の形態のＤＮＳにおけるリソースレコード制御システムの構成を表わしたシステム構成図である。
【図７】本実施の形態におけるゲートウェイの原理的な構成を表わしたブロック図である。
【図８】本実施の形態のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示した説明図である。
【図９】本実施の形態におけるＲＲ制御ポリシテーブルの一例を表わした説明図である。
【図１０】本発明の第１の変形例におけるＲＲ制御ポリシテーブルの構成を表わした説明図である。
【図１１】第１の変形例のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示した説明図である。
【図１２】本発明の第２の変形例におけるゲートウェイで行われるＲＲ制御ポリシテーブルについての登録処理の様子を表わした流れ図である。
【図１３】第２の変形例で使用されるＩＰｖ６通信不能検出テーブルの一例を示した説明図である。
【発明を実施するための形態】
【００２２】
図１は、本発明のリソースレコード制御システムのクレーム対応図を示したものである。本発明のリソースレコード制御システム１０は、デュアルスタック端末１１と、ＤＮＳ（Domain Name System）サーバ１２と、ゲートウェイ１３を備えている。ここで、デュアルスタック端末１１は、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載した端末である。ＤＮＳ（Domain Name System）サーバ１２は、所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答する。ゲートウェイ１３は、名前解決要求送信手段１３ａと、リソースレコード受信手段１３ｂと、リソースレコード制御ポリシテーブル１３ｃと、ＤＮＳ応答手段１３ｄを備えている。ここで名前解決要求送信手段１３ａは、デュアルスタック端末１１から名前解決要求が送られてきたときこれを受信してＤＮＳサーバ１２に送信する。リソースレコード受信手段１３ｂは、名前解決要求送信手段１３ａの送信した名前解決要求に対してＤＮＳサーバ１２から返答として送られてくるリソースレコードを受信する。リソースレコード制御ポリシテーブル１３ｃは、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたテーブルである。ＤＮＳ応答手段１３ｄは、リソースレコード受信手段１３ｂの受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブル１３ｃを参照し前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行う。
【００２３】
図２は、本発明のリソースレコード制御方法のクレーム対応図を示したものである。本発明のリソースレコード制御方法２０は、名前解決要求送信ステップ２１と、リソースレコード受信ステップ２２と、ＤＮＳ応答ステップ２３を備えている。ここで、名前解決要求送信ステップ２１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する。リソースレコード受信ステップ２２では、名前解決要求送信ステップ２１で送信した名前解決要求の返答として前記したＤＮＳサーバから送られてくるリソースレコードを受信する。ＤＮＳ応答ステップ２３では、リソースレコード受信ステップ２２で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行う。
【００２４】
図３は、本発明のアプリケーション判別方法のクレーム対応図を示したものである。本発明のアプリケーション判別方法３０は、名前解決要求送信ステップ３１と、ＤＮＳ応答返信ステップ３２と、通信有無判別ステップ３３と、未対応プログラム存在判別ステップ３４と、フォールバック事象発生有無判別ステップ３５と、対応プログラム存在判別ステップ３６を備えている。ここで、名前解決要求送信ステップ３１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する。ＤＮＳ応答返信ステップ３２では、名前解決要求送信ステップ３１で送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信する。通信有無判別ステップ３３では、ＤＮＳ応答返信ステップ３２で返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する。未対応プログラム存在判別ステップ３４では、通信有無判別ステップ３３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する。フォールバック事象発生有無判別ステップ３５では、通信有無判別ステップ３３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別する。対応プログラム存在判別ステップ３６では、フォールバック事象発生有無判別ステップ３５でフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する。
【００２５】
図４は、本発明のリソースレコード制御プログラムのクレーム対応図を示したものである。本発明のリソースレコード制御プログラム４０は、ゲートウェイのコンピュータに、名前解決要求送信処理４１と、リソースレコード受信処理４２と、ＤＮＳ応答処理４３を実行させるようにしている。ここで、名前解決要求送信処理４１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する。リソースレコード受信処理４２では、名前解決要求送信処理４１で送信した名前解決要求の返答として前記したＤＮＳサーバから送られてくるリソースレコードを受信する。ＤＮＳ応答処理４３では、リソースレコード受信処理４２で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行う。
【００２６】
図５は、本発明のアプリケーション判別プログラムのクレーム対応図を示したものである。本発明のアプリケーション判別プログラム５０は、ゲートウェイのコンピュータに、名前解決要求送信処理５１と、ＤＮＳ応答返信処理５２と、通信有無判別処理５３と、未対応プログラム存在判別処理５４と、フォールバック事象発生有無判別処理５５と、対応プログラム存在判別処理５６を実行させるようにしている。ここで、名前解決要求送信処理５１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する。ＤＮＳ応答返信処理５２では、名前解決要求送信処理５１で送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信する。通信有無判別処理５３では、ＤＮＳ応答返信処理５２で返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する。未対応プログラム存在判別処理５４では、通信有無判別処理５３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する。フォールバック事象発生有無判別処理５５では、通信有無判別処理５３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別する。対応プログラム存在判別処理５６では、フォールバック事象発生有無判別処理５５でフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する。
【００２７】
＜発明の実施の形態＞
【００２８】
次に本発明の実施の形態を説明する。
【００２９】
図６は、本発明の実施の形態によるＤＮＳにおけるリソースレコード制御システムの構成を表わしたものである。このリソースレコード制御システム１００は、インターネット１０１にゲートウェイ１０２を介して接続されたローカルネットワーク上の第１および第２の端末１０４、１０５によって構成されている。インターネット１０１上には、ＩＰｖ６（Internet Protocol version 6）用の第１のＷＷＷ（World Wide Web）サーバ１０６と、ＩＰｖ４（Internet Protocol version 4）用の第２のＷＷＷサーバ１０７と、ＤＮＳ（Domain Name System）サーバ１０８が配置されている。
【００３０】
第１の端末１０４および第２の端末１０５は、ＩＰｖ４プロトコルスタックとＩＰｖ６プロトコルスタックの両方を搭載した、いわゆるデュアルスタック端末である。これら第１および第２の端末１０４および１０５は、たとえばＷＷＷ（World Wide Web）サーバへのアクセスを行うパーソナルコンピュータや情報家電として実現される。
【００３１】
ゲートウェイ１０２は、ローカルネットワーク環境に設置されており、異なるインタフェース間でパケット転送処理を行うルータやファイアウォール（FireWall）で構成されている。
【００３２】
図７は、ゲートウェイの原理的な構成を表わしたものである。図６と共に説明する。ゲートウェイ１０２は、ＤＮＳリゾルバ１１１、ＤＮＳキャッシュテーブル１１２、ＤＮＳサーバモジュール１１３、ＲＲ（Resource Record：リソースレコード）制御ポリシテーブル１１４、およびＩＰｖ６通信不能検出テーブル１１５およびＩＰｖ６通信不能検出モジュール１１７の各構成要素を備えている。
【００３３】
ここでＤＮＳリゾルバ１１１は、ＤＮＳサーバモジュール１１３またはＩＰｖ６通信不能検出モジュール１１７からの名前解決要求に応じて、図６に示したＤＮＳサーバ１０８に対して正引き処理（ドメイン名に対するＩＰアドレス応答）や逆引き処理（ＩＰアドレスに対するドメイン名応答）等の処理を行う機能を有する。また、ＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２を参照して、過去に名前解決した情報が保持されている場合にはＤＮＳサーバ１０８に問合せを行わず、ＤＮＳキャッシュテーブル１１２に保持されている情報を応答する。
【００３４】
ＤＮＳキャッシュテーブル１１２は、ＦＱＤＮ（完全修飾ドメイン名）というドメイン名情報と、ＲＲ（Resource Record：リソースレコード）タイプと、ＩＰアドレス等の実データ、ＴＴＬ（Time To Live：キャッシュ保持時間）の情報要素を保持するテーブルである。ＤＮＳキャッシュテーブル１１２は、ＤＮＳリゾルバ１１１が使用する。
【００３５】
ＤＮＳサーバモジュール１１３は、第１および第２の端末１０４、１０５からの名前解決要求を受け付け、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。また、ＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１から得られた応答結果に対して、ポリシ（policy）を実現するために用意したＲＲ制御ポリシテーブル１１４を参照する。そして、当該ＦＱＤＮに該当するレコードが存在する場合、ＤＮＳサーバモジュール１１３はそのポリシに応じて、リソースレコードを制御して応答を行う。
【００３６】
ＲＲ制御ポリシテーブル１１４は、完全修飾ドメイン名（ＦＱＤＮ）、許可ＲＲ、禁止ＲＲ、送信元ＭＡＣアドレス、送信元ＩＰｖ４アドレス、送信元ＩＰｖ６アドレスの各情報要素を保持するテーブルである。ＲＲ制御ポリシテーブル１１４は、ＤＮＳサーバモジュール１１３またはＩＰｖ６通信不能検出モジュール１１７で使用される。
【００３７】
ＩＰｖ６通信不能検出モジュール１１７は、第１および第２の端末１０４、１０５からの名前解決要求に対して、仮想のＡＡＡＡリソースレコードを応答する。これにより、ＩＰｖ６未対応アプリケーションの検出およびＩＰｖ６からＩＰｖ４へのフォールバック事象の検出を行い、検出結果をＲＲ制御ポリシテーブル１１４に登録する。
【００３８】
ＩＰｖ６通信不能検出テーブル１１５は、完全修飾ドメイン名（ＦＱＤＮ）、ＡＡＡＡリソースレコードの有無（ＡＡＡＡ有無）、仮想ＡＡＡＡリソースレコード（仮想ＡＡＡＡ ＲＲ）、送信元ＩＰｖ４アドレス、送信元ＩＰｖ６アドレスの情報要素を保持するテーブルである。ＩＰｖ６通信不能検出テーブル１１５は、ＩＰｖ６通信不能検出モジュール１１７で使用される。
【００３９】
ゲートウェイ１０２自体は図示しないがＣＰＵ（Central Processing Unit）や、ＣＰＵが実行するプログラムを格納した記憶媒体（メモリ）を備えている。したがって、図７に示したＤＮＳリゾルバ１１１等の各機能部品は、ハードウェアで構成してもよいが、ＣＰＵがプログラムを実行することでソフトウェア的に実現させることも可能である。
【００４０】
一方、インターネット１０１上に配置されたＤＮＳサーバ１０８は、第１および第２の端末１０４、１０５やゲートウェイ１０２からの名前解決要求に応じて、正引き処理や逆引き処理等の処理を行うサーバである。また、第１のＷＷＷサーバ１０６はＩＰｖ６プロトコルスタックを搭載しており、ＩＰｖ６によるＷＷＷサービスの提供を行う。第２のＷＷＷサーバ１０７はＩＰｖ４プロトコルスタックを搭載しており、ＩＰｖ４によるＷＷＷサービスの提供を行う。
【００４１】
図８は、以上のような構成のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示したものである。ここでは、ＩＰｖ６通信を抑制する動作シーケンスでの動作を示す。図６および図７と共に説明する。
【００４２】
ローカルネットワーク１０３上の通信端末である第１または第２の端末１０４、１０５が、ドメイン名に対するＩＰアドレスを調べるためにゲートウェイ１０２に対してＤＮＳ問合せとして、名前解決の要求を行ったとする（ステップＳ２０１）。ここではドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」に対するＩＰアドレスを調べるものとする。
【００４３】
ゲートウェイ１０２内のＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。ＤＮＳリゾルバ１１１はこの依頼を受けて、ＤＮＳサーバ１０８に対してドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」に対する名前解決の要求を行う（ステップＳ２０２）。
【００４４】
ＤＮＳサーバ１０８は、ＤＮＳ応答としてＡおよびＡＡＡＡリソースレコードをゲートウェイ１０２に応答する（ステップＳ２０３）。ゲートウェイ１０２内のＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２に結果を記録すると共に、ＤＮＳサーバモジュール１１３に結果を返す。
【００４５】
ＤＮＳサーバモジュール１１３は、この結果を基にしてＲＲ制御ポリシテーブル１１４を参照する。そして、ポリシに応じて、リソースレコードを制御して（ステップＳ２０４）、応答する（ステップＳ２０５）。
【００４６】
図９は、ＲＲ制御ポリシテーブルの一例を表わしたものである。ＲＲ制御ポリシテーブル１１４には、完全修飾ドメイン名（ＦＱＤＮ）のそれぞれに対して、使用を許可する許可リソースレコード（ＲＲ）と、使用を禁止する禁止リソースレコード（ＲＲ）が設定できるようになっている。今回のリソースレコード制御の対象となるドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」については、Ａリソースレコードが許可リソースレコードとして設定されている。Ａリソースレコードの「Ａ」は「Address」の略語である。
【００４７】
本実施の形態で例示したＲＲ制御ポリシテーブル１１４には、完全修飾ドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」についての許可リソースレコードにＡＡＡＡリソースレコードを設定していない。
【００４８】
このようにＲＲ制御ポリシテーブル１１４には、完全修飾ドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」についての許可リソースレコードとしてＡリソースレコードのみを設定している。このため、ＤＮＳサーバモジュール１１３はＡリソースレコードのみを第１および第２の端末１０４、１０５に応答するための処理を行う（図９ステップＳ２０４）。ゲートウェイ１０２は第１および第２の端末１０４、１０５にＡリソースレコードを結果としてＤＮＳ応答する（ステップＳ２０５）。
【００４９】
第１および第２の端末１０４、１０５は、得られた結果がＡリソースレコードであるため、ＩＰｖ４プロトコルを用いて、ＩＰｖ４用の第２のＷＷＷサーバ１０７に対してＨＴＴＰ（Hypertext Transfer Protocol）接続要求を行う（ステップＳ２０６）。そして、ＩＰｖ４用の第２のＷＷＷサーバ１０７からＨＴＴＰ応答を得ることで（ステップＳ２０７）、第２のＷＷＷサーバ１０７との通信が行われることになる。
【００５０】
なお、図９に示したＲＲ制御ポリシテーブル１１４の中には、「−（ハイフン）」で示した箇所がある。ＤＮＳ応答で使用されるリソースレコード（ＲＲ）は、このＲＲ制御ポリシテーブル１１４内で示したＡリソースレコード、ＡＡＡＡリソースレコードおよびＰＴＲ（PoinTeR）リソースレコード以外にも多くの種類がある。そこで図９では、該当する完全修飾ドメイン名（ＦＱＤＮ）で表示しているリソースレコード以外を総括的に「−」で示している。
【００５１】
たとえば、完全修飾ドメイン名が「abc.example.jp」の欄では、許可リソースレコード（ＲＲ）がＡリソースレコードとＰＴＲリソースレコードになっている。したがって、禁止リソースレコード（ＲＲ）における「−」は、ＡＡＡＡリソースレコードを含み、ＡリソースレコードとＰＴＲリソースレコードを除外した残りすべてのリソースレコードを意味していることになる。
【００５２】
以上のように本実施の形態では、ＤＮＳサーバ１０８の名前解決によって得られたＡリソースレコードとＡＡＡＡリソースレコードのうちのＡＡＡＡリソースレコードを、ＩＰｖ４用の第２のＷＷＷサーバ１０７で問題を引き起こす可能性があるとするポリシの下でゲートウェイ１０２内のＤＮＳサーバモジュール１１３が排除した。このような本実施の形態のＤＮＳにおけるリソースレコード制御システム１００では、ＩＰｖ６通信を抑制する動作シーケンスの存在によって、問題の発生を回避することが可能になる。
【００５３】
＜発明の第１の変形例＞
【００５４】
以上説明した実施の形態では、ローカルネットワーク内に複数の端末が存在している場合におけるこれらの端末のアプリケーションプログラムに共通のリソースレコードを設定するシステムを説明した。これとは異なり、ローカルネットワーク内に複数の通信端末が存在する場合には、これらの通信端末ごとにアプリケーションプログラムとの関係で適切なリソースレコードを返すようになっていてもよい。
【００５５】
図１０は、本発明の第１の変形例におけるＲＲ制御ポリシテーブルの構成を表わしたものである。この変形例のＲＲ制御ポリシテーブル１１４Ａは、図９に示した先の実施の形態のＲＲ制御ポリシテーブル１１４と比べて、送信元ＭＡＣアドレスと、送信元ＩＰｖ４とＩＰｖ６のアドレスが新たな項目として追加されている。これは、送信側の通信端末のアプリケーションプログラムがＩＰｖ６に対応できるか等の状況を加味して、より適切なサーバ等の相手方通信装置の選択を可能にするためである。ＲＲ制御ポリシテーブル１１４Ａには事前に登録された送信元端末ごとのポリシが登録されているため、同一の完全修飾ドメイン名（ＦＱＤＮ）に対する名前解決であっても、信元端末ごとに異なる応答を返すことが可能になる。
【００５６】
図１１は、この第１の変形例のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示したものである。図６、図７および図１０と共に説明する。
【００５７】
まず、時刻ｔ1に第１の端末１０４が、ドメイン名に対するＩＰアドレスを調べるためにゲートウェイ１０２に対してＤＮＳ問合せとして、名前解決の要求を行ったとする（ステップＳ２２１）。ここではドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対するＩＰアドレスを調べるものとする。
【００５８】
ゲートウェイ１０２内のＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。ＤＮＳリゾルバ１１１はこの依頼を受けて、ＤＮＳサーバ１０８に対してドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対する名前解決の要求を行う（ステップＳ２２２）。
【００５９】
ＤＮＳサーバ１０８は、ＤＮＳ応答としてＡおよびＡＡＡＡリソースレコードをゲートウェイ１０２に応答する（ステップＳ２２３）。ゲートウェイ１０２内のＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２に結果を記録すると共に、ＤＮＳサーバモジュール１１３に結果を返す。
【００６０】
ＤＮＳサーバモジュール１１３は、この結果を基にしてＲＲ制御ポリシテーブル１１４を参照する。そして、ポリシに応じて、リソースレコードを制御して（ステップＳ２２４）、応答する（ステップＳ２２５）。具体的には、図１０の「送信元ＩＰｖ４アドレス」が「１９２．１６８．１．１」の通信端末が第１の端末１０４であるとして、完全修飾ドメイン名（ＦＱＤＮ）が「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対する禁止ＲＲのＡＡＡＡリソースレコードが適用される。この結果、ゲートウェイ１０２ＡからのＤＮＳ応答は、ＡＡＡＡリソースレコードを排除してＡリソースレコードとなる（ステップＳ２２５）。
【００６１】
第１の端末１０４は、得られた結果がＡリソースレコードであるため、ＩＰｖ４プロトコルを用いて、ＩＰｖ４用の第２のＷＷＷサーバ１０７に対してＨＴＴＰ接続要求を行う（ステップＳ２２６）。そして、ＩＰｖ４用の第２のＷＷＷサーバ１０７からＨＴＴＰ応答を得ることで（ステップＳ２２７）、第２のＷＷＷサーバ１０７との通信が行われることになる。
【００６２】
次に、時刻ｔ2に第２の端末１０５が、ドメイン名に対するＩＰアドレスを調べるためにゲートウェイ１０２に対して名前解決の要求を行ったとする（ステップＳ２４１）。ここでもドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対するＩＰアドレスを調べるものとする。
【００６３】
ゲートウェイ１０２内のＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。ＤＮＳリゾルバ１１１はこの依頼を受けて、ＤＮＳサーバ１０８に対してドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対する名前解決の要求を行う（ステップＳ２４２）。
【００６４】
ＤＮＳサーバ１０８は、ＤＮＳ応答としてＡおよびＡＡＡＡリソースレコードをゲートウェイ１０２に応答する（ステップＳ２４３）。ゲートウェイ１０２内のＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２に結果を記録すると共に、ＤＮＳサーバモジュール１１３に結果を返す。
【００６５】
ＤＮＳサーバモジュール１１３は、この結果を基にしてＲＲ制御ポリシテーブル１１４を参照する。そして、ポリシに応じて、リソースレコードを制御して（ステップＳ２４４）、応答する（ステップＳ２４５）。具体的には、図１０の「送信元ＩＰｖ４アドレス」が「１９２．１６８．１．２」の通信端末が第２の端末１０５であるとして、完全修飾ドメイン名（ＦＱＤＮ）が「ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」に対する許可ＲＲのＡリソースレコード、ＡＡＡＡリソースレコードおよびＰＴＲ（PoinTeR）レコードが適用される。ＰＴＲレコードは、ＩＰアドレスからホスト名への変換のためのレコードである。この結果、ゲートウェイ１０２ＡからのＤＮＳ応答は、ＡリソースレコードおよびＡＡＡＡリソースレコードとなる（ステップＳ２４５）。
【００６６】
第２の端末１０５は、得られた結果がＡリソースレコードおよびＡＡＡＡリソースレコードであるため、ＩＰｖ６プロトコルを用いて、ＩＰｖ６用の第１のＷＷＷサーバ１０６に対してＨＴＴＰ接続要求を行う（ステップＳ２４６）。そして、ＩＰｖ６用の第１のＷＷＷサーバ１０６からＨＴＴＰ応答を得ることで（ステップＳ２４７）、第１のＷＷＷサーバ１０６との通信が行われることになる。
【００６７】
このように本発明の第１の変形例によれば、第２の端末１０５は、先の実施の形態と異なりＩＰｖ６用の第１のＷＷＷサーバ１０６との通信が可能である。
【００６８】
＜発明の第２の変形例＞
【００６９】
以上説明した実施の形態および第１の変形例では、ＲＲ制御ポリシテーブル１１４、１１４Ａをシステム側が予め用意する必要があった。本発明の第２の変形例では、ＩＰｖ６未対応アプリケーションの検出およびＴＣＰフォールバック事象の検出を行って、検出結果をＲＲ制御ポリシテーブルに自動的に登録できるようにした。
【００７０】
図１２は、ゲートウェイで行われるＲＲ制御ポリシテーブルについての登録処理の様子を表わしたものである。図６および図７と共に説明する。
【００７１】
ゲートウェイ１０２の前記したＣＰＵは第１あるいは第２の端末１０４、１０５から、ドメイン名に対するＩＰアドレスを調べるために名前解決の要求が行われるのを待機している（ステップＳ２６１）。このＤＮＳに対する問合わせがあると（Ｙ）、ゲートウェイ１０２ではＩＰｖ６通信不能検出モジュール１１７がＤＮＳリゾルバ１１１に対して名前解決の処理を依頼し、ＤＮＳリゾルバ１１１は、ＤＮＳサーバ１０８に対して名前解決の要求（問合わせ）を行う（ステップＳ２６２）。
【００７２】
これに対してＤＮＳサーバ１０８からＤＮＳが受信されると（ステップＳ２６３：Ｙ）、ゲートウェイ１０２が仮想ＡＡＡＡ応答処理を実行する（ステップＳ２６４）。具体的には、ゲートウェイ１０２内のＤＮＳリゾルバ１１１が、ＤＮＳキャッシュテーブル１１２にＤＮＳサーバ１０８から得られた結果を記録する。この後、ＩＰｖ６通信不能検出モジュール１１７に結果が返される。
【００７３】
ＩＰｖ６通信不能検出モジュール１１７は、ＤＮＳ応答にＡＡＡＡリソースレコードが含まれているか否かをＩＰｖ６通信不能検出テーブル１１５に記録すると共に、仮想ＡＡＡＡリソースレコード（ＲＲ）（仮想のＩＰｖ６アドレス）を、問合わせを行った第１あるいは第２の端末１０４、１０５に応答（ＤＮＳ応答）する（ステップＳ２６５）。
【００７４】
図１３は、この第２の変形例で使用されるＩＰｖ６通信不能検出テーブルの一例を示したものである。ＩＰｖ６通信不能検出テーブル１１５の「ＡＡＡＡ有無」の欄には、ＤＮＳ応答にＡＡＡＡリソースレコードが含まれているか否かを「あり」または「なし」で記録するようになっている。また、「仮想ＡＡＡＡリソースレコード（ＲＲ）」欄には、完全修飾ドメイン名（ＦＱＤＮ）に対応した仮想ＡＡＡＡリソースレコードが予め記載されている。
【００７５】
図１２のステップＳ２６５の処理が行われた後、ＩＰｖ６通信不能検出モジュール１１７は、名前解決の要求を行った第１あるいは第２の端末１０４、１０５が仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを確認する（ステップＳ２６６）。この確認は、予め定めた時間ｔ1以内に仮想ＡＡＡＡリソースレコード宛の通信が開始したかによってチェックされる（ステップＳ２６６：Ｎ、ステップＳ２６７）。
【００７６】
名前解決の要求が仮に第１の端末１０４によって行われたとする。第１の端末１０４のアプリケーションプログラムはＩＰｖ４には対応する。しかしながらこれらのアプリケーションプログラムの中には、ＩＰｖ６に未対応のものが存在している。したがってＩＰｖ６に未対応のアプリケーションプログラムが稼働した場合、仮想ＡＡＡＡリソースレコード宛の通信が開始することはない。一方、名前解決の要求が第２の端末１０５によって行われた場合には、ＩＰｖ６に対応するアプリケーションプログラムが稼働することで、仮想ＡＡＡＡリソースレコード宛の通信が時間ｔ1以内に行われようとする可能性が高い。
【００７７】
そこで、時間ｔ1以内に仮想ＡＡＡＡリソースレコード宛の通信がなければ（ステップＳ２２６：Ｎ、ステップＳ２６７：Ｙ）、ＩＰｖ６通信不能検出モジュール１１７は該当する端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する。この場合、ＩＰｖ６通信不能検出モジュール１１７は、ＲＲ制御ポリシテーブル１１４の該当する完全修飾ドメイン名（ＦＱＤＮ）にＡＡＡＡリソースレコードを禁止リソースレコード（ＲＲ）として登録する（ステップＳ２６８）。この後、処理はステップＳ２６１に戻る（リターン）。
【００７８】
ところで、時間ｔ1以内に仮想ＡＡＡＡリソースレコード宛の通信があった場合には（ステップＳ２６６：Ｙ）、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを確認する必要がある。そこで、この場合、ＩＰｖ６通信不能検出モジュール１１７は、名前解決の要求を行った第１あるいは第２の端末１０４、１０５が通信に使用した同じプロトコルと同じポート番号を使用して、名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能かを確認する（ステップＳ２６９）。この通信が不可能な場合には（Ｎ）、前記したフォールバック事象が発生していると判断して、ＲＲ制御ポリシテーブル１１４の該当する完全修飾ドメイン名（ＦＱＤＮ）にＡＡＡＡリソースレコードを禁止リソースレコード（ＲＲ）として登録する（ステップＳ２６８）。この後、処理はステップＳ２６１に戻る（リターン）。
【００７９】
この例の場合、ステップＳ２６９で名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能であった場合（Ｙ）、特に許可ＲＲとして登録を行うことなく、処理はステップＳ２６１に戻る（リターン）。処理内容によっては、名前解決の要求を行った端末について許可リソースレコード（ＲＲ）の登録を行うようにしてもよい。
【００８０】
このように本発明の第２の変形例によれば、ゲートウェイにＤＮＳサーバモジュール１１３、ＲＲ制御ポリシテーブル１１４、ＩＰｖ６通信不能検出テーブル１１５およびＩＰｖ６通信不能検出モジュール１１７を有することにした。これにより、端末のアプリケーションプログラムを入れ換えたりしたような場合にも、システムの管理者に負担を掛けずにＲＲ制御ポリシテーブル１１４の変更が可能になるという利点が生じる。
【００８１】
なお、以上説明した実施の形態および変形例では、ローカルネットワーク上の端末（デュアルスタック端末）１０４、１０５が名前解決要求を行った場合を説明したが、ローカルネットワーク上の端末からの名前解決要求に限定されるものでないことはもちろんである。
【００８２】
また、端末（デュアルスタック端末）１０４、１０５からＤＮＳサーバ１０８に送られるＤＮＳ問合わせを受信するゲートウェイは、ネットワーク間の中継装置という広義の意味で使用しており、ルータ等の他の名称のものもＤＮＳ問合わせを中継する機能を備えていれば本発明が適用されることは当然である。
【００８３】
以上説明した実施の形態の一部または全部は、以下の付記のようにも記載されるが、以下の記載に限定されるものではない。
【００８４】
（付記１）
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末と、
所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答するＤＮＳ（Domain Name System）サーバと、
前記デュアルスタック端末から名前解決要求が送られてきたときこれを受信して前記ＤＮＳサーバに送信する名前解決要求送信手段と、この名前解決要求送信手段の送信した名前解決要求に対して前記ＤＮＳサーバから返答として送られてくるリソースレコードを受信するリソースレコード受信手段と、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルと、前記リソースレコード受信手段の受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブルを参照し前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答手段とを備えたゲートウェイ
とを具備することを特徴とするリソースレコード制御システム。
【００８５】
（付記２）
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末および通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードを個別に設定していることを特徴とする付記１記載のリソースレコード制御システム。
【００８６】
（付記３）
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末が前記通信相手と通信する際に稼働するアプリケーションプログラムがＩＰｖ６で不適合である場合を前提としたＩＰｖ６通信を抑制するポリシで作成された内容であることを特徴とする付記１または付記２記載のリソースレコード制御システム。
【００８７】
（付記４）
前記リソースレコード制御ポリシテーブルには、通信を許可する許可リソースレコードあるいは通信を禁止する禁止リソースレコードが通信相手のドメイン名としての完全修飾ドメイン名（ＦＱＤＮ：Fully Qualified Domain Name）に対応付けて記載されていることを特徴とする付記２記載のリソースレコード制御システム。
【００８８】
（付記５）
前記ゲートウェイは、前記デュアルスタック端末からのすべての名前解決要求に対して仮想のＡＡＡＡリソースレコードを応答する仮想のＡＡＡＡリソースレコード応答手段と、この仮想のＡＡＡＡリソースレコードに対して前記デュアルスタック端末がＩＰｖ６通信を行うか否かを判別するＩＰｖ６通信可否判別手段と、このＩＰｖ６通信可否判別手段がＩＰｖ６通信を可能と判別したとき前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別するアプリケーション対応判別手段とを具備することを特徴とする付記１記載のリソースレコード制御システム。
【００８９】
（付記６）
前記リソースレコード制御ポリシテーブルには、前記アプリケーション対応判別手段によって前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別したものに対してフォールバック事象が発生している場合を除き、ＩＰｖ６通信を許可する許可リソースレコードが記載されることを特徴とする付記５記載のリソースレコード制御システム。
【００９０】
（付記７）
前記リソースレコード制御ポリシテーブルには、前記アプリケーション対応可否判別手段によって前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していないと判別したものに対してＩＰｖ６通信を禁止する禁止リソースレコードが記載されることを特徴とする付記５記載のリソースレコード制御システム。
【００９１】
（付記８）
前記ゲートウェイは、名前解決の要求を行った前記デュアルスタック端末が通信に使用した同じプロトコルと同じポート番号を使用して、名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能か否かを判別する同一プロトコル・同一ポート番号通信判別手段と、この同一プロトコル・同一ポート番号通信判別手段で所定時間内に仮想ＡＡＡＡリソースレコード宛の通信が可能でないと判別されたときフォールバック事象が発生したものと判別するフォールバック事象判別手段を具備することを特徴とする付記５記載のリソースレコード制御システム。
【００９２】
（付記９）
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信ステップと、
このリソースレコード受信ステップで受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答ステップ
とを具備することを特徴とするリソースレコード制御方法。
【００９３】
（付記１０）
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信ステップと、
このＤＮＳ応答返信ステップで返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別ステップと、
この通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別ステップと、
前記通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別ステップと、
このフォールバック事象発生有無判別ステップでフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別ステップ
とを具備することを特徴とするアプリケーション判別方法。
【００９４】
（付記１１）
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信処理と、
このリソースレコード受信処理で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答処理
とを実行させることを特徴とするリソースレコード制御プログラム。
【００９５】
（付記１２）
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信処理と、
このＤＮＳ応答返信処理で返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別処理と、
この通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別処理と、
前記通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別処理と、
このフォールバック事象発生有無判別処理でフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別処理
とを実行させることを特徴とするアプリケーション判別プログラム。
【符号の説明】
【００９６】
１０、１００ リソースレコード制御システム
１１ デュアルスタック端末
１２ ＤＮＳサーバ
１３、１０２ ゲートウェイ
１３ａ 名前解決要求送信手段
１３ｂ リソースレコード受信手段
１３ｃ リソースレコード制御ポリシテーブル
１３ｄ ＤＮＳ応答手段
２０ リソースレコード制御方法
２１、３１ 名前解決要求送信ステップ
２２ リソースレコード受信ステップ
２３ ＤＮＳ応答ステップ
３０ アプリケーション判別方法
３２ ＤＮＳ応答返信ステップ
３３ 通信有無判別ステップ
３４ 未対応プログラム存在判別ステップ
３５ フォールバック事象発生有無判別ステップ
３６ 対応プログラム存在判別ステップ
４０ リソースレコード制御プログラム
４１、５１ 名前解決要求送信処理
４２ リソースレコード受信処理
４３ ＤＮＳ応答処理
５０ アプリケーション判別プログラム
５２ ＤＮＳ応答返信処理
５３ 通信有無判別処理
５４ 未対応プログラム存在判別処理
５５ フォールバック事象発生有無判別処理
５６ 対応プログラム存在判別処理
１０１ インターネット
１０３ ローカルネットワーク
１０４ 第１の端末
１０５ 第２の端末
１０６ 第１のＷＷＷサーバ
１０７ 第２のＷＷＷサーバ
１１１ ＤＮＳリゾルバ
１１２ ＤＮＳキャッシュテーブル
１１３ ＤＮＳサーバモジュール
１１４、１１４Ａ ＲＲ制御ポリシテーブル
１１５ ＩＰｖ６通信不能検出テーブル
１１７ ＩＰｖ６通信不能検出モジュール
【技術分野】
【０００１】
本発明は、通信端末がインターネットプロトコルを用いて通信を開始する際に相手装置と通信不能となる状態を回避するようにしたリソースレコード制御システム、リソースレコード制御方法およびリソースレコード制御プログラムならびに端末装置のアプリケーション判別方法およびアプリケーション判別プログラムに関する。
【背景技術】
【０００２】
インターネットプロトコルとしてのＩＰｖ４（Internet Protocol version 4）プロトコルとＩＰｖ６（Internet Protocol version 6）プロトコルの双方を実装したパーソナルコンピュータや情報家電等のデュアルスタック端末が数多く存在している。このような端末のＯＳ（Operating System）におけるＤＮＳリゾルバ（Domain Name System resolver）は、名前からアドレスを割り出す際にＤＮＳサーバに対してＡリソースレコードとＡＡＡＡリソースレコードを問合せることが一般的である。
【０００３】
ここでＡリソースレコードは完全修飾ドメイン名に対するＩＰｖ４アドレスを指定するＤＮＳレコードである。また、ＡＡＡＡリソースレコードは、１２８ビット長のＩＰｖ６アドレスをサポートする点で、Ａリソースレコードと異なる。
【０００４】
ＡリソースレコードとＡＡＡＡリソースレコードの問合せに対してＤＮＳサーバからこれら両方の応答が得られた場合、その端末はＡＡＡＡリソースレコードを自身の稼働中のアプリケーションプログラムに優先して応答するのが通常である。ところが、その端末の稼働中のアプリケーションプログラムがＩＰｖ６に対応していないという場合がある。この場合には、そのアプリケーションプログラムが、名前解決を行った相手装置と通信を開始しようとしてもＡＡＡＡリソースレコードを解釈することができない。この結果、通信を開始することができずにアプリケーションプログラムが使用不可能となる問題が発生する。
【０００５】
また、このような問題発生を回避するために通信端末によってはＩＰｖ４への通信にフォールバック（fallback）して通信を試みるようにしている。しかしながら、この手法を採用するためには、まずＩＰｖ６による通信ができないことをタイムアウトになるまで待って確認する必要がある。このため、ＩＰｖ４による通信が開始するまでにタイムアウト待ちによる通信遅延が発生するという問題が生じる。
【０００６】
そこで、本発明に関連する関連技術として、ＩＰｖ４アドレスからＩＰｖ６アドレス、またはＩＰｖ６アドレスからＩＰｖ４アドレスへの変換を行うトランスレータ装置をネットワーク上に設けることが提案されている（たとえば特許文献１参照）。この関連技術で、ＩＰｖ４−ＩＰｖ６トランスレータ装置は通信端末（ユーザ端末）から所定のＦＱＤＮ（Fully Qualified Domain Name：完全修飾ドメイン名）に対するＩＰｖ６アドレス解決の問合せを受け、ＤＮＳサーバに当該ＦＱＤＮのＩＰｖ４アドレスとＩＰｖ６アドレスの名前解決について問合せを行う。
【０００７】
名前解決の結果、ＩＰｖ６アドレスとＩＰｖ４アドレスが取得できた場合に、取得したＩＰｖ６アドレスと併せて、予め設定されたダミープレフィックスに当該ＩＰｖ４アドレスを埋め込んだダミーＩＰｖ６アドレスを通信端末側に返答する。そして、通信端末と通信相手との間の通信に使用するアドレスとしてＩＰｖ４アドレス、あるいは、ＩＰｖ６アドレスのいずれを優先するか判断する。この結果、通信端末と通信相手との間の通信に使用するアドレスとしてＩＰｖ４アドレスを優先する場合にはグローバルＩＰｖ６アドレスを、また、ＩＰｖ６アドレスを優先する場合はユニークローカルＩＰｖ６ユニキャストアドレスを、ダミープレフィックスとして使用する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−２０６５６２号公報（第０００５段落、第００２１段落、図１）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
この関連技術によれば、通信端末がＩＰｖ４アドレスとＩＰｖ６アドレスの両方に対応したデュアルスタックホストと通信を行う際に、ＩＰｖ４アドレスでの通信を優先するか、あるいは、ＩＰｖ６アドレスでの通信を優先するかを、ＩＰｖ４−ＩＰｖ６トランスレータにおいて制卸が可能である。したがって、ＩＰｖ４−ＩＰｖ６トランスレータ装置の負荷を軽減し、かつ、通信の冗長性を保つことが可能となる。
【００１０】
しかしながら、この関連技術では、ＤＮＳサーバの他にＩＰｖ４−ＩＰｖ６トランスレータ装置という特別の装置をネットワーク上に必要とする。また、通信端末はＩＰｖ４−ＩＰｖ６トランスレータ装置からＩＰｖ６に関する２種類のアドレスを受け取り、ロンゲストマッチ方式でこれらのうちの１つを選択する処理が必要となる。このため、通信端末側の処理も複雑化する。
【００１１】
また、デュアルスタック端末であっても、通信相手との関係で適用されるアプリケーションプログラムがＩＰｖ６に対応していない場合がある。このような場合、前記した関連技術では、通信端末のアプリケーションプログラム側でＡＡＡＡリソースレコードを取り扱うことができないという問題を解決することができない。
【００１２】
そこで本発明の目的は、ＩＰｖ６に対応していないアプリケーションプログラムが内在する端末に対して、ＤＮＳサーバがＤＮＳ応答に際して適切なリソースレコードで応答することのできるリソースレコード制御システム、方法およびプログラムを提供することにある。
【００１３】
本発明の他の目的は、端末側のアプリケーションプログラムがＩＰｖ６に対応しているかどうかを判別することのできるアプリケーション判別方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
本発明では、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末と、（ロ）所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答するＤＮＳ（Domain Name System）サーバと、（ハ）前記したデュアルスタック端末から名前解決要求が送られてきたときこれを受信して前記したＤＮＳサーバに送信する名前解決要求送信手段と、この名前解決要求送信手段の送信した名前解決要求に対して前記したＤＮＳサーバから返答として送られてくるリソースレコードを受信するリソースレコード受信手段と、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルと、前記したリソースレコード受信手段の受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブルを参照し前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答手段とを備えたゲートウェイとをリソースレコード制御システムが具備する。
【００１５】
また、本発明では、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、（ロ）この名前解決要求送信ステップで送信した名前解決要求の返答として前記したＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信ステップと、（ハ）このリソースレコード受信ステップで受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答ステップとをリソースレコード制御方法が具備する。
【００１６】
更に本発明では、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、（ロ）この名前解決要求送信ステップで送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信ステップと、（ハ）このＤＮＳ応答返信ステップで返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別ステップと、（ニ）この通信有無判別ステップで前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別ステップと、（ホ）前記した通信有無判別ステップで前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別ステップと、（へ）このフォールバック事象発生有無判別ステップでフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別ステップとをアプリケーション判別方法が具備する。
【００１７】
更にまた本発明では、ゲートウェイのコンピュータに、リソースレコード制御プログラムとして、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、（ロ）この名前解決要求送信処理で送信した名前解決要求の返答としてＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信処理と、（ハ）このリソースレコード受信処理で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答処理とを実行させることを特徴としている。
【００１８】
また、本発明では、ゲートウェイのコンピュータに、アプリケーション判別プログラムとして、（イ）ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、（ロ）この名前解決要求送信処理で送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信処理と、（ハ）このＤＮＳ応答返信処理で返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別処理と、（ニ）この通信有無判別処理で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別処理と、（ホ）前記した通信有無判別処理で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別処理と、（へ）このフォールバック事象発生有無判別処理でフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別処理とを実行させることを特徴としている。
【発明の効果】
【００１９】
以上説明したように本発明によれば、ＩＰｖ４プロトコルスタックとＩＰｖ６プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたとき、これを受信したゲートウェイがリソースレコード制御ポリシテーブルを参照して、ＤＮＳサーバの応答結果を必要により限定してデュアルスタック端末に返答することにした。これにより、該当するデュアルスタック端末にＩＰｖ６に対応していないアプリケーションが内在していた場合でも、適切なリソースレコードを応答することで通信不能となる状態を回避することが可能になる。
【００２０】
また、本発明によれば、デュアルスタック端末がＩＰｖ６からＩＰｖ４へのフォールバック事象を発生させることで、見かけ上、ＩＰｖ６プロトコルに対応する場合であっても、ゲートウェイ側がフォールバック事象の発生の有無を判別することにした。これにより、デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していないと判別される場合には、ＩＰｖ４通信の対象となる通信相手の選択が可能になる。
【図面の簡単な説明】
【００２１】
【図１】本発明のリソースレコード制御システムのクレーム対応図である。
【図２】本発明のリソースレコード制御方法のクレーム対応図である。
【図３】本発明のアプリケーション判別方法のクレーム対応図である。
【図４】本発明のリソースレコード制御プログラムのクレーム対応図である。
【図５】本発明のアプリケーション判別プログラムのクレーム対応図である。
【図６】本発明の実施の形態のＤＮＳにおけるリソースレコード制御システムの構成を表わしたシステム構成図である。
【図７】本実施の形態におけるゲートウェイの原理的な構成を表わしたブロック図である。
【図８】本実施の形態のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示した説明図である。
【図９】本実施の形態におけるＲＲ制御ポリシテーブルの一例を表わした説明図である。
【図１０】本発明の第１の変形例におけるＲＲ制御ポリシテーブルの構成を表わした説明図である。
【図１１】第１の変形例のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示した説明図である。
【図１２】本発明の第２の変形例におけるゲートウェイで行われるＲＲ制御ポリシテーブルについての登録処理の様子を表わした流れ図である。
【図１３】第２の変形例で使用されるＩＰｖ６通信不能検出テーブルの一例を示した説明図である。
【発明を実施するための形態】
【００２２】
図１は、本発明のリソースレコード制御システムのクレーム対応図を示したものである。本発明のリソースレコード制御システム１０は、デュアルスタック端末１１と、ＤＮＳ（Domain Name System）サーバ１２と、ゲートウェイ１３を備えている。ここで、デュアルスタック端末１１は、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載した端末である。ＤＮＳ（Domain Name System）サーバ１２は、所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答する。ゲートウェイ１３は、名前解決要求送信手段１３ａと、リソースレコード受信手段１３ｂと、リソースレコード制御ポリシテーブル１３ｃと、ＤＮＳ応答手段１３ｄを備えている。ここで名前解決要求送信手段１３ａは、デュアルスタック端末１１から名前解決要求が送られてきたときこれを受信してＤＮＳサーバ１２に送信する。リソースレコード受信手段１３ｂは、名前解決要求送信手段１３ａの送信した名前解決要求に対してＤＮＳサーバ１２から返答として送られてくるリソースレコードを受信する。リソースレコード制御ポリシテーブル１３ｃは、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたテーブルである。ＤＮＳ応答手段１３ｄは、リソースレコード受信手段１３ｂの受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブル１３ｃを参照し前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行う。
【００２３】
図２は、本発明のリソースレコード制御方法のクレーム対応図を示したものである。本発明のリソースレコード制御方法２０は、名前解決要求送信ステップ２１と、リソースレコード受信ステップ２２と、ＤＮＳ応答ステップ２３を備えている。ここで、名前解決要求送信ステップ２１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する。リソースレコード受信ステップ２２では、名前解決要求送信ステップ２１で送信した名前解決要求の返答として前記したＤＮＳサーバから送られてくるリソースレコードを受信する。ＤＮＳ応答ステップ２３では、リソースレコード受信ステップ２２で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行う。
【００２４】
図３は、本発明のアプリケーション判別方法のクレーム対応図を示したものである。本発明のアプリケーション判別方法３０は、名前解決要求送信ステップ３１と、ＤＮＳ応答返信ステップ３２と、通信有無判別ステップ３３と、未対応プログラム存在判別ステップ３４と、フォールバック事象発生有無判別ステップ３５と、対応プログラム存在判別ステップ３６を備えている。ここで、名前解決要求送信ステップ３１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する。ＤＮＳ応答返信ステップ３２では、名前解決要求送信ステップ３１で送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信する。通信有無判別ステップ３３では、ＤＮＳ応答返信ステップ３２で返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する。未対応プログラム存在判別ステップ３４では、通信有無判別ステップ３３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する。フォールバック事象発生有無判別ステップ３５では、通信有無判別ステップ３３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別する。対応プログラム存在判別ステップ３６では、フォールバック事象発生有無判別ステップ３５でフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する。
【００２５】
図４は、本発明のリソースレコード制御プログラムのクレーム対応図を示したものである。本発明のリソースレコード制御プログラム４０は、ゲートウェイのコンピュータに、名前解決要求送信処理４１と、リソースレコード受信処理４２と、ＤＮＳ応答処理４３を実行させるようにしている。ここで、名前解決要求送信処理４１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する。リソースレコード受信処理４２では、名前解決要求送信処理４１で送信した名前解決要求の返答として前記したＤＮＳサーバから送られてくるリソースレコードを受信する。ＤＮＳ応答処理４３では、リソースレコード受信処理４２で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記した名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行う。
【００２６】
図５は、本発明のアプリケーション判別プログラムのクレーム対応図を示したものである。本発明のアプリケーション判別プログラム５０は、ゲートウェイのコンピュータに、名前解決要求送信処理５１と、ＤＮＳ応答返信処理５２と、通信有無判別処理５３と、未対応プログラム存在判別処理５４と、フォールバック事象発生有無判別処理５５と、対応プログラム存在判別処理５６を実行させるようにしている。ここで、名前解決要求送信処理５１では、ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する。ＤＮＳ応答返信処理５２では、名前解決要求送信処理５１で送信した名前解決要求に対して前記したＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記したデュアルスタック端末にＤＮＳ応答として返信する。通信有無判別処理５３では、ＤＮＳ応答返信処理５２で返信した前記したデュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する。未対応プログラム存在判別処理５４では、通信有無判別処理５３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記したデュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する。フォールバック事象発生有無判別処理５５では、通信有無判別処理５３で前記した所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別する。対応プログラム存在判別処理５６では、フォールバック事象発生有無判別処理５５でフォールバック事象が発生していないと判別されたとき前記したデュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する。
【００２７】
＜発明の実施の形態＞
【００２８】
次に本発明の実施の形態を説明する。
【００２９】
図６は、本発明の実施の形態によるＤＮＳにおけるリソースレコード制御システムの構成を表わしたものである。このリソースレコード制御システム１００は、インターネット１０１にゲートウェイ１０２を介して接続されたローカルネットワーク上の第１および第２の端末１０４、１０５によって構成されている。インターネット１０１上には、ＩＰｖ６（Internet Protocol version 6）用の第１のＷＷＷ（World Wide Web）サーバ１０６と、ＩＰｖ４（Internet Protocol version 4）用の第２のＷＷＷサーバ１０７と、ＤＮＳ（Domain Name System）サーバ１０８が配置されている。
【００３０】
第１の端末１０４および第２の端末１０５は、ＩＰｖ４プロトコルスタックとＩＰｖ６プロトコルスタックの両方を搭載した、いわゆるデュアルスタック端末である。これら第１および第２の端末１０４および１０５は、たとえばＷＷＷ（World Wide Web）サーバへのアクセスを行うパーソナルコンピュータや情報家電として実現される。
【００３１】
ゲートウェイ１０２は、ローカルネットワーク環境に設置されており、異なるインタフェース間でパケット転送処理を行うルータやファイアウォール（FireWall）で構成されている。
【００３２】
図７は、ゲートウェイの原理的な構成を表わしたものである。図６と共に説明する。ゲートウェイ１０２は、ＤＮＳリゾルバ１１１、ＤＮＳキャッシュテーブル１１２、ＤＮＳサーバモジュール１１３、ＲＲ（Resource Record：リソースレコード）制御ポリシテーブル１１４、およびＩＰｖ６通信不能検出テーブル１１５およびＩＰｖ６通信不能検出モジュール１１７の各構成要素を備えている。
【００３３】
ここでＤＮＳリゾルバ１１１は、ＤＮＳサーバモジュール１１３またはＩＰｖ６通信不能検出モジュール１１７からの名前解決要求に応じて、図６に示したＤＮＳサーバ１０８に対して正引き処理（ドメイン名に対するＩＰアドレス応答）や逆引き処理（ＩＰアドレスに対するドメイン名応答）等の処理を行う機能を有する。また、ＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２を参照して、過去に名前解決した情報が保持されている場合にはＤＮＳサーバ１０８に問合せを行わず、ＤＮＳキャッシュテーブル１１２に保持されている情報を応答する。
【００３４】
ＤＮＳキャッシュテーブル１１２は、ＦＱＤＮ（完全修飾ドメイン名）というドメイン名情報と、ＲＲ（Resource Record：リソースレコード）タイプと、ＩＰアドレス等の実データ、ＴＴＬ（Time To Live：キャッシュ保持時間）の情報要素を保持するテーブルである。ＤＮＳキャッシュテーブル１１２は、ＤＮＳリゾルバ１１１が使用する。
【００３５】
ＤＮＳサーバモジュール１１３は、第１および第２の端末１０４、１０５からの名前解決要求を受け付け、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。また、ＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１から得られた応答結果に対して、ポリシ（policy）を実現するために用意したＲＲ制御ポリシテーブル１１４を参照する。そして、当該ＦＱＤＮに該当するレコードが存在する場合、ＤＮＳサーバモジュール１１３はそのポリシに応じて、リソースレコードを制御して応答を行う。
【００３６】
ＲＲ制御ポリシテーブル１１４は、完全修飾ドメイン名（ＦＱＤＮ）、許可ＲＲ、禁止ＲＲ、送信元ＭＡＣアドレス、送信元ＩＰｖ４アドレス、送信元ＩＰｖ６アドレスの各情報要素を保持するテーブルである。ＲＲ制御ポリシテーブル１１４は、ＤＮＳサーバモジュール１１３またはＩＰｖ６通信不能検出モジュール１１７で使用される。
【００３７】
ＩＰｖ６通信不能検出モジュール１１７は、第１および第２の端末１０４、１０５からの名前解決要求に対して、仮想のＡＡＡＡリソースレコードを応答する。これにより、ＩＰｖ６未対応アプリケーションの検出およびＩＰｖ６からＩＰｖ４へのフォールバック事象の検出を行い、検出結果をＲＲ制御ポリシテーブル１１４に登録する。
【００３８】
ＩＰｖ６通信不能検出テーブル１１５は、完全修飾ドメイン名（ＦＱＤＮ）、ＡＡＡＡリソースレコードの有無（ＡＡＡＡ有無）、仮想ＡＡＡＡリソースレコード（仮想ＡＡＡＡ ＲＲ）、送信元ＩＰｖ４アドレス、送信元ＩＰｖ６アドレスの情報要素を保持するテーブルである。ＩＰｖ６通信不能検出テーブル１１５は、ＩＰｖ６通信不能検出モジュール１１７で使用される。
【００３９】
ゲートウェイ１０２自体は図示しないがＣＰＵ（Central Processing Unit）や、ＣＰＵが実行するプログラムを格納した記憶媒体（メモリ）を備えている。したがって、図７に示したＤＮＳリゾルバ１１１等の各機能部品は、ハードウェアで構成してもよいが、ＣＰＵがプログラムを実行することでソフトウェア的に実現させることも可能である。
【００４０】
一方、インターネット１０１上に配置されたＤＮＳサーバ１０８は、第１および第２の端末１０４、１０５やゲートウェイ１０２からの名前解決要求に応じて、正引き処理や逆引き処理等の処理を行うサーバである。また、第１のＷＷＷサーバ１０６はＩＰｖ６プロトコルスタックを搭載しており、ＩＰｖ６によるＷＷＷサービスの提供を行う。第２のＷＷＷサーバ１０７はＩＰｖ４プロトコルスタックを搭載しており、ＩＰｖ４によるＷＷＷサービスの提供を行う。
【００４１】
図８は、以上のような構成のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示したものである。ここでは、ＩＰｖ６通信を抑制する動作シーケンスでの動作を示す。図６および図７と共に説明する。
【００４２】
ローカルネットワーク１０３上の通信端末である第１または第２の端末１０４、１０５が、ドメイン名に対するＩＰアドレスを調べるためにゲートウェイ１０２に対してＤＮＳ問合せとして、名前解決の要求を行ったとする（ステップＳ２０１）。ここではドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」に対するＩＰアドレスを調べるものとする。
【００４３】
ゲートウェイ１０２内のＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。ＤＮＳリゾルバ１１１はこの依頼を受けて、ＤＮＳサーバ１０８に対してドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」に対する名前解決の要求を行う（ステップＳ２０２）。
【００４４】
ＤＮＳサーバ１０８は、ＤＮＳ応答としてＡおよびＡＡＡＡリソースレコードをゲートウェイ１０２に応答する（ステップＳ２０３）。ゲートウェイ１０２内のＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２に結果を記録すると共に、ＤＮＳサーバモジュール１１３に結果を返す。
【００４５】
ＤＮＳサーバモジュール１１３は、この結果を基にしてＲＲ制御ポリシテーブル１１４を参照する。そして、ポリシに応じて、リソースレコードを制御して（ステップＳ２０４）、応答する（ステップＳ２０５）。
【００４６】
図９は、ＲＲ制御ポリシテーブルの一例を表わしたものである。ＲＲ制御ポリシテーブル１１４には、完全修飾ドメイン名（ＦＱＤＮ）のそれぞれに対して、使用を許可する許可リソースレコード（ＲＲ）と、使用を禁止する禁止リソースレコード（ＲＲ）が設定できるようになっている。今回のリソースレコード制御の対象となるドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」については、Ａリソースレコードが許可リソースレコードとして設定されている。Ａリソースレコードの「Ａ」は「Address」の略語である。
【００４７】
本実施の形態で例示したＲＲ制御ポリシテーブル１１４には、完全修飾ドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」についての許可リソースレコードにＡＡＡＡリソースレコードを設定していない。
【００４８】
このようにＲＲ制御ポリシテーブル１１４には、完全修飾ドメイン名「ｗｗｗ．ｇｈｉ．ｅｘａｍｐｌｅ．ｊｐ」についての許可リソースレコードとしてＡリソースレコードのみを設定している。このため、ＤＮＳサーバモジュール１１３はＡリソースレコードのみを第１および第２の端末１０４、１０５に応答するための処理を行う（図９ステップＳ２０４）。ゲートウェイ１０２は第１および第２の端末１０４、１０５にＡリソースレコードを結果としてＤＮＳ応答する（ステップＳ２０５）。
【００４９】
第１および第２の端末１０４、１０５は、得られた結果がＡリソースレコードであるため、ＩＰｖ４プロトコルを用いて、ＩＰｖ４用の第２のＷＷＷサーバ１０７に対してＨＴＴＰ（Hypertext Transfer Protocol）接続要求を行う（ステップＳ２０６）。そして、ＩＰｖ４用の第２のＷＷＷサーバ１０７からＨＴＴＰ応答を得ることで（ステップＳ２０７）、第２のＷＷＷサーバ１０７との通信が行われることになる。
【００５０】
なお、図９に示したＲＲ制御ポリシテーブル１１４の中には、「−（ハイフン）」で示した箇所がある。ＤＮＳ応答で使用されるリソースレコード（ＲＲ）は、このＲＲ制御ポリシテーブル１１４内で示したＡリソースレコード、ＡＡＡＡリソースレコードおよびＰＴＲ（PoinTeR）リソースレコード以外にも多くの種類がある。そこで図９では、該当する完全修飾ドメイン名（ＦＱＤＮ）で表示しているリソースレコード以外を総括的に「−」で示している。
【００５１】
たとえば、完全修飾ドメイン名が「abc.example.jp」の欄では、許可リソースレコード（ＲＲ）がＡリソースレコードとＰＴＲリソースレコードになっている。したがって、禁止リソースレコード（ＲＲ）における「−」は、ＡＡＡＡリソースレコードを含み、ＡリソースレコードとＰＴＲリソースレコードを除外した残りすべてのリソースレコードを意味していることになる。
【００５２】
以上のように本実施の形態では、ＤＮＳサーバ１０８の名前解決によって得られたＡリソースレコードとＡＡＡＡリソースレコードのうちのＡＡＡＡリソースレコードを、ＩＰｖ４用の第２のＷＷＷサーバ１０７で問題を引き起こす可能性があるとするポリシの下でゲートウェイ１０２内のＤＮＳサーバモジュール１１３が排除した。このような本実施の形態のＤＮＳにおけるリソースレコード制御システム１００では、ＩＰｖ６通信を抑制する動作シーケンスの存在によって、問題の発生を回避することが可能になる。
【００５３】
＜発明の第１の変形例＞
【００５４】
以上説明した実施の形態では、ローカルネットワーク内に複数の端末が存在している場合におけるこれらの端末のアプリケーションプログラムに共通のリソースレコードを設定するシステムを説明した。これとは異なり、ローカルネットワーク内に複数の通信端末が存在する場合には、これらの通信端末ごとにアプリケーションプログラムとの関係で適切なリソースレコードを返すようになっていてもよい。
【００５５】
図１０は、本発明の第１の変形例におけるＲＲ制御ポリシテーブルの構成を表わしたものである。この変形例のＲＲ制御ポリシテーブル１１４Ａは、図９に示した先の実施の形態のＲＲ制御ポリシテーブル１１４と比べて、送信元ＭＡＣアドレスと、送信元ＩＰｖ４とＩＰｖ６のアドレスが新たな項目として追加されている。これは、送信側の通信端末のアプリケーションプログラムがＩＰｖ６に対応できるか等の状況を加味して、より適切なサーバ等の相手方通信装置の選択を可能にするためである。ＲＲ制御ポリシテーブル１１４Ａには事前に登録された送信元端末ごとのポリシが登録されているため、同一の完全修飾ドメイン名（ＦＱＤＮ）に対する名前解決であっても、信元端末ごとに異なる応答を返すことが可能になる。
【００５６】
図１１は、この第１の変形例のリソースレコード制御システムでＤＮＳにおけるリソースレコード制御の様子を示したものである。図６、図７および図１０と共に説明する。
【００５７】
まず、時刻ｔ1に第１の端末１０４が、ドメイン名に対するＩＰアドレスを調べるためにゲートウェイ１０２に対してＤＮＳ問合せとして、名前解決の要求を行ったとする（ステップＳ２２１）。ここではドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対するＩＰアドレスを調べるものとする。
【００５８】
ゲートウェイ１０２内のＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。ＤＮＳリゾルバ１１１はこの依頼を受けて、ＤＮＳサーバ１０８に対してドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対する名前解決の要求を行う（ステップＳ２２２）。
【００５９】
ＤＮＳサーバ１０８は、ＤＮＳ応答としてＡおよびＡＡＡＡリソースレコードをゲートウェイ１０２に応答する（ステップＳ２２３）。ゲートウェイ１０２内のＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２に結果を記録すると共に、ＤＮＳサーバモジュール１１３に結果を返す。
【００６０】
ＤＮＳサーバモジュール１１３は、この結果を基にしてＲＲ制御ポリシテーブル１１４を参照する。そして、ポリシに応じて、リソースレコードを制御して（ステップＳ２２４）、応答する（ステップＳ２２５）。具体的には、図１０の「送信元ＩＰｖ４アドレス」が「１９２．１６８．１．１」の通信端末が第１の端末１０４であるとして、完全修飾ドメイン名（ＦＱＤＮ）が「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対する禁止ＲＲのＡＡＡＡリソースレコードが適用される。この結果、ゲートウェイ１０２ＡからのＤＮＳ応答は、ＡＡＡＡリソースレコードを排除してＡリソースレコードとなる（ステップＳ２２５）。
【００６１】
第１の端末１０４は、得られた結果がＡリソースレコードであるため、ＩＰｖ４プロトコルを用いて、ＩＰｖ４用の第２のＷＷＷサーバ１０７に対してＨＴＴＰ接続要求を行う（ステップＳ２２６）。そして、ＩＰｖ４用の第２のＷＷＷサーバ１０７からＨＴＴＰ応答を得ることで（ステップＳ２２７）、第２のＷＷＷサーバ１０７との通信が行われることになる。
【００６２】
次に、時刻ｔ2に第２の端末１０５が、ドメイン名に対するＩＰアドレスを調べるためにゲートウェイ１０２に対して名前解決の要求を行ったとする（ステップＳ２４１）。ここでもドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対するＩＰアドレスを調べるものとする。
【００６３】
ゲートウェイ１０２内のＤＮＳサーバモジュール１１３は、ＤＮＳリゾルバ１１１に対して名前解決の処理を依頼する。ＤＮＳリゾルバ１１１はこの依頼を受けて、ＤＮＳサーバ１０８に対してドメイン名「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に対する名前解決の要求を行う（ステップＳ２４２）。
【００６４】
ＤＮＳサーバ１０８は、ＤＮＳ応答としてＡおよびＡＡＡＡリソースレコードをゲートウェイ１０２に応答する（ステップＳ２４３）。ゲートウェイ１０２内のＤＮＳリゾルバ１１１は、ＤＮＳキャッシュテーブル１１２に結果を記録すると共に、ＤＮＳサーバモジュール１１３に結果を返す。
【００６５】
ＤＮＳサーバモジュール１１３は、この結果を基にしてＲＲ制御ポリシテーブル１１４を参照する。そして、ポリシに応じて、リソースレコードを制御して（ステップＳ２４４）、応答する（ステップＳ２４５）。具体的には、図１０の「送信元ＩＰｖ４アドレス」が「１９２．１６８．１．２」の通信端末が第２の端末１０５であるとして、完全修飾ドメイン名（ＦＱＤＮ）が「ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」に対する許可ＲＲのＡリソースレコード、ＡＡＡＡリソースレコードおよびＰＴＲ（PoinTeR）レコードが適用される。ＰＴＲレコードは、ＩＰアドレスからホスト名への変換のためのレコードである。この結果、ゲートウェイ１０２ＡからのＤＮＳ応答は、ＡリソースレコードおよびＡＡＡＡリソースレコードとなる（ステップＳ２４５）。
【００６６】
第２の端末１０５は、得られた結果がＡリソースレコードおよびＡＡＡＡリソースレコードであるため、ＩＰｖ６プロトコルを用いて、ＩＰｖ６用の第１のＷＷＷサーバ１０６に対してＨＴＴＰ接続要求を行う（ステップＳ２４６）。そして、ＩＰｖ６用の第１のＷＷＷサーバ１０６からＨＴＴＰ応答を得ることで（ステップＳ２４７）、第１のＷＷＷサーバ１０６との通信が行われることになる。
【００６７】
このように本発明の第１の変形例によれば、第２の端末１０５は、先の実施の形態と異なりＩＰｖ６用の第１のＷＷＷサーバ１０６との通信が可能である。
【００６８】
＜発明の第２の変形例＞
【００６９】
以上説明した実施の形態および第１の変形例では、ＲＲ制御ポリシテーブル１１４、１１４Ａをシステム側が予め用意する必要があった。本発明の第２の変形例では、ＩＰｖ６未対応アプリケーションの検出およびＴＣＰフォールバック事象の検出を行って、検出結果をＲＲ制御ポリシテーブルに自動的に登録できるようにした。
【００７０】
図１２は、ゲートウェイで行われるＲＲ制御ポリシテーブルについての登録処理の様子を表わしたものである。図６および図７と共に説明する。
【００７１】
ゲートウェイ１０２の前記したＣＰＵは第１あるいは第２の端末１０４、１０５から、ドメイン名に対するＩＰアドレスを調べるために名前解決の要求が行われるのを待機している（ステップＳ２６１）。このＤＮＳに対する問合わせがあると（Ｙ）、ゲートウェイ１０２ではＩＰｖ６通信不能検出モジュール１１７がＤＮＳリゾルバ１１１に対して名前解決の処理を依頼し、ＤＮＳリゾルバ１１１は、ＤＮＳサーバ１０８に対して名前解決の要求（問合わせ）を行う（ステップＳ２６２）。
【００７２】
これに対してＤＮＳサーバ１０８からＤＮＳが受信されると（ステップＳ２６３：Ｙ）、ゲートウェイ１０２が仮想ＡＡＡＡ応答処理を実行する（ステップＳ２６４）。具体的には、ゲートウェイ１０２内のＤＮＳリゾルバ１１１が、ＤＮＳキャッシュテーブル１１２にＤＮＳサーバ１０８から得られた結果を記録する。この後、ＩＰｖ６通信不能検出モジュール１１７に結果が返される。
【００７３】
ＩＰｖ６通信不能検出モジュール１１７は、ＤＮＳ応答にＡＡＡＡリソースレコードが含まれているか否かをＩＰｖ６通信不能検出テーブル１１５に記録すると共に、仮想ＡＡＡＡリソースレコード（ＲＲ）（仮想のＩＰｖ６アドレス）を、問合わせを行った第１あるいは第２の端末１０４、１０５に応答（ＤＮＳ応答）する（ステップＳ２６５）。
【００７４】
図１３は、この第２の変形例で使用されるＩＰｖ６通信不能検出テーブルの一例を示したものである。ＩＰｖ６通信不能検出テーブル１１５の「ＡＡＡＡ有無」の欄には、ＤＮＳ応答にＡＡＡＡリソースレコードが含まれているか否かを「あり」または「なし」で記録するようになっている。また、「仮想ＡＡＡＡリソースレコード（ＲＲ）」欄には、完全修飾ドメイン名（ＦＱＤＮ）に対応した仮想ＡＡＡＡリソースレコードが予め記載されている。
【００７５】
図１２のステップＳ２６５の処理が行われた後、ＩＰｖ６通信不能検出モジュール１１７は、名前解決の要求を行った第１あるいは第２の端末１０４、１０５が仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを確認する（ステップＳ２６６）。この確認は、予め定めた時間ｔ1以内に仮想ＡＡＡＡリソースレコード宛の通信が開始したかによってチェックされる（ステップＳ２６６：Ｎ、ステップＳ２６７）。
【００７６】
名前解決の要求が仮に第１の端末１０４によって行われたとする。第１の端末１０４のアプリケーションプログラムはＩＰｖ４には対応する。しかしながらこれらのアプリケーションプログラムの中には、ＩＰｖ６に未対応のものが存在している。したがってＩＰｖ６に未対応のアプリケーションプログラムが稼働した場合、仮想ＡＡＡＡリソースレコード宛の通信が開始することはない。一方、名前解決の要求が第２の端末１０５によって行われた場合には、ＩＰｖ６に対応するアプリケーションプログラムが稼働することで、仮想ＡＡＡＡリソースレコード宛の通信が時間ｔ1以内に行われようとする可能性が高い。
【００７７】
そこで、時間ｔ1以内に仮想ＡＡＡＡリソースレコード宛の通信がなければ（ステップＳ２２６：Ｎ、ステップＳ２６７：Ｙ）、ＩＰｖ６通信不能検出モジュール１１７は該当する端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する。この場合、ＩＰｖ６通信不能検出モジュール１１７は、ＲＲ制御ポリシテーブル１１４の該当する完全修飾ドメイン名（ＦＱＤＮ）にＡＡＡＡリソースレコードを禁止リソースレコード（ＲＲ）として登録する（ステップＳ２６８）。この後、処理はステップＳ２６１に戻る（リターン）。
【００７８】
ところで、時間ｔ1以内に仮想ＡＡＡＡリソースレコード宛の通信があった場合には（ステップＳ２６６：Ｙ）、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを確認する必要がある。そこで、この場合、ＩＰｖ６通信不能検出モジュール１１７は、名前解決の要求を行った第１あるいは第２の端末１０４、１０５が通信に使用した同じプロトコルと同じポート番号を使用して、名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能かを確認する（ステップＳ２６９）。この通信が不可能な場合には（Ｎ）、前記したフォールバック事象が発生していると判断して、ＲＲ制御ポリシテーブル１１４の該当する完全修飾ドメイン名（ＦＱＤＮ）にＡＡＡＡリソースレコードを禁止リソースレコード（ＲＲ）として登録する（ステップＳ２６８）。この後、処理はステップＳ２６１に戻る（リターン）。
【００７９】
この例の場合、ステップＳ２６９で名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能であった場合（Ｙ）、特に許可ＲＲとして登録を行うことなく、処理はステップＳ２６１に戻る（リターン）。処理内容によっては、名前解決の要求を行った端末について許可リソースレコード（ＲＲ）の登録を行うようにしてもよい。
【００８０】
このように本発明の第２の変形例によれば、ゲートウェイにＤＮＳサーバモジュール１１３、ＲＲ制御ポリシテーブル１１４、ＩＰｖ６通信不能検出テーブル１１５およびＩＰｖ６通信不能検出モジュール１１７を有することにした。これにより、端末のアプリケーションプログラムを入れ換えたりしたような場合にも、システムの管理者に負担を掛けずにＲＲ制御ポリシテーブル１１４の変更が可能になるという利点が生じる。
【００８１】
なお、以上説明した実施の形態および変形例では、ローカルネットワーク上の端末（デュアルスタック端末）１０４、１０５が名前解決要求を行った場合を説明したが、ローカルネットワーク上の端末からの名前解決要求に限定されるものでないことはもちろんである。
【００８２】
また、端末（デュアルスタック端末）１０４、１０５からＤＮＳサーバ１０８に送られるＤＮＳ問合わせを受信するゲートウェイは、ネットワーク間の中継装置という広義の意味で使用しており、ルータ等の他の名称のものもＤＮＳ問合わせを中継する機能を備えていれば本発明が適用されることは当然である。
【００８３】
以上説明した実施の形態の一部または全部は、以下の付記のようにも記載されるが、以下の記載に限定されるものではない。
【００８４】
（付記１）
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末と、
所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答するＤＮＳ（Domain Name System）サーバと、
前記デュアルスタック端末から名前解決要求が送られてきたときこれを受信して前記ＤＮＳサーバに送信する名前解決要求送信手段と、この名前解決要求送信手段の送信した名前解決要求に対して前記ＤＮＳサーバから返答として送られてくるリソースレコードを受信するリソースレコード受信手段と、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルと、前記リソースレコード受信手段の受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブルを参照し前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答手段とを備えたゲートウェイ
とを具備することを特徴とするリソースレコード制御システム。
【００８５】
（付記２）
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末および通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードを個別に設定していることを特徴とする付記１記載のリソースレコード制御システム。
【００８６】
（付記３）
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末が前記通信相手と通信する際に稼働するアプリケーションプログラムがＩＰｖ６で不適合である場合を前提としたＩＰｖ６通信を抑制するポリシで作成された内容であることを特徴とする付記１または付記２記載のリソースレコード制御システム。
【００８７】
（付記４）
前記リソースレコード制御ポリシテーブルには、通信を許可する許可リソースレコードあるいは通信を禁止する禁止リソースレコードが通信相手のドメイン名としての完全修飾ドメイン名（ＦＱＤＮ：Fully Qualified Domain Name）に対応付けて記載されていることを特徴とする付記２記載のリソースレコード制御システム。
【００８８】
（付記５）
前記ゲートウェイは、前記デュアルスタック端末からのすべての名前解決要求に対して仮想のＡＡＡＡリソースレコードを応答する仮想のＡＡＡＡリソースレコード応答手段と、この仮想のＡＡＡＡリソースレコードに対して前記デュアルスタック端末がＩＰｖ６通信を行うか否かを判別するＩＰｖ６通信可否判別手段と、このＩＰｖ６通信可否判別手段がＩＰｖ６通信を可能と判別したとき前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別するアプリケーション対応判別手段とを具備することを特徴とする付記１記載のリソースレコード制御システム。
【００８９】
（付記６）
前記リソースレコード制御ポリシテーブルには、前記アプリケーション対応判別手段によって前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別したものに対してフォールバック事象が発生している場合を除き、ＩＰｖ６通信を許可する許可リソースレコードが記載されることを特徴とする付記５記載のリソースレコード制御システム。
【００９０】
（付記７）
前記リソースレコード制御ポリシテーブルには、前記アプリケーション対応可否判別手段によって前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していないと判別したものに対してＩＰｖ６通信を禁止する禁止リソースレコードが記載されることを特徴とする付記５記載のリソースレコード制御システム。
【００９１】
（付記８）
前記ゲートウェイは、名前解決の要求を行った前記デュアルスタック端末が通信に使用した同じプロトコルと同じポート番号を使用して、名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能か否かを判別する同一プロトコル・同一ポート番号通信判別手段と、この同一プロトコル・同一ポート番号通信判別手段で所定時間内に仮想ＡＡＡＡリソースレコード宛の通信が可能でないと判別されたときフォールバック事象が発生したものと判別するフォールバック事象判別手段を具備することを特徴とする付記５記載のリソースレコード制御システム。
【００９２】
（付記９）
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信ステップと、
このリソースレコード受信ステップで受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答ステップ
とを具備することを特徴とするリソースレコード制御方法。
【００９３】
（付記１０）
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信ステップと、
このＤＮＳ応答返信ステップで返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別ステップと、
この通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別ステップと、
前記通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別ステップと、
このフォールバック事象発生有無判別ステップでフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別ステップ
とを具備することを特徴とするアプリケーション判別方法。
【００９４】
（付記１１）
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信処理と、
このリソースレコード受信処理で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答処理
とを実行させることを特徴とするリソースレコード制御プログラム。
【００９５】
（付記１２）
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信処理と、
このＤＮＳ応答返信処理で返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別処理と、
この通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別処理と、
前記通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別処理と、
このフォールバック事象発生有無判別処理でフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別処理
とを実行させることを特徴とするアプリケーション判別プログラム。
【符号の説明】
【００９６】
１０、１００ リソースレコード制御システム
１１ デュアルスタック端末
１２ ＤＮＳサーバ
１３、１０２ ゲートウェイ
１３ａ 名前解決要求送信手段
１３ｂ リソースレコード受信手段
１３ｃ リソースレコード制御ポリシテーブル
１３ｄ ＤＮＳ応答手段
２０ リソースレコード制御方法
２１、３１ 名前解決要求送信ステップ
２２ リソースレコード受信ステップ
２３ ＤＮＳ応答ステップ
３０ アプリケーション判別方法
３２ ＤＮＳ応答返信ステップ
３３ 通信有無判別ステップ
３４ 未対応プログラム存在判別ステップ
３５ フォールバック事象発生有無判別ステップ
３６ 対応プログラム存在判別ステップ
４０ リソースレコード制御プログラム
４１、５１ 名前解決要求送信処理
４２ リソースレコード受信処理
４３ ＤＮＳ応答処理
５０ アプリケーション判別プログラム
５２ ＤＮＳ応答返信処理
５３ 通信有無判別処理
５４ 未対応プログラム存在判別処理
５５ フォールバック事象発生有無判別処理
５６ 対応プログラム存在判別処理
１０１ インターネット
１０３ ローカルネットワーク
１０４ 第１の端末
１０５ 第２の端末
１０６ 第１のＷＷＷサーバ
１０７ 第２のＷＷＷサーバ
１１１ ＤＮＳリゾルバ
１１２ ＤＮＳキャッシュテーブル
１１３ ＤＮＳサーバモジュール
１１４、１１４Ａ ＲＲ制御ポリシテーブル
１１５ ＩＰｖ６通信不能検出テーブル
１１７ ＩＰｖ６通信不能検出モジュール
【特許請求の範囲】
【請求項１】
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末と、
所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答するＤＮＳ（Domain Name System）サーバと、
前記デュアルスタック端末から名前解決要求が送られてきたときこれを受信して前記ＤＮＳサーバに送信する名前解決要求送信手段と、この名前解決要求送信手段の送信した名前解決要求に対して前記ＤＮＳサーバから返答として送られてくるリソースレコードを受信するリソースレコード受信手段と、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルと、前記リソースレコード受信手段の受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブルを参照し前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答手段とを備えたゲートウェイ
とを具備することを特徴とするリソースレコード制御システム。
【請求項２】
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末および通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードを個別に設定していることを特徴とする請求項１記載のリソースレコード制御システム。
【請求項３】
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末が前記通信相手と通信する際に稼働するアプリケーションプログラムがＩＰｖ６で不適合である場合を前提としたＩＰｖ６通信を抑制するポリシで作成された内容であることを特徴とする請求項１または請求項２記載のリソースレコード制御システム。
【請求項４】
前記ゲートウェイは、前記デュアルスタック端末からのすべての名前解決要求に対して仮想のＡＡＡＡリソースレコードを応答する仮想のＡＡＡＡリソースレコード応答手段と、この仮想のＡＡＡＡリソースレコードに対して前記デュアルスタック端末がＩＰｖ６通信を行うか否かを判別するＩＰｖ６通信可否判別手段と、このＩＰｖ６通信可否判別手段がＩＰｖ６通信を可能と判別したとき前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別するアプリケーション対応判別手段とを具備することを特徴とする請求項１記載のリソースレコード制御システム。
【請求項５】
前記リソースレコード制御ポリシテーブルには、前記アプリケーション対応判別手段によって前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別したものに対してフォールバック事象が発生している場合を除き、ＩＰｖ６通信を許可する許可リソースレコードが記載されることを特徴とする請求項４記載のリソースレコード制御システム。
【請求項６】
前記ゲートウェイは、名前解決の要求を行った前記デュアルスタック端末が通信に使用した同じプロトコルと同じポート番号を使用して、名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能か否かを判別する同一プロトコル・同一ポート番号通信判別手段と、この同一プロトコル・同一ポート番号通信判別手段で所定時間内に仮想ＡＡＡＡリソースレコード宛の通信が可能でないと判別されたときフォールバック事象が発生したものと判別するフォールバック事象判別手段を具備することを特徴とする請求項４記載のリソースレコード制御システム。
【請求項７】
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信ステップと、
このリソースレコード受信ステップで受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答ステップ
とを具備することを特徴とするリソースレコード制御方法。
【請求項８】
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信ステップと、
このＤＮＳ応答返信ステップで返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別ステップと、
この通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別ステップと、
前記通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別ステップと、
このフォールバック事象発生有無判別ステップでフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別ステップ
とを具備することを特徴とするアプリケーション判別方法。
【請求項９】
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信処理と、
このリソースレコード受信処理で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答処理
とを実行させることを特徴とするリソースレコード制御プログラム。
【請求項１０】
（付記１２）
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信処理と、
このＤＮＳ応答返信処理で返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別処理と、
この通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別処理と、
前記通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別処理と、
このフォールバック事象発生有無判別処理でフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別処理
とを実行させることを特徴とするアプリケーション判別プログラム。
【請求項１】
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末と、
所定のネットワークを介して送られてくる名前解決要求を受信して該当する通信相手のドメイン名に対するリソースレコードを要求先に応答するＤＮＳ（Domain Name System）サーバと、
前記デュアルスタック端末から名前解決要求が送られてきたときこれを受信して前記ＤＮＳサーバに送信する名前解決要求送信手段と、この名前解決要求送信手段の送信した名前解決要求に対して前記ＤＮＳサーバから返答として送られてくるリソースレコードを受信するリソースレコード受信手段と、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルと、前記リソースレコード受信手段の受信したリソースレコードを基にしてこのリソースレコード制御ポリシテーブルを参照し前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答手段とを備えたゲートウェイ
とを具備することを特徴とするリソースレコード制御システム。
【請求項２】
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末および通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードを個別に設定していることを特徴とする請求項１記載のリソースレコード制御システム。
【請求項３】
前記リソースレコード制御ポリシテーブルは、前記デュアルスタック端末が前記通信相手と通信する際に稼働するアプリケーションプログラムがＩＰｖ６で不適合である場合を前提としたＩＰｖ６通信を抑制するポリシで作成された内容であることを特徴とする請求項１または請求項２記載のリソースレコード制御システム。
【請求項４】
前記ゲートウェイは、前記デュアルスタック端末からのすべての名前解決要求に対して仮想のＡＡＡＡリソースレコードを応答する仮想のＡＡＡＡリソースレコード応答手段と、この仮想のＡＡＡＡリソースレコードに対して前記デュアルスタック端末がＩＰｖ６通信を行うか否かを判別するＩＰｖ６通信可否判別手段と、このＩＰｖ６通信可否判別手段がＩＰｖ６通信を可能と判別したとき前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別するアプリケーション対応判別手段とを具備することを特徴とする請求項１記載のリソースレコード制御システム。
【請求項５】
前記リソースレコード制御ポリシテーブルには、前記アプリケーション対応判別手段によって前記デュアルスタック端末の該当するアプリケーションプログラムがＩＰｖ６通信に対応していると判別したものに対してフォールバック事象が発生している場合を除き、ＩＰｖ６通信を許可する許可リソースレコードが記載されることを特徴とする請求項４記載のリソースレコード制御システム。
【請求項６】
前記ゲートウェイは、名前解決の要求を行った前記デュアルスタック端末が通信に使用した同じプロトコルと同じポート番号を使用して、名前解決により得られたＡＡＡＡリソースレコードのＩＰｖ６アドレス宛に通信が可能か否かを判別する同一プロトコル・同一ポート番号通信判別手段と、この同一プロトコル・同一ポート番号通信判別手段で所定時間内に仮想ＡＡＡＡリソースレコード宛の通信が可能でないと判別されたときフォールバック事象が発生したものと判別するフォールバック事象判別手段を具備することを特徴とする請求項４記載のリソースレコード制御システム。
【請求項７】
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信ステップと、
このリソースレコード受信ステップで受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答ステップ
とを具備することを特徴とするリソースレコード制御方法。
【請求項８】
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれをゲートウェイとして受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信ステップと、
この名前解決要求送信ステップで送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信ステップと、
このＤＮＳ応答返信ステップで返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別ステップと、
この通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別ステップと、
前記通信有無判別ステップで前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別ステップと、
このフォールバック事象発生有無判別ステップでフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別ステップ
とを具備することを特徴とするアプリケーション判別方法。
【請求項９】
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求の返答として前記ＤＮＳサーバから送られてくるリソースレコードを受信するリソースレコード受信処理と、
このリソースレコード受信処理で受信したリソースレコードを基にして、通信相手のドメイン名ごとに使用を許可するリソースレコードあるいは使用を禁止するリソースレコードをポリシとして定めたリソースレコード制御ポリシテーブルを参照して前記名前解決要求を行ったデュアルスタック端末に対して通信相手のドメインと通信するためのＤＮＳ応答を行うＤＮＳ応答処理
とを実行させることを特徴とするリソースレコード制御プログラム。
【請求項１０】
（付記１２）
ゲートウェイのコンピュータに、
ＩＰｖ４（Internet Protocol version 4）プロトコルスタックとＩＰｖ６（Internet Protocol version 6）プロトコルスタックの双方を搭載したデュアルスタック端末から名前解決要求が送られてきたときこれを受信してＤＮＳ（Domain Name System）サーバに送信する名前解決要求送信処理と、
この名前解決要求送信処理で送信した名前解決要求に対して前記ＤＮＳサーバからＡＡＡＡリソースレコードがＤＮＳ応答として送られてきたときこれを前記デュアルスタック端末にＤＮＳ応答として返信するＤＮＳ応答返信処理と、
このＤＮＳ応答返信処理で返信した前記デュアルスタック端末がこの返信に基づいて所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってくるかを判別する通信有無判別処理と、
この通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信を行ってこないとき前記デュアルスタック端末内にＩＰｖ６未対応アプリケーションプログラムが存在していると判断する未対応プログラム存在判別処理と、
前記通信有無判別処理で前記所定時間内に仮想ＡＡＡＡリソースレコード宛の通信があった場合、これがＩＰｖ６からＩＰｖ４へのフォールバック事象の発生によるものであるかを判別するフォールバック事象発生有無判別処理と、
このフォールバック事象発生有無判別処理でフォールバック事象が発生していないと判別されたとき前記デュアルスタック端末にＩＰｖ６対応のアプリケーションプログラムが存在していると判断する対応プログラム存在判別処理
とを実行させることを特徴とするアプリケーション判別プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−１０９８８７（Ｐ２０１２−１０９８８７Ａ）
【公開日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願番号】特願２０１０−２５８５２９（Ｐ２０１０−２５８５２９）
【出願日】平成２２年１１月１９日（２０１０．１１．１９）
【出願人】（０００１９７３６６）ＮＥＣアクセステクニカ株式会社 (1,236)
【Ｆターム（参考）】
【公開日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願日】平成２２年１１月１９日（２０１０．１１．１９）
【出願人】（０００１９７３６６）ＮＥＣアクセステクニカ株式会社 (1,236)
【Ｆターム（参考）】
[ Back to top ]