今回は、Domain Name Serviceについて学びましょう。

 


 

 

一般的に利用者はホスト名+ドメイン名からなるFQDNを利用して通信を行います。

 

それに対し、コンピュータ同士の通信はIPアドレスで行われます。

 

そこで、FQDN IPアドレスに、IPアドレスをFQDNに 変換するという仕組みが必要となります。

 

 

 


 

 

この、FQDN IPアドレスに変換する、逆に、IPアドレスをFQDNに変換する、という役目をDomain Name Service DNSが担っています。

 

TCP/IPネットワークで、 ホスト名とIPアドレスの対応を解決する場合に DNSは必要なシステムとなっています。

 

DNSは、

ホスト名とIPアドレスの対応表を持つDNSサーバと、

名前解決・IPアドレス解決をDNSサーバに頼るクライアント=リゾルバ

からなるクライアントサーバシステムです。

 

DNSサーバの保持しているホスト名とIPアドレスの対応表は一種のデータベースです。このホスト名とIPアドレスの対応表を格納しているファイルをゾーンファイルと呼びます。


 

 

ホスト名からIPアドレスの対応を解決することを正引きと言います。

 

IPアドレスからホスト名の対応を解決することを逆引きと言います。

 

 

 


 

 

正引きゾーンで利用する、ホスト名とIPアドレスの対応エントリをAレコードと言います。

 

逆引きゾーンで利用する、IPアドレスとホスト名の対応エントリPTRレコードといいます。

 

 


 

 

先ほど説明したようにホスト名+ドメイン名からなる文字列をFQDNと呼びます。FQDNを利用する利点に、

              利用者にわかりやすい

              利用者が覚えやすい

というメリットがあげられます。

 

組織名や団体の名称を連想できる文字列をドメイン名として利用できますし、

提供しているサービスや役目を連想できる文字列をホスト名として利用できます。

例えば www.axisnet.co.jp      という文字列の場合、このIPホストを設置したエンジニアでなくても、@日本の企業でAaxisnetというドメインのBwwwサーバである、ということが判ります。

現在、このホストが持つIPアドレス203.138.214.11ではこのような便利な意味付けができません。

 

私たちは日常、インターネット上の任意のサーバと通信するときにURLという形でFQDNを指定しています。


 

 

 TCP/IPを利用する閉じられた小さなネットワークで、名前解決のためにDNSを利用する場合、そのDNSサーバにすべてのホストを登録して運用することは可能です。

 

 しかし、インターネットの場合、サーバに限定しても、日々刻々と変わるホスト名をすべて登録することは不可能です。

 

 そこでインターネット上ではドメイン名を階層化し、それぞれのドメイン毎にDNSサーバを用意し、

 「自分の知らない名前解決は知っているサーバに任せる」

というシステムを用意しました。

 

 各々のDNSサーバが管理するドメイン名空間の一部をゾーンと呼びます。各々のDNSサーバは自分の管理しているドメインのホスト名とIPアドレスの対応表を保持します。このホスト名とIPアドレスの対応表を格納しているファイルをゾーンファイルと呼びます。

 


 

 

階層化したドメインの構造をドメイン名空間 Domain Name Spaceと呼びます。

 

ドメイン名空間の階層構造はご覧の図のようになっています。

 

ukauドメインの下部にもjpドメインと同様に、coneorgoなどのサブドメインがあります。

 

coneorgocomnetorggovの下部には団体や企業など組織のドメインがサブドメインとして存在します。

 

管理している組織が同じということは多々ありますが、ツリー構造の枝別れた先で枝が再び合流することはありません。この枝構造(ツリー構造)によってユニークなドメインが特定できるようになっています。

 

例えば、www.google.comwww.google.co.jpはいずれもwwwというホスト名とgoogleというドメイン名が同一ですが、上位ドメインがcomco.jpと異なることで、別なドメインに属するホストとして区別可能になります。


 

 

ドメイン名空間の構造・規則としてトップレベルドメイン TLDをどっと一つで表します。Unix互換OSrootをスラッシュ1つで表すのに似ていますね。

 

WebブラウザにURLを入力する時には、FQDNとして入力する文字列の最後にこのドットの入力は省略可能です。一部のDNSサーバアプリケーションやnslookupコマンドでは省略できないこともあります。

 

TLDの次に国・地域別表示のドメインが来ます。このレベルをGeneric Top Level Domain GTLDといいます。日本は.jp、英国はuk、フランスはfr、アメリカ合衆国はusです。

 

しかし、インターネット発祥の地であるアメリカ合衆国は今はまだ国表示のドメインusの利用があまりありません。TLDの次にcom net org govといった組織種のドメインが来ます。国ごとのドメイン管理が行われる以前はこの方法でした。

 

