JP2017175567A - 名前解決装置、名前解決方法及び名前解決プログラム - Google Patents

Abstract

【課題】送信元に応じて名前解決の応答を変更する場合に、高速、かつ、メモリ使用量を低減できる名前解決装置、名前解決方法及び名前解決プログラムを提供すること。
【解決手段】名前解決装置１は、ＤＮＳクエリを受信するクエリ受信部１１と、ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換部１２と、ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを標準ＤＮＳ機能部２０へ送信した後、当該リクエストに対する回答を標準ＤＮＳ機能部２０から受信し、当該回答に基づいてＤＮＳクエリに対する応答項目を生成するクエリ処理部１３と、応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信部１４と、を備える。
【選択図】図２

Description

本発明は、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）クエリに応答する名前解決装置、名前解決方法及び名前解決プログラムに関する。

ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）の普及により、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）及びスマートフォンなどの人が利用する端末だけでなく、センサなどの多数のＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）デバイスがクライアント端末としてインターネットに接続されることが予想される。
このような状況において、集中配備されたデータセンタなどによりサービスを提供する従来のクラウドコンピューティング環境では、トラフィック負荷の増大が問題となる。そこで、多数のクライアント端末が配備される現場の近くに分散配備されたエッジサーバで処理を行い、トラフィック及びクライアント端末への応答時間を削減させるコンピューティング技術として、モバイルエッジコンピューティングが提案されている。

モバイルエッジコンピューティングに求められる条件として、クライアント端末からのリクエストに対して、クライアント端末に近いエッジサーバで処理し応答するために、処理したいパケットの宛先をエッジサーバのＩＰアドレスとするルーティング（ローカルブレイクアウト）を行なう必要がある。ローカルブレイクアウトの手法は、以下の３つが挙げられる。

手法１は、クライアント端末に専用アプリケーションをインストールし、かつ、エッジサーバに専用のネットワーク機器を設置することにより、クライアント端末から直接エッジサーバを指定して、機器上で指定されたパケットをエッジサーバにルーティングする手法である。
手法２は、エッジサーバ側にローカルＤＮＳサーバを配置し、クライアント端末にＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）を事前設定してローカルＤＮＳサーバを指定することにより、エッジサーバのＩＰアドレスを宛先としてＤＮＳ名前解決させ、エッジサーバにルーティングする手法である。
手法３は、既設のＤＮＳサーバを利用して、エッジサーバのＩＰアドレスを宛先としてＤＮＳ名前解決させ、エッジサーバにルーティングする手法である。
ここで、ユーザの利便性を考慮すると、クライアント端末に専用アプリケーション又は事前設定が不要な手法３が最も有効な手法と言える。

非特許文献１には、ＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）によりコンテンツ配信サーバを選択する技術が提案されている。この技術では、個々のコンテンツサーバを識別するＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）を管理するＤＮＳサーバが用意される。クライアントは、通常の権威ＤＮＳサーバにＤＮＳクエリを送信するが、権威ＤＮＳサーバからは、ＦＱＤＮを管理するＤＮＳサーバに問合せを行うようにクライアントに対してＤＮＳレスポンスが返信される。クライアントは、指定されたＤＮＳサーバに対して再度ＤＮＳクエリを送信して、コンテンツ配信サーバのＩＰアドレスを得る。

特許文献１では、サービス（ドメイン）毎及び送信元毎にＤＮＳゾーンファイルを設定し、クライアントの置かれた送信元の環境（ＩＰアドレス又はネットワークの帯域など）により、名前解決の応答を変更する装置が提案されている。
特許文献２では、検索キー（例えば、送信元のＩＰアドレス）の値から検索対象（例えば、接続するエッジサーバのＩＰアドレス）を探索する検索テーブル（ハッシュテーブル）を作成し、検索回数を削減する装置が提案されている。

特開２００７−１６６６５９号公報 特開２０１１−１０３６１３号公報

Ｄｉｌｌｅｙ， Ｊ． ｅｔ． ａｌ．， "Ｇｌｏｂａｌｌｙ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ" Ｉｎｔｅｒｎｅｔ Ｃｏｍｐｕｔｉｎｇ， ＩＥＥＥ （２００２）

