パソコン実習室
アドレス検索 - DNSの話
≪　previous 　

Ⅵ．名前解決

　DNSは通信相手のホスト名からIPアドレス(あるいはその逆)を検索するシステムで、この一連の検索処理を名前解決 (name resolution)、または単に解決 (resolution) と呼びます。


Ⅵ．１．正引き (IPアドレス検索)

　ホスト(ドメイン)名からIPアドレスを検索するために、リゾルバやネームサーバーはどのようなDNSメッセージを交わしているのか、少し具体的に見ることにしましょう。

Ⅵ．１．１．正引きの手順

　例として、project研究所のLinux部門が公開しているwebサーバー www.linux.project.ed.jp (Ⅲ.2.ゾーンとドメイン の図を参照 )に、外部のユーザーがアクセスする時の名前解決の様子を追ってみましょう。


①ブラウザとスタブリゾルバの処理
　ユーザーがブラウザを起動して www.linux.project.ed.jp へのアクセスを開始すると、ブラウザは入力されたアドレスをスタブリゾルバに渡して名前解決(IPアドレスの検索)を依頼します。
　スタブリゾルバはパソコン内に該当キャッシュがあれば、キャッシュのデータ(IPアドレス)をブラウザに返しますが、キャッシュが無い事を確認すると問い合わせ用のDNSメッセージを組み立ててローカルネームサーバーへ送信します。
※　ローカルネームサーバーのIPアドレスは、パソコンの [ ネットワーク接続 ] に設定済みの [ DNS
　　サーバーのアドレス ] を参照します。　( Ⅳ．２．３．ローカルネームサーバー 参照 )
ヘッダ部問い合わせ部
QR=0(問い合わせ)
RD=1(再帰要求)
[section数]
QDCount=1		 QNAME=www.linux.project.ed.jp.
QTYPE=1(Aレコード)

②ローカルネームサーバーの処理
　DNSメッセージの[QNAME]をキーにしてローカルデータを検索します。[QTYPE]に該当するデータを検出できればスタブリゾルバに返します。
※　ローカルデータ : キャッシュ及び、自サーバー内にあるゾーンファイルを読み込んだデータ。
※　実際には上位ドメイン名の project.ed.jp, ed.jp, jp も検索し、検出できれば利用します。
　検出できない時は再帰検索の要求(RD=1)を受けているので、逆ツリー構造を辿るように他ネームサーバーへの反復問い合わせを行い名前解決を図ります。
　スタブリゾルバから受けたDNSメッセージをコピーし、ヘッダ部のRDを"0"に変更してルートネームサーバーへ送信します。
※　ルートネームサーバーの情報(IPアドレス等)は公開されていて、ローカルネームサーバーを運用す
　　る時にファイルとして保存済みです。( Ⅳ．２．５．ルートネームサーバー 参照 )
ヘッダ部問い合わせ部
QR=0(問い合わせ)
RD=0(反復要求)
[section数]
QDCount=1		 QNAME=www.linux.project.ed.jp.
QTYPE=1(Aレコード)

③ルートネームサーバーの処理
　[QNAME]に最も近い回答として、委任先 jp ゾーンのネームサーバー名(NSレコード)とそのIPアドレス(Aレコード)を返します。
　自身は[QNAME]のゾーンに権威を持っていないので、AA(Authoritative Answer)には"0"をセットします。またエラーが無ければ RCode=0 をセットします。
ヘッダ部問い合わせ部権威部付加情報部
QR=1(応答)
AA=0
RCode=0(エラーなし)
[section数]
QDCount=1
NSCount=7
ARCount=7		 省略
(①項と同じ)		 NAME=jp.
TYPE=2(NSレコード)
RDATA=a.dns.jp.
(b.dns.jp ～ g.dns.jp の
NSレコード)		 NAME=a.dns.jp.
TYPE=1(Aレコード)
RDATA=203.119.1.1
(b.dns.jp ～ g.dns.jp の
Aレコード)

④ローカルネームサーバーの処理
　ルートネームサーバーの応答を受信したローカルネームサーバーは、次の処理を行います。
  • ヘッダ部のIDを問い合わせメッセージと照合します。
  • ヘッダ部の AA=0 を確認し、この応答メッセージは参照先データと判断します。
  • 複数の参照先(jpの権威ネームサーバー)から1つのネームサーバーを選択します。
