JP2015220483A - ＤＮＳ−Ｐｒｏｘｙ機能を有する中継装置 - Google Patents

Abstract

【課題】デュアルスタック環境で使用される中継装置におけるＤＮＳの名前の解決において、サーバへの問い合わせ回数を減らし、端末側で体感される応答速度を向上させる。【解決手段】ＩＰｖ４及びＩＰｖ６のうちの一方のＤＮＳクエリをＬＡＮ側から受信すると、ＷＡＮ側のＤＮＳサーバへ中継するとともに、上記ＤＮＳクエリに対応するＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを生成して上記ＤＮＳサーバへ送信し、返答を受け取って名前の解決がされた上記他方のＩＰアドレスを保持し、ＬＡＮ側からＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを受信したら、上記ＩＰアドレスをＤＮＳレスポンスとして返答する中継装置を用いる。【選択図】図４

Description

この発明は、ホームゲートウェイなどに用いられる中継装置に関する。

インターネットに接続する端末の利用者はほとんどの場合、通信するサーバのアドレスを、ＩＰアドレスではなくドメイン名（ＦＱＤＮ：Fully Qualified Domain Name）で指定する。ＦＱＤＮで指定されたアドレスは、ＤＮＳサーバに問い合わせて名前の解決を行い、得られたＩＰアドレス（ＩＰｖ４、ＩＰｖ６）によって、当該ＩＰアドレスのサーバと通信する。現在のインターネットはＩＰｖ４アドレスとＩＰｖ６アドレスが混在しており、端末がＤＮＳサーバに送信する問い合わせであるクエリにはＩＰｖ６／ＡＡＡＡクエリとＩＰｖ４／Ａクエリとがある。

また、一般家庭や小規模事業者では、端末を直接にインターネットに接続するのではなく、ＷＡＮとの間にホームゲートウェイとなる中継装置を設けて、その中継装置によって区切られたＬＡＮに接続し、上記中継装置を介してインターネットへ接続することが一般的である。ＤＮＳの名前の解決にあたっても、端末はＷＡＮ上のＤＮＳサーバに直接接続するのではなく、ＤＮＳプロキシとして動作する上記中継装置にＤＮＳクエリを送ることがある。この場合、上記中継装置は端末からのＤＮＳクエリをｐｒｏｘｙしてＤＮＳサーバへ送り、名前の解決が出来ればＩＰアドレスを、出来なければＮｏＳｕｃｈＮａｍｅを端末に返送する。

しかし、ＩＰｖ４アドレスとＩＰｖ６アドレスが混在している現在は、それらのうちのどちらかでしか接続できないケースがある。そのため、接続できない方で接続を試みた場合、一旦問い合わせや通信などに失敗するため、待ち時間が発生したり、タイムアウトしてエラーが起こる可能性がある。こういったユーザが感じる不利益を無くすため、種々の方法によりデュアルスタック問題の解決や影響の低減が試みられている。

例えば、特許文献１には、ＤＮＳクエリに対するＤＮＳレスポンスを受け取った中継装置が、名前の解決がされたアドレスに対して実際に通信を試みて、実際に応答が得られたアドレスのみを端末に返すことで、エラーを抑制する方法が記載されている。

特開２０１３−１９２１５６号公報

しかしながら、特許文献１のアプローチによると、端末側で体感する応答の確実性は確保できるものの、サーバへの問い合わせ回数が増え、待ち時間が生じることがあった。

そこでこの発明は、デュアルスタック環境で使用される中継装置におけるＤＮＳの名前の解決において、サーバへの問い合わせ回数を減らし、端末側で体感される応答速度を向上させることを目的とする。

この発明は、
ＩＰｖ４及びＩＰｖ６のうちの一方のＤＮＳクエリをＬＡＮ側から受信すると、ＷＡＮ側のＤＮＳサーバへ中継するとともに、上記ＤＮＳクエリに対応するＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを生成して上記ＤＮＳサーバへ送信し、返答を受け取って名前の解決がされた上記他方のＩＰアドレスを保持し、
ＬＡＮ側からＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを受信したら、上記ＩＰアドレスをＤＮＳレスポンスとして返答する中継装置により、上記の課題を解決したのである。

すなわち、上記一方のクエリ（例えばＩＰｖ６／ＡＡＡＡ）では名前の解決ができなかった場合、待ち時間経過後に、端末は上記他方のクエリ（例えばＩＰｖ４／Ａ）を改めて送出することになる。従来であればこの上記他方のクエリを受信した中継装置は改めてＤＮＳサーバへクエリを中継することになるが、上記一方のクエリを受信した段階で、上記他方のＤＮＳクエリをＤＮＳサーバに送出していれば、この段階で既にＤＮＳサーバからのＤＮＳレスポンスが返ってきており、速やかに端末へ上記他方のクエリに対するレスポンスを返すことができる。