非特許文献１の手法では、クライアントから、権威ＤＮＳサーバへの問合せ及びエッジサーバ（コンテンツ配信サーバ）を管理するＤＮＳサーバへの問合せの２回の問合せが必ず発生する。これに伴い、クライアントで名前解決が完了するまでに２往復分の通信遅延が発生するため、応答の高速性に課題があった。
特許文献１の手法では、１台のＤＮＳサーバに、送信元情報データベース及びＤＮＳ応答用データベースを保有することで、ＤＮＳサーバへの問合せ回数を１回に抑制できるが、２つのデータベースに対して検索を行うため、応答の高速性に課題があった。
特許文献２の手法では、検索テーブルの作成によってＤＮＳレコードの検索回数を削減できるものの、検索テーブル作成のためのメモリ使用量は、ＤＮＳレコード数が増加するに従って増大していた。さらに、ＤＮＳサーバが管理するサービス（ドメイン）数との積のメモリ使用量が必要となるため、エッジサーバの数が制限されるなど、スケーラビリティに課題があった。

本発明は、送信元に応じて名前解決の応答を変更する場合に、高速、かつ、メモリ使用量を低減できる名前解決装置、名前解決方法及び名前解決プログラムを提供することを目的とする。

本発明に係る名前解決装置は、ＤＮＳクエリを受信するクエリ受信部と、前記ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換部と、前記ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を前記送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを所定のＤＮＳ機能部へ送信した後、当該リクエストに対する回答を前記ＤＮＳ機能部から受信し、当該回答に基づいて前記ＤＮＳクエリに対する応答項目を生成するクエリ処理部と、前記応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信部と、を備える。

前記リクエストに対する回答は、当該リクエストにおける前記変換後のホスト名とＩＰアドレスとが対応付けられたゾーンファイルに基づいて生成されてもよい。

前記クエリ処理部は、前記リクエストに対して、外部のネームサーバへの再帰問合せクエリを受信した場合、当該再帰問合せクエリにおけるＦＱＤＮを変換前の文字列に復元して前記ネームサーバへ送信した後、当該ネームサーバから受信した回答に基づいて、前記再帰問合せクエリに対する回答を前記ＤＮＳ機能部へ送信してもよい。

前記名前解決装置は、前記再帰問合せクエリの送信先として前記ネームサーバのアドレスと組合せて設定されるポート番号に基づいて、前記ＤＮＳ機能部から送信される再帰問合せクエリを前記クエリ処理部に、前記レスポンス送信部から送信される再帰問合せクエリを前記ネームサーバに送信する通信制御部を備えてもよい。

前記クエリ処理部は、前記再帰問合せクエリに対する回答において、ＦＱＤＮのホスト名をワイルドカードで拡張して前記ＤＮＳ機能部にキャッシュさせてもよい。

本発明に係る名前解決方法は、ＤＮＳクエリを受信するクエリ受信ステップと、前記ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換ステップと、前記ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を前記送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを所定のＤＮＳ機能部へ送信した後、当該リクエストに対する回答を前記ＤＮＳ機能部から受信し、当該回答に基づいて前記ＤＮＳクエリに対する応答項目を生成するクエリ処理ステップと、前記応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信ステップと、をコンピュータが実行する。

本発明に係る名前解決プログラムは、ＤＮＳクエリを受信するクエリ受信ステップと、前記ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換ステップと、前記ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を前記送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを所定のＤＮＳ機能部へ送信した後、当該リクエストに対する回答を前記ＤＮＳ機能部から受信し、当該回答に基づいて前記ＤＮＳクエリに対する応答項目を生成するクエリ処理ステップと、前記応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信ステップと、をコンピュータに実行させる。

本発明によれば、送信元に応じて名前解決の応答を変更する場合に、高速、かつ、メモリ使用量を低減できる。

実施形態に係る名前解決装置を含むシステムの全体構成を示す図である。 実施形態に係る名前解決装置の機能構成を示すブロック図である。 実施形態に係るゾーンファイルにおいて、ＩＰｖ４が採用されている場合の記述例を示す図である。 実施形態に係るゾーンファイルにおいて、ＩＰｖ６が採用されている場合の記述例を示す図である。 実施形態に係る名前解決処理の第１パターンを示すシーケンス図である。 実施形態に係る名前解決処理の第１パターンにおいて処理されるＤＮＳメッセージを例示する図である。 実施形態に係る名前解決処理の第２パターンを示すシーケンス図である。 実施形態に係る名前解決処理の第２パターンにおいて処理されるＤＮＳメッセージを例示する図である。

