"少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、仮想のレコードタイプとエントリを特定する情報であるエントリ特定情報とを送信して当該エントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、前記検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、前記エントリ検索手段が特定したエントリに含まれるノード情報を前記端末装置に送信する検索結果送信手段とを備えることを特徴とするネームデータベースサーバ。検索対象レコード決定手段は、ノード情報記憶手段に記憶されるレコードタイプとは異なる仮想のレコードタイプに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した文字列からレコードタイプを決定する請求項1記載のネームデータベースサーバ。検索対象レコード決定手段は、仮想のレコードタイプとホスト名とを受信した場合に、IPv6アドレスを示すレコードタイプ及びIPv4アドレスを示すレコードタイプを、検索対象とするエントリのレコードタイプとして決定し、エントリ検索手段は、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスを示すレコードタイプ及びIPv4アドレスを示すレコードタイプのエントリを特定する請求項1または請求項2記載のネームデータベースサーバ。ノード情報を問い合わせる端末装置と、前記端末装置からの問い合わせを受信するネームデータベースサーバとを備え、前記端末装置は、ネームデータベースサーバが記憶するエントリを特定するエントリ特定情報と仮想のレコードタイプとを前記ネームデータベースサーバに送信して、当該ノード情報を問い合わせるアドレス問合せ手段を備え、前記ネームデータベースサーバは、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、前記検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、前記エントリ検索手段が特定したエントリに含まれるノード情報を前記端末装置に送信する検索結果送信手段とを備えることを特徴とする名前解決システム。端末装置のアドレス問合せ手段は、名前解決を行う対象のホスト名と、ノード情報記憶手段に記憶されるレコードタイプとは異なる仮想のレコードタイプとを前記ネームデータベースサーバに送信して、当該ホスト名に対応するアドレスを問い合わせ、前記ネームデータベースサーバの検索対象レコード決定手段は、前記文字列に応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した仮想のレコードタイプからレコードタイプを決定する請求項4記載の名前解決システム。検索対象レコード決定手段は、仮想のレコードタイプとノード名とを受信した場合に、IPv6アドレスを示すレコードタイプ及びIPv4アドレスを示すレコードタイプを、検索対象とするエントリのレコードタイプとして決定し、エントリ検索手段は、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスを示すレコードタイプ及びIPv4アドレスを示すレコードタイプのエントリを特定する請求項5または請求項6記載の名前解決システム。仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを特定する情報であるエントリ特定情報と仮想のレコードタイプとを送信して当該エントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した当該仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、前記エントリを記憶するノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、特定されたエントリに含まれるノード情報を前記端末装置に送信することを特徴とするエントリ検索方法。レコードタイプを決定する際、ノード情報記憶手段に記憶されるレコードタイプを示す文字列とは異なる仮想のレコードタイプに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した文字列からレコードタイプを決定する請求項7記載のエントリ検索方法。ノード情報を問い合わせる端末装置が、当該問い合わせに対してノード情報を応答するネームデータベースサーバが記憶するエントリを特定するエントリ特定情報と仮想のレコードタイプとを、当該ネームデータベースサーバに送信して、当該ノード情報を問い合わせ、前記ネームデータベースサーバが、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、特定されたエントリに含まれるノード情報を前記端末装置に送信することを特徴とする名前解決方法。端末装置が、名前解決を行う対象のホスト名と、ノード情報記憶手段に記憶されるレコードタイプを示す文字列とは異なる仮想のレコードタイプとをネームデータベースサーバに送信して、当該ホスト名に対応するアドレスを問い合わせ、ネームデータベースサーバは、前記文字列に応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した仮想のレコードタイプからレコードタイプを決定する請求項9記載の名前解決方法。少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を備えたコンピュータに適用されるエントリ検索プログラムであって、前記コンピュータに、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、仮想のレコードタイプとエントリを特定する情報であるエントリ特定情報とを送信して当該エントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定処理、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したエントリ特定情報に対応するエントリであって、前記検索対象レコード決定処理で決定されたレコードタイプのエントリを特定するエントリ検索処理、および、前記エントリ検索処理で特定されたエントリに含まれるノード情報を前記端末装置に送信する検索結果送信処理を実行させるためのエントリ検索プログラム。コンピュータに、検索対象レコード決定処理で、ノード情報記憶手段に記憶されるレコードタイプとは異なる仮想のレコードタイプに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置から受信した文字列からレコードタイプを決定させる請求項11記載のエントリ検索プログラム。IPv6通信環境の新たな導入に伴い、図17~図21に示すように、IPv4アドレスのみ存在していた際の方法を残し、この方法とは独立して、IPv6アドレス用に新しい問い合わせを行う方法が追加されてきた。そのため、結果として、今までは一つのホスト名に対する問い合わせが一回で済んでいたのに対し、図17~図21に示す方法では、問い合わせを二回することになる。一方、問い合わせを二回必要とすることから、各アドレスの問い合わせパターンは複数存在することになる。さらに、先の問い合わせの応答内容によって、その後の処理を決める方法を考慮した場合、その処理方法は、より複雑になる。さらに、それぞれの問い合わせに対し、サーバからは別々に応答が返ってくるため、クライアントは、応答内容を一度に集めることが出来ない。そのため、一方が応答するまで他方が待たされることで、応答完了までの時間がよりかかってしまう。また、一方の問い合わせに用いられるパケットが欠落した場合まで想定すると、それぞれの応答内容を考慮した処理はさらに複雑になる。このような複雑さから、当初想定していなかった問題が発生することもあった。また、問い合わせが2回発生することから、問い合わせで発生するネットワークトラフィック量も2倍になる。このように、問い合わせの回数は一回増えるだけだが、考慮しなければならない事項は多数存在する。特許文献1に記載された通信装置も、図18に示す方法と同様に、一方の問い合わせの応答内容によって、問い合わせが複数回発生する。このような複雑な構成にすることなく、一回の問い合わせで複数のレコードタイプのノード情報を取得できることが望ましい。そこで、本発明は、一度の問い合わせで、複数のレコードタイプのノード情報を取得できるネームデータベースサーバ、名前解決システム、エントリ検索方法、名前解決方法およびエントリ検索プログラムを提供することを目的とする。本発明によるネームデータベースサーバは、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、仮想のレコードタイプとエントリを特定する情報であるエントリ特定情報とを送信してそのエントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、ノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、エントリ検索手段が特定したエントリに含まれるノード情報を端末装置に送信する検索結果送信手段とを備えることを特徴とする。本発明による名前解決システムは、ノード情報を問い合わせる端末装置と、端末装置からの問い合わせを受信するネームデータベースサーバとを備え、端末装置が、ネームデータベースサーバが記憶するエントリを特定するエントリ特定情報と仮想のレコードタイプとをネームデータベースサーバに送信して、そのノード情報を問い合わせるアドレス問合せ手段を備え、ネームデータベースサーバが、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定手段と、ノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段が決定したレコードタイプのエントリを特定するエントリ検索手段と、エントリ検索手段が特定したエントリに含まれるノード情報を端末装置に送信する検索結果送信手段とを備えることを特徴とする。本発明によるエントリ検索方法は、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを特定する情報であるエントリ特定情報と仮想のレコードタイプとを送信してそのエントリ特定情報に対応するノード情報を問い合わせる端末装置から受信したその仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、エントリを記憶するノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、特定されたエントリに含まれるノード情報を端末装置に送信することを特徴とする。本発明による名前解決方法は、ノード情報を問い合わせる端末装置が、その問い合わせに対してノード情報を応答するネームデータベースサーバが記憶するエントリを特定するエントリ特定情報と仮想のレコードタイプとを、そのネームデータベースサーバに送信して、そのノード情報を問い合わせ、ネームデータベースサーバが、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定し、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、決定されたレコードタイプのエントリを特定し、特定されたエントリに含まれるノード情報を端末装置に送信することを特徴とする。本発明によるエントリ検索プログラムは、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段を備えたコンピュータに適用されるエントリ検索プログラムであって、コンピュータに、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、仮想のレコードタイプとエントリを特定する情報であるエントリ特定情報とを送信してそのエントリ特定情報に対応するノード情報を問い合わせる端末装置から受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する検索対象レコード決定処理、ノード情報記憶手段を検索することにより、端末装置から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定処理で決定されたレコードタイプのエントリを特定するエントリ検索処理、および、エントリ検索処理で特定されたエントリに含まれるノード情報を端末装置に送信する検索結果送信処理を実行させることを特徴とする。本発明によれば、一度の問い合わせで、複数のレコードタイプのホスト情報を取得できる。以下、本発明の実施形態を図面を参照して説明する。実施形態1.まず、図1を参照して、第1の実施形態における名前解決システムの概要を説明する。図1は、名前解決を行う動作の例を示す説明図である。第1の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名図1では、hostXとレコードタイプ図1では、AAAAAとを指定したDNSクエリパケットをDNSサーバに対して送信する。ここで指定されるレコードタイプAAAAAとは、AやAAAAといったDNSサーバに記憶されるレコードタイプとは異なる仮想のレコードタイプである。仮想のレコードタイプには、任意の情報を設定することが可能である。例えば、既存のDNSに存在しないレコードタイプを新たに定義し、そのレコードタイプを表す情報を、仮想のレコードタイプとして使用してもよい。なお、以下の説明では、便宜上、仮想のレコードタイプをAAAAAと記す。ただし、仮想のレコードタイプは、AAAAAの一種類に限られず、複数種類あってもよい。この仮想のレコードタイプは、ユーザ等により予め定められる。なお、仮想のレコードタイプとは、クエリパケットでレコードを指定する部分に指定されるレコードタイプであって、DNSで定義されていないレコードタイプと言うこともできる。次に、DNSクエリパケットを受信したDNSサーバは、指定された仮想のレコードタイプAAAAAに応じて予め定められたルールに従って、検索対象のレコードタイプを決定する。そして、DNSサーバは、決定したレコードタイプ及び受信したホスト名に対応するエントリを検索する。図1に示す例では、レコードタイプAAAA及びAのエントリが検索される。そして、DNSサーバは、検索したエントリに含まれるIPv6アドレスおよびIPv4アドレス図1では、s,t,p,qを含む返信パケットをクライアントに送信する。すなわち、第1の実施形態における名前解決システムは、エントリを特定する情報例えば、ホスト名やアドレス。以下、エントリ特定情報と記す。とレコードタイプAAAAAとを指定したパケットをDNSサーバに1回送信するだけで、対応するノード情報例えば、IPv6アドレスおよびIPv4アドレス、ホスト名を含むパケットを一度に取得することができるものである。なお、以下の説明では、ドメイン名から対応するIPアドレスを解決する場合正引きの場合について説明する。ただし、本実施形態における名前解決システムでは、IPアドレスから対応するホスト名を解決する場合逆引きの場合にも適用可能である。以下、第1の実施形態における名前解決システムの内容を、詳しく説明する。図2は、本発明の第1の実施形態における名前解決システムの例を示すブロック図である。本実施形態における名前解決システムは、端末装置10と、ネームデータベースサーバ20とを備えている。ネームデータベースサーバ20は、例えば、DNSサーバにより実現される。ただし、ネームデータベースサーバ20は、DNSサーバに限定されない。端末装置10は、アドレス問合せ手段11を備えている。アドレス問合せ手段11は、仮想のレコードタイプとエントリ特定情報例えば、名前解決を行う対象のホスト名やアドレスとをネームデータベースサーバ20に送信し、対応するノード情報の問い合わせを行う。なお、仮想のレコードタイプには、後述するノード情報記憶手段21に記憶されたレコードタイプに存在しない予め定められた情報すなわち、上述するAAAAAが指定される。アドレス問合せ手段11は、例えば、プログラムに従って動作するコンピュータ端末装置10のCPUによって実現される。なお、アドレス問合せ手段11がネームデータベースサーバ20に送信するエントリ特定情報はホスト名やアドレス及び仮想のレコードタイプに限定されない。アドレス問合せ手段11は、例えば、端末装置10自身のアドレスなどをネームデータベースサーバ20に送信してもよい。なお、アドレス問合せ手段11がネームデータベースサーバ20に問い合わせるレコードタイプは、例えば、他の高級API図示せず等により指定される。ネームデータベースサーバ20は、ノード情報記憶手段21と、検索対象レコード決定手段22と、エントリ検索手段23と、検索結果送信手段24とを備えている。ノード情報記憶手段21は、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶する。具体的には、ノード情報記憶手段21は、少なくともIPv6アドレスおよびIPv4アドレスをホスト名と対応付けたエントリを記憶する。ノード情報記憶手段21は、例えば、磁気ディスク等により実現される。なお、各アドレス及びレコードタイプに対応付ける情報は、ホスト名に限定されない。ノード情報記憶手段21は、ゾーンファイルのように、ドメインのホスト情報を示す他の情報を各アドレス及びレコードタイプに対応付けたエントリを記憶していてもよい。ノード情報記憶手段21に記憶されるエントリは、例えば、DNSダイナミックアップデートなどの仕組みを用いて、逐次更新される。検索対象レコード決定手段22は、端末装置10から受信した仮想のレコードタイプから、検索対象とするエントリのレコードタイプを決定する。具体的には、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルール以下、検索ルールを予め定めておく。検索対象レコード決定手段22は、その検索ルールに従って、受信した仮想のレコードタイプから検索対象とするエントリのレコードタイプを決定する。具体的には、検索ルールとして、レコードタイプとして文字列AAAAAが指定された場合に、検索対象とするレコードタイプをAAAA及びAとすると定めておく。このように定めておくことで、後述するエントリ検索手段23が、仮想のレコードタイプAAAAAを受信した場合でも、レコードタイプAAAA及びAのエントリを検索することが可能になる。エントリ検索手段23は、ノード情報記憶手段21を検索することにより、受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段22が決定したレコードタイプのエントリを特定する。例えば、検索対象レコード決定手段22が検索対象とするエントリのレコードタイプをAAAA及びAと決定したとする。この場合、エントリ検索手段23は、ノード情報記憶手段21を検索して、端末装置10から受信したホスト名に対応するIPv4アドレスとIPv6アドレスとを含むエントリを特定する。このように指定された仮想のレコードタイプは、検索対象とするレコードタイプを特定する情報といえる。さらに、この仮想のレコードタイプは、DNSサーバに検索対象を指示する情報ということもできる。すなわち、このレコードタイプAAAAAは、検索対象とするレコードタイプをDNSサーバに指示するコマンドの役割を果たすものと言うことができる。また、問い合わせの際、DNSサーバに記憶されるレコードタイプとは異なるレコードタイプが用いられることで、既存の仕組みに与える影響を抑えることが出来る。検索結果送信手段24は、エントリ検索手段23が特定したエントリに含まれるノード情報を端末装置10に送信する。なお、対象のエントリが存在しなかった場合、検索結果送信手段24は、ホスト名に対応するノード情報が存在しなかった旨の情報を含むパケットを、端末装置10に送信すればよい。検索対象レコード決定手段22と、エントリ検索手段23と、検索結果送信手段24とは、プログラムエントリ検索プログラムに従って動作するコンピュータのCPUによって実現される。例えば、プログラムは、ネームデータベースサーバ20の記憶部図示せずに記憶され、CPUは、そのプログラムを読み込み、プログラムに従って、検索対象レコード決定手段22、エントリ検索手段23および検索結果送信手段24として動作してもよい。また、検索対象レコード決定手段22と、エントリ検索手段23と、検索結果送信手段24とは、それぞれが専用のハードウェアで実現されていてもよい。次に、ホスト名とレコードタイプAAAAAとを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv4アドレス及びIPv6アドレスのいずれのアドレスもクライアントに返信する動作を説明する。なお、クライアントが端末装置10に対応し、DNSサーバがネームデータベースサーバ20に対応する。図3は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段11は、ホスト名と仮想のレコードタイプAAAAAとを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせるステップS1。DNSサーバの検索対象レコード決定手段22は、仮想のレコードタイプAAAAAを含むパケットを受信すると、予め定められた検索ルールに従って、検索対象とするレコードタイプをAAAA及びAと決定するステップS2。次に、エントリ検索手段23は、ノード情報記憶手段21を検索して、受信したホスト名に対応するレコードタイプAAAA及びAのエントリを特定するステップS3。具体的には、エントリ検索手段23は、IPv4アドレスとIPv6アドレスとを含むエントリを特定する。そして、検索結果送信手段24は、エントリ検索手段23が特定したエントリのIPv4アドレスとIPv6アドレスとを含むパケットをクライアントに送信するステップS4以上のように、本実施形態によれば、端末装置10のアドレス問合せ手段11が、仮想のレコードタイプとエントリ特定情報とをネームデータベースサーバ20に送信して、そのエントリ特定情報に対応するノード情報を問い合わせる。ネームデータベースサーバ20の検索対象レコード決定手段22は、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、検索対象とするエントリのレコードタイプを決定する。エントリ検索手段23は、ノード情報記憶手段21を検索することにより、受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段22が決定したレコードタイプのエントリを特定する。そして、検索結果送信手段24は、エントリ検索手段23が特定したエントリに含まれるノード情報を端末装置10に送信する。そのため、一度の問い合わせで、複数のレコードタイプのノード情報を取得できる。具体的には、IPv4とIPv6とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、IPv4とIPv6のいずれについても名前解決できる。例えば、一つのレコードタイプを指定したDNSクエリパケットを一度送信するだけで、ホスト名に対応する複数のレコードタイプIPv4とIPv6両方のアドレスが取得できる。また、クライアント側の処理は、一回の問い合わせで完了するため効率的である。また、各処理がシンプルになることで様々な問題が発生することを抑制できる。さらに、クライアント側は、複数の問い合わせがある場合に比べ、一つの問い合わせに対する応答を待てばよい。そのため、処理が高速になる。また、問い合わせで発生するトラフィック量も減少する。実施形態2.次に、図4を参照して、第2の実施形態における名前解決システムの概要を説明する。図4は、名前解決を行う動作の例を示す説明図である。第2の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名図4では、hostXとIPv6アドレスのレコードタイプ図4では、AAAAとを指定したDNSクエリパケットをDNSサーバに対して送信する。次に、DNSクエリパケットを受信したDNSサーバは、受信したホスト名のエントリのうち、指定されたレコードタイプAAAAのエントリだけでなく、レコードタイプAのエントリも検索する。図4に示す例では、この結果、ホスト名hostXに一致するエントリに含まれるアドレスp,q,s,tが特定される。そして、DNSサーバは、レコードタイプがAのIPv4アドレスp,qを、受信したレコードタイプのアドレスであるIPv6アドレスに変換する。以下、IPv6アドレスに変換されたアドレスp,qを、p’,q’と記す。そして、DNSサーバは、これらのIPv6アドレスs,t,p’,q’を含むパケットをクライアントに送信する。IPv6アドレスを受信したクライアントは、変換されたアドレスp’,q’を、変換前のIPv4アドレスp,qに戻し変換する。IPv4アドレスをIPv6アドレスへ変換する方法として、例えば、IPv4アドレスをIPv4mappedIPv6Address以下、IPv4mappedAddressと記す。へ変換する方法が用いられる。IPv4mappedAddressからIPv4アドレスへの変換処理は、通常カーネルで行われる。そのため、IPv4アドレスをIPv4mappedAddressに変換することで、クライアント側のユーザランドにおけるアプリケーションにおいて、戻し変換処理が不要になる。このように、第2の実施形態における名前解決システムは、ホスト名とIPv6アドレスのレコードタイプとを指定したパケットをDNSサーバに1回送信するだけで、ホスト名に対応するアドレスを含むパケットを、指定したレコードタイプで一度に取得することができる。さらに、変換されたアドレスを、変換前のアドレスに戻し変換することで、変換されたアドレスをもとのアドレスとして利用できる。以下、第2の実施形態における名前解決システムの内容を、詳しく説明する。図5は、本発明の第2の実施形態における名前解決システムの例を示すブロック図である。なお、第1の実施形態と同様の構成については、図2と同一の符号を付し、説明を省略する。本実施形態における名前解決システムは、端末装置30と、ネームデータベースサーバ40とを備えている。ネームデータベースサーバ40は、例えば、DNSサーバにより実現される。ただし、ネームデータベースサーバ40は、DNSサーバに限定されない。ネームデータベースサーバ40は、ノード情報記憶手段21と、エントリ検索手段41と、アドレス変換手段42と、検索結果送信手段43とを備えている。なお、ノード情報記憶手段21は、第1の実施形態と同様であるため、説明を省略する。エントリ検索手段41は、ノード情報記憶手段21を検索することにより、端末装置30から受信したホスト名に対応するエントリを特定する。具体的には、端末装置30からレコードタイプAAAAを示すパケットを受信した場合、エントリ検索手段41は、受信したホスト名及びレコードタイプAAAAに対応するエントリを特定する。さらに、エントリ検索手段41は、受信したホスト名及びレコードタイプAに対応するエントリを特定する。アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、端末装置30から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換する。具体的には、端末装置30からレコードタイプAAAAを示すパケットを受信した場合、アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、レコードタイプがAのアドレスIPv4アドレスを、所定の規則に基づいて、レコードタイプAAAAのアドレスIPv6アドレスに変換する。なお、受信したレコードタイプと異なるレコードタイプのアドレスを、受信したレコードタイプのアドレスに変換する規則については、レコードタイプごとに予め定めておけばよい。例えば、IPv4アドレスをIPv6アドレスに変換する規則として、IPv4アドレスをIPv4mappedAddressに変換すると定めてもよい。具体的には、端末装置30からレコードタイプAAAAを受信した場合、アドレス変換手段42は、IPv4mappedAddressとして定義されるフォーマットに基づいてエントリ検索手段41が特定したIPv4アドレスをIPv6アドレスに変換する。なお、IPv4mappedAddressの定義は、以下の参考文献12552IPv4MappedIPv6Addressに記載されている。また、IPv4mappedAddressの使用方法機能は、以下の参考文献2に記載されている。そのため、詳細な説明は省略する。<参考文献1>RHindenSDeeringIPVersion6AddressingArchitectureFebruary2006RFC4291<参考文献2>MKShinetalApplicationAspectsofIPv6TransitionMarch2005RFC4038なお、IPv4アドレスをIPv6アドレスに変換する方法は、IPv4アドレスをIPv4mappedAddressに変換する方法に限定されない。クライアント側端末装置30で、もとのIPv4アドレスが取り出せる方法であれば、他の変換アルゴリズムが用いられていてもよい。変換する方法についての仕様は、データの送受信が行われる装置間で定められていれば、上記フォーマットに限られない。例えば、任意のビットパターンをIPv4アドレスの前後に付加することで、IPv4アドレスをIPv6アドレスに変換してもよい。これは、IPv6アドレス空間は極めて広大であるため、IPv6アドレス空間にIPv4アドレスを含めることは容易だからである。検索結果送信手段43は、受信したホスト名及びレコードタイプに対応するアドレスを端末装置30に送信する。具体的には、検索結果送信手段43は、アドレス変換手段42が変換したアドレス、および、エントリ検索手段41が特定したエントリに含まれるアドレスのうちアドレス変換手段42が変換していないアドレスを端末装置30に送信する。なお、エントリ検索手段41がエントリを特定できなかった場合、検索結果送信手段43は、ホスト名に対応するアドレスが存在しなかった旨の情報を含むパケットを、端末装置30に送信すればよい。このように、本実施形態におけるネームデータベースサーバ40は、端末装置30からの問い合わせに応じてアドレスを変換する。そのため、本実施形態による名前解決方法を、動的変換方法と呼ぶことができる。例えば、アドレスを変換する規則において、DNSクエリ発生時に初めて分かる情報が用いられる場合、この動的変換方法は有効である。エントリ検索手段41と、アドレス変換手段42と、検索結果送信手段43とは、プログラムエントリ検索プログラムに従って動作するコンピュータのCPUによって実現される。また、エントリ検索手段41と、アドレス変換手段42と、検索結果送信手段43とが、それぞれが専用のハードウェアで実現されていてもよい。端末装置30は、アドレス問合せ手段31と、変換アドレス再変換手段32とを備えている。アドレス問合せ手段31は、レコードタイプと名前解決を行う対象のホスト名とをネームデータベースサーバ40に送信し、ホスト名に対するアドレスの問い合わせを行う。レコードタイプには、例えば、IPv6アドレスを示すレコードタイプAAAAが指定される。変換アドレス再変換手段32は、ネームデータベースサーバ40から受信したパケットに含まれるアドレスのうち、所定の規則に基づいて変換されたアドレスを、変換前のアドレスに変換する。具体的には、変換アドレス再変換手段32は、IPv4アドレスからIPv6アドレスに変換されたアドレスを、変換前のIPv4アドレスに変換する。変換アドレス再変換手段32は、受信したアドレスのうち、所定のフォーマットのアドレスを、変換前のアドレスに変換するアドレスと特定してもよい。例えば、アドレス変換手段42がIPv4mappedAddressのフォーマットに従ってIPv4アドレスをIPv6アドレスに変換しているとする。この場合、変換アドレス再変換手段32は、受信したIPv6アドレスのうちIPv4mappedAddressのフォーマットのアドレスを変換対象のアドレスと特定してもよい。このとき、変換アドレス再変換手段32は、IPv4mappedAddressのフォーマットのIPv6アドレスを変換前のIPv4アドレスに変換すればよい。なお、一般的に、ユーザランドの通信アプリケーションがIPv4mappedAddressを用いる場合、カーネルにおいて、そのアドレスがIPv4mappedAddressか否かの判断が行われる。そして、アドレスがIPv4mappedAddressと判断された場合、カーネルでこのアドレスが認識され、このアドレスがIPv4アドレスに変換される。一般的なカーネルには、通常この機能が実装されている。そのため、既存の構造カーネルと、IPv4mappedAddressとを用いる場合で、クライアントのアプリケーションでは、新たな戻し変換処理すなわち、IPv6アドレスからIPv4アドレスへの変換処理が不要になる。したがって、通信アプリケーション側では、IPv6アドレスがIPv4mappedAddressか、通常のIPv6アドレスかを意識する必要はなく、変換処理などを行う必要もない。すなわち、IPv6アドレスにIPv4mappedAddressと通常のIPv6アドレスとが混在していても、通信アプリケーション側では、通常のIPv6アドレスと同様に扱うことができる。また、言い換えると、通信アプリケーション側でIPv4mappedAddressを用いた場合、IPv6アドレスが自動的にIPv4アドレスに変換されるということもできる。これらのことから、IPv4アドレスをIPv6アドレスに変換する場合、IPv4アドレスをIPv4mappedAddressに変換することが好ましい。なお、アドレス問合せ手段31は、第1の実施形態におけるアドレス問い合わせ手段11と同様であるため、説明を省略する。アドレス問合せ手段31と、変換アドレス再変換手段32とは、プログラム名前解決プログラムに従って動作するコンピュータのCPUによって実現される。また、アドレス問合せ手段31と、変換アドレス再変換手段32とは、それぞれが専用のハードウェアで実現されていてもよい。次に、ホスト名とレコードタイプAAAAとを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv6アドレスと、IPv4アドレスをIPv6アドレスに変換したアドレスとをクライアントに返信する動作を説明する。なお、クライアントが端末装置30に対応し、DNSサーバがネームデータベースサーバ40に対応する。図6は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段31は、ホスト名とレコードタイプAAAAとを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせるステップS11。DNSサーバのエントリ検索手段41は、クライアントからDNSクエリパケットを受信すると、ノード情報記憶手段21を検索して、受信したホスト名に対応するエントリを特定するステップS12。具体的には、エントリ検索手段41は、ホスト名に対応するIPv6アドレス及びIPv4アドレスを含むエントリを特定する。続いて、アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、IPv4アドレスを、所定の規則に基づいて、IPv6アドレスに変換するステップS13。そして、検索結果送信手段43は、ホスト名に対応するアドレスを含むパケットをクライアントに送信するステップS14。クライアントがアドレスを含むパケットを受信すると、変換アドレス再変換手段32は、DNSサーバから受信したアドレスのうち、IPv6アドレスに変換されたIPv4アドレスを、変換前のIPv4アドレスに変換するステップS15。以上のように、本実施形態によれば、端末装置30のアドレス問合せ手段31が、レコードタイプと名前解決を行う対象のホスト名とをネームデータベースサーバ40に送信して、そのホスト名に対応するアドレスを問い合わせる。エントリ検索手段41は、ノード情報記憶手段21を検索することにより、端末装置30から受信したホスト名に対応するエントリを特定する。アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、端末装置30から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換する。そして、検索結果送信手段43は、特定されたエントリに含まれる受信したレコードタイプのアドレスと、アドレス変換手段42によって変換されたアドレスとを端末装置30に送信する。具体的には、アドレス問合せ手段31が、レコードタイプAAAAと名前解決を行う対象のホスト名とをネームデータベースサーバ40に送信して、そのホスト名に対応するアドレスを問い合わせる。エントリ検索手段41は、ノード情報記憶手段21を検索することにより、端末装置30から受信したホスト名及びレコードタイプAAAAに対応するエントリを特定する。さらに、エントリ検索手段41は、端末装置30から受信したホスト名及びレコードタイプAに対応するエントリを特定する。アドレス変換手段42は、所定の規則に基づいて、IPv4アドレスをIPv6アドレスに変換する。そして、検索結果送信手段43は、特定されたエントリに含まれるIPv6アドレスと、アドレス変換手段42によって変換されたIPv6アドレスとを端末装置30に送信する。以上のような構成により、第1の実施形態の効果と同様に、IPv4とIPv6とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、IPv4とIPv6のいずれについても名前解決できる。また、変換アドレス再変換手段32が、ネームデータベースサーバ40から受信したアドレスのうち、所定の規則に基づいて変換されたアドレスを、変換前のアドレスに変換する。よって、端末装置30は、要求されたレコードタイプのアドレスを取得できると共に、変換前のアドレスを利用することが可能になる。また、アドレス変換手段42が、端末装置30からレコードタイプとしてIPv6アドレスを示すレコードタイプが指定されたときに、ノード情報記憶手段21から抽出されたIPv4アドレスを、IPv4mappedAddressに変換してもよい。この場合、通常のカーネルで実装されるIPv4mappedAddressとIPv4アドレスの変換機能を用いることが出来る。そのため、クライアントのアプリケーション側では、新たな戻し変換処理を追加する必要が無くなる。したがって、多数存在するクライアントのアプリケーションへの影響を抑えることができる。また、この場合、ネームデータベースサーバ40例えば、DNSサーバ側に本実施形態における機能を実装するだけで対応できるため、影響範囲を小さく抑えることが出来る。次に、第2の実施形態の変形例を説明する。第2の実施形態では、アドレス変換手段42がIPv4アドレスをIPv6アドレスに変換し、変換アドレス再変換手段32が変換後のIPv6アドレスを変換前のIPv4アドレスに変換する場合について説明した。本変形例では、アドレス変換手段42がアドレスの変換以外の処理も行う場合について説明する。第2の実施形態では、端末装置30からホスト名に対応するアドレスの問い合わせがあると、アドレス変換手段42がアドレスを変換する処理を行っていた。本変形例では、アドレス変換手段42が、アドレスを変換する処理に加え、問い合わせ結果を特定の端末装置のみ利用可能にする処理以下、特定処理と記す。を行う。このとき、変換アドレス再変換手段32は、特定処理に対応した処理を行う。以下、特定処理が行われた問い合わせ結果を利用可能な状態にする処理のことを戻し変換処理と記す。端末装置30とネームデータベースサーバ40との間で特定処理についての仕様が決められている場合、端末装置30が特定処理を行った場合であっても、ネームデータベースサーバ40は、行われた特定処理に対する戻し変換処理を認識できる。一方、ネームデータベースサーバ40による特定処理を知らない端末装置30は、特定処理への対応方法が分からないため、特定処理が行われた情報を利用することが出来ない。このように、端末装置30とネームデータベースサーバ40との間で特定処理についての取り決めを行うことで、アドレス変換や特定処理を行う端末を、取り決めを行った特定のクライアント端末装置30に限定することができる。また、アドレス変換手段42は、戻し変換処理自体はどの装置でも可能にする特定処理を行ってもよい。ただし、その際、アドレス変換手段42は、戻し処理が行われた情報内に、特定の端末装置30のみ認識できる付加情報を付加するようにする。アドレス変換手段42は、付加情報を、例えば、情報の末尾に付加してもよく、透かし的に付加してもよい。これらの方法は、チェックディジット方式、または、あぶり出し方式と呼ぶこともできる。このチェックディジット方式、あぶり出し方式を認識している端末装置30のみ、付加情報を使用できることになる。さらに、アドレス変換手段42は、アドレス変換を行う際、戻し変換処理を行う端末装置30が持つ特定の鍵を用いて、情報を暗号化する処理を特定処理として行ってもよい。このとき、例えば、プロトコルとして、公開鍵符号方式を使うESPEncapsulatingSecurityPayloadや公開鍵符号方式を使うAHAuthenticationHeaderが暗号化処理及び認証処理に用いられる。このとき、端末装置30は、戻し変換処理として、端末装置30が持つ特定の鍵に対応した復号鍵を用いて情報を復号すればよい。ただし、暗号化処理及び認証処理に用いられるプロトコルは、上記内容に限定されない。また、名前解決システムは、チャレンジ/レスポンス認証による認証方式を特定処理に用いてもよい。具体的には、端末装置30具体的には、アドレス問合せ手段31が認証要求をネームデータベースサーバ40に送信すると、ネームデータベースサーバ40例えば、アドレス変換手段42は、それに対しチャレンジを返信する。そして、アドレス問合せ手段31は、受信したチャレンジとパスワードを特定のアルゴリズムに従って変換したレスポンスを作成し、ネームデータベースサーバ40に送信する。アドレス変換手段42は、送信したチャレンジと予め登録された端末装置30のパスワードから同じようにレスポンスを作成する。そして、アドレス変換手段42は、そのレスポンスと端末装置30から受信したレスポンスとが一致したときに、アドレス変換を行う。他にも、名前解決システムは、チェックディジットによる認証方法、ワンタイムパスワードを用いた認証方法を特定処理に用いてもよい。なお、チャレンジ/レスポンス認証による認証方式、チェックディジットによる認証方法、および、ワンタイムパスワードを用いた認証方法は広く知られているため、詳細な説明は省略する。次に、端末装置30が行う戻し処理を説明する。第2の実施形態で説明したIPv4アドレスをIPv4mappedAddressに変換する処理は、通常、カーネルで行われることになる。そのため、ユーザランドのアプリケーションでは、この変換処理を意識する必要はない。一方、IPv4mappedAddressへの変換処理以外の処理を端末装置30が行う場合、DNSクエリの返信パケットを受け取る部分、または、その返信パケットの伝達先が戻し変換処理を実装することになる。返信パケットは、resolverLibraryが受け取ることになる。そのため、この戻し変換処理は、resolverLibraryに実装されることが望ましい。カーネルではないresolverLibraryは、ユーザランドにおける処理であると言える。しかし、通信アプリケーションで共通に用いられるresolverLibraryにこの戻し変換処理を実装することで、個々の通信アプリケーションに戻し変換処理を加える労力を削減できる。このように、アドレス変換処理以外の処理を端末装置30及びネームデータベースサーバ40が行うことにより、名前解決システムに名前解決以外の新たな付加価値を持たせることができる。実施形態3.次に、図7を参照して、第3の実施形態における名前解決システムの概要を説明する。図7は、名前解決を行う動作の例を示す説明図である。第3の実施形態における名前解決システムは、ホスト名に対してIPv6アドレスとIPv4アドレスの両方のエントリが存在する場合に、IPv4アドレスをIPv6アドレスに変換したエントリを予め作成しておくものである。具体的には、図7は、IPv4アドレスp,qが、所定のタイミングでIPv6アドレスp’,q’に変換静的変換され、磁気ディスク等に保持されていることを示す。なお、表中の網掛け部分が、変換されたレコードを示す。この状態から、まず、クライアントが、名前解決を行う対象のホスト名図7では、hostXとIPv6アドレスのレコードタイプ図7では、AAAAとを指定したDNSクエリパケットをDNSサーバに対して送信する。次に、DNSクエリパケットを受信したDNSサーバは、受信したホスト名及びレコードタイプAAAAのエントリを検索する。図7に示す例では、この結果、ホスト名hostX及びレコードタイプAAAAのエントリのアドレスs,t,p’,q’が特定される。そして、DNSサーバは、これらのIPv6アドレスs,t,p’,q’を含むパケットをクライアントに送信する。IPv6アドレスを受信したクライアントは、変換されたアドレスp’,q’を、変換前のIPv4アドレスp,qに戻し変換する。IPv4アドレスをIPv6アドレスへ変換する方法として、例えば、IPv4アドレスをIPv4mappedIPv6Address以下、IPv4mappedAddressと記す。へ変換する方法が用いられる。IPv4mappedAddressからIPv4アドレスへの変換処理は、通常カーネルで行われるため、IPv4アドレスをIPv4mappedAddressに変換することで、クライアント側のユーザランドにおけるアプリケーションにおいて、戻し変換処理が不要になる。このように、第3の実施形態における名前解決システムも、ホスト名とIPv6アドレスのレコードタイプとを指定したパケットをDNSサーバに1回送信するだけで、ホスト名に対応するアドレスを含むパケットを、指定したレコードタイプで一度に取得することができる。さらに、変換されたアドレスを、変換前のアドレスに戻し変換することで、変換されたアドレスがもとのアドレスとして利用できる。以下、第3の実施形態における名前解決システムの内容を、詳しく説明する。図8は、本発明の第3の実施形態における名前解決システムの例を示すブロック図である。なお、第2の実施形態と同様の構成については、図5と同一の符号を付し、説明を省略する。本実施形態における名前解決システムは、端末装置30と、ネームデータベースサーバ50とを備えている。端末装置30は、第2の実施形態と同様であるため、説明を省略する。ネームデータベースサーバ50は、ノード情報記憶手段21と、変換アドレス記憶手段51と、アドレス変換手段52と、エントリ検索手段53と、検索結果送信手段54とを備えている。なお、ノード情報記憶手段21は、第1および第2の実施形態と同様であるため、説明を省略する。変換アドレス記憶手段51は、ノード情報記憶手段21に記憶されたIPv4アドレスをIPv6アドレスに変換したアドレス以下、変換アドレスと記す。と、ノード情報記憶手段21に記憶されたIPv6アドレスとを、ホスト名と対応付けたエントリを記憶する。変換アドレス記憶手段51は、例えば、磁気ディスク等により実現される。なお、各アドレスに対応付ける情報は、ホスト名に限定されない。変換アドレス記憶手段51は、ノード情報記憶手段21と同様、ゾーンファイルのように、ドメインのホスト情報を示す他の情報を各アドレスに対応付けたエントリを記憶していてもよい。なお、変換アドレス記憶手段51が記憶するエントリは、後述するアドレス変換手段52によって記憶される。アドレス変換手段52は、ノード情報記憶手段21に記憶されたアドレスのうち、一のレコードタイプのアドレスを、所定の規則に基づいて他のレコードタイプのアドレスに変換する。そして、アドレス変換手段52は、ノード情報記憶手段21に記憶されたエントリのうち、変換したアドレスを含むエントリと変換しなかったアドレスを含むエントリのいずれも、変換アドレス記憶手段51に記憶させる。具体的には、アドレス変換手段52は、ノード情報記憶手段21に記憶されたIPv4アドレスを、所定の規則に基づいてIPv6アドレスに変換する。そして、アドレス変換手段52は、変換したIPv6アドレスすなわち、変換アドレスを含むエントリと、ノード情報記憶手段21に記憶された未変換のIPv6アドレスを含むエントリのいずれも、変換アドレス記憶手段51に記憶させる。アドレス変換手段52は、予め定めた期間ごと、または、予め定められた時間にアドレスを変換してもよい。または、アドレス変換手段52は、ノード情報記憶手段21にエントリが追加されるタイミングで、そのアドレスを変換してもよい。また、アドレス変換手段52が変換アドレス記憶手段51に記憶させるエントリは、前の変換処理からの差分であってもよく、対象とするエントリ全体であってもよい。エントリ検索手段53は、変換アドレス記憶手段51を検索することにより、端末装置30から受信したホスト名およびレコードタイプに対応するエントリを特定する。例えば、端末装置30からレコードタイプAAAAを受信した場合、エントリ検索手段53は、ホスト名に対応するエントリのうち、レコードタイプがAAAAであるエントリすなわち、IPv6アドレスを含むエントリを特定する。検索結果送信手段54は、ホスト名に対応するアドレスを端末装置30に送信する。具体的には、検索結果送信手段54は、エントリ検索手段53が特定したエントリに含まれるアドレスを端末装置30に送信する。なお、エントリ検索手段53がエントリを特定できなかった場合、検索結果送信手段54は、ホスト名に対応するアドレスが存在しなかった旨の情報を、端末装置30に送信すればよい。本実施形態では、変換後のアドレスを予め変換アドレス記憶手段51に記憶させている点において、第2の実施形態と異なる。すなわち、本実施形態におけるネームデータベースサーバ50は、端末装置30からの問い合わせの有無に関わらず、予めアドレスを変換して記憶しておく。そのため、本実施形態による名前解決方法を、静的変換方法と呼ぶことができる。また、本実施形態では、ネームデータベースサーバ50がノード情報記憶手段21と変換アドレス記憶手段51とを備えている場合について説明した。このように、ノード情報記憶手段21と変換アドレス記憶手段51とを別々にすることによって、一般的なDNSに適用する場合に、ゾーンファイルノード情報記憶手段21に相当のエントリを更新する仕組みを変える必要がなくなる。そして、エントリを特定する処理では、エントリの検索先を、ゾーンファイルから、変換アドレス記憶手段51へと変更するだけで良い。また、ネームデータベースサーバ50がノード情報記憶手段21のみを備えるようにしてもよい。この場合、例えば、DNSダイナミックアップデートを適用してゾーンファイルノード情報記憶手段21に相当のエントリを更新する際に、アドレス変換手段52は、レコードタイプも併せて変換し、変換後のアドレスを含むエントリをノード情報記憶手段21に記憶させるようにすればよい。このように、ノード情報記憶手段21へのエントリ更新前に、レコードタイプも併せて変換することで、エントリの検索先を変更する必要がなくなる。よって、既存のDNSをそのまま利用することが可能になる。アドレス変換手段52は、所定の規則として、IPv4アドレスをIPv4mappedAddressに変換する規則を用いてもよい。このIPv4mappedAddressは、IPv4アドレスをIPv6アドレスに変換したものである。そのため、変換後のアドレスをDNSのデータベースに登録する上での問題は生じない。なお、上述した、IPv4アドレスを所定のタイミングで随時IPv6アドレスに変換して保持する方法を、混合変換方法と呼ぶことができる。混合変換方法の実体は、動的変換方法である。静的変換方法は、アドレス情報を含むファイルデータベース情報ファイルと言うこともできるの情報を事前に変換する方法以下、事前変換方法と記す。と捉えることができる。動的変換方法では、対象とするデータベース情報に記憶された情報が事前変換方法により変換された情報か、静的変換方法により変換された方法かを意識する必要はない。つまり、静的変換方法と動的変換方法とは、互いに独立した変換方法であるといえる。その一方、混合変換方法は、静的変換方法と動的変換方法の両方を有効にした方法であるといえる。本実施形態では、ネームデータベースサーバ50がアドレス変換手段52を備え、アドレス変換手段52が、所定のタイミングでノード情報記憶手段21に記憶されたアドレスを変換し、変換したアドレスを含むエントリを変換アドレス記憶手段51に記憶させる場合について説明した。ただし、外部の装置図示せずが、所定のタイミングでノード情報記憶手段21に記憶されたアドレスを変換し、変換したアドレスを含むエントリを変換アドレス記憶手段51に記憶させてもよい。この場合、ネームデータベースサーバ50自身が、アドレス変換手段52を備えていなくてもよい。アドレス変換手段52と、エントリ検索手段53と、検索結果送信手段54とは、プログラムエントリ検索プログラムに従って動作するコンピュータのCPUによって実現される。また、アドレス変換手段52と、エントリ検索手段53と、検索結果送信手段54とは、それぞれが専用のハードウェアで実現されていてもよい。次に、ホスト名とレコードタイプAAAAとを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv6アドレスと、IPv4アドレスをIPv6アドレスに変換したアドレスとをクライアントに返信する動作を説明する。なお、クライアントが端末装置30に対応し、DNSサーバがネームデータベースサーバ50に対応する。図9は、名前解決を行う動作の例を示すシーケンス図である。DNSサーバでは、アドレス変換手段52が、所定のタイミングでノード情報記憶手段21に記憶されたIPv4アドレスをIPv6アドレスに変換する。そして、アドレス変換手段52は、変換したIPv6アドレスを含むエントリを変換アドレス記憶手段51に記憶させるステップS21。一方、クライアントのアドレス問合せ手段31は、ホスト名とレコードタイプAAAAとを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせるステップS11。クライアントからDNSクエリパケットを受信すると、エントリ検索手段53は、変換アドレス記憶手段51を検索して、受信したホスト名およびレコードタイプAAAAのエントリを特定するステップS22。そして、検索結果送信手段54は、特定されたエントリのアドレスを含むパケットをクライアントに送信するステップS23。クライアントがアドレスを含むパケットを受信すると、変換アドレス再変換手段32は、DNSサーバから受信したアドレスのうち、IPv6アドレスに変換されたIPv4アドレスを、変換前のIPv4アドレスに変換するステップS15。以上のように、本実施形態によれば、変換アドレス記憶手段51が、第一のレコードタイプのアドレスIPv4アドレスを所定の規則に基づいて第二のレコードタイプのアドレスIPv6アドレスに変換したアドレスすなわち、変換アドレス及びその第二のレコードタイプをホスト名と対応付けたエントリを記憶する。そして、エントリ検索手段53が、端末装置30から第二のレコードタイプIPv6アドレスを受信したときに、変換アドレス記憶手段51を検索することにより、ホスト名に対応する第二のレコードタイプAAAAのエントリを特定する。そして、検索結果送信手段54が、特定されたエントリに含まれる第二のレコードタイプのアドレスIPv6アドレスを端末装置30に送信する。よって、第1の実施形態の効果と同様に、IPv4とIPv6とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、IPv4とIPv6のいずれについても名前解決できる。さらに、ネームデータベースサーバ50が予め変換したアドレスを記憶している。そのため、第2の実施形態の効果に加え、端末装置30から問い合わせを受信するたびに変換処理を行う必要がなくなる。よって、ネームデータベースサーバ50DNSサーバの負荷が軽減されるという効果も得られる。また、アドレス変換手段52が、第一のレコードタイプのアドレスIPv4アドレスを、所定の規則に基づいて、第二のレコードタイプのアドレスIPv6アドレスに変換してもよい。そして、アドレス変換手段52は、変換したアドレスをノード情報記憶手段21に記憶させるようにしてもよい。実施形態4.次に、図10を参照して、第4の実施形態における名前解決システムの概要を説明する。図10は、名前解決を行う動作の例を示す説明図である。第4の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名図10では、hostXと、IPv4アドレス及びIPv6アドレスのレコードタイプ図10では、A,AAAAとを指定したDNSクエリパケットをDNSサーバに対して送信する。次に、DNSクエリパケットを受信したDNSサーバは、受信したホスト名のエントリのうち、指定されたレコードタイプA及びAAAAのエントリを検索する。図10に示す例では、この結果、ホスト名hostXと、指定されたレコードタイプに一致するエントリに含まれるアドレスp,q,s,tが特定される。そして、DNSサーバは、これらのアドレスp,q,s,tを含むパケットをクライアントに送信する。一般的なDNSでは、アドレスの問い合わせを行う際に、複数のレコードタイプを指定しない。しかし、第4の実施形態における名前解決システムは、ホスト名と複数のレコードタイプとを指定したパケットをDNSサーバに1回送信することで、ホスト名に対応するアドレスを含むパケットを、一度に取得することができる。また、第4の実施形態では、アドレスに何ら変換処理を行っていないため、アドレスを受信したクライアント側では、受信したアドレスを変換する必要はない。以下、第4の実施形態における名前解決システムの内容を、詳しく説明する。図11は、本発明の第4の実施形態における名前解決システムの例を示すブロック図である。なお、第1の実施形態と同様の構成については、図2と同一の符号を付し、説明を省略する。本実施形態における名前解決システムは、端末装置60と、ネームデータベースサーバ70とを備えている。ネームデータベースサーバ70は、例えば、DNSサーバにより実現される。ただし、ネームデータベースサーバ70は、DNSサーバに限定されない。端末装置60は、アドレス問合せ手段61を備えている。アドレス問合せ手段61は、ホスト名とともに、複数のレコードタイプをネームデータベースサーバ70に送信し、ホスト名に対するアドレスの問い合わせを行う。送信するレコードタイプには、ノード情報記憶手段21に記憶されたレコードタイプが指定される。具体的には、アドレス問合せ手段61は、ホスト名とともにA及びAAAAすなわち、IPv4アドレスを示すレコードタイプ及びIPv6アドレスを示すレコードタイプをネームデータベースサーバ70に送信する。アドレス問合せ手段61は、例えば、プログラムに従って動作するコンピュータ端末装置60のCPUによって実現される。ネームデータベースサーバ70は、ノード情報記憶手段21と、エントリ検索手段71と、検索結果送信手段72とを備えている。なお、ノード情報記憶手段21は、第1の実施形態と同様であるため、説明を省略する。エントリ検索手段71は、ノード情報記憶手段21を検索することにより、端末装置60から受信したホスト名に一致し、かつ、複数のレコードタイプのうちのいずれかに一致するレコードタイプのエントリを特定する。例えば、エントリ検索手段71がホスト名とともにレコードタイプA及びAAAAを含むパケットを端末装置60から受信する。このとき、エントリ検索手段71は、ノード情報記憶手段21を検索して、ホスト名に対応するエントリであって、レコードタイプがAまたはAAAAであるエントリを特定する。検索結果送信手段72は、エントリ検索手段71が特定したエントリのアドレスを端末装置60に送信する。なお、対象のエントリが存在しなかった場合、検索結果送信手段72は、ホスト名に対応するアドレスが存在しなかった旨の情報を含むパケットを、端末装置60に送信すればよい。エントリ検索手段71と、検索結果送信手段72とは、プログラムエントリ検索プログラムに従って動作するコンピュータのCPUによって実現される。また、エントリ検索手段71と、検索結果送信手段72とは、それぞれが専用のハードウェアで実現されていてもよい。次に、ホスト名とレコードタイプA及びAAAAとを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv6アドレス及びIPv4アドレスをクライアントに返信する動作を説明する。なお、クライアントが端末装置60に対応し、DNSサーバがネームデータベースサーバ70に対応する。図12は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段61は、ホスト名とレコードタイプA及びAAAAとを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせるステップS31。DNSサーバがクライアントからDNSクエリパケットを受信すると、エントリ検索手段71は、ノード情報記憶手段21を検索して、ホスト名に対応するエントリであって、レコードタイプがAまたはAAAAであるエントリを特定するステップS32。そして、検索結果送信手段72は、特定されたエントリのアドレスを含むパケットをクライアントに送信するステップS33。以上のように、本実施形態によれば、アドレス問合せ手段61が、ホスト名とともに、複数のレコードタイプをネームデータベースサーバ70に送信する。そして、エントリ検索手段71が、ノード情報記憶手段21を検索することにより、受信したホスト名に一致し、かつ、複数のレコードタイプのうちのいずれかに一致するエントリを特定する。そして、検索結果送信手段72が、特定されたエントリに含まれるアドレスを端末装置60に送信する。以上のような構成により、IPv4とIPv6とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、IPv4とIPv6のいずれについても名前解決できる。また、第2の実施形態および第3の実施形態とは異なり、ネームデータベースサーバ70サーバ側で変換処理を行わないため、端末装置60クライアント側では、アドレスを戻すための変換処理を行う必要がない。次に、本発明の最小構成を説明する。図13は、本発明による名前解決システムの最小構成の例を示すブロック図である。また、図14は、本発明によるネームデータベースサーバの最小構成の例を示すブロック図である。図13に例示する名前解決システムは、ノード情報を問い合わせる端末装置90例えば、端末装置10と、端末装置90からの問い合わせを受信するネームデータベースサーバ80例えば、ネームデータベースサーバ20とを備えている。端末装置90は、ネームデータベースサーバが記憶するエントリを特定するエントリ特定情報と仮想のレコードタイプ例えば、AAAAAとをネームデータベースサーバ80に送信して、そのノード情報を問い合わせるアドレス問合せ手段91例えば、アドレス問合せ手段11を備えている。ネームデータベースサーバ80は、少なくともアドレス及びレコードタイプをホスト名と対応付けたノード情報のエントリを記憶するノード情報記憶手段81例えば、ノード情報記憶手段21と、仮想のレコードタイプに応じて検索対象とするレコードタイプを規定したルールである検索ルールに基づいて、受信した仮想のレコードタイプ例えば、AAAAAから検索対象とするエントリのレコードタイプ例えば、A,AAAAを決定する検索対象レコード決定手段82例えば、検索対象レコード決定手段22と、ノード情報記憶手段81を検索することにより、端末装置90から受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段82が決定したレコードタイプのエントリを特定するエントリ検索手段83例えば、エントリ検索手段23と、エントリ検索手段83が特定したエントリに含まれるノード情報例えば、IPv4アドレス、IPv6アドレスを端末装置90に送信する検索結果送信手段84例えば、検索結果送信手段24とを備えている。また、図14に例示するネームデータベースサーバは、ノード情報記憶手段81例えば、ノード情報記憶手段21と、検索対象レコード決定手段82例えば、検索対象レコード決定手段22と、エントリ検索手段83例えば、エントリ検索手段23と、検索結果送信手段84例えば、検索結果送信手段24を備えている。なお、ノード情報記憶手段81、検索対象レコード決定手段82、エントリ検索手段83および検索結果送信手段84の内容は、図13に示す内容と同様である。以上のような構成により、一度の問い合わせで、複数のレコードタイプのノード情報を取得できる。また、検索対象レコード決定手段82は、ノード情報記憶手段81に記憶されるレコードタイプを示す文字列とは異なる仮想のレコードタイプ例えば、AAAAAに応じて検索対象とするレコードタイプを規定した検索ルールに基づいて、端末装置90から受信した仮想のレコードタイプからレコードタイプを決定してもよい。このように、問い合わせの際、DNSサーバに記憶される仮想のレコードタイプとは異なるレコードタイプが用いられることで、既存の仕組みに与える影響を抑えることが出来る。また、検索対象レコード決定手段82は、仮想のレコードタイプとホスト名とを受信した場合に、IPv6アドレスを示すレコードタイプ例えば、AAAA及びIPv4アドレスを示すレコードタイプ例えば、Aを、検索対象とするエントリのレコードタイプとして決定し、エントリ検索手段83は、ノード情報記憶手段81を検索することにより、端末装置90から受信したホスト名に対応するエントリであって、IPv6アドレスを示すレコードタイプ及びIPv4アドレスを示すレコードタイプのエントリを特定してもよい。以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。この出願は、2010年10月18日に出願された日本特許出願2010-233412を基礎とする優先権を主張し、その開示の全てをここに取り込む。"