具体的には、次のような構成によりこの発明を実現できる。
ＬＡＮ側とＷＡＮ側とにインターフェースを有し、ＤＮＳクエリ及びＤＮＳレスポンスを中継するＤＮＳ−ｐｒｏｘｙ部を有する中継装置であって、
ＩＰｖ４及びＩＰｖ６のうちの一方のＤＮＳクエリを受信すると、当該ＤＮＳクエリとはＩＰのバージョンが異なるＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを生成して上記ＤＮＳ−ｐｒｏｘｙ部へ渡すＤＮＳクエリ変換部を有し、
上記ＤＮＳ−ｐｒｏｘｙ部は、
上記の他方のＤＮＳクエリに対するＤＮＳサーバからのＤＮＳレスポンスの内容を一時的に記憶部に保持する生成返答一時保持手段と、
上記他方のＤＮＳクエリとドメインとＩＰのバージョンが同じであるＤＮＳクエリを受信すると、上記生成返答一時保持手段で保持していたＤＮＳレスポンスの内容を、送信元アドレスへと返答するレスポンス即応手段とを実行する
中継装置である。

さらに、第二の発明として、上記の構成に加えて
過去にＤＮＳサーバに名前の解決を問い合わせたドメイン名について、ＩＰｖ４とＩＰｖ６のいずれかでの名前の解決の結果を記録するＤＮＳ問合履歴保持部を有し、
上記ＤＮＳ−ｐｒｏｘｙ部が、
ＬＡＮ側から受信したＤＮＳクエリについて上記ＤＮＳ問合履歴保持部を検索して、そのＤＮＳクエリのドメインについて該当するＩＰバージョンで名前の解決ができなかったか否かの履歴の有無を得る、履歴結果判断手段と、
上記履歴結果判断手段により、当該ドメイン名及び当該ＩＰバージョンのＤＮＳクエリでは名前の解決ができなかった履歴が得られれば、当該ＤＮＳクエリに対するＮｏＳｕｃｈＮａｍｅの返答を送信元アドレス宛に生成する履歴返答即応手段とを実行する
中継装置とすると、ＤＮＳサーバへの無駄な問い合わせの結果を待つことなく、好適なバージョンでのＤＮＳクエリの送出に切り替えることができるので、端末の体感レスポンスが向上する。

この発明にかかる中継装置を用いることにより、履歴が無い場合でもバージョン違いのＩＰアドレスについてのＤＮＳサーバへの問い合わせを端末からの要求に先んじて行っているため、端末が改めてＤＮＳクエリを送出したとき、ＤＮＳサーバまでの問い合わせを行うまでもなく、中継装置から即座にＤＮＳレスポンスを返すことができるので、端末が体感する即応性が向上する。

また、履歴を用いると、当該バージョンのＩＰアドレスについてはＤＮＳサーバに問い合わせても無駄な通信になることが予めわかり、これを送出することなく即座に端末に対して回答できない旨を回答できるので、ネットワーク負荷を軽減させるとともに、バージョン違いでのＤＮＳクエリの送出を端末に早めさせる効果があり、これによっても即応性が向上する。

この発明にかかる中継装置の機能ブロックと、周囲とのネットワーク構成を示すブロック図 （ａ）、（ｂ）ＤＮＳ問合履歴保持部の例を示すテーブル この発明にかかる中継装置をＩＰｖ６優先で使用したときのフロー例図 図３のフロー例図の続き この発明にかかる中継装置が端末からの問合と同じバージョンで履歴を保持していた際のシーケンス例図 この発明にかかる中継装置が端末からの問合に該当するドメインの履歴を保持していない際のシーケンス例図 この発明にかかる中継装置が端末からの問合と異なるバージョンで履歴を保持していた際のシーケンス例図 図７のシーケンスにおいて名前の解決に失敗した際のシーケンス例図

以下、この発明について詳細に説明する。
この発明にかかる中継装置１１の機能ブロック図と、ＬＡＮ１３側の端末１２、ＷＡＮ１６側のＤＮＳサーバ１４、ＷＥＢサーバ１５との関係図を図１に示す。

ＬＡＮ１３側には端末１２がある。ＬＡＮ１３は例えば家庭内ネットワークや小規模事業者内ネットワークなど、大規模通信事業者やプロバイダと契約する個人などが管理するネットワークである。端末１２は、パソコンやスマートフォンなどのＬＡＮ接続可能な端末であり、中継装置１１を通じてＷＡＮ１６と接続する。