以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係る名前解決装置１を含むシステム１００の全体構成を示す図である。
システム１００は、名前解決装置１と、複数のクライアント２と、複数のエッジサーバ３と、クラウドサーバ４と、ルートネームサーバ５とを備え、これらの装置は、所定のネットワークを介して互いに接続されている。

名前解決装置１は、クライアント２からの要求に応じて名前解決を行うＤＮＳサーバであり、詳細は後述する。
クライアント２は、クラウドサーバ４が提供するサービスを利用するデバイスであり、例えば、ＰＣ、スマートフォン又はセンサなど、種々のＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）デバイスであってよい。
エッジサーバ３は、クライアント２に対してクラウドサーバ４に代わりサービスを提供するサーバであり、クライアント２が配備される現場付近に分散配備される。
クラウドサーバ４は、クライアント２に対してサービスを提供するサーバであり、データセンタなどに集中配備される。
ルートネームサーバ５は、インターネットで利用されるＤＮＳにおいて、ツリー構造の起点となるサーバである。

図２は、本実施形態に係る名前解決装置１の機能構成を示すブロック図である。
名前解決装置１は、プラグインソフトウェアにより実装されるプラグイン機能部１０と、標準ＤＮＳ機能部２０と、通信制御部３０とを備える。
プラグイン機能部１０は、クエリ受信部１１と、送信元変換部１２と、クエリ処理部１３と、レスポンス送信部１４とを備える。
標準ＤＮＳ機能部２０は、ＢＩＮＤなどのオープンソースとして公開されているバイナリファイルにより実装される名前解決処理部２１と、設定ファイル群２２（ｎａｍｅｄ．ｃｏｎｆファイル、ゾーンファイル、ｒｏｏｔ．ｈｉｎｔファイル）とを備える。

通信制御部３０は、プラグイン機能部１０又は標準ＤＮＳ機能部２０から送信されるＤＮＳメッセージについて、送信先ＩＰアドレス及びポート番号の組合せに基づいて、ルーティングテーブルを参照することにより、実際の送信先を決定する。本実施形態においては、ルートネームサーバ５に向けた後述の再帰問合せクエリについて、特定のポート番号が設定されたパケットの宛先がプラグイン機能部１０に変更される。

クエリ受信部１１は、クライアント２からＤＮＳクエリを受信し、ＦＱＤＮ及び送信元ＩＰアドレスを読み取る。送信元ＩＰアドレスは、送信元変換部１２に渡される。

送信元変換部１２は、送信元ＩＰアドレスを、標準ＤＮＳ機能部２０へ問い合わせるための送信元情報、すなわち送信元を一意に識別可能な文字列へ変換し、クエリ処理部に通知する。
例えば、送信元変換部１２は、「１２．０．０．１１」という送信元ＩＰアドレスを、ホスト名として取り扱うことのできる「１２−０−０−１１」という送信元情報に変換する。また、送信元変換部１２は、名前解決装置１とクライアント２とが同一のネットワークドメインで使用される場合には、例えば「１９２．１６８．０．１／２４」という送信元ＩＰアドレスを、ホスト部のみの「１」という送信元情報に変換してもよい。

クエリ処理部１３は、クエリ受信部１１が外部装置（クライアント２又はルートネームサーバ５）から受け取ったＤＮＳメッセージ（ＤＮＳクエリ又は再帰問合せレスポンス）を受け取る。さらに、クエリ処理部１３は、送信元変換部１２から送信元情報を受け取る。
クエリ処理部１３は、ＤＮＳメッセージの一部を変換して、標準ＤＮＳ機能部２０にＤＮＳメッセージ（Ａレコードリクエスト又は再帰問合せレスポンス）を送信する。また、クエリ処理部１３は、標準ＤＮＳ機能部２０から受け取ったＤＮＳメッセージ（Ａレコードレスポンス、再帰問合せリクエスト）を一部変換して、外部装置への送信内容（応答ＩＰアドレス又は再帰問合せリクエスト）を、レスポンス送信部１４に通知する。

レスポンス送信部１４は、クエリ処理部１３から送信内容を受け取り、ＤＮＳメッセージの形式にパケットを構成して、外部装置（クライアント２又はルートネームサーバ５）に送信する。

