特許 5987690 ネームデータベースサーバ、名前解決システム、エントリ検索方法およびエントリ検索プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5987690

(24)【登録日】2016年8月19日

(45)【発行日】2016年9月7日

(54)【発明の名称】ネームデータベースサーバ、名前解決システム、エントリ検索方法およびエントリ検索プログラム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20160825BHJP

【ＦＩ】

   H04L12/70 B

【請求項の数】12

【全頁数】32

(21)【出願番号】特願2012-539581(P2012-539581)

(86)(22)【出願日】2011年10月11日

(86)【国際出願番号】JP2011005687

(87)【国際公開番号】WO2012053162

(87)【国際公開日】20120426

【審査請求日】2014年9月5日

(31)【優先権主張番号】特願2010-233412(P2010-233412)

(32)【優先日】2010年10月18日

(33)【優先権主張国】JP

【前置審査】

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103090

【弁理士】

【氏名又は名称】岩壁 冬樹

(74)【代理人】

【識別番号】100124501

【弁理士】

【氏名又は名称】塩川 誠人

(72)【発明者】

【氏名】北村 浩

【審査官】 安藤 一道

(56)【参考文献】

【文献】 特許第３８２８８９４（ＪＰ，Ｂ２）

【文献】 米国特許出願公開第２０１０／００１１４２０（ＵＳ，Ａ１）

【文献】 特開平０５−０１２３３５（ＪＰ，Ａ）

【文献】 北村 浩他，ＩＰｖ６導入環境を改善するＩＰｖ４／ＩＰｖ６混在通信におけるＤＮＳ名前解決処理方式，電子情報通信学会技術研究報告，２０１１年 ２月２４日，Vol.110 No.449，pp.55-60

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

(57)【特許請求の範囲】

【請求項1】

少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、
仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、エントリを特定する情報であるエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを送信して当該エントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、
前記ノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、前記検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、
前記エントリ検索手段が特定したエントリに含まれるノード情報を前記端末装置に送信する検索結果送信手段とを備え、
前記検索対象レコード決定手段は、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、当該仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定する
ことを特徴とするネームデータベースサーバ。

【請求項2】

検索対象レコード決定手段は、ノード情報記憶手段に記憶されるレコードタイプとは異なる仮想のレコードタイプに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した文字列からレコードタイプを決定する
請求項１記載のネームデータベースサーバ。

【請求項3】

検索対象レコード決定手段は、仮想のレコードタイプとホスト名とを受信した場合に、ＩＰｖ６アドレスを示すレコードタイプ及びＩＰｖ４アドレスを示すレコードタイプを、検索対象とするエントリのレコードタイプとして決定し、
エントリ検索手段は、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、ＩＰｖ６アドレスを示すレコードタイプ及びＩＰｖ４アドレスを示すレコードタイプのエントリを特定する
請求項１または請求項２記載のネームデータベースサーバ。

【請求項4】

ノード情報を問い合わせる端末装置と、
前記端末装置からの問い合わせを受信するネームデータベースサーバとを備え、
前記端末装置は、
ネームデータベースサーバが記憶するエントリを特定するエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを前記ネームデータベースサーバに送信して、当該ノード情報を問い合わせるアドレス問合せ手段を備え、
前記ネームデータベースサーバは、
少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、
仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、
前記ノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、前記検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、
前記エントリ検索手段が特定したエントリに含まれるノード情報を前記端末装置に送信する検索結果送信手段とを備え、
前記検索対象レコード決定手段は、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、当該仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定する
ことを特徴とする名前解決システム。

【請求項5】

端末装置のアドレス問合せ手段は、名前解決を行う対象のホスト名と、ノード情報記憶手段に記憶されるレコードタイプとは異なる仮想のレコードタイプとを前記ネームデータベースサーバに送信して、当該ホスト名に対応するアドレスを問い合わせ、
前記ネームデータベースサーバの検索対象レコード決定手段は、前記文字列に応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した仮想のレコードタイプからレコードタイプを決定する
請求項４記載の名前解決システム。

【請求項6】

検索対象レコード決定手段は、仮想のレコードタイプとノード名とを受信した場合に、ＩＰｖ６アドレスを示すレコードタイプ及びＩＰｖ４アドレスを示すレコードタイプを、検索対象とするエントリのレコードタイプとして決定し、
エントリ検索手段は、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、ＩＰｖ６アドレスを示すレコードタイプ及びＩＰｖ４アドレスを示すレコードタイプのエントリを特定する
請求項５または請求項６記載の名前解決システム。

【請求項7】

仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、エントリを特定する情報であるエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを送信して当該エントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した当該仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、
前記エントリを記憶するノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、
前記レコードタイプのエントリを特定する際、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、当該仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定し、
特定されたエントリに含まれるノード情報を前記端末装置に送信する
ことを特徴とするエントリ検索方法。

【請求項8】

レコードタイプを決定する際、ノード情報記憶手段に記憶されるレコードタイプを示す文字列とは異なる仮想のレコードタイプに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した文字列からレコードタイプを決定する
請求項７記載のエントリ検索方法。

【請求項9】

ノード情報を問い合わせる端末装置が、当該問い合わせに対してノード情報を応答するネームデータベースサーバが記憶するエントリを特定するエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを、当該ネームデータベースサーバに送信して、当該ノード情報を問い合わせ、
前記ネームデータベースサーバが、
仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、
少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、
前記レコードタイプのエントリを特定する際、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、当該仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定し、
特定されたエントリに含まれるノード情報を前記端末装置に送信する
ことを特徴とする名前解決方法。

【請求項10】

端末装置が、名前解決を行う対象のホスト名と、ノード情報記憶手段に記憶されるレコードタイプを示す文字列とは異なる仮想のレコードタイプとをネームデータベースサーバに送信して、当該ホスト名に対応するアドレスを問い合わせ、
ネームデータベースサーバは、前記文字列に応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した仮想のレコードタイプからレコードタイプを決定する
請求項９記載の名前解決方法。

【請求項11】

少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を備えたコンピュータに適用されるエントリ検索プログラムであって、
前記コンピュータに、
仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、エントリを特定する情報であるエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを送信して当該エントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定処理、
前記ノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、前記検索対象レコード決定処理で決定されたレコードタイプのエントリを特定するエントリ検索処理、および、
前記エントリ検索処理で特定されたエントリに含まれるノード情報を前記端末装置に送信する検索結果送信処理を実行させ、
前記検索対象レコード決定処理で、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、当該仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定させる
ためのエントリ検索プログラム。

【請求項12】

コンピュータに、
検索対象レコード決定処理で、ノード情報記憶手段に記憶されるレコードタイプとは異なる仮想のレコードタイプに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した文字列からレコードタイプを決定させる
請求項１１記載のエントリ検索プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のレコードタイプが混在する通信環境で名前解決を行う際に用いられるネームデータベースサーバ、名前解決システム、エントリ検索方法、名前解決方法およびエントリ検索プログラムに関する。

【背景技術】

【0002】

ＩＰｖ４（Internet Protocol version 4 ）の通信環境から始まったインターネットに、ＩＰｖ６（Internet Protocol version 6 ）の通信環境が新たに導入されてきている。現在のインターネットは、ＩＰｖ６環境導入の途上にある。そのため、その導入過程では、ＩＰｖ４のみに対応した通信装置、既存のＩＰｖ４に対応する機能に加えてＩＰｖ６に対応する機能の一部が実装された通信装置、ＩＰｖ６に対応する機能を完全に実装し、ＩＰｖ４及びＩＰｖ６に対応した全ての機能が使える通信装置、といった複数の種類の通信装置が混在する。

【0003】

図１５は、ＩＰｖ４のみの通信環境において名前解決を行う場合の説明図である。図１５は、ホスト名「ｈｏｓｔＸ」に対し、レコードタイプを「Ａ」とするＩＰｖ４アドレスｐ、ｑのエントリが２つＤＮＳ（Domain Name System）サーバに登録されていることを示す。クライアント端末からＤＮＳサーバに対し、ＩＰｖ４のレコードタイプ「Ａ」を指定してホスト名「ｈｏｓｔＸ」のアドレスを問い合わせるパケットが送信されると、ＤＮＳサーバは、ｈｏｓｔＸに対応するＩＰｖ４アドレスを含むエントリを検索する。そして、ＤＮＳサーバは、検索したＩＰｖ４アドレスを含むパケットをクライアント端末に送信する。図１５に示す例では、ＤＮＳサーバは、ｈｏｓｔＸのＩＰｖ４アドレスとしてアドレスｐ及びｑを含むパケットを、クライアント端末に送信する。以下、ホスト名とレコードタイプとを指定して、ホスト名に対応するアドレスを問い合わせるパケットを、ＤＮＳクエリパケットと記す。

【0004】

一方、上述した複数の種類の通信装置が混在している環境において、ＩＰｖ６の新しい機能を導入するには、様々な要件が課せられる。まず、現在動作している既存の環境において、通信が出来なくなるといった問題を生じさせないことである。また、ＩＰｖ４とＩＰｖ６両方の情報が存在する場合、新しいＩＰｖ６の方を優先して選択できるようにすることである。

【0005】

ＩＰｖ４とＩＰｖ６とが混在する通信環境において名前解決を行う方法が、各種提案されている。図１６は、ＩＰｖ４とＩＰｖ６とが混在する通信環境でＤＮＳサーバが記憶する情報の例を示す説明図である。以下、ＩＰｖ６アドレスのレコードタイプを「ＡＡＡＡ」と記し、ＩＰｖ４アドレスのレコードタイプを「Ａ」と記す。また、図１６は、ホスト名「ｈｏｓｔＸ」に対し、レコードタイプを「Ａ」とするＩＰｖ４アドレスｐ、ｑのエントリが２つ、レコードタイプを「ＡＡＡＡ」とするＩＰｖ６アドレスｓ、ｔのエントリが２つ、合計４つのエントリがＤＮＳ（Domain Name System）サーバに登録されていることを示す。以下、ＩＰｖ４とＩＰｖ６とが混在する通信環境で名前解決が行われる場合、ＤＮＳサーバが図１６に示す情報を記憶しているものとして説明する。

【0006】