選択した参照先(jpの権威ネームサーバー)へ、②項と同じDNSメッセージ(問い合わせ)を送ります。
ヘッダ部問い合わせ部
QR=0(問い合わせ)
RD=0(反復要求)
[section数]
QDCount=1(質問数)		 QNAME=www.linux.project.ed.jp.
QTYPE=1(Aレコード)

⑤jpの権威ネームサーバーの処理
　[QNAME]に最も近い回答として、委任先 project.ed.jp ゾーンのネームサーバー名(NSレコード)とそのIPアドレス(Aレコード)を返します。
　自身は[QNAME]のゾーンに権威を持っていないので、AA(Authoritative Answer)には"0"をセットします。
ヘッダ部問い合わせ部権威部付加情報部
QR=1(応答)
AA=0
RCode=0(エラーなし)
[section数]
QDCount=1
NSCount=2
ARCount=2		 省略
(①項と同じ)		 NAME=project.ed.jp.
TYPE=2(NSレコード)
RDATA=nsw.project.ed.jp.
NAME=project.ed.jp.
TYPE=2(NSレコード)
RDATA=ns2.project.ed.jp.		 NAME=nsw.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.241
NAME=ns2.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.242
※　jpゾーンの構成変更により、co.jp, ne.jp, ed.jp～ 等がすべて1つの jp ゾーンにまとめられた
　　ようです。その結果jpの権威ネームサーバーで project.ed.jp.が検出されます。

⑥ローカルネームサーバーの処理
　再び参照先データを受信したローカルネームサーバーは、同じ処理を行います。
  • ヘッダ部のIDを問い合わせメッセージと照合します。
  • ヘッダ部の AA=0 を確認し、この応答メッセージは参照先データと判断します。
  • 2つの参照先(project.ed.jpの権威ネームサーバー)から1つを選択します。
選択した参照先(project.ed.jpの権威ネームサーバー)へ、②項と同じDNSメッセージを送って問い合わせを継続します。
ヘッダ部問い合わせ部
QR=0(問い合わせ)
RD=0(反復要求)
[section数]
QDCount=1		 QNAME=www.linux.project.ed.jp.
QTYPE=1(Aレコード)

⑦project.ed.jpの権威ネームサーバーの処理
　自ゾーンのデータベースから[QNAME]に一致したAレコードを検出します。ネームサーバーは応答用DNSメッセージを次のようにセットして返信します。
  • ヘッダ部のAAに"1"をセット。(AAフラグ・オン)
    [QNAME]は自身が管理しているゾーンで、その資源レコードに権威を持っています。
  • 回答部にAレコードをセット。
  • 権威部にNSレコードをセット。
  • 付加情報部にNSレコードに対応したAレコードをセット。
ヘッダ部回答部権威部付加情報部
QR=1(応答)
AA=1
RCode=0(エラーなし)
[section数]
QDCount=1
ANCount=1
NSCount=1
ARCount=1		 NAME=
www.linux.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.244		 NAME=project.ed.jp.
TYPE=2(NSレコード)
RDATA=nsw.project.ed.jp.		 NAME=nsw.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.241
※　問い合わせ部は省略しています。
※　権威部と付加情報部を省略するネームサーバーもあります。

⑧ローカルネームサーバーの処理
　ヘッダ部のAAフラグがオン(AA=1)である(名前解決した)ことを確認すると、スタブリゾルバへの応答メッセージを準備します。
  • ヘッダ部のIDを問い合わせメッセージと照合します。
  • ヘッダ部のフラグを次のようにセットします。
    • AA=0 : 回答するゾーンに権威を持っていません。
    • RA=1 (Recursion Available) : 再帰要求をサポートした事を表します。
ヘッダ部回答部権威部付加情報部
QR=1(応答)
AA=0
RD=1(再帰要求)
RA=1(再帰可能)
RCode=0(エラーなし)
[section数]
QDCount=1
ANCount=1
NSCount=1
ARCount=1		 NAME=
www.linux.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.244		 NAME=project.ed.jp.
TYPE=2(NSレコード)
RDATA=nsw.project.ed.jp.		 NAME=nsw.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.241
※　問い合わせ部は省略しています。

セットアップしたDNSメッセージをスタブリゾルバへ返信します。


