JP4405553B2 - ネットワークノードの構成情報を検索する方法および装置 - Google Patents

Description

本発明は、ネットワークノードの構成情報を検索するプロセスに関するものである。より詳しくは、本発明は、グローバルネーミングサービスを提供する分散システムの一部であるネームサーバに問い合わせメッセージを送ることによってネットワークノードの構成情報を検索するプロセスに関する。

インターネットは、カメラの購入から不動産購入にいたるまで、また新聞購読から映画鑑賞にいたるまで、われわれの生活のいろいろな面にますます多く入り込んできている。

インターネットの複雑性の故に、インターネットに参加したいコンピュータのようなネットワークノードは、大量の構成情報を検索する必要がある。例えば、ネットワークノードは、通常、まずメールサーバの名前を検索してからでないと電子メールを送受することができない。

ネットワークノードが検索する必要がある構成情報は、どちらかというと位置固有性であることが多い。例えば、ある組織中のネットワークノード用のメールサーバの名前は、同じ組織中にある別のネットワークノード用のメールサーバの名前とは異なる。さらに、ユーザにその構成情報を検索するよう求めることは面倒である。したがって、ネットワークノードがそれ自身の構成情報を自動的に検索できるようにするメカニズムが強く求められている。

動的ホスト構成プロトコル（ＤＨＣＰ）は、ネットワークノードにＩＰアドレスを自動的に割り当てるために設計された一般的に用いられているプロトコルである。その後、この規約は、ネットワークノードが構成情報を検索できるようにするべく拡張された。今日では、多くのネットワークノードが構成情報を検索するためにＤＨＣＰを使用している。

残念ながら、構成情報を検索するためにＤＨＣＰを用いるについては多くの欠点がある。ＤＨＣＰは、通常、システム起動時に１回使用されるだけであるから、ネットワークノードは構成情報を検索する機会は１度しか得られない。これは、どのような種類の構成情報が将来必要になりそうかをネットワークノードに推定させることになるので、重大な制約である。例えば、ネットワークノードは、システム起動時にＮｅｔＢＩＯＳ（ネットバイオス）ネームサーバを検索しないと、通常のシステム動作時にこの情報を必要とするアプリケーションにそれを提供することができず、その結果アプリケーションが正しく動作しなくなる場合がある。

さらに、構成情報は時間が経つにつれて変化するため、システム起動時にＤＨＣＰを用いて得られた構成情報は期限切れになることがある。

ここで留意しなければならないのは、通常のシステム動作時にＤＨＣＰを使用して構成情報検索することは可能であるが、このような検索動作がすべてのＤＨＣＰサーバによりサポートされてはいない場合もある。その上、通常のシステム動作時に検索を行うことによって、ＤＨＣＰサーバが新しいＩＰアドレスをネットワークノードに割り当てることになり、その結果多くのアプリケーションが正しく機能しなくなる場合が起こり得る。

さらに、ＤＨＣＰは最大２５５タイプの構成情報しかサポートすることができず、これによって、ＤＨＣＰを用いて検索することができる構成情報のタイプに厳しい制約が課される。

これに加えて、ＩＰｖ６の利点の１つは、ＩＰｖ６ではネットワークノードがそのインタフェース用ＩＰｖ６アドレスをＤＨＣＰサーバの必要なく構成することが可能であるということである。このことは、ネットワークオペレータが維持しなければならないサーバ数が少なくなることにより、ネットワークオペレータにかかる負担が小さくなるので、有利である。しかしながら、ＩＰｖ６へのアップグレード後もなおネットワークオペレータがＤＨＣＰサーバを使用し続けなければならないとすると、ＩＰｖ６を使用することの重要な利点が失われることになる。

したがって、上に述べたような欠点を解消した広範囲の位置固有ネットワークノードの構成情報を検索する方法および装置が必要とされている。

本発明は、実施態様として、ネットワークノードまたはサブネットの位置固有構成情報を検索するシステムを提供するものである。システムの動作時、ネットワークノードは、ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とからなるキーが入った問い合わせメッセージを生成する。次に、ネットワークノードは、この問い合わせメッセージを、グローバルネーミングサービスを提供する分散システムの一部であって構成情報を記憶しているネームサーバへ送る。最後に、ネットワークノードは、要求した構成情報が入っている応答メッセージをネームサーバから受け取る。

