　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　DNSについて

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　*このページではサンプルとしてアスキー社の名前を使用しています。

DNSに関連する用語は、かなりわかりにくい。

概念的なものが多いうえに、無理やり日本語に訳されたものや、そのままカタカナにしただけのものが混在して使われるから、やっかいだ。
DNS を理解するためには、まず独特な用語の意味をしっかり押さえながら、基本的な仕組みを知ることが大切である。

DNS とは何か？

DNS は、インターネットをはじめ TCP/IP ネットワークにはなくてはならない存在だ。「ドメイン名システム」（ Domain Name System ）を意味する DNS は、
ネットワーク上の住所である「 IP アドレス」と、ふだん私たちが使う「ドメイン名」を相互に変換する役割を担っている（図1）。

図1●インターネットに不可欠な名前解決サービスを提供するDNS

なぜ、このようなシステムが必要なのだろうか？ご存知のように IP アドレスは、0か1が32個並んだ32ビットの2進数。
通常は「192.168.0.1」のように、わかりやすい10進数の数字で示されるとはいえ、これは「単なる数字」でしかない。
ルータがパケットを宛先に送り届けるのに必要な、配送情報が示されているだけだ。

このままでは、ネットワークを利用する側（＝人間）にとって不便である。数字の羅列を扱わなければならないからだ。
人間の頭はコンピュータと違って、数字の羅列をらくらく処理できるようにはなっていない。電話番号でも、2つ3つ覚えるのがやっとだろう。
ここはやはり、なんらかの「意味」を関連付けて IP アドレスを扱いたい。

たとえば、「192.168.0.0」は「アスキー」という会社のネットワークで、「192.168.0.1」は「その Web サーバ」というようにである。
人間にとって意味のあるこの文字列が「ドメイン名」だ。ドメイン名を使えば、IP アドレスを使わなくても該当するサーバへアクセスできる。
そして、この間を取り持つシステムが DNS というわけである。

DNS が提供する IP アドレスとドメイン名の変換機能のことを「名前解決」という。奇妙な言い回しだが、これは英語の「 name resolve 」を直訳したものだ。
あまり難しく考えなくてもよい。

DNS の名前解決は、「ネームサーバ」（ DNS サーバ）と呼ばれる専用サーバが行なう。
処理としては、IP アドレスとドメイン名の対応を管理するデータベース（ゾーン情報）から、ユーザーが指定したドメイン名に該当する IP アドレスを検索するだけだ。

ちなみに、ドメイン名から IP アドレスを見つけることを「正引き」、逆に IP アドレスからドメイン名を見つけることを「逆引き」というが、
どちらもネームサーバが提供する名前解決サービスである（以下、単に名前解決といった場合は正引きを指すことにする）。

名前解決の仕組み

それでは、名前解決の仕組みを少し具体的に見てみよう。クライアントには、Web ブラウザやメールソフトといったアプリケーションがある。
こうしたアプリケーションを利用するユーザーはドメイン名を使って宛先サーバを指定するので、ここで名前解決が必要となる。
TCP/IP で通信するコンピュータには、名前解決を行なう専用 DNS クライアント「リゾルバ」が備わっている（特に「スタブリゾルバ」という）。
アプリケーションはこのリゾルバに名前解決を依頼し、宛先の IP アドレスを取得する（図2）。

図2●名前解決の基本的な仕組み

名前解決を依頼されたリゾルバは、クライアントのネットワーク設定で指定されているネームサーバ（たいていはローカルネットワーク上のサーバ）に問い合わせをする。
問い合わせを受けるのは、ネームサーバのサーバプログラムである。これは、先のスタブリゾルバに対して「フルサービスリゾルバ」と呼ばれる。
ネームサーバ上にはゾーン情報が管理されているので、問い合わせを受けたフルサービスリゾルバはゾーン情報を検索し、該当する IP アドレスを回答する。

ここで、1つ注意がある。ゾーン情報には必ずしも問い合わされたドメイン名の IP アドレスが記録されているわけではないという点だ。
インターネットの「規模」を考えれば、1台のネームサーバに、インターネット上にあるすべてのホストの IP アドレスを記録しておくことは不可能だ。
したがって、リゾルバからの問い合わせに対する回答がゾーン情報になければ、フルサービスリゾルバは別のネームサーバへあらためて問い合わせることになる。

この動作が DNS のキモである。つまり DNS では、
１：ネームサーバが名前解決できる範囲が限定されており（この範囲がゾーン情報の「ゾーン」）、
２：必要ならネームサーバ自身が目的の IP アドレスを管理している別のネームサーバに問い合わせできる。
このことは、DNS がインターネット中に分散するネームサーバの協調動作によって機能する「分散システム」であることを意味している。

ドメイン名とドメイン

分散システムとしての DNS では、名前解決に必要な情報（ゾーン情報）を多くのネームサーバで分担して管理している。
この分担がどのようになされているかは、ドメイン名を見ると一目瞭然である。

図3は、アスキーの Web サーバを表わすドメイン名だ。よく見ると、ドメイン名の右端（ jp の右）に、余分に「.」（ピリオド）が付いていることに気づくだろう。
日常ユーザーがドメイン名を扱うときは最後のピリオドは付けないが、DNS ではこの形で1つのドメイン名を表記することになっている。
これを「完全修飾ドメイン名」（ FQDN：Fully Qualified Domain Name ）という。

図3●ドメイン名は階層構造になっている

FQDN は、特定のホストを示す部分「 www 」と、そのホストが所属するネットワークを示す部分「 ascii.co.jp. 」に分かれる。
これは、名前解決をするネームサーバがascii.co.jp. で示されるアスキーのネットワークに問い合わせをすれば、www というホストの IP アドレスを取得できることを示す。

ただ「 ascii.co.jp. 」に問い合わせるといっても、インターネットには膨大な数のネットワークが接続している。
この中から該当するネットワークを探し出さなければならないわけだが、先のホストと同じ要領で考える。今度はドメイン名の「 ascii 」の右に注目すればよい。
すると、ascii というネットワークは co.jp. というネットワークに所属しておりco.jp. に問い合わせればよいことがわかる。
同様に、co.jp. ネットワークは jp. に、jp. ネットワークは「.」に所属している。この所属を示すグループが「ドメイン」である。
この所属の上下関係を追えば、インターネット中のどのネットワークにも問い合わせできるようになる。

このように、ドメインには「上位」と「下位」という階層の概念がある。一番上位に位置するのはインターネット全体である。これは、ドメイン名の右端にあるピリオドで示される。
これを「ルートドメイン」といい、インターネットのすべてのドメインはここに属する「サブドメイン」（下位のドメイン）となる。ドメインの総元締といったところだ。

ルートドメインの1つ下には、jp や com、de、uk、us といった「トップレベルドメイン」（ TLD ）がある。
世界中の各国は1つの TLD を持っており、これを「国別トップレベルドメイン」（ ccTLD ）という。ccTLD は、国という所属グループを示すものだ。
ただし com、net、org、gov、edu などアメリカが管理し、一部世界中に開放されている「一般トップレベルドメイン」（ gTLD ）もある。
TLD の下には、セカンドレベルドメイン（ SLD ）がある。ccTLD の下には、各国のドメイン管理機関が定めた SLD が作られる。
日本の場合は、jp を管理するJPRS（日本レジストリサービス）によって、co、ad、go、ed といった、おもに組織の種別を示す SLD が作られている。
なお gTLD の場合は、各組織の名前がSLDになる。

co や go といった SLD の下には、特定の組織の名前を示すサードレベルドメイン（ 3LD ）がある。アスキーなら「 ascii 」、首相官邸なら「 kantei 」だ。
一般にはこのレベルで1つのドメインが完結し、その下には特定のホストの名前（ www や mail など）が続く。
ただ、場合によっては組織内でさらにサブドメインを作って管理を分散させることもある。

ドメインは「ツリー構造」で管理される

前述のドメインの構造を図で示すと、図4のようになる。ご覧のように、ルートを根っことした「ツリー（木）構造」によって、ドメインが階層的に管理されている。
木としては逆さまの向きになるが、これを「ドメインツリー」といい、ツリーの広がり（枝の部分）を「名前空間」という。

図4●ドメインツリーの構造

DNS の分散システムの実体は、このドメインツリーである。木の枝の分かれ目にあたる部分（ノード）は、直下の名前空間だけを管理すればよい。
こうしたノードが集まることで、インターネット全体で各ゾーン情報を分担して管理できるようになる。

