(57)【要約】【課題】１つのコア網と複数のプライベート網がゲートウェイを介して接続する環境において、プライベート網のサーバに接続することを可能とする。【解決手段】端末は、目的のサーバのドメイン名解決を行い、探索結果が得られない場合に、目的のサーバに中継するゲートウェイのドメイン名解決を行う。このとき、ＤＮＳサーバは、サーバのドメイン名の最後に、専用のＴＬＤ（Ｔｏｐ  Ｌｅｖｅｌ  Ｄｏｍａｉｎ）を付加したものと、ゲートウェイのアドレスを対応付けて管理している。端末は、ゲートウェイのドメイン名解決を行うために、目的のサーバのドメイン名の最後に、専用のＴＬＤを付加してドメイン名解決を行う。ＤＮＳサーバは、ＴＬＤが付加されたドメイン名に対応するゲートウェイのアドレスを応答として返す。端末は、ゲートウェイのアドレスを取得した場合、ゲートウェイへの接続手順でゲートウェイに接続し、ゲートウェイに対して、目的のサーバへの接続要求を行う。【選択図】図４
2010130604.tif 000002
【特許請求の範囲】
【請求項１】
コア網と、
少なくとも１つのサーバが存在するプライベート網と、
前記コア網と前記プライベート網とを接続するゲートウェイと、
前記コア網上に存在し、前記プライベート網上のサーバの既存のドメイン名に対する特定の機能を問い合わせるために付加される独自のトップレベルドメインを管理するドメイン名管理サーバと、
前記コア網上に存在し、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせに対し、前記ゲートウェイのアドレスを応答する名前解決サーバと
を含む
動的ゲートウェイ探索システム。
【請求項２】
請求項１に記載の動的ゲートウェイ探索システムであって、
前記名前解決サーバは、前記既存のドメイン名への問い合わせに対しては応答せず、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせに対し、前記ゲートウェイのアドレスを応答する
動的ゲートウェイ探索システム。
【請求項３】
請求項１又は２に記載の動的ゲートウェイ探索システムであって、
前記ドメイン名管理サーバは、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを受け取り、事前に前記ドメイン名管理サーバが登録されていれば、前記受け取った問い合わせを前記ドメイン名管理サーバに転送する
動的ゲートウェイ探索システム。
【請求項４】
請求項１乃至３のいずれか一項に記載の動的ゲートウェイ探索システムであって、
前記プライベート網外に存在する端末は、前記コア網に対し、前記既存のドメイン名への問い合わせに対する応答が得られなかった場合、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを行い、前記ゲートウェイのアドレスを取得すると、前記ゲートウェイを介して前記プライベート網上のサーバに接続し、前記特定の機能を利用する
動的ゲートウェイ探索システム。
【請求項５】
請求項４に記載の動的ゲートウェイ探索システムであって、
前記プライベート網外に存在する端末は、他のプライベート網上に存在する場合、前記コア網と前記他のプライベート網とを接続する他のゲートウェイを介して、前記コア網に対し、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを行う
動的ゲートウェイ探索システム。
【請求項６】
請求項４又は５に記載の動的ゲートウェイ探索システムであって、
前記名前解決サーバは、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名と前記ゲートウェイのアドレスとを紐付けして前記ドメイン名管理サーバに登録し、
前記ドメイン名管理サーバは、前記プライベート網外に存在する端末から、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを受け取ると、前記プライベート網外に存在する端末に対し、前記ゲートウェイのアドレスを応答する
動的ゲートウェイ探索システム。
【請求項７】
請求項４乃至６のいずれか一項に記載の動的ゲートウェイ探索システムで使用される端末。
【請求項８】
請求項１乃至６のいずれか一項に記載の動的ゲートウェイ探索システムで使用されるドメイン名管理サーバ。
【請求項９】
請求項１乃至６のいずれか一項に記載の動的ゲートウェイ探索システムで使用される名前解決サーバ。
【請求項１０】
ゲートウェイを介して、コア網と少なくとも１つのサーバが存在するプライベート網とを接続するステップと、
前記コア網上で、前記プライベート網上のサーバの既存のドメイン名に対する特定の機能を問い合わせるために付加される独自のトップレベルドメインを管理するステップと、
前記コア網上で、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせに対し、前記ゲートウェイのアドレスを応答するステップと
を含む
動的ゲートウェイ探索方法。
【請求項１１】
請求項１０に記載の動的ゲートウェイ探索方法であって、
前記既存のドメイン名への問い合わせに対しては応答せず、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせに対し、前記ゲートウェイのアドレスを応答するステップ
を更に含む
動的ゲートウェイ探索方法。
【請求項１２】
請求項１０又は１１に記載の動的ゲートウェイ探索方法であって、
前記プライベート網外から前記コア網に対して、前記既存のドメイン名への問い合わせを行った際に、前記既存のドメイン名への問い合わせに対する応答が得られなかった場合、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを行うステップと、
前記ゲートウェイのアドレスを取得すると、前記ゲートウェイを介して前記プライベート網上のサーバに接続し、前記特定の機能を利用するステップと
を更に含む
動的ゲートウェイ探索方法。
【請求項１３】
請求項１２に記載の動的ゲートウェイ探索方法であって、
他のプライベート網から前記コア網に対して、前記既存のドメイン名への問い合わせを行った際に、前記既存のドメイン名への問い合わせに対する応答が得られなかった場合、前記コア網と前記他のプライベート網とを接続する他のゲートウェイを介して、前記コア網に対し、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを行うステップ
を更に含む
動的ゲートウェイ探索方法。
【請求項１４】
請求項１２又は１３に記載の動的ゲートウェイ探索方法であって、
前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名と前記ゲートウェイのアドレスとを紐付けして登録するステップと、
前記プライベート網外から、前記既存のドメイン名に前記トップレベルドメインが付加されたドメイン名への問い合わせを受け取ると、前記プライベート網外に対し、前記ゲートウェイのアドレスを応答するステップ
を更に含む
動的ゲートウェイ探索方法。
【請求項１５】
請求項１０乃至１４のいずれか一項に記載の動的ゲートウェイ探索方法を、コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動的ゲートウェイ探索システムに関し、特に１つのコア網と複数のプライベート網がゲートウェイを介して接続する動的ゲートウェイ探索システムに関する。
【背景技術】
【０００２】
図１のように、ＩＰネットワークによるコア網「Ｇ」に複数のプライベート網「Ａ〜Ｃ」が接続する環境において、コア網上の端末「Ｕ」（１０）や、コア網上のサーバ「Ｓｇ１〜４」（２０−ｉ、ｉ＝１〜４）、プライベート網上のサーバ「Ｓａ１〜３」（２１−ｉ、ｉ＝１〜３）、「Ｓｂ１〜３」（２２−ｉ、ｉ＝１〜３）、「Ｓｃ１〜３」（２３−ｉ、ｉ＝１〜３）がある。コア網とプライベート網とは、ゲートウェイ「Ｎ１〜３」（３０−ｉ、ｉ＝１〜３）を介してそれぞれ接続している。ここで、コア網上の端末「Ｕ」（１０）からコア網上のサーバとプライベート網上のサーバとに接続する環境を実現することが求められている。
【０００３】
上記の課題の解決手法として、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）方式と、仮想ホスト方式とがある。いずれの方式も、ＤＮＳサーバ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｅｒｖｅｒ）を使用する。ＤＮＳサーバは、ネームサーバ（Ｎａｍｅ  Ｓｅｒｖｅｒ）の一例である。ここでは、ＩＰマスカレードを始めとするＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）方式もＮＡＴ方式の１つとする。
【０００４】
図２を参照して、ＮＡＴ方式について説明する。
ＮＡＴ方式は、ゲートウェイ「Ｎ１」（３０−１）がプライベート網内のサーバ毎にコア網側のＩＰアドレスを対応させる方法である。この方式（ＮＡＴ方式）では、端末「Ｕ」（１０）がドメイン名「Ｓａ２．Ａ」のサーバに接続する場合、以下の手順で処理を行う。
【０００５】
（１）ステップＳ２０１
端末「Ｕ」（１０）は、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）に問い合わせ、ＩＰアドレス「ｇａ２」を取得する。
【０００６】
（２）ステップＳ２０２
端末「Ｕ」（１０）は、ＩＰアドレス「ｇａ２」に接続すると、ゲートウェイ「Ｎ１」（３０−１）に到達する。
【０００７】
（３）ステップＳ２０３
端末「Ｕ」（１０）は、ゲートウェイ「Ｎ１」（３０−１）により、ＩＰアドレス「ｇａ２」への接続を、ＩＰアドレス「ｐａ２」との通信に書き換えられ、プライベート網内のサーバ「Ｓａ２」（２１−２）に接続する。
【０００８】
この方式（ＮＡＴ方式）は、プライベート網内のサーバが増加するとコア網側のＩＰアドレスを消費するという課題があり、接続可能なサーバ数は、コア網側のＩＰアドレス数の制限を受けるという課題がある。
【０００９】
図３を参照して、仮想ホスト方式について説明する。
仮想ホスト方式は、ゲートウェイ「Ｎ１」（３０−１）がＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サーバとして動作し、各サーバに接続を振り分ける方式である。この方式（仮想ホスト方式）では、端末「Ｕ」（１０）がドメイン名「Ｓａ２．Ａ」のサーバに接続する場合、以下の手順で処理を行う。
【００１０】
（１）ステップＳ３０１
端末「Ｕ」（１０）は、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）に問い合わせ、コア網側のＩＰアドレス「ｇａ１」を取得する。
【００１１】
（２）ステップＳ３０２
端末「Ｕ」（１０）は、ゲートウェイ「Ｎ１」（３０−１）に設定されたＩＰアドレス「ｇａ１」に接続し、ＨＴＴＰリクエストを送信する。
【００１２】
（３）ステップＳ３０３
ゲートウェイ「Ｎ１」（３０−１）は、ＨＴＴＰリクエストを解析し、Ｈｏｓｔヘッダからドメイン名「Ｓａ２．Ａ」への要求であることを知る。
【００１３】
（４）ステップＳ３０４
ゲートウェイ「Ｎ１」（３０−１）は、プライベート網内向けＤＮＳデータを参照し、ドメイン名「Ｓａ２．Ａ」への要求であることに基づいて、ＩＰアドレス「ｐａ２」を取得する。プライベート網内向けＤＮＳデータには、ドメイン名「Ｓａ２．Ａ」とＩＰアドレス「ｐａ２」とが紐付け（対応付け）されている。これにより、ゲートウェイ「Ｎ１」（３０−１）は、ＩＰアドレス「ｇａ１」とＩＰアドレス「ｐａ２」との通信を中継する。
【００１４】
（５）ステップＳ３０５
端末「Ｕ」（１０）は、プライベート網内のサーバ「Ｓａ２」（２１−２）に接続する。
【００１５】
この方式（仮想ホスト方式）は、非暗号の場合は良いが、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）に対応できない課題がある。ＳＳＬは、接続時にサーバからクライアントにサーバ証明書を送信するが、ゲートウェイ「Ｎ１」（３０−１）は、ＩＰアドレスを共通化しているため、サーバ「Ｓａ１〜３」（２１−ｉ、ｉ＝１〜３）のどのサーバ証明書を送信すれば良いか分からないからである。
【００１６】
また、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）の「Ｓｅｒｖｅｒ  Ｎａｍｅ  Ｉｎｄｉｃａｔｉｏｎ拡張」では、接続時にクライアントがサーバに接続したいサーバ名を通知することができる。仮想ホスト方式に適用すれば、ゲートウェイ「Ｎ１」（３０−１）がサーバ「Ｓａ１〜３」（２１−ｉ、ｉ＝１〜３）に接続を中継し、クライアントにサーバ証明書を送信することができる。しかし、ゲートウェイ「Ｎ１」（３０−１）と仮想ホストサーバ「Ｓａ１〜３」（２１−ｉ、ｉ＝１〜３）がＴＬＳに使うポート番号を合わせなければならないという制約があり、大規模なプライベート網「Ａ」に適用できないという課題がある。
【００１７】
その他、ＤＮＳサーバに新たなレコードを追加し、ゲートウェイが介在するかどうか判定するという手法が考えられる。しかし、新たなレコードの追加は、広範囲のＤＮＳサーバの変更が必要になるという課題がある。また、プロキシサーバ（ｐｒｏｘｙ）の有無を端末上のファイルを用いて管理する方法が考えられる。しかし、ドメイン名のデータベースを端末に置いて常に最新の状態に保つことは、更新頻度が膨大になるという課題がある。
【００１８】
すなわち、ＮＡＴ方式や仮想ホスト方式では、以下のような問題点が存在する。
【００１９】
第１の問題点は、プライベート網上に複数のサーバを設置した場合に、ゲートウェイであるＮＡＴサーバのコア網側のアドレスも複数必要になることである。その理由は、サーバの運用では固定のポート番号が必要となるため、複数のサーバを識別するためにはアドレスが複数必要となるためである。
【００２０】
第２の問題点は、ゲートウェイをＨＴＴＰサーバとした場合に、アドレスを１つに集約することができるが、ＳＳＬによる暗号化が行えないことである。その理由は、ゲートウェイがプロトコル内の情報を解析して転送先サーバを判定する必要があるが、ＳＳＬの場合は、最初の暗号化手順でクライアントに送信するべき証明書の判定ができない。これはアドレスが１つのため、その先のサーバがどれなのか分からないからである。
【００２１】
第３の問題点は、目的のサーバに接続するためにゲートウェイがあるかどうかを端末が管理するのは、そのデータベースの更新頻度が膨大になるということである。その理由は、端末が持つ現在のゲートウェイのデータベース（プロキシ自動設定ファイル）は、特定のゲートウェイを使うことが前提となっている。一方、複数のプライベート網が存在する環境では、ゲートウェイが複数存在するが、これへの対応はない。また、対応が可能だとしてもサーバの追加に併せて端末のデータベースを更新し、最新の状態に保持するためには、その更新頻度が多くなってしまうからである。
【００２２】
なお、関連する技術として、特開２００３−２９８６２０号公報（特許文献１）に仮想ドメインシステムが開示されている。この関連技術では、仮想ドメインサーバは、仮想ドメイン名及び対応する実ドメイン名を紐付けして書込み、正常に書込みが完了後、書込み完了通知を仮想ドメイン登録サーバに返す。仮想ドメイン名に含まれるＴＬＤ（Ｔｏｐ  Ｌｅｖｅｌ  Ｄｏｍａｉｎ：トップレベルドメイン）に応じて、各サーバが紐付けされた仮想ドメイン名及び対応する実ドメイン名に関する情報を登録する。また、情報利用者は、情報利用者端末から仮想ドメイン名を含む仮想アドレスにて、ネットワーク上に対して情報を要求する。
【００２３】
また、特開２００６−１８０２９５号公報（特許文献２）にアドレス変換装置及びアドレス変換方法が開示されている。この関連技術では、プライベートネットワーク内のホストは、プライベートネットワーク内のＤＮＳサーバへドメイン名「ａ．ｇｌｏｂａｌ．ｃｏｍ」の名前解決の依頼（ＤＮＳクエリ）を送信する。しかし、ＤＮＳサーバには、ドメイン名「ａ．ｇｌｏｂａｌ．ｃｏｍ」が登録されていないため、ゲートウェイ装置へ名前問い合わせが送信される。この場合、ＤＮＳメッセージ生成部によって名前問い合わせが生成され、グローバルネットワーク内のＤＮＳサーバｃへ名前問い合わせが転送される。この関連技術では、ゲートウェイ装置において、プライベートネットワーク内のホストにはゲートウェイ装置のグローバルＩＰアドレス及びグローバルポートが割り当てられ、グローバルネットワーク内のホストにはプライベートＩＰアドレスが割り当てられる。
【００２４】
【特許文献１】特開２００３−２９８６２０号公報
【特許文献２】特開２００６−１８０２９５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２５】
本発明の目的は、ゲートウェイのコア網側のアドレスを１つに集約し、ＨＴＴＰ及びＨＴＴＰＳ（ＨＴＴＰ  ｏｖｅｒ  ＴＬＳ／ＳＳＬ）による通信を実現する動的ゲートウェイ探索システム、動的ゲートウェイ探索方法、及びプログラムを提供することである。
【課題を解決するための手段】
【００２６】
本発明の動的ゲートウェイ探索システムは、コア網と、少なくとも１つのサーバが存在するプライベート網と、コア網とプライベート網とを接続するゲートウェイと、コア網上に存在し、プライベート網上のサーバの既存のドメイン名に対する特定の機能を問い合わせるために付加される独自のトップレベルドメインを管理するドメイン名管理サーバと、コア網上に存在し、既存のドメイン名にトップレベルドメインが付加されたドメイン名への問い合わせに対し、ゲートウェイのアドレスを応答する名前解決サーバとを含む。
【００２７】
本発明の動的ゲートウェイ探索方法は、ゲートウェイを介して、コア網と少なくとも１つのサーバが存在するプライベート網とを接続するステップと、コア網上で、プライベート網上のサーバの既存のドメイン名に対する特定の機能を問い合わせるために付加される独自のトップレベルドメインを管理するステップと、コア網上で、既存のドメイン名にトップレベルドメインが付加されたドメイン名への問い合わせに対し、ゲートウェイのアドレスを応答するステップとを含む。
【発明の効果】
【００２８】
１つのコア網と複数のプライベート網がゲートウェイを介して接続する環境において、プライベート網のサーバに接続することを可能とする。
【発明を実施するための最良の形態】
【００２９】
＜本発明の第１実施形態＞
以下に、本発明の第１実施形態について添付図面を参照して説明する。
本発明の動的ゲートウェイ探索システムでは、図４のように、ＩＰネットワークによるコア網「Ｇ」に複数のプライベート網「Ａ〜Ｂ」が接続する環境において、コア網上の端末「Ｕ」（１０）や、プライベート網上のサーバ「Ｓａ１〜３」（２１−ｉ、ｉ＝１〜３）、「Ｓｂ１〜３」（２２−ｉ、ｉ＝１〜３）がある。コア網とプライベート網とは、ゲートウェイ「Ｎ１〜２」（３０−ｉ、ｉ＝１〜２）を介してそれぞれ接続している。ここでは、各ゲートウェイは、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）サーバとして動作しているものとする。また、本発明の動的ゲートウェイ探索システムでは、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）、「ＤＮＳ  Ｂ」（４０−２）、「ＤＮＳ  Ｌ」（４０−３）、「ＤＮＳ  Ｐ」（４０−４）、「ＤＮＳ  Ｒ」（４０−５）がある。
【００３０】
本発明の動的ゲートウェイ探索システムでは、コア網側に「．ｐｒｏｘｙ」というＴＬＤ（Ｔｏｐ  Ｌｅｖｅｌ  Ｄｏｍａｉｎ：トップレベルドメイン）を管理するＤＮＳサーバを置く。ここでは、ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）が、「．ｐｒｏｘｙ」というＴＬＤを管理するＤＮＳサーバであるものとする。すなわち、ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）は、ドメイン名管理サーバである。
【００３１】
ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）は、コア網内のルートサーバ（ｒｏｏｔ）である。
【００３２】
ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、プライベート網「Ａ」の本来のドメイン名「．Ａ」に加え、ＴＬＤ付きのドメイン名「．Ａ．ｐｒｏｘｙ」を管理する。ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、プライベート網内のサーバのドメイン名「Ｓａ１．Ａ」に対するコア網側からの問い合わせには応答せず、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」に対する問い合わせには、ゲートウェイ「Ｎ１」（３０−１）のコア網側のアドレスを応答する。すなわち、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、名前解決サーバである。
【００３３】
ゲートウェイ「Ｎ１」（３０−１）は、ＨＴＴＰのプロキシサーバ（ｐｒｏｘｙ）である。
【００３４】
なお、端末「Ｕ」（１０）の例として、ＰＣ（パソコン）、シンクライアント端末、ワークステーション、携帯電話機、、携帯ゲーム機、携帯音楽プレーヤー、カーナビ（カーナビゲーションシステム）、家庭用ゲーム機、双方向テレビ、デジタルチューナー、デジタルレコーダー、情報家電（ｉｎｆｏｒｍａｔｉｏｎ  ｈｏｍｅ  ａｐｐｌｉａｎｃｅ）、ＰＯＳ（Ｐｏｉｎｔ  ｏｆ  Ｓａｌｅ）端末、ＯＡ（Ｏｆｆｉｃｅ  Ａｕｔｏｍａｔｉｏｎ）機器、又は同様の通信機能を有する電子機器等が考えられる。端末「Ｕ」（１０）は、車両や船舶、航空機等の移動体に搭載されていても良い。また、端末「Ｕ」（１０）は、コンピュータに搭載される拡張ボードやソフトウェアでも良い。更に、端末「Ｕ」（１０）は、コンピュータに搭載された仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ（ＶＭ））環境でも良い。但し、実際には、これらの例に限定されない。
【００３５】
また、サーバ「Ｓａ１〜３」（２１−ｉ、ｉ＝１〜３）、「Ｓｂ１〜３」（２２−ｉ、ｉ＝１〜３）、及び、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）、「ＤＮＳ  Ｂ」（４０−２）、「ＤＮＳ  Ｌ」（４０−３）、「ＤＮＳ  Ｐ」（４０−４）、「ＤＮＳ  Ｒ」（４０−５）の例として、ＰＣ、シンクライアントサーバ、ワークステーション、メインフレーム、スーパーコンピュータ等のコンピュータを想定している。各サーバは、車両や船舶、航空機等の移動体に搭載されていても良い。また、各サーバは、コンピュータに搭載される拡張ボードやソフトウェアでも良い。更に、各サーバは、コンピュータに搭載された仮想マシン（ＶＭ）環境でも良い。但し、実際には、これらの例に限定されない。
【００３６】
ここでは、ゲートウェイ「Ｎ１〜２」（３０−ｉ、ｉ＝１〜２）の例として、ＨＴＴＰプロキシサーバを想定しているが、他にも、ルータやスイッチングハブ等の中継機器や、ネットワーク上の中継サーバ、キャッシュサーバ（ｃａｃｈｅ  ｓｅｒｖｅｒ）、ファイアウォール（ｆｉｒｅｗａｌｌ）等が考えられる。但し、実際には、これらの例に限定されない。
【００３７】
また、コア網、及び、プライベート網の例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ、３Ｇ（第３世代携帯電話）、専用線等が考えられる。但し、実際には、これらの例に限定されない。
【００３８】
図４を参照して、本発明の動的ゲートウェイ探索システムの動作原理について説明する。
【００３９】
（１）ステップＳ４０１
予め、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、ＴＬＤ「．ｐｒｏｘｙ」を管理するＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に、プライベート網「Ａ」のドメイン名のゲートウェイが登録できるように、登録を行う。この手続きは、自動でも手動でも構わない。例えば、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）自身を登録することで、ＴＬＤ「．ｐｒｏｘｙ」が付加されたドメイン名の問い合わせを受けられるようにする。ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）は、登録されたＤＮＳサーバがＴＬＤ付きのドメイン名の問い合わせに対応していると認識し、ＴＬＤ「．ｐｒｏｘｙ」が付加されたドメイン名の問い合わせを受けた際に、登録されたＤＮＳサーバに対して、問い合わせを転送する。但し、実際には、これらの例に限定されない。
【００４０】
（２）ステップＳ４０２
端末「Ｕ」（１０）は、プライベート網「Ａ」内のサーバのドメイン名「Ｓａ１．Ａ」に接続する際、端末「Ｕ」（１０）が接続するコア網内のＤＮＳサーバ「ＤＮＳ  Ｌ」（４０−３）を介して、ドメイン名解決を行う。ここでは、端末「Ｕ」（１０）は、ＤＮＳサーバ「ＤＮＳ  Ｌ」（４０−３）を介して、コア網内のルートサーバ（ｒｏｏｔ）であるＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）に対して、ドメイン名「Ｓａ１．Ａ」の問い合わせを行う。ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）は、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）に、ドメイン名「Ｓａ１」の問い合わせを転送する。このとき、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、ドメイン名「Ｓａ１．Ａ」へのコア網側からの問い合わせには応答しない。従って、端末「Ｕ」（１０）は、ドメイン名「Ｓａ１．Ａ」のドメイン名解決に失敗する。
【００４１】
（３）ステップＳ４０３
端末「Ｕ」（１０）は、ドメイン名「Ｓａ１．Ａ」のドメイン名解決に失敗した場合、プライベート網「Ａ」内のサーバのドメイン名「Ｓａ１．Ａ」にＴＬＤ「．ｐｒｏｘｙ」を付加し、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」のドメイン名解決を行う。このとき、端末「Ｕ」（１０）は、ＤＮＳサーバ「ＤＮＳ  Ｌ」（４０−３）を介して、コア網内の各ＤＮＳサーバに対して、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを行う。例えば、端末「Ｕ」（１０）は、ＤＮＳサーバ「ＤＮＳ  Ｌ」（４０−３）を介して、ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）に対して、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを行う。ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）は、ＴＬＤ「．ｐｒｏｘｙ」を管理するＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを転送する。ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）は、登録されたＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）に、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを転送する。最終的に、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせに対して、ゲートウェイ「Ｎ１」（３０−１）のアドレスを応答する。これにより、端末「Ｕ」（１０）は、ゲートウェイ「Ｎ１」（３０−１）のアドレスを取得する。
【００４２】
（４）ステップＳ４０４
端末「Ｕ」（１０）は、ゲートウェイ「Ｎ１」（３０−１）をドメイン名「Ｓａ１．Ａ」へのＨＴＴＰプロキシとして接続する。このとき、ゲートウェイ「Ｎ１」（３０−１）は、ＨＴＴＰプロキシ用にポート番号「８０８０番」を固定で使うこととする。
【００４３】
（５）ステップＳ４０５
ゲートウェイ「Ｎ１」（３０−１）は、ドメイン名「Ｓａ１．Ａ」の特定の機能に対する接続要求を受けると、プライベート網「Ａ」内のＤＮＳサーバに問い合わせ、プライベート網内のサーバのドメイン名「Ｓａ１．Ａ」のアドレスを取得し、ドメイン名「Ｓａ１．Ａ」の当該特定の機能で利用されるポート番号に接続する。例えば、ゲートウェイ「Ｎ１」（３０−１）は、ドメイン名「Ｓａ１．Ａ」がＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）の場合、「ＣＯＮＮＥＣＴ  Ｓａ１．Ａ：４４３  ＨＴＴＰ／１．０」の要求を受ける。この場合、ゲートウェイ「Ｎ１」（３０−１）は、プライベート網「Ａ」内のＤＮＳサーバに問い合わせ、プライベート網内のサーバのドメイン名「Ｓａ１．Ａ」のアドレスを取得し、ドメイン名「Ｓａ１．Ａ」のポート番号「４４３番」に接続する。ゲートウェイ「Ｎ１」（３０−１）は、接続が完了した後、端末「Ｕ」（１０）に応答を返す。この後、ゲートウェイ「Ｎ１」（３０−１）は、端末「Ｕ」（１０）とドメイン名「Ｓａ１．Ａ」の間で、ＳＳＬのネゴシエーションを行ってから、ＨＴＴＰの通信を行う。
【００４４】
なお、ステップＳ４０１において、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、プライベート網「Ａ」内の外部に公開する全てのサーバをゲートウェイ「Ｎ１」（３０−１）のアドレスとしてＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に登録することにより、問い合わせを集中管理するようにしても良い。
【００４５】
また、ステップＳ４０２において、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、ドメイン名「Ｓａ１．Ａ」へのコア網側からの問い合わせに対し、応答として、ドメイン名解決に失敗した旨と共に、ＴＬＤ「．ｐｒｏｘｙ」を通知するようにしても良い。このとき、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、通知対象として予め登録されている端末「Ｕ」（１０）にのみ、前述の通知を行うようにしても良い。これにより、端末「Ｕ」（１０）は、ＴＬＤ「．ｐｒｏｘｙ」を取得し、ドメイン名「Ｓａ１．Ａ」にＴＬＤ「．ｐｒｏｘｙ」を付加できるようになる。
【００４６】
＜本発明の第２実施形態＞
以下に、本発明の第２実施形態について説明する。
図５を参照して、プライベート網「Ｂ」内のサーバ「Ｓｂ１」（２２−１）がプライベート網「Ａ」内のサーバ「Ｓａ１」（２１−１）に接続する場合を示す。この場合、サーバ「Ｓｂ１」（２２−１）は、第１実施形態における端末「Ｕ」（１０）に相当する。なお、ゲートウェイ「Ｎ２」（３０−２）は、プライベート網「Ｂ」からコア網「Ｇ」に接続するためのＮＡＴサーバとして動作している。
【００４７】
（１）ステップＳ５０１
ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、プライベート網「Ａ」内のサーバを外部に公開するために、プライベート網「Ａ」のドメイン名のゲートウェイが登録できるように、ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に登録する。例えば、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、プライベート網「Ａ」内の外部に公開する全てのサーバのドメイン名にＴＬＤを付加したドメイン名を、ゲートウェイ「Ｎ１」（３０−１）のアドレスと紐付けして、ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に登録する。これにより、ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）は、プライベート網「Ａ」内の外部に公開する全てのサーバのドメイン名にＴＬＤが付加されたドメイン名への問い合わせに対し、ゲートウェイ「Ｎ１」（３０−１）のアドレスを応答できるようになる。但し、実際には、これらの例に限定されない。
【００４８】
（２）ステップＳ５０２
サーバ「Ｓｂ１」（２２−１）は、プライベート網「Ａ」内のサーバのドメイン名「Ｓａ１．Ａ」に接続する際、ＤＮＳサーバ「ＤＮＳ  Ｂ」（４０−２）を介して、ドメイン名解決を行う。ここでは、サーバ「Ｓｂ１」（２２−１）は、ＤＮＳサーバ「ＤＮＳ  Ｂ」（４０−２）を介して、コア網内のルートサーバ（ｒｏｏｔ）であるＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）に対して、ドメイン名「Ｓａ１．Ａ」の問い合わせを行う。ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）は、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）に、ドメイン名「Ｓａ１」の問い合わせを転送する。このとき、ＤＮＳサーバ「ＤＮＳ  Ａ」（４０−１）は、ドメイン名「Ｓａ１．Ａ」への問い合わせには応答しない。従って、サーバ「Ｓｂ１」（２２−１）は、ドメイン名「Ｓａ１．Ａ」のドメイン名解決に失敗する。
【００４９】
（３）ステップＳ５０３
サーバ「Ｓｂ１」（２２−１）は、ドメイン名「Ｓａ１．Ａ」のドメイン名解決に失敗した場合、ドメイン名「Ｓａ１．Ａ」にＴＬＤ「．ｐｒｏｘｙ」を付加し、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」のドメイン名解決を行い、ゲートウェイ「Ｎ１」（３０−１）のアドレスを取得する。このとき、サーバ「Ｓｂ１」（２２−１）は、ＤＮＳサーバ「ＤＮＳ  Ｂ」（４０−２）を介して、コア網内の各ＤＮＳサーバに対して、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを行う。例えば、サーバ「Ｓｂ１」（２２−１）は、ＤＮＳサーバ「ＤＮＳ  Ｂ」（４０−２）を介して、ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）に対して、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを行う。ＤＮＳサーバ「ＤＮＳ  Ｒ」（４０−５）は、ＴＬＤ「．ｐｒｏｘｙ」を管理するＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）に、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせを転送する。ＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）は、ドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせに対して、ゲートウェイ「Ｎ１」（３０−１）のアドレスを応答する。これにより、サーバ「Ｓｂ１」（２２−１）は、ゲートウェイ「Ｎ１」（３０−１）のアドレスを取得する。
【００５０】
（４）ステップＳ５０４
サーバ「Ｓｂ１」（２２−１）は、ゲートウェイ「Ｎ１」（３０−１）をドメイン名「Ｓａ１．Ａ」へのＨＴＴＰプロキシとして接続する。このとき、ゲートウェイ「Ｎ１」（３０−１）は、ＨＴＴＰプロキシ用にポート番号「８０８０番」を固定で使うこととする。ここでは、サーバ「Ｓｂ１」（２２−１）は、ゲートウェイ「Ｎ１」（３０−１）のポート番号「８０８０番」に接続し、ＨＴＴＰのリクエストを送信する。
【００５１】
（５）ステップＳ５０５
ゲートウェイ「Ｎ１」（３０−１）は、サーバ「Ｓｂ１」（２２−１）からのＨＴＴＰリクエストに従い、サーバ「Ｓａ１」（２１−１）に接続し、ＨＴＴＰを中継する。
【００５２】
図５において、ゲートウェイ「Ｎ２」（３０−２）は、ＨＴＴＰプロキシでも良い。すなわち、ゲートウェイ「Ｎ２」（３０−２）が、ＴＬＤ「．ｐｒｏｘｙ」を管理するＤＮＳサーバ「ＤＮＳ  Ｐ」（４０−４）と同じ役割を担うようにする。この場合、サーバ「Ｓｂ１」（２２−１）は、ゲートウェイ「Ｎ２」（３０−２）に、ＨＴＴＰプロキシとして接続する。ゲートウェイ「Ｎ２」（３０−２）は、サーバ「Ｓｂ１」（２２−１）から受け取ったドメイン名「Ｓａ１．Ａ．ｐｒｏｘｙ」の問い合わせが、ドメイン名「Ｓａ１．Ａ」への接続要求であることを知る。これ以降、ゲートウェイ「Ｎ２」（３０−２）及びゲートウェイ「Ｎ１」（３０−１）は、サーバ「Ｓｂ１」（２２−１）とサーバ「Ｓａ１」（２１−１）の間で、ＨＴＴＰ通信の中継を行う。
【００５３】
なお、本発明におけるＴＬＤは、共通の文字列であれば良く、「．ｐｒｏｘｙ」に限定されない。すなわち、「．ｐｒｏｘｙ」は、ＴＬＤの一例に過ぎない。ＴＬＤは、既存のドメイン名と重複しない文字列であると好適である。
【００５４】
ここでは、ＨＴＴＰ及びＨＴＴＰＳ（ＨＴＴＰ  ｏｖｅｒ  ＴＬＳ／ＳＳＬ）による通信を例に説明しているが、実際には、ＩＰアドレスを使用する他のプロトコルによる通信に対しても、本発明は適用可能である。他のプロトコルの例として、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）／ＰＯＰ（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ）、ＳＭＢ（Ｓｅｒｖｅｒ  Ｍｅｓｓａｇｅ  Ｂｌｏｃｋ）、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）等が考えられる。但し、実際には、これらの例に限定されない。
【００５５】
以上のように、本発明は、１つのコア網と複数のプライベート網がゲートウェイを介して接続する環境において、プライベート網のサーバに接続することを可能とする技術に関する。
【００５６】
本発明は、ゲートウェイのコア網側のアドレスを１つに集約することと、ＨＴＴＰ及びＨＴＴＰＳ（ＨＴＴＰ  ｏｖｅｒ  ＴＬＳ／ＳＳＬ）によるプライベート網のサーバとの通信を実現することを主な目的とする。
【００５７】
上記目的を達成するために、本発明にかかる端末は、目的のサーバのドメイン名解決を行い、探索結果が得られない場合に、目的のサーバに中継するゲートウェイのドメイン名解決を行う。本発明では、ゲートウェイのドメイン名解決を行うために、目的のサーバのドメイン名の最後に、専用のＴＬＤ（Ｔｏｐ  Ｌｅｖｅｌ  Ｄｏｍａｉｎ）を付加する。端末は、ゲートウェイのドメイン名解決が成功した場合、ゲートウェイへの接続手順でゲートウェイに接続し、ゲートウェイに対して、目的のサーバへの接続要求を行う。
【００５８】
このように、本発明の動的ゲートウェイ探索システムでは、既存のドメイン名に対する特定の機能を問い合わせるため付加するトップレベルドメインを管理する。
【００５９】
また、本発明の動的ゲートウェイ探索システムでは、プライベート網内に接続するために使うゲートウェイの名前解決を目的としたトップレベルドメインを管理する。
【００６０】
また、本発明の動的ゲートウェイ探索システムでは、既存のドメイン名の名前解決が失敗した場合に、ＨＴＴＰクライアント端末が、ＨＴＴＰプロキシサーバの名前解決を行う。
【００６１】
本発明によれば、従来のドメイン名解決の手順を用いて、端末が目的のサーバに接続するためのゲートウェイの有無を検出できるので、ＮＡＴ方式を用いた場合のように、コア網側のアドレスを消費せず、ＳＳＬの暗号化に対応でき、既存のＤＮＳシステムが利用でき、端末のゲートウェイデータベースに依存する必要がない。
【００６２】
また、本発明では、ＮＡＴ方式とは異なり、ゲートウェイのアドレスを消費しない。その理由は、本発明では、プライベート網内のサーバに対応したアドレスをゲートウェイに持たせる代わりに、ゲートウェイでコネクションを一旦終端するためである。
【００６３】
また、本発明では、仮想ホスト方式とは異なり、ＳＳＬの暗号化に対応できる。その理由は、仮想ホスト方式は、端末に対してゲートウェイが本物のサーバのように振舞うため証明書の送信で問題が起こるが、本発明では、端末がゲートウェイをゲートウェイとして正しく認識しているため、暗号化の場合は接続の中継をゲートウェイに要求することができるからである。
【００６４】
また、本発明では、ＴＬＳ拡張を用いた仮想ホスト方式とは異なり、大規模なプライベート網に対応できる。その理由は、ゲートウェイと多数のプライベート網内のサーバがＴＬＳに使うポート番号を合わせなければならないが、本発明では、ゲートウェイがサーバに中継する際にポート番号を変換することができるからである。
【００６５】
また、本発明では、既存のＤＮＳの変更が要らない。その理由は、本発明では、専用のＴＬＤを追加する方式であるため、ＤＮＳに特別のリソースレコードを追加する必要がなく、端末のドメイン名解決機構のＡＰＩへの変更が要らないからである。
【００６６】
また、本発明では、端末上のゲートウェイ管理データベースの管理が要らない。その理由は、本発明では、必要に応じてゲートウェイの有無をＤＮＳを使って問い合わせるからである。
【００６７】
本発明では、オペレータのコア網が拡大した場合に、既存のＩＰシステムを変更せずに移行することができる。更に、本発明は、インターネットでＩＰｖ４アドレスが枯渇した場合に適用できる。
【００６８】
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【図面の簡単な説明】
【００６９】
【図１】図１は、複数のプライベート網が接続したコア網側からプライベート網側のサーバに接続するイメージ図である。
【図２】図２は、ＮＡＴ方式の課題を説明するための図である。
【図３】図３は、ＨＴＴＰ仮想ホスト方式の課題を説明するための図である。
【図４】図４は、本発明の第１実施形態の動作原理を説明するための図である。
【図５】図５は、本発明の第２実施形態の動作原理を説明するための図である。
【符号の説明】
【００７０】
１０…  コア網上の端末「Ｕ」
２０−ｉ（ｉ＝１〜４）…  コア網上のサーバ「Ｓｇ１〜４」、
２１−ｉ（ｉ＝１〜３）…  プライベート網上のサーバ「Ｓａ１〜３」
２２−ｉ（ｉ＝１〜３）…  プライベート網上のサーバ「Ｓｂ１〜３」
２３−ｉ（ｉ＝１〜３）…  プライベート網上のサーバ「Ｓｃ１〜３」
３０−ｉ（ｉ＝１〜３）…  ゲートウェイ「Ｎ１〜３」
４０−１…  ＤＮＳサーバ「ＤＮＳ  Ａ」
４０−２…  ＤＮＳサーバ「ＤＮＳ  Ｂ」
４０−３…  ＤＮＳサーバ「ＤＮＳ  Ｌ」
４０−４…  ＤＮＳサーバ「ＤＮＳ  Ｐ」
４０−５…  ＤＮＳサーバ「ＤＮＳ  Ｒ」
【図１】
2010130604.tif 000003
【図２】
2010130604.tif 000004
【図３】
2010130604.tif 000005
【図４】
2010130604.tif 000006
【図５】
2010130604.tif 000007