図面 (/)

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

出願人 日本電気株式会社
発明者 北村浩
出願日 2011年10月11日 (9年0ヶ月経過) 出願番号 2012-539582
公開日 2014年2月24日 (6年8ヶ月経過) 公開番号 WO2012-053163
状態 不明
技術分野
  • -
主要キーワード 事前変換 あぶり 検索対象レコード 検索ルール ゾーンファイル アドレスファミリ ネットワークトラフィック量 名前解決システム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2014年2月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

ノード情報記憶手段は、アドレス及びレコードタイプをホスト名と対応付けエントリを記憶する。アドレス変換手段は、エントリのうち、端末装置から受信するレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換する。エントリ検索手段は、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定する。検索結果送信手段は、特定されたエントリに含まれるアドレスを端末装置に送信する。

概要

背景

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

図15は、IPv4のみの通信環境において名前解決を行う場合の説明図である。図15は、ホスト名「hostX」に対し、レコードタイプを「A」とするIPv4アドレスp、qのエントリが2つDNS(Domain Name System)サーバ登録されていることを示す。クライアント端末からDNSサーバに対し、IPv4のレコードタイプ「A」を指定してホスト名「hostX」のアドレスを問い合わせるパケットが送信されると、DNSサーバは、hostXに対応するIPv4アドレスを含むエントリを検索する。そして、DNSサーバは、検索したIPv4アドレスを含むパケットをクライアント端末に送信する。図15に示す例では、DNSサーバは、hostXのIPv4アドレスとしてアドレスp及びqを含むパケットを、クライアント端末に送信する。以下、ホスト名とレコードタイプとを指定して、ホスト名に対応するアドレスを問い合わせるパケットを、DNSクエリパケットと記す。

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

IPv4とIPv6とが混在する通信環境において名前解決を行う方法が、各種提案されている。図16は、IPv4とIPv6とが混在する通信環境でDNSサーバが記憶する情報の例を示す説明図である。以下、IPv6アドレスのレコードタイプを「AAAA」と記し、IPv4アドレスのレコードタイプを「A」と記す。また、図16は、ホスト名「hostX」に対し、レコードタイプを「A」とするIPv4アドレスp、qのエントリが2つ、レコードタイプを「AAAA」とするIPv6アドレスs、tのエントリが2つ、合計4つのエントリがDNS(Domain Name System)サーバに登録されていることを示す。以下、IPv4とIPv6とが混在する通信環境で名前解決が行われる場合、DNSサーバが図16に示す情報を記憶しているものとして説明する。

ここで、DNSにおいてアドレスを問い合わせる装置(例えば、クライアント端末)が用いるAPI(Application Programming Interface )を説明する。DNSにおける名前解決処理には、原始的な処理を行う低級APIの集合であるresolver Libraryが用いられる。具体的には、DNSにおいて、サーバ側が備えるデータベースに記憶されたデータそのものを直接抽出するような低級な処理を行うコマンド(例えば、nslookup、dig、hostなど)が、このresolver Libraryに含まれる。

一方、ユーザランドにおいて用いられる通信アプリケーションは、直接resolver Libraryを呼び出さず、高級APIを用いることが一般的である。高級APIの内部では、resolver Libraryが用いられるが、ユーザは、その内部のAPIを意識する必要はない。

具体的には、IPv4のみの通信環境では、高級APIとしてgethostbyname()が用いられていた。しかし、IPv6の登場とともに、IPv4のみの通信環境に対応したgethostbyname()は使われなくなり、現在では、getaddrinfo()が用いられている。getaddrinfo()は、IPv4及びIPv6両方のプロトコルマルチプロトコル)に対応した関数である。getaddrinfo()関数では、レコードタイプ(具体的には、ネットワークアドレスの種類を表すアドレスファミリ)を指定して問い合わせが行われる。アドレスファミリには、IPv4(PF_INET)、IPv6(PF_INET6)、または、どちらでもよい(PF_UNSPEC)のいずれかが指定される。なお、問い合わせ結果(アドレス)は、リスト形式返却される。

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

具体的には、高級APIでは、レコードタイプを意識せずに(例えば、PF_UNSPECを指定した)通信アプリケーションが作成される。一方、resolver Libraryは、高級APIから呼び出されると、名前解決するレコードタイプを指定して、DNSサーバにアドレスを問い合わせることになる。これは、DNSサーバがエントリを検索する際、アドレスとレコードタイプとが必要になるからである。

図17〜図21は、IPv4とIPv6とが混在する通信環境でDNSサーバにアドレスを問い合わせる動作を示す説明図である。以下、IPv4アドレスを含むエントリをAレコードと記し、IPv6アドレスを含むエントリをAAAAレコードと記す。

図17に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAレコードを問い合わせ、その応答が戻ってきた後で(すなわち、戻るまで待機してから)、AAAAレコードを問い合わせる方法である。図17に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv4アドレスp、qを検索し、検索したアドレスを含むパケットをクライアントに送信する。IPv4アドレスを含むパケットを受信したクライアントは、次に、ホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv6アドレスs、tを検索し、検索したアドレスを含むパケットをクライアントに送信する。

図18に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAレコードを問い合わせ、戻ってきた応答内容によって、AAAAレコードを問い合わせる否かを判断する方法である。すなわち、図18に示す方法は、IPv4アドレスp,qの応答内容によって、AAAAレコードを問い合わせる否かを判断する点において図17に示す方法と異なる。図17に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv4アドレスp、qを検索し、検索したアドレスを含むパケットをクライアントに送信する。IPv4アドレスを含むパケットを受信したクライアントは、そのパケットに含まれる内容によって、ホスト名「hostX」とレコードタイプ「AAAA」とを指定したDNSクエリパケットをDNSサーバに送信するか否かを判断する。なお、DNSクエリパケットをDNSサーバに送信すると判断した場合、以降の処理は、図17に示す方法と同様である。

図19に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAレコードを問い合わせ、その応答を待たずして、AAAAレコードを問い合わせる方法である。図19に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そして、クライアントは、IPv4アドレスを含むパケットを受信する前に、ホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。なお、DNSサーバが、受信したDNSクエリパケットに応じてクライアントに送信するパケットの内容は、図17に示す内容と同様である。

図20に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAAAAレコードを問い合わせ、その応答が戻ってきた後で、Aレコードを問い合わせる方法である。すなわち、図20に示す方法は、AレコードとAAAAレコードを問い合わせる順番が逆になっている点において図17に示す方法と異なる。具体的には、まず、クライアントがホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv6アドレスs、tを検索し、検索したアドレスを含むパケットをクライアントに送信する。IPv6アドレスを含むパケットを受信したクライアントは、次に、ホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv4アドレスp、qを検索し、検索したアドレスを含むパケットをクライアントに送信する。

