Cisco Network Registrar ユーザー ガイド 7.0
ドメイン ネーム システムの概要
ドメイン ネーム システムの概要
発行日;2012/01/16 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

ドメイン ネーム システムの概要

DNS の仕組み

ドメイン

ExampleCo 社のアドレスの検索

ドメインの確立

ドメインとゾーンの違い

ネームサーバ

逆引きネームサーバ

ハイ アベイラビリティ DNS

ドメイン ネーム システムの概要

ドメイン ネーム システム(DNS)は、増え続けるインターネット ユーザに対応します。DNS は、コンピュータが互いに通信できるように、www.cisco.com のような URL を 192.168.40.0 のような IP アドレス(または拡張された IPv6 アドレス)に変換します。DNS を使用することにより、ワールド ワイド ウェブ(WWW)などのインターネット アプリケーションを簡単に使えるようになります。DNS のプロセスは、相手の名前さえわかっていれば電話番号を覚えていなくても自動ダイヤルで電話をかけられるようなものです。

DNS の仕組み

DNS の仕組みについて理解するために、ごく普通のユーザである John がコンピュータにログインする場合を想定します。John は ExampleCo という会社の Web サイトを見るために Web ブラウザを起動しました(図14-1を参照)。Web サイトの名前である http://www.example.com を入力します。

1. John のワークステーションが、www.example.com の IP アドレスについての要求を DNS サーバに送ります。

2. DNS サーバはデータベースをチェックし、www.example.com が 192.168.1.4 という IP アドレスに対応していることを検出します。

3. サーバは、このアドレスを John のブラウザに返します。

4. ブラウザは、その IP アドレスを使用して Web サイトの場所を特定します。

5. ブラウザは、Web サイトを John のモニタに表示します。

図14-1 ドメイン名とアドレス

 

ドメイン

John が ExampleCo 社の Web サイトにアクセスできるのは、彼の DNS サーバが www.example.com の IP アドレスを知っているからです。サーバは、ドメイン ネームスペースでこのアドレスを検索しました。DNS はツリー構造として設計されており、各名前付きドメインはツリー内のノードです。ツリーの最上位の階層のノードは DNS ルート ドメイン(.)であり、その下に .com、.edu、.gov、.mil などのサブドメインがあります(図14-2を参照)。

図14-2 ドメイン ネーム システムの階層

 

完全修飾ドメイン名(FQDN)は、ルートから始まるすべてのネットワーク ドメインのドットで区切られた文字列です。この名前は、インターネット上の各ホストに対して一意になっています。前述の例で、ドメインの FQDN である example.com は、このドメインが example で、親ドメインは .com、そのルート ドメインは「.」であることを示しています。

ExampleCo 社のアドレスの検索

John のワークステーションが www.example.com という Web サイトの IP アドレスを要求します(図14-3を参照)。

図14-3 DNS 階層名の検索

 

1. ローカル DNS サーバがデータベースで www.example.com ドメインを検索しますが見つけられません。これは、サーバがこのドメインに対する権限を持っていないことを示しています。

2. サーバは、最上位の階層(ルート)のドメインである「.」(ドット)に対する権限を持つルート ネームサーバを要求します。

3. ルート ネームサーバは、そのサブドメインについての情報を持つ .com ドメインのネームサーバにクエリーを転送します。

4. .com ネームサーバは、example.com が .com ネームサーバのサブドメインの 1 つであると判断し、そのサーバのアドレスを返します。

5. ローカル サーバは、example.com のネームサーバに www.example.com の場所をたずねます。

6. example.com ネームサーバは、アドレスが 192.168.1.4 であると応答します。

7. ローカル サーバは、このアドレスを John の Web ブラウザに送ります。

ドメインの確立

ExampleCo 社の Web サイトに John がアクセスできたのは、同社がドメインを公認のドメイン登録機関に登録していたからです。また、ExampleCo 社はドメイン名を .com サーバのデータベースに登録し、IP アドレスの範囲を定義するネットワーク番号も要求しました。この例におけるネットワーク番号は 192.168.1.0 であり、これは 192.168.1.1 から 192.168.1.255 の範囲のすべてのアドレスが含まれます。オクテットと呼ばれるアドレス フィールドのそれぞれには、0 ~ 256(2 8 )の番号だけが設定できます。ただし、0 と 256 の番号は、それぞれネットワーク アドレスとブロードキャスト アドレスに予約されており、ホストには使用されません。

