JP2016506655A - Ｄｎｓサービス提供方法及び装置 - Google Patents

Abstract

ＤＮＳサービス提供方法および装置を開示する。本発明の好適な一実施形態によれば、ローカルＤＮＳサービスからドメイン名解決要求を受信すると、ユーザーＤＮＳサーバーから、受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して受信し、受信されたホストレコードを用いてドメイン名解決要求に対する応答をローカルＤＮＳサーバーへ伝送する。本発明によれば、効果的にＤＮＳゾーンファイルの追加や変動などが可能であって、ＤＮＳサービスをより速く且つ正確に提供することができる。

Description

本発明は、ＤＮＳサービス提供方法及び装置に係り、より詳しくは、ＤＮＳゾーンファイル（ｚｏｎｅ ｆｉｌｅ）を別途保存しなくてもＤＮＳサービスの提供が可能なＤＮＳサービス提供方法及び装置に関する。

ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ ＳｙｓｔｅｍまたはＤｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）サービスは、主にＴＣＰ／ＩＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークで使用されるネームサービスであって、人が覚えやすく文字からなるドメインを、コンピュータが処理可能な数字からなるインターネットアドレスに変えてサーバーなどのデバイスに接続できるようにするサービスである。

ドメイン名は、インターネットアドレスであって、人々が覚えやすく意味を付与して設定される名前であるが、インターネット上であるコンピュータを実際検索するには、数字体系からなるＩＰアドレス（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ａｄｄｒｅｓｓ）が必要である。

各サイトが運営するサーバーは、固有のＩＰアドレスを持っているため、ユーザーが文字でアドレスを入力すると、ＤＮＳサーバーを介してサーバーが認識可能なＩＰアドレスに変わって接続ができるようになる。

ＤＮＳサービスは、ＤＮＳサーバーが各サイトのドメイン情報とＩＰアドレス情報を持っており、該当サイトへのアクセスを求める要求が受信されると、この要求を解析し、該当ＩＰアドレスを持つサイトのサーバーに接続させる。

一方、このようなＤＮＳサービスでは、ＤＮＳゾーンデータ（ｚｏｎｅ ｄａｔａ）またはＤＮＳゾーンファイル（ｚｏｎｅ ｆｉｌｅ）と呼ばれる特定のドメイン名の一部分を説明するデータが含まれているファイルが存在する。

ＤＮＳゾーンファイルには、ドメイン名をＩＰ数字に分解するために必要な情報、すなわち、ドメイン名およびそれに関連付けられているサブドメイン、ＩＰアドレス情報、メールサーバー情報などが含まれる。

そして、ＤＮＳゾーンファイルは、一般に、アドレスレコード、ＣＮＡＭＥ、メールレコード、ＴＴＬ（Ｔｉｍｅ Ｔｉ Ｌｉｖｅ）などから構成される。

一方、このようなＤＮＳゾーンファイルは、ＤＮＳサービスを提供するＤＮＳサーバーのうち、特に自らＤＮＳ解決（ｒｅｓｏｌｕｔｉｏｎ）要求（ＤＮＳクエリ）に対して、直接数字からなるＩＰアドレスを応答することが可能な権威ＤＮＳ（ａｕｔｈｏｒｉｔａｔｉｖｅ ＤＮＳ）サーバー（以下、「権威ＤＮＳサーバー」という）の場合、必ず保存されているべきである。

ところが、ＤＮＳゾーンファイルの場合、従来は、ドメイン名の解決（ｒｅｓｏｌｕｔｉｏｎ）に必要な情報を相対的に多く必要としないので、比較的そのデータのサイズが大きくなかった。

しかし、最近、ネットワークの構成が複雑になるにつれて、ＤＮＳゾーンファイルに保存されるべきデータのサイズも増加している。

したがって、ＤＮＳゾーンファイルの追加や変更などに多くの時間がかかり、また、ＤＮＳゾーンファイルを持っていなければならないＤＮＳシステムを構成する装置において多くの保存空間が求められる問題点がある。

特に、ＤＮＳサービスの提供を受けようとするユーザーが、ＤＮＳゾーンファイルの内容が変更または削除される場合には、権威ＤＮＳサーバーにＤＮＳゾーンファイルをすべて更新しなければならないという問題点がある。

そして、ＤＮＳゾーンファイルの追加や変更に多くの時間がかかり、特にＤＮＳゾーンファイルの追加や変更などが時間的に同時に行われない場合は、ＤＮＳサービスにおけるエラーが発生するなどの問題点がある。

前述した従来の問題点を解決するために、本発明は、ＤＮＳゾーンファイルのサイズが大きい場合でも、効果的にＤＮＳゾーンファイルの追加や変更などを可能にするＤＮＳサービス提供方法及び装置を提供することを目的とする。

また、本発明は、効果的にＤＮＳゾーンファイルの追加や変更などを可能にしてＤＮＳサービスにおけるエラーが発生しないようにするＤＮＳサービス提供方法及び装置を提供することである。

本発明の別の目的は、以下の実施形態についての説明から容易に理解できるであろう。

上記目的を達成するために、本発明の一側面によれば、ＤＮＳサービス提供方法が提供される。

