ネームサーバデータベースのリソースレコードを更新する方法および装置
本発明の実施形態は、ネームサーバデータベースのリソースレコードを更新するシステムにある。システムの動作時に、ネットワークノードは、リソースレコード更新の集合と、ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースとが入っている更新要求メッセージを生成する。次に、ネットワークノードは、更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送る。ネットワークノードは、次いで、ネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネームサーバから受け取る。
【発明の詳細な説明】
【技術の分野】
【０００１】
本発明は、ネームサーバデータベースを更新するプロセスに関する。より詳しくは、本発明は、ネームサーバに更新要求メッセージを送ることによってネームサーバデータベース中のリソースレコードを更新する方法および装置であって、その更新要求メッセージが、ネームサーバがリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースを含む方法および装置に関する。
【背景技術】
【０００２】
ドメインネームシステム（ＤＮＳ）は、グローバルネーミングサービスを提供する分散システムである。他の多くのサービスと同様、ＤＮＳは、基本的にグローバルネーム空間がまれにしか変化しないと予期される静的ネットワーク用に設計されたものである。変化の頻度がかなり低いと思われたため、ＤＮＳは動的更新を処理するようには設計されなかった。
【０００３】
その後、ＤＮＳは動的更新をサポートするよう拡張された。ＩＥＴＦ（インターネット技術標準化委員会）のＲＦＣ（リクエスト・フォア・コメント）２１３６には、ＤＮＳが動的更新を処理できるようにするＤＮＳへの拡張が規定されている。この拡張規定では、ラップトップコンピュータのようなネットワークノードはＤＮＳネームサーバに明示的更新情報を提供する必要がある旨規定されている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
不都合なことには、この拡張により、ＤＮＳネームサーバに古くなった情報が入っている状態が起こり得る。例えば、モバイルユーザのラップトップコンピュータがＤＮＳネームサーバを動的更新によって更新する場合を考えてみる。この場合、それらの更新は明示的に削除されるまでＤＮＳネームサーバに残存し続けるということに注意すべきである。例えば、ユーザが明示的に更新を削除することなくラップトップコンピュータをネットワークから切り離したとすると、それらの更新は、ＤＮＳネームサーバ上にいつまでも残り続けることになる。このことは、ＤＮＳネームサーバデータベースに古くなった情報が入っている状態を引き起こし、その結果ＤＮＳネームサーバデータベースの正確さと有効性が減じられるため、重大な問題になり得る。
【０００５】
「ＤＮＳ清掃」法は、上記の問題を解決しようとする一つの試みである。「ＤＮＳ清掃」法では、ラップトップコンピュータのようなクライアントネットワークノードとＤＮＳネームサーバを、プリセットされたリフレッシュ間隔でコンフィギュレーションする。不都合なことに、この方法は、ラップトップコンピュータとＤＮＳネームサーバの両方を互換性のあるリフレッシュ間隔でコンフィギュレーションする場合に限って有効であり、それは両方が同一管理下にある場合にしか確実に達成することはできない。多くの状況において、ラップトップコンピュータとＤＮＳネームサーバは異なる管理下にある。それ故、「ＤＮＳ清掃」法はその利用が極めて限定される。
【０００６】
したがって、上記のような欠点を解消したネームサーバデータベースを動的に更新する方法および装置が必要とされている。
【課題を解決するための手段】
【０００７】
本発明の実施態様では、ネームサーバデータベースのリソースレコードを更新するシステムを提供する。システムの動作時に、ネットワークノードは、リソースレコード更新の集合と、ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースとが入っている更新要求メッセージを生成する。次に、ネットワークノードは、この更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送る。その後、ネットワークノードはネームサーバからネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージを受け取る。
【０００８】
この実施態様の変形例においては、ネームサーバは、リソースレコード更新の集合と、ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースとが入っているネットワークノードからの更新要求メッセージを受け取る。次に、ネームサーバは、その更新要求メッセージに入っている情報を用いてネームサーバデータベース中のリソースレコードを更新する。その後、ネームサーバは、ネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネットワークノードへ送る。
【０００９】
この実施態様のもう一つの変形例においては、許可リースが期限切れになると、ネームサーバは更新済みリソースレコードをネームサーバデータベースから削除することによって、古くなった情報を取り除くことによりグローバルネーム空間を常に最新の状態に保つ。
【００１０】
この実施態様のもう一つの変形例においては、リソースレコード更新の集合は、ＤＮＳ（ドメインネームシステム）リソースレコードを含まないかあるいは１以上のＤＮＳリソースレコードを含むことが可能である。
【００１１】
この実施態様のもう一つの変形例においては、更新要求メッセージは、更新済みリソースレコードについてのカレントリースを延長する要求をなす更新リフレッシュメッセージとすることができる。
【００１２】
この実施態様のもう一つの変形例においては、更新リフレッシュメッセージは、ネームサーバをして更新済みリソースレコードについてのカレントリースを許可させた先行の更新要求メッセージと同じである。
【００１３】
この実施態様のもう一つの変形例においては、ネットワークノードがネームサーバから指定時間内に応答メッセージを受け取らなかった場合、更新要求メッセージをネームサーバへ再送する。
【００１４】
この実施態様のもう一つの変形例においては、ネットワークノードとネームサーバはＵＤＰ（ユーザデータグラムプロトコル）を用いて相互に通信する。
【００１５】
この実施態様のもう一つの変形例においては、ネットワークノードとネームサーバはＴＣＰ（伝送制御プロトコル）を用いて相互に通信する。
【００１６】
この実施態様のもう一つの変形例においては、ネームサーバはドメインネームシステム（ＤＮＳ）に属する。
【発明を実施するための最良の形態】
【００１７】
以下、本発明を当業者が実施することができるよう詳細に説明するが、説明は特定の利用形態とその要求事項との関連において行う。当業者にとっては、本願開示の実施形態について様々な修正・変更態様が自明であり、本願中に明確に記載する基本原理は、本発明の精神と範囲を逸脱することなく他の実施や利用の形態に適用することが可能である。したがって、本発明は、本願で説明する実施形態に限定されず、本願に開示する原理や特徴に合致する最大の範囲を許可されるべきものである。
【００１８】
この詳細な説明に記載するデータ構造とコードは、通常、コンピュータ可読記憶媒体に記憶される。この記憶媒体としては、コンピュータシステムで使用するコードおよび／またはデータを記憶することができる任意のデバイスあるいは媒体を用いることが可能である。このような記憶媒体としては、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）とＤＶＤ（デジタル多目的ディスクまたはデジタルビデオディスク）のような磁気記憶装置や光記憶装置、さらには伝送媒体の形で実施されるコンピュータ命令信号（これらの信号を上に重ねることにより変調する搬送波の有無を問わない）があるが、これらに限定されるものではない。この伝送媒体としては、例えば、インターネットのような通信ネットワークがある。
ネットワーク
【００１９】
図１は、本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ１０２、ＤＮＳ（ドメインネームシステム）ネームサーバ１０６、ラップトップコンピュータ１０８に接続されたネットワーク１０４を図解して示す概略図である。
【００２０】
ネットワーク１０４は、全般的に、ネットワークノードを互いに結合することができる任意の種類の有線または無線の通信チャンネルを含む。このような通信チャンネルとしては、ローカルエリアネットワーク、ワイドエリアネットワーク、あるいはネットワークを組合せた形のものがあるが、これらに限定されるものではない。本発明の一実施形態においては、ネットワーク１０４はインターネットを含む。
【００２１】
コンピュータ１０２のようなネットワークノードは、全般的に、ネットワークを介して他のネットワークノードと通信することができる任意の種類の通信デバイスを含む。このような通信デバイスとしては、マイクロプロセッサに基づくコンピュータシステム、メインフレームコンピュータ、サーバ、プリンタ、ビデオカメラ、外部ディスクドライブ、ルータ、交換機、電子手帳、携帯電話があるが、これらに限定されるものではない。
【００２２】
ネットワーク１０４は、コンピュータ１０２のようなソースネットワークノードがラップトップコンピュータ１０８のようなターゲットネットワークノードと通信することを可能にする。しかし、通信が行われるには、まずその前にソースネットワークノード、すなわちコンピュータ１０２がターゲットネットワークノード、すなわちラップトップコンピュータ１０８のＩＰアドレスを知ることが必要である。通常、コンピュータ１０２は、ＤＮＳネームサーバ１０６に問い合わせることによりラップトップコンピュータ１０８の名前を対応するＩＰアドレスに変換する。
ＤＮＳ更新パケットの構造
【００２３】
図２は、本発明の一実施形態において、コンピュータ１０２のようなネットワークノードがそれを使ってＤＮＳネームサーバ１０６と情報を交換することができる多様な情報片が入ったＤＮＳ更新パケット２００を示す説明図である。
【００２４】
更新要求メッセージと応答メッセージは共に同じＤＮＳ更新パケット２００のフォーマットを使用する。具体的に言うと、ＤＮＳ更新パケット２００中には、コンピュータ１０２のようなネットワークノードが更新要求を対応する応答と合致させることを可能にする識別フィールド２０２が入っている。また、ＤＮＳ更新パケット２００中には、とりわけＤＮＳ更新パケットが更新要求であるか応答であるかを指示するフラグフィールド２０４も入っている。
【００２５】
さらに、ＤＮＳ更新パケット２００中には、４つの可変長フィールド、すなわちゾーンフィールド２１４、先要リソースレコードフィールド２１６、更新リソースレコードフィールド２１８、追加データリソースレコードフィールド２２０が入っている。これらの可変長フィールドは、ネットワークノード、すなわちコンピュータ１０２とＤＮＳネームサーバ１０６との間で情報を交換するために使用される。
【００２６】
上記の他、ＤＮＳ更新パケット２００中には、さらに４つのフィールド、すなわち上記４つの可変長フィールドのエントリの番号をそれぞれ指定するゾーン番号フィールド２０６、先要リソースレコード番号フィールド２０８、更新リソースレコード番号フィールド２１０、追加データリソースレコード番号フィールド２１２が入っている。
ゾーンフィールドの構造
【００２７】
図３は、本発明の一実施形態において、ゾーンフィールド２１４に入っているゾーン３００の構造を示す説明図である。ゾーン３００には、リソースレコード更新のゾーン名を指定するゾーン名フィールド３０２が入っている。さらに、ゾーン３００には、ゾーン３００のタイプとクラスをそれぞれ指定するゾーンタイプフィールド３０４とゾーンクラスフィールド３０６が入っている。
リソースレコードの構造
【００２８】
図４は、本発明の一実施形態にしたがって、ＤＮＳネームサーバ１０６と情報を交換するために、コンピュータ１０２のようなネットワークノードによって用いられるリソースレコード４００の構造を示す説明図である。
【００２９】
具体的に言うと、リソースレコード４００には、考えているドメイン名を指定するドメイン名フィールド４０２が入っている。また、リソースレコード４００には、リソースレコードのタイプとクラスをそれぞれ指定するリソースレコードタイプフィールド４０４とリソースレコードクラスフィールド４０６も入っている。
【００３０】
上記の他、リソースレコード４００には、さらに、リソースレコードをコンピュータ１０２のようなネットワークノードによりキャッシュすることができる時間の長さ（秒）を指定する有効時間（ＴＴＬ）フィールド４０８が入っている。
【００３１】
さらに、リソースレコード４００は、ＤＮＳネームサーバ１０６と情報を交換するために、コンピュータ１０２のようなネットワークノードによって使用される可変長フィールドであるリソースデータフィールド４１２を含む。また、リソースレコード４００は、可変長リソースデータフィールド４１２中のデータ量を指定するリソースデータ長フィールド４１０も含む。
リースを指定するリソースデータフィールドの構造
【００３２】
図５は、本発明の一実施形態において、リースを指定するリソースデータフィールド４１２の構造を示す説明図である。
【００３３】
具体的に言うと、リソースデータフィールド４１２には、リソースデータのタイプを指定するオプションコードフィールド５０２が入っている。また、リソースデータフィールド４１２には、リースフィールド５０６も入っている。ここで留意しなければならないのは、リースフィールド５０６は、ネットワークノード１０２がこれを用いてリースを要求し、かつＤＮＳネームサーバ１０６がこれを使ってリースを許可するということである。さらに、リソースデータフィールド４１２には、リースフィールド５０６の長さを指定するオプションコードフィールド５０４が入っている。
【００３４】
さらに、リソースデータフィールド４１２は、ＩＥＴＦ ＲＦＣ２６７１に規定されたＯＰＴ疑似ＲＲ（疑似リソースレコード）の中に入っている。ここで留意しなければならないのは、ＩＥＴＦ ＲＦＣ２６７１は、新しいリソースレコードのデータタイプを定義するメカニズムについて規定しているということである。さらに、ＯＰＴ疑似ＲＲは、ＤＮＳ更新パケット２００中の追加データリソースレコードフィールド２２０中に入っている。
リソースレコードを更新するプロセス
【００３５】
図６は、本発明の一実施形態において、リソースレコードを更新するプロセスを図解したフローチャートである。
【００３６】
このプロセスは、例えば、ラップトップコンピュータ１０８のようなネットワークノードがネットワーク１０４に参加するとき開始される。まず、ラップトップコンピュータ１０８が、リソースレコード更新の集合および要求リースが入っている更新要求メッセージを生成する（ステップ６０２）。
【００３７】
ここで留意しなければならないのは、更新要求メッセージにはＤＮＳ更新パケット２００が入っているということである。さらに、リソースレコード更新は、ＤＮＳ更新パケット２００の更新リソースレコードフィールド２１８で指定されている。かつ、要求リースは、リソースデータフィールド４１２に入っているリースフィールド５０６で指定されている。なおまた、リソースデータフィールド４１２は、ＤＮＳ更新パケット２００の追加データリソースレコードフィールド２２０中に入っている。
【００３８】
次に、ラップトップコンピュータ１０８は更新要求メッセージをＤＮＳネームサーバ１０６へ送る（ステップ６０４）。ここで留意しなければならないのは、ラップトップコンピュータ１０８はＵＤＰ（ユーザデータグラムプロトコル）またはＴＣＰ（伝送制御プロトコル）使用して更新要求メッセージと応答メッセージをＤＮＳネームサーバ１０６と交換することができるということである。
【００３９】
次に、ＤＮＳネームサーバ１０６は更新要求メッセージを受け取る（ステップ６０６）。次いで、ＤＮＳネームサーバ１０６は更新要求メッセージに入っている情報を用いてリソースレコードを更新する（ステップ６０８）。次に、ＤＮＳネームサーバ１０６はリースを許可し、リースタイマーを起動する（ステップ６１０）。
【００４０】
ここで留意しなければならないのは、許可リースは要求リースと等しいこともあれば、これより小さいことも、あるいはこれより大きいこともあるということである。さらに、ネットワークとサーバの負荷を小さくするために、ＤＮＳサーバネーム１０６は、例えば１２０分というように、許可リースの最小値を設定することができる。
【００４１】
ＤＮＳネームサーバは、次に、許可リースが入った応答メッセージを送り出す（ステップ６１２）。ここで留意しなければならないのは、応答メッセージにはＤＮＳ更新パケット２００が入っているということである。そして、許可リースはリソースデータフィールド４１２に入っているリースフィールド５０６で指定されている。さらに、リソースデータフィールド４１２はＤＮＳ更新パケット２００の追加データリソースレコードフィールド中に入っている。
【００４２】
次に、ラップトップコンピュータ１０８は許可リースが入った応答メッセージを受け取る（ステップ６１４）。本発明の一実施形態においては、応答メッセージには、更新要求メッセージを受け取ったことを確認すると共に、その状態、すなわち更新要求の成功・不成功を示す受領確認応答しか入れないことも可能である。さらに、ラップトップコンピュータ１０８は、ＤＮＳネームサーバ１０６から応答を指定時間内に受け取らなかった場合、更新要求メッセージを１回または２回以上再送することができる。
【００４３】
このようにして、ラップトップコンピュータ１０８のようなネットワークノードはＤＮＳネームサーバ１０６中のリソースレコードを更新することができ、これによってコンピュータ１０２のような別のネットワークノードが、ＤＮＳネームサーバ１０６に問い合わせることによりラップトップコンピュータ１０８の名前を対応するＩＰアドレスに変換するというような目的のためにそれらのリソースレコードにアクセスすることを可能にする。
古くなったリソースレコードを削除するプロセス
【００４４】
図７は、本発明の一実施形態において、古くなったリソースレコードを削除するプロセスを図解したフローチャートである。
【００４５】
ラップトップコンピュータ１０８のようなネットワークノードから更新要求を受け取ると、ＤＮＳネームサーバ１０６は、リースを許可し、リースタイマーを起動する（ステップ６１０）。次に、ＤＮＳネームサーバ１０６は許可リースが期限切れになったかどうかをチェックする（ステップ７０２）。そして、許可リースが期限切れになると、ＤＮＳネームサーバ１０６は更新済みリソースレコードを削除する（ステップ７０４）。
【００４６】
ここで留意しなければならないのは、許可リースはユーザがラップトップコンピュータ１０８をネットワーク１０４から切り離したというような種々の理由で期間切れになることである。本発明が実施されていない場合、ＤＮＳネームサーバ１０６は、その切り離されたラップトップコンピュータ１０８に対応する古くなったリソースレコードを記憶し続けることになる。これは、ＤＮＳネームサーバ１０６中の情報の正確さと有効性を低減する要因である。
【００４７】
これに対して、本発明は、許可リースの期限切れと同時に古くなったリソースレコードを削除することによって、ＤＮＳネームサーバ１０６上の情報を最新に保ち、これによってＤＮＳネームサーバ１０６上の情報の正確さと有効性を維持する。
リソースレコードをリフレッシュするプロセス
【００４８】
図８は、本発明の一実施形態において、リソースレコードをリフレッシュするプロセスを図解したフローチャートである。
【００４９】
許可リースが入った応答メッセージを受け取ると同時に（ステップ６１４）、ラップトップコンピュータ１０８はリースタイマーを起動する（ステップ８０２）。次に、ラップトップコンピュータ１０８は許可リースが期限切れになりかかっているかどうかをチェックする（ステップ８０４）。そして、許可リースが期限切れになりかかっているならば、ラップトップコンピュータ１０８は更新リフレッシュメッセージをＤＮＳネームサーバ１０６へ送る（ステップ８０６）。
【００５０】
ラップトップコンピュータ１０８は、次に、ＤＮＳネームサーバ１０６から指定時間内に応答メッセージを受け取ったかどうかをチェックする（ステップ８０８）。応答メッセージを指定時間に受け取らなかった場合、ラップトップコンピュータ１０８は更新リフレッシュメッセージをＤＮＳネームサーバ１０６へ送る（ステップ８１０）。他方、応答メッセージを指定時間内に受け取ったならば、ラップトップコンピュータ１０８はリースタイマーを再起動する（ステップ８０２）。
【００５１】
ここで留意しなければならないのは、ラップトップコンピュータ１０８は、応答メッセージを受け取らなければ、ＤＮＳネームサーバ１０６へ何回でも更新リフレッシュメッセージ送ることができるということである。さらに、ラップトップコンピュータ１０８は、更新リフレッシュメッセージを何度も再送するとき、毎回異なる時間だけ待ってから再送するようにすることができる。
【００５２】
スを許可させた最初の更新要求メッセージと同じであってもよい。なおまた、ＤＮＳネームサーバ１０６は、リフレッシュ要求メッセージに応答して新しい許可リースが入った応答メッセージを送り出すことができる。
【００５３】
さらに、ラップトップコンピュータ１０８のようなネットワークノードがいくつもの更新要求メッセージをＤＮＳネームサーバ１０６へ送った場合、そのネットワークノードは、先行のすべてのリソースレコード更新についてのリフレッシュ要求を単一の更新リフレッシュメッセージに入れることができる。
【００５４】
本発明の実施形態についての上記説明は、もっぱら発明の例示説明を目的としたものである。これらの説明は、包括的であることを意図したものでも、本発明を本願開示の形態に限定することを意図したものでもない。したがって、当業者にとっては多くの修正・変更態様が自明であろう。また、上記の開示内容は本発明を制限することを意図したものではない。本発明の範囲は、特許請求の範囲に明確に記載されているところにより定まる。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ、ＤＮＳ（ドメインネームシステム）ネームサーバ、およびラップトップコンピュータに接続されたネットワークを図解して示す説明図である。
【図２】本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使ってＤＮＳネームサーバと情報を交換することができる多様な情報片が入ったＤＮＳ更新パケットを示す説明図である。
【図３】本発明の一実施形態において、ゾーンフィールドに入っているゾーンの構造を示す説明図である。
【図４】本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使ってＤＮＳネームサーバと情報を交換することができるリソースレコードの構造を示す説明図である。
【図５】本発明の一実施形態において、リースを指定するリソースデータフィールドの構造を示す説明図である。
【図６】本発明の一実施形態において、リソースレコードを更新するプロセスを図解したフローチャートである。
【図７】本発明の一実施形態において、古くなったリソースレコードを削除するプロセスを図解したフローチャートである。
【図８】本発明の一実施形態において、リソースレコードをリフレッシュするプロセスを図解したフローチャートである。
【技術の分野】
【０００１】
本発明は、ネームサーバデータベースを更新するプロセスに関する。より詳しくは、本発明は、ネームサーバに更新要求メッセージを送ることによってネームサーバデータベース中のリソースレコードを更新する方法および装置であって、その更新要求メッセージが、ネームサーバがリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースを含む方法および装置に関する。
【背景技術】
【０００２】
ドメインネームシステム（ＤＮＳ）は、グローバルネーミングサービスを提供する分散システムである。他の多くのサービスと同様、ＤＮＳは、基本的にグローバルネーム空間がまれにしか変化しないと予期される静的ネットワーク用に設計されたものである。変化の頻度がかなり低いと思われたため、ＤＮＳは動的更新を処理するようには設計されなかった。
【０００３】
その後、ＤＮＳは動的更新をサポートするよう拡張された。ＩＥＴＦ（インターネット技術標準化委員会）のＲＦＣ（リクエスト・フォア・コメント）２１３６には、ＤＮＳが動的更新を処理できるようにするＤＮＳへの拡張が規定されている。この拡張規定では、ラップトップコンピュータのようなネットワークノードはＤＮＳネームサーバに明示的更新情報を提供する必要がある旨規定されている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
不都合なことには、この拡張により、ＤＮＳネームサーバに古くなった情報が入っている状態が起こり得る。例えば、モバイルユーザのラップトップコンピュータがＤＮＳネームサーバを動的更新によって更新する場合を考えてみる。この場合、それらの更新は明示的に削除されるまでＤＮＳネームサーバに残存し続けるということに注意すべきである。例えば、ユーザが明示的に更新を削除することなくラップトップコンピュータをネットワークから切り離したとすると、それらの更新は、ＤＮＳネームサーバ上にいつまでも残り続けることになる。このことは、ＤＮＳネームサーバデータベースに古くなった情報が入っている状態を引き起こし、その結果ＤＮＳネームサーバデータベースの正確さと有効性が減じられるため、重大な問題になり得る。
【０００５】
「ＤＮＳ清掃」法は、上記の問題を解決しようとする一つの試みである。「ＤＮＳ清掃」法では、ラップトップコンピュータのようなクライアントネットワークノードとＤＮＳネームサーバを、プリセットされたリフレッシュ間隔でコンフィギュレーションする。不都合なことに、この方法は、ラップトップコンピュータとＤＮＳネームサーバの両方を互換性のあるリフレッシュ間隔でコンフィギュレーションする場合に限って有効であり、それは両方が同一管理下にある場合にしか確実に達成することはできない。多くの状況において、ラップトップコンピュータとＤＮＳネームサーバは異なる管理下にある。それ故、「ＤＮＳ清掃」法はその利用が極めて限定される。
【０００６】
したがって、上記のような欠点を解消したネームサーバデータベースを動的に更新する方法および装置が必要とされている。
【課題を解決するための手段】
【０００７】
本発明の実施態様では、ネームサーバデータベースのリソースレコードを更新するシステムを提供する。システムの動作時に、ネットワークノードは、リソースレコード更新の集合と、ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースとが入っている更新要求メッセージを生成する。次に、ネットワークノードは、この更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送る。その後、ネットワークノードはネームサーバからネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージを受け取る。
【０００８】
この実施態様の変形例においては、ネームサーバは、リソースレコード更新の集合と、ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースとが入っているネットワークノードからの更新要求メッセージを受け取る。次に、ネームサーバは、その更新要求メッセージに入っている情報を用いてネームサーバデータベース中のリソースレコードを更新する。その後、ネームサーバは、ネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネットワークノードへ送る。
【０００９】
この実施態様のもう一つの変形例においては、許可リースが期限切れになると、ネームサーバは更新済みリソースレコードをネームサーバデータベースから削除することによって、古くなった情報を取り除くことによりグローバルネーム空間を常に最新の状態に保つ。
【００１０】
この実施態様のもう一つの変形例においては、リソースレコード更新の集合は、ＤＮＳ（ドメインネームシステム）リソースレコードを含まないかあるいは１以上のＤＮＳリソースレコードを含むことが可能である。
【００１１】
この実施態様のもう一つの変形例においては、更新要求メッセージは、更新済みリソースレコードについてのカレントリースを延長する要求をなす更新リフレッシュメッセージとすることができる。
【００１２】
この実施態様のもう一つの変形例においては、更新リフレッシュメッセージは、ネームサーバをして更新済みリソースレコードについてのカレントリースを許可させた先行の更新要求メッセージと同じである。
【００１３】
この実施態様のもう一つの変形例においては、ネットワークノードがネームサーバから指定時間内に応答メッセージを受け取らなかった場合、更新要求メッセージをネームサーバへ再送する。
【００１４】
この実施態様のもう一つの変形例においては、ネットワークノードとネームサーバはＵＤＰ（ユーザデータグラムプロトコル）を用いて相互に通信する。
【００１５】
この実施態様のもう一つの変形例においては、ネットワークノードとネームサーバはＴＣＰ（伝送制御プロトコル）を用いて相互に通信する。
【００１６】
この実施態様のもう一つの変形例においては、ネームサーバはドメインネームシステム（ＤＮＳ）に属する。
【発明を実施するための最良の形態】
【００１７】
以下、本発明を当業者が実施することができるよう詳細に説明するが、説明は特定の利用形態とその要求事項との関連において行う。当業者にとっては、本願開示の実施形態について様々な修正・変更態様が自明であり、本願中に明確に記載する基本原理は、本発明の精神と範囲を逸脱することなく他の実施や利用の形態に適用することが可能である。したがって、本発明は、本願で説明する実施形態に限定されず、本願に開示する原理や特徴に合致する最大の範囲を許可されるべきものである。
【００１８】
この詳細な説明に記載するデータ構造とコードは、通常、コンピュータ可読記憶媒体に記憶される。この記憶媒体としては、コンピュータシステムで使用するコードおよび／またはデータを記憶することができる任意のデバイスあるいは媒体を用いることが可能である。このような記憶媒体としては、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）とＤＶＤ（デジタル多目的ディスクまたはデジタルビデオディスク）のような磁気記憶装置や光記憶装置、さらには伝送媒体の形で実施されるコンピュータ命令信号（これらの信号を上に重ねることにより変調する搬送波の有無を問わない）があるが、これらに限定されるものではない。この伝送媒体としては、例えば、インターネットのような通信ネットワークがある。
ネットワーク
【００１９】
図１は、本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ１０２、ＤＮＳ（ドメインネームシステム）ネームサーバ１０６、ラップトップコンピュータ１０８に接続されたネットワーク１０４を図解して示す概略図である。
【００２０】
ネットワーク１０４は、全般的に、ネットワークノードを互いに結合することができる任意の種類の有線または無線の通信チャンネルを含む。このような通信チャンネルとしては、ローカルエリアネットワーク、ワイドエリアネットワーク、あるいはネットワークを組合せた形のものがあるが、これらに限定されるものではない。本発明の一実施形態においては、ネットワーク１０４はインターネットを含む。
【００２１】
コンピュータ１０２のようなネットワークノードは、全般的に、ネットワークを介して他のネットワークノードと通信することができる任意の種類の通信デバイスを含む。このような通信デバイスとしては、マイクロプロセッサに基づくコンピュータシステム、メインフレームコンピュータ、サーバ、プリンタ、ビデオカメラ、外部ディスクドライブ、ルータ、交換機、電子手帳、携帯電話があるが、これらに限定されるものではない。
【００２２】
ネットワーク１０４は、コンピュータ１０２のようなソースネットワークノードがラップトップコンピュータ１０８のようなターゲットネットワークノードと通信することを可能にする。しかし、通信が行われるには、まずその前にソースネットワークノード、すなわちコンピュータ１０２がターゲットネットワークノード、すなわちラップトップコンピュータ１０８のＩＰアドレスを知ることが必要である。通常、コンピュータ１０２は、ＤＮＳネームサーバ１０６に問い合わせることによりラップトップコンピュータ１０８の名前を対応するＩＰアドレスに変換する。
ＤＮＳ更新パケットの構造
【００２３】
図２は、本発明の一実施形態において、コンピュータ１０２のようなネットワークノードがそれを使ってＤＮＳネームサーバ１０６と情報を交換することができる多様な情報片が入ったＤＮＳ更新パケット２００を示す説明図である。
【００２４】
更新要求メッセージと応答メッセージは共に同じＤＮＳ更新パケット２００のフォーマットを使用する。具体的に言うと、ＤＮＳ更新パケット２００中には、コンピュータ１０２のようなネットワークノードが更新要求を対応する応答と合致させることを可能にする識別フィールド２０２が入っている。また、ＤＮＳ更新パケット２００中には、とりわけＤＮＳ更新パケットが更新要求であるか応答であるかを指示するフラグフィールド２０４も入っている。
【００２５】
さらに、ＤＮＳ更新パケット２００中には、４つの可変長フィールド、すなわちゾーンフィールド２１４、先要リソースレコードフィールド２１６、更新リソースレコードフィールド２１８、追加データリソースレコードフィールド２２０が入っている。これらの可変長フィールドは、ネットワークノード、すなわちコンピュータ１０２とＤＮＳネームサーバ１０６との間で情報を交換するために使用される。
【００２６】
上記の他、ＤＮＳ更新パケット２００中には、さらに４つのフィールド、すなわち上記４つの可変長フィールドのエントリの番号をそれぞれ指定するゾーン番号フィールド２０６、先要リソースレコード番号フィールド２０８、更新リソースレコード番号フィールド２１０、追加データリソースレコード番号フィールド２１２が入っている。
ゾーンフィールドの構造
【００２７】
図３は、本発明の一実施形態において、ゾーンフィールド２１４に入っているゾーン３００の構造を示す説明図である。ゾーン３００には、リソースレコード更新のゾーン名を指定するゾーン名フィールド３０２が入っている。さらに、ゾーン３００には、ゾーン３００のタイプとクラスをそれぞれ指定するゾーンタイプフィールド３０４とゾーンクラスフィールド３０６が入っている。
リソースレコードの構造
【００２８】
図４は、本発明の一実施形態にしたがって、ＤＮＳネームサーバ１０６と情報を交換するために、コンピュータ１０２のようなネットワークノードによって用いられるリソースレコード４００の構造を示す説明図である。
【００２９】
具体的に言うと、リソースレコード４００には、考えているドメイン名を指定するドメイン名フィールド４０２が入っている。また、リソースレコード４００には、リソースレコードのタイプとクラスをそれぞれ指定するリソースレコードタイプフィールド４０４とリソースレコードクラスフィールド４０６も入っている。
【００３０】
上記の他、リソースレコード４００には、さらに、リソースレコードをコンピュータ１０２のようなネットワークノードによりキャッシュすることができる時間の長さ（秒）を指定する有効時間（ＴＴＬ）フィールド４０８が入っている。
【００３１】
さらに、リソースレコード４００は、ＤＮＳネームサーバ１０６と情報を交換するために、コンピュータ１０２のようなネットワークノードによって使用される可変長フィールドであるリソースデータフィールド４１２を含む。また、リソースレコード４００は、可変長リソースデータフィールド４１２中のデータ量を指定するリソースデータ長フィールド４１０も含む。
リースを指定するリソースデータフィールドの構造
【００３２】
図５は、本発明の一実施形態において、リースを指定するリソースデータフィールド４１２の構造を示す説明図である。
【００３３】
具体的に言うと、リソースデータフィールド４１２には、リソースデータのタイプを指定するオプションコードフィールド５０２が入っている。また、リソースデータフィールド４１２には、リースフィールド５０６も入っている。ここで留意しなければならないのは、リースフィールド５０６は、ネットワークノード１０２がこれを用いてリースを要求し、かつＤＮＳネームサーバ１０６がこれを使ってリースを許可するということである。さらに、リソースデータフィールド４１２には、リースフィールド５０６の長さを指定するオプションコードフィールド５０４が入っている。
【００３４】
さらに、リソースデータフィールド４１２は、ＩＥＴＦ ＲＦＣ２６７１に規定されたＯＰＴ疑似ＲＲ（疑似リソースレコード）の中に入っている。ここで留意しなければならないのは、ＩＥＴＦ ＲＦＣ２６７１は、新しいリソースレコードのデータタイプを定義するメカニズムについて規定しているということである。さらに、ＯＰＴ疑似ＲＲは、ＤＮＳ更新パケット２００中の追加データリソースレコードフィールド２２０中に入っている。
リソースレコードを更新するプロセス
【００３５】
図６は、本発明の一実施形態において、リソースレコードを更新するプロセスを図解したフローチャートである。
【００３６】
このプロセスは、例えば、ラップトップコンピュータ１０８のようなネットワークノードがネットワーク１０４に参加するとき開始される。まず、ラップトップコンピュータ１０８が、リソースレコード更新の集合および要求リースが入っている更新要求メッセージを生成する（ステップ６０２）。
【００３７】
ここで留意しなければならないのは、更新要求メッセージにはＤＮＳ更新パケット２００が入っているということである。さらに、リソースレコード更新は、ＤＮＳ更新パケット２００の更新リソースレコードフィールド２１８で指定されている。かつ、要求リースは、リソースデータフィールド４１２に入っているリースフィールド５０６で指定されている。なおまた、リソースデータフィールド４１２は、ＤＮＳ更新パケット２００の追加データリソースレコードフィールド２２０中に入っている。
【００３８】
次に、ラップトップコンピュータ１０８は更新要求メッセージをＤＮＳネームサーバ１０６へ送る（ステップ６０４）。ここで留意しなければならないのは、ラップトップコンピュータ１０８はＵＤＰ（ユーザデータグラムプロトコル）またはＴＣＰ（伝送制御プロトコル）使用して更新要求メッセージと応答メッセージをＤＮＳネームサーバ１０６と交換することができるということである。
【００３９】
次に、ＤＮＳネームサーバ１０６は更新要求メッセージを受け取る（ステップ６０６）。次いで、ＤＮＳネームサーバ１０６は更新要求メッセージに入っている情報を用いてリソースレコードを更新する（ステップ６０８）。次に、ＤＮＳネームサーバ１０６はリースを許可し、リースタイマーを起動する（ステップ６１０）。
【００４０】
ここで留意しなければならないのは、許可リースは要求リースと等しいこともあれば、これより小さいことも、あるいはこれより大きいこともあるということである。さらに、ネットワークとサーバの負荷を小さくするために、ＤＮＳサーバネーム１０６は、例えば１２０分というように、許可リースの最小値を設定することができる。
【００４１】
ＤＮＳネームサーバは、次に、許可リースが入った応答メッセージを送り出す（ステップ６１２）。ここで留意しなければならないのは、応答メッセージにはＤＮＳ更新パケット２００が入っているということである。そして、許可リースはリソースデータフィールド４１２に入っているリースフィールド５０６で指定されている。さらに、リソースデータフィールド４１２はＤＮＳ更新パケット２００の追加データリソースレコードフィールド中に入っている。
【００４２】
次に、ラップトップコンピュータ１０８は許可リースが入った応答メッセージを受け取る（ステップ６１４）。本発明の一実施形態においては、応答メッセージには、更新要求メッセージを受け取ったことを確認すると共に、その状態、すなわち更新要求の成功・不成功を示す受領確認応答しか入れないことも可能である。さらに、ラップトップコンピュータ１０８は、ＤＮＳネームサーバ１０６から応答を指定時間内に受け取らなかった場合、更新要求メッセージを１回または２回以上再送することができる。
【００４３】
このようにして、ラップトップコンピュータ１０８のようなネットワークノードはＤＮＳネームサーバ１０６中のリソースレコードを更新することができ、これによってコンピュータ１０２のような別のネットワークノードが、ＤＮＳネームサーバ１０６に問い合わせることによりラップトップコンピュータ１０８の名前を対応するＩＰアドレスに変換するというような目的のためにそれらのリソースレコードにアクセスすることを可能にする。
古くなったリソースレコードを削除するプロセス
【００４４】
図７は、本発明の一実施形態において、古くなったリソースレコードを削除するプロセスを図解したフローチャートである。
【００４５】
ラップトップコンピュータ１０８のようなネットワークノードから更新要求を受け取ると、ＤＮＳネームサーバ１０６は、リースを許可し、リースタイマーを起動する（ステップ６１０）。次に、ＤＮＳネームサーバ１０６は許可リースが期限切れになったかどうかをチェックする（ステップ７０２）。そして、許可リースが期限切れになると、ＤＮＳネームサーバ１０６は更新済みリソースレコードを削除する（ステップ７０４）。
【００４６】
ここで留意しなければならないのは、許可リースはユーザがラップトップコンピュータ１０８をネットワーク１０４から切り離したというような種々の理由で期間切れになることである。本発明が実施されていない場合、ＤＮＳネームサーバ１０６は、その切り離されたラップトップコンピュータ１０８に対応する古くなったリソースレコードを記憶し続けることになる。これは、ＤＮＳネームサーバ１０６中の情報の正確さと有効性を低減する要因である。
【００４７】
これに対して、本発明は、許可リースの期限切れと同時に古くなったリソースレコードを削除することによって、ＤＮＳネームサーバ１０６上の情報を最新に保ち、これによってＤＮＳネームサーバ１０６上の情報の正確さと有効性を維持する。
リソースレコードをリフレッシュするプロセス
【００４８】
図８は、本発明の一実施形態において、リソースレコードをリフレッシュするプロセスを図解したフローチャートである。
【００４９】
許可リースが入った応答メッセージを受け取ると同時に（ステップ６１４）、ラップトップコンピュータ１０８はリースタイマーを起動する（ステップ８０２）。次に、ラップトップコンピュータ１０８は許可リースが期限切れになりかかっているかどうかをチェックする（ステップ８０４）。そして、許可リースが期限切れになりかかっているならば、ラップトップコンピュータ１０８は更新リフレッシュメッセージをＤＮＳネームサーバ１０６へ送る（ステップ８０６）。
【００５０】
ラップトップコンピュータ１０８は、次に、ＤＮＳネームサーバ１０６から指定時間内に応答メッセージを受け取ったかどうかをチェックする（ステップ８０８）。応答メッセージを指定時間に受け取らなかった場合、ラップトップコンピュータ１０８は更新リフレッシュメッセージをＤＮＳネームサーバ１０６へ送る（ステップ８１０）。他方、応答メッセージを指定時間内に受け取ったならば、ラップトップコンピュータ１０８はリースタイマーを再起動する（ステップ８０２）。
【００５１】
ここで留意しなければならないのは、ラップトップコンピュータ１０８は、応答メッセージを受け取らなければ、ＤＮＳネームサーバ１０６へ何回でも更新リフレッシュメッセージ送ることができるということである。さらに、ラップトップコンピュータ１０８は、更新リフレッシュメッセージを何度も再送するとき、毎回異なる時間だけ待ってから再送するようにすることができる。
【００５２】
スを許可させた最初の更新要求メッセージと同じであってもよい。なおまた、ＤＮＳネームサーバ１０６は、リフレッシュ要求メッセージに応答して新しい許可リースが入った応答メッセージを送り出すことができる。
【００５３】
さらに、ラップトップコンピュータ１０８のようなネットワークノードがいくつもの更新要求メッセージをＤＮＳネームサーバ１０６へ送った場合、そのネットワークノードは、先行のすべてのリソースレコード更新についてのリフレッシュ要求を単一の更新リフレッシュメッセージに入れることができる。
【００５４】
本発明の実施形態についての上記説明は、もっぱら発明の例示説明を目的としたものである。これらの説明は、包括的であることを意図したものでも、本発明を本願開示の形態に限定することを意図したものでもない。したがって、当業者にとっては多くの修正・変更態様が自明であろう。また、上記の開示内容は本発明を制限することを意図したものではない。本発明の範囲は、特許請求の範囲に明確に記載されているところにより定まる。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ、ＤＮＳ（ドメインネームシステム）ネームサーバ、およびラップトップコンピュータに接続されたネットワークを図解して示す説明図である。
【図２】本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使ってＤＮＳネームサーバと情報を交換することができる多様な情報片が入ったＤＮＳ更新パケットを示す説明図である。
【図３】本発明の一実施形態において、ゾーンフィールドに入っているゾーンの構造を示す説明図である。
【図４】本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使ってＤＮＳネームサーバと情報を交換することができるリソースレコードの構造を示す説明図である。
【図５】本発明の一実施形態において、リースを指定するリソースデータフィールドの構造を示す説明図である。
【図６】本発明の一実施形態において、リソースレコードを更新するプロセスを図解したフローチャートである。
【図７】本発明の一実施形態において、古くなったリソースレコードを削除するプロセスを図解したフローチャートである。
【図８】本発明の一実施形態において、リソースレコードをリフレッシュするプロセスを図解したフローチャートである。
【特許請求の範囲】
【請求項１】
ネームサーバデータベース中のリソースレコードを更新する方法であって：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っている更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージを前記ネームサーバから受け取るステップと；
からなる方法。
【請求項２】
前記応答メッセージに、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースが入っている請求項１に記載の方法。
【請求項３】
前記リソースレコード更新の集合に、１つ以上のＤＮＳ（ドメインネームシステム）リソースレコードを入っている請求項１に記載の方法。
【請求項４】
前記更新要求メッセージが、前記リソースレコード更新のいずれかについてのカレントリースを延長する要求を構成する更新リフレッシュメッセージである請求項１に記載の方法。
【請求項５】
前記更新リフレッシュメッセージは、ネームサーバが前記リソースレコード更新についてのカレントリースを許可できるようになる先行の更新要求メッセージと同じである請求項４に記載の方法。
【請求項６】
前記要求リースが、追加データリソースレコードフィールドに属するＯＰＴ疑似リソースレコードに入っている請求項１に記載の方法。
【請求項７】
ネットワークノードが、ネームサーバから指定時間内に応答メッセージを受け取らなかった場合に、更新要求メッセージをネームサーバへ再送する請求項１に記載の方法。
【請求項８】
ネットワークノードとネームサーバとがユーザデータグラムプロトコル（ＵＤＰ）を用いて相互に通信する請求項１に記載の方法。
【請求項９】
ネットワークノードとネームサーバとが伝送制御プロトコル（ＴＣＰ）を用いて相互に通信する請求項１に記載の方法。
【請求項１０】
ネームサーバデータベース中のリソースレコードを更新する方法であって：
リソースレコード更新の集合を含む更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記リソースレコード更新をネームサーバデータベースが記憶する時間の長さを指定する許可リースが入っている応答メッセージを前記ネームサーバから受け取るステップと；
からなる方法。
【請求項１１】
ネームサーバデータベース中のリソースレコードを更新する方法であって：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っているネットワークノードからの更新要求メッセージを受け取るステップと；
前記更新要求メッセージに入っている情報を用いてネームサーバデータベースを更新するステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージをネットワークノードへ送るステップと；
からなる方法。
【請求項１２】
前記応答メッセージに、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースで、前記要求リースとは異なる許可リースが入っている請求項１１に記載の方法。
【請求項１３】
前記許可リースが期限切れになると、さらに：
更新済みリソースレコードをネームサーバデータベースから削除することによって、古くなった情報を除去することによりグローバルネーム空間を常に最新に保つステップを含む請求項１２に記載の方法。
【請求項１４】
ネームサーバデータベースを更新する前記ステップが、前記更新済みリソースレコードを記憶するステップを含む請求項１１に記載の方法。
【請求項１５】
前記更新要求メッセージが、前記更新要求メッセージ中に入っている前記リソースレコード更新のいずれかについてカレントリースを延長する要求である請求項１１に記載の方法。
【請求項１６】
コンピュータにより実行されるときネームサーバデータベース中のリソースレコードを更新する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入った更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージを前記ネームサーバから受け取るステップと；
からなるコンピュータ可読記憶媒体。
【請求項１７】
前記応答メッセージが、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースを含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記リソースレコード更新の集合が１つ以上のＤＮＳ（ドメインネームシステム）リソースレコードを含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記更新要求メッセージが、更新済みリソースレコードについてのカレントリースを延長する要求を構成する更新リフレッシュメッセージである請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記更新リフレッシュメッセージは、ネームサーバが前記更新済みリソースレコードについてのカレントリースを許可できるようにする先行の更新要求メッセージと同じである請求項１９に記載のコンピュータ記憶媒体。
【請求項２１】
前記要求リースを、追加データリソースレコードフィールドに属するＯＰＴ疑似リソースレコードに入っている請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２２】
ネットワークノードが、ネームサーバから指定時間内に応答メッセージを受け取らなかった場合に、更新要求メッセージをネームサーバへ再送する請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２３】
ネットワークノードとネームサーバとがユーザデータグラムプロトコル（ＵＤＰ）を用いて相互に通信する請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２４】
ネットワークノードとネームサーバとが伝送制御プロトコル（ＴＣＰ）を用いて相互に通信する請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２５】
コンピュータにより実行されるときネームサーバデータベース中のリソースレコードを更新する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が：
リソースレコード更新の集合が入っている更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記リソースレコード更新をネームサーバデータベースが記憶する時間の長さを指定する許可リースが入っている応答メッセージをネームサーバから受け取るステップと；
からなるコンピュータ可読記憶媒体。
【請求項２６】
コンピュータにより実行されるときネームサーバデータベース中のリソースレコードを更新する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っているネットワークノードからの更新要求メッセージを受け取るステップと；
前記更新要求メッセージに入っている情報を用いてネームサーバデータベースを更新するステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージをネットワークノードへ送るステップと；
からなるコンピュータ可読記憶媒体。
【請求項２７】
前記応答メッセージに、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースで、前記要求リースとは異なる許可リースが入っている請求項２６に記載のコンピュータ可読記憶媒体。
【請求項２８】
前記許可リースが期限切れになると、前記方法が、さらに
更新済みリソースレコードをネームサーバデータベースから削除することによって、古くなった情報を除去することによりグローバルネーム空間を常に最新に保つステップを含む請求項２７に記載のコンピュータ可読記憶媒体。
【請求項２９】
ネームサーバデータベースを更新する前記ステップが、前記更新済みリソースレコードを記憶するステップを含む請求項２６に記載のコンピュータ可読記憶媒体。
【請求項３０】
前記更新要求メッセージが、前記更新要求メッセージ中に入っている前記リソースレコード更新のいずれかについてカレントリースを延長する要求である請求項２６に記載のコンピュータ可読記憶媒体。
【請求項３１】
ネームサーバデータベース中のリソースレコードを更新する装置であって：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入った更新要求メッセージを生成する生成機構と；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るよう構成された送信機構と；
ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネームサーバから受け取るよう構成された受信機構と；
を備える装置。
【請求項３２】
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っているネットワークノードからの更新要求メッセージを受け取るよう構成された受信機構と；
前記更新要求メッセージに入っている情報を用いてネームサーバデータベース中のリソースレコードを更新するよう構成された更新機構と；
ネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネットワークノードへ送る送信機構と；
をさらに含む請求項３１に記載の装置。
【請求項３３】
許可リースが期限切れになると、更新リソースレコードをネームサーバデータベースから削除することによって、古くなった情報を取り除くことによりグローバルネーム空間を常に最新の状態に保つよう構成された削除機構をさらに含む請求項３１に記載の装置。
【請求項３４】
前記リソースレコード更新の集合がドメインネームシステム（ＤＮＳ）リソースレコードを含まないかあるいは１以上のＤＮＳリソースレコードを含む請求項３１に記載の装置。
【請求項３５】
前記更新要求メッセージが、更新済みリソースレコードについてのカレントリースを延長する要求を構成する更新リフレッシュメッセージである請求項３１に記載の装置。
【請求項３６】
前記更新リフレッシュメッセージは、ネームサーバが前記更新済みリソースレコードについてのカレントリースを許可できるようにする先行の更新要求メッセージと同じである請求項３５に記載の装置。
【請求項３７】
ネットワークノードが、ネームサーバから指定時間内に応答メッセージを受け取らなかった場合に、更新要求メッセージをネームサーバへ再送する請求項３１に記載の装置。
【請求項３８】
ネットワークノードとネームサーバとがユーザデータグラムプロトコル（ＵＤＰ）を用いて相互に通信する請求項３１に記載の装置。
【請求項３９】
ネットワークノードとネームサーバとが伝送制御プロトコル（ＴＣＰ）を用いて相互に通信する請求項３１に記載の装置。
【請求項４０】
ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項３１に記載の装置。
【請求項１】
ネームサーバデータベース中のリソースレコードを更新する方法であって：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っている更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージを前記ネームサーバから受け取るステップと；
からなる方法。
【請求項２】
前記応答メッセージに、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースが入っている請求項１に記載の方法。
【請求項３】
前記リソースレコード更新の集合に、１つ以上のＤＮＳ（ドメインネームシステム）リソースレコードを入っている請求項１に記載の方法。
【請求項４】
前記更新要求メッセージが、前記リソースレコード更新のいずれかについてのカレントリースを延長する要求を構成する更新リフレッシュメッセージである請求項１に記載の方法。
【請求項５】
前記更新リフレッシュメッセージは、ネームサーバが前記リソースレコード更新についてのカレントリースを許可できるようになる先行の更新要求メッセージと同じである請求項４に記載の方法。
【請求項６】
前記要求リースが、追加データリソースレコードフィールドに属するＯＰＴ疑似リソースレコードに入っている請求項１に記載の方法。
【請求項７】
ネットワークノードが、ネームサーバから指定時間内に応答メッセージを受け取らなかった場合に、更新要求メッセージをネームサーバへ再送する請求項１に記載の方法。
【請求項８】
ネットワークノードとネームサーバとがユーザデータグラムプロトコル（ＵＤＰ）を用いて相互に通信する請求項１に記載の方法。
【請求項９】
ネットワークノードとネームサーバとが伝送制御プロトコル（ＴＣＰ）を用いて相互に通信する請求項１に記載の方法。
【請求項１０】
ネームサーバデータベース中のリソースレコードを更新する方法であって：
リソースレコード更新の集合を含む更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記リソースレコード更新をネームサーバデータベースが記憶する時間の長さを指定する許可リースが入っている応答メッセージを前記ネームサーバから受け取るステップと；
からなる方法。
【請求項１１】
ネームサーバデータベース中のリソースレコードを更新する方法であって：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っているネットワークノードからの更新要求メッセージを受け取るステップと；
前記更新要求メッセージに入っている情報を用いてネームサーバデータベースを更新するステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージをネットワークノードへ送るステップと；
からなる方法。
【請求項１２】
前記応答メッセージに、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースで、前記要求リースとは異なる許可リースが入っている請求項１１に記載の方法。
【請求項１３】
前記許可リースが期限切れになると、さらに：
更新済みリソースレコードをネームサーバデータベースから削除することによって、古くなった情報を除去することによりグローバルネーム空間を常に最新に保つステップを含む請求項１２に記載の方法。
【請求項１４】
ネームサーバデータベースを更新する前記ステップが、前記更新済みリソースレコードを記憶するステップを含む請求項１１に記載の方法。
【請求項１５】
前記更新要求メッセージが、前記更新要求メッセージ中に入っている前記リソースレコード更新のいずれかについてカレントリースを延長する要求である請求項１１に記載の方法。
【請求項１６】
コンピュータにより実行されるときネームサーバデータベース中のリソースレコードを更新する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入った更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージを前記ネームサーバから受け取るステップと；
からなるコンピュータ可読記憶媒体。
【請求項１７】
前記応答メッセージが、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースを含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記リソースレコード更新の集合が１つ以上のＤＮＳ（ドメインネームシステム）リソースレコードを含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記更新要求メッセージが、更新済みリソースレコードについてのカレントリースを延長する要求を構成する更新リフレッシュメッセージである請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記更新リフレッシュメッセージは、ネームサーバが前記更新済みリソースレコードについてのカレントリースを許可できるようにする先行の更新要求メッセージと同じである請求項１９に記載のコンピュータ記憶媒体。
【請求項２１】
前記要求リースを、追加データリソースレコードフィールドに属するＯＰＴ疑似リソースレコードに入っている請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２２】
ネットワークノードが、ネームサーバから指定時間内に応答メッセージを受け取らなかった場合に、更新要求メッセージをネームサーバへ再送する請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２３】
ネットワークノードとネームサーバとがユーザデータグラムプロトコル（ＵＤＰ）を用いて相互に通信する請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２４】
ネットワークノードとネームサーバとが伝送制御プロトコル（ＴＣＰ）を用いて相互に通信する請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２５】
コンピュータにより実行されるときネームサーバデータベース中のリソースレコードを更新する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が：
リソースレコード更新の集合が入っている更新要求メッセージを生成するステップと；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと；
前記リソースレコード更新をネームサーバデータベースが記憶する時間の長さを指定する許可リースが入っている応答メッセージをネームサーバから受け取るステップと；
からなるコンピュータ可読記憶媒体。
【請求項２６】
コンピュータにより実行されるときネームサーバデータベース中のリソースレコードを更新する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っているネットワークノードからの更新要求メッセージを受け取るステップと；
前記更新要求メッセージに入っている情報を用いてネームサーバデータベースを更新するステップと；
前記更新要求メッセージを受け取ったことを通知する応答メッセージをネットワークノードへ送るステップと；
からなるコンピュータ可読記憶媒体。
【請求項２７】
前記応答メッセージに、さらに、ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースで、前記要求リースとは異なる許可リースが入っている請求項２６に記載のコンピュータ可読記憶媒体。
【請求項２８】
前記許可リースが期限切れになると、前記方法が、さらに
更新済みリソースレコードをネームサーバデータベースから削除することによって、古くなった情報を除去することによりグローバルネーム空間を常に最新に保つステップを含む請求項２７に記載のコンピュータ可読記憶媒体。
【請求項２９】
ネームサーバデータベースを更新する前記ステップが、前記更新済みリソースレコードを記憶するステップを含む請求項２６に記載のコンピュータ可読記憶媒体。
【請求項３０】
前記更新要求メッセージが、前記更新要求メッセージ中に入っている前記リソースレコード更新のいずれかについてカレントリースを延長する要求である請求項２６に記載のコンピュータ可読記憶媒体。
【請求項３１】
ネームサーバデータベース中のリソースレコードを更新する装置であって：
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入った更新要求メッセージを生成する生成機構と；
前記更新要求メッセージを、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るよう構成された送信機構と；
ネームサーバデータベースが前記リソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネームサーバから受け取るよう構成された受信機構と；
を備える装置。
【請求項３２】
リソースレコード更新の集合と、
ネームサーバがそれらのリソースレコード更新を記憶するよう要求される時間の長さを指定する要求リースと、
が入っているネットワークノードからの更新要求メッセージを受け取るよう構成された受信機構と；
前記更新要求メッセージに入っている情報を用いてネームサーバデータベース中のリソースレコードを更新するよう構成された更新機構と；
ネームサーバデータベースがリソースレコード更新を記憶する時間の長さを指定する許可リースが入っている応答メッセージをネットワークノードへ送る送信機構と；
をさらに含む請求項３１に記載の装置。
【請求項３３】
許可リースが期限切れになると、更新リソースレコードをネームサーバデータベースから削除することによって、古くなった情報を取り除くことによりグローバルネーム空間を常に最新の状態に保つよう構成された削除機構をさらに含む請求項３１に記載の装置。
【請求項３４】
前記リソースレコード更新の集合がドメインネームシステム（ＤＮＳ）リソースレコードを含まないかあるいは１以上のＤＮＳリソースレコードを含む請求項３１に記載の装置。
【請求項３５】
前記更新要求メッセージが、更新済みリソースレコードについてのカレントリースを延長する要求を構成する更新リフレッシュメッセージである請求項３１に記載の装置。
【請求項３６】
前記更新リフレッシュメッセージは、ネームサーバが前記更新済みリソースレコードについてのカレントリースを許可できるようにする先行の更新要求メッセージと同じである請求項３５に記載の装置。
【請求項３７】
ネットワークノードが、ネームサーバから指定時間内に応答メッセージを受け取らなかった場合に、更新要求メッセージをネームサーバへ再送する請求項３１に記載の装置。
【請求項３８】
ネットワークノードとネームサーバとがユーザデータグラムプロトコル（ＵＤＰ）を用いて相互に通信する請求項３１に記載の装置。
【請求項３９】
ネットワークノードとネームサーバとが伝送制御プロトコル（ＴＣＰ）を用いて相互に通信する請求項３１に記載の装置。
【請求項４０】
ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項３１に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２００７−５３３０２４（Ｐ２００７−５３３０２４Ａ）
【公表日】平成１９年１１月１５日（２００７．１１．１５）
【国際特許分類】
【出願番号】特願２００７−５０８３３２（Ｐ２００７−５０８３３２）
【出願日】平成１７年２月１０日（２００５．２．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００４３０３
【国際公開番号】ＷＯ２００６／０１１９０７
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（５０００２７７７０）アプル・コンピュータ・インコーポレーテッド (16)
【Ｆターム（参考）】
【公表日】平成１９年１１月１５日（２００７．１１．１５）
【国際特許分類】
【出願日】平成１７年２月１０日（２００５．２．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００４３０３
【国際公開番号】ＷＯ２００６／０１１９０７
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（５０００２７７７０）アプル・コンピュータ・インコーポレーテッド (16)
【Ｆターム（参考）】
[ Back to top ]