■ ネームサーバ

さて、前回ドメイン名前空間を説明したな。

木構造ですね。

うむ、木構造を使ったインターネットに接続されたホストの名前の空間だ。

根(root)からたどればすべてのホストの名前がわかるって奴ですよね。

その通り。
言い忘れていたが例外もある、例えインターネットに接続されていたとしても名前をつけていないものはドメイン名前空間にない。

名前をつけていない？

URIやメールアドレスなどで使用されるドメイン名だが。そういうものに使用されないホストならば、わざわざ名前をつける必要がないだろう？ 名前をつけるのはIPアドレスを覚えやすくするためなのだから。

サーバのIPアドレスを覚えやすく文字にしたのがDNSでしたっけ。
覚える必要がないなら、名前は確かに必要ないですね。

うむ。そういうことだな。
さて、この名前空間だが。

この名前空間を管理するものが必要だ。これをネームサーバという。

ねーむさーば。名前のサーバ？

そうだ。ドメイン名前空間を管理し、名前に対する問い合わせに答えるサーバだ。

名前対する問い合わせ？

おいおい。DNSとは何だ？

覚えやすい英数字のホスト名とそのホストのIPアドレスを対応させるものです。
ってこれ前回も言ったような。

では、名前に対する問い合わせってのは？

…その名前に対するIPアドレスを教えてもらうってことですか？

そういうことだ。ネット君、知識は流れるものではなく、積み重ねるものだぞ。

それはわかってますけど。

ふむ。河を流れる石に苔はつかないとはこのことか。

いや、それ違うと思います。

■ ゾーン

さて、ドメイン名前空間を管理するものがネームサーバだが。
ネームサーバは各節(node)に配置される。

節に？ 根に１つ置くわけではなくて？

根にも配置されるが、節、つまりドメインに配置されるということだな。

この形だな。
この各ネームサーバは名前空間全体を知っているわけではない。

じゃあ、何処を知っているんですか？

それぞれの子だけを知っている。
つまり、自分の直下にあるサーバ又はホストの名前とIPアドレスを知っているということだな。

自分の直下。
じゃあ、上の例で言えば、「3min.co.jp」のネームサーバは、その隣の「30min.ne.jp」のことは知らないんですか？

そうだ。
あくまでも自分の直下だ。その上も知らない。

自分の上も知らないんですか？

うむ。このそれぞれのネームサーバが管理する範囲のことをゾーンという。

ネームサーバは、自分とその直下というドメイン名前空間の部分木をゾーンとして管理する、というわけだ。

ぞーん。
範囲とか、地域とかそういう意味ですよね。

そうだ。まあ「管理範囲」と訳すのが適当かな。

管理範囲。そのまんまですね。

■ 基本的な問い合わせ

さて。このようにドメイン名前空間の部分部分を分散してネームサーバが管理している。
では、インターネット上のホストのIPアドレスを知りたい場合、どのように調べるかと言うと。基本的にはこう。

まぁ、細かい話はまた説明するが、簡単にいうとこの方式だな。

ははぁ。順番に下っていくんですね。

そうだ。ドメイン名の後ろからの順番で調べていくわけだな。

ドメイン名の後ろから…。
「www.3min.co.jp」なら、「jp」、「co.jp」、「3min.co.jp」ときて「www.3min.co.jp」と。

そういうことだ。
ちなみに根を管理するサーバのことをルートサーバという。

根(root)のサーバだから、ルートサーバですか。

各ネームサーバは先ほども説明したように直下しか管理しない。ルートサーバの場合、直下のTLDのドメインとネームサーバだな。

jpとかukとかcomとかですね。

なので問い合わせにいった場合、まずTLDのネームサーバへ。次はSLDのネームサーバへ。そして「3min」のドメインへ、ということになるわけだ。

は〜。

インターネットに接続される膨大な数のホストの名前を管理するため、分散して管理している、ということがわかったかな。

DNSは「分散型データベース」だ、っておっしゃってましたよね。納得。

■ リソースレコード

さて、そのネームサーバだが。
自分が管理するゾーンの情報を持っているデータベースサーバなわけだ。

ドメイン名とIPアドレスの対応を行うデータベースですね。

ドメイン名とIPアドレスの対応以外にも、管理情報を持っている。
これらのネームサーバが持つ情報のことをリソースレコードという。

りそーすれこーど？
リソースは「資源」。レコードは「記録」。資源の記録？

まぁ、そうなるな。ネームサーバが管理するホストという資源の記録だな。

データベースに保存されているデータを、リソースレコードと。

そういうことだ。
リソースレコードは以下の形のデータだ。

ん〜？

例えば、「3min.co.jp」のネームサーバのデータベースにある「www」のリソースレコードはこんな形だ。

え、え〜っと。所有者が「3min.co.jp」。名前が「www」。タイプが「0001」。クラスが「0001」。TTLが「86400」。RD長が「4」。RDATAが「192.168.0.1」？

ネット君。理解できるところだけでいいから言ってみたまえ。

「3min.co.jp」の「www」という名前のホストは「192.168.0.1」である。

そうだ。

え？ あってるんですか？

なんだその鳩が豆まきしたような顔は。

どんな顔ですか、それは。「鳩が豆鉄砲」です。
いや、あってるとは思わなくて。

他にわかるところは？

TTLが「84600」。キャッシュって何をキャッシュするかわからないですけど、ともかくキャッシュの時間が86400秒。
あとは……？

よしよし。なかなかいいぞ。
他のは今から説明しよう。まずタイプだが、代表的なタイプとしては以下のものがある。

他にもあるが、よく使われるのはこれぐらいだ。

さっきの例のはタイプが「0001」だから、タイプAですね。

そういう場合「Aレコード」と言うのだ。

えーれこーど。
じゃあ、タイプSOAは「SOAレコード」ですね。

そうなる。このリソースレコードのタイプについては重要なので先で詳しく説明する。
次はクラス。

先ほどの例では0001でした。説明では通常は0001だとか。

うむ。ここにはそのリソースレコードのクラスというか、使用プロトコルが入るのだが。
現在では「0x0001 = Internet(in)」しか使われない。

ははぁ。じゃあここは「in(0x0001)」が入る、と覚えておけばいいですね。

あとは、RD長と、RDATAだな。
RDATAはタイプによって変わるので一概にこれといいがたい。

さっきの例ですと、「192.168.0.1」というIPアドレスが入ってましたね。

うむ、Aレコードの場合はIPアドレスが入る。
RD長はRDATAの長さが入る。単位がオクテットだから、32bitなので4オクテットだから、4だ。

ふむふむ。

よし、今回はここまでとしよう。
次回はそのリソースレコードのタイプについて説明しよう。

はい。

ではまた次回。

了解です。
３分間ネットワーキングでした〜♪