本発明の好適な一実施形態によれば、クライアント、ローカルＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー、権威ＤＮＳ（ａｕｔｈｏｒｉｔａｔｉｖｅ ＤＮＳ）サーバー、およびユーザーＤＮＳサーバーを含むＤＮＳシステムで前記権威ＤＮＳサーバーによって行われるＤＮＳサービス提供方法において、前記ローカルＤＮＳサーバーからドメイン名解決要求を受信する段階と、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階と、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対する応答を前記ローカルＤＮＳサーバーへ伝送する段階とを含むことを特徴とする、ＤＮＳサービス提供方法が提供される。

前記ＤＮＳシステムは複数の権威ＤＮＳサーバーを含み、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階は、前記ユーザーＤＮＳサーバーの代わりに前記複数の権威ＤＮＳサーバーのうち他の権威ＤＮＳサーバーから前記ホストレコードを要求して受信することができる。

前記ホストレコードは、ドメイン名、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス情報、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）情報を含むことができる。

そして、前記受信されたホストレコードは、前記ＴＴＬ情報に基づいて一時的に前記権威ＤＮＳサーバーに保存できる。

前記ＤＮＳシステムは複数のユーザーＤＮＳサーバーを含み、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求することは、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバーを検索し、前記検索されたユーザーＤＮＳサーバーに対して要求することができる。

前記権威ＤＮＳサーバーは、ドメイン名にマッチするＩＰアドレスを含むＤＮＳルックアップテーブル（ｌｏｏｋ−ｕｐ ｔａｂｌｅ）情報をさらに含み、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対して応答することは、前記ＤＮＳルックアップテーブルからマッチするＩＰアドレスを選択して応答することができる。

本発明の他の一側面によれば、ＤＮＳサービス提供装置が提供される。

本発明の好適な一実施形態によれば、クライアント、ローカルＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー、およびユーザーＤＮＳサーバーを含むＤＮＳシステムに含まれてＤＮＳサービスを提供する装置であって、前記ローカルＤＮＳサーバーからドメイン名解決要求を受信し、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して受信し、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対する応答を前記ローカルＤＮＳサーバーへ伝送する通信部と、前記ユーザーＤＮＳサーバーから受信された前記ホストレコードを保存するホストレコード保存部とを含むことを特徴とする、ＤＮＳサービス提供装置が提供される。

前記ＤＮＳシステムは前記ＤＮＳサービス提供装置を複数含み、前記通信部が前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して受信することは、前記ユーザーＤＮＳサーバーの代わりに他のＤＮＳサービス提供装置から前記ホストレコードを要求して受信することができる。

前記ホストレコードは、ドメイン名、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス情報、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）情報を含むことができる。

そして、前記受信されたホストレコードは、前記ＴＴＬ情報に基づいて一時的に前記保存部に保存できる。

前記ＤＮＳシステムは複数のユーザーＤＮＳサーバーを含み、前記保存部は、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバー情報をさらに保存し、前記ユーザーＤＮＳサーバーから前記ホストレコードを要求することは、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバーを検索し、前記検索されたユーザーＤＮＳサーバーに対して要求することができる。

前記保存部は、ドメイン名にマッチするＩＰアドレスを含むＤＮＳルックアップテーブル（ｌｏｏｋ−ｕｐ ｔａｂｌｅ）情報をさらに保存し、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対して応答することは、前記ＤＮＳルックアップテーブルからマッチするＩＰアドレスを選択して応答することができる。

本発明の別の側面によれば、ＤＮＳサービス提供方法を実現するためのプログラムを記録した記録媒体が提供される。

本発明の好適な一実施形態によれば、クライアント、ローカルＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー、権威ＤＮＳ（ａｕｔｈｏｒｉｔａｔｉｖｅ ＤＮＳ）サーバー、およびユーザーＤＮＳサーバーを含むＤＮＳシステムで前記権威ＤＮＳサーバーによって行われるＤＮＳサービス提供方法を実現するためのプログラムを記録した記録媒体であって、前記ローカルＤＮＳサーバーからドメイン名解決要求を受信する段階と、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階と、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対する応答を前記ローカルＤＮＳサーバーへ伝送する段階とを含むことを特徴とする、ＤＮＳサービス提供方法を実現するためのプログラムを記録した記録媒体が提供される。

前記ＤＮＳシステムは複数の権威ＤＮＳサーバーを含み、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメイに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階は、前記ユーザーＤＮＳサーバーの代わりに前記複数の権威ＤＮＳサーバーのうち他の権威ＤＮＳサーバーから前記ホストレコードを要求して受信することができる。

前記ホストレコードは、ドメイン名、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス情報、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）情報を含むことができる。

そして、前記受信されたホストレコードは、前記ＴＴＬ情報に基づいて一時的に前記権威ＤＮＳサーバーに保存できる。

前記ＤＮＳシステムは複数のユーザーＤＮＳサーバーを含み、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求することは、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバーを検索し、前記検索されたユーザーＤＮＳサーバーに対して要求することができる。

前記権威ＤＮＳサーバーは、ドメイン名にマッチするＩＰアドレスを含むＤＮＳルックアップテーブル（ｌｏｏｋ−ｕｐ ｔａｂｌｅ）情報をさらに含み、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対して応答することは、前記ＤＮＳルックアップテーブルからマッチするＩＰアドレスを選択して応答することができる。

以上で説明したように、本発明に係るＤＮＳサービス提供方法および装置によれば、効果的にＤＮＳゾーンファイルの追加や変更などができるという長所がある。