この実施態様の変形例においては、ネームサーバは、ネットワークノードまたはサブネットを特定するインターネットプロトコル（ＩＰ）プレフィクスと構成情報のタイプを指定する文字列とからなるキーが入った問い合わせメッセージをネットワークノードから受け取る。次に、ネームサーバは、そのキーを用いて構成データベースに入っている構成情報を検索する。最後に、ネームサーバは、構成情報が入っている応答メッセージをネットワークノードへ送る。

この実施態様のもう一つの変形例においては、ＩＰプレフィクスはＩＰアドレスのすべてのビットを含む。

この実施態様のもう一つの変形例においては、キーは、まずＩＰプレフィクスのバイトを逆順にし、そのＩＰプレフィクスの逆順バイトを文字列として表現することにより生成される。次に、構成情報のタイプを指定する文字列を上記の逆順にしたＩＰプレフィクス文字列の先頭に付加する。最後に、得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加して完全な形のキーを形成する。

この実施態様のもう一つの変形例においては、ネームサーバはドメインネームシステム（ＤＮＳ）に属する。

この実施態様のもう一つの変形例においては、問い合わせメッセージはＤＮＳ問い合わせメッセージである。

この実施態様のもう一つの変形例においては、応答メッセージはＤＮＳ応答メッセージである。

この実施態様のもう一つの変形例においては、ＩＰプレフィクスはＩＰバージョン４のプレフィクスまたはＩＰバージョン６のプレフィクスである。

以下、本発明を当業者が実施することができるよう詳細に説明するが、説明は特定の利用形態やその要求事項との関連において行う。当業者にとっては、本願開示の実施形態について様々な修正・変更態様が自明であり、本願中に明確に記載する基本原理は、本発明の精神および範囲を逸脱することなく他の実施形態や利用の形態に適用することが可能である。したがって、本発明は、本願で説明する実施形態に限定されず、本願に開示する原理と特徴に合致する最大の範囲を許可されるべきものである。

この詳細な説明に記載するデータ構造とコードは、通常、コンピュータ可読記憶媒体に記憶される。この記憶媒体としては、コンピュータシステムで使用するコードおよび／またはデータを記憶することができる任意のデバイスあるいは媒体を用いることが可能である。このような記憶媒体としては、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）およびＤＶＤ（デジタル多目的ディスクまたはデジタルビデオディスク）のような磁気記憶装置や光記憶装置、さらに伝送媒体の形で実施されるコンピュータ命令信号（これらの信号を上に重ねることにより変調する搬送波の有無を問わない）があるが、これらに限定されるものではない。この伝送媒体としては、例えば、インターネットのような通信ネットワークがある。
ネットワーク

図１は、本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ１０２、メール転送プロトコル（ＳＭＴＰ）サーバ１１８、ネットワークタイムプロトコル（ＮＴＰ）サーバ１２０、ＮｅｔＢＩＯＳ（ネットバイオス）サーバ１２２、ポストオフィスプロトコル（ＰＯＰ３）サーバ１２４、構成情報が入っているドメインネームシステム（ＤＮＳ）ネームサーバ１１６に接続されたネットワークを１０４図解して示す説明図である。

ネットワーク１０４は、全般的に、ネットワークノードを互いに結合することができる任意の種類の有線または無線の通信チャンネルを含む。このような通信チャンネルとしては、ローカルエリアネットワーク、ワイドエリアネットワーク、あるいはネットワークを組合せた形のものがあるが、これらに限定されるものではない。本発明の一実施形態においては、ネットワーク１０４はインターネットを含む。

コンピュータ１０２のようなネットワークノードは、全般的に、ネットワークを介して他のネットワークノードと通信することができる任意の種類の通信デバイスを含む。このような通信デバイスとしては、マイクロプロセッサに基づくコンピュータシステム、メインフレームコンピュータ、サーバ、プリンタ、ビデオカメラ、外部ディスクドライブ、ルータ、交換機、電子手帳、携帯電話があるが、これらに限定されるものではない。

