(57)【特許請求の範囲】
【請求項１】
ユーザ情報とサービスドメインネーム情報とを含むドメインネーム・クエリを出力するクライアントと、
前記クライアントから、前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリを出力するＤＮＳ（domain name system）と、
ユーザ情報別に目的地経路情報を保存しており、前記ＤＮＳから前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリに含まれたユーザ情報を抽出し、前記抽出されたユーザ情報に対応する目的地経路情報と前記クライアントが前記ＤＮＳにドメインネーム・クエリを行う際に前記ＤＮＳが動作しない場合に備えて前記ＤＮＳを代替する前記ＤＮＳと異なる第２ＤＮＳの経路情報とを前記ＤＮＳに提供するデータベースと、
を含み、
前記ＤＮＳは、前記データベースから前記クライアントのドメインネーム・クエリに対応する目的地経路情報と前記第２ＤＮＳの経路情報とを受信して、前記クライアントに送信し、
前記クライアントは、エージェントを含み、
前記エージェントは、前記ＤＮＳにドメインネーム・クエリを送信するとき、前記ドメインネーム・クエリにユーザ情報を追加して前記ＤＮＳに出力し、前記ドメインネーム・クエリに対する応答として前記ＤＮＳから前記目的地経路情報と前記第２ＤＮＳの経路情報とを受信すると、前記目的地経路情報と前記第２ＤＮＳの経路情報とを分離し前記第２ＤＮＳの経路情報をキャッシュするように構成されており、
前記エージェントは、更に、前記ＤＮＳに送信したドメインネーム・クエリに対して前記ＤＮＳが応答しない場合、先行して送信したドメインネーム・クエリに対して受信しキャッシュされた前記第２ＤＮＳの経路情報を用いて、前記第２ＤＮＳにドメインネーム・クエリを出力するように構成されている
ことを特徴とするユーザ情報に基づいたドメインネーム・サービスシステム。
【請求項２】
クライアントから、ユーザ情報とサービスドメインネーム情報とを含むドメインネーム・クエリを受信するクエリ受信部と、
ユーザ情報別に目的地経路情報を保存しており、前記クエリ受信部から受信された前記ドメインネーム・クエリに含まれたユーザ情報を抽出し、前記抽出されたユーザ情報に対応する目的地経路情報と前記クライアントがＤＮＳにドメインネーム・クエリを行う際に前記ＤＮＳが動作しない場合に備えて前記ＤＮＳを代替する第２ＤＮＳの経路情報とを提供する経路提供部と、
前記経路提供部から出力される目的地経路情報と第２ＤＮＳの経路情報とを前記クライアントに送信するクエリ応答部と、
を含む
ことを特徴とするユーザ情報に基づいたドメインネーム・サービスシステム。
【請求項３】
クライアントが、ユーザ情報とサービスドメインネーム情報とを含むドメインネーム・クエリを出力する段階と、
ＤＮＳ（domain name system）が、前記クライアントから前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリを出力する段階と、
データベースが、前記ＤＮＳから前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリに含まれたユーザ情報を抽出する段階と、
前記データベースが、前記抽出されたユーザ情報に対応する目的地経路情報と、前記クライアントが前記ＤＮＳにドメインネーム・クエリを行う際に前記ＤＮＳが動作しない場合に備えて前記ＤＮＳを代替する前記ＤＮＳと異なる第２ＤＮＳの経路情報と、を前記ＤＮＳに提供する段階と、
前記ＤＮＳが、前記クライアントのドメインネーム・クエリに対応する目的地経路情報と第２ＤＮＳの経路情報とを受信して前記クライアントに送信する段階と、
前記クライアントが、前記ＤＮＳから前記目的地経路情報と第２ＤＮＳの経路情報とを受信する段階と、
を含み、
前記クライアントに含まれるエージェントが、前記ＤＮＳにドメインネーム・クエリを送信するとき、前記ドメインネーム・クエリにユーザ情報を追加して前記ＤＮＳに出力する段階と、
前記エージェントが、前記目的地経路情報と前記第２ＤＮＳの経路情報とを受信すると、前記目的地経路情報と前記第２ＤＮＳの経路情報とを分離し前記第２ＤＮＳの経路情報をキャッシュする段階と、
前記エージェントが、前記ＤＮＳに送信したドメインネーム・クエリに対して前記ＤＮＳが応答しない場合、先行して送信したドメインネーム・クエリに対して受信しキャッシュされた前記第２ＤＮＳの経路情報を用いて、前記第２ＤＮＳにドメインネーム・クエリを出力する段階と、
を更に含む
ことを特徴とするユーザ情報に基づいたドメインネーム・サービス方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドメインネーム・サービスに係り、特に、ユーザ別に目的地経路を分配して制御して安定して回線を管理し、サービスに利用されるサーバ及び装置の非正常的な動作中でも、ユーザにサービスの連続性を維持させる、ユーザ情報に基づいた、ドメインネーム・システム及びドメインネーム・サービス方法に関する。
【背景技術】
【０００２】
インターネットは、個体を区分するために、ＩＰアドレスを利用する。しかし、人は、アドレスよりは名称を使用しようとする傾向がある。従って、名称をアドレスに変え、かつアドレスを名称にするシステムが必要である。
【０００３】
かような変換システムは、名称及びアドレス（全ての名称とアドレスは、一意（unique）である）をマッピングさせ、一つを知っていれば、他の一つを知らせる形態によってなるが、インターネットの規模がだんだんと大きくなりながら、全ての名称及びアドレスを単一コンピュータに保存して知らせることが不可能になった。
【０００４】
これに対する解決策として現在使用されいるシステムは、非常に多くの情報を小さい部分に分けた後、互いに異なるコンピュータに各部分を分けて保存するドメインネーム・システム（ＤＮＳ）である。
【０００５】
ドメインネームは、「.」で区切られる多くのラベルを有するが、各ラベルは、最大６３個の文字からなる。言い換えれば、完全なドメインネームは、「.」で区切られる複数のラベルの連続である。
【０００６】
例えば、「service.com」は、serviceラベル、comラベル及びNULLラベルからなる（ドメインネームの終わりには、常にNULLラベルが含まれる）。
【０００７】
名称をアドレスに変換したり、あるいはアドレスを名称に変換することを名称アドレス解析（name-address resolution）という。
【０００８】
図１は、ドメインネーム解析過程に係わる一例を示したものであり、図１を参照し、ドメインネームの一例として、「www.service.com」ドメインを解析する過程を説明する。
【０００９】
一般的にユーザは、ブラウザを介して、ドメインネームにサービスを要請するが、アドレスを名称に変換することを所望するホストは、リゾルバ（resolver）と呼ばれるＤＮＳクライアントを呼び出す。リゾルバは、解析要求を送るために、最も近いＤＮＳサーバに接続する。ＤＮＳサーバは、ホストのＯＳ（operating system）上に設定され、本明細書では、ＤＮＳサーバを公開ＤＮＳと称する。
【００１０】
解析は、ドメインネームの後尾から始まる。ドメインネームの最後尾は、常にNULLラベル１１５が存在し、ドメインネームの終わりには、常にドット（.）が存在する。
【００１１】
NULLラベル１１５は、ルートＤＮＳサーバ１３０を意味し、ユーザのドメイン要請メッセージを受けた公開ＤＮＳ１２５は、設定されたルートサーバに「www.service.com」のＩＰアドレスを要請する。
【００１２】
ルートＤＮＳサーバ１３０は、当該ドメインに係わるＩＰアドレス情報を有していないのであれば、comラベル１１０に係わる情報を有したcomネームサーバ１３５のアドレスを応答する。
【００１３】
公開ＤＮＳ１２５は、応答されたcomネームサーバ１３５に、「www.service.com」のＩＰアドレスを要請し、comネームサーバ１３５は、serviceラベル１０５の情報（権限）を有したＤＮＳサーバ１４０を応答する。
【００１４】
また、公開ＤＮＳ１２５は、応答されたＤＮＳサーバに、「www.service.com」に係わる解析を要請する。要請を受けたＤＮＳサーバは、serviceの情報を有したゾーンファイル（zone file）１４５内部に、「www」に係わるマッピングされたＩＰアドレス情報があるので、ＩＰアドレス（200.1.1.1）を応答する。
【００１５】
応答された公開ＤＮＳサーバ１２５は、クライアントリゾルバ（resolver）１２０に「200.1.1.1」を応答し、クライアントリゾルバ１２０が応答メッセージを解析した後、解析を要求したクライアント・プログラムにその値を渡す。
【００１６】
このように、ＤＮＳサーバがドメインに係わる権限を有したＤＮＳサーバのＩＰを渡し、質疑を反復して試みる方式を反復的（iterative）解析という。
【００１７】
そして、ＤＮＳサーバがzoneファイルにおいて、ドメインネームとマッチングされたＩＰアドレスを応答するが、初期には、アドレスに多くの変更が加えられるか予測することができなかった。
【００１８】
ドメインネームとマッピングされたＩＰアドレス情報を変更しなければならないとき、それを管理者が受動的に一つ一つ変更することは、大変に厄介である。その解決策として、ＤＮＳメインファイルを自動的に更新させるが、それを動的（dynamic）ＤＮＳと呼ぶ。
【００１９】
しかし、ユーザベースの情報提供のためには、ＤＮＳ要請メッセージからユーザ情報を収集しなければならないが、従来のＤＮＳ要請メッセージには、その情報が極めて制限的である。また、ＤＮＳサーバのメインマスターファイルの修正、すなわち、マッピングされた情報の追加、除去及び変更が頻繁であり、同期化を常に維持しなければならないサービスの場合、従来の静的ＤＮＳでは、機能を完壁に遂行し難い。
【００２０】
それだけでなく、分散サービス拒否攻撃（Ｄ−ＤＯＳ：distributed denial-of-service attack）は、インターネット上で多数のシステムが協力し、１つの標的システムを攻撃することにより、サービス拒否（ＤＯＳ）を起こさせることをいう。標的システムは、氾濫するメッセージによって、結局システム稼動が止まり、善意のユーザは、まさにそのシステムからサービスを受けることができないという事態になる。すなわち、目標システムの特定資源や、使用が可能な回線トラフィックを独占し、善意のユーザが目標システムのサービスを受けることができないのである。
【００２１】
そして、ロードバランシング（load balancing）とは、並列に運用されている機器間で、負荷が均等になるように処理を分散して割り当てることをいう。ロードバランシングは、コンピュータ内の多くのマイクロプロセッサに均等に処理を付与したり、あるいは、接続要求をネットワーク上の余力があるサーバに回送するような多様な分野で幅広く利用されている概念である。ロードバランシングを効率的に遂行するためには、各機器の負荷を継続的に測定する必要があるが、それを正確に適用するためには、ロードバランシングの制御自体が大きい負荷を発生させる。従って、実際に利用されているロードバランシングは、正確度と負荷とのバランスを取るようになっており、それよりももっと効率的な手段を求めるために研究が続けられている。
【００２２】
ところで、帯域幅攻撃の場合、装置（ＩＰＳ（intrusion prevention system）、サーバ）の高度化だけでは攻撃を防ぎにくい。ネットワーク帯域幅攻撃の場合、ゾンビＰＣ（personal computer）のネットワーク性能と合わさって攻撃が強まる。ゾンビＰＣで利用するネットワークとＰＣ性能がすぐれるほど攻撃が強まるが、以前のＡＤＳＬ（asymmetric digital subscriber line）基準で，１００Ｇｂ／ｓの攻撃を作るためには、１０万台のゾンビＰＣが必要であったが、最近普及された光ＬＡＮ（local area network）（アップロード１００Ｍｂ／ｓ）の場合、１，０００台のゾンビＰＣでも可能である。そして、これから登場するギガビット（giga bit）ホームＬＡＮが普及される場合、１００台のゾンビＰＣだけでも、９０Ｇｂ／ｓの帯域幅攻撃が可能である。これからもＩＰＳ装置の高度化は進められるが、帯域幅攻撃を防ぐのは、現実的に非常に困難である。
【００２３】
また、サーバのＩＰアドレスが露出されて公開される場合、悪意的なユーザによって，攻撃対象になりもする。ＤＮＳサーバの場合、ドメイン管理機関を介して、ネームサーバ情報が公開されるために、ＩＰアドレス露出が不可避である。また、ＤＮＳサーバ自体が使用不可能になる場合、当該ＤＮＳで管理したドメインのサービス自体が不可能である。
【発明の概要】
【発明が解決しようとする課題】
【００２４】
本発明が解決しようとする課題は、前述の問題点を解決するためのものであり、ユーザ別に目的地経路を分配して制御して安定して回線を管理し、サービスに利用されるサーバ及び装置の非正常的な動作中でも、ユーザにサービスの連続性を維持させることができる、ユーザ情報に基づいたドメインネーム・システム及びドメインネーム・サービス方法を提供するものである。
【課題を解決するための手段】
【００２５】
本発明によるユーザ情報に基づいたドメインネーム・サービスシステムは、ユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリを出力するクライアントと、前記クライアントから、前記ドメインネーム・クエリを受信するＤＮＳと、前記ＤＮＳから、前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリに含まれたユーザ情報を抽出し、前記ユーザ情報別に目的地経路情報を異ならせて提供するデータベースと、を含み、前記クライアントは、前記データベースから出力されるユーザ情報別の目的地経路情報を、前記ＤＮＳを介して受信することを特徴とする。
【００２６】
そして、前記データベースは、ユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、前記ＤＮＳが動作しないとき前記ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報または迂回プロキシ経路情報、あるいはゲートウェイ経路情報と、を提供することが望ましい。前記クライアントは、ドメイン解析のために設定されたＤＮＳに、ＤＮＳ要請メッセージを伝送するクライアントリゾルバと、前記ＤＮＳ要請メッセージにユーザ情報を追加し、前記ＤＮＳにクエリを出力するエージェントと、を含むことが望ましい。
【００２７】
本発明によるユーザ情報に基づいたドメインネーム・サービスシステムは、クライアントからユーザ情報と、サービスドメインネーム情報とを含む前記ドメインネーム・クエリを受信するＤＮＳと、前記ＤＮＳから、前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリに含まれたユーザ情報を抽出し、前記ユーザ情報別に、目的地経路情報を異ならせて提供するデータベースと、を含み、前記ＤＮＳは、前記データベースから出力されるユーザ情報別の目的地経路情報を前記クライアントに伝送することを特徴とする。そのとき、前記データベースは、ユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、前記ＤＮＳが動作しないとき、前記ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することが望ましい。
【００２８】
本発明によるユーザ情報に基づいたドメインネーム・サービスシステムは、クライアントからユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリを受信するクエリ受信部；前記クエリ受信部から受信された前記ドメインネーム・クエリに含まれたユーザ情報を抽出し、前記ユーザ情報別に、目的地経路情報を異ならせて提供する経路提供部；及び前記経路提供部から出力されるユーザ情報別の目的地経路情報を前記クライアントに伝送するクエリ応答部を含むことを特徴とする。前記経路提供部はユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、ＤＮＳが動作しないとき、前記ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することが望ましい。
【００２９】
本発明によるユーザ情報に基づいたドメインネーム・サービス方法は、クライアントがユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリを出力する段階と、ＤＮＳが前記クライアントから、前記ドメインネーム・クエリを受信する段階と、前記ＤＮＳから、前記ドメインネーム・クエリを受信し、前記ドメインネーム・クエリに含まれたユーザ情報を抽出する段階と、前記抽出されたユーザ情報によって、目的地経路情報を異ならせて提供する段階と、を含む。前記クライアントは、前記データベースから出力されるユーザ情報別の目的地経路情報を、前記ＤＮＳを介して受信する段階をさらに含むことが望ましい。
【００３０】
そして、プロセッサによって実行するプログラムを記録したプロセッサによって読取り可能な記録媒体を提供する。
【発明の効果】
【００３１】
本発明によるユーザ情報に基づいたドメインネーム・サービスシステムによれば、ユーザ別に目的地経路を分配して制御して安定して回線を管理し、サービスに利用されるサーバ及び装置の非正常的な動作中でも、ユーザにサービスの連続性を維持させることができる。
【００３２】
また、ユーザ別に目的地経路を分配及び制御することにより、Ｄ−ＤＯＳによる帯域幅攻撃を防ぐことができる。そして、攻撃または障害を受けたプロキシ、ゲートウェイなどの装置を割り当てられたユーザをデータベースで検索し、非正常的な攻撃または障害を誘発したユーザを直ちに認知することができ、追加的な措置を下すことができる。
【図面の簡単な説明】
【００３３】
【図１】ドメインネーム解析過程に係わる一例を示した図面である。
【図２】本発明によるユーザ情報に基づいたドメインネーム・サービスシステムの構成に係わる一実施形態を図示した図面である。
【図３】クライアントのＤＮＳ解析要請過程に使用されるクライアントＰＣまたは装置に係わる詳細構成をブロック図で示した図面である。
【図４】クライアントのＤＮＳ解析要請過程に使用されるクライアントＰＣまたは装置に係わる詳細構成をブロック図で示した図面である。
【図５】本発明によるユーザ情報に基づいたドメインネーム・サービスシステムの構成に係わる他の実施形態を図示した図面である。
【図６】本発明によるユーザ情報に基づいたドメインネーム・サービスシステムにおいて、クライアントとデータベースとのデータ伝送過程に係わる一例について説明するためのシステム構成をブロック図で示した図面である。
【図７】クライアントと、クライアントがサービスを受けることを所望するホストサーバとのサービス過程を示した図面である。
【図８】ＤＮＳを利用したプログラム及び装置情報提供において、エージェントによる情報獲得過程を示した図面である。
【図９】ＤＮＳを利用したプログラム及び装置情報提供において、ユーザによる情報獲得過程を示した図面である。
【図１０】ＤＮＳ迂回経路制御に係わる一実施形態を示した図面である。
【図１１】ＤＮＳ迂回経路制御に係わる他の実施形態を示した図面である。
【図１２】本発明による、ユーザ情報に基づいたドメインネーム・サービス方法に係わる一実施形態を示したフローチャートである。
【図１３】本発明によるユーザ情報に基づいたドメインネーム・サービス方法に係わる一例を示したフローチャートである。
【発明を実施するための形態】
【００３４】
以下、添付された図面を参照し、本発明の望ましい実施形態について詳細に説明する。それに先立ち、本明細書に記載された実施形態と、図面に図示された構成は、本発明の望ましい一実施形態に過ぎず、本発明の技術的思想をいずれも代弁するものではないので、本出願時点において、それらを代替することができる多様な均等物と変形例とがありうるということを理解しなければならない。
【００３５】
図２は、本発明によるユーザ情報に基づいたドメインネーム・サービスシステムの構成に係わる一実施形態を図示したものであり、そのドメインネーム・サービスシステムは、クライアント２００、ＤＮＳ（domain name system）２２０及びデータベース２４０を含んでなる。
【００３６】
クライアント２００は、ユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリをＤＮＳに伝送する。そして、クライアント２００は、データベース２４０から出力されるユーザ情報別の目的地経路情報を、ＤＮＳ２２０を介して受信する。
【００３７】
ＤＮＳ２２０は、クライアント２００から、ドメインネーム・クエリを受信する。
【００３８】
データベース２４０は、ＤＮＳ２２０から、ドメインネーム・クエリを受信し、ドメインネーム・クエリに含まれたユーザ情報を抽出し、ユーザ情報別に、目的地経路情報を異ならせて提供する。具体的には、データベース２４０は、ユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、ＤＮＳが動作しないとき、ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することが望ましい。
【００３９】
クライアント２００は、ドメイン解析のために設定されたＤＮＳに、ＤＮＳ要請メッセージを伝送するクライアントリゾルバ（図示せず）、及びＤＮＳ要請メッセージにユーザ情報を追加し、ＤＮＳにクエリを出力するエージェント（図示せず）を含んでもよい。
【００４０】
一方、本発明によるユーザ情報に基づいたドメインネーム・サービスシステムは、クライアントとは別個に、ＤＮＳ２２０及びデータベース２４０を含んでもなる。そのとき、ＤＮＳ２２０は、クライアント２００から、ユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリを受信する。そしてデータベース２４０は、ＤＮＳ２２０から、ドメインネーム・クエリを受信し、当該ドメインネーム・クエリに含まれたユーザ情報を抽出し、ユーザ情報別に、目的地経路情報を異ならせて提供することもできる。
【００４１】
ここで、ＤＮＳ２２０は、データベース２４０から出力されるユーザ情報別の目的地経路情報をクライアント２２０で伝送する。そして、データベース２４０は、ユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、ＤＮＳが動作しないとき、ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することが望ましい。
【００４２】
図３及び図４は、クライアント２００のＤＮＳ解析要請過程に使用されるクライアントＰＣ（personal computer）または装置に係わる詳細構成をブロック図で示したものである。
【００４３】
本発明によるクライアント２００は、図３及び図４に図示されているように、ユーザプログラム３００，４００、リゾルバ３１０，４２０、エージェント３２０，４１０、及びキャッシュ３３０，３４０，４３０，４４０を含んでなる。そして、図１３は、本発明によるユーザ情報に基づいたドメインネーム・サービス方法に係わる一例を示したものである。
【００４４】
図３、図４及び図１３を参照し、本発明によるユーザ情報に基づいたドメインネーム・サービスシステム及び方法に係わるさらに具体的な実施形態について説明する。
【００４５】
ユーザ・プログラム３００は、リゾルバ３１０にドメインネーム解析を要請する（Ｓ１３００段階）。リゾルバ３１０は、ドメインネーム解析のために設定されたＤＮＳに、ＤＮＳ要請メッセージを伝送する（Ｓ１３１０段階）。そのとき、エージェント３２０は、ＤＮＳ要請が発生されれば、Question sectionのクエリ名称（query name）領域にユーザ情報を追加し、ＤＮＳ要請メッセージを公開ＤＮＳサーバ３５０に伝送する。
【００４６】
公開ＤＮＳサーバ３５０は、クエリ名称の情報を、要請メッセージの情報（権限）を有したＤＮＳサーバ３６０に伝送する。情報（権限）を有したＤＮＳサーバ３６０は、既設定のデータベース３７０に問い合わせる（Ｓ１３４０段階）。ＤＮＳ３６０は、要請メッセージを、データベースにおいて、追加、修正及び抽出する機能を遂行する。データベース３７０は、マッチングされた情報を応答する（Ｓ１３５５段階）。ここで、データベース３７０は、エージェント３２０が追加したユーザ情報を抽出し、ユーザ情報別に、目的地経路情報、例えば、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することができる。
【００４７】
ＤＮＳ３６０は、データベース３７０から受けた応答情報を公開ＤＮＳ３５０に伝達する（Ｓ１３６５段階）。公開ＤＮＳ３５０が、ＤＮＳ３６０から受けた応答情報を、エージェント３２０に伝達すれば（Ｓ１３７０段階）、エージェント３２０は、応答メッセージ内容を確認した後、ＤＮＳ解析を要請したリゾルバ３１０に伝送する（Ｓ１３７５段階）。リゾルバ３１０は、応答メッセージを分析してキャッシングした後、ユーザ・プログラム３００に伝達すれば（Ｓ１３８０段階）、ユーザ・プログラムは、応答されたアドレスに接続してサービスを利用する（Ｓ１３８５段階）。ここで、リゾルバ３１０は、応答メッセージに、迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報があれば、それをキャッシング（caching）することができる。
【００４８】
そして、図３のリゾルバ３１０とエージェント３２０は、図４のように、互いに位置を変えて位置することもできる。すなわち、エージェント４１０は、ＤＮＳクエリをリゾルバ４２０に伝送し、リゾルバ４２０から出力される応答メッセージをエージェント４１０に伝送することもできる。
【００４９】
一方、図５は、本発明によるユーザ情報に基づいたドメインネーム・サービスシステムの構成に係わる他の実施形態を図示したものであり、本発明によるドメインネーム・サービスシステムは、クエリ受信部５００、経路提供部５２０及びクエリ応答部５４０を含んでもなる。
【００５０】
クエリ受信部５００は、クライアント５５０から、ユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリを受信する。
【００５１】
経路提供部５２０は、クエリ受信部５００から受信されたドメインネーム・クエリに含まれたユーザ情報を抽出し、ユーザ情報別に、目的地経路情報をクエリ応答部５４０で提供する。経路提供部５２０は、ユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、ＤＮＳが動作しないとき、ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することが望ましい。
【００５２】
クエリ応答部５４０は、経路提供部５２０から出力されるユーザ情報別の目的地経路情報をクライアント６５０に伝送する。
【００５３】
前述のクエリ受信部５００、経路制御部５２０及びクエリ応答部５４０は、１つのシステムにも具現されて設置され、経路制御部５２０を別途の装置、例えば、データベースを利用して具現して設置することもできる。
【００５４】
図６は、本発明によるユーザ情報に基づいたドメインネーム・サービスシステムにおいて、クライアントとデータベースとのデータ伝送過程に係わる一例について説明するためのシステム構成をブロック図で示したものである。
【００５５】
エージェント６２０は、ユーザの情報を収集し、ユーザのプログラム（ブラウザ）のＤＮＳ解析要請時、当該メッセージにユーザ情報を含める機能を遂行するプログラムまたは装置である。
【００５６】
ＤＮＳサーバ６４０は、ＤＮＳ要請メッセージのホストを、既設定のデータベース６５０にマッチングされた情報を要請し、データベース６５０から応答された情報を公開ＤＮＳを介してエージェントに伝送する。ＤＮＳ１（６４０）は、ネームサーバ情報が公開されたＤＮＳサーバであり、図１０のＤＮＳ１（１０３０）と同一である。そして、図１０のＤＮＳ２（１０７０）は、ネームサーバ情報が公開されていないＤＮＳサーバをいい、ＤＮＳ１と同一のデータベースを利用して同一の役割を行う。
【００５７】
データベース６５０，１０４０は、ドメインネーム・システムのサービスまたは管理に利用されるデータが保存されており、ユーザ別に他の目的地経路を設定したものを保存している。
【００５８】
図６に図示されたユーザ情報に基づいたドメインネーム・サービスシステムは、次のような条件を有すると仮定する。
【００５９】
１）ＤＮＳ１（６４０）を介して、「service.com」というドメインをユーザ情報に基づいた経路制御を行う。
２）ユーザは、ブラウザなどのプログラムを介してservice.comドメインを利用するウェブサーバに接続することを所望する。
３）service.comドメインは、前もって登録されている。
４）データベース６５０には、クライアントの情報別にservice.comのホストサーバに行くためのプロキシあるいはゲートウェイの経路情報（ＩＰアドレス、ドメインなど）、ゲートウェイの経路情報（ＩＰアドレス、ドメインなど）、またはホストサーバ経路情報（ＩＰアドレス、ドメインなど）が保存されている。
５）クライアント情報としては、ＩＰアドレスだけではなく、Ｍａｃ ＩＤ（identification）、Ｌｏｇｉｎ ＩＤなどユーザを認証することができる多くの情報が単独あるいは複合的に使用されもするが、図６では、ＩＰアドレスのみを利用すると仮定する。
６）クライアントの公認ＩＰは、100.100.100.1と仮定する。
７）目的地（service.comのプロキシまたはゲートウェイ）ＩＰアドレスは、200.0.0.1と仮定する。
【００６０】
ＤＮＳを利用したユーザベースの目的地経路提供は、次のようになされる。まず、ユーザの要請をエージェントが伝達される過程は、次の通りである。まず、ユーザは、クライアント・プログラム６００を介して、ドメイン名称（「service.com」）に係わるＩＰアドレスを、ＤＮＳクライアントであるリゾルバ６１０に要請する。要請されたリゾルバ６１０は、当該ドメインネームを、運用体制（ＯＳ）に設定されたＤＮＳサーバアドレスにＤＮＳ要請メッセージを伝送するが、既インストールのエージェント６２０は、ＤＮＳ要請メッセージを次の通り変調する。
【００６１】
変更前：「service.com」
変更後：「100_100_100_1.service.com」
【００６２】
ここで、「100_100_100_1」は、クライアントのＩＰアドレスを、分かりやすいように表記した内容であり、該当情報は、暗号化されていないクライアントＩＰアドレスを意味する。
【００６３】
エージェント６２０が変更されたメッセージを、運用体制（ＯＳ）に設定されたＤＮＳサーバアドレスに伝送する。
【００６４】
公開ＤＮＳ６３０は、「100_100_100_1.service.com」ドメインを解析するために、rootネームサーバに解析要請を送り、rootネームサーバは、「com」ネームサーバのアドレスを知らせる。「com」ネームサーバは、「service.com」のドメイン情報が登録されたＤＮＳサーバのアドレスをさらに知らせる。comネームサーバは、service.comドメイン情報が登録されたＤＮＳサーバのアドレスをさらに知らせる。ＤＮＳサーバは、「100_100_100_1.service.com」を解析するが、既設定のデータベース６５０に当該ドメイン内容を質疑する。
【００６５】
データベース６５０は、当該データにマッチングされた情報ＩＰアドレス：200.0.0.1を、ＤＮＳネームサーバにさらに応答する。
【００６６】
もしマッチングされた情報がなければ、ＤＮＳ１（６４０）は、既設定のポリシーによって、クライアント100_100_100_1に係わる情報を、データベース６５０に挿入（insert）する。
【００６７】
ＤＮＳ１（６４０）は、伝達された情報、すなわち、目的地経路を公開ＤＮＳ６３０に応答する。公開ＤＮＳ６３０は、エージェント６２０にドメイン解析結果を応答する。
【００６８】
エージェント６２０は、応答メッセージを分析し、応答された情報がＩＰアドレスであるならば、キャッシングする。その後、ドメインネーム解析結果をリゾルバ６１０に応答する。
【００６９】
リゾルバ６１０は、ドメイン解析を要請したクライアント・プログラム６００に当該経路を応答する。クライアント・プログラム６００は、目的地ＩＰアドレスが200.0.0.1であるサーバに接続する。
【００７０】
図７は、クライアントと、当該クライアントがサービスを受けることを所望するホストサーバとのサービス過程を示したものである。
【００７１】
図７に図示されているように、クライアント７００は、ＤＮＳクエリを出力すれば、エージェント７１０が、当該ＤＮＳクエリにユーザ情報を追加し、公開ＤＮＳ７２０を介して、ＤＮＳ１（７３０）に、ユーザ情報とドメインネーム情報とを含むドメインネーム・クエリを伝送する。それにより、ＤＮＳ１（７３０）は、ドメインネーム・クエリからユーザ情報を抽出し、抽出されたユーザ情報に該当する目的地経路情報、例えば、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を公開ＤＮＳ７２０を介して、エージェント７１０に伝達する。エージェント７１０は、クライアント７００に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報を伝達すれば、クライアント７００は、自体の情報を基に事前に割り当てられたホストサーバ、プロキシまたはゲートウェイ７４０を介して、目的地であるホストサーバ７５０にアクセスする。
【００７２】
図８は、ＤＮＳを利用したプログラム及び装置情報提供において、エージェントによる情報獲得過程を示している。
【００７３】
プログラム及び装置が、自らＤＮＳ１（８３０）に質疑を伝送して情報を提供される方式である。エージェント８１０が、周期的にあるいは特定イベント発生時に、ＤＮＳに装置情報が含まれた、例えば、プログラムバージョン、設定バージョンのようなＤＮＳ質疑を要請し、データベースから情報を提供される。
【００７４】
ＤＮＳ質疑は、テキスト方式で要請することができ、テキスト方式だけではなく、ＤＮＳ問い合わせレコードの質疑種類（query type）に適用される全ての形式で応答可能である。
【００７５】
エージェントは、１０秒ごとに１回ずつ自体のプログラムバージョンが含まれたＤＮＳ質疑「configversion00002.service.com」をテキスト形式で公開ＤＮＳに伝送し、「service.com」の情報を有したＤＮＳ１サーバに要請を送れば、ＤＮＳ１サーバは、データベースでマッチングされた情報をテキスト形式で応答する。
【００７６】
この応答メッセージに含まれた情報を適用または加工し、エージェントは、二次的な情報の利用が可能である。
【００７７】
図９は、ＤＮＳを利用したプログラム及び装置情報提供において、ユーザによる情報獲得過程を示したものであり、図８のエージェントによる情報獲得と類似しているが、クライアント９００の要請によって、エージェント９１０及び公開ＤＮＳ９２０を経て、ＤＮＳ１（９３０）に質疑を伝送して情報を提供される。
【００７８】
一方、図１０は、ＤＮＳ迂回経路制御に係わる一例を示したものであり、ＤＮＳ迂回経路制御は、次の通りなされる。
【００７９】
ＤＮＳは、ネームサーバ情報、例えば、ＤＮＳサーバのＩＰ及びその他登録情報を公開することによって、直接的な攻撃、例えば、（Ｄ−ＤＯＳ：distributed denial-of-service attack）攻撃に露出される。
【００８０】
ＤＮＳ１（１０３０）は、非正常的な状況、例えば、ＤＮＳのネームサーバ情報公開による悪意的ユーザの攻撃、または自体ＤＮＳサーバの自体エラーなどにより、正常なＤＮＳサービスが不可能である場合、ＤＮＳ２（１０７０）でＤＮＳ要請経路を制御し、エージェント１０１０がインストールされたユーザに、ＤＮＳサービスの連続性を維持させるが、かような機能をＤＮＳ迂回経路制御という。
【００８１】
すなわち、ＤＮＳ迂回経路制御とは、ＤＮＳ１（１０３０）が使用不可能であるとき、同一の機能、例えば、同一のデータベースを利用する他のＤＮＳ２（１０７０）で経路を制御するのである。
【００８２】
迂回経路制御の正しい使用例を挙げるために、サービス状況を二つに分けて説明する。
【００８３】
第１の状況は、正常なサービス過程であり、第２の状況は、非常時、すなわち、正常なサービス過程時に使用されるＤＮＳ１（１０３０）が使用不可能であるときのサービス過程である。
【００８４】
正常なサービス過程は、ＤＮＳサービスモデルで表現された図６、図７と同一である。ただし、１つの情報が追加して運用されるが、それは、非常時に、ＤＮＳ２（１０７０）の情報を有したプロキシあるいはゲートウェイの経路情報、またはＤＮＳ２の経路情報、すなわち、公開ＤＮＳと同一の役割を担当するプロキシあるいはゲートウェイのＩＰアドレス情報、またはＤＮＳ２のＩＰアドレス情報である。
【００８５】
クライアントのＤＮＳ解析要請によって、リゾルバがＤＮＳ要請パケットを生成し、エージェント１０１０がこのメッセージを変調した後、公開ＤＮＳ１０２０を介して、ＤＮＳ１（１０３０）に要請する。ＤＮＳ１（１０３０）は、当該ドメイン情報に含まれたユーザ情報を基に、目的地またはその経路に係わる情報を提供するが、そのとき、ユーザ情報に基づいたＤＮＳ２（１０７０）の経路情報、例えば、プロキシあるいはゲートウェイのＩＰアドレスあるいはドメインネームを、同時にまたは順次に、ＤＮＳ応答メッセージに含めて伝送する。
【００８６】
公開ＤＮＳ１０２０は、応答されたメッセージをエージェント１０１０にさらに応答し、エージェント１０１０は、当該ＤＮＳ応答メッセージを分析しつつ、ここで２つの状況に分けられる。
【００８７】
第１は、正常な応答メッセージである場合である。エージェント１０１０は、ＤＮＳ応答メッセージにおいて、ＤＮＳ要請に対する応答と、迂回ＤＮＳ情報とに分離した後、迂回情報（ＤＮＳ２情報）は、クライアント１０００のメモリにキャッシュ（caching）する。もしすでにキャッシュされた情報があるならば変更し、ＤＮＳ応答メッセージは、リゾルバを介して、クライアント１０００に伝達し、クライアント・プログラムは、伝達された経路を介して、所望するサービスを利用する。
【００８８】
第２は、非正常な応答メッセージである場合である。エージェント１０１０は、ＤＮＳ１（１０３０）が正常なサービスが不可能であると判断し、キャッシングされた迂回情報、例えば、プロキシあるいはゲートウェイのＩＰアドレスあるいはドメインネームに、ＤＮＳ要請メッセージを伝送する。
【００８９】
プロキシまたはゲートウェイ１０６０は、既設定のＤＮＳ２（１０７０）、または同一の役割を行うように具現された装置に、ドメインネームにマッチングされた情報を要請し、応答を受けてエージェント１０１０に伝送する。そのとき、ＤＮＳ要請メッセージは、最初に伝送されたＤＮＳ要請メッセージと同一であり、応答もまた同じデータベースを参照するために同一である。ＵＤＰ（user datagram protocol）通信だけではなく、ＴＣＰ（transmission control protocol）通信も支援され、プロトコルの変調も可能である。ただし、迂回への経路は、第３ＤＮＳ、例えば、図面上では存在しないＤＮＳ３の経路情報を伝送する。
【００９０】
すなわち、ＤＮＳは、ドメインネームに係わる情報だけではなく、ＤＮＳ迂回情報を同時に提供し、エージェント１０１０は、迂回情報をキャッシングして保存していて、ＤＮＳ１（１０３０）利用が不可能なとき、当該迂回アドレスを介して、ネームサーバ情報が露出されていない他のＤＮＳ２（１０７０）を利用して、ＤＮＳサービスを受ける。
【００９１】
図１１は、ＤＮＳ迂回経路制御に係わる他の例を示したものであり、図１０において、公開ＤＮＳ１０２０及びプロキシまたはゲートウェイ１０６０がない場合を示したものである。クライアント１１１０、エージェント１１１０、ＤＮＳ１（１１２０）、データベース１１３０、キャッシュ１１４０及びＤＮＳ２（１１５０）は、図１０のエージェント１０１０、ＤＮＳ１（１０３０）、データベース１０４０、キャッシュ１０５０及びＤＮＳ２（１０７０）とその機能が同一である。
【００９２】
また、図１０の公開ＤＮＳ１０２０、及びプロキシまたはゲートウェイ１０６０のうちいずれか一つだけがなくとも、図１０で説明したＤＮＳ迂回経路制御が可能である。
【００９３】
一方、図１２は、本発明による、ユーザ情報に基づいたドメインネーム・サービス方法に係わる一実施形態を示したものである。
【００９４】
図２と図１２とを参照すれば、まず、クライアント２００が、ユーザ情報と、サービスドメインネーム情報とを含むドメインネーム・クエリをＤＮＳ２２０に伝送する（Ｓ１２００段階）。ＤＮＳ２２０は、クライアント２００から、ドメインネーム・クエリを受信し、データベース２４０に伝達する（Ｓ１２１０段階）。データベース２４０は、ＤＮＳ２２０から、ドメインネーム・クエリを受信し、当該ドメインネーム・クエリに含まれたユーザ情報を抽出し、ユーザ情報によって、目的地経路情報を異ならせて提供する（Ｓ１２２０段階）。ここで、目的地経路提供は、ユーザ情報別に、ホストサーバ経路情報、またはプロキシあるいはゲートウェイの経路情報と、ＤＮＳが動作しないとき、ＤＮＳの代わりに使用可能な迂回ＤＮＳサーバ経路情報、または迂回プロキシあるいはゲートウェイの経路情報と、を提供することが望ましい。そして、クライアント２００は、データベース２４０から出力されるユーザ情報別の目的地経路情報を、ＤＮＳ２２０を介して受信する（Ｓ１２３０段階）。
【００９５】
前述のように、本発明によるユーザ情報に基づいたドメインネーム・サービスシステム及び方法は、Ｄ−ＤＯＳ攻撃のような外部からの攻撃がある場合、各ユーザごとに異なるホスト情報を応答し、攻撃者と一般ユーザとを分離する。そのためにクライアントがドメインネーム解析を要請すればユーザ情報を共に伝送するためのプログラム及び装置を利用することができる。
【００９６】
そして、攻撃の対象になるサーバのＩＰアドレスを露出させず、ＤＮＳサーバが使用不可能になった場合、臨時的にＩＰアドレスが露出されないＤＮＳを、ユーザ別にまたはユーザが属したグループ別に異なるように利用することができる迂回路を提供する。そのため、にＤＮＳサーバは、ドメイン情報をzoneファイルではないデータベースを介して管理する。データベースは、ＤＮＳの内部または外部に存在する。また、ドメインを登録するとき、ＴＴＬ（time to live）を最低値に設定し、キャッシュされないようにする。
【００９７】
一方、前述の本発明によるユーザ情報に基づいたドメインネーム・サービスシステム及び方法で使用される詳細的なデータフォーマットは、次の通りである。
【００９８】
まず、クライアントがＤＮＳメッセージのデータフォーマットは、次の通りである。
【００９９】
【表１】
0005976232.tif 000002
【０１００】
ＤＮＳメッセージデータ・フォーマットは、ＯＳＩ（open systems interconnection）参照モデルの下位階層ヘッダが含まれたデカプセル化される前のＤＮＳメッセージである。
【０１０１】
下位階層のヘッダを介して、断片的なユーザ、すなわち、ＤＮＳメッセージを要請したクライアント情報を知ることができるが、例えば、Ｍａｃヘッダを介して、当該パケットを送信する側のＭａｃアドレスが分かり、ＩＰヘッダでは、パケットの出発地アドレス、すなわち、ソースアドレスが分かり、ＴＣＰ／ＵＤＰヘッダを介して使用されたポートを知ることができる。
【０１０２】
しかし、図１で説明したように、現在使用されるドメインネーム・システム上、ＤＮＳが受信するパケットの出発地は、ユーザ（クライアント）の情報ではない公開ＤＮＳの情報であるのである。
【０１０３】
そして、ＤＮＳ要請メッセージとＤＮＳ応答メッセージとのフォーマットは、次の通りである。
【０１０４】
【表２】
0005976232.tif 000003
【０１０５】
【表３】
0005976232.tif 000004
【０１０６】
エージェントは、既存のＤＮＳで使用される共通規約であるＲＦＣ（request for comment）規約を守るために、ＤＮＳ要請メッセージ及びＤＮＳ応答メッセージのヘッダを修正しない。
【０１０７】
また、ＤＮＳ問い合わせレコードのフォーマットは、次の通りである。
【０１０８】
【表４】
0005976232.tif 000005
【０１０９】
Query name（質疑名称）フィールドは、可変長を有し、ドメインネームを含む。
【０１１０】
Query type（質疑種類）フィールドは、１６ビットからなり、質疑種類を示す。
【０１１１】
本発明で頻繁に使用されるクエリ種類は、表５の通りである。
【０１１２】
【表５】
0005976232.tif 000006
【０１１３】
エージェントは、前述のＤＮＳ問い合わせレコード形式において、Query nameとQuery typeとを修正し、ＤＮＳ問い合わせメッセージを伝送する。そして、Query typeを変更することも可能であるが、それはＩＰアドレスだけではなく、Text型情報、例えば、クライアント・モジュールに必要な情報を伝送されるためである。
【０１１４】
そして、本発明によるユーザ情報に基づいたドメインネーム・サービスシステム及び方法において、ユーザ情報追加前後のクエリ名称変化に係わる例を挙げれば、次の通りである。
【０１１５】
１つのラベルを介して、ユーザ情報を追加する場合：
変更前：www.service.com
変更後：IPAddressUserID.www.service.com
多数のラベルを介して、ユーザ情報を追加する場合：
変更前：www.service.com
変更後：Ipaddress.UserID.www.service.com
上述の方法でクライアント・モジュールの情報を追加する場合：
変更前：www.service.com
変更後：ModuleVersion.UserID.www.service.com
上述の方法で装置情報を追加する場合：
変更前：www.service.com
変更後：DevInfo.www.service.com
【０１１６】
すなわち、ドメインネームの前に情報を追加し、ＤＮＳサーバがそれを受信することを可能にする。
【０１１７】
サービスドメイン「www.service.com」を修正し、他のＤＮＳサーバがそれを受信することを可能にする場合
変更前：www.service.com
変更後：Ipaddress.UserID.Service.OtherDNS.com
【０１１８】
すなわち、「OtherDNS.com」というドメイン情報を登録したＤＮＳサーバが変更後に該当するドメイン情報を解析する。
【０１１９】
そして、データベース連結の例を挙げれば、表６の通りである。
【０１２０】
【表６】
0005976232.tif 000007
【０１２１】
表６の例は、説明のための単純な例であり、要請したドメインネームと一致する情報を、表５のように、多様なタイプで応答することができる。セキュリティが要求されるＤＮＳサービスについては、ＤＮＳＳＥＣ方式も適用可能である。
【０１２２】
一方、本発明によるＤＮＳの応答データの例は、次の通りである。本発明の実施形態において使用される応答データとして、ＤＮＳ解析を要請するとき、ユーザ情報（クライアント）別の目的地経路とＤＮＳ迂回情報を共に応答する。ＤＮＳ応答は、ポリシーによって、１つのＤＮＳ応答メッセージ内に、目的地ＩＰアドレスと迂回ＤＮＳアドレスとが含まれたり、あるいは２つのＤＮＳ応答メッセージに分けて応答したりすることができる。
【０１２３】
【表７】
0005976232.tif 000008
【０１２４】
情報入力または情報獲得の場合にも、同様に、ＤＮＳ迂回情報を共に応答する。
【０１２５】
【表８】
0005976232.tif 000009
【０１２６】
本発明は、コンピュータで読取り可能な記録媒体に、コンピュータ（情報処理機能を有する装置をいずれも含む）で読取り可能なコードとして具現することが可能である。コンピュータで読取り可能な記録媒体は、コンピュータ・システムによって読取り可能なデータが保存される全ての種類の記録装置を含む。コンピュータで読取り可能な記録装置の例としては、ＲＯＭ（read-only memory）、ＲＡＭ（random-access memory）、ＣＤ（compact disc）−ＲＯＭ、磁気テープ、フロッピーディスク、光データ保存装置などがある。
【０１２７】
本発明は、図面に図示された実施形態を参照して説明したが、それらは例示的なものに過ぎず、本技術分野の当業者であるならば、それらから多様な変形及び均等な他の実施形態が可能であるという点を理解するであろう。従って、本発明の真の技術的保護範囲は、特許請求の範囲の技術的思想によって決まらなければならないのである。
【産業上の利用可能性】
【０１２８】
サービスに利用されるサーバ及び装置の非正常的な動作中にも、ユーザにサービスの連続性を維持させることができるドメインネーム・システムとドメインネーム・サービスとに利用可能である。
【図１】
0005976232.tif 000010
【図２】
0005976232.tif 000011
【図３】
0005976232.tif 000012
【図４】
0005976232.tif 000013
【図５】
0005976232.tif 000014
【図６】
0005976232.tif 000015
【図７】
0005976232.tif 000016
【図８】
0005976232.tif 000017
【図９】
0005976232.tif 000018
【図１０】
0005976232.tif 000019
【図１１】
0005976232.tif 000020
【図１２】
0005976232.tif 000021
【図１３】
0005976232.tif 000022