gTLDの次にco ne or go組織種のドメインが来ます。組織種のドメインは通常2文字ですが、アメリカ合衆国や台湾のように3文字のところもあります。


 

 

ドメイン名空間にはIPアドレスからFQDNを解決する、逆引き用のドメインも用意してあります。

 

IPv4アドレスは、32ビットをオクテットと呼ぶ8ビットづつの4ブロックに分割して表記しています。そこで、最大6階層でホストの属するドメインを特定できます。

 

IPアドレス 210.155.152.132のホストは152. 155. 210.in-addr.arap.ドメインになります。

 

 


 

 

実際にLANで使用しいるDNSサーバでドメイン名空間の階層構造が確認できます。

 

DNSサーバは管理しているネットーク上のクライアントホストから、インターネット上など自身が管理していないネットワーク上のホストを対象とする名前解決のリクエストの名前解決に成功すると、一定時間キャッシュとして成功エントリを保持します。この解決キャッシュはあたかもファイルのディレクトリと同様にツリーと構造として確認できます。

 

トップレベルドメインを表すドットの階層を選択すると、トップレベルドメインを管理している世界で13台のDNSサーバのエントリが確認できます。このトップレベルドメインを管理しているDNSサーバをrootサーバといいます。

 

rootサーバはトップレベルドメインの情報のみを持ちます。gTLDなど下の階層の情報はそのドメインのサーバに委任します。同様に更に下の階層でも委任が行われています。

 例1 rootサーバはjpドメインの情報をjpドメインを管理しているサーバに委任する


 例2 jpサーバはcoドメインの情報をcoドメインを管理しているサーバに委任する

 

DNSサーバによる名前解決は一つもしくは数台のサーバでインターネット上の全てのホスト名とIPアドレスの対応を管理しているのではなく、この様にドメインレベルと各ドメインで分散して管理しています。


 

 

では具体的に分散管理のプロセスを見ていきましょう。

 

企業組織、もしくは、家庭のPCwww.atmarkit.co.jpwebページにアクセスする事を想定します。

 

ユーザーが操作しているPCwww.atmarkit.co.jpというホストのIPアドレスを、ユーザ組織内のDNSサーバ、もしくは加入しているISPDNSサーバに問い合わせます。

 

Windows PCの場合、ipconfig /allコマンドで問い合わせ先のDNSサーバのIPアドレスを確認できます。

 

また、この問い合わせという動作をクエリとも言います。


 

 

ユーザ組織内のDNSサーバ、もしくは加入しているISPDNSサーバは、rootサーバに対してwww.atmarkit.co.jpIPアドレスを問い合わせます。

 

Rootサーバはクエリを解釈して、jpドメイン(jpゾーン)を管理しているDNSサーバにクエリするようにjpドメイン(jpゾーン)を管理しているDNSサーバのアドレスを返します。

 


 

 

そこでユーザ組織内のDNSサーバ、もしくはISPDNSサーバは、jpソーンのDNSサーバへwww.atmarkit.co.jpIPアドレスを問い合わせます。

 

Jpソーンサーバはクエリを解釈して、co.jpドメイン(co.jpゾーン)を管理しているDNSサーバにクエリするようにco.jpドメイン(co.jpゾーン)を管理しているDNSサーバのアドレスを返します。


 

 

そこでユーザ組織内のDNSサーバ、もしくはISPDNSサーバは、co.jpソーンのDNSサーバへwww.atmarkit.co.jpIPアドレスを問い合わせます。

 

co.jpソーンサーバはクエリを解釈して、atmarkit.co.jpドメイン(atmarkit.co.jpゾーン)を管理しているDNSサーバにクエリするようにatmarkit.co.jpドメイン(atmarkit.co.jpゾーン)を管理しているDNSサーバのアドレスを返します。

 


 

 

そこでユーザ組織内のDNSサーバ、もしくはISPDNSサーバは、atmarkit.co.jpソーンのDNSサーバへwww.atmarkit.co.jpIPアドレスを問い合わせます。

 

atmarkit.co.jpソーンサーバはクエリを解釈して、www.atmarkit.co.jpIPアドレスを返します。

 

 


 

 

ユーザ組織内のDNSサーバ、もしくはISPDNSサーバは、回答を得たのでwww.atmarkit.co.jpIPアドレスを問い合わせ元のクライアントに返します。

 


 

 

クライアントPCは回答として得たIPアドレスを使用してwww.atmarkit.co.jpと通信します。

 


 

 

クライアントPCから直接クエリを受けるユーザ組織内・もしくはISPDNSサーバをローカルDNSサーバと呼ぶ事も有ります。

 

ローカルDNSサーバは自分が管理しているゾーンの情報を管理しているのはもちろんですが、外部のサーバで解決したクエリ結果を一定時間キャッシュとして保持します。

 