ネットワーク１０４は、コンピュータ１０２のようなソースネットワークノードがＳＭＴＰサーバ１１８のようなターゲットネットワークノードと通信することを可能にする。しかし、通信が行われるには、まずその前にソースネットワークノード、すなわちコンピュータ１０２がターゲットネットワークノード、すなわちＳＭＴＰサーバ１１８の名前またはＩＰアドレスを知ることが必要である。通常、このような構成情報は、コンピュータ１０２がＤＨＣＰを用いてシステム起動時に得、以後の使用に備えて保存する。
構成情報

図１には、本発明の一実施形態において、コンピュータ１０２に保存することができる構成情報１０６の集合が示してある。この構成情報１０６の集合には、ＳＭＴＰサーバ名１０８、ＮＴＰサーバ名１１０、ＰＯＰ３サーバ名、ＮｅｔＢＩＯＳサーバ名のような１以上の構成情報片が含まれる。その独特の効用として、構成情報１０６の集合は、コンピュータ１０２が種々のサービスをそのユーザに提供すること可能にする。例えば、コンピュータ１０２は、構成情報の集合の部分であるＳＭＴＰサーバ名１０８を使用してＳＭＴＰサーバ１１８と通信することができ、これによってメールサービスをそのエンドユーザに提供することができる。
ＤＮＳパケットの構造

図２は、本発明の一実施形態において、コンピュータ１０２のようなネットワークノードがそれを使ってＤＮＳネームサーバ１１６と情報を交換することができる多様な情報片が入ったＤＮＳパケット２００を示す説明図である。

ＤＮＳ問い合わせパケットとＤＮＳ応答パケットは、どちらも同じＤＮＳパケットフォーマットを使用する。具体的に言うと、ＤＮＳパケット２００中には、コンピュータ１０２のようなネットワークノードが問い合わせをそれぞれ対応する応答と合致させることを可能にする識別フィールド２０２が入っている。また、ＤＮＳ更新パケット２００中には、とりわけＤＮＳパケットが問い合わせであるか応答であるかを指示するフラグフィールド２０４も入っている。

さらに、ＤＮＳ更新パケット２００中には、４つの可変長フィールド、すなわち問い合わせフィールド２１４、応答リソースレコードフィールド２１６、オーソリティリソースレコードフィールド２１８、追加情報応答レコードフィールド２２０が入っている。これらの可変長フィールドは、ネットワークノード、すなわちコンピュータ１０２とＤＮＳネームサーバ１１６との間で情報を交換するために使用される。

上記の他、ＤＮＳパケット２００中には、さらに４つのフィールド、すなわち上記４つの可変長フィールドのエントリの番号をそれぞれ指定する問い合わせ番号フィールド２０６、応答リソースレコード番号フィールド２０８、オーソリティリソースレコード番号フィールド２１０、追加情報リソースレコード番号フィールド２１２が入っている。
問い合わせの構造

図３は、本発明の一実施形態において、問い合わせフィールド２１４に入っている問い合わせ３００の構造を示す説明図である。問い合わせフィールド３００には、問い合わせしているドメイン名を指定するドメイン名フィールド３０２が入っている。さらに、問い合わせ３００には、問い合わせ３００のタイプとクラスをそれぞれ指定する問い合わせタイプフィールド３０４と問い合わせクラスフィールド３０６が入っている。
リソースレコードの構造

図４は、本発明の一実施形態において、ＤＮＳネームサーバ１１６がそれを使って問い合わせに応答して情報を提供することができるリソースレコード４００の構造を示す説明図である。

具体的に言うと、リソースレコード４００には、考えているドメイン名を指定するドメイン名フィールド４０２が入っている。また、リソースレコード４００には、リソースレコードのタイプとクラスをそれぞれ指定するリソースレコードタイプフィールド４０４とリソースレコードクラスフィールド４０６も入っている。上記の他、リソースレコード４００には、さらに、リソースレコードをコンピュータ１０２のようなネットワークノードによりキャッシュすることができる時間の長さ（秒）を指定する有効時間フィールド４０８が入っている。さらに、リソースレコード４００には、リソースデータフィールド４１２が入っており、このフィールドは、ＤＮＳネームサーバ１１６が使用することにより、問い合わせに応じてネットワークノード、すなわちコンピュータ１０２へ情報を提供することができる可変長フィールドである。また、リソースレコード４００には、可変長リソースデータフィールド４１２中のデータ量を指定するリソースデータ長フィールド４１０も入っている。
構成情報を検索するプロセス