図21に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAAAAレコードを問い合わせ、その応答を待たずして、Aレコードを問い合わせる方法である。図21に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。そして、クライアントは、IPv6アドレスを含むパケットを受信する前に、ホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。なお、DNSサーバが、受信したDNSクエリパケットに応じてクライアントに送信するパケットの内容は、図20に示す内容と同様である。

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

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

概要

ノード情報記憶手段は、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶する。アドレス変換手段は、エントリのうち、端末装置から受信するレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換する。エントリ検索手段は、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定する。検索結果送信手段は、特定されたエントリに含まれるアドレスを端末装置に送信する。

目的

また、IPv4とIPv6両方の情報が存在する場合、新しいIPv6の方を優先して選択できるようにすることである

効果

実績

技術文献被引用数
- 件
牽制数
- 件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

アドレス及びレコードタイプをホスト名と対応付けエントリを記憶するノード情報記憶手段と、前記エントリのうち、レコードタイプと名前解決を行う対象のホスト名とを送信して当該ホスト名に対応するアドレスを問い合わせる端末装置から受信する当該レコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換手段と、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したホスト名に対応するエントリを特定するエントリ検索手段と、特定されたエントリに含まれるアドレスを前記端末装置に送信する検索結果送信手段とを備えたことを特徴とするネームデータベースサーバ

請求項2

アドレス変換手段は、エントリ検索手段が特定したエントリに含まれるアドレスのうち、端末装置から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換し、検索結果送信手段は、特定されたエントリに含まれる受信したレコードタイプのアドレスと、アドレス変換手段によって変換されたアドレスとを端末装置に送信する請求項1記載のネームデータベースサーバ。

請求項3

ノード情報記憶手段は、少なくともIPv6アドレスおよびIPv4アドレスをホスト名と対応付けたエントリを記憶し、エントリ検索手段は、端末装置からIPv6アドレスのレコードタイプと、名前解決を行う対象のホスト名とを受信したときに、前記ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスおよび/またはIPv4アドレスを示すレコードタイプのエントリを特定し、アドレス変換手段は、所定の規則に基づいて、エントリ検索手段が特定したエントリに含まれるIPv4アドレスをIPv6アドレスに変換し、検索結果送信手段は、エントリ検索手段が特定したエントリに含まれるIPv6アドレスと、アドレス変換手段によって変換されたIPv6アドレスとを端末装置に送信する請求項2記載のネームデータベースサーバ。

請求項4

アドレス変換手段は、端末装置からIPv6アドレスのレコードタイプを受信した場合に、IPv4アドレスを、IPv4mappedAddressに変換する請求項1から請求項3記載のネームデータベースサーバ。

請求項5

ノード情報記憶手段は、第一のレコードタイプのアドレスと、第二のレコードタイプのアドレスから変換された第一のレコードタイプのアドレスである変換アドレスとを、ホスト名と対応付けて記憶し、エントリ検索手段は、端末装置から第一のレコードタイプを受信したときに、前記ノード情報記憶手段を検索することにより、ホスト名に対応する当該第一のレコードタイプのエントリを特定し、検索結果送信手段は、特定されたエントリに含まれる第一のレコードタイプのアドレスを端末装置に送信する請求項1記載のネームデータベースサーバ。

請求項6

アドレス変換手段は、所定の規則に基づいて第二のレコードタイプのアドレスを第一のレコードタイプのアドレスに変換し、変換した第一のレコードタイプのアドレスを、ホスト名と対応付けてノード情報記憶手段に記憶させる請求項5記載のネームデータベースサーバ。

請求項7

ノード情報記憶手段は、少なくともIPv6アドレスと、所定の規則に基づいてIPv4アドレスから変換されたIPv6アドレスとを、ホスト名と対応付けて記憶し、エントリ検索手段は、端末装置からIPv6アドレスのレコードタイプを受信したときに、前記ノード情報記憶手段を検索することにより、ホスト名に対応するIPv6アドレスのエントリを特定し、検索結果送信手段は、特定されたエントリに含まれるIPv6アドレスを端末装置に送信する請求項5または請求項6記載のネームデータベースサーバ。

請求項8

ノード情報記憶手段は、IPv6アドレスとして、IPv4アドレスから変換されたIPv4mappedAddressをホスト名と対応付けて記憶する請求項5から請求項7のうちのいずれか1項に記載のネームデータベースサーバ。

請求項9

ホスト名に対するアドレスの問い合わせを行う端末装置と、前記端末装置からの問い合わせを受信するネームデータベースサーバとを備え、前記端末装置は、レコードタイプと名前解決を行う対象のホスト名とを前記ネームデータベースサーバに送信して、当該ホスト名に対応するアドレスを問い合わせるアドレス問合せ手段を備え、前記ネームデータベースサーバは、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段と、前記エントリのうち、前記端末装置から受信するレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換手段と、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したホスト名に対応するエントリを特定するエントリ検索手段と、特定されたエントリに含まれるアドレスを前記端末装置に送信する検索結果送信手段とを備えたことを特徴とする名前解決システム

請求項10

端末装置のアドレス問合せ手段は、IPv6アドレスのレコードタイプと、名前解決を行う対象のホスト名とをネームサーバに送信して、当該ホスト名に対応するアドレスを問い合わせ、ノード情報記憶手段は、少なくともIPv6アドレスおよびIPv4アドレスをホスト名と対応付けたエントリを記憶し、エントリ検索手段は、前記ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスおよび/またはIPv4アドレスを示すレコードタイプのエントリを特定し、アドレス変換手段は、所定の規則に基づいて、エントリ検索手段が特定したエントリに含まれるIPv4アドレスをIPv6アドレスに変換し、検索結果送信手段は、エントリ検索手段が特定したエントリに含まれるIPv6アドレスと、アドレス変換手段によって変換されたIPv6アドレスとを端末装置に送信する請求項9記載の名前解決システム。

請求項11

アドレス変換手段は、端末装置からIPv6アドレスのレコードタイプを受信した場合に、IPv4アドレスを、IPv4mappedAddressに変換する請求項9または請求項10記載の名前解決システム。

請求項12

ネームデータベースサーバのアドレス変換手段は、端末装置による問い合わせの結果を特定の端末装置のみ利用可能にする処理である特定処理を行い、端末装置は、前記特定処理が行われた問い合わせの結果を利用可能にする戻し変換手段を備えた請求項9から請求項11のうちのいずれか1項に記載の名前解決システム。

請求項13

ノード情報記憶手段は、少なくともIPv6アドレスと、所定の規則に基づいてIPv4アドレスから変換されたIPv6アドレスとを、ホスト名と対応付けて記憶し、エントリ検索手段は、端末装置からIPv6アドレスのレコードタイプを受信したときに、前記ノード情報記憶手段を検索することにより、ホスト名に対応するIPv6アドレスのエントリを特定し、検索結果送信手段は、特定されたエントリに含まれるIPv6アドレスを端末装置に送信する請求項9記載の名前解決システム。