ここで、ＤＮＳにおいてアドレスを問い合わせる装置（例えば、クライアント端末）が用いるＡＰＩ（Application Programming Interface ）を説明する。ＤＮＳにおける名前解決処理には、原始的な処理を行う低級ＡＰＩの集合であるｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙが用いられる。具体的には、ＤＮＳにおいて、サーバ側が備えるデータベースに記憶されたデータそのものを直接抽出するような低級な処理を行うコマンド（例えば、ｎｓｌｏｏｋｕｐ、ｄｉｇ、ｈｏｓｔなど）が、このｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙに含まれる。

【0007】

一方、ユーザランドにおいて用いられる通信アプリケーションは、直接ｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙを呼び出さず、高級ＡＰＩを用いることが一般的である。高級ＡＰＩの内部では、ｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙが用いられるが、ユーザは、その内部のＡＰＩを意識する必要はない。

【0008】

具体的には、ＩＰｖ４のみの通信環境では、高級ＡＰＩとしてｇｅｔｈｏｓｔｂｙｎａｍｅ（）が用いられていた。しかし、ＩＰｖ６の登場とともに、ＩＰｖ４のみの通信環境に対応したｇｅｔｈｏｓｔｂｙｎａｍｅ（）は使われなくなり、現在では、ｇｅｔａｄｄｒｉｎｆｏ（）が用いられている。ｇｅｔａｄｄｒｉｎｆｏ（）は、ＩＰｖ４及びＩＰｖ６両方のプロトコル（マルチプロトコル）に対応した関数である。ｇｅｔａｄｄｒｉｎｆｏ（）関数では、レコードタイプ（具体的には、ネットワークアドレスの種類を表すアドレスファミリ）を指定して問い合わせが行われる。アドレスファミリには、ＩＰｖ４（ＰＦ＿ＩＮＥＴ）、ＩＰｖ６（ＰＦ＿ＩＮＥＴ６）、または、どちらでもよい（ＰＦ＿ＵＮＳＰＥＣ）のいずれかが指定される。なお、問い合わせ結果（アドレス）は、リストの形式で返却される。

【0009】

ユーザランドのアプリケーション側では、レコードタイプを気にせずに問い合わせができることが期待される。一方、ＤＮＳサーバ側では、ＩＰｖ４とＩＰｖ６のいずれのアドレスも管理する必要がある。したがって、最終的には、ＤＮＳサーバがＩＰｖ４とＩＰｖ６のいずれのアドレスも管理する状況で、クライアント側がアドレスファミリとしてＰＦ＿ＵＮＳＰＥＣを指定した問合せを行うことが想定される。

【0010】

具体的には、高級ＡＰＩでは、レコードタイプを意識せずに（例えば、ＰＦ＿ＵＮＳＰＥＣを指定した）通信アプリケーションが作成される。一方、ｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙは、高級ＡＰＩから呼び出されると、名前解決するレコードタイプを指定して、ＤＮＳサーバにアドレスを問い合わせることになる。これは、ＤＮＳサーバがエントリを検索する際、アドレスとレコードタイプとが必要になるからである。

【0011】

図１７〜図２１は、ＩＰｖ４とＩＰｖ６とが混在する通信環境でＤＮＳサーバにアドレスを問い合わせる動作を示す説明図である。以下、ＩＰｖ４アドレスを含むエントリをＡレコードと記し、ＩＰｖ６アドレスを含むエントリをＡＡＡＡレコードと記す。

【0012】

図１７に示す方法は、ＤＮＳサーバに対し、まず、ホスト名に対応するＡレコードを問い合わせ、その応答が戻ってきた後で（すなわち、戻るまで待機してから）、ＡＡＡＡレコードを問い合わせる方法である。図１７に示す方法では、まず、クライアントがホスト名「ｈｏｓｔＸ」とレコードタイプ「Ａ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そうすると、ＤＮＳサーバは、対応するＩＰｖ４アドレスｐ、ｑを検索し、検索したアドレスを含むパケットをクライアントに送信する。ＩＰｖ４アドレスを含むパケットを受信したクライアントは、次に、ホスト名「ｈｏｓｔＸ」とレコードタイプ「ＡＡＡＡ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そうすると、ＤＮＳサーバは、対応するＩＰｖ６アドレスｓ、ｔを検索し、検索したアドレスを含むパケットをクライアントに送信する。

【0013】

図１８に示す方法は、ＤＮＳサーバに対し、まず、ホスト名に対応するＡレコードを問い合わせ、戻ってきた応答内容によって、ＡＡＡＡレコードを問い合わせる否かを判断する方法である。すなわち、図１８に示す方法は、ＩＰｖ４アドレスｐ，ｑの応答内容によって、ＡＡＡＡレコードを問い合わせる否かを判断する点において図１７に示す方法と異なる。図１７に示す方法では、まず、クライアントがホスト名「ｈｏｓｔＸ」とレコードタイプ「Ａ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そうすると、ＤＮＳサーバは、対応するＩＰｖ４アドレスｐ、ｑを検索し、検索したアドレスを含むパケットをクライアントに送信する。ＩＰｖ４アドレスを含むパケットを受信したクライアントは、そのパケットに含まれる内容によって、ホスト名「ｈｏｓｔＸ」とレコードタイプ「ＡＡＡＡ」とを指定したＤＮＳクエリパケットをＤＮＳサーバに送信するか否かを判断する。なお、ＤＮＳクエリパケットをＤＮＳサーバに送信すると判断した場合、以降の処理は、図１７に示す方法と同様である。

【0014】

図１９に示す方法は、ＤＮＳサーバに対し、まず、ホスト名に対応するＡレコードを問い合わせ、その応答を待たずして、ＡＡＡＡレコードを問い合わせる方法である。図１９に示す方法では、まず、クライアントがホスト名「ｈｏｓｔＸ」とレコードタイプ「Ａ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そして、クライアントは、ＩＰｖ４アドレスを含むパケットを受信する前に、ホスト名「ｈｏｓｔＸ」とレコードタイプ「ＡＡＡＡ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。なお、ＤＮＳサーバが、受信したＤＮＳクエリパケットに応じてクライアントに送信するパケットの内容は、図１７に示す内容と同様である。

【0015】

図２０に示す方法は、ＤＮＳサーバに対し、まず、ホスト名に対応するＡＡＡＡレコードを問い合わせ、その応答が戻ってきた後で、Ａレコードを問い合わせる方法である。すなわち、図２０に示す方法は、ＡレコードとＡＡＡＡレコードを問い合わせる順番が逆になっている点において図１７に示す方法と異なる。具体的には、まず、クライアントがホスト名「ｈｏｓｔＸ」とレコードタイプ「ＡＡＡＡ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そうすると、ＤＮＳサーバは、対応するＩＰｖ６アドレスｓ、ｔを検索し、検索したアドレスを含むパケットをクライアントに送信する。ＩＰｖ６アドレスを含むパケットを受信したクライアントは、次に、ホスト名「ｈｏｓｔＸ」とレコードタイプ「Ａ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そうすると、ＤＮＳサーバは、対応するＩＰｖ４アドレスｐ、ｑを検索し、検索したアドレスを含むパケットをクライアントに送信する。

【0016】

図２１に示す方法は、ＤＮＳサーバに対し、まず、ホスト名に対応するＡＡＡＡレコードを問い合わせ、その応答を待たずして、Ａレコードを問い合わせる方法である。図２１に示す方法では、まず、クライアントがホスト名「ｈｏｓｔＸ」とレコードタイプ「ＡＡＡＡ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。そして、クライアントは、ＩＰｖ６アドレスを含むパケットを受信する前に、ホスト名「ｈｏｓｔＸ」とレコードタイプ「Ａ」を指定したＤＮＳクエリパケットをＤＮＳサーバに送信する。なお、ＤＮＳサーバが、受信したＤＮＳクエリパケットに応じてクライアントに送信するパケットの内容は、図２０に示す内容と同様である。

【0017】

このように、ＤＮＳサーバがホスト名に対するＩＰｖ４アドレスとＩＰｖ６アドレスのいずれのエントリも記憶している場合、クライアントは、ホスト名及びＩＰｖ４アドレスのレコードタイプを指定したＤＮＳクエリパケットと、ホスト名及びＩＰｖ６アドレスのレコードタイプを指定したＤＮＳクエリパケットをそれぞれ送信する。このようにすることで、クライアントは、ホスト名に対するＩＰｖ６アドレスとＩＰｖ４アドレスの両方のアドレスを取得できる。

【0018】

なお、特許文献１には、ＩＰｖ４アドレスとＩＰｖ６アドレスとが混在した環境で名前解決を行う通信装置が記載されている。特許文献１に記載された通信装置は、まず、ＩＰｖ４アドレス空間における名前解決を行うＤＮＳサーバに名前解決を依頼する。ＩＰｖ４アドレスが得られなかった場合、上記通信装置は、ＩＰｖ６アドレス空間における名前解決を行うＤＮＳサーバに対して問合せを行うＤＮＳプロキシサーバに、再度名前解決を依頼する。

【先行技術文献】

【特許文献】

【0019】

【特許文献1】特開２０１０−１８３２４２号公報

【発明の概要】

【発明が解決しようとする課題】

【0020】

ＩＰｖ６通信環境の新たな導入に伴い、図１７〜図２１に示すように、ＩＰｖ４アドレスのみ存在していた際の方法を残し、この方法とは独立して、ＩＰｖ６アドレス用に新しい問い合わせを行う方法が追加されてきた。そのため、結果として、今までは一つのホスト名に対する問い合わせが一回で済んでいたのに対し、図１７〜図２１に示す方法では、問い合わせを二回することになる。

【0021】

一方、問い合わせを二回必要とすることから、各アドレスの問い合わせパターンは複数存在することになる。さらに、先の問い合わせの応答内容によって、その後の処理を決める方法を考慮した場合、その処理方法は、より複雑になる。

【0022】

さらに、それぞれの問い合わせに対し、サーバからは別々に応答が返ってくるため、クライアントは、応答内容を一度に集めることが出来ない。そのため、一方が応答するまで他方が待たされることで、応答完了までの時間がよりかかってしまう。また、一方の問い合わせに用いられるパケットが欠落した場合まで想定すると、それぞれの応答内容を考慮した処理はさらに複雑になる。このような複雑さから、当初想定していなかった問題が発生することもあった。

【0023】

また、問い合わせが２回発生することから、問い合わせで発生するネットワークトラフィック量も２倍になる。このように、問い合わせの回数は一回増えるだけだが、考慮しなければならない事項は多数存在する。

【0024】

特許文献１に記載された通信装置も、図１８に示す方法と同様に、一方の問い合わせの応答内容によって、問い合わせが複数回発生する。このような複雑な構成にすることなく、一回の問い合わせで複数のレコードタイプのノード情報を取得できることが望ましい。

【0025】

そこで、本発明は、一度の問い合わせで、複数のレコードタイプのノード情報を取得できるネームデータベースサーバ、名前解決システム、エントリ検索方法、名前解決方法およびエントリ検索プログラムを提供することを目的とする。

【課題を解決するための手段】

【0026】

本発明によるネームデータベースサーバは、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、エントリを特定する情報であるエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを送信してそのエントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、ノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、エントリ検索手段が特定したエントリに含まれるノード情報を端末装置に送信する検索結果送信手段とを備え、検索対象レコード決定手段が、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、その仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定することを特徴とする。

【0027】

本発明による名前解決システムは、ノード情報を問い合わせる端末装置と、端末装置からの問い合わせを受信するネームデータベースサーバとを備え、端末装置が、ネームデータベースサーバが記憶するエントリを特定するエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットをネームデータベースサーバに送信して、そのノード情報を問い合わせるアドレス問合せ手段を備え、ネームデータベースサーバが、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、ノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、エントリ検索手段が特定したエントリに含まれるノード情報を端末装置に送信する検索結果送信手段とを備え、検索対象レコード決定手段が、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、その仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定することを特徴とする。

【0028】

本発明によるエントリ検索方法は、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、エントリを特定する情報であるエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを送信してそのエントリ特定情報に対応するノード情報を問い合わせる端末装置から受信したその仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、エントリを記憶するノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、レコードタイプのエントリを特定する際、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、その仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定し、特定されたエントリに含まれるノード情報を端末装置に送信することを特徴とする。

【0029】

本発明による名前解決方法は、ノード情報を問い合わせる端末装置が、その問い合わせに対してノード情報を応答するネームデータベースサーバが記憶するエントリを特定するエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを、そのネームデータベースサーバに送信して、そのノード情報を問い合わせ、ネームデータベースサーバが、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、レコードタイプのエントリを特定する際、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、その仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定し、特定されたエントリに含まれるノード情報を端末装置に送信することを特徴とする。

【0030】

本発明によるエントリ検索プログラムは、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を備えたコンピュータに適用されるエントリ検索プログラムであって、コンピュータに、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、エントリを特定する情報であるエントリ特定情報を含み、かつ、ドメインネームシステムで規定されるクエリパケットのレコード指定部分に仮想のレコードタイプを含むパケットを送信してそのエントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定処理、ノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定処理で決定されたレコードタイプのエントリを特定するエントリ検索処理、および、エントリ検索処理で特定されたエントリに含まれるノード情報を端末装置に送信する検索結果送信処理を実行させ、検索対象レコード決定処理で、予め定めた仮想レコードタイプに一致するレコードタイプを受信したときに、その仮想レコードタイプに対応付けて定義された複数のレコードタイプを、検索対象とするエントリのレコードタイプと決定させることを特徴とする。

【発明の効果】

【0031】

本発明によれば、一度の問い合わせで、複数のレコードタイプのホスト情報を取得できる。

【図面の簡単な説明】

【0032】

【図1】名前解決を行う動作の例を示す説明図である。

【図2】本発明の第１の実施形態における名前解決システムの例を示すブロック図である。

【図3】名前解決を行う動作の例を示すシーケンス図である。

【図4】名前解決を行う動作の例を示す説明図である。

【図5】本発明の第２の実施形態における名前解決システムの例を示すブロック図である。

【図6】名前解決を行う動作の例を示すシーケンス図である。

【図7】名前解決を行う動作の例を示す説明図である。

【図8】本発明の第３の実施形態における名前解決システムの例を示すブロック図である。

【図9】名前解決を行う動作の例を示すシーケンス図である。

【図10】名前解決を行う動作の例を示す説明図である。

【図11】本発明の第４の実施形態における名前解決システムの例を示すブロック図である。

【図12】名前解決を行う動作の例を示すシーケンス図である。

【図13】本発明による名前解決システムの最小構成の例を示すブロック図である。

【図14】本発明によるネームデータベースサーバの最小構成の例を示すブロック図である。

【図15】ＩＰｖ４のみの通信環境において名前解決を行う場合の説明図である。

【図16】ＤＮＳサーバが記憶する情報の例を示す説明図である。

【図17】ＤＮＳサーバにアドレスを問い合わせる動作を示す説明図である。

【図18】ＤＮＳサーバにアドレスを問い合わせる動作を示す説明図である。

【図19】ＤＮＳサーバにアドレスを問い合わせる動作を示す説明図である。

【図20】ＤＮＳサーバにアドレスを問い合わせる動作を示す説明図である。

【図21】ＤＮＳサーバにアドレスを問い合わせる動作を示す説明図である。

【発明を実施するための形態】

【0033】

以下、本発明の実施形態を図面を参照して説明する。

【0034】

実施形態１．
まず、図１を参照して、第１の実施形態における名前解決システムの概要を説明する。図１は、名前解決を行う動作の例を示す説明図である。第１の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名（図１では、「ｈｏｓｔＸ」）とレコードタイプ（図１では、「ＡＡＡＡ＋Ａ」）とを指定したＤＮＳクエリパケットをＤＮＳサーバに対して送信する。ここで指定されるレコードタイプ「ＡＡＡＡ＋Ａ」とは、「Ａ」や「ＡＡＡＡ」といったＤＮＳサーバに記憶されるレコードタイプとは異なる仮想のレコードタイプである。

【0035】

仮想のレコードタイプには、任意の情報を設定することが可能である。例えば、既存のＤＮＳに存在しないレコードタイプを新たに定義し、そのレコードタイプを表す情報を、仮想のレコードタイプとして使用してもよい。なお、以下の説明では、便宜上、仮想のレコードタイプを「ＡＡＡＡ＋Ａ」と記す。ただし、仮想のレコードタイプは、「ＡＡＡＡ＋Ａ」の一種類に限られず、複数種類あってもよい。この仮想のレコードタイプは、ユーザ等により予め定められる。なお、仮想のレコードタイプとは、クエリパケットでレコードを指定する部分に指定されるレコードタイプであって、ＤＮＳで定義されていないレコードタイプと言うこともできる。

【0036】

次に、ＤＮＳクエリパケットを受信したＤＮＳサーバは、指定された仮想のレコードタイプ「ＡＡＡＡ＋Ａ」に応じて予め定められたルールに従って、検索対象のレコードタイプを決定する。そして、ＤＮＳサーバは、決定したレコードタイプ及び受信したホスト名に対応するエントリを検索する。図１に示す例では、レコードタイプ「ＡＡＡＡ」及び「Ａ」のエントリが検索される。そして、ＤＮＳサーバは、検索したエントリに含まれるＩＰｖ６アドレスおよびＩＰｖ４アドレス（図１では、ｓ，ｔ，ｐ，ｑ）を含む返信パケットをクライアントに送信する。

【0037】

すなわち、第１の実施形態における名前解決システムは、エントリを特定する情報（例えば、ホスト名やアドレス。以下、エントリ特定情報と記す。）とレコードタイプ「ＡＡＡＡ＋Ａ」とを指定したパケットをＤＮＳサーバに１回送信するだけで、対応するノード情報（例えば、ＩＰｖ６アドレスおよびＩＰｖ４アドレス、ホスト名）を含むパケットを一度に取得することができるものである。なお、以下の説明では、ドメイン名から対応するＩＰアドレスを解決する場合（正引きの場合）について説明する。ただし、本実施形態における名前解決システムでは、ＩＰアドレスから対応するホスト名を解決する場合（逆引きの場合）にも適用可能である。以下、第１の実施形態における名前解決システムの内容を、詳しく説明する。

【0038】

図２は、本発明の第１の実施形態における名前解決システムの例を示すブロック図である。本実施形態における名前解決システムは、端末装置１０と、ネームデータベースサーバ２０とを備えている。ネームデータベースサーバ２０は、例えば、ＤＮＳサーバにより実現される。ただし、ネームデータベースサーバ２０は、ＤＮＳサーバに限定されない。

【0039】

端末装置１０は、アドレス問合せ手段１１を備えている。アドレス問合せ手段１１は、仮想のレコードタイプとエントリ特定情報（例えば、名前解決を行う対象のホスト名やアドレス）とをネームデータベースサーバ２０に送信し、対応するノード情報の問い合わせを行う。なお、仮想のレコードタイプには、後述するノード情報記憶手段２１に記憶されたレコードタイプに存在しない予め定められた情報（すなわち、上述する「ＡＡＡＡ＋Ａ」）が指定される。

【0040】

アドレス問合せ手段１１は、例えば、プログラムに従って動作するコンピュータ（端末装置１０）のＣＰＵによって実現される。

【0041】

なお、アドレス問合せ手段１１がネームデータベースサーバ２０に送信するエントリ特定情報はホスト名やアドレス及び仮想のレコードタイプに限定されない。アドレス問合せ手段１１は、例えば、端末装置１０自身のアドレスなどをネームデータベースサーバ２０に送信してもよい。なお、アドレス問合せ手段１１がネームデータベースサーバ２０に問い合わせるレコードタイプは、例えば、他の高級ＡＰＩ（図示せず）等により指定される。

【0042】

ネームデータベースサーバ２０は、ノード情報記憶手段２１と、検索対象レコード決定手段２２と、エントリ検索手段２３と、検索結果送信手段２４とを備えている。

【0043】

ノード情報記憶手段２１は、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶する。具体的には、ノード情報記憶手段２１は、少なくともＩＰｖ６アドレスおよびＩＰｖ４アドレスをホスト名と対応付けたエントリを記憶する。ノード情報記憶手段２１は、例えば、磁気ディスク等により実現される。なお、各アドレス及びレコードタイプに対応付ける情報は、ホスト名に限定されない。ノード情報記憶手段２１は、ゾーンファイルのように、ドメインのホスト情報を示す他の情報を各アドレス及びレコードタイプに対応付けたエントリを記憶していてもよい。