名前解決処理部２１は、既存のＤＮＳサーバが標準的に備える名前解決機能を有し、設定ファイル群２２に含まれるサービス（ドメイン）毎のゾーンファイル２２１を参照し、ＦＱＤＮに対応するＩＰアドレスを回答する。

設定ファイル群２２は、ゾーンファイル２２１の他、ゾーンファイル２２１の格納場所などの設定情報が記述されるｎａｍｅｄ．ｃｏｍｆファイル２２２、及びルートネームサーバ５のＩＰアドレスが記述されるｒｏｏｔ．ｈｉｎｔファイル２２３を含む。

図３は、本実施形態に係るゾーンファイル２２１において、ＩＰｖ４が採用されている場合の記述例を示す図である。
ゾーンファイル２２１は、あるドメイン（例えば、「ａｂｃ．ｃｏｍ」）における送信元情報及びホスト名と、エッジサーバ３の応答ＩＰアドレスとの対応関係を示すＡレコードを含む。

Ａレコードは、「（送信元情報）．（ホスト名） ＩＮ Ａ （応答ＩＰアドレス）」の形式で記述される。例えば、「１２−０−０−１１．ｗｗｗ ＩＮ Ａ １１．０．０．１１」は、送信元ＩＰアドレス「１２．０．０．１１」から、ＦＱＤＮ「ｗｗｗ．ａｂｃ．ｃｏｍ」の問合せがあった場合に、エッジサーバ３のＩＰアドレス「１１．０．０．１１」を応答するという意味である。
また、ゾーンファイル内の最後のＡレコード「＊．（ホスト名） ＩＮ Ａ （クラウドサーバに相当する応答ＩＰアドレス）」は、ゾーンファイル２２１に適切なエッジサーバ３の登録がない場合に、クラウドサーバ４のＩＰアドレスを応答するための記述である。

図４は、本実施形態に係るゾーンファイル２２１において、ＩＰｖ６が採用されている場合の記述例を示す図である。
ＩＰｖ６の場合は、Ａレコードの代わりに、ＡＡＡＡレコードが記述され、ＩＰｖ４の場合と同様に、送信元情報及びホスト名と、エッジサーバ３の応答ＩＰアドレスとの対応関係が示される。

図５は、本実施形態に係る名前解決処理の第１パターンを示すシーケンス図である。
第１パターンは、クライアントから受信したＤＮＳクエリのＦＱＤＮに対して、対象ドメインのゾーンファイル２２１が標準ＤＮＳ機能部２０に存在する場合の処理である。

ステップＳ１において、プラグイン機能部１０（クエリ受信部１１）は、クライアント２からＤＮＳクエリを受信する。

ステップＳ２において、プラグイン機能部１０（クエリ受信部１１）は、ＤＮＳクエリから送信元ＩＰアドレス及びＦＱＤＮを取得する。クエリ受信部１１は、取得した送信元ＩＰアドレスを送信元変換部１２へ通知する。

ステップＳ３において、プラグイン機能部１０（送信元変換部１２）は、送信元ＩＰアドレス（例えば、「１２．０．０．１１」）を送信元情報（例えば、「１２−０−０−１１」）に変換する。送信元変換部１２は、送信元情報をクエリ処理部１３へ通知する。

ステップＳ４において、プラグイン機能部１０（クエリ処理部１３）は、クエリ受信部１１からＦＱＤＮ（例えば、「ｗｗｗ．ａｂｃ．ｃｏｍ」）を、送信元変換部１２から送信元情報（例えば、「１２−０−０−１１」）を受け取り、標準ＤＮＳ機能部２０に問合せるためのＡレコードリクエストを作成する。Ａレコードリクエストは、ＤＮＳメッセージの形式に則って作成される。メッセージ内の問合せＦＱＤＮは、受け取ったＦＱＤＮ及び送信元情報を組合せ、例えば「１２−０−０−１１．ｗｗｗ．ａｂｃ．ｃｏｍ」と記述される。

ステップＳ５において、プラグイン機能部１０（クエリ処理部１３）は、標準ＤＮＳ機能部２０に対して、Ａレコードリクエストを送信し、Ａレコードの問合せを行う。

