JP2006287416A - アドレス情報取得装置、アドレス情報取得方法およびアドレス情報取得プログラム - Google Patents

Abstract

【課題】ネットワーク上の各装置のアドレス情報を管理する装置への再度の問い合わせで対応するアドレス情報が取得できない場合に、より高い確率で目的の相手先へのアクセスを実現できるアドレス情報取得装置、アドレス情報取得方法およびアドレス情報取得プログラムを得ること。
【解決手段】ＤＮＳキャッシュメモリ２２１には過去の名前解決の結果が格納されており、ＴＴＬ更新部２２５は各エントリのＴＴＬを減じていくが、値「０」になったときの削除は行わない。ＤＮＳキャッシュ制御部は、名前解決の対象となる装置の名前を受け取ると、ＤＮＳキャッシュメモリ２２１で該当するエントリを検索し、そのＴＴＬが値「０」よりも大きい場合にはそのＩＰアドレスを名前解決の結果とする。ＴＴＬが値「０」以下の場合にはＤＮＳサーバへ問い合わせるが、この問い合わせが失敗した場合にはエントリのＩＰアドレスを名前解決の結果とする。
【選択図】図２

Description

本発明は、ネームサーバのようにネットワークに配置された各装置のアドレス情報を管理する装置に対して所望の装置のアドレス情報の問い合わせを行うアドレス情報取得装置、アドレス情報取得方法およびアドレス情報取得プログラムに係わり、特に問い合わせの結果得られたアドレス情報を該当する装置に対応付けて自装置内に記憶しておきこれを使用するようにしたアドレス情報取得装置、アドレス情報取得方法およびアドレス情報取得プログラムに関する。

インターネットに代表されるＩＰ（Internet Protocol）網では、データを送信する場合にはその相手先の装置に割り当てられたＩＰアドレスを宛先情報として付加するようになっている。ＩＰアドレスはＩＰｖ４（version 4）で３２ビットのデータ列により構成され、８ビットごとにピリオドで区切った上でそれぞれを１０進数で表記する等の表記上の工夫も行われている。また、ＩＰｖ６（version 6）では、セキュリティ関係を改善する等の目的により１２８ビットのデータ列に拡張されている。

このようなＩＰアドレスは数字の羅列であり、通信端末を扱うユーザにとって把握や記憶が難しいという問題がある。そこで、ユーザに分かり易い文字列による識別子を、ＩＰアドレスと併せて各装置に割り当てることが行われている。このような識別子はドメイン名やＤＮＳ（Domain Name System）名、あるいは必要なドメイン名やホスト名を一切省略しない場合にはＦＱＤＮ（Fully Qualified Domain Name）と呼ばれ（以下、これらを名前と総称する。）、属する国名や組織名あるいは提供するサービス内容等に関連付けられて設定されることが多い。この名前は、ＩＰアドレスと同様、インターネットのアドレス資源の管理を行う組織であるＩＣＡＮＮ（Internet Corporation for Assigned Names and Numbers）によって各装置にユニークとなるように割り当てが行われている。

各通信端末では、パケットの送信先の名前が指定あるいは入力されると、これを対応するＩＰアドレスに変換して該当するパケットの宛先として記述するようになっている。これにより、ＩＰ網を使用するユーザはＩＰアドレスの代わりにより親しみ易い識別子である名前によって通信を取り扱うことができる。

しかしながら、ＩＰアドレスはＤＨＣＰ（Dynamic Host Configuration Protocol）による自動割り当てのように、装置に固定となってない場合がある。また、ＩＰアドレスは固定であっても各種の都合により名前が変更される場合もある。このように名前とＩＰアドレスとの組み合わせに変更が発生すると、これを知らない通信端末との間の通信に支障をきたす恐れがある。

そこで、各装置に割り当てられたＩＰアドレスと名前との対応付けを管理するためにネームサーバを設置することが従来より提案されている（たとえば特許文献１参照。）。この提案では、ネームサーバは自己の管理下にある各装置のＩＰアドレスと名前との対応表を持っており、その内容は最新の情報で更新されるようになっている。各通信端末は、通信の新たな相手先が名前で指定されると、この名前に対応するＩＰアドレスをこのネームサーバに問い合わせる。ＩＰアドレスが返信されると、通信端末ではそのＩＰアドレスを名前と対応付けて記憶しておき、以降の名前で指示された通信を行う際にはこの記憶されたＩＰアドレスを使用するようになっている。このように名前に対応するＩＰアドレスを取得しこれらを対応付けることを名前解決という。また、この情報の記憶には予め継続して保持しておくべき時間としての生存時間が設定されており、この生存時間が経過した情報は削除される。削除された名前について、通信端末は必要に応じて再び問い合わせを行って最新の情報を取得するようになっている。

これにより、各通信端末では通信を行う可能性のある相手先の全てのＩＰアドレスと名前の対応付けを記憶するといった必要がなくなるとともに、ＩＰアドレスと名前との対応付けに変更があった場合でも前記した生存時間の範囲内でこれに追従できるようになっている。
特開２００４−３２６６６７号公報（第００１９、第００２０段落、図１）

ところで、過去に通信を行ったものの対応する生存時間が経過してしまった相手先と通信を行おうとするとき、この従来の提案では前記したように再度ネームサーバに問い合わせを行うようになっている。ところが、ネームサーバのダウンやネットワーク障害等の原因により、再度の問い合わせ時にＩＰアドレスを取得できない場合がある。すると、該当する目的の相手先にアクセスしようにも、ＩＰアドレスが不明なためにアクセスができないという問題が発生する。

そこで本発明の目的は、ネットワーク上の各装置のアドレス情報を管理する装置への問い合わせで対応するアドレス情報が取得できない場合であっても相手先への通信の可能性を高めるようにしたアドレス情報取得装置、アドレス情報取得方法およびアドレス情報取得プログラムを提供することにある。

