JP3703457B2 - アドレス通知方法、プログラム、及び、装置 - Google Patents
アドレス通知方法、プログラム、及び、装置 Download PDFInfo
- Publication number
- JP3703457B2 JP3703457B2 JP2003012283A JP2003012283A JP3703457B2 JP 3703457 B2 JP3703457 B2 JP 3703457B2 JP 2003012283 A JP2003012283 A JP 2003012283A JP 2003012283 A JP2003012283 A JP 2003012283A JP 3703457 B2 JP3703457 B2 JP 3703457B2
- 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.)
- Expired - Fee Related
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/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/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/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)
Description
【発明の属する技術分野】
本発明は、アドレス通知方法、プログラム、及び、装置に関する。
【0002】
【従来の技術】
近年、現在のインターネットを支える基盤プロトコルであるIPv4(Internet Protocol version 4)の次世代バージョンであるIPv6(Internet Protocol version 6)の検討が開始された。
【0003】
IPv6はIPv4に置き換わる技術であるが、これまでのIPv4のネットワークを排除するものではなく、IPv4からIPv6への移行技術も検討されている。移行技術にはトンネル技術、トランスレート技術、デュアル技術が存在する。
【0004】
このうち、デュアル技術は、IPv4とIPv6を同一のネットワーク上で運用することにより、ネットワーク上で利用する機器やアプリケーションのスムーズな移行を助ける技術である。これからは、このデュアル技術を用いたIPv4/IPv6デュアル環境のネットワークが広がり、インターネット上で利用されるすべてのアプリケーションがIPv6に完全に移行されるまでの相当長い期間、このデュアル環境ネットワークが利用されると考えられる。
【0005】
このデュアル環境におけるIPv4/IPv6アクセス可能なE−MailやWebなどのサービスを利用した際、IPv4とIPv6のどちらの通信プロトコルを利用して通信するかを決定する「通信プロトコル選択手順」では、通信相手のサーバの指定をIPv4/IPv6アドレスで指定した場合、それぞれ指定された通信プロトコルを利用する。
【0006】
しかしながら、通信相手のサーバの指定をFQDN(Fully Qualified Domain Name)で指定した場合、どちらの通信プロトコルを利用して通信するかは、以下の手順で決定される。
【0007】
すなわち、
1.IPv6アドレスをDNSに問合せる。
2.IPv6アドレスの取得に成功すればIPv6で通信を行う。
3.IPv6アドレスの取得に失敗した場合、続いてIPv4アドレスをDNSに問合せる。
4.IPv4アドレスの取得に成功すればIPv4で通信を行う。
5.IPv4アドレスの取得も失敗した場合は、サーバが存在しないことになりエラー終了となる。
【0008】
これは、現状の各種アプリケーションの動作内容を解析しても、IETF(The Internet Engineering Task Force)にて規定している「Basic Socket Interface Extensions for IPv6」(RFC2133、RFC2553)を参照しても、上記の通信プロトコル選択手順を行っている。
【0009】
WebやE−Mailなど、一般的なインターネットアプリケーションでは、DNSを利用した通信相手の特定を行っている。
【0010】
しかしながら、IPv4/IPv6アクセス可能なサーバでは、一つのネットワークインターフェースにIPv4/IPv6それぞれのアドレスを設定しているが、サーバ名としてはFQDNを一つだけ登録することがしばしばである。
【0011】
つまり、IPv4/IPv6アクセス可能なWebサーバ「www.server.net」が存在した場合、このサーバにはIPv4アドレスとIPv6アドレスが対応していることになる。DNSへの登録内容においても、IPv4アドレスを設定する「A」レコードと、IPv6アドレスを設定する「AAAA」レコードの二つを、「www.server.net」に設定することが一般的に多い。
【0012】
通信相手のサーバの指定をIPv4/IPv6アドレスで指定する通信プロトコル選択手順は利用されにくく、通信相手のサーバの指定をFQDNで指定することが多いので、IPv6通信プロトコルを優先的に使用するアクセスがしばしばである。
【0013】
クライアントやサーバが属しているデュアル環境のネットワークでは、IPv4もIPv6も同一の物理回線上にて通信しているが、そのネットワークの外部、あるいは、そのネットワークを提供しているISPの外部では、IPv4とIPv6はまったくの別回線上で通信が行われていることが多い。事実、現在サービス提供されているIPv6接続サービスの多くは、トンネル接続によるものである。
【0014】
また、日本のIXにおいて、同一の回線口においてISP同士がIPv4/IPv6両方の通信トラフィックを交換しているところはまずない。
【0015】
ISP内部においても、IPv6バックボーンを別途構築したり、トンネル技術やMPLSなどを利用して仮想的に独立したネットワークを構築したりするなどして、IPv4とIPv6を区別した運用を行っていることがしばしばである。
【0016】
これより、デュアル環境におけるIPv4/IPv6通信品質は、同一のデュアルネットワーク内では同等だが、外部のネットワークとの通信に関しては、通信プロトコルにより帯域や輻輳、クオリティは全く異なる。
【0017】
また、IPv6はいまだ実験運用が主であり、運用ノウハウや対応機器の信頼性を現在高めている最中である。つまり、IPv6通信プロトコルだけが通信不通となることが、比較的頻度に発生する。
【0018】
一方、DNSサーバの問合せに利用する通信プロトコルはIPv4を利用するものが一般的に多い。例えば、ISC(Internet Software Consortium)提供のBINDは現在、BIND4、BIND8が広く世界で利用されているが、IPv6通信プロトコルを利用して問合せ・返信を行うことができるバージョンはBIND9のみである。つまり、DNSに「AAAA」レコードの登録は可能だが、IPv6通信プロトコルを利用しての問合せ・返信はできないのである。
【0019】
また、Windows(登録商標) XPでは、サポート外でありながら、IPv6プロトコルスタックを搭載したOSであるが、リゾルバはIPv6通信によるDNS問合せが行えない。
【0020】
このような状況から、IPv6通信が途中切断している場合でも、通信相手となるサーバのDNS問合せはIPv4通信プロトコルを利用して行うことができ、対象サーバに「AAAA」レコードでの登録がある場合は、IPv6アドレスを取得できてしまう。
【0021】
【発明が解決しようとする課題】
以上のような状況から、途中のネットワークにおいて、IPv6接続性のみが切断している場合(IPv4接続性は保たれている場合)には、IPv6アドレスは取得できるので、IPv6を利用した通信を試みるが、IPv6ではサーバとの通信はできないので、数十秒のタイムアウトを経てから、IPv4アドレスを取得して、IPv4を利用した通信を行う現象が現れる。
【0022】
この現象は、特に、WebやE−Mailといった、何度もアクセスするようなアプリケーションでは、そのたびにタイムアウト待ちをすることとなり、ユーザにとって大変フラストレーションがたまるものといえる。また、IPv6の利用に際し、ユーザにとってデュアル環境が「利用しにくい環境」と認識されてしまう可能性がある。
【0023】
本発明は、この問題を解決するために成されるものであり、アドレスが取得できても、接続できない事態を減らすことを目的とする。
【0024】
【課題を解決するための手段】
本発明のアドレス通知方法、プログラム、及び、装置は、第1の装置のアドレスの問合せを第2の装置から受けると、前記第1の装置のアドレスを第3の装置に問合せ、前記第3の装置から得られた前記第1の装置のアドレスを前記第2の装置に通知するアドレス通知方法、プログラム、及び、装置において、前記第1の装置のアドレスと共に前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とする。
【0026】
【発明の実施の形態】
以下、図面を参照して本発明の一実施形態を詳細に説明する。
【0027】
図1は本発明の一実施形態のネットワークの構成図である。
【0028】
図1において、101はユーザの所属するIPv4/IPv6デュアル環境なネットワークである。ユーザネットワーク101には、ユーザの利用するIPv4/IPv6アクセス可能なWebクライアント106が接続している。また、IPv4/IPv6アクセス可能なDNSサーバ109もユーザネットワーク101に同じく接続している。DNSサーバ109は、ユーザネットワーク101に属する端末群のドメインを管理するDNSである。
【0029】
107はIPv4/IPv6アクセス可能なWebサーバであり、IPv4/IPv6デュアル環境のサーバネットワーク103に接続している。108はIPv4/IPv6アクセス可能なDNSサーバであり、IPv4/IPv6デュアル環境のドメイン管理ネットワーク102に接続している。
【0030】
Webサーバ107にはFQDNが割当ててあり、そのFQDNの属するドメインを管理するDNSサーバがDNSサーバ108である。
【0031】
ユーザネットワーク101とドメイン管理ネットワーク102とサーバネットワーク103は、IPv4インターネット104を介してIPv4通信プロトコルを利用して相互に通信が可能である。また、ユーザネットワーク101とドメイン管理ネットワーク102とサーバネットワーク103は、IPv6インターネット105を介したIPv6通信プロトコルを利用して相互に通信が可能である。
【0032】
図2は、図1において説明した各ネットワークの属するドメイン名と、各ホストに割当てたFQDNの一例である。また、各ネットワークに割当てたIPv4及びIPv6ネットワークアドレスと、各ホストに割当てたIPv4及びIPv6アドレスの一例も示す。
【0033】
ユーザネットワーク101に属するDNSサーバ109は、「client.com」ドメインを管理するマスタゾーンファイルを保持している。一方、ドメイン管理ネットワーク102に属するDNSサーバ108は、「server.net」ドメインを管理するマスタゾーンファイルを保持している。
【0034】
図3は、本実施形態での機能を実現するソフトウェアプログラムを動作させる構成の一例を示したものである。
【0035】
例えば、DNSサーバ109は、図3に示すコンピュータ900の機能により、本実施形態での機能を実現する。コンピュータ900は、CPU901と、ROM902と、RAM903と、ハードディスク(HD)907及びフロッピー(登録商標)ディスク(FD)908のディスクコントローラ(DC)905と、ネットワークインタフェースカード(NIC)906とが、システムバス904を介して互いに通信可能に接続された構成としている。そして、ネットワークインタフェースカード906は、図1に示したネットワーク101を、システムバス904に接続する。
【0036】
DNSサーバ109は、クライアント106(第2の装置)から受けたサーバ107(第1の装置)のアドレスの問合せに対する返信メッセージを返信する返信装置であり、クライアント106(第2の装置)からサーバ107(第1の装置)のアドレスの問合せを受けると、サーバ107のアドレスをクライアント106に通知するアドレス通知装置である。
【0037】
ネットワークインタフェースカード906は、ネットワーク101を接続する接続手段である。
【0038】
また、CPU901は、クライアント106から受けたサーバ107のアドレスの問合せに対する返信メッセージを生成する生成手段であり、サーバ107のアドレスを用いてサーバ107との接続試験を行い、接続試験が失敗した場合には、サーバ107のアドレスがないことを示す返信メッセージを生成する。また、CPU901は、クライアント106からサーバ107のアドレスの問合せを受けると、サーバ107のアドレスをクライアント106に通知する通知手段であり、サーバ107のアドレスをDNSサーバ108(第3の装置)に問合せ、DNSサーバ108から得られたサーバ107のアドレスとともに、DNSサーバ108から得られたサーバ107のアドレスの有効期限より短い有効期限を、サーバ107のアドレスの有効期限として、クライアント106に通知する。
【0039】
CPU901は、ROM902あるいはHD907に記憶されたソフトウェア、あるいはFD908より供給されるソフトウェアを実行することで、システムバス904に接続された各構成部を統括的に制御する。すなわち、CPU901は、以下に説明する処理シーケンスに従った処理プログラムを、ROM902、あるいはHD907、あるいはFD908から読み出して実行することで、本実施形態での動作を実現するための制御を行う。
【0040】
RAM903は、CPU901の主メモリあるいはワークエリア等として機能する。DC905は、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイル、ネットワーク管理プログラム、および本実施形態における下記処理プログラム等を記憶するHD907、およびFD908とのアクセスを制御する。NIC906は、ネットワーク101を通じてIPv4インターネット104に接続するサーバ107等と、IPv4通信プロトコルを用いて相互にデータのやり取りをする。また、NIC906は、ネットワーク101を通じてIPv6インターネット105に接続するサーバ107等と、IPv6通信プロトコルを用いて相互にデータのやり取りをする。
【0041】
なお、Webクライアント106、Webサーバ107、DNSサーバ108も、DNSサーバ109と同様に、図3にしめるコンピュータ900のように構成可能である。Webクライアント106、Webサーバ107、DNSサーバ108は、夫々、NIC906を介して、ネットワーク101、103、102に接続される。
【0042】
図4はWebクライアント106とWebサーバ107の通信確立までの処理概要を示したモジュール図である。
【0043】
301〜303はWebクライアント106内のモジュールである。304〜308はDNSサーバ109内のモジュールである。309、310はDNSサーバ108内のモジュールである。311はWebサーバ107内のモジュールである。
【0044】
なお、モジュール304、307、308は、DNSサーバ109のROM902あるいはHD907に記憶されたソフトウェア、あるいはFD908より供給されるソフトウェアにより実現される。CPU901は、モジュール304、307、308を実現するためのプログラムを、ROM902、あるいはHD907、あるいはFD908から読み出して実行することで、モジュール304、307、308の機能を実現する。
【0045】
また、マスタゾーンファイル305、キャッシュデータ306は、RAM903、又は、HD907に格納される。
【0046】
Webクライアント106においても、モジュール301、302は、ソフトウェアにより実現され、キャッシュデータ303は、RAM903、又は、HD907に格納される。
【0047】
また、DNSサーバ108においても、モジュール309は、ソフトウェアにより実現され、マスタゾーンファイル310は、RAM903、又は、HD310に格納される。Webサーバ107においても、サーバアプリケーション311は、ソフトウェアにより実現される。
【0048】
次に、Webクライアント106とWebサーバ107の通信確立までの処理を説明する。
【0049】
まず、クライアントアプリケーション301にて、通信相手となるサーバアプリケーションが指定される。指定方法としては本実施形態のWebの場合、「http://www.server.net」というURLの形にて指定される。クライアントアプリケーション301はこのURLより、サーバアプリケーションのホスト名であるFQDN「www.server.net」を抽出し、リゾルバモジュール302に、指定したFQDNに対応するIPv4/IPv6どちらかのアドレスを問合せる。
【0050】
FQDNからのアドレス問合せを受け取ったリゾルバモジュール302は、以前に問合せた結果が記録されているキャッシュデータ303に、「www.server.net」に対応するIPv6アドレスがあるかどうかをチェックする。キャッシュデータ303に対応するIPv6アドレスが存在しない場合、続いて、IPv4アドレスに関してもキャッシュデータ303を調査する。
【0051】
どちらのアドレスもキャッシュデータ303に存在しない場合、リゾルバモジュール302は、DNSサーバ109に対して指定したFQDNに対するIPv4/IPv6アドレスの問合せ(以降、正引き問合せと言う)を行う。
【0052】
ここで正引き問合せで利用する通信プロトコルとして選択される通信プロトコルは、Webクライアント106のOSに設定しているDNSサーバのアドレスをどちらの通信プロトコルで指定したかによって決定される。一方、リゾルバモジュール302から送られる正引き問合せは、前述したとおり、「AAAA」DNS Queryメッセージ(つまり、IPv6アドレスの正引き問合せ)を初めに送信する。この送信に用いられる通信プロトコルは、Webクライアント106のOSに設定しているDNSサーバのアドレスがIPv6アドレスであれば、IPv6であり、IPv4アドレスであれば、IPv4である。
【0053】
送信した正引き問合せはDNSサーバ109内のネームサーバモジュール304にて受信される。ネームサーバモジュール304は、ユーザネットワーク101に属するドメイン「client.com」の管理を行っており、このドメインに属するすべてのFQDNとIPv4/IPv6アドレスを対としたレコードを、マスタゾーンファイル305に保持している。ネームサーバモジュール304は、管理しているドメイン「client.com」に属するFQDNに対しての正引き問合せを受信した場合、マスタゾーンファイル305より情報を抽出し、返答する。
【0054】
ネームサーバモジュール304は、管理外となるその他のドメインに関する正引き問合せを受信した場合、以前にDNSサーバ109によって正引き問合せが行われた結果が記録されているキャッシュデータ306を検索する。このキャッシュデータ306はDNSサーバ109内部のデータであり、Webクライアント106内のキャッシュデータ303とは独立して存在する。
【0055】
キャッシュデータ306に該当データが存在した場合、ネームサーバモジュール304はキャッシュデータ306から該当データを取得し、その有効性のチェックを行う。この有効性のチェックについては後ほど詳細に説明するが、そのチェックの結果によって、該当データのIPv6アドレスをリゾルバモジュール302に返信して、本処理は終了する。例えば、このチェックの結果によって、有効性が否定された場合、ネームサーバモジュール304は、キャッシュデータ306にアドレスが存在していても、問合せを受けたアドレスがないことを示すメッセージを返信する。
【0056】
一方、キャッシュデータ306に該当データが存在しない場合、つまり、問合せを受けた「www.server.net」のIPv6アドレスがキャッシュデータ306に存在しない場合は、依頼を受けた正引き問合せの中継を行うべく、DNSサーバ109内のリゾルバモジュール307は、外部のDNSサーバに対して正引き問合せを行う。このリゾルバモジュール307における正引き問合せは、RFC1034ならびにRFC1035にて規定されるアルゴリズムに即して行われる。つまり、ルートDNSサーバ、「net」DNSサーバ、「server.net」DNSサーバと順番に配下のドメインを問合せていく。すなわち、ネームサーバモジュール304は、サーバ107(第1の装置)のアドレスの問合せをクライアント106(第2の装置)から受けると、リゾルバモジュール307は、サーバ107のアドレスをDNSサーバ108(第3の装置)に問合せる。
【0057】
「www.server.net」の正引き問合せを受けたネームサーバモジュール309は、マスタゾーンファイル310に記載されている「www.server.net」のレコードを検索し、該当のアドレスを抽出する。前述したとおり、上記での正引き問合せの全てにおいて、IPv6アドレスの正引き問合せを初めに送信する。ネームサーバモジュール309がマスタゾーンファイル310より抽出した「www.server.net」のIPv6アドレスをDNS Responseとしてリゾルバモジュール307に返信する。
【0058】
ネームサーバモジュール309からの返信を受信したリゾルバモジュール307は、受信したデータをキャッシュデータ306に記録する。同時に、受信した「www.server.net」のIPv6アドレスを通信プロトコルチェックモジュール308に渡し、チェック処理を行う。通信プロトコルチェックモジュール308では、渡されたIPv6アドレスのチェック処理(接続試験)を行い、その結果をキャッシュデータ306に記録する。このチェック処理(接続試験)については後ほど詳細に説明する。
【0059】
一方、ネームサーバモジュール304は、リゾルバモジュール307が「www.server.net」のIPv6アドレスを取得し、キャッシュデータに306に記録したことを確認した時点で、キャッシュデータ306より該当データを取得し、問合せ元であるリゾルバモジュール302に返信を行う。すなわち、ネームサーバモジュール304は、DNSサーバ108(第3の装置)から得られたサーバ107(第3の装置)のアドレスをクライアント106(第2の装置)に通知する。
【0060】
リゾルバモジュール302では、ネームサーバモジュール304からの返信を受信すると、「www.server.net」のIPv6アドレスが取得できたかどうかをチェックする。有効なIPv6アドレスを取得したリゾルバモジュール302は、該当データをキャッシュデータ303に記録し、クライアントアプリケーション301にIPv6アドレスを返信する。
【0061】
一方、リゾルバモジュール302において、返信されたデータに有効なIPv6アドレスが存在しなかった場合、通信相手となる「www.server.net」にはIPv6アドレスが存在しないと判断し、リゾルバモジュール302は「www.server.net」の「A」DNS Queryメッセージ(つまり、IPv4アドレスの正引き問合せ)を新たにネームサーバモジュール304に送信する。以下、処理内容はIPv6アドレスの正引き問合せと同じである。このIPv4アドレスの正引き問合せの結果、IPv4アドレスも存在しないと判断した場合には、その旨を、クライアントアプリケーション301に通知する。
【0062】
以上のようにして、クライアントアプリケーション301は、リゾルバモジュール302への「www.server.net」アドレス問合せに対する返信としてIPv6アドレス、もしくは、IPv4アドレスを取得する。クライアントアプリケーション301は取得したアドレスを用いて通信相手のサーバアプリケーション311を特定し、通信を開始する。
【0063】
図5で、DNSサーバ109のキャッシュデータ306におけるエントリデータの内容を説明する。
【0064】
図中の一列が一つのエントリデータである。エントリデータにはいくつかの項目情報が含まれており、それぞれは以下のような情報を含んでいる。「FQDN」701はキャッシュデータとして保持するターゲットホストのFQDNを保持する。
【0065】
「Type」702はそのFQDNに定義されたレコードタイプを示している。このレコードタイプとは、DNSサーバのマスタゾーンファイル中の記述で、IPv4アドレスの定義レコードは「A」、IPv6アドレスの定義レコードは「AAAA」としているので、キャッシュデータ内でも同一の表記を用いている。正引き問合せに含まれる情報は、「www.server.net」の「AAAA」を問合せという内容なので、FQDNとレコードタイプを保持することで、キャッシュデータ内に該当する情報があるかを検索することが可能となる。
【0066】
次の項目である「Address」703にはIPv4アドレスもしくはIPv6アドレスが保持される。図からも明らかなように、「www.server.net」というFQDNにIPv6アドレスとIPv4アドレスの両方がDNSにて登録されていた場合、二つのエントリ711、712を持つこととなる。
【0067】
ネームサーバモジュール309にてFQDNに対応するIPv4/IPv6アドレスを返信する際、キャッシュ可能な時間を含めてアドレス情報を問合せ者(リゾルバモジュール302)に返信する。
【0068】
「C−TTL」704は、そのキャッシュ可能な時間の値であり、実際にキャッシュデータ306にて保持していられる時間を意味している。一方、「R−TTL」705は、先に説明した「C−TTL」704と同様にキャッシュ可能な時間であるが、この数値はリゾルバモジュール302からの正引き問合せに対する返信に含めるキャッシュ可能時間である。
【0069】
本実施形態では、このデータ「C−TTL」704と「R−TTL」705を分割して管理し、FQDNを管理するDNSサーバ(DNSサーバ108にあたる)から通知されたTTL(キャッシュ可能時間「C−TTL」704)をそのまま問合せ者(リゾルバモジュール302にあたる)に通知せずに、問合せ者(リゾルバモジュール302)に対してTTL=0(「R−TTL」705)としてアドレス情報を返信することで、問合せ側のキャッシュデータ(キャッシュデータ303にあたる)にアドレス情報がキャッシュさせない効果がある。
【0070】
最後の「Check」には、通信プロトコルチェックモジュール308における有効性チェックの結果を保持する。保持する値としては、「OK」が有効(接続試験成功)を、「NG」が無効(接続試験失敗)を示しており、「−」がチェック前のデータであることを示している。
【0071】
表中の「mail.dual.biz」713のIPv6アドレス、「www.v4only.com」714のIPv4アドレスは、DNSサーバへの正引き問合せには成功したものの、アドレスの有効性チェックにて到達性がなかったので、無効なデータとしてキャッシュデータに保持されている例である。
【0072】
また、「mail.entry.ne.jp」715は、リゾルバモジュール307から新規にキャッシュデータに記録されたデータであるので、有効性チェックはチェック前の状態である。このとき、ネームサーバモジュール304はリゾルバモジュール302に対し、速やかに取得したアドレス情報を返信する必要があるので、初めての正引き問合せに対してはアドレスの有効性チェックの結果を待たずにアドレス情報を返信する。しかし、この際に返信したアドレスが無効な場合、クライアント側のキャッシュデータ303に該当のアドレス情報を保持されては、次回からの接続時にも、タイムアウトの問題が発生してしまうので、TTL=0として返信するために、R−TTLの値を「0」としている。
【0073】
図6を用いて、DNSサーバ109のネームサーバモジュール304にて処理されるフローを説明する。このフローは、DNSサーバ109のROM902あるいはHD907に記憶されたプログラム、あるいはFD908より供給されるプログラムの一部を示す。CPU901は、モジュール304を実現するためのプログラムを、ROM902、あるいはHD907、あるいはFD908から読み出して実行することで、以下の処理を実現する。
【0074】
401はネームサーバモジュール304が管理するドメイン以外に関する正引き問合せを待ち受けるループである。このリゾルバモジュール302からの正引き問合せは、NIC906により受信される。CPU901は、リゾルバモジュール302からの「www.server.net」の正引き問合せを受信した場合、402へと処理が進む。この際、IPv6アドレスの正引き問合せでもIPv4アドレスの正引き問合せでも同様に機能する。
【0075】
なお、ネームサーバモジュール304は、管理しているドメイン「client.com」に属するFQDNに対しての正引き問合せを受信した場合は、マスタゾーンファイル305より情報を抽出し、返答する。
【0076】
402ではキャッシュデータ306に問合せのFQDNに対応するIPv4/IPv6アドレス(リゾルバモジュール302から問合せられた方)が存在するかを検索する。検索の結果は403にて判定され、該当データ(「www.server.net」のIPv4アドレス、またはIPv6アドレス)が発見された場合は407に進み、該当データが発見されなかった場合には404へ進む。
【0077】
404ではリゾルバモジュール307に対し、受信した「www.server.net」の正引き問合せを外部のDNSサーバに向けて行うよう、問合せ内容をリゾルバモジュール307に送信し、問合せの依頼を行う。リゾルバモジュール307も、ネームサーバモジュール304と同様に、CPU901が、プログラムを、ROM902、あるいはHD907、あるいはFD908から読み出して実行することで、実現される処理モジュールである。
【0078】
上述のように、リゾルバモジュール307により「www.server.net」のIPv4/IPv6アドレスが解決し、キャッシュデータ306を通してその結果を取得する。なお、この問合せ依頼に関して、IPv4/IPv6どちらのアドレスの正引き問合せかは、前記401にて受信した正引き問合せの内容(IPv4又はIPv6のどちらに対する正引き問合せか)と同一のものである。
【0079】
CPU901は、ネームサーバモジュール304の処理を実行し、404において、リゾルバモジュール307による処理に移行し、リゾルバモジュール307による処理の結果が出ると、ネームサーバモジュール304の処理を再開する。
【0080】
ネームサーバモジュール304は、キャッシュデータ306を通して得られた結果を405にて判定する。405における判定にて、正引き問合せに対してIPv4/IPv6アドレスを取得できた場合には、407に進み、取得できなかった場合には406に進む。該当のIPv4/IPv6アドレスが取得できなかった場合には406にてリゾルバモジュール307にて得られた結果と同一の返信メッセージ(Response(nothing)メッセージ、あるいはErrorメッセージ)をリゾルバモジュール302に向けて送信し、待ち受けループ401に処理が戻る。
【0081】
一方、405における判定にて、該当のIPv4/IPv6アドレスを取得できた場合、及び、403における判定にて、キャッシュデータ306の検索によりIPv4/IPv6アドレスを取得できた場合、407にてそのアドレスの有効性に関してチェックを行う。アドレスの有効性の処理に関しては、通信プロトコルチェックモジュール308にて行われており、図5に示すように、その結果706がキャッシュデータ306のエントリに記録されている。そのチェック結果を抽出し、408にて判定している。408での判定では、キャッシュデータ306のエントリ内にある「check」項目706を参照し、この項目が「OK」の場合は有効な(接続試験に成功した)アドレス、「NG」の場合は無効な(接続試験に失敗した)アドレスと判定する。
【0082】
なお、この判定項目で「−」の場合が存在するが、それは通信プロトコルチェックモジュール308にてチェック前のデータであることを示し、404でリゾルバへの問合せ依頼をした際に現れる。このチェック前のデータの場合は、有効なアドレスとして判断される。
【0083】
401にて受信した「www.server.net」への正引き問合せがIPv6アドレスを求めるものである場合は、409にて有効なIPv6アドレスをキャッシュデータ306より抽出し、リゾルバモジュール302に対してResponse AAAAメッセージにて送信する。その際、メッセージ内のTTL値(このIPv6アドレスをキャッシュデータ303にてキャッシュできる時間)に、キャッシュデータ306内の「R−TTL」項目の値を代入して送信する。
【0084】
また、401にて受信した「www.server.net」への正引き問合せがIPv4アドレスを求めるものである場合は、411にて有効なIPv4アドレスをキャッシュデータ306より抽出し、リゾルバモジュール302に対してResponse Aメッセージにて送信する。その際にも、メッセージ内のTTL値に、キャッシュデータ306内の「R−TTL」項目の値を代入して送信する。
【0085】
408にて無効と判断された場合、410にてリゾルバモジュール302に対してResponse(nothing)メッセージを送信する。以上、409〜411の処理が終了した場合は、401の待ち受けループに処理が戻る。
【0086】
次に、図7にて、DNSサーバ109のリゾルバモジュール307の処理フローを説明する。このフローは、DNSサーバ109のROM902あるいはHD907に記憶されたプログラム、あるいはFD908より供給されるプログラムの一部を示す。CPU901は、モジュール307を実現するためのプログラムを、ROM902、あるいはHD907、あるいはFD908から読み出して実行することで、以下の処理を実現する。
【0087】
CPU901は、ネームサーバモジュール304の処理403において、該当するキャッシュデータがない場合、リゾルバモジュール307の処理を行う。すなわち、ネームサーバモジュール304にて受信した正引き問合せに対する該当データがキャッシュデータ306に存在しない場合、リゾルバモジュール307は、501にて、ネームサーバモジュール304より正引き問合せの依頼を受理する。ここで、リゾルバモジュール307がネームサーバモジュール304より委託された正引き問合せ内容は、リゾルバモジュール302からネームサーバモジュール304に問合せられた「www.server.net」のIPv4/IPv6アドレスの正引き問合せ内容と同一のものである。
【0088】
502では、501にて受理した内容の正引き問合せを外部のDNSサーバに向けて実行する。この502にて実行される正引き問合せは、前述したように、RFC1034ならびにRFC1035にて規定されるアルゴリズムに即して行われる。つまり、ルートDNSサーバ、「net」DNSサーバ、「server.net」DNSサーバと順番に配下のドメインを問合せていく。
【0089】
「server.net」ドメインの管理サーバであるDNSサーバ108に対して送信する「www.server.net」に対する正引き問合せで利用される通信プロトコルは、上位のDNSサーバである「net」ドメイン管理サーバによって通知されたDNSサーバ107のアドレスによって決定される。「net」ドメインを管理するDNSサーバではIPv6アドレスでのレコード登録を受け付けていない場合、リゾルバモジュール307とネームサーバモジュール309の通信にはIPv4プロトコルが利用される。
【0090】
そして、503にて外部DNSサーバから、問合せに対する返信を受信する。504では503にて受信した問合せに対する返信の内容をチェックし、場合分けを行う。以下、505〜508がその場合分けである。
【0091】
505は、「www.server.net」のIPv6アドレスを求める正引き問合せが成功した場合であり、IPv6アドレス情報が含まれたResponse AAAAメッセージを受信する。508は、「www.server.net」のIPv4アドレスを求める正引き問合せが成功した場合であり、IPv4アドレス情報が含まれたResponse Aメッセージを受信する。以上の505、508はともに502における正引き問合せに対して成功した場合であり、どちらも510の処理に進む。
【0092】
一方、506は、「www.server.net」にIPv6アドレスまたはIPv4アドレスを求める正引き問合せに対して、該当のアドレス情報を持ったレコードが存在しない場合であり、アドレス情報が含まれていないResponse (nothing)メッセージを受信する。507は、「www.server.net」にIPv6アドレスまたはIPv4アドレスを求める正引き問合せに対して、何らかのエラーが発生した場合(外部DNSサーバにて問合せのレコードタイプが理解できなかった場合や、ターゲットとなる外部DNSサーバが見つからなかった場合など)であり、Errorメッセージを受信する。これら506、507はともに502における正引き問合せに対して失敗した場合であり、どちらも509にてネームサーバモジュール304に返信内容(Response(nothing)メッセージあるいはErrorメッセージ)を伝達し、ネームサーバモジュール304に、委託された正引き問合せの終了を通知し、処理を終了する。そして、CPU901は、ネームサーバモジュール304の処理405を行う。この場合は、406で、リゾルバモジュール302に取得失敗を返信する。
【0093】
正引き問合せに成功した場合は、510にてキャッシュデータ306に記録する内容を作成する。この各項目情報に関しては、図5を参照して、前述した通りである。
【0094】
すなわち、ここでの作成データには、FQDN「www.server.net」701と、そのIPv4/IPv6アドレス703、レコードタイプ(「A」(IPv4)又は「AAAA」(IPv6))702、C−TTL(外部DNSサーバより通知されたキャッシュ可能時間)704のDNSキャッシュデータ標準の項目情報に加えて、チェック判定結果706、R−TTL(対クライアントへの実キャッシュ可能時間)705の項目情報が含まれる。510でのデータ作成において、チェック判定結果項目には「−」(チェック前データ)を代入し、実TTL(R−TTL)705には「0」を代入する。ここで、実TTL(R−TTL)の値は「0」に限らず、「1」あるいは「2」、「3」に設定しても、実用上、大きな支障はない。
【0095】
511において、510にて作成したデータをキャッシュデータ306に記録し、ネームサーバモジュール304に、委託された正引き問合せの終了を通知する。その後、CPU901は、ネームサーバモジュール304の処理405を行う。また、512ではキャッシュデータ306に記録したIPv4/IPv6アドレスが有効かどうかのチェック(接続試験)を行うために、通信プロトコルチェックモジュール308に、511にて記録したデータを送信し、アドレスのチェック処理を依頼し、全処理を終了する。
【0096】
図8で、DNSサーバ109の通信プロトコルチェックモジュール308における処理フローを説明する。このフローは、DNSサーバ109のROM902あるいはHD907に記憶されたプログラム、あるいはFD908より供給されるプログラムの一部を示す。CPU901は、モジュール308を実現するためのプログラムを、ROM902、あるいはHD907、あるいはFD908から読み出して実行することで、以下の処理を実現する。
【0097】
この通信プロトコルチェック処理は、二つのタイミングで起動される。まず一つはリゾルバモジュール307からIPv4/IPv6アドレスを通知された場合である。これは、新規にキャッシュデータ306にアドレス情報が記録された際に発生する事例であり、そのIPv4/IPv6アドレスの有効性をチェックする必要がある。
【0098】
もう一つの起動のタイミングは、ある一定時間(例えば、5分)が経過した場合である。これは、キャッシュデータ306に記録されているIPv4/IPv6アドレスの有効性を定期的にチェックし、刻々と変化するネットワーク情報に適した評価を行うためである。
【0099】
601では以上の二つのタイミングによる起動(リゾルバモジュール307からのチェック要請、または、ある一定時間経過による定期チェック)を判定する。リゾルバモジュール307からIPv4/IPv6アドレスを受信した場合、すなわち、CPU901が、リゾルバモジュール307の処理において、外部サーバから有効なIPv4/IPv6アドレスが得て、リゾルバモジュール307の処理を終了した場合、CPU901は、602において該当アドレスの有効性チェック処理を行う。
【0100】
本実施形態でのアドレス(例えば、Webサーバ107のアドレス)の有効性チェックは、IPv4/IPv6アドレスがDNSサーバ109からWebサーバ107までのそれぞれの通信プロトコルでの接続性を確認する(接続試験を行う)ことで、アドレスの有効性を判定している。そこで、602にて、疎通チェックを対象となるIPv4/IPv6アドレスに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、そのメッセージに対する応答を判断し、その判断に基づき、アドレスの有効性を確認する。このチェック処理に関しては611〜616にて詳しく説明する。
【0101】
602でのアドレス有効性チェック処理を行ったデータは、603にてキャッシュデータ306に既に記録されているエントリデータの「Check」欄706、「R−TTL」欄705を上書き修正し、601へ戻る。
【0102】
一方、ある一定時間(例えば、5分)を経過した場合の処理は、604に進む。604ではキャッシュデータ306に記録されているエントリデータを取得する。そして、605において取得したエントリからIPv4/IPv6アドレスを抽出し、606においてアドレス有効性チェック処理(接続試験)を行う。606のチェック処理も602と同様の処理を行う。そして、608にて、603と同様に、606のチェック処理の結果を、キャッシュデータ306に反映させる。この604、605、606の処理は、キャッシュデータ306に格納されているエントリのそれぞれについて、すなわち、キャッシュデータ306に格納されているアドレスのそれぞれについて、接続試験を行い、その結果を、チェック欄706に格納する。
【0103】
引き続き、図9で、602、606で行われるアドレス有効性チェック(接続試験)の処理フローを説明する。
【0104】
本実施形態でのアドレス有効性チェックは、IPv4/IPv6アドレスがDNSサーバ109からWebサーバ107までのそれぞれの通信プロトコルでの接続性を確認する(接続試験を行う)ことで、アドレスの有効性を判定している。
【0105】
すなわち、疎通チェックを対象となるIPv4/IPv6アドレスに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、そのメッセージに対する応答を判断し、その判断に基づき、アドレスの有効性を確認する。
【0106】
本実施形態では、アドレスの有効性をチェックする(接続性を試験する)ためのメッセージとして、ICMP echoメッセージを用いる。すなわち、611にてICMP echoメッセージによる疎通チェックを対象となるIPv4/IPv6アドレスに対して、それぞれの通信プロトコルを利用して送信する。IPv6アドレスのチェックには、IPv6の通信プロトコルを用いて、ICMP echoメッセージを送信し、IPv4アドレスのチェックには、IPv4の通信プロトコルを用いて、ICMP echoメッセージを送信する。
【0107】
612にて、602あるいは606で発行したICMP echoに対する返信があるかを判定し、所定時間内に(例えば、1秒以内)、返信があった場合にはそのアドレスは有効であると判断し、613にて、キャッシュデータ306に記録するエントリデータ内の項目であるチェック判定結果の欄に「OK」を代入する。
【0108】
一方、所定時間内に(例えば、1秒)ICMP echoに対する返信がない場合は、そのアドレスは無効と判断し、615にて、キャッシュデータ306に記録するエントリデータ内の項目であるチェック判定結果の欄に「NG」を代入する。続いて、616にて、同じくエントリデータ内のR−TTL(対クライアントへの実キャッシュ可能時間)705の値を「0」し、チェック処理を終了する。なお、所定時間内に(例えば、1秒以内)、ICMP echoメッセージが宛先に届かないことを示すメッセージが、インターネット104あるいは105内のサーバから、送られてきた場合も、チェック判定結果の欄に「NG」を代入し、R−TTLの値を「0」にする。ここで、チェック判定結果の欄が「NG」ならば、410で、クライアントには、Response (nothing)メッセージを返信するので、R−TTLの値は「0」に設定しなくても、問題ない。
【0109】
613、614、615、616で、作成したエントリデータは、603、608において、キャッシュデータ306に格納される。なお、606では、キャッシュデータ306に記録されているIPv4/IPv6アドレスのそれぞれに対して、それぞれの通信プロトコルを利用して、所定のメッセージを送信し、612で返信があれば、613の処理を行い、所定時間内に、返信がない場合、615、616の処理を行う。
【0110】
なお、このアドレスの有効性をチェックするために送信したメッセージの返信を待つ時間は、1秒に限らず、例えば、30秒に設定してもよい。
【0111】
他の形態では、602でのアドレス有効性チェックと606でのアドレス有効性チェックで、返信を待つ時間として、異なる時間を用いる。例えば、602でのアドレス有効性チェックでは、30秒、606のアドレス有効性チェックでは、1秒、メッセージの返信を待って、アドレス有効性を判断する。
【0112】
なお、DNSキャッシュデータは、TTL値を越える時間、キャッシュすることが許されない仕組みとなっている。そのため、図には示さないが、例えば、1秒ごとに、キャッシュ時間C−TTL(外部DNSサーバより通知されたキャッシュ可能時間)704の値を1つ減らして、C−TTL値704の判定を行い、既に期限切れのエントリは、キャッシュデータ306から削除する。なお、R−TTL(対クライアントへの実キャッシュ可能時間)705に関しては、値が「0」でなければ、1つ減らす。
【0113】
図10は本実施形態の通信の流れにおいて、Webクライアント106からWebサーバ107に対し、IPv6通信プロトコルでの到達が不可能な状況での通信パケットの内容とそのフローである。以下のフローにおいて、DNSサーバ109の動作は、DNSサーバ109のROM902あるいはHD907に記憶されたソフトウェア、あるいはFD908より供給されるソフトウェアであるモジュール304、307、308により実現される。図6、図7、図8、図9は、連携して動作することにより、第1の装置のアドレスを用いて前記第1の装置との接続試験を行う試験ステップ(606)と、前記試験ステップでの接続試験が失敗した場合には、第2の装置からの前記第1の装置のアドレスの問合せに対して、前記第1の装置のアドレスがないことを示すメッセージを返信する返信ステップ(410)とを有するアドレスの問合せに対する返信プログラムであり、また、第1の装置のアドレスの問合せを第2の装置から受けると(401)、前記第1の装置のアドレスを第3の装置に問合せ(502)、前記第3の装置から得られた前記第1の装置のアドレスを前記第2の装置に通知し(409、411)、前記第1の装置のアドレスと共に前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知するアドレス通知プログラムである。
【0114】
Webクライアント106は、最寄りのDNSサーバ109に対して正引き問合せ(「www.server.net」に対する「AAAA」の問合せ)AAAA Query801を送信する。
【0115】
DNSサーバ109は、この正引き問合せ801を受け(図6の401)、自分の所持するキャッシュデータを検索し(402)、該当するデータがないことから(図6の403でNo)、対象となるFQDNの管理を行っているDNSサーバ108に正引き問合せ(「www.server.net」に対する「AAAA」の問合せ)AAAA Query 802を行う(図6の404、図7の501、502)。すなわち、DNSサーバ109は、サーバ107(第1の装置)のアドレスの問合せをクライアント106(第2の装置)から受けると、サーバ107のアドレスをDNSサーバ(第3の装置)に問合せる。
【0116】
問合せ802に対し、DNSサーバ108は、問合せのFQDNに対するIPv6アドレスを含む問合せへの返信(「www.server.net」の「AAAA」は「2001:340:0:1::1」、「TTL=10000」)Response AAAA 803を、DNSサーバ109に送信する。
【0117】
DNSサーバ109は、この返信803を受信し(図7の503、504、505、510、511)、迅速にWebクライアント106に対して問合せの返信(「www.server.net」の「AAAA」は「2001:340:0:1::1」、「TTL=0」)Response AAAA 804を送信する(図6の405のYes、407、408、409)。すなわち、DNSサーバ109は、DNSサーバ108から得られたサーバ107のアドレスをクライアント106に通知する。DNSサーバ106は、DNSサーバ108から得られたサーバ107のアドレスの有効期限C−TTL704より短い有効期限R−TTL705(その値は、例えば、「0」)を、サーバ107のアドレスの有効期限として、クライアント106に通知する。
【0118】
返信804を受信したWebクライアントは「www.server.net」のIPv6アドレス「2001:340:0:1::1」を取得したので、目的のサーバ107にIPv6通信プロトコルを利用して接続805を試みるが、途中でネットワークが切断状態であるために接続はできない。
【0119】
一方、DNSサーバ109でも、IPv6アドレス通知Response AAAA 804とほぼ同時刻に、IPv6アドレスの有効性チェックのために、ICMP echoメッセージ806を対象アドレス「2001:340:0:1::1」に送信する(図7の512、図8の601、602)。メッセージ806の通信に関しても、Webサーバ107には到達しないので(図9の612はNo)、アドレス有効性チェック807はNG(接続試験失敗)となる(615)。このIPv6アドレスの接続性試験は、IPv6の通信プロトコルを用いて、行う。
【0120】
Webクライアント106は、接続805から通信確立失敗までタイムアウト待ちを行い、そのタイムアウトの後、IPv4アドレスを取得すべく最寄りのDNSサーバ109に対して正引き問合せ(「www.server.net」に対する「A」の問合せ)A Query 808を行う。
【0121】
DNSサーバ109は、この正引き問合せ808を受け(図6の401)、自分の所持するキャッシュデータを検索し(402)、該当するデータがないことから(図6の403のNo)、対象となるFQDNの管理を行っているDNSサーバ108に正引き問合せ(「www.server.net」に対する「A」の問合せ)A Query 809を行う(図6の404、図7の501、502)。
【0122】
問合せ809に対し、DNSサーバ108は、問合せのFQDNに対するIPv4アドレスを含む問合せへの返信(「www.server.net」の「A」は「172.16.0.1」、「TTL=10000」)Response A 810を、DNSサーバ109に送信する。
【0123】
DNSサーバ109は、この返信810を受信し(図7の503、504、508、510、511)、迅速にWebクライアント106に対して問合せの返信(「www.server.net」の「A」は「172.16.0.1」、「TTL=0」)Response A 811を送信する(図6の405のYes、407、408、411)。
返信811を受信したWebクライアントは「www.server.net」のIPv4アドレス「172.16.0.1」を取得したので、目的のサーバ107にIPv4通信プロトコルを利用して接続812を試みる。この接続812は成功するので、Webクライアント106には、Webサーバ107のデータが受信される。
【0124】
一方、DNSサーバ109でも、IPv4アドレス通知Response A811とほぼ同時刻に、IPv4アドレスの有効性チェックのために、ICMP echoメッセージ813を対象アドレス「172.16.0.1」に送信する(図7の512、図8の601、602)。メッセージ813に対する返信が、Webサーバ107よりICMP Response 814として送信されるので(図9の612は、Yes)、アドレス有効性チェック706はOK(接続試験成功)となる(613)。なお、このIPv4アドレスの接続性試験は、IPv4の通信プロトコルを用いて、行う。
【0125】
その後、新たにWebサーバ107への接続要求が発生した際(例えば、Web表示上のリンクを選択し、同じWebサーバ内の別のデータを取得するような場合)、Webクライアント106はもう一度最寄りのDNSサーバ109にIPv6アドレスの正引き問合せ(「www.server.net」に対する「AAAA」の問合せ)AAAA Query 815を行う。
【0126】
DNSサーバ109は、この正引き問合せ815を受け(図6の401)、自分の所持するキャッシュデータを検索し(402)、図10の807でアドレス有効性チェックの行われたキャッシュデータから、IPv6アドレスのチェック結果が「NG」であることを知るので(図6の403のYes、407、408のNo)、Webクライアント106への返信にはアドレス無しメッセージ(「www.server.net」の「AAAA」はありません)Response (nothing) 816を送信する(図6の410)。すなわち、DNSサーバ109は、サーバ107(第1の装置)のアドレスを用いてサーバ107との接続試験(806、807)を行い、その接続試験が失敗した場合には、サーバ107のアドレスがないことを示すメッセージを返信する。
【0127】
この返信816を受けたWebクライアントは、続いてIPv4アドレスの正引き問合せA Query 817を送信する。DNSサーバ109は、同様に、この正引き問合せを受け(図6の401)、自分の所持するキャッシュデータを検索し(402)、アドレス有効性チェックの行われたキャッシュデータから、IPv4アドレスを検索し、チェック結果の「OK」を確認してから(図6の403のYes、407、408)、問合せ返信(「www.server.net」の「A」は「172.16.0.1」、「TTL=10000」)Response A 818を送信する(411)。
【0128】
返信818によりWebサーバ107のIPv4アドレス取得に成功したWebクライアント109は、IPv4通信プロトコルを利用した接続819を行い、Webサーバ107からデータを取得する。
【0132】
上記実施形態において、Webクライアント106とWebサーバ107は、Webアプリケーションに限定されるものではなく、どのようなネットワークアプリケーションであってもよい。
【0133】
また、上記実施形態において、ユーザネットワーク101に接続したDNSサーバ109には、ユーザネットワーク101に属するホスト端末群のドメインを管理するマスタゾーンファイル305を、必ずしも、保持する必要はなく、単なるDNSキャッシュサーバとしての機能のみを提供するものであってよい。
【0134】
また、上記実施形態において、ドメイン管理ネットワーク102とサーバネットワーク103は必ずしも独立したネットワークである必要はなく、同一のネットワーク上にDNSサーバ108とWebサーバ107が存在してもよい。
【0135】
また、上記実施形態において、DNSサーバ109は必ずしもユーザネットワーク101に属している必要はなく、ユーザネットワークに極力近ければよく、例えば、クライアント106にインターネットサービスを提供しているISP内のネットワークに存在してもよい。
【0136】
また、上記実施形態において、各ホストに割当てたドメイン名、FQDN、IPv4ネットワークアドレス、IPv4アドレス、IPv6ネットワークアドレス、IPv6アドレスは一例に過ぎず、その他の任意のドメイン名、FQDN、IPv4ネットワークアドレス、IPv4アドレス、IPv6ネットワークアドレス、IPv6アドレスであってもよい。
【0137】
【発明の効果】
本発明によれば、第1の装置のアドレスの問合せを第2の装置から受けると、前記第1の装置のアドレスを第3の装置に問合せ、前記第3の装置から得られた前記第1の装置のアドレスを前記第2の装置に通知する場合に、前記第1の装置のアドレスと共に前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することにより、前記第2の装置が、前記第1の装置のアドレスが取得できても、接続できない事態を減らすことが可能となる。
【0138】
更に、前記第1の装置のアドレスを用いて前記第1の装置との接続試験を行う場合に、前記試験ステップの接続試験の結果が得られる前は、前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することにより、前記第1の装置のアドレスを用いて前記第1の装置と接続できるか確認できる前に、前記第2の装置が、前記第1の装置のアドレスが取得できても、接続できない事態を防ぐことが可能となる。
【0139】
更に、前記試験ステップでは、前記第1の装置のアドレスに対応するプロトコルで、前記第1の装置との接続試験を行うことにより、プロトコル毎に、前記第1の装置に接続できない事態を防ぐことが可能となる。
【図面の簡単な説明】
【図1】ネットワークの構成図である。
【図2】各ネットワークの属するドメイン名と、各ホストに割当てたFQDNの一例の図である。
【図3】本実施形態での機能を実現するソフトウェアプログラムを動作させる構成の一例の図である。
【図4】WebクライアントとWebサーバの通信確立までの処理概要を示したモジュール図である。
【図5】DNSサーバのキャッシュデータにおけるエントリデータの内容の図である。
【図6】DNSサーバのネームサーバモジュールにて処理されるフローの図である。
【図7】DNSサーバのリゾルバモジュールにおける処理フローの図である。
【図8】DNSサーバの通信プロトコルチェックモジュールにおける処理フローの図である。
【図9】アドレス有効性チェック(接続試験)の処理フローの図である。
【図10】IPv6通信プロトコルでの到達が不可能な状況での通信パケットの内容とそのフローの図である。
【符号の説明】
106 Webクライアント
107 Webサーバ
108 DNSサーバ
109 DNSサーバ
Claims (9)
- 第1の装置のアドレスの問合せを第2の装置から受けると、前記第1の装置のアドレスを第3の装置に問合せ、前記第3の装置から得られた前記第1の装置のアドレスを前記第2の装置に通知するアドレス通知方法において、
前記第1の装置のアドレスと共に前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とするアドレス通知方法。 - 前記第1の装置のアドレスを用いて前記第1の装置との接続試験を行う試験ステップを更に有し、
前記試験ステップの接続試験の結果が得られる前は、前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とする請求項1のアドレス通知方法。 - 前記試験ステップでは、前記第1の装置のアドレスに対応するプロトコルで、前記第1の装置との接続試験を行うことを特徴とする請求項2のアドレス通知方法。
- 第1の装置のアドレスの問合せを第2の装置から受けると、前記第1の装置のアドレスを第3の装置に問合せ、前記第3の装置から得られた前記第1の装置のアドレスを前記第2の装置に通知するアドレス通知プログラムにおいて、
前記第1の装置のアドレスと共に前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とするアドレス通知プログラム。 - 前記第1の装置のアドレスを用いて前記第1の装置との接続試験を行う試験ステップを更に有し、
前記試験ステップの接続試験の結果が得られる前は、前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とする請求項4のアドレス通知プログラム。 - 前記試験ステップでは、前記第1の装置のアドレスに対応するプロトコルで、前記第1の装置との接続試験を行うことを特徴とする請求項5のアドレス通知プログラム。
- ネットワークを接続する接続手段と、
前記接続手段に接続されたネットワークを介して、第2の装置から第1の装置のアドレスの問合せを受けると、前記第1の装置のアドレスを前記第2の装置に通知する通知手段とを有し、
前記通知手段は、前記第1の装置のアドレスを第3の装置に問合せ、前記第1の装置のアドレスと共に前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とするアドレス通知装置。 - 前記通知手段は、前記第1の装置のアドレスを用いて前記第1の装置との接続試験を行い、
前記接続試験の結果が得られる前は、前記第3の装置から得られた前記第1の装置のアドレスの有効期限より短い有効期限を、前記第1の装置のアドレスの有効期限として、前記第2の装置に通知することを特徴とする請求項7のアドレス通知装置。 - 前記通知手段は、前記第1の装置のアドレスに対応するプロトコルで、前記第1の装置との接続試験を行うことを特徴とする請求項8のアドレス通知装置。
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 JP2004228760A (ja) | 2004-08-12 |
JP3703457B2 true 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) |
Families Citing this family (84)
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 |
US8676922B1 (en) | 2004-06-30 | 2014-03-18 | Google Inc. | Automatic proxy setting modification |
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 |
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 |
JP4512192B2 (ja) * | 2005-02-09 | 2010-07-28 | 株式会社日立製作所 | 輻輳制御装置、および、ネットワークの輻輳制御方法 |
US7436783B2 (en) * | 2005-04-04 | 2008-10-14 | Apple Inc. | Method and apparatus for detecting a router that improperly responds to ARP requests |
US8312074B2 (en) * | 2005-05-26 | 2012-11-13 | Bytemobile, Inc. | Method for multipart encoding |
JP4241681B2 (ja) * | 2005-07-05 | 2009-03-18 | ブラザー工業株式会社 | 情報処理装置、およびプログラム |
CN100454849C (zh) * | 2005-08-05 | 2009-01-21 | 华为技术有限公司 | 下一代网络中的故障检测方法 |
US20070043667A1 (en) * | 2005-09-08 | 2007-02-22 | Bahman Qawami | Method for secure storage and delivery of media content |
KR100739807B1 (ko) * | 2006-02-06 | 2007-07-13 | 삼성전자주식회사 | Dhcp를 이용한 핸드오버 정보 검색 및 획득 방법 및장치 |
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 |
JP5057077B2 (ja) * | 2008-03-05 | 2012-10-24 | Necインフロンティア株式会社 | ルータ装置、通信システム及びそれらに用いる不正経路確認方法 |
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 |
US8087067B2 (en) | 2008-10-21 | 2011-12-27 | Lookout, Inc. | Secure mobile platform system |
US9235704B2 (en) | 2008-10-21 | 2016-01-12 | Lookout, Inc. | System and method for a scanning API |
US8984628B2 (en) | 2008-10-21 | 2015-03-17 | Lookout, Inc. | System and method for adverse mobile application identification |
US9367680B2 (en) | 2008-10-21 | 2016-06-14 | Lookout, Inc. | System and method for mobile communication device application advisement |
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 |
US8347386B2 (en) | 2008-10-21 | 2013-01-01 | Lookout, Inc. | System and method for server-coupled malware prevention |
US8533844B2 (en) | 2008-10-21 | 2013-09-10 | Lookout, Inc. | System and method for security data collection and analysis |
US9781148B2 (en) | 2008-10-21 | 2017-10-03 | Lookout, Inc. | Methods and systems for sharing risk responses between collections of mobile communications devices |
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 |
US8467768B2 (en) | 2009-02-17 | 2013-06-18 | Lookout, Inc. | System and method for remotely securing or recovering a mobile device |
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 |
US8538815B2 (en) | 2009-02-17 | 2013-09-17 | Lookout, Inc. | System and method for mobile device replacement |
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 |
US9178749B2 (en) * | 2009-08-14 | 2015-11-03 | Akamai Technologies, Inc. | Method and apparatus for correlating nameserver IPv6 and IPv4 addresses |
JP5531517B2 (ja) * | 2009-09-04 | 2014-06-25 | ヤマハ株式会社 | 通信装置および通信方法 |
US9098335B2 (en) | 2009-12-23 | 2015-08-04 | Citrix Systems, Inc. | Systems and methods for managing spillover limits in a multi-core system |
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 |
CN102771083B (zh) * | 2009-12-23 | 2015-05-13 | 思杰***有限公司 | 用于全局服务器负载平衡的IPv6和IPv4 DNS的混合模式的***和方法 |
US9378245B2 (en) * | 2010-10-18 | 2016-06-28 | Nec Corporation | Name database server, name resolution system, entry search method and entry search program |
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 |
EP2605145A4 (en) * | 2010-11-17 | 2017-08-16 | Hitachi, Ltd. | Method for finding communication devices connected to communication network, and management device |
JP5231513B2 (ja) * | 2010-11-19 | 2013-07-10 | Necアクセステクニカ株式会社 | リソースレコード制御システム、リソースレコード制御方法、アプリケーション判別方法およびプログラム |
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 |
JP5777938B2 (ja) * | 2011-05-26 | 2015-09-09 | 日本電信電話株式会社 | フォールバック検知装置、フォールバック検知方法及びフォールバック検知プログラム |
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 |
JP5644710B2 (ja) | 2011-07-26 | 2014-12-24 | 株式会社Pfu | ノード検出装置、ノード検出方法、及びプログラム |
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 |
US8839087B1 (en) | 2012-01-26 | 2014-09-16 | Amazon Technologies, Inc. | Remote browsing and searching |
US9336321B1 (en) | 2012-01-26 | 2016-05-10 | 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 |
KR101520811B1 (ko) * | 2014-07-11 | 2015-05-21 | 주식회사 엘지유플러스 | Ims 망에서 호 세션을 제어하는 방법 및 이를 수행하는 장치 |
AU2016258533B2 (en) | 2015-05-01 | 2017-11-30 | 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 |
WO2017147250A1 (en) * | 2016-02-23 | 2017-08-31 | 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 |
US12034618B2 (en) * | 2022-09-08 | 2024-07-09 | Roku, Inc. | IPV6 connectivity test and DNS improvements |
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 |
AU2001232699A1 (en) | 2000-11-09 | 2002-05-21 | 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
Also Published As
Publication number | Publication date |
---|---|
JP2004228760A (ja) | 2004-08-12 |
US7415536B2 (en) | 2008-08-19 |
CN1520123A (zh) | 2004-08-11 |
CN100484125C (zh) | 2009-04-29 |
US20040143579A1 (en) | 2004-07-22 |
EP1441487A3 (en) | 2005-12-14 |
EP1441487A2 (en) | 2004-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3703457B2 (ja) | アドレス通知方法、プログラム、及び、装置 | |
JP4965559B2 (ja) | リソースアドレスリクエスト管理方法及び関連するゲートウェイ装置 | |
JP4668775B2 (ja) | Dnsサーバ装置 | |
JP4684534B2 (ja) | ピアツーピア環境においてキャッシュされた資源間における資源の相同性 | |
JP4234482B2 (ja) | 動的dns登録方法、ドメイン名解決方法、代理サーバ、及びアドレス変換装置 | |
US9584360B2 (en) | Global server load balancing support for private VIP addresses | |
JP4159337B2 (ja) | 仮想ネットワーク名の解決方法 | |
US7831697B2 (en) | Mapping notification system for relating static identifier to dynamic address | |
JP4075318B2 (ja) | プロトコル変換方法,及びアドレス変換サーバ | |
US7573903B2 (en) | IPv6/IPv4 translator | |
US8954603B2 (en) | Communication device and communication method of the same | |
US8423670B2 (en) | Accessing distributed services in a network | |
TW200924462A (en) | System and method for connection of hosts behind NATs | |
CN106161667A (zh) | 一种域名解析方法及装置 | |
JP2007527068A (ja) | 少なくとも2つの計算装置間の接続を設定する際のアドレス及びポート番号アブストラクション | |
JP3601526B2 (ja) | 代理登録装置およびネットワークシステムおよびプログラム | |
JP2004350133A (ja) | 接続制御方法、接続制御プログラム、及び、接続装置 | |
US9497067B2 (en) | Address determination apparatus, communication system, address determination method, and program | |
JP2014135592A (ja) | 情報処理装置、情報処理方法及び情報処理システム | |
US7610403B2 (en) | Device retrieving a name of a communications node in a communications network | |
JPH1117726A (ja) | Dns機能を内蔵したipネットワークの結合制御装置 | |
JP2002217941A (ja) | ネットワークアドレス再割り当て方法及びルータ | |
JP4905376B2 (ja) | 複数のネットワークプロトコルに対応した通信システムおよび通信方法 | |
JP2004007151A (ja) | ルータとそれに接続されるddnsクライアント端末、及びddnsシステム | |
JP3708085B2 (ja) | Dns問い合わせ装置およびdns問い合わせ方法 |
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 |