JP3577067B2

JP3577067B2 - 動的ｉｐアドレス割当てを受けた機器を管理する方法およびシステム

Info

Publication number: JP3577067B2
Application number: JP2002371448A
Authority: JP
Inventors: 一福嶋
Original assignee: 一福嶋
Priority date: 2002-12-24
Filing date: 2002-12-24
Publication date: 2004-10-13
Anticipated expiration: 2022-12-24
Also published as: JP2004266305A; JPWO2004059925A1; EP1578068A1; US20060101026A1; JP4417850B2; CN1754351A; KR20080040784A; EP1578068A4; US7831697B2; AU2003296079A1; KR100838911B1; CN1754351B; KR20050084465A; WO2004059925A1

Description

【０００１】
【発明の属する技術分野】
本発明はＴＣＰ／ＩＰにおけるネットワーク管理技術に属する。
ＴＣＰ／ＩＰネットワークにおいて固定的なＩＰアドレスの割当を受けない（動的割当を受けた）ホストでＴＣＰ／ＩＰによるネットワークサービス（以下、「インターネットサービス」とする。なお、ここではＴＣＰ／ＩＰによるネットワークサービスでありさえすれば、広域のインターネットワーキング（以下、「グローバルサービス」とする）であるか任意の範囲で閉じたネットワーク（通常「イントラネット」あるいは「ローカルエリアネットワーク」（以下、「ＬＡＮ」とする）などと呼ばれている）であるかを問わないものとする）を提供させる際の管理技術に属する。
【０００２】
【従来の技術】
インターネット（＝ｔｈｅＩｎｔｅｒｎｅｔ）は非常に多数のコンピュータとコンピュータ・ネットワークから構成され、これらはＴＣＰ／ＩＰプロトコルを用いた通信リンクを通して世界的な規模で相互に接続されている。相互に接続されたコンピュータは、電子メール、ゴーファー、およびワールドワイドウェブなどの、様々なインターネットサービスを利用して情報をやりとりしている。
【０００３】
インターネットは、ネットワーク割当て団体から一意に割当てられたＩＰアドレスによって、そのホストを識別している。ＩＰアドレスは、計算機が処理し易いように固定長の数字の羅列として表現されており、人間にとっては無意味綴りであり、覚えたり毎回間違えずに入力したりするのが困難である。ＴＣＰ／ＩＰネットワークにおいては、ホストを特定するためには少なくともＩＰアドレスが必要であり、ＩＰアドレスでホストを特定することが人間にとって判りにくいものであるという問題を軽減するために、ドメインネームシステム（以下、「ＤＮＳ」とする）を用いてホストを特定することがおこなわれてきた。
【０００４】
ＤＮＳは、ＩＰアドレスのような数字の羅列ではなく、人間にとって意味がある文字列でインターネット上のホストを特定するためのデータベースシステムである。図２に示すように階層的な名前空間を構成しており、ドメイン名と呼ばれる文字列を登録しておき、これをＩＰアドレスと対応づけることによって、インターネット上のホストを特定する。これを正引き名前解決という。逆に、ＩＰアドレスからドメイン名を検索することを逆引き名前解決という。ＤＮＳの特徴は、ルートサーバを頂点とする木構造の分散データベースである。また、ＩＰアドレスはルーティングの制約を受けるが、ＤＮＳにおける名前はホストのネットワーク的な位置とは無関係に存在できる。
【０００５】
一般にインターネットに常時接続し、ＩＰアドレスの割当てを受けた各利用組織は、ドメイン名の登録団体に対して、ドメインの登録をおこない、自組織のためのドメイン名の運用をおこなう。この時にドメイン運用をおこなうサーバがＤＮＳサーバである。なお、ＤＮＳサーバの登録には、ドメイン名の登録団体に対してＩＰアドレスおよびホスト名を指定して、ＤＮＳサーバの登録をおこなう。
【０００６】
ルートサーバは第一レベルのＤＮＳサーバに、第一レベルのＤＮＳサーバは第二レベルのＤＮＳサーバに、そして最終的に上で示したＩＰアドレスの割当てを受けた各利用組織のＤＮＳサーバにドメイン運用の権限の委譲をおこなう。図１９に、ＤＮＳの検索順を示す。ＩＰアドレスの割当てを受けた各利用組織のＤＮＳサーバでは、ドメイン名に対するホスト名とＩＰアドレスの対応づけや、メールの配送経路の指定などといった実際の設定をおこなう。
【０００７】
旧来ＤＮＳは設定ファイルを手動で設定および更新されてきた。ところが主に社内で利用されるプライベートＬＡＮなどにおいて、Ｗｉｎｄｏｗｓ（登録商標、以下同様）パソコンの普及とダイナミック・ホスト・コンフィグレーション・プロトコル（ＤＨＣＰ）による端末となるパソコンの動的なネットワーク設定の普及によって、Ｗｉｎｄｏｗｓパソコンが再起動されるたびにＩＰアドレスが変化するなどの、従来のように静的に１のホスト名と１のＩＰアドレスを対応づけることが難しくなってきた。ダイナミックＤＮＳとは、ＤＮＳサーバのレコードの更新をクライアントからのアップデート要求によって自動的に更新するしくみを提供するものである。ダイナミックＤＮＳの利用について、社内ＬＡＮなどの直接インターネットに接しないネットワークにおける利用だけではなく、インターネットのグローバルサービスの中でも、現在、実用性の検証がされている。
【０００８】
インターネットのグローバルサービスの中でダイナミックＤＮＳサービスを利用した場合には、ネットワーク割当て団体からネットワークの割当てを受けないあるいはプロバイダから固定的なＩＰアドレス割当てを受けない（ダイヤルアップの）ホストで、インターネットサービスを提供することが出来るようになる。
【０００９】
ところで、ダイヤルアップとは、主にダイヤルアップ接続としてインターネットに接続する際に電話をかける行為を伴うものをいうが、近年ケーブルテレビやデジタル加入者回線、光ファイバをアクセス回線に用いた定額制のＩＰ接続役務などによるアクセス回線の多様化により、必ずしも電話をかける行為を必要としなくなっている。これら近年の常時接続型と呼ばれるインターネット接続役務は、単に接続時間による課金体系でなくなったことを意味し、ルータのセッション異常終了（停電など）、回線の異常、センタの故障やメンテナンスなどにより接続が異常切断された場合や接続業者もしくはダイヤルアップするホストの無通信タイマーによって回線が切断された場合などに再接続すると、ＩＰアドレスが変わる場合があるという点で専用線による接続と異なる。そこで本発明では、従来の専用線による接続に代表されるネットワーク割当団体から恒常的なネットワークの割当てを受けて接続する場合かプロバイダ（あるいはＩＰアドレスの割当てを受けた各利用組織）から恒常的なＩＰアドレスの割当てを受けて接続する場合と対比して、プロバイダ（あるいはＩＰアドレスの割当てを受けた各利用組織）からの一時的な利用を前提としたＩＰアドレスの割当てを受けて接続することを（モデムを用いて電話をかけるという行為を伴わず、ＤＨＣＰやＰＰＰｏＥなどによる割当てであったとしても）「ダイヤルアップ接続」といい、一時的なＩＰアドレスの割当てを受けるための動作をすることを「ダイヤルアップする」という。また、ＩＰアドレスの一時的な割当てそのものを「ダイヤルアップ」ということとする。
【００１０】
【ダイナミックＤＮＳ特有の問題】
従来の技術では、ＩＰアドレスが変化するホストでのインターネットサービスの提供はできなかったが、ごく最近になってダイナミックＤＮＳを用いることによって、限定的に（グローバルサービスとしてのＤＮＳは固定ＩＰアドレスが必要なことからＤＮＳ以外の）インターネットサービスを提供できるようになった。しかし、ダイナミックＤＮＳを用いることに特有の以下の問題点があったので、これを以下の図で説明する。
図３。管理対象機器（４１００）からプロバイダＡ（４０００）へダイヤルアップ（ＰＰＰｏＥなどを含む）する。
図４。管理対象機器（４１００）はプロバイダＡ（４０００）からＩＰアドレスの動的割当てを受ける。この時、割当てを受けたＩＰアドレスを仮に１７２．１６．１００．１００とする。
図５。管理対象機器（４１００）はセンタ側ＤＮＳサーバ（１０００）へＤＮＳの更新要求をし、ダイナミックＤＮＳを運用するセンタ側のＤＮＳサーバ（１０００）（以下、「センタ側ＤＮＳサーバ」とする）は図４で管理対象機器（４１００）に割当てられたＩＰアドレス（仮に１７２．１６．１００．１００）をＤＮＳに設定する。
図６。管理対象機器（４１００）は、インターネットの一般利用者（５３００）からのアクセスを受ける事ができる（正常状態）。
図７。なんらかの理由で管理対象機器（４１００）からプロバイダＡ（４０００）への接続が失われるなどの障害が発生する。
【００１１】
図８。管理対象機器（４１００）からプロバイダＡ（４０００）へ再接続（ＰＰＰｏＥなどを含む）する。
図９。管理対象機器（４１００）はプロバイダＡ（４０００）からＩＰアドレスの動的割当てを受ける。ＩＰアドレスが変化するまで割当てられていたＩＰアドレス（仮に１７２．１６．１００．１００）とは別のＩＰアドレス（仮に１７２．１６．２００．１０）が割当てられる。
図１０。管理対象機器（４１００）はセンタ側ＤＮＳサーバ（１０００）へＤＮＳの更新要求をだし、センタ側ＤＮＳサーバ（１０００）は図９で割当てられたＩＰアドレス（仮に１７２．１６．２００．１０）をＤＮＳに設定する。
【００１２】
図１１。図９において、この時、管理対象機器（４１００）のＩＰアドレスはＩＰアドレスが変化するまで割当てられていたＩＰアドレスとは別のアドレス（仮に１７２．１６．２００．１０）を割当てられており、管理対象機器（４１００）にＩＰアドレスが変化するまで割当てられていたＩＰアドレス（仮に１７２．１６．１００．１００）は同一プロバイダの別のユーザ（４２００）に割当てられている。この場合において、インターネットの一般利用者（５３００）から見るとホストがすり替わっているかのように見える。
図１２。インターネット全体では参照されるＤＮＳはここでいうセンタ側ＤＮＳサーバ（１０００）ではあり得ず、各利用者毎に直接接続されたプロバイダのＤＮＳ（４５００や５５００など）である事がほとんどであると思われる。そのため、仮にセンタ側ＤＮＳサーバ（１０００）が正常に更新されたとしても、キャッシュの生存時間内には、各利用者毎に直接接続されたプロバイダのＤＮＳ（４５００や５５００など）からセンタ側ＤＮＳサーバ（１０００）への名前問合せは行われないために、これらのＤＮＳサーバに管理対象機器（４１００）のＩＰアドレス（仮に１７２．１６．２００．１０）が反映されるには時間がかかる。
【００１３】
ＤＮＳ（４５００や５５００など）は、一度問合せをおこなったリソースレコードに関して、一定期間ローカルに記憶しておく。これをキャッシュという。キャッシュは、リソースレコードのＴＴＬ（＝ｔｉｍｅｔｏｌｉｖｅ。キャッシュの生存時間に同じ）で指定された期間だけ記憶され、その後破棄される。これをキャッシュの生存時間という。キャッシュの生存時間中は、ＤＮＳ（４５００や５５００など）はリゾルバ（４１００や４２００あるいは５３００など）からの問合せに対して、ローカルな記憶を参照して名前解決するために、一度おこなった名前問合せを繰り返すことを抑制し、効率をよくするために考えられた。しかし、ダイナミックＤＮＳにおいては、このキャッシュというメカニズムが逆に管理対象機器（４１００）のＩＰアドレスの変化に追従できないなどのうまく合致していない部分があるので、以下に説明する。
【００１４】
図１８に、一般利用者（５３００）からどのようにＤＮＳが探索され、目的ホストである管理対象機器（４１００）に到達するかを順に見てみる。
▲１▼で、一般利用者（５３００）からプロバイダＢのＤＮＳ（５５００）へ、管理対象機器（４１００）について正引き名前問合せをおこなう。
▲２▼、プロバイダＢのＤＮＳ（５５００）は、まず、目的ドメイン名を知っているかどうかを調べ、知っている場合は、即座に目的ホストである管理対象機器（４１００）のＩＰアドレスを一般利用者（５３００）に返す。この時、プロバイダＢのＤＮＳ（５５００）が目的ドメイン名を知っている場合とは、目的ドメイン名をプロバイダＢのＤＮＳ（５５００）が運用している場合と、目的ホストである管理対象機器（４１００）に対するＩＰアドレスがプロバイダＢのＤＮＳ（５５００）に、キャッシュされている場合である。プロバイダＢのＤＮＳ（５５００）が目的ドメイン名を知らない場合を、図１９に示す。
▲３▼、▲２▼によって管理対象機器（４１００）のＩＰアドレスを知ることができた一般利用者（５３００）は、これをもとに、管理対象機器（４１００）へアクセスする。
【００１５】
図１９は、図１８の▲２▼で、プロバイダＢのＤＮＳ（５５００）が管理対象機器（４１００）のドメインを運用していない場合と、キャッシュされていない場合（最初の名前問合せの時）のＤＮＳの探索順である。
▲１▼で、一般利用者（５３００）からプロバイダＢのＤＮＳ（５５００）へ、管理対象機器（４１００）について正引き名前問合せをおこなう。
▲２▼、プロバイダＢのＤＮＳ（５５００）は、目的ドメイン名である管理対象機器（４１００）のドメインを運用しておらず、キャッシュの中からも見つけられなかった場合、ＲｏｏｔＤＮＳに、名前問合せをする。
▲３▼、ＲｏｏｔＤＮＳは、仮に目的ホストである管理対象機器（４１００）のドメイン名が例としてＪＰドメインであった場合には、ＪＰＤＮＳの所在を返す。（管理対象機器（４１００）のドメイン名がＪＰドメインではない場合には、ｃｃＴＬＤなり、ｇＴＬＤなりを管理するネームサーバの所在をプロバイダＢのＤＮＳ（５５００）に返す。）
▲４▼、プロバイダＢのＤＮＳ（５５００）は、▲３▼で得たＪＰドメインのＤＮＳに対して、目的ドメイン名である管理対象機器（４１００）のドメインを名前問合せをする。
▲５▼、ＪＰドメインのＤＮＳは、目的ホストである管理対象機器（４１００）のドメイン名を運用するサーバ（ここではセンタ側ＤＮＳサーバ（１０００））の所在を（ＪＰ配下のドメインは、ＪＰＮＩＣおよび会員のサーバに登録されるツリー構造であり、第二レベル毎のＤＮＳには分かれていないため、すぐに）プロバイダＢのＤＮＳ（５５００）に返す。
▲６▼、プロバイダＢのＤＮＳ（５５００）は、▲５▼で得たセンタ側ＤＮＳサーバ（１０００）に対して、管理対象機器（４１００）のＩＰアドレスを名前問合せをする。
▲７▼、センタ側ＤＮＳサーバ（１０００）は、管理対象機器（４１００）の所在をプロバイダＢのＤＮＳ（５５００）に返す。
▲８▼、プロバイダＢのＤＮＳ（５５００）は、▲７▼で得た管理対象機器（４１００）の所在を一般利用者（５３００）に返す。
▲９▼、一般利用者（５３００）は、管理対象機器（４１００）へアクセスする。
図２０。ＤＮＳ（４５００や５５００など）は、最初の名前問合せによってキャッシュされ、その後キャッシュの期限が過ぎた事によって、キャッシュが無効となるよう設定するのが一般的である。このキャッシュが無効なタイミング（図１９）では、センタ側ＤＮＳサーバ（１０００）に対して名前問合せがおこなわれるために正しく管理対象機器（４１００）のＩＰアドレスが得られる。しかし、キャッシュが有効な間（図１８）に管理対象機器（４１００）のＩＰアドレスが変ってしまった場合、センタ側ＤＮＳサーバ（１０００）に対する名前問合せなしにキャッシュされたＩＰアドレスが返されるために、図１０での更新より以前の（キャッシュされた）ＩＰアドレス（仮に１７２．１６．１００．１００）が返される。なお、図１８の▲２▼のとおり、一般利用者（５３００）の接続先であるプロバイダＢのＤＮＳ（５５００）が管理対象機器（４１００）のドメインを運用している場合には、キャッシュの問題は発生しない。
【００１６】
図１３。そのために、インターネット全体から見れば、このタイミングで、同一プロバイダの別のユーザ（４２００）が管理対象機器（４１００）として誤認されてしまうおそれがある。
またこの時、管理対象機器（４１００）はメールサーバやｗｗｗサーバの機能が設定されたホストであるものとしても、別のホスト（４２００）はメールサーバやｗｗｗサーバの設定はされていないホストであるか、仮に設定されていたとしても管理対象機器（４１００）の設定とは違う内容であるために、一般利用者（５３００）からは、管理対象機器（４１００）が正常でない状態（障害発生中）にあるように見えてしまう。
図１４。この問題は、インターネット上の各プロバイダのＤＮＳ（４５００や５５００など）が、キャッシュの生存時間が過ぎ、センタ側ＤＮＳサーバに再度、名前問合せをおこなえば、収束される問題である。そのために、時間が経過するにしたがって、図１４のような正常な状態となる。
【００１７】
次に、回線断後、管理対象機器（４１００）が再接続しない（回線断のままの）場合について考えてみる。
この場合に、考えられる理由は回線障害や（ダイヤルアップをする）プログラムの障害などである。
図３ないし図７までは、前述の説明と同じである。つぎに、
図１５において、この時、管理対象機器（４１００）はインターネットへ接続されていない状態のためプロバイダＡは、管理対象機器（４１００）にＩＰアドレスが変化するまで割当てられていたＩＰアドレス（仮に１７２．１６．１００．１００）を同一プロバイダの別のユーザ（４２００）がダイヤルアップした時点で、別のユーザ（４２００）に割当てる。
図１６。センタ側ＤＮＳサーバ（４０００）に設定されている管理対象機器（４１００）のＩＰアドレスは、更新そのものが出来ないために、切断前のＩＰアドレス（仮に１７２．１６．１００．１００）が設定されている。そのために、やはり同一プロバイダの別のユーザ（４２００）が管理対象機器（４１００）と誤認されてしまう。
【００１８】
図２１は、管理対象機器（４１００）の動作フローである。ここで、破線内は、管理対象機器（４１００）が影響を与える外部環境の状態である。障害が発生したタイミングによって、インターネットから見失われたり、誤認されたりする。なお、図２１において、Ｓ１０８は管理対象機器（４１００）において、検出可能なイベントであると同時に外部環境の変化でもある。
【００１９】
図２２は、管理対象機器（４１００）における、管理対象機器（４１００）の状態と割当てＩＰアドレスの関係からの障害のパターンである。
パターン１は、回線断のままの場合である。管理対象機器（４１００）が回線断後再接続出来なかった場合には、回線断以前に割当てられていたＩＰアドレスが別のユーザ（４２００）に割当てられている場合に、誤認となる。割当てられていなかった場合に、アクセス不可となる。アクセス不可とは、目的ホストである管理対象機器（４１００）に到達せずに見失われた状態である。回線断のままの場合は、ＤＮＳ（４５００や５５００など）への再更新を、管理対象機器（４１００）は当然することが出来ない。
パターン２は、ＤＮＳへのダイナミックアップデートに失敗した場合である。管理対象機器（４１００）のダイナミックアップデートに係る部分のプログラム障害やセンタ側ＤＮＳサーバ（１０００）の障害などによって起こる。この場合において回線は、接続されているか、切断されても再接続されているものとする。この時の動作は、パターン１の管理対象機器（４１００）が回線断後再接続出来なかった（回線断のまま）場合と同様に、回線断以前に割当てられていたＩＰアドレスが別のユーザ（４２００）に割当てられている場合に、誤認となる。割当てられていなかった場合に、アクセス不可となる。また、割当てＩＰアドレスが変化しなかった場合には、インターネットの一般利用者（５３００）からの通信には問題がないために、正常であるようかのようにみえる。
パターン３は、回線断後再接続した場合である。キャッシュの生存時間の影響を受け、網掛け部分はキャッシュの生存時間の影響を受ける部分であり、それ以外は、キャッシュされていないために、名前問合せがうまく行っている場合である。ここで通信の相手方であるインターネットの一般利用者（５３００）は、地域的に広がっており、個別の各インターネットの一般利用者（５３００）が以前に名前参照したことがあるか、あればキャッシュされているほど最近の名前参照であったかによって、網掛け部分に含まれるか否かが決定される。
【００２０】
図２２において、網掛け部分は、管理対象機器（４１００）が回線断後再接続し、センタ側ＤＮＳサーバ（１０００）への更新もうまく行っている場合における、管理対象機器（４１００）の動作としては正常であるにも関わらず、ＤＮＳ（４５００や５５００など）が管理対象機器（４１００）のＩＰアドレスをキャッシュしているために、管理対象機器（４１００）が一時的に障害状態にあるように見えてしまうタイミングである。
【００２１】
以上に、キャッシュというメカニズムが逆に管理対象機器（４１００）のＩＰアドレスの変化に追従できないなどのうまく合致していない部分があることを説明してきた。
この問題はダイナミックＤＮＳの仕組が旧来のＤＮＳへの拡張であり、後付けされたものであるために、発生する。
【００２２】
前記した通り、旧来ＤＮＳは手動で設定および更新されていた。ダイナミックＤＮＳを利用した場合には、管理対象機器（４１００）からセンタ側ＤＮＳサーバ（１０００）への更新の間隔が短い場合に、ＤＮＳを参照（正引き）して得られた管理対象機器（４１００）のＩＰアドレスは必ずしも正しいとは言えない場合があり得ることを説明してきた。
キャッシュの生存時間経過後、センタ側ＤＮＳ（１０００）へ名前問合せするタイミングに比して、管理対象機器（４１００）の回線断およびＩＰアドレス更新の間隔が短すぎると、一般利用者（５３００）は常に別のホストを管理対象機器（４１００）と誤認することになる。回線の不安定を原因とするこのような場合にも、ＤＮＳとしては機能することが望まれるが、ダイナミックＤＮＳとしてはこの場合において、機能し得ず一種の障害状態とみなし得る。
【００２３】
これはＤＮＳをめぐるインターネット全体の問題であり、個別の実装などによって（個々のホストが対応するだけでは）解決することができない問題である。
【００２４】
以上によって、一時的に動的なＩＰアドレスを割当てられたホストにおいては、ホストの動作としては正常であったとしても、障害状態に見えてしまうなどの問題があり、ホストを特定しづらい状況にある。
【００２５】
【発明が解決しようとする課題】
インターネットの一般利用者（５３００）が管理対象機器（４１００）だと認識していたとしても、実際には別の無関係なホストであり得る。そこで、少なくとも管理サーバ（２０００）からは、管理対象機器（４１００）が、誤認されたホスト（４２００）でなく管理対象機器だと認識されているホストとして本当に正しい通信相手（真性なホスト）であることを確認する手段を提供する。
【００２６】
【課題を解決するための手段】
ホストの確認については、以下の方法でもって確認する。ここでは管理サーバ（２０００）から管理対象機器（４１００）に対して通信をした結果から、管理対象機器（４１００）が真性のホストであるかどうかの判定を、管理サーバ（２０００）がする。
課題を解決するための手段は、以下の三段階でおこなう。
準備段階として、合意および設定がある。
第一の段階はアドレス確認であり、
第二の段階は真性確認である。
図２７に、第一の段階および第二段階によって実際に管理対象機器（４１００）の真性確認をおこなう、管理サーバ（２０００）の動作を示す。
【００２７】
合意および設定は、準備段階である。
管理サーバ（２０００）および管理対象機器（４１００）の双方で、管理対象機器（４１００）名に対するあらかじめ合意された通信の方式と合意された方式での通信に対する答えられるべき返事の組あるいはペアテーブルを合意する。
これを管理サーバ（２０００）に設定する。
動的ＩＰアドレスを割当てられたホストであるところのあるいは前記ホストと一体となって外部ネットワークから参照されるホストであるところの管理対象機器（４１００）にあらかじめ合意された方式での通信に対する答えるべき返事を設定する。
ただし、以上の合意および設定に先立って、管理対象機器（４１００）が外部ネットワークからホスト名でアクセスできるようにするために、ドメイン名およびホスト名を選択し、センタ側ＤＮＳサーバ（１０００）に登録し、管理対象機器（４１００）が回線断あるいはＩＰアドレスの変化を検出し再接続し、ＤＮＳへの動的更新を要求するシステムなどを準備しておく。
【００２８】
アドレス確認は、第一の段階である。
Ｓ２０２において、管理サーバ（２０００）からキャッシュの生存時間の問題を避けるために、センタ側ＤＮＳサーバ（１０００）に対して名前問合せ（正引き）をする。
Ｓ２０４において、Ｓ２０２の返事から管理対象機器（４１００）のＩＰアドレスを得る。
なお、管理対象機器（４１００）のＩＰアドレスの確認は、管理サーバ（２０００）とセンタ側ＤＮＳサーバ（１０００）が同一のホストである場合か管理サーバ（２０００）のリゾルバがセンタ側ＤＮＳサーバ（１０００）を向いている場合や、センタ側ＤＮＳサーバ（１０００）のＴＴＬ（キャッシュの生存時間）の設定が極めて短い場合などは、省略することができる。
【００２９】
真性確認は、第二の段階である。
Ｓ２０２およびＳ２０４で管理対象機器（４１００）のＩＰアドレスが得られたこの時点では、管理対象機器（４１００）が正しく認識されたとおりの管理対象機器（４１００）であるかどうかは、未だ確認されていない。管理対象機器（４１００）とプロバイダＡ（４０００）間の回線断やセンタ側ＤＮＳ（１０００）に対して管理対象機器（４１００）が更新することができない場合などでは、真性確認で初めて管理対象機器（４１００）が真性でないことが判明する。また、管理対象機器（４１００）において提供されているサービスがあらかじめわかっていたとして、このサービスに正常にアクセスできない場合も、キャッシュの問題を除いても単にそれだけで管理対象機器（４１００）がネットワークから断たれた状態にあるとは、判断できない。例えば、管理対象機器（４１００）がプロバイダＡ（４０００）に正常に接続されておりかつセンタ側ＤＮＳサーバ（１０００）への更新も正常にされている場合であって、かつキャッシュの問題も発生していない場合であってなお、サービスを提供するプログラムに障害がある場合が考えられるからである。ネットワーク管理的な考え方としては、管理対象機器（４１００）がインターフェース障害や回線断などのネットワーク的な障害（根本的な障害）に陥っているのか、あるいはサービス障害（アプリケーションレベルの障害）なのかを切分けたいところである。ここで、障害切分けは低レイヤからするのが定石である。そこでこの時点では、とりあえず管理対象機器（４１００）だと思われるホストに対して通信を試み、その結果から本当に管理対象機器（４１００）なのかどうかを判別することによって、まずネットワーク的な障害の有無を確認することとする。
Ｓ２０６において、管理サーバ（２０００）からアドレス確認Ｓ２０２およびＳ２０４の結果から求められた管理対象機器（４１００）のＩＰアドレスに対して、あらかじめ合意された方式での通信をおこなう。
Ｓ２０８において、Ｓ２０６の返事がなければ管理対象機器（４１００）が見失われている。
Ｓ２１０において、Ｓ２０６の返事を受取り、この結果に対して、文字列処理をして、不要な文字列を取除いた値あるいは文字列を求める。これが管理サーバ（２０００）に設定された管理対象機器（４１００）からあらかじめ合意された方式での通信に対して答えられるべき返事である。
【００３０】
Ｓ２１２において、Ｓ２０８で受取った返事を、管理サーバ（２０００）に設定された、管理対象機器（４１００）からの返事であるべき、あらかじめ合意された方式での通信に対する答えられるべき返事との比較をおこない、判定する。
ここで、管理対象機器（４１００）が答えるべき返事と管理サーバ（２０００）が受取るべき返事は同じ物であることが合意されている。
あらかじめ合意された方式での通信に対する答えられるべき返事と一致した場合は、管理対象機器（４１００）は正常に動作している。
一致しない場合は、キャッシュの生存時間の問題とは無関係に、管理対象機器（４１００）はインターネットに接続されていないか何らかの問題でセンタＤＮＳに対する更新が出来ない状態にある、との判定をおこなう。
【００３１】
判定の結果を表示する。Ｓ２１２の判定によって、管理対象機器（４１００）が正常稼動しかつ真性な管理対象機器（４１００）であることが確認された場合Ｓ２１４か、あるいは障害状態であることが確認された場合Ｓ２１６とに分けられるが、この判定結果を受けてどうするかは、管理対象機器（４１００）の運用責任者と管理する側の人間との契約に基づくべきものであるため、本発明では単に結果の表示とするが、管理対象機器（４１００）が正常稼動しかつ真性の場合Ｓ２１４では、従来は監視不可能であったＩＰアドレスが変化するホストに対して、トラフィック監視などの通常の監視に後続させることができるという点は特筆すべき成果である。一般的には、Ｓ２１４の場合には正常である旨のみをログに書出すなどしてあえて通知せず、管理対象機器（４１００）が正常でない状態の場合Ｓ２１６は、アラートをあげるなどの状態を通知する処理に進むのがよい。Ｓ２１６の場合、管理対象機器（４１００）がセンタ側ＤＮＳ（１０００）を更新したタイミングと重なった場合などに、センタ側ＤＮＳ（１０００）が更新を反映するのに遅延が生じる可能性を考慮して、やや時間をおいて再度本プロセスを実行しそれでも障害が検出されるのを待った後、初めてアラートをあげる（Ｓ６０８に後述する）のか、あるいは誰にどのような方法でアラートをあげるのかを考慮するとよい。また、管理対象機器（４１００）が正常でない状態の場合Ｓ２１６では、重大度に応じて、必要であれば保守および復旧段階へ移行する。
【００３２】
この時、必要であって保守および復旧段階へ移行する場合にあって、管理対象機器（４１００）が何らかの理由でインターネットから切断された状態にある時などの管理対象機器（４１００）が発見できないかまたは、誤認されたホストのみが発見された場合においては、管理対象機器（４１００）は、管理サーバ（２０００）から見失われているため、一般にアクセスするには、管理対象機器（４１００）の設置場所に行かなくてはならない。しかし、これでは障害からの迅速な復旧をはかることができないため、図１７に示すように、あらかじめ第二の保守経路などを用意しておき、リモートメンテナンスできるようにしておくとよい。
【００３３】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。なお、各図面において同様の機能を有する箇所には同一の符号を付している。
【００３４】
実施例１
実施例１は、あらかじめ合意された通信の方式に、ＳＮＭＰを用いるものである。
管理対象機器（４１００）は計算機であり、直接ダイヤルアップ接続している。ＳＮＭＰエージェントを実装しており、設定されているものとする。後述する図５０の接続形態１である。
管理サーバ（２０００）では、監視プログラムをタイマー実行している。
以下の件が合意され設定されているものとする。
管理サーバ（２０００）には、管理対象機器（４１００）名とあらかじめ合意された方式での通信に対する返事の組あるいはペアテーブルが作成され登録されているものとする。
ＳＮＭＰなどの通信の方式は、待受け側のポート番号として、以下特にことわりのない場合は、ＲＦＣ１７００ＡＳＳＩＧＮＥＤＮＵＭＢＥＲＳに規定されたウェルノウン・ポートと同じか類似のものとする。ＲＦＣは、ＡＲＰＡＮＥＴ開発時代に、通信の方式を合意する（よりよくする）ために「意見を求む（＝ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔｓ）」として公開された文書を起源とし、現在ではインターネットあるいはＴＣＰ／ＩＰによる通信における標準的な規約集として機能している。
ＳＮＭＰ（＝ＳｉｍｐｌｅＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）は、けして単純とはいえない標準的なネットワーク管理用のプロトコルである。ＳＮＭＰにおける通信ではコミュニティ名および管理対象機器（４１００）の真性確認で用いるべきオブジェクトＩＤを通信の方式として合意し、管理対象機器（４１００）に設定されるオブジェクトＩＤの値を答えられるべき返事として合意する。例としてコミュニティ名に初期値のままのＰＵＢＬＩＣとし、オブジェクトＩＤにホスト名を意味するｓｙｓＮａｍｅを用いる。
ｓｙｓＮａｍｅはＳＮＭＰエージェントの設定上、ほとんどの場合で明示的に設定するものではなく、単にシステムのホスト名をそのまま引用する。ごく一部のシステムによってはＦＱＤＮを設定できずドメイン名を含まないホスト名のみ設定できる場合があるが、ここで、管理対象機器（４１００）に設定されたホスト名は、センタ側ＤＮＳサーバ（１０００）に登録される完全修飾ドメイン名（ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ。ホスト名＋サブドメイン名＋ドメイン名からなる。以下、「ＦＱＤＮ」とする）が設定されているものとする（ＦＱＤＮ＝管理対象機器（４１００）名とすることで、例を単純化できるが、ＦＱＤＮ以外（前述のドメイン名を含まないホスト名のみである場合を含む）が設定された場合にも、以下に示すプログラム中で変数を増やすことによって対応できる（実施例２参照））。
ここでオブジェクトＩＤは、返事の内容（＝識別子）が代入される変数だと考えればよいので、以下のようになる。
オブジェクトＩＤ（ｓｙｓＮａｍｅ）の値＝ＦＱＤＮ＝返事の内容＝管理対象機器名。
【００３５】
管理サーバ（２０００）において、
１、インターネットではＵＮＩＸ（登録商標、以下同様）サーバが非常に多く使われているため、本発明実施の場合にも、ＵＮＩＸ上で動作させる場合が多いだろうことが想定されること。
２、ＵＮＩＸにはウェルノウンポートなどで待受けする主要なインターネットサービスがあらかじめ導入されているか、少ない費用と労力で導入することができること。
３、ＵＮＩＸには文字列処理環境が最初からＯＳの一部として提供されていること。
などによって、本発明部分のみの実装で実験環境が構築できることから、サンプルプログラムはＵＮＩＸ上に実装した。
Ｗｉｎｄｏｗｓ系のＯＳの場合は、ＤＮＳについてはＩＳＣ版ＢＩＮＤ（最初のＤＮＳの実装としてバークレー版ＵＮＩＸに採用されて以来、インターネットの標準ＤＮＳである）に入替える。あるいはＩＳＣ版ＢＩＮＤの代替物に入替える。代替物とは、ＩＳＣ版ＢＩＮＤに含まれるｄｉｇコマンドのようにＤＮＳサーバの情報を外部から精査できるものをいう。ＳＮＭＰマネージャについては、マイクロソフト社製のものを用いてもよいし、ＯｐｅｎＶｉｅｗ（登録商標、以下同様）などの製品を新たに導入してもよい。文字列処理環境については、Ｗｉｎｄｏｗｓ系のＯＳにあっては十分にはＯＳに含まれていないので別途文字列処理環境を用意するか、本発明を実装する際のプログラム開発中に組み込みとした方がよいかもしれない（ただしこの場合、ＩＳＣ版ＢＩＮＤに含まれるｄｉｇコマンドの出力に対するプログラムインターフェースの問題もあるので、いっそｄｉｇコマンド代替から作成してしまった方が、労力が少ないかもしれない）。
管理対象機器（４１００）においては、Ｗｉｎｄｏｗｓ系のＯＳの場合は、ＷｉｎｄｏｗｓＮＴやＷｉｎｄｏｗｓ２０００にはＳＮＭＰエージェントが含まれているために、そのまま利用することができる。
以上によって、ＯＳの種類に関わらずに、本発明を実施可能である。
【００３６】
管理サーバ（２０００）に登録された管理対象機器（４１００）名や返されるべき返事などの通信の設定に必要な項目を、図４７に示す。
管理サーバ（２０００）においては、通信の設定に必要な項目を設定する場合は、シーケンシャルファイルのレコードとして記憶装置に保存してもよいし、ＤＢＭＳを通じてアクセスされるデータベースであっても、かまわない。また、管理対象機器（４１００）毎にプログラムを用意し、そのプログラム中に設定情報を記述する方法でもよい。これらは管理サーバ（２０００）において管理する管理対象機器（４１００）のボリュームに応じて選択すればよい。以降の例に挙げるプログラム中に直接埋め込む方式は、管理対象機器（４１００）の数が多くとも数百などの比較的少ない場合によい選択である。ここで設定される内容は、管理対象機器あたりに必要な項目が含まれていればよく、付加情報が追加されていてもよい。また、項目が並ぶ順序についても図４７の通りでなくても、管理対象機器（４１００）あたりとして混乱のないように保存されるようにすればよい。
本発明では、記憶装置については、レジスタやキャッシュについては考慮せず、メモリおよび外部記憶装置を指すこととする。また、外部記憶装置は、管理サーバ（２０００）や管理対象機器（４１００）の当該機器内に内蔵されるローカルな装置である必要はないものとする。例えばハードディスクドライブにおいて、ファイバーチャネルなどを経由してアクセスされるディスクアレイであっても、ＮＦＳマウントなどをされるような共有型のディスクであっても、単にハードディスクドライブとして扱う。一時記憶は、機器の再起動などの際には保持される必要がないものであり、比較的短時間で消去されるものであるが、一時記憶はメモリ上に展開されても、ハードディスクドライブなどに一時ファイルとして展開されてもよい。
管理対象機器（４１００）においては、通信の設定に必要な項目は多くない。これらは、合意された方式での通信要求に応答するプログラム部分と返事そのものであるところの通信の設定に必要な項目すなわち、パラメータからなる。プログラムが実装済みであるならば、保存すべきデータ量が少ないこととなる。これらの通信の設定に必要な項目を保存する記憶装置には以下のものが考えられる。機器内の不揮発メモリ、ＣＦカード・スマートカードなどのメモリカード類、ＰＣＭＣＩＡインタフェースを有したハードディスクドライブか通常のハードディスクドライブ、ディスケットドライブ、ＭＯドライブ、テープ装置などの記憶装置（か、ＤＶＤ−ＲＡＭやパケットライト方式のＣＤ−ＲＷもしくはイメージを作成するものとしてＣＤ−Ｒなどの取り外し可能な記憶媒体を利用した記憶媒体読取り装置）が利用可能であるし、書換えの頻度が極めて低い場合が考えられることから、当該機器において直接に記憶媒体に対する書換えをするのではなく交換によって保存内容の修正をおこなうＣＤ−ＲＯＭ、ＤＶＤ―ＲＯＭ、ＲＯＭカートリッジなどの取り外し可能な記憶媒体を利用した記憶装置まで可能である。ところで、ＵＳＢインターフェースやＩＥＥＥ１３９４インターフェースの記憶装置であっても、ハードディスクドライブにおいてＳＣＳＩインターフェースなのかＩＤＥインターフェースなのかを区別する必要がないのと同様に、インターフェースの種類については区別する必要がない。その他にも、例えば、システムの起動時にあらかじめ指定されたホストからＴＦＴＰなどの通信を用いて、設定をロードすることも可能である。この場合の記憶装置は通信を経由した外部のホストであり、内部の記憶装置に一時記憶させることによって用いる。
これらは、実施しようとする環境（具体的な装置）にあわせて利用可能なものの中から選択すればよいものとする。
【００３７】
図３０にプログラムのサンプルを示す。本プログラムはＵＮＩＸのシェルスクリプトである。本プログラムは図２７の骨格のみをプログラム化したものであり、必要最低限とした。例えば本プログラム実行時において、管理対象機器（４１００）名や管理サーバ（２０００）に登録された返されるべき返事をどのようにして本プログラムが得るかは、別の問題だが必須なためにプログラム中に埋め込んだ。また、後続する処理または人間によるアクションが必要な場合も、単にメッセージ出力するにとどめた。
なお、行末の矢印（−−＞）は表示の都合上折り返されているだけで、本当は１行であることを示している。
また、処理を示すＳ２０２などの番号は引用元の図２７などから、ひきついでいる。
【００３８】
Ｓ２０２およびＳ２０４はアドレス確認である。これにより、キャッシュの生存時間の問題を解決している。
キャッシュの生存時間の問題とは、ＤＮＳサーバ（４５００や５５００あるいは管理サーバ（２０００）が参照するＤＮＳサーバ）から管理対象機器（４１００）のＩＰアドレスを正引き名前問合せをしようとする時に、センタ側ＤＮＳサーバ（１０００）の指定したキャッシュの生存時間中の２度目以降のアクセスであって、かつ管理対象機器（４１００）がその間に更新していた場合には、誤った管理対象機器（４１００）のＩＰアドレスを得るために、管理対象機器（４１００）以外のホストにアクセスしようとしてしまうことをいう。
このキャッシュの生存時間の問題を解決するために、Ｓ２０２では、管理サーバ（２０００）からセンタ側ＤＮＳサーバ（１０００）に対して名前問合せ（正引き）をしている。
図３４に名前問合せの出力のサンプルを示す。下線部がセンタ側ＤＮＳサーバ（１０００）に対して最後に更新された管理対象機器（４１００）のＩＰアドレスである。この出力結果に文字列処理を施し、下線部のみを抽出し、管理対象機器（４１００）のＩＰアドレスを得る（Ｓ２０４）と、これを記憶装置に一時的に保存する。図３５に名前問合せでエラーになった場合の出力のサンプルを示す。ＤＮＳサーバが正しくない場合かＤＮＳサーバがダウンしている場合の例である。
図３６に名前問合せのエラーになった場合の出力のサンプルを示す。管理対象機器（４１００）が見つからなかった場合（管理対象機器（４１００）を示す情報がＤＮＳレコード中に存在しない場合）の例である。
【００３９】
図２３ないし図２６にキャッシュの生存時間のために、キャッシュされたＤＮＳ（４５００で計測）を参照する場合とセンタ側ＤＮＳサーバ（１０００）から直接正引きした場合とで、管理対象機器（４１００）のＩＰアドレスが違っている実例を示す。
図２３に実際に計測した際のプログラムを示す。本プログラムはＵＮＩＸのシェルスクリプトである。行末の矢印（−−＞）は表示の都合上折り返されているだけで、本当は１行であることを示している。
図２４ないし図２６に計測結果を示す。各試行は、１行目が試行番号、２行目が試行した時間を示し、３行目がインターネットワーキングにおいて標準的なＤＮＳの実装であるＩＳＣ版ＢＩＮＤのｄｉｇコマンドがセンタ側ＤＮＳサーバ（１０００）を参照した結果に文字列処理を施し、管理対象機器（４１００）のＩＰアドレスを抽出したもの（ａ、ｃ、ｅ）であり、４行目から６行目までがｐｉｎｇコマンドがキャッシュされたＤＮＳ（リゾルバがセンタ側ＤＮＳサーバ（１０００）を向いておらず、プロバイダＡのＤＮＳ（４５００）を向いているため）を参照した場合の管理対象機器（４１００）のＩＰアドレス（ｂ、ｄ、ｆ）である。なお７行目から１０行目は前記ｐｉｎｇコマンドの付帯する出力である。
試行に用いたＤＮＳサーバは、既にダイナミックＤＮＳサービスを提供しているＤｙｎＤＮＳ．ＯＲＧをセンタ側ＤＮＳサーバ（１０００）として用いた。試行時において、このサーバのキャッシュの生存時間の設定は１分である。なお、この１分という値はきわめて短い。
第１回目の試行と同時に管理対象機器（４１００）からの更新要求を送信し、第１回目の試行と第２回目の試行の間に更新が完了している。そのため、第２回目の試行から前記ｄｉｇコマンドの出力（センタ側ＤＮＳサーバ（１０００）が示す管理対象機器（４１００）のＩＰアドレス）とｐｉｎｇコマンドの出力（この試験ではプロバイダＡのＤＮＳサーバ（４５００）を参照したが、プロバイダＡのＤＮＳサーバ（４５００）はキャッシュの生存時間の影響を受ける）は、それぞれ、別のＩＰアドレスを示している（下線部ａ＝下線部ｂから下線部ｃ≠下線部ｄへと変化）。
これが収束（下線部ｅ＝下線部ｆ）するのは、第１６回目の試行である。この時、第１６回目の試行は第２回目の試行からちょうど１分後に試行されている。このように、キャッシュの生存時間の影響により、どのＤＮＳを参照するかによってアドレスのずれが生じている。しかし時間の経過とともに収束している。センタ側ＤＮＳサーバ（１０００）のキャッシュの生存時間は１分と短いが、それでもこのようなずれは生じる。
このことにより、管理対象機器（４１００）のＩＰアドレスの確認は、管理サーバ（２０００）のリゾルバがセンタ側ＤＮＳサーバ（１０００）を向いている場合や、センタ側ＤＮＳサーバ（１０００）のＴＴＬ（キャッシュの生存時間）の設定が極めて短い場合などは、省略することができる。
【００４０】
Ｓ２０４では、必要に応じて図２８のようなエラーチェックをするとよい。センタ側ＤＮＳサーバ（１０００）で障害が発生している場合には、Ｓ２０４で受取る返事が不整なものになる。Ｓ２０４で受取る返事の中に管理対象機器（４１００）を示すデータが含まれないなどの場合をＳ４０２において検出し、センタ側ＤＮＳサーバ（１０００）を切り替えてみたり（Ｓ４０８ないしＳ４１０）、それでもだめな時は処理を中止するようにするとよい。ここで中止された場合には、管理対象機器（４１００）の状態が正常であっても、管理対象機器（４１００）は見失われることになる。また、センタ側ＤＮＳサーバ（１０００）の信頼性がじゅうぶんある場合には、このエラーチェックは省略することができる。
【００４１】
Ｓ２０６ではＳ２０４で求められた管理対象機器（４１００）のＩＰアドレスに対して、あらかじめ合意された方式での通信をおこなっている。なお、アドレス確認が省略できるときには、あえてＩＰアドレスに変換する必要はない（この場合でも、ＤＮＳを正引きした際に得られるＩＰアドレスで問合せをおこなう）。Ｓ２０８では、Ｓ２０６の返事が返ってきた場合には返ってきた返事を一時的に記憶し、Ｓ２０６の返事が返ってこなかった場合には、Ｓ２０６の終了コードを一時的に記憶するなどして、Ｓ２１６のエラー処理へ進む。
図３７に、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令で管理対象機器（４１００）のホスト名を引いた場合の出力例を示す。
図３８は、Ｓ２０６の通信に失敗した場合として、キャッシュの生存時間の影響などでホスト名が間違っていた場合すなわち相手先ホストがＳＮＭＰを受付けるよう設定されていなかった場合、あるいは相手先ホストが存在しなかった場合の例を示す。
図３９は、Ｓ２０６の通信に失敗した場合として、相手先はＳＮＭＰを受付けたがコミュニティ名が間違っていた場合の例を示す。
Ｓ２０８では、前記図３８および図３９の場合などのように、管理対象機器（４１００）が管理サーバ（２０００）からのＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令を受付けなかった場合のエラー処理をしている。図３８や図３９などのＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令でエラーとなった場合には、Ｓ２０６の返事はエラーはエラー出力のみに返され、標準出力には何も帰ってこないために、サンプルプログラムでは終了コードをフラグとして代入している。
図４０に、ＳＮＭＰのオブジェクトＩＤの指定間違いの場合を示す。この場合は該当するオブジェクトＩＤの値が正常に返され、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令におけるエラーにはならないために、Ｓ２１２で判定されるべきである。サンプルではｓｙｓＬｏｃａｔｉｏｎを用いている。
その外、Ｓ２０６の通信が正常であってかつ合意された返事と違う返事が返された場合には、Ｓ２１２で判断される。
Ｓ２１０では、この通信の返事に対して、文字列処理をして、管理対象機器のホスト名（ＦＱＤＮ）を抽出する。
【００４２】
Ｓ２１２では、この返事を管理サーバ（２０００）に設定された、管理対象機器（４１００）からの返事であるべき、あらかじめ合意された方式での通信に対する答えられるべき返事との比較をおこない、判定する。
【００４３】
あらかじめ合意された方式での通信に対する、管理サーバ（２０００）に登録された管理対象機器（４１００）から答えられるべき返事と、管理サーバ（２０００）からの問合せ（合意された方式での通信）に対して実際に管理対象機器（４１００）が答えてきた返事とが一致した場合Ｓ２１４では、管理対象機器（４１００）は正常に動作し真性なホストである。
【００４４】
ここでＳ２１４および後述するＳ２１６の結果表示の出力手段であるが、キーボードとディスプレイ装置からなる通常のコンソールあるいは端末装置に出力してもよいし、記憶装置に保存されるログファイルとして書出すか、あるいはＳｙｓｌｏｇやＸ、ＳＮＭＰＴＲＡＰなどのＴＣＰ／ＩＰ上の通信路を経由して別のホストに出力してもよい。また、ＳＭＴＰサーバプログラムへの入力としてつなぐことによってメール送信でき、後述する保守に連係させる際に都合がよい場合もある。これらは複数を組合わせて出力してもよいし、もちろん紙媒体へ印刷出力してもよい。サンプルプログラムでは、単に標準出力に対して書出しているが、本発明を実施する場合には前記の出力方法からその環境に最適な方法で出力するか、あるいは後続する処理に進むようにするとよい。
【００４５】
出力結果（サンプルプログラムのメッセージ例）を図３１に示す。
管理対象機器（４１００）が真性なホストであることが確認された場合には、後続する処理に接続することができる。例えばＭＲＴＧやＯｐｅｎＶｉｅｗなどによる通常（管理対象機器が固定ＩＰアドレスであり、真性チェックを必要としない場合と同等）の監視処理をあげておく。通常の監視（＝後続する処理）の例として、ｕｃｄ−ｓｎｍｐ−４．２．１およびｍｒｔｇ−２．９．１７を用いてみた。ＭＲＴＧは、現在のネットワークのトラフィックの状態および時間によって変化する情報（例えば、ＣＰＵ負荷率など）をグラフィカルに表示してくれるソフトウェアツールである。ＭＲＴＧはＳＮＭＰマネージャの機能を含んでいる（そのため、ここではＳＮＭＰマネージャとして扱った）が、トラフィック履歴ファイル生成用に特化している（つまりユーザー・インターフェースを持たない）ために、通常は別途ＳＮＭＰマネージャと組合わせて用いる。通常の管理方法については、本発明の対象外なので説明しないが、接続の際に問題があったので、その解決方法については以下に説明する。ここで試験の結果、ＭＲＴＧではＩＰアドレスが変化するホストに対しては、管理対象機器をＦＱＤＮで指定しても（ＩＰアドレスの変化に追従できず）、通常の監視をおこなうことはできなかった。そのため、ＭＲＴＧで指定する管理対象機器名にその時点での管理対象機器（４１００）のＩＰアドレスを代入したＭＲＴＧの設定ファイルを生成しなおす処理を追加することによって、通常の監視処理に接続した。
【００４６】
ここで念のためにネットワーク管理の必要性について説明する。まず、用語の説明として、ネットワーク管理自体は、いわゆる構成管理や課金管理などをも含む通常の管理の概念であって、その対象をネットワークとしているものである。つぎに、管理と監視の関係は、ネットワーク管理という大カテゴリの中で、ホストや網そのもの（例えば、トラフィック（＝流量）は個別のノードに対してだけでなく、全体に対しても計測できる）の監視という具体的な手法があるものと解されたい。ネットワークの状態は常に変動しているために、その状態を監視することが障害対応の第一であり、また、ネットワーク設計へのフィードバックや将来の拡張計画の根拠資料となるべきものである。
しかし本発明では、管理対象機器（４１００）は動的ＩＰアドレス割当てを受けたカスタマネットワークの境界ノードあるいは境界ノードと一体となって参照されるホストであり、きわめて小規模なものである。しかし、何らかのＴＣＰ／ＩＰサービスを提供するのであるから、回線断やシステム障害などによって、サービス提供ができなくなっているにもかかわらず気づかずにいたのでは、問題がある。そこで、なんらかの障害が発生した場合に、すみやかに通知され復旧すべきと考えて、このような小規模なネットワークにおいてもネットワーク管理は必要なものであるとして、従来管理することのできなかったＩＰアドレスが変化するホストにおいても管理できるようにしようというものである。
【００４７】
一致しない場合Ｓ２１６は、管理対象機器（４１００）はインターネットに接続されていないか何らかの問題でセンタ側ＤＮＳサーバ（１０００）に対する更新が出来ない状態にある。
図３２が出力結果（サンプルプログラムのメッセージ例）で、（Ａ）が返事がなかった場合、（Ｂ）が返事はあったが、一致しなかった場合である。この場合でもサンプルスクリプトでは、標準出力に対して書出しているだけだが、ログファイルなどに書出すようにした方がよい。管理対象機器（４１００）がセンタ側ＤＮＳサーバ（１０００）に更新要求したタイミングと偶然重なったために管理対象機器（４１００）で障害が発生しているように見えてしまう場合などは２回目の監視タイミングまで待てば、自然と正常状態に収束するはずである。このような場合には、障害として検出しない方がよい場合がある。図２９にあるように、管理サーバ（２０００）では、監視プログラムをタイマー実行しているため、エラーフラグをたてることにより、１回目の異常（Ｓ６０６）と２回目の異常（Ｓ６０８）とを別々に検出することができる。（この場合において、図３０下線部のように（フローチャートでは図２９を図２７の部分としたために表現できなかったが、図２７Ｓ２１４の下で）正常復帰時にエラーフラグを消去した方がよい）
【００４８】
図３３が２回目の出力結果（サンプルプログラムのメッセージ例）で、（Ａ）が返事がなかった場合、（Ｂ）が返事はあったが、一致しなかった場合である。タイマー実行による２回目のＳ２１６（Ｓ６０８）では、管理対象機器（４１００）が見失われていることが明らかなので、単にログファイルに書出すだけではなく、アラートをあげるなりポケベルを鳴らすなりメールにて通知するなどの方法で、何らかの後続するアクションへとつなぐようにするとよい。この場合の後続するアクションとは、復旧段階のことである。図１７のように、例えば、管理対象機器（４１００）あるいは管理対象機器（４１００）に接続されたＬＡＮ上にシリアルコンソールを用意しておき、電話回線などが考えられるが第二の保守経路を経由して管理対象機器（４１００）の復旧をはかるなどをするとよい。
【００４９】
ＳＮＭＰは通信可能な状態であれば、管理対象機器（４１００）のシステムの状態をほぼ何でも知りうる。また、設定変更も可能である。
本発明ではＳＮＭＰの強力な管理機能を利用することが目的ではなく、見失われがちな動的ＩＰアドレス割当てを受けた本来なら特定できないホストが、本当に意図している相手として正しいかどうかを確認しようとするものである。ここで、後続する従来の管理に接続しようとするならば、後続する管理の方法はＳＮＭＰである可能性が高い。この場合、ＳＮＭＰは管理対象機器（４１００）においてすでに利用可能な状態となっているはずのものなので、この環境をそのまま利用するものとして、ＳＮＭＰを真偽の判定に用いてみた（後続する管理が不要な場合やＳＮＭＰ以外の方法で真性確認をおこなう場合については後述する）。
ＳＮＭＰを合意された通信の方式に用いる上で、セキュリティ上、以下の点に注意した方がよい。本発明では実験環境としてコミュニティ名は初期値であるＰＵＢＬＩＣを用いたが、初期値のままでは侵入者を含め誰でもアクセスできてしまうため、本番環境ではＰＵＢＬＩＣやＰＲＩＶＡＴＥなどの初期値を決して用いてはいけない。また、管理サーバ（２０００）のＩＰアドレスがわかっている場合には、管理サーバ（２０００）のＩＰアドレス以外からのアクセスを受付けないなどのアクセス制御もあわせておこなうべきである。
【００５０】
実施例２
実施例１と同様の環境であって、かつ同様にＳＮＭＰをあらかじめ合意された通信の方式に用いるものであって、ｓｙｓＮａｍｅの替わりに、ｓｙｓＮａｍｅと比較して使うことの出来る文字列の制限が少ないｓｙｓＬｏｃａｔｉｏｎを用いる事もできる。この場合にあっては、プログラム中で管理対象機器（４１００）を指す変数とあらかじめ合意された方式での通信の返事をかねることが妥当でないため、あらかじめ合意された方式での通信の返事のための変数を別途用意することによって、実施例１と同様のプログラムで管理対象機器（４１００）の真偽を判定できる。
【００５１】
すなわち実施例１において、合意された返事は省略可能だが、たとえ合意された返事が明示されなくともＦＱＤＮが暗示されることによって、合意された返事はなくてもよい訳ではなくＦＱＤＮを省略時の値とすることによって、存在していることになる。ここで、ＦＱＤＮはセンタ側ＤＮＳサーバ（１０００）に登録されるホスト名である。
なお、設定に必要な項目は図４７を参照されたい。
【００５２】
実施例１では、管理対象機器名をＦＱＤＮとして、合意された返事そのものであったため、管理対象機器（４１００）が複数あっても、合意された返事が重複することはなかった。
これはＦＱＤＮはあらかじめ一意性が保証されているため、他の管理対象機器（４１００）と混同されることがないからである。
つぎに、なぜ明確な合意なく真性が確認できるのかについて説明する。図４６のように、管理サーバ（２０００）は管理対象機器（４１００）に対してＩＰアドレスで問合せをする。ダイヤルアップのホストであってかつダイナミックＤＮＳを利用することが前提であるので、管理対象機器（４１００）の逆引きホスト名は、プロバイダ（あるいはＩＰアドレスの割当てを受けた各利用組織）のドメインに対するホスト名を返すか、あるいは逆引き設定されていない場合は、単にＩＰアドレスを返す。よって管理対象機器以外のホストがＩＰアドレスから、センタ側ＤＮＳサーバ（１０００）に設定されるＦＱＤＮを導き出すことができない。管理対象機器（４１００）が、センタ側ＤＮＳサーバ（１０００）に設定されるＦＱＤＮを返事として応答するのであれば、真性の管理対象機器（４１００）以外に知り得ないことを知っていることになるので、管理対象機器（４１００）は真性であることが確認できる。なお、センタ側ＤＮＳサーバ（１０００）への更新をのっとるような攻撃については別論であり、これはダイナミックＤＮＳを運営するセンタ側ＤＮＳサーバ（１０００）で対処すべき問題である。
【００５３】
また、ＦＱＤＮを用いることには、もうひとつの意味がある。実施例１や実施例２の方法では、管理対象機器（４１００）の真性確認は、安全でない通信路をデータの暗号化もしないままやりとりすることになる。そこで、パケット盗聴に対抗し得る方法として、もともと盗聴されてもかまわない情報のみ通過させることにした。ここで、センタ側ＤＮＳサーバ（１０００）に設定されるＦＱＤＮは、外部から管理対象機器（４１００）（あるいは管理対象機器と一体となってなんらかのサービスを提供するホスト）にアクセスするために用いられる公開された情報である。したがって、当然に盗聴されたとしてもなんら問題のない情報である（ただし、ＳＮＭＰコミュニティ名を盗聴されると実はよろしくない。この回避方法はアクセス制御することであり、ＳＮＭＰを用いない方法を実施例５以降で説明する）。
【００５４】
ｐｉｎｇとは、ＩＣＭＰプロトコルのエコー要求を実装したプログラムとして、従来はホストの到達性（活死）確認に用いられてきた。ところがこのｐｉｎｇはＩＰアドレスが変化するホストに対しては利用することができない。本発明では、ＩＰアドレスが変化するホストに対してはｐｉｎｇが利用できなくなったことを代替することにも利用できるようにしたいので、処理的にもプロトコル的にも軽量であることが望ましく、暗号化しなくても済むということは、軽量であることに貢献する。
【００５５】
実施例２において、管理対象機器（４１００）が複数ある場合で、合意された返事が重複する場合に、管理対象機器（４１００）を管理サーバ側で間違えると、別の管理対象機器が正常稼動しているから、管理対象機器（４１００）が正常に稼動しているという誤った管理をしてしまうおそれがある。したがって、実施例２（および実施例５ないし実施例８）のＦＱＤＮでないものを合意された返事として用いる場合には、管理対象機器（４１００）の数だけ、合意された返事の組を用意した方がよい。しかし、管理サーバ（２０００）が管理対象機器（４１００）を間違えることがないなら、返事は仮にすべての管理対象機器（４１００）で共通でもかまわない。
【００５６】
実施例３
実施例１および２は管理対象機器（４１００）が直接ダイヤルアップしていた。実施例３では、管理対象機器（４１００）が直接ダイヤルアップするのではなく、間にネットワーク接続機器が介されており、このネットワーク接続機器がダイヤルアップする場合である。
ＩＳＤＮルータなどと呼ばれるダイヤルアップルータ、あるいはブロードバンドルータなどと呼ばれるＰＰＰｏＥ、ＰＰＰｏＡ、ＤＨＣＰなどによってＩＰアドレスを取得できＩＰマスカレードなどの動的なネットワークアドレス変換（以下、「ＮＡＴ」とする）を用いて複数のＬＡＮ上のパソコンにグローバルサービスを受けさせるようなネットワーク接続機器（以下、「ＮＡＴＢＯＸ」とする）がダイヤルアップし、管理対象機器（４１００）はカスタマのＬＡＮにのみ接している場合（図５０の接続形態４ないし接続形態６のいずれかを参照）には、ネットワーク接続機器に静的ＮＡＴあるいはポートフォワーディングなどの設定をすることによって、管理対象機器（４１００）が直接ダイヤルアップしていなくても（直接インターネットに接していなくても）実施例１や実施例２と同様に管理サーバ（２０００）から真偽の判定ができる。
この場合の条件はダイヤルアップする機能が管理対象機器（４１００）でなくネットワーク接続機器であること、静的ＮＡＴあるいはポートフォワーディングなどの設定がネットワーク接続機器になされていることなどをのぞけば、管理対象機器（４１００）にＳＮＭＰエージェントを実装されておりかつ設定されていることを含め、実施例１および２と同様である。
【００５７】
実施例４
実施例３と同様に計算機が直接にダイヤルアップするのではなくネットワーク接続機器がダイヤルアップする場合において、ダイヤルアップルータなどのネットワーク接続機器がＳＮＭＰを実装していれば、これを管理対象機器（４１００）として利用することが出来る。
ＵＮＩＸの場合は、ＩＰアドレスを割当て可能な装置はすべてホストと呼ばれる。本発明では、この考え方を援用してルータやＮＡＴＢＯＸであろうとも、ＩＰアドレスが割当てられていれば、ホストと呼ぶこととする。すなわち、実施例４ではダイヤルアップするルータが管理対象機器（４１００）たるホストである。管理対象機器（４１００）はＳＮＭＰを実装していることからダイヤルアップルータなどのネットワーク接続機器である（図５０の接続形態２参照）が、この際に、前記ルータにＩＰマスカレードなどの動的ＮＡＴの機能があれば、前記ルータにＤＮＳへの動的更新する機能がない場合でも、ＬＡＮ上のパソコンにＤＮＳ更新させることもできる（図５０の接続形態３を参照）。
この場合においては、ダイヤルアップルータにセンタ側ＤＮＳサーバ（１０００）に登録され動的更新されるホスト名と同じ名前を設定すれば実施例１と同様に管理サーバ（２０００）から管理対象機器（４１００）の真偽を判定することができる。しかし、実施例２のようにｓｙｓＬｏｃａｔｉｏｎを用いてより柔軟な任意の文字列を、管理対象機器（４１００）が返すべき返事として合意した方がスマートな構成となる。
【００５８】
実施例５
実施例５は、あらかじめ合意された通信の方式に、ＤＯＭＡＩＮ（ＤＮＳ）を用いるものである。
管理対象機器（４１００）は計算機であり、ＢＩＮＤを実装しており、バージョン情報が設定されているものとする。ここでは、あらかじめ合意された通信の方式にＤＯＭＡＩＮ（ＤＮＳ）を用い、双方で合意された返事にこのバージョン情報を用いるものとする。
管理対象機器（４１００）は、直接ダイヤルアップ接続しているか、あるいはネットワーク接続機器経由で静的ＮＡＴあるいはポートフォワーディングの設定がされているものとする。
管理サーバ（２０００）では、監視プログラムをタイマー実行している。
その他の条件や設定内容は実施例１と同様とする。
準備段階として、以下の件が合意され設定されているものとする。
管理サーバ（２０００）には、管理対象機器（４１００）名とあらかじめ合意された方式での通信に対する返事の組あるいはペアテーブルが作成され登録されているものとする。
管理対象機器（４１００）に設定される、あらかじめ合意された方式での通信に対する答えるべき返事は管理対象機器（４１００）で動作するＢＩＮＤが返す任意の文字列に変更されたバージョン情報とする。
【００５９】
グローバルなインターネット向けの名前サービスを提供していない場合でも、局域的なＬＡＮ環境のために管理対象機器（４１００）はＤＮＳサービスを提供することができる。
図４１に、管理対象機器（４１００）において設定する、ＢＩＮＤにおけるバージョン情報の設定の仕方を示す。
ＢＩＮＤの標準的な動作として、このバージョン情報は明示的に設定されていないと、図４４のように通常はプログラムそのもののバージョンを返す。もともとはネットワークを経由した攻撃者に対して、プログラムのバージョン情報がわかると攻撃する時の方法も明らかになるので、攻撃者の手間を増やすために、バージョン情報をわざと変更していたものである。しかし任意に設定できることから、これをあらかじめ合意された方式での通信に対する返事として用いることができる。
【００６０】
ふたたび図２７を参照されたい。
Ｓ２０２およびＳ２０４はアドレス確認である。実施例１と同様である。
Ｓ２０６では上で求められた管理対象機器（４１００）のＩＰアドレスに対して、あらかじめ合意された方式での通信をおこなっている。
Ｓ２０８では、返事が返ってきた場合には返ってきた返事を一時的に記憶し、返事が返ってこなかった場合には、Ｓ２０６の終了コードを一時的に記憶する。図４２に、ｄｉｇでＢＩＮＤにおけるバージョン情報を引いた場合の出力例を示す。下線部が管理サーバ（２０００）に設定された、管理対象機器（４１００）からの返事であるべき、あらかじめ合意された方式での通信に対する答えられるべき返事にあたる部分である。
ここには任意の文字列を用いることができるが、実施例２と同様に管理サーバ（２０００）では、返事の重複による複数の管理対象機器（４１００）間での混同を避けるために、どのような返事を合意するかに気をつける必要がある。
図４３に、管理対象機器（４１００）がかつて割当てられていたＩＰアドレスを現在割当てられているホストが存在しない場合および、管理対象機器（４１００）がかつて割当てられていたＩＰアドレスを割当てられている誤認されたホストが存在する場合であって、その誤認されたホストでＢＩＮＤが動作していなかった場合を示す。
エラー出力に出力されるエラーのみ四角で囲んであり、その他は標準出力に出力されるエラーである。
図４４に、管理対象機器（４１００）がかつて割当てられていたＩＰアドレスを割当てられている誤認されたホストが存在する場合であって、その誤認されたホストでＢＩＮＤが動作していた場合を示す。この場合はｄｉｇコマンドの出力としてはエラーにならないために、Ｓ２１２で判定されるべきである。
Ｓ２１０では、この通信の返事に対して、文字列処理をして、管理対象機器で動作するＢＩＮＤのバージョン情報を抽出する。
Ｓ２１２では、この返事を管理サーバ（２０００）に設定された、管理対象機器（４１００）からの返事であるべき、あらかじめ合意された方式での通信に対する答えられるべき返事との比較をおこない、判定する。
あらかじめ合意された方式での通信に対する管理対象機器（４１００）が返す答えるべき返事と管理サーバ（２０００）に登録された答えられるべき返事とが一致した場合Ｓ２１４では、管理対象機器（４１００）は正常に動作し真性なホストである。Ｓ２１４では、実施例１と同様にログファイルなどに書出すなり後続する通常の監視へ進むなりした方がよい。
一致しない場合Ｓ２１６でも、実施例１と同じようにすればよい。
【００６１】
実施例６
実施例６は、あらかじめ合意された通信の方式に、ＳＭＴＰを用いるものである。
管理対象機器（４１００）は計算機であり、ＳＭＴＰサーバを実装しているものとする。ここでは、あらかじめ合意された通信の方式にＳＭＴＰを用い、双方で合意された返事に管理対象機器（４１００）のホスト名（ＦＱＤＮ）を用いるものとする。
管理対象機器（４１００）は、直接ダイヤルアップ接続しているか、あるいはネットワーク接続機器経由で静的ＮＡＴあるいはポートフォワーディングの設定がされているものとする。
管理サーバ（２０００）では、監視プログラムをタイマー実行している。
その他の条件や設定内容は実施例１と同様とする。
準備段階として、以下の件が合意され設定されているものとする。
管理サーバ（２０００）には、管理対象機器（４１００）名とあらかじめ合意された方式での通信に対する返事の組あるいはペアテーブルが作成され登録されているものとする。
管理対象機器（４１００）に設定される、あらかじめ合意された方式での通信に対する答えるべき返事は管理対象機器（４１００）に設定されたホスト名そのものとする。
【００６２】
ＳＭＴＰサーバに接続した時には多くの場合、図４５のようなメッセージを出力する（例はＳＭＴＰサーバとしてもっとも普及しているＳＥＮＤＭＡＩＬの場合であるが、ＳＥＮＤＭＡＩＬに次いで普及しているＱＭＡＩＬの場合でも、メッセージ中にホスト名が含まれるか含めることができる）。
このメッセージには、ホスト名がＦＱＤＮで表示（図４５下線部参照）されているので、これを管理対象機器（４１００）が真性であるかどうかを判定する識別子すなわち合意された返事に用いることができる。
【００６３】
実施例７
実施例７は、あらかじめ合意された通信の方式に、ＨＴＴＰを用いるものである。
管理対象機器（４１００）は計算機であり、ウェブサーバを実装しているものとする。ここでは、あらかじめ合意された通信の方式にＨＴＴＰを用いる。すなわち、管理対象機器（４１００）で待受けするサービスがウェブサーバであることから、双方で合意された返事には、どのような文字列でも用いることができる。
管理対象機器（４１００）は、直接ダイヤルアップ接続しているか、あるいはネットワーク接続機器経由で静的ＮＡＴあるいはポートフォワーディングの設定がされているものとする。
管理サーバ（２０００）では、監視プログラムをタイマー実行している。
その他の条件や設定内容は実施例１および２と同様とする。
準備段階として、以下の件が合意され設定されているものとする。
管理サーバ（２０００）には、管理対象機器（４１００）名とあらかじめ合意された方式での通信に対する返事の組あるいはペアテーブルが作成され登録されているものとする。
管理対象機器（４１００）に設定される、あらかじめ合意された方式での通信に対する答えるべき返事は管理対象機器（４１００）で動作するＨＴＴＰサーバが返す文字列中に埋め込まれた任意の文字列とする。
【００６４】
計算機系の技術者以外の人にとっても馴染み深いものであるために、おそらくウェブサーバは、管理対象機器（４１００）もしくはカスタマのネットワークにおけるＴＣＰ／ＩＰサービスを提供するサーバにおいて、もっとも提供したいサービスのひとつだろう。ＨＴＴＰでは、どのような文字列でも転送することができることから、これを合意された通信の返事として利用可能である。多くのウェブサーバはファイル名の指定がない場合は、多くの場合ｉｎｄｅｘ．ｈｔｍｌという名前のファイルが開かれる（ウェブサーバからクライアントへ転送されるの意味である）が、ここに返事となるべき文字列を記述しておくだけでよい。例えばトップページのｉｎｄｅｘ．ｈｔｍｌ中、本文の３ワード目の文字列を合意しておくなどである。しかし、これでは更新の際に誤って本文の３ワード目の文字列を変更してしまったりすることがあるので、別のファイル名を合意しかつそのファイル中の特定の文字列を返事として合意しておいた方がよい。また、ＨＴＭＬ文の＜ＭＥＴＡ＞文中に埋め込むこともできるし、＜ＴＩＴＬＥ＞を合意した返事として用いることもできる。要するに、ＨＴＴＰを用いる場合には、合意された通信の方式と意図された返事の境界があいまいになる。例えばＵＲＬ中に特定のディレクトリ名とファイル名を含む場合、これは通信の方式と考えるべきであろう。では、ここで転送されたＨＴＭＬ文中の本文の３ワード目は、返事とみなすべきだろうか？これもやはり通信の方式として合意すべきだが、実施例１や実施例２、あるいは実施例５のようなプロトコルによる制約がない分、より具体的な合意が必要であることに注意した方がよい。
また、ＨＴＴＰＳを合意された通信に用いる場合であって、管理対象機器（４１００）にＳＳＬサーバ証明書が組み込まれている場合には、シリアルナンバやフィンガープリントか、あるいは単にオーガニゼーション名やカンパニー名、サーバ名などのいずれかを利用することもできる。
実施例１や実施例２の場合は、管理対象機器（４１００）の確認をする管理サーバ（２０００）以外からのアクセスを制限する方向であったが、実施例１や実施例２と違い、通信の方式にＨＴＴＰを用いる場合は、むしろ公開サーバとして、より多くの人から確認できるようにしたい場合に有効であろう。
ところで、ＨＴＴＰは通常ＴＣＰポートの８０番で待受けするが、しばしば別のポート番号に意図的に変更して待受けされることがある。このような場合でも、変更されたＴＣＰポート番号が管理サーバ（２０００）と管理対象機器（４１００）の間で合意されていれば、管理対象機器（４１００）が真性のホストであるか否かを確認するために用いることができる。
また、静的ＮＡＴでもポートフォワーディングでもないが実施例３との複合型として、ＮＡＴＢＯＸは、例えば８８番ポートでＮＡＴＢＯＸ自体の設定変更のためのウェブアクセスを受付け、８０番ポートでリバースプロクシが動作しているような場合には、リバースプロクシによる転送先ウェブサーバにおいて、実施例７のあらかじめ合意された通信を実装可能である。
【００６５】
実施例８
実施例８では、管理対象機器（４１００）がダイヤルアップルータあるいはＮＡＴＢＯＸ経由で接続している場合と管理対象機器（４１００）が直接ダイヤルアップをしている場合とを問わず、管理対象機器（４１００）の記憶装置に任意の情報を答えるべき返事として保存し、あらかじめ合意された任意の方式での通信に対して前記保存された情報を記憶装置より読み出し、少なくとも前記情報を含めた返事を返信することさえ出来れば、通信の方式を問わずに管理対象機器（４１００）が真性のホストであるか否かを確認するために用いることができる。この例は実施例７の通常でないＴＣＰポートで待受けするウェブサーバの例をすでに挙げた。あるいはＦＴＰサーバへクライアントが接続する際に表示されるウェルカムメッセージもあらかじめ合意された通信の方式として用いることができる。その外、管理サーバ（２０００）と管理対象機器（４１００）の間で合意されていれば、独自プロトコルなどの一般的でない（ウェルノウンでない）通信の方式でも同様に合意された通信の方式として用いることができる。
【００６６】
管理対象機器（４１００）は、機能的に以下に分割され得る。ａのダイヤルアップするホスト、ｂのダイナミックＤＮＳへ動的更新をするホスト、ｃの管理対象機器（４１００）である。これらの機能は、各機能毎のホストに分散されていてもよいし、各機能が１のホストに集約されていてもよい。これらの関係は、ネットワークの接続形態によって影響される。
管理対象機器（４１００）のカスタマネットワークにおける接続形態を図５０にまとめる。
モデム上部の雷型の線は電気通信回線を意味し、その上部にある楕円はネットワーククラウドを意味する。最上部の小さく描かれた四角が管理サーバ（２０００）である。
モデムとは、通常変復調装置を指すが、ここではケーブルモデムやＡＤＳＬモデム（やＴＡ）などを（あるいはデジタル回線終端装置（＝ＤｉｇｔａｌＳｅｒｖｉｃｅＵｎｉｔ）や光終端装置（＝ＯｐｔｉｃａｌＮｅｔｗｏｒｋＵｎｉｔ）などがあるときは、説明の便宜上これをも）含み、ルーティング機能を提供しない、通信路上の物理的な境界を構成する装置を指すこととする。図５０ではモデムを独立した装置として描いたが、ネットワーク接続機器や計算機に組込まれている場合がある。モデムに類する機能が、ネットワーク接続機器や計算機に組込まれている場合には、ネットワーク接続機器や計算機としてあつかうこととする。よって本発明では、モデムは通信の機能上必要なものであっても、ＴＣＰ／ＩＰ的なネットワーク境界を構成しないことから、モデム単独については考慮しないものとする。
図５０で、モデムのすぐ下に描かれているものは、必ずダイヤルアップする機能を有するものである。これに属するものは、ネットワーク接続機器と計算機がある。
ネットワーク接続機器とは、ルーティング機能あるいはプロトコル変換機能を提供し、ＴＣＰ／ＩＰ的なネットワーク境界を構成する装置を指すこととする。図５０では、「ルータなど」と表記している。
計算機とは、利用者によってプログラム可能なものを計算機と呼ぶこととし、仮に計算機がネットワーク接続機器と同様の機能を有している場合であったとしても、この点においてネットワーク接続機器と区別されることとする。利用者端末などもこれに含まれる。
【００６７】
以下各接続形態に応じて、管理対象機器（４１００）がどの装置であるかを中心に説明する。
実施例１の典型を接続形態１とする。これは、計算機が直接ダイヤルアップする場合である。実施例２も同じである。この形態では、ｂのＤＮＳ更新するホスト、ｃの管理対象たるホストがａのダイヤルアップするホストと同一の場合である。この場合において、ａのダイヤルアップするホストすなわち計算機がネットワーク境界を構成する。このことから、例えばＮＡＴを実装している場合やＶＰＮトンネリングしている場合のようにネットワーク接続機器の機能を有しているか、アプリケーションゲートウェイを構成していれば、破線部分の計算機に対して、ネットワーク接続を提供することも可能である。
実施例４は、ネットワーク接続機器を介して計算機が接続される場合であって、ネットワーク接続機器がｃの管理対象機器（４１００）である場合である。典型例が接続形態２である。また、接続形態２に対して、ネットワーク接続機器がＤＮＳ更新できない場合に、ｂのＤＮＳ更新するホストを計算機とした場合が、接続形態３である。
実施例３および実施例５ないし実施例８では、ａのダイヤルアップするホスト、ｂのＤＮＳ更新するホスト、ｃの管理対象たるホストなどが機能的に分割され、この機能が計算機およびネットワーク接続機器に分散されている場合である。この場合の典型が接続形態６である。ここで、例えば接続形態４の場合は、ネットワーク接続機器がセンタ側ＤＮＳサーバ（１０００）に対してダイナミックＤＮＳ更新できる場合であって、かつ管理対象機器（４１００）たりえない場合にこのような構成をとることができる。なお、接続形態４ないし接続形態６において、ａのダイヤルアップするホストはルータなどとされているが、接続形態１の応用としてこれは計算機によっても代替し得る。ここで、ネットワーク接続機器がダイヤルアップすることを明示している実施例３および実施例４を除けば、一般に計算機はネットワーク接続機器と比してソフトウェアを追加することによってｃの管理対象機器（４１００）としてもｂのＤＮＳ更新するホストとしても用いることができることから、接続形態１はどの実施例にも用いることができる。すなわち実施例３および実施例４（ネットワーク接続機器がダイヤルアップすることが明記されている場合）を除き、ａの位置にあるルータなどは計算機であってもよい。この場合、ａのダイヤルアップするホストには、少なくともｃの管理対象機器（４１００）に対して静的ＮＡＴあるいはポートフォワーディングなどが設定されているものとする。図５０ではモデムのすぐ下にａのダイヤルアップするホストがあるが、この下には計算機だけではなく、ネットワーク接続機器があってもよい。これはカスタマネットワークを構成するＬＡＮが多段のＬＡＮを構成していてもよいことを示す。
実施例５ないし実施例８は、すべての接続形態で用いることができる。ただし、実施例５ないし実施例８を接続形態２や接続形態３に適用する場合には、ネットワーク接続機器がサインに対し、カウンターサインを返しうるように構成できる必要がある。
【００６８】
ａのダイヤルアップするホスト、ｂのダイナミックＤＮＳへ動的更新をするホスト、ｃの管理対象機器（４１００）は、同一のＬＡＮ上（あるいは同一の場所）に設置されるものとするすると、広域のネットワークから見れば、このＬＡＮは網端側にあることになる。ここで広域のネットワークをインターネットとした場合（正確にはＮＡＴを必要とする場合）、広域のネットワークを経由した通信では、ａ、ｂ、ｃのそれぞれを識別することはできない。よって、このＬＡＮは外部に対して単一のネットワークノードのように振舞う、計算機およびネットワーク接続機器の集合である（インターネット・サービス・プロバイダーへの端末型ダイヤルアップのようにＬＡＮを構成しておらず、端末一台のみの場合にあっても同じである）。これを本発明では、カスタマネットワークもしくはエンドサイトと呼ぶこととする。エンドサイトは特に広域のネットワークから見た場合のエッジ側を指すものとして扱うが、着目点が違うだけで同じ物を指している。図５０のモデム以下の点線で囲まれた部分である。接続形態１から接続形態６は、カスタマネットワークの内訳であり、管理サーバ（２０００）から見れば、カスタマネットワークが接続形態１から接続形態６のいずれの類型に属していようと、ａ、ｂ、ｃのそれぞれを識別することはできないという点で共通している。そのため、管理サーバ（２０００）ではカスタマネットワークの構成や管理対象機器（４１００）がカスタマネットワークのＬＡＮ上でどこに、位置しているかについて考慮する必要がない。
【００６９】
なお、カスタマネットワークはプライベートＩＰアドレスが使用されている状態を仮定している。このため、インターネットからは、カスタマネットワークに対して、直接ルーティングされることはない。ａのダイヤルアップするホストは、インターネットとカスタマネットワークの接点を構成する。ルーティングはａのダイヤルアップするホストで止まるから、インターネットからｂ、ｃには直接到達できない。
上記は、広域のネットワークをインターネットとした場合であった。
ところが、広域のネットワークとしては、インターネット以外にも、第一種電気通信事業者や第二種電気通信事業者が提供するかあるいは自営網によるインターネットに接続されない、ＴＣＰ／ＩＰによるネットワークが考えられる。この場合には、ＮＡＴを前提とするのでなく、ルーティングによって別のネットワークにあるセンタ側ＤＮＳサーバ（１０００）や管理サーバ（２０００）から管理対象機器（４１００）へのアクセスが、直接に管理対象機器（４１００）に到達できる場合がある。
【００７０】
実施例１ないし実施例８では、説明上インターネットと表現してきた。しかし、グローバルなインターネットでのみ本発明は実施可能なものではなく、実際はＴＣＰ／ＩＰを用いた通信でありさえすればよい。
カスタマネットワークと外部ネットワークの関係を図４９に示す。
▲１▼は、インターネット・サービス・プロバイダーへの端末型ダイヤルアップのようにＬＡＮを構成しておらず、端末一台のみの場合を指す。ＮＴＴのフレッツ・ＡＤＳＬ（登録商標）などがこれに該当する。この場合はＬＡＮを構成していないが、インターネットに接しているために、やはりネットワークに接続されている（スタンドアロンではない）ものとみなす。ＬＡＮを構成していないことから、カスタマネットワークは存在しないのではとの議論がありうるが、ループバックのみのカスタマネットワークが存在し、ＷＡＮ接続されているものと考えればよい。▲３▼および▲５▼は、▲１▼に準ずるものとする。
▲２▼は、代表的なインターネット接続の場合である。これまでの説明は、このパターンを想定して、説明してきた。以下、このパターンとの相違点がどのように影響するかについて、説明する。
▲４▼は、第一種電気通信事業者や第二種電気通信事業者が提供するインターネットに接続されない、ＴＣＰ／ＩＰによるネットワークをＷＡＮとする場合である。パソコン通信やフレッツ（登録商標）オフィスなどがこれに該当する。▲２▼の場合と同様に扱って問題ない。ＤＮＳサーバが私設のものであることは、従来からあるプライベートネットワークに使用するドメイン名の命名規則において制限があるのみで、本発明には影響しない。
▲６▼は、自営網による場合である。自営網は一般に組織内の利用のために、専用線（および類似の役務。例としてＡＴＭメガリンクやＩＰ−ＶＰＮなどを挙げておく）などによって構成され、ルーティングされているものをいう。▲４▼の場合は、ＩＰ−ＶＰＮなどの契約がなければ通常はカスタマネットワーク（の内側。網端までは当然に到達するので）へのルーティングは提供されない。しかし、第一種電気通信事業者や第二種電気通信事業者が提供する役務であって、ルーティングがされる場合は、▲６▼に含めて考えた方が筋道がよい。ネットワーク境界を越えて、外部ネットワークがルーティングによって直接にカスタマネットワーク上のホストにアクセスできる場合である。すなわち、この場合は、管理対象機器（４１００）がモデムのすぐ下に位置しない場合であっても、ａのダイヤルアップするホストは上流の網からＩＰアドレスを動的に割当てられるのではなく、カスタマネットワーク上のＤＨＣＰサーバ（ＤＨＣＰリレーされている場合を含む）からＩＰアドレスを動的に割当てられ、かつ管理対象機器（４１００）であるという点で、図５０の接続形態１ないし接続形態３に相当することになる。ところで、古くから自営網を運用している会社や大学の中には、ＩＰアドレス体系がグローバル・アドレスになっているところがある。このような自営網は、インターネットそのものの構成要素であるものと考えてさしつかえない。
▲８▼は、ＬＡＮのみで構成されたネットワークにあって、ＬＡＮが多段となっている場合である。例を挙げると、１の事業所であって、フロア毎に別の部に分かれている場合に、各フロアが事業所内バックボーン・ネットワークを経由して相互に接続されている場合などである。ＷＡＮが存在しておらず、インターネットに接続しない場合やインターネットに接続しない広域のネットワークに接続しない場合か、仮にインターネットに接続していたとしてもこの接続を無視できる（セキュリティポリシが強力な組織などにあってインターネットなどへ接続する際に障壁が大きい）場合であるという特徴を除けば、自営網の場合と酷似する。ここで、ＬＡＮが多段になっているとは、単にハブなどによって多段となっているだけではなく、論理セグメントが分かれており、ルーティングされている状態を指す。この場合、管理サーバ（２０００）の接するＬＡＮが管理対象機器（４１００）の接するＬＡＮとは別のＬＡＮであれば、管理対象機器（４１００）の接するＬＡＮをカスタマネットワークと考え、▲４▼▲６▼と同じと考えればよい。
以上は、物理セグメントと論理セグメントがともに分かれている場合であったが、例外として、物理セグメントが１で論理セグメントのみ２以上に分かれている場合、例えば１のインターフェースに異なるネットワークに属する２以上のＩＰアドレスを割当て、これを中継するよう構成されたゲートウェイ装置などがある場合には、単一の（＝一段の）ＬＡＮの場合と同様となる。
▲７▼は、単一のＬＡＮの場合である。本発明は実施可能だが、ＬＡＮが一段のみの場合すなわち外部ネットワークがまったく存在しない場合には、ＴＣＰ／ＩＰ的な中継を要せず、各ホストがすべて直接かつローカルに通信できるので、動的ＩＰアドレス割当てのホストであっても、わざわざ私設のＤＮＳサーバを参照することなく、ＴＣＰ／ＩＰ以外のプロトコルによって、真性確認をした方が現実的であろう。
当然のことであるが、管理対象機器（４１００）がスタンドアロンの場合を、本発明では考慮していない。通信する相手が存在しないからである。
なお、▲２▼▲４▼▲６▼の場合は▲８▼と共存する。
以上によって、（▲７▼の場合に意味があるかどうかは別論だが）▲１▼ないし▲８▼のすべてのパターンで本発明を実施可能である。
【００７１】
ここで図４８に、主に多段のＬＡＮの場合に問題になり得る点について説明する。図４８は、カスタマネットワークにおけるＬＡＮの内訳でもあるが、自営網の場合およびインターネットに接続されない電気通信事業者が提供する役務の場合も同様であるものとし、この場合にあってはカスタマネットワークは管理対象機器（４１００）が直接接続されている部分を指すものと考えられる。ネットワーク１およびネットワーク２は、それぞれＬＡＮの場合とＷＡＮの場合がある。
図４８には、パターン１ないしパターン３までを挙げた。パターン２およびパターン３は、図４９における▲４▼▲６▼と類似のパターンであって問題がない。ここで問題となり得る場合は、パターン１の場合であって、ネットワーク１がＬＡＮの場合である。図４９における▲７▼に挙げた単一のＬＡＮの場合と同様に、管理対象機器（４１００）と管理サーバ（２０００）とが同一のＬＡＮ上にあるため、ＴＣＰ／ＩＰ以外のプロトコルによって、真性確認をした方が現実的と考えることができる。しかし、この場合であっても、別のネットワーク上に管理対象機器（４１００）が存在し、かつここでいう管理サーバ（２０００）が前記管理対象機器（４１００）をも管理するものとすれば、本発明を実施する意義はじゅうぶんにあると考える。なぜならば、別のネットワーク上の管理対象機器（４１００）を管理する際には、本発明の実施が必要なものであって、管理サーバ（２０００）が集中管理するためには、管理の方法を統一した方がよいからである。なお、図４９の▲８▼においてパターン３のように装置が配置されている場合は、図４９の▲２▼▲４▼▲６▼の場合に相当し、本発明で典型的に扱っている接続形態に相当する。
なお、ＴＣＰ／ＩＰ以外のプロトコルはルーティングされないものとする。
【００７２】
ここまで、場合分けして説明してきたが、複雑でわかりにくいものである。これはネットワークの接続のされ方を網羅的に説明する困難さに起因すると思われるので、以下のように、ＬＡＮかＷＡＮかを問わず、ルーティングがどこで止まるかによって、大別できる。
ルーティングによって、直接管理対象機器（４１００）に到達できる場合には管理サーバ（２０００）は、当然に管理対象機器（４１００）の１つ１つを別のホストとして識別できる。この場合においては、管理対象機器（４１００）は、ダイヤルアップする（動的アドレス割当てを受ける）機能と、ダイナミックＤＮＳ更新する機能と管理対象機器（４１００）であることの機能を備えていなければならない。そして、この場合は、比較的単純な場合である。
ルーティングがダイヤルアップするホストで止まる場合には、ダイヤルアップするホストにおいてポートフォワーディングなどによって、外部ネットワークからは管理対象機器（４１００）に管理サーバ（２０００）からのアクセスが到達するようにするかダイヤルアップするホストを管理対象機器（４１００）としなければならない。これはルーティングによって到達できる場合と比べてやや複雑であり、具体例についてはすでに実施例として詳述した。ダイヤルアップする（動的アドレス割当てを受ける）機能と、ダイナミックＤＮＳ更新する機能と管理対象機器（４１００）であることの機能は、独立した３のホストが担ってもまた１のホストが担ってもよいが、外部からはカスタマネットワークの代表として、管理対象機器（４１００）が確認されるという点で特徴がある。
【００７３】
実施例９
ルータなどで、設定変更用のウェブインターフェースを有する場合は、ウェルノウンポート（ＲＦＣ１７００ＡＳＳＩＧＮＥＤＮＵＭＢＥＲＳでいうところのウェルノウンポートと同じか類似するもの）に従って８０番ポートで待受けする。ファイヤウォールなどの一部の機器は、例えば８８番ポート（などの８０番ポート以外のポート）で設定変更のためのウェブアクセスを待受けする場合がある。最近のエンドサイト向けのこれらの製品はＷＡＮ側とＬＡＮ側に分かれてインターフェースを用意しており、多くの場合、ＷＡＮ側ポートにはアクセス制御が施されている。
ここで、ネットワーク接続機器において（ファイヤウォールでなくとも）、設定変更のためのウェブアクセスの待受けを８８番ポート（などの８０番ポート以外のポート）でし、アクセス制御されるものとする。この際、８０番ポートで通常のウェブアクセスを待受け、これにはアクセス制御などを施さないものとする。８０番ポートでリバースプロクシを動作させ、リバースプロクシによる転送先ウェブサーバにおいて、実施例８のあらかじめ合意された通信を実装可能とするのも手なのだが、ここで、装置にはホスト名が登録されるものとし（エンドサイト向け製品の内、低価格製品の多くはこのような装置にはホスト名の設定ができないものがある）、このホスト名はダイナミックＤＮＳによって動的更新されるセンタ側ＤＮＳサーバ（１０００）にて設定されるＦＱＤＮで登録されるものとし不揮発メモリなどの記憶装置に保存され、８０番ポートへの通信要求を受けた際に、前記保存されたＦＱＤＮを記憶装置より読み出し、該ＦＱＤＮすなわちホスト名を含めた文字列を返信するように構成する。
【００７４】
管理サーバ（２０００）が管理対象機器（４１００）に対して通信を試みる方法として、このように実施例４のようにネットワーク接続機器に対して、実施例７のようにＨＴＴＰを合意された通信の方式として用い、実施例１のように（ＳＮＭＰのｓｙｓＮａｍｅではなくＨＴＴＰだが）ＦＱＤＮを返事として合意した方法などのように実施例を組合わせた方法として用いることができる。なお、カスタマネットワーク上の位置だが、図５０の接続形態のすべての場所だけでなく、接続形態６における計算機の位置にあっても、すでに説明したように機能するものであって、ここで構成した装置がネットワーク接続機器であった場合に、配下に別のネットワークを有している場合が考えられる。また、ここで構成した装置が直接図５０におけるａのダイヤルアップするホストである必要は必ずしもない。
【００７５】
このとき仮に、ここで述べた機器が図５０にいうａのダイヤルアップするホストであって、ネットワークの到達性からＮＡＴを必要とするネットワークである場合には、８０番ポートを上記のようなサイン・アンド・カウンターサインに用いてしまうと、ウェブサービスを提供する際にポートフォワーディングなどが必要であるから、ウェルノウンでないポートをアナウンスしなければならなくなる。これでは、カスタマネットワークにおいてウェブサービスを提供しようとする場合の利便性をそこなうことになるから、ウェブサービスを提供したい場合には、類似のポートでサインを待受けするようにするとよい。すなわち、ＨＴＴＰアクセスを待受けするポートにおいて、機器設定用のポート、サイン・アンド・カウンターサインを用いたネットワーク管理用のポート、一般の閲覧に供するためのウェブサービスを提供するウェルノウンなポート（ただし、ここで述べた機器が応答するのでなく、ポートフォワーディングなどしてもよい）のように３種類のポートで待受けするように構成することもできる。
これを実施例９とする。実施例９では通信の方式をＨＴＴＰ固定とし、返事をＦＱＤＮとすることによって、単純化した。通常、ネットワーク接続機器にあっては、いわゆる計算機に比して拡張性に劣るものである。これは、例えば機能追加する際に単にプログラムを追加実装すればよいというものではなく、ファームウェアの書換えなどが必要であって、利用者によっては、簡単にできないなどの問題があるものである。そこで、、実施例９は、ルータやＮＡＴＢＯＸなどのように記憶装置の容量に制限があるネットワーク接続機器に対しても、あらかじめコンパクトに実装しておくことが可能である。
【００７６】
管理対象機器（４１００）としては、ネットワーク接続機器だけでなく、もちろん計算機であってもよいし、コンパクトに実装可能なことから、専用のシステムでもよい。この場合、専用のシステムは、単に管理サーバ（２０００）に真性確認させるためだけの機能を有しておればよく、インターフェースももちろん１でよい。例えば、図５０の接続形態６の場合であって、ｃに位置していたとすると（図５０では計算機だが、これが上記専用のシステムの場合）、ダイヤルアップするホストの外側にあるネットワークがインターネットなどのルーティングによって管理対象機器（４１００）に到達できないネットワークである場合に、ダイヤルアップするホストに静的ＮＡＴやポートフォワーディングなどが設定されていれば、外部ネットワークからはシステムに到達可能である。この場合において、システムは単にＬＡＮ上のＩＰアドレスを割当てられていれば、外部ネットワークからは、一体となって参照されるために、ここでいう専用のシステムが真性確認できれば、管理サーバ（２０００）からは、カスタマネットワークおよびその境界ノードが真性であることが確認される。つまり、ここでは、単に実施例９を実装した１のインターフェースを有する機器を準備すれば、ポートフォワーディングなどの設定をダイヤルアップするホストにするだけで、真性確認できることになる。このような装置は、単純なために、安価に製造することができるし、完成品ではなく組込み用の基盤あるいはキットとしても提供できる。また、これをソフトウェアとして実装すれば、計算機に用いる場合でも、設定作業を省略化することができる。この場合は、記憶装置に述べた記憶媒体読取り装置に実装される取り外し可能な記憶媒体とすればよい。
【００７７】
サインはあらかじめ合意された通信の方式の上位概念であって、単にカウンターサイン（合意された方式での通信に対する答えられるべき返事を返信すること）をうながす働きをする。この場合において、サインを受取った通信相手が、そのサインを理解できないようなら、その通信相手はサインの送り手が想定していた通信相手ではない。すなわち、管理対象機器（４１００）ではない。
サインの出し方もカウンターサインの内容も、相方の合意に基づくべきものである。そのため、多くのパターンが考えられることから、サインの仕方、カウンターサインの内容を多く例示してきた。
以上見てきたように、ＴＣＰ／ＩＰネットワークにおいてＩＰアドレスが変化するホストを特定するためにダイナミックＤＮＳを用いるが、なおダイナミックＤＮＳの特性のために誤認されたホスト（４２００）でなく管理対象機器だと認識されているホストとして本当に正しい通信相手（真性なホスト）であることを明らかにすることができない場合において、
図１のように、サインとして通信の方式を合意し、管理サーバ（２０００）から管理対象機器（４１００）に対してサインでもって問合せをし、管理対象機器（４１００）はサインに対するカウンターサインを返信する。この時、管理サーバ（２０００）では管理サーバ（２０００）内に設定される管理対象機器（４１００）毎の（サインと）カウンターサイン（の組あるいはペアテーブルの登録情報）と照合することによって、管理対象機器（４１００）が真性であるか否かの確認をおこなうことができる。
【００７８】
実施例１０
実施例１ないし実施例９は、管理サーバ（２０００）側から管理対象機器（４１００）に対して順にポーリングをおこなうものであった。実施例１０では、管理対象機器（４１００）の方から自律的に行動を起こす場合を示す。
【００７９】
管理対象機器（４１００）から管理サーバ（２０００）へのアライブメッセージを送信する。
メッセージ送信時において相手が正常に受取ったかどうかの確認もなく、したがって再送も発生しない場合を除けば、送信側から見れば単純な送信であったとしても、受信側からは送信側に対して少なくともＡＣＫ、ＮＡＫの応答などによる双方向の通信でもって送信処理は成立っている。このような場合でも通常単に「送信」するという表現がとられるため、ここでは以下に例示する認証などといったややインテリジェントな処理が含まれてはいるが、一連のセション（通信のかたまり）として、ここでは単に「アライブメッセージの送信」としている。
管理サーバ（２０００）では、管理対象機器（４１００）からのアライブメッセージを受付ける際に、認証をおこなうものとする。なお、管理サーバ（２０００）では、認証をおこなうことから、仮に管理対象機器（４１００）になりすまされたアクセスを受けた際にも、管理サーバ（２０００）のシステムへの侵入を阻むように設定すべきであることに注意されたい。この方法については従来の技術であり、当業者であるならば理解されることであろうから、本願では単に注意すべきこととして挙げるに止める。
【００８０】
認証はユーザ名でおこなう。ユーザ名と管理対象機器（４１００）名の組は一意な組であるものとすると、ユーザ名から、どの管理対象機器（４１００）からのアライブメッセージであるかを導き出せる。よって、管理対象機器（４１００）からのアライブメッセージを認証後受領したことによって管理サーバ（２０００）において、管理対象機器（４１００）についてわかることは、以下のことである。
▲１▼ 管理対象機器（４１００）が生存していること。
▲２▼ 管理対象機器（４１００）が真性であること。
▲３▼ 管理対象機器（４１００）のＩＰアドレス。
▲４▼ アライブメッセージの到着時間。（＝最終管理対象機器（４１００）生存確認時刻）
管理サーバ（２０００）では、管理対象機器（４１００）から送信されたアライブメッセージを認証に成功したときに受領し、認証に失敗したときには破棄する。ただし、失敗の際にもユーザ名および発信元ＩＰアドレスは記録するものとする。
【００８１】
アライブメッセージは送信されるものとしているが、管理サーバ（２０００）で認証に成功して初めて受付けられるものであるから、単にパケットを投げればよいという類の通信ではなく、ハンドシェーク後認証というコネクション型の通信をする必要がある。
コネクション型の通信として、例えばＴＣＰによる通信が考えられる。認証は、従来であれば、正規利用者本人だと確認する過程（例えば、システムにログインする権利の確認あるいはファイルシステムへのアクセス権を獲得する過程）であった。しかしここでは、利用権限の正当性を確認することではなく、管理対象機器（４１００）の識別に用いる。
【００８２】
ここでは、従来のパスワード認証を用いる場合を説明することとする。
この場合、通信の方式としては、認証できるものであれば、どのような通信の方式でもかまわない。主にシステムのアカウントを利用する方法に、ｔｅｌｎｅｔやｆｔｐが挙げられる。システムのアカウントを利用しないものとして、ＨＴＴＰのＣＧＩ認証などが挙げられる。以下、ｆｔｐを利用した例を挙げることにする。ただしｆｔｐは認証機能のみ利用し、ファイル形式変換機能やファイル転送機能などの認証以外の機能は利用しないものとする。よってここでアライブメッセージは、管理対象機器（４１００）から管理サーバ（２０００）への一連のＦＴＰコネクションである。
【００８３】
管理対象機器（４１００）と管理サーバ（２０００）の双方で合意され、設定されるべき内容を図４７に示す。
管理対象機器（４１００）がＵＮＩＸの場合は、図５３のシェルスクリプトを実行する。
ここで、ｆｔｐに対するオプション−ｎは、ｆｔｐが最初に接続する際の自動ログインを無効化（非対話型のインターフェースで実行）するためのオプションである。これによって、ＥＯＦまでをクライアント側から制御することが可能になる。ｍｇｒ．ｃｅｎｔｅｒ．ｎａｍｅｓ４ｃｏｍｍｅｒｃｅ．ｃｏｍは管理サーバ（２０００）のホスト名である。ｈｂｕｓｅｒ０１ｈｂｐａｓｓ０１はそれぞれ、ユーザ名およびパスワードである。
Ｗｉｎｄｏｗｓ機の場合は、ｆｔｐクライアントの中から、ユーザ名とパスワードを指定可能なオートパイロット機能のあるプログラムを選べばよい。その他、専用のシステムであれば、ＵＮＩＸの例を参考に実装する。
【００８４】
管理サーバ（２０００）では、管理対象機器（４１００）からの通信に対して認証ログを記録する。これによって、過去にさかのぼって、管理対象機器（４１００）が、少なくともいつまではアライブメッセージを送ってきていたか（すなわち管理対象機器（４１００）がいつまで生存していたか）などを追跡することができる。
【００８５】
管理サーバ（２０００）では、以下のログが残される。
図５４に、認証に成功したときの例を示す。
図５５に正しくないパスワードのため、認証に失敗したときの例を示す。
このうち、
Ｓｅｐ１０２１：０４：１９ｍｇｒｆｔｐｄ［２０００８］：ＦＴＰＬＯＧＩＮＦＲＯＭｔｏｋｙｏ−ｐｐｐ３６．ｋｏｒａｉ．ｏｒ．ｊｐａｓｈｂｕｓｅｒ０１（図５４の下線部）
が、管理対象機器（４１００）の識別に用いることができる。すなわち、ユーザ名と送信元ホスト名が含まれ、認証に成功したことを示している行である。これを管理対象機器（４１００）からのアライブメッセージと呼ぶこととする。実施例２に管理対象機器（４１００）名と返事に別々の文字列を使う場合の返事が管理サーバ（２０００）上の管理対象機器（４１００）の設定情報において重複しないようにした方がよいことを説明したが、実施例１０では管理対象機器（４１００）名とユーザ名は１対１に対応されなくてはならない。ユーザ名から管理対象機器（４１００）名を一意に導くことができれば、認証は管理対象機器（４１００）の生存確認に用いることがきる。ここで、表示される接続元ホスト名ｔｏｋｙｏ−ｐｐｐ３６．ｋｏｒａｉ．ｏｒ．ｊｐは、ダイナミックＤＮＳの習性により、管理対象機器（４１００）のＩＰアドレスがプロバイダ（あるいはＩＰアドレスの割当てを受けた各利用組織）のドメインに対するホスト名に化けたもの（逆引き設定されていない場合は、最初からＩＰアドレスを返すので、この行の処理は不要）であるので、このホスト名を正引きすることによって、この時点での管理対象機器（４１００）のＩＰアドレスが求められる。
【００８６】
以上が、管理対象機器（４１００）から管理サーバ（２０００）へ、管理対象機器（４１００）が自律的にその生存を知らせる場合の方法である。
しかし、アライブメッセージの最終到達時間が古い場合（例えば３日前でも１２時間前でも）であるときに、現在の管理対象機器（４１００）がどうなっているかを知ることができない。そこで現在と近似するほど古くない過去において管理対象機器（４１００）の生存確認がされている状態を保つ必要がある。こうすることによって、この状態が保てなくなれば、管理対象機器（４１００）に障害が発生したということができる。この方法を以下に示す。
【００８７】
管理対象機器（４１００）からのアライブメッセージの送信が定期的におこなわれれば、管理対象機器（４１００）が障害に陥ったことも検出可能である。すなわち、管理対象機器（４１００）からのアライブメッセージが途切れたことによって、管理対象機器（４１００）が障害に陥ったことがわかる。
図５１のように、管理対象機器（４１００）がアライブメッセージ送信プログラム（例えば、図５３のようなものである）をタイマー実行し、定期的にアライブメッセージを送信する。
管理サーバ（２０００）では、前記管理対象機器（４１００）毎のレコードの中でタイマー時間も合意しておく。ただし、ここでのタイマー時間は、プログラムがタイマー実行される時間間隔を示すものであり、通信において用いるものではないため、図４７に挙げる設定項目には含めないこととした（ただし合意されている必要はある。このような情報が、付加情報である）。このタイマー時間はプログラムをタイマー実行させるＯＳ上の仕掛け（ＵＮＩＸならｃｒｏｎ、Ｗｉｎｄｏｗｓならａｔコマンドなどの、あるいはネットワーク接続機器なら当該機器が備えているスケジュール機能など）によって、設定されるべきものである。
しかし、この場合においては管理対象機器（４１００）は、認証可能な通信をタイマー実行できるものに限られる。計算機の場合はもちろん可能だが、ネットワーク接続機器を管理対象機器（４１００）として用いる場合には、スケジュール機能をもったものに限られる。
管理サーバ（２０００）で管理対象機器（４１００）の障害発生を最遅で検出できる時間を、時間「ａ」とすると、
時間「ａ」＝タイマー時間＋遅延時間＋余裕時間
となるので、これを超えて、管理対象機器（４１００）からのアライブメッセージの到着（認証の成功）が検出できなければ、管理対象機器（４１００）は障害に陥っている。遅延時間は、中継される網の混雑やホップ数、中継ルータの処理性能、管理サーバ（２０００）や管理対象機器（４１００）の処理性能やＣＰＵの負荷が大きいことによって発生する。
このことから、ログから最後のアライブメッセージの到着時間と現在の時刻の差を計算し、この時間差が前記時間「ａ」より長い場合に、管理対象機器（４１００）が障害であることを検出するプログラム（図５２）をタイマ実行すればよい。障害が検出されたときは、実施例１のＳ２１６と同様の障害通知をおこなえばよい。
【００８８】
上で障害が検出されたときに、何らかの理由で（例えば、管理対象機器（４１００）を再起動しているタイミングなど）管理対象機器（４１００）は、異常でないにもかかわらずアライブメッセージの送信ができないことがあり得るために、実施例１と同様に２度目の障害検出を待ってもよい。
２度目の障害検出で管理対象機器（４１００）が障害に陥っていることを検出すればよい場合には、時間「ａ」を算出するためにあらかじめ遅延時間を計算する必要がなくなる。
このとき、管理サーバ（２０００）では、
時間「ａ」＝管理対象機器（４１００）で定期的にアライブメッセージを送信する際のタイマー時間
時間「ａ」＝管理サーバ（２０００）で図５２のプログラムを実行するタイマー時間
とすれば、
管理サーバ（２０００）で実行される図５２のチェックで２回連続して、障害が検出されたときに、管理対象機器（４１００）は障害に陥っているといえることになる。なお、２回目の検出は実施例１の図２９のように、フラグを用いて検出すればよい。そのため、管理対象機器（４１００）と管理サーバ（２０００）でそれぞれプログラムの実行が同期されなくても（マシン時間が同期されていなくても）タイマー時間の２回分を限度（最遅）としての障害検出が可能になる。
【００８９】
最初の障害検出のときに２度目の検出を待つかわりに、実施例１ないし実施例９のいずれかの方法で、管理サーバ（２０００）の方から管理対象機器（４１００）に確認プロセスをおこなうことによって、管理対象機器（４１００）が障害状態に陥っていることを確認することもできる。
また、この場合において、管理対象機器（４１００）からのアライブメッセージの到着があるかあるいはアライブメッセージの到着が途切れることを障害検出の手段とするのではなく（すなわち認証は実は重要ではなく）、実施例１ないし実施例９のいずれかの方法で管理対象機器（４１００）の活死を確認するための、単にトリガとして実施例１０を用いることができる。
この際、実施例１０を接続形態６の計算機で実施して、前記トリガによって、実施例４を接続形態２のネットワーク接続機器で行うという、１のカスタマネットワークに管理対象機器（４１００）が２つあるような応用も可能である。もちろん、接続形態６で実施例１０と実施例１ないし８とを２種類の管理対象機器（４１００）でおこなうなどして、冗長化するのもよい。
【００９０】
これまで認証の方法を、「認証はユーザ名でおこなう」ものとして説明してきたたが、これは既存のシステムによるログイン認証の仕組みを流用しやすかったために用いただけである。「しかしここでは、利用権限の正当性を確認することではなく、管理対象機器（４１００）の識別に用いる。」と前記したとおり、「認証はユーザ名でおこなう」必要はかならずしもない。
すなわち、合意（管理サーバ（２０００）にとって予期）された方法にのっとって、所定のメッセージが管理サーバ（２０００）に届くことによって、管理対象機器（４１００）の生存が確認できる。
【００９１】
サイン・アンド・カウンターサインでは、管理サーバ（２０００）から管理対象機器（４１００）への問合せを行い（サイン）、管理対象機器（４１００）から管理サーバ（２０００）への返事（カウンターサイン）が管理サーバ（２０００）において予期（合意）されたものである場合に、管理対象機器（４１００）が真性であるものとしていた。
ここで、管理対象機器（４１００）が一方的に管理サーバ（２０００）に対して、２つの独立したメッセージを順に送信したものとすると、管理サーバ（２０００）では２つのメッセージの内容Ａ、Ｂとその順序を照合することによって、管理対象機器（４１００）が真性であるという事ができる。この方法は、認証という概念には含まれないものである。
実際には、連続して送られてくる２のメッセージにおいて、その順番と内容から管理サーバ（２０００）に管理対象機器（４１００）を識別させ生存確認させることができる。この際、管理サーバ（２０００）では、最初に送られてくるメッセージが正しかった場合に、次のメッセージが正しいことをチェックするプログラムを書けばよい。ただし連続して送信される２のメッセージではなく、単に１のメッセージを送信する方が、タイマー時間を短くできる場合がある。
【００９２】
また、公開かぎ暗号方式の利用した方法を用いることもできる。例えば管理対象機器（４１００）は管理対象機器（４１００）を示す識別子を管理サーバ（２０００）の公開かぎで暗号化し、これをアライブメッセージとして送信することによって、管理対象機器（４１００）が生存しかつ真性であることを管理対象機器（４１００）に知らせることもできる。この場合、管理対象機器（４１００）を示す識別子は管理サーバ（２０００）の公開かぎで暗号化されているため、管理サーバ（２０００）の秘密かぎでしか復号することができないため、前記識別子は第三者に漏洩することはない（復号できない暗号化された情報は盗聴されてもよい）。この方法でも一応は安全性を確保できるが、悪意の第三者が適当な文字列を管理サーバ（２０００）の公開かぎで暗号化して管理サーバ（２０００）に送信する（公開かぎは入手可能であるので、これは可能である）と、アライブメッセージを偽造することができることとなる。管理サーバ（２０００）には、前記識別子が登録されているものとすると、（ここまで気にする必要があるかどうかは別として）攻撃者が識別子を推測できるなら、管理サーバ（２０００）に管理対象機器（４１００）の状態のいかんにかかわらず、稼動していると誤認させることができる。このような場合には、前記識別子をいったん管理対象機器（４１００）の秘密かぎで暗号化した後、さらに管理サーバ（２０００）の公開かぎで暗号化した後にアライブメッセージとして送信するか、メッセージダイジェストを付して生成されたアライブメッセージを送信するとよい。公開かぎ暗号方式の利用は、処理が重くなるという難点はあるが、盗聴不可、本人確認、改ざんを発見できるなどの面で優れた点が多い。
なお、管理対象機器（４１００）たる装置は、実施例９で説明したものを用いることができる。
【００９３】
以上のことによって、管理サーバ（２０００）側から管理対象機器（４１００）に対して順にポーリングをおこなう方法だけでなく、管理対象機器（４１００）の方から自律的に行動を起こす場合でも、管理サーバ（２０００）と管理対象機器（４１００）とが所定の通信をすることによって、管理対象機器（４１００）の真性を管理サーバ（２０００）に確認させることができる。
【００９４】
【発明の効果】
固定的なＩＰアドレスを与えられたＴＣＰ／ＩＰネットワーク上のホストの管理は、通常であれば機器監視としてｐｉｎｇコマンドなどを利用してホストの活死を監視することができる。しかし、ダイヤルアップのホストにあっては、そのＩＰアドレスが変化することから、ｐｉｎｇによる管理では、誤った（管理対象機器でない）ホストがｐｉｎｇに応えていても、正常に稼動していることになってしまう。本発明では、管理対象機器（４１００）が真性なホストであることを確認するようにして、これまで管理することのできなかったＩＰアドレスの変化するホストを、管理できるようにした。また、通常の管理をおこなう場合にも、従来であればＩＰアドレスが変化するホストは管理することができなかったが、通常の管理の前段の処理として本発明を用いることによって、その後のより高度な管理（例えば、ＣＰＵ負荷やネットワークトラフィックの監視）をも可能とした。
【００９５】
【補助的説明】
１、ログの出方を含むプログラム出力は実装やオプションに依存する。ログファイルやプログラムの在処などは、処理系によって標準的な場所が異なる。それぞれ、実施しようとする環境にあわせて実施されたい。
２、実験はインターネットのグローバルネットワーク環境をメインにおこなった。ホスト名やＩＰアドレスについては、実験時に利用可能なものを用いた。実験用に用意したホストもあるが、多くは実在のホストである。これらのホストはグローバルサービスを提供しているものであり、本発明と直接の関係はないものも多い。また、これらのホストが、将来に向けても実験時と同様のサービスを提供している保証はない。よって、ホスト名やＩＰアドレスについては、あくまでも例として見ていただきたい。本発明はやがて公開されることになるが、その際も、本発明が何らかの攻撃の一助となることを、発明者は決して望んでいない。３、ｔｅｌｎｅｔコマンドやＴＥＬＮＥＴプロトコルなどのように、コマンドは小文字、プロトコルは大文字として表記した。コマンドとプロトコルの両方の意味で通じる場合には、いずれかで表記しているが区別していない。
４、カスタマネットワーク上のサーバあるいは端末機器などの計算機はパーソナルコンピュータであることをさまたげない。
【００９６】
【公知の技術文献】
【公知の技術のＵＲＬ一覧】
ＩＳＣ−ＢＩＮＤは最初のＤＮＳの実装としてバークレー版ＵＮＩＸに採用されて以来、インターネットの標準ＤＮＳである。インターネット・ソフトウェア・コンソーシアムは、ＢＩＮＤの開発元である。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｗｗｗ．ｉｓｃ．ｏｒｇ／
ｎｅｔ−ｓｎｍｐはＳＮＭＰエージェントとＳＮＭＰマネージャの統合パッケージである。ｕｃｄ−ｓｎｍｐから名前が変更されたものである。ＵＣＤはカリフォルニア大学デビス校の意味で、開発の母体であった。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｗｗｗ．ｎｅｔ−ｓｎｍｐ．ｏｒｇ／
ＭＲＴＧ（ＴｈｅＭｕｌｔｉＲｏｕｔｅｒＴｒａｆｆｉｃＧｒａｐｈｅｒ）は、ネットワークの負荷を監視するソフトウェアツールである。ＭＲＴＧは現在のネットワークのトラフィックの状態を示すグラフィックイメージを含むＨＴＭＬページを生成する。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｗｗｗ．ｍｒｔｇ．ｊｐ／ｄｏｃ／（日本語）
ｈｔｔｐ：／／ｐｅｏｐｌｅ．ｅｅ．ｅｔｈｚ．ｃｈ／￣ｏｅｔｉｋｅｒ／ｗｅｂｔｏｏｌｓ／ｍｒｔｇ／
ｇｎｕｄｉｐはダイナミックＤＮＳをグローバルサービスとして役務提供するためのパッケージである。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｇｎｕｄｉｐ２．ｓｏｕｒｃｅｆｏｒｇｅ．ｎｅｔ／
ＤＨＩＳはダイナミックＤＮＳをグローバルサービスとして役務提供するためのパッケージである。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｗｗｗ．ｄｈｉｓ．ｏｒｇ／
ＤｙｎＤＮＳはダイナミックＤＮＳをグローバルサービスとして役務提供している業者である。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｗｗｗ．ｄｙｎｄｎｓ．ｏｒｇ／
ｎａｍｅｓ４ｃｏｍｍｅｒｃｅはダイナミックＤＮＳをグローバルサービスとして役務提供している業者である。以下にＵＲＬを示す。
ｈｔｔｐ：／／ｗｗｗ．ｎａｍｅｓ４ｃｏｍｍｅｒｃｅ．ｎｅｔ／
【００９７】
【ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍに関係するＲＦＣ一覧】
０８１９ＤｏｍａｉｎｎａｍｉｎｇｃｏｎｖｅｎｔｉｏｎｆｏｒＩｎｔｅｒｎｅｔｕｓｅｒａｐｐｌｉｃａｔｉｏｎｓ．
０８８１Ｄｏｍａｉｎｎａｍｅｓｐｌａｎａｎｄｓｃｈｅｄｕｌｅ．（ＵｐｄａｔｅｄｂｙＲＦＣ０８９７）
０８９７Ｄｏｍａｉｎｎａｍｅｓｙｓｔｅｍｉｍｐｌｅｍｅｎｔａｔｉｏｎｓｃｈｅｄｕｌｅ．（ＵｐｄａｔｅｓＲＦＣ０８８１）
０９２０Ｄｏｍａｉｎｒｅｑｕｉｒｅｍｅｎｔｓ．
０９２１Ｄｏｍａｉｎｎａｍｅｓｙｓｔｅｍｉｍｐｌｅｍｅｎｔａｔｉｏｎｓｃｈｅｄｕｌｅ − ｒｅｖｉｓｅｄ．（ＵｐｄａｔｅｓＲＦＣ０８９７）
０９５２ＤｏＤＩｎｔｅｒｎｅｔｈｏｓｔｔａｂｌｅｓｐｅｃｉｆｉｃａｔｉｏｎ．
０９７４Ｍａｉｌｒｏｕｔｉｎｇａｎｄｔｈｅｄｏｍａｉｎｓｙｓｔｅｍ．
１０３２Ｄｏｍａｉｎａｄｍｉｎｉｓｔｒａｔｏｒｓｇｕｉｄｅ．
１０３３Ｄｏｍａｉｎａｄｍｉｎｉｓｔｒａｔｏｒｓｏｐｅｒａｔｉｏｎｓｇｕｉｄｅ．
１０３４Ｄｏｍａｉｎｎａｍｅｓ − ｃｏｎｃｅｐｔｓａｎｄｆａｃｉｌｉｔｉｅｓ．（ＵｐｄａｔｅｄｂｙＲＦＣ１１０１，ＲＦＣ１１８３，ＲＦＣ１３４８，ＲＦＣ１８７６，ＲＦＣ１９８２，ＲＦＣ２０６５，ＲＦＣ２１８１，ＲＦＣ２３０８，ＲＦＣ２５３５）
１０３５Ｄｏｍａｉｎｎａｍｅｓ − ｉｍｐｌｅｍｅｎｔａｔｉｏｎａｎｄｓｐｅｃｉｆｉｃａｔｉｏｎ．
１１０１ＤＮＳｅｎｃｏｄｉｎｇｏｆｎｅｔｗｏｒｋｎａｍｅｓａｎｄｏｔｈｅｒｔｙｐｅｓ．（ＵｐｄａｔｅｓＲＦＣ１０３４，ＲＦＣ１０３５）
１１２２ＲｅｑｕｉｒｅｍｅｎｔｓｆｏｒＩｎｔｅｒｎｅｔｈｏｓｔｓ − ｃｏｍｍｕｎｉｃａｔｉｏｎｌａｙｅｒｓ．
１１２３ＲｅｑｕｉｒｅｍｅｎｔｓｆｏｒＩｎｔｅｒｎｅｔｈｏｓｔｓ − ａｐｐｌｉｃａｔｉｏｎａｎｄｓｕｐｐｏｒｔ．（Ｕｐｄａｔｅｓ
ＲＦＣ０８２２）（ＵｐｄａｔｅｄｂｙＲＦＣ２１８１）
１１７８Ｃｈｏｏｓｉｎｇａｎａｍｅｆｏｒｙｏｕｒｃｏｍｐｕｔｅｒ．
１１８３ＮｅｗＤＮＳＲＲＤｅｆｉｎｉｔｉｏｎｓ．（ＵｐｄａｔｅｓＲＦＣ１０３４，ＲＦＣ１０３５）
１４６４ＵｓｉｎｇｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍＴｏＳｔｏｒｅＡｒｂｉｔｒａｒｙＳｔｒｉｎｇＡｔｔｒｉｂｕｔｅｓ．
１４８０ＴｈｅＵＳＤｏｍａｉｎ．
１５３５ＡＳｅｃｕｒｉｔｙＰｒｏｂｌｅｍａｎｄＰｒｏｐｏｓｅｄＣｏｒｒｅｃｔｉｏｎＷｉｔｈＷｉｄｅｌｙＤｅｐｌｏｙｅｄＤＮＳＳｏｆｔｗａｒｅ．
１５３６ＣｏｍｍｏｎＤＮＳＩｍｐｌｅｍｅｎｔａｔｉｏｎＥｒｒｏｒｓａｎｄＳｕｇｇｅｓｔｅｄＦｉｘｅｓ．
１５９１ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍＳｔｒｕｃｔｕｒｅａｎｄＤｅｌｅｇａｔｉｏｎ．
１６１１ＤＮＳＳｅｒｖｅｒＭＩＢＥｘｔｅｎｓｉｏｎｓ．
１６１２ＤＮＳＲｅｓｏｌｖｅｒＭＩＢＥｘｔｅｎｓｉｏｎｓ．
１７０６ＤＮＳＮＳＡＰＲｅｓｏｕｒｃｅＲｅｃｏｒｄｓ．
１７１３ＴｏｏｌｓｆｏｒＤＮＳｄｅｂｕｇｇｉｎｇ．
１７９４ＤＮＳＳｕｐｐｏｒｔｆｏｒＬｏａｄＢａｌａｎｃｉｎｇ．
１８７６ＡＭｅａｎｓｆｏｒＥｘｐｒｅｓｓｉｎｇＬｏｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ．（ＵｐｄａｔｅｓＲＦＣ１０３４，ＲＦＣ１０３５）
１８８６ＤＮＳＥｘｔｅｎｓｉｏｎｓｔｏｓｕｐｐｏｒｔＩＰｖｅｒｓｉｏｎ６．
１９１２ＣｏｍｍｏｎＤＮＳＯｐｅｒａｔｉｏｎａｌａｎｄＣｏｎｆｉｇｕｒａｔｉｏｎＥｒｒｏｒｓ．
１９１８ＡｄｄｒｅｓｓＡｌｌｏｃａｔｉｏｎｆｏｒＰｒｉｖａｔｅＩｎｔｅｒｎｅｔｓ．
１９５６ＲｅｇｉｓｔｒａｔｉｏｎｉｎｔｈｅＭＩＬＤｏｍａｉｎ．
１９８２ＳｅｒｉａｌＮｕｍｂｅｒＡｒｉｔｈｍｅｔｉｃ．（ＵｐｄａｔｅｓＲＦＣ１０３４，ＲＦＣ１０３５）
１９９５ＩｎｃｒｅｍｅｎｔａｌＺｏｎｅＴｒａｎｓｆｅｒｉｎＤＮＳ．
１９９６ＡＭｅｃｈａｎｉｓｍｆｏｒＰｒｏｍｐｔＮｏｔｉｆｉｃａｔｉｏｎｏｆＺｏｎｅＣｈａｎｇｅｓ（ＤＮＳＮＯＴＩＦＹ）．（ＵｐｄａｔｅｓＲＦＣ１０３５）
２０１０ＯｐｅｒａｔｉｏｎａｌＣｒｉｔｅｒｉａｆｏｒＲｏｏｔＮａｍｅＳｅｒｖｅｒｓ．
２０５２ＡＤＮＳＲＲｆｏｒｓｐｅｃｉｆｙｉｎｇｔｈｅｌｏｃａｔｉｏｎｏｆｓｅｒｖｉｃｅｓ（ＤＮＳＳＲＶ）．
２０６５ＤＮＳＳｅｃｕｒｉｔｙ．（削除）
２１０４ＨＭＡＣ：Ｋｅｙｅｄ−ＨａｓｈｉｎｇｆｏｒＭｅｓｓａｇｅＡｕｔｈｅｎｔｉｃａｔｉｏｎ．
２１３６ＤｙｎａｍｉｃＵｐｄａｔｅｓｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳＵＰＤＡＴＥ）．（ＵｐｄａｔｅｓＲＦＣ１０３５）
２１３７ＳｅｃｕｒｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍＤｙｎａｍｉｃＵｐｄａｔｅ．（ＵｐｄａｔｅｓＲＦＣ１０３５）
２１４６Ｕ．Ｓ．ＧｏｖｅｒｎｍｅｎｔＩｎｔｅｒｎｅｔＤｏｍａｉｎＮａｍｅｓ．
２１６３ＵｓｉｎｇｔｈｅＩｎｔｅｒｎｅｔＤＮＳｔｏＤｉｓｔｒｉｂｕｔｅＭＩＸＥＲＣｏｎｆｏｒｍａｎｔＧｌｏｂａｌＡｄｄｒｅｓｓＭａｐｐｉｎｇ（ＭＣＧＡＭ）．
２１６８ＲｅｓｏｌｕｔｉｏｎｏｆＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒｓｕｓｉｎｇｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ．
２１８１ＣｌａｒｉｆｉｃａｔｉｏｎｓｔｏｔｈｅＤＮＳＳｐｅｃｉｆｉｃａｔｉｏｎ．（ＵｐｄａｔｅｓＲＦＣ１０３４，ＲＦＣ１０３５，
ＲＦＣ１１２３）（ＵｐｄａｔｅｄｂｙＲＦＣ２５３５）
２１８２ＳｅｌｅｃｔｉｏｎａｎｄＯｐｅｒａｔｉｏｎｏｆＳｅｃｏｎｄａｒｙＤＮＳＳｅｒｖｅｒｓ．
２２１９ＵｓｅｏｆＤＮＳＡｌｉａｓｅｓｆｏｒＮｅｔｗｏｒｋＳｅｒｖｉｃｅｓ．
２２３０ＫｅｙＥｘｃｈａｎｇｅＤｅｌｅｇａｔｉｏｎＲｅｃｏｒｄｆｏｒｔｈｅＤＮＳ．
２２４７ＵｓｉｎｇＤｏｍａｉｎｓｉｎＬＤＡＰ／Ｘ．５００ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅｓ．
２３０８ＮｅｇａｔｉｖｅＣａｃｈｉｎｇｏｆＤＮＳＱｕｅｒｉｅｓ（ＤＮＳＮＣＡＣＨＥ）．（ＵｐｄａｔｅｓＲＦＣ１０３４，ＲＦＣ１０３５）
２３１７ＣｌａｓｓｌｅｓｓＩＮ−ＡＤＤＲ．ＡＲＰＡｄｅｌｅｇａｔｉｏｎ．２３４５ＤｏｍａｉｎＮａｍｅｓａｎｄＣｏｍｐａｎｙＮａｍｅＲｅｔｒｉｅｖａｌ．
２３５２ＡＣｏｎｖｅｎｔｉｏｎＦｏｒＵｓｉｎｇＬｅｇａｌＮａｍｅｓａｓＤｏｍａｉｎＮａｍｅｓ．
２３７３ＩＰＶｅｒｓｉｏｎ６ＡｄｄｒｅｓｓｉｎｇＡｒｃｈｉｔｅｃｔｕｒｅ．
２３７４ＡｎＩＰｖ６ＡｇｇｒｅｇａｔａｂｌｅＧｌｏｂａｌＵｎｉｃａｓｔＡｄｄｒｅｓｓＦｏｒｍａｔ．
２３７５ＩＰｖ６ＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓＡｓｓｉｇｎｍｅｎｔｓ．
２３７７ＮａｍｉｎｇＰｌａｎｆｏｒＩｎｔｅｒｎｅｔＤｉｒｅｃｔｏｒｙ−ＥｎａｂｌｅｄＡｐｐｌｉｃａｔｉｏｎｓ．
２５１７ＢｕｉｌｄｉｎｇＤｉｒｅｃｔｏｒｉｅｓｆｒｏｍＤＮＳ：ＥｘｐｅｒｉｅｎｃｅｓｆｒｏｍＷＷＷＳｅｅｋｅｒ．
２５３５ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍＳｅｃｕｒｉｔｙＥｘｔｅｎｓｉｏｎｓ．（ＵｐｄａｔｅｓＲＦＣ２１８１，ＲＦＣ１０３５，ＲＦＣ１０３４）
２５３６ＤＳＡＫＥＹｓａｎｄＳＩＧｓｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳ）．
２５３７ＲＳＡ／ＭＤ５ＫＥＹｓａｎｄＳＩＧｓｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳ）．
２５３８ＳｔｏｒｉｎｇＣｅｒｔｉｆｉｃａｔｅｓｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳ）．
２５３９ＳｔｏｒａｇｅｏｆＤｉｆｆｉｅ−ＨｅｌｌｍａｎＫｅｙｓｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳ）．
２５４０ＤｅｔａｃｈｅｄＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳ）Ｉｎｆｏｒｍａｔｉｏｎ．
２５４１ＤＮＳＳｅｃｕｒｉｔｙＯｐｅｒａｔｉｏｎａｌＣｏｎｓｉｄｅｒａｔｉｏｎｓ．
２５５３ＢａｓｉｃＳｏｃｋｅｔＩｎｔｅｒｆａｃｅＥｘｔｅｎｓｉｏｎｓｆｏｒＩＰｖ６．
２６０６ＲｅｓｅｒｖｅｄＴｏｐＬｅｖｅｌＤＮＳＮａｍｅｓ．（ＡｌｓｏＲＦＣ２６０６）
２６７１ＥｘｔｅｎｓｉｏｎＭｅｃｈａｎｉｓｍｓｆｏｒＤＮＳ（ＥＤＮＳ０）．
２６７２Ｎｏｎ−ＴｅｒｍｉｎａｌＤＮＳＮａｍｅＲｅｄｉｒｅｃｔｉｏｎ．
２６７３ＢｉｎａｒｙＬａｂｅｌｓｉｎｔｈｅＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ．
２７８２ＡＤＮＳＲＲｆｏｒｓｐｅｃｉｆｙｉｎｇｔｈｅｌｏｃａｔｉｏｎｏｆｓｅｒｖｉｃｅｓ（ＤＮＳＳＲＶ）．
２８４５ＳｅｃｒｅｔＫｅｙＴｒａｎｓａｃｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎｆｏｒＤＮＳ（ＴＳＩＧ）．
２８７０ＲｏｏｔＮａｍｅＳｅｒｖｅｒＯｐｅｒａｔｉｏｎａｌＲｅｑｕｉｒｅｍｅｎｔｓ．
【図面の簡単な説明】
【図１】サイン・アンド・カウンターサインの動作を示す図である。
【図２】インターネットのドメイン名における、ドメインツリーを示す図である。
【図３】管理対象機器もしくはカスタマネットワークにおいて、ダイヤルアップを示す図である。
【図４】管理対象機器もしくはカスタマネットワークにおいて、アドレス割当てを示す図である。
【図５】管理対象機器もしくはカスタマネットワークにおいて、ＤＮＳ更新を示す図である。
【図６】管理対象機器もしくはカスタマネットワークにおいて、正常状態を示す図である。
【図７】管理対象機器もしくはカスタマネットワークにおいて、回線断発生を示す図である。
【図８】管理対象機器もしくはカスタマネットワークにおいて、再接続を示す図である。
【図９】管理対象機器もしくはカスタマネットワークにおいて、アドレス割当て（再）を示す図である。
【図１０】管理対象機器もしくはカスタマネットワークにおいて、ＤＮＳ更新（再）を示す図である。
【図１１】管理対象機器もしくはカスタマネットワークにおいて、ホストの移動を示す図である。
【図１２】各ネットワークにおいて、参照されるＤＮＳを示す図である。
【図１３】管理対象機器もしくはカスタマネットワークにおいて、誤認を示す図である。
【図１４】管理対象機器もしくはカスタマネットワークにおいて、正常状態（収束）を示す図である。
【図１５】管理対象機器もしくはカスタマネットワークにおいて、回線断のまま（図８以降の別パターン）を示す図である。
【図１６】管理対象機器もしくはカスタマネットワークにおいて、回線断のままの場合の誤認を示す図である。
【図１７】管理対象機器もしくはカスタマネットワークを保守する場合において、回線断時などにおける第二の保守経路による保守を示す図である。
【図１８】インターネットの一般利用者が管理対象ホストを正引き名前問合せする場合において、キャッシュが有効な時のＤＮＳの探索順を示す図である。
【図１９】インターネットの一般利用者が管理対象ホストを正引き名前問合せする場合において、キャッシュが有効でない時のＤＮＳの探索順を示す図である。
【図２０】キャッシュの生存時間を示す図である。
【図２１】管理対象ホストの動作および外部環境の変化を示すフローチャートである。
【図２２】管理対象ホストの障害のパターンを示す図である。
【図２３】キャッシュの生存時間の収束１（計測プログラム）を示す図である。
【図２４】キャッシュの生存時間の収束２（計測結果１）を示す図である。
【図２５】キャッシュの生存時間の収束３（計測結果１の続き）を示す図である。
【図２６】キャッシュの生存時間の収束４（計測結果２の続き）を示す図である。
【図２７】課題を解決するための手段を示すフローチャートである。
【図２８】課題を解決するための手段２（Ｓ２０４のオプション処理）を示すフローチャートである。
【図２９】課題を解決するための手段３（Ｓ２１６のオプション処理）を示すフローチャートである。
【図３０】スクリプト１を示す図である。
【図３１】スクリプト１正常出力サンプル（正常な場合）を示す図である。
【図３２】スクリプト１エラー出力サンプル（管理対象ホストが見付けられなかった場合）を示す図である。
【図３３】スクリプト１エラー出力サンプル（管理対象ホストが２度目に見付けられなかった場合）を示す図である。
【図３４】ＤＩＧコマンド正常出力サンプルを示す図である。
【図３５】ＤＩＧコマンドエラー出力サンプル（ＤＮＳサーバが存在しない場合）を示す図である。
【図３６】ＤＩＧコマンドエラー出力サンプル（管理対象ホストが存在しない場合）を示す図である。
【図３７】ＳＮＭＰ正常出力サンプル（管理対象機器（４１００）が真性の場合）を示す図である。
【図３８】ＳＮＭＰエラー出力サンプル（ホストが間違いの場合）を示す図である。
【図３９】ＳＮＭＰエラー出力サンプル（コミュニティ名が間違いの場合）を示す図である。
【図４０】ＳＮＭＰエラー出力サンプル（オブジェクトＩＤの指定間違いの場合）を示す図である。
【図４１】ＢＩＮＤにおけるバージョン情報の設定のためにする設定ファイルの変更箇所を示す図である。
【図４２】ＤＩＧコマンド正常出力サンプルを示す図である。
【図４３】ＤＩＧコマンドエラー出力サンプル（管理対象ホストが存在しなかった場合）を示す図である。
【図４４】ＤＩＧコマンドエラー出力サンプル（別のネームサーバを参照してしまった場合）を示す図である。なお、バージョン情報が設定されていない場合の標準的な出力例（正常）でもある。
【図４５】ＳＭＴＰサーバ（ＳＥＮＤＭＡＩＬ）に接続した際の最初のメッセージ例を示す図である。
【図４６】管理サーバ（２０００）から管理対象機器（４１００）へ行きがＩＰアドレス、帰りがＦＱＤＮであることを示す図である。
【図４７】管理サーバ（２０００）と管理対象機器（４１００）の通信に必要な設定されるべき項目を一覧で示す図である。
【図４８】各ホストとネットワークの位置関係を示す図である。
【図４９】カスタマネットワークとＷＡＮの関係を示す図である。
【図５０】管理対象機器（４１００）のカスタマネットワークにおける接続形態を示す図である。
【図５１】管理対象機器（４１００）から管理サーバ（２０００）へアライブメッセージが定期的に送信される様子を示す図である。
【図５２】管理対象機器（４１００）からアライブメッセージが定期的に送信される場合に管理サーバ（２０００）で実行すべき処理を示すフローチャートである。
【図５３】管理対象機器（４１００）で実行されるｆｔｐによるアライブメッセージ送信プログラム（シェルスクリプト例）を示す図である。
【図５４】管理サーバ（２０００）でのｆｔｐ認証に成功したときのログ出力サンプルを示す図である。
【図５５】管理サーバ（２０００）でのｆｔｐ認証に失敗したときのログ出力サンプルを示す図である。
【符号の説明】
記号名称
１０００センタ側ＤＮＳサーバ。ダイナミックＤＮＳサービスを提供するサーバ。
２０００センタ側管理サーバ。
４０００プロバイダＡ。管理対象機器の接続先たるプロバイダである。あるいはカスタマネットワークから見て上流のネットワーク（ＤＮＳサーバなどがある側）を構成し、これに接続されるネットワーク境界ノードに動的ＩＰアドレス割当てする機能を有するものを指す。
４１００管理対象機器。管理サーバからの管理を受けるホストである。ホストとは、ＴＣＰ／ＩＰネットワーク上のＩＰアドレスを割当てられた装置をいうのであって、必ずしも計算機である必要はなく、ネットワーク接続機器であってもよい。
４２００プロバイダＡの別のユーザ。プロバイダＡの管理対象機器以外のユーザである。別のホストあるいは誤認されたホストともいう。管理対象機器がかつて割当を受けていたＩＰアドレスを割当てられる可能性があるという点で、管理対象機器と誤認されるおそれのあるホストのこと。
４５００プロバイダＡのＤＮＳサーバ。
５０００プロバイダＢ。管理対象機器の接続先以外のプロバイダ。すなわちインターネットの一般利用者の接続先たるプロバイダである。この概念はプロバイダＡがインターネットに接続しているかもしくはプロバイダＡがその他のＴＣＰ／ＩＰネットワークと相互接続されている場合にのみ有効な考え方である。
５３００一般利用者。インターネットの一般利用者。（センタ側と総称されるサーバの）管理者および管理対象機器の運用者、管理対象機器の（閲覧者を除く）直接（ローカルな）利用者から見た、第三者のことである。管理対象機器（あるいはカスタマネットワークとプロバイダＡのネットワーク境界）に動的ＩＰアドレス割当てするプロバイダＡがインターネットに接続しておりかつプロバイダＢがインターネットに接続しているか、もしくはプロバイダＡとプロバイダＢが相互接続されている場合にのみ一般利用者の概念は（管理対象機器から見て）プロバイダＢの上で成立する。すなわち、プロバイダＢは（プロバイダＡから見て）ルーティングによって到達する別のネットワークでありさえすればよい。
５５００プロバイダＢのＤＮＳサーバ