本発明では、（イ）通信先の装置を指定する装置指定手段と、（ロ）通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段と、（ハ）装置指定手段によって通信先の装置が指定されたとき、この装置別アドレス情報登録手段を用いてそのアドレス情報を検索するか否かを判別する検索適否判別手段と、（ニ）この検索適否判別手段が検索しないと判別したとき装置指定手段が指定した装置のアドレス情報の取得を外部に対して要求するアドレス情報取得要求手段と、（ホ）このアドレス情報取得要求手段の要求に対応するアドレス情報の取得が失敗したとき、あるいは検索適否判別手段が検索すると判別したとき、装置のアドレス情報を取得するため装置別アドレス情報登録手段を検索するアドレス情報検索手段とをアドレス情報取得装置に具備させる。

すなわち本発明では、アドレス情報取得装置は通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段を備えている。そして、たとえばネットワークに配置されたアドレス情報が不明の装置にパケットを送信するといった目的でいずれかの装置が指定されたとき、この装置別アドレス情報登録手段を用いてそのアドレス情報を検索するか否かの判別を行う。そして、検索しない場合にはその装置のアドレス情報の取得を外部に対して要求するが、対応するアドレス情報の取得が失敗したときには装置別アドレス情報登録手段で検索するようになっている。これにより、外部に対するアドレス情報の取得が失敗したときに過去の判別結果を使用することができ、この間に該当する装置のアドレス情報が変更されていないような場合には、これが結果として適切なアドレス情報として取得されることになる。すなわち、目的の相手先への通信の可能性を高めることが可能となる。

また、本発明では、（イ）通信先の装置を指定する装置指定ステップと、（ロ）通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段に、この装置指定ステップで指定された装置についての登録がされているか否かを判別する登録有無判別ステップと、（ハ）この登録有無判別ステップで登録されていると判別すると、装置別アドレス情報登録手段の該当するアドレス情報を取得するか否かを判別するアドレス情報取得適否判別ステップと、（ニ）このアドレス情報取得適否判別ステップで取得しないと判別すると、装置指定手段が指定した装置のアドレス情報の取得を外部に対して要求するアドレス情報取得要求ステップと、（ホ）このアドレス情報取得要求ステップでの要求に対応するアドレス情報取得が失敗すると、あるいはアドレス情報取得適否判別ステップで取得すると判別すると、装置別アドレス情報登録手段の該当するアドレス情報を取得するアドレス情報取得ステップとをアドレス情報取得方法に具備させる。

すなわち本発明では、たとえばネットワークに配置されたアドレス情報が不明の装置にパケットを送信するといった目的でいずれかの装置が指定されると、通信先の各装置とこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段に、その装置についての登録がされているか否かを判別する。登録されている場合には、次に装置別アドレス情報登録手段の該当するアドレス情報を取得するか否かを判別する。そして、取得しない場合にはその装置のアドレス情報の取得を外部に対して要求するが、対応するアドレス情報の取得が失敗したときには装置別アドレス情報登録手段から取得するようになっている。これにより、外部に対するアドレス情報の取得が失敗したときに過去の判別結果を使用することができ、この間に該当する装置のアドレス情報が変更されていないような場合には、これが結果として適切なアドレス情報として取得されることになる。すなわち、目的の相手先への通信の可能性を高めることが可能となる。

更に、本発明では、通信装置を構成するコンピュータに、（イ）通信先の装置を指定する装置指定処理と、（ロ）通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段に、この装置指定処理で指定された装置についての登録がされているか否かを判別する登録有無判別処理と、（ハ）この登録有無判別処理で登録されていると判別すると、装置別アドレス情報登録手段の該当するアドレス情報を取得するか否かを判別するアドレス情報取得適否判別処理と、（ニ）このアドレス情報取得適否判別処理で取得しないと判別すると、装置指定手段が指定した装置のアドレス情報の取得を外部に対して要求するアドレス情報取得要求処理と、（ホ）このアドレス情報取得要求処理での要求に対応するアドレス情報取得が失敗すると、あるいはアドレス情報取得適否判別処理で取得すると判別すると、装置別アドレス情報登録手段の該当するアドレス情報を取得するアドレス情報取得処理とをアドレス情報取得プログラムにより実行させる。

すなわち本発明では、アドレス情報取得プログラムは、たとえばネットワークに配置されたアドレス情報が不明の装置にパケットを送信するといった目的でいずれかの装置が指定する。そして、通信先の各装置とこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段に、その指定された装置についての登録がされているか否かを判別する。登録されている場合には、次に装置別アドレス情報登録手段の該当するアドレス情報を取得するか否かを判別する。そして、取得しない場合にはその装置のアドレス情報の取得を外部に対して要求するが、対応するアドレス情報の取得が失敗したときには装置別アドレス情報登録手段から取得するようになっている。これにより、外部に対するアドレス情報の取得が失敗したときに過去の判別結果を使用することができ、この間に該当する装置のアドレス情報が変更されていないような場合には、これが結果として適切なアドレス情報として取得されることになる。すなわち、目的の相手先への通信の可能性を高めることが可能となる。また、このようなプログラムをインストールすることで、汎用あるいは既存のルータやパーソナルコンピュータといった通信機能を有する各種装置でもこのような効果を簡単に実現することができる。

以上説明したように本発明によれば、通信先の装置のアドレス情報を取得する際、外部への問い合わせが失敗したときには過去の同じ装置についての判別結果を利用する。すなわち、該当する装置のアドレス情報が変更されていないような場合にはこれが結果的に適切なアドレス情報として取得されるため、目的の相手先への通信の可能性を高めることが可能となる。

以下実施例につき本発明を詳細に説明する。

図１は、本発明の一実施例によるアドレス情報取得装置としてのルータを用いた通信システムの構成を表わしたものである。この通信システム２００では、インターネット２０１にネームサーバとしてのＤＮＳサーバ２０２と、ウェブサイトを公開しているウェブサーバ２０３と、ルータ２０４が接続されており、ルータ２０４には更にＬＡＮ（Local Area Network）２０５が接続されている。また、ＬＡＮ２０５には通信端末としてのパーソナルコンピュータ２０７が接続されている。ＤＮＳサーバ２０２はルータ２０４の最寄りのネームサーバであり、なおかつウェブサーバ２０３のＩＰアドレスおよびドメイン名を管理する装置である。ルータ２０４は、ＬＡＮ２０５とインターネット２０１との間でパケットの転送を双方向に行うようになっているとともに、ＬＡＮ２０５側からの名前解決の要求に応じて代理でＤＮＳサーバ２０２に対する問い合わせを行うＤＮＳプロキシとしての機能を持っている。

