JP4992016B2 - ドメイン名管理システム - Google Patents

Description

本発明はドメイン名管理システムに関し、特にインターネットにおいてドメイン名による問合せに対して対応するデータを迅速かつ大量に応答できるようにしたものである。

現在用いられているインターネットに接続されているすべてのコンピュータは、固有のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＩＰ）アドレスを持っており、インターネット上のどんなコンピュータにアクセスする際にも、最終的には当該コンピュータのＩＰアドレスを知る必要がある。

このＩＰアドレスには実際上人間が覚え易い名前として、「完全修飾ドメイン名（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）」（これを「ドメイン名」（Ｄｏｍａｉｎ Ｎａｍｅ）と呼ぶ）が割り当てられており、図１のドメイン名管理システム１に示すように、ネットワーク２に接続されている１つのクライアント３Ａのコンピュータから他のクライアント３Ｂ……３Ｎのコンピュータへアクセスする際には、クライアント３Ａのネットワークインターフェイスカード（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ：ＮＩＣ）４Ａでなる通信用ハードウェアからネットワーク２を介して伝送路５を通じてＤＮＳ（Ｄｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ６のネットワークインターフェイスカード６Ｘに、アクセスしようとする他のクライアント３Ｂ……３Ｎのドメイン名についての問合せ要求Ｄ１を伝送し、当該ドメイン名に対応するＩＰアドレスをネットワークインターフェイスカード６Ｘ→伝送路５→ネットワーク２→ネットワークインターフェイスカード４Ａを介して応答させる（これを「名前解決処理」と呼ぶ）手法が用いられている（特許文献１参照）。
特開２００７−１６６６５９公報

ところが、図１の従来の構成によると、ネットワーク２に接続されているクライアント３Ａ、３Ｂ……３Ｎの数が増加すればする程、各クライアントからＤＮＳサーバ６への問合せ要求Ｄ１が増えることになり、ＤＮＳサーバ６は大量の問合せ要求Ｄ１に対して名前解決応答Ｄ２を同じ数だけ作成し各クライアントへ返答する必要があるが、ＤＮＳサーバ６の性能の限界により、必ずしもＤＮＳサーバ６が受け取った問合せ要求Ｄ１すべてに対して名前解決応答Ｄ２を返答できるわけではないため、ネットワーク２の効率的な使用の観点から、ＤＮＳサーバ６の負荷を低減させることと、仮にＤＮＳサーバ６に多くの負荷がかかっていたとしても、各クライアントからの問合せ要求Ｄ１に対する名前解決応答Ｄ２を、各クライアントへ正確に返答できることが望ましい。

本発明は以上の点を考慮してなされたもので、名前解決処理における名前解決応答Ｄ２の送信をＤＮＳサーバ６の代わりに行い、該当ＤＮＳサーバの負荷をできるだけ低減させ、かつ、該当ＤＮＳサーバの状態に関わらず、名前解決応答Ｄ２を作成、送信できるようにしたドメイン名管理システムを提案しようとするものである。

かかる課題を解決するため本発明においては、複数のクライアント３Ａ、３Ｂ……３Ｎが接続されているネットワーク２に、複数のクライアントのドメイン名をＩＰアドレスに相互変換するドメイン名−ＩＰアドレス変換データを有するドメイン名変換サーバ６を接続し、複数のクライアント３Ａ、３Ｂ……３Ｎの１つ３Ａが他のクライアント３Ｂ……３Ｎのドメイン名を問合せ要求Ｄ１１としてネットワーク２を介してドメイン名変換サーバ６に送信したとき、当該ドメイン名変換サーバ６がネットワーク２を介して上記１つのクライアント３Ａに対して他のクライアント３Ｂ……３ＮのＩＰアドレスを供給するドメイン名管理システム１０において、ネットワーク２とドメイン名変換サーバ６との間にドメイン名管理装置２５を設け、ドメイン名管理装置２５は、ドメイン名変換サーバ６がネットワーク２を介して１つのクライアント３Ａに対して他のクライアント３Ｂ……３ＮのＩＰアドレスを供給したとき、当該他のクライアント３Ｂ……３Ｎのドメイン名に対応するＩＰアドレスを表わすドメイン名−ＩＰアドレス変換データを保存するドメイン名−ＩＰアドレス変換メモリ３６を有し、１つのクライアント３Ａからネットワーク２を介して問合せ要求Ｄ１１が送信されたとき、当該問合せ要求Ｄ１１に対応するドメイン名−ＩＰアドレス変換データがドメイン名−ＩＰアドレス変換メモリ３６に存在するとき、当該対応するドメイン名−ＩＰアドレス変換データをネットワーク２を介して問合せ要求Ｄ１１を出した１つのクライアント３Ａに名前解決応答Ｄ２３として供給するようにする。そして、ドメイン名管理装置２５は、上記ドメイン名−ＩＰアドレス変換データとして問合せ要求Ｄ１１に対する名前解決応答Ｄ２３のデータ形式と同様のデータ形式のデータをドメイン名−ＩＰアドレス変換メモリ３６に保存し、当該保存しているドメイン名−ＩＰアドレス変換データの一部を問合せ要求Ｄ１１に適合するように改変して名前解決応答Ｄ２３としてネットワーク２を介して上記１つのクライアント３Ａに供給する。