また枝の先端（ 3LD のノード）には、木の葉っぱにあたるホストがぶら下がる。ルートから下へ向かっていくつかのノードをたどっていけば、どこからでも末端の葉っぱに
到達できるわけだ。実際にドメインツリーにおいて、どのような流れで最終的なIPアドレスを解決するのかはもう少し後で取り上げるが、ここではこの構造を頭に入れておこう。

ドメインとゾーンの違い

よく、ドメインとゾーンの区別がつかないという人がいるが、図4を見るとその違いもよくわかると思う。
前述したようにドメインは所属グループのことなので、あるノードから下の名前空間全体がドメインになる。
たとえば jp ドメインは、ドメイン名に jp と付くすべてのドメインを包含しており、ascii.co.jp も kantei.go.jp もその一部になる。

一方のゾーンは、ネームサーバが名前解決できる範囲のことだ。ドメインツリーでいえば、あるノードから次のノードの間、あるいは接続ホストを持つノード以下の部分がゾーンになる。
同じドメインレベルの名前空間が1つのゾーンだと考えるとわかりやすい。
ここで、中間のノードで管理されるゾーンでは、名前解決の対象は葉っぱ（ホスト）ではなく、別のノード（ドメインの頂点）になることに注意が必要だ。
つまり、名前解決で取得できるのは特定のホストのIPアドレスとは限らず、特定のドメインのゾーンを管理するネームサーバも含まれるということだ。
この概念は、名前解決プロセスを理解するうえで重要になる。

またルートの下に、あまり聞き慣れない「 arpa 」（アルパ）、その下に「 in-addr 」（インターネットアドレス）というドメインがある。
この2つをまとめて「 in-addr.arpa ドメイン」という。このドメイン以下では、「61.114.182.85」のような IP アドレスの4つの数字を右から上位順にノードにしたツリーが
形成される。これは、IP アドレスからドメイン名を取得する逆引きの名前解決に使われる名前空間である。

権限委譲

ドメインは所属を同じとするグループのことだと説明した。繰り返すが、ascii.co.jp. というドメイン名は「ルート⊃ jp ⊃ co ⊃ ascii」という具合に、含む／含まれるという
所属関係に基づくネットワークを示している（⊃は部分集合を意味する記号）。

このことは、ドメインの一部を別のドメインとして独立させ、名前解決の責任を委譲していることにほかならない。
ちょうど会社組織が「会社⊃事業部⊃部⊃課」のように業務範囲を細分し、権限や責任をその「長」に委譲しているのと同じである。
DNS におけるこの概念を「権限委譲」（委任、デリゲーション）という（図5）。

各ドメインでそのゾーンの管理を権限委譲されたネームサーバは「権限元」と呼ばれる。上位のドメインは、この権限元ネームサーバを束ねる形になる。
外部のネームサーバはゾーンの権限元に問い合わせすることで、当該ドメインに属するホストやサブドメインの情報がわかる。
これが分散システムとして協調動作する DNS の仕組みである。

ドメインの権限元となるネームサーバは、概念的には1つである。ただし実運用上では、ネームサーバは複数台置かれるのが一般的だ。
たとえば、ルートサーバは現在13台体制で運用されているし、一般的な企業でも2～3台のネームサーバを持つ。

これは、名前解決という重要な役割を担うネームサーバには、安定動作が不可欠だからである。
ネームサーバを複数台運用することで冗長構成を採り、問い合わせへの応答を負荷分散できる。オリジナルのゾーン情報を持つネームサーバを「プライマリネームサーバ」、
プライマリからゾーン情報をコピーして持つネームサーバを「セカンダリネームサーバ」という。

とはいえ、問い合わせに対する動作としてはプライマリとセカンダリに違いはない。
サーバ管理者はプライマリだけを管理しておけば、ゾーン情報を自動的にセカンダリに転送することができるという、あくまでも運用・管理する側に必要な違いだ。

2種類の問い合わせ

DNS では、クライアントから最初に問い合わされたネームサーバが名前解決できなければ、サーバ自身で適切なネームサーバに問い合わせをする。
つまり名前解決プロセスは、１：クライアントが最初に行なう問い合わせと、２：ネームサーバが行なう問い合わせの2段構えになる。

問い合わせをしたクライアントは、ネームサーバから最終的な IP アドレスが回答されることを期待している。
とにかく、IP アドレスが返されることだけがクライアントの関心事となる。このような、最終的な IP アドレスを求める問い合わせを「再帰的な問い合わせ」という（図1）。
この問い合わせでは、回答は必ず IP アドレスである。もし該当する IP アドレスを解決できなければ、「そのようなドメイン名はありません」というエラーを戻すしかない。

図1●DNSの2種類の問い合わせ

一方、ネームサーバが行なう問い合わせは、もう少し柔軟である。回答は必ずしも IP アドレスでなくてよい。
目的の IP アドレスを管理するネームサーバに到達するまでの「手掛かり」であってもかまわない。先ほど、ゾーン情報はドメインツリーの階層ごとに分散管理されていると説明した。
つまりこの問い合わせでは、ドメイン階層の各権限元ネームサーバから目的のサーバへの「道しるべ」を回答としてもらえる。
「自分のゾーンには情報はないが、自分の下位ドメインの○○というネームサーバに聞けば何かわかるかもしれない」という具合に、特定のネームサーバの名前を紹介してもらうことが
できるのだ。この種の問い合わせのことを「反復的な問い合わせ」（再帰的でない問い合わせ）という。

再帰的な問い合わせで回答される IP アドレスは、DNS 用語で「 A レコード」という。これは「 Address 」（アドレス）という意味である。
また、反復的な問い合わせで回答されるネームサーバの名前は、「NSレコード」（ Name Server ）という。
レコードとは、ネームサーバ上で管理されるゾーン情報の個々の項目のことである。レコードについては後ほど取り上げるが、ここでは回答される情報に
A レコードと NS レコードの2種類があることを覚えておいてほしい。

名前解決のプロセス

この2種類の問い合わせを使って、ドメイン名から IP アドレスが取得されるまでの流れを示したのが図2である。順を追って見ていこう。

図2●名前解決されるまでのプロセス

まず、クライアントは再帰的な問い合わせであることを指定したうえで、「 www.ascii. co.jp. 」といったドメイン名の名前解決をローカルのネームサーバに依頼する。
通常、クライアントのスタブリゾルバから発行される問い合わせは、自動的に再帰的な問い合わせになる。

したがって問い合わせを受けたローカルネームサーバは、自分の管理下にないドメイン名であれば反復的な問い合わせで最終的な IP アドレスを調べる責任を負うことになる。
問い合わせの対象がインターネット上のホストのときは、ローカルネームサーバは必ず反復的な問い合わせをしなければならないと考えてよい。
（ただし、以前に名前解決されたことのある IP アドレスなら、キャッシュから読み込まれる。）

では、ネームサーバが反復的な問い合わせをするとき、まずどこに問い合わせればよいのだろうか？
ドメインツリーの構造を思い浮かべれば、答えがわかるだろう。すべてのドメインを包括するドメインとして、ルートドメイン（「.」で示される）がある。
ルートドメインのゾーンを管理するネームサーバ（ルートサーバ）に問い合わせれば、とりあえずドメイン名の TLD（ jp ）を管理するネームサーバを絞り込める。

ネームサーバのサーバプログラム（フルサービスリゾルバ）には、現在稼働している13台のルートサーバがあらかじめ登録されている。
そこで問い合わせ元のネームサーバは、ルートサーバに対して「jp.」（ jp の権限元を教えてほしいという意味）を送り、その回答としてたとえば「 ns.jp 」のような
ネームサーバ名を取得できる。

ドメインツリーをどんどん下っていく

これで、ルートサーバから jp ドメインを束ねる権限元のネームサーバの名前が得られた。
次にここに問い合わせれば、ドメイン階層の次のレベル（ SLD、ここでは「 co 」）まで、目的のネームサーバに近づくことができる。
そこで問い合わせ元のネームサーバは、ns.jp に「 co.jp. 」という問い合わせを送る。今度は、「 ns.co.jp 」といった co.jp ゾーンを管理するネームサーバが回答される。

ns.co.jp ネームサーバには、「 xxx.co.jp 」というドメイン名を持つすべてのドメインが登録されている。ascii.co.jp もしかりだ。
実際に「 ascii.co.jp. 」と問い合わせれば、ascii ドメインを管理するネームサーバが「 ns.ascii.co.jp 」であることを知ることができる。

ここまででようやく、目的のネットワークを管理するネームサーバまでたどり着いたことになる。
このネームサーバに問い合わせることで、配下にある「 www 」や「 ftp 」といった個々のホストの IP アドレスを取得できる。
たとえば、「 www.ascii.co.jp. 」と問い合わせれば、「 61.114.182.85 」のような IP アドレスが返される。この IP アドレスをクライアントに送ってやれば、名前解決は完了だ。