図２は、ルータの構成を表わしたものである。ルータ２０４は、図１のＬＡＮ２０５とインターネット２０１に接続してそれぞれから送られてきたパケットの転送を行うパケット転送処理部２１１と、ＤＮＳプロキシとしての機能を実現するＤＮＳプロキシ処理部２１２を備えている。更に、ＤＮＳプロキシとしての機能以外にホスト装置としての各種データ処理を行うホスト処理部２１３を備えている。

ＤＮＳプロキシ処理部２１２は、名前解決された名前と対応するＩＰアドレスとを対応付けて格納するＤＮＳキャッシュメモリ２２１を備えている。また、パケット転送処理部２１１から受け取ったパケットが名前解決に関するものであるときにその解析を行うパケット解析部２２２と、このパケット解析部２２２の解析結果に応じてＤＮＳキャッシュメモリ２２１の書き替えを含む名前解決に関する処理を行うＤＮＳキャッシュ制御部２２３を備えている。更に、ＤＮＳキャッシュ制御部２２３からの指示に従って名前解決に関するパケットを生成しこれをパケット転送処理部２１１へと渡すパケット生成部２２４と、ＤＮＳキャッシュメモリ２２１の各エントリのＴＴＬ（Time To Live：生存時間）を更新するＴＴＬ更新部２２５を備えている。パケット解析部２２２とＤＮＳキャッシュ制御部２２３は、それぞれホスト処理部２１３と接続されている。

このルータ２０４は、図示しないがＣＰＵ（中央処理装置）と制御プログラムを格納したＲＯＭ（Read Only Memory）等の記憶媒体、ＲＡＭ（Random Access Memory）等の作業用メモリならびに通信制御部等のハードウェアによって構成されている。すなわち、制御プログラムをＣＰＵが実行することで上記した各機能部が実現するようになっている。

以下、ルータ２０４のＤＮＳキャッシュメモリ２２１にはウェブサーバ２０３についての情報が格納されていない状態で、パーソナルコンピュータ２０７からウェブサーバ２０３についての名前解決の要求があった場合を例として説明する。ここで、ウェブサーバ２０３に割り当てられた名前は「ｗｗｗ．ｈｏｇｅ１．ｃｏｍ」、ＩＰアドレスは「１９２．１６８．１．１」となっているものとする。

図１に示したパーソナルコンピュータ２０７には、名前解決を行う場合の問い合わせ先、すなわちＤＮＳサーバとして、ルータ２０４のＩＰアドレスが設定されている。したがって、パーソナルコンピュータ２０７は問い合わせの対象となる名前を格納してこれに対応するＩＰアドレスの返信を求めるパケット（以下、名前解決要求パケットという。）を、ルータ２０４宛てに送信する。

ルータ２０４のパケット転送処理部２１１は、各パケットについて図示しないルーティングテーブルを参照してその宛先ＩＰアドレスが示す相手先へと至る経路を判別し、その経路へと送り出すようになっている。たとえば、ルータ２０４側から送られてきたウェブサーバ２０３のＩＰアドレスを宛先とするパケットは、このルーティングテーブルを参照してインターネット２０１へと送出する。また、自装置のＩＰアドレスを宛先とするパケットは、ＤＮＳプロキシ処理部２１２へと渡すとともに、ＤＮＳプロキシ処理部２１２から渡されたパケットはその宛先ＩＰアドレスに対応するネットワークへと送出するようになっている。したがって、パーソナルコンピュータ２０７からＬＡＮ２０５を経由して送られてきた名前解決要求パケットを含む自装置宛てパケットは、ＤＮＳプロキシ処理部２１２へと渡される。ＤＮＳプロキシ処理部２１２では、パケット解析部２２２がこれを受け取り、パケットの解析を行う。

図３は、パケット解析部のパケット解析処理の流れを表わしたものである。パケット解析部２２２は、パケット転送処理部２１１からパケットを受け取ると（ステップＳ２５１：Ｙ）、これが名前解決要求パケットか否かを判別する（ステップＳ２５２）。名前解決要求パケットである場合には（Ｙ）、その問い合わせの対象として格納された名前と送信元のＩＰアドレスを抽出してＤＮＳキャッシュ制御部２２３へ渡し、代理で名前解決を行うことを指示する（ステップＳ２５３）。ここでは、ウェブサーバ２０３の名前「ｗｗｗ．ｈｏｇｅ１．ｃｏｍ」が渡される。そして、再びパケット転送処理部２１１からのパケットの受け取りを待機する（リターン）。

また、ルータ２０４のホスト処理部２１３でも、ＩＰパケットの送信等に伴い、名前を指定してこれに該当するＩＰアドレスを問い合わせることが必要となる場合がある。このような要求は、ルータ２０４内部で発生した名前解決要求のイベントとして同様に指定された名前と共にＤＮＳキャッシュ制御部２２３へと送られる。

図４は、ＤＮＳキャッシュ制御部の名前解決処理の流れを表わしたものである。ＤＮＳキャッシュ制御部２２３は、ホスト処理部２１３からこのようなイベントを受け取ったり、図３のステップＳ２５３に対応してパケット解析部２２２から名前を受け取る等して名前解決の実行を指示されると（ステップＳ２７１：Ｙ）、該当する名前がＤＮＳキャッシュメモリ２２１にエントリされているか否かを判別する（ステップＳ２７２）。

図５は、ウェブサーバについての名前解決が行われる前のＤＮＳキャッシュメモリの内容を表わしたものである。ＤＮＳキャッシュメモリ２２１には既に名前解決が行われた各装置の名前２９１に対応付けて、ＩＰアドレス２９２と、キャッシュとして残すべき残り時間を秒単位で表わすＴＴＬ２９３とが格納されている。ＴＴＬ２９３の値は、図２に示したＴＴＬ更新部２２５によって逐次更新されて時間の経過と共に減少するようになっており、ＴＴＬ２９３の初期値は問い合わせを行った相手先であるＤＮＳサーバ２０２により設定されるようになっている。ＴＴＬ更新部２２５によるＴＴＬ２９３の更新処理については後に説明する。ここでは、前記したようにまだウェブサーバ２０３の名前「ｗｗｗ．ｈｏｇｅ１．ｃｏｍ」はエントリされていない。