また、本発明によれば、効果的にＤＮＳゾーンファイルの追加や変更などを可能にしてＤＮＳサービスをより速く且つ正確に提供することができるという長所がある。

本発明の好適な一実施形態に係るＤＮＳサービス提供方法が適用できるＤＮＳシステムの構成を例示する図である。 本発明の好適な一実施形態に係るＤＮＳサービス提供方法が適用される順序を示すフローチャートである。 本発明の好適な一実施形態に係るＤＮＳサービス提供装置の構成を示す図である。

本発明は、様々な変更を加えることができ、様々な実施形態を有することができるもので、以下、本発明の特定の実施形態を図面に例示し、詳細な説明に詳しく説明する。ところが、これらの実施形態は本発明を限定するためのものではなく、本発明の思想及び技術範囲に含まれる変更、均等物及び代替物はいずれも本発明に含まれるものと理解すべきである。

各図面を説明しながら、類似する参照符号を類似する構成要素に対して使用した。本発明を説明するにあたり、関連した公知の技術についての具体的な説明が本発明の要旨を無駄に不明確にする可能性があると判断される場合は、その詳細な説明を省略する。

「第１」、「第２」などの用語は様々な構成要素を説明するために使用できるが、前記構成要素はこれらの用語によって限定されるものではない。これらの用語は、ある構成要素を他の構成要素と区別するために使用されるだけである。

例えば、本発明の権利範囲を逸脱しない範疇内で、第１構成要素は第２構成要素と命名でき、同様に、第２構成要素も第１構成要素と命名できる。

「及び／又は」という用語は、複数の関連した記載項目の組み合わせ又は複数の関連した記載項目のいずれかを含む。

ある構成要素が他の構成要素に「連結」または「接続」されていると言及されたときは、他の構成要素に直接連結又は接続されている可能性もあるが、それらの構成要素の間に別の構成要素が介在することもあると理解すべきである。

これに対して、ある構成要素が他の構成要素に「直接連結」されているか、「直接接続」されていると言及されたときは、それらの構成要素の間に別の構成要素が存在しないと理解すべきである。

本出願において使用した用語は、単に特定の実施形態を説明するために使用されたものであり、本発明を限定するものではない。

単数の表現は、文脈上明らかに異なる意味を表さない限り、複数の表現を含む。本出願において、「含む」又は「有する」などの用語は、明細書に記載された特徴、数字、段階、動作、構成要素、部品又はそれらの組み合わせが存在することを示すものであり、１つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品又はそれらの組み合わせの存在又は付加の可能性を予め排除するものではないと理解すべきである。

別途定義されていない限り、技術的又は科学的な用語を含めてここで使用される全ての用語は、本発明の属する技術分野における通常の知識を有する者により一般的に理解されるものと同様の意味を有する。

一般に使用される辞書に定義されている用語は、関連技術の文脈上持つ意味と同じ意味を持つものと解釈されるべきであり、本出願において明らかに定義しない限り、理想的または過度に形式的な意味には解釈されない。

以下、添付図面を参照して、本発明に係る好適な実施形態を詳細に説明するが、図面符号を問わず、同一または対応の構成要素は同一の参照番号を付し、これについての重複説明は省略する。

まず、図１を参照して、本発明の好適な一実施形態に係るＤＮＳサービス提供方法が適用できるＤＮＳサービス提供システムについて説明する。

図１は本発明の好適な一実施形態に係るＤＮＳサービス提供方法が適用できるＤＮＳシステムの構成を例示する図である。図１に示すように、本発明の好適な一実施形態によるＤＮＳシステムは、クライアント１００、ローカルＤＮＳサーバー１１０、権威ＤＮＳサーバー１２０、およびユーザーＤＮＳサーバー１３０を含む。

それぞれの構成要素は複数存在できるのは自明であるが、以下では、説明の便宜のために、それぞれ１つのみを図示して説明する。

まず、クライアント１００は、ＤＮＳサービスを用いてユーザーの所望するサーバーに接続することができるようにする装置であって、例えば、ＰＣ、ノートパソコン、スマートフォン、タッチパッドなどの通信網に接続することができ、Ｗｅｂブラウザなどがインストールされてドメイン名の入力を介して特定のサーバーに接続することができる端末装置であれば、いずれも可能である。

ローカルＤＮＳサーバー１１０は、クライアント１００から文字で入力されたドメイン名に対する解決要求を最初に受信する。

ローカルＤＮＳサーバー１１０は、受信されたドメイン名に対する解決が可能な場合、直ちにクライアント１００へ数字からなるＩＰアドレスを伝送する。

しかし、受信されたドメイン名に対する解決が不可能な場合、上位ＤＮＳサーバーにドメイン名に対する解決要求を伝達する。

そして、上位ＤＮＳサーバーがドメイン名解決要求を受信してドメイン名に対する解決、すなわちＩＰアドレスをさらにローカルＤＮＳサーバー１１０へ伝送し、これをさらにクライアント１００へ伝送することになる。

一方、上位ＤＮＳサーバーは、場合に応じて複数の段階のＤＮＳサーバーを経由することが可能であるが、ＤＮＳクエリに対してＩＰアドレスを返却しなければならない上位ＤＮＳサーバーを権威ＤＮＳサーバー（ａｕｔｈｏｒｉｔａｔｉｖｅ ＤＮＳサーバー）１２０という。