Claims

ＴＣＰ／ＩＰネットワークにおいて、
管理対象機器（4100）の使用するドメイン名に属するホスト名のＩＰアドレスを動的に更新するシステムにおいて、
ＩＰアドレスの割当てを動的に受けてなる計算機もしくはネットワーク接続機器を管理対象機器（4100）とする場合か、
ＩＰアドレスの割当てを動的に受けてなる装置と一体となって外部ネットワークから参照される計算機もしくはネットワーク接続機器もしくはシステムを管理対象機器（4100）とする場合であって、
管理サーバ（2000）に第三者に漏洩しても良い情報を管理対象機器（4100）の真性を確認させる情報として記憶させ、管理サーバ（2000）と管理対象機器（4100）とが所定の通信をすることによって管理対象機器（4100）が管理サーバ（2000）に対してした返信を前記記憶した情報と比較することによって、管理対象機器（4100）の真偽を管理サーバ（2000）に確認させることを特徴とするネットワーク管理の方法。
請求項１に記載のネットワーク管理方法において、
管理対象機器（4100）において、管理対象機器（4100）の記憶装置に第三者に漏洩しても良い任意の情報を答えるべき返事として保存し、あらかじめ合意された方式での通信に対して前記保存された情報を記憶装置より読み出し、少なくとも該情報を含めた返事を返信することによって、管理対象機器（4100）が真性の管理対象機器（4100）であることを管理サーバ（2000）に確認させることを特徴とするネットワーク管理の方法。
請求項１に記載のネットワーク管理方法において、
管理対象機器（4100）のドメインを管理する複数存在するＤＮＳサーバの内の１のＤＮＳサーバを選択して正引き名前問合せをして、参照する管理対象機器（4100）毎に異なるＤＮＳサーバに切り替えることによって、管理対象機器（4100）のＩＰアドレスを取得して、請求項１に記載の管理対象機器（4100）と前記所定の通信をするために前記取得したＩＰアドレスを用いておこなうことを特徴とするネットワーク管理の方法。
請求項１から請求項３のいずれかに記載のネットワーク管理方法において、
管理対象機器（4100）の真性確認に失敗した場合に、所定の時間間隔を経過した後、再度請求項１から請求項３のいずれかに記載のネットワーク管理方法を実施することによって、管理対象機器（4100）にネットワーク的に到達するかしないかを確認することを特徴とするネットワーク管理の方法。
管理対象機器（4100）から管理サーバ（2000）に対して、所定の時間間隔でアライブメッセージの送信をおこない、
管理サーバ（2000）では前記アライブメッセージの到着が途切れたことをトリガとして、請求項１から請求項４のいずれかに記載のネットワーク管理方法を実施することを特徴とするネットワーク管理の方法。
請求項５に記載のネットワーク管理方法において、
管理サーバ（2000）では、管理対象機器（4100）からの前記アライブメッセージを受信することによって管理対象機器（4100）のＩＰアドレスの変化にかかわらず管理対象機器（4100）が、どの管理対象機器（4100）であるかを識別するかあるいは管理対象機器（4100）が少なくとも生存していることを確認することを特徴とするネットワーク管理の方法。
請求項１から請求項６のいずれかに記載のネットワーク管理方法において、
前記真性確認の結果を、所定の対象者に通知することをさらに具備することを特徴とするネットワーク管理の方法。
ＳＮＭＰマネージャを用いてするネットワーク管理方法に先だって、請求項１から請求項６のいずれかに記載の管理対象機器（4100）の真性確認を実施し、ここで管理対象機器（4100）が真性であることが確認された場合に、真性であることが確認されたネットワーク上で管理対象機器（4100）を特定する情報を、ＳＮＭＰマネージャを用いてするネットワーク管理の方法に引き渡すことによって、動的にＩＰアドレスが変化する管理対象機器（4100）を管理することを特徴とするネットワーク管理の方法。
請求項１から請求項８のいずれかに記載のネットワーク管理方法を、
計算機もしくはネットワーク接続機器に実行させるためのプログラム。
管理対象機器（4100）を管理するためのシステムであって、
該システムに管理対象機器（4100）毎に少なくともサインが設定され、カウンターサインが管理対象機器（4100）を示すＦＱＤＮでない場合にはカウンターサインをも設定され、該システムから管理対象機器（4100）にサインを送信する手段と、管理対象機器（4100）から返信される第三者に漏洩しても良い情報からなるカウンターサインを受信する手段と、前記受信されたカウンターサインと前記設定されたカウンターサインとを比較する手段とを備え、比較された結果が真であることによって管理対象機器（4100）が真性の管理対象機器（4100）であることを確認することを特徴とするシステム。
管理対象機器（4100）を管理するためのシステムであって、
該システムに管理対象機器（4100）毎に少なくともあらかじめ合意された通信の方式が設定され、合意された方式での通信に対する返事が管理対象機器（4100）を示すＦＱＤＮでない場合には第三者に漏洩しても良い答えられるべき返事をも設定され、該システムからあらかじめ合意された通信の方式で管理対象機器（4100）に問い合わせる手段と、管理対象機器（4100）からの返事を受信する手段と、前記受信された返事と前記設定された合意された方式での通信に対する答えられるべき返事とを比較する手段とを備え、比較された結果の真偽によって管理対象機器（4100）の真偽を確認することを特徴とするシステム。
請求項１０から請求項１１のいずれかに記載のシステムにおける前記確認において、
管理対象機器（4100）の使用するドメイン名を管理する複数存在するＤＮＳサーバの内の１のＤＮＳサーバを、管理対象機器（4100）毎に選択して正引き名前問合せをして、管理対象機器（4100）のＩＰアドレスを取得して、管理対象機器（4100）と通信するために前記取得したＩＰアドレスを用いておこなうことを特徴とするシステム。
請求項１０から請求項１２のいずれかに記載のシステムであって、
管理対象機器（4100）の真性確認に失敗した場合に、所定の時間間隔を経過した後、再度請求項１０から請求項１２に記載の確認処理を再度実施することによって、真性の管理対象機器（4100）に到達するか否かを確認することを特徴とするシステム。
管理対象機器（4100）から管理サーバ（2000）に対して、所定の時間間隔でアライブメッセージの送信をおこない、
管理サーバ（2000）では前記アライブメッセージの到着が途切れたことをトリガとして、請求項１０から請求項１３のいずれかに記載のネットワーク管理の方法を実施することを特徴とするシステム。
請求項１４に記載のシステムにおいて、
管理サーバ（2000）では、管理対象機器（4100）からの前記アライブメッセージを受信することによって管理対象機器（4100）のＩＰアドレスの変化にかかわらず管理対象機器（4100）が、どの管理対象機器（4100）であるかを識別するかあるいは管理対象機器（4100）が少なくとも生存していることを確認することを特徴とするシステム。
請求項１０から請求項１５のいずれかに記載のシステムにおいて、
前記真性確認の結果を、所定の対象者に通知することをさらに具備することを特徴とするシステム。
請求項１０から請求項１５のいずれかに記載の確認に後続して、ＳＮＭＰマネージャを用いてするネットワーク管理の方法に接続するために、
請求項１０から請求項１５のいずれかに記載された真性であることが確認された管理対象機器（4100）をネットワーク上で特定する情報を、ＳＮＭＰマネージャを用いてするネットワーク管理の方法に引き渡すことによって動的にＩＰアドレスが変化する管理対象機器（4100）を管理することを特徴とするシステム。
請求項１０から請求項１７のいずれかに記載のシステムを、
計算機もしくはネットワーク接続機器に実現させるためのプログラム。
計算機もしくはネットワーク接続機器であって、ＩＰアドレスの割当てを動的に受けてなる通信ノードもしくは外部ネットワークからは該通信ノードと一体となって参照される通信ノードのいずれかであって、
該通信ノードの記憶装置に第三者に漏洩しても良い任意の情報をカウンターサインもしくは答えるべき返事として保存し、サインもしくはあらかじめ合意された方式での通信に対して前記保存された情報を該記憶装置より読み出し、少なくとも該情報を含めたカウンターサインもしくはあらかじめ合意された方式での通信に対する返事を返信するように構成されることを特徴とする通信ノード。
請求項１９に記載の通信ノードにおいて、
該通信ノードにはホスト名が設定されるものであって、該ホスト名が該通信ノードの記憶装置に保存され、所定のポートへの通信要求を受けた際に、前記保存されたホスト名を該記憶装置より読み出し、少なくとも該ホスト名を含めた文字列を返信するように構成されることを特徴とする通信ノード。
請求項１９に記載の通信ノードにおいて、
ダイナミックＤＮＳによって動的更新されるセンタ側ＤＮＳサーバ（1000）において設定されるホスト名をＦＱＤＮでもって、該通信ノードに読み出し可能な文字列として設定されるものであって、該文字列が該通信ノードの記憶装置に保存され、所定のポートへの通信要求を受けた際に、前記保存された文字列を該記憶装置より読み出し、少なくとも該文字列を含めた文字列を返信するように構成されることを特徴とする通信ノード。
請求項１９から請求項２１のいずれかに記載の通信ノードにおいて、
請求項１９から請求項２１のいずれかに記載の待受けされる所定のポート以外に、該通信ノードの設定変更用のポートあるいは、一般の閲覧に供するためのウェブサービスを提供するウェルノウンなポートのいずれかのポート、あるいはその両方のポートで待受けされる所定のポートを備えるように構成されることを特徴とする通信ノード。
請求項１９から請求項２２のいずれかに記載の通信ノードにおいて、
管理サーバ（2000）からのサインもしくはあらかじめ合意された方式での通信に対して、
管理対象機器（4100）がカウンターサインもしくはあらかじめ合意された方式での通信に対する返事を返信することによって、
管理サーバ（2000）に、管理対象機器（4100）の真偽を判定させることを特徴とする通信ノード。
請求項２３に記載の通信ノードにおいて、
管理対象機器（4100）が管理サーバ（2000）からのサインもしくはあらかじめ合意された方式での通信を受信するまでは、管理サーバ（2000）にアライブメッセージを送信することによって管理対象機器（4100）の変動するＩＰアドレスを通知し、どの管理対象機器（4100）であるかを識別させるとともに、管理対象機器（4100）が少なくとも生存していることを確認させることを特徴とする通信ノード。
請求項１９から請求項２４のいずれかに記載の通信ノードとしての機能を、
計算機もしくはネットワーク接続機器に実現させるためのプログラム。