(57)【特許請求の範囲】
【請求項１】
通信先の装置の名前を指定する名前指定手段と、
通信先の各装置の名前と通信ネットワーク上におけるこれらのアドレス情報およびこれらの情報を最低限残すべき残り時間について過去に前記名前の判別されたものを対比して登録しておく装置情報格納メモリと、
前記名前指定手段によって通信先の装置の名前が指定されたとき、前記装置情報格納メモリ内に該当する名前があり、かつ前記残り時間が経過しているかどうかによってアドレス情報の検索の適否を判別する検索適否判別手段と、
この検索適否判別手段がアドレス情報の検索をしないと判別したとき前記名前指定手段が指定した装置の名前に対応するアドレス情報の取得を外部に対して要求するアドレス情報取得要求手段と、
このアドレス情報取得要求手段の要求に対応するアドレス情報の取得が失敗したとき、あるいは前記検索適否判別手段が検索を適当であると判別したとき、前記装置の名前に対応するアドレス情報を取得するため前記装置情報格納メモリを検索するアドレス情報検索手段と、
前記名前指定手段による名前の指定が行われ、前記アドレス情報検索手段による検索結果が検索の要求先に通知されたときから予め設定した所定の短時間が経過する前に前記名前指定手段による同一の名前の指定が行われたとき、前記アドレス情報取得要求手段の要求に対応するアドレス情報の取得が失敗したと判別するアドレス情報取得失敗判別手段
とを具備することを特徴とするアドレス情報取得装置。
【請求項２】
前記アドレス情報取得要求手段の要求に対応するアドレス情報の取得が成功したとき前記装置情報格納メモリ内の該当する名前に対応する前記残り時間を初期値に更新することを特徴とする請求項１記載のアドレス情報取得装置。
【請求項３】
前記残り時間がなくなったときに、対応する装置の名前とアドレス情報を前記装置情報格納メモリから削除すべきか否かを示すフラグを設定するフラグ設定手段を更に具備することを特徴とする請求項１記載のアドレス情報取得装置。
【請求項４】
前記アドレス情報の取得が失敗したと判別したとき、前記フラグ設定手段によって設定された対応するフラグを、装置の名前とアドレス情報を前記装置情報格納メモリから削除すべきとする側に変更することを特徴とする請求項３記載のアドレス情報取得装置。
【請求項５】
通信先の装置の名前を指定する名前指定ステップと、
通信先の各装置の名前と通信ネットワーク上におけるこれらのアドレス情報およびこれらの情報を最低限残すべき残り時間について過去に前記名前の判別されたものを対比して装置情報格納メモリに登録する装置情報格納メモリ登録ステップと、
前記名前指定ステップによって通信先の装置の名前が指定されたとき、前記装置情報格納メモリ内に該当する名前があり、かつ前記残り時間が経過しているかどうかによって検索の適否を判別する検索適否判別ステップと、
この検索適否判別ステップで検索をしないと判別したとき前記名前指定ステップで指定した装置の名前に対応するアドレス情報の取得を外部に対して要求するアドレス情報取得要求ステップと、
このアドレス情報取得要求ステップによる要求に対応するアドレス情報の取得が失敗したとき、あるいは前記検索適否判別ステップで検索を適当であると判別したとき、前記装置の名前に対応するアドレス情報を取得するため前記装置情報格納メモリを検索するアドレス情報検索ステップと、
前記名前指定ステップによる名前の指定が行われ、前記アドレス情報検索ステップによる検索結果が検索の要求先に通知されたときから予め設定した所定の短時間が経過する前に前記名前指定ステップによる同一の名前の指定が行われたとき、前記アドレス情報取得要求ステップの要求に対応するアドレス情報の取得が失敗したと判別するアドレス情報取得失敗判別ステップ
とを具備することを特徴とするアドレス情報取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネームサーバのようにネットワークに配置された各装置のアドレス情報を管理する装置に対して所望の装置のアドレス情報の問い合わせを行うアドレス情報取得装置およびアドレス情報取得方法に係わり、特に問い合わせの結果得られたアドレス情報を該当する装置に対応付けて自装置内に記憶しておきこれを使用するようにしたアドレス情報取得装置およびアドレス情報取得方法に関する。
【背景技術】
【０００２】
インターネットに代表されるＩＰ（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）サーバはこのような装置の代表的なものである。本変形例によれば、このような装置についてのエントリを優先的にＤＮＳキャッシュメモリ２２１に残すようにする一方で他のエントリを従来通りＴＴＬに従って削除するので、ＤＮＳキャッシュメモリ２２１の肥大化を抑えることができる。
【００５４】
なお、フラグ設定部４２０はホスト処理部２１３の操作によって過去の解決結果を保持しておくことを優先させるべき相手先を指定するようにしたが、ＤＮＳキャッシュメモリ２２１の内容を利用したアクセスの成功の可否をエントリごとに監視し、その監視結果を基に指定を行うようにしてもよい。具体的には、名前解決要求ごとにその送信元に対して対応する名前解決応答を使用したアクセスが成功したか否かを送信させるようにし、成功率が高いあるいは継続して成功していることが確認された装置ではＩＰアドレスの変更が稀であるとして、これに指定を行うようにすればよい。また、図１１のステップＳ３３４でのＤＮＳキャッシュメモリの状態の観点によるエントリの削除でも、フラグ４９４による判別を行い、「ＯＮ」となっているものを削除の対象から除外するようにしてもよい。
【００５５】
あるいは、初期状態でフラグ４９４を「ＯＮ」に設定し、名前解決要求パケットが送られてくるごとにその送信元と指定する相手先の名前とを対応付けて履歴として記録しておくようにする。そして、対応する名前解決応答パケットを返信してから短時間のうちに同じ内容の名前解決要求パケットが送られてきたような場合には、返信した名前解決要求パケットに基づいて行ったアクセスが失敗したと判別して、該当するフラグ４９４を「ＯＦＦ」に書き替えるようにしてもよい。あるいは、このときに該当するエントリを強制的に削除するようにしてもよい。
【００５６】
なお、以上説明した実施例および変形例ではＤＮＳプロキシ機能を有するルータに適用した場合について説明したが、ＤＮＳリゾルバ機能のみを有する通信端末や、他のネームサーバに問い合わせた結果を自己のメモリにキャッシュしてこれを利用するような各種アドレス情報取得装置に適用できることはもちろんである。また、エントリの削除や名前解決の再実行を行う判断基準をＴＴＬが値「０」よりも大きいか否かとしたが、所定のゼロでない数値にバイアスして、その値をネームサーバに問い合わせるようにしてもよい。また、減算ではなく加算によって時間とともにパラメータを変化させ、所定の数値以上となったときにエントリの削除や名前解決の再実行を行うようにしてもよい。
【図面の簡単な説明】
【００５７】
【図１】本発明の一実施例によるアドレス情報取得装置としてのルータが使用される通信システムの構成を表わした構成図である。
【図２】本発明の実施例によるルータの構成を表わした構成図である。
【図３】本発明の実施例によるパケット解析部のパケット解析処理の流れを表わした流れ図である。
【図４】本発明の実施例によるＤＮＳキャッシュ制御部の名前解決処理の流れを表わした流れ図である。
【図５】本発明の実施例によるウェブサーバについての名前解決が行われる前のＤＮＳキャッシュメモリの内容を表わした説明図である。
【図６】本発明の実施例によるパケット生成部のパケット生成処理の流れを表わした流れ図である。
【図７】本発明の実施例によるウェブサーバについての名前解決が行われた直後のＤＮＳキャッシュメモリの内容を表わした説明図である。
【図８】本発明の実施例によるＴＴＬ更新部のＴＴＬ更新処理の流れを表わした流れ図である。
【図９】本発明の変形例によるルータの構成を表わした構成図である。
【図１０】本変形例によるＤＮＳキャッシュメモリに格納される内容を表わした説明図である。
【図１１】本変形例によるＴＴＬ更新部のＴＴＬ更新処理の流れを表わした流れ図である。
【符号の説明】
【００５８】
２００  通信システム
２０１  インターネット
２０２  ＤＮＳサーバ
２０３  ウェブサーバ
２０４、４０４  ルータ
２０５  ＬＡＮ
２０７  パーソナルコンピュータ
２１１  パケット転送処理部
２１２  ＤＮＳプロキシ処理部
２１３  ホスト処理部
２２１  ＤＮＳキャッシュメモリ
２２２  パケット解析部
２２３  ＤＮＳキャッシュ制御部
２２４  パケット生成部
２２５、４２５  ＴＴＬ更新部
４２０  フラグ設定部
【図１】
0004266950.tif 000002
【図２】
0004266950.tif 000003
【図３】
0004266950.tif 000004
【図４】
0004266950.tif 000005
【図５】
0004266950.tif 000006
【図６】
0004266950.tif 000007
【図７】
0004266950.tif 000008
【図８】
0004266950.tif 000009
【図９】
0004266950.tif 000010
【図１０】
0004266950.tif 000011
【図１１】
0004266950.tif 000012