本発明によれば、ネットワークとＤＮＳサーバとの間にドメイン名管理装置を設け、問合せ要求に対応するドメイン名−ＩＰアドレス変換データがドメイン名−ＩＰアドレス変換メモリに保存されている場合には、当該対応するドメイン名−ＩＰアドレスデータを名前解決応答として問合せ要求を出したクライアントに返送することにより、ネットワークに接続するクライアントの数が膨大になったとしてもＤＮＳサーバの状態に関係なく名前解決応答を送信することができる。

以下図面について、本発明の一実施の形態を詳述する。

図２において、１０はドメイン名管理システムを示し、図１との対応部分に同一符号を付して示すように、ネットワーク２とＤＮＳサーバ６との間の伝送路５にドメイン名管理装置２５を配設した構成を有する。

ドメイン名管理装置２５は、図３に示すように、ネットワーク側のネットワークインターフェイスカード（ＮＩＣ）２５Ｙと、ＤＮＳサーバ側のネットワークインターフェイスカード２５Ｚとを有し、ネットワーク側のネットワークインターフェイスカード２５Ｙを伝送路５の伝送路部５Ａを介してネットワーク２に接続すると共に、ＤＮＳサーバ側のネットワークインターフェイスカード２５Ｚを伝送路５の伝送路部分５Ｂを介してＤＮＳサーバ６のネットワークインターフェイスカード６Ｘに接続している。

かくしてネットワークインターフェイスカード２５Ｙ及び２５Ｚからドメイン名管理装置２５に取り込まれたデータは、バス３１を介して中央処理ユニット（ＣＰＵ）３２に取り込まれ、ＣＰＵ３２は当該取り込まれたデータを、入力手段３３を介してユーザから入力される指定情報に基づいて、プログラム・動作メモリ３４に格納されているプログラムを用いてドメイン名−ＩＰアドレス変換処理をディスプレイ３５によってオペレータに表示しながら実行し、当該ドメイン名−ＩＰアドレス変換処理結果をドメイン名−ＩＰアドレス変換メモリ３６に記憶するようになされている。

ドメイン名管理装置２５のＣＰＵ３２は、ネットワーク側のネットワークインターフェイスカード２５Ｙに問合せ要求Ｄ１１を受けたとき、又はＤＮＳサーバ側のネットワークインターフェイスカード２５ＺにＤＮＳサーバ６から名前解決応答Ｄ２２を受けたとき、図４に示すＤＮＳ名前解決処理手順ＲＴ１を実行する。

ＣＰＵ３２は、ＤＮＳ名前解決処理手順ＲＴ１に入ると、まずステップＳＰ１において、受けたデータが問合せ要求パケットか否かの判断をする。

ここで肯定結果が得られると、このことはネットワーク２に接続されている伝送路部５Ａからクライアント３Ａ、３Ｂ……３Ｎのいずれかから問合せ要求Ｄ１１を受けたことを意味し、このときＣＰＵ３２は、ステップＳＰ２に移ってネットワークインターフェイスカード（ＮＩＣ）２５Ｙから到来した問合せパケットを取得する。

続いてＣＰＵ３２は、ステップＳＰ３に移ってドメイン名−ＩＰアドレス変換メモリ３６に設けたハッシュテーブル３６Ａについてそのデータのハッシュ値を計算することにより、ハッシュテーブル３６Ａにおいて、取得した問合せパケットによって表されているドメイン名に対応する応答パケットを検索する。

この実施の形態の場合、ハッシュテーブル３６Ａは、図５に示すように、ハッシュ値「１０１０」、「１０３０」、「１０５０」、「１１１０」……のメモリエリアに応答パケットＡ、Ｂ、Ｃ、Ｄ……を記憶した構成を有し、かくしてＣＰＵ３２は、順次ハッシュ値「１０１０」、「１０３０」、「１０５０」、「１１１０」……を計算することにより、応答パケットＡ、Ｂ、Ｃ、Ｄ……の内容を順次確認することにより、上述のステップＳＰ２において取得したパケットに対応する応答パケットを検索する。