キャッシュとして保持している間に再びクライアントPCからクエリを受けると、この時は外部サーバへクエリを送信せずにキャッシュ情報を利用して回答します。ネットワークのトラフィック減・外部のDNSサーバに対する負荷減というメリットがあります。特に13台のみで稼動しているrootサーバは全インターネットのクエリを処理するので負荷が高い。

 

デメリットとして、キャッシュを保持している間に対象のホストがIPアドレス変更してしまうと、そのホストへのアクセスに失敗してしまう事があります。

 

悪意を持ったサーバへ誘導するためにDNSキャッシュに不正なクエリ結果(正規のIPアドレスではないIPアドレス)を送り込むDNSポイズンキャッシュという攻撃方法があることを覚えておきましょう。


 

 

IPアドレスからホスト名を解決する逆引きもキャッシュしているのが確認できます。

 

正引きゾーンキャッシュと逆引きゾーンキャッシュでDNS名前空間がドットが表すルートを起点とした階層構造になっている事もわかります。


 

 

nslookupコマンドを利用すると名前解決のプロセスが体験できます。(実際には名前解決ではなくDNSサーバの持つ情報の検索となります。)

 

引数をつけずにnslookupコマンドを起動します。nslookupのシェルでプロンプト表示になります。

 

serverコマンドで情報検索に利用するサーバをrootサーバに設定します。先に説明したようにルートサーバは13台存在します。どれに設定してもかまいません。例ではm.root-servers.netにしています。

 

ルートサーバもnetドメインが管理するroot-servers.netというドメインのホストです。今まで説明してきた教科書的原則では

              まずルートサーバにクエリを出す

              次にnetドメインのサーバにクエリを出す

              次にroot-servers.netドメインのサーバにクエリを出す

となりますが、これでは「ルートサーバの名前解決にルートサーバを利用する」という矛盾が生じます。そこで一般的なDNSサーバアプリケーションにはルートサーバのみローカルで名前解決できるように、13台のルートサーバのホスト名とIPアドレスの情報をはじめから用意しています。


 

 

www.atmarkit.co.jpというホスト名の文字列を入力すると、DNSサーバの持つ情報の中から対応する回答が表示されます。

 

今回は、

複数のDNSサーバがwww.atmarkit.co.jpの名前解決が出来る

という事が判りました。


 

 

得られた回答の中からひとつのサーバを選んでserverコマンドで情報検索に利用するサーバを設定します。

 

次にホスト名www.atmarkit.co.jpをクエリします。

 

今回も、

複数のDNSサーバがwww.atmarkit.co.jpの名前解決が出来る

という事が判ります。

 

また、atmarkit.co.jpを管理しているDNSサーバを回答してきたことからF.DNS.jpjpゾーンとco.jpゾーンの管理を兼ねている事が判ります。

 


 

 

得られた回答の中からひとつのサーバを選んでserverコマンドで情報検索に利用するサーバを設定します。

 

次にホスト名www.atmarkit.co.jpをクエリします。

 

IPアドレスが返されました。

 

 


 

 

クライアントマシンでEtheralなどのプロトコルアナライザを起動し、トラフィックをキャプチャすると、

              ローカルDNSサーバに名前解決クエリを送信し

              対応するIPアドレスを得てから

              IPアドレス同士で通信している

事が判ります。

 

 


 

 

また名前解決クエリとクエリ結果(レスポンス)のパケットを見ると、DNSサーバのUDPポート53番を利用している事がわかります。

 

DNSはサーバ側がUDP53番ポートを使用し、クライアント側はUDPのランダムポートをし使用するapplicationということが判ります。

 

UDPは再送やエラー制御という仕組みを持たない信頼性の無いプロトコルです。反面オーバーヘッドが少ない通信を提供できます。DNSは名前解決という役目から身のこなしの軽いプロトコルで実装されました。

 

 

 


 

 

DNSサーバ上でnetstatコマンドを実行するとUDPポート53番でリッスン(待ち受け)している様子がわかります。

 

 


 

 

DNSサーバは名前解決以外にも、

IP電話利用時のIPアドレスと電話番号の対応

・任意ドメインでのmailサーバの特定

の役目でも利用されています。

 

 

本講座で既に、DNSパケットはUDPである、ということを学んでいますが、ここでTCPDNSパケットについて触れておきます。

 

DNSの仕様では,クエリも応答もデータを512バイト以下にして一つのUDPパケットで運びます。しかし

              ひとつのホスト名に複数のIPアドレスを持つ場合や

              ひとつのIPアドレスに複数のホスト名を持つ場合

              IPv6アドレスとIPv4アドレスの双方を持つ場合

              長いホスト名の場合

に、DNSサーバーが512バイトを超えるデータをやりとりすることがあります。このようなときは,UDPの代わりにTCPを使い512バイトを超えるデータを扱います。