■ サブドメインと権限委譲

大体前回まででDNSの基本的なポイントは終わったわけだ。

ドメイン名前空間、ゾーン、リソースレコード、反復と再帰、ゾーン転送、ですね。

うむうむ。そこらへんだな。
なので、今回はそれ以外のところをまとめて話す。

はい。

まず、前も話して、その時は特に説明しなかったが、このようなドメインがあるとする。

え〜っと、第64回でNSレコードの説明のときに使った図ですよね。

うむ。さて、これは3min.co.jpのドメインなわけだが。
3min.co.jpというドメイン名は、ICANN、というかJPRSにもらったドメイン名なわけだ。

です。

まぁ、インターネットに接続しない内部ネットワークでもいいんだが、どちらにしろその組織の名前があるわけだな。
で、この下にさらにexというドメインを作成した。

FQDNですと、ex.3min.co.jpですね。

そうだ。このex.3min.co.jpを3min.co.jpのサブドメインという。

さぶどめいん…。
なんか、サブネットワークみたいな感じですね。

うむ、その理解は間違っていない。ネットワークをさらに細分化してサブネットワークを作るように、ドメインをさらに細分化してサブドメインを作ることが可能だ。

ふむふむ。

ICANNからもらったIPアドレスのホスト部をそのネットワークの管理者が自由にサブネット化していくように、サブドメインも自由に作成できる。

ん〜っと。さっきの図だと１つだけですけど、いくつも作成できるんですね？

そうだ。例えば、3min.co.jpの下に3つのサブドメインを作ってみよう。

3分間ネットワーキングの各講座名にあわせて、ex、sup、comと名づけてみた。
それぞれがwebサーバとメールサーバを持っている。

親元の3min.co.jpにもwebサーバがあるんですね。

うむ。あっても問題ない。FQDNにすれば違う名前になるからな。
そして、サブドメインを管理するネームサーバがそれぞれ必要になる。

各ネームサーバは自分の下のホスト達を管理する。つまり、3min.co.jpのネームサーバからその一部の管理を任されたわけだ。これを権限委譲という。

ん〜っと。本来ならば3min.co.jpのネームサーバが3min.co.jpドメイン内の全ホストを管理する？

そうだ。

それをサブドメイン化して、それぞれのサブドメインのネームサーバがそこを管理する？

そういうことだ。管理の権限を委譲したわけだな。管理の権限を委譲したので、サブドメイン内のホストについては親ドメインのネームサーバは一切関わらない。

ははぁ。…それってどっかで聞き覚えがあるんですけど？

いいぞ、ネット君。親ドメインは子ドメインのことは知らない。自分のすぐ下しか管理しない。第63回のゾーンで説明したな。

でも、それってドメイン名前空間全体の話じゃないんですか？

うむ、つまり、例えば3min.co.jpというのは、co.jpドメインのサブドメイン、co.jpドメインはjpドメインのサブドメインなのだよ。

そうなんですか？

そうなのだ。つまりDNSというシステムは権限を委譲することによってデータを分散して保有しているのだよ。

それぞれが自分の下のドメインに管理権限を委譲して、分散型データベースを作り上げる。なるほど。

■ 逆引き

さて、次の話をしよう。
ネット君、ドメイン名からIPアドレスを調べるのが通常のDNSだったな。ではIPアドレスからドメイン名を調べるのは？

逆引きでしたよね。
なんかPTRレコードってのを使うとか。

うむ。まず覚えておいて欲しいのは、正引きと逆引きではドメイン名前空間の使うところが違うということだ。

違う？ じゃあ、別のドメイン名前空間が存在するってことですか？

同じドメイン名前空間だが、特殊なドメイン名が使われている。
図でしめそう。

arpa？ in-addr？

TLDがarpa、SLDがin-addrのドメインが逆引き用ドメインになる。

つまり、「なんとか.in-addr.arpa」ってのは逆引き用のドメイン名ってことですか？

そういうことだな。そしてそのドメイン名はIPアドレスを逆に書いたものになる。例えばこの「Roads to Node」がある「www5e.biglobe.ne.jp」のIPアドレスは「61.193.0.66」だが、逆引き用のドメイン名はこうなる。

