nslookupで実際のDNSの動作を探ってみよう
WindowsやLinux／UNIXには、「nslookup」というDNSクライアント・コマンドが付属している。普段は隠れてほとんど見えないDNS検索も、このコマンドを使って実際の動作をシミュレーションすることができる。ここでは、「www.atmarkit.co.jp」のIPアドレスをどのように見つけているか、実際に試して確認してみよう。
前回説明したDNS検索のフローを、もう一度思い出してほしい。DNS検索では、まずルート・ネーム・サーバをスタート・ポイントにして始める必要がある。そのためには、このルート・ネーム・サーバのIPアドレスなどを知らなければならない。
一般に、多くの「フルサービス・リゾルバ」DNSサーバの起動時に必要とするのが「ルート・キャッシュ」の設定だ。これは、ルート・ネーム・サーバの一覧表である。例えばBINDであれば、「named.root」ファイルや「named.cache」ファイルとして設定しておかなければならない。ルート・キャッシュはあまり頻繁に内容が変更されることはないが、InterNICのWebページに使用すべき一覧が用意されているので、定期的に更新する方がよい。
一覧を見てもらうと分かるが、実はルート・ネーム・サーバは1台だけではない＊3。現在は13台用意されている。これは、負荷分散とともに障害時対策のためで、その多くは米国に配置されているが、全世界の数カ所にも分散配置されている。日本にもWIDE（Widely Integrated Distributed Environment：慶応義塾大学などを中心に設立された日本のインターネット学究系団体）プロジェクトで1台を運用中だ。保持している情報は完全に同じなので、どれを利用してもよい。通常はランダムに選択される。
＊3すなわちルート・ネーム・サーバ（に限らない）は、いわゆるプライマリ・サーバとセカンダリ・サーバなど、複数台で運用されている。プライマリとセカンダリの差異については、本連載の第3回にて説明しよう
さて、では実際にnslookupコマンドを実行してみよう。ここではWindowsを例に説明するが、ほかのOSでも要領は変わらない。
C:\>nslookup Default Server: ns.xxxxx.ad.jp Address: 202.XXX.XXX.XXX >
nslookupコマンドは対話型コマンドとしても使用できるので、引数なしで起動すると、入力プロンプト待ちになる。この後、さまざまなコマンドやオプションを指定して使用する。通常は、皆さんのPCで「DNSサーバ」として設定されているホスト（つまり「フルサービス・リゾルバ」）が「Default Server」として表示されるだろう。これは、DNS要求の送信先DNSサーバだ。ここで「www.atmarkit.co.jp」と入力しても単純にIPアドレスが得られるが、これは実際にはフルサービス・リゾルバが代わりにすべての検索を行っているだけだ。
それではつまらないので、ここではフルサービス・リゾルバが普段行っている検索をnslookupでシミュレーションしてみよう。
> set norecurse > set type=a >
上記はオプションの設定だ。検索方法で「リカーシブ（再帰検索）を使わない」、すなわちイテレイティブ検索(反復検索)に変更する。厳密に、そのDNSサーバが持っているゾーン情報だけに限定して、それらゾーン情報だけを純粋にたどってみる。また今回は必須ではないのだが、typeオプションでAレコードの検索のみを行うことを明示的に指定しておこう。
まず、ルートから検索を開始する。Default Serverをルート・ネーム・サーバに変更しよう。ルート・ネーム・サーバのIPアドレスは、先ほどの一覧から適当に選べばよい。ここでは、ネットワーク的に最も近い場所にあるWIDEのサーバを選択する。
> server 202.12.27.33 Default Server: m.root-servers.net Address: 202.12.27.33
このサーバで検索を行おう。「www.atmarkit.co.jp」と入力すると、DNSサーバは自動的に自身が返答できる情報を判断して。jpドメインのDNSサーバ情報を返答してくれる。
> www.atmarkit.co.jp
Server: m.root-servers.net
Address: 202.12.27.33
Name: jp.
Served by:
- DNS0.SPIN.AD.jp
165.76.0.98
jp
- NS-JP.SINET.AD.jp
150.100.2.3
jp
- NS.WIDE.AD.jp
203.178.136.63
jp
- NS0.IIJ.AD.jp
202.232.2.34
jp
- NS0.NIC.AD.jp
202.12.30.131
jp
- NS-JP.NIC.AD.jp
61.120.151.100
jp
>
これが、jpドメインのDNSサーバ一覧だ。やはり複数台で運用されているのが分かる。また、JPNICだけではなく、ほかの大手プロバイダも運用に協力しているのが分かるだろう。インターネットはこうした多くの組織による協力の下、運用されている。おかげで、わたしたちは苦労なく利用できているというわけだ。
jpドメインのDNSサーバが分かったので、次はDefault ServerをjpドメインDNSサーバへと切り替える。やはり、指定するサーバはどれでもよい。ここではJPNICを選ぼう。そして、「www.atmarkit.co.jp」を指定して問い合わせる。
> server 61.120.151.100
Default Server: ns-jp.nic.ad.jp
Address: 61.120.151.100
Aliases: 100.151.120.61.in-addr.arpa
> www.atmarkit.co.jp
Server: ns-jp.nic.ad.jp
Address: 61.120.151.100
Aliases: 100.151.120.61.in-addr.arpa
Name: www.atmarkit.co.jp
Served by:
- dns1.i2ts.ne.jp
211.4.249.193
atmarkit.co.jp
- dns2.i2ts.ne.jp
211.4.249.194
atmarkit.co.jp
- ns1.i2ts.ne.jp
211.4.249.195
atmarkit.co.jp
>
おや？ と思われただろうか。「co.jp」ドメインのDNSサーバではなく、「atmarkit.co.jp」ドメインのDNSサーバ一覧がすでに入手できてしまった。実は、これは運用依存なのだが、co.jpドメインDNSサーバはjpドメインDNSサーバと同じホストなのだ。つまり、同じサーバで「jp」と「co.jp」のゾーン情報を管理している。現状では、分けて運用するほどの負荷や手間はないという判断なのだろう。
試しに、jpドメインDNSサーバで検索レコードをNSに指定して、jpドメインとco.jpドメインのDNSサーバ情報を検索してみた。まったく同じホストを示しているのが分かる。
> set type=ns > jp Server: [61.120.151.100] Address: 61.120.151.100 jp nameserver = ns.wide.ad.jp jp nameserver = ns0.iij.ad.jp jp nameserver = dns0.spin.ad.jp jp nameserver = ns-jp.sinet.ad.jp jp nameserver = ns-jp.nic.ad.jp jp nameserver = ns0.nic.ad.jp ns.wide.ad.jp AAAA IPv6 address = 2001:200:0:4400:0:0:0:1 ns.wide.ad.jp internet address = 203.178.136.63 ns0.iij.ad.jp AAAA IPv6 address = 2001:240:0:0:0:0:0:53 ns0.iij.ad.jp internet address = 202.232.2.34 dns0.spin.ad.jp internet address = 165.76.0.98 ns-jp.sinet.ad.jp internet address = 150.100.2.3 ns-jp.nic.ad.jp internet address = 61.120.151.100 ns0.nic.ad.jp internet address = 202.12.30.131 > co.jp Server: [61.120.151.100] Address: 61.120.151.100 co.jp nameserver = dns0.spin.ad.jp co.jp nameserver = ns-jp.sinet.ad.jp co.jp nameserver = ns-jp.nic.ad.jp co.jp nameserver = ns0.nic.ad.jp co.jp nameserver = ns.wide.ad.jp co.jp nameserver = ns0.iij.ad.jp dns0.spin.ad.jp internet address = 165.76.0.98 ns-jp.sinet.ad.jp internet address = 150.100.2.3 ns-jp.nic.ad.jp internet address = 61.120.151.100 ns0.nic.ad.jp internet address = 202.12.30.131 ns.wide.ad.jp AAAA IPv6 address = 2001:200:0:4400:0:0:0:1 ns.wide.ad.jp internet address = 203.178.136.63 ns0.iij.ad.jp AAAA IPv6 address = 2001:240:0:0:0:0:0:53 ns0.iij.ad.jp internet address = 202.232.2.34 >
DNSサーバとしては、自身が知っている中で最も階層が深い「atmarkit.co.jp」を返答してきたというわけだ。ちょっとしたショートカットだ。
ようやく、「atmarkit.co.jp」ドメインのDNSサーバが判明した。これまでと同様に、Default Serverをatmarkit.co.jpドメインのDNSサーバへ切り替えて、最後の検索を行おう。
> server 211.4.249.195 249.4.211.in-addr.arpa nameserver = dns10.dion.ne.jp 249.4.211.in-addr.arpa nameserver = ns1.neweb.ne.jp 249.4.211.in-addr.arpa nameserver = ns2.neweb.ne.jp 249.4.211.in-addr.arpa nameserver = ns3.neweb.ne.jp dns10.dion.ne.jp internet address = 211.5.1.217 ns1.neweb.ne.jp internet address = 203.140.129.2 ns2.neweb.ne.jp internet address = 203.140.129.3 ns3.neweb.ne.jp internet address = 203.140.129.4 Default Server: [211.4.249.195] Address: 211.4.249.195 > www.atmarkit.co.jp Server: [211.4.249.195] Address: 211.4.249.195 Name: atmarkit-www.atmarkit.co.jp Address: 211.4.251.193 Aliases: www.atmarkit.co.jp >
これで、最終的にIPアドレスは「211.4.251.193」だと判明した。また、「www.atmarkit.co.jp」は実はエイリアス（CNAMEレコード）で、実際のAレコードでの名前は「atmarkit-www.atmarkit.co.jp」だということも分かる。ここでは正引きを試してみたが、もちろん逆引きも同じ要領で検索することができる。いかがだろう。興味があれば、ぜひ自社のWebサーバなどがどのように登録されているか、確認してみてはどうだろうか？
ところで、こうした検索が毎回行われているのかといえば、実はそうではない。フルサービス・リゾルバとして動作するDNSサーバは、通常、「キャッシュ・サーバ」としても動作しており、キャッシュを再利用することで毎回の検索を回避していることが多い。最終目的となるレコードを保持していればそれを回答すればよいし、またco.jpドメインDNSサーバ名をすでにキャッシュしていれば、次回はわざわざルート・ネーム・サーバから再び検索しなくとも、co.jpドメインDNSサーバから始めることもできる。キャッシュ・サーバについては、次回で詳しく述べよう。
もう1つのドメイン・ツリー
ドメイン・ツリーの概念については、すでに理解していただけたと思う。この概念を注意深く考えると、「すべてのリゾルバがルート・ネーム・サーバを唯一のスタート・ポイントとしているからこそ、まったく同じDNS情報＝名前空間を共有できる」という点に気付いていただけることだろう。
では、この唯一のルート・ネーム・サーバがまったく別のドメイン・ツリーを示すものに変わってしまったら？ そのときわれわれは、まったく別のDNS空間を見ることになるはずだ。実はこの発想を実現しようとしている企業がある。それがNew.net社で、実は親会社は「.tv」ドメインを買い取ったdotTV社と同じIdealab社だ。
彼らが2001年春から始めたのは、まったく別の新しいTLDの提供だった。New.net社のWebサイトを見ていただくと一目瞭然だが、「.shop」「.game」「.sport」「.mp3」など、現在のTLDからは考えられない名称のものを、現在では28ドメイン提供中だ。
この発想は、珍しそうなccTLDを買い取るというのとはまったく別次元の話だ。特にICANNやNICなど、現在の「正規」ドメイン管理団体（と見なされている団体）は、こうした動きに激しく反発している。このような商業主義によるドメイン・ツリーの乱立は、インターネットの根本を揺るがす事態だとの指摘である。
もっとも、New.net社のTLDがすぐに現在のDNSに影響するのかといえば、そう簡単な話ではない。当然、各DNSサーバ（リゾルバ）が、ルート・ネーム・サーバとしてNew.netのサーバを指定したり、クライアントの設定を変更するなどの作業が行われない限り、ユーザーが使用できることはないからだ。インターネット・コミュニティが積極的に受け入れない限り何の意味もなくなる、というのがNew.netにとっての最大の弱点だ。
商魂たくましいと片付けるのは簡単だ。だが、こうしたビジネスが起こり得る根本は、1つにはICANNが決定した新規gTLDが、マーケティング的な観点からは魅力に乏しすぎたという面もあるようだ。では、どのようなTLDを認めるべきかという問題も、また簡単に答えが出せるには至っていない。DNSはインターネットの根源であり、ICANNなどの立場からは、安直な変更を導くわけにもいかないだろうからだ。
ドメインとマーケティング的価値の問題は、これもまた商業サービス基盤へと広がったインターネットの宿命なのだろう。
Copyright © ITmedia, Inc. All Rights Reserved.