上記のプロセスを見ると、ルートから co のネームサーバ（ ns.co.jp ）までは、NS レコードで問い合わせしていることがわかるだろう。
また最後の ns.ascii.co.jp に対しては、A レコードでの問い合わせである。この判断は問い合わせ元のネームサーバがドメイン名に基づいて行なう。
ただ、最初からAレコード（ www.ascii.co.jp. ）の問い合わせをしても同様の結果になる。ルートサーバをはじめとした途中のネームサーバは、ドメイン名から自分のわかる範囲で
「 ns.jp 」や「 ns.co.jp 」、「 ns.ascii.co.j p」といった NS レコードを返してくるからである。

この名前解決のプロセスは、nslookup というコマンドを使って体験してみることが可能だ。自分の目で確かめてみると、DNS の仕組みがよくわかると思う。

DNSのメッセージ形式

名前解決のプロセスがわかったところで、次にネームサーバはどのようなメッセージのやり取りでこの動作を実現しているのかを見てみよう。

DNS の通信は、問い合わせに対する回答というシンプルなやり取りが基本になるため、トランスポート層プロトコルには UDP を使う。UDP でやり取りできるメッセージは最大で 512 バイトである。そのため、DNS でもメッセージの最大長は 512 バイトとなる。ただし、メッセージ（特に回答）が 512 バイトを超えるときや、プライマリネームサーバのゾーン情報をセカンダリネームサーバに転送する場合は、大容量のデータ転送が可能な TCP が使われる。

DNS のメッセージの特徴は、HTTP や SMTP といった他のアプリケーションプロトコルのように、要求（問い合わせ）と応答（回答）で形式に区別がないことだ。
図3のように、問い合わせと回答で共通のメッセージ形式を使う。

図3●問い合わせと回答で共通のDNSのメッセージ形式

DNS のメッセージは、5つのセクションに分かれている。問い合わせ時には、上の2つセクション「へッダ部」と「問い合わせ部」が使われる。

へッダ部には、メッセージが問い合わせか回答かを示す「 QR 」（ Query/Response ）、再帰的な問い合わせ（ Recursion ）を指定する「 RD 」（ Recursion Desired ）、
サーバが再帰的な問い合わせをサポートしているかどうかを示す「 RA 」（ Recursion Available ）といったフラグ（ 1か0 で示す情報）がある。
また問い合わせ部には、名前解決したいドメイン名（正引きの場合）と、問い合わせの種類（タイプ）が指定される。タイプは、回答に IP アドレスを望むなら「 A 」、
ネームサーバ名を望むなら「 NS 」となる（図4）。

一方、回答のメッセージは問い合わせに対して「回答部」「権限情報部」「追加情報部」を追加する形になる。検索結果を格納する部分が「回答部」である。
ここには、回答として見つけ出された IP アドレスやネームサーバ名に関連するドメイン名情報とそのタイプ（ AとかNS とか）、後述するキャッシュの有効期限、
そして実際の回答となる IP アドレスやネームサーバ名※2が入る。また回答された情報の権限元を示す「権限情報部」や、その権限元に関する情報が示す「追加情報部」が
加わることもある。

ここで、回答は必ずしも1つとは限らないという点に注意しよう。
たとえば、問い合わせの「 www.ascii.co.jp 」というドメイン名で、複数の Web サーバが稼働しているかもしれない。
また、Web サーバが「別名」（ CNAME ）を使って別の名前で管理されていることもある。こうした場合は、複数の IP アドレスが回答されたり、別名と本当の名前の関連付けが
示されたりと、1つのメッセージに複数の回答およびその権限／追加情報が含まれることになる。

※2：DNSの回答メッセージには、同じドメイン名が何度も現われることが多い。そのため重複するラベル（ドメイン名を構成する要素）は、最初に登場した部分を指す
「ポインタ」（位置情報）として示されている（ラベル圧縮）。

キャッシュの提供

ドメイン名を使って通信する限り、名前解決が必要である。ただし、ネームサーバがいつでも必ずドメインツリー上のネームサーバに尋ね回っているかといえば、そうでもない。
というのも、ネームサーバは一度名前解決した IP アドレスやドメイン名を「キャッシュ」として一定時間保持しておき、そこからクライアントの問い合わせに応えることが
できるからだ。キャッシュを使えば、名前解決に必要な DNS の通信を大幅に減らすことができる。

たとえば、Web ページを表示するという HTTP 通信には、大量の名前解決が必要である。たいていの Web ページには、URL によって画像などのリンクが貼られている。
ある HTML ファイルに10個の画像が貼られているとすると、1ページを表示するのに11回も、あの面倒な名前解決を処理しなければならない。
これをまともにやっていたら、インターネットは DNS のパケットだらけになってしまう。

そこで、ネームサーバは名前解決が済んでいる IP アドレスを自分のハードディスクに記録しておく。その後、同じドメイン名が問い合わせされたら、そこから応答すればよい。
特に HTTP は、続けて同じドメイン名が問い合わされることがわかっているから、キャッシュは効率よく機能する。

ただし、いったんキャッシュした情報をいつまでも使い続けるわけにはいかない。インターネットのどこかで、新しいドメイン名が登録されたり IP アドレスの割り当てに変化があったときに対応できないからだ。キャッシュとして残される時間は、ネームサーバの設定によって定められる。通常は3600秒（＝1時間）程度に設定され、
これは DNS 応答メッセージの「 TTL 」（ Time To Live ）に示されている。

図5●キャッシュの提供もDNSの重要な機能だ

ネガティブキャッシュとは？

また前述のキャッシュとは逆に、名前解決に失敗したドメイン名を保存しておく「ネガティブキャッシュ」という機能もある。
なぜこのようなキャッシュがあるかというと、通信に失敗したときユーザーは概して何度もやり直しをするものだからである。

たとえば存在しないドメイン名が問い合わされたり、ネームサーバが停止して名前解決ができなかった場合を考えてほしい。クライアントには、最終的にエラーが返されるだろう。
ユーザーにしてみれば、何かおかしいと思ってもう一度通信を試みるのは当然だ。Web 通信であれば、ユーザーは意地になって何度もリロードボタンを押すかもしれない。
しかし一度名前解決に失敗したのなら、すぐにやり直してもまた失敗する確率が高い。
そこで、名前解決に失敗したドメイン名はネガティブキャッシュを参照してエラーをユーザーに戻し、直後の再問い合わせの無駄を軽減するのだ。

ネガティブキャッシュの時間も、ネームサーバで設定される（最小 TTL ）。通常は、1200秒（＝20分）程度の時間、設定されていることが多い。

ネームサーバがデータベースの一部の情報を分散して持ち、要求に応じて知っている範囲で情報を返すことで、DNS 全体が成り立っている。
そもそも、ある問い合わせに対して回答できるかどうかは、ネームサーバ自身が読み込んだ「ゾーンファイル」に、その情報があるかどうかでしかない。
ここではゾーンファイルの中身を見ながら、DNSの情報がどのように管理されているか調べてみよう。

ゾーンファイルとは？

ネームサーバの事実上の標準プログラムとして利用されている「BIND」（Berkeley Internet Name Domain）では、named.confファイルとゾーンファイルという
2種類のファイルを使う。
named.confファイルには、ゾーンファイルへのパス（場所）や動作モードなどが記述されている。実際の名前解決データベースを構成するための情報は、ゾーンファイルという別の
ファイルに記述される。BINDでは、基本的に図1に示す4つのゾーンファイルを読み込んでいる。以下それぞれについて、簡単に見ていこう。

まず「.」で示されるルートゾーン用に、「named.root」というゾーンファイルが指定されている。
これは「ヒント情報」（＝type hint）として与えられるもので、現在稼動しているルートサーバのドメイン名とIPアドレスが記述されている（図2）。
このファイルはBINDをインストールした時点で提供されているので、通常はそのまま使うことになる。

図2●ルートゾーンを定義したファイルの内容

また「0.0.127.IN-ADDR.ARPA」で示されるゾーンは、127.0.0.1という自分自身を示す特殊なIPアドレス（ループバックアドレス）を処理するために必要となるものだ。
読み込むファイルは「localhost.rev」となっているが、このファイルも多くの場合インストール時のものをそのまま使う。
ちなみに、ファイル名は「127.0.0.db」や、その他の名前で示されることもある。