権威ＤＮＳサーバー１２０の場合、自らＤＮＳ解決要求（ＤＮＳクエリ）に対して直接数字からなるＩＰアドレスを応答することができなければならないので、ＤＮＳゾーンファイルが保存されていなければならない。

そして、最近のネットワーク構成上、権威ＤＮＳサーバー１２０が複数存在する場合がほとんどであるので、複数の権威ＤＮＳサーバー１２０に同時に同じＤＮＳゾーンファイルが保存されていなければならない。

したがって、権威ＤＮＳサーバー１２０にＤＮＳゾーンファイルをアップロードする過程で多くのエラーが発生し、特にＤＮＳゾーンファイルのサイズが大きくなるにつれて、ＤＮＳゾーンファイルの更新などに多くの時間がかかるようになる。

本発明では、このような問題点を解決するために、権威ＤＮＳサーバー１２０が接続される別個のユーザーＤＮＳサーバー１３０をさらに含む。

ユーザーＤＮＳサーバー１３０は、ＤＮＳサービスの提供を受けようとするユーザーがＤＮＳゾーンファイルの原本をアップロードすることが可能なサーバーである。

すなわち、ＤＮＳサーバーという名称を使用しているが、これは説明の便宜のための名称の付与に過ぎず、ＤＮＳゾーンファイルの原本のアップロードを可能とする別個のサーバーであれば、本発明に係るユーザーＤＮＳサーバー１３０に含まれ得る。

一方、従来は、ＤＮＳサービスの提供を受けようとするユーザーに別個のサーバーが提供されない或いは提供される場合でも、単にＤＮＳゾーンファイルを含むＤＮＳ情報の比較およびバックアップのための用途に過ぎず、権威ＤＮＳサーバー１２０に接続されなかった。

しかし、本発明では、図１に示すように、ユーザーＤＮＳサーバー１３０は権威ＤＮＳサーバー１２０に接続される。

一方、本発明に係る権威ＤＮＳサーバー１２０が、ローカルＤＮＳサーバー１１０から受信される、或いはローカルＤＮＳサーバー１１０から他のＤＮＳサーバーを経て受信されるＤＮＳ解決要求に対して権威ＤＮＳサーバー１２０として機能するためには、ドメイン名登録事業者を介して、本発明による権威ＤＮＳサーバーが該当ドメインのａｕｔｈｏｒｉｔａｔｉｖｅ ＮＳ（Ｎａｍｅ Ｓｅｒｖｅｒ）として指定されることが必要であるが、これに限定されない。

このような構成を持つ本発明に係るＤＮＳシステムでＤＮＳサービスが提供されることを、従来のＤＮＳサービスと比較して考察する。

まず、従来のＤＮＳサービスは、クライアント１００からローカルＤＮＳサーバー１１０へドメイン名解決要求を伝送すると、ローカルＤＮＳサーバー１１０は、権威ＤＮＳサーバー１２０へドメイン名解決要求をフォワードし、権威ＤＮＳサーバー１２０は、予め保存されたＤＮＳゾーンファイル情報に基づいてＩＰアドレスをローカルＤＮＳサーバー１１０へ伝送し、これをさらにクライアント１００へフォワードすることにより、クライアント１００は所望のサーバー（図示せず）に接続することになる。

一方、このような従来のＤＮＳシステムにおいて、ＤＮＳゾーンファイルは、権威ＤＮＳサーバー１２０に予めすべて保存されていてこそＤＮＳサービスの提供が可能となる。

特に、ＤＮＳゾーンファイルは、特定のドメイン名の一部を説明するデータが含まれているファイルであって、ＤＮＳゾーンファイルには、ドメイン名をＩＰ数字に分解するために必要な情報、すなわち、ドメイン名およびそれに関連付けられているサブドメイン、ＩＰアドレス、メールサーバー情報などが含まれる。

このようなＤＮＳゾーンファイルは、例えば、次のとおり構成できる。

ＤＮＳゾーンファイルの構成において、まず、＄ＴＴＬｘｘｘにおけるｘｘｘは、数字であって、サーバーに存在するＤＮＳゾーンファイルの有効時間を秒単位で表現したものである。

＠は、ドメインを意味するもので、ｎａｍｅｄ．ｃｏｎｆファイルに設定されているドメイン名を意味する。

ＩＮ ＳＯＡネームサーバー．管理者メールは、該当ドメインに対して記録されたネームサーバーがすべての情報を持っていることを宣言する構文である。

ネームサーバー部分にはｎｓ．ｄｎｓ．ｃｏｍのようにネームサーバーアドレスを記録し、その次には管理者のメールアドレスを記録することになる。

ｘｘｘ；ｓｅｒｉａｌ（ｄ．ａｄａｍｓ）において、ｘｘｘは一般に日付形式で記載され、ゾーンファイルに対する一種の識別番号として認識される。

ｘＨ；ｒｅｆｒｅｓｈは、下位（２次）ネームサーバーから上位（１次）ネームサーバーに変更された内容があるかをチェックする周期であり、ｘｘＭ；ｒｅｔｒｙは、２次ネームサーバーから１次ネームサーバーへのアクセスができない場合、引き続きアクセスの試みを続ける周期を設定しておいた時間である。