ＷＡＮ１６は、通信事業者ネットワークやインターネットなどであり、プロバイダや通信事業者が管理するＤＮＳサーバ１４が少なくとも一基、中継装置１１から接続可能に設けられてある。また、ＤＮＳの名前を解決することにより端末１２がアクセスしようとするＷＥＢサーバ１５も設置されている。

中継装置１１は、ＬＡＮ側ネットワークインターフェースとＷＡＮ側ネットワークインターフェースを有し、端末１２によるＷＡＮ１６との通信を中継する。ＤＮＳに関する名前の解決だけでなく、ＤＨＣＰサーバなどの一般的ルータ機能を兼ね備えたホームゲートウェイであってもよい。その場合は、中継装置１１には図示しないその他の機能を兼ね備える。また、中継装置１１は、演算処理を行う制御部と、データを記憶するメモリである記憶部２５を有し、これらの環境で実行されるソフトウェア又はハードウェアとして、下記のＤＮＳ−ｐｒｏｘｙ部２１を始めとする機能を実行する。

上記の記憶部２５は揮発性メモリでも不揮発性メモリでもよいが、後述するＤＮＳ問合履歴保持部２３の記録を一定時間保持できるものである必要がある。

ＤＮＳ−Ｐｒｏｘｙ部２１は、ＬＡＮ１３側の端末１２からのＤＮＳクエリを受け付けてＤＮＳレスポンスを返すＤＮＳサーバ機能４１と、当該ＤＮＳクエリをＤＮＳサーバ１４に送出してＤＮＳレスポンスを受け取るＤＮＳリゾルバ機能４２とを基本機能として有する。

また、中継装置１１は、ＤＮＳ−ｐｒｏｘｙ部２１が受け取ったＩＰｖ４及びＩＰｖ６のうちの一方のＤＮＳクエリについて、ＩＰのバージョンが異なるＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを生成するＤＮＳクエリ変換部２２を有する。ＩＰのバージョンが異なるＤＮＳクエリを生成するとは、すなわち、受け取ったＤＮＳクエリがＩＰｖ６であれば、ＩＰｖ４のＤＮＳクエリを生成し、受け取ったＤＮＳクエリがＩＰｖ４であれば、ＩＰｖ６のＤＮＳクエリを生成することを意味する。この中継装置１１が生成した他方のＩＰのバージョンのＤＮＳクエリを下記で「生成ＤＮＳクエリ」と呼ぶことがある。この生成ＤＮＳクエリはＤＮＳ−ｐｒｏｘｙ部２１に渡され、ＤＮＳ−ｐｒｏｘｙ部２１は上記ＤＮＳリゾルバ機能４２に従い、ＤＮＳサーバ１４に送る。

ただし、上記生成ＤＮＳクエリに対するＤＮＳレスポンスがＤＮＳサーバ１４から返ってきたら、中継装置１１のＤＮＳ−ｐｒｏｘｙ部２１は、その内容を一時的に上記記憶部２５に保持する生成返答一時保持手段３１を実行する。上記生成ＤＮＳクエリは端末１２から送出されたものではないため、この段階で端末１２に送っても意味はなく、同じ内容のＤＮＳクエリが端末１２から送信されて来るまで待機する必要があるからである。

一方で、上記の生成ＤＮＳクエリに対する応答と並行して、元のＤＮＳクエリに対するＤＮＳレスポンスがＤＮＳサーバ１４から返ってくる。これを受けたＤＮＳ−ｐｒｏｘｙ部２１はＤＮＳサーバ機能４１として、元のＤＮＳクエリを送信した端末１２宛にこのＤＮＳレスポンスを返答する。このＤＮＳレスポンスによって名前の解決がされれば、端末１２はそのままそのアドレスを使ってＷＥＢサーバ１５にアクセスすることができる。しかし、このＤＮＳレスポンスがＮｏＳｕｃｈＮａｍｅであったり、通知されたＩＰアドレスでは直接に接続できなかったりするなどの理由により、ＷＥＢサーバ１５へのアクセスが出来ない場合は、端末１２は改めて、ＩＰのバージョンが異なるＤＮＳクエリを中継装置１１に送信することになる。例えば、ＩＰｖ６でのＤＮＳクエリで名前の解決が出来なかった場合には、改めてＩＰｖ４でのＤＮＳクエリを送信することになる。

これに対して、中継装置１１のＤＮＳ−ｐｒｏｘｙ部２１は、上記他方のＩＰのバージョンのＤＮＳクエリ（生成ＤＮＳクエリ）と、ドメイン名及びＩＰのバージョンが同じであるＤＮＳクエリを受信すると、上記生成返答一時保持手段３１で保持していたＤＮＳレスポンスの内容を、送信元アドレスである端末１２へと返答するレスポンス即応手段３２とを実行する。保持していた結果を即座に返すため、改めてＤＮＳサーバ１４に問い合わせてその返答を待つ必要がなく、端末１２に対して速やかに名前の解決を提供することができる。なお、改めて送られてきたＤＮＳクエリについては、改めてＤＮＳサーバ１４へ中継する必要はない。