図５は、本発明の一実施形態において、コンピュータ１０２のようなネットワークノードがそれを使って構成情報１１６が入っているＤＮＳネームサーバに問い合わせることにより構成情報を検索するプロセスを図解したフローチャートである。

まず、コンピュータ１０２が、キーが入っている問い合わせ３００を含むＤＮＳ問い合わせパケット２００を生成する（ステップ５０２）。より詳しくは、問い合わせ３００中のドメイン名３２０は、まずＩＰプレフィクスのバイトを逆順にし、そのＩＰプレフィクスの逆順バイトを文字列として表現することにより生成されるキーを含んでいる。次に、構成情報のタイプを指定する文字列を上記の逆順にしたＩＰプレフィクス文字列の先頭に付加する。最後に、得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加して完全な形のキーを形成する。ここで留意しなければならないのは、文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”はアドレス−名前対応付けに用いられるＤＮＳ中の特殊なドメインを表すということである。

例えば、ＩＰアドレスがサブネットマスク２５５．２５５．０．０付きの１７．２５５．１２．３４のコンピュータ１０２がＮＴＰサーバ名１１０を検索したい場合、コンピュータ１１０はキー“４．ｄｈｃｐｏｐｔ．２５５．１７．ｉｎ−ａｄｄｒ．ａｒｐａ．“が入ったドメイン名３０２を備えた問い合わせ３００を生成する。ここで、“４．ｄｈｃｐｏｐｔ．”は構成情報のタイプを指定する文字列、“２５５．１７は“逆順ＩＰプレフィクスの文字列表現、“．ｉｎ−ａｄｄｒ．ａｒｐａ．”は付加文字列である。ここで留意しなければならないのは、文字列”４．ｄｈｃｐｏｐｔ．”は、インターネット技術標準化委員会（ＩＥＴＦ）コメント要求（ＲＦＣ）２１３２に規定するところにより、ＮＴＰサーバ名に対応するＤＨＣＰオプション４を指すということである。当業者にとっては、ＩＥＴＦ ＲＦＣ２１３２の各オプションＤＨＣＰは、構成情報のタイプを指定する文字列に上記同様に変換できるということは自明であろう。

次に、コンピュータはＤＮＳ問い合わせパケット２００を構成情報１１６が入っているＤＮＳネームサーバに送る（ステップ５０４）。そして、構成情報１１６が入ったＤＮＳネームサーバがそのＤＮＳ問い合わせパケット２００を受け取る（ステップ５０６）。次に、構成情報１１６が入っているＤＮＳネームサーバは、そのデータベースでＤＮＳ問い合わせパケット２００に入っている問い合わせの中のキーを用いてその構成情報を検索する（ステップ５０８）。そして、構成情報１１６が入っているＤＮＳネームサーバは、その構成情報が入った応答メッセージを送り出す（ステップ５１０）。最後に、コンピュータ１０２は、構成情報が入った応答メッセージ受け取り（ステップ５１２）、これによってコンピュータ１０２はその構成情報を利用してタスクを行うことが可能になる。

さらに、コンピュータ１０２のようなネットワークノードは、多様な問い合わせを構成情報１１６が入っているＤＮＳネームサーバへ億って、種々異なるレベルの細分性で構成情報を検索することができる。例えば、ネットワークノードは、キー“４．ｄｈｃｐｏｐｔ．３４．１２．２５５．１７．ｉｎ−ａｄｄｒ．ａｒｐａ”が入っている問い合わせを送って、そのホストにだけ適用されるホスト固有構成情報を検索することができる。他方、ネットワークノードは、キー“４．ｄｈｃｐｏｐｔ．２５５．１７．ｉｎ−ａｄｄｒ．ａｒｐａ”が入っている問い合わせを送って、サブネット上のすべてのネットワークノード割り当てられるサブネット固有構成情報を検索することができる。さらに、ネットワークノードは、キー“４．ｄｈｃｐｏρｔ．１７．ｉｎ−ａｄｄｒ．ａｒｐａ”が入っている問い合わせを送って、社内のすべてのネットワークノードに一様に適用される全社対応構成情報を検索することができる。