ステップＳ６において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、受信したＡレコードリクエスト内のＦＱＤＮに対応するドメインのゾーンファイル２２１が存在するか否かを判定する。本処理の第１パターンでは、この判定がＹＥＳとなり、処理はステップＳ７に進む。

ステップＳ７において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、Ａレコードリクエストに対して名前解決を実施する。具体的には、名前解決処理部２１は、ゾーンファイル２２１内のホスト名（例えば、「１２−０−０−１１．ｗｗｗ」）を探索し、該当のＡレコードに記述されているＩＰアドレス（例えば、「１１．０．０．１１」）を名前解決する。
ここで、ゾーンファイル２２１に対象のホスト名がない場合、例えば、送信元ＩＰアドレスが「１２．０．０．１４」であり、リクエストされたホスト名が「１２−０−０−１４．ｗｗｗ」の場合、「＊．ｗｗｗ」のＡレコードに該当するので、名前解決処理部２１は、クラウドサーバのＩＰアドレス（例えば、「１０．０．０．１１」）を名前解決する。

ステップＳ８において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、名前解決結果をＤＮＳメッセージとして構成し、Ａレコードレスポンスとしてプラグイン機能部１０（クエリ処理部１３）へ送信する。

ステップＳ９において、プラグイン機能部１０（クエリ処理部１３）は、クライアント２に応答する項目を生成する。具体的には、クエリ処理部１３は、ＤＮＳレスポンスの内容となる項目として、Ａレコードレスポンス内のＦＱＤＮ（例えば、「１２−０−０−１１．ｗｗｗ．ａｂｃ．ｃｏｍ」）を元のＤＮＳクエリのＦＱＤＮ（例えば、「ｗｗｗ．ａｂｃ．ｃｏｍ」）に変換し、ＦＱＤＮ及び応答ＩＰアドレスを、レスポンス送信部１４に通知する。

ステップＳ１０において、プラグイン機能部１０（レスポンス送信部１４）は、レスポンスの内容をＤＮＳメッセージとして構成し、クライアント２へＤＮＳレスポンスを返信する。

図６は、本実施形態に係る名前解決処理の第１パターンにおいて処理されるＤＮＳメッセージを例示する図である。
クエリ受信部１１が受信するＤＮＳクエリ（１）は、送信元ＩＰアドレス、送信先ＩＰアドレス、送信先ポート番号及びＦＱＤＮを含む。

クエリ処理部１３は、Ａレコードリクエスト（２）において、送信元ＩＰアドレスに自分自身を、送信先ＩＰアドレスに自分自身を表す仮想アドレスであるループバックアドレス「１２７．０．０．１」を設定する。また、ＦＱＤＮには、送信元ＩＰアドレスを一意に示す文字列にホスト名が変換されて設定される。
ここで、ポート番号は、プラグイン機能部１０及び標準ＤＮＳ機能部２０のそれぞれにおいて、ＤＮＳメッセージを受信する際に衝突が発生しないように別々に設定される。具体的には、名前解決装置１がＤＮＳメッセージを受信するポート番号である５３番がプラグイン機能部１０に割り当てられ、未使用の特定ポート（例えば、１００５３番）が標準ＤＮＳ機能部２０に割り当てられる。

名前解決処理部２１からクエリ処理部１３に返信されるＡレコードレスポンス（３）には、ＦＱＤＮに対応するエッジサーバ３のＩＰアドレスが回答として設定される。
なお、ポート番号には、クエリ処理部１３がＡレコードリクエストを送信した際に使用した送信元ポート番号が設定される。

レスポンス送信部１４は、ＤＮＳレスポンス（４）において、送信先ＩＰアドレスをクライアント２に、ポート番号をクライアント２がＤＮＳクエリ送信時に使用した番号に設定する。そして、ＦＱＤＮは、クエリ処理部１３によりＤＮＳクエリと同じ文字列に復元される。

図７は、本実施形態に係る名前解決処理の第２パターンを示すシーケンス図である。
第２パターンは、クライアントから受信したＤＮＳクエリのＦＱＤＮに対して、対象ドメインのゾーンファイル２２１が標準ＤＮＳ機能部２０に存在しない場合（図５のステップＳ６で判定がＮＯの場合）の処理である。

