JP2004228760A - アドレスの問合せに対する返信方法、プログラム、装置、及び、アドレス通知方法、プログラム、装置 - Google Patents
アドレスの問合せに対する返信方法、プログラム、装置、及び、アドレス通知方法、プログラム、装置 Download PDFInfo
- Publication number
- JP2004228760A JP2004228760A JP2003012283A JP2003012283A JP2004228760A JP 2004228760 A JP2004228760 A JP 2004228760A JP 2003012283 A JP2003012283 A JP 2003012283A JP 2003012283 A JP2003012283 A JP 2003012283A JP 2004228760 A JP2004228760 A JP 2004228760A
- Authority
- JP
- Japan
- Prior art keywords
- address
- server
- ipv6
- ipv4
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
【課題】途中のネットワークにおいて、ＩＰｖ６接続性のみが切断している場合（ＩＰｖ４接続性は保たれている場合）には、ＩＰｖ６アドレスは取得できるので、ＩＰｖ６を利用した通信を試みるが、ＩＰｖ６ではサーバとの通信はできないので、数十秒のタイムアウトを経てから、ＩＰｖ４アドレスを取得して、ＩＰｖ４を利用した通信を行っていた。
【解決手段】ＤＮＳサーバ１０９は、サーバ１０７のアドレスの問合せをクライアント１０６から受けて、ＤＮＳサーバ１０８に問合せ、クライアント１０６に通知する場合に、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスの有効期限より短い有効期限を、サーバ１０７のアドレスの有効期限として通知する。また、ＤＮＳサーバ１０９は、サーバ１０９との接続試験を行って、失敗した場合に、クライアント１０６からのサーバ１０７のアドレスの問合せを受けた場合には、アドレスがないことを返信する。
【選択図】 図１
【解決手段】ＤＮＳサーバ１０９は、サーバ１０７のアドレスの問合せをクライアント１０６から受けて、ＤＮＳサーバ１０８に問合せ、クライアント１０６に通知する場合に、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスの有効期限より短い有効期限を、サーバ１０７のアドレスの有効期限として通知する。また、ＤＮＳサーバ１０９は、サーバ１０９との接続試験を行って、失敗した場合に、クライアント１０６からのサーバ１０７のアドレスの問合せを受けた場合には、アドレスがないことを返信する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、アドレスの問合せに対する返信方法、プログラム、装置、及び、アドレス通知方法、プログラム、装置に関する。
【０００２】
【従来の技術】
近年、現在のインターネットを支える基盤プロトコルであるＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）の次世代バージョンであるＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）の検討が開始された。
【０００３】
ＩＰｖ６はＩＰｖ４に置き換わる技術であるが、これまでのＩＰｖ４のネットワークを排除するものではなく、ＩＰｖ４からＩＰｖ６への移行技術も検討されている。移行技術にはトンネル技術、トランスレート技術、デュアル技術が存在する。
【０００４】
このうち、デュアル技術は、ＩＰｖ４とＩＰｖ６を同一のネットワーク上で運用することにより、ネットワーク上で利用する機器やアプリケーションのスムーズな移行を助ける技術である。これからは、このデュアル技術を用いたＩＰｖ４／ＩＰｖ６デュアル環境のネットワークが広がり、インターネット上で利用されるすべてのアプリケーションがＩＰｖ６に完全に移行されるまでの相当長い期間、このデュアル環境ネットワークが利用されると考えられる。
【０００５】
このデュアル環境におけるＩＰｖ４／ＩＰｖ６アクセス可能なＥ−ＭａｉｌやＷｅｂなどのサービスを利用した際、ＩＰｖ４とＩＰｖ６のどちらの通信プロトコルを利用して通信するかを決定する「通信プロトコル選択手順」では、通信相手のサーバの指定をＩＰｖ４／ＩＰｖ６アドレスで指定した場合、それぞれ指定された通信プロトコルを利用する。
【０００６】
しかしながら、通信相手のサーバの指定をＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）で指定した場合、どちらの通信プロトコルを利用して通信するかは、以下の手順で決定される。
【０００７】
すなわち、
１．ＩＰｖ６アドレスをＤＮＳに問合せる。
２．ＩＰｖ６アドレスの取得に成功すればＩＰｖ６で通信を行う。
３．ＩＰｖ６アドレスの取得に失敗した場合、続いてＩＰｖ４アドレスをＤＮＳに問合せる。
４．ＩＰｖ４アドレスの取得に成功すればＩＰｖ４で通信を行う。
５．ＩＰｖ４アドレスの取得も失敗した場合は、サーバが存在しないことになりエラー終了となる。
【０００８】
これは、現状の各種アプリケーションの動作内容を解析しても、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）にて規定している「Ｂａｓｉｃ Ｓｏｃｋｅｔ Ｉｎｔｅｒｆａｃｅ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰｖ６」（ＲＦＣ２１３３、ＲＦＣ２５５３）を参照しても、上記の通信プロトコル選択手順を行っている。
【０００９】
ＷｅｂやＥ−Ｍａｉｌなど、一般的なインターネットアプリケーションでは、ＤＮＳを利用した通信相手の特定を行っている。
【００１０】
しかしながら、ＩＰｖ４／ＩＰｖ６アクセス可能なサーバでは、一つのネットワークインターフェースにＩＰｖ４／ＩＰｖ６それぞれのアドレスを設定しているが、サーバ名としてはＦＱＤＮを一つだけ登録することがしばしばである。
【００１１】
つまり、ＩＰｖ４／ＩＰｖ６アクセス可能なＷｅｂサーバ「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」が存在した場合、このサーバにはＩＰｖ４アドレスとＩＰｖ６アドレスが対応していることになる。ＤＮＳへの登録内容においても、ＩＰｖ４アドレスを設定する「Ａ」レコードと、ＩＰｖ６アドレスを設定する「ＡＡＡＡ」レコードの二つを、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に設定することが一般的に多い。
【００１２】
通信相手のサーバの指定をＩＰｖ４／ＩＰｖ６アドレスで指定する通信プロトコル選択手順は利用されにくく、通信相手のサーバの指定をＦＱＤＮで指定することが多いので、ＩＰｖ６通信プロトコルを優先的に使用するアクセスがしばしばである。
【００１３】
クライアントやサーバが属しているデュアル環境のネットワークでは、ＩＰｖ４もＩＰｖ６も同一の物理回線上にて通信しているが、そのネットワークの外部、あるいは、そのネットワークを提供しているＩＳＰの外部では、ＩＰｖ４とＩＰｖ６はまったくの別回線上で通信が行われていることが多い。事実、現在サービス提供されているＩＰｖ６接続サービスの多くは、トンネル接続によるものである。
【００１４】
また、日本のＩＸにおいて、同一の回線口においてＩＳＰ同士がＩＰｖ４／ＩＰｖ６両方の通信トラフィックを交換しているところはまずない。
【００１５】
ＩＳＰ内部においても、ＩＰｖ６バックボーンを別途構築したり、トンネル技術やＭＰＬＳなどを利用して仮想的に独立したネットワークを構築したりするなどして、ＩＰｖ４とＩＰｖ６を区別した運用を行っていることがしばしばである。
【００１６】
これより、デュアル環境におけるＩＰｖ４／ＩＰｖ６通信品質は、同一のデュアルネットワーク内では同等だが、外部のネットワークとの通信に関しては、通信プロトコルにより帯域や輻輳、クオリティは全く異なる。
【００１７】
また、ＩＰｖ６はいまだ実験運用が主であり、運用ノウハウや対応機器の信頼性を現在高めている最中である。つまり、ＩＰｖ６通信プロトコルだけが通信不通となることが、比較的頻度に発生する。
【００１８】
一方、ＤＮＳサーバの問合せに利用する通信プロトコルはＩＰｖ４を利用するものが一般的に多い。例えば、ＩＳＣ（Ｉｎｔｅｒｎｅｔ Ｓｏｆｔｗａｒｅ Ｃｏｎｓｏｒｔｉｕｍ）提供のＢＩＮＤは現在、ＢＩＮＤ４、ＢＩＮＤ８が広く世界で利用されているが、ＩＰｖ６通信プロトコルを利用して問合せ・返信を行うことができるバージョンはＢＩＮＤ９のみである。つまり、ＤＮＳに「ＡＡＡＡ」レコードの登録は可能だが、ＩＰｖ６通信プロトコルを利用しての問合せ・返信はできないのである。
【００１９】
また、Ｗｉｎｄｏｗｓ（登録商標） ＸＰでは、サポート外でありながら、ＩＰｖ６プロトコルスタックを搭載したＯＳであるが、リゾルバはＩＰｖ６通信によるＤＮＳ問合せが行えない。
【００２０】
このような状況から、ＩＰｖ６通信が途中切断している場合でも、通信相手となるサーバのＤＮＳ問合せはＩＰｖ４通信プロトコルを利用して行うことができ、対象サーバに「ＡＡＡＡ」レコードでの登録がある場合は、ＩＰｖ６アドレスを取得できてしまう。
【００２１】
【発明が解決しようとする課題】
以上のような状況から、途中のネットワークにおいて、ＩＰｖ６接続性のみが切断している場合（ＩＰｖ４接続性は保たれている場合）には、ＩＰｖ６アドレスは取得できるので、ＩＰｖ６を利用した通信を試みるが、ＩＰｖ６ではサーバとの通信はできないので、数十秒のタイムアウトを経てから、ＩＰｖ４アドレスを取得して、ＩＰｖ４を利用した通信を行う現象が現れる。
【００２２】
この現象は、特に、ＷｅｂやＥ−Ｍａｉｌといった、何度もアクセスするようなアプリケーションでは、そのたびにタイムアウト待ちをすることとなり、ユーザにとって大変フラストレーションがたまるものといえる。また、ＩＰｖ６の利用に際し、ユーザにとってデュアル環境が「利用しにくい環境」と認識されてしまう可能性がある。
【００２３】
本発明は、この問題を解決するために成されるものであり、アドレスが取得できても、接続できない事態を減らすことを目的とする。
【００２４】
【課題を解決するための手段】
本発明の返信装置、プログラム、及び、装置は、第１の装置のアドレスを用いて前記第１の装置との接続試験を行う試験ステップと、前記試験ステップでの接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信する返信ステップとを有することを特徴とする。
【００２５】
また、本発明のアドレス通知方法、プログラム、及び、装置は、第１の装置のアドレスの問合せを第２の装置から受けると、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知するアドレス通知方法、プログラム、及び、装置において、前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することを特徴とする。
【００２６】
【発明の実施の形態】
以下、図面を参照して本発明の一実施形態を詳細に説明する。
【００２７】
図１は本発明の一実施形態のネットワークの構成図である。
【００２８】
図１において、１０１はユーザの所属するＩＰｖ４／ＩＰｖ６デュアル環境なネットワークである。ユーザネットワーク１０１には、ユーザの利用するＩＰｖ４／ＩＰｖ６アクセス可能なＷｅｂクライアント１０６が接続している。また、ＩＰｖ４／ＩＰｖ６アクセス可能なＤＮＳサーバ１０９もユーザネットワーク１０１に同じく接続している。ＤＮＳサーバ１０９は、ユーザネットワーク１０１に属する端末群のドメインを管理するＤＮＳである。
【００２９】
１０７はＩＰｖ４／ＩＰｖ６アクセス可能なＷｅｂサーバであり、ＩＰｖ４／ＩＰｖ６デュアル環境のサーバネットワーク１０３に接続している。１０８はＩＰｖ４／ＩＰｖ６アクセス可能なＤＮＳサーバであり、ＩＰｖ４／ＩＰｖ６デュアル環境のドメイン管理ネットワーク１０２に接続している。
【００３０】
Ｗｅｂサーバ１０７にはＦＱＤＮが割当ててあり、そのＦＱＤＮの属するドメインを管理するＤＮＳサーバがＤＮＳサーバ１０８である。
【００３１】
ユーザネットワーク１０１とドメイン管理ネットワーク１０２とサーバネットワーク１０３は、ＩＰｖ４インターネット１０４を介してＩＰｖ４通信プロトコルを利用して相互に通信が可能である。また、ユーザネットワーク１０１とドメイン管理ネットワーク１０２とサーバネットワーク１０３は、ＩＰｖ６インターネット１０５を介したＩＰｖ６通信プロトコルを利用して相互に通信が可能である。
【００３２】
図２は、図１において説明した各ネットワークの属するドメイン名と、各ホストに割当てたＦＱＤＮの一例である。また、各ネットワークに割当てたＩＰｖ４及びＩＰｖ６ネットワークアドレスと、各ホストに割当てたＩＰｖ４及びＩＰｖ６アドレスの一例も示す。
【００３３】
ユーザネットワーク１０１に属するＤＮＳサーバ１０９は、「ｃｌｉｅｎｔ．ｃｏｍ」ドメインを管理するマスタゾーンファイルを保持している。一方、ドメイン管理ネットワーク１０２に属するＤＮＳサーバ１０８は、「ｓｅｒｖｅｒ．ｎｅｔ」ドメインを管理するマスタゾーンファイルを保持している。
【００３４】
図３は、本実施形態での機能を実現するソフトウェアプログラムを動作させる構成の一例を示したものである。
【００３５】
例えば、ＤＮＳサーバ１０９は、図３に示すコンピュータ９００の機能により、本実施形態での機能を実現する。コンピュータ９００は、ＣＰＵ９０１と、ＲＯＭ９０２と、ＲＡＭ９０３と、ハードディスク（ＨＤ）９０７及びフロッピー（登録商標）ディスク（ＦＤ）９０８のディスクコントローラ（ＤＣ）９０５と、ネットワークインタフェースカード（ＮＩＣ）９０６とが、システムバス９０４を介して互いに通信可能に接続された構成としている。そして、ネットワークインタフェースカード９０６は、図１に示したネットワーク１０１を、システムバス９０４に接続する。
【００３６】
ＤＮＳサーバ１０９は、クライアント１０６（第２の装置）から受けたサーバ１０７（第１の装置）のアドレスの問合せに対する返信メッセージを返信する返信装置であり、クライアント１０６（第２の装置）からサーバ１０７（第１の装置）のアドレスの問合せを受けると、サーバ１０７のアドレスをクライアント１０６に通知するアドレス通知装置である。
【００３７】
ネットワークインタフェースカード９０６は、ネットワーク１０１を接続する接続手段である。
【００３８】
また、ＣＰＵ９０１は、クライアント１０６から受けたサーバ１０７のアドレスの問合せに対する返信メッセージを生成する生成手段であり、サーバ１０７のアドレスを用いてサーバ１０７との接続試験を行い、接続試験が失敗した場合には、サーバ１０７のアドレスがないことを示す返信メッセージを生成する。また、ＣＰＵ９０１は、クライアント１０６からサーバ１０７のアドレスの問合せを受けると、サーバ１０７のアドレスをクライアント１０６に通知する通知手段であり、サーバ１０７のアドレスをＤＮＳサーバ１０８（第３の装置）に問合せ、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスとともに、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスの有効期限より短い有効期限を、サーバ１０７のアドレスの有効期限として、クライアント１０６に通知する。
【００３９】
ＣＰＵ９０１は、ＲＯＭ９０２あるいはＨＤ９０７に記憶されたソフトウェア、あるいはＦＤ９０８より供給されるソフトウェアを実行することで、システムバス９０４に接続された各構成部を統括的に制御する。すなわち、ＣＰＵ９０１は、以下に説明する処理シーケンスに従った処理プログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、本実施形態での動作を実現するための制御を行う。
【００４０】
ＲＡＭ９０３は、ＣＰＵ９０１の主メモリあるいはワークエリア等として機能する。ＤＣ９０５は、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイル、ネットワーク管理プログラム、および本実施形態における下記処理プログラム等を記憶するＨＤ９０７、およびＦＤ９０８とのアクセスを制御する。ＮＩＣ９０６は、ネットワーク１０１を通じてＩＰｖ４インターネット１０４に接続するサーバ１０７等と、ＩＰｖ４通信プロトコルを用いて相互にデータのやり取りをする。また、ＮＩＣ９０６は、ネットワーク１０１を通じてＩＰｖ６インターネット１０５に接続するサーバ１０７等と、ＩＰｖ６通信プロトコルを用いて相互にデータのやり取りをする。
【００４１】
なお、Ｗｅｂクライアント１０６、Ｗｅｂサーバ１０７、ＤＮＳサーバ１０８も、ＤＮＳサーバ１０９と同様に、図３にしめるコンピュータ９００のように構成可能である。Ｗｅｂクライアント１０６、Ｗｅｂサーバ１０７、ＤＮＳサーバ１０８は、夫々、ＮＩＣ９０６を介して、ネットワーク１０１、１０３、１０２に接続される。
【００４２】
図４はＷｅｂクライアント１０６とＷｅｂサーバ１０７の通信確立までの処理概要を示したモジュール図である。
【００４３】
３０１〜３０３はＷｅｂクライアント１０６内のモジュールである。３０４〜３０８はＤＮＳサーバ１０９内のモジュールである。３０９、３１０はＤＮＳサーバ１０８内のモジュールである。３１１はＷｅｂサーバ１０７内のモジュールである。
【００４４】
なお、モジュール３０４、３０７、３０８は、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたソフトウェア、あるいはＦＤ９０８より供給されるソフトウェアにより実現される。ＣＰＵ９０１は、モジュール３０４、３０７、３０８を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、モジュール３０４、３０７、３０８の機能を実現する。
【００４５】
また、マスタゾーンファイル３０５、キャッシュデータ３０６は、ＲＡＭ９０３、又は、ＨＤ９０７に格納される。
【００４６】
Ｗｅｂクライアント１０６においても、モジュール３０１、３０２は、ソフトウェアにより実現され、キャッシュデータ３０３は、ＲＡＭ９０３、又は、ＨＤ９０７に格納される。
【００４７】
また、ＤＮＳサーバ１０８においても、モジュール３０９は、ソフトウェアにより実現され、マスタゾーンファイル３１０は、ＲＡＭ９０３、又は、ＨＤ３１０に格納される。Ｗｅｂサーバ１０７においても、サーバアプリケーション３１１は、ソフトウェアにより実現される。
【００４８】
次に、Ｗｅｂクライアント１０６とＷｅｂサーバ１０７の通信確立までの処理を説明する。
【００４９】
まず、クライアントアプリケーション３０１にて、通信相手となるサーバアプリケーションが指定される。指定方法としては本実施形態のＷｅｂの場合、「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」というＵＲＬの形にて指定される。クライアントアプリケーション３０１はこのＵＲＬより、サーバアプリケーションのホスト名であるＦＱＤＮ「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」を抽出し、リゾルバモジュール３０２に、指定したＦＱＤＮに対応するＩＰｖ４／ＩＰｖ６どちらかのアドレスを問合せる。
【００５０】
ＦＱＤＮからのアドレス問合せを受け取ったリゾルバモジュール３０２は、以前に問合せた結果が記録されているキャッシュデータ３０３に、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対応するＩＰｖ６アドレスがあるかどうかをチェックする。キャッシュデータ３０３に対応するＩＰｖ６アドレスが存在しない場合、続いて、ＩＰｖ４アドレスに関してもキャッシュデータ３０３を調査する。
【００５１】
どちらのアドレスもキャッシュデータ３０３に存在しない場合、リゾルバモジュール３０２は、ＤＮＳサーバ１０９に対して指定したＦＱＤＮに対するＩＰｖ４／ＩＰｖ６アドレスの問合せ（以降、正引き問合せと言う）を行う。
【００５２】
ここで正引き問合せで利用する通信プロトコルとして選択される通信プロトコルは、Ｗｅｂクライアント１０６のＯＳに設定しているＤＮＳサーバのアドレスをどちらの通信プロトコルで指定したかによって決定される。一方、リゾルバモジュール３０２から送られる正引き問合せは、前述したとおり、「ＡＡＡＡ」ＤＮＳ Ｑｕｅｒｙメッセージ（つまり、ＩＰｖ６アドレスの正引き問合せ）を初めに送信する。この送信に用いられる通信プロトコルは、Ｗｅｂクライアント１０６のＯＳに設定しているＤＮＳサーバのアドレスがＩＰｖ６アドレスであれば、ＩＰｖ６であり、ＩＰｖ４アドレスであれば、ＩＰｖ４である。
【００５３】
送信した正引き問合せはＤＮＳサーバ１０９内のネームサーバモジュール３０４にて受信される。ネームサーバモジュール３０４は、ユーザネットワーク１０１に属するドメイン「ｃｌｉｅｎｔ．ｃｏｍ」の管理を行っており、このドメインに属するすべてのＦＱＤＮとＩＰｖ４／ＩＰｖ６アドレスを対としたレコードを、マスタゾーンファイル３０５に保持している。ネームサーバモジュール３０４は、管理しているドメイン「ｃｌｉｅｎｔ．ｃｏｍ」に属するＦＱＤＮに対しての正引き問合せを受信した場合、マスタゾーンファイル３０５より情報を抽出し、返答する。
【００５４】
ネームサーバモジュール３０４は、管理外となるその他のドメインに関する正引き問合せを受信した場合、以前にＤＮＳサーバ１０９によって正引き問合せが行われた結果が記録されているキャッシュデータ３０６を検索する。このキャッシュデータ３０６はＤＮＳサーバ１０９内部のデータであり、Ｗｅｂクライアント１０６内のキャッシュデータ３０３とは独立して存在する。
【００５５】
キャッシュデータ３０６に該当データが存在した場合、ネームサーバモジュール３０４はキャッシュデータ３０６から該当データを取得し、その有効性のチェックを行う。この有効性のチェックについては後ほど詳細に説明するが、そのチェックの結果によって、該当データのＩＰｖ６アドレスをリゾルバモジュール３０２に返信して、本処理は終了する。例えば、このチェックの結果によって、有効性が否定された場合、ネームサーバモジュール３０４は、キャッシュデータ３０６にアドレスが存在していても、問合せを受けたアドレスがないことを示すメッセージを返信する。
【００５６】
一方、キャッシュデータ３０６に該当データが存在しない場合、つまり、問合せを受けた「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスがキャッシュデータ３０６に存在しない場合は、依頼を受けた正引き問合せの中継を行うべく、ＤＮＳサーバ１０９内のリゾルバモジュール３０７は、外部のＤＮＳサーバに対して正引き問合せを行う。このリゾルバモジュール３０７における正引き問合せは、ＲＦＣ１０３４ならびにＲＦＣ１０３５にて規定されるアルゴリズムに即して行われる。つまり、ルートＤＮＳサーバ、「ｎｅｔ」ＤＮＳサーバ、「ｓｅｒｖｅｒ．ｎｅｔ」ＤＮＳサーバと順番に配下のドメインを問合せていく。すなわち、ネームサーバモジュール３０４は、サーバ１０７（第１の装置）のアドレスの問合せをクライアント１０６（第２の装置）から受けると、リゾルバモジュール３０７は、サーバ１０７のアドレスをＤＮＳサーバ１０８（第３の装置）に問合せる。
【００５７】
「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の正引き問合せを受けたネームサーバモジュール３０９は、マスタゾーンファイル３１０に記載されている「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のレコードを検索し、該当のアドレスを抽出する。前述したとおり、上記での正引き問合せの全てにおいて、ＩＰｖ６アドレスの正引き問合せを初めに送信する。ネームサーバモジュール３０９がマスタゾーンファイル３１０より抽出した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスをＤＮＳ Ｒｅｓｐｏｎｓｅとしてリゾルバモジュール３０７に返信する。
【００５８】
ネームサーバモジュール３０９からの返信を受信したリゾルバモジュール３０７は、受信したデータをキャッシュデータ３０６に記録する。同時に、受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスを通信プロトコルチェックモジュール３０８に渡し、チェック処理を行う。通信プロトコルチェックモジュール３０８では、渡されたＩＰｖ６アドレスのチェック処理（接続試験）を行い、その結果をキャッシュデータ３０６に記録する。このチェック処理（接続試験）については後ほど詳細に説明する。
【００５９】
一方、ネームサーバモジュール３０４は、リゾルバモジュール３０７が「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスを取得し、キャッシュデータに３０６に記録したことを確認した時点で、キャッシュデータ３０６より該当データを取得し、問合せ元であるリゾルバモジュール３０２に返信を行う。すなわち、ネームサーバモジュール３０４は、ＤＮＳサーバ１０８（第３の装置）から得られたサーバ１０７（第３の装置）のアドレスをクライアント１０６（第２の装置）に通知する。
【００６０】
リゾルバモジュール３０２では、ネームサーバモジュール３０４からの返信を受信すると、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスが取得できたかどうかをチェックする。有効なＩＰｖ６アドレスを取得したリゾルバモジュール３０２は、該当データをキャッシュデータ３０３に記録し、クライアントアプリケーション３０１にＩＰｖ６アドレスを返信する。
【００６１】
一方、リゾルバモジュール３０２において、返信されたデータに有効なＩＰｖ６アドレスが存在しなかった場合、通信相手となる「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」にはＩＰｖ６アドレスが存在しないと判断し、リゾルバモジュール３０２は「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」ＤＮＳ Ｑｕｅｒｙメッセージ（つまり、ＩＰｖ４アドレスの正引き問合せ）を新たにネームサーバモジュール３０４に送信する。以下、処理内容はＩＰｖ６アドレスの正引き問合せと同じである。このＩＰｖ４アドレスの正引き問合せの結果、ＩＰｖ４アドレスも存在しないと判断した場合には、その旨を、クライアントアプリケーション３０１に通知する。
【００６２】
以上のようにして、クライアントアプリケーション３０１は、リゾルバモジュール３０２への「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」アドレス問合せに対する返信としてＩＰｖ６アドレス、もしくは、ＩＰｖ４アドレスを取得する。クライアントアプリケーション３０１は取得したアドレスを用いて通信相手のサーバアプリケーション３１１を特定し、通信を開始する。
【００６３】
図５で、ＤＮＳサーバ１０９のキャッシュデータ３０６におけるエントリデータの内容を説明する。
【００６４】
図中の一列が一つのエントリデータである。エントリデータにはいくつかの項目情報が含まれており、それぞれは以下のような情報を含んでいる。「ＦＱＤＮ」７０１はキャッシュデータとして保持するターゲットホストのＦＱＤＮを保持する。
【００６５】
「Ｔｙｐｅ」７０２はそのＦＱＤＮに定義されたレコードタイプを示している。このレコードタイプとは、ＤＮＳサーバのマスタゾーンファイル中の記述で、ＩＰｖ４アドレスの定義レコードは「Ａ」、ＩＰｖ６アドレスの定義レコードは「ＡＡＡＡ」としているので、キャッシュデータ内でも同一の表記を用いている。正引き問合せに含まれる情報は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」を問合せという内容なので、ＦＱＤＮとレコードタイプを保持することで、キャッシュデータ内に該当する情報があるかを検索することが可能となる。
【００６６】
次の項目である「Ａｄｄｒｅｓｓ」７０３にはＩＰｖ４アドレスもしくはＩＰｖ６アドレスが保持される。図からも明らかなように、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」というＦＱＤＮにＩＰｖ６アドレスとＩＰｖ４アドレスの両方がＤＮＳにて登録されていた場合、二つのエントリ７１１、７１２を持つこととなる。
【００６７】
ネームサーバモジュール３０９にてＦＱＤＮに対応するＩＰｖ４／ＩＰｖ６アドレスを返信する際、キャッシュ可能な時間を含めてアドレス情報を問合せ者（リゾルバモジュール３０２）に返信する。
【００６８】
「Ｃ−ＴＴＬ」７０４は、そのキャッシュ可能な時間の値であり、実際にキャッシュデータ３０６にて保持していられる時間を意味している。一方、「Ｒ−ＴＴＬ」７０５は、先に説明した「Ｃ−ＴＴＬ」７０４と同様にキャッシュ可能な時間であるが、この数値はリゾルバモジュール３０２からの正引き問合せに対する返信に含めるキャッシュ可能時間である。
【００６９】
本実施形態では、このデータ「Ｃ−ＴＴＬ」７０４と「Ｒ−ＴＴＬ」７０５を分割して管理し、ＦＱＤＮを管理するＤＮＳサーバ（ＤＮＳサーバ１０８にあたる）から通知されたＴＴＬ（キャッシュ可能時間「Ｃ−ＴＴＬ」７０４）をそのまま問合せ者（リゾルバモジュール３０２にあたる）に通知せずに、問合せ者（リゾルバモジュール３０２）に対してＴＴＬ＝０（「Ｒ−ＴＴＬ」７０５）としてアドレス情報を返信することで、問合せ側のキャッシュデータ（キャッシュデータ３０３にあたる）にアドレス情報がキャッシュさせない効果がある。
【００７０】
最後の「Ｃｈｅｃｋ」には、通信プロトコルチェックモジュール３０８における有効性チェックの結果を保持する。保持する値としては、「ＯＫ」が有効（接続試験成功）を、「ＮＧ」が無効（接続試験失敗）を示しており、「−」がチェック前のデータであることを示している。
【００７１】
表中の「ｍａｉｌ．ｄｕａｌ．ｂｉｚ」７１３のＩＰｖ６アドレス、「ｗｗｗ．ｖ４ｏｎｌｙ．ｃｏｍ」７１４のＩＰｖ４アドレスは、ＤＮＳサーバへの正引き問合せには成功したものの、アドレスの有効性チェックにて到達性がなかったので、無効なデータとしてキャッシュデータに保持されている例である。
【００７２】
また、「ｍａｉｌ．ｅｎｔｒｙ．ｎｅ．ｊｐ」７１５は、リゾルバモジュール３０７から新規にキャッシュデータに記録されたデータであるので、有効性チェックはチェック前の状態である。このとき、ネームサーバモジュール３０４はリゾルバモジュール３０２に対し、速やかに取得したアドレス情報を返信する必要があるので、初めての正引き問合せに対してはアドレスの有効性チェックの結果を待たずにアドレス情報を返信する。しかし、この際に返信したアドレスが無効な場合、クライアント側のキャッシュデータ３０３に該当のアドレス情報を保持されては、次回からの接続時にも、タイムアウトの問題が発生してしまうので、ＴＴＬ＝０として返信するために、Ｒ−ＴＴＬの値を「０」としている。
【００７３】
図６を用いて、ＤＮＳサーバ１０９のネームサーバモジュール３０４にて処理されるフローを説明する。このフローは、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたプログラム、あるいはＦＤ９０８より供給されるプログラムの一部を示す。ＣＰＵ９０１は、モジュール３０４を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、以下の処理を実現する。
【００７４】
４０１はネームサーバモジュール３０４が管理するドメイン以外に関する正引き問合せを待ち受けるループである。このリゾルバモジュール３０２からの正引き問合せは、ＮＩＣ９０６により受信される。ＣＰＵ９０１は、リゾルバモジュール３０２からの「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の正引き問合せを受信した場合、４０２へと処理が進む。この際、ＩＰｖ６アドレスの正引き問合せでもＩＰｖ４アドレスの正引き問合せでも同様に機能する。
【００７５】
なお、ネームサーバモジュール３０４は、管理しているドメイン「ｃｌｉｅｎｔ．ｃｏｍ」に属するＦＱＤＮに対しての正引き問合せを受信した場合は、マスタゾーンファイル３０５より情報を抽出し、返答する。
【００７６】
４０２ではキャッシュデータ３０６に問合せのＦＱＤＮに対応するＩＰｖ４／ＩＰｖ６アドレス（リゾルバモジュール３０２から問合せられた方）が存在するかを検索する。検索の結果は４０３にて判定され、該当データ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４アドレス、またはＩＰｖ６アドレス）が発見された場合は４０７に進み、該当データが発見されなかった場合には４０４へ進む。
【００７７】
４０４ではリゾルバモジュール３０７に対し、受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の正引き問合せを外部のＤＮＳサーバに向けて行うよう、問合せ内容をリゾルバモジュール３０７に送信し、問合せの依頼を行う。リゾルバモジュール３０７も、ネームサーバモジュール３０４と同様に、ＣＰＵ９０１が、プログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、実現される処理モジュールである。
【００７８】
上述のように、リゾルバモジュール３０７により「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４／ＩＰｖ６アドレスが解決し、キャッシュデータ３０６を通してその結果を取得する。なお、この問合せ依頼に関して、ＩＰｖ４／ＩＰｖ６どちらのアドレスの正引き問合せかは、前記４０１にて受信した正引き問合せの内容（ＩＰｖ４又はＩＰｖ６のどちらに対する正引き問合せか）と同一のものである。
【００７９】
ＣＰＵ９０１は、ネームサーバモジュール３０４の処理を実行し、４０４において、リゾルバモジュール３０７による処理に移行し、リゾルバモジュール３０７による処理の結果が出ると、ネームサーバモジュール３０４の処理を再開する。
【００８０】
ネームサーバモジュール３０４は、キャッシュデータ３０６を通して得られた結果を４０５にて判定する。４０５における判定にて、正引き問合せに対してＩＰｖ４／ＩＰｖ６アドレスを取得できた場合には、４０７に進み、取得できなかった場合には４０６に進む。該当のＩＰｖ４／ＩＰｖ６アドレスが取得できなかった場合には４０６にてリゾルバモジュール３０７にて得られた結果と同一の返信メッセージ（Ｒｅｓｐｏｎｓｅ（ｎｏｔｈｉｎｇ）メッセージ、あるいはＥｒｒｏｒメッセージ）をリゾルバモジュール３０２に向けて送信し、待ち受けループ４０１に処理が戻る。
【００８１】
一方、４０５における判定にて、該当のＩＰｖ４／ＩＰｖ６アドレスを取得できた場合、及び、４０３における判定にて、キャッシュデータ３０６の検索によりＩＰｖ４／ＩＰｖ６アドレスを取得できた場合、４０７にてそのアドレスの有効性に関してチェックを行う。アドレスの有効性の処理に関しては、通信プロトコルチェックモジュール３０８にて行われており、図５に示すように、その結果７０６がキャッシュデータ３０６のエントリに記録されている。そのチェック結果を抽出し、４０８にて判定している。４０８での判定では、キャッシュデータ３０６のエントリ内にある「ｃｈｅｃｋ」項目７０６を参照し、この項目が「ＯＫ」の場合は有効な（接続試験に成功した）アドレス、「ＮＧ」の場合は無効な（接続試験に失敗した）アドレスと判定する。
【００８２】
なお、この判定項目で「−」の場合が存在するが、それは通信プロトコルチェックモジュール３０８にてチェック前のデータであることを示し、４０４でリゾルバへの問合せ依頼をした際に現れる。このチェック前のデータの場合は、有効なアドレスとして判断される。
【００８３】
４０１にて受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」への正引き問合せがＩＰｖ６アドレスを求めるものである場合は、４０９にて有効なＩＰｖ６アドレスをキャッシュデータ３０６より抽出し、リゾルバモジュール３０２に対してＲｅｓｐｏｎｓｅ ＡＡＡＡメッセージにて送信する。その際、メッセージ内のＴＴＬ値（このＩＰｖ６アドレスをキャッシュデータ３０３にてキャッシュできる時間）に、キャッシュデータ３０６内の「Ｒ−ＴＴＬ」項目の値を代入して送信する。
【００８４】
また、４０１にて受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」への正引き問合せがＩＰｖ４アドレスを求めるものである場合は、４１１にて有効なＩＰｖ４アドレスをキャッシュデータ３０６より抽出し、リゾルバモジュール３０２に対してＲｅｓｐｏｎｓｅ Ａメッセージにて送信する。その際にも、メッセージ内のＴＴＬ値に、キャッシュデータ３０６内の「Ｒ−ＴＴＬ」項目の値を代入して送信する。
【００８５】
４０８にて無効と判断された場合、４１０にてリゾルバモジュール３０２に対してＲｅｓｐｏｎｓｅ（ｎｏｔｈｉｎｇ）メッセージを送信する。以上、４０９〜４１１の処理が終了した場合は、４０１の待ち受けループに処理が戻る。
【００８６】
次に、図７にて、ＤＮＳサーバ１０９のリゾルバモジュール３０７の処理フローを説明する。このフローは、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたプログラム、あるいはＦＤ９０８より供給されるプログラムの一部を示す。ＣＰＵ９０１は、モジュール３０７を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、以下の処理を実現する。
【００８７】
ＣＰＵ９０１は、ネームサーバモジュール３０４の処理４０３において、該当するキャッシュデータがない場合、リゾルバモジュール３０７の処理を行う。すなわち、ネームサーバモジュール３０４にて受信した正引き問合せに対する該当データがキャッシュデータ３０６に存在しない場合、リゾルバモジュール３０７は、５０１にて、ネームサーバモジュール３０４より正引き問合せの依頼を受理する。ここで、リゾルバモジュール３０７がネームサーバモジュール３０４より委託された正引き問合せ内容は、リゾルバモジュール３０２からネームサーバモジュール３０４に問合せられた「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４／ＩＰｖ６アドレスの正引き問合せ内容と同一のものである。
【００８８】
５０２では、５０１にて受理した内容の正引き問合せを外部のＤＮＳサーバに向けて実行する。この５０２にて実行される正引き問合せは、前述したように、ＲＦＣ１０３４ならびにＲＦＣ１０３５にて規定されるアルゴリズムに即して行われる。つまり、ルートＤＮＳサーバ、「ｎｅｔ」ＤＮＳサーバ、「ｓｅｒｖｅｒ．ｎｅｔ」ＤＮＳサーバと順番に配下のドメインを問合せていく。
【００８９】
「ｓｅｒｖｅｒ．ｎｅｔ」ドメインの管理サーバであるＤＮＳサーバ１０８に対して送信する「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する正引き問合せで利用される通信プロトコルは、上位のＤＮＳサーバである「ｎｅｔ」ドメイン管理サーバによって通知されたＤＮＳサーバ１０７のアドレスによって決定される。「ｎｅｔ」ドメインを管理するＤＮＳサーバではＩＰｖ６アドレスでのレコード登録を受け付けていない場合、リゾルバモジュール３０７とネームサーバモジュール３０９の通信にはＩＰｖ４プロトコルが利用される。
【００９０】
そして、５０３にて外部ＤＮＳサーバから、問合せに対する返信を受信する。５０４では５０３にて受信した問合せに対する返信の内容をチェックし、場合分けを行う。以下、５０５〜５０８がその場合分けである。
【００９１】
５０５は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスを求める正引き問合せが成功した場合であり、ＩＰｖ６アドレス情報が含まれたＲｅｓｐｏｎｓｅ ＡＡＡＡメッセージを受信する。５０８は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４アドレスを求める正引き問合せが成功した場合であり、ＩＰｖ４アドレス情報が含まれたＲｅｓｐｏｎｓｅ Ａメッセージを受信する。以上の５０５、５０８はともに５０２における正引き問合せに対して成功した場合であり、どちらも５１０の処理に進む。
【００９２】
一方、５０６は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」にＩＰｖ６アドレスまたはＩＰｖ４アドレスを求める正引き問合せに対して、該当のアドレス情報を持ったレコードが存在しない場合であり、アドレス情報が含まれていないＲｅｓｐｏｎｓｅ （ｎｏｔｈｉｎｇ）メッセージを受信する。５０７は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」にＩＰｖ６アドレスまたはＩＰｖ４アドレスを求める正引き問合せに対して、何らかのエラーが発生した場合（外部ＤＮＳサーバにて問合せのレコードタイプが理解できなかった場合や、ターゲットとなる外部ＤＮＳサーバが見つからなかった場合など）であり、Ｅｒｒｏｒメッセージを受信する。これら５０６、５０７はともに５０２における正引き問合せに対して失敗した場合であり、どちらも５０９にてネームサーバモジュール３０４に返信内容（Ｒｅｓｐｏｎｓｅ（ｎｏｔｈｉｎｇ）メッセージあるいはＥｒｒｏｒメッセージ）を伝達し、ネームサーバモジュール３０４に、委託された正引き問合せの終了を通知し、処理を終了する。そして、ＣＰＵ９０１は、ネームサーバモジュール３０４の処理４０５を行う。この場合は、４０６で、リゾルバモジュール３０２に取得失敗を返信する。
【００９３】
正引き問合せに成功した場合は、５１０にてキャッシュデータ３０６に記録する内容を作成する。この各項目情報に関しては、図５を参照して、前述した通りである。
【００９４】
すなわち、ここでの作成データには、ＦＱＤＮ「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」７０１と、そのＩＰｖ４／ＩＰｖ６アドレス７０３、レコードタイプ（「Ａ」（ＩＰｖ４）又は「ＡＡＡＡ」（ＩＰｖ６））７０２、Ｃ−ＴＴＬ（外部ＤＮＳサーバより通知されたキャッシュ可能時間）７０４のＤＮＳキャッシュデータ標準の項目情報に加えて、チェック判定結果７０６、Ｒ−ＴＴＬ（対クライアントへの実キャッシュ可能時間）７０５の項目情報が含まれる。５１０でのデータ作成において、チェック判定結果項目には「−」（チェック前データ）を代入し、実ＴＴＬ（Ｒ−ＴＴＬ）７０５には「０」を代入する。ここで、実ＴＴＬ（Ｒ−ＴＴＬ）の値は「０」に限らず、「１」あるいは「２」、「３」に設定しても、実用上、大きな支障はない。
【００９５】
５１１において、５１０にて作成したデータをキャッシュデータ３０６に記録し、ネームサーバモジュール３０４に、委託された正引き問合せの終了を通知する。その後、ＣＰＵ９０１は、ネームサーバモジュール３０４の処理４０５を行う。また、５１２ではキャッシュデータ３０６に記録したＩＰｖ４／ＩＰｖ６アドレスが有効かどうかのチェック（接続試験）を行うために、通信プロトコルチェックモジュール３０８に、５１１にて記録したデータを送信し、アドレスのチェック処理を依頼し、全処理を終了する。
【００９６】
図８で、ＤＮＳサーバ１０９の通信プロトコルチェックモジュール３０８における処理フローを説明する。このフローは、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたプログラム、あるいはＦＤ９０８より供給されるプログラムの一部を示す。ＣＰＵ９０１は、モジュール３０８を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、以下の処理を実現する。
【００９７】
この通信プロトコルチェック処理は、二つのタイミングで起動される。まず一つはリゾルバモジュール３０７からＩＰｖ４／ＩＰｖ６アドレスを通知された場合である。これは、新規にキャッシュデータ３０６にアドレス情報が記録された際に発生する事例であり、そのＩＰｖ４／ＩＰｖ６アドレスの有効性をチェックする必要がある。
【００９８】
もう一つの起動のタイミングは、ある一定時間（例えば、５分）が経過した場合である。これは、キャッシュデータ３０６に記録されているＩＰｖ４／ＩＰｖ６アドレスの有効性を定期的にチェックし、刻々と変化するネットワーク情報に適した評価を行うためである。
【００９９】
６０１では以上の二つのタイミングによる起動（リゾルバモジュール３０７からのチェック要請、または、ある一定時間経過による定期チェック）を判定する。リゾルバモジュール３０７からＩＰｖ４／ＩＰｖ６アドレスを受信した場合、すなわち、ＣＰＵ９０１が、リゾルバモジュール３０７の処理において、外部サーバから有効なＩＰｖ４／ＩＰｖ６アドレスが得て、リゾルバモジュール３０７の処理を終了した場合、ＣＰＵ９０１は、６０２において該当アドレスの有効性チェック処理を行う。
【０１００】
本実施形態でのアドレス（例えば、Ｗｅｂサーバ１０７のアドレス）の有効性チェックは、ＩＰｖ４／ＩＰｖ６アドレスがＤＮＳサーバ１０９からＷｅｂサーバ１０７までのそれぞれの通信プロトコルでの接続性を確認する（接続試験を行う）ことで、アドレスの有効性を判定している。そこで、６０２にて、疎通チェックを対象となるＩＰｖ４／ＩＰｖ６アドレスに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、そのメッセージに対する応答を判断し、その判断に基づき、アドレスの有効性を確認する。このチェック処理に関しては６１１〜６１６にて詳しく説明する。
【０１０１】
６０２でのアドレス有効性チェック処理を行ったデータは、６０３にてキャッシュデータ３０６に既に記録されているエントリデータの「Ｃｈｅｃｋ」欄７０６、「Ｒ−ＴＴＬ」欄７０５を上書き修正し、６０１へ戻る。
【０１０２】
一方、ある一定時間（例えば、５分）を経過した場合の処理は、６０４に進む。６０４ではキャッシュデータ３０６に記録されているエントリデータを取得する。そして、６０５において取得したエントリからＩＰｖ４／ＩＰｖ６アドレスを抽出し、６０６においてアドレス有効性チェック処理（接続試験）を行う。６０６のチェック処理も６０２と同様の処理を行う。そして、６０８にて、６０３と同様に、６０６のチェック処理の結果を、キャッシュデータ３０６に反映させる。この６０４、６０５、６０６の処理は、キャッシュデータ３０６に格納されているエントリのそれぞれについて、すなわち、キャッシュデータ３０６に格納されているアドレスのそれぞれについて、接続試験を行い、その結果を、チェック欄７０６に格納する。
【０１０３】
引き続き、図９で、６０２、６０６で行われるアドレス有効性チェック（接続試験）の処理フローを説明する。
【０１０４】
本実施形態でのアドレス有効性チェックは、ＩＰｖ４／ＩＰｖ６アドレスがＤＮＳサーバ１０９からＷｅｂサーバ１０７までのそれぞれの通信プロトコルでの接続性を確認する（接続試験を行う）ことで、アドレスの有効性を判定している。
【０１０５】
すなわち、疎通チェックを対象となるＩＰｖ４／ＩＰｖ６アドレスに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、そのメッセージに対する応答を判断し、その判断に基づき、アドレスの有効性を確認する。
【０１０６】
本実施形態では、アドレスの有効性をチェックする（接続性を試験する）ためのメッセージとして、ＩＣＭＰ ｅｃｈｏメッセージを用いる。すなわち、６１１にてＩＣＭＰ ｅｃｈｏメッセージによる疎通チェックを対象となるＩＰｖ４／ＩＰｖ６アドレスに対して、それぞれの通信プロトコルを利用して送信する。ＩＰｖ６アドレスのチェックには、ＩＰｖ６の通信プロトコルを用いて、ＩＣＭＰ ｅｃｈｏメッセージを送信し、ＩＰｖ４アドレスのチェックには、ＩＰｖ４の通信プロトコルを用いて、ＩＣＭＰ ｅｃｈｏメッセージを送信する。
【０１０７】
６１２にて、６０２あるいは６０６で発行したＩＣＭＰ ｅｃｈｏに対する返信があるかを判定し、所定時間内に（例えば、１秒以内）、返信があった場合にはそのアドレスは有効であると判断し、６１３にて、キャッシュデータ３０６に記録するエントリデータ内の項目であるチェック判定結果の欄に「ＯＫ」を代入する。
【０１０８】
一方、所定時間内に（例えば、１秒）ＩＣＭＰ ｅｃｈｏに対する返信がない場合は、そのアドレスは無効と判断し、６１５にて、キャッシュデータ３０６に記録するエントリデータ内の項目であるチェック判定結果の欄に「ＮＧ」を代入する。続いて、６１６にて、同じくエントリデータ内のＲ−ＴＴＬ（対クライアントへの実キャッシュ可能時間）７０５の値を「０」し、チェック処理を終了する。なお、所定時間内に（例えば、１秒以内）、ＩＣＭＰ ｅｃｈｏメッセージが宛先に届かないことを示すメッセージが、インターネット１０４あるいは１０５内のサーバから、送られてきた場合も、チェック判定結果の欄に「ＮＧ」を代入し、Ｒ−ＴＴＬの値を「０」にする。ここで、チェック判定結果の欄が「ＮＧ」ならば、４１０で、クライアントには、Ｒｅｓｐｏｎｓｅ （ｎｏｔｈｉｎｇ）メッセージを返信するので、Ｒ−ＴＴＬの値は「０」に設定しなくても、問題ない。
【０１０９】
６１３、６１４、６１５、６１６で、作成したエントリデータは、６０３、６０８において、キャッシュデータ３０６に格納される。なお、６０６では、キャッシュデータ３０６に記録されているＩＰｖ４／ＩＰｖ６アドレスのそれぞれに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、６１２で返信があれば、６１３、６１４の処理を行い、所定時間内に、返信がない場合、６１５、６１６の処理を行う。
【０１１０】
なお、このアドレスの有効性をチェックするために送信したメッセージの返信を待つ時間は、１秒に限らず、例えば、３０秒に設定してもよい。
【０１１１】
他の形態では、６０２でのアドレス有効性チェックと６０６でのアドレス有効性チェックで、返信を待つ時間として、異なる時間を用いる。例えば、６０２でのアドレス有効性チェックでは、３０秒、６０６のアドレス有効性チェックでは、１秒、メッセージの返信を待って、アドレス有効性を判断する。
【０１１２】
なお、ＤＮＳキャッシュデータは、ＴＴＬ値を越える時間、キャッシュすることが許されない仕組みとなっている。そのため、図には示さないが、例えば、１秒ごとに、キャッシュ時間Ｃ−ＴＴＬ（外部ＤＮＳサーバより通知されたキャッシュ可能時間）７０４の値を１つ減らして、Ｃ−ＴＴＬ値７０４の判定を行い、既に期限切れのエントリは、キャッシュデータ３０６から削除する。なお、Ｒ−ＴＴＬ（対クライアントへの実キャッシュ可能時間）７０５に関しては、値が「０」でなければ、１つ減らす。
【０１１３】
図１０は本実施形態の通信の流れにおいて、Ｗｅｂクライアント１０６からＷｅｂサーバ１０７に対し、ＩＰｖ６通信プロトコルでの到達が不可能な状況での通信パケットの内容とそのフローである。以下のフローにおいて、ＤＮＳサーバ１０９の動作は、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたソフトウェア、あるいはＦＤ９０８より供給されるソフトウェアであるモジュール３０４、３０７、３０８により実現される。図６、図７、図８、図９は、連携して動作することにより、第１の装置のアドレスを用いて前記第１の装置との接続試験を行う試験ステップ（６０６）と、前記試験ステップでの接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信する返信ステップ（４１０）とを有するアドレスの問合せに対する返信プログラムであり、また、第１の装置のアドレスの問合せを第２の装置から受けると（４０１）、前記第１の装置のアドレスを第３の装置に問合せ（５０２）、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知し（４０９、４１１）、前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知するアドレス通知プログラムである。
【０１１４】
Ｗｅｂクライアント１０６は、最寄りのＤＮＳサーバ１０９に対して正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「ＡＡＡＡ」の問合せ）ＡＡＡＡ Ｑｕｅｒｙ８０１を送信する。
【０１１５】
ＤＮＳサーバ１０９は、この正引き問合せ８０１を受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、該当するデータがないことから（図６の４０３でＮｏ）、対象となるＦＱＤＮの管理を行っているＤＮＳサーバ１０８に正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「ＡＡＡＡ」の問合せ）ＡＡＡＡ Ｑｕｅｒｙ ８０２を行う（図６の４０４、図７の５０１、５０２）。すなわち、ＤＮＳサーバ１０９は、サーバ１０７（第１の装置）のアドレスの問合せをクライアント１０６（第２の装置）から受けると、サーバ１０７のアドレスをＤＮＳサーバ（第３の装置）に問合せる。
【０１１６】
問合せ８０２に対し、ＤＮＳサーバ１０８は、問合せのＦＱＤＮに対するＩＰｖ６アドレスを含む問合せへの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」は「２００１：３４０：０：１：：１」、「ＴＴＬ＝１００００」）Ｒｅｓｐｏｎｓｅ ＡＡＡＡ ８０３を、ＤＮＳサーバ１０９に送信する。
【０１１７】
ＤＮＳサーバ１０９は、この返信８０３を受信し（図７の５０３、５０４、５０５、５１０、５１１）、迅速にＷｅｂクライアント１０６に対して問合せの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」は「２００１：３４０：０：１：：１」、「ＴＴＬ＝０」）Ｒｅｓｐｏｎｓｅ ＡＡＡＡ ８０４を送信する（図６の４０５のＹｅｓ、４０７、４０８、４０９）。すなわち、ＤＮＳサーバ１０９は、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスをクライアント１０６に通知する。ＤＮＳサーバ１０６は、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスの有効期限Ｃ−ＴＴＬ７０４より短い有効期限Ｒ−ＴＴＬ７０５（その値は、例えば、「０」）を、サーバ１０７のアドレスの有効期限として、クライアント１０６に通知する。
【０１１８】
返信８０４を受信したＷｅｂクライアントは「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレス「２００１：３４０：０：１：：１」を取得したので、目的のサーバ１０７にＩＰｖ６通信プロトコルを利用して接続８０５を試みるが、途中でネットワークが切断状態であるために接続はできない。
【０１１９】
一方、ＤＮＳサーバ１０９でも、ＩＰｖ６アドレス通知Ｒｅｓｐｏｎｓｅ ＡＡＡＡ ８０４とほぼ同時刻に、ＩＰｖ６アドレスの有効性チェックのために、ＩＣＭＰ ｅｃｈｏメッセージ８０６を対象アドレス「２００１：３４０：０：１：：１」に送信する（図７の５１２、図８の６０１、６０２）。メッセージ８０６の通信に関しても、Ｗｅｂサーバ１０７には到達しないので（図９の６１２はＮｏ）、アドレス有効性チェック８０７はＮＧ（接続試験失敗）となる（６１５）。このＩＰｖ６アドレスの接続性試験は、ＩＰｖ６の通信プロトコルを用いて、行う。
【０１２０】
Ｗｅｂクライアント１０６は、接続８０５から通信確立失敗までタイムアウト待ちを行い、そのタイムアウトの後、ＩＰｖ４アドレスを取得すべく最寄りのＤＮＳサーバ１０９に対して正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「Ａ」の問合せ）Ａ Ｑｕｅｒｙ ８０８を行う。
【０１２１】
ＤＮＳサーバ１０９は、この正引き問合せ８０８を受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、該当するデータがないことから（図６の４０３のＮｏ）、対象となるＦＱＤＮの管理を行っているＤＮＳサーバ１０８に正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「Ａ」の問合せ）Ａ Ｑｕｅｒｙ ８０９を行う（図６の４０４、図７の５０１、５０２）。
【０１２２】
問合せ８０９に対し、ＤＮＳサーバ１０８は、問合せのＦＱＤＮに対するＩＰｖ４アドレスを含む問合せへの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」は「１７２．１６．０．１」、「ＴＴＬ＝１００００」）Ｒｅｓｐｏｎｓｅ Ａ ８１０を、ＤＮＳサーバ１０９に送信する。
【０１２３】
ＤＮＳサーバ１０９は、この返信８１０を受信し（図７の５０３、５０４、５０８、５１０、５１１）、迅速にＷｅｂクライアント１０６に対して問合せの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」は「１７２．１６．０．１」、「ＴＴＬ＝０」）Ｒｅｓｐｏｎｓｅ Ａ ８１１を送信する（図６の４０５のＹｅｓ、４０７、４０８、４１１）。
返信８１１を受信したＷｅｂクライアントは「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４アドレス「１７２．１６．０．１」を取得したので、目的のサーバ１０７にＩＰｖ４通信プロトコルを利用して接続８１２を試みる。この接続８１２は成功するので、Ｗｅｂクライアント１０６には、Ｗｅｂサーバ１０７のデータが受信される。
【０１２４】
一方、ＤＮＳサーバ１０９でも、ＩＰｖ４アドレス通知Ｒｅｓｐｏｎｓｅ Ａ８１１とほぼ同時刻に、ＩＰｖ４アドレスの有効性チェックのために、ＩＣＭＰ ｅｃｈｏメッセージ８１３を対象アドレス「１７２．１６．０．１」に送信する（図７の５１２、図８の６０１、６０２）。メッセージ８１３に対する返信が、Ｗｅｂサーバ１０７よりＩＣＭＰ Ｒｅｓｐｏｎｓｅ ８１４として送信されるので（図９の６１２は、Ｙｅｓ）、アドレス有効性チェック７０６はＯＫ（接続試験成功）となる（６１３）。なお、このＩＰｖ４アドレスの接続性試験は、ＩＰｖ４の通信プロトコルを用いて、行う。
【０１２５】
その後、新たにＷｅｂサーバ１０７への接続要求が発生した際（例えば、Ｗｅｂ表示上のリンクを選択し、同じＷｅｂサーバ内の別のデータを取得するような場合）、Ｗｅｂクライアント１０６はもう一度最寄りのＤＮＳサーバ１０９にＩＰｖ６アドレスの正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「ＡＡＡＡ」の問合せ）ＡＡＡＡ Ｑｕｅｒｙ ８１５を行う。
【０１２６】
ＤＮＳサーバ１０９は、この正引き問合せ８１５を受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、図１０の８０７でアドレス有効性チェックの行われたキャッシュデータから、ＩＰｖ６アドレスのチェック結果が「ＮＧ」であることを知るので（図６の４０３のＹｅｓ、４０７、４０８のＮｏ）、Ｗｅｂクライアント１０６への返信にはアドレス無しメッセージ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」はありません）Ｒｅｓｐｏｎｓｅ （ｎｏｔｈｉｎｇ） ８１６を送信する（図６の４１０）。すなわち、ＤＮＳサーバ１０９は、サーバ１０７（第１の装置）のアドレスを用いてサーバ１０７との接続試験（８０６、８０７）を行い、その接続試験が失敗した場合には、サーバ１０７のアドレスがないことを示すメッセージを返信する。
【０１２７】
この返信８１６を受けたＷｅｂクライアントは、続いてＩＰｖ４アドレスの正引き問合せＡ Ｑｕｅｒｙ ８１７を送信する。ＤＮＳサーバ１０９は、同様に、この正引き問合せを受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、アドレス有効性チェックの行われたキャッシュデータから、ＩＰｖ４アドレスを検索し、チェック結果の「ＯＫ」を確認してから（図６の４０３のＹｅｓ、４０７、４０８）、問合せ返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」は「１７２．１６．０．１」、「ＴＴＬ＝１００００」）Ｒｅｓｐｏｎｓｅ Ａ ８１８を送信する（４１１）。
【０１２８】
返信８１８によりＷｅｂサーバ１０７のＩＰｖ４アドレス取得に成功したＷｅｂクライアント１０９は、ＩＰｖ４通信プロトコルを利用した接続８１９を行い、Ｗｅｂサーバ１０７からデータを取得する。
【０１２９】
＜他の実施の形態＞
上記実施形態では、ＤＮＳサーバ１０９のネームサーバモジュール３０４は、リゾルバモジュール３０７が外部のＤＮＳサーバ１０７から受け取ったアドレスを、通信プロトコルチェックモジュール３０８が有効かチェックする前に、クライアント１０６のリゾルバモジュール３０２に通知したが、他の形態では、ＤＮＳサーバ１０９のネームサーバモジュール３０４は、リゾルバモジュール３０７が外部のＤＮＳサーバ１０７から受け取ったアドレスを、通信プロトコルチェックモジュール３０８が有効かチェックした後、クライアント１０６のリゾルバモジュール３０２に通知する。
【０１３０】
この他の形態では、リゾルバモジュール３０７は、外部サーバへの正引き問合せが成功した場合、通信プロトコルチェックモジュール３０８によるアドレスの有効性のチェックが終了した後、ネームサーバモジュール３０４に正引き問合せの終了を通知する。そして、ネームサーバモジュール３０４は、通信プロトコルチェックモジュール３０８による有効性のチェックが行われたアドレスについて、クライアント１０６のリゾルバモジュール３０２に対して、アドレスの有効性に基づき（４０７、４０８）、有効であれば、アドレスを返信し（４０９、４１１）、有効でなければ、取得失敗を返信する（４１０）。
【０１３１】
なお、この他の形態では、通信プロトコルチェックモジュール３０８により無効と判断されたアドレスは、キャッシュデータ３０６から削除してもよい。このように削除する形態では、Ｒ−ＴＴＬ７０５、チェック欄７０６は、設けなくてもよい。
【０１３２】
上記実施形態において、Ｗｅｂクライアント１０６とＷｅｂサーバ１０７は、Ｗｅｂアプリケーションに限定されるものではなく、どのようなネットワークアプリケーションであってもよい。
【０１３３】
また、上記実施形態において、ユーザネットワーク１０１に接続したＤＮＳサーバ１０９には、ユーザネットワーク１０１に属するホスト端末群のドメインを管理するマスタゾーンファイル３０５を、必ずしも、保持する必要はなく、単なるＤＮＳキャッシュサーバとしての機能のみを提供するものであってよい。
【０１３４】
また、上記実施形態において、ドメイン管理ネットワーク１０２とサーバネットワーク１０３は必ずしも独立したネットワークである必要はなく、同一のネットワーク上にＤＮＳサーバ１０８とＷｅｂサーバ１０７が存在してもよい。
【０１３５】
また、上記実施形態において、ＤＮＳサーバ１０９は必ずしもユーザネットワーク１０１に属している必要はなく、ユーザネットワークに極力近ければよく、例えば、クライアント１０６にインターネットサービスを提供しているＩＳＰ内のネットワークに存在してもよい。
【０１３６】
また、上記実施形態において、各ホストに割当てたドメイン名、ＦＱＤＮ、ＩＰｖ４ネットワークアドレス、ＩＰｖ４アドレス、ＩＰｖ６ネットワークアドレス、ＩＰｖ６アドレスは一例に過ぎず、その他の任意のドメイン名、ＦＱＤＮ、ＩＰｖ４ネットワークアドレス、ＩＰｖ４アドレス、ＩＰｖ６ネットワークアドレス、ＩＰｖ６アドレスであってもよい。
【０１３７】
【発明の効果】
本発明によれば、第１の装置のアドレスを用いて前記第１の装置との接続試験を行い、前記接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信することにより、前記第２の装置が、前記第１の装置のアドレスが取得できても、接続できない事態を防ぐことが可能となる。
【０１３８】
更に、前記試験ステップでは、前記第１の装置のアドレスに対応するプロトコルで、前記第１の装置との接続試験を行うことにより、プロトコル毎に、前記第１の装置に接続できない事態を防ぐことが可能となる。
【０１３９】
また、第１の装置のアドレスの問合せを第２の装置から受けると、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知する場合に、前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することにより、前記第２の装置が、前記第１の装置のアドレスが取得できても、接続できない事態を減らすことが可能となる。
【図面の簡単な説明】
【図１】ネットワークの構成図である。
【図２】各ネットワークの属するドメイン名と、各ホストに割当てたＦＱＤＮの一例の図である。
【図３】本実施形態での機能を実現するソフトウェアプログラムを動作させる構成の一例の図である。
【図４】ＷｅｂクライアントとＷｅｂサーバの通信確立までの処理概要を示したモジュール図である。
【図５】ＤＮＳサーバのキャッシュデータにおけるエントリデータの内容の図である。
【図６】ＤＮＳサーバのネームサーバモジュールにて処理されるフローの図である。
【図７】ＤＮＳサーバのリゾルバモジュールにおける処理フローの図である。
【図８】ＤＮＳサーバの通信プロトコルチェックモジュールにおける処理フローの図である。
【図９】アドレス有効性チェック（接続試験）の処理フローの図である。
【図１０】ＩＰｖ６通信プロトコルでの到達が不可能な状況での通信パケットの内容とそのフローの図である。
【符号の説明】
１０６ Ｗｅｂクライアント
１０７ Ｗｅｂサーバ
１０８ ＤＮＳサーバ
１０９ ＤＮＳサーバ
【発明の属する技術分野】
本発明は、アドレスの問合せに対する返信方法、プログラム、装置、及び、アドレス通知方法、プログラム、装置に関する。
【０００２】
【従来の技術】
近年、現在のインターネットを支える基盤プロトコルであるＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）の次世代バージョンであるＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）の検討が開始された。
【０００３】
ＩＰｖ６はＩＰｖ４に置き換わる技術であるが、これまでのＩＰｖ４のネットワークを排除するものではなく、ＩＰｖ４からＩＰｖ６への移行技術も検討されている。移行技術にはトンネル技術、トランスレート技術、デュアル技術が存在する。
【０００４】
このうち、デュアル技術は、ＩＰｖ４とＩＰｖ６を同一のネットワーク上で運用することにより、ネットワーク上で利用する機器やアプリケーションのスムーズな移行を助ける技術である。これからは、このデュアル技術を用いたＩＰｖ４／ＩＰｖ６デュアル環境のネットワークが広がり、インターネット上で利用されるすべてのアプリケーションがＩＰｖ６に完全に移行されるまでの相当長い期間、このデュアル環境ネットワークが利用されると考えられる。
【０００５】
このデュアル環境におけるＩＰｖ４／ＩＰｖ６アクセス可能なＥ−ＭａｉｌやＷｅｂなどのサービスを利用した際、ＩＰｖ４とＩＰｖ６のどちらの通信プロトコルを利用して通信するかを決定する「通信プロトコル選択手順」では、通信相手のサーバの指定をＩＰｖ４／ＩＰｖ６アドレスで指定した場合、それぞれ指定された通信プロトコルを利用する。
【０００６】
しかしながら、通信相手のサーバの指定をＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）で指定した場合、どちらの通信プロトコルを利用して通信するかは、以下の手順で決定される。
【０００７】
すなわち、
１．ＩＰｖ６アドレスをＤＮＳに問合せる。
２．ＩＰｖ６アドレスの取得に成功すればＩＰｖ６で通信を行う。
３．ＩＰｖ６アドレスの取得に失敗した場合、続いてＩＰｖ４アドレスをＤＮＳに問合せる。
４．ＩＰｖ４アドレスの取得に成功すればＩＰｖ４で通信を行う。
５．ＩＰｖ４アドレスの取得も失敗した場合は、サーバが存在しないことになりエラー終了となる。
【０００８】
これは、現状の各種アプリケーションの動作内容を解析しても、ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）にて規定している「Ｂａｓｉｃ Ｓｏｃｋｅｔ Ｉｎｔｅｒｆａｃｅ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰｖ６」（ＲＦＣ２１３３、ＲＦＣ２５５３）を参照しても、上記の通信プロトコル選択手順を行っている。
【０００９】
ＷｅｂやＥ−Ｍａｉｌなど、一般的なインターネットアプリケーションでは、ＤＮＳを利用した通信相手の特定を行っている。
【００１０】
しかしながら、ＩＰｖ４／ＩＰｖ６アクセス可能なサーバでは、一つのネットワークインターフェースにＩＰｖ４／ＩＰｖ６それぞれのアドレスを設定しているが、サーバ名としてはＦＱＤＮを一つだけ登録することがしばしばである。
【００１１】
つまり、ＩＰｖ４／ＩＰｖ６アクセス可能なＷｅｂサーバ「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」が存在した場合、このサーバにはＩＰｖ４アドレスとＩＰｖ６アドレスが対応していることになる。ＤＮＳへの登録内容においても、ＩＰｖ４アドレスを設定する「Ａ」レコードと、ＩＰｖ６アドレスを設定する「ＡＡＡＡ」レコードの二つを、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に設定することが一般的に多い。
【００１２】
通信相手のサーバの指定をＩＰｖ４／ＩＰｖ６アドレスで指定する通信プロトコル選択手順は利用されにくく、通信相手のサーバの指定をＦＱＤＮで指定することが多いので、ＩＰｖ６通信プロトコルを優先的に使用するアクセスがしばしばである。
【００１３】
クライアントやサーバが属しているデュアル環境のネットワークでは、ＩＰｖ４もＩＰｖ６も同一の物理回線上にて通信しているが、そのネットワークの外部、あるいは、そのネットワークを提供しているＩＳＰの外部では、ＩＰｖ４とＩＰｖ６はまったくの別回線上で通信が行われていることが多い。事実、現在サービス提供されているＩＰｖ６接続サービスの多くは、トンネル接続によるものである。
【００１４】
また、日本のＩＸにおいて、同一の回線口においてＩＳＰ同士がＩＰｖ４／ＩＰｖ６両方の通信トラフィックを交換しているところはまずない。
【００１５】
ＩＳＰ内部においても、ＩＰｖ６バックボーンを別途構築したり、トンネル技術やＭＰＬＳなどを利用して仮想的に独立したネットワークを構築したりするなどして、ＩＰｖ４とＩＰｖ６を区別した運用を行っていることがしばしばである。
【００１６】
これより、デュアル環境におけるＩＰｖ４／ＩＰｖ６通信品質は、同一のデュアルネットワーク内では同等だが、外部のネットワークとの通信に関しては、通信プロトコルにより帯域や輻輳、クオリティは全く異なる。
【００１７】
また、ＩＰｖ６はいまだ実験運用が主であり、運用ノウハウや対応機器の信頼性を現在高めている最中である。つまり、ＩＰｖ６通信プロトコルだけが通信不通となることが、比較的頻度に発生する。
【００１８】
一方、ＤＮＳサーバの問合せに利用する通信プロトコルはＩＰｖ４を利用するものが一般的に多い。例えば、ＩＳＣ（Ｉｎｔｅｒｎｅｔ Ｓｏｆｔｗａｒｅ Ｃｏｎｓｏｒｔｉｕｍ）提供のＢＩＮＤは現在、ＢＩＮＤ４、ＢＩＮＤ８が広く世界で利用されているが、ＩＰｖ６通信プロトコルを利用して問合せ・返信を行うことができるバージョンはＢＩＮＤ９のみである。つまり、ＤＮＳに「ＡＡＡＡ」レコードの登録は可能だが、ＩＰｖ６通信プロトコルを利用しての問合せ・返信はできないのである。
【００１９】
また、Ｗｉｎｄｏｗｓ（登録商標） ＸＰでは、サポート外でありながら、ＩＰｖ６プロトコルスタックを搭載したＯＳであるが、リゾルバはＩＰｖ６通信によるＤＮＳ問合せが行えない。
【００２０】
このような状況から、ＩＰｖ６通信が途中切断している場合でも、通信相手となるサーバのＤＮＳ問合せはＩＰｖ４通信プロトコルを利用して行うことができ、対象サーバに「ＡＡＡＡ」レコードでの登録がある場合は、ＩＰｖ６アドレスを取得できてしまう。
【００２１】
【発明が解決しようとする課題】
以上のような状況から、途中のネットワークにおいて、ＩＰｖ６接続性のみが切断している場合（ＩＰｖ４接続性は保たれている場合）には、ＩＰｖ６アドレスは取得できるので、ＩＰｖ６を利用した通信を試みるが、ＩＰｖ６ではサーバとの通信はできないので、数十秒のタイムアウトを経てから、ＩＰｖ４アドレスを取得して、ＩＰｖ４を利用した通信を行う現象が現れる。
【００２２】
この現象は、特に、ＷｅｂやＥ−Ｍａｉｌといった、何度もアクセスするようなアプリケーションでは、そのたびにタイムアウト待ちをすることとなり、ユーザにとって大変フラストレーションがたまるものといえる。また、ＩＰｖ６の利用に際し、ユーザにとってデュアル環境が「利用しにくい環境」と認識されてしまう可能性がある。
【００２３】
本発明は、この問題を解決するために成されるものであり、アドレスが取得できても、接続できない事態を減らすことを目的とする。
【００２４】
【課題を解決するための手段】
本発明の返信装置、プログラム、及び、装置は、第１の装置のアドレスを用いて前記第１の装置との接続試験を行う試験ステップと、前記試験ステップでの接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信する返信ステップとを有することを特徴とする。
【００２５】
また、本発明のアドレス通知方法、プログラム、及び、装置は、第１の装置のアドレスの問合せを第２の装置から受けると、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知するアドレス通知方法、プログラム、及び、装置において、前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することを特徴とする。
【００２６】
【発明の実施の形態】
以下、図面を参照して本発明の一実施形態を詳細に説明する。
【００２７】
図１は本発明の一実施形態のネットワークの構成図である。
【００２８】
図１において、１０１はユーザの所属するＩＰｖ４／ＩＰｖ６デュアル環境なネットワークである。ユーザネットワーク１０１には、ユーザの利用するＩＰｖ４／ＩＰｖ６アクセス可能なＷｅｂクライアント１０６が接続している。また、ＩＰｖ４／ＩＰｖ６アクセス可能なＤＮＳサーバ１０９もユーザネットワーク１０１に同じく接続している。ＤＮＳサーバ１０９は、ユーザネットワーク１０１に属する端末群のドメインを管理するＤＮＳである。
【００２９】
１０７はＩＰｖ４／ＩＰｖ６アクセス可能なＷｅｂサーバであり、ＩＰｖ４／ＩＰｖ６デュアル環境のサーバネットワーク１０３に接続している。１０８はＩＰｖ４／ＩＰｖ６アクセス可能なＤＮＳサーバであり、ＩＰｖ４／ＩＰｖ６デュアル環境のドメイン管理ネットワーク１０２に接続している。
【００３０】
Ｗｅｂサーバ１０７にはＦＱＤＮが割当ててあり、そのＦＱＤＮの属するドメインを管理するＤＮＳサーバがＤＮＳサーバ１０８である。
【００３１】
ユーザネットワーク１０１とドメイン管理ネットワーク１０２とサーバネットワーク１０３は、ＩＰｖ４インターネット１０４を介してＩＰｖ４通信プロトコルを利用して相互に通信が可能である。また、ユーザネットワーク１０１とドメイン管理ネットワーク１０２とサーバネットワーク１０３は、ＩＰｖ６インターネット１０５を介したＩＰｖ６通信プロトコルを利用して相互に通信が可能である。
【００３２】
図２は、図１において説明した各ネットワークの属するドメイン名と、各ホストに割当てたＦＱＤＮの一例である。また、各ネットワークに割当てたＩＰｖ４及びＩＰｖ６ネットワークアドレスと、各ホストに割当てたＩＰｖ４及びＩＰｖ６アドレスの一例も示す。
【００３３】
ユーザネットワーク１０１に属するＤＮＳサーバ１０９は、「ｃｌｉｅｎｔ．ｃｏｍ」ドメインを管理するマスタゾーンファイルを保持している。一方、ドメイン管理ネットワーク１０２に属するＤＮＳサーバ１０８は、「ｓｅｒｖｅｒ．ｎｅｔ」ドメインを管理するマスタゾーンファイルを保持している。
【００３４】
図３は、本実施形態での機能を実現するソフトウェアプログラムを動作させる構成の一例を示したものである。
【００３５】
例えば、ＤＮＳサーバ１０９は、図３に示すコンピュータ９００の機能により、本実施形態での機能を実現する。コンピュータ９００は、ＣＰＵ９０１と、ＲＯＭ９０２と、ＲＡＭ９０３と、ハードディスク（ＨＤ）９０７及びフロッピー（登録商標）ディスク（ＦＤ）９０８のディスクコントローラ（ＤＣ）９０５と、ネットワークインタフェースカード（ＮＩＣ）９０６とが、システムバス９０４を介して互いに通信可能に接続された構成としている。そして、ネットワークインタフェースカード９０６は、図１に示したネットワーク１０１を、システムバス９０４に接続する。
【００３６】
ＤＮＳサーバ１０９は、クライアント１０６（第２の装置）から受けたサーバ１０７（第１の装置）のアドレスの問合せに対する返信メッセージを返信する返信装置であり、クライアント１０６（第２の装置）からサーバ１０７（第１の装置）のアドレスの問合せを受けると、サーバ１０７のアドレスをクライアント１０６に通知するアドレス通知装置である。
【００３７】
ネットワークインタフェースカード９０６は、ネットワーク１０１を接続する接続手段である。
【００３８】
また、ＣＰＵ９０１は、クライアント１０６から受けたサーバ１０７のアドレスの問合せに対する返信メッセージを生成する生成手段であり、サーバ１０７のアドレスを用いてサーバ１０７との接続試験を行い、接続試験が失敗した場合には、サーバ１０７のアドレスがないことを示す返信メッセージを生成する。また、ＣＰＵ９０１は、クライアント１０６からサーバ１０７のアドレスの問合せを受けると、サーバ１０７のアドレスをクライアント１０６に通知する通知手段であり、サーバ１０７のアドレスをＤＮＳサーバ１０８（第３の装置）に問合せ、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスとともに、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスの有効期限より短い有効期限を、サーバ１０７のアドレスの有効期限として、クライアント１０６に通知する。
【００３９】
ＣＰＵ９０１は、ＲＯＭ９０２あるいはＨＤ９０７に記憶されたソフトウェア、あるいはＦＤ９０８より供給されるソフトウェアを実行することで、システムバス９０４に接続された各構成部を統括的に制御する。すなわち、ＣＰＵ９０１は、以下に説明する処理シーケンスに従った処理プログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、本実施形態での動作を実現するための制御を行う。
【００４０】
ＲＡＭ９０３は、ＣＰＵ９０１の主メモリあるいはワークエリア等として機能する。ＤＣ９０５は、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイル、ネットワーク管理プログラム、および本実施形態における下記処理プログラム等を記憶するＨＤ９０７、およびＦＤ９０８とのアクセスを制御する。ＮＩＣ９０６は、ネットワーク１０１を通じてＩＰｖ４インターネット１０４に接続するサーバ１０７等と、ＩＰｖ４通信プロトコルを用いて相互にデータのやり取りをする。また、ＮＩＣ９０６は、ネットワーク１０１を通じてＩＰｖ６インターネット１０５に接続するサーバ１０７等と、ＩＰｖ６通信プロトコルを用いて相互にデータのやり取りをする。
【００４１】
なお、Ｗｅｂクライアント１０６、Ｗｅｂサーバ１０７、ＤＮＳサーバ１０８も、ＤＮＳサーバ１０９と同様に、図３にしめるコンピュータ９００のように構成可能である。Ｗｅｂクライアント１０６、Ｗｅｂサーバ１０７、ＤＮＳサーバ１０８は、夫々、ＮＩＣ９０６を介して、ネットワーク１０１、１０３、１０２に接続される。
【００４２】
図４はＷｅｂクライアント１０６とＷｅｂサーバ１０７の通信確立までの処理概要を示したモジュール図である。
【００４３】
３０１〜３０３はＷｅｂクライアント１０６内のモジュールである。３０４〜３０８はＤＮＳサーバ１０９内のモジュールである。３０９、３１０はＤＮＳサーバ１０８内のモジュールである。３１１はＷｅｂサーバ１０７内のモジュールである。
【００４４】
なお、モジュール３０４、３０７、３０８は、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたソフトウェア、あるいはＦＤ９０８より供給されるソフトウェアにより実現される。ＣＰＵ９０１は、モジュール３０４、３０７、３０８を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、モジュール３０４、３０７、３０８の機能を実現する。
【００４５】
また、マスタゾーンファイル３０５、キャッシュデータ３０６は、ＲＡＭ９０３、又は、ＨＤ９０７に格納される。
【００４６】
Ｗｅｂクライアント１０６においても、モジュール３０１、３０２は、ソフトウェアにより実現され、キャッシュデータ３０３は、ＲＡＭ９０３、又は、ＨＤ９０７に格納される。
【００４７】
また、ＤＮＳサーバ１０８においても、モジュール３０９は、ソフトウェアにより実現され、マスタゾーンファイル３１０は、ＲＡＭ９０３、又は、ＨＤ３１０に格納される。Ｗｅｂサーバ１０７においても、サーバアプリケーション３１１は、ソフトウェアにより実現される。
【００４８】
次に、Ｗｅｂクライアント１０６とＷｅｂサーバ１０７の通信確立までの処理を説明する。
【００４９】
まず、クライアントアプリケーション３０１にて、通信相手となるサーバアプリケーションが指定される。指定方法としては本実施形態のＷｅｂの場合、「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」というＵＲＬの形にて指定される。クライアントアプリケーション３０１はこのＵＲＬより、サーバアプリケーションのホスト名であるＦＱＤＮ「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」を抽出し、リゾルバモジュール３０２に、指定したＦＱＤＮに対応するＩＰｖ４／ＩＰｖ６どちらかのアドレスを問合せる。
【００５０】
ＦＱＤＮからのアドレス問合せを受け取ったリゾルバモジュール３０２は、以前に問合せた結果が記録されているキャッシュデータ３０３に、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対応するＩＰｖ６アドレスがあるかどうかをチェックする。キャッシュデータ３０３に対応するＩＰｖ６アドレスが存在しない場合、続いて、ＩＰｖ４アドレスに関してもキャッシュデータ３０３を調査する。
【００５１】
どちらのアドレスもキャッシュデータ３０３に存在しない場合、リゾルバモジュール３０２は、ＤＮＳサーバ１０９に対して指定したＦＱＤＮに対するＩＰｖ４／ＩＰｖ６アドレスの問合せ（以降、正引き問合せと言う）を行う。
【００５２】
ここで正引き問合せで利用する通信プロトコルとして選択される通信プロトコルは、Ｗｅｂクライアント１０６のＯＳに設定しているＤＮＳサーバのアドレスをどちらの通信プロトコルで指定したかによって決定される。一方、リゾルバモジュール３０２から送られる正引き問合せは、前述したとおり、「ＡＡＡＡ」ＤＮＳ Ｑｕｅｒｙメッセージ（つまり、ＩＰｖ６アドレスの正引き問合せ）を初めに送信する。この送信に用いられる通信プロトコルは、Ｗｅｂクライアント１０６のＯＳに設定しているＤＮＳサーバのアドレスがＩＰｖ６アドレスであれば、ＩＰｖ６であり、ＩＰｖ４アドレスであれば、ＩＰｖ４である。
【００５３】
送信した正引き問合せはＤＮＳサーバ１０９内のネームサーバモジュール３０４にて受信される。ネームサーバモジュール３０４は、ユーザネットワーク１０１に属するドメイン「ｃｌｉｅｎｔ．ｃｏｍ」の管理を行っており、このドメインに属するすべてのＦＱＤＮとＩＰｖ４／ＩＰｖ６アドレスを対としたレコードを、マスタゾーンファイル３０５に保持している。ネームサーバモジュール３０４は、管理しているドメイン「ｃｌｉｅｎｔ．ｃｏｍ」に属するＦＱＤＮに対しての正引き問合せを受信した場合、マスタゾーンファイル３０５より情報を抽出し、返答する。
【００５４】
ネームサーバモジュール３０４は、管理外となるその他のドメインに関する正引き問合せを受信した場合、以前にＤＮＳサーバ１０９によって正引き問合せが行われた結果が記録されているキャッシュデータ３０６を検索する。このキャッシュデータ３０６はＤＮＳサーバ１０９内部のデータであり、Ｗｅｂクライアント１０６内のキャッシュデータ３０３とは独立して存在する。
【００５５】
キャッシュデータ３０６に該当データが存在した場合、ネームサーバモジュール３０４はキャッシュデータ３０６から該当データを取得し、その有効性のチェックを行う。この有効性のチェックについては後ほど詳細に説明するが、そのチェックの結果によって、該当データのＩＰｖ６アドレスをリゾルバモジュール３０２に返信して、本処理は終了する。例えば、このチェックの結果によって、有効性が否定された場合、ネームサーバモジュール３０４は、キャッシュデータ３０６にアドレスが存在していても、問合せを受けたアドレスがないことを示すメッセージを返信する。
【００５６】
一方、キャッシュデータ３０６に該当データが存在しない場合、つまり、問合せを受けた「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスがキャッシュデータ３０６に存在しない場合は、依頼を受けた正引き問合せの中継を行うべく、ＤＮＳサーバ１０９内のリゾルバモジュール３０７は、外部のＤＮＳサーバに対して正引き問合せを行う。このリゾルバモジュール３０７における正引き問合せは、ＲＦＣ１０３４ならびにＲＦＣ１０３５にて規定されるアルゴリズムに即して行われる。つまり、ルートＤＮＳサーバ、「ｎｅｔ」ＤＮＳサーバ、「ｓｅｒｖｅｒ．ｎｅｔ」ＤＮＳサーバと順番に配下のドメインを問合せていく。すなわち、ネームサーバモジュール３０４は、サーバ１０７（第１の装置）のアドレスの問合せをクライアント１０６（第２の装置）から受けると、リゾルバモジュール３０７は、サーバ１０７のアドレスをＤＮＳサーバ１０８（第３の装置）に問合せる。
【００５７】
「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の正引き問合せを受けたネームサーバモジュール３０９は、マスタゾーンファイル３１０に記載されている「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のレコードを検索し、該当のアドレスを抽出する。前述したとおり、上記での正引き問合せの全てにおいて、ＩＰｖ６アドレスの正引き問合せを初めに送信する。ネームサーバモジュール３０９がマスタゾーンファイル３１０より抽出した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスをＤＮＳ Ｒｅｓｐｏｎｓｅとしてリゾルバモジュール３０７に返信する。
【００５８】
ネームサーバモジュール３０９からの返信を受信したリゾルバモジュール３０７は、受信したデータをキャッシュデータ３０６に記録する。同時に、受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスを通信プロトコルチェックモジュール３０８に渡し、チェック処理を行う。通信プロトコルチェックモジュール３０８では、渡されたＩＰｖ６アドレスのチェック処理（接続試験）を行い、その結果をキャッシュデータ３０６に記録する。このチェック処理（接続試験）については後ほど詳細に説明する。
【００５９】
一方、ネームサーバモジュール３０４は、リゾルバモジュール３０７が「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスを取得し、キャッシュデータに３０６に記録したことを確認した時点で、キャッシュデータ３０６より該当データを取得し、問合せ元であるリゾルバモジュール３０２に返信を行う。すなわち、ネームサーバモジュール３０４は、ＤＮＳサーバ１０８（第３の装置）から得られたサーバ１０７（第３の装置）のアドレスをクライアント１０６（第２の装置）に通知する。
【００６０】
リゾルバモジュール３０２では、ネームサーバモジュール３０４からの返信を受信すると、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスが取得できたかどうかをチェックする。有効なＩＰｖ６アドレスを取得したリゾルバモジュール３０２は、該当データをキャッシュデータ３０３に記録し、クライアントアプリケーション３０１にＩＰｖ６アドレスを返信する。
【００６１】
一方、リゾルバモジュール３０２において、返信されたデータに有効なＩＰｖ６アドレスが存在しなかった場合、通信相手となる「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」にはＩＰｖ６アドレスが存在しないと判断し、リゾルバモジュール３０２は「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」ＤＮＳ Ｑｕｅｒｙメッセージ（つまり、ＩＰｖ４アドレスの正引き問合せ）を新たにネームサーバモジュール３０４に送信する。以下、処理内容はＩＰｖ６アドレスの正引き問合せと同じである。このＩＰｖ４アドレスの正引き問合せの結果、ＩＰｖ４アドレスも存在しないと判断した場合には、その旨を、クライアントアプリケーション３０１に通知する。
【００６２】
以上のようにして、クライアントアプリケーション３０１は、リゾルバモジュール３０２への「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」アドレス問合せに対する返信としてＩＰｖ６アドレス、もしくは、ＩＰｖ４アドレスを取得する。クライアントアプリケーション３０１は取得したアドレスを用いて通信相手のサーバアプリケーション３１１を特定し、通信を開始する。
【００６３】
図５で、ＤＮＳサーバ１０９のキャッシュデータ３０６におけるエントリデータの内容を説明する。
【００６４】
図中の一列が一つのエントリデータである。エントリデータにはいくつかの項目情報が含まれており、それぞれは以下のような情報を含んでいる。「ＦＱＤＮ」７０１はキャッシュデータとして保持するターゲットホストのＦＱＤＮを保持する。
【００６５】
「Ｔｙｐｅ」７０２はそのＦＱＤＮに定義されたレコードタイプを示している。このレコードタイプとは、ＤＮＳサーバのマスタゾーンファイル中の記述で、ＩＰｖ４アドレスの定義レコードは「Ａ」、ＩＰｖ６アドレスの定義レコードは「ＡＡＡＡ」としているので、キャッシュデータ内でも同一の表記を用いている。正引き問合せに含まれる情報は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」を問合せという内容なので、ＦＱＤＮとレコードタイプを保持することで、キャッシュデータ内に該当する情報があるかを検索することが可能となる。
【００６６】
次の項目である「Ａｄｄｒｅｓｓ」７０３にはＩＰｖ４アドレスもしくはＩＰｖ６アドレスが保持される。図からも明らかなように、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」というＦＱＤＮにＩＰｖ６アドレスとＩＰｖ４アドレスの両方がＤＮＳにて登録されていた場合、二つのエントリ７１１、７１２を持つこととなる。
【００６７】
ネームサーバモジュール３０９にてＦＱＤＮに対応するＩＰｖ４／ＩＰｖ６アドレスを返信する際、キャッシュ可能な時間を含めてアドレス情報を問合せ者（リゾルバモジュール３０２）に返信する。
【００６８】
「Ｃ−ＴＴＬ」７０４は、そのキャッシュ可能な時間の値であり、実際にキャッシュデータ３０６にて保持していられる時間を意味している。一方、「Ｒ−ＴＴＬ」７０５は、先に説明した「Ｃ−ＴＴＬ」７０４と同様にキャッシュ可能な時間であるが、この数値はリゾルバモジュール３０２からの正引き問合せに対する返信に含めるキャッシュ可能時間である。
【００６９】
本実施形態では、このデータ「Ｃ−ＴＴＬ」７０４と「Ｒ−ＴＴＬ」７０５を分割して管理し、ＦＱＤＮを管理するＤＮＳサーバ（ＤＮＳサーバ１０８にあたる）から通知されたＴＴＬ（キャッシュ可能時間「Ｃ−ＴＴＬ」７０４）をそのまま問合せ者（リゾルバモジュール３０２にあたる）に通知せずに、問合せ者（リゾルバモジュール３０２）に対してＴＴＬ＝０（「Ｒ−ＴＴＬ」７０５）としてアドレス情報を返信することで、問合せ側のキャッシュデータ（キャッシュデータ３０３にあたる）にアドレス情報がキャッシュさせない効果がある。
【００７０】
最後の「Ｃｈｅｃｋ」には、通信プロトコルチェックモジュール３０８における有効性チェックの結果を保持する。保持する値としては、「ＯＫ」が有効（接続試験成功）を、「ＮＧ」が無効（接続試験失敗）を示しており、「−」がチェック前のデータであることを示している。
【００７１】
表中の「ｍａｉｌ．ｄｕａｌ．ｂｉｚ」７１３のＩＰｖ６アドレス、「ｗｗｗ．ｖ４ｏｎｌｙ．ｃｏｍ」７１４のＩＰｖ４アドレスは、ＤＮＳサーバへの正引き問合せには成功したものの、アドレスの有効性チェックにて到達性がなかったので、無効なデータとしてキャッシュデータに保持されている例である。
【００７２】
また、「ｍａｉｌ．ｅｎｔｒｙ．ｎｅ．ｊｐ」７１５は、リゾルバモジュール３０７から新規にキャッシュデータに記録されたデータであるので、有効性チェックはチェック前の状態である。このとき、ネームサーバモジュール３０４はリゾルバモジュール３０２に対し、速やかに取得したアドレス情報を返信する必要があるので、初めての正引き問合せに対してはアドレスの有効性チェックの結果を待たずにアドレス情報を返信する。しかし、この際に返信したアドレスが無効な場合、クライアント側のキャッシュデータ３０３に該当のアドレス情報を保持されては、次回からの接続時にも、タイムアウトの問題が発生してしまうので、ＴＴＬ＝０として返信するために、Ｒ−ＴＴＬの値を「０」としている。
【００７３】
図６を用いて、ＤＮＳサーバ１０９のネームサーバモジュール３０４にて処理されるフローを説明する。このフローは、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたプログラム、あるいはＦＤ９０８より供給されるプログラムの一部を示す。ＣＰＵ９０１は、モジュール３０４を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、以下の処理を実現する。
【００７４】
４０１はネームサーバモジュール３０４が管理するドメイン以外に関する正引き問合せを待ち受けるループである。このリゾルバモジュール３０２からの正引き問合せは、ＮＩＣ９０６により受信される。ＣＰＵ９０１は、リゾルバモジュール３０２からの「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の正引き問合せを受信した場合、４０２へと処理が進む。この際、ＩＰｖ６アドレスの正引き問合せでもＩＰｖ４アドレスの正引き問合せでも同様に機能する。
【００７５】
なお、ネームサーバモジュール３０４は、管理しているドメイン「ｃｌｉｅｎｔ．ｃｏｍ」に属するＦＱＤＮに対しての正引き問合せを受信した場合は、マスタゾーンファイル３０５より情報を抽出し、返答する。
【００７６】
４０２ではキャッシュデータ３０６に問合せのＦＱＤＮに対応するＩＰｖ４／ＩＰｖ６アドレス（リゾルバモジュール３０２から問合せられた方）が存在するかを検索する。検索の結果は４０３にて判定され、該当データ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４アドレス、またはＩＰｖ６アドレス）が発見された場合は４０７に進み、該当データが発見されなかった場合には４０４へ進む。
【００７７】
４０４ではリゾルバモジュール３０７に対し、受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の正引き問合せを外部のＤＮＳサーバに向けて行うよう、問合せ内容をリゾルバモジュール３０７に送信し、問合せの依頼を行う。リゾルバモジュール３０７も、ネームサーバモジュール３０４と同様に、ＣＰＵ９０１が、プログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、実現される処理モジュールである。
【００７８】
上述のように、リゾルバモジュール３０７により「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４／ＩＰｖ６アドレスが解決し、キャッシュデータ３０６を通してその結果を取得する。なお、この問合せ依頼に関して、ＩＰｖ４／ＩＰｖ６どちらのアドレスの正引き問合せかは、前記４０１にて受信した正引き問合せの内容（ＩＰｖ４又はＩＰｖ６のどちらに対する正引き問合せか）と同一のものである。
【００７９】
ＣＰＵ９０１は、ネームサーバモジュール３０４の処理を実行し、４０４において、リゾルバモジュール３０７による処理に移行し、リゾルバモジュール３０７による処理の結果が出ると、ネームサーバモジュール３０４の処理を再開する。
【００８０】
ネームサーバモジュール３０４は、キャッシュデータ３０６を通して得られた結果を４０５にて判定する。４０５における判定にて、正引き問合せに対してＩＰｖ４／ＩＰｖ６アドレスを取得できた場合には、４０７に進み、取得できなかった場合には４０６に進む。該当のＩＰｖ４／ＩＰｖ６アドレスが取得できなかった場合には４０６にてリゾルバモジュール３０７にて得られた結果と同一の返信メッセージ（Ｒｅｓｐｏｎｓｅ（ｎｏｔｈｉｎｇ）メッセージ、あるいはＥｒｒｏｒメッセージ）をリゾルバモジュール３０２に向けて送信し、待ち受けループ４０１に処理が戻る。
【００８１】
一方、４０５における判定にて、該当のＩＰｖ４／ＩＰｖ６アドレスを取得できた場合、及び、４０３における判定にて、キャッシュデータ３０６の検索によりＩＰｖ４／ＩＰｖ６アドレスを取得できた場合、４０７にてそのアドレスの有効性に関してチェックを行う。アドレスの有効性の処理に関しては、通信プロトコルチェックモジュール３０８にて行われており、図５に示すように、その結果７０６がキャッシュデータ３０６のエントリに記録されている。そのチェック結果を抽出し、４０８にて判定している。４０８での判定では、キャッシュデータ３０６のエントリ内にある「ｃｈｅｃｋ」項目７０６を参照し、この項目が「ＯＫ」の場合は有効な（接続試験に成功した）アドレス、「ＮＧ」の場合は無効な（接続試験に失敗した）アドレスと判定する。
【００８２】
なお、この判定項目で「−」の場合が存在するが、それは通信プロトコルチェックモジュール３０８にてチェック前のデータであることを示し、４０４でリゾルバへの問合せ依頼をした際に現れる。このチェック前のデータの場合は、有効なアドレスとして判断される。
【００８３】
４０１にて受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」への正引き問合せがＩＰｖ６アドレスを求めるものである場合は、４０９にて有効なＩＰｖ６アドレスをキャッシュデータ３０６より抽出し、リゾルバモジュール３０２に対してＲｅｓｐｏｎｓｅ ＡＡＡＡメッセージにて送信する。その際、メッセージ内のＴＴＬ値（このＩＰｖ６アドレスをキャッシュデータ３０３にてキャッシュできる時間）に、キャッシュデータ３０６内の「Ｒ−ＴＴＬ」項目の値を代入して送信する。
【００８４】
また、４０１にて受信した「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」への正引き問合せがＩＰｖ４アドレスを求めるものである場合は、４１１にて有効なＩＰｖ４アドレスをキャッシュデータ３０６より抽出し、リゾルバモジュール３０２に対してＲｅｓｐｏｎｓｅ Ａメッセージにて送信する。その際にも、メッセージ内のＴＴＬ値に、キャッシュデータ３０６内の「Ｒ−ＴＴＬ」項目の値を代入して送信する。
【００８５】
４０８にて無効と判断された場合、４１０にてリゾルバモジュール３０２に対してＲｅｓｐｏｎｓｅ（ｎｏｔｈｉｎｇ）メッセージを送信する。以上、４０９〜４１１の処理が終了した場合は、４０１の待ち受けループに処理が戻る。
【００８６】
次に、図７にて、ＤＮＳサーバ１０９のリゾルバモジュール３０７の処理フローを説明する。このフローは、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたプログラム、あるいはＦＤ９０８より供給されるプログラムの一部を示す。ＣＰＵ９０１は、モジュール３０７を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、以下の処理を実現する。
【００８７】
ＣＰＵ９０１は、ネームサーバモジュール３０４の処理４０３において、該当するキャッシュデータがない場合、リゾルバモジュール３０７の処理を行う。すなわち、ネームサーバモジュール３０４にて受信した正引き問合せに対する該当データがキャッシュデータ３０６に存在しない場合、リゾルバモジュール３０７は、５０１にて、ネームサーバモジュール３０４より正引き問合せの依頼を受理する。ここで、リゾルバモジュール３０７がネームサーバモジュール３０４より委託された正引き問合せ内容は、リゾルバモジュール３０２からネームサーバモジュール３０４に問合せられた「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４／ＩＰｖ６アドレスの正引き問合せ内容と同一のものである。
【００８８】
５０２では、５０１にて受理した内容の正引き問合せを外部のＤＮＳサーバに向けて実行する。この５０２にて実行される正引き問合せは、前述したように、ＲＦＣ１０３４ならびにＲＦＣ１０３５にて規定されるアルゴリズムに即して行われる。つまり、ルートＤＮＳサーバ、「ｎｅｔ」ＤＮＳサーバ、「ｓｅｒｖｅｒ．ｎｅｔ」ＤＮＳサーバと順番に配下のドメインを問合せていく。
【００８９】
「ｓｅｒｖｅｒ．ｎｅｔ」ドメインの管理サーバであるＤＮＳサーバ１０８に対して送信する「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する正引き問合せで利用される通信プロトコルは、上位のＤＮＳサーバである「ｎｅｔ」ドメイン管理サーバによって通知されたＤＮＳサーバ１０７のアドレスによって決定される。「ｎｅｔ」ドメインを管理するＤＮＳサーバではＩＰｖ６アドレスでのレコード登録を受け付けていない場合、リゾルバモジュール３０７とネームサーバモジュール３０９の通信にはＩＰｖ４プロトコルが利用される。
【００９０】
そして、５０３にて外部ＤＮＳサーバから、問合せに対する返信を受信する。５０４では５０３にて受信した問合せに対する返信の内容をチェックし、場合分けを行う。以下、５０５〜５０８がその場合分けである。
【００９１】
５０５は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレスを求める正引き問合せが成功した場合であり、ＩＰｖ６アドレス情報が含まれたＲｅｓｐｏｎｓｅ ＡＡＡＡメッセージを受信する。５０８は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４アドレスを求める正引き問合せが成功した場合であり、ＩＰｖ４アドレス情報が含まれたＲｅｓｐｏｎｓｅ Ａメッセージを受信する。以上の５０５、５０８はともに５０２における正引き問合せに対して成功した場合であり、どちらも５１０の処理に進む。
【００９２】
一方、５０６は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」にＩＰｖ６アドレスまたはＩＰｖ４アドレスを求める正引き問合せに対して、該当のアドレス情報を持ったレコードが存在しない場合であり、アドレス情報が含まれていないＲｅｓｐｏｎｓｅ （ｎｏｔｈｉｎｇ）メッセージを受信する。５０７は、「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」にＩＰｖ６アドレスまたはＩＰｖ４アドレスを求める正引き問合せに対して、何らかのエラーが発生した場合（外部ＤＮＳサーバにて問合せのレコードタイプが理解できなかった場合や、ターゲットとなる外部ＤＮＳサーバが見つからなかった場合など）であり、Ｅｒｒｏｒメッセージを受信する。これら５０６、５０７はともに５０２における正引き問合せに対して失敗した場合であり、どちらも５０９にてネームサーバモジュール３０４に返信内容（Ｒｅｓｐｏｎｓｅ（ｎｏｔｈｉｎｇ）メッセージあるいはＥｒｒｏｒメッセージ）を伝達し、ネームサーバモジュール３０４に、委託された正引き問合せの終了を通知し、処理を終了する。そして、ＣＰＵ９０１は、ネームサーバモジュール３０４の処理４０５を行う。この場合は、４０６で、リゾルバモジュール３０２に取得失敗を返信する。
【００９３】
正引き問合せに成功した場合は、５１０にてキャッシュデータ３０６に記録する内容を作成する。この各項目情報に関しては、図５を参照して、前述した通りである。
【００９４】
すなわち、ここでの作成データには、ＦＱＤＮ「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」７０１と、そのＩＰｖ４／ＩＰｖ６アドレス７０３、レコードタイプ（「Ａ」（ＩＰｖ４）又は「ＡＡＡＡ」（ＩＰｖ６））７０２、Ｃ−ＴＴＬ（外部ＤＮＳサーバより通知されたキャッシュ可能時間）７０４のＤＮＳキャッシュデータ標準の項目情報に加えて、チェック判定結果７０６、Ｒ−ＴＴＬ（対クライアントへの実キャッシュ可能時間）７０５の項目情報が含まれる。５１０でのデータ作成において、チェック判定結果項目には「−」（チェック前データ）を代入し、実ＴＴＬ（Ｒ−ＴＴＬ）７０５には「０」を代入する。ここで、実ＴＴＬ（Ｒ−ＴＴＬ）の値は「０」に限らず、「１」あるいは「２」、「３」に設定しても、実用上、大きな支障はない。
【００９５】
５１１において、５１０にて作成したデータをキャッシュデータ３０６に記録し、ネームサーバモジュール３０４に、委託された正引き問合せの終了を通知する。その後、ＣＰＵ９０１は、ネームサーバモジュール３０４の処理４０５を行う。また、５１２ではキャッシュデータ３０６に記録したＩＰｖ４／ＩＰｖ６アドレスが有効かどうかのチェック（接続試験）を行うために、通信プロトコルチェックモジュール３０８に、５１１にて記録したデータを送信し、アドレスのチェック処理を依頼し、全処理を終了する。
【００９６】
図８で、ＤＮＳサーバ１０９の通信プロトコルチェックモジュール３０８における処理フローを説明する。このフローは、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたプログラム、あるいはＦＤ９０８より供給されるプログラムの一部を示す。ＣＰＵ９０１は、モジュール３０８を実現するためのプログラムを、ＲＯＭ９０２、あるいはＨＤ９０７、あるいはＦＤ９０８から読み出して実行することで、以下の処理を実現する。
【００９７】
この通信プロトコルチェック処理は、二つのタイミングで起動される。まず一つはリゾルバモジュール３０７からＩＰｖ４／ＩＰｖ６アドレスを通知された場合である。これは、新規にキャッシュデータ３０６にアドレス情報が記録された際に発生する事例であり、そのＩＰｖ４／ＩＰｖ６アドレスの有効性をチェックする必要がある。
【００９８】
もう一つの起動のタイミングは、ある一定時間（例えば、５分）が経過した場合である。これは、キャッシュデータ３０６に記録されているＩＰｖ４／ＩＰｖ６アドレスの有効性を定期的にチェックし、刻々と変化するネットワーク情報に適した評価を行うためである。
【００９９】
６０１では以上の二つのタイミングによる起動（リゾルバモジュール３０７からのチェック要請、または、ある一定時間経過による定期チェック）を判定する。リゾルバモジュール３０７からＩＰｖ４／ＩＰｖ６アドレスを受信した場合、すなわち、ＣＰＵ９０１が、リゾルバモジュール３０７の処理において、外部サーバから有効なＩＰｖ４／ＩＰｖ６アドレスが得て、リゾルバモジュール３０７の処理を終了した場合、ＣＰＵ９０１は、６０２において該当アドレスの有効性チェック処理を行う。
【０１００】
本実施形態でのアドレス（例えば、Ｗｅｂサーバ１０７のアドレス）の有効性チェックは、ＩＰｖ４／ＩＰｖ６アドレスがＤＮＳサーバ１０９からＷｅｂサーバ１０７までのそれぞれの通信プロトコルでの接続性を確認する（接続試験を行う）ことで、アドレスの有効性を判定している。そこで、６０２にて、疎通チェックを対象となるＩＰｖ４／ＩＰｖ６アドレスに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、そのメッセージに対する応答を判断し、その判断に基づき、アドレスの有効性を確認する。このチェック処理に関しては６１１〜６１６にて詳しく説明する。
【０１０１】
６０２でのアドレス有効性チェック処理を行ったデータは、６０３にてキャッシュデータ３０６に既に記録されているエントリデータの「Ｃｈｅｃｋ」欄７０６、「Ｒ−ＴＴＬ」欄７０５を上書き修正し、６０１へ戻る。
【０１０２】
一方、ある一定時間（例えば、５分）を経過した場合の処理は、６０４に進む。６０４ではキャッシュデータ３０６に記録されているエントリデータを取得する。そして、６０５において取得したエントリからＩＰｖ４／ＩＰｖ６アドレスを抽出し、６０６においてアドレス有効性チェック処理（接続試験）を行う。６０６のチェック処理も６０２と同様の処理を行う。そして、６０８にて、６０３と同様に、６０６のチェック処理の結果を、キャッシュデータ３０６に反映させる。この６０４、６０５、６０６の処理は、キャッシュデータ３０６に格納されているエントリのそれぞれについて、すなわち、キャッシュデータ３０６に格納されているアドレスのそれぞれについて、接続試験を行い、その結果を、チェック欄７０６に格納する。
【０１０３】
引き続き、図９で、６０２、６０６で行われるアドレス有効性チェック（接続試験）の処理フローを説明する。
【０１０４】
本実施形態でのアドレス有効性チェックは、ＩＰｖ４／ＩＰｖ６アドレスがＤＮＳサーバ１０９からＷｅｂサーバ１０７までのそれぞれの通信プロトコルでの接続性を確認する（接続試験を行う）ことで、アドレスの有効性を判定している。
【０１０５】
すなわち、疎通チェックを対象となるＩＰｖ４／ＩＰｖ６アドレスに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、そのメッセージに対する応答を判断し、その判断に基づき、アドレスの有効性を確認する。
【０１０６】
本実施形態では、アドレスの有効性をチェックする（接続性を試験する）ためのメッセージとして、ＩＣＭＰ ｅｃｈｏメッセージを用いる。すなわち、６１１にてＩＣＭＰ ｅｃｈｏメッセージによる疎通チェックを対象となるＩＰｖ４／ＩＰｖ６アドレスに対して、それぞれの通信プロトコルを利用して送信する。ＩＰｖ６アドレスのチェックには、ＩＰｖ６の通信プロトコルを用いて、ＩＣＭＰ ｅｃｈｏメッセージを送信し、ＩＰｖ４アドレスのチェックには、ＩＰｖ４の通信プロトコルを用いて、ＩＣＭＰ ｅｃｈｏメッセージを送信する。
【０１０７】
６１２にて、６０２あるいは６０６で発行したＩＣＭＰ ｅｃｈｏに対する返信があるかを判定し、所定時間内に（例えば、１秒以内）、返信があった場合にはそのアドレスは有効であると判断し、６１３にて、キャッシュデータ３０６に記録するエントリデータ内の項目であるチェック判定結果の欄に「ＯＫ」を代入する。
【０１０８】
一方、所定時間内に（例えば、１秒）ＩＣＭＰ ｅｃｈｏに対する返信がない場合は、そのアドレスは無効と判断し、６１５にて、キャッシュデータ３０６に記録するエントリデータ内の項目であるチェック判定結果の欄に「ＮＧ」を代入する。続いて、６１６にて、同じくエントリデータ内のＲ−ＴＴＬ（対クライアントへの実キャッシュ可能時間）７０５の値を「０」し、チェック処理を終了する。なお、所定時間内に（例えば、１秒以内）、ＩＣＭＰ ｅｃｈｏメッセージが宛先に届かないことを示すメッセージが、インターネット１０４あるいは１０５内のサーバから、送られてきた場合も、チェック判定結果の欄に「ＮＧ」を代入し、Ｒ−ＴＴＬの値を「０」にする。ここで、チェック判定結果の欄が「ＮＧ」ならば、４１０で、クライアントには、Ｒｅｓｐｏｎｓｅ （ｎｏｔｈｉｎｇ）メッセージを返信するので、Ｒ−ＴＴＬの値は「０」に設定しなくても、問題ない。
【０１０９】
６１３、６１４、６１５、６１６で、作成したエントリデータは、６０３、６０８において、キャッシュデータ３０６に格納される。なお、６０６では、キャッシュデータ３０６に記録されているＩＰｖ４／ＩＰｖ６アドレスのそれぞれに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、６１２で返信があれば、６１３、６１４の処理を行い、所定時間内に、返信がない場合、６１５、６１６の処理を行う。
【０１１０】
なお、このアドレスの有効性をチェックするために送信したメッセージの返信を待つ時間は、１秒に限らず、例えば、３０秒に設定してもよい。
【０１１１】
他の形態では、６０２でのアドレス有効性チェックと６０６でのアドレス有効性チェックで、返信を待つ時間として、異なる時間を用いる。例えば、６０２でのアドレス有効性チェックでは、３０秒、６０６のアドレス有効性チェックでは、１秒、メッセージの返信を待って、アドレス有効性を判断する。
【０１１２】
なお、ＤＮＳキャッシュデータは、ＴＴＬ値を越える時間、キャッシュすることが許されない仕組みとなっている。そのため、図には示さないが、例えば、１秒ごとに、キャッシュ時間Ｃ−ＴＴＬ（外部ＤＮＳサーバより通知されたキャッシュ可能時間）７０４の値を１つ減らして、Ｃ−ＴＴＬ値７０４の判定を行い、既に期限切れのエントリは、キャッシュデータ３０６から削除する。なお、Ｒ−ＴＴＬ（対クライアントへの実キャッシュ可能時間）７０５に関しては、値が「０」でなければ、１つ減らす。
【０１１３】
図１０は本実施形態の通信の流れにおいて、Ｗｅｂクライアント１０６からＷｅｂサーバ１０７に対し、ＩＰｖ６通信プロトコルでの到達が不可能な状況での通信パケットの内容とそのフローである。以下のフローにおいて、ＤＮＳサーバ１０９の動作は、ＤＮＳサーバ１０９のＲＯＭ９０２あるいはＨＤ９０７に記憶されたソフトウェア、あるいはＦＤ９０８より供給されるソフトウェアであるモジュール３０４、３０７、３０８により実現される。図６、図７、図８、図９は、連携して動作することにより、第１の装置のアドレスを用いて前記第１の装置との接続試験を行う試験ステップ（６０６）と、前記試験ステップでの接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信する返信ステップ（４１０）とを有するアドレスの問合せに対する返信プログラムであり、また、第１の装置のアドレスの問合せを第２の装置から受けると（４０１）、前記第１の装置のアドレスを第３の装置に問合せ（５０２）、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知し（４０９、４１１）、前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知するアドレス通知プログラムである。
【０１１４】
Ｗｅｂクライアント１０６は、最寄りのＤＮＳサーバ１０９に対して正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「ＡＡＡＡ」の問合せ）ＡＡＡＡ Ｑｕｅｒｙ８０１を送信する。
【０１１５】
ＤＮＳサーバ１０９は、この正引き問合せ８０１を受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、該当するデータがないことから（図６の４０３でＮｏ）、対象となるＦＱＤＮの管理を行っているＤＮＳサーバ１０８に正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「ＡＡＡＡ」の問合せ）ＡＡＡＡ Ｑｕｅｒｙ ８０２を行う（図６の４０４、図７の５０１、５０２）。すなわち、ＤＮＳサーバ１０９は、サーバ１０７（第１の装置）のアドレスの問合せをクライアント１０６（第２の装置）から受けると、サーバ１０７のアドレスをＤＮＳサーバ（第３の装置）に問合せる。
【０１１６】
問合せ８０２に対し、ＤＮＳサーバ１０８は、問合せのＦＱＤＮに対するＩＰｖ６アドレスを含む問合せへの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」は「２００１：３４０：０：１：：１」、「ＴＴＬ＝１００００」）Ｒｅｓｐｏｎｓｅ ＡＡＡＡ ８０３を、ＤＮＳサーバ１０９に送信する。
【０１１７】
ＤＮＳサーバ１０９は、この返信８０３を受信し（図７の５０３、５０４、５０５、５１０、５１１）、迅速にＷｅｂクライアント１０６に対して問合せの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」は「２００１：３４０：０：１：：１」、「ＴＴＬ＝０」）Ｒｅｓｐｏｎｓｅ ＡＡＡＡ ８０４を送信する（図６の４０５のＹｅｓ、４０７、４０８、４０９）。すなわち、ＤＮＳサーバ１０９は、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスをクライアント１０６に通知する。ＤＮＳサーバ１０６は、ＤＮＳサーバ１０８から得られたサーバ１０７のアドレスの有効期限Ｃ−ＴＴＬ７０４より短い有効期限Ｒ−ＴＴＬ７０５（その値は、例えば、「０」）を、サーバ１０７のアドレスの有効期限として、クライアント１０６に通知する。
【０１１８】
返信８０４を受信したＷｅｂクライアントは「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ６アドレス「２００１：３４０：０：１：：１」を取得したので、目的のサーバ１０７にＩＰｖ６通信プロトコルを利用して接続８０５を試みるが、途中でネットワークが切断状態であるために接続はできない。
【０１１９】
一方、ＤＮＳサーバ１０９でも、ＩＰｖ６アドレス通知Ｒｅｓｐｏｎｓｅ ＡＡＡＡ ８０４とほぼ同時刻に、ＩＰｖ６アドレスの有効性チェックのために、ＩＣＭＰ ｅｃｈｏメッセージ８０６を対象アドレス「２００１：３４０：０：１：：１」に送信する（図７の５１２、図８の６０１、６０２）。メッセージ８０６の通信に関しても、Ｗｅｂサーバ１０７には到達しないので（図９の６１２はＮｏ）、アドレス有効性チェック８０７はＮＧ（接続試験失敗）となる（６１５）。このＩＰｖ６アドレスの接続性試験は、ＩＰｖ６の通信プロトコルを用いて、行う。
【０１２０】
Ｗｅｂクライアント１０６は、接続８０５から通信確立失敗までタイムアウト待ちを行い、そのタイムアウトの後、ＩＰｖ４アドレスを取得すべく最寄りのＤＮＳサーバ１０９に対して正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「Ａ」の問合せ）Ａ Ｑｕｅｒｙ ８０８を行う。
【０１２１】
ＤＮＳサーバ１０９は、この正引き問合せ８０８を受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、該当するデータがないことから（図６の４０３のＮｏ）、対象となるＦＱＤＮの管理を行っているＤＮＳサーバ１０８に正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「Ａ」の問合せ）Ａ Ｑｕｅｒｙ ８０９を行う（図６の４０４、図７の５０１、５０２）。
【０１２２】
問合せ８０９に対し、ＤＮＳサーバ１０８は、問合せのＦＱＤＮに対するＩＰｖ４アドレスを含む問合せへの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」は「１７２．１６．０．１」、「ＴＴＬ＝１００００」）Ｒｅｓｐｏｎｓｅ Ａ ８１０を、ＤＮＳサーバ１０９に送信する。
【０１２３】
ＤＮＳサーバ１０９は、この返信８１０を受信し（図７の５０３、５０４、５０８、５１０、５１１）、迅速にＷｅｂクライアント１０６に対して問合せの返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」は「１７２．１６．０．１」、「ＴＴＬ＝０」）Ｒｅｓｐｏｎｓｅ Ａ ８１１を送信する（図６の４０５のＹｅｓ、４０７、４０８、４１１）。
返信８１１を受信したＷｅｂクライアントは「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」のＩＰｖ４アドレス「１７２．１６．０．１」を取得したので、目的のサーバ１０７にＩＰｖ４通信プロトコルを利用して接続８１２を試みる。この接続８１２は成功するので、Ｗｅｂクライアント１０６には、Ｗｅｂサーバ１０７のデータが受信される。
【０１２４】
一方、ＤＮＳサーバ１０９でも、ＩＰｖ４アドレス通知Ｒｅｓｐｏｎｓｅ Ａ８１１とほぼ同時刻に、ＩＰｖ４アドレスの有効性チェックのために、ＩＣＭＰ ｅｃｈｏメッセージ８１３を対象アドレス「１７２．１６．０．１」に送信する（図７の５１２、図８の６０１、６０２）。メッセージ８１３に対する返信が、Ｗｅｂサーバ１０７よりＩＣＭＰ Ｒｅｓｐｏｎｓｅ ８１４として送信されるので（図９の６１２は、Ｙｅｓ）、アドレス有効性チェック７０６はＯＫ（接続試験成功）となる（６１３）。なお、このＩＰｖ４アドレスの接続性試験は、ＩＰｖ４の通信プロトコルを用いて、行う。
【０１２５】
その後、新たにＷｅｂサーバ１０７への接続要求が発生した際（例えば、Ｗｅｂ表示上のリンクを選択し、同じＷｅｂサーバ内の別のデータを取得するような場合）、Ｗｅｂクライアント１０６はもう一度最寄りのＤＮＳサーバ１０９にＩＰｖ６アドレスの正引き問合せ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」に対する「ＡＡＡＡ」の問合せ）ＡＡＡＡ Ｑｕｅｒｙ ８１５を行う。
【０１２６】
ＤＮＳサーバ１０９は、この正引き問合せ８１５を受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、図１０の８０７でアドレス有効性チェックの行われたキャッシュデータから、ＩＰｖ６アドレスのチェック結果が「ＮＧ」であることを知るので（図６の４０３のＹｅｓ、４０７、４０８のＮｏ）、Ｗｅｂクライアント１０６への返信にはアドレス無しメッセージ（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「ＡＡＡＡ」はありません）Ｒｅｓｐｏｎｓｅ （ｎｏｔｈｉｎｇ） ８１６を送信する（図６の４１０）。すなわち、ＤＮＳサーバ１０９は、サーバ１０７（第１の装置）のアドレスを用いてサーバ１０７との接続試験（８０６、８０７）を行い、その接続試験が失敗した場合には、サーバ１０７のアドレスがないことを示すメッセージを返信する。
【０１２７】
この返信８１６を受けたＷｅｂクライアントは、続いてＩＰｖ４アドレスの正引き問合せＡ Ｑｕｅｒｙ ８１７を送信する。ＤＮＳサーバ１０９は、同様に、この正引き問合せを受け（図６の４０１）、自分の所持するキャッシュデータを検索し（４０２）、アドレス有効性チェックの行われたキャッシュデータから、ＩＰｖ４アドレスを検索し、チェック結果の「ＯＫ」を確認してから（図６の４０３のＹｅｓ、４０７、４０８）、問合せ返信（「ｗｗｗ．ｓｅｒｖｅｒ．ｎｅｔ」の「Ａ」は「１７２．１６．０．１」、「ＴＴＬ＝１００００」）Ｒｅｓｐｏｎｓｅ Ａ ８１８を送信する（４１１）。
【０１２８】
返信８１８によりＷｅｂサーバ１０７のＩＰｖ４アドレス取得に成功したＷｅｂクライアント１０９は、ＩＰｖ４通信プロトコルを利用した接続８１９を行い、Ｗｅｂサーバ１０７からデータを取得する。
【０１２９】
＜他の実施の形態＞
上記実施形態では、ＤＮＳサーバ１０９のネームサーバモジュール３０４は、リゾルバモジュール３０７が外部のＤＮＳサーバ１０７から受け取ったアドレスを、通信プロトコルチェックモジュール３０８が有効かチェックする前に、クライアント１０６のリゾルバモジュール３０２に通知したが、他の形態では、ＤＮＳサーバ１０９のネームサーバモジュール３０４は、リゾルバモジュール３０７が外部のＤＮＳサーバ１０７から受け取ったアドレスを、通信プロトコルチェックモジュール３０８が有効かチェックした後、クライアント１０６のリゾルバモジュール３０２に通知する。
【０１３０】
この他の形態では、リゾルバモジュール３０７は、外部サーバへの正引き問合せが成功した場合、通信プロトコルチェックモジュール３０８によるアドレスの有効性のチェックが終了した後、ネームサーバモジュール３０４に正引き問合せの終了を通知する。そして、ネームサーバモジュール３０４は、通信プロトコルチェックモジュール３０８による有効性のチェックが行われたアドレスについて、クライアント１０６のリゾルバモジュール３０２に対して、アドレスの有効性に基づき（４０７、４０８）、有効であれば、アドレスを返信し（４０９、４１１）、有効でなければ、取得失敗を返信する（４１０）。
【０１３１】
なお、この他の形態では、通信プロトコルチェックモジュール３０８により無効と判断されたアドレスは、キャッシュデータ３０６から削除してもよい。このように削除する形態では、Ｒ−ＴＴＬ７０５、チェック欄７０６は、設けなくてもよい。
【０１３２】
上記実施形態において、Ｗｅｂクライアント１０６とＷｅｂサーバ１０７は、Ｗｅｂアプリケーションに限定されるものではなく、どのようなネットワークアプリケーションであってもよい。
【０１３３】
また、上記実施形態において、ユーザネットワーク１０１に接続したＤＮＳサーバ１０９には、ユーザネットワーク１０１に属するホスト端末群のドメインを管理するマスタゾーンファイル３０５を、必ずしも、保持する必要はなく、単なるＤＮＳキャッシュサーバとしての機能のみを提供するものであってよい。
【０１３４】
また、上記実施形態において、ドメイン管理ネットワーク１０２とサーバネットワーク１０３は必ずしも独立したネットワークである必要はなく、同一のネットワーク上にＤＮＳサーバ１０８とＷｅｂサーバ１０７が存在してもよい。
【０１３５】
また、上記実施形態において、ＤＮＳサーバ１０９は必ずしもユーザネットワーク１０１に属している必要はなく、ユーザネットワークに極力近ければよく、例えば、クライアント１０６にインターネットサービスを提供しているＩＳＰ内のネットワークに存在してもよい。
【０１３６】
また、上記実施形態において、各ホストに割当てたドメイン名、ＦＱＤＮ、ＩＰｖ４ネットワークアドレス、ＩＰｖ４アドレス、ＩＰｖ６ネットワークアドレス、ＩＰｖ６アドレスは一例に過ぎず、その他の任意のドメイン名、ＦＱＤＮ、ＩＰｖ４ネットワークアドレス、ＩＰｖ４アドレス、ＩＰｖ６ネットワークアドレス、ＩＰｖ６アドレスであってもよい。
【０１３７】
【発明の効果】
本発明によれば、第１の装置のアドレスを用いて前記第１の装置との接続試験を行い、前記接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信することにより、前記第２の装置が、前記第１の装置のアドレスが取得できても、接続できない事態を防ぐことが可能となる。
【０１３８】
更に、前記試験ステップでは、前記第１の装置のアドレスに対応するプロトコルで、前記第１の装置との接続試験を行うことにより、プロトコル毎に、前記第１の装置に接続できない事態を防ぐことが可能となる。
【０１３９】
また、第１の装置のアドレスの問合せを第２の装置から受けると、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知する場合に、前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することにより、前記第２の装置が、前記第１の装置のアドレスが取得できても、接続できない事態を減らすことが可能となる。
【図面の簡単な説明】
【図１】ネットワークの構成図である。
【図２】各ネットワークの属するドメイン名と、各ホストに割当てたＦＱＤＮの一例の図である。
【図３】本実施形態での機能を実現するソフトウェアプログラムを動作させる構成の一例の図である。
【図４】ＷｅｂクライアントとＷｅｂサーバの通信確立までの処理概要を示したモジュール図である。
【図５】ＤＮＳサーバのキャッシュデータにおけるエントリデータの内容の図である。
【図６】ＤＮＳサーバのネームサーバモジュールにて処理されるフローの図である。
【図７】ＤＮＳサーバのリゾルバモジュールにおける処理フローの図である。
【図８】ＤＮＳサーバの通信プロトコルチェックモジュールにおける処理フローの図である。
【図９】アドレス有効性チェック（接続試験）の処理フローの図である。
【図１０】ＩＰｖ６通信プロトコルでの到達が不可能な状況での通信パケットの内容とそのフローの図である。
【符号の説明】
１０６ Ｗｅｂクライアント
１０７ Ｗｅｂサーバ
１０８ ＤＮＳサーバ
１０９ ＤＮＳサーバ
Claims (9)
- 第１の装置のアドレスを用いて前記第１の装置との接続試験を行う試験ステップと、
前記試験ステップでの接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信する返信ステップとを有することを特徴とするアドレスの問合せに対する返信方法。 - 前記試験ステップでは、前記第１の装置のアドレスに対応するプロトコルで、前記第１の装置との接続試験を行うことを特徴とする請求項１の返信方法。
- 第１の装置のアドレスの問合せを第２の装置から受けると、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知するアドレス通知方法において、
前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することを特徴とするアドレス通知方法。 - 第１の装置のアドレスを用いて前記第１の装置との接続試験を行う試験ステップと、
前記試験ステップでの接続試験が失敗した場合には、第２の装置からの前記第１の装置のアドレスの問合せに対して、前記第１の装置のアドレスがないことを示すメッセージを返信する返信ステップとを有することを特徴とするアドレスの問合せに対する返信プログラム。 - 前記試験ステップでは、前記第１の装置のアドレスに対応するプロトコルで、前記第１の装置との接続試験を行うことを特徴とする請求項４の返信プログラム。
- 第１の装置のアドレスの問合せを第２の装置から受けると、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスを前記第２の装置に通知するアドレス通知プログラムにおいて、
前記第１の装置のアドレスと共に前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することを特徴とするアドレス通知プログラム。 - ネットワークを接続する接続手段と、
前記接続手段に接続されたネットワークを介して、第２の装置から受けた第１の装置のアドレスの問合せに対する返信メッセージを生成する生成手段とを有し、
前記生成手段は、前記第１の装置のアドレスを用いて前記第１の装置との接続試験を行い、接続試験が失敗した場合には、前記第１の装置のアドレスがないことを示す返信メッセージを生成することを特徴とする返信装置。 - 前記生成手段は、前記第１の装置のアドレスに対応するプロトコルで、前記第１の装置との接続試験を行うことを特徴とする請求項１の返信方法。
- ネットワークを接続する接続手段と、
前記接続手段に接続されたネットワークを介して、第２の装置から第１の装置のアドレスの問合せを受けると、前記第１の装置のアドレスを前記第２の装置に通知する通知手段とを有し、
前記通知手段は、前記第１の装置のアドレスを第３の装置に問合せ、前記第３の装置から得られた前記第１の装置のアドレスと共に、前記第３の装置から得られた前記第１の装置のアドレスの有効期限より短い有効期限を、前記第１の装置のアドレスの有効期限として、前記第２の装置に通知することを特徴とするアドレス通知装置。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003012283A JP3703457B2 (ja) | 2003-01-21 | 2003-01-21 | アドレス通知方法、プログラム、及び、装置 |
| US10/756,883 US7415536B2 (en) | 2003-01-21 | 2004-01-13 | Address query response method, program, and apparatus, and address notification method, program, and apparatus |
| EP20040250144 EP1441487A3 (en) | 2003-01-21 | 2004-01-14 | Address query response method, program, and apparatus |
| CNB2004100022488A CN100484125C (zh) | 2003-01-21 | 2004-01-16 | 对地址询问的回答方法和回答装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003012283A JP3703457B2 (ja) | 2003-01-21 | 2003-01-21 | アドレス通知方法、プログラム、及び、装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004228760A true JP2004228760A (ja) | 2004-08-12 |
| JP3703457B2 JP3703457B2 (ja) | 2005-10-05 |
Family
ID=32588613
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003012283A Expired - Fee Related JP3703457B2 (ja) | 2003-01-21 | 2003-01-21 | アドレス通知方法、プログラム、及び、装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7415536B2 (ja) |
| EP (1) | EP1441487A3 (ja) |
| JP (1) | JP3703457B2 (ja) |
| CN (1) | CN100484125C (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006222631A (ja) * | 2005-02-09 | 2006-08-24 | Hitachi Ltd | 輻輳制御装置、および、ネットワークの輻輳制御方法 |
| JP2009212878A (ja) * | 2008-03-05 | 2009-09-17 | Nec Infrontia Corp | ルータ装置、通信システム及びそれらに用いる不正経路確認方法 |
| JP2011055434A (ja) * | 2009-09-04 | 2011-03-17 | Yamaha Corp | 通信装置 |
| JP2012109887A (ja) * | 2010-11-19 | 2012-06-07 | Nec Access Technica Ltd | リソースレコード制御システム、リソースレコード制御方法、アプリケーション判別方法およびプログラム |
| JP2012249015A (ja) * | 2011-05-26 | 2012-12-13 | Nippon Telegr & Teleph Corp <Ntt> | フォールバック検知装置、フォールバック検知方法及びフォールバック検知プログラム |
| JP2013026993A (ja) * | 2011-07-26 | 2013-02-04 | Pfu Ltd | ノード検出装置、ノード検出方法、及びプログラム |
| KR101520811B1 (ko) * | 2014-07-11 | 2015-05-21 | 주식회사 엘지유플러스 | Ims 망에서 호 세션을 제어하는 방법 및 이를 수행하는 장치 |
Families Citing this family (76)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6928463B1 (en) * | 2001-07-06 | 2005-08-09 | Nortel Networks Limited | Broadband content delivery via personal content tunnel |
| US8161184B2 (en) * | 2004-06-25 | 2012-04-17 | Apple Inc. | Method and apparatus for facilitating long-lived DNS queries |
| US8224964B1 (en) | 2004-06-30 | 2012-07-17 | Google Inc. | System and method of accessing a document efficiently through multi-tier web caching |
| US7437364B1 (en) * | 2004-06-30 | 2008-10-14 | Google Inc. | System and method of accessing a document efficiently through multi-tier web caching |
| US8676922B1 (en) | 2004-06-30 | 2014-03-18 | Google Inc. | Automatic proxy setting modification |
| CN100440813C (zh) * | 2004-09-28 | 2008-12-03 | 上海贝尔阿尔卡特股份有限公司 | 因特网协议第六版接入网的连接中断检测方法和设备 |
| JP4033187B2 (ja) * | 2004-10-08 | 2008-01-16 | ブラザー工業株式会社 | 設定管理プログラム，管理デバイスおよび設定管理システム |
| US20070168292A1 (en) * | 2004-12-21 | 2007-07-19 | Fabrice Jogand-Coulomb | Memory system with versatile content control |
| US7436783B2 (en) * | 2005-04-04 | 2008-10-14 | Apple Inc. | Method and apparatus for detecting a router that improperly responds to ARP requests |
| US8583827B2 (en) * | 2005-05-26 | 2013-11-12 | Citrix Systems, Inc. | Dynamic data optimization in data network |
| JP4241681B2 (ja) | 2005-07-05 | 2009-03-18 | ブラザー工業株式会社 | 情報処理装置、およびプログラム |
| CN100454849C (zh) | 2005-08-05 | 2009-01-21 | 华为技术有限公司 | 下一代网络中的故障检测方法 |
| US20070056042A1 (en) * | 2005-09-08 | 2007-03-08 | Bahman Qawami | Mobile memory system for secure storage and delivery of media content |
| KR100739807B1 (ko) * | 2006-02-06 | 2007-07-13 | 삼성전자주식회사 | Ｄｈｃｐ를 이용한 핸드오버 정보 검색 및 획득 방법 및장치 |
| US8804759B2 (en) * | 2006-02-28 | 2014-08-12 | Hewlett-Packard Development Company, L.P. | Network name resolution into network address |
| JP2009528743A (ja) | 2006-03-02 | 2009-08-06 | ノキア コーポレイション | 無線アクセス・ネットワークを経由した接続先ネットワークへのアクセス支援 |
| CN104734908B (zh) * | 2006-03-02 | 2018-07-27 | 诺基亚技术有限公司 | 支持经由无线接入网络来接入目的网络 |
| US8812651B1 (en) | 2007-02-15 | 2014-08-19 | Google Inc. | Systems and methods for client cache awareness |
| US8935748B2 (en) * | 2007-10-31 | 2015-01-13 | Microsoft Corporation | Secure DNS query |
| US7958261B2 (en) * | 2008-02-14 | 2011-06-07 | Microsoft Corporation | Domain name cache control system generating series of varying nonce-bearing domain names based on a function of time |
| US7865618B2 (en) * | 2008-02-22 | 2011-01-04 | Micorsoft Corporation | Defeating cache resistant domain name systems |
| KR101548959B1 (ko) * | 2008-06-04 | 2015-09-01 | 삼성전자주식회사 | 패킷 통신 시스템에서 네트워크 주소 설정을 위한 장치 및방법 |
| US20100041398A1 (en) * | 2008-08-14 | 2010-02-18 | Donna Michaels Sand | Method for providing wireless subscriber services |
| US8984628B2 (en) | 2008-10-21 | 2015-03-17 | Lookout, Inc. | System and method for adverse mobile application identification |
| US8347386B2 (en) | 2008-10-21 | 2013-01-01 | Lookout, Inc. | System and method for server-coupled malware prevention |
| US9781148B2 (en) | 2008-10-21 | 2017-10-03 | Lookout, Inc. | Methods and systems for sharing risk responses between collections of mobile communications devices |
| US8533844B2 (en) | 2008-10-21 | 2013-09-10 | Lookout, Inc. | System and method for security data collection and analysis |
| US9235704B2 (en) | 2008-10-21 | 2016-01-12 | Lookout, Inc. | System and method for a scanning API |
| US8108933B2 (en) | 2008-10-21 | 2012-01-31 | Lookout, Inc. | System and method for attack and malware prevention |
| US9043919B2 (en) | 2008-10-21 | 2015-05-26 | Lookout, Inc. | Crawling multiple markets and correlating |
| US9367680B2 (en) | 2008-10-21 | 2016-06-14 | Lookout, Inc. | System and method for mobile communication device application advisement |
| US8087067B2 (en) | 2008-10-21 | 2011-12-27 | Lookout, Inc. | Secure mobile platform system |
| US8243740B1 (en) * | 2008-11-21 | 2012-08-14 | Sprint Communications Company L.P. | Using domain name server response and internet protocol version 6 to conserve internet protocol version 4 addresses |
| US9104618B2 (en) * | 2008-12-18 | 2015-08-11 | Sandisk Technologies Inc. | Managing access to an address range in a storage device |
| US8538815B2 (en) | 2009-02-17 | 2013-09-17 | Lookout, Inc. | System and method for mobile device replacement |
| US9955352B2 (en) | 2009-02-17 | 2018-04-24 | Lookout, Inc. | Methods and systems for addressing mobile communications devices that are lost or stolen but not yet reported as such |
| US8467768B2 (en) | 2009-02-17 | 2013-06-18 | Lookout, Inc. | System and method for remotely securing or recovering a mobile device |
| US8156249B2 (en) * | 2009-02-20 | 2012-04-10 | Microsoft Corporation | Using server type to obtain network address |
| TW201039593A (en) * | 2009-04-30 | 2010-11-01 | Vivotek Inc | DDNS system and auto-registering method |
| EP2465247B1 (en) * | 2009-08-14 | 2019-08-14 | Akamai Technologies, Inc. | Method for correlating nameserver ipv6 and ipv4 addresses |
| US8825859B2 (en) | 2009-12-23 | 2014-09-02 | Citrix Systems, Inc. | System and methods for mixed mode of IPv6 and IPv4 DNS of global server load balancing |
| EP2517406B1 (en) * | 2009-12-23 | 2015-06-17 | Citrix Systems Inc. | Systems and methods for mixed mode of ipv6 and ipv4 dns of global server load balancing |
| US9098335B2 (en) | 2009-12-23 | 2015-08-04 | Citrix Systems, Inc. | Systems and methods for managing spillover limits in a multi-core system |
| WO2012053162A1 (ja) * | 2010-10-18 | 2012-04-26 | 日本電気株式会社 | ネームデータベースサーバ、名前解決システム、エントリ検索方法およびエントリ検索プログラム |
| JP5383927B2 (ja) * | 2010-11-17 | 2014-01-08 | 株式会社日立製作所 | 通信ネットワークに接続されている通信装置を発見する方法及び管理装置 |
| US8671221B2 (en) * | 2010-11-17 | 2014-03-11 | Hola Networks Ltd. | Method and system for increasing speed of domain name system resolution within a computing device |
| US8806030B2 (en) * | 2010-12-06 | 2014-08-12 | Microsoft Corporation | Multichannel connections in file system sessions |
| US9929951B1 (en) * | 2011-05-24 | 2018-03-27 | Amazon Technologies, Inc. | Techniques for using mappings to manage network traffic |
| US8738765B2 (en) * | 2011-06-14 | 2014-05-27 | Lookout, Inc. | Mobile device DNS optimization |
| US20120324568A1 (en) * | 2011-06-14 | 2012-12-20 | Lookout, Inc., A California Corporation | Mobile web protection |
| US8788881B2 (en) | 2011-08-17 | 2014-07-22 | Lookout, Inc. | System and method for mobile device push communications |
| US8705545B2 (en) * | 2011-08-18 | 2014-04-22 | Oracle International Corporation | N-way routing packets across an intermediate network |
| US9330188B1 (en) | 2011-12-22 | 2016-05-03 | Amazon Technologies, Inc. | Shared browsing sessions |
| US9336321B1 (en) | 2012-01-26 | 2016-05-10 | Amazon Technologies, Inc. | Remote browsing and searching |
| US8839087B1 (en) | 2012-01-26 | 2014-09-16 | Amazon Technologies, Inc. | Remote browsing and searching |
| US9374244B1 (en) * | 2012-02-27 | 2016-06-21 | Amazon Technologies, Inc. | Remote browsing session management |
| US9589129B2 (en) | 2012-06-05 | 2017-03-07 | Lookout, Inc. | Determining source of side-loaded software |
| US9407443B2 (en) | 2012-06-05 | 2016-08-02 | Lookout, Inc. | Component analysis of software applications on computing devices |
| US8655307B1 (en) | 2012-10-26 | 2014-02-18 | Lookout, Inc. | System and method for developing, updating, and using user device behavioral context models to modify user, device, and application state, settings and behavior for enhanced user security |
| CN103051739A (zh) * | 2012-12-11 | 2013-04-17 | 中兴通讯股份有限公司 | 一种网络终端及其配置ip地址方法 |
| US9208215B2 (en) | 2012-12-27 | 2015-12-08 | Lookout, Inc. | User classification based on data gathered from a computing device |
| US9374369B2 (en) | 2012-12-28 | 2016-06-21 | Lookout, Inc. | Multi-factor authentication and comprehensive login system for client-server networks |
| US8855599B2 (en) | 2012-12-31 | 2014-10-07 | Lookout, Inc. | Method and apparatus for auxiliary communications with mobile communications device |
| US9424409B2 (en) | 2013-01-10 | 2016-08-23 | Lookout, Inc. | Method and system for protecting privacy and enhancing security on an electronic device |
| US8990638B1 (en) | 2013-03-15 | 2015-03-24 | Digimarc Corporation | Self-stabilizing network nodes in mobile discovery system |
| US9578137B1 (en) | 2013-06-13 | 2017-02-21 | Amazon Technologies, Inc. | System for enhancing script execution performance |
| US10152463B1 (en) | 2013-06-13 | 2018-12-11 | Amazon Technologies, Inc. | System for profiling page browsing interactions |
| US9642008B2 (en) | 2013-10-25 | 2017-05-02 | Lookout, Inc. | System and method for creating and assigning a policy for a mobile communications device based on personal data |
| US10122747B2 (en) | 2013-12-06 | 2018-11-06 | Lookout, Inc. | Response generation after distributed monitoring and evaluation of multiple devices |
| US9753796B2 (en) | 2013-12-06 | 2017-09-05 | Lookout, Inc. | Distributed monitoring, evaluation, and response for multiple devices |
| CA2982463C (en) | 2015-05-01 | 2019-03-05 | Lookout, Inc. | Determining source of side-loaded software |
| US10735461B2 (en) | 2015-10-21 | 2020-08-04 | Verisign, Inc. | Method for minimizing the risk and exposure duration of improper or hijacked DNS records |
| US10819673B2 (en) * | 2016-02-23 | 2020-10-27 | Level 3 Communications, Llc | Systems and methods for content server rendezvous in a dual stack protocol network |
| US10218697B2 (en) | 2017-06-09 | 2019-02-26 | Lookout, Inc. | Use of device risk evaluation to manage access to services |
| US11785658B2 (en) * | 2021-06-24 | 2023-10-10 | Mediatek Inc. | Method and apparatus for performing internet reachability management with aid of indicator |
| US20230216825A1 (en) * | 2021-12-31 | 2023-07-06 | T-Mobile Innovations Llc | Gateway based ip address translation in communication networks |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5459837A (en) * | 1993-04-21 | 1995-10-17 | Digital Equipment Corporation | System to facilitate efficient utilization of network resources in a computer network |
| US7165116B2 (en) * | 2000-07-10 | 2007-01-16 | Netli, Inc. | Method for network discovery using name servers |
| WO2002039699A1 (en) | 2000-11-09 | 2002-05-16 | Cacheflow, Inc. | Domain name system extensions to support reverse proxy operations and layer-7 redirection |
| JP2002261794A (ja) | 2001-03-01 | 2002-09-13 | Zion Ltd | ホスト接続装置及び方法、並びにそのプログラム |
| US6959333B2 (en) * | 2001-05-08 | 2005-10-25 | Lucent Technologies Inc. | Technique for content delivery over the internet |
| US20060020688A1 (en) * | 2001-05-14 | 2006-01-26 | At&T Corp. | System having generalized client-server computing |
-
2003
- 2003-01-21 JP JP2003012283A patent/JP3703457B2/ja not_active Expired - Fee Related
-
2004
- 2004-01-13 US US10/756,883 patent/US7415536B2/en not_active Expired - Fee Related
- 2004-01-14 EP EP20040250144 patent/EP1441487A3/en not_active Withdrawn
- 2004-01-16 CN CNB2004100022488A patent/CN100484125C/zh not_active Expired - Fee Related
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006222631A (ja) * | 2005-02-09 | 2006-08-24 | Hitachi Ltd | 輻輳制御装置、および、ネットワークの輻輳制御方法 |
| JP4512192B2 (ja) * | 2005-02-09 | 2010-07-28 | 株式会社日立製作所 | 輻輳制御装置、および、ネットワークの輻輳制御方法 |
| JP2009212878A (ja) * | 2008-03-05 | 2009-09-17 | Nec Infrontia Corp | ルータ装置、通信システム及びそれらに用いる不正経路確認方法 |
| JP2011055434A (ja) * | 2009-09-04 | 2011-03-17 | Yamaha Corp | 通信装置 |
| JP2012109887A (ja) * | 2010-11-19 | 2012-06-07 | Nec Access Technica Ltd | リソースレコード制御システム、リソースレコード制御方法、アプリケーション判別方法およびプログラム |
| JP2012249015A (ja) * | 2011-05-26 | 2012-12-13 | Nippon Telegr & Teleph Corp <Ntt> | フォールバック検知装置、フォールバック検知方法及びフォールバック検知プログラム |
| JP2013026993A (ja) * | 2011-07-26 | 2013-02-04 | Pfu Ltd | ノード検出装置、ノード検出方法、及びプログラム |
| US8943195B2 (en) | 2011-07-26 | 2015-01-27 | Pfu Limited | Node detection apparatus, node detection method and computer readable medium |
| KR101520811B1 (ko) * | 2014-07-11 | 2015-05-21 | 주식회사 엘지유플러스 | Ims 망에서 호 세션을 제어하는 방법 및 이를 수행하는 장치 |
Also Published As
| Publication number | Publication date |
|---|---|
| US7415536B2 (en) | 2008-08-19 |
| EP1441487A3 (en) | 2005-12-14 |
| CN1520123A (zh) | 2004-08-11 |
| CN100484125C (zh) | 2009-04-29 |
| JP3703457B2 (ja) | 2005-10-05 |
| EP1441487A2 (en) | 2004-07-28 |
| US20040143579A1 (en) | 2004-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3703457B2 (ja) | アドレス通知方法、プログラム、及び、装置 | |
| JP4668775B2 (ja) | Ｄｎｓサーバ装置 | |
| JP4159337B2 (ja) | 仮想ネットワーク名の解決方法 | |
| JP4965559B2 (ja) | リソースアドレスリクエスト管理方法及び関連するゲートウェイ装置 | |
| US9584360B2 (en) | Global server load balancing support for private VIP addresses | |
| US9515981B2 (en) | Method and system for increasing speed of domain name system resolution within a computing device | |
| JP4684534B2 (ja) | ピアツーピア環境においてキャッシュされた資源間における資源の相同性 | |
| JP4234482B2 (ja) | 動的ｄｎｓ登録方法、ドメイン名解決方法、代理サーバ、及びアドレス変換装置 | |
| US7573903B2 (en) | IPv6/IPv4 translator | |
| US8954603B2 (en) | Communication device and communication method of the same | |
| US20060031534A1 (en) | Position identifier management apparatus and method, mobile computer, and position identifier processing method | |
| JP2007207231A (ja) | ネットワークにおける分散サービスへのアクセス法 | |
| CN106161667A (zh) | 一种域名解析方法及装置 | |
| TW200924462A (en) | System and method for connection of hosts behind NATs | |
| JP3601526B2 (ja) | 代理登録装置およびネットワークシステムおよびプログラム | |
| US9497067B2 (en) | Address determination apparatus, communication system, address determination method, and program | |
| JP3052826B2 (ja) | アドレス変換装置 | |
| JP2004350133A (ja) | 接続制御方法、接続制御プログラム、及び、接続装置 | |
| US7610403B2 (en) | Device retrieving a name of a communications node in a communications network | |
| JPH1117726A (ja) | Ｄｎｓ機能を内蔵したｉｐネットワークの結合制御装置 | |
| JP2002217941A (ja) | ネットワークアドレス再割り当て方法及びルータ | |
| JP2015220483A (ja) | ＤＮＳ−Ｐｒｏｘｙ機能を有する中継装置 | |
| JP4905376B2 (ja) | 複数のネットワークプロトコルに対応した通信システムおよび通信方法 | |
| JP2004007151A (ja) | ルータとそれに接続されるｄｄｎｓクライアント端末、及びｄｄｎｓシステム | |
| JP3708085B2 (ja) | Ｄｎｓ問い合わせ装置およびｄｎｓ問い合わせ方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050413 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050419 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050614 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050705 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050719 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080729 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090729 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090729 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100729 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100729 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110729 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120729 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |