スライド 1

今回は、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ホストを設置したエンジニアでなくても、①日本の企業で②axisnetというドメインの③wwwサーバである、ということが判ります。

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

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

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

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

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

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

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

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

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

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

ukやauドメインの下部にもjpドメインと同様に、co・ne・or・goなどのサブドメインがあります。

co・ne・or・goやcom・net・org・govの下部には団体や企業など組織のドメインがサブドメインとして存在します。

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

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

ドメイン名空間の構造・規則としてトップレベルドメイン　TLDをどっと一つで表します。Unix互換OSのrootをスラッシュ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アドレスの対応を管理しているのではなく、この様にドメインレベルと各ドメインで分散して管理しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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