さらに、中継装置１１は、上記のＤＮＳリゾルバ機能４２やＤＮＳクエリ変換部２２の実行を管理するために、個々に問い合わせたドメインについて、ＩＰｖ４及びＩＰｖ６のいずれか一方、又は両方で解決できたかを記録する、ＤＮＳ問合履歴保持部２３を有していると好ましい。具体的には、記憶部２５の中に、図２（ａ）や図２（ｂ）のようなテーブルを有するとよい。ここで、最低限記録するのは管理番号と、ドメイン名、いずれのバージョンのＩＰで名前の解決に失敗したかの情報である。なお、図２（ｂ）に記載のように、「ＩＰｖ４」と「ＩＰｖ６」との異なる単独のＩＰのバージョンのそれぞれについて、名前の解決に失敗したＩＰのバージョン（図中「×」で表示）だけでなく、名前の解決に成功したＩＰのバージョン（図中「○」で表示）も記録しておくと、複数の端末１２が存在する場合には、それぞれの端末１２が優先的に用いるＩＰのバージョンが異なっている場合でも処理を適切に行えるためより好ましい。なお、図中「―」はまだ成功や失敗の記録が無い状態である。ただし、具体的なＩＰアドレスをキャッシュして応答に用いようとすると、ＩＰアドレスの変更や負荷分散のためのＩＰアドレスの分配に対応しきれないため、ＩＰアドレスのキャッシュは使用しない方がよい。名前の解決に失敗したＩＰのバージョンとして、端末１２が優先的に用いるＩＰのバージョンが登録されてあれば、最初のＤＮＳクエリで応答が得られず名前の解決に失敗してＤＮＳクエリを送信し直す必要があったことを意味する。名前の解決に失敗したＩＰのバージョンとして、両方のＩＰのバージョンが登録されていれば、新たにバージョンを変更して送信し直したＤＮＳクエリでも名前の解決ができなかったことを意味する。

ＤＮＳ問合履歴保持部２３のレコード数は記憶部２５の容量次第であるが、多すぎると処理が滞り、また、状況が変化して履歴が役に立たなくなることがあるため、適宜古いレコードを削除することが好ましい。例えば、件数に上限を設けて超過した分は古いレコードから順に削除したり、図２のテーブルにさらに問合した日時を記録するレコードとして、一定の保持期間を超過したものから削除するといった方式が挙げられる。

ＤＮＳ−ｐｒｏｘｙ部２１は、これらのレコードからなるテーブルに対し、ＮｏＳｕｃｈＮａｍｅであるＤＮＳレスポンスがＤＮＳサーバ１４から返ってきたタイミングで、その結果をテーブルに書き込む履歴登録手段３３を実行する。

中継装置１１がこのＤＮＳ問合履歴保持部２３を有する場合、ＤＮＳ−ｐｒｏｘｙ部２１は、名前の解決ができないＩＰのバージョンでのＤＮＳクエリに対して、速やかにＮｏＳｕｃｈＮａｍｅを返すことができる。具体的にはまず、ＤＮＳ−ｐｒｏｘｙ部２１は、ＬＡＮ１３側の端末１２から受信したＤＮＳクエリについてＤＮＳ問合履歴保持部２３を検索して、そのＤＮＳクエリのＩＰバージョンで名前の解決に失敗した履歴の有無を得る履歴結果判断手段３４を実行する。これにより、当該ドメイン名及び当該ＩＰのバージョンのＤＮＳクエリでは名前の解決ができなかった旨の履歴が得られれば、当該ＤＮＳクエリに対するＮｏＳｕｃｈＮａｍｅの返答を送信元アドレス宛に生成する履歴返答即応手段３５を実行する。これにより、端末１２はＤＮＳサーバ１４までの問い合わせにかかる時間を省略して、当該バージョンのＩＰではアクセスできないことを検知し、別バージョンのＩＰでのＤＮＳクエリ送信に切り替えることができる。

中継装置１１の全体の処理としては、ＤＮＳクエリを受信したら、これらの履歴結果判断手段３４及び履歴返答即応手段３５と並行して、当該ＤＮＳクエリに対応した生成ＤＮＳクエリを生成する生成返答一時保持手段３１も実行する。この生成ＤＮＳクエリを予めＤＮＳサーバ１４に送出しておくことにより、上記の履歴返答即応手段３５による応答後に端末１２が送出してきたバージョン違いのＤＮＳクエリに対して、速やかなＤＮＳレスポンスの応答が可能となる。