各応答パケットＡ、Ｂ……はそれぞれ、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットＰＴ１と、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）パケットＰＴ２と、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）パケットＰＴ３とでなる。

ＩＰパケットＰＴ１は、図6（Ａ）に示すようなフォーマットによって構成され、発信元のクライアントと宛先のクライアントとの間の通信を確保するデータを含み、ＯＳ（オペレーティングシステム：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）ドライバとしての機能を実現する以下のデータを有する

バージョン
バージョンフィールドは、インターネットヘッダの形式を示す。現在のインターネットでは、ＩＰプロトコルバージョン４が使用されている。そのためこの領域には４という数値が記載される。

ヘッダ長
インターネットヘッダ長(ＩＨＬ：Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ)は、３２ビット単位のインターネットヘッダの長さであり、データの始点を示す。正しいヘッダの最小値は５である。

サービスタイプ
このパケットの信頼性や、優先度を意味するデータ。このパケットがどれほど重要で、どれほど優先して運ばなければならないかなどが記述される。郵便局の「速達」や「書留」と似ている。

全データ長
全データ長はデータグラムの長さであり、オクテット単位で算出され、インターネットヘッダとデータを含む。このフィールドは、最大６５５３５オクテットまでのデータグラムの長さが可能である。そのような長いデータグラムは、大半のホストやネットワークに対して非実践的である。すべてのホストは、最大５７６オクテットまでのデータグラムを受信する準備をしなければならない (受信するものが全体であれ、フラクセメントであれ)。もし宛先がより大きいデータグラムを受信する準備を行っている保証があるならば、ホストは５７６オクテットよりも大きいデータグラムを送信することが推奨される。

識別子
パケットを識別する値。ネットワーク上では、膨大な量のパケットが飛びかうことになるため、それぞれのパケットを識別するための番号（自動車のナンバープレートようなもの）がつけられる。

フラグ
このフィールドは、データグラム中のどこにこのフラグメントが属するかを示す。フラグメントオフセットは、８オクテット(６４ビット)単位で算出される。１番目のフラグメントのオフセットは０である。

生存時間
このフィールドは、データグラムがインターネットシステムに残ることが許される最大時間を示す。もしこのフィールドが値０を含むならば、そのデータグラムを破棄しなければならない。このフィールドは、インターネットヘッダ処理で更新される。時間は秒単位で計測されるが、データグラムを処理する全てのモジュールは、たとえデータグラムを１秒以下で処理したとしても、ＴＴＬを少なくとも１減らさなければならないので、ＴＴＬはデータグラムが存在してもよい時間の上限の値だけを考慮しなければならない。このフィールドの意図は、配送できないデータグラムを破棄することであり、最大データグラム生存時間を割り当てることである。

プロトコル
上位のプロトコルが何であるかを記述する。ＩＰの上位は、大抵「ＴＣＰ」もしくは「ＵＤＰ」であるため、このどちらかが入れられる。

チェックサム
ＩＰヘッダが壊れていないかを確認するためのデータである。

ネットワーク通信は、電気信号の伝達なので、伝達の途中でデータが変わって（壊れて）しまう可能性がある。なので、パケットが壊れていないかどうかを調べる必要がある。そのため、ＩＰヘッダ全体に対して、特殊な計算を施して、その計算によって算出された値を、このチェックサム領域に格納する。このチェックサム領域の値と、ＩＰヘッダ全体を見ることで、データが正確に伝わっているかどうかを確認できる仕組みである。

発信元ＩＰアドレス
発信元のＩＰアドレス。

宛て先ＩＰアドレス
宛て先のＩＰアドレス。

オプション
ネットワークに関する様々な情報が記載されるが、本発明では使用されない。

ＵＤＰパケットＰＴ２は、図6（Ｂ）に示すようなフォーマットを有し、これにより下位のアプリケーション層のデータ転送を行う機能をもち、以下のデータでなる。

発信元ポート番号
発信元のポート番号。

宛て先ポート番号
宛て先のポート番号。

ＵＤＰデータ長
ＵＤＰデータ（ＵＤＰヘッダ含む）のサイズ。

ＵＤＰチェックサム
基本的には、ＩＰヘッダのチェックサムと同じだが、こちらはＵＤＰデータ（ＵＤＰヘッダ含む）に対して、破損がないかの計算（チェック）が行われる。

ＤＮＳパケットＰＴ３、は図６（Ｃ）に示すフォーマットを有し、これにより上位のアプリケーション層としての機能を実現する、以下のデータを有する。