ステップＳ１〜Ｓ５は、第１パターン（図５）と共通である。
ステップＳ６において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、受信したＡレコードリクエスト内のＦＱＤＮに対応するドメインのゾーンファイル２２１が存在するか否かを判定する。本処理の第２パターンでは、この判定がＮＯとなり、処理はステップＳ１１に進む。

ステップＳ１１において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、ｒｏｏｔ．ｈｉｎｔファイル２２２に記載されたルートネームサーバ５に向けての再帰問合せクエリを作成する。例えば、ＩＰアドレスが「１９８．９７．１９０．５３」のルートネームサーバ５に対して、Ａレコードリクエストに記述された「１２−０−０−１１．ｗｗｗ．ｄｅｆ．ｃｏｍ」の再帰問合せクエリが作成される。

ステップＳ１２において、プラグイン機能部１０（クエリ処理部１３）は、標準ＤＮＳ機能部２０から再帰問合せクエリを受信する。このとき、クエリ処理部１３は、ＤＮＳメッセージヘッダ内のＲＤ（再帰要求）ビットによって、受信したＤＮＳメッセージが再帰問合せクエリであることを確認する。
ここで、再帰問合せクエリの送信先ＩＰアドレスはルートネームサーバ５のものであるが、特定のＩＰアドレス及びポート番号の組合せであることから、名前解決装置１の外部へは送信されず、プラグイン機能部１０が受け取る。

ステップＳ１３において、プラグイン機能部１０（クエリ処理部１３）は、標準ＤＮＳ機能部２０から受信した再帰問合せクエリのＦＱＤＮ（例えば、「１２−０−０−１１．ｗｗｗ．ｄｅｆ．ｃｏｍ」）を元のＤＮＳクエリのＦＱＤＮ（例えば、「ｗｗｗ．ｄｅｆ．ｃｏｍ」）に変換して、レスポンス送信部１４に通知する。

ステップＳ１４において、プラグイン機能部１０（レスポンス送信部１４）は、ルートネームサーバ５に向けて再帰問合せクエリを送信する。

ステップＳ１５において、プラグイン機能部１０（クエリ受信部１１）は、ルートネームサーバ５から、再帰問合せレスポンスを受信する。クエリ受信部１１は、再帰問合せレスポンスの内容である応答ＩＰアドレス（例えば、「１０．０．０．１０１」）及びＦＱＤＮ（例えば、「ｗｗｗ．ｄｅｆ．ｃｏｍ」）を読み取り、クエリ処理部１３に通知する。

ステップＳ１６において、プラグイン機能部１０（クエリ処理部１３）は、受け取ったＦＱＤＮ（例えば、「ｗｗｗ．ｄｅｆ．ｃｏｍ」）にワイルドカードの「＊．」を付加し（例えば、「＊．ｗｗｗ．ｄｅｆ．ｃｏｍ」）、これをＦＱＤＮとする標準ＤＮＳ機能部２０向けの再帰問合せレスポンスを作成する。

ステップＳ１７において、プラグイン機能部１０（クエリ処理部１３）は、標準ＤＮＳ機能部２０に対して、再帰問合せレスポンスを送信する。

ステップＳ１８において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、再帰問合せレスポンスの結果をキャッシュし、応答ＩＰアドレスを含むＡレコードレスポンスを作成する。標準ＤＮＳ機能部２０は、キャッシュすることにより、拡張されたＦＱＤＮ（例えば、「＊．ｗｗｗ．ｄｅｆ．ｃｏｍ」）に対して再度Ａレコードリクエストを受信した場合に、再帰問合せを行わずに直接ＩＰアドレスを応答できる。

ステップＳ１９において、標準ＤＮＳ機能部２０（名前解決処理部２１）は、Ａレコードレスポンスをプラグイン機能部１０（クエリ処理部１３）に送信する。

ステップＳ２０において、プラグイン機能部１０（クエリ処理部１３）は、Ａレコードレスポンス内のＦＱＤＮ（例えば、「＊．ｗｗｗ．ｄｅｆ．ｃｏｍ」）を元のＤＮＳクエリのＦＱＤＮ（例えば、「ｗｗｗ．ｄｅｆ．ｃｏｍ」）に変換してＤＮＳレスポンスの項目を生成し、ＦＱＤＮ及び応答ＩＰアドレスをレスポンス送信部１４に通知する。

ステップＳ２１において、プラグイン機能部１０（レスポンス送信部１４）は、クライアント２に向けてＤＮＳレスポンスを返信する。