図４に戻って説明を続ける。ウェブサーバ２０３の名前はＤＮＳキャッシュメモリ２２１にまだエントリされていないため（ステップＳ２７２：Ｎ）、ＤＮＳキャッシュ制御部２２３はパケット生成部２２４にその名前とＤＮＳサーバのＩＰアドレスとを渡し、ＤＮＳサーバ２０２に対する名前解決要求パケットの生成と送信を指示する（ステップＳ２７３）。

図６は、パケット生成部のパケット生成処理の流れを表わしたものである。パケット生成部２２４は、図４のステップＳ２７３に対応して名前解決要求パケットの送信が指示されると（ステップＳ３１１：Ｙ）、受け取ったＤＮＳサーバ２０２のＩＰアドレスを宛先として該当する名前を格納した名前解決要求パケットを生成してパケット転送処理部２１１へ渡す（ステップＳ３１２）。そして、再びＤＮＳキャッシュ制御部２２３からの指示を待機する（リターン）。パケット転送処理部２１１は、前記したようにこのパケットをインターネット２０１へと送出し、その結果として名前解決要求パケットはＤＮＳサーバ２０２へと到達する。

ＤＮＳサーバ２０２は、図示しないが自己の管理下にある各装置のＩＰアドレスと名前との対応表を持っている。そして、名前解決要求パケットを受け取ると、名前が格納されている場合にはこれを対応表で検索し、名前解決要求パケットに対する応答として対応するＩＰアドレスを格納したパケット（以下、名前解決応答パケットという。）を生成し、返信するようになっている。また、この名前解決応答パケットにはそのＩＰアドレスをその問い合わせ元の装置に初期値として設定すべきＴＴＬが付加されている。ここでは、ウェブサーバ２０３のＩＰアドレス「１９２．１６８．１．１」が格納されるとともに、その宛先はルータ２０４のＩＰアドレスとなっている。したがって、ルータ２０４では、この名前解決応答パケットは自装置宛てであることからパケット転送処理部２１１を経てパケット解析部２２２へと渡される。また、ＤＮＳサーバ２０２は、この名前解決応答パケットにＴＴＬを付加するようになっており、ここでは１日の時間長さに相当する「８６，４００秒」を付加するものとする。これは、１日周期でその名前解決応答パケットにより作成されるエントリを更新すべきであることを通知するものである。また、該当するＩＰアドレスが特定できない場合には、名前解決が失敗した旨を通知する名前解決失敗情報を格納した名前解決応答パケットを生成してこれを返信するようになっている。

なお、ＤＮＳサーバ２０２は、各装置に割り当てられる名前のＴＬＤ（Top Level Domain）を管理するルートサーバのＩＰアドレスを記憶しており、問い合わせがあった名前についての情報を持っていない場合、まずこのルートサーバに対して問い合わせを行う。そして、次に問い合わせを行うべきネームサーバのＩＰアドレスをその応答結果として取得すると、そのネームサーバに対して同様に問い合わせを行う。このような問い合わせを繰り返していくことで、最終的に目的の装置のＩＰアドレスを取得できるようになっている。

図３に戻って説明を続ける。パケット解析部２２２は、パケット転送処理部２１１から受け取ったパケットが名前解決要求パケットではない場合（ステップＳ２５２：Ｎ）、次に名前解決応答パケットであるか否かを判別する（ステップＳ２５４）。名前解決応答パケットである場合には（Ｙ）、応答内容としてＩＰアドレスが格納されている場合にはＩＰアドレスと付加されたＴＴＬとを抽出してＤＮＳキャッシュ制御部２２３へ渡す（ステップＳ２５５）。ここでは、ＩＰアドレス「１９２．１６８．１．１」とＴＴＬ「８６，４００」が渡される。なお、応答内容が名前解決失敗情報である場合には、これをＤＮＳキャッシュ制御部２２３へ渡す。そして、再びパケットの受け取りを待機する（リターン）。一方、名前解決要求パケットでも名前解決応答パケットでもなかった場合には（ステップＳ２５２：Ｎ、ステップＳ２５４：Ｎ）、上位のアプリケーションソフトウェアで使用するデータが格納されているため、ホスト処理部２１３へと渡し（ステップＳ２５６）、再びパケットの受け取りを待機する（リターン）。

図４に戻って説明を続ける。ＤＮＳキャッシュ制御部２２３は、ステップＳ２７３で送信を指示した名前解決要求パケットに対する応答として、図３のステップＳ２５５に対応してパケット解析部２２２からＩＰアドレスを受け取ると（ステップＳ２７４：Ｙ）、これを問い合わせを行った名前と対応付けたものをＤＮＳキャッシュメモリ２２１にエントリさせる（ステップＳ２７５）。ステップＳ２７４でＴＴＬを受け取った場合には、これも併せてエントリさせる。

図７は、このようにしてウェブサーバについての名前解決が行われた直後のＤＮＳキャッシュメモリの内容を表わしたものであり、図５に対応するものである。図５とは異なり、新たにウェブサーバ２０３の名前「ｗｗｗ．ｈｏｇｅ１．ｃｏｍ」と、ＩＰアドレス「１９２．１６８．１．１」およびＴＴＬ「８６，４００」により構成されるエントリが作成されている。

図４に戻って説明を続ける。ＤＮＳキャッシュ制御部２２３は、更にステップＳ２７１で受け取った名前解決指示の送信元に対してこの解決したＩＰアドレスを送る（ステップＳ２７６）。具体的には、送信元が自装置の場合にはホスト処理部２１３へとＩＰアドレスを渡し、他装置の場合にはパケット生成部２２４にＩＰアドレスとＴＬＬおよび元の名前解決要求パケットの送信元ＩＰアドレスとを渡し、名前解決応答パケットの生成を指示する。ここでは、名前解決の応答内容としてウェブサーバ２０３のＩＰアドレスとＴＴＬが、そしてその送信先としてパーソナルコンピュータ２０７のＩＰアドレスが、パケット生成部２２４に渡される。このＴＴＬは、ＤＮＳサーバ２０２から通知されたものでもよいし、自装置で新たに設定したものでもよい。そして再び名前解決の実行が要求されるのを待機する（リターン）。