請求項14

ノード情報記憶手段は、IPv6アドレスとして、IPv4アドレスから変換されたIPv4mappedAddressをホスト名と対応付けて記憶する請求項9または請求項13記載の名前解決システム。

請求項15

端末装置は、ネームデータベースサーバから受信したアドレスのうち、所定の規則に基づいて変換されたアドレスを、変換前のアドレスに変換する変換アドレス再変換手段を備えた請求項9から請求項14のうちのいずれか1項に記載の名前解決システム

請求項16

アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段に記憶された当該エントリのうち、レコードタイプと名前解決を行う対象のホスト名とを送信して当該ホスト名に対応するアドレスを問い合わせる端末装置から受信する当該レコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換し、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したホスト名に対応するエントリを特定し、特定されたエントリに含まれるアドレスを前記端末装置に送信することを特徴とするエントリ検索方法

請求項17

端末装置からIPv6アドレスのレコードタイプと、名前解決を行う対象のホスト名とを受信したときに、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスおよび/またはIPv4アドレスを示すレコードタイプのエントリを特定し、所定の規則に基づいて、特定されたエントリに含まれるIPv4アドレスをIPv6アドレスに変換し、特定されたエントリに含まれるIPv6アドレスと、IPv4アドレスが変換されたIPv6アドレスとを端末装置に送信する請求項16記載のエントリ検索方法。

請求項18

端末装置からIPv6アドレスのレコードタイプを受信したときに、少なくともIPv6アドレスと、所定の規則に基づいてIPv4アドレスから変換されたIPv6アドレスとを、ホスト名と対応付けて記憶するノード情報記憶手段を検索することにより、ホスト名に対応するIPv6アドレスのエントリを特定し、検索結果送信手段は、特定されたエントリに含まれるIPv6アドレスを端末装置に送信する請求項16記載のエントリ検索方法。

請求項19

ホスト名に対するアドレスの問い合わせを行う端末装置が、レコードタイプと名前解決を行う対象のホスト名とを前記ネームデータベースサーバに送信して、当該ホスト名に対応するアドレスを問い合わせ、前記ネームデータベースサーバが、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段に記憶された当該エントリのうち、前記端末装置から受信するレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換し、前記ネームデータベースサーバが、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したホスト名に対応するエントリを特定し、前記ネームデータベースサーバが、特定されたエントリに含まれるアドレスを前記端末装置に送信することを特徴とする名前解決方法

請求項20

ネームデータベースサーバが、端末装置からIPv6アドレスのレコードタイプと、名前解決を行う対象のホスト名とを受信したときに、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスおよび/またはIPv4アドレスを示すレコードタイプのエントリを特定し、ネームデータベースサーバが、所定の規則に基づいて、特定されたエントリに含まれるIPv4アドレスをIPv6アドレスに変換し、ネームデータベースサーバが、特定されたエントリに含まれるIPv6アドレスと、IPv4アドレスが変換されたIPv6アドレスとを端末装置に送信する請求項19記載の名前解決方法。

請求項21

ネームデータベースサーバが、端末装置からIPv6アドレスのレコードタイプを受信したときに、少なくともIPv6アドレスと、所定の規則に基づいてIPv4アドレスから変換されたIPv6アドレスとを、ホスト名と対応付けて記憶するノード情報記憶手段を検索することにより、ホスト名に対応するIPv6アドレスのエントリを特定し、ネームデータベースサーバが、特定されたエントリに含まれるIPv6アドレスを端末装置に送信する請求項19記載の名前解決方法。

請求項22

アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段を備えたコンピュータに適用されるエントリ検索プログラムであって、前記コンピュータに、前記エントリのうち、レコードタイプと名前解決を行う対象のホスト名とを送信して当該ホスト名に対応するアドレスを問い合わせる端末装置から受信する当該レコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換処理、前記ノード情報記憶手段を検索することにより、前記端末装置から受信したホスト名に対応するエントリを特定するエントリ検索処理、および、特定されたエントリに含まれるアドレスを前記端末装置に送信する検索結果送信処理を実行させるためのエントリ検索プログラム。

請求項23

コンピュータに、エントリ検索処理で、端末装置からIPv6アドレスのレコードタイプと、名前解決を行う対象のホスト名とを受信したときに、少なくともIPv6アドレスおよびIPv4アドレスをホスト名と対応付けたエントリを記憶するノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリであって、IPv6アドレスおよび/またはIPv4アドレスを示すレコードタイプのエントリを特定させ、アドレス変換処理で、所定の規則に基づいて、エントリ検索処理で特定されたエントリに含まれるIPv4アドレスをIPv6アドレスに変換させ、検索結果送信処理で、エントリ検索処理で特定されたエントリに含まれるIPv6アドレスと、アドレス変換処理で変換されたIPv6アドレスとを端末装置に送信させる請求項22記載のエントリ検索プログラム。

請求項24

コンピュータに、エントリ検索処理で、端末装置からIPv6アドレスのレコードタイプを受信したときに、少なくともIPv6アドレスと、所定の規則に基づいてIPv4アドレスから変換されたIPv6アドレスとを、ホスト名と対応付けて記憶するノード情報記憶手段を検索することにより、ホスト名に対応するIPv6アドレスのエントリを特定させ、検索結果送信処理で、特定されたエントリに含まれるIPv6アドレスを端末装置に送信させる請求項22記載のエントリ検索プログラム。

技術分野

0001

本発明は、IPv4(Internet Protocol version 4 )とIPv6(Internet Protocol version 6 )とが混在する通信環境名前解決を行う際に用いられるネームデータベースサーバ名前解決システムエントリ検索方法名前解決方法およびエントリ検索プログラムに関する。

背景技術

0002

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

0003

図15は、IPv4のみの通信環境において名前解決を行う場合の説明図である。図15は、ホスト名「hostX」に対し、レコードタイプを「A」とするIPv4アドレスp、qのエントリが2つDNS(Domain Name System)サーバに登録されていることを示す。クライアント端末からDNSサーバに対し、IPv4のレコードタイプ「A」を指定してホスト名「hostX」のアドレスを問い合わせるパケットが送信されると、DNSサーバは、hostXに対応するIPv4アドレスを含むエントリを検索する。そして、DNSサーバは、検索したIPv4アドレスを含むパケットをクライアント端末に送信する。図15に示す例では、DNSサーバは、hostXのIPv4アドレスとしてアドレスp及びqを含むパケットを、クライアント端末に送信する。以下、ホスト名とレコードタイプとを指定して、ホスト名に対応するアドレスを問い合わせるパケットを、DNSクエリパケットと記す。

0004

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

0005

