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

Transcription

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

2 の仕組み の仕組み の仕組みについて理解するために ごく普通のユーザである John がコンピュータにログインする場合を想定します John は Co という会社の Web サイトを見るために Web ブラウザを起動しました ( 図 13-1 を参照 ) Web サイトの名前である を入力します 1. John のワークステーションが の IP アドレスについての要求を サーバ に送ります 2. サーバはデータベースをチェックし が という IP アドレス に対応していることを検出します 3. サーバは このアドレスを John のブラウザに返します 4. ブラウザは その IP アドレスを使用して Web サイトの場所を特定します 5. ブラウザは Web サイトを John のモニタに表示します 図 13-1 ドメイン名とアドレス John IP Web

3 ドメイン ドメイン John が Co 社の Web サイトにアクセスできるのは 彼の サーバが の IP アドレスを知っているからです サーバは ドメインネームスペースでこのアドレスを検索しました はツリー構造として設計されており 各名前付きドメインはツリー内のノードです ツリーの最上位の階層のノードは ルートドメイン (.) であり その下に.com.edu.gov.mil などのサブドメインがあります ( 図 13-2 を参照 ) 図 13-2 ドメインネームシステムの階層.( ) com edu gov mil example.com 完全修飾ドメイン名 (FQDN) は ルートから始まるすべてのネットワークドメインのドットで区切られた文字列です この名前は インターネット上の各ホストに対して一意になっています 前述の例で ドメインの FQDN である example.com は このドメインが example で 親ドメインは.com そのルートドメインは. であることを示しています Co 社のアドレスの検索 John のワークステーションが という Web サイトの IP アドレスを要求します ( 図 13-3 を参照 ) 図 13-3 John 階層名の検索. ( ). ( ) ( ) ローカル サーバがデータベースで ドメインを検索しますが見つけられません これは サーバがこのドメインに対する権限を持っていないことを示しています 2. サーバは 最上位の階層 ( ルート ) のドメインである. ( ドット ) に対する権限を持つルートネームサーバを要求します 13-3

4 ドメイン 3. ルートネームサーバは そのサブドメインについての情報を持つ.com ドメインのネームサー バにクエリーを転送します 4..com ネームサーバは example.com が.com ネームサーバのサブドメインの 1 つであると判断 し そのサーバのアドレスを返します 5. ローカルサーバは example.com のネームサーバに の場所をたずねます 6. example.com ネームサーバは アドレスが であると応答します 7. ローカルサーバは このアドレスを John の Web ブラウザに送ります ドメインの確立 Co 社の Web サイトに John がアクセスできたのは 同社がドメインを公認のドメイン登録機関に登録していたからです また Co 社はドメイン名を.com サーバのデータベースに登録し IP アドレスの範囲を定義するネットワーク番号も要求しました この例におけるネットワーク番号は であり これは から の範囲のすべてのアドレスが含まれます オクテットと呼ばれるアドレスフィールドのそれぞれには 0 ~ 256(2 8 ) の番号だけが設定できます ただし 0 と 256 の番号は それぞれネットワークアドレスとブロードキャストアドレスに予約されており ホストには使用されません ドメインとゾーンの違い ドメインネームスペースは ゾーン と呼ばれる領域に分割されます ゾーンは ツリー内の委任ポイントです ゾーンには特定のポイントから下のドメインのうち 別のゾーンが権限を持つポイントを除いたドメインがすべて含まれています ゾーンには 通常 権限ネームサーバがあり 複数存在することも珍しくありません 組織内では多数のネームサーバを持つことができますが インターネットのクライアントはルートネームサーバが知っているネームサーバしか照会できません 他のネームサーバは 内部クエリーにだけ応答します Co 社は同社のドメインである example.com を登録し example.com marketing.example.com および finance.example.com という 3 つのゾーンを確立しました そして marketing.example.com および finance.example.com に対する権限を社内の Marketing and Finance グループにある サーバに委任しました marketing.example.com 内のホストに関する照会を example.com に実行すると example.com は marketing.example.com ネームサーバにクエリーを送ります 図 13-4 では example.com ドメインに 3 つのゾーンが含まれており example.com ゾーンは自身に対する権限だけを持っています 図 13-4 委任したサブドメインを持つ example.com. ( ) Marketing com Finance

5 ドメイン Co 社は 権限をサブドメインに委任しない方法も選択できました その場合 example.com ドメインはサブドメインの marketing および finance に対する権限を持つゾーンです ( 図 13-5 を参照 ) example.com サーバは marketing および finance に関する外部のクエリーにすべて応答します 図 13-5 委任を使用しない example.com.( ) com Marketing Finance Network Registrar を使用してゾーンの設定を開始すると 各ゾーンに対してネームサーバを設定する必要があります 各ゾーンにはプライマリサーバが 1 つずつあり これがゾーンの内容をローカル設定データベースからロードします また 各ゾーンにはセカンダリサーバをいくつでも含むことができます セカンダリサーバはプライマリサーバからデータを取り出すことによってゾーンの内容をロードします 図 13-6 は セカンダリサーバを 1 つ使用する構成を示しています 図 13-6 ゾーンのプライマリサーバとセカンダリサーバ