ｘＷ；ｅｘｐｉｒｙ２次ネームサーバーから１次ネームサーバーへ周期的に確認したが、接続されていないときに該当ドメインが削除または破棄されたと判断する時間である
ｘＤ）；ｍｉｎｉｍｕｍはＴＴＬと同じ意味であり、ＩＮ ＮＳネームサーバーのアドレスは該当ドメインのネームサーバーを指定するレコードであり、ｗｗｗ ＩＮ Ａ ＩＰ ＡＤＤＲＥＳＳ、ｆｔｐ ＩＮ Ａ ＩＰ ＡＤＤＲＥＳＳ、ｍａｉｌ ＩＮ Ａ ＩＰ ＡＤＤＲＥＳＳなどは該当ドメインの実際アドレスを示すレコードである。

このような構成を持つＤＮＳゾーンファイルは、ＤＮＳゾーンファイルに含まれている情報によってＤＮＳサービスの提供が可能になり、このようなＤＮＳゾーンファイルは、ＤＮＳサービスを利用しようとするユーザーによって設定される。

従来のＤＮＳシステムにおいて、もし権威ＤＮＳサーバー１２０が多数存在する場合であれば、ユーザーがどこでも同じサービスの提供を受けるためには、すべての権威ＤＮＳサーバー１２０に同じＤＮＳゾーンファイルが存在しなければならない。

権威ＤＮＳサーバー１２０の個数が１つであるか或いはその個数が多くない場合には、権威ＤＮＳサーバー１２０にＤＮＳゾーンファイルを追加または変更することが比較的簡単であった。よって、ＤＮＳサービスにも大きな影響を及ぼさなかった。

しかし、最近のネットワークの構成が複雑になるにつれて、権威ＤＮＳサーバー１２０の個数が増加し、また、ＤＮＳゾーンファイルのサイズ自体も増加するにつれて、権威ＤＮＳサーバー１２０にＤＮＳゾーンファイルを追加または変更するのに多くの時間がかかり、ＤＮＳゾーンファイルの追加や変更などが行われる間、ＤＮＳサービスがまともに行われないこともある。

特にしばらく前に発生した有名なポータルサイトへの接続エラーがＤＮＳゾーンファイルの交替によるＤＮＳサービスのエラーであると明らかになっているほど、ＤＮＳゾーンファイルの追加または変更の際にＤＮＳサービスのエラーが発生する可能性が高い。

一方、このようなＤＮＳゾーンファイルは、ドメイン名とＩＰアドレスとをマッチさせるＤＮＳルックアップ（ｌｏｏｋ−ｕｐ）テーブルとは異なる情報である。

ＤＮＳルックアップテーブルに関して、ドメイン名解決要求を受信したＤＮＳサーバーが、ＤＮＳルックアップテーブルがない場合には、上位のＤＮＳサーバーまたは他のＤＮＳサーバーからＤＮＳルックアップテーブル情報を受信してドメイン名解決要求に応答し、ＤＮＳルックアップテーブルを一時保存するキャッシュ（ｃａｃｈｅ）機能を行う。

本発明では、ＤＮＳゾーンファイル、特にＤＮＳゾーンファイル全部ではなく、ＤＮＳゾーンファイルの一部に対しても、ＤＮＳルックアップテーブルの場合と同様に他のＤＮＳサーバーから受信することを可能にしてＤＮＳゾーンファイルの追加や変更などに能動的に対処できるようにする。

このため、ＤＮＳゾーンファイルのうち、ＤＮＳ解決要求に対して応答できるようにする最小限の情報を含むホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）のみを、ドメイン名解決要求が受信されるときにのみユーザーＤＮＳサーバー１３０または他の権威ＤＮＳサーバーから受信するようにするのである。

つまり、権威ＤＮＳサーバー１２０とユーザーＤＮＳサーバー１３０を接続し、権威ＤＮＳサーバー１２０はドメイン名解決要求が受信されると、該当ドメインに対するＤＮＳゾーンファイルのうちホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）のみを、該当ドメインに対するユーザーＤＮＳサーバー１３０を検索して該当ユーザーＤＮＳサーバー１３０に接続して、持ってくるようにする。

また、複数の権威ＤＮＳサーバー１２０が存在する場合、他の権威ＤＮＳサーバー１２０に接続し、該当ドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して受信することも可能である。

ホストレコードは、ＤＮＳゾーンファイルの一部であって、ＤＮＳゾーンファイルと同様に、ドメイン名、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス情報、ＴＴＬ、クラス、およびその他の属性から構成できる。

このようなホストレコードの集合がＤＮＳゾーンファイルであり、例えば、ｆｏｏ．ｃｏｍというドメイン名に対するホストは、ｍａｉｌ．ｆｏｏ．ｃｏｍ、ｐｉｃｔｕｒｅ．ｆｏｏ．ｃｏｍ、ｖｉｄｅｏ．ｆｏｏ．ｃｏｍなどのように様々に構成できる。

したがって、ＤＮＳゾーンファイルはこのようなホストレコードの集合で構成され、本発明では、ＤＮＳ解決要求が受信されたホストに対するホストレコードのみをユーザーＤＮＳサーバー１３０または他の権威ＤＮＳサーバー１２０から受信するのである。

特に、ＤＮＳゾーンファイルの場合、ドメイン名に関連するすべてのゾーンに対する情報を含んでいるが、これに対し、本発明では、ＤＮＳ解決要求を受信したドメインに対してのみＤＮＳゾーンファイルの一部であるホストレコードを受信するようにして、送受信されるべきデータの量も減らすことになる。