　ようやくスタブリゾルバに結果が返ってきました。ローカルネームサーバーから応答DNSメッセージを受信したスタブリゾルバは、ヘッダ部のIDをチェックし、名前解決依頼元のアプリケーションに(フォーマットを戻して)データを渡します。

　スタブリゾルバは名前解決の結果をパソコンのキャッシュとして保存します。
パソコンのキャッシュはコマンドプロンプトのipconfigコマンドで確認や消去ができます。
[ キャッシュの確認 ]
C:\＞ipconfig /displaydns

[ キャッシュの消去 ]
C:\>ipconfig /flushdns
※　パソコンの再起動やシャットダウンでもキャッシュは消滅します。

　ローカルネームサーバーは、ルートネームサーバーやjpの権威ネームサーバー等に問い合わせを出して回答を受け取っています。検索の途中で得られた情報も再利用すれば検索時間の短縮・ネットワーク負荷の抑制につながります。最終結果のみならず各段階での回答をキャッシュとして保存し、この後の問い合わせに備えます。
※　キャッシュの有効期限は資源レコードのTTLで指定されています。
※　スタブリゾルバが受信するDNSメッセージは、ローカルネームサーバーがキャッシュを返してきた可能
　　性があります。当然ながらこの時のTTLは、保存されていた時間分小さい値になっています。


Ⅵ．１．２．別パターンの回答

　project.ed.jpの権威ネームサーバーが返すDNSメッセージ(⑦を参照)は、問い合わせのあったホストやゾーンによって返す資源レコードが異なります。その違いを見てみましょう。

【 問い合わせが www.project.ed.jp の場合(CNAMEレコードを返す) 】
　project研究所のwebサーバー www.project.ed.jp (Ⅲ.2.ゾーンとドメイン の図を参照 )は、権威ネームサーバー(nsw)と同じマシンに割り当てられています。外部のユーザーがアクセスした時、名前解決の流れは上記説明と同じになりますが、⑦項の project.ed.jp 権威ネームサーバーが返す応答DNSメッセージは次のようになります。
ヘッダ部回答部権威部付加情報部
QR=1(応答)
AA=1
RCode=0(エラーなし)
[section数]
QDCount=1
ANCount=2
NSCount=1
ARCount=1		 NAME=
www.project.ed.jp.
TYPE=5(CNAMEレコード)
RDATA=nsw.project.ed.jp.
NAME=
nsw.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.241		 NAME=project.ed.jp.
TYPE=2(NSレコード)
RDATA=nsw.project.ed.jp.		 NAME=nsw.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.241
※　問い合わせ部は省略しています。
※　権威部と付加情報部を省略するネームサーバーもあります。

【 問い合わせが network.project.ed.jp の場合(NSレコードを返す) 】
　問い合わせ先は自ドメイン内に存在するサブドメインではありますが委任先の別ゾーンとなっています。このゾーンについては権威はなく管理対象でもありません。こうした場合委任元ネームサーバーは、委任先ネームサーバーの情報を返す事になります。
ヘッダ部権威部付加情報部
QR=1(応答)
AA=0
RCode=0(エラーなし)
[section数]
QDCount=1
NSCount=2
ARCount=2		 NAME=network.project.ed.jp.
TYPE=2(NSレコード)
RDATA=nns.network.project.ed.jp.
NAME=network.project.ed.jp.
TYPE=2(NSレコード)
RDATA=nns2.network.project.ed.jp.		 NAME=nns.network.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.193
NAME=nns2.network.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.194
※　問い合わせ部は省略していますが、各項目は以下のようになります。
　　QNAME=network.project.ed.jp. QTYPE=1(Aレコード)

　ローカルネームサーバーはこのDNSメッセージを基に nns.network.project.ed.jp. への問い合わせを行います。


Ⅵ．２．逆引き (ドメイン名検索)

　DNSの仕組みにはドメイン名からIPアドレスを検索するだけでなく、IPアドレスからドメイン名を検索する機能があります。ドメイン名からIPアドレスを検索する仕組みを「正引き (forward mapping) 」と呼ぶのに対し、逆方向の検索は「逆引き (reverse mapping) 」と呼ばれます。
　逆引きは認証チェック等のセキュリティの担保に使われる側面がありますが万全ではありません。また逆引きの提供は必須ではないので、逆引きの設定を行っていないネームサーバー(あるいは行わない組織)もあります。

Ⅵ．２．１．逆引きのドメイン名