6 ネームサーバ ネームサーバ はクライアント / サーバモデルに基づいています このモデルでは ネームサーバが データベースの一部分に関するデータを持ち ネットワークを介してネームサーバに照会を行うクライアントにこの情報を提供します ネームサーバは 物理ホスト上で実行されるプログラムであり ゾーンに関するデータを格納します ドメインの管理者は ゾーン内のホストを記述するすべてのリソースレコード (RR) のデータベースを持つネームサーバを設定します ( 図 13-7 を参照 ) RR の詳細については 付録 A リソースレコード を参照してください 図 13-7 クライアント / サーバ名前解決 example.com ns.myname.com サーバは名前からアドレスへの変換 つまり名前解決を提供します これらは 完全修飾ドメイン名 (FQDN) 内の情報を解釈してそのアドレスを見つけます クエリーで要求されているデータがローカルネームサーバにない場合は 見つかるまで別のネームサーバに問い合せます ネームサーバでは ドメインネームスペースに関してクエリーから得た情報を継続的にキャッシュしているので 頻繁に要求される名前についてはこのプロセスが迅速化します 各ゾーンでは ローカルデータベースからゾーンの内容をロードするプライマリネームサーバが 1 つと プライマリサーバからデータのコピーをロードするセカンダリサーバがいくつか必要です ( 図 13-8 を参照 ) プライマリサーバからセカンダリサーバを更新するプロセスを ゾーン転送 といいます 図 13-8 ゾーン転送

7 ネームサーバ セカンダリネームサーバがプライマリサーバの一種のバックアップとして動作する場合でも 両方のタイプのサーバはいずれもゾーンに対する権限を持つことができます プライマリネームサーバもセカンダリネームサーバも クエリーの回答結果として取得した情報からではなく ゾーンの権限を持つデータベースからゾーン内のホスト名を取得します クライアントは両方のサーバに名前解決を照会できます Network Registrar の ネームサーバを設定するときには ゾーンごとにそのサーバの役割をプライマリ セカンダリ キャッシュ専用のうちから指定します サーバのタイプはサーバの役割においてのみ意味を持ちます サーバは あるゾーンではプライマリサーバになり 別のゾーンではセカンダリサーバになることができます また プライマリサーバかセカンダリサーバのいずれか一方だけになることも ゾーンを使用しないでキャッシュを使ってクエリーに回答するだけのサーバになることも可能です 全サーバが 情報をデータの期限満了まで保存しておくキャッシュサーバといえますが キャッシュ専用サーバは いずれのゾーンに対しても権限を持たないサーバを指します このサーバは内部クエリーに回答し 他の権限サーバに対して情報を要求します サイトはキャッシュ専用サーバを作成して権限サーバの負荷を軽減することによって すべてのクエリーを権限サーバに送る必要がなくなります サーバの設定については 次の項を参照してください プライマリネームサーバ :P.14-6 の プライマリ サーバの管理 セカンダリサーバ :P の セカンダリサーバの管理 キャッシュ専用サーバ :P.16-6 の キャッシング専用サーバの設定 13-7

8 逆引きネームサーバ 逆引きネームサーバ ここまで説明した サーバは名前からアドレスへの解決を実行します すべてのデータは名前別にインデックスが付けられているので サーバはデータベース全体で正しいアドレスを検索することによって 簡単に名前からアドレスへの解決を行うことができます しかし コンピュータログファイルなどの特定の出力を解釈できるアドレスから名前への解決が必要な場合もあります しかし アドレスだけがわかっていてドメイン名を探す場合は ネームスペース全体を検索する必要があります は in-addr.arpa ドメインというアドレスを名前として使用するドメインネームスペースをサポートすることにより この問題を解決します この逆ゾーンには ネットワーク番号に基づく各ネットワークのサブドメインがあります 整合性と自然なグループ化を実現するために ホスト番号の 4 つのオクテットが逆引きされます IP アドレスをドメイン名として読み取ると その名前はリーフからルートという順になって逆順に表示されます たとえば Co 社の example ドメインのネットワーク番号は です このドメインの逆ゾーンは in-addr.arpa です サーバアドレス ( ) しかわからない場合は 逆引きドメインへのクエリーによって example.com にマッピングするホストエントリ in-addr.arpa が得られます 図 13-9 に示すように 逆引きドメインは Pointer(PTR)RR によって処理されます 図 13-9 逆引きドメイン in-add arpa in-addr.arpa ptr ns.example.com ハイアベイラビリティ ゾーンあたり 1 台のプライマリ サーバしか存在しないことがあるため プライマリ サーバがダウンした場合に ダイナミックアップデートが失敗するリスクがあります このようなアップデートは プライマリ サーバだけで実行されることがあります そのため セカンダリ サーバはアップデートによる変更を記録できません しかし 変更をプライマリサーバに転送する必要があります この問題を解決するために 2 番目のプライマリサーバをメインのプライマリサーバの障害に備えるホットスタンバイサーバにすることができます これはハイアベイラビリティ (HA) と呼ばれます ( 第 17 章 ハイアベイラビリティ サーバの設定 を参照 ) このフェールオーバー構成で 両方のサーバは それぞれのプライマリゾーンおよび関連するアトリビュートが同じになるように同期化する必要があります Network Registrar は 同期のためのメインとバックアップ フェールオーバーモードに移行するタイムアウト時間を識別するためにメインサーバの設定を提供します 13-8