IPv4とIPv6とが混在する通信環境において名前解決を行う方法が、各種提案されている。図16は、IPv4とIPv6とが混在する通信環境でDNSサーバが記憶する情報の例を示す説明図である。以下、IPv6アドレスのレコードタイプを「AAAA」と記し、IPv4アドレスのレコードタイプを「A」と記す。また、図16は、ホスト名「hostX」に対し、レコードタイプを「A」とするIPv4アドレスp、qのエントリが2つ、レコードタイプを「AAAA」とするIPv6アドレスs、tのエントリが2つ、合計4つのエントリがDNS(Domain Name System)サーバに登録されていることを示す。以下、IPv4とIPv6とが混在する通信環境で名前解決が行われる場合、DNSサーバが図16に示す情報を記憶しているものとして説明する。

0006

ここで、DNSにおいてアドレスを問い合わせる装置(例えば、クライアント端末)が用いるAPI(Application Programming Interface )を説明する。DNSにおける名前解決処理には、原始的な処理を行う低級APIの集合であるresolver Libraryが用いられる。具体的には、DNSにおいて、サーバ側が備えるデータベースに記憶されたデータそのものを直接抽出するような低級な処理を行うコマンド(例えば、nslookup、dig、hostなど)が、このresolver Libraryに含まれる。

0007

一方、ユーザランドにおいて用いられる通信アプリケーションは、直接resolver Libraryを呼び出さず、高級APIを用いることが一般的である。高級APIの内部では、resolver Libraryが用いられるが、ユーザは、その内部のAPIを意識する必要はない。

0008

具体的には、IPv4のみの通信環境では、高級APIとしてgethostbyname()が用いられていた。しかし、IPv6の登場とともに、IPv4のみの通信環境に対応したgethostbyname()は使われなくなり、現在では、getaddrinfo()が用いられている。getaddrinfo()は、IPv4及びIPv6両方のプロトコルマルチプロトコル)に対応した関数である。getaddrinfo()関数では、レコードタイプ(具体的には、ネットワークアドレスの種類を表すアドレスファミリ)を指定して問い合わせが行われる。アドレスファミリには、IPv4(PF_INET)、IPv6(PF_INET6)、または、どちらでもよい(PF_UNSPEC)のいずれかが指定される。なお、問い合わせ結果(アドレス)は、リスト形式返却される。

0009

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

0010

具体的には、高級APIでは、レコードタイプを意識せずに(例えば、PF_UNSPECを指定した)通信アプリケーションが作成される。一方、resolver Libraryは、高級APIから呼び出されると、名前解決するレコードタイプを指定して、DNSサーバにアドレスを問い合わせることになる。これは、DNSサーバがエントリを検索する際、アドレスとレコードタイプとが必要になるからである。

0011

図17図21は、IPv4とIPv6とが混在する通信環境でDNSサーバにアドレスを問い合わせる動作を示す説明図である。以下、IPv4アドレスを含むエントリをAレコードと記し、IPv6アドレスを含むエントリをAAAAレコードと記す。

0012

図17に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAレコードを問い合わせ、その応答が戻ってきた後で(すなわち、戻るまで待機してから)、AAAAレコードを問い合わせる方法である。図17に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv4アドレスp、qを検索し、検索したアドレスを含むパケットをクライアントに送信する。IPv4アドレスを含むパケットを受信したクライアントは、次に、ホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv6アドレスs、tを検索し、検索したアドレスを含むパケットをクライアントに送信する。

0013

図18に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAレコードを問い合わせ、戻ってきた応答内容によって、AAAAレコードを問い合わせる否かを判断する方法である。すなわち、図18に示す方法は、IPv4アドレスp,qの応答内容によって、AAAAレコードを問い合わせる否かを判断する点において図17に示す方法と異なる。図17に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv4アドレスp、qを検索し、検索したアドレスを含むパケットをクライアントに送信する。IPv4アドレスを含むパケットを受信したクライアントは、そのパケットに含まれる内容によって、ホスト名「hostX」とレコードタイプ「AAAA」とを指定したDNSクエリパケットをDNSサーバに送信するか否かを判断する。なお、DNSクエリパケットをDNSサーバに送信すると判断した場合、以降の処理は、図17に示す方法と同様である。

0014

図19に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAレコードを問い合わせ、その応答を待たずして、AAAAレコードを問い合わせる方法である。図19に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そして、クライアントは、IPv4アドレスを含むパケットを受信する前に、ホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。なお、DNSサーバが、受信したDNSクエリパケットに応じてクライアントに送信するパケットの内容は、図17に示す内容と同様である。

0015

図20に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAAAAレコードを問い合わせ、その応答が戻ってきた後で、Aレコードを問い合わせる方法である。すなわち、図20に示す方法は、AレコードとAAAAレコードを問い合わせる順番が逆になっている点において図17に示す方法と異なる。具体的には、まず、クライアントがホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv6アドレスs、tを検索し、検索したアドレスを含むパケットをクライアントに送信する。IPv6アドレスを含むパケットを受信したクライアントは、次に、ホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。そうすると、DNSサーバは、対応するIPv4アドレスp、qを検索し、検索したアドレスを含むパケットをクライアントに送信する。

0016

図21に示す方法は、DNSサーバに対し、まず、ホスト名に対応するAAAAレコードを問い合わせ、その応答を待たずして、Aレコードを問い合わせる方法である。図21に示す方法では、まず、クライアントがホスト名「hostX」とレコードタイプ「AAAA」を指定したDNSクエリパケットをDNSサーバに送信する。そして、クライアントは、IPv6アドレスを含むパケットを受信する前に、ホスト名「hostX」とレコードタイプ「A」を指定したDNSクエリパケットをDNSサーバに送信する。なお、DNSサーバが、受信したDNSクエリパケットに応じてクライアントに送信するパケットの内容は、図20に示す内容と同様である。

0017

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

0018

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

先行技術

0019

特開2010−183242号公報

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

0020

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

0021

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

0022

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

0023

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

0024

特許文献1に記載された通信装置も、図18に示す方法と同様に、一方の問い合わせの応答内容によって、問い合わせが複数回発生する。このような複雑な構成にすることなく、一回の問い合わせで複数のレコードタイプのアドレスについて名前解決できることが望ましい。

0025

そこで、本発明は、IPv4とIPv6とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、IPv4とIPv6のいずれについても名前解決できるネームデータベースサーバ、名前解決システム、エントリ検索方法、名前解決方法およびエントリ検索プログラムを提供することを目的とする。

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

0026

本発明によるネームデータベースサーバは、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段と、エントリのうち、レコードタイプと名前解決を行う対象のホスト名とを送信してそのホスト名に対応するアドレスを問い合わせる端末装置から受信するそのレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換手段と、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定するエントリ検索手段と、特定されたエントリに含まれるアドレスを端末装置に送信する検索結果送信手段とを備えたことを特徴とする。

0027