さて、これを普通のドメイン名だと考えた場合、どういう意味だね、ネット君？

ふつーのどめいんめい？
普通じゃないですよ、これ。

そんな事は言われんでもわかっとる。
例えば、「www5e.biglobe.ne.jp」はどういう意味だった？

jpドメイン内、neドメイン内、biglobeドメイン内のwww5eホスト、です。

それと同様に、66.0.193.61.in-addr.arpaを考えると？

arpaドメイン内、in-addrドメイン内、61ドメイン内、193ドメイン内、0ドメイン内の66ホスト？

そうだ。これは何を意味する？
ネームサーバとドメインの関係から考えると？

ネームサーバとドメインの関係？ ドメインにはネームサーバがあります。
…arpaドメインとか、in-addrドメインとか、61ドメインにもネームサーバがある？

そういうことだ。つまり正引きとは違うネームサーバが存在するということだな。

ははぁ。ネームサーバが一杯必要なんですねぇ。

まぁ、多くの場合は通常のネームサーバが兼務しているがな。
つまり、２つのゾーンを兼務しているネームサーバってことだな。

正引きを管理するため、Aレコードをリソースレコードとして保有していたように、逆引きを管理するネームサーバはPTRレコードを保有する。上の図の例の場合、まず正引き用のAレコードがこう。

一方、逆引き用がこうなる。

名前は「10」とか「11」とかなんですね。

これでもわかるからな。1.168.192.in-addr.arpaドメイン内の10というホストのFQDNは「10.1.168.192.in-addr.arpa」になるからな。
別に「10.1.168.192.in-addr.arpa PTR IN www.3min.co.jp」と書いてもいい。

ははぁ。

もちろん、まったく違うゾーンを持つのだからSOAレコードやNSレコードも別に持つ必要があることを忘れないように。
さて、この逆引き問い合わせだが、基本的には正引きと一緒の動きをする。

正引きと同じということは、反復問い合わせとか、再帰問い合わせとか？

そういうことだ。違いがあるとすれば、問い合わせるリソースレコードがPTRレコードというところだな。

ほんとだ、あまり変わらない。

うむ、IPアドレスというドメイン名とは違うものも、in-addr.arpaというドメイン名に変換して、通常のDNS問い合わせで可能にしているということだな。

ははぁ。無理矢理、通常のDNSで可能にしちゃってるというわけですか。

無理矢理ってわけではないが。
ポイントは逆引き用に別のゾーンを用意しているということだ。

わざわざ逆引き用に用意するわけですね。

うむ。ただし、必ず用意しなければならないというわけではない、ということを忘れないように。
正引きは必須だが、逆引きは任意だからな。

■ DNS Update

さてさて、最後の話だ。DNSの応用の話をしよう。
ネットワークのインフラ、なくてはならないこのDNSというシステムだが、欠点が存在する。

なんか、博士の話って「欠点がある」ので「こうなった」っていうのが多いですね。

「欠点がある」のだが「どうにもならない」という話の方がいいかね？
ネット君、それはあまりにも身近な話になるぞ。

あまりにも身近？
僕の周りの話ですか？

もうちょっと身近だ。

もうちょっと身近？ じゃ何処だろう？

まぁ、気づかないのならばいい。
ともかくだ、DNSの欠点、わかるかね？

欠点、欠点、……なんだろう？

それは、ゾーン情報の更新が手動で行われるという点だ。ゾーン内に新しいホストや変更があった場合、管理者が手動でゾーン情報を変更しなければならない。

それって欠点なんですか？

まぁ、欠点というほど欠点ではないかもしれん。だが、この点のおかげでできないこともある。
例えばこうだ。

DHCPによりIPアドレスが配布されている。LAN内のAやBのホストから「file.3min.co.jp」にドメイン名でアクセスしたい。どうする？

DNSサーバに「file.3min.co.jp」のIPアドレスを聞きます。

そうなると、file.3min.co.jpはDHCPによりIPアドレスが変化するから、その度に管理者がDNSサーバのゾーン情報を書き換える必要があるわけだ。