一方、名前解決失敗情報を受け取ったり、パケット解析部２２２からＩＰアドレスとＴＴＬを受け取らないまま所定の時間が経過してタイムアウトになるなどして、名前解決が失敗すると（ステップＳ２７４：Ｎ）、ステップＳ２７１で受け取った名前解決指示の送信元に対して対応する名前解決失敗情報を生成して送信する（ステップＳ２７７）。具体的には、送信元が自装置の場合にはホスト処理部２１３へと名前解決失敗を通知し、他装置の場合にはパケット生成部２２４に名前解決失敗情報と基の名前解決要求パケットの送信元ＩＰアドレスとを渡し、名前解決応答パケットの生成を指示する。そして再び名前解決の実行が要求されるのを待機する（リターン）。

図６に戻って説明を続ける。パケット生成部２２４は、図４のステップＳ２７６に対応して名前解決応答パケットの送信が指示されると（ステップＳ３１１：Ｎ、ステップＳ３１３：Ｙ）、指定されたＩＰアドレスを宛先とし受け取った応答内容を格納した名前解決要求パケットを生成してパケット転送処理部２１１へ渡す（ステップＳ３１４）。そして、再びＤＮＳキャッシュ制御部２２３からの指示を待機する（リターン）。図４のステップＳ２７７に対応して名前解決失敗情報を格納した名前解決応答パケットの生成が指示された場合も（ステップＳ３１１：Ｎ、ステップＳ３１３：Ｎ、ステップＳ３１５：Ｙ）、同様に受け取った名前解決失敗情報を応答内容として格納した名前解決応答パケットを生成してパケット転送処理部２１１へ渡す（ステップＳ３１６）。なお、名前解決が失敗した場合には対応する名前解決要求パケットを生成しないようにしてもよい。このようにして、図２に示したパーソナルコンピュータ２０７ではウェブサーバ２０３のＩＰアドレス「１９２．１６８．１．１」が取得され、ウェブサーバ２０３へのＩＰパケットの送信が可能となる。

以降、たとえばパーソナルコンピュータ２０７以外のＬＡＮ２０５上の図示しない通信端末から、再びウェブサーバ２０３の名前を指定した名前解決要求パケットがルータ２０４に送られてきたとする。同様にパケット転送処理部２１１とパケット解析部２２２を経て、ＤＮＳキャッシュ制御部２２３へと送られるが（図４ステップＳ２７１：Ｙ）、今度は図７に示したようにウェブサーバ２０３の名前「ｗｗｗ．ｈｏｇｅ１．ｃｏｍ」がＤＮＳキャッシュメモリ２２１にエントリされている（図４ステップＳ２７２：Ｙ）。ただし、次に説明するＴＴＬ更新部２２５による更新処理で減算処理が行われてＴＴＬが値「０」以下となっている場合には、そのエントリの内容は比較的古く、現状と一致しなくなっている恐れがある。そこで、エントリのＴＴＬが値「０」よりも大きいか否かを判別し（ステップＳ２７８）、大きい場合には（Ｙ）、そのエントリの内容は比較的新しいものであるとしてＩＰアドレス「１９２．１６８．１．１」を取得する（ステップＳ２７９）。そしてステップＳ２７６へ進み、名前解決指示の送信元に対してこれらのＩＰアドレスとＴＴＬを通知する。

図８は、ＴＴＬ更新部のＴＴＬ更新処理の流れを表わしたものである。ＴＴＬ更新部２２５は、ＤＮＳキャッシュメモリ２２１のＴＴＬ２９３を更新するための更新周期が到来すると（ステップＳ３３１：Ｙ）、ＤＮＳキャッシュメモリ２２１の各エントリのＴＴＬ２９３の値をそれぞれ更新周期の時間長さ分だけ減じる（ステップＳ３３２）。この更新周期は、たとえば１秒とすればよい。そして、たとえばＤＮＳキャッシュメモリ２２１の容量の使用率が９０％を超えているか否かというように、ＤＮＳキャッシュメモリ２２１の状態が予め定められた所定の基準を超えているか否かを判別する（ステップＳ３３３）。基準を超えている場合には（Ｙ）、より古いものあるいはＴＴＬがより少ないものを優先させる形で一部のエントリをＤＮＳキャッシュメモリ２２１から削除し（ステップＳ３３４）、次の更新周期が到来するのを待機する（リターン）。基準を超えていない場合には（ステップＳ３３３：Ｎ）、そのまま次の更新周期の到来を待機する（リターン）。

このようなＴＴＬ更新部２２５による処理によって、ＤＮＳキャッシュメモリ２２１の各エントリのＴＴＬ２９２は時間の経過とともに減っていき、やがて値「０」以下となる。従来ではこのようなエントリは削除されるが、本実施例では削除せず、ＤＮＳサーバ２０２を使用した名前解決が失敗したときにはこれを利用するようにしている。

図４に戻って説明を続ける。時間が経過してウェブサーバ２０３の名前「ｗｗｗ．ｈｏｇｅ１．ｃｏｍ」についてのエントリのＴＬＬ２９３が値「０」以下になっているときに、ウェブサーバ２０３の名前を指定した名前解決要求パケットがルータ２０４に送られてきたとする（ステップＳ２７８：Ｎ）。すると、そのエントリの内容は比較的古いものであるとして、ステップＳ２７３と同様にＤＮＳサーバ２０２に対する名前解決要求パケットの生成と送信をパケット生成部２２４に指示する（ステップＳ２８０）。これに対応する名前解決応答パケットがＤＮＳサーバ２０２から送られ、パケット解析部２２２からその応答内容としてＩＰアドレスとＴＴＬを受け取ると（ステップＳ２８１：Ｙ）、その内容でＤＮＳキャッシュメモリ２２１の該当するエントリを更新する（ステップＳ２８２）。そして、ステップＳ２７６へと進み、ステップＳ２７１で受け取った名前解決指示の送信元に対してこのＩＰアドレスと対応するＴＴＬとを通知する。