また、受信したホストレコードを権威ＤＮＳサーバー１２０に一時保存するようにするキャッシュ機能を行うようにすることにより、権威ＤＮＳサーバー１２０がＤＮＳゾーンファイルを常に保持していなければならない必要がないようにする。

そして、ＤＮＳゾーンファイルの場合にも、特定のドメイン名全体に対してＤＮＳゾーンファイル単位で受信し、これをキャッシュするのではなく、ドメイン名解決要求に関連するホストレコード単位でデータを受信し、これをキャッシュすることになる。

例えば、前述した例示の如く、ｆｏｏ．ｃｏｍドメインに対するＤＮＳサービス利用者がいる場合は、ｍａｉｌ．ｆｏｏ．ｃｏｍ、ｐｉｃｔｕｒｅ．ｆｏｏ．ｃｏｍ、ｖｉｄｅｏ．ｆｏｏ．ｃｏｍなどの様々なホスト名が存在しうる。

たとえば、ローカルＤＮＳサーバー１１０を介して受信されたドメイン名解決要求がそれらの中の一つに対するものであれば、ｆｏｏ．ｃｏｍドメインに対するユーザーＤＮＳサーバー１３０または他の権威ＤＮＳサーバー１２０から前記それらの中の一つに対するホストレコードのみを受信してＤＮＳ解決要求に応答し、選択的に権威ＤＮＳサーバー１２０に保存するようにするのである。

一方、ＤＮＳゾーンファイルのうち、ＤＮＳ解決に必要な情報のみから構成されるホストレコードの場合でも、ＤＮＳルックアップテーブルと同様に他の装置から受信し、これを一時保存するキャッシュ機能を行うようにする場合、権威ＤＮＳサーバー１２０からユーザーＤＮＳサーバー１３０または他の権威ＤＮＳサーバー１２０に接続してホストレコードを受信することによる時間的遅延が発生しうる。

しかし、権威ＤＮＳサーバー１２０がホストレコードを要求するユーザーＤＮＳサーバー１３０と他の権威ＤＮＳサーバー１２０との間のネットワークが専用網を使用するか、物理的に非常に近接するようにするなど、ホストレコードの要求および受信に多くの時間がかからなければ、このような時間的遅延は大きく発生しない。

これに対し、最近のネットワークはその構成が複雑になり、全世界的なネットワークとして構成されるため、権威ＤＮＳサーバー１２０の個数およびＤＮＳゾーンファイルのサイズが増加することにより、権威ＤＮＳサーバー１２０には大量のデータを保存する必要がなく、ＤＮＳゾーンファイルの追加や変更などに迅速な対処が可能であるという利点がある。

一方、ユーザーＤＮＳサーバー１３０の場合、ドメイン名ユーザーに応じてそれぞれ構成するか、或いは１つのサーバーを多数のドメイン名ユーザーが利用するようにすることも可能である。

そして、権威ＤＮＳサーバー１２０が数多くのドメイン名に対してすべてのホストレコードを保存する場合、たとえＤＮＳゾーンファイル全体ではないとしても、結局、権威ＤＮＳサーバー１２０に保存されるデータの量は増加することになる。

したがって、権威ＤＮＳサーバー１２０は、ＤＮＳ解決要求を受信したドメイン名に対するホストレコードのみを、ユーザーＤＮＳサーバー１３０または他の権威ＤＮＳサーバー１２０から受信して保存するようにすることにより、権威ＤＮＳサーバー１２０に保存されるべきデータの量をさらに減らすことができる。

一方、もはやＤＮＳ解決要求が受信されないドメイン名に対しては、ホストレコードを削除することが好ましい。

このため、ホストレコードに含まれているＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）を用いて、保存されたホストレコードが一定の時間経過すると自動的に削除されるようにし、また、ＤＮＳ解決要求に対して応答するときにホストレコードの有効性を判断することができる。

こうすることにより、権威ＤＮＳサーバー１２０は、多くのデータを保存する必要がなく、また、ＤＮＳゾーンファイルの変更などにも効果的に対応できるようにすることが可能となる。

そして、ユーザーＤＮＳサーバー１３０で、ｐｕｒｇｅ命令などを介して権威ＤＮＳサーバー１２０からのホストレコードの一括的な削除なども可能なので、ＤＮＳゾーンファイルの削除などにも効果的に対応できることになり、ＤＮＳサービスが一層効果的に提供されるようにすることが可能となる。

以下、図２を参照して、本発明の好適な一実施形態に係るＤＮＳサービス提供方法が提供される順序を考察する。

本発明の好適な一実施形態に係るＤＮＳサービス提供方法は、権威ＤＮＳサーバー１２０における処理過程を中心に説明する。

図２は本発明の好適な一実施形態に係るＤＮＳサービス提供方法が適用される順序を示すフローチャートである。図２に示すように、本発明の好適な一実施形態に係るＤＮＳサービス提供方法は、まずローカルＤＮＳサーバー１１０からドメイン名解決要求を受信する（Ｓ２００）。

このようなドメイン名解決要求はクライアント１００からローカルＤＮＳサーバーを介して受信されるのである。

もちろん、ローカルＤＮＳサーバー１１０を経ることなく直接クライアント１００が権威ＤＮＳサーバー１２０に接続してドメイン名解決要求を行うことも可能であるが、ネットワーク構成の特性上、このような場合はほとんどないため、このような場合については説明を省略する。

