(57)【特許請求の範囲】
【請求項１】
ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、当該グループ毎に、前記送信元ＩＰアドレスのそれぞれと応答ＩＰアドレスとの対応付けレコードが記述されたゾーンファイルを記憶する第１記憶部と、
前記ＤＮＳクエリを受信する受信部と、
受信された前記ＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応する前記ゾーンファイルから、前記対応付けレコードを読み込み、前記応答ＩＰアドレスを、前記所定のビット列で表現される数値範囲に対応付けた１次元配列として展開する読込部と、
前記１次元配列から、前記ＤＮＳクエリの送信元ＩＰアドレスにおける前記所定のビット列が表す数値に対応する位置にある前記応答ＩＰアドレスを特定する特定部と、
特定された前記応答ＩＰアドレスを、前記ＤＮＳクエリに対する応答として送信する送信部と、を備える名前解決装置。
【請求項２】
前記グループ毎の前記送信元ＩＰアドレスの範囲、及び当該グループに対応する前記ゾーンファイルを規定した設定ファイルを記憶する第２記憶部を備える請求項１に記載の名前解決装置。
【請求項３】
前記所定のビット列は、最下位のセクションである請求項１又は請求項２に記載の名前解決装置。
【請求項４】
受信された前記ＤＮＳクエリの送信元ＩＰアドレスが前記グループのいずれにも属さない場合、前記ＤＮＳクエリを、前記対応付けレコードを除くＤＮＳレコードを用いて名前解決する標準名前解決部を備える請求項１から請求項３のいずれかに記載の名前解決装置。
【請求項５】
コンピュータがＤＮＳクエリに応答する名前解決方法であって、
前記コンピュータは、ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、当該グループ毎に、前記送信元ＩＰアドレスのそれぞれと応答ＩＰアドレスとの対応付けレコードが記述されたゾーンファイルを記憶する第１記憶部にアクセスし、
前記ＤＮＳクエリを受信する受信ステップと、
受信された前記ＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応する前記ゾーンファイルから、前記対応付けレコードを読み込み、前記応答ＩＰアドレスを、前記所定のビット列で表現される数値範囲に対応付けた１次元配列として展開する読込ステップと、
前記１次元配列から、前記ＤＮＳクエリの送信元ＩＰアドレスにおける前記所定のビット列が表す数値に対応する位置にある前記応答ＩＰアドレスを特定する特定ステップと、
特定された前記応答ＩＰアドレスを、前記ＤＮＳクエリに対する応答として送信する送信ステップと、を実行する名前解決方法。
【請求項６】
コンピュータがＤＮＳクエリに応答するための名前解決プログラムであって、
前記コンピュータに、ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、当該グループ毎に、前記送信元ＩＰアドレスのそれぞれと応答ＩＰアドレスとの対応付けレコードが記述されたゾーンファイルを記憶する第１記憶部にアクセスさせ、
前記ＤＮＳクエリを受信する受信ステップと、
受信された前記ＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応する前記ゾーンファイルから、前記対応付けレコードを読み込み、前記応答ＩＰアドレスを、前記所定のビット列で表現される数値範囲に対応付けた１次元配列として展開する読込ステップと、
前記１次元配列から、前記ＤＮＳクエリの送信元ＩＰアドレスにおける前記所定のビット列が表す数値に対応する位置にある前記応答ＩＰアドレスを特定する特定ステップと、
特定された前記応答ＩＰアドレスを、前記ＤＮＳクエリに対する応答として送信する送信ステップと、を実行させるための名前解決方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）クエリに応答する名前解決装置、名前解決方法及び名前解決プログラムに関する。
【背景技術】
【０００２】
ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）の普及により、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）及びスマートフォン等の人が利用する端末だけでなく、センサ等の多数のＭ２Ｍ（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ）デバイスがクライアント端末としてインターネットに接続されることが予想される。
このような状況において、集中配備されたデータセンタ等によりサービスを提供する従来のクラウドコンピューティング環境では、トラフィック負荷の増大が問題となる。そこで、多数のクライアント端末が配備される現場の近くに分散配備されたエッジサーバで処理を行い、トラフィック及びクライアント端末への応答時間を削減させるコンピューティング技術として、モバイルエッジコンピューティングが提案されている。
【０００３】
モバイルエッジコンピューティングに求められる条件として、クライアント端末からのリクエストに対して、クライアント端末に近いエッジサーバで処理し応答するために、処理したいパケットの宛先をエッジサーバのＩＰアドレスとするルーティング（ローカルブレイクアウト）を行なう必要がある。ローカルブレイクアウトの手法は、以下の３つが挙げられる。
【０００４】
手法１は、クライアント端末に専用アプリケーションをインストールし、かつ、エッジサーバに専用のネットワーク機器を設置することにより、クライアント端末から直接エッジサーバを指定して、機器上で指定されたパケットをエッジサーバにルーティングする手法である。
手法２は、エッジサーバ側にローカルＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバを配置し、クライアント端末にＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）を事前設定してローカルＤＮＳサーバを指定することにより、エッジサーバのＩＰアドレスを宛先としてＤＮＳ名前解決させ、エッジサーバにルーティングする手法である。
手法３は、既設のＤＮＳサーバを利用して、エッジサーバのＩＰアドレスを宛先としてＤＮＳ名前解決させ、エッジサーバにルーティングする手法である。
【０００５】
ここで、ユーザの利便性を考慮すると、クライアント端末に専用アプリケーション又は事前設定が不要な手法３が最も有効な手法と言える。ところが、手法３では、ＤＮＳサーバへ各エッジサーバのＩＰアドレスを登録する必要があるため、エッジサーバの台数が増加すると、ＤＮＳサーバのＤＮＳレコードが増加する。そして、ＤＮＳレコードが増加すると、名前解決の際に掛かるＤＮＳレコードの検索回数及びメモリ使用量が増加する。
【０００６】
特許文献１には、ＤＮＳレコードにおいて、ＤＮＳクエリの送信元ＩＰアドレスを８ビット区切表記から１０進数表記に変換（例えば、１９２．１６８．１．０を３２３２２３５７７６へ変換）し、ハッシュ探索することでＤＮＳレコードの検索回数を削減する手法が提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−１０３６１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１の手法では、ハッシュ探索によってＤＮＳレコードの検索回数を１回に削減できる。しかしながら、このときのメモリ使用量は、１レコード当たりの８Ｂｙｔｅ（送信元ＩＰアドレス４Ｂｙｔｅ＋応答ＩＰアドレス４Ｂｙｔｅ）が必要なため、ＤＮＳレコード数が増加するに従って増大（例えば、１００００００レコードに対して８０００ＫＢｙｔｅ）していた。
【０００９】
本発明は、クライアント端末に事前設定を必要とせず、検索回数及びメモリ使用量を削減できる名前解決装置、名前解決方法及び名前解決プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る名前解決装置は、ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、当該グループ毎に、前記送信元ＩＰアドレスのそれぞれと応答ＩＰアドレスとの対応付けレコードが記述されたゾーンファイルを記憶する第１記憶部と、前記ＤＮＳクエリを受信する受信部と、受信された前記ＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応する前記ゾーンファイルから、前記対応付けレコードを読み込み、前記応答ＩＰアドレスを、前記所定のビット列で表現される数値範囲に対応付けた１次元配列として展開する読込部と、前記１次元配列から、前記ＤＮＳクエリの送信元ＩＰアドレスにおける前記所定のビット列が表す数値に対応する位置にある前記応答ＩＰアドレスを特定する特定部と、特定された前記応答ＩＰアドレスを、前記ＤＮＳクエリに対する応答として送信する送信部と、を備える。
【００１１】
前記名前解決装置は、前記グループ毎の前記送信元ＩＰアドレスの範囲、及び当該グループに対応する前記ゾーンファイルを規定した設定ファイルを記憶する第２記憶部を備えてもよい。
【００１２】
前記所定のビット列は、最下位のセクションであってもよい。
【００１３】
前記名前解決装置は、受信された前記ＤＮＳクエリの送信元ＩＰアドレスが前記グループのいずれにも属さない場合、前記ＤＮＳクエリを、前記対応付けレコードを除くＤＮＳレコードを用いて名前解決する標準名前解決部を備えてもよい。
【００１４】
本発明に係る名前解決方法は、コンピュータがＤＮＳクエリに応答する名前解決方法であって、前記コンピュータは、ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、当該グループ毎に、前記送信元ＩＰアドレスのそれぞれと応答ＩＰアドレスとの対応付けレコードが記述されたゾーンファイルを記憶する第１記憶部にアクセスし、前記ＤＮＳクエリを受信する受信ステップと、受信された前記ＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応する前記ゾーンファイルから、前記対応付けレコードを読み込み、前記応答ＩＰアドレスを、前記所定のビット列で表現される数値範囲に対応付けた１次元配列として展開する読込ステップと、前記１次元配列から、前記ＤＮＳクエリの送信元ＩＰアドレスにおける前記所定のビット列が表す数値に対応する位置にある前記応答ＩＰアドレスを特定する特定ステップと、特定された前記応答ＩＰアドレスを、前記ＤＮＳクエリに対する応答として送信する送信ステップと、を実行する。
【００１５】
本発明に係る名前解決プログラムは、コンピュータがＤＮＳクエリに応答するための名前解決プログラムであって、前記コンピュータに、ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、当該グループ毎に、前記送信元ＩＰアドレスのそれぞれと応答ＩＰアドレスとの対応付けレコードが記述されたゾーンファイルを記憶する第１記憶部にアクセスさせ、前記ＤＮＳクエリを受信する受信ステップと、受信された前記ＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応する前記ゾーンファイルから、前記対応付けレコードを読み込み、前記応答ＩＰアドレスを、前記所定のビット列で表現される数値範囲に対応付けた１次元配列として展開する読込ステップと、前記１次元配列から、前記ＤＮＳクエリの送信元ＩＰアドレスにおける前記所定のビット列が表す数値に対応する位置にある前記応答ＩＰアドレスを特定する特定ステップと、特定された前記応答ＩＰアドレスを、前記ＤＮＳクエリに対する応答として送信する送信ステップと、を実行させる。
【発明の効果】
【００１６】
本発明によれば、クライアント端末に事前設定を必要とせず、検索回数及びメモリ使用量を削減できる。
【図面の簡単な説明】
【００１７】
【図１】実施形態に係るサービス提供システムの構成を示す図である。
【図２】実施形態に係るＤＮＳサーバの機能構成を示す図である。
【図３】実施形態に係る設定ファイルの一例を示す図である。
【図４】実施形態に係るゾーンファイルの一例を示す図である。
【図５】実施形態に係る初期設定処理を示すフローチャートである。
【図６】実施形態に係る応答ＩＰアドレスの１次元配列の例を示す図である。
【図７】実施形態に係る名前解決処理を示すシーケンス図である。
【図８】実施形態に係る名前解決方法によるＤＮＳレコードの検索回数及びメモリ使用量を、従来の方法と比較して示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係るＤＮＳサーバ１（名前解決装置）を含むサービス提供システム１００の構成を示す図である。
サービス提供システム１００は、ＤＮＳサーバ１と、クライアント端末２と、エッジサーバ３と、クラウドサーバ４とを備える。
【００１９】
ＤＮＳサーバ１は、クライアント端末２からＤＮＳクエリを受信し、送信元ＩＰアドレスに基づいて、ドメイン名からエッジサーバ３のいずれか又はクラウドサーバ４のＩＰアドレスへの名前解決を行い、結果をＤＮＳレスポンスとして返信する。
【００２０】
クライアント端末２は、Ｗｅｂアクセス等に必要なＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）を含んだＤＮＳクエリを送信し、ＤＮＳサーバ１から得られるＤＮＳレスポンスに応じて、指定されたエッジサーバ３又はクラウドサーバ４にアクセスすることにより、所定のサービスの提供を受ける。
【００２１】
エッジサーバ３は、クライアント端末２のある現場近くに設置される複数のサーバ群である。エッジサーバ３のそれぞれには、クラウドサーバ４と同様のアプリケーションが実装され、特定範囲のＩＰアドレスを持つクライアント端末２は、ＤＮＳサーバ１により指定されたエッジサーバ３にアクセスする。
【００２２】
クラウドサーバ４は、クライアント端末２へ所定のサービスを提供するためデータセンタ等に設置されるサーバである。ＤＮＳサーバ１によりいずれのエッジサーバ３も選択されない場合、このクラウドサーバ４がデフォルトのアクセス先として指定される。
【００２３】
図２は、本実施形態に係るＤＮＳサーバ１の機能構成を示す図である。
ＤＮＳサーバ１は、プラグイン処理部１０及び標準処理部２０を含む制御部（ＣＰＵ）と、記憶部３０とを備える。
【００２４】
プラグイン処理部１０は、記憶部３０に格納されたプラグインアプリケーション（名前解決プログラム）を制御部が実行することにより機能する。
標準処理部２０は、記憶部３０に格納された標準アプリケーションを制御部が実行することにより機能する。この標準アプリケーションは、ＤＮＳサーバ１による標準的な名前解決機能を実現するためのプログラムであり、例えば、ＤＮＳ  Ｂｉｎｄソフトウェアである。
なお、プラグイン処理部１０及び標準処理部２０の詳細な機能は後述する。
【００２５】
記憶部３０は、ハードウェア群をＤＮＳサーバ１として機能させるための各種プログラム、及び各種データ等を記憶する。具体的には、記憶部３０は、標準アプリケーション及びプラグインアプリケーションの他、双方のアプリケーションから参照される設定ファイル３１及びゾーンファイル３２を記憶する。
【００２６】
設定ファイル３１は、ＤＮＳクエリの送信元となり得る送信元ＩＰアドレスを、所定のビット列以外が共通のグループに分割し、グループ毎の送信元ＩＰアドレスの範囲、及び各グループに対応するゾーンファイル３２を規定する。
ゾーンファイル３２には、グループに含まれる送信元ＩＰアドレスのそれぞれと、応答ＩＰアドレスとの対応付けレコードが記述される。
【００２７】
ここで、記憶部３０に格納される設定ファイル３１及びゾーンファイル３２の初期設定について詳述する。
図３は、本実施形態に係る設定ファイル３１の一例を示す図である。
【００２８】
まず、プラグイン処理部１０により名前解決する送信元ＩＰアドレスのグループを範囲指定するために、ＡＣＬ（Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ）コードが記載される。範囲指定は、ＣＩＤＲ（Ｃｌａｓｓｌｅｓｓ  Ｉｎｔｅｒ−Ｄｏｍａｉｎ  Ｒｏｕｔｉｎｇ）表記に従い、ＡＣＬコードは、標準的なＤＮＳの文法に従う。
例えば、送信元ＩＰアドレスとして「１０．１０．１０．０〜１０．１０．１０．２５５」を指定する場合、ＡＣＬ名「ｅｄｇｅ−ａｂｃ１」に対して「１０．１０．１０．０／２４」が記載される。
なお、ＡＣＬ名は、ＡＣＬステートメント内で重複しない任意の文字列が設定される。
【００２９】
次に、ＡＣＬコードで範囲指定されたグループに対応するゾーンファイル３２を指定するために、ＶＩＥＷ制御コードが記載される。
例えば、ＶＩＥＷ名「ｇｌｏｂａｌ１」に対して、ＡＣＬ名「ｅｄｇｅ−ａｂｃ１」が記載され、さらに、名前解決する対象のドメイン名（例えば、「ｅｘａｍｐｌｅ．ｊｐ」）と、参照するＤＮＳレコードが記述されたゾーンファイル３２のファイル名（例えば、「ａｂｃ．ｅｘａｍｐｌｅ．ｊｐ１．ｚｏｎｅ」）とが記載される。
【００３０】
ここで、ＡＣＬコードは、送信元ＩＰアドレスのグループ毎に複数設定される。グループ内のＩＰアドレスは、第４オクテットのみが異なり、２５６以下のクライアント端末が属する。
また、ＶＩＥＷコードは、ＡＬＣコードで設定されたグループ毎、名前解決する対象のドメイン毎に複数設定される。
【００３１】
図４は、本実施形態に係るゾーンファイル３２の一例を示す図である。
この例は、図３の設定ファイル３１におけるＶＩＥＷ名「ｇｌｏｂａｌ１」に対応するゾーンファイル３２の例である。
【００３２】
ＤＮＳレコードは、ホスト名に対するＩＰアドレスを記述したＡレコードに加えて、送信元ＩＰアドレスと応答ＩＰアドレスとの対応付けがＴＸＴレコードとして、グループに属するクライアント端末の数だけ記載される。
例えば、ホスト名「ａｂｃ」に対して、送信元ＩＰアドレス「１０．１０．１０．５３」と、応答ＩＰアドレスとしてのエッジサーバ３のＩＰアドレス「１１．１１．１１．７６」とが連結して記載される。
【００３３】
図５は、本実施形態に係るＤＮＳサーバ１における初期設定処理を示すフローチャートである。
本処理は、ＤＮＳサーバ１の管理者による操作入力に応じて実行される。
【００３４】
ステップＳ１において、ＤＮＳサーバ１は、設定ファイル３１へＡＣＬコードを追加する。
ステップＳ２において、ＤＮＳサーバ１は、設定ファイル３１へＶＩＥＷコードを追加する。
【００３５】
ステップＳ３において、ＤＮＳサーバ１は、送信元ＩＰアドレス及びドメイン名の追加があるか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１に戻り、判定がＮＯの場合、処理はステップＳ４に移る。
【００３６】
ステップＳ４において、ＤＮＳサーバ１は、ゾーンファイルへＴＸＴレコードを追加する。
【００３７】
ステップＳ５において、ＤＮＳサーバ１は、送信元ＩＰアドレス及び応答ＩＰアドレスの追加があるか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ４に戻り、判定がＮＯの場合、処理はステップＳ５に移る。
【００３８】
ステップＳ６において、ＤＮＳサーバ１は、プラグイン処理部１０及び標準処理部２０においてＤＮＳクエリを受信するための監視ポートを、衝突が発生しないように別々に設定する。具体的には、ＤＮＳサーバ１がＤＮＳクエリを受信するポート番号である５３番がプラグイン処理部１０（プラグインアプリケーション）に割り当てられ、未使用の特定ポート（例えば、５００００番）が標準処理部２０（標準アプリケーション）に割り当てられる。
【００３９】
プラグイン処理部１０は、応答制御部１１（受信部、送信部）と、読込部１２と、特定部１３とを備えることにより、クライアント端末２から受信するＤＮＳクエリを、プラグインの名前解決処理又は標準の名前解決処理に分岐させ、いずれかの処理結果を応答する。
【００４０】
応答制御部１１は、クライアント端末２からＤＮＳクエリを受信すると、送信元ＩＰアドレスに基づいて、このＤＮＳクエリを特定部１３又は標準処理部２０へ転送する。
具体的には、応答制御部１１は、受信したＤＮＳクエリのＦＱＤＮ及び送信元ＩＰアドレスと、読込部１２により読み込まれる設定ファイル３１とを照合する。応答制御部１１は、対応するＡＣＬコード及びＶＩＥＷコードがある場合、ＤＮＳクエリを特定部１３に提供し、対応するＡＣＬコード及びＶＩＥＷコードがない場合、ＤＮＳクエリを標準処理部２０へ特定ポート（例えば、５００００番）により転送する。
【００４１】
また、応答制御部１１は、特定部１３又は標準処理部２０によって名前解決された応答ＩＰアドレスを受け取り、ＤＮＳクエリに対するＤＮＳ応答としてクライアント端末２へ送信する。
【００４２】
読込部１２は、記憶部３０から設定ファイル３１を読み込み、応答制御部１１へ提供する。
また、読込部１２は、応答制御部１１により受信したＤＮＳクエリの送信元ＩＰアドレスが属するグループに対応するゾーンファイル３２から、送信元ＩＰアドレスと応答ＩＰアドレスとが対応付けられたＴＸＴレコードを読み込み、応答ＩＰアドレスを１次元配列として展開する。
【００４３】
具体的には、読込部１２は、設定ファイル３１のうち、対応するＡＣＬコード及びＶＩＥＷコードが応答制御部１１で判定されると、このＶＩＥＷコードに記載されたゾーンファイル３２を読み込む。
このとき、送信元ＩＰアドレスの最下位のセクションである第４オクテットのビット列で表現される数値（０〜２５５）の順に、応答ＩＰアドレスを１次元配列としてメモリに展開する。
【００４４】
読込部１２は、プラグインアプリケーションの起動時にファイル群を読み込まず、ＤＮＳクエリを受信した際に必要なデータを読み込む。したがって、プラグイン処理部１０は、必要なデータのみを効率良く取得できると共に、たとえ標準処理部２０によりファイル群のいずれかが更新された場合にも最新の設定情報を利用できる。
【００４５】
図６は、本実施形態に係るプラグイン処理部１０においてメモリ上に展開される応答ＩＰアドレスの１次元配列の例を示す図である。
送信元ＩＰアドレスのホスト部、すなわち第４オクテットの８ビットで表現される数値０〜２５５を配列番号として、それぞれに対応する応答ＩＰアドレスが１次元配列として並べられる。
例えば、送信元ＩＰアドレス「１０．１０．１０．５３」に対しては、配列番号５３の位置に応答ＩＰアドレス「１１．１１．１１．７６」が配置されている。
【００４６】
特定部１３は、１次元配列から、ＤＮＳクエリの送信元ＩＰアドレスにおける第４オクテットのビット列が表す数値に対応する位置にある応答ＩＰアドレスを特定し、応答制御部１１へ提供する。
【００４７】
標準処理部２０は、読込部２１と、標準名前解決部２２とを備えることにより、ＤＮＳクエリに対して、標準の名前解決処理の結果を応答する。
【００４８】
読込部２１は、標準アプリケーションが起動されたタイミングで、記憶部３０から設定ファイル３１及びゾーンファイル３２を読み込み、標準名前解決部２２へ提供する。
【００４９】
標準名前解決部２２は、プラグイン処理部１０からＤＮＳクエリを受信すると、読込部２１により読み込まれた設定ファイル３１、及びゾーンファイル３２のＤＮＳレコードに基づいて名前解決し、応答ＩＰアドレスをプラグイン処理部１０へ提供する。
このとき、標準名前解決部２２は、ゾーンファイル３２に含まれるＤＮＳレコードのうち、初期設定処理で追加されたＴＸＴレコードを除くＡレコードに基づいて応答ＩＰアドレスを抽出する。
【００５０】
図７は、本実施形態に係るＤＮＳサーバ１による名前解決処理を示すシーケンス図である。
ステップＳ１１において、ＤＮＳサーバ１は、記憶部３０のファイル群（設定ファイル３１及びゾーンファイル３２）の初期設定を行う。
【００５１】
ステップＳ１２において、ＤＮＳサーバ１は、プラグインアプリケーション及び標準アプリケーションを起動する。
【００５２】
ステップＳ１３において、ＤＮＳサーバ１（プラグイン処理部１０）は、クライアント端末２からＤＮＳクエリを受信する。
【００５３】
ステップＳ１４において、ＤＮＳサーバ１（プラグイン処理部１０）は、記憶部３０から設定ファイル３１を読み込む。
【００５４】
ステップＳ１５において、ＤＮＳサーバ１（プラグイン処理部１０）は、受信したＤＮＳクエリの送信元ＩＰアドレスに対応するＡＣＬコード及びＶＩＥＷコードが設定ファイル内にあるか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１６に移り、判定がＮＯの場合、処理はステップＳ１７に移る。
【００５５】
ステップＳ１６において、ＤＮＳサーバ１（プラグイン処理部１０）は、記憶部３０のゾーンファイル３２からＴＸＴレコードを読み込んで名前解決し、送信元ＩＰアドレスに対応する応答ＩＰアドレスを特定する。その後、処理はステップＳ２０に移る。
【００５６】
ステップＳ１７において、ＤＮＳサーバ１（プラグイン処理部１０）は、ＤＮＳクエリを標準処理部２０へ転送する。
【００５７】
ステップＳ１８において、ＤＮＳサーバ１（標準処理部２０）は、記憶部３０から読み込んだ設定ファイル３１及びゾーンファイル３２のＡレコードに基づいて名前解決し、応答ＩＰアドレスを特定する。
【００５８】
ステップＳ１９において、ＤＮＳサーバ１（標準処理部２０）は、応答ＩＰアドレスをプラグイン処理部１０へ応答する。
【００５９】
ステップＳ２０において、ＤＮＳサーバ１（プラグイン処理部１０）は、応答ＩＰアドレスをクライアント端末２へ応答する。
【００６０】
本実施形態によれば、ＤＮＳサーバ１は、送信元ＩＰアドレスをグループ分けし、グループ毎に応答ＩＰアドレスを、送信元ＩＰアドレスの所定のビット列を配列番号とした１次元配列に展開する。
これにより、ＤＮＳサーバ１は、送信元ＩＰアドレスに基づいて１回の検索で容易にエッジサーバ３のＩＰアドレスを特定できると共に、メモリ使用量を所定のビット列で表現できる数（例えば、８ビットなら２５６個）のＩＰアドレスの配列分に低減できる。
また、クライアント端末２は、事前設定を必要とせず、従来と同様のＤＮＳクエリをＤＮＳサーバ１に送信することにより、エッジサーバ３のＩＰアドレスを得られるので、エッジサーバ３を用いたサービス提供システム１００の実装が容易になる。
【００６１】
図８は、本実施形態に係る名前解決方法によるＤＮＳレコードの検索回数及びメモリ使用量を、従来の方法と比較して示す図である。
【００６２】
従来の処理方法Ａ（特許文献１）では、ハッシュ探索によってＤＮＳレコードの検索回数を１回に削減できるが、このときのメモリ使用量は、１レコード当たり８Ｂｙｔｅ（送信元ＩＰアドレス４Ｂｙｔｅ＋応答ＩＰアドレス４Ｂｙｔｅ）で、ＤＮＳレコード数が増加するに従って増大（例えば、１００００００レコードに対して８０００ＫＢｙｔｅ）していた。
【００６３】
これに対して、本実施形態の処理方法Ｂでは、ＤＮＳレコードの検索回数が１回に低減されると共に、メモリ使用量は、ＤＮＳレコードの数によらず一定で、約１ＫＢｙｔｅに低減される。具体的には、メモリ使用量は、配列番号となる送信元ＩＰアドレスのホスト部（１Ｂｙｔｅ）と応答ＩＰアドレス（４Ｂｙｔｅ）とが配列数（２５６）だけ必要であり、「２５６×（１Ｂｙｔｅ＋４Ｂｙｔｅ）＝１．２８ＫＢｙｔｅ」となる。
【００６４】
ＤＮＳサーバ１は、特にＩＰアドレスの利用範囲が限られたネットワーク（例えば、モバイルネットワーク）においては、分割されるグループの数を抑えられるため、初期設定の量も抑制できることから、検索回数及びメモリ使用量の削減による処理負荷の低減が顕著となる。
【００６５】
また、ＤＮＳサーバ１は、既存の設定ファイル３１の仕様におけるＡＣＬコード及びＶＩＥＷコードを用いて、グループ毎の送信元ＩＰアドレスの範囲、及びグループに対応するゾーンファイルを規定するので、既存システムに対する改変が抑えられ、容易にサービス提供システム１００が実現される。
【００６６】
また、ＤＮＳサーバ１は、送信元ＩＰアドレスの最下位のセクションである第４オクテットを配列番号としてグループを形成するので、対応付けが簡便であり、かつ、グループ内のＩＰアドレスの数を適度に抑えることができる。
【００６７】
また、ＤＮＳサーバ１は、初期設定されたグループのいずれにも属さないＩＰアドレスからＤＮＳクエリを受信した場合には、既存の標準処理部２０に転送することにより、標準の名前解決処理を実行できる。このように、プラグイン処理部１０が上乗せで実装されることにより、既存の名前解決装置を容易に改変して本実施形態のＤＮＳサーバ１が実現できる。
【００６８】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。
【００６９】
本実施形態では、ＩＰアドレスのバージョンをＩＰｖ４として説明したが、これには限られず、ＩＰｖ６でもよい。ＩＰｖ６の場合、配列番号となる所定のビット列は、最下位の第８セクションであってよい。
【００７０】
また、プラグイン処理部１０は、設定ファイル３１及びゾーンファイル３２を、読込部１２により記憶部３０から直接読み込むこととしたが、これには限られない。例えば、プラグイン処理部１０は、標準処理部２０へ要求することによりデータを取得し、記憶部３０のファイル群に対するインタフェースを統一してもよい。
【００７１】
ＤＮＳサーバ１による制御方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（ＤＮＳサーバ１）にインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。さらに、これらのプログラムは、ダウンロードされることなくネットワークを介したＷｅｂサービスとしてユーザのコンピュータ（ＤＮＳサーバ１）に提供されてもよい。
【符号の説明】
【００７２】
１  ＤＮＳサーバ（名前解決装置）
２  クライアント端末
３  エッジサーバ
４  クラウドサーバ
１０  プラグイン処理部
１１  応答制御部（受信部、送信部）
１２  読込部
１３  特定部
２０  標準処理部
２１  読込部
２２  標準名前解決部
３０  記憶部（第１記憶部、第２記憶部）
３１  設定ファイル
３２  ゾーンファイル
１００  サービス提供システム
【図１】
0006484166.tif 000002
【図２】
0006484166.tif 000003
【図３】
0006484166.tif 000004
【図４】
0006484166.tif 000005
【図５】
0006484166.tif 000006
【図６】
0006484166.tif 000007
【図７】
0006484166.tif 000008
【図８】
0006484166.tif 000009