識別子
このＤＮＳデータを識別するための番号。
ＩＰヘッダにあったものと基本的には同じだが、こちらはＤＮＳプロトコルに対する識別番号。

ＱＲ（Ｑｕｅｒｙ／Ｒｅｓｐｏｎｓｅ）
クライアント３Ａ，３Ｂ……３Ｎが送ったパケットなのか、又はＤＮＳサーバが送ったパケットなのかを判別する番号が入る。クライアント３Ａ，３Ｂ……３Ｎが送ったパケットなら「０」、ＤＮＳサーバ６が送ったパケットなら「１」になる。

ＯＰＣＯＤＥ
ＤＮＳ要求に関するステータス情報が入る。クライアント３Ａ，３Ｂ……３Ｎが設定する。この要求は「どのような目的で送っていて」「どのような応答が欲しいのか」などを設定する。

ＡＡ（Ａｕｔｈｏｒｉｔａｔｉｖｅ Ａｎｓｗｅｒの略）
ＤＮＳサーバ６が設定する。信頼できるＤＮＳサーバ６から回答された場合は「１」になり、キャッシュサーバから回答された場合は「０」に設定される。

ＴＣ（Ｔｒａｎｃａｔｉｏｎの略）
ＤＮＳサーバ６の回答が、長くなった場合に、ＤＮＳサーバ６が「１」を設定する。
ＤＮＳパケットは、通常は１パケット（５１２バイト未満）に収まるが、稀に複数のパケットに分割しなければならないほど長くなる場合がある。その場合に、この値を「１」にして、クライアントに、回答パケットが複数あることを通知する。
ちなみに、ＤＮＳアクセラレータドメイン名管理装置２５では、ＴＣが「１」になっている応答パケットには対応しないことにしている。

ＲＤ（Ｒｅｃｕｒｓｉｏｎ Ｄｅｓｉｒｅｄの略）
ＲＤはクライアントが設定する。再帰問い合わせを許可するかどうかをサーバに通知する。再帰問い合わせとは、質問をされたＤＮＳサーバが、自分ではその質問に答えられなかった場合に、さらに別のＤＮＳサーバに質問すること。それを、ＤＮＳサーバが行ってよいかどうかを設定する。

ＲＡ（Ｒｅｃｕｒｓｉｏｎ Ａｖａｉｌａｂｌｅの略）
ＲＡはサーバが設定する。再帰問い合わせが可能かどうかをクライアントに通知する。

Ｚ
将来、プロトコルが拡張される場合に備えて、予約された領域。現在は、すべて「０」に設定することが決められている。

ＲＣＯＤＥ（Ｒｅｓｐｏｎｓｅ Ｃｏｄｅの略）
応答に関するステータス情報をサーバが設定する。

ステータス情報の例：
・問題なし
・パケットのフォーマットエラー
・ＤＮＳサーバの障害により回答不可
・サポートされていない質問
・この要求に対する回答を拒否

質問数
質問レコードに存在する質問の数を設定する。通常は「１」が入れられる。

回答ＲＲ数
回答レコードに存在する回答の数を設定する。
クライアントは「０」を、サーバは「１」を設定する。

権威ＲＲ数
権威レコードに存在するＤＮＳサーバの数を設定する。（通常は「０」）

追加ＲＲ数
追加情報レコードに存在する追加情報の数を設定する。（通常は「０」）

質問レコード
クライアントが「問い合わせる名前」や「タイプ」や「クラス」を設定する。つまり、クライアントが聞きたい質問をここに記述する。

回答レコード
サーバが「質問に対する回答」を設定する。つまり、クライアントが聞きたい質問に対する回答をここに記述する。

権威レコード
この回答に対して、権威を有するＤＮＳサーバの名前を設定する。通常のＤＮＳパケットではあまり使われない。

追加情報レコード
このＤＮＳパケットに対する追加情報を設定する。通常のＤＮＳパケットではあまり使われない。

続いてＣＰＵ３２は、上述のステップＳＰ３に続くステップＳＰ４において、ハッシュテーブル３６Ａに対する検索結果として、ハッシュテーブル３６Ａに応答パケットが存在するか否かの判断をし、否定結果が得られたときステップＳＰ５に移って上述のステップＳＰ２において取得した問合せパケットをネットワークインターフェイスカード２５Ｚを介してＤＮＳサーバ６に接続されている伝送路部分５Ｂに問合せ要求Ｄ１２として送出する。

かくしてＣＰＵ３２は、ネットワークインターフェイスカード２５Ｙから取り込んだ問合せ要求Ｄ１１に対して、ドメイン名ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａには対応する応答パケットが存在しないことを確認することにより、当該ＤＮＳ名前解決処理手順ＲＴ１をステップＳＰ６において終了する。