そう…なりますね。

もう１つ例をだそう。

ネット君はプロバイダを経由してインターネットに接続されている。通常のサービスを受けているので、接続する度にまたは時間によりプロバイダから受け取るIPアドレスが変化する。私の家からネット君の自宅のパソコンにアクセスするには？

僕の家のパソコンがもらったIPアドレスを使う…。

確かにそれが一番確実だ。だが、アクセスする度にネット君に電話してIPアドレスを聞くのかね？
もっと簡単にドメイン名でアクセスする方法はないのかね？ その場合、変化するIPアドレスにどう対応する？

登録しているネームサーバのゾーン情報を書き換える…。

この２つの例から考えると、管理者が手動でゾーン情報を更新しているのがやはりネックとなる。
さて、解決法はなんだ？

手動でまずいのだから、自動？

そう、つまりゾーン情報の変化に動的に対応するシステムがあればいいわけだな。
これをDNS Updateという。 ▼ link

でぃーえぬえすあっぷでーと。

一般的にはDynamic DNSの名前で知られている。
動きを簡単に説明しよう。

ははぁ。DNS Updateにサーバもクライアントも対応してないと駄目なんですね。

そういうことだ。必ずしもDNS Updateが必要なネームサーバばかりではないからな。

でも、自動更新とかいうわりには、「ユーザが判断して」なんて科白がはいってますけど、この更新ってどういうタイミングで行うものなんですか？

うむ。そうだな。それについては実際例で話したほうがいいだろう。
まず、先ほどのLAN内のホストに対しドメイン名でアクセスしたい場合、これはWindows2000ServerのDNSで実現されている。

Windows2000Serverだけなんですか？

いや、設定次第ではUNIXでもっとも使われているBINDというDNSサーバアプリケーションでも可能だ。
ともかく、Windows2000Serverだとこうなる。

は〜。このDHCPと連動する方式、スマートですよね。

そうだな、これにはDHCPサーバがもちろん対応している必要があるが、かなり効率のいい方式だろう。特にネームサーバがDHCPサーバも兼ねていたりすれば、かなり効率的だ。

なるほど〜。確かに。

もう１つ、プロバイダからもらえるIPアドレスを使ってドメイン名でアクセスしたい場合の実際例だが。
ダイナミックDNSサービスを使うのが一般的だな。 ▼ link

だいなみっくDNSさーびす？ どんなサービスなんですか？

サービス事業者はネームサーバを保有しており、そのネームサーバで登録者のドメイン名とIPアドレスを管理してくれるサービスだ。

ははぁ。つまりネームサーバを貸し出すというか、ダイナミックDNSサービスの事業者のドメインに混ぜてくれるというか、そんな感じなんですね。

そういうことだ。このダイナミックDNSサービス事業者が保有するネームサーバはDNS Updateに対応していて、登録者の要求にしたがってレコードの更新をしてくれる。

なるほどなるほど。要求はどうやって出すんです？

一般的なものは、ダイナミックDNSサービス事業者のWebサイトで更新処理が行える。

Webサイトで？ ということは、Webサイトを見に行って手動で更新するってことですよね。

そうだ。だが、自分のIPアドレスをチェックして、自動で登録してあるダイナミックDNSサービス事業者のネームサーバに更新に行くというソフトウェアもあることにはある。

は〜、便利なツールですね。

有名なものではDiCEというツールがある。 私もこれを使っているな。▼ link

なるほど。

さて、これで一応DNSの話はお終いだ。

長かったですね、DNS。

くどいようだが、インターネットのインフラ、現在のインターネットサービスの根幹を成すサービスだからな。DNSの動作を知っているのと知らないのではインターネットに対する理解度が違う。

ドメイン名がないインターネットって、今は考えられないですからね。

そうだ。DNSは今後も重要な位置を占めていくだろうと予想される。例えIPのバージョンが変わってもだ。
いいか、DNSがわからないのはインターネットがわからんのと同意義だからな。

了解です。

さて、次回からはまた違うプロトコルを説明しよう。

いぇっさ〜。
３分間ネットワーキングでした〜♪