【0044】

ノード情報記憶手段２１に記憶されるエントリは、例えば、ＤＮＳダイナミックアップデートなどの仕組みを用いて、逐次更新される。

【0045】

検索対象レコード決定手段２２は、端末装置１０から受信した仮想のレコードタイプから、検索対象とするエントリのレコードタイプを決定する。具体的には、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルール（以下、検索ルール）を予め定めておく。検索対象レコード決定手段２２は、その検索ルールに従って、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する。具体的には、検索ルールとして、『レコードタイプとして文字列「ＡＡＡＡ＋Ａ」が指定された場合に、検索対象とするレコードタイプを「ＡＡＡＡ」及び「Ａ」とする』と定めておく。このように定めておくことで、後述するエントリ検索手段２３が、仮想のレコードタイプ「ＡＡＡＡ＋Ａ」を受信した場合でも、レコードタイプ「ＡＡＡＡ」及び「Ａ」のエントリを検索することが可能になる。

【0046】

エントリ検索手段２３は、ノード情報記憶手段２１を検索することにより、受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段２２が決定したレコードタイプのエントリを特定する。例えば、検索対象レコード決定手段２２が検索対象とするエントリのレコードタイプを「ＡＡＡＡ」及び「Ａ」と決定したとする。この場合、エントリ検索手段２３は、ノード情報記憶手段２１を検索して、端末装置１０から受信したホスト名に対応するＩＰｖ４アドレスとＩＰｖ６アドレスとを含むエントリを特定する。

【0047】

このように指定された仮想のレコードタイプは、検索対象とするレコードタイプを特定する情報といえる。さらに、この仮想のレコードタイプは、ＤＮＳサーバに検索対象を指示する情報ということもできる。すなわち、このレコードタイプ「ＡＡＡＡ＋Ａ」は、検索対象とするレコードタイプをＤＮＳサーバに指示するコマンドの役割を果たすものと言うことができる。また、問い合わせの際、ＤＮＳサーバに記憶されるレコードタイプとは異なるレコードタイプが用いられることで、既存の仕組みに与える影響を抑えることが出来る。

【0048】

検索結果送信手段２４は、エントリ検索手段２３が特定したエントリに含まれるノード情報を端末装置１０に送信する。なお、対象のエントリが存在しなかった場合、検索結果送信手段２４は、ホスト名に対応するノード情報が存在しなかった旨の情報を含むパケットを、端末装置１０に送信すればよい。

【0049】

検索対象レコード決定手段２２と、エントリ検索手段２３と、検索結果送信手段２４とは、プログラム（エントリ検索プログラム）に従って動作するコンピュータのＣＰＵによって実現される。例えば、プログラムは、ネームデータベースサーバ２０の記憶部（図示せず）に記憶され、ＣＰＵは、そのプログラムを読み込み、プログラムに従って、検索対象レコード決定手段２２、エントリ検索手段２３および検索結果送信手段２４として動作してもよい。また、検索対象レコード決定手段２２と、エントリ検索手段２３と、検索結果送信手段２４とは、それぞれが専用のハードウェアで実現されていてもよい。

【0050】

次に、ホスト名とレコードタイプ「ＡＡＡＡ＋Ａ」とを指定してクライアントからアドレスの問い合わせが行われた場合に、ＤＮＳサーバが、ＩＰｖ４アドレス及びＩＰｖ６アドレスのいずれのアドレスもクライアントに返信する動作を説明する。なお、クライアントが端末装置１０に対応し、ＤＮＳサーバがネームデータベースサーバ２０に対応する。

【0051】

図３は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段１１は、ホスト名と仮想のレコードタイプ「ＡＡＡＡ＋Ａ」とを指定したＤＮＳクエリパケットをＤＮＳサーバに送信して、ホスト名に対するアドレスを問い合わせる（ステップＳ１）。ＤＮＳサーバの検索対象レコード決定手段２２は、仮想のレコードタイプ「ＡＡＡＡ＋Ａ」を含むパケットを受信すると、予め定められた検索ルールに従って、検索対象とするレコードタイプを「ＡＡＡＡ」及び「Ａ」と決定する（ステップＳ２）。

【0052】

次に、エントリ検索手段２３は、ノード情報記憶手段２１を検索して、受信したホスト名に対応するレコードタイプ「ＡＡＡＡ」及び「Ａ」のエントリを特定する（ステップＳ３）。具体的には、エントリ検索手段２３は、ＩＰｖ４アドレスとＩＰｖ６アドレスとを含むエントリを特定する。

【0053】

そして、検索結果送信手段２４は、エントリ検索手段２３が特定したエントリのＩＰｖ４アドレスとＩＰｖ６アドレスとを含むパケットをクライアントに送信する（ステップＳ４）

【0054】

以上のように、本実施形態によれば、端末装置１０のアドレス問合せ手段１１が、仮想のレコードタイプとエントリ特定情報とをネームデータベースサーバ２０に送信して、そのエントリ特定情報に対応するノード情報を問い合わせる。ネームデータベースサーバ２０の検索対象レコード決定手段２２は、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、検索対象とするエントリのレコードタイプを決定する。エントリ検索手段２３は、ノード情報記憶手段２１を検索することにより、受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段２２が決定したレコードタイプのエントリを特定する。そして、検索結果送信手段２４は、エントリ検索手段２３が特定したエントリに含まれるノード情報を端末装置１０に送信する。

【0055】

そのため、一度の問い合わせで、複数のレコードタイプのノード情報を取得できる。具体的には、ＩＰｖ４とＩＰｖ６とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、ＩＰｖ４とＩＰｖ６のいずれについても名前解決できる。例えば、一つのレコードタイプを指定したＤＮＳクエリパケットを一度送信するだけで、ホスト名に対応する複数のレコードタイプ（ＩＰｖ４とＩＰｖ６両方）のアドレスが取得できる。

【0056】

また、クライアント側の処理は、一回の問い合わせで完了するため効率的である。また、各処理がシンプルになることで様々な問題が発生することを抑制できる。さらに、クライアント側は、複数の問い合わせがある場合に比べ、一つの問い合わせに対する応答を待てばよい。そのため、処理が高速になる。また、問い合わせで発生するトラフィック量も減少する。

【0057】

実施形態２．
次に、図４を参照して、第２の実施形態における名前解決システムの概要を説明する。図４は、名前解決を行う動作の例を示す説明図である。第２の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名（図４では、「ｈｏｓｔＸ」）とＩＰｖ６アドレスのレコードタイプ（図４では、「ＡＡＡＡ」）とを指定したＤＮＳクエリパケットをＤＮＳサーバに対して送信する。次に、ＤＮＳクエリパケットを受信したＤＮＳサーバは、受信したホスト名のエントリのうち、指定されたレコードタイプ「ＡＡＡＡ」のエントリだけでなく、レコードタイプ「Ａ」のエントリも検索する。図４に示す例では、この結果、ホスト名「ｈｏｓｔＸ」に一致するエントリに含まれるアドレスｐ，ｑ，ｓ，ｔが特定される。

【0058】

そして、ＤＮＳサーバは、レコードタイプが「Ａ」のＩＰｖ４アドレスｐ，ｑを、受信したレコードタイプのアドレスであるＩＰｖ６アドレスに変換する。以下、ＩＰｖ６アドレスに変換されたアドレスｐ，ｑを、ｐ’，ｑ’と記す。そして、ＤＮＳサーバは、これらのＩＰｖ６アドレスｓ，ｔ， ｐ’，ｑ’を含むパケットをクライアントに送信する。ＩＰｖ６アドレスを受信したクライアントは、変換されたアドレスｐ’，ｑ’を、変換前のＩＰｖ４アドレスｐ，ｑに戻し変換する。

【0059】

ＩＰｖ４アドレスをＩＰｖ６アドレスへ変換する方法として、例えば、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ ＩＰｖ６ Ａｄｄｒｅｓｓ（以下、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓと記す。）へ変換する方法が用いられる。ＩＰｖ４ ｍａｐｐｅｄ ＡｄｄｒｅｓｓからＩＰｖ４アドレスへの変換処理は、通常カーネルで行われる。そのため、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換することで、クライアント側のユーザランドにおけるアプリケーションにおいて、戻し変換処理が不要になる。

【0060】

このように、第２の実施形態における名前解決システムは、ホスト名とＩＰｖ６アドレスのレコードタイプとを指定したパケットをＤＮＳサーバに１回送信するだけで、ホスト名に対応するアドレスを含むパケットを、指定したレコードタイプで一度に取得することができる。さらに、変換されたアドレスを、変換前のアドレスに戻し変換することで、変換されたアドレスをもとのアドレスとして利用できる。以下、第２の実施形態における名前解決システムの内容を、詳しく説明する。

【0061】

図５は、本発明の第２の実施形態における名前解決システムの例を示すブロック図である。なお、第１の実施形態と同様の構成については、図２と同一の符号を付し、説明を省略する。本実施形態における名前解決システムは、端末装置３０と、ネームデータベースサーバ４０とを備えている。ネームデータベースサーバ４０は、例えば、ＤＮＳサーバにより実現される。ただし、ネームデータベースサーバ４０は、ＤＮＳサーバに限定されない。

【0062】

ネームデータベースサーバ４０は、ノード情報記憶手段２１と、エントリ検索手段４１と、アドレス変換手段４２と、検索結果送信手段４３とを備えている。なお、ノード情報記憶手段２１は、第１の実施形態と同様であるため、説明を省略する。

【0063】

エントリ検索手段４１は、ノード情報記憶手段２１を検索することにより、端末装置３０から受信したホスト名に対応するエントリを特定する。具体的には、端末装置３０からレコードタイプ「ＡＡＡＡ」を示すパケットを受信した場合、エントリ検索手段４１は、受信したホスト名及びレコードタイプ「ＡＡＡＡ」に対応するエントリを特定する。さらに、エントリ検索手段４１は、受信したホスト名及びレコードタイプ「Ａ」に対応するエントリを特定する。

【0064】