　逆引きにもドメイン名があります。それは project.ed.jp と同じドメイン名空間で管理されていますが、IPアドレスをラベル名に使った独特なものになっています。
　in-addr.arpa.ドメインを頂点に、ラベルにはIPアドレスを8ビットごとに区切ったオクテット表記(0～255の数値)を付けます。(下図およびⅡ.１.ドメイン名空間 参照)

　具体的には、in-addr.arpa.ドメインの下にはIPアドレスの先頭オクテット(8ビット)に対応した256個のサブドメインが存在し、これら256個のサブドメインそれぞれの下に、第2オクテットに対応した256個のサブドメインが存在する・・・となります。

　逆引きのドメイン名表記は最終オクテットから記述します。例えば www.linux.project.ed.jp のIPアドレスが 10.23.145.244 であった時、
その表記は
244.145.23.10.in-addr.arpa. になります。

　逆引きドメインのツリー構造にもゾーンの概念と委任の上下関係があり、逆引きを提供するネームサーバーは自ゾーンに権威と責任を持ちます。
　最終オクテット番号のノードがそれぞれの資源(PTR)レコードに対応しています。PTRレコードにはホストの完全なドメイン名が記録されています。

Ⅵ．２．２．逆引きの手順

　逆引きの問い合わせも正引きと同じようにドメイン名空間の逆ツリー構造を辿って行われますが、in-addr.arpa のゾーンとそれを管理しているネームサーバーのゾーンが違っていることが一般的なので、判りにくい印象があります。

　逆引きの名前解決も正引きと同じ手順でスタブリゾルバから始まります。スタブリゾルバから逆引きの再帰要求を受けたローカルネームサーバーは、(キャッシュが無ければ)ルートネームサーバーから順に反復問い合わせを送って名前解決を行い、スタブリゾルバへ返します。

　www.linux.project.ed.jp のIPアドレス 10.23.145.244 を例にして、逆引き名前解決の手順を追ってみましょう。
検索するドメイン名は 244.145.23.10.in-addr.arpa. 検索対象の資源レコードはPTRレコードになります。

スタブリゾルバは下記DNSメッセージをローカルネームサーバーへ送ります。
ヘッダ部問い合わせ部
QR=0(問い合わせ)
RD=1(再帰要求)
[後続section数]
QDCount=1		 QNAME=244.145.23.10.in-addr.arpa.
QTYPE=12(PTRレコード)

　以後ローカルネームサーバーは目的のPTRレコードを得るまで、ルートネームサーバーから順に反復問い合わせを繰り返します。
問い合わせに対する各ネームサーバーからの応答DNSメッセージは、次のようになります。

※　DNSメッセージの主要部分を資源レコードの形で示しています。
  1. ルートネームサーバーは次の応答メッセージを返してきます。
    in-addr.arpa.NSa.in-addr-servers.arpa.
    a.in-addr-servers.arpa.A199.212.0.73
    　委任先ゾーン(in-addr.arpa.)とネームサーバー名(a.in-addr-servers.arpa.)を参照先として示すと共に、グルーレコードが返ってきました。
    　ローカルネームサーバーはグルーレコードで示されたネームサーバーのIPアドレス(199.212.0.73)へ問い合わせを送ります。

  2. a.in-addr-servers.arpa.ネームサーバーは次の応答メッセージを返してきます。
    10.in-addr.arpa.NSns1.apnic.net.
    　in-addr.arpa. の委任先ゾーン(10.in-addr.arpa.)が参照先として示されていますが、そのゾーン情報を管理しているネームサーバー(ns1.apnic.net.)は異なるゾーンに属しています。このような場合、IPアドレスを示すグルーデータ(Aレコード)は存在しません。
    　ローカルネームサーバーは ns1.apnic.net. のIPアドレスを検索した後、逆引きの問い合わせを継続します。

  3. ns1.apnic.net.ネームサーバーは次の応答メッセージを返してきます。
    23.10.in-addr.arpa.NSa.dns.jp.
    　参照先情報として、委任先ゾーン(23.10.in-addr.arpa.)とネームサーバー名(a.dns.jp.)が返ってきましたが、前項と同様の理由でグルーレコードはありません。
    　ローカルネームサーバーは a.dns.jp. のIPアドレスを検索した後、逆引きの問い合わせを継続します。

  4. a.dns.jp.ネームサーバーは次の応答メッセージを返してきます。
    145.23.10.in-addr.arpa.NSnsw.project.ed.jp.
    　参照先情報として、委任先ゾーン(145.23.10.in-addr.arpa.)とネームサーバー名(nsw.project.ed.jp.)が返ってきましたが、[2]項同様グルーレコードはありません。
    　ローカルネームサーバーは nsw.project.ed.jp. のIPアドレスを検索した後、逆引きの問い合わせを継続します。

  5. nsw.project.ed.jp.ネームサーバーは次の応答メッセージを返してきます。
    244.145.23.10.in-addr.arpa.PTRwww.linux.project.ed.jp.
    145.23.10.in-addr.arpa.NSnsw.project.ed.jp.
    nsw.project.ed.jp.A10.23.145.241
    　目的としていたPTRレコードが返ってきました。ローカルネームサーバーはこの回答を応答メッセージとしてスタブリゾルバへ送信します。
    ※　NSレコードとAレコードを省略するネームサーバーもあります。