図８は、本実施形態に係る名前解決処理の第２パターンにおいて処理されるＤＮＳメッセージを例示する図である。
クエリ受信部１１が受信するＤＮＳクエリ（１）及びＡレコードリクエスト（２）は、第１パターン（図６）と比べてＦＱＤＮが異なっている。

標準ＤＮＳ機能部２０からプラグイン機能部１０に対する再帰問合せクエリ（３）は、送信先ＩＰアドレスがルートネームサーバ５を示し、ポート番号がＡレコードリクエストと同一の「１００５３」となっている。この送信先ＩＰアドレス及びポート番号の組合せに基づいて、通信制御部３０により、再帰問合せクエリの宛先がプラグイン機能部１０に変更される。

プラグイン機能部１０からルートネームサーバ５に対する再帰問合せクエリ（４）では、ＦＱＤＮが送信元情報を含まない変換前の状態に復元される。また、ポート番号が標準の「５３」に設定されることにより、通信制御部３０は、宛先を変更することなく、再帰問合せクエリをルートネームサーバ５へ送信する。

ルートネームサーバ５からプラグイン機能部１０に対する再帰問合せレスポンス（５）では、ＦＱＤＮに対するクラウドサーバ４のＩＰアドレスが回答される。ポート番号には、プラグイン機能部１０が再帰問合せクエリを送信した際に使用した送信元ポート番号が設定される。

プラグイン機能部１０から標準ＤＮＳ機能部２０に対する再帰問合せレスポンス（６）では、ＦＱＤＮがワイルドカード「＊．」により拡張され、ＩＰアドレスが回答される。ポート番号には、標準ＤＮＳ機能部２０が再帰問合せクエリを送信した際に使用した送信元ポート番号が設定される。

標準ＤＮＳ機能部２０からプラグイン機能部１０に返信されるＡレコードレスポンス（７）には、再帰問合せレスポンスにより得られたクラウドサーバ４のＩＰアドレスが回答として設定される。ポート番号には、プラグイン機能部１０がＡレコードリクエストを送信した際に使用した送信元ポート番号が設定される。

ＤＮＳレスポンス（８）において、送信先ＩＰアドレスはクライアント２に、ポート番号はクライアント２がＤＮＳクエリを送信した際に使用した番号に設定され、クラウドサーバ４のＩＰアドレスが回答される。このとき、ＦＱＤＮは、受信したＤＮＳクエリと同じ文字列に復元される。

本実施形態によれば、名前解決装置１は、プラグイン機能部１０がクライアント２から受け取るＤＮＳクエリのＦＱＤＮに送信元情報を付加して標準ＤＮＳ機能部２０に問合せを実施する。これにより、同一サーバ（名前解決装置１）内で送信元に応じて応答を変更可能となるため、名前解決における問合せ回数が削減され、標準ＤＮＳ機能部２０内のゾーンファイル２２１に送信元情報とエッジサーバ３のＩＰアドレスとの対応関係を記述することにより検索回数が削減される。
さらに、名前解決装置１は、標準ＤＮＳ機能部２０内のゾーンファイル２２１に対して検索を行うことにより検索テーブル（ハッシュテーブル）を新たに作成する必要がないので、メモリ使用量を削減できる。
したがって、名前解決装置１は、送信元に応じて名前解決の応答を変更する場合に、高速、かつ、メモリ使用量を低減できる。

また、名前解決装置１は、プラグイン機能部１０と標準ＤＮＳ機能部２０とが分離されており、双方を独立に開発することが可能になる。すなわち、標準ＤＮＳ機能部２０を実現する標準ソフトウェアは広く普及しており、安全性向上のため頻繁にアップグレードが行われるが、このアップグレードに伴うプラグイン機能部１０への実装は不要である。これにより、開発、テスト及びメンテナンスにおける工数の削減、並びに脆弱性への素早い対応が可能といった効果も期待できる。