ドメイン名解決要求が受信されると、該当ドメインに対するユーザーＤＮＳサーバー１３０を検索し、該当ドメインのユーザーＤＮＳサーバー１３０からＤＮＳゾーンファイルのうちＤＮＳ解決に必要なホストレコードのみを要求して受信する（Ｓ２０２）。

該当ドメインに対するユーザーＤＮＳサーバー１３０の検索は、権威ＤＮＳサーバー１２０が多数のドメインに対してドメイン名解決要求を行うことができる場合であればユーザーＤＮＳサーバー１３０も複数個が存在しうるので、これを仮定した上でのことである。

したがって、権威ＤＮＳサーバー１２０が一つのドメインに対してのみドメイン名解決要求を行う場合であれば、ユーザーＤＮＳサーバー１３０を検索する過程は必要でないことがある。

一方、受信されたホストレコードを用いてドメイン名解決要求に対する応答をローカルＤＮＳサーバー１１０へ伝送する（Ｓ２０４）。

ドメイン名解決要求に対する応答を受信したローカルＤＮＳサーバー１１０はこれをクライアント１００へ伝送し、これにより、クライアント１００は特定のコンテンツサーバーに接続することができることになる。

一方、図２では示していないが、前述したように権威ＤＮＳサーバーがホストレコードを受信する場合、権威ＤＮＳサーバーは受信したホストレコードを一時保存するキャッシュ機能を行うことができる。

前述したように、権威ＤＮＳサーバーに保存される時間、すなわち有効時間は、ホストレコードに含まれているＴＴＬに基づいて決定できる。

一方、このような本発明に係るＤＮＳサービス提供方法は、プログラムの形で実現できるのは自明である。

以下、図３を参照して、本発明の好適な一実施形態に係るＤＮＳサービス提供装置である権威ＤＮＳサーバー１２０の構成について考察する。

一方、前述したように、権威ＤＮＳサーバー１２０は、ローカルＤＮＳサーバー１１０とは異なり、上位のＤＮＳサーバーであって、ＤＮＳ解決要求に対して他のＤＮＳサーバーへＤＮＳ解決要求を伝達せずに応答することができなければならない。

このため、ドメイン名登録事業者を介して、本発明に係る権威ＤＮＳサーバー１２０が該当ドメインのａｕｔｈｏｒｉｔａｔｉｖｅ ＮＳ（Ｎａｍｅ Ｓｅｒｖｅｒ）として指定されることが必要であるが、これに限定されず、他の設定または方法によって該当ドメインのａｕｔｈｏｒｉｔａｔｉｖｅ ＮＳ（Ｎａｍｅ Ｓｅｒｖｅｒ）として指定されるようにすることも可能であるのは自明である。

図３は本発明の好適な一実施形態に係るＤＮＳサービス提供装置である権威ＤＮＳサーバー１２０の構成を示す図である。図３に示すように、本発明の好適な一実施形態に係るＤＮＳサービス提供装置は、保存部３００および通信部３１０を含むことができる。

保存部３００は、ユーザーＤＮＳサーバー情報保存部３０２、ホストレコード保存部３０４、およびＤＮＳルックアップテーブル保存部３０６を含んで構成できる。

ユーザーＤＮＳサーバー情報保存部３０２は、ドメイン名ユーザーが複数であり、ＤＮＳゾーンファイルがアップロードされるユーザーＤＮＳサーバー１３０がそれぞれ存在する場合、ドメイン名および該ドメイン名にマッチするユーザーＤＮＳサーバー１３０情報が保存される。

ホストレコード保存部３０４は、ユーザーＤＮＳサーバー１３０または他の権威ＤＮＳサーバー１２０から、ＤＮＳゾーンファイルのうちＤＮＳ解決要求に必要な情報のみから構成されるホストレコードを要求して受信されるホストレコードが保存される。

ホストレコードは、前述したように、権威ＤＮＳサーバー１２０に継続的に保存されるのではなく、ホストレコードに含まれているＴＴＬに基づいて一時的に保存されることが好ましい。

ホストレコードは、ＤＮＳ解決に必要な情報のみからなり、公知の如く、ＤＮＳゾーンファイルの一部であって、ドメイン名、ＩＰ、ＴＴＬ、クラス、およびその他の属性から構成できる。

ＤＮＳルックアップテーブル保存部３０６は、ドメイン名、およびドメイン名にマッチするサーバーのＩＰアドレスが保存される。

ＤＮＳルックアップテーブルの場合も、上位ＤＮＳサーバーまたは他のＤＮＳサーバーからＤＮＳルックアップテーブルを要求し、これを受信して保存されるようにすることも可能であり、ホストレコードと同様に一時的に保存されるようにすることも可能である。

通信部３１０は、通信網を介してローカルＤＮＳサーバー１１０、ユーザーＤＮＳサーバー１３０、および他の権威ＤＮＳサーバー１２０と通信する。一方、本発明の好適な一実施形態に係るＤＮＳサービス提供装置は、本発明によるＤＮＳサービス提供方法をプログラムの形で実現し、プログラムがインストールされたサーバーなどのデジタル処理装置の形で実現することもできるのは自明である。

前述した本発明の好適な実施形態は例示の目的のために開示されたものに過ぎない。当該分野における通常の知識を有する者であれば、本発明の思想および範囲内において様々な修正、変更および付加を加えることが可能であり、それらの修正、変更および付加も下記の特許請求の範囲に属すると理解すべきである。

Claims (13)