本発明による名前解決システムは、ホスト名に対するアドレスの問い合わせを行う端末装置と、端末装置からの問い合わせを受信するネームデータベースサーバとを備え、端末装置が、レコードタイプと名前解決を行う対象のホスト名とをネームデータベースサーバに送信して、そのホスト名に対応するアドレスを問い合わせるアドレス問合せ手段を備え、ネームデータベースサーバが、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段と、エントリのうち、端末装置から受信するレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換手段と、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定するエントリ検索手段と、特定されたエントリに含まれるアドレスを端末装置に送信する検索結果送信手段とを備えたことを特徴とする。

0028

本発明によるエントリ検索方法は、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段に記憶されたそのエントリのうち、レコードタイプと名前解決を行う対象のホスト名とを送信してそのホスト名に対応するアドレスを問い合わせる端末装置から受信するそのレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換し、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定し、特定されたエントリに含まれるアドレスを端末装置に送信することを特徴とする。

0029

本発明による名前解決方法は、ホスト名に対するアドレスの問い合わせを行う端末装置が、レコードタイプと名前解決を行う対象のホスト名とをネームデータベースサーバに送信して、そのホスト名に対応するアドレスを問い合わせ、ネームデータベースサーバが、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段に記憶されたそのエントリのうち、端末装置から受信するレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換し、ネームデータベースサーバが、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定し、ネームデータベースサーバが、特定されたエントリに含まれるアドレスを端末装置に送信することを特徴とする。

0030

本発明によるエントリ検索プログラムは、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段を備えたコンピュータに適用されるエントリ検索プログラムであって、エントリのうち、レコードタイプと名前解決を行う対象のホスト名とを送信してそのホスト名に対応するアドレスを問い合わせる端末装置から受信するそのレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換処理、ノード情報記憶手段を検索することにより、端末装置から受信したホスト名に対応するエントリを特定するエントリ検索処理、および、特定されたエントリに含まれるアドレスを端末装置に送信する検索結果送信処理を実行させることを特徴とする。

発明の効果

0031

本発明によれば、IPv4とIPv6とが混在する通信環境であっても、ホスト名を一度問い合わせるだけで、IPv4とIPv6のいずれについても名前解決できる。

図面の簡単な説明

0032

名前解決を行う動作の例を示す説明図である。
本発明の第1の実施形態における名前解決システムの例を示すブロック図である。
名前解決を行う動作の例を示すシーケンス図である。
名前解決を行う動作の例を示す説明図である。
本発明の第2の実施形態における名前解決システムの例を示すブロック図である。
名前解決を行う動作の例を示すシーケンス図である。
名前解決を行う動作の例を示す説明図である。
本発明の第3の実施形態における名前解決システムの例を示すブロック図である。
名前解決を行う動作の例を示すシーケンス図である。
名前解決を行う動作の例を示す説明図である。
本発明の第4の実施形態における名前解決システムの例を示すブロック図である。
名前解決を行う動作の例を示すシーケンス図である。
本発明による名前解決システムの最小構成の例を示すブロック図である。
本発明によるネームデータベースサーバの最小構成の例を示すブロック図である。
IPv4のみの通信環境において名前解決を行う場合の説明図である。
DNSサーバが記憶する情報の例を示す説明図である。
DNSサーバにアドレスを問い合わせる動作を示す説明図である。
DNSサーバにアドレスを問い合わせる動作を示す説明図である。
DNSサーバにアドレスを問い合わせる動作を示す説明図である。
DNSサーバにアドレスを問い合わせる動作を示す説明図である。
DNSサーバにアドレスを問い合わせる動作を示す説明図である。

実施例

0033

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

0034

実施形態1.
まず、図1を参照して、第1の実施形態における名前解決システムの概要を説明する。図1は、名前解決を行う動作の例を示す説明図である。第1の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名(図1では、「hostX」)とレコードタイプ(図1では、「AAAA+A」)とを指定したDNSクエリパケットをDNSサーバに対して送信する。ここで指定されるレコードタイプ「AAAA+A」とは、「A」や「AAAA」といったDNSサーバに記憶されるレコードタイプとは異なる仮想のレコードタイプである。

0035

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

0036

次に、DNSクエリパケットを受信したDNSサーバは、指定された仮想のレコードタイプ「AAAA+A」に応じて予め定められたルールに従って、検索対象のレコードタイプを決定する。そして、DNSサーバは、決定したレコードタイプ及び受信したホスト名に対応するエントリを検索する。図1に示す例では、レコードタイプ「AAAA」及び「A」のエントリが検索される。そして、DNSサーバは、検索したエントリに含まれるIPv6アドレスおよびIPv4アドレス(図1では、s,t,p,q)を含む返信パケットをクライアントに送信する。

0037

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

0038

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

0039

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

0040

アドレス問合せ手段11は、例えば、プログラムに従って動作するコンピュータ(端末装置10)のCPUによって実現される。

0041

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

0042

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

0043

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

0044

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

0045

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

0046

エントリ検索手段23は、ノード情報記憶手段21を検索することにより、受信したエントリ特定情報に対応するエントリであって、検索対象レコード決定手段22が決定したレコードタイプのエントリを特定する。例えば、検索対象レコード決定手段22が検索対象とするエントリのレコードタイプを「AAAA」及び「A」と決定したとする。この場合、エントリ検索手段23は、ノード情報記憶手段21を検索して、端末装置10から受信したホスト名に対応するIPv4アドレスとIPv6アドレスとを含むエントリを特定する。

0047

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

0048

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

0049

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

0050

次に、ホスト名とレコードタイプ「AAAA+A」とを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv4アドレス及びIPv6アドレスのいずれのアドレスもクライアントに返信する動作を説明する。なお、クライアントが端末装置10に対応し、DNSサーバがネームデータベースサーバ20に対応する。

0051

図3は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段11は、ホスト名と仮想のレコードタイプ「AAAA+A」とを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせる(ステップS1)。DNSサーバの検索対象レコード決定手段22は、仮想のレコードタイプ「AAAA+A」を含むパケットを受信すると、予め定められた検索ルールに従って、検索対象とするレコードタイプを「AAAA」及び「A」と決定する(ステップS2)。

0052

次に、エントリ検索手段23は、ノード情報記憶手段21を検索して、受信したホスト名に対応するレコードタイプ「AAAA」及び「A」のエントリを特定する(ステップS3)。具体的には、エントリ検索手段23は、IPv4アドレスとIPv6アドレスとを含むエントリを特定する。

0053

そして、検索結果送信手段24は、エントリ検索手段23が特定したエントリのIPv4アドレスとIPv6アドレスとを含むパケットをクライアントに送信する(ステップS4)

0054

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

0055

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

0056

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

0057