このようにして、ドメイン名管理装置２５のＤＮＳ名前解決処理手順ＲＴ１のループＳＰ２−ＳＰ３−ＳＰ４−ＳＰ５−ＳＰ６のループによって、ＤＮＳサーバ６に送信された問合せ要求Ｄ１２は、ＤＮＳサーバ６のネットワークインターフェイスカード６ＸからＤＮＳサーバ６に取り込まれて、図７に示すＤＮＳ名前解決処理手順ＲＴ２を実行することにより、当該問合せ要求Ｄ１２に対応する応答処理を実行する。

ＤＮＳ名前解決処理手順ＲＴ２に入ると、ＤＮＳサーバ６はステップＳＰ２１においてネットワークインターフェイスカード６Ｘからパケットを取得した後、ステップＳＰ２２においてデータの解析を行う。

続いてＤＮＳサーバ６は、ステップＳＰ２３において当該解析した問合せ要求は自身が管理するＤＮＳデータの要求であるか否かの判断をする。

ここで肯定結果が得られたとき、このことは、ＤＮＳサーバ６が問合せ要求されたドメイン名に対応するＩＰアドレスに変換して応答できることを表しており、このときＤＮＳサーバ６はステップＳＰ２４に移って該当するデータをパケットデータに変換した後、ステップＳＰ２５において当該変換したパケットデータをネットワークインターフェイスカード６Ｘからドメイン名管理装置２５に接続された伝送路部５Ｂに名前解決応答Ｄ２２として送信する。

これに対して、上述のステップＳＰ２３において否定結果が得られると、このことは問合せ要求されたドメイン名は自身が管理するものではないためＩＰアドレスを応答できないことを意味し、このときＤＮＳサーバ６はステップＳＰ２７において該当するＩＰアドレスを保持していないことを通知するパケットデータを生成した後、ステップＳＰ２５において当該生成したパケットデータをネットワークインターフェイスカード６Ｘから伝送路部５Ｂに名前解決応答Ｄ２２として送信する。

かくしてＤＮＳサーバ６はドメイン名管理装置２５から転送されてきた問合せ要求Ｄ１２に対するＤＮＳ名前解決処理手順ＲＴ２をステップＳＰ２６において終了する。

このようにして伝送路５の伝送路部５Ｂに対してＤＮＳサーバ６から名前解決応答２２として送信されたパケットデータは、ドメイン名管理装置２５のネットワークインターフェイスカード２５Ｚに到来し、このときドメイン名管理装置２５のＣＰＵ３２は、図４のＤＮＳ名前解決処理手順ＲＴ１のステップＳＰ１において要求パケットか否かの判断をする。

このとき到来したパケットデータはネットワーク２からの問合せ要求ではなくＤＮＳサーバ６からの名前解決応答パケットであるので、ＣＰＵ３２は、ステップＳＰ１において否定結果が得られることによりステップＳＰ１０に移ってネットワークインターフェイスカード２５Ｚからパケットを取得すると共に、ステップＳＰ１１において当該パケットデータをドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａに保存する。

その後ＣＰＵ３２は、ステップＳＰ１２において上述のステップＳＰ１０において取得したパケットをそのまま名前解決応答Ｄ２３としてネットワーク２側のネットワークインターフェイスカード２５Ｙから伝送路部５Ａに送信する。

かくしてＣＰＵ３２は、ステップＳＰ１０−ＳＰ１１−ＳＰ１２のループにおける処理をすることにより、ステップＳＰ６において当該ＤＮＳ名前解決処理手順ＲＴ１の処理を終了する。

この結果ＣＰＵ３２は、ネットワーク２から到来した問合せ要求Ｄ１１に対するＤＮＳサーバ６における名前解決処理結果を、ドメイン名管理装置２５のドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａに保存すると共に当該データをネットワーク２を介して要求を出したクライアントに送信する。

このようにしてドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａには、クライアント２Ａ、２Ｂ……２Ｎから到来した問合せ要求について、対応する名前解決応答がハッシュテーブル３６Ａに存在しない場合には、ＤＮＳサーバ６における名前解決処理を待って、当該処理結果を順次蓄積して行くことになる。

当該蓄積された名前解決データに対する問合せ要求Ｄ１１がネットワークインターフェイスカード２５Ｙに到来すると、ＣＰＵ３２は、その都度、図４のＤＮＳ名前解決処理手順ＲＴ１の処理に入って、ステップＳＰ１−ＳＰ２−ＳＰ３−ＳＰ４のループの処理を実行することにより、ステップＳＰ４において肯定結果を得る。