また、名前解決装置１は、標準ＤＮＳ機能部２０において対象のゾーンファイル２２１がないために名前解決できない場合にも、プラグイン機能部１０が再帰問合せにおけるＦＱＤＮを復元してルートネームサーバ５に問合せ、標準ＤＮＳ機能部２０に応答できる。したがって、名前解決装置１は、標準ＤＮＳ機能部２０の状況に応じた複数種類のＤＮＳメッセージを処理し、クライアント２へ適切に応答できる。
このとき、名前解決装置１は、再帰問合せにおける送信先ＩＰアドレス及びポート番号の組合せを参照してルートネームサーバ５を宛先とするＤＮＳメッセージをプラグイン機能部１０で中継できる。したがって、名前解決装置１は、名前解決処理部２１を改変することなくＦＱＤＮを適切に変換して再帰問合せに対応できる。

また、名前解決装置１は、再帰問合せに応じて取得した応答ＩＰアドレスを、ワイルドカードにより拡張したホスト名と対応付けてキャシュするので、同一ドメインに対する次回の名前解決要求に対して効率的に応答できる。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

名前解決装置１による名前解決方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（名前解決装置１）にインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。

１ 名前解決装置
２ クライアント
３ エッジサーバ
４ クラウドサーバ
５ ルートネームサーバ
１０ プラグイン機能部
１１ クエリ受信部
１２ 送信元変換部
１３ クエリ処理部
１４ レスポンス送信部
２０ 標準ＤＮＳ機能部
２１ 名前解決処理部
２２ 設定ファイル群
３０ 通信制御部
１００ システム
２２１ ゾーンファイル
２２２ ｎａｍｅｄ．ｃｏｎｆファイル
２２３ ｒｏｏｔ．ｈｉｎｔファイル

Claims (7)

1. ＤＮＳクエリを受信するクエリ受信部と、
   前記ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換部と、
   前記ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を前記送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを所定のＤＮＳ機能部へ送信した後、当該リクエストに対する回答を前記ＤＮＳ機能部から受信し、当該回答に基づいて前記ＤＮＳクエリに対する応答項目を生成するクエリ処理部と、
   前記応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信部と、を備える名前解決装置。
2. 前記リクエストに対する回答は、当該リクエストにおける前記変換後のホスト名とＩＰアドレスとが対応付けられたゾーンファイルに基づいて生成される請求項１に記載の名前解決装置。
3. 前記クエリ処理部は、前記リクエストに対して、外部のネームサーバへの再帰問合せクエリを受信した場合、当該再帰問合せクエリにおけるＦＱＤＮを変換前の文字列に復元して前記ネームサーバへ送信した後、当該ネームサーバから受信した回答に基づいて、前記再帰問合せクエリに対する回答を前記ＤＮＳ機能部へ送信する請求項１又は請求項２に記載の名前解決装置。
4. 前記再帰問合せクエリの送信先として前記ネームサーバのアドレスと組合せて設定されるポート番号に基づいて、前記ＤＮＳ機能部から送信される再帰問合せクエリを前記クエリ処理部に、前記レスポンス送信部から送信される再帰問合せクエリを前記ネームサーバに送信する通信制御部を備える請求項３に記載の名前解決装置。
5. 前記クエリ処理部は、前記再帰問合せクエリに対する回答において、ＦＱＤＮのホスト名をワイルドカードで拡張して前記ＤＮＳ機能部にキャッシュさせる請求項４に記載の名前解決装置。
6. ＤＮＳクエリを受信するクエリ受信ステップと、
   前記ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換ステップと、
   前記ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を前記送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを所定のＤＮＳ機能部へ送信した後、当該リクエストに対する回答を前記ＤＮＳ機能部から受信し、当該回答に基づいて前記ＤＮＳクエリに対する応答項目を生成するクエリ処理ステップと、
   前記応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信ステップと、をコンピュータが実行する名前解決方法。
7. ＤＮＳクエリを受信するクエリ受信ステップと、
   前記ＤＮＳクエリに含まれる送信元のアドレスを、当該送信元を示す文字列である送信元情報に変換する送信元変換ステップと、
   前記ＤＮＳクエリに含まれるＦＱＤＮにおけるホスト名を前記送信元情報に基づいて一意に変換し、変換後のホスト名を名前解決するためのリクエストを所定のＤＮＳ機能部へ送信した後、当該リクエストに対する回答を前記ＤＮＳ機能部から受信し、当該回答に基づいて前記ＤＮＳクエリに対する応答項目を生成するクエリ処理ステップと、
   前記応答項目に基づいてＤＮＳレスポンスを送信するレスポンス送信ステップと、をコンピュータに実行させるための名前解決プログラム。

Images