この発明にかかる中継装置１１を実施した際の動作フローの例を、図３を用いて説明する。仮に、中継装置１１のＬＡＮ１３側にある端末１２は、ＩＰｖ６を優先的に使用する設定になっているとする。

最初に、ＬＡＮ１３側のインターフェースからＤＮＳクエリを受信する（Ｓ１０１）。初期設定から、ＩＰｖ６のＤＮＳクエリであるとする。ここで履歴結果判断手段３４を実行して、当該ＤＮＳクエリに含まれるドメインについてのレコードがＤＮＳ問合履歴保持部２３にあるか否かを検索する（Ｓ１０２）。無ければＳ１１１へ、有ればＳ１３１（以降のフローは図４で説明。）へ進む。なお、ＤＮＳ問合履歴保持部２３自体を有しない場合は当然にＳ１１１以降のフローとなる。

レコードが無い場合から説明する（Ｓ１０２−履歴無）。ＤＮＳ−ｐｒｏｘｙ部２１はＤＮＳリゾルバ機能４２を実行して、ＤＮＳサーバ１４に受信したＤＮＳクエリと同じバージョンのＤＮＳクエリを送信する（Ｓ１１１）。これと並行して、ＤＮＳクエリ変換部が、当該ＤＮＳクエリ（ここではＩＰｖ６）とＩＰのバージョンの異なる生成ＤＮＳクエリ（ここではＩＰｖ４）を生成する（Ｓ１１２）。この生成ＤＮＳクエリも、ＤＮＳ−ｐｒｏｘｙ部２１のＤＮＳリゾルバ機能４２によりＤＮＳサーバ１４へ送信する（Ｓ１１３）。

先に送信したＤＮＳクエリに対するＤＮＳレスポンスが返ってきたら、そのＤＮＳレスポンスで名前の解決がされているか否かを判断する（Ｓ１１４）。名前の解決がされていたら（Ｓ１１４−名前解決完了）、端末１２にＤＮＳレスポンスを返して名前の解決が図られる（Ｓ１１５）。

一方、ＤＮＳレスポンスで名前の解決がされていなければ（Ｓ１１４−名前解決未完）、履歴登録手段３３を実行してＤＮＳ問合履歴保持部２３へ、当該ＤＮＳレスポンスで解決しようとするドメイン名が当該バージョンのＩＰ（ここではＩＰｖ６）で名前の解決に失敗した旨を登録した上で（Ｓ１２０）、端末１２に対してＮｏＳｕｃｈＮａｍｅを返却する（Ｓ１２１）。これに対して端末１２は新たに別バージョンのＩＰによるＤＮＳクエリ（ここではＩＰｖ４）を生成して送信してくるが、それと前後するタイミングで、先の生成ＤＮＳクエリ（ここではＩＰｖ４）に対する返答がＤＮＳサーバ１４から返ってくる（Ｓ１２２）。この結果がＮｏＳｕｃｈＮａｍｅで名前の解決がされていなければ、履歴登録手段３３を実行してＤＮＳ問合履歴保持部２３へ、当該ＤＮＳレスポンスで解決しようとするドメイン名が当該バージョンのＩＰ（ここではＩＰｖ４）で名前の解決に失敗した旨を登録する（Ｓ１２３）。

なお、Ｓ１２２で受け取るべきＤＮＳサーバからのＤＮＳレスポンスが、ＤＮＳクエリ送信からタイムアウトするまで返ってこない場合は、履歴には特に記録することなく、端末１２へタイムアウトを通知する（図示せず）。

上記の生成ＤＮＳクエリに対するＤＮＳレスポンスを受信した（Ｓ１２２）の段階で、既にＬＡＮ１３側の端末１２から、別バージョンのＩＰによるＤＮＳクエリ（ここではＩＰｖ４）を受信していれば（Ｓ１２４−Ｙｅｓ）、このＤＮＳレスポンスの内容を速やかに端末１２へ送信するレスポンス即応手段３２を実行する（Ｓ１１５）。既にＳ１２２で名前の解決がされたＤＮＳレスポンスを受け取っていたのであれば、これにより端末１２はＤＮＳサーバ１４のさらなる返答を待たずに名前の解決ができる。また、名前の解決がされなかったＤＮＳレスポンスを受け取っていた場合も、端末１２は同じくＤＮＳサーバ１４のさらなる返答を待たずに、ＮｏＳｕｃｈＮａｍｅである情報を速やかに得ることができる。