一方、名前解決が失敗した場合、すなわちＩＰアドレスを受け取らなかった場合には（ステップＳ２８１：Ｎ）、ステップＳ２７９へ進み、ＤＮＳキャッシュメモリ２２１の該当するエントリからＩＰアドレスを取得する。そしてステップＳ２７６へ進み、名前解決指示の送信元に対してこれらのＩＰアドレスとＴＴＬを名前解決の結果として通知する。ここでは、ＤＮＳキャッシュメモリ２２１の内容は図７に示した内容とＴＴＬ２９３を除いて同様となっているものとし、その結果、ＩＰアドレス「１９２．１６８．１．１」が取得される。したがって、該当する名前の装置に割り当てられたＩＰアドレスが変化していないような場合には、名前解決要求の送信元はその目的の相手先にアクセスすることができる。すなわち、ＬＡＮ２０５に配置された各装置やルータ２０４のホスト処理部２１３には、ＤＮＳサーバ２０２への再度の問い合わせで対応するＩＰアドレスが取得できない場合でも、目的の相手先にアクセスできるチャンスが与えられている。

以上説明したように本実施例では、名前に対応付けられたＩＰアドレスのレコードデータを、そのＴＴＬが値「０」となってもこれを削除せず、ＤＮＳサーバへ問い合わせを行って成功すればそのデータを更新し、失敗すれば削除せずに残しておいたデータを利用するようにしている。これにより、ネットワーク上の各装置の名前とＩＰアドレスとの対応付けの変化に追従させながら、ＤＮＳサーバのダウンやネットワーク障害等によって問い合わせが失敗したときには過去の解決結果を使用して相手先にアクセスを試みることができる。すなわち、ＩＰ網を利用した通信において、目的の相手先へのアクセス成功の可能性を高めることが可能となる。また、プロキシとして機能するため、名前解決要求パケットの送信によって所望の装置のＩＰアドレスの解決を行う、いわゆるＤＮＳリゾルバ機能を有する他の通信端末に対しても、より高い確率で適切なＩＰアドレスを提供することができる。

＜本発明の変形例＞

ＴＴＬが値「０」以下となったレコードデータを無条件に削除するようになっていた従来の手法に比べて、以上説明した実施例ではキャッシュされるデータが肥大化し、ＤＮＳキャッシュメモリに必要な容量が増大する恐れがある。そこで、この変形例では、エントリの一部を従来の手法のように削除することによって、このようなデータの肥大化を低減させる。

図９は、本発明の変形例によるルータの構成を表わしたものであり、実施例の図２に対応するものである。そこで、図２と同一部分には同一符号を付し、これらについての説明を適宜省略する。このルータ４０４には、ＤＮＳキャッシュメモリ２２１に格納される各エントリにＴＴＬが値「０」以下となっときにこれを削除すべきか否かを示すフラグを設定するフラグ設定部４２０が備えられており、ホスト処理部２１３に接続されている。また、図２のＴＴＬ更新部２２５に替えて、図８とは異なる内容のＴＴＬ更新処理を行うＴＴＬ更新部４２５が備えられている。また、ホスト処理部２１３は、図示しないがモニタとキーボードおよびポインティングデバイスとしてのマウスを備えており、ネットワーク管理者がモニタの表示内容を見ながら各種操作や情報入力が行えるようになっている。

フラグ設定部４２０は、比較的古い情報であっても過去の解決結果を保持しておくべき相手先をホスト処理部２１３によって指定されると、この相手先に該当するエントリがＤＮＳキャッシュメモリ２２１に存在するか否かを判別する。この指定は、キーボード操作による名前の指定を受け付けるようにしてもよいし、ＤＮＳキャッシュメモリ２２１に存在する名前の一部あるいは全てをリスト化したデータをホスト処理部２１３のモニタに表示させ、その中からのマウス操作による選択を受け付けるようにしてもよい。そして、ＤＮＳキャッシュメモリ２２１の指定されたエントリについて、ＴＴＬが値「０」以下となっても無条件に削除を行わないことを指示するフラグを「ＯＮ（オン）」にする。

図１０は、ＤＮＳキャッシュメモリに格納される内容を表わしたものであり、実施例の図７に対応するものである。そこで、図７と同一部分には同一符号を付し、これらについての説明を適宜省略する。図７とは異なり、各エントリには初期状態では「ＯＦＦ（オフ）」となっているフラグ４９４が付加されている。ここでは、同図に示すように、フラグ設定部４２０によって既に名前「ｗｗｗ．ｈｏｇｅ３．ｃｏｍ」のエントリにフラグ「ＯＮ」が設定されているものとする。

図１１は、ＴＴＬ更新部のＴＴＬ更新処理の流れを表わしたものであり、実施例の図８に対応するものである。そこで、図８と同一部分には同一ステップ番号を付し、これについての説明を適宜省略する。ステップＳ３３２までとステップＳ３３３以降は図８と同様となっているが、図１１に示すＴＴＬ更新処理では、ステップＳ３３２で各エントリのＴＴＬを減じた後、ＤＮＳキャッシュメモリ２２１に格納された各エントリの内容を順にチェックしていくようになっている。まず、エントリの１つについて、そのＴＴＬ２９３が値「０」よりも大きいか否か、フラグ４９４が「ＯＮ」となっているか否かをそれぞれ判別する（ステップＳ４３１）。ＴＴＬ２９３が値「０」以下となっておりなおかつフラグ４９４が「ＯＦＦ」となっている場合には（Ｎ）、そのエントリをＤＮＳキャッシュメモリ２２１から削除する（ステップＳ４３２）。そして、ＤＮＳキャッシュメモリ２２１にまだチェックを行っていないエントリが存在する場合には（ステップＳ４３３：Ｙ）、ステップＳ４３１へ戻り次のエントリのチェックに移る。

一方、ＴＴＬ２９３がまだ値「０」以下となっていない、あるいはフラグ４９４が「ＯＮ」となっている場合には（ステップＳ４３１：Ｙ）、削除を行わずにそのままステップＳ４３３へ進む。このようにしてステップＳ４３１からステップＳ４３３を繰り返し、全てのエントリのチェックが終了すると（ステップＳ４３３：Ｎ）、ステップＳ３３３へと進み図８と同様にＤＮＳキャッシュメモリの状態の観点によるエントリの削除を適宜行う。

