インターネットの仕組みを学ぶ 第2回

Domain Name System

新潟インターネット研究会

金 東虎

歴史

1970年代、ARPANETはわずか数百台のホストから構成される、 非常に小さなネットワークであった。 これらのホストに関する情報はすべて HOSTS.TXTという一つのファイルに収められていた。 ファイルの体裁はUnixの/etc/hostsとよく似ていた。 すなわち、ホストの名前とIPアドレスとの対応がずらずら並んでいたのである。

このファイルはSRI-NIC (Stanford Research Institute - Network Information Center)によって一元管理されていた。 ARPANETの各サイトの管理者は、自分のサイトのホスト情報に変更が生じると、 それを電子メールでSRI-NICに連絡し、 SRI-NICの担当者は手動でその変更をHOSTS.TXTに反映させたのである。 また、各サイトの管理者は定期的にSRI-NICからftpで最新のHOSTS.TXTを取り寄せ、 自分のサイトのホストテーブルを更新する作業を怠らないようにしていた。

当然のことながら、この仕組みはARPANETの規模が大きくなるにつれて破綻した。 そこで1983年に登場したのがDomain Name System (DNS)である。 ( RFC882 , RFC883 , RFC1034 , RFC1035 ) このシステムは Internetが数千万台のホストで構成される規模になった現在においても 十分に機能しており、なおかつ当分の間は大丈夫であろうと言われている。 すなわち、きわめて高いスケーラビリティを持ったシステムなのである。

DNS

ドメイン名システムは分散型データベースシステム (Distributed Database System) である。一般に分散型データベースシステムと言えば、 リレーショナルデータベースシステムの各リレーションが 地理的に分散配置されているモデルを思い浮かべる人が多いかもしれないが、 ドメイン名システムは違う。

ドメイン名システムのもっとも大きな特徴は、 そのデータベースの構造がツリーになっていることである。 計算機科学で出て来るツリーは、自然界の木とは異なる。 不思議なことに、根(ルート)が一番上にあり、下に向かって伸びていくのである。

ツリー構造を理解するためには、 Unixのファイルシステムを思い浮かべるのがよいかもしれない。 Unixファイルシステムにおける「ディレクトリ」がドメイン名システムにおける 「ドメイン」に相当する。 「サブディレクトリ」、「サブドメイン」についても同様に考えればよい。

Unixファイルシステムとドメイン名システムは構造としては似通っているが、 表記法はまるで逆になっている。 すなわち、Unixファイルシステムにおいては、 ルートから葉に向かって / (スラッシュ) で区切りながら記述していくが、 ドメイン名システムにおいては逆に、 葉の方からルートに向かって . (ドット) で区切りながら記述する。

ドメイン名システムのもう一つの大きな特徴は、 各ドメインを異なる組織が管理することができることにある。 ルートドメインはInterNICが管理し、jpドメインはJPNICが管理し、 niigata-u.ac.jpドメインは新潟大学が管理し、 dent.niigata-u.ac.jpドメインは新潟大学歯学部が管理する、 といった具合である。 ドメイン名システムにおいては、ドメインが異なっていれば、 たとえ名前が衝突していても違うものとみなされるので、 各ドメインの管理者は自由に名前を付けることができる。

BIND

ドメイン名システムは4.3BSDに実装された。これがBerkley Internet Name Domain (BIND)である。DNSの実装としては、BINDが事実上の標準である。

ドメイン名空間

DNSツリーの全体をドメイン名空間と呼ぶ。

ドメイン名

DNSツリーの各ノードには(ドットを含まない)簡単な名前のラベルが付けられる。 このラベルの長さは63文字までとなっている。 当初は数字で始まってはいけないという制限があったが、この制限は RFC1123 で緩和された。 ルートドメインには空の(長さゼロの)ラベルがあらかじめ付けられている。 各ノードの完全なドメイン名はそのノードからルートに向かうパス上を、 ラベルを . (ドット) で区切りながら並べたものである。

ドメイン

ドメインとは単にドメイン名空間の中の、あるサブツリーのことである。 ドメインのドメイン名は、 そのサブツリーの中でのルート(最上位)ノードのドメイン名と同じになる。

TLD

ルートドメインの直下にあるドメインをTop Level Domain (TLD)と呼ぶ。 TLDには大きく分けて次の5種類がある。

委任

ドメイン名システムが作られた大きな目的は、管理を集中させないことであった。 これは委任(delegation)で実現される。 ドメインの仕事を委任するのは、職場で仕事を任せるようなものである。 マネージャーは大きなプロジェクトの仕事をいくつかの小さな仕事に分けて、 スタッフおのおのに仕事の責任分担をするであろう。

同じように、 ある組織の管理しているドメインはいくつかのサブドメインに分けられる。 各サブドメインはそれぞれ別組織に委任することができるのである。 これによって、 委任された組織はそのサブドメインのすべてのデータの保守について責任を負う。 各組織で自由にデータを変更することもできるし、 そのサブドメインをさらにサブドメインに分けて仕事を委任することもできる。 親ドメインは単にそのサブドメインへのポインタだけを持っている。