1. クライアント、ローカルＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー、権威ＤＮＳ（ａｕｔｈｏｒｉｔａｔｉｖｅ ＤＮＳ）サーバーおよびユーザーＤＮＳサーバーを含むＤＮＳシステムで前記権威ＤＮＳサーバーによって行われるＤＮＳサービス提供方法において、
   前記ローカルＤＮＳサーバーからドメイン名解決要求を受信する段階と、
   前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階と、
   前記受信されたホストレコードを用いて前記ドメイン名解決要求に対する応答を前記ローカルＤＮＳサーバーへ伝送する段階とを含んでなることを特徴とする、ＤＮＳサービス提供方法。
2. 前記ＤＮＳシステムは複数の権威ＤＮＳサーバーを含み、
   前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階は、
   前記ユーザーＤＮＳサーバーの代わりに、前記複数の権威ＤＮＳサーバーのうち他の権威ＤＮＳサーバーから前記ホストレコードを要求して受信することを特徴とする、請求項１に記載のＤＮＳサービス提供方法。
3. 前記ホストレコードは、ドメイン名、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス情報、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）情報を含むことを特徴とする、請求項１に記載のＤＮＳサービス提供方法。
4. 前記受信されたホストレコードは、前記ＴＴＬ情報に基づいて一時的に前記権威ＤＮＳサーバーに保存されることを特徴とする、請求項３に記載のＤＮＳサービス提供方法。
5. 前記ＤＮＳシステムは複数のユーザーＤＮＳサーバーを含み、
   前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求することは、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバーを検索し、前記検索されたユーザーＤＮＳサーバーに対して要求することを特徴とする、請求項１に記載のＤＮＳサービス提供方法。
6. 前記権威ＤＮＳサーバーは、ドメイン名にマッチするＩＰアドレスを含むＤＮＳルックアップテーブル（ｌｏｏｋ−ｕｐ ｔａｂｌｅ）情報をさらに含み、
   前記受信されたホストレコードを用いて前記ドメイン名解決要求に対して応答することは、前記ＤＮＳルックアップテーブルからマッチするＩＰアドレスを選択して応答することを特徴とする、請求項１に記載のＤＮＳサービス提供方法。
7. クライアント、ローカルＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバーおよびユーザーＤＮＳサーバーを含むＤＮＳシステムに含まれてＤＮＳサービスを提供する装置において、
   前記ローカルＤＮＳサーバーからドメイン名解決要求を受信し、前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して受信し、前記受信されたホストレコードを用いて前記ドメイン名解決要求に対する応答を前記ローカルＤＮＳサーバーへ伝送する通信部と、
   前記ユーザーＤＮＳサーバーから受信された前記ホストレコードを保存するホストレコード保存部とを含んでなることを特徴とする、ＤＮＳサービス提供装置。
8. 前記ＤＮＳシステムは前記ＤＮＳサービス提供装置を複数含み、
   前記通信部が前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して受信することは、前記ユーザーＤＮＳサーバーの代わりに他のＤＮＳサービス提供装置から前記ホストレコードを要求して受信することを特徴とする、請求項７に記載のＤＮＳサービス提供装置。
9. 前記ホストレコードはドメイン名、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス情報、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）情報を含むことを特徴とする、請求項７に記載のＤＮＳサービス提供装置。
10. 前記受信されたホストレコードは前記ＴＴＬ情報に基づいて一時的に前記保存部に保存されることを特徴とする、請求項９に記載のＤＮＳサービス提供装置。
11. 前記ＤＮＳシステムは複数のユーザーＤＮＳサーバーを含み、
    前記保存部は、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバー情報をさらに保存し、
    前記ユーザーＤＮＳサーバーから前記ホストレコードを要求することは、前記ドメイン名解決要求が受信されたドメイン名にマッチするユーザーＤＮＳサーバーを検索し、前記検索されたユーザーＤＮＳサーバーに対して要求することを特徴とする、請求項７に記載のＤＮＳサービス提供装置。
12. 前記保存部は、ドメイン名にマッチするＩＰアドレスを含むＤＮＳルックアップテーブル（ｌｏｏｋ−ｕｐ ｔａｂｌｅ）情報をさらに保存し、
    前記受信されたホストレコードを用いて前記ドメイン名解決要求に対して応答することは、前記ＤＮＳルックアップテーブルからマッチするＩＰアドレスを選択して応答することを特徴とする、請求項７に記載のＤＮＳサービス提供装置。
13. クライアント、ローカルＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー、権威ＤＮＳ（ａｕｔｈｏｒｉｔａｔｉｖｅ ＤＮＳ）サーバーおよびユーザーＤＮＳサーバーを含むＤＮＳシステムで前記権威ＤＮＳサーバーによって行われるＤＮＳサービス提供方法を実現するためのプログラムを記録した記録媒体において、
    前記ローカルＤＮＳサーバーからドメイン名解決要求を受信する段階と、
    前記ユーザーＤＮＳサーバーから前記受信されたドメイン名解決要求のドメインに対するホストレコード（ｈｏｓｔ ｒｅｃｏｒｄ）を要求して前記ホストレコードを受信する段階と、
    前記受信されたホストレコードを用いて前記ドメイン名解決要求に対する応答を前記ローカルＤＮＳサーバーへ伝送する段階とを含んでなることを特徴とする、ＤＮＳサービス提供方法を実現するためのプログラムを記録した記録媒体。

Images