アドレス変換手段４２は、エントリ検索手段４１が特定したエントリに含まれるアドレスのうち、端末装置３０から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換する。具体的には、端末装置３０からレコードタイプ「ＡＡＡＡ」を示すパケットを受信した場合、アドレス変換手段４２は、エントリ検索手段４１が特定したエントリに含まれるアドレスのうち、レコードタイプが「Ａ」のアドレス（ＩＰｖ４アドレス）を、所定の規則に基づいて、レコードタイプ「ＡＡＡＡ」のアドレス（ＩＰｖ６アドレス）に変換する。なお、受信したレコードタイプと異なるレコードタイプのアドレスを、受信したレコードタイプのアドレスに変換する規則については、レコードタイプごとに予め定めておけばよい。

【0065】

例えば、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換する規則として、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換すると定めてもよい。具体的には、端末装置３０からレコードタイプ「ＡＡＡＡ」を受信した場合、アドレス変換手段４２は、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓとして定義されるフォーマットに基づいてエントリ検索手段４１が特定したＩＰｖ４アドレスをＩＰｖ６アドレスに変換する。

【0066】

なお、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓの定義は、以下の参考文献１「2.5.5.2. IPv4-Mapped IPv6 Address 」に記載されている。また、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓの使用方法（機能）は、以下の参考文献２に記載されている。そのため、詳細な説明は省略する。

【0067】