すなわち、実施例とは異なり、ＴＴＬ２９３が値「０」以下となっていても、フラグ４９４が「ＯＮ」に設定されているものはＤＮＳキャッシュメモリ２２１に残しておき、再度の問い合わせで対応するＩＰアドレスを取得できない場合に活用することができる。たとえば、図１０の状態からエントリの更新が行われないまま２２，３３３秒が経過したとき、名前「ｗｗｗ．ｎｅｃａｔ２．ｃｏ．ｊｐ」のエントリはフラグ４９４が「ＯＦＦ」となっているため（図１１ステップＳ４３１：Ｎ）、削除される（ステップＳ４３２）。ところが、名前「ｗｗｗ．ｈｏｇｅ３．ｃｏｍ」のエントリはフラグ４９４が「ＯＮ」となっているため（図１１ステップＳ４３１：Ｙ）、ＴＬＬ２９３は値「０」以下となっているにもかかわらず残された状態となる。

このような過去の解決結果を保持しておくことを優先させるべき相手先としては、たとえば名前とＩＰアドレスの割り当てが変更されることが非常に稀で、なおかつ重要なサービスを実現しているような装置が考えられる。通信端末の位置情報を集中管理するレジストラや、複数の通信端末を管理しこれらに代理して通信を行うプロキシサーバといったいわゆるＳＩＰ（Session Initiation Protocol）サーバはこのような装置の代表的なものである。本変形例によれば、このような装置についてのエントリを優先的にＤＮＳキャッシュメモリ２２１に残すようにする一方で他のエントリを従来通りＴＴＬに従って削除するので、ＤＮＳキャッシュメモリ２２１の肥大化を抑えることができる。

なお、フラグ設定部４２０はホスト処理部２１３の操作によって過去の解決結果を保持しておくことを優先させるべき相手先を指定するようにしたが、ＤＮＳキャッシュメモリ２２１の内容を利用したアクセスの成功の可否をエントリごとに監視し、その監視結果を基に指定を行うようにしてもよい。具体的には、名前解決要求ごとにその送信元に対して対応する名前解決応答を使用したアクセスが成功したか否かを送信させるようにし、成功率が高いあるいは継続して成功していることが確認された装置ではＩＰアドレスの変更が稀であるとして、これに指定を行うようにすればよい。また、図１１のステップＳ３３４でのＤＮＳキャッシュメモリの状態の観点によるエントリの削除でも、フラグ４９４による判別を行い、「ＯＮ」となっているものを削除の対象から除外するようにしてもよい。

あるいは、初期状態でフラグ４９４を「ＯＮ」に設定し、名前解決要求パケットが送られてくるごとにその送信元と指定する相手先の名前とを対応付けて履歴として記録しておくようにする。そして、対応する名前解決応答パケットを返信してから短時間のうちに同じ内容の名前解決要求パケットが送られてきたような場合には、返信した名前解決要求パケットに基づいて行ったアクセスが失敗したと判別して、該当するフラグ４９４を「ＯＦＦ」に書き替えるようにしてもよい。あるいは、このときに該当するエントリを強制的に削除するようにしてもよい。

なお、以上説明した実施例および変形例ではＤＮＳプロキシ機能を有するルータに適用した場合について説明したが、ＤＮＳリゾルバ機能のみを有する通信端末や、他のネームサーバに問い合わせた結果を自己のメモリにキャッシュしてこれを利用するような各種アドレス情報取得装置に適用できることはもちろんである。また、エントリの削除や名前解決の再実行を行う判断基準をＴＴＬが値「０」よりも大きいか否かとしたが、所定のゼロでない数値にバイアスして、その値をネームサーバに問い合わせるようにしてもよい。また、減算ではなく加算によって時間とともにパラメータを変化させ、所定の数値以上となったときにエントリの削除や名前解決の再実行を行うようにしてもよい。

本発明の一実施例によるアドレス情報取得装置としてのルータが使用される通信システムの構成を表わした構成図である。 本発明の実施例によるルータの構成を表わした構成図である。 本発明の実施例によるパケット解析部のパケット解析処理の流れを表わした流れ図である。 本発明の実施例によるＤＮＳキャッシュ制御部の名前解決処理の流れを表わした流れ図である。 本発明の実施例によるウェブサーバについての名前解決が行われる前のＤＮＳキャッシュメモリの内容を表わした説明図である。 本発明の実施例によるパケット生成部のパケット生成処理の流れを表わした流れ図である。 本発明の実施例によるウェブサーバについての名前解決が行われた直後のＤＮＳキャッシュメモリの内容を表わした説明図である。 本発明の実施例によるＴＴＬ更新部のＴＴＬ更新処理の流れを表わした流れ図である。 本発明の変形例によるルータの構成を表わした構成図である。 本変形例によるＤＮＳキャッシュメモリに格納される内容を表わした説明図である。 本変形例によるＴＴＬ更新部のＴＴＬ更新処理の流れを表わした流れ図である。

符号の説明

２００ 通信システム
２０１ インターネット
２０２ ＤＮＳサーバ
２０３ ウェブサーバ
２０４、４０４ ルータ
２０５ ＬＡＮ
２０７ パーソナルコンピュータ
２１１ パケット転送処理部
２１２ ＤＮＳプロキシ処理部
２１３ ホスト処理部
２２１ ＤＮＳキャッシュメモリ
２２２ パケット解析部
２２３ ＤＮＳキャッシュ制御部
２２４ パケット生成部
２２５、４２５ ＴＴＬ更新部
４２０ フラグ設定部

Claims (11)

1. 通信先の装置を指定する装置指定手段と、
   通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段と、
   前記装置指定手段によって通信先の装置が指定されたとき、この装置別アドレス情報登録手段を用いてそのアドレス情報を検索するか否かを判別する検索適否判別手段と、
   この検索適否判別手段が検索しないと判別したとき前記装置指定手段が指定した装置のアドレス情報の取得を外部に対して要求するアドレス情報取得要求手段と、
   このアドレス情報取得要求手段の要求に対応するアドレス情報の取得が失敗したとき、あるいは前記検索適否判別手段が検索すると判別したとき、前記装置のアドレス情報を取得するため前記装置別アドレス情報登録手段を検索するアドレス情報検索手段
   とを具備することを特徴とするアドレス情報取得装置。