ドメインとゾーンの違い

ドメイン ネームスペースは、「ゾーン」と呼ばれる領域に分割されます。ゾーンは、DNS ツリー内の委任ポイントです。ゾーンには特定のポイントから下のドメインのうち、別のゾーンが権限を持つポイントを除いたドメインがすべて含まれています。

ゾーンには、通常、権限ネームサーバがあり、複数存在することも珍しくありません。組織内では多数のネームサーバを持つことができますが、インターネットのクライアントはルート ネームサーバが知っているネームサーバしか照会できません。他のネームサーバは、内部クエリーにだけ応答します。

ExampleCo 社は同社のドメインである example.com を登録し、example.com、marketing.example.com、および finance.example.com という 3 つのゾーンを確立しました。そして、marketing.example.com および finance.example.com に対する権限を社内の Marketing グループと Finance グループにある各 DNS サーバに委任しました。marketing.example.com 内のホストに関する照会を example.com に実行すると、example.com は marketing.example.com ネームサーバにクエリーを送ります。

図14-4では、example.com ドメインに 3 つのゾーンが含まれており、example.com ゾーンは自身に対する権限だけを持っています。

図14-4 委任したサブドメインを持つ example.com

 

ExampleCo 社は、権限をサブドメインに委任しない方法も選択できました。その場合、example.com ドメインはサブドメインの marketing および finance に対する権限を持つゾーンです。example.com サーバは、marketing および finance に関する外部のクエリーにすべて応答します。

Network Registrar を使用してゾーンの設定を開始すると、各ゾーンに対してネームサーバを設定する必要があります。各ゾーンにはプライマリ サーバが 1 つずつあり、これがゾーンの内容をローカル設定データベースからロードします。また、各ゾーンにはセカンダリ サーバをいくつでも含むことができます。セカンダリ サーバはプライマリ サーバからデータを取り出すことによってゾーンの内容をロードします。図14-5は、セカンダリ サーバを 1 つ使用する構成を示しています。

図14-5 ゾーンのプライマリ サーバとセカンダリ サーバ

 

ネームサーバ

DNS はクライアント/サーバ モデルに基づいています。このモデルでは、ネームサーバが DNS データベースの一部分に関するデータを持ち、ネットワークを介してネームサーバに照会を行うクライアントにこの情報を提供します。ネームサーバは、物理ホスト上で実行されるプログラムであり、ゾーンに関するデータを格納します。ドメインの管理者は、ゾーン内のホストを記述するすべてのリソース レコード(RR)のデータベースを持つネームサーバを設定します(図14-6を参照)。DNS RR の詳細については、 付録A「リソース レコード」 を参照してください。

図14-6 クライアント/サーバ名前解決

 

DNS サーバは名前からアドレスへの変換、つまり名前解決を提供します。これらは、完全修飾ドメイン名(FQDN)内の情報を解釈してそのアドレスを見つけます。クエリーで要求されているデータがローカル ネームサーバにない場合は、見つかるまで別のネームサーバに問い合せます。ネームサーバでは、ドメイン ネームスペースに関してクエリーから得た情報を継続的にキャッシュしているので、頻繁に要求される名前についてはこのプロセスが迅速化します。

各ゾーンでは、ローカル データベースからゾーンの内容をロードするプライマリ ネームサーバが 1 つと、プライマリ サーバからデータのコピーをロードするセカンダリ サーバがいくつか必要です(図14-7を参照)。プライマリ サーバからセカンダリ サーバを更新するプロセスを、「ゾーン転送」といいます。