ここで留意しなければならないのは、ＤＮＳは、ネットワークノードが通常のシステム動作時に問い合わせることができるように設計されているということである。それ故、ＤＨＣＰに代えてＤＮＳを用いて構成情報を保存することにより、本発明は、ネットワークノードによる構成情報の検索がシステム起動時に限定されるというＤＨＣＰに付随する制約の１つを克服したものである。さらに、本発明によれば、ネットワークノードは、構成情報が入っているＤＮＳネームサーバに周期的に問い合わせを行うことにより、構成情報を常に最新に保つことができる。さらにまた、本発明においては、構成情報のタイプを“４．ｄｈｃｐｏｐｔ”のような任意の文字列によって指定する。それ故、本発明は、ＤＨＣＰが最大２５５タイプの構成情報しかサポートすることができないのに対して、潜在的には無限のタイプの構成情報をサポートすることが可能である。

たものである。これらの説明は、包括的であることを意図したものでも、本発明を本願開示の形態に限定することを意図したものでもない。したがって、当業者にとっては多くの修正・変更態様が自明であろう。また、上記の開示内容は本発明を制限することを意図したものではない。本発明の範囲は、特許請求の範囲に明確に記載されているところにより定まる。

本発明の一実施形態において、多様なネットワークノード、すなわちコンピュータ、メール転送プロトコル（ＳＭＴＰ）サーバ、ネットワークタイムプロトコル（ＮＴＰ）サーバ、ネットバイオス（ＮｅｔＢＩＯＳ）サーバ、ポストオフィスプロトコル（ＰＯＰ３）サーバ、構成情報が入っているドメインネームシステム（ＤＮＳ）ネームサーバに接続されたネットワークを図解して示す説明図である。 本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使ってＤＮＳネームサーバと情報を交換することができる多様な情報片が書き込まれたＤＮＳパケットを示す説明図である。 本発明の一実施形態において、ＤＮＳパケット中の問い合わせフィールドを占める問い合わせの構造を示す説明図である。 本発明の一実施形態において、ＤＮＳネームサーバがそれを使って問い合わせに応答して情報を提供することができるリソースレコードの構造を示す説明図である。 本発明の一実施形態において、コンピュータのようなネットワークノードがそれを使って構成情報が入っているＤＮＳネームサーバに問い合わせることにより構成情報を検索するプロセスを図解したフローチャートである。

Claims (20)

1. ネットワークノードまたはサブネットの位置固有構成情報を検索する方法であって、
   ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と、
   所望の構成情報のタイプを特定的に指示する構成識別子と
   を含む問い合わせメッセージを生成するステップであって、前記問い合わせメッセージが、前記アドレス識別子と前記構成識別子とを組み合わせることにより生成されたドメイン名フィールドが入っているＤＮＳ問い合わせメッセージであるステップと、
   前記問い合わせメッセージをグローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと、
   前記ネームサーバから応答メッセージを受け取るステップと、
   を含む方法。
2. 前記アドレス識別子が、インターネットプロトコルアドレスの１以上のビットの文字列表現である請求項１に記載の方法。
3. 前記ネームサーバからの応答メッセージに、要求した構成情報を入れ得る請求項１に記載の方法。
4. 前記ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項１に記載の方法。
5. 前記問い合わせメッセージに、構成識別子をアドレス識別子の先頭に付加し、これにより得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加することによって生成されるキーが入っている請求項１に記載の方法。
6. 前記問い合わせメッセージがＤＮＳ問い合わせメッセージである請求項１に記載の方法。
7. ネットワークノードまたはサブネットの位置固有構成情報を検索する方法であって、
   前記ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と構成情報のタイプを特定的に指示する構成識別子とを含む問い合わせメッセージをネットワークノードからネームサーバに受け取るステップと、
   前記問い合わせメッセージ中に入っている情報を用いて前記構成情報を前記ネームサーバのデータベースで検索するステップと、
   応答メッセージを前記ネットワークノードへ送るステップと、
   を含み、
   前記問い合わせメッセージが、前記アドレス識別子と前記構成識別子とを組み合わせることにより生成されたドメイン名フィールドが入っているＤＮＳ問い合わせメッセージである
   方法。