Ｓ１２２の段階でまだ別バージョンのＩＰによるＤＮＳクエリ（ここではＩＰｖ４）を受信していなければ（Ｓ１２４−Ｎｏ）そのＤＮＳレスポンスの内容を一時的に記憶部２５に保持する生成返答一時保持手段３１を実行する（Ｓ１２５）。規定の時間が経過するまで待機し、待機時間中に端末１２から別バージョンのＩＰによるＤＮＳクエリ（ここではＩＰｖ４）を受信すれば（Ｓ１２６−Ｙｅｓ）、ＤＮＳレスポンスの内容を速やかに端末１２へ送信するレスポンス即応手段３２を実行する（Ｓ１１５）。規定時間が経過しても端末１２からの同一ドメインに対する別バージョンのＤＮＳクエリが送信されてこなければ、ＤＮＳレスポンスの内容を破棄する（Ｓ１２７）。

次に、履歴結果判断手段３４においてＤＮＳ問合履歴保持部２３に、当該ＤＮＳクエリに対応する、レコードが存在する場合について図４を用いて説明する（Ｓ１０２−履歴有→Ｓ１３１）。この履歴が、当該ＤＮＳクエリとは異なるバージョンのＩＰについてのみ名前の解決が失敗した旨の記録（ここでは「ＩＰｖ４」）となっていれば（Ｓ１３１−ＩＰｖ４／Ａのみ）、少なくとも当該ＤＮＳクエリのバージョン（ここでは「ＩＰｖ６」）による問い合わせでは、名前の解決に失敗していないことを意味する。これは、先に成功している場合と、未だ問い合わせを行っていない場合の両方が考えられる。このいずれの場合であっても、当該ＤＮＳクエリのバージョンでのＤＮＳサーバ１４への問い合わせは行うべきであるので、当該ＤＮＳクエリをそのままＤＮＳサーバ１４へ送信する（Ｓ１３２）。ＤＮＳサーバ１４からＤＮＳレスポンスが返ってきたら（Ｓ１３３）、名前の解決がされているか否かを確認する。名前の解決に失敗していたら、当該ドメインについて当該バージョンでの問い合わせが失敗した旨のレコードを登録するように履歴登録手段３３を実行する（Ｓ１３４）。具体的には、問い合わせのあったバージョン（ここではＩＰｖ６）をレコードに追記する。このようなレコードはＩＰｖ４とＩＰｖ６のどちらでもアクセスできないことを意味する。一方、問い合わせが成功していたら、当該レコードについて上書き登録するように履歴登録手段３３を実行する（Ｓ１３４）。具体的にはタイムアウト時刻を更新したり、削除順を最後に移動したりする。その上で中継装置１１はＤＮＳサーバ機能４１としてＤＮＳレスポンスを端末１２に送信する（Ｓ１３５）。

一方、ＤＮＳ問合履歴保持部２３に記録されている、名前の解決に失敗した履歴のバージョンが、元のＤＮＳクエリと同じバージョンのみ（ここではＩＰｖ６）である場合は（Ｓ１３１−ＩＰｖ６／ＡＡＡＡのみ）、先に行った当該バージョン（ここではＩＰｖ６）のＤＮＳクエリでは名前の解決に失敗したことを意味する。そのため、ＤＮＳサーバ１４にＤＮＳクエリを送るまでもなく、当該ＤＮＳクエリに対するＮｏＳｕｃｈＮａｍｅの返答を端末１２宛に生成する履歴返答即応手段３５を実行し（Ｓ１４１）、ＤＮＳサーバ機能４１によりこれを端末１２へ送信する。これに並行して、ＤＮＳクエリ変換部２２が、元のＤＮＳクエリとはバージョンの異なる（ここではＩＰｖ４）生成ＤＮＳクエリを生成してＤＮＳ−ｐｒｏｘｙ部２１へ渡す（Ｓ１４２）。ＤＮＳ−ｐｒｏｘｙ部２１はＤＮＳリゾルバ機能４２により生成ＤＮＳクエリをＤＮＳサーバ１４へ送信する（Ｓ１４３）。

この後の処理はＳ１２２以降と同様である。生成ＤＮＳクエリに対するＤＮＳサーバ１４からのＤＮＳレスポンスを受けて（Ｓ１４４）保持し、名前の解決ができなかった場合は生成ＤＮＳクエリのバージョンで名前の解決を失敗した旨を履歴に登録する履歴登録手段３３を実行する（Ｓ１４５）。なおＤＮＳレスポンスで名前の解決がされていた場合は当該レコード（ここではＩＰｖ４）について時刻の更新や削除順の移動などの上書き登録を行う。端末１２からのバージョンの違うＤＮＳクエリの出し直し（ここではＩＰｖ４）を受ければ（Ｓ１４６−Ｙｅｓ，Ｓ１４８−Ｙｅｓ）その内容を端末１２に返送する。ただし、こちらのフローではＳ１４１において先にＮｏＳｕｃｈＮａｍｅを端末１２に送信しているため、次のＤＮＳクエリがＳ１４６に間に合う可能性が高くなる。