※　各段階での応答メッセージには複数の参照先を示すレコードがありますが、ここでは省略しています。

スタブリゾルバが受信する応答メッセージは次のようになります。
ヘッダ部回答部権威部付加情報部
QR=1(応答)
AA=0
RD=1
(再帰要求)
RA=1
(再帰可能)
RCode=0(エラーなし)		 NAME=
244.145.23.10.in-addr.arpa.
TYPE=12(PTRレコード)
RDATA=www.linux.project.ed.jp.		 NAME=
145.23.10.in-addr.arpa.
TYPE=2(NSレコード)
RDATA=nsw.project.ed.jp.		 NAME=nsw.project.ed.jp.
TYPE=1(Aレコード)
RDATA=10.23.145.241
※　問い合わせ部は省略しています。

Ⅵ．２．３．クラスC未満の逆引き

　逆引きではIPアドレスをラベル名として使っているので、145.23.10.in-addr.arpa.ゾーンの下には256個ものラベルが存在することになります。1つの組織がこんなに多くのIPアドレスを保有することはまれで、10個未満のIPアドレスでゾーンを細分化すると云うのが一般的でしょう。
　ゾーンを細分化しても逆引きを可能にする方法の1つとしてCNAMEを使う方法があります。ゾーンの細分化はIPアドレスの払い出しをしているプロバイダが行います。CNAMEを使った逆引きはプロバイダとの共同作業になります。

　あるプロバイダからproject研究所向けに 10.23.145.240 ～ 10.23.145.247 のIPアドレスが払い出されている時、 プロバイダのネームサーバーの逆引きゾーンファイルには次のようなNSレコードとCNAMEレコードを記述します。
div-a.145.23.10.in-addr.arpa.NSnsw.project.ed.jp.
241.145.23.10.in-addr.arpa.CNAME241.div-a.145.23.10.in-addr.arpa.
・・・ 242 ～ 246 のCNAMEレコード ・・
247.145.23.10.in-addr.arpa.CNAME247.div-a.145.23.10.in-addr.arpa.
　このゾーンファイルは 244.145.23.10.in-addr.arpa. の正規名は 244.div-a.145.23.10.in-addr.arpa.であり、それを管理しているネームサーバーは nsw.project.ed.jp. であるとしています。(細分化したゾーンの逆引きを可能にするための方便です)
　逆引き(244.145.23.10.in-addr.arpa.)を問い合わせたローカルネームサーバーは、この回答を基に nsw.project.ed.jp.に対して 244.div-a.145.23.10.in-addr.arpa.の逆引きを問い合わせます。

　nsw.project.ed.jp.ではプロバイダの設定に合わせて、逆引きゾーンファイルを次のように記述しておきます。
241.div-a.145.23.10.in-addr.arpa.PTRnsw.project.ed.jp.
・・・・・
244.div-a.145.23.10.in-addr.arpa.PTRwww.linux.project.ed.jp.
・・・・・
※　SOAレコードやNSレコード等は省略しています。

　目的のPTRレコードが見つかり、該当のホスト名は www.linux.project.ed.jp.であると判明しました。

※　この例では仮サブドメイン名を div-a としましたが、名称の付け方はプロバイダによって様々です。
　　IPアドレスの範囲を示す 240-247 が使われたり、単に先頭数字の 240 とすることもあります。




≪　previous [[ アドレス検索 - DNSの話 ]]