ネームサーバ

ドメイン名空間についての情報を持つプログラムをネームサーバと呼ぶ。 普通、ネームサーバはドメイン名空間のある部分についての完全な情報を持っており、 その部分をゾーンと呼ぶ。 このとき、このネームサーバはそのゾーンについての権限(authority)を持っている、 と呼ぶ。 一つのネームサーバが複数のゾーンについての権限を持つことも、 もちろん可能である。

プライマリとセカンダリ

あるゾーンについての権限を持つネームサーバには2種類ある。 プライマリネームサーバとセカンダリネームサーバである。 プライマリネームサーバは、ゾーンの情報をファイルから読み込む。 セカンダリネームサーバは、権限を持つ他のネームサーバから、 ネットワーク経由でゾーン転送により情報を読み込む。

リゾルバ

ネームサーバにアクセスするクライアントをリゾルバと呼ぶ。

解決

ネームサーバは、ドメイン名空間の中で自分が権限を持っていない部分についても データを検索することができる。 このプロセスを名前の解決(resolution)と呼ぶ。

ルートネームサーバ

どのネームサーバも、 名前を解決するためにあらかじめ必要な情報はほんの少しである。 それはルートネームサーバのアドレスである。 ルートネームサーバはすべてのTLDについて、 権限を持っているネームサーバのアドレスを知っている。 ルートネームサーバに、あるドメイン名を問い合わせれば、 少なくともそのドメイン名が属するTLDについて、 その権限を持っているネームサーバのアドレスを教えてくれる。 次に、そのTLDについて権限を持っているネームサーバに問い合わせれば、 第2レベルドメインについて教えてくれる。 これを繰り返すことにより、名前の解決が実現する。

ルートネームサーバは世界に9個用意されている。それらには、 a.root-servers.net〜i.root-servers.net というわかりやすい名前が付けられている。ルートネームサーバのリストは ftp://rs.internic.net/domain/named.root にある。ルートネームサーバは時々変更されるので、 各ドメインのネームサーバ管理者は、 常に最新版を入手して設定を正しく保つよう心がける必要がある。

本稿執筆中の1997年1月22日、新たに2個のルートネームサーバが加わった、 というニュースが飛び込んで来た。すなわち、j.root-servers.netと k.root-servers.netの2つである。さらに、近い将来、 あと2個のルートネームサーバが加わる予定とのことである。 既存の9個のルートネームサーバは、 実はCOM/EDU/GOV/MIL/NET/ORGドメインについても権限を持っていたが、 新しいルートネームサーバはそうではないという違いがある。

逆引き

通常の名前の解決は、ドメイン名を与えて、 対応する(数字の)IPアドレスを聞き出すものである。 では、IPアドレスの方が分かっているときに、 対応するドメイン名を知りたいときはどうすればよいだろうか? これは、ログの出力を(人間にとって)見やすくしたり、 ある種の認証(authentication)を行なおうとするときに必要となる。

一つのアプローチは、DNSの全データを探索することである。 しかし、これはHOSTS.TXTの時代には可能であったろうが、 今となってはもちろん実行不可能である。

非常に巧妙な仕組みが考え出された。 ドメイン名空間の中に、 IPアドレスを名前として用いる部分空間をつくってしまうのである。 これがin-addr.arpaドメインである。 例えば、IPアドレス1.2.3.4は4.3.2.1.in-addr.arpaとなる。 逆順に並べることにより、各レベルでの委任が可能になるのである。 実に見事な仕組みである。

キャッシュ

ネームサーバは名前の解決にあたって入手したデータを すぐには捨てずに一定時間保存しておく。 どのゾーンについても権限を持たず、 もっぱらリゾルバからの問い合わせに答えることだけが仕事の ネームサーバも存在する。 このようなネームサーバをキャッシュオンリーネームサーバと呼ぶ。

リソースレコード

A
Address
CNAME
Canonical Name
HINFO
Host INFOrmation
MX
Mail eXchanger
NS
Name Server
PTR
PoinTeR
SOA
Start Of Authority
SERIAL
シリアル番号
REFRESH
セカンダリがプライマリにアクセスする間隔
RETRY
定時にアクセスできなかったときに、再度アクセスする間隔
EXPIRE
アクセスできないままのとき、権限を喪失するまでの時間
MINIMUM
データの生存時間(TTL)
TXT
TeXT
WKS
Well Known Services

ネットワーク名とネットマスク

RFC1101, ftp://ftp.nic.ad.jp/pub/jpnic/dns-info.txt

参考文献

本稿をまとめるにあたり、「DNS&BIND」(アスキー)をおおいに参考にした。 一部の文章はそっくり借用している。

実習用リンク