一方、ＤＮＳ問合履歴保持部２３に記録されている、名前の解決に失敗した履歴が、ＩＰｖ４とＩＰｖ６の両方であった場合は（Ｓ１３１−ＩＰｖ６／ＡＡＡＡ，ＩＰｖ４／Ａ）、端末に当該ＤＮＳクエリのバージョン（ここではＩＰｖ６）でのＮｏＳｕｃｈＮａｍｅのレスポンスを速やかに返す（Ｓ１５１）。さらにその後、端末１２から元のＤＮＳクエリとはバージョンの異なる（ここではＩＰｖ４）ＤＮＳクエリが届いたら（Ｓ１５２）、同じく速やかにＮｏＳｕｃｈＮａｍｅのレスポンスを返す（Ｓ１５３）。いずれの場合もＤＮＳサーバ１４への無駄な問い合わせが発生することなく、端末１２の待ち時間を最少にすることができる。

次に、実施形態のシーケンス図を用いて各状況におけるフローを説明することで、端末１２が得られる待ち時間の短縮効果について説明する。図５のシーケンスではまず、端末１２からＤＮＳクエリが送信される（Ｓ２０１）。ここで図中（１）及び（２）はそれぞれＩＰｖ４とＩＰｖ６のいずれかであることを意味する。仮に（１）がＩＰｖ６であれば、（２）はＩＰｖ４となる。ＤＮＳクエリを受け取った中継装置１１はＤＮＳ問合履歴保持部２３を検索する履歴結果判断手段３４を実行する（Ｓ２０２）。ここで名前の解決に失敗した履歴として（１）が記録されていると、過去に（１）で問い合わせて失敗していることになるため、速やかに端末１２にＮｏＳｕｃｈＮａｍｅを返す履歴返答即応手段３５を実行する（Ｓ２０３）。これに引き続く端末１２からの次のクエリ（Ｓ２０６）を待たずに、ＤＮＳクエリ変換部２２が（２）の生成ＤＮＳクエリを生成し（Ｓ２０４）、（２）の生成ＤＮＳクエリをＤＮＳサーバ１４へ送信する（Ｓ２０５）。この後に端末１２から（２）のＤＮＳクエリが送信されてくる（Ｓ２０６）が、このＤＮＳクエリに対応する内容は既にＳ２０５でＤＮＳサーバ１４に送信済みである。これに前後してＤＮＳレスポンスが返ってくること（Ｓ２０７）で、Ｓ２０５とＳ２０６の間の時間が短縮されて、端末１２へＤＮＳレスポンスが返答される（Ｓ２０８）。

次に、問い合わせたＤＮＳクエリの履歴がＤＮＳ問合履歴保持部２３に無い場合における待ち時間の短縮効果を図６のシーケンス図を用いて説明する。まず端末１２から（１）のＤＮＳクエリが送信される（Ｓ２１１）。ＤＮＳクエリを受け取った中継装置１１はＤＮＳ問合履歴保持部２３を検索する履歴結果判断手段３４を実行する（Ｓ２１２）。ここまでは図５のシーケンス図と同じである。ここで当該ＤＮＳクエリが問い合わせたドメインについてのレコードが存在しないと、中継装置１１は通常のＤＮＳ−ｐｒｏｘｙ部２１の動作としてＤＮＳリゾルバ機能４２を実行してＤＮＳサーバ１４に（１）のＤＮＳクエリをそのまま送信する（Ｓ２１３）。その返答を待つ時間と並行して中継装置はＤＮＳクエリ変換部２２で、（２）の生成ＤＮＳクエリを生成する（Ｓ２１４）。これは、ＤＮＳサーバ１４からの返答を待たずして、先んじて行う。この後にＤＮＳサーバ１４からの（１）のＤＮＳレスポンスが返ってくるが、これがＮｏＳｕｃｈＮａｍｅであった場合（Ｓ２１５）、ＤＮＳ問合履歴保持部２３に（１）での名前の解決が失敗した旨の履歴を登録する履歴登録手段３３を実行した上で（Ｓ２１６）、その内容をＤＮＳサーバ機能４１としてそのまま端末１２に転送する（Ｓ２１７）。このＳ２１５〜Ｓ２１７と前後しうるタイミングで、Ｓ２１４にて生成された（２）の生成ＤＮＳクエリをＤＮＳサーバ１４に送信する（Ｓ２１８）。この後のＳ２１９にて端末１２から送信されてくる（２）のＤＮＳクエリの到着よりも速くＤＮＳサーバ１４に問合をするため、ＤＮＳサーバ１４から返ってくる（２）のＤＮＳレスポンスの到着（Ｓ２２０）は、Ｓ２１８とＳ２１９とのタイムラグ分だけ短縮されることになる。これにより、（２）のＤＮＳレスポンスは速やかに端末１２に到着する（Ｓ２２１）。