実施形態2.
次に、図4を参照して、第2の実施形態における名前解決システムの概要を説明する。図4は、名前解決を行う動作の例を示す説明図である。第2の実施形態における名前解決システムでは、まず、クライアントが、名前解決を行う対象のホスト名(図4では、「hostX」)とIPv6アドレスのレコードタイプ(図4では、「AAAA」)とを指定したDNSクエリパケットをDNSサーバに対して送信する。次に、DNSクエリパケットを受信したDNSサーバは、受信したホスト名のエントリのうち、指定されたレコードタイプ「AAAA」のエントリだけでなく、レコードタイプ「A」のエントリも検索する。図4に示す例では、この結果、ホスト名「hostX」に一致するエントリに含まれるアドレスp,q,s,tが特定される。

0058

そして、DNSサーバは、レコードタイプが「A」のIPv4アドレスp,qを、受信したレコードタイプのアドレスであるIPv6アドレスに変換する。以下、IPv6アドレスに変換されたアドレスp,qを、p’,q’と記す。そして、DNSサーバは、これらのIPv6アドレスs,t, p’,q’を含むパケットをクライアントに送信する。IPv6アドレスを受信したクライアントは、変換されたアドレスp’,q’を、変換前のIPv4アドレスp,qに戻し変換する。

0059

IPv4アドレスをIPv6アドレスへ変換する方法として、例えば、IPv4アドレスをIPv4 mapped IPv6 Address(以下、IPv4 mapped Addressと記す。)へ変換する方法が用いられる。IPv4 mapped AddressからIPv4アドレスへの変換処理は、通常カーネルで行われる。そのため、IPv4アドレスをIPv4 mapped Addressに変換することで、クライアント側のユーザランドにおけるアプリケーションにおいて、戻し変換処理が不要になる。

0060

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

0061

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

0062

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

0063

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

0064

アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、端末装置30から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換する。具体的には、端末装置30からレコードタイプ「AAAA」を示すパケットを受信した場合、アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、レコードタイプが「A」のアドレス(IPv4アドレス)を、所定の規則に基づいて、レコードタイプ「AAAA」のアドレス(IPv6アドレス)に変換する。なお、受信したレコードタイプと異なるレコードタイプのアドレスを、受信したレコードタイプのアドレスに変換する規則については、レコードタイプごとに予め定めておけばよい。

0065

例えば、IPv4アドレスをIPv6アドレスに変換する規則として、IPv4アドレスをIPv4 mapped Addressに変換すると定めてもよい。具体的には、端末装置30からレコードタイプ「AAAA」を受信した場合、アドレス変換手段42は、IPv4 mapped Addressとして定義されるフォーマットに基づいてエントリ検索手段41が特定したIPv4アドレスをIPv6アドレスに変換する。

0066

なお、IPv4 mapped Addressの定義は、以下の参考文献1「2.5.5.2. IPv4-Mapped IPv6 Address 」に記載されている。また、IPv4 mapped Addressの使用方法(機能)は、以下の参考文献2に記載されている。そのため、詳細な説明は省略する。

0067

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

0068

なお、IPv4アドレスをIPv6アドレスに変換する方法は、IPv4アドレスをIPv4 mapped Addressに変換する方法に限定されない。クライアント側(端末装置30)で、もとのIPv4アドレスが取り出せる方法であれば、他の変換アルゴリズムが用いられていてもよい。変換する方法についての仕様は、データの送受信が行われる装置間で定められていれば、上記フォーマットに限られない。例えば、任意のビットパターンをIPv4アドレスの前後に付加することで、IPv4アドレスをIPv6アドレスに変換してもよい。これは、IPv6アドレス空間は極めて広大であるため、IPv6アドレス空間にIPv4アドレスを含めることは容易だからである。

0069

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

0070

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

0071

エントリ検索手段41と、アドレス変換手段42と、検索結果送信手段43とは、プログラム(エントリ検索プログラム)に従って動作するコンピュータのCPUによって実現される。また、エントリ検索手段41と、アドレス変換手段42と、検索結果送信手段43とが、それぞれが専用のハードウェアで実現されていてもよい。

0072

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

0073

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

0074

変換アドレス再変換手段32は、受信したアドレスのうち、所定のフォーマットのアドレスを、変換前のアドレスに変換するアドレスと特定してもよい。例えば、アドレス変換手段42がIPv4 mapped Addressのフォーマットに従ってIPv4アドレスをIPv6アドレスに変換しているとする。この場合、変換アドレス再変換手段32は、受信したIPv6アドレスのうちIPv4 mapped Addressのフォーマットのアドレスを変換対象のアドレスと特定してもよい。このとき、変換アドレス再変換手段32は、IPv4 mapped AddressのフォーマットのIPv6アドレスを変換前のIPv4アドレスに変換すればよい。

0075

なお、一般的に、ユーザランドの通信アプリケーションがIPv4 mapped Addressを用いる場合、カーネルにおいて、そのアドレスがIPv4 mapped Addressか否かの判断が行われる。そして、アドレスがIPv4 mapped Addressと判断された場合、カーネルでこのアドレスが認識され、このアドレスがIPv4アドレスに変換される。

0076

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

0077

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

0078

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

0079

次に、ホスト名とレコードタイプ「AAAA」とを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv6アドレスと、IPv4アドレスをIPv6アドレスに変換したアドレスとをクライアントに返信する動作を説明する。なお、クライアントが端末装置30に対応し、DNSサーバがネームデータベースサーバ40に対応する。

0080

図6は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段31は、ホスト名とレコードタイプ「AAAA」とを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせる(ステップS11)。DNSサーバのエントリ検索手段41は、クライアントからDNSクエリパケットを受信すると、ノード情報記憶手段21を検索して、受信したホスト名に対応するエントリを特定する(ステップS12)。具体的には、エントリ検索手段41は、ホスト名に対応するIPv6アドレス及びIPv4アドレスを含むエントリを特定する。続いて、アドレス変換手段42は、エントリ検索手段41が特定したエントリに含まれるアドレスのうち、IPv4アドレスを、所定の規則に基づいて、IPv6アドレスに変換する(ステップS13)。そして、検索結果送信手段43は、ホスト名に対応するアドレスを含むパケットをクライアントに送信する(ステップS14)。

0081

クライアントがアドレスを含むパケットを受信すると、変換アドレス再変換手段32は、DNSサーバから受信したアドレスのうち、IPv6アドレスに変換されたIPv4アドレスを、変換前のIPv4アドレスに変換する(ステップS15)。

0082

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

0083

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

0084

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

0085

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

0086

また、アドレス変換手段42が、端末装置30からレコードタイプとしてIPv6アドレスを示すレコードタイプが指定されたときに、ノード情報記憶手段21から抽出されたIPv4アドレスを、IPv4 mapped Addressに変換してもよい。この場合、通常のカーネルで実装されるIPv4 mapped AddressとIPv4アドレスの変換機能を用いることが出来る。そのため、クライアントのアプリケーション側では、新たな戻し変換処理を追加する必要が無くなる。したがって、多数存在するクライアントのアプリケーションへの影響を抑えることができる。また、この場合、ネームデータベースサーバ40(例えば、DNSサーバ)側に本実施形態における機能を実装するだけで対応できるため、影響範囲を小さく抑えることが出来る。