さて、ここからが重要だ。
次は正引きのためのゾーンファイルである。たとえば、ascii.co.jpゾーンであれば、「ascii.zone」というファイル名でファイルを作り、ここにホストとIPアドレスの対応表を
記述することになる（後述）。図1のnamed.confファイルでは、「type master」によってネームサーバが自分でこのファイルを読み込んで
プライマリ（マスター）ネームサーバとして動作させる指定をしている。もし、ネームサーバをセカンダリ（スレーブ）として使いたい場合は、以下のようにタイプの指定を
「slave」とし、「forwarders」で情報を提供してくれるネームサーバのIPアドレスを記述する。

zone "ascii.co.jp" {
type slave;
forwarders 192.168.1.10
};

プライマリネームサーバとセカンダリネームサーバの違いは、ネームサーバがどこからデータ（情報）を得るかである。
プライマリは自分自身が保持しているファイルからデータを読み出す。一方のセカンダリは、ネットワークを経由して他のネームサーバからデータを得る（ゾーン転送）。

さらに、逆引き用のゾーン「1.168.192.IN-ADDR.ARPA」の設定もある。ここでは、「ascii.rev」ファイルをマスター情報として読み込んでいる。
逆引きについては5限目で取り上げるが、ここにはIPアドレスからドメイン名を検索する情報が記述される。

ゾーンファイルの中身と項目

それでは、正引きのゾーンファイルの中身を見ていこう。ゾーンファイルといっても、図3のような情報を必要に応じて順に定義しているだけである。
個々の情報は、「リソースレコード」（以下レコード）と呼ばれる。レコードには次ページの表1にまとめたようなタイプ（種類）があるが、ここでは
「SOA レコード」「NS レコード」「MX レコード」「A レコード」に注目してみる。

図3●名前解決（正引き）のための定義ファイル例

　　　　　　　　　　　　　　　　　　　　　　表1●ゾーンファイルで定義される主なレコード

レコード種別	役割
$TTL	ゾーンのデフォルト TTL を定義
SOA	ゾーンの開始を示し、各種の制御情報などを定義する
NS	ドメインのネームサーバを定義
A	ホストの IP アドレスを定義
MX	ドメインのメールサーバ名を定義
PTR	IP アドレスに対するFDQNを定義
CNAME	ホスト名の別名を定義
WKS	ホストで実行されているサービス情報を示す
HINFO	ホストの追加情報を示す
TXT	ホストへのテキスト情報を示す

だがその前に、先頭の「$TTL 3600」という行が目につく。各レコードの詳細に入る前に、この行について少し説明しておこう。

$TTL 3600 は、ネームサーバに対するデフォルト TTL（ Time To Live ：生存時間）の指定だ。
生存時間とは、他のネームサーバがキャッシュを保持するときの有効時間のことである。数字の単位は秒で、この場合は一度名前解決された IP アドレスは
1時間（＝3600秒）キャッシュされることになる※1。

●注●
※1：$TTL の指定は、最近の BIND から有効になったものだ。以前の BIND では、キャッシュの有効時間は SOA レコードの TTL で指定していた。
現在は、SOA レコードの TTL は「ネガティブキャッシュ」用に使い、キャッシュは $TTL で指定される。

SOA レコード

SOA（ Start Of Authority ）レコードは、文字通りゾーンの開始を宣言し、そのゾーンに関する制御情報など定義するためのレコードだ。
DNS が動作するうえでの心臓部となるレコードである。したがって、ここは少し詳しく説明しておこう。

先頭にある「 @ 」は、ゾーンファイル内の起点となるドメイン名を示す。named.conf で指定したドメイン名のことと考えればよい。
この場合は、ascii.co.jp. というドメインのゾーンを管理する SOA レコードという意味になる。ちなみに、@ に続く「 IN 」はレコードがインターネットのデータであることを
示している（クラス）。通常、ゾーンファイルではクラスはINしか使われないので、あまり気にしなくてよいだろう。

さて SOA では、まずゾーンファイルを管理するネームサーバ名（ ns1.ascii.co.jp. ）と、管理者のメールアドレス（ root.ns1.ascii.co.jp.＝root@ns1.ascii.co.jp のこと）が
記述される。また、右端の開き括弧はレコードが複数行にまたがることを可能にするもので、それ以降、閉じ括弧までシリアル番号や各種の制御時間が設定される。

シリアル番号は、ファイルに記述された情報に修正があるかどうかを判断するための情報である。これは、セカンダリネームサーバがゾーンの情報を参照する際に使われる。
この値を見て、自分が持つ情報より新しければそちらを採用するわけだ。したがって、ゾーンファイルに少しでも修正などを加えた場合は、この数字を増やさなければならない。
一般には「年月日＋2桁」くらいの番号で、いつ更新されたか、その日の何度目の更新かがわかるようにしている。

Refresh（更新間隔）は、セカンダリに対してこのゾーン情報の正しさをどれくらいの頻度でプライマリに確認すべきかを指定するものである。
また Retry（転送再試行時間）は、Refresh で指定された時間が経過してもセカンダリがプライマリに到達できなかった場合、どれくらいの頻度で再接続を試みればよいかを指定する。
Expire（レコード有効時間）は、ゾーン情報が最新であると確認できない場合の有効時間を指定するものである。
指定時間を経過してもセカンダリがプライマリに到達できなかった場合には、セカンダリは現在のデータを無効とみなして捨ててしまう。
これは、データが古くなりすぎて有効性を保証できないと考えられる場合、それ以上問い合わせに対して答えるべきではないという前提に立っている。

最後の Negative（ネガティブキャッシュ有効時間）は、DNS の検索に失敗したドメイン名をどれくらいの期間キャッシュに保持して外部に不要な問い合わせをしないようにするかを
指定する。短すぎると不要な問い合わせを増やし、逆に長すぎると一度検索に失敗したドメインへはその時間ずっとアクセスできないことになる。
通常は20分程度（ 1200 ）くらいに設定される。

NS レコードと MX レコード

SOA レコードの次には、NS レコードとMXレコードが定義されている。

NS レコードは、ここまですでに見てきたようにドメインを管理するネームサーバを指定するものである。
定義としては本来、 ascii.co.jp. IN NS ns1.ascii.co.jp. のように記述するが、レコードの先頭がスペースかタブのときは直前のレコードのドメイン名（ @＝ascii.co.jp. ）を
意味するので、図3のように省略して記述できる。

また MX レコードは、そのドメインで使用するメールサーバを指定する。このレコードには、他のレコードにはない「10」という数字が含まれている。
これは、メールサーバの優先度（プリファレンス）を示す値である。複数のメールサーバを指定した場合は、数字が単に小さいほうが優先される。

A レコード

A レコードも、これまで何度も登場したレコードだ。すでにご存知のように、ここは IP（ IPv4 ）アドレスを指定する。
行の先頭に特定の名前が指定されない行は、「 ascii.co.jp 」自体の IP アドレスを示す。逆に「 www 」のように、行の先頭に名前を示すと、「 www.ascii.co.jp 」の
ホストの IP アドレスを示すことができる。

ただし、いったん行の先頭に「 www 」といった名前を指定すると、以降はスペースやタブで起点となるドメイン名を示せなくなることに注意してほしい。
もし、この2行を逆に書くと、ascii.co.jp の IP アドレスを記述したつもりでも実際には www.ascii.co.jp の IP アドレスであると解釈されてしまう。

図3のゾーンファイルでは、A レコードを使って ascii.co.jp のドメイン内にあるホスト名とその IP アドレスを定義している。
これによって、たとえば「 host01.ascii.co.jp 」の名前解説を依頼されたネームサーバは「 192.168.1.101 」であると回答できるようになる。

複数のゾーンの管理

以上で、ドメイン（ゾーン）がどのように定義され、そのゾーンファイルがどういう内容になっているのかおよそ理解できたと思う。
だが組織によっては、ascii.co.jp だけでなく、「 ascii.jp 」や「アスキー.jp」といった複数のドメインを持つところも多い。
この場合ゾーンは、どのように管理されているのだろうか。

複数のドメインを使うには、それぞれのドメインごとにゾーンファイルを定義し、それを named.conf ファイル中で一括して読み込ませればよい（図4）。
いささか拍子抜けするくらい単純だが、実際にこのような感じで運用できてしまう。

図4●複数のゾーンを扱う場合

では、組織をいくつかに分けてサブドメインを作る場合はどうだろう。サブドメインを作る場合にまず最初に決めることは、そのサブドメインに関する情報を一箇所で持つか、
サブドメインを委任（権限委譲）して管理を任せるかのどちらかになる。