2. 前記アドレス情報取得要求手段の要求で対応するアドレス情報が取得されたとき、この取得したアドレス情報に対応する前記通信先の装置が前記装置別アドレス情報登録手段に登録されていない場合にはこれにその通信先の装置とそのアドレス情報を新規登録する新規登録手段と、
   前記アドレス情報取得要求手段の要求で対応するアドレス情報が取得されたとき、この取得したアドレス情報に対応する前記通信先の装置が前記装置別アドレス情報登録手段に登録されている場合にはその通信先の装置のアドレス情報を前記取得したアドレス情報で更新するアドレス情報更新手段とを更に具備することを特徴とする請求項１記載のアドレス情報取得装置。
3. 前記装置別アドレス情報登録手段に指定された通信先の装置についてのアドレス情報が登録されているか否かを判別するアドレス情報登録有無判別手段を更に備え、
   前記検索適否判別手段は、このアドレス情報登録有無判別手段が該当するアドレス情報が登録されていると判別したときそのアドレス情報の最新の更新が行われたときからの経過時間あるいは更新が行われていない場合の登録が行われたときからの経過時間をあらかじめ定めた時間と比較する経過時間比較手段と、この経過時間比較手段の比較により前記経過時間が前記あらかじめ定めた時間よりも長いと判別されたとき前記装置別アドレス情報登録手段による検索を行わないと判別する経過時間用検索判別手段を備えた手段であることを特徴とする請求項１記載のアドレス情報取得装置。
4. 前記検索適否判別手段は、前記装置別アドレス情報登録手段を用いてアドレス情報の検索を行うべきか否かを示す識別情報を前記通信先の装置ごとに登録した装置別検索適否登録手段を備え、前記装置指定手段によって通信先の装置が指定されたとき、この装置別検索適否登録手段を用いてアドレス情報を検索するか否かを判別することを特徴とする請求項１記載のアドレス情報取得装置。
5. 前記装置別アドレス情報登録手段に登録されたアドレス情報による対応する装置へのアクセスが成功したか否かを記録した履歴記録手段を更に具備し、
   前記検索適否判別手段は、前記装置指定手段によって通信先の装置が指定されたとき、その装置についてのこの履歴記録手段の履歴に応じて前記装置別アドレス情報登録手段を用いてそのアドレス情報を検索するか否かを判別する手段であることを特徴とする請求項１記載のアドレス情報取得装置。
6. 前記装置指定手段は少なくともドメイン名を含む名前情報で通信先の装置を指定する手段であり、前記アドレス情報は少なくともＩＰアドレスを含む情報であって、前記アドレス情報取得要求手段は自己の管理下にある各装置の名前情報とアドレス情報とを対応付けて管理するネームサーバに対してアドレス情報の取得を要求する手段であることを特徴とする請求項１記載のアドレス情報取得装置。
7. 前記装置別アドレス情報登録手段から登録を削除すべき通信先の装置を指定する要削除装置指定手段と、
   この要削除装置指定手段が指定した装置についての登録を前記装置別アドレス情報登録手段から削除する登録削除手段とを更に具備し、
   前記検索適否判別手段は、前記装置指定手段によって指定された通信先の装置についての登録が前記装置別アドレス情報登録手段に存在しないとき、この装置別アドレス情報登録手段を用いてそのアドレス情報を検索しないと判別する手段であることを特徴とする請求項１記載のアドレス情報取得装置。
8. 前記装置指定手段は、送信の対象となるデータを格納したパケットの送信の相手先の装置をアドレス情報の取得対象として指定する手段であり、
   この装置指定手段による前記指定に対応して得られたアドレス情報を宛先として該当する前記パケットの送信を行うパケット送信手段を更に具備することを特徴とする請求項１記載のアドレス情報取得装置。
9. 前記装置指定手段は、前記通信先の装置のいずれかを指定したアドレス情報の取得の要求があるとこれを受信するアドレス情報取得要求受信手段を備え、このアドレス情報取得受信手段が受信した要求で指定された装置を指定する手段であり、
   この装置指定手段による前記指定に対応して得られたアドレス情報を、前記アドレス情報取得要求受信手段が受信した対応する前記要求の送信元へと送信する取得アドレス情報送信手段を更に具備することを特徴とする請求項１記載のアドレス情報取得装置。
10. 通信先の装置を指定する装置指定ステップと、
    通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段に、この装置指定ステップで指定された装置についての登録がされているか否かを判別する登録有無判別ステップと、
    この登録有無判別ステップで登録されていると判別すると、前記装置別アドレス情報登録手段の該当するアドレス情報を取得するか否かを判別するアドレス情報取得適否判別ステップと、
    このアドレス情報取得適否判別ステップで取得しないと判別すると、前記装置指定手段が指定した装置のアドレス情報の取得を外部に対して要求するアドレス情報取得要求ステップと、
    このアドレス情報取得要求ステップでの要求に対応するアドレス情報取得が失敗すると、あるいは前記アドレス情報取得適否判別ステップで取得すると判別すると、前記装置別アドレス情報登録手段の該当するアドレス情報を取得するアドレス情報取得ステップ
    とを具備することを特徴とするアドレス情報取得方法。
11. 通信装置を構成するコンピュータに、
    通信先の装置を指定する装置指定処理と、
    通信先の各装置と通信ネットワーク上におけるこれらのアドレス情報について過去に判別されたものを対比して登録しておく装置別アドレス情報登録手段に、この装置指定処理で指定された装置についての登録がされているか否かを判別する登録有無判別処理と、
    この登録有無判別処理で登録されていると判別すると、前記装置別アドレス情報登録手段の該当するアドレス情報を取得するか否かを判別するアドレス情報取得適否判別処理と、
    このアドレス情報取得適否判別処理で取得しないと判別すると、前記装置指定手段が指定した装置のアドレス情報の取得を外部に対して要求するアドレス情報取得要求処理と、
    このアドレス情報取得要求処理での要求に対応するアドレス情報取得が失敗すると、あるいは前記アドレス情報取得適否判別処理で取得すると判別すると、前記装置別アドレス情報登録手段の該当するアドレス情報を取得するアドレス情報取得処理
    とを実行させるアドレス情報取得プログラム。

Images