0087

次に、第2の実施形態の変形例を説明する。第2の実施形態では、アドレス変換手段42がIPv4アドレスをIPv6アドレスに変換し、変換アドレス再変換手段32が変換後のIPv6アドレスを変換前のIPv4アドレスに変換する場合について説明した。本変形例では、アドレス変換手段42がアドレスの変換以外の処理も行う場合について説明する。

0088

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

0089

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

0090

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

0091

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

0092

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

0093

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

0094

次に、端末装置30が行う戻し処理を説明する。第2の実施形態で説明したIPv4アドレスをIPv4 mapped Addressに変換する処理は、通常、カーネルで行われることになる。そのため、ユーザランドのアプリケーションでは、この変換処理を意識する必要はない。一方、IPv4 mapped Addressへの変換処理以外の処理を端末装置30が行う場合、DNSクエリの返信パケットを受け取る部分、または、その返信パケットの伝達先が戻し変換処理を実装することになる。

0095

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

0096

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

0097

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

0098

この状態から、まず、クライアントが、名前解決を行う対象のホスト名(図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に戻し変換する。

0099

IPv4アドレスをIPv6アドレスへ変換する方法として、例えば、IPv4アドレスをIPv4 mapped IPv6 Address(以下、IPv4 mapped Addressと記す。)へ変換する方法が用いられる。IPv4 mapped AddressからIPv4アドレスへの変換処理は、通常カーネルで行われるため、IPv4アドレスをIPv4 mapped Addressに変換することで、クライアント側のユーザランドにおけるアプリケーションにおいて、戻し変換処理が不要になる。

0100

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

0101

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

0102

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

0103

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

0104

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

0105

具体的には、アドレス変換手段52は、ノード情報記憶手段21に記憶されたIPv4アドレスを、所定の規則に基づいてIPv6アドレスに変換する。そして、アドレス変換手段52は、変換したIPv6アドレス(すなわち、変換アドレス)を含むエントリと、ノード情報記憶手段21に記憶された未変換のIPv6アドレスを含むエントリのいずれも、変換アドレス記憶手段51に記憶させる。

0106

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

0107

エントリ検索手段53は、変換アドレス記憶手段51を検索することにより、端末装置30から受信したホスト名およびレコードタイプに対応するエントリを特定する。例えば、端末装置30からレコードタイプ「AAAA」を受信した場合、エントリ検索手段53は、ホスト名に対応するエントリのうち、レコードタイプが「AAAA」であるエントリ(すなわち、IPv6アドレスを含むエントリ)を特定する。

0108

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

0109

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

0110

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

0111

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

0112

アドレス変換手段52は、所定の規則として、IPv4アドレスをIPv4 mapped Addressに変換する規則を用いてもよい。このIPv4 mapped Addressは、IPv4アドレスをIPv6アドレスに変換したものである。そのため、変換後のアドレスをDNSのデータベースに登録する上での問題は生じない。

0113

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

0114

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

0115

アドレス変換手段52と、エントリ検索手段53と、検索結果送信手段54とは、プログラム(エントリ検索プログラム)に従って動作するコンピュータのCPUによって実現される。また、アドレス変換手段52と、エントリ検索手段53と、検索結果送信手段54とは、それぞれが専用のハードウェアで実現されていてもよい。

0116

次に、ホスト名とレコードタイプ「AAAA」とを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv6アドレスと、IPv4アドレスをIPv6アドレスに変換したアドレスとをクライアントに返信する動作を説明する。なお、クライアントが端末装置30に対応し、DNSサーバがネームデータベースサーバ50に対応する。

0117

図9は、名前解決を行う動作の例を示すシーケンス図である。DNSサーバでは、アドレス変換手段52が、所定のタイミングでノード情報記憶手段21に記憶されたIPv4アドレスをIPv6アドレスに変換する。そして、アドレス変換手段52は、変換したIPv6アドレスを含むエントリを変換アドレス記憶手段51に記憶させる(ステップS21)。

0118

一方、クライアントのアドレス問合せ手段31は、ホスト名とレコードタイプ「AAAA」とを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせる(ステップS11)。クライアントからDNSクエリパケットを受信すると、エントリ検索手段53は、変換アドレス記憶手段51を検索して、受信したホスト名およびレコードタイプ「AAAA」のエントリを特定する(ステップS22)。そして、検索結果送信手段54は、特定されたエントリのアドレスを含むパケットをクライアントに送信する(ステップS23)。

0119

クライアントがアドレスを含むパケットを受信すると、変換アドレス再変換手段32は、DNSサーバから受信したアドレスのうち、IPv6アドレスに変換されたIPv4アドレスを、変換前のIPv4アドレスに変換する(ステップS15)。

0120

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

0121

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

0122

また、アドレス変換手段52が、第一のレコードタイプのアドレス(IPv4アドレス)を、所定の規則に基づいて、第二のレコードタイプのアドレス(IPv6アドレス)に変換してもよい。そして、アドレス変換手段52は、変換したアドレスをノード情報記憶手段21に記憶させるようにしてもよい。

0123

実施形態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を含むパケットをクライアントに送信する。

0124

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

0125

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

0126

端末装置60は、アドレス問合せ手段61を備えている。アドレス問合せ手段61は、ホスト名とともに、複数のレコードタイプをネームデータベースサーバ70に送信し、ホスト名に対するアドレスの問い合わせを行う。送信するレコードタイプには、ノード情報記憶手段21に記憶されたレコードタイプが指定される。具体的には、アドレス問合せ手段61は、ホスト名とともに「A」及び「AAAA」(すなわち、IPv4アドレスを示すレコードタイプ及びIPv6アドレスを示すレコードタイプ)をネームデータベースサーバ70に送信する。アドレス問合せ手段61は、例えば、プログラムに従って動作するコンピュータ(端末装置60)のCPUによって実現される。

0127

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

0128

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

0129

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

0130

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

0131

次に、ホスト名とレコードタイプ「A」及び「AAAA」とを指定してクライアントからアドレスの問い合わせが行われた場合に、DNSサーバが、IPv6アドレス及びIPv4アドレスをクライアントに返信する動作を説明する。なお、クライアントが端末装置60に対応し、DNSサーバがネームデータベースサーバ70に対応する。

0132

図12は、名前解決を行う動作の例を示すシーケンス図である。クライアントのアドレス問合せ手段61は、ホスト名とレコードタイプ「A」及び「AAAA」とを指定したDNSクエリパケットをDNSサーバに送信して、ホスト名に対するアドレスを問い合わせる(ステップS31)。DNSサーバがクライアントからDNSクエリパケットを受信すると、エントリ検索手段71は、ノード情報記憶手段21を検索して、ホスト名に対応するエントリであって、レコードタイプが「A」または「AAAA」であるエントリを特定する(ステップS32)。そして、検索結果送信手段72は、特定されたエントリのアドレスを含むパケットをクライアントに送信する(ステップS33)。

0133

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

0134

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

0135

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

0136

図13に例示する名前解決システムは、ホスト名に対するアドレスの問い合わせを行う端末装置90(例えば、端末装置30)と、端末装置90からの問い合わせを受信するネームデータベースサーバ80(例えば、ネームデータベースサーバ40)とを備えている。

0137

端末装置90は、レコードタイプ(例えば、「AAAA」)と名前解決を行う対象のホスト名とをネームデータベースサーバ80に送信して、そのホスト名に対応するアドレスを問い合わせるアドレス問合せ手段81(例えば、アドレス問合せ手段31)を備えている。

0138

ネームデータベースサーバ80は、アドレス及びレコードタイプをホスト名と対応付けたエントリを記憶するノード情報記憶手段81(例えば、ノード情報記憶手段21)と、エントリのうち、端末装置90から受信するレコードタイプ(例えば、「AAAA」)と異なるレコードタイプ(例えば、「A」)のアドレス(例えば、IPv4アドレス)を、所定の規則に基づいて、受信するレコードタイプのアドレスに変換するアドレス変換手段82(例えば、アドレス変換手段42)と、ノード情報記憶手段81を検索することにより、端末装置90から受信したホスト名に対応するエントリを特定するエントリ検索手段83(例えば、エントリ検索手段41)と、特定されたエントリに含まれるアドレスを端末装置に送信する検索結果送信手段84(例えば、検索結果送信手段43)とを備えている。

0139

また、図14に例示するネームデータベースサーバは、ノード情報記憶手段81(例えば、ノード情報記憶手段21)と、アドレス変換手段82(例えば、アドレス変換手段42)と、エントリ検索手段83(例えば、エントリ検索手段41)と、検索結果送信手段84(例えば、検索結果送信手段43)とを備えている。なお、ノード情報記憶手段81、アドレス変換手段82、エントリ検索手段83および検索結果送信手段84の内容は、図13に示す内容と同様である。

0140

以上のような構成により、IPv4とIPv6とが混在する通信環境であっても、一の問い合わせでIPv4とIPv6のいずれについても名前解決できる。

0141

また、アドレス変換手段82が、エントリ検索手段83が特定したエントリに含まれるアドレスのうち、端末装置から受信したレコードタイプと異なるレコードタイプのアドレスを、所定の規則に基づいて、受信したレコードタイプのアドレスに変換し、検索結果送信手段84が、特定されたエントリに含まれる受信したレコードタイプのアドレスと、アドレス変換手段82によって変換されたアドレスとを端末装置に送信する構成であってもよい。

0142

また、ノード情報記憶手段81が、少なくともIPv6アドレスおよびIPv4アドレスをホスト名と対応付けたエントリを記憶し、エントリ検索手段83が、端末装置90からIPv6アドレスのレコードタイプと、名前解決を行う対象のホスト名とを受信したときに、ノード情報記憶手段81を検索することにより、端末装置90から受信したホスト名に対応するエントリであって、IPv6アドレスおよび/またはIPv4アドレスを示すレコードタイプのエントリを特定し、アドレス変換手段82が、所定の規則に基づいて、エントリ検索手段83が特定したエントリに含まれるIPv4アドレスをIPv6アドレスに変換し、検索結果送信手段84が、エントリ検索手段83が特定したエントリに含まれるIPv6アドレスと、アドレス変換手段82によって変換されたIPv6アドレスとを端末装置に送信する構成であってもよい。なお、「IPv6アドレスおよび/またはIPv4アドレス」とは、「IPv6アドレス」、「IPv4アドレス」、または「IPv6アドレスとIPv4アドレスの双方」を表す。

0143

また、アドレス変換手段82は、端末装置90からIPv6アドレスのレコードタイプを受信した場合に、IPv4アドレスを、IPv4 mapped Addressに変換してもよい。

0144

また、ノード情報記憶手段81(例えば、変換アドレス記憶手段51)が、第一のレコードタイプのアドレス(例えば、IPv6アドレス)と、第二のレコードタイプのアドレス(IPv4アドレス)から変換された第一のレコードタイプのアドレスである変換アドレスとを、ホスト名と対応付けて記憶し、エントリ検索手段83(例えば、エントリ検索手段53)が、端末装置90から第一のレコードタイプを受信したときに、ノード情報記憶手段81を検索することにより、ホスト名に対応するその第一のレコードタイプのエントリを特定し、検索結果送信手段84(例えば、検索結果送信手段54)が、特定されたエントリに含まれる第一のレコードタイプのアドレスを端末装置90に送信する構成であってもよい。

0145

また、アドレス変換手段82(例えば、アドレス変換手段53)は、所定の規則に基づいて第二のレコードタイプのアドレスを第一のレコードタイプのアドレスに変換し、変換した第一のレコードタイプのアドレスを、ホスト名と対応付けてノード情報記憶手段81(例えば、変換アドレス記憶手段51、ノード情報記憶手段21)に記憶させてもよい。

0146

また、ノード情報記憶手段81(例えば、変換アドレス記憶手段51)が、少なくともIPv6アドレスと、所定の規則に基づいてIPv4アドレスから変換されたIPv6アドレスとを、ホスト名と対応付けて記憶し、エントリ検索手段83(例えば、エントリ検索手段53)が、端末装置90からIPv6アドレスのレコードタイプを受信したときに、ノード情報記憶手段81を検索することにより、ホスト名に対応するIPv6アドレスのエントリを特定し、検索結果送信手段84が、特定されたエントリに含まれるIPv6アドレスを端末装置に送信する構成であってもよい。

0147

また、ノード情報記憶手段81(例えば、変換アドレス記憶手段51、ノード情報記憶手段21)は、IPv6アドレスとして、IPv4アドレスから変換されたIPv4 mapped Addressをホスト名と対応付けて記憶してもよい。

0148

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

0149

この出願は、2010年10月18日に出願された日本特許出願2010−233413を基礎とする優先権を主張し、その開示の全てをここに取り込む。

0150

本発明は、IPv4とIPv6とが混在する通信環境で名前解決を行う際に用いられるネームデータベースサーバに好適に適用される。

0151

10,30,60端末装置
11,31,61アドレス問合せ手段
20,40,50,70ネームデータベースサーバ
21ノード情報記憶手段
22検索対象レコード決定手段
24,43,54,72検索結果送信手段
32変換アドレス再変換手段
23,41,53,71エントリ検索手段
42,52アドレス変換手段
51 変換アドレス記憶手段

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

この 技術と関連性が強い技術

該当するデータがありません

この 技術と関連性が強い法人

該当するデータがありません

この 技術と関連性が強い人物

該当するデータがありません

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