一箇所で持つ場合は、複数のドメインを扱うときのように複数のゾーンを定義し、それをネームサーバに読み込ませる。
また委任をする場合は、委任先のネームサーバを指し示すようにする。具体的には、ゾーンファイル中でサブドメインを管理するのネームサーバを定義する。

ゾーン管理の実際

ところで、ひと言で「ゾーンを管理する」といっても、実際にはどういうことなのだろうか。一般論で語ることしかできないが、最後に確認しておきたい。

DNSの名前空間は、ルートドメインを頂点としてその下に階層化されている。インターネットのルートゾーンを管理しているのは、
「ICANN」（The Internet Corporation for Assigned Names and Numbers）と呼ばれる米国の非営利組織である。実際にルートゾーンのファイルの内容を変更するためには
いまだに米国政府（商務省）の許可が必要だが、どのトップレベルドメインを誰に任せるか、どのようなトップレベルドメインを新設するかといった全般的な調整はICANNによって
行なわれている。

トップレベルドメインを運用するためには、管理組織としてICANNに認められるだけでなく、ルートのゾーンファイル中にトップレベルドメインを管理するネームサーバを実際に
記述してもらわなければならない。これがないと、そのドメインが検索できなくなってしまう。

日本のドメインである「jp」を例にすると、その管理・運用は「日本レジストリサービス」（JPRS）に委任されている。
また同時に、JPRSの管理するネームサーバがjpトップレベルドメインのネームサーバとして登録されている（図5）。
委任というと何やらいかめしい感じがするが、要は一度ドメインの管理を委任されればその中でどのようなサブドメインを作ろうと、どのようなポリシーで運用しようと自由になる
ということである。その部分はそれぞれが責任を持って管理・運用してくださいという信頼関係を基に、管理権限を委譲するのである。

図5●ゾーンの管理の実際

同様に、アスキーのドメインであるascii.co.jpは、ドメイン名の取得という段階を経て、JPRSの管理するネームサーバにascii.co.jpを管理・運用するネームサーバが登録されている
（ascii.co.jpを委任される）。これによってはじめて、ルートネームサーバから順に、アスキーのネームサーバにたどり着けることができるようになる。

このように、あるゾーンは必ず上位のゾーンから信頼され、委任を受けていなければならない。同時に、そのゾーンを管理するものは自分自身のドメインに関する情報を責任を持って
インターネットに告知しなければならない。このときに重要になるのが「権限元」（Authority）という考え方である。

権限元は「たしかに○○ドメインは“××”に委任しています」ということを示すものであるため、そのゾーンの情報が信じられるかどうかといったときに「信頼性」の
よりどころになる。権限元があれば、確実に委任されているということを示すことができるわけだ。DNSはこうした信頼の連鎖によって全体が構成されている。

DNS の役割は、問い合わせを受けた IP アドレス（ A レコード）やネームサーバ名（ NS レコード）を回答するだけではない。実際、ゾーンファイルには前回説明したようにさまざまなレコードが登録されている。中でも、ドメイン宛にメールを送信するときに必要な MX レコードと、サーバに別名を付けるときに使う CNAME レコードは重要だ。

ドメイン名だけでメールが届く

DNSの用途と聞いて真っ先に思いつくのは、Webブラウザに入力したURLからWebサーバのIPアドレスを調べることだろう。
事実、Webページを見るのにIPアドレスを覚えなくて済むのはDNSのおかげだ。しかし、DNSはWebブラウズのためだけにあるわけではない。
実は、メールをやり取りする際にもDNSは利用されている。

メールを送信したあと相手に届くまでには、個人であればISPのメールサーバを、企業であれば社内に設置されたメールサーバを経由して、送信相手のISP（あるいは企業）の
メールサーバへ送られる。そして、メールを受け取る側は、自身のメールボックスがあるメールサーバにアクセスしてメールを受信するようになっている。

このように、メールサーバがメールを届けるには、送信相手のメールボックスがあるメールサーバのIPアドレスが必要だ。
しかし、その目印になるメールアドレスには「宛先ユーザー名」と「宛先ドメイン名」の2つの情報しか含まれていないことが多い※1。

DNSを使えば、ドメイン名からメール送信先のドメインを管理するネームサーバを見つけられる。そのネームサーバに配下のメールサーバを問い合わせればメールを届けられる。
つまりDNSには、メールアドレスに含まれるドメイン名から送信先メールサーバのホスト名とIPアドレスを求める仕組みが備わっている。

ネームサーバが、ドメイン名からメールサーバのIPアドレスを得る流れは図1のようになる。
まずは、メールアドレスに含まれるドメイン名からそのドメインを管理するネームサーバを探し、見つかれば今度はドメイン内に設置されているメールサーバのホスト名を尋ねる。

図1●宛先ドメインのネームサーバには2度尋ねることになる

このときに問い合わせ先のネームサーバが参照するのがMX（Mail eXchanger）レコードである。ネームサーバはこの回答を元にIPアドレスを尋ねる。
この場合、問い合わせ先のネームサーバはAレコードを参照する。以上の手順を経ることで、メールの転送に必要な送信先のメールサーバ（メールエクスチェンジャ）の
IPアドレスがわかる。このメールエクスチェンジャとは、別ドメインにあるメールサーバと直接通信するメールサーバのことである。

※1：宛先ドメイン名の部分に、宛先メールサーバのホスト名が直接指定されていることもある。

メールエクスチェンジャとは？

一般に、同じドメイン宛のメールはメールサーバが処理するが、異なるドメイン宛のメールは（メールサーバが）メールエクスチェンジャに送信を依頼する。
このメールエクスチェンジャとはいったいどんなサーバなのだろうか。メールが配信される仕組みをおさらいしながら、メールエクスチェンジャが必要な理由を調べてみよう（図2）。

図2●メールエクスチェンジャがメール中継の責任を負う

メールはいったん社内のサーバに

クライアントでメールソフトの送信ボタンを押すと、メールは社内メールサーバに送られる。
このサーバは、たとえば Outlook Express の場合［ツール］→［アカウント］→［プロパティ］→［サーバ］とたどれば表示される「送信メールサーバ（ SMTP ）」のことだ。

社内・社外宛を問わず、社内のクライアントから送信されたメールはいったんすべてこのメールサーバに蓄えられる。
そして、社内メールサーバがメールアドレスの宛先ドメイン名（ @ から右の部分）をチェックし、社内宛であれば該当するユーザーのメールボックスに振り分け、ドメイン名が
異なればメールエクスチェンジャに送信を依頼する。

このようにメールエクスチェンジャは、社内から送信された社外宛のメールを中継するために設置されている。
加えて、社外からのメールを一括して受け取り、適切な社内のメールサーバに中継する役割も担っている。
ちなみにこれらメールサーバは、社内メールサーバがファイアウォールの内側に、メールエクスチェンジャがファイアウォールの外側に設置されているのが一般的だ。
社内のメールサーバが直接メールを送信しないのは、主にセキュリティの観点からの措置である。インターネットに直接つながるサーバにメールを保管するのは好ましくない。
そのため、メールエクスチェンジャはメールボックスを持たない。

DNSでメールエクスチェンジャを調べる仕組み
社外宛のメールは、インターネットを経由して送信することになる。メールの宛先の手掛かりになるのはメールアドレスに含まれるドメイン名しかない。
そこでメールエクスチェンジャは、ネームサーバに対して「このドメイン宛のメールを受け取ってくれるメールエクスチェンジャのホスト名（ MX レコード）を調べてほしい」と
依頼する。
依頼を受けたネームサーバは、まずは宛先のドメインを管理するネームサーバを探す。
簡単にいうと、最初に自身のキャッシュを調べ、なければドメインツリーのルートサーバから順番に尋ねて回る。そして最後に目的のドメインを管理するネームサーバを見つける。
そのあと、

・ドメインにあるメールエクスチェンジャのホスト名を尋ねる
・返ってきたホスト名を元にIPアドレスの問い合わせをする

といった具合に、最後にきて少し手間がかかるようになっている。

図3●プリファレンス値でメールエクスチェンジャの役割を変える

MXレコードが必要なワケ

メールアドレスのドメイン名の部分がメールサーバのホスト名であれば、MX レコードは必要ない。
それに、もともとはメールアドレスの @ 以下はメールサーバのホスト名そのものだった。しかし、メールが普及するにつれ、メールサーバへの負荷が高まった。
こうなると、負荷を分散させるための仕組みと、冗長性を確保するための仕組みが必要になる。そこで利用されるのがMX レコードというわけだ。
MX レコードを使用する利点は、ドメイン名宛のメールを受け取れるメールサーバを複数指定できるという点にある。
複数台のメールサーバを用意し、すべて MX レコードに指定しておくことで、メールサーバの負荷を分散し、冗長性を高められる。
メールサーバのダウンやメンテナンスを目的にハードウェアを停止しなければならない場面でも、他のメールサーバがメールの受信を継続できる。
また停電や地震などの不意の事故に対応する必要があれば、物理的に離れた地点にメールサーバを設置してもよい。
MX レコードの設定さえ正しければ、設置場所に依存せずに負荷分散や冗長構成を採れる。