このときＣＰＵ３２は、ステップＳＰ１５に移ってドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａから対応する応答パケットをネットワークインターフェイスカード２５Ｙを介して伝送路部５Ａに送信した後、ステップＳＰ６において当該ＤＮＳ名前解決処理手順ＲＴ１を終了する。

この結果、ドメイン名管理装置２５のＣＰＵ３２は、クライアント３Ａ、３Ｂ……３Ｎから受けた問合せ要求Ｄ１１について、ドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａに問合せ要求されたドメイン名に対応するＩＰアドレスが蓄積されているとき、当該蓄積されたデータを直ちにネットワークインターフェイスカード２５Ｙからネットワーク２を介して要求を出したクライアント３Ａ、３Ｂ……３Ｎに、名前解決応答Ｄ２３を供給することができる。

ＤＮＳ名前解決処理手順ＲＴ１のステップＳＰ１５における応答パケットの生成は、図８に示すように、ネットワークインターフェイスカード２５Ｙから機能ブロックＢＬ１に示すようにＤＮＳ要求パケット（例えばパケット「Ａ」）が取得されたとき、機能ブロックＢＬ２に示すように、ＤＮＳ要求パケット「Ａ」に対応するハッシュテーブル３６Ａからの応答パケット「Ａ」を取得する。

この取得されたＤＮＳ応答パケット（機能ブロックＢＬ３）は、図６（Ａ）、（Ｂ）及び（Ｃ）について上述したように、ＩＰパケットＰＴ１、ＵＤＰパケットＰＴ２及びＤＮＳパケットＰＴ３を含んでいるところ、まず機能ブロックＢＬ４で示すようにＩＰパケットのフォーマットに含まれる発信元ＩＰアドレスと宛て先ＩＰアドレスとを変更（改変）する。

それと共に、機能ブロックＢＬ５に示すように、ＩＰパケットＰＴ１のフォーマットに含まれるチェックサムを再計算した後、機能ブロックＢＬ６に示すようにＵＤＰパケットＰＴのうち発信元ＰＯＲＴ番号及び宛先ＰＯＲＴ番号を変更（改変）する。

さらに機能ブロックＢＬ７で示すＤＮＳパケットＰＴ３に含まれる識別子を変更することにより応答パケットの生成を終了して、ネットワークインターフェイスカード２５Ｙに渡す。

かくして、ドメイン名管理装置２５のＣＰＵ３２は、応答パケットの生成処理として、プロトコルレイヤから見て、第１層のＩＰパケットＰＴ１（図６（Ａ））と、当該第１層に対して上位プロトコル層となる第２層として形成するＵＤＰパケットＰＴ２（図６（Ｂ））と、当該第２層に対して上位アプリケーション層となる第３層を形成するＤＮＳパケットＰＴ３（図６（Ｃ））とを、あらかじめ用意したフォーマットをもつデータとしてハッシュテーブル３６Ａにハッシュ値を付けて保存すると共に、当該フォーマットの一部のデータを改変するだけで応答パケットを生成することができる。

このような応答パケットの生成の仕方ができるのは、図９に示すように、オペレーティングシステム（ＯＳ）に、応答パケットの一部であるＩＰパケットＰＴ１とＵＤＰパケットＰＴ２の生成を任せずに、ドメイン名管理装置２５の下層ソフトウェア層（第２層）でオペレーティングシステム（ＯＳ）とは別に用意された該当パケットを検索する機能Ｍ１と、その検索の結果応答パケットがあるとき応答する機能Ｍ２、また該当パケットがない場合には、通過機能Ｍ３を、ＣＰＵ３２が実行し、ハードウェア層（第1層）ＬＹ１を構成するネットワークインターフェースに応答データとして渡せるからである。

システムが、すべてのパケットデータを、オペレーティングシステム（ＯＳ）を含むカーネルの機能として、ドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａから該当パケットを検索する機能Ｍ１と、その検索の結果応答パケットがあるとき応答する機能Ｍ２とを管理することにより、応答データを作ってハードウェア層（第１層）ＬＹ１のネットワークインターフェイスカード２５Ｙに渡すような管理をする。これに加えてハッシュテーブル３６Ａに該当パケットがない場合には、通過機能Ｍ３によって取得した問合せ要求をハードウェア層（第１層）ＬＹ１を構成するネットワークインターフェイスカード２５Ｚに渡す。

かくしてＣＰＵ３２は、下層ソフトウェア層（第２層）ＬＹ２がハードウェア層（第１層）ＬＹ１のハードウェアと密接に関連しながらその動作を制御するカーネル機能をもつような制御機能を実現している。