さらに、問い合わせたＤＮＳクエリの履歴が、（２）のＤＮＳクエリで名前の解決が失敗したとの記録である場合を念のため図７のシーケンス図に示す。この場合は特に時間短縮効果は無く、通常の応答速度で名前の解決がされる（Ｓ２３１〜Ｓ２３５）。

さらに、図７のシーケンスにおいてＤＮＳサーバからの返答で名前の解決がされなかった場合を図８に示す。（１）のＤＮＳクエリでも名前の解決に失敗した場合は（Ｓ２３６）、図６と同様にＤＮＳ問合履歴保持部に（２）での名前の解決が失敗した旨の履歴を登録する履歴登録手段３３が実行される（Ｓ２４１）。その上でＮｏＳｕｃｈＮａｍｅが端末１２に返される（Ｓ２４２）。その後、（２）のＤＮＳクエリが端末１２から送信されてくるが（Ｓ２４３）、ＤＮＳ問合履歴保持部２３には（２）での名前の解決が失敗した履歴が記録されているので（Ｓ２４４）、履歴返答即応手段３５が実行され、ＤＮＳサーバ１４への問い合わせを省略してＮｏＳｕｃｈＮａｍｅが端末１２に返送される（Ｓ２４５）。

１１ 中継装置
１２ 端末
１３ ＬＡＮ
１４ ＤＮＳサーバ
１５ ＷＥＢサーバ
１６ ＷＡＮ
２１ ＤＮＳ−ｐｒｏｘｙ部
２２ ＤＮＳクエリ変換部
２３ ＤＮＳ問合履歴保持部
２５ 記憶部
３１ 生成返答一時保持手段
３２ レスポンス即応手段
３３ 履歴登録手段
３４ 履歴結果判断手段
３５ 履歴返答即応手段
４１ ＤＮＳサーバ機能
４２ ＤＮＳリゾルバ機能

Claims (3)

1. ＩＰｖ４及びＩＰｖ６のうちの一方のＤＮＳクエリをＬＡＮ側から受信すると、ＷＡＮ側のＤＮＳサーバへ中継するとともに、上記ＤＮＳクエリに対応するＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを生成して上記ＤＮＳサーバへ送信し、返答を受け取って名前の解決がされた上記他方のＩＰアドレスを保持し、
   ＬＡＮ側からＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを受信したら、上記ＩＰアドレスをＤＮＳレスポンスとして返答する中継装置。
2. ＬＡＮ側とＷＡＮ側とにインターフェースを有し、ＤＮＳクエリ及びＤＮＳレスポンスを中継するＤＮＳ−ｐｒｏｘｙ部を有する中継装置であって、
   ＩＰｖ４及びＩＰｖ６のうちの一方のＤＮＳクエリを受信すると、当該ＤＮＳクエリとはＩＰのバージョンが異なるＩＰｖ４及びＩＰｖ６のうちの他方のＤＮＳクエリを生成して上記ＤＮＳ−ｐｒｏｘｙ部へ渡すＤＮＳクエリ変換部を有し、
   上記ＤＮＳ−ｐｒｏｘｙ部は、
   上記の他方のＤＮＳクエリに対するＤＮＳサーバからのＤＮＳレスポンスの内容を一時的に記憶部に保持する生成返答一時保持手段と、
   上記他方のＤＮＳクエリとドメイン名及びＩＰのバージョンが同じであるＤＮＳクエリを受信すると、上記生成返答一時保持手段で保持していたＤＮＳレスポンスの内容を、送信元アドレスへと返答するレスポンス即応手段とを実行する
   中継装置。
3. 過去にＤＮＳサーバに名前の解決を問い合わせたドメイン名について、ＩＰｖ４とＩＰｖ６のいずれかでの名前の解決の結果を記録するＤＮＳ問合履歴保持部を有し、
   上記ＤＮＳ−ｐｒｏｘｙ部が、
   ＬＡＮ側から受信したＤＮＳクエリについて上記ＤＮＳ問合履歴保持部を検索して、そのＤＮＳクエリのドメインについて該当するＩＰのバージョンで名前の解決ができなかったか否かの履歴の有無を得る履歴結果判断手段と、
   上記履歴結果判断手段により、当該ドメイン名及び当該ＩＰのバージョンのＤＮＳクエリでは名前の解決ができなかった履歴が得られれば、当該ＤＮＳクエリに対するＮｏＳｕｃｈＮａｍｅの返答をＬＡＮ側の送信元アドレス宛に生成する履歴返答即応手段とを実行する
   請求項２に記載の中継装置。

Images