また、それぞれのメールサーバには優先順位をつけることも可能だ（前ページ図3）。これには、プリファレンス値と呼ばれる値を使う。
この値そのものに意味はなく、小さいほど優先順位が高いと2解釈される。同じ値であれば、ネームサーバが問い合わせを受けるたびにランダムに選ぶため負荷が分散される。
またプリファレンス値を大きくしたメールサーバを運用しておけば、値の小さなメールサーバがダウンした際のバックアップとして利用できる。

たとえば、 IN MX 10 mx1.ascii.co.jp. という環境があったとする。稼動しているメールサーバは mx1 だけだ。
このドメインに、新たにメールサーバ（ mx2 ）を1台追加したとしよう。このとき、IN MX 10 mx2.ascii.co.jp. とすれば負荷が分散され、 IN MX 20 mx2.ascii.co.jp. とすれば、
mx2 は mx1 のバックアップサーバとして稼動することになる。プリファレンス値次第で役割を柔軟に設定できるのが MX レコードのメリットである。

CNAME で複数のサーバに同じ名前を付ける

アクセスが集中することが予想されるサーバは、複数台設置して負荷分散するのが一般的だ。
実際に大企業の公開 Web サーバなどは、バックアップも兼ねて複数台で運用している（画面1）。
しかし、同じホスト名を別のサーバに付けることはできず、かといって利用者にホスト名を使い分けてもらうのも現実的ではない。
このような場面で利用されるのが CNAME（ Canonical NAME ）レコードである。ちなみに、「 canonical 」は「正統の」や「正規の」と訳される。

画面1●複数のサーバで運用していると複数のIPアドレスが返ってくる

具体的には、図4のようにゾーンファイルを設定することになる。
このように設定することで、www.example.comの名前解決を依頼されたネームサーバは、まず www.example.com にはCNAMEがあることを把握する。
そして、www.example.comを別名（エイリアス）として持つサーバの正規名（ www1.example.com、www2.example.com、www3.example.com ）を調べ、
それぞれの A レコードを元に、すべての IP アドレスをリゾルバに回答するようになっている。

図4●複数のサーバで負荷を分散する場合

画面2は「 www.microsoft.com 」を名前解決したときのパケットをキャプチャしたものだ。
これを見ると、www.microsoft.com は複数台のサーバで構成されており、その正規名は「www.microsoft.akadns.net」であることがわかる。
また、第2回で解説した DNS メッセージの「回答部」には、CNAME であることと、複数台設置された Web サーバの IP アドレスが含まれていることがわかる。

画面2●CNAMEであることを含め、複数の回答が返る

CNAMEレコードの中身

CNAMEレコードには、別名と正規名の関連付けが記述されている。
この場合の別名は「外部からのアクセスを受け付けられる名前」を指し、正規名は「サーバに付けられた本当のホスト名」を指す。

ゾーンファイルには、別名と正規名を並べて記述する。具体的には、

といった具合になる。この場合、「 www.example.com 」が別名で、「 www1.example.com 」や「 www2.example.com 」が正規名だ。

同じサーバで別のサービスを提供

CNAME の使い道は負荷分散だけではない。
先の例では別々のサーバ（マシン）に同じ別名を割り当てたが、逆の使い方もできる。つまり、1台のサーバに異なる別名を割り当てることもできる（図5）。

図5●同じサーバで複数のサービスを提供する場合

中小規模のネットワークでよく採られるサーバの運用方法に、1台のサーバでいろいろなサービスを提供するというものがある。このような場合にも CNAME は便利だ。

たとえば、ゾーンファイルに

www IN CNAME servers.example.com.
ftp IN CNAME servers.example.com.
proxy IN CNAME servers.example.com.

と記述しておけば、www.example.com と ftp.example.com および proxy.example.com のどのホスト名で名前解決しても、
ネームサーバは servers.example.com の A レコードを参照して回答する。

なお、同じサーバで別のサービスを提供するという用途では CNAME を使わずに A レコードを羅列するという方法もある。

今回の例では、

www.example.com. IN A 192.168.0.1
ftp.example.com. IN A 192.168.0.1
proxy.example.com. IN A 192.168.0.1

と記述すれば同じ動作をすることになる。CNAME を設定すると、CNAME レコードの参照結果を元に A レコードを参照するので、ゾーンファイルを参照する回数が増える。
また、CNAME を使いすぎると正規名と別名の対応の管理が煩わしくなることもある。
そのため、1台のサーバで複数のサービスを提供する中小規模のネットワークでは、CNAME は使わず A レコードを羅列する運用をしている場合も多い。

ドメイン名だけでメールが届く

逆引きの仕組み

ネームサーバの基本的な役割は、ドメイン名（ホスト名）と IP アドレスを相互変換することである。
あらためていうと、ドメイン名から IP アドレスを引くことを正引き、IP アドレスからドメイン名を引くことを逆引きと呼ぶ。
そのため、逆引きは単純にネームサーバがデータベースを逆向きに検索すれば実現できると思ってしまいがちだが、実はそうではない。
正引きと逆引きには、まったく異なるデータベース（ゾーンファイル）が使われている（図1）。

図1●正引きと逆引きには、異なるデータベースが使われている

また、逆引きには IP アドレスを一覧したデータベースが使われるというイメージがあるが、ドメイン名を一覧したデータベースが使われるといったほうがしっくりくる。
意外と知られていないが、逆引きには、ドメイン名から IP アドレスを求める正引きと同じ仕組みがそのまま使われているのだ。
この点は少しわかりにくいので、実例に照らして説明しよう。

たとえば、逆引きのデータは IP アドレスそのものではなく、「1.1.168.192.in-addr.arpa.」のような形式になっている。これは実のところ、ドメイン名そのものである。
たとえば、次の2行を見比べてみてほしい。

下の「www.ascii.co.jp.」はアスキーの Web サーバのドメイン名だが、左のほうがホスト側、右にいくに従ってルートに近くなっている。
では上の「1.1.168.192.in-addr.arpa.」はどうだろうか？これを「192.168.1.1」という IP アドレスに対する「逆引きドメイン名」という。
www.ascii.co.jp. のドメイン名と同じように、左のほうがホスト側で、右に行くほどルートに近くなっているのわかるだろう（図2）。

図2●逆引きの仕組み

逆引きドメイン名

逆引きドメイン名に出てくる「arpa」（アルパ）という名前は、「jp」や「com」と同じく、インターネットのトップレベルドメインの1つである。
arpa トップレベルドメインは、インターネットの特殊な用途で利用するために、「IAB」（ Internet Architecture Board ：インターネットアーキテクチャ委員会）によって
予約されているドメイン名だ。このドメインには、IPv4 のインターネットアドレスであることを示す「in-addr」（インターネットアドレス）や、IPv6 のインターネットアドレスの
ゾーンを管理する「ip6」、IP 電話のゾーンを管理する「e164」というサブドメインが所属している（図3）。

図3● 特殊な用途で使われるドメイン名

ここで、図2に目を戻していただきたい。これまでの説明に照らしてもう一度見てみると、逆引きドメイン名の構成がどのようになっているのかわかると思う。
具体的には、arpa トップレベルドメインから in-addr ドメインにつながり、さらにその下に IP アドレスのオクテット※1の順序が逆になって、ドメイン名が構成される。

このドメイン名は、逆引きのゾーンファイルに図4のように登録されている。
ご覧のように、IP アドレスの4オクテット目（ 192.168.1.1 でいう右端の「1」）を「ホスト名」にした格好になる。ネームサーバはこの逆引きドメイン名を元にゾーンファイルを
検索し、最終的に目的とするドメイン名が取り出されている。

図4● 逆引きのゾーンファイルの中身

※1 ：オクテットとは8ビットの単位のこと。IP アドレスではピリオドで区切られた数字が1オクテットと思えばよい。

逆引きのゾーンファイル

それでは、逆引きのゾーンファイルの中身を詳細に見ていくことにしよう。先の図4はゾーンファイルの一例だが、ここでは「192.168.1.xx」という IP アドレスのゾーンが
定義されている。