この第２層ＬＹ２の機能は、上位のソフトウェア層を形成する第３層ＬＹ３においてドメイン名管理装置２５の動作条件として、設定データを適用され動作を制御される、レイヤ構成を構築している。

以上の構成において、ドメイン名管理装置２５のＣＰＵ３２は、クライアント３Ａ、３Ｂ……３Ｎの１つから、ネットワーク２を介してドメイン名でなる問合せ要求Ｄ１１を受けたとき、図４のＤＮＳ名前解決処理手順ＲＴ１のステップＳＰ１−ＳＰ２−ＳＰ３−ＳＰ４のループによってドメイン名−ＩＰアドレス変換メモリ３６のハッシュテーブル３６Ａを検索することにより対応するドメイン名をもつ応答パケットを検索し、当該該当する応答パケットが存在すれば、ステップＳＰ１５においてハッシュメモリ３６に記憶されているパケットのフォーマットに基づいてその一部、すなわち発信元ＩＰ ＰＯＲＴ、宛先ＩＰ ＰＯＲＴ、識別子を改変して応答すべきパケットデータを作成して、これをネットワークインターフェイスカード２５Ｙを介して応答要求を出したクライアントに対する名前解決応答Ｄ２３として供給する。

以上の構成によれば、ネットワーク２とＤＮＳサーバ６との間にドメイン名管理装置２５を設け、問合せ要求Ｄ１１に対応するドメイン名−ＩＰアドレス変換データがドメイン名−ＩＰアドレス変換メモリ３６に保存されていない場合には、当該問合せ要求をＤＮＳサーバ６に転送してドメイン名−ＩＰアドレス変換処理をさせることにより名前解決応答を得て名前解決応答Ｄ２３として問合せ要求を出したクライアント３Ａに返送すると共にこれをドメイン名−ＩＰアドレス変換メモリ３６に保存する。

これに対して問合せ要求Ｄ１１に対応するドメイン名−ＩＰアドレス変換データがドメイン名−ＩＰアドレス変換メモリ３６に保存されている場合には、当該対応するドメイン名−ＩＰアドレスデータを名前解決応答Ｄ２３として問合せ要求を出したクライアント３Ａに返送することにより、ネットワーク２に接続するクライアント３Ａ、３Ｂ……３Ｎの数が膨大になったとしてもＤＮＳサーバの状態に関係なく名前解決応答を送信することができる。

このとき応答パケットの生成をあらかじめ決めたフォーマットを有する第１層プロトコルを形成するＩＰパケットＰＴ１と、第２層パケットを構成するＵＤＰパケットＰＴ２と、第３層を構成するＤＮＳパケットＰＴ３を用いるようにしたことにより、問合せ要求Ｄ１１を受けてから名前解決応答Ｄ２３を供給するまでの時間を一段と短縮することができる。

実験によれば、ドメイン名管理装置２５を設置しない一般的なネットワークにおいて、ネットワーク２から直接ＤＮＳサーバ６に問合せ要求を出した場合と比較して、単位時間毎に約２０倍の応答量を確認し得た。

かくするにつき、ドメイン名−ＩＰアドレス変換メモリ３６上にハッシュテーブル３６Ａを形成しハッシュ値を計算することにより各応答データを検索できるようにしたことにより、応答量を一段と高めることができる。

また、システムの構成を、実質上ハードウェアを直接的にコントロールできるようなカーネル形態のソフトウェアを構築するようにしたことにより、問合せ要求Ｄ１１に対して一段と速い応答処理を実現した。

さらに、問合せ要求に対する名前解決応答のパケットフォーマットを共通化できるように構成したことにより、問合せ要求データを元に名前解決データの一部にある発信元ＩＰアドレス（ＰＯＲＴ含む）、宛先ＩＰアドレス（ＰＯＲＴ含む）及び識別子を改変するだけで問い合わせ要求に対する名前解決応答パケットデータを生成できるようにしたことにより、応答時間を一段と短縮することができる。

本発明はインターネットにおけるドメイン名とＩＰアドレスを相互変換する管理システムに適応できる。

従来の構成を示すブロック図である。 本発明によるドメイン名管理システムの一実施の形態を示すブロック図である。 図２のドメイン名管理装置の詳細構成を示すブロック図である。 ドメイン名管理装置におけるＤＮＳ名前解決処理手順を示すフローチャートである。 図３のハッシュテーブルの詳細構成を示す略線図である。 図５の応答パケットの構成を示す略線図である。 ＤＮＳサーバ６におけるＤＮＳ名前解決処理手順を示すフローチャートである。 応答パケットの生成手順を示す機能ブロック図である。 システムのレイヤ構成を示す略線図である。