＜参考文献１＞R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", February 2006, RFC4291 (http://www.ietf.org/rfc/rfc4291.txt)
＜参考文献２＞M-K. Shin, et al., "Application Aspects of IPv6 Transition", March 2005, RFC4038 (http://www.ietf.org/rfc/rfc4038.txt)

【0068】

なお、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換する方法は、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換する方法に限定されない。クライアント側（端末装置３０）で、もとのＩＰｖ４アドレスが取り出せる方法であれば、他の変換アルゴリズムが用いられていてもよい。変換する方法についての仕様は、データの送受信が行われる装置間で定められていれば、上記フォーマットに限られない。例えば、任意のビットパターンをＩＰｖ４アドレスの前後に付加することで、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換してもよい。これは、ＩＰｖ６アドレス空間は極めて広大であるため、ＩＰｖ６アドレス空間にＩＰｖ４アドレスを含めることは容易だからである。

【0069】

検索結果送信手段４３は、受信したホスト名及びレコードタイプに対応するアドレスを端末装置３０に送信する。具体的には、検索結果送信手段４３は、アドレス変換手段４２が変換したアドレス、および、エントリ検索手段４１が特定したエントリに含まれるアドレスのうちアドレス変換手段４２が変換していないアドレスを端末装置３０に送信する。なお、エントリ検索手段４１がエントリを特定できなかった場合、検索結果送信手段４３は、ホスト名に対応するアドレスが存在しなかった旨の情報を含むパケットを、端末装置３０に送信すればよい。

【0070】

このように、本実施形態におけるネームデータベースサーバ４０は、端末装置３０からの問い合わせに応じてアドレスを変換する。そのため、本実施形態による名前解決方法を、動的変換方法と呼ぶことができる。例えば、アドレスを変換する規則において、ＤＮＳクエリ発生時に初めて分かる情報が用いられる場合、この動的変換方法は有効である。

【0071】

エントリ検索手段４１と、アドレス変換手段４２と、検索結果送信手段４３とは、プログラム（エントリ検索プログラム）に従って動作するコンピュータのＣＰＵによって実現される。また、エントリ検索手段４１と、アドレス変換手段４２と、検索結果送信手段４３とが、それぞれが専用のハードウェアで実現されていてもよい。

【0072】

端末装置３０は、アドレス問合せ手段３１と、変換アドレス再変換手段３２とを備えている。アドレス問合せ手段３１は、レコードタイプと名前解決を行う対象のホスト名とをネームデータベースサーバ４０に送信し、ホスト名に対するアドレスの問い合わせを行う。レコードタイプには、例えば、ＩＰｖ６アドレスを示すレコードタイプ「ＡＡＡＡ」が指定される。

【0073】

変換アドレス再変換手段３２は、ネームデータベースサーバ４０から受信したパケットに含まれるアドレスのうち、所定の規則に基づいて変換されたアドレスを、変換前のアドレスに変換する。具体的には、変換アドレス再変換手段３２は、ＩＰｖ４アドレスからＩＰｖ６アドレスに変換されたアドレスを、変換前のＩＰｖ４アドレスに変換する。

【0074】

変換アドレス再変換手段３２は、受信したアドレスのうち、所定のフォーマットのアドレスを、変換前のアドレスに変換するアドレスと特定してもよい。例えば、アドレス変換手段４２がＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓのフォーマットに従ってＩＰｖ４アドレスをＩＰｖ６アドレスに変換しているとする。この場合、変換アドレス再変換手段３２は、受信したＩＰｖ６アドレスのうちＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓのフォーマットのアドレスを変換対象のアドレスと特定してもよい。このとき、変換アドレス再変換手段３２は、ＩＰｖ４ ｍａｐｐｅｄ ＡｄｄｒｅｓｓのフォーマットのＩＰｖ６アドレスを変換前のＩＰｖ４アドレスに変換すればよい。

【0075】

なお、一般的に、ユーザランドの通信アプリケーションがＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓを用いる場合、カーネルにおいて、そのアドレスがＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓか否かの判断が行われる。そして、アドレスがＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓと判断された場合、カーネルでこのアドレスが認識され、このアドレスがＩＰｖ４アドレスに変換される。

【0076】

一般的なカーネルには、通常この機能が実装されている。そのため、既存の構造（カーネル）と、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓとを用いる場合で、クライアントのアプリケーションでは、新たな戻し変換処理（すなわち、ＩＰｖ６アドレスからＩＰｖ４アドレスへの変換処理）が不要になる。したがって、通信アプリケーション側では、ＩＰｖ６アドレスがＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓか、通常のＩＰｖ６アドレスかを意識する必要はなく、変換処理などを行う必要もない。すなわち、ＩＰｖ６アドレスにＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓと通常のＩＰｖ６アドレスとが混在していても、通信アプリケーション側では、通常のＩＰｖ６アドレスと同様に扱うことができる。また、言い換えると、通信アプリケーション側でＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓを用いた場合、ＩＰｖ６アドレスが自動的にＩＰｖ４アドレスに変換されるということもできる。これらのことから、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換する場合、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換することが好ましい。

【0077】

なお、アドレス問合せ手段３１は、第１の実施形態におけるアドレス問い合わせ手段１１と同様であるため、説明を省略する。

【0078】

アドレス問合せ手段３１と、変換アドレス再変換手段３２とは、プログラム（名前解決プログラム）に従って動作するコンピュータのＣＰＵによって実現される。また、アドレス問合せ手段３１と、変換アドレス再変換手段３２とは、それぞれが専用のハードウェアで実現されていてもよい。

【0079】

次に、ホスト名とレコードタイプ「ＡＡＡＡ」とを指定してクライアントからアドレスの問い合わせが行われた場合に、ＤＮＳサーバが、ＩＰｖ６アドレスと、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換したアドレスとをクライアントに返信する動作を説明する。なお、クライアントが端末装置３０に対応し、ＤＮＳサーバがネームデータベースサーバ４０に対応する。

【0080】

図６は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段３１は、ホスト名とレコードタイプ「ＡＡＡＡ」とを指定したＤＮＳクエリパケットをＤＮＳサーバに送信して、ホスト名に対するアドレスを問い合わせる（ステップＳ１１）。ＤＮＳサーバのエントリ検索手段４１は、クライアントからＤＮＳクエリパケットを受信すると、ノード情報記憶手段２１を検索して、受信したホスト名に対応するエントリを特定する（ステップＳ１２）。具体的には、エントリ検索手段４１は、ホスト名に対応するＩＰｖ６アドレス及びＩＰｖ４アドレスを含むエントリを特定する。続いて、アドレス変換手段４２は、エントリ検索手段４１が特定したエントリに含まれるアドレスのうち、ＩＰｖ４アドレスを、所定の規則に基づいて、ＩＰｖ６アドレスに変換する（ステップＳ１３）。そして、検索結果送信手段４３は、ホスト名に対応するアドレスを含むパケットをクライアントに送信する（ステップＳ１４）。

【0081】

クライアントがアドレスを含むパケットを受信すると、変換アドレス再変換手段３２は、ＤＮＳサーバから受信したアドレスのうち、ＩＰｖ６アドレスに変換されたＩＰｖ４アドレスを、変換前のＩＰｖ４アドレスに変換する（ステップＳ１５）。

【0082】

以上のように、本実施形態によれば、端末装置３０のアドレス問合せ手段３１が、レコードタイプと名前解決を行う対象のホスト名とをネームデータベースサーバ４０に送信して、そのホスト名に対応するアドレスを問い合わせる。エントリ検索手段４１は、ノード情報記憶手段２１を検索することにより、端末装置３０から受信したホスト名に対応するエントリを特定する。アドレス変換手段４２は、エントリ検索手段４１が特定したエントリに含まれるアドレスのうち、端末装置３０から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換する。そして、検索結果送信手段４３は、特定されたエントリに含まれる受信したレコードタイプのアドレスと、アドレス変換手段４２によって変換されたアドレスとを端末装置３０に送信する。

【0083】

具体的には、アドレス問合せ手段３１が、レコードタイプ「ＡＡＡＡ」と名前解決を行う対象のホスト名とをネームデータベースサーバ４０に送信して、そのホスト名に対応するアドレスを問い合わせる。エントリ検索手段４１は、ノード情報記憶手段２１を検索することにより、端末装置３０から受信したホスト名及びレコードタイプ「ＡＡＡＡ」に対応するエントリを特定する。さらに、エントリ検索手段４１は、端末装置３０から受信したホスト名及びレコードタイプ「Ａ」に対応するエントリを特定する。アドレス変換手段４２は、所定の規則に基づいて、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換する。そして、検索結果送信手段４３は、特定されたエントリに含まれるＩＰｖ６アドレスと、アドレス変換手段４２によって変換されたＩＰｖ６アドレスとを端末装置３０に送信する。

【0084】

以上のような構成により、第１の実施形態の効果と同様に、ＩＰｖ４とＩＰｖ６とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、ＩＰｖ４とＩＰｖ６のいずれについても名前解決できる。

【0085】

また、変換アドレス再変換手段３２が、ネームデータベースサーバ４０から受信したアドレスのうち、所定の規則に基づいて変換されたアドレスを、変換前のアドレスに変換する。よって、端末装置３０は、要求されたレコードタイプのアドレスを取得できると共に、変換前のアドレスを利用することが可能になる。

【0086】

また、アドレス変換手段４２が、端末装置３０からレコードタイプとしてＩＰｖ６アドレスを示すレコードタイプが指定されたときに、ノード情報記憶手段２１から抽出されたＩＰｖ４アドレスを、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換してもよい。この場合、通常のカーネルで実装されるＩＰｖ４ ｍａｐｐｅｄ ＡｄｄｒｅｓｓとＩＰｖ４アドレスの変換機能を用いることが出来る。そのため、クライアントのアプリケーション側では、新たな戻し変換処理を追加する必要が無くなる。したがって、多数存在するクライアントのアプリケーションへの影響を抑えることができる。また、この場合、ネームデータベースサーバ４０（例えば、ＤＮＳサーバ）側に本実施形態における機能を実装するだけで対応できるため、影響範囲を小さく抑えることが出来る。

【0087】

次に、第２の実施形態の変形例を説明する。第２の実施形態では、アドレス変換手段４２がＩＰｖ４アドレスをＩＰｖ６アドレスに変換し、変換アドレス再変換手段３２が変換後のＩＰｖ６アドレスを変換前のＩＰｖ４アドレスに変換する場合について説明した。本変形例では、アドレス変換手段４２がアドレスの変換以外の処理も行う場合について説明する。

【0088】

第２の実施形態では、端末装置３０からホスト名に対応するアドレスの問い合わせがあると、アドレス変換手段４２がアドレスを変換する処理を行っていた。本変形例では、アドレス変換手段４２が、アドレスを変換する処理に加え、問い合わせ結果を特定の端末装置のみ利用可能にする処理（以下、特定処理と記す。）を行う。このとき、変換アドレス再変換手段３２は、特定処理に対応した処理を行う。以下、特定処理が行われた問い合わせ結果を利用可能な状態にする処理のことを戻し変換処理と記す。

【0089】

端末装置３０とネームデータベースサーバ４０との間で特定処理についての仕様が決められている場合、端末装置３０が特定処理を行った場合であっても、ネームデータベースサーバ４０は、行われた特定処理に対する戻し変換処理を認識できる。一方、ネームデータベースサーバ４０による特定処理を知らない端末装置３０は、特定処理への対応方法が分からないため、特定処理が行われた情報を利用することが出来ない。このように、端末装置３０とネームデータベースサーバ４０との間で特定処理についての取り決めを行うことで、アドレス変換や特定処理を行う端末を、取り決めを行った特定のクライアント（端末装置３０）に限定することができる。

【0090】

また、アドレス変換手段４２は、戻し変換処理自体はどの装置でも可能にする特定処理を行ってもよい。ただし、その際、アドレス変換手段４２は、戻し処理が行われた情報内に、特定の端末装置３０のみ認識できる付加情報を付加するようにする。アドレス変換手段４２は、付加情報を、例えば、情報の末尾に付加してもよく、透かし的に付加してもよい。これらの方法は、チェックディジット方式、または、あぶり出し方式と呼ぶこともできる。このチェックディジット方式、あぶり出し方式を認識している端末装置３０のみ、付加情報を使用できることになる。

【0091】

さらに、アドレス変換手段４２は、アドレス変換を行う際、戻し変換処理を行う端末装置３０が持つ特定の鍵を用いて、情報を暗号化する処理を特定処理として行ってもよい。このとき、例えば、プロトコルとして、公開鍵符号方式を使うＥＳＰ（Encapsulating Security Payload）や公開鍵符号方式を使うＡＨ（Authentication Header ）が暗号化処理及び認証処理に用いられる。このとき、端末装置３０は、戻し変換処理として、端末装置３０が持つ特定の鍵に対応した復号鍵を用いて情報を復号すればよい。ただし、暗号化処理及び認証処理に用いられるプロトコルは、上記内容に限定されない。

【0092】

また、名前解決システムは、チャレンジ／レスポンス認証による認証方式を特定処理に用いてもよい。具体的には、端末装置３０（具体的には、アドレス問合せ手段３１）が認証要求をネームデータベースサーバ４０に送信すると、ネームデータベースサーバ４０（例えば、アドレス変換手段４２）は、それに対しチャレンジを返信する。そして、アドレス問合せ手段３１は、受信したチャレンジとパスワードを特定のアルゴリズムに従って変換したレスポンスを作成し、ネームデータベースサーバ４０に送信する。アドレス変換手段４２は、送信したチャレンジと予め登録された端末装置３０のパスワードから同じようにレスポンスを作成する。そして、アドレス変換手段４２は、そのレスポンスと端末装置３０から受信したレスポンスとが一致したときに、アドレス変換を行う。

【0093】

他にも、名前解決システムは、チェックディジットによる認証方法、ワンタイムパスワードを用いた認証方法を特定処理に用いてもよい。なお、チャレンジ／レスポンス認証による認証方式、チェックディジットによる認証方法、および、ワンタイムパスワードを用いた認証方法は広く知られているため、詳細な説明は省略する。

【0094】

次に、端末装置３０が行う戻し処理を説明する。第２の実施形態で説明したＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換する処理は、通常、カーネルで行われることになる。そのため、ユーザランドのアプリケーションでは、この変換処理を意識する必要はない。一方、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓへの変換処理以外の処理を端末装置３０が行う場合、ＤＮＳクエリの返信パケットを受け取る部分、または、その返信パケットの伝達先が戻し変換処理を実装することになる。

【0095】

返信パケットは、ｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙが受け取ることになる。そのため、この戻し変換処理は、ｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙに実装されることが望ましい。カーネルではないｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙは、ユーザランドにおける処理であると言える。しかし、通信アプリケーションで共通に用いられるｒｅｓｏｌｖｅｒ Ｌｉｂｒａｒｙにこの戻し変換処理を実装することで、個々の通信アプリケーションに戻し変換処理を加える労力を削減できる。

【0096】

このように、アドレス変換処理以外の処理を端末装置３０及びネームデータベースサーバ４０が行うことにより、名前解決システムに名前解決以外の新たな付加価値を持たせることができる。

【0097】

実施形態３．
次に、図７を参照して、第３の実施形態における名前解決システムの概要を説明する。図７は、名前解決を行う動作の例を示す説明図である。第３の実施形態における名前解決システムは、ホスト名に対してＩＰｖ６アドレスとＩＰｖ４アドレスの両方のエントリが存在する場合に、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換したエントリを予め作成しておくものである。具体的には、図７は、ＩＰｖ４アドレスｐ，ｑが、所定のタイミングでＩＰｖ６アドレスｐ’，ｑ’に変換（静的変換）され、磁気ディスク等に保持されていることを示す。なお、表中の網掛け部分が、変換されたレコードを示す。

【0098】

この状態から、まず、クライアントが、名前解決を行う対象のホスト名（図７では、「ｈｏｓｔＸ」）とＩＰｖ６アドレスのレコードタイプ（図７では、「ＡＡＡＡ」）とを指定したＤＮＳクエリパケットをＤＮＳサーバに対して送信する。次に、ＤＮＳクエリパケットを受信したＤＮＳサーバは、受信したホスト名及びレコードタイプ「ＡＡＡＡ」のエントリを検索する。図７に示す例では、この結果、ホスト名「ｈｏｓｔＸ」及びレコードタイプ「ＡＡＡＡ」のエントリのアドレスｓ，ｔ，ｐ’，ｑ’が特定される。そして、ＤＮＳサーバは、これらのＩＰｖ６アドレスｓ，ｔ， ｐ’，ｑ’を含むパケットをクライアントに送信する。ＩＰｖ６アドレスを受信したクライアントは、変換されたアドレスｐ’，ｑ’を、変換前のＩＰｖ４アドレスｐ，ｑに戻し変換する。

【0099】

ＩＰｖ４アドレスをＩＰｖ６アドレスへ変換する方法として、例えば、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ ＩＰｖ６ Ａｄｄｒｅｓｓ（以下、ＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓと記す。）へ変換する方法が用いられる。ＩＰｖ４ ｍａｐｐｅｄ ＡｄｄｒｅｓｓからＩＰｖ４アドレスへの変換処理は、通常カーネルで行われるため、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換することで、クライアント側のユーザランドにおけるアプリケーションにおいて、戻し変換処理が不要になる。

【0100】

このように、第３の実施形態における名前解決システムも、ホスト名とＩＰｖ６アドレスのレコードタイプとを指定したパケットをＤＮＳサーバに１回送信するだけで、ホスト名に対応するアドレスを含むパケットを、指定したレコードタイプで一度に取得することができる。さらに、変換されたアドレスを、変換前のアドレスに戻し変換することで、変換されたアドレスがもとのアドレスとして利用できる。以下、第３の実施形態における名前解決システムの内容を、詳しく説明する。

【0101】

図８は、本発明の第３の実施形態における名前解決システムの例を示すブロック図である。なお、第２の実施形態と同様の構成については、図５と同一の符号を付し、説明を省略する。本実施形態における名前解決システムは、端末装置３０と、ネームデータベースサーバ５０とを備えている。端末装置３０は、第２の実施形態と同様であるため、説明を省略する。

【0102】

ネームデータベースサーバ５０は、ノード情報記憶手段２１と、変換アドレス記憶手段５１と、アドレス変換手段５２と、エントリ検索手段５３と、検索結果送信手段５４とを備えている。なお、ノード情報記憶手段２１は、第１および第２の実施形態と同様であるため、説明を省略する。

【0103】

変換アドレス記憶手段５１は、ノード情報記憶手段２１に記憶されたＩＰｖ４アドレスをＩＰｖ６アドレスに変換したアドレス（以下、変換アドレスと記す。）と、ノード情報記憶手段２１に記憶されたＩＰｖ６アドレスとを、ホスト名と対応付けたエントリを記憶する。変換アドレス記憶手段５１は、例えば、磁気ディスク等により実現される。なお、各アドレスに対応付ける情報は、ホスト名に限定されない。変換アドレス記憶手段５１は、ノード情報記憶手段２１と同様、ゾーンファイルのように、ドメインのホスト情報を示す他の情報を各アドレスに対応付けたエントリを記憶していてもよい。なお、変換アドレス記憶手段５１が記憶するエントリは、後述するアドレス変換手段５２によって記憶される。

【0104】

アドレス変換手段５２は、ノード情報記憶手段２１に記憶されたアドレスのうち、一のレコードタイプのアドレスを、所定の規則に基づいて他のレコードタイプのアドレスに変換する。そして、アドレス変換手段５２は、ノード情報記憶手段２１に記憶されたエントリのうち、変換したアドレスを含むエントリと変換しなかったアドレスを含むエントリのいずれも、変換アドレス記憶手段５１に記憶させる。

【0105】

具体的には、アドレス変換手段５２は、ノード情報記憶手段２１に記憶されたＩＰｖ４アドレスを、所定の規則に基づいてＩＰｖ６アドレスに変換する。そして、アドレス変換手段５２は、変換したＩＰｖ６アドレス（すなわち、変換アドレス）を含むエントリと、ノード情報記憶手段２１に記憶された未変換のＩＰｖ６アドレスを含むエントリのいずれも、変換アドレス記憶手段５１に記憶させる。

【0106】

アドレス変換手段５２は、予め定めた期間ごと、または、予め定められた時間にアドレスを変換してもよい。または、アドレス変換手段５２は、ノード情報記憶手段２１にエントリが追加されるタイミングで、そのアドレスを変換してもよい。また、アドレス変換手段５２が変換アドレス記憶手段５１に記憶させるエントリは、前の変換処理からの差分であってもよく、対象とするエントリ全体であってもよい。

【0107】

エントリ検索手段５３は、変換アドレス記憶手段５１を検索することにより、端末装置３０から受信したホスト名およびレコードタイプに対応するエントリを特定する。例えば、端末装置３０からレコードタイプ「ＡＡＡＡ」を受信した場合、エントリ検索手段５３は、ホスト名に対応するエントリのうち、レコードタイプが「ＡＡＡＡ」であるエントリ（すなわち、ＩＰｖ６アドレスを含むエントリ）を特定する。

【0108】

検索結果送信手段５４は、ホスト名に対応するアドレスを端末装置３０に送信する。具体的には、検索結果送信手段５４は、エントリ検索手段５３が特定したエントリに含まれるアドレスを端末装置３０に送信する。なお、エントリ検索手段５３がエントリを特定できなかった場合、検索結果送信手段５４は、ホスト名に対応するアドレスが存在しなかった旨の情報を、端末装置３０に送信すればよい。

【0109】

本実施形態では、変換後のアドレスを予め変換アドレス記憶手段５１に記憶させている点において、第２の実施形態と異なる。すなわち、本実施形態におけるネームデータベースサーバ５０は、端末装置３０からの問い合わせの有無に関わらず、予めアドレスを変換して記憶しておく。そのため、本実施形態による名前解決方法を、静的変換方法と呼ぶことができる。

【0110】

また、本実施形態では、ネームデータベースサーバ５０がノード情報記憶手段２１と変換アドレス記憶手段５１とを備えている場合について説明した。このように、ノード情報記憶手段２１と変換アドレス記憶手段５１とを別々にすることによって、一般的なＤＮＳに適用する場合に、ゾーンファイル（ノード情報記憶手段２１に相当）のエントリを更新する仕組みを変える必要がなくなる。そして、エントリを特定する処理では、エントリの検索先を、ゾーンファイルから、変換アドレス記憶手段５１へと変更するだけで良い。

【0111】

また、ネームデータベースサーバ５０がノード情報記憶手段２１のみを備えるようにしてもよい。この場合、例えば、ＤＮＳダイナミックアップデートを適用してゾーンファイル（ノード情報記憶手段２１に相当）のエントリを更新する際に、アドレス変換手段５２は、レコードタイプも併せて変換し、変換後のアドレスを含むエントリをノード情報記憶手段２１に記憶させるようにすればよい。このように、ノード情報記憶手段２１へのエントリ更新前に、レコードタイプも併せて変換することで、エントリの検索先を変更する必要がなくなる。よって、既存のＤＮＳをそのまま利用することが可能になる。

【0112】

アドレス変換手段５２は、所定の規則として、ＩＰｖ４アドレスをＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓに変換する規則を用いてもよい。このＩＰｖ４ ｍａｐｐｅｄ Ａｄｄｒｅｓｓは、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換したものである。そのため、変換後のアドレスをＤＮＳのデータベースに登録する上での問題は生じない。

【0113】

なお、上述した、ＩＰｖ４アドレスを所定のタイミングで随時ＩＰｖ６アドレスに変換して保持する方法を、混合変換方法と呼ぶことができる。混合変換方法の実体は、動的変換方法である。静的変換方法は、アドレス情報を含むファイル（データベース情報ファイルと言うこともできる）の情報を事前に変換する方法（以下、事前変換方法と記す。）と捉えることができる。動的変換方法では、対象とするデータベース情報に記憶された情報が事前変換方法により変換された情報か、静的変換方法により変換された方法かを意識する必要はない。つまり、静的変換方法と動的変換方法とは、互いに独立した変換方法であるといえる。その一方、混合変換方法は、静的変換方法と動的変換方法の両方を有効にした方法であるといえる。

【0114】

本実施形態では、ネームデータベースサーバ５０がアドレス変換手段５２を備え、アドレス変換手段５２が、所定のタイミングでノード情報記憶手段２１に記憶されたアドレスを変換し、変換したアドレスを含むエントリを変換アドレス記憶手段５１に記憶させる場合について説明した。ただし、外部の装置（図示せず）が、所定のタイミングでノード情報記憶手段２１に記憶されたアドレスを変換し、変換したアドレスを含むエントリを変換アドレス記憶手段５１に記憶させてもよい。この場合、ネームデータベースサーバ５０自身が、アドレス変換手段５２を備えていなくてもよい。

【0115】

アドレス変換手段５２と、エントリ検索手段５３と、検索結果送信手段５４とは、プログラム（エントリ検索プログラム）に従って動作するコンピュータのＣＰＵによって実現される。また、アドレス変換手段５２と、エントリ検索手段５３と、検索結果送信手段５４とは、それぞれが専用のハードウェアで実現されていてもよい。

【0116】

次に、ホスト名とレコードタイプ「ＡＡＡＡ」とを指定してクライアントからアドレスの問い合わせが行われた場合に、ＤＮＳサーバが、ＩＰｖ６アドレスと、ＩＰｖ４アドレスをＩＰｖ６アドレスに変換したアドレスとをクライアントに返信する動作を説明する。なお、クライアントが端末装置３０に対応し、ＤＮＳサーバがネームデータベースサーバ５０に対応する。

【0117】

図９は、名前解決を行う動作の例を示すシーケンス図である。ＤＮＳサーバでは、アドレス変換手段５２が、所定のタイミングでノード情報記憶手段２１に記憶されたＩＰｖ４アドレスをＩＰｖ６アドレスに変換する。そして、アドレス変換手段５２は、変換したＩＰｖ６アドレスを含むエントリを変換アドレス記憶手段５１に記憶させる（ステップＳ２１）。

【0118】

一方、クライアントのアドレス問合せ手段３１は、ホスト名とレコードタイプ「ＡＡＡＡ」とを指定したＤＮＳクエリパケットをＤＮＳサーバに送信して、ホスト名に対するアドレスを問い合わせる（ステップＳ１１）。クライアントからＤＮＳクエリパケットを受信すると、エントリ検索手段５３は、変換アドレス記憶手段５１を検索して、受信したホスト名およびレコードタイプ「ＡＡＡＡ」のエントリを特定する（ステップＳ２２）。そして、検索結果送信手段５４は、特定されたエントリのアドレスを含むパケットをクライアントに送信する（ステップＳ２３）。

【0119】

クライアントがアドレスを含むパケットを受信すると、変換アドレス再変換手段３２は、ＤＮＳサーバから受信したアドレスのうち、ＩＰｖ６アドレスに変換されたＩＰｖ４アドレスを、変換前のＩＰｖ４アドレスに変換する（ステップＳ１５）。

【0120】

以上のように、本実施形態によれば、変換アドレス記憶手段５１が、第一のレコードタイプのアドレス（ＩＰｖ４アドレス）を所定の規則に基づいて第二のレコードタイプのアドレス（ＩＰｖ６アドレス）に変換したアドレス（すなわち、変換アドレス）及びその第二のレコードタイプをホスト名と対応付けたエントリを記憶する。そして、エントリ検索手段５３が、端末装置３０から第二のレコードタイプ（ＩＰｖ６アドレス）を受信したときに、変換アドレス記憶手段５１を検索することにより、ホスト名に対応する第二のレコードタイプ（「ＡＡＡＡ」）のエントリを特定する。そして、検索結果送信手段５４が、特定されたエントリに含まれる第二のレコードタイプのアドレス（ＩＰｖ６アドレス）を端末装置３０に送信する。よって、第１の実施形態の効果と同様に、ＩＰｖ４とＩＰｖ６とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、ＩＰｖ４とＩＰｖ６のいずれについても名前解決できる。

【0121】

さらに、ネームデータベースサーバ５０が予め変換したアドレスを記憶している。そのため、第２の実施形態の効果に加え、端末装置３０から問い合わせを受信するたびに変換処理を行う必要がなくなる。よって、ネームデータベースサーバ５０（ＤＮＳサーバ）の負荷が軽減されるという効果も得られる。

【0122】

また、アドレス変換手段５２が、第一のレコードタイプのアドレス（ＩＰｖ４アドレス）を、所定の規則に基づいて、第二のレコードタイプのアドレス（ＩＰｖ６アドレス）に変換してもよい。そして、アドレス変換手段５２は、変換したアドレスをノード情報記憶手段２１に記憶させるようにしてもよい。

【0123】

実施形態４．
次に、図１０を参照して、第４の実施形態における名前解決システムの概要を説明する。図１０は、名前解決を行う動作の例を示す説明図である。第４の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名（図１０では、「ｈｏｓｔＸ」）と、ＩＰｖ４アドレス及びＩＰｖ６アドレスのレコードタイプ（図１０では、「Ａ，ＡＡＡＡ」）とを指定したＤＮＳクエリパケットをＤＮＳサーバに対して送信する。次に、ＤＮＳクエリパケットを受信したＤＮＳサーバは、受信したホスト名のエントリのうち、指定されたレコードタイプ「Ａ」及び「ＡＡＡＡ」のエントリを検索する。図１０に示す例では、この結果、ホスト名「ｈｏｓｔＸ」と、指定されたレコードタイプに一致するエントリに含まれるアドレスｐ，ｑ，ｓ，ｔが特定される。そして、ＤＮＳサーバは、これらのアドレスｐ，ｑ，ｓ，ｔを含むパケットをクライアントに送信する。

【0124】

一般的なＤＮＳでは、アドレスの問い合わせを行う際に、複数のレコードタイプを指定しない。しかし、第４の実施形態における名前解決システムは、ホスト名と複数のレコードタイプとを指定したパケットをＤＮＳサーバに１回送信することで、ホスト名に対応するアドレスを含むパケットを、一度に取得することができる。また、第４の実施形態では、アドレスに何ら変換処理を行っていないため、アドレスを受信したクライアント側では、受信したアドレスを変換する必要はない。以下、第４の実施形態における名前解決システムの内容を、詳しく説明する。

【0125】

図１１は、本発明の第４の実施形態における名前解決システムの例を示すブロック図である。なお、第１の実施形態と同様の構成については、図２と同一の符号を付し、説明を省略する。本実施形態における名前解決システムは、端末装置６０と、ネームデータベースサーバ７０とを備えている。ネームデータベースサーバ７０は、例えば、ＤＮＳサーバにより実現される。ただし、ネームデータベースサーバ７０は、ＤＮＳサーバに限定されない。

【0126】

端末装置６０は、アドレス問合せ手段６１を備えている。アドレス問合せ手段６１は、ホスト名とともに、複数のレコードタイプをネームデータベースサーバ７０に送信し、ホスト名に対するアドレスの問い合わせを行う。送信するレコードタイプには、ノード情報記憶手段２１に記憶されたレコードタイプが指定される。具体的には、アドレス問合せ手段６１は、ホスト名とともに「Ａ」及び「ＡＡＡＡ」（すなわち、ＩＰｖ４アドレスを示すレコードタイプ及びＩＰｖ６アドレスを示すレコードタイプ）をネームデータベースサーバ７０に送信する。アドレス問合せ手段６１は、例えば、プログラムに従って動作するコンピュータ（端末装置６０）のＣＰＵによって実現される。

【0127】

ネームデータベースサーバ７０は、ノード情報記憶手段２１と、エントリ検索手段７１と、検索結果送信手段７２とを備えている。なお、ノード情報記憶手段２１は、第１の実施形態と同様であるため、説明を省略する。

【0128】

エントリ検索手段７１は、ノード情報記憶手段２１を検索することにより、端末装置６０から受信したホスト名に一致し、かつ、複数のレコードタイプのうちのいずれかに一致するレコードタイプのエントリを特定する。例えば、エントリ検索手段７１がホスト名とともにレコードタイプ「Ａ」及び「ＡＡＡＡ」を含むパケットを端末装置６０から受信する。このとき、エントリ検索手段７１は、ノード情報記憶手段２１を検索して、ホスト名に対応するエントリであって、レコードタイプが「Ａ」または「ＡＡＡＡ」であるエントリを特定する。

【0129】

検索結果送信手段７２は、エントリ検索手段７１が特定したエントリのアドレスを端末装置６０に送信する。なお、対象のエントリが存在しなかった場合、検索結果送信手段７２は、ホスト名に対応するアドレスが存在しなかった旨の情報を含むパケットを、端末装置６０に送信すればよい。

【0130】

エントリ検索手段７１と、検索結果送信手段７２とは、プログラム（エントリ検索プログラム）に従って動作するコンピュータのＣＰＵによって実現される。また、エントリ検索手段７１と、検索結果送信手段７２とは、それぞれが専用のハードウェアで実現されていてもよい。

【0131】

次に、ホスト名とレコードタイプ「Ａ」及び「ＡＡＡＡ」とを指定してクライアントからアドレスの問い合わせが行われた場合に、ＤＮＳサーバが、ＩＰｖ６アドレス及びＩＰｖ４アドレスをクライアントに返信する動作を説明する。なお、クライアントが端末装置６０に対応し、ＤＮＳサーバがネームデータベースサーバ７０に対応する。

【0132】

図１２は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段６１は、ホスト名とレコードタイプ「Ａ」及び「ＡＡＡＡ」とを指定したＤＮＳクエリパケットをＤＮＳサーバに送信して、ホスト名に対するアドレスを問い合わせる（ステップＳ３１）。ＤＮＳサーバがクライアントからＤＮＳクエリパケットを受信すると、エントリ検索手段７１は、ノード情報記憶手段２１を検索して、ホスト名に対応するエントリであって、レコードタイプが「Ａ」または「ＡＡＡＡ」であるエントリを特定する（ステップＳ３２）。そして、検索結果送信手段７２は、特定されたエントリのアドレスを含むパケットをクライアントに送信する（ステップＳ３３）。

【0133】

以上のように、本実施形態によれば、アドレス問合せ手段６１が、ホスト名とともに、複数のレコードタイプをネームデータベースサーバ７０に送信する。そして、エントリ検索手段７１が、ノード情報記憶手段２１を検索することにより、受信したホスト名に一致し、かつ、複数のレコードタイプのうちのいずれかに一致するエントリを特定する。そして、検索結果送信手段７２が、特定されたエントリに含まれるアドレスを端末装置６０に送信する。

【0134】

以上のような構成により、ＩＰｖ４とＩＰｖ６とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、ＩＰｖ４とＩＰｖ６のいずれについても名前解決できる。また、第２の実施形態および第３の実施形態とは異なり、ネームデータベースサーバ７０（サーバ側）で変換処理を行わないため、端末装置６０（クライアント側）では、アドレスを戻すための変換処理を行う必要がない。

【0135】

次に、本発明の最小構成を説明する。図１３は、本発明による名前解決システムの最小構成の例を示すブロック図である。また、図１４は、本発明によるネームデータベースサーバの最小構成の例を示すブロック図である。

【0136】

図１３に例示する名前解決システムは、ノード情報を問い合わせる端末装置９０（例えば、端末装置１０）と、端末装置９０からの問い合わせを受信するネームデータベースサーバ８０（例えば、ネームデータベースサーバ２０）とを備えている。

【0137】

端末装置９０は、ネームデータベースサーバが記憶するエントリを特定するエントリ特定情報と仮想のレコードタイプ（例えば、「ＡＡＡＡ＋Ａ」）とをネームデータベースサーバ８０に送信して、そのノード情報を問い合わせるアドレス問合せ手段９１（例えば、アドレス問合せ手段１１）を備えている。

【0138】

ネームデータベースサーバ８０は、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段８１（例えば、ノード情報記憶手段２１）と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプ（例えば、「ＡＡＡＡ＋Ａ」）から検索対象とするエントリのレコードタイプ（例えば、「Ａ」，「ＡＡＡＡ」）を決定する検索対象レコード決定手段８２（例えば、検索対象レコード決定手段２２）と、ノード情報記憶手段８１を検索することにより、端末装置９０から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段８２が決定したレコードタイプのエントリを特定するエントリ検索手段８３（例えば、エントリ検索手段２３）と、エントリ検索手段８３が特定したエントリに含まれるノード情報（例えば、ＩＰｖ４アドレス、ＩＰｖ６アドレス）を端末装置９０に送信する検索結果送信手段８４（例えば、検索結果送信手段２４）とを備えている。

【0139】

また、図１４に例示するネームデータベースサーバは、ノード情報記憶手段８１（例えば、ノード情報記憶手段２１）と、検索対象レコード決定手段８２（例えば、検索対象レコード決定手段２２）と、エントリ検索手段８３（例えば、エントリ検索手段２３）と、検索結果送信手段８４（例えば、検索結果送信手段２４）を備えている。なお、ノード情報記憶手段８１、検索対象レコード決定手段８２、エントリ検索手段８３および検索結果送信手段８４の内容は、図１３に示す内容と同様である。

【0140】

以上のような構成により、一度の問い合わせで、複数のレコードタイプのノード情報を取得できる。

【0141】

また、検索対象レコード決定手段８２は、ノード情報記憶手段８１に記憶されるレコードタイプを示す文字列とは異なる仮想のレコードタイプ（例えば、「ＡＡＡＡ＋Ａ」）に応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置９０から受信した仮想のレコードタイプからレコードタイプを決定してもよい。このように、問い合わせの際、ＤＮＳサーバに記憶される仮想のレコードタイプとは異なるレコードタイプが用いられることで、既存の仕組みに与える影響を抑えることが出来る。

【0142】

また、検索対象レコード決定手段８２は、仮想のレコードタイプとホスト名とを受信した場合に、ＩＰｖ６アドレスを示すレコードタイプ（例えば、「ＡＡＡＡ」）及びＩＰｖ４アドレスを示すレコードタイプ（例えば、「Ａ」）を、検索対象とするエントリのレコードタイプとして決定し、エントリ検索手段８３は、ノード情報記憶手段８１を検索することにより、端末装置９０から受信したホスト名に対応するエントリであって、ＩＰｖ６アドレスを示すレコードタイプ及びＩＰｖ４アドレスを示すレコードタイプのエントリを特定してもよい。

【0143】

以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

【0144】

この出願は、２０１０年１０月１８日に出願された日本特許出願２０１０−２３３４１２を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【産業上の利用可能性】

【0145】

本発明は、複数のレコードタイプが混在する通信環境で名前解決を行う際に用いられるネームデータベースサーバに好適に適用される。

【符号の説明】

【0146】

１０，３０，６０ 端末装置
１１，３１，６１ アドレス問合せ手段
２０，４０，５０，７０ ネームデータベースサーバ
２１ ノード情報記憶手段
２２ 検索対象レコード決定手段
２４，４３，５４，７２ 検索結果送信手段
３２ 変換アドレス再変換手段
２３，４１，５３，７１ エントリ検索手段
４２，５２ アドレス変換手段
５１ 変換アドレス記憶手段

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】