(57)【要約】  本発明の実施態様は、ネットワークノードまたはサブネットの位置固有の構成情報を検索するシステムにある。システムの動作時、ネットワークノードは、ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とからなるキーが入った問い合わせメッセージを生成する。次に、ネットワークノードは、この問い合わせメッセージを、グローバルネーミングサービスを提供する分散システムの一部であって構成情報を記憶しているネームサーバへ送る。最後に、ネットワークノードは、要求した構成情報が入っている応答メッセージをネームサーバから受け取る。【特許請求の範囲】
【請求項１】
ネットワークノードまたはサブネットの位置固有構成情報を検索する方法であって、
ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と、
所望の構成情報のタイプを特定的に指示する構成識別子と
を含む問い合わせメッセージを生成するステップと、
前記問い合わせメッセージをグローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと、
前記ネームサーバから応答メッセージを受け取るステップと、
を含む方法。
【請求項２】
前記アドレス識別子が、インターネットプロトコルアドレスの１以上のビットの文字列表現である請求項１に記載の方法。
【請求項３】
前記ネームサーバからの応答メッセージに、要求した構成情報を入れ得る請求項１に記載の方法。
【請求項４】
前記ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項１に記載の方法。
【請求項５】
前記問い合わせメッセージに、構成識別子をアドレス識別子の先頭に付加し、これにより得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加することによって生成されるキーが入っている請求項１に記載の方法。
【請求項６】
前記問い合わせメッセージがＤＮＳ問い合わせメッセージである請求項１に記載の方法。
【請求項７】
前記問い合わせメッセージがＤＮＳ応答メッセージである請求項１に記載の方法。
【請求項８】
ネットワークノードまたはサブネットの位置固有構成情報を検索する方法であって、
前記ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と構成情報のタイプを特定的に指示する構成識別子とを含む問い合わせメッセージをネットワークノードからネームサーバに受け取るステップと、
前記問い合わせメッセージ中に入っている情報を用いて前記構成情報を前記ネームサーバのデータベースで検索するステップと、
応答メッセージを前記ネットワークノードへ送るステップと、
を含む方法。
【請求項９】
前記アドレス識別子が、ＩＰバージョン４アドレスの１以上のビットの文字列表現またはＩＰバージョン６アドレスの１以上のビットの文字列表現のどちらか一方である請求項８に記載の方法。
【請求項１０】
前記ネームサーバのデータベースで前記構成情報を検索するステップが、１以上のリソースレコードにアクセスするステップを含む請求項８に記載の方法。
【請求項１１】
前記応答メッセージが、要求した構成情報が入っているＤＮＳ応答メッセージである請求項８に記載の方法。
【請求項１２】
前記問い合わせメッセージが、前記アドレス識別子と前記構成識別子とを組み合わせることにより生成されたドメイン名フィールドが入っているＤＮＳ問い合わせメッセージである請求項８に記載の方法。
【請求項１３】
ネットワークノードまたはサブネットの位置固有構成情報を検索する方法であって、
ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とを含むキーが入った問い合わせメッセージを生成するステップと、
前記問い合わせメッセージを、グローバルネーミングサービスを提供する分散システムの一部であって構成情報を記憶しているネームサーバへ送るステップと、
要求した構成情報が入っている応答メッセージを前記ネームサーバから受け取るステップと、
を含む方法。
【請求項１４】
コンピュータにより実行されるときネットワークノードまたはサブネットの位置固有構成情報を検索する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が、
ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と、
所望の構成情報のタイプを特定的に指示する構成識別子と、を含む問い合わせメッセージを生成するステップと、
前記問い合わせメッセージをグローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと、
前記ネームサーバから応答メッセージを受け取るステップと、を含むコンピュータ可読記憶媒体。
【請求項１５】
前記アドレス識別子が、インターネットプロトコル（ＩＰ）アドレスの１以上のビットの文字列表現である請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１６】
前記ネームサーバからの応答メッセージが要求した構成情報を含む請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１７】
前記ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記問い合わせメッセージに、
構成識別子をアドレス識別子の先頭に付加し、
これにより得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加すること、によって生成されるキーが入っている請求項１４に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記問い合わせメッセージがＤＮＳ問い合わせメッセージである請求項１４に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記応答メッセージがＤＮＳ応答メッセージである請求項１４に記載のコンピュータ可読記憶媒体。
【請求項２１】
コンピュータにより実行されるときネットワークノードまたはサブネットの位置固有構成情報を検索する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が、
前記ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と、
構成情報のタイプを特定的に指示する構成識別子と、
を含む問い合わせメッセージをネットワークノードからネームサーバに受け取るステップと、
前記問い合わせメッセージ中に入っている情報を用いて前記構成情報を前記ネームサーバのデータベースで検索するステップと、
応答メッセージを前記ネットワークノードへ送るステップと、
を含むコンピュータ可読記憶媒体。
【請求項２２】
前記アドレス識別子が、
ＩＰバージョン４アドレスの１以上のビットの文字列表現、または
ＩＰバージョン６アドレスの１以上のビットの文字列表現、
のどちらか一方である請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２３】
前記ネームサーバのデータベースで前記構成情報を検索するステップが、１以上のリソースレコードにアクセスするステップを含む請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２４】
前記応答メッセージが、要求した構成情報が入っているＤＮＳ応答メッセージである請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２５】
前記問い合わせメッセージが、前記アドレス識別子と前記構成識別子とを組み合わせることにより生成されたドメイン名フィールドが入っているＤＮＳ問い合わせメッセージである請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２６】
コンピュータにより実行されるときネットワークノードまたはサブネットの位置固有構成情報を検索する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が、
ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とを含むキーが入った問い合わせメッセージを生成するステップと、
前記問い合わせメッセージを、グローバルネーミングサービスを提供する分散システムの一部であって構成情報を記憶しているネームサーバへ送るステップと、
要求した構成情報が入っている応答メッセージを前記ネームサーバから受け取るステップと、
を含むコンピュータ可読記憶媒体。
【請求項２７】
ネットワークノードまたはサブネットの位置固有構成情報を検索する装置であって、
ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とを含むキーが入った問い合わせメッセージを生成するよう構成された生成機構と、
前記問い合わせメッセージを、グローバルネーミングサービスを提供する分散システムの一部であって構成情報を記憶しているネームサーバへ送るよう構成された送信機構と、
要求した構成情報が入っている応答メッセージを前記ネームサーバから受け取るよう構成された受信機構と、
を含む装置。
【請求項２８】
ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と構成情報のタイプを特定的に指示する構成識別子とを含む問い合わせメッセージをネットワークノードからネームサーバに受け取るよう構成された受信機構と、
構成データベースに入っている構成情報を前記キーを用いて検索するよう構成された検索機構と、
構成情報が入っている応答メッセージをネットワークノードへ送る送信機構と、
をさらに含む請求項２７に記載の装置。
【請求項２９】
前記ＩＰプレフィクスがＩＰアドレスのすべてのビットを含む請求項２７記載の装置。
【請求項３０】
前記キーを、ＩＰプレフィクスのバイトを逆順にし、そのＩＰプレフィクスの逆順バイトを文字列として表現し、構成情報のタイプを指定する文字列を上記の逆順にしたＩＰプレフィクス文字列の先頭に付加し、これにより得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加することにより生成する請求項２７に記載の装置。
【請求項３１】
前記ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項２７に記載の装置。
【請求項３２】
前記問い合わせメッセージがＤＮＳ問い合わせメッセージである請求項２７に記載の装置。
【請求項３３】
前記問い合わせメッセージがＤＮＳ応答メッセージである請求項２７に記載の装置。
【請求項３４】
前記ＩＰプレフィクスが、
ＩＰバージョン４プレフィクス、または
ＩＰバージョン６プレフィクス、
のどちらかである請求項２７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークノードの構成情報を検索するプロセスに関するものである。より詳しくは、本発明は、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバに問い合わせメッセージを送ることによってネットワークノードの構成情報を検索するプロセスに関する。
【背景技術】
【０００２】
インターネットは、カメラの購入から不動産購入にいたるまで、また新聞購読から映画鑑賞にいたるまで、われわれの生活のいろいろな面にますます多く入り込んできている。
【０００３】
インターネットの複雑性の故に、インターネットに参加したいコンピュータのようなネットワークノードは、大量の構成情報を検索する必要がある。例えば、ネットワークノードは、通常、まずメールサーバの名前を検索してからでないと電子メールを送受することができない。
【０００４】
ネットワークノードが検索する必要がある構成情報は、どちらかというと位置固有性であることが多い。例えば、ある組織中のネットワークノード用のメールサーバの名前は、同じ組織中にある別のネットワークノード用のメールサーバの名前とは異なる。さらに、ユーザにその構成情報を検索するよう求めることは面倒である。したがって、ネットワークノードがそれ自身の構成情報を自動的に検索できるようにするメカニズムが強く求められている。
【０００５】
動的ホスト構成プロトコル（ＤＨＣＰ）は、ネットワークノードにＩＰアドレスを自動的に割り当てるために設計された一般的に用いられているプロトコルである。その後、この規約は、ネットワークノードが構成情報を検索できるようにするべく拡張された。今日では、多くのネットワークノードが構成情報を検索するためにＤＨＣＰを使用している。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
残念ながら、構成情報を検索するためにＤＨＣＰを用いるについては多くの欠点がある。ＤＨＣＰは、通常、システム起動時に１回使用されるだけであるから、ネットワークノードは構成情報を検索する機会は１度しか得られない。これは、どのような種類の構成情報が将来必要になりそうかをネットワークノードに推定させることになるので、重大な制約である。例えば、ネットワークノードは、システム起動時にＮｅｔＢＩＯＳ（ネットバイオス）ネームサーバを検索しないと、通常のシステム動作時にこの情報を必要とするアプリケーションにそれを提供することができず、その結果アプリケーションが正しく動作しなくなる場合がある。
【０００７】
さらに、構成情報は時間が経つにつれて変化するため、システム起動時にＤＨＣＰを用いて得られた構成情報は期限切れになることがある。
【０００８】
ここで留意しなければならないのは、通常のシステム動作時にＤＨＣＰを使用して構成情報検索することは可能であるが、このような検索動作がすべてのＤＨＣＰサーバによりサポートされてはいない場合もある。その上、通常のシステム動作時に検索を行うことによって、ＤＨＣＰサーバが新しいＩＰアドレスをネットワークノードに割り当てることになり、その結果多くのアプリケーションが正しく機能しなくなる場合が起こり得る。
【０００９】
さらに、ＤＨＣＰは最大２５５タイプの構成情報しかサポートすることができず、これによって、ＤＨＣＰを用いて検索することができる構成情報のタイプに厳しい制約が課される。
【００１０】
これに加えて、ＩＰｖ６の利点の１つは、ＩＰｖ６ではネットワークノードがそのインタフェース用ＩＰｖ６アドレスをＤＨＣＰサーバの必要なく構成することが可能であるということである。このことは、ネットワークオペレータが維持しなければならないサーバ数が少なくなることにより、ネットワークオペレータにかかる負担が小さくなるので、有利である。しかしながら、ＩＰｖ６へのアップグレード後もなおネットワークオペレータがＤＨＣＰサーバを使用し続けなければならないとすると、ＩＰｖ６を使用することの重要な利点が失われることになる。
【００１１】
したがって、上に述べたような欠点を解消した広範囲の位置固有ネットワークノードの構成情報を検索する方法および装置が必要とされている。
【課題を解決するための手段】
【００１２】
本発明は、実施態様として、ネットワークノードまたはサブネットの位置固有構成情報を検索するシステムを提供するものである。システムの動作時、ネットワークノードは、ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とからなるキーが入った問い合わせメッセージを生成する。次に、ネットワークノードは、この問い合わせメッセージを、グローバルネーミングサービスを提供する分散システムの一部であって構成情報を記憶しているネームサーバへ送る。最後に、ネットワークノードは、要求した構成情報が入っている応答メッセージをネームサーバから受け取る。
【００１３】
この実施態様の変形例においては、ネームサーバは、ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とからなるキーが入った問い合わせメッセージをネットワークノードから受け取る。次に、ネームサーバは、そのキーを用いて構成データベースに入っている構成情報を検索する。最後に、ネームサーバは、構成情報が入っている応答メッセージをネットワークノードへ送る。
【００１４】
この実施態様のもう一つの変形例においては、ＩＰプレフィクスはＩＰアドレスのすべてのビットを含む。
【００１５】
この実施態様のもう一つの変形例においては、キーは、まずＩＰプレフィクスのバイトを逆順にし、そのＩＰプレフィクスの逆順バイトを文字列として表現することにより生成される。次に、構成情報のタイプを指定する文字列を上記の逆順にしたＩＰプレフィクス文字列の先頭に付加する。最後に、得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加して完全な形のキーを形成する。
【００１６】
この実施態様のもう一つの変形例においては、ネームサーバはドメインネームシステム（ＤＮＳ）に属する。
【００１７】
この実施態様のもう一つの変形例においては、問い合わせメッセージはＤＮＳ問い合わせメッセージである。
【００１８】
この実施態様のもう一つの変形例においては、応答メッセージはＤＮＳ応答メッセージである。
【００１９】
この実施態様のもう一つの変形例においては、ＩＰプレフィクスはＩＰバージョン４のプレフィクスまたはＩＰバージョン６のプレフィクスである。
【発明を実施するための最良の形態】
【００２０】
以下、本発明を当業者が実施することができるよう詳細に説明するが、説明は特定の利用形態やその要求事項との関連において行う。当業者にとっては、本願開示の実施形態について様々な修正・変更態様が自明であり、本願中に明確に記載する基本原理は、本発明の精神および範囲を逸脱することなく他の実施形態や利用の形態に適用することが可能である。したがって、本発明は、本願で説明する実施形態に限定されず、本願に開示する原理と特徴に合致する最大の範囲を許可されるべきものである。
【００２１】
この詳細な説明に記載するデータ構造とコードは、通常、コンピュータ可読記憶媒体に記憶される。この記憶媒体としては、コンピュータシステムで使用するコードおよび／またはデータを記憶することができる任意のデバイスあるいは媒体を用いることが可能である。このような記憶媒体としては、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）およびＤＶＤ（デジタル多目的ディスクまたはデジタルビデオディスク）のような磁気記憶装置や光記憶装置、さらに伝送媒体の形で実施されるコンピュータ命令信号（これらの信号を上に重ねることにより変調する搬送波の有無を問わない）があるが、これらに限定されるものではない。この伝送媒体としては、例えば、インターネットのような通信ネットワークがある。
ネットワーク
【００２２】
図１は、本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ１０２、メール転送プロトコル（ＳＭＴＰ）サーバ１１８、ネットワークタイムプロトコル（ＮＴＰ）サーバ１２０、ＮｅｔＢＩＯＳ（ネットバイオス）サーバ１２２、ポストオフィスプロトコル（ＰＯＰ３）サーバ１２４、構成情報が入っているドメインネームシステム（ＤＮＳ）ネームサーバ１１６に接続されたネットワークを１０４図解して示す説明図である。
【００２３】
ネットワーク１０４は、全般的に、ネットワークノードを互いに結合することができる任意の種類の有線または無線の通信チャンネルを含む。このような通信チャンネルとしては、ローカルエリアネットワーク、ワイドエリアネットワーク、あるいはネットワークを組合せた形のものがあるが、これらに限定されるものではない。本発明の一実施形態においては、ネットワーク１０４はインターネットを含む。
【００２４】
コンピュータ１０２のようなネットワークノードは、全般的に、ネットワークを介して他のネットワークノードと通信することができる任意の種類の通信デバイスを含む。このような通信デバイスとしては、マイクロプロセッサに基づくコンピュータシステム、メインフレームコンピュータ、サーバ、プリンタ、ビデオカメラ、外部ディスクドライブ、ルータ、交換機、電子手帳、携帯電話があるが、これらに限定されるものではない。
【００２５】
ネットワーク１０４は、コンピュータ１０２のようなソースネットワークノードがＳＭＴＰサーバ１１８のようなターゲットネットワークノードと通信することを可能にする。しかし、通信が行われるには、まずその前にソースネットワークノード、すなわちコンピュータ１０２がターゲットネットワークノード、すなわちＳＭＴＰサーバ１１８の名前またはＩＰアドレスを知ることが必要である。通常、このような構成情報は、コンピュータ１０２がＤＨＣＰを用いてシステム起動時に得、以後の使用に備えて保存する。
構成情報
【００２６】
図１には、本発明の一実施形態において、コンピュータ１０２に保存することができる構成情報１０６の集合が示してある。この構成情報１０６の集合には、ＳＭＴＰサーバ名１０８、ＮＴＰサーバ名１１０、ＰＯＰ３サーバ名、ＮｅｔＢＩＯＳサーバ名のような１以上の構成情報片が含まれる。その独特の効用として、構成情報１０６の集合は、コンピュータ１０２が種々のサービスをそのユーザに提供すること可能にする。例えば、コンピュータ１０２は、構成情報の集合の部分であるＳＭＴＰサーバ名１０８を使用してＳＭＴＰサーバ１１８と通信することができ、これによってメールサービスをそのエンドユーザに提供することができる。
ＤＮＳパケットの構造
【００２７】
図２は、本発明の一実施形態において、コンピュータ１０２のようなネットワークノードがそれを使ってＤＮＳネームサーバ１１６と情報を交換することができる多様な情報片が入ったＤＮＳパケット２００を示す説明図である。
【００２８】
ＤＮＳ問い合わせパケットとＤＮＳ応答パケットは、どちらも同じＤＮＳパケットフォーマットを使用する。具体的に言うと、ＤＮＳパケット２００中には、コンピュータ１０２のようなネットワークノードが問い合わせをそれぞれ対応する応答と合致させることを可能にする識別フィールド２０２が入っている。また、ＤＮＳ更新パケット２００中には、とりわけＤＮＳパケットが問い合わせであるか応答であるかを指示するフラグフィールド２０４も入っている。
【００２９】
さらに、ＤＮＳ更新パケット２００中には、４つの可変長フィールド、すなわち問い合わせフィールド２１４、応答リソースレコードフィールド２１６、オーソリティリソースレコードフィールド２１８、追加情報応答レコードフィールド２２０が入っている。これらの可変長フィールドは、ネットワークノード、すなわちコンピュータ１０２とＤＮＳネームサーバ１１６との間で情報を交換するために使用される。
【００３０】
上記の他、ＤＮＳパケット２００中には、さらに４つのフィールド、すなわち上記４つの可変長フィールドのエントリの番号をそれぞれ指定する問い合わせ番号フィールド２０６、応答リソースレコード番号フィールド２０８、オーソリティリソースレコード番号フィールド２１０、追加情報リソースレコード番号フィールド２１２が入っている。
問い合わせの構造
【００３１】
図３は、本発明の一実施形態において、問い合わせフィールド２１４に入っている問い合わせ３００の構造を示す説明図である。問い合わせフィールド３００には、問い合わせしているドメイン名を指定するドメイン名フィールド３０２が入っている。さらに、問い合わせ３００には、問い合わせ３００のタイプとクラスをそれぞれ指定する問い合わせタイプフィールド３０４と問い合わせクラスフィールド３０６が入っている。
リソースレコードの構造
【００３２】
図４は、本発明の一実施形態において、ＤＮＳネームサーバ１１６がそれを使って問い合わせに応答して情報を提供することができるリソースレコード４００の構造を示す説明図である。
【００３３】
具体的に言うと、リソースレコード４００には、考えているドメイン名を指定するドメイン名フィールド４０２が入っている。また、リソースレコード４００には、リソースレコードのタイプとクラスをそれぞれ指定するリソースレコードタイプフィールド４０４とリソースレコードクラスフィールド４０６も入っている。上記の他、リソースレコード４００には、さらに、リソースレコードをコンピュータ１０２のようなネットワークノードによりキャッシュすることができる時間の長さ（秒）を指定する有効時間フィールド４０８が入っている。さらに、リソースレコード４００には、リソースデータフィールド４１２が入っており、このフィールドは、ＤＮＳネームサーバ１１６が使用することにより、問い合わせに応じてネットワークノード、すなわちコンピュータ１０２へ情報を提供することができる可変長フィールドである。また、リソースレコード４００には、可変長リソースデータフィールド４１２中のデータ量を指定するリソースデータ長フィールド４１０も入っている。
構成情報を検索するプロセス
【００３４】
図５は、本発明の一実施形態において、コンピュータ１０２のようなネットワークノードがそれを使って構成情報１１６が入っているＤＮＳネームサーバに問い合わせることにより構成情報を検索するプロセスを図解したフローチャートである。
【００３５】
まず、コンピュータ１０２が、キーが入っている問い合わせ３００を含むＤＮＳ問い合わせパケット２００を生成する（ステップ５０２）。より詳しくは、問い合わせ３００中のドメイン名３２０は、まずＩＰプレフィクスのバイトを逆順にし、そのＩＰプレフィクスの逆順バイトを文字列として表現することにより生成されるキーを含んでいる。次に、構成情報のタイプを指定する文字列を上記の逆順にしたＩＰプレフィクス文字列の先頭に付加する。最後に、得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加して完全な形のキーを形成する。ここで留意しなければならないのは、文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”はアドレス−名前対応付けに用いられるＤＮＳ中の特殊なドメインを表すということである。
【００３６】
例えば、ＩＰアドレスがサブネットマスク２５５．２５５．０．０付きの１７．２５５．１２．３４のコンピュータ１０２がＮＴＰサーバ名１１０を検索したい場合、コンピュータ１１０はキー“４．ｄｈｃｐｏｐｔ．２５５．１７．ｉｎ−ａｄｄｒ．ａｒｐａ．“が入ったドメイン名３０２を備えた問い合わせ３００を生成する。ここで、“４．ｄｈｃｐｏｐｔ．”は構成情報のタイプを指定する文字列、“２５５．１７は“逆順ＩＰプレフィクスの文字列表現、“．ｉｎ−ａｄｄｒ．ａｒｐａ．”は付加文字列である。ここで留意しなければならないのは、文字列”４．ｄｈｃｐｏｐｔ．”は、インターネット技術標準化委員会（ＩＥＴＦ）コメント要求（ＲＦＣ）２１３２に規定するところにより、ＮＴＰサーバ名に対応するＤＨＣＰオプション４を指すということである。当業者にとっては、ＩＥＴＦ  ＲＦＣ２１３２の各オプションＤＨＣＰは、構成情報のタイプを指定する文字列に上記同様に変換できるということは自明であろう。
【００３７】
次に、コンピュータはＤＮＳ問い合わせパケット２００を構成情報１１６が入っているＤＮＳネームサーバに送る（ステップ５０４）。そして、構成情報１１６が入ったＤＮＳネームサーバがそのＤＮＳ問い合わせパケット２００を受け取る（ステップ５０６）。次に、構成情報１１６が入っているＤＮＳネームサーバは、そのデータベースでＤＮＳ問い合わせパケット２００に入っている問い合わせの中のキーを用いてその構成情報を検索する（ステップ５０８）。そして、構成情報１１６が入っているＤＮＳネームサーバは、その構成情報が入った応答メッセージを送り出す（ステップ５１０）。最後に、コンピュータ１０２は、構成情報が入った応答メッセージ受け取り（ステップ５１２）、これによってコンピュータ１０２はその構成情報を利用してタスクを行うことが可能になる。
【００３８】
さらに、コンピュータ１０２のようなネットワークノードは、多様な問い合わせを構成情報１１６が入っているＤＮＳネームサーバへ億って、種々異なるレベルの細分性で構成情報を検索することができる。例えば、ネットワークノードは、キー“４．ｄｈｃｐｏｐｔ．３４．１２．２５５．１７．ｉｎ−ａｄｄｒ．ａｒｐａ”が入っている問い合わせを送って、そのホストにだけ適用されるホスト固有構成情報を検索することができる。他方、ネットワークノードは、キー“４．ｄｈｃｐｏｐｔ．２５５．１７．ｉｎ−ａｄｄｒ．ａｒｐａ”が入っている問い合わせを送って、サブネット上のすべてのネットワークノード割り当てられるサブネット固有構成情報を検索することができる。さらに、ネットワークノードは、キー“４．ｄｈｃｐｏρｔ．１７．ｉｎ−ａｄｄｒ．ａｒｐａ”が入っている問い合わせを送って、社内のすべてのネットワークノードに一様に適用される全社対応構成情報を検索することができる。
【００３９】
ここで留意しなければならないのは、ＤＮＳは、ネットワークノードが通常のシステム動作時に問い合わせることができるように設計されているということである。それ故、ＤＨＣＰに代えてＤＮＳを用いて構成情報を保存することにより、本発明は、ネットワークノードによる構成情報の検索がシステム起動時に限定されるというＤＨＣＰに付随する制約の１つを克服したものである。さらに、本発明によれば、ネットワークノードは、構成情報が入っているＤＮＳネームサーバに周期的に問い合わせを行うことにより、構成情報を常に最新に保つことができる。さらにまた、本発明においては、構成情報のタイプを“４．ｄｈｃｐｏｐｔ”のような任意の文字列によって指定する。それ故、本発明は、ＤＨＣＰが最大２５５タイプの構成情報しかサポートすることができないのに対して、潜在的には無限のタイプの構成情報をサポートすることが可能である。
【００４０】
たものである。これらの説明は、包括的であることを意図したものでも、本発明を本願開示の形態に限定することを意図したものでもない。したがって、当業者にとっては多くの修正・変更態様が自明であろう。また、上記の開示内容は本発明を制限することを意図したものではない。本発明の範囲は、特許請求の範囲に明確に記載されているところにより定まる。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ、メール転送プロトコル（ＳＭＴＰ）サーバ、ネットワークタイムプロトコル（ＮＴＰ）サーバ、ネットバイオス（ＮｅｔＢＩＯＳ）サーバ、ポストオフィスプロトコル（ＰＯＰ３）サーバ、構成情報が入っているドメインネームシステム（ＤＮＳ）ネームサーバに接続されたネットワークを図解して示す説明図である。
【図２】本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使ってＤＮＳネームサーバと情報を交換することができる多様な情報片が書き込まれたＤＮＳパケットを示す説明図である。
【図３】本発明の一実施形態において、ＤＮＳパケット中の問い合わせフィールドを占める問い合わせの構造を示す説明図である。
【図４】本発明の一実施形態において、ＤＮＳネームサーバがそれを使って問い合わせに応答して情報を提供することができるリソースレコードの構造を示す説明図である。
【図５】本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使って構成情報が入っているＤＮＳネームサーバに問い合わせることにより構成情報を検索するプロセスを図解したフローチャートである。
【図１】
2007534237.tif 000002
【図２】
2007534237.tif 000003
【図３】
2007534237.tif 000004
【図４】
2007534237.tif 000005
【図５】
2007534237.tif 000006
【国際調査報告】
2007534237.tif 000007
2007534237.tif 000008