符号の説明

１、１０……ドメイン名管理システム、２……ネットワーク、３Ａ、３Ｂ……３Ｎ……クライアント、４Ａ、４Ｂ……４Ｎ、６Ｘ、２５Ｙ、２５Ｚ……ネットワークインターフェイスカード、３１……バス、３２……ＣＰＵ、３３……入力手段、３４……プログラム・動作メモリ、３５……ディスプレイ、３６……ドメイン名−ＩＰアドレス変換メモリ、３６Ａ……ハッシュテーブル。

Claims (3)

1. 複数のクライアントが接続されているネットワークに、上記複数のクライアントのドメイン名をＩＰアドレスに変換するドメイン名−ＩＰアドレス変換データを有するドメイン名変換サーバを接続し、上記複数のクライアントの１つが他のクライアントのドメイン名を問合せ要求として上記ネットワークを介して上記ドメイン名変換サーバに送信したとき、当該ドメイン名変換サーバが上記ネットワークを介して上記１つのクライアントに対して上記他のクライアントのＩＰアドレスを供給するドメイン名管理システムにおいて、
   上記ネットワークと上記ドメイン名変換サーバとの間にドメイン名管理装置を設け、
   上記ドメイン名管理装置は、上記ドメイン名変換サーバが上記ネットワークを介して上記１つのクライアントに対して上記他のクライアントの上記ＩＰアドレスを供給したとき、当該他のクライアントのドメイン名に対応する上記ＩＰアドレスを表わすドメイン名−ＩＰアドレス変換データを保存するドメイン名−ＩＰアドレス変換メモリを有し、
   上記１つのクライアントから上記ネットワークを介して上記問合せ要求が送信されたとき、当該問合せ要求に対応するドメイン名−ＩＰアドレス変換データが上記ドメイン名−ＩＰアドレス変換メモリに存在するとき、当該対応するドメイン名−ＩＰアドレス変換データを上記ネットワークを介して上記問合せ要求を出した上記１つのクライアントに名前解決応答として供給し、
   上記ドメイン名−ＩＰアドレス変換データとして上記問合せ要求に対する名前解決応答のデータ形式と同様のデータ形式のデータを上記ドメイン名−ＩＰアドレス変換メモリに保存し、当該保存しているドメイン名−ＩＰアドレス変換データの一部を上記問合せ要求に適合するように改変して上記名前解決応答として上記ネットワークを介して上記１つのクライアントに供給する
   ことを特徴とするドメイン名管理システム。
2. 上記ドメイン名−ＩＰアドレス変換メモリは、ドメイン名−ＩＰアドレス変換データを
   検索する際、ハッシュテーブルを有する
   ことを特徴とする請求項１に記載のドメイン名管理システム。
3. ネットワークに接続されている複数のクライアントのドメイン名をＩＰアドレスに変換するドメイン名−ＩＰアドレス変換データを有し、上記複数のクライアントの１つが他のクライアントのドメイン名を問合せ要求として上記ネットワークを介して送信してきたとき、上記ネットワークを介して上記１つのクライアントに対して上記他のクライアントのＩＰアドレスを供給するドメイン名変換サーバと上記ネットワークとの間に設けられたドメイン名管理装置であって、
   上記ドメイン名変換サーバが上記ネットワークを介して上記１つのクライアントに対して上記他のクライアントの上記ＩＰアドレスを供給したとき、当該他のクライアントのドメイン名に対応する上記ＩＰアドレスを表わすドメイン名−ＩＰアドレス変換データを保存するドメイン名−ＩＰアドレス変換メモリを有し、
   上記１つのクライアントから上記ネットワークを介して上記問合せ要求が送信されたとき、当該問合せ要求に対応するドメイン名−ＩＰアドレス変換データが上記ドメイン名−ＩＰアドレス変換メモリに存在するとき、当該対応するドメイン名−ＩＰアドレス変換データを、上記ネットワークを介して上記問合せ要求を出した上記１つのクライアントに名前解決応答として供給し、
   上記ドメイン名−ＩＰアドレス変換データとして上記問合せ要求に対する名前解決応答のデータ形式と同様のデータ形式のデータを上記ドメイン名−ＩＰアドレス変換メモリに保存し、
   当該保存しているドメイン名−ＩＰアドレス変換データの一部を上記問合せ要求に適合するように改変して上記名前解決応答として上記ネットワークを介して上記１つのクライアントに供給する
   ことを特徴とするドメイン名管理装置。