最初に目に付くのは「 $ORIGIN 」の文字だろう。$ORIGIN は、以降のドメイン名を指定した始点名に置き換えるものである。
これによって、「1.168.192.in-addr.arpa.」が始点名となり、以降、最後がピリオドで終わっていないドメイン名がある場合には「1.168.192.in-addr.arpa.」の文字が自動的に
補完される。

$ORIGIN のあとは、正引きのところで説明した SOA レコードや NS レコードが続く。ここでは、次の「PTR」（ポインタ）レコードに注目してほしい。
PTR レコードは、指定された逆引きドメイン名に対するドメイン名を求めるための情報である。レコードの形式は

逆引きドメイン名 : IN : PTR : IPアドレスに対応するドメイン名（FQDN）

となる。図4では、PTR レコードの各行は「1」や「11」のように、IP アドレスの第4オクテット目だけしか記述していないが、前述したように「1.168.192.in-addr.arpa.」が
補完される。つまり PTR レコードとして定義されている「1」は、1.1.168.192.in-addr.arpa. という逆引きドメイン名を示し、これがg w-bk1.book.ascii.co.jp. という
ドメイン名（ IP アドレスに対するドメイン名）と関連付けられていることになる。したがって、192.168.1.1 という逆引きの問い合わせ（ PTR レコード）があれば、
この gw-bk1.book.ascii.co.jp が回答される。

ゾーンファイルを作る

以上で逆引き用のゾーンファイルの中身がわかったが、実際このファイルはどのようにして作ればよいのだろうか。たとえば「192.168.1.0～192.168.3.255」のような範囲で
IP アドレスを使っているとしよう。この場合でも、基本は単純だ。IP アドレスの第3オクテットを仮想的にドメインツリーのノードと見なして、その単位ごとに定義した
ゾーンファイルを作ればよい。具体的には図5のように、「1.168.192.in-addr.arpa.」「2.168.192.in-addr.arpa.」「3.168.192.in-addr.arpa.」という、
3つの逆引きゾーンファイルを作成する。

ただし、名前解決は正引きと同様に処理されるため、必要に応じて第3オクテットのノードを第1オクテットと第2オクテットのノードから検索できるようにしておかなければならない。
たとえば上位「192.168」のゾーンを自分で管理するなら、通常のネームサーバの設定をするときのように、「192.168.1」から「192.168.3」のゾーンを管理するネームサーバ
（ NS レコード）を、192.168 ゾーンを管理するネームサーバに登録しておく必要がある。

CIDR を使っている場合を考える

さて、ここまでの説明は実は、都合よく IP アドレスがオクテット単位で使える状態にある場合を想定していた。
しかし実際の逆引きのゾーンファイルは、ある問題を考慮して作らなければならない。というのも、現在のインターネットは、IP アドレスのネットワーク部を可変長にして運用する
「CIDR」（ Classless Inter-Domain Routing、サイダー）が使われているからである。

DNS の逆引きは、基本的にオクテット単位でしか行なえない。逆引きのためのデータ構造がそうなっているためである。
先に述べたように、逆引きは IP アドレスの各オクテットを仮想的にノードと見なし、その単位ごとにゾーンを定義することで実現している。

いいかえれば、IP アドレスのピリオドで区切られる境界ごとに、特定のドメインを示す構造になっている。

ここには、オクテット単位以外でドメイン名を管理する仕組みが存在しないのだ。

ところが、CIDR は IP アドレスからクラスの概念を取り除き、1ビットごとに可変長のネットワークアドレスを使えるようにする。
つまり、オクテットの境界とは無関係にネットワークアドレスを割り振るわけだ。

たとえば、小さな組織だと接続先の ISP から「/28」とか「/29」いう形で16個、ないしは8個の IP アドレスを割り振ってもらっている。

この場合、IP アドレスの第4オクテットの一部に、自分のネットワークアドレス（ドメイン）が含まれることになる。

ユーザー（ ISP に契約している組織）に割り当てられる IP アドレスが16個や8個だと、1つのオクテット（8ビット、最大で256個の IP アドレスがある）を複数のユーザーで
共有しなければならない。

そうなると、同じ逆引きのゾーンを他のユーザーも使うことになり、誰がどのようにゾーンを管理をすればよいのかということが問題になる。

実際のところ、こうした CIDR 環境における逆引きの問題は、ISP によって対応が異なる。

代表的なのは、1: あるオクテットの逆引きを ISP 側で一括管理してしまう方法と、

2: 第4オクテットの下にサブドメインを定義し、そのサブドメインの管理をユーザー側に任せる方法の2種類だ（図6）。

前者の方法なら、逆引きゾーンの設定を ISP に任せてしまえるので簡単だ。
だが、何か変更があるたびに ISP に連絡し、必要な作業をしてもらわなければならないという不都合もある。
一方後者はゾーンを自分で管理できるが、仕組みとしてはややトリッキーな方法を使わなければならず、ユーザー側に相応の知識が求められる。

どちらがよいかは一概にはいえないが、ここでは後者の方法を採る場合に、具体的にどのようなテクニックが使われているのか見てみよう。
内容は少し難しいかもしれないが、現在のインターネット環境では DNS の逆引きをするのに「こうしたことが行なわれている」という、雰囲気だけでもつかんでもらえれば結構だ。

CNAMEを使ってネームサーバを振り分ける

まず最初に、図7を見てほしい。この例では、ユーザーが持っている「192.168.10.18」というIPアドレスに対するドメイン名をどのように解決するかという点に絞って説明している。
「192.168.10.18」というIPアドレスは、「18.10.168.192.in-addr.arpa.」という逆引きドメイン名に変換される。
このドメイン名は「10.168.192.in-addr.arpa.」のゾーンを管理しているゾーンファイルに登録されているので、ここが参照されることになる。

このゾーンファイルには、18.10.168.192.in-addr.arpa. の逆引きドメイン名に対して、PTR レコードではなく CNAME レコードによって、
「18.usr1.10.168.192.in-addr.arpa.」という別名が付けられている。このようにするのは、同じオクテット内の IP アドレスを使っているユーザーごとに、
別々のネームサーバを関連付けるためである。つまり、ユーザー1（ usr1 ）が持つ IP アドレスへの問い合わせがあれば、そのユーザーが管理するネームサーバに問い合わせを
振り分けるのだ。

CNAME（別名）が回答されると、問い合わせ元のネームサーバはその正規名を調べなければならない。
この例では、ISP 側のゾーンファイルの最初に示した NS レコードにより、usr1.10.168.192.in-addr.arpa. は「usrns1.ext.ascii.co.jp.」というネームサーバの管理下に
あることがわかる。そこで、今度はそのネームサーバに問い合わせが行なわれる。

ユーザー側は自分のゾーンファイルに、18.usr1.10.168.192.in-addr.arpa. という逆引きドメイン名に対して、PTR レコードで「userhost.ext.ascii.co.jp.」というドメイン名
（ FQDN ）を定義している。最終的に、このドメイン名が取り出されれば、逆引きが完了するという流れになる。

いかがだろうか。たしかに、この方法を使えばCIDRを使った環境でも、ユーザーが管理するゾーン情報にたどり着くことができる。
しかしその反面、ユーザー側に十分な知識がないと正しく逆引きを設定できないこともわかるだろう。

逆引きを設定しよう

逆引きを提供していないネームサーバが多いのは冒頭で紹介した通りだが、原因はこうした設定の難しさにもある。インターネットでは逆引きは必ずしも必要ではないが、
あったほうが便利なのは明らかだ。このあたりは、優秀な技術者が増えることで解決される方向に向かってほしいところである。

たとえば DNS の逆引きは、最近の迷惑メールに対する対策としても有効だ。実際、逆引きを使って送信ホスト名などを特定しているサイトも増えているという。
このパートでは、CIDR を使っているときの逆引きテクニックを実環境を想定して解説した。ネームサーバを管理している読者なら、これを機会に逆引きを設定してみては
いかがだろうか？

nslookup を起動する

コマンドプロンプトから「 nslookup 」と入力すると、nslookup が起動する。最初に表示される2行は、現在の問い合わせ先ネームサーバを示す。
実際は、PC に設定した DNS サーバである。「 Default Server 」はサーバ名（ドメイン名）、「 Address 」はその IP アドレスだ。問い合わせ先サーバは変更できるが、
とりあえずこのサーバを使ってみる。

また最後の「 > 」は、入力プロンプトである。ここに続けて nslookup のコマンドを入力する（以降、入力は太字で示す）。

いくつか名前解決してみる

まずは、アスキーの Web サーバの IP アドレスを調べてみよう。「www.ascii.co.jp. 」と入力する
（最後の「 . 」を忘れずに）。すると、現在のネームサーバから回答が返ってくる。