8. 前記アドレス識別子が、ＩＰバージョン４アドレスの１以上のビットの文字列表現またはＩＰバージョン６アドレスの１以上のビットの文字列表現のどちらか一方である請求項７に記載の方法。
9. 前記ネームサーバのデータベースで前記構成情報を検索するステップが、１以上のリソースレコードにアクセスするステップを含む請求項７に記載の方法。
10. 前記応答メッセージが、要求した構成情報が入っているＤＮＳ応答メッセージである請求項７に記載の方法。
11. コンピュータにより実行されるときネットワークノードまたはサブネットの位置固有構成情報を検索する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が、
    ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と、
    所望の構成情報のタイプを特定的に指示する構成識別子と、を含む問い合わせメッセージを生成するステップであって、前記問い合わせメッセージが、前記アドレス識別子と前記構成識別子とを組み合わせることにより生成されたドメイン名フィールドが入っているＤＮＳ問い合わせメッセージであるステップと、
    前記問い合わせメッセージをグローバルネーミングサービスを提供する分散システムの一部であるネームサーバへ送るステップと、
    前記ネームサーバから応答メッセージを受け取るステップと、を含むコンピュータ可読記憶媒体。
12. 前記アドレス識別子が、インターネットプロトコル（ＩＰ）アドレスの１以上のビットの文字列表現である請求項１１に記載のコンピュータ可読記憶媒体。
13. 前記ネームサーバからの応答メッセージが要求した構成情報を含む請求項１１に記載のコンピュータ可読記憶媒体。
14. 前記ネームサーバがドメインネームシステム（ＤＮＳ）に属する請求項１１に記載のコンピュータ可読記憶媒体。
15. 前記問い合わせメッセージに、
    構成識別子をアドレス識別子の先頭に付加し、
    これにより得られた文字列に文字列“．ｉｎ−ａｄｄｒ．ａｒｐａ．”を付加すること、によって生成されるキーが入っている請求項１１に記載のコンピュータ可読記憶媒体。
16. 前記応答メッセージがＤＮＳ応答メッセージである請求項１１に記載のコンピュータ可読記憶媒体。
17. コンピュータにより実行されるときネットワークノードまたはサブネットの位置固有構成情報を検索する方法を前記コンピュータに遂行させる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が、
    前記ネットワークノードまたはサブネットを特定的に指示するアドレス識別子と、
    構成情報のタイプを特定的に指示する構成識別子と、
    を含む問い合わせメッセージをネットワークノードからネームサーバに受け取るステップと、
    前記問い合わせメッセージ中に入っている情報を用いて前記構成情報を前記ネームサーバのデータベースで検索するステップと、
    応答メッセージを前記ネットワークノードへ送るステップと、
    を含み、
    前記問い合わせメッセージが、前記アドレス識別子と前記構成識別子とを組み合わせることにより生成されたドメイン名フィールドが入っているＤＮＳ問い合わせメッセージである、
    コンピュータ可読記憶媒体。
18. 前記アドレス識別子が、
    ＩＰバージョン４アドレスの１以上のビットの文字列表現、または
    ＩＰバージョン６アドレスの１以上のビットの文字列表現、
    のどちらか一方である請求項１７に記載のコンピュータ可読記憶媒体。
19. 前記ネームサーバのデータベースで前記構成情報を検索するステップが、１以上のリソースレコードにアクセスするステップを含む請求項１７に記載のコンピュータ可読記憶媒体。
20. 前記応答メッセージが、要求した構成情報が入っているＤＮＳ応答メッセージである請求項１７に記載のコンピュータ可読記憶媒体。

Images