セカンダリ ネームサーバがプライマリ サーバの一種のバックアップとして動作する場合でも、両方のタイプのサーバはいずれもゾーンに対する権限を持つことができます。プライマリ ネームサーバもセカンダリ ネームサーバも、クエリーの回答結果として取得した情報からではなく、ゾーンの権限を持つデータベースからゾーン内のホスト名を取得します。クライアントは両方のサーバに名前解決を照会できます。

Network Registrar の DNS ネームサーバを設定するときには、ゾーンごとにそのサーバの役割をプライマリ、セカンダリ、キャッシュ専用のうちから指定します。サーバのタイプはサーバの役割においてのみ意味を持ちます。サーバは、あるゾーンではプライマリ サーバになり、別のゾーンではセカンダリ サーバになることができます。また、プライマリ サーバかセカンダリ サーバのいずれか一方だけになることも、ゾーンを使用しないでキャッシュを使ってクエリーに回答するだけのサーバになることも可能です。

全サーバが、情報をデータの期限満了まで保存しておくキャッシュ サーバといえますが、キャッシュ専用サーバは、いずれのゾーンに対しても権限を持たないサーバを指します。このサーバは内部クエリーに回答し、他の権限サーバに対して情報を要求します。サイトはキャッシュ専用サーバを作成して権限サーバの負荷を軽減することによって、すべてのクエリーを権限サーバに送る必要がなくなります。

図14-7 DNS ゾーン転送

 

サーバの設定については、次の項を参照してください。

プライマリ ネームサーバ:「プライマリ DNS サーバの管理」

セカンダリ サーバ:「セカンダリ サーバの管理」

キャッシュ専用サーバ:「キャッシュ専用 DNS サーバの設定」

逆引きネームサーバ

ここまで説明した DNS サーバは名前からアドレスへの解決を実行します。すべてのデータは名前別にインデックスが付けられているので、サーバはデータベース全体で正しいアドレスを検索することによって、簡単に名前からアドレスへの解決を行うことができます。しかし、コンピュータ ログ ファイルなどの特定の出力を解釈できるアドレスから名前への解決が必要な場合もあります。

しかし、アドレスだけがわかっていてドメイン名を探す場合は、ネームスペース全体を検索する必要があります。DNS は、in-addr.arpa ドメインというアドレスを名前として使用するドメイン ネームスペースをサポートすることにより、この問題を解決します。この逆ゾーンには、ネットワーク番号に基づく各ネットワークのサブドメインがあります。整合性と自然なグループ化を実現するために、ホスト番号の 4 つのオクテットが逆引きされます。

IP アドレスをドメイン名として読み取ると、その名前はリーフからルートという順になって逆順に表示されます。たとえば、ExampleCo 社の example ドメインのネットワーク番号は 192.168.1.0 です。このドメインの逆ゾーンは 1.168.192.in-addr.arpa です。DNS サーバ アドレス(192.168.1.1)しかわからない場合は、逆引きドメインへのクエリーによって example.com にマッピングするホスト エントリ 1.1.168.192.in-addr.arpa が得られます。

図14-8に示すように、逆引きドメインは、Pointer(PTR)RR によって処理されます。

図14-8 逆引きドメイン

 

ハイ アベイラビリティ DNS

ゾーンあたり 1 台のプライマリ DNS サーバしか存在しないことがあるため、プライマリ DNS サーバがダウンした場合に、ダイナミック アップデートが失敗するリスクがあります。このようなアップデートは、プライマリ DNS サーバだけで実行されることがあります。そのため、セカンダリ DNS サーバはアップデートによる変更を記録できません。しかし、変更をプライマリ サーバに転送する必要があります。この問題を解決するために、2 番目のプライマリ サーバをメインのプライマリ サーバの障害に備えるホット スタンバイ サーバにすることができます。これはハイ アベイラビリティ(HA)DNS と呼ばれます( 第18章「ハイ アベイラビリティ DNS サーバの設定」 を参照)。このフェールオーバー構成で、両方のサーバは、それぞれのプライマリ ゾーンおよび関連するアトリビュートが同じになるように同期化する必要があります。Network Registrar は、同期のためのメインとバックアップ、フェールオーバー モードに移行するタイムアウト時間を識別するためにメイン サーバの設定を提供します。