回答結果を見ると、IP アドレスは「61.114.182.85」であることがわかる。
ただ、そのドメイン名は、「at3.ascii.co.jp」になっている。www.ascii.co.jp は、その下の「Aliases」（別名）として表示されている。
このドメイン名は CNAME で定義されているわけだ。正規の名前は、at3.ascii.co.jp である。

同じようにして、別のドメイン名も調べてみよう。ここでは、アメリカ航空宇宙局（ NASA、www.nasa.gov ）の Web サーバを名前解決してみた。
その結果、NASA の Web サーバは「198.116.142.34」であることがわかった。NASAのWebサーバのドメイン名も別名で、正規名は「foundation.hq.nasa.gov」であることも
見てとれる。

ここで、目を凝らして見比べてほしい部分がある。アスキーの結果には、「Non-authoritative answer」という文字が付いている。
これは「権限元からではない回答」という意味で、回答がキャッシュから返されていることを示す。一方、NASAのIPアドレスはキャッシュになかったようである。
だが今の名前解決でキャッシュされているから、もう一度検索すれば「Non-authoritative answer」になるはずだ。

NS レコードと MX レコードを調べる

DNS で検索できる情報は、IP アドレス（ A レコード）だけではない。ドメインを管理するネームサーバ（ NS レコード）や、ドメイン宛のメールを受け取るメールサーバ
（メールエクスチェンジャ、MXレコード）を調べることもできる。ここで、NS レコードと MX レコードを検索してみよう。

まず「set type=○○」と入力して、検索したいレコードのタイプを変更する。NSレコードを調べるなら、「set type=ns」とする。
そのあと、「ascii.co.jp. 」とドメイン名を入力すると、アスキーのドメインを管理するネームサーバが回答される。

ご覧のように、「ascns3.ascii.co.jp」「ascns4.ascii.co.jp」「ns1.iij.ad.jp」の3つのネームサーバが回答された。アスキーは3台のネームサーバで運用されているということだ。
プライマリサーバはこのうちの1つだが、IIJ のサーバでもアスキーのゾーンを管理していることがわかる。
ネームサーバは複数台で、しかも異なるネットワークで分散して運用することが推奨されているが、まさにその通りになっているわけだ。

同様に、MX レコードも調べてみよう。最初に「set type=mx」、そして「ascii.co.jp.」と入力する。
すると、4台のメールサーバが回答された。「mail exchanger =」に続くドメイン名がメールサーバを示す。
「preference」はメールサーバの優先度。数値が小さいほど優先度が高い。「preference = 10」のサーバが2台あるということは、
平常時はこの2台でメールを並列処理していることを示している。そして、これらに障害が発生した場合は、「preference = 30」のサーバが処理を引き継ぐ。

最後のピリオドを付けなかったら？

DNS では、ドメイン名の最後に付けられたピリオド（ . ）で、ルートドメインを示す。ここまで、この実習ではドメイン名にはすべてピリオドを付けて入力している。
このピリオドは必須なのだろうか？

結論からいうと、必須とはいわないまでも、意識して付けるべきである。ピリオドを付けずにドメイン名を指定すると、ドメイン名が「終端」されないからだ。
つまり、名前解決を依頼されたリゾルバが後ろにまだ何か続くのでは？と考えるのだ。その結果、リゾルバが勝手に自ドメイン（ ascii.co.jp とか）を補完して送ることになる。
たとえば、「www.nasa.gov」を調べようとすると、「www.nasa.gov.ascii.co.jp」というドメイン名が送られる。これでは、正しい名前解決はできない。

だが、「うっかりピリオドを忘れたが、問題なく名前解決できた」という読者もいるかもしれない。
これは、リゾルバとネームサーバが何度かやり取りして、最終的に正しいドメイン名を見つけているからに他ならない。
リゾルバが、「www.nasa.gov.ascii.co.jp と補完したが正しい回答がなかったから、次は www.nasa.gov.co.jp を送ってみよう」、
「www.nasa.gov.co.jp でも正しい回答がなかったから、www.nasa.gov.jp でやってみよう」というように、補完する文字列を減らしながら最終的に www.nasa.gov を
見つけているのだ。

ただし、いつでもこのようにうまくいくとは限らない。そのため nslookup を使うときは、最後のピリオドを付けるクセを付けておこう。

自分で反復的な問い合わせをやってみる

次に、反復的な問い合わせを使って、ドメインツリーの中から目的のネームサーバ（ NS レコード）を探してみよう。
通常は問い合わせ先のネームサーバ（フルサービスリゾルバ）がしていることだが、自分でやってみることも可能だ。
ここでは、ルートドメインからたどりながら www.ascii.co.jp. を管理するネームサーバを探して、IP アドレスを解決する。

●ルートサーバに問い合わせる

まずは「set type=ns」と入力して、検索するレコードを NS レコードに変更する。続いて「 . 」と入力すると、利用可能なルートサーバがずらりと一覧される。
現在、ルートサーバは13台稼働している。よく見ると「A～M」までのアルファベットで管理されていることがわかる（表示順はばらばら）。
このうち、「M.ROOT-SERVERS.NET」は日本（ WIDE プロジェクト）で管理されているネームサーバだ。ここでは、このサーバに問い合わせしてみよう。

問い合わせ先サーバの変更は、「server サーバ名」でできる。サーバを変更すると、Default Server の欄も変わることに注目してほしい。

ルートサーバは、世界で約250ある TLD （トップレベルドメイン）を束ねるネームサーバである。日本の ccTLD である jp も、いうまでもなくその1つに含まれる。
したがって、ここに問い合わせれば、jp ドメインを管理しているネームサーバがわかる。
「jp. 」と入力してみると、「DNS0.SPIN.AD.jp」をはじめとした6台のネームサーバが表示されるだろう。

● ネームサーバを絞り込む

これらのネームサーバは、co.jp や ne.jp、ad.jp、go.jp、ed.jp といった、ドメイン名に「jp」を持つすべての SLD（セカンドレベルドメイン）を束ねている。
ascii.co.jp は、そのうちの co.jp ドメインに含まれるので、co.jp ドメインを管理しているネームサーバがわかればよい。
そこで、たとえば dns0.spin.ad.jp にサーバを変更して、「co.jp.」と問い合わせる。

回答結果を見ると、表示状態は若干異なるものの、サーバとしては同じ6台が一覧された。
これは、jp ドメインのゾーンと、jp 以下の SLD のゾーンが同じサーバで管理されていることを示す。
ネームサーバは複数の異なるゾーン情報を持つことができるので、こうした運用も可能なのだ。
なお、ns0.nic.ad.jp と ns0.iij.ad.jp の A レコードには「クワッド A レコード」（ AAAA レコード）も表示されている。
この2つのネームサーバは、IPv6 に対応しているようである。

続いて、アスキーのドメインを管理しているネームサーバを調べる。
サーバを変更する必要はないので、そのまま「ascii.co.jp.」と入力する。すると、3台のネームサーバが回答された。

● 最後にホストを検索

これらのネームサーバでは、ascii 配下のホストを管理している。
ここに、「www.ascii.co.jp.」といった A レコードの問い合わせをすれば（ set type=a が必要）、該当する IP アドレスを得られる。
ちなみに、これらのネームサーバは「外向け」に運用されている。
公開ホストの情報しか持っていないので、アスキーの社内ネットワークにあるサブドメインや個々のホストの情報は検索できない。

逆引きしてみる

最後に、IP アドレスからドメイン名を見つける「逆引き」を試してみよう。
逆引きには PTR レコードを使うので、「set type=ptr」としてレコードタイプを変更する（問い合わせ先サーバは同じでよいだろう）。

逆引きするときは、ドメイン名の代わりに IP アドレスを入力する。
たとえば、「61.114.182.85」を問い合わせると、「at3.ascii.co.jp」（ www.ascii.co.jp の正規名）が回答される。
回答結果をよく見ると、61.114.182.85 という IP アドレスは、「85.182.114.61.in-addr.arpa」という逆引きドメイン名で処理されていることに気づく。
また、上位ドメインとして「182.114.61.in-addr.arpa」があり、権限元のネームサーバは「ns02.secomtrust.net」などであることもわかる。
逆引きには、in-addr.arpa という専用のドメインが使われる。このドメインでは、IP アドレスの4つの数字をノードとした名前空間が形成されている。
イメージとしては、182.114.61.in-addr.arpa というドメインに、85というドメインがぶら下がる形になる。
したがって、「85.182.114.61.in-addr.arpa.」のように、最初から逆引きドメイン名で問い合わせしても同じ結果が得られる。