第5章
DNS入門
DNS(Domain Name System:ドメインネームシステム)により、私たちは階層的でわかりやすい名前を使用して、IPネットワーク上にあるコンピュータなどの資源を見つけることができます。この章では、DNSの基本概念について説明します。また、IETF(Internet Engineering Task Force)から公開されている動的更新などに関する最新のRFC(Request for Comments)も取り上げます。ただし、特に明記しない限り、Microsoft Windows 2000に実装されている独自のDNS機能は扱いません。
Windows 2000に実装されているDNSの詳細については、本書の「第6章 Windows 2000 DNS」を参照してください。
DNSは、DNSドメイン名からIPアドレスへのマッピングが含まれている分散データベースです。また、TCP/IP(Transmission Control Protocol/Internet Protocol:伝送制御プロトコル/インターネットプロトコル)ネットワークのためのプロトコルでもあり、DNSに関連するRFCで規定されています。DNSは、次のしくみを定義しています。
データベースの照会と更新のためのしくみ
サーバー間でデータベース内の情報を複製するためのしくみ
データベースのスキーマ
関連情報
TCP/IPプロトコルの詳細については、本書の「第1章 TCP/IP入門」を参照してください。
Windows 2000に実装されているDNSの詳細については、本書の「第6章 Windows 2000 DNS」を参照してください。
5.1DNS入門
ホスト(コンピュータなどのTCP/IPネットワークデバイス)を見つけて接続するとき、TCP/IPではIPアドレスが使用されますが、ユーザーはわかりやすい名前を使用したいと思うのが普通でしょう。たとえば、172.16.23.55のようなIPアドレスより、ftp.reskit.comのようなわかりやすい名前をユーザーは好むはずです。RFC 1034と1035で規定されているDNSは、インターネット上でIPをベースにしたコンピュータを見つけるための、標準の名前解決の方法を提供します。
インターネットでは、DNSが実装される以前から、TCP/IPネットワーク上の資源を名前で見つける方法がありました。それがhostsファイルの利用です。この方法では、hostsファイルに記述されたホスト名とIPアドレスを対応させることで、名前解決を行います。
hostsファイルとDNSは、ともに名前空間を使用します。「名前空間」とは、DNSデータベースの階層構造を提供する名前付けの体系のことです。それぞれの名前空間には、名前の作成方法と使用方法を決定する特定のルールが確立しています。DNSなどの名前空間は、階層構造を持ち、全体をいくつかの部分集合に分けて配布したり委任したりするためのルールが決められています。一方、hostsファイルなどの名前空間は分割できないので、全体をまとめて配布しなければなりません。そのことが、hostsファイルを利用するネットワーク管理者にとって悩みの種でした。現在では、インターネット上のコンピュータとユーザーの数が増えたため、hostsファイルの更新と配布を管理することは不可能になっています。
DNSは、hostsファイルを、階層型ネームシステムを実装する分散データベースに置き換えます。このネームシステムは、インターネットの拡張を可能にします。さらに、インターネットやTCP/IPベースのプライベートイントラネットの中で固有な名前を付けることを可能にします。
5.1.1ドメイン名前空間
DNSの基本になっているネームシステムは、「ドメイン名前空間」と呼ばれる階層型の論理ツリー構造です。それぞれの企業や組織が独自のドメイン名前空間を使用して、インターネット上に公開しないプライベートネットワークを構築することもできます。図5.1に、インターネットドメイン名前空間の一部を示します。ここでは、ルートドメインとトップレベルドメインから、Mfgserverというホスト(コンピュータ)を含むreskit.comという架空のDNSドメインまでを表しています。
図5.1 インターネットドメイン名前空間
DNSツリーの各ノードは、DNS名を表します。DNS名には、DNSドメイン、コンピュータ、サービスなどがあります。DNSドメインは、ノードの下にある枝にあたります。たとえば、図5.1のreskit.comはDNSドメインです。DNSドメインには、ホスト(コンピュータまたはサービス)とほかのドメイン(「サブドメイン」と呼びます)を含むことができます。それぞれの企業や組織は、ドメイン名前空間の一部の権限が与えられ、権限が与えられた部分に含まれるDNSドメインとコンピュータの管理、細分化、名前付けの責任を持ちます。
細分化はDNSの重要な概念です。ドメイン名前空間を細分化し、プライベートTCP/IPネットワークにDNSドメインを提供することがインターネットの新しい発展を支え、名前や管理上のグループを継続的に増やしていくことを可能にします。通常、細分化はそれぞれの企業や組織の部門別または地域別に行われます。
たとえば、DNSドメインreskit.comには北米とヨーロッパのサイトが含まれているとします。reskit.comのDNS管理者は、地域によってドメインを細分化し、noam.reskit.comとeu.reskit.comの2つのサブドメインを作成することができます。図5.2に、この2つのサブドメインの例を示します。
図5.2 サブドメイン
■|ドメイン名
コンピュータとDNSドメインには、ドメインツリー内の位置に基づいて名前が付けられます。たとえば図5.2では、.comドメインのサブドメインであるreskitのドメイン名は、reskit.comになります。
DNSドメインツリーのノードは、すべてFQDN(Fully Qualified Domain Name:完全修飾ドメイン名)によって識別されます。FQDNは、DNSドメインツリーのルートからの相対的な位置として表現することで、ホストの正確な位置を表します。それに対して、相対名はルート以外のDNSドメインからの相対的な名前です。
たとえば、reskit.comにあるサーバーのFQDNは、Mfgserver.reskit.com.になります。この名前は、ホスト名(Mfgserver)にプライマリDNSサフィックス(reskit.com)を連結し、最後にドット(.)を付けることによって得られます。最後に付けるドットは、トップレベルドメインのラベルとの便宜上、空のラベルが付けられているルートドメインとの区切り文字として使用されます。
注
一般に、FQDNには英数字(a〜z、A〜Z、0〜9)とマイナス記号(-)だけを使用することになっています。ピリオド(.)は、ドメイン名のラベル(「reskit.com」など)とラベルの間、およびFQDNの最後にだけ使用します。ドメイン名に使用するアルファベットの大文字と小文字は区別されません。 Windows 2000のDNSサーバーでは、設定によって、文字に関するRFCの制約の一部またはすべてを適用したり、すべての制約を無視したりできます。詳細については、本書の「第6章 Windows 2000 DNS」を参照してください。
■|インターネットドメイン名前空間
インターネットドメイン名前空間のルート(最上位)は、インターネット名前登録機関によって管理されます。この機関は、ドメイン名前空間を分割し、各部分の管理責任を、インターネットに接続する組織に委任します。
ルートDNSドメインの下にはトップレベルドメインがあり、このレベルもインターネット名前登録機関によって管理されます。トップレベルドメインには、次の3種類があります。
組織ドメイン ― DNSドメインに含まれる組織の主な役割または活動を示す3文字のコードを使用して名前が付けられます。一般に、組織ドメインを持つのは米国内の組織に限られ、米国の企業や組織は、これらの組織ドメインの1つにほとんど含まれています。
地域ドメイン ― ISO(International Organization for Standardization)3166によって定められている、2文字の国コードと地域コードを使用して名前が付けられます。
逆引きドメイン ― in-addr.arpaという名前の特殊ドメインです。IPアドレスから名前へのマッピング(「逆引き参照」と呼びます)に使用されます。詳細については、この章の「5.3 名前解決」を参照してください。また、IPv6の逆引き参照に使用されるIP6.INTという名前の特殊ドメインもあります。詳細については、RFC 1886を参照してください。
米国内の企業や組織で最も多く使用されているトップレベルドメイン名の構成要素を表5.1に示します。
表5.1DNS階層のトップレベルのドメイン名構成要素
トップレベルの名前構成要素
説明
DNSドメイン名の例
|
.com
インターネット名前登録機関がMicrosoft Corporationなどの営利団体に割り当て、委任する。
microsoft.com
.edu
インターネット名前登録機関が米国マサチューセッツ工科大学(MIT)などの教育機関に割り当て、委任する。
mit.edu
.gov
インターネット名前登録機関がワシントン特別区のホワイトハウスなどの政府機関に割り当て、委任する。
whitehouse.gov
.int
インターネット名前登録機関が北大西洋条約機構(NATO)などの国際組織に割り当て、委任する。
nato.int
.mil
インターネットの名前登録機関がDefense Data Network(DDN)などの軍の機関に割り当て、委任する。
ddn.mil
.net
インターネット名前登録機関が米国科学財団(National Science Foundation:NSF)などのネットワーク組織に割り当て、委任する。
nsf.net
.org
インターネット名前登録機関がCNIDR(Center for Networked Information Discovery and Retrieval)などの非営利団体に割り当て、委任する。
cnidr.org
表5.1のトップレベルドメインに加え、各国に独自のトップレベルドメインがあります。たとえば、.caはカナダのトップレベルドメインです。
インターネットの名前登録機関は、トップレベルドメインの下で、インターネットに接続するそれぞれの企業や組織にドメインを委任します。インターネットの名前登録機関からドメイン名前空間の一部を委任された企業や組織は、割り当てられたドメインとそのサブドメイン内にあるコンピュータとネットワークデバイスに名前を付ける責任を持ちます。それぞれの企業や組織は、名前空間が割り当てられたドメインに含まれるホストデバイスに関しては、DNSサーバーを使用してその名前からIPアドレスへのマッピング、およびIPアドレスから名前へのマッピングを管理します。
5.1.2DNSの基本概念
ここでは、DNSの上記以外の概念を簡単に定義します。その後の項で、各概念について詳しく説明していきます。
DNSサーバー ― DNSドメインツリー構造に関するDNSデータベース情報を保持し、DNSサーバープログラムを実行するコンピュータ。DNSサーバーは、クライアントからの照会も解決しようとします。照会を受けたDNSサーバーは、次のうちのいずれかの処理を行います。
要求された情報を提供する
照会を解決できる可能性がある別のサーバーを教える
自分が情報を持っていないあるいは情報自体が存在しないことを返す
DNSリゾルバ ― DNS照会を使用してサーバーに情報を問い合わせるプログラム。リゾルバは、リモートDNSサーバーもしくはローカルコンピュータ上で実行されているDNSサーバープログラムと通信します。通常、ユーティリティプログラムに組み込まれているか、ライブラリ関数を通じてアクセスできます。DNSサーバーを含むどのコンピュータでも実行できます。
リソースレコード ― クライアントからの照会を処理するために使用するDNSデータベース内の情報。各データベースサーバーは、DNS名前空間の権限が与えられているドメインについての照会に答えるために必要なリソースレコードを含んでいます(DNSサーバーは、名前空間の隣接したドメインに関する情報を持っているときは、そのドメインの権限も持ちます)。
ゾーン ― 特定のサーバーに権限が与えられている名前空間の連続した範囲。1台のサーバーは1つ以上のゾーンの権限を持つことができます。
ゾーンファイル ― サーバーが権限を持っているゾーンのリソースレコードが入ったファイル。ほとんどのDNSサーバーでは、ゾーン情報はテキストファイルとして保持されています。
5.1.3ゾーン
DNS名前空間の中の連続した範囲を「ゾーン」と呼びます。ゾーンには、DNSサーバーに格納されている一連のレコードが入っています。各ゾーンは、特定のドメインノードと結び付きます。しかし、ゾーンはドメインではありません。「DNSドメイン」は名前空間の枝の1つです。ゾーンは、一般にファイルに格納され、複数のドメインを含むことができる名前空間の一部です。1つのドメインはいくつかの部分に細分化できます。細分化された各部分、つまりゾーンごとに別々のサーバーによって、ドメインは管理できます。ゾーンを使用することによって、DNSサーバーはそのゾーン内のホストに関する照会に答え、そのゾーンの権限を持ちます。ゾーンには「プライマリゾーン」と「セカンダリゾーン」があります。プライマリゾーンは更新対象のコピー、セカンダリゾーンはマスタサーバーから複製されたコピーです。
ゾーンはさまざまな方法で格納できます。たとえば、ゾーンファイルとして格納できます。Windows 2000を実行しているサーバーでは、Active Directoryディレクトリサービスデータベースにも格納できます。セカンダリサーバーの中にはメモリに格納し、再起動するたびにゾーン転送を行うものもあります。
図5.3に、2つのプライマリゾーンを含むDNSドメインの例を示します。この例では、ドメインreskit.comにnoam.reskit.com.とeu.reskit.com.の2つのサブドメインが含まれています。サブドメインnoam.reskit.com.の管理は、サーバーnoamdc1.noam.reskit.com.に委任されています。したがって、図5.3のように、noam.reskit.comというゾーンはnoamdc1.noam.reskit.comというサーバーが管理し、サブドメインeu.reskit.comを含むゾーンreskit.comは2番目のサーバーreskitdc1.reskit.comが管理します。
図5.3 ドメインとゾーン
noam.reskit.comゾーンをnoamdc1.noam.reskit.comに委任する代わりに、管理者はnoam.reskit.comのゾーンをreskitdc1に管理させることもできます。
一方、複数の異なるサーバーによって、同じプライマリゾーンを管理することはできません。ただし、例外が1つあります。統合されたゾーンであるWindows 2000 Active Directoryは、複数のコンピュータで管理できます。詳細については、本書の 「第6章 Windows 2000 DNS」を参照してください。
1台のDNSサーバーによって、必要に応じて1つまたは複数のゾーンを管理することができます。複数のゾーンを作成することにより、管理作業を複数のグループで分担し、データを効率良く分散させることができます。また、複数のサーバー上に同じゾーンを格納することで、負荷のバランスをとり、フォールトトレランスを実現することもできます。
ゾーンに含まれている情報の詳細は、「5.4 リソースレコードとゾーン」を参照してください。
5.2DNSサーバー
DNSサーバーには、ゾーンの情報が格納されていない場合もあれば、1つまたは複数のゾーンの情報が格納されている場合もあります。DNSサーバーはDNS照会を受け取ると、そのローカルゾーンからデータを検索することによって、要求された情報を見つけようとします。要求されたDNSドメインの権限を持っていないことが原因で情報を見つけることができない場合は、キャッシュをチェックし、ほかのDNSサーバーに問い合わせて要求に応えるか、要求に応えられる可能性があるほかのDNSサーバーをクライアントに照会します。
DNSサーバーはプライマリゾーンとセカンダリゾーンを管理できます。1台のサーバーが管理できるプライマリゾーンとセカンダリゾーンの数は、現実的な範囲内であれば上限はありません。つまり、1台のサーバーが特定のゾーンのプライマリコピーと別のゾーンのセカンダリコピーを管理したり、ゾーンのプライマリコピーだけまたはセカンダリコピーだけを管理したりできます。プライマリゾーンを管理するサーバーは、そのゾーンの「プライマリサーバー」として位置付けられます。セカンダリゾーンを管理するサーバーは、そのゾーンの「セカンダリサーバー」として位置付けられます。
プライマリゾーンはローカルで更新されます。ゾーンの一部を別のDNSサーバーに委任したり、ゾーンにリソースレコードを追加したりするときなど、ゾーンデータに変更を加えるときは、そのゾーンのプライマリサーバー上で変更を加え、新しい情報がローカルゾーンに更新されるようにしなければなりません。
対照的に、セカンダリゾーンは別のサーバーから複製されます。セカンダリサーバーで定義したゾーンには、そのゾーンの複製元サーバーのIPアドレスが使用されます。ゾーンファイルの複製元サーバーは、そのゾーンのプライマリゾーンとセカンダリゾーンのどちらでもかまいません。セカンダリゾーンの複製元サーバーのことを「マスタサーバー」と呼ぶこともあります。
ゾーンのセカンダリサーバーは、起動時にゾーンのマスタサーバーと通信してゾーンの転送を開始します。さらにマスタサーバーと定期的に通信を行って、ゾーンデータが変更されていないかどうかを確認します。変更されているときは、ゾーンの転送を開始することができます。この処理を「ゾーン転送」と呼びます。ゾーン転送の詳細については、「5.5 ゾーン転送」を参照してください。
各ゾーンにはプライマリサーバーが必須です。さらに、できればセカンダリサーバーを各ゾーンに少なくとも1台用意します。セカンダリサーバーがないゾーンでは、プライマリサーバーがダウンすると、そのゾーンの名前解決ができなくなります。
セカンダリサーバーを用意することによって、次のような利点があります。
フォールトトレランス ─ ゾーンのセカンダリサーバーを用意すると、クライアントはゾーンのプライマリサーバーがダウンした場合でもそのゾーンの名前解決を行うことができます。一般に、ゾーンのプライマリサーバーとセカンダリサーバーは、別のサブネットに置きます。このようにすると、DNSクライアントは、一方のサブネットへの接続が断たれても、もう一方のネームサーバーに照会を行うことができます。
ワイドエリアリンク上のトラフィックの軽減 ─ 離れた場所にクライアントが多数存在する場合は、それらのクライアントの最初の照会先として、その場所にセカンダリサーバーを置くとよいでしょう。クライアントが低速のリンクを経由してDNS照会を行う回数が少なくなります。
プライマリサーバーの負荷の軽減 ─ セカンダリサーバーがゾーンの照会に答えることができれば、プライマリサーバーが答えなければならない照会の数が減ります。
次に、キャッシュ専用サーバー、フォワーダ、スレーブについて説明します。
5.2.1キャッシュ専用サーバー
どのDNSサーバーもキャッシングを行い、ほかのサーバーから受け取った情報を一定時間キャッシュに保持します。キャッシングによってDNS解決が高速になり、DNS関連の照会のトラフィックが減少し、信頼性が向上します。詳細については、「5.3.2 キャッシングとTTL」を参照してください。
「キャッシュ専用サーバー」と呼ばれる特定のDNSサーバーの役割は、照会を行い、回答をキャッシュに入れ、結果を返すだけに限られます。DNSドメインの権限を持たず、どのゾーンも管理しません。キャッシュに入れたデータについては、照会を解決している間保管しているに過ぎません。
キャッシュ専用サーバーを利用すると、キャッシュ専用サーバーが特定のゾーンを持たないため、ゾーン転送によるネットワークトラフィックが発生しないという利点があります。ただし、これには欠点が1つあります。それは、キャッシュ専用サーバーを最初に起動したときはキャッシュに何も情報がないため、要求を処理し続けることによって時間をかけて情報を蓄積しなければならないことです。
5.2.2フォワーダとスレーブ
DNSサーバーは、照会を受け取ると、要求された情報をそのローカルゾーン内とキャッシュから見つけようとします。要求された情報を見つけることができず、要求された情報への権限も持っていない場合は、要求を処理するためにほかのサーバーと通信をしなければなりません。しかし、サーバーがほかのサーバーと直接通信してほしくないケースもあります。たとえば、企業または組織が低速のワイドエリアリンクを使用してインターネットに接続している場合は、内部のすべてのDNSサーバーがインターネット上のDNSサーバーに直接接続するのは好ましくありません。
DNSでは、「フォワーダ」を使用してこの問題を解決することができます。フォワーダとは、外部のほかのサーバーに対する照会を転送するように指定されているサーバーのことです。たとえば、1台のDNSサーバーをインターネット上のコンピュータの名前解決のためのフォワーダとして指定し、ほかのサーバーは、自分が権限を持たない名前の解決をするときにそのフォワーダを使用するように設定します。
フォワーダとして指定されたコンピュータでは、特別な設定をする必要はありません。一方、照会を転送することが必要なほかのDNSサーバーでは、フォワーダのDNSサーバーのIPアドレスを指定しなければなりません。
サーバーは、フォワーダを非排他モードまたは排他モードで使用できます。非排他モードでは、受け取った照会が、自分のゾーンとキャッシュを使用して解決できないと、指定されているフォワーダの1つに渡します。照会を受け取ったフォワーダは、照会を解決するために必要な通信を実行し、結果を最初の要求元に返します。フォワーダが問い合わせを処理できないときは、照会を最初に受け取ったサーバーが再度自分で処理を試みます。
排他モードでは、サーバーは、名前解決をすべてフォワーダに任せます。フォワーダを排他モードで使用するサーバーを、「スレーブ」と呼びます。スレーブは、自分のゾーンで処理できないDNS照会を受け取ると、指定されているフォワーダの1つに渡します。スレーブから照会を受け取ったサーバーは、照会を処理するために必要な通信を実行し、結果をスレーブに返します。スレーブは、受け取った結果を要求元に返します。フォワーダが要求を処理できないときは、照会に失敗したことをスレーブが要求元に報告します。フォワーダが要求を処理できない場合、スレーブはそれ以上の照会を行いません。
5.2.3負荷共有
DNSサーバーは、RFC 1794で説明されているラウンドロビンまたは負荷共有(load sharing)という仕組みで、ネットワーク資源の負荷を共有し、分散します。ラウンドロビンは、照会された1つのDNSドメイン名に同じ種類の複数のリソースレコード(RR)が存在する場合、それぞれの照会ごとに、返されるリソースレコードデータの順序が並び替えられている方式です。
たとえば、WWWServerという同じ名前で3台のWWWサーバーを用意し、そのすべてがwww.reskit.comのWebページを表示するようにして、負荷を共有させたいとします。その場合は、ネームサーバー上で次のリソースレコードを作成します。
www.reskit.com. IN A 172.16.64.11
www.reskit.com. IN A 172.17.64.22
www.reskit.com. IN A 172.18.64.33
ラウンドロビンを実行するように設定されているネームサーバーは、クライアント要求に応えるたびにAリソースレコードの順序を変えます。この例の場合、最初のクライアント要求に応えるときは、172.16.64.11、172.17.64.22、172.18.64.33のようにアドレスを並べます。2番目のクライアント要求に応えるときは、172.17.64.22、172.18.64.33、172.16.64.11のように並べ替えます。要求された名前に関連付けられた同じ種類のすべてのリソースレコードが、クライアント要求に対して返すリストの最初に来るまで、このプロセスは続けられます。クライアントは、リストの先頭にあるIPアドレスを試す必要があります。
Windows 2000 DNSサーバーは、既定では、クライアントに返すレコードの順序を別の方法で決定します。クライアントに最も近いIPアドレスが付けられたリソースレコードを探し、該当するレコードがあるとそれをリストの先頭に置いて返します。しかし、この既定の動作は、従来のラウンドロビンを実行するように変更することができます。詳細については、本書の「第6章 Windows 2000 DNS」を参照してください。BIND 4.9.3以降のバージョンでは、ラウンドロビン方式の負荷共有を行います。それ以前のバージョンでは、異なる方式が使用されます。詳細については、RFC 1794を参照してください。
5.3名前解決
DNSクライアントは、クライアントに代わってDNSサーバーに照会を行う「リゾルバ」と呼ばれるライブラリを使用します。ここの説明を読むと、DNSサーバーも別のサーバーのクライアントになる可能性があることがわかるでしょう。
注
Microsoft Windows NT Workstation 4.0またはMicrosoft Windows NT Server 4.0を実行するコンピュータは、名前照会要求の名前にピリオドが含まれているか、コンピュータ名が15バイトより長いと、DNS名前解決を使用します。Windows 2000を実行するコンピュータは、常にDNS名前解決を試みます。DNSとNetBIOSの名前解決の詳細については、本書の「第3章 TCP/IPのトラブルシューティング」と「第6章 Windows 2000 DNS」を参照してください。
DNSクライアントは、再帰照会と反復照会の2種類の照会を行うことができます。
5.3.1再帰照会と反復照会
DNSクライアントがDNSサーバーに対し、要求したリソースレコードか、レコードまたはドメイン名が存在しないことを示すエラーメッセージのいずれかを返して応答するよう要求するときに、「再帰名前照会」を使用します。再帰名前照会の要求を受けたサーバーは、別のDNSサーバーをクライアントに照会することはできません。
したがって、再帰照会の要求を受けたDNSサーバーは、要求された情報を持っていない場合は、情報を入手するか名前照会に失敗するまで、ほかのサーバーに照会を行います。
一般に、DNSサーバーがフォワーダを使用するように設定されていれば、再帰名前照会は、DNSクライアントがDNSサーバーに送信するように設定されているDNSサーバー、または未解決の名前照会を別のDNSサーバーに渡すように設定されているDNSサーバーが使用します。
一方、「反復名前照会」を受け取ったDNSサーバーは、そのキャッシュまたはゾーンデータに基づいて最善の回答を返すことができます。照会先のDNSサーバーが照会された名前と正確に一致するレコードを持っていない場合、そのサーバーの最善の回答は「照会」(つまり、より低いレベルのドメイン名前空間の権限を持っているDNSサーバーへのポインタを返すこと)です。クライアントは、取得したポインタが指すDNSサーバーに照会を行うことができます。この処理は、照会している名前の権限を持っているDNSサーバーが見つかるか、エラーになるかタイムアウトするまで続けられます。
この処理は「ツリー内の巡回」と呼ばれることもあります。このタイプの照会は、DNSクライアントから再帰名前照会を要求されたDNSサーバーによって行われるのが普通です。
図5.4に、反復照会と再帰照会の例を示します。この例では、要求されている情報をキャッシュに持っているサーバーがないと想定しています。
図5.4 反復照会と再帰照会
図5.4に示す例では、インターネット上のあるクライアントにはnoam.reskit.comのIPアドレスが必要です。次のイベントが発生します。
クライアントがnoam.reskit.comの再帰照会をネームサーバー1に送信します。ネームサーバー1は、回答かエラーメッセージのいずれかを返さなければなりません。
ネームサーバー1はそのキャッシュとゾーンから回答を探しますが、見つかりません。そこで、インターネットの権限を持っているサーバー(つまり、「ルートサーバー」)にnoam.reskit.comの反復照会を送信します。
インターネットのルートのサーバーは回答を知らないため、.comドメインの権限を持つサーバーを照会します。
ネームサーバー1は、.comドメインの権限を持つサーバーにnoam.reskit.comの反復照会を送信します。
.comドメインの権限を持つサーバーは正確な回答を知らないため、reskit.comドメインの権限を持つサーバーを照会します。
ネームサーバー1は、reskit.comドメインの権限を持つサーバーにnoam.reskit.comの反復照会を送信します。
reskit.comドメインの権限を持つサーバーは回答を知っています。要求されたIPアドレスを返します。
ネームサーバー1は、クライアントの照会に対し、noam.reskit.comのIPアドレスで応答します。
5.3.2キャッシングとTTL
サーバーは再帰照会を処理しているときに、最終的な回答を見つけるまでにいくつかの照会をほかのDNSサーバーに送ります。サーバーは、この処理の間に受け取る情報のすべてを、返されたデータに指定されている時間に従って、キャッシュに保持します。この時間は「TTL(Time to Live:生存時間)」と呼ばれ、秒単位で指定されます。データのTTLは、そのデータが入っているプライマリゾーンのサーバー管理者が決定します。データが変更される頻度が高ければ、TTLの値が小さいほど、ドメインに関する情報のネットワーク上での一貫性が保たれます。しかし、キャッシュを保持しているネームサーバーの負荷は高くなり、インターネットのトラフィックも高くなります。データがキャッシュに入っているため、リソースレコードでの変更がインターネット全体にすぐに反映されないことがあります。
DNSサーバーは、データをキャッシュに入れた後、キャッシュからデータを削除するタイミングがわかるように、TTLを規定値から徐々に減少させていきます。DNSサーバーは、そのキャッシュのデータによって照会に応答するとき、その応答にはTTLが含まれます。リゾルバは、サーバーによって送信されたTTLを使用し、このデータをキャッシュに入れることができます。
5.3.3否定キャッシング
解決された照会をキャッシュに入れるだけでなく、リゾルバとサーバーは否定応答、つまり特定のリソースレコードの集合(RRset)またはDNSドメイン名が存在しないという情報もキャッシュに入れることができます。否定キャッシングにより、否定回答の応答時間を短縮できます。また、リゾルバとネームサーバーの間、ネームサーバーとネームサーバーの間で送信しなければならないメッセージの数が減るため、ネットワークトラフィックも減少させることができます。
否定キャッシングは、RFC 1034とRFC 2308で規定されています。RFC 1034は、否定応答をキャッシュに入れる方法を記述し、否定キャッシングを省略可能としています。RFC 2308は、リゾルバが応答をキャッシュに入れる場合は、否定応答をキャッシュに入れなければならないとしています。また、ネームサーバーがキャッシュの中の否定応答を、リゾルバに転送する方法を記述しています。通常のキャッシングとまったく同じように、否定応答をキャッシュに入れるときもTTLを減らしていかなければなりません。
Windows 2000 DNSでの否定キャッシングの詳細については、本書の「第6章 Windows DNS」を参照してください。
5.4リソースレコードとゾーン
名前解決を行う場合、サーバーは自分のゾーン(「DNSデータベースファイル」、または単に「dbファイル」とも呼びます)を調べます。ゾーンには、DNSドメインに対応するリソース情報を構成するリソースレコード(RR)が入っています。たとえば、リソースレコードの中には、わかりやすい名前をIPアドレスにマップするものと、IPアドレスをわかりやすい名前にマップするものがあります。
リソースレコードは、DNSドメイン内のサーバーに関する情報を含んでいます。また、どのサーバーがどのゾーンの権限を持っているかを指定することによって、ドメインを定義する役割も果たします。これらのリソースレコード(SOAリソースレコードとNSリソースレコード)については、後で詳しく説明します。
5.4.1リソースレコードの形式
リソースレコードの構文は、次のとおりです。
<所有者> <TTL> <クラス> <タイプ> <RDATA>
この構文に含まれる各フィールドについて、表5.2で説明します。
表5.2代表的なリソースレコードのフィールド
名前
説明
|
<所有者>
このリソースレコードを所有しているホストまたはDNSドメインの名前。
<TTL>
DNSサーバーまたはリゾルバがこのエントリをキャッシュに入れてから破棄するまでの時間を秒単位で表した32ビットの整数。このフィールドは省略可能で、指定されていない場合、クライアントはSOAレコードの最小TTLを使用する。
<クラス>
使用するネットワークのクラスを指定する。インターネットシステムでは、ほとんどの場合にINが使用される。RFC 1034では、この値のほかにMITで実験的に使用されたChaosシステムを表すCHが定義されている。
<タイプ>
リソースレコードのタイプ。
<RDATA>
リソースレコードのデータ。このフィールドに入るデータの形式は、リソースレコードのタイプとクラスによって異なる。たとえば、Aレコードの場合は、リソースレコードによって定義されるホストを表す32ビットのIPアドレスが入る。
DNSを使用して照会と応答を行うとき、パケット内ではリソースレコードがバイナリ形式で表現されます。一方、データベースファイル内では、テキストエントリとして表現されます。ほとんどのリソースレコードは単一行のテキストエントリとして表現されます。1つのエントリが複数の行にまたがるときは、括弧を使用して情報をカプセル化できます。多くのDNSサーバーでは、SOA(Start of Authority)レコードだけが複数の行で表現されます。読みやすくするために、ゾーンファイルには空行やコメントが挿入されることがよくあります(空行やコメントは、DNSサーバーには無視されます)。コメントは必ずセミコロン(;)から始まり、改行キーで終了します。
5.4.2リソースレコードのタイプ
TCP/IPネットワーク上のコンピュータに関するDNSベースのデータを提供するため、さまざまなタイプのリソースレコードが使用できます。ここでは、最初に次のリソースレコードについて説明します。
SOA(Start of Authority)
NS(ネームサーバ)
A(アドレス)
PTR(ポインタ)
CNAME(正規名)
MX(メール交換)
SRV(サービス)
次に、RFCの規約で定められているほかのリソースレコードのいくつかを取り上げます。最後に、Windows 2000に独自に実装されているリソースレコードと、ATMフォーラムによって規定されている1つのリソースレコードを紹介します。
■|SOAリソースレコード
ゾーンの先頭には、必ずSOA(Start of Authority)リソースレコードがあります。SOAリソースレコードは、次のフィールドを含んでいます。
所有者、TTL、クラス、タイプ ― この章の「5.4.1 リソースレコードの形式」で説明した同じ名前のフィールドと同じ役割を果たします。
権限を持っているサーバー ― ゾーンの権限を持つプライマリDNSサーバーのFQDNが入ります。
ゾーンの担当者 ― ゾーンの管理責任者の電子メールアドレスが入ります。このフィールドでは、アットマーク(@)の代わりにピリオド(.)が使用されます。
シリアル番号 ― ゾーンが更新された回数が入ります。ゾーンのセカンダリサーバーがそのゾーンのマスタサーバーと通信を行ってゾーン転送を開始する必要があるかどうかを判断するとき、セカンダリサーバーは自分のシリアル番号とマスタのシリアル番号を比較します。マスタのシリアル番号の方が大きいと、セカンダリサーバーがゾーン転送を開始します。
更新間隔 ― ゾーンが変更されたかどうかを、ゾーンのセカンダリサーバーがチェックする間隔が入ります。
再試行間隔 ― ゾーンのセカンダリサーバーがゾーン転送要求を送信してから要求をもう一度送信するまでの、マスタサーバーからの応答を待機する時間が入ります。
有効期間 ― ゾーンのセカンダリサーバーが直前のゾーン転送から自分のゾーンを無効として破棄するまで、ゾーンの照会に対する応答を停止するまでの時間が入ります。
最小TTL ― TTLの値が指定されていないゾーン内のすべてのリソースレコードに適用するTTLの値が入ります。リゾルバがサーバーに照会を行うとき、サーバーはリソースレコードを最小TTLとともに返します。否定応答は、権限を持っているゾーンのSOAリソースレコードの最小TTLが経過するまでキャッシュに保持されます。
次に示すのは、SOAリソースレコードの例です。
noam.reskit.com. IN SOA (
noamdc1.noam.reskit.com. ; ゾーンの権限を持つサーバー
administrator.noam.reskit.com.; ゾーン担当者(責任者)の
; 電子メールアドレス
5099 ; シリアル番号
3600 ; 更新間隔(1時間)
600 ; 再試行間隔(10分)
86400 ; 有効期間(1日)
60 ) ; 最小TTL(1分)
■|NSリソースレコード
ネームサーバー(NS)リソースレコードは、ドメインを管理するDNSサーバーを示します。SOAリソースレコードで指定されているゾーンのプライマリサーバーとセカンダリサーバーを示します。その際、委任されているゾーンがあればそのサーバーも示します。どのゾーンも、ゾーンのルートには少なくとも1つのNSレコードを含んでいなければなりません。
たとえば、reskit.comの管理者がサブドメインnoam.reskit.comの権限をnoamdc1.noam.reskit.com.に委任していれば、reskit.comゾーンとnoam.reskit.comゾーンには、次に示す行が追加されています。
noam.reskit.com. IN NSnoamdc1.noam.reskit.com.
■|Aリソースレコード
アドレス(A)リソースレコードは、FQDNからIPアドレスへのマッピングを指定します。このレコードにより、リゾルバはFQDNに対応するIPアドレスを要求できます。たとえば、noam.reskit.comゾーンにある次のAリソースレコードは、サーバーのFQDNをそのIPアドレスにマップします。
noamdc1INA172.16.48.1
■|PTRレコード
ポインタ(PTR)リソースレコードは、Aレコードとは対照的に、IPアドレスからFQDNのマッピングを指定します。たとえば、次に示すPTRリソースレコードは、noamdc1.noam.reskit.comのIPアドレスをそのFQDNにマップします。
1.48.16.172.in-addr.arpa.INPTR
noamdc1.noam.reskit.com.
■|CNAMEリソースレコード
正規名(CNAME)リソースレコードは、特定のFQDNのエイリアス(別名)を作成します。CNAMEレコードを使用すれば、存在するホスト名をネットワークに接続するクライアントから隠すことができます。たとえば、ftp1.noam.reskit.comというFTPサーバーをサブドメインnoam.reskit.comに置きたいとします。ただし、6カ月後にはftp2.noam.reskit.comというコンピュータにFTPサーバーを移行することがわかっており、ユーザーがその変更について知らなくても済むようにしたいと考えているとします。その場合は、ftp1.noam.reskit.comを指すftp.noam.reskit.comというエイリアスを作成しておけば、コンピュータを移動するとき、エイリアスがftp2.noam.reskit.comを指すようにCNAMEリソースレコードを変更するだけで済みます。たとえば、次のCNAMEレコードは、ftp1.noam.reskit.comのエイリアスを作成します。
ftp.noam.reskit.com.INCNAMEftp1.noam.reskit.com.
DNSクライアントがftp.noam.reskit.comのAリソースレコードについての照会を行うと、DNSサーバーはCNAMEリソースレコードを見つけ、ftp1.noam.reskit.comのAリソースレコードについての照会を解決した後、AリソースレコードとCNAMEリソースレコードの両方をクライアントに返します。
注
RFC 2181によると、各エイリアスには必ず1つの正規名がなければなりません。
■|MXリソースレコード
メール交換(MX)リソースレコードは、DNSドメイン名のメール交換サーバーを指定します。「メール交換サーバー」とは、DNSドメイン名宛てのメールの処理または転送のいずれかを行うホストのことです。「メールの処理」とは、メールを受信者に配信するか、種類の異なるメール転送システムに受け渡しを行うことです。「メールの転送」とは、メールをその最終的な宛先サーバーに送信する場合や簡易メール転送プロトコル(SMTP)を使用して最終的な宛先に近い別のメール交換サーバーに送信する場合、転送先サーバーが停止していた場合に、指定された時間内キューに保持しておくことです。
注
MXレコードを使用するのはメール交換サーバーだけです。
1つのDNSドメインで複数のメール交換サーバーを使用したいときは、そのドメインのMXリソースレコードを複数作成することができます。次に示す例は、noam.reskit.com.ドメインのメールサーバーを指定するMXリソースレコードです。
*.noam.reskit.com. INMX0 mailserver1.noam.reskit.com.
*.noam.reskit.com. INMX10 mailserver2.noam.reskit.com.
*.noam.reskit.com. INMX10 mailserver3.noam.reskit.com.
このリソースレコードの先頭の3つのフィールドは、所有者、クラス、タイプを示す標準的なフィールドです。4番目のフィールドは、メールサーバーの優先順位値です。優先順位値は、複数のMXレコードの中でそのレコードに与えられる優先順位を示します。この値が小さいレコードほど優先されます。したがって、メーラーが特定のDNSドメインにメールを送信する必要があるときは、まずそのドメインのDNSサーバーと通信し、すべてのMXレコードを取り出します。その後、優先順位値が最も小さいレコードで指定されているメールサーバーと通信します。
たとえば、ユーザーAが電子メールメッセージをUserA@noam.reskit.comに送信したその日にmailserver1がダウンし、mailserver2が稼動しているとします。ユーザーAのメーラーは、優先順位値が最も小さいmailserver1にメッセージを配信しようとしますが、mailserver1がダウンしているため失敗します。その後、mailserver2とmailserver3の優先順位値が等しいため、メーラーはどちらのサーバーでも選ぶことができます。今度はmailserver2にメッセージが配信されます。
メールのループを防ぐため、宛先ホストのMXとして指定されているホスト上のメーラーは、自分のローカルホストより優先順位値が低いMXにしかメッセージを配信できないようになっています。
注
MXレコードでCNAMEが参照されていないときにsendmailプログラムを使用する場合は、特に注意が必要です。
■|SRVレコード
MXレコードにより、ドメインの管理者は1つのDNSドメイン内に複数のメールサーバーを置くことができます。そのドメイン内のホストにメールを送信する必要があるメーラーは、メール交換サーバーの場所を見つけることができます。
WWWやtelnetなど、メーラー以外のアプリケーションについては、「サービス(SRV)リソースレコード」を使用します。これによって、特定のサービス、プロトコル、DNSドメインのサーバーの場所を指定できます。たとえば、ドメイン内に2台のWebサーバーがあるときは、Webサーバーとして機能するホストを指定するSRVリソースレコードを作成すれば、リゾルバがすべてのSRVリソースレコードを検索してWebサーバーが見つけられるようになります。
SRVレコードの形式は、次のとおりです。
_<サービス>._<プロトコル>.<名前> <TTL> <クラス> SRV <優先順位> <重み> <ポート> <ターゲット>
<サービス>フィールドには、httpまたはtelnetなどサービスの名前を指定します。サービスには、規格で定義されているものとローカルに定義されるものとがあります。
<プロトコル>フィールドには、TCPまたはUDPなどプロトコルを指定します。
<名前>フィールドには、リソースレコードが指しているドメイン名を指定します。
<TTL>フィールドと<クラス>フィールドは、前述のフィールドと同じです。
<優先順位>フィールドには、ホストの優先順位を表す値を指定します。クライアントは、この値が最も小さいホストとの通信を試みます。
<重み>フィールドは、負荷のバランスをとるための仕組みです。同じドメインの2つ以上のレコードで優先順位の値が同じとき、クライアントが別の方法で負荷のバランスをとらない限り、重みの値が大きなレコードほど頻繁にアクセスされます。
<ポート>フィールドには、このサービスに使用するホスト上のポートが入ります。
<ターゲット>フィールドには、このサービスをサポートするホストの完全修飾ドメイン名が入ります。
次に示すのは、WebサーバーのSRVレコードの例です。
_http._tcp.reskit.com. IN SRV 0 0 80webserver1.noam.reskit.com.
_http._tcp.reskit.com. IN SRV 10 0 80webserver2.noam.reskit.com.
注
この例のレコードには、TTLの値が指定されていません。そのため、リゾルバはSOAリソースレコードで指定されている最小TTLを使用します。
コンピュータがDNSドメインreskit.comのWebサーバーを見つける必要があるときには、リゾルバが次の照会を送信します。
_http._tcp.www.reskit.com.
DNSサーバーは、上の例にあるSRVレコードで応答します。応答を受け取ったリゾルバは、優先順位の値を調べてwebserver1とwebserver2のうち一方を選びます。webserver1の方が優先順位の値が「小さい」ため、DNSサーバーはwebserver1を選択します。
注
優先順位の値が同じで、重みの値が異なる場合、クライアントはWebサーバーを無作為に選択します。ただし、重みの値が「大きい」サーバーの方が、選択される可能性は高くなります。
次に、リゾルバはwebserver1.reskit.comのAレコードを要求し、DNSサーバーがAレコードを返します。最後に、クライアントがwebserver1との通信を試みます。
SRVレコードの詳細については、Web ResourcesのWebサイト(http://windows. microsoft.com/windows2000/reskit/webresources)で「Internet Engineering Task Force(IETF)」のリンクを参照してください。Windows 2000は、『DNS RR for specifying the location of services (DNS SRV)』というタイトルのインターネットドラフトをサポートします。
■|使用頻度の低いリソースレコード
図5.3に、上記以外のリソースレコードのいくつかとそれらを定義するRFCを示します。これらのリソースレコードの多くは、試験的なものとされています。
表5.3使用頻度の低いリソースレコード
レコードドタイプ
RFC
説明
|
AAAA
1886
ホスト(コンピュータまたはほかのネットワークデバイス)名をIPv6アドレスにマップする特殊なアドレスレコード。
AFSDB
1183
AFS(Andrew File System)セルのデータベースサーバー、またはDCE(Distributed Computing Environment:分散コンピューティング環境)セルの認証済みサーバーの場所を指定する。AFSシステムは、DNSを使用してDNSドメイン名をAFSセルデータベースサーバーの名前にマップする。OSF(Open Software Foundation)のDCEネームサービスは、同様の機能にDNSを使用する。
HINFO
1035
ホスト情報(HINFO)リソースレコード。ホストのハードウェアタイプとオペレーティングシステムを示す。CPUタイプとオペレーティングシステムのIDには、RFC 1700のリストに含まれているコンピュータ名とシステム名が使用される。
ISDN
1183
総合デジタル通信網(ISDN)リソースレコード。A(アドレス)レコードの形を変えたもの。FQDNをIPアドレスにマップする代わりに、ISDNレコードは名前をISDNアドレスにマップする。ISDNアドレスとは、国/地域コード、エリアコードまたは国/地域コード、国または地域内での電話番号、サブアドレス(省略可能)から構成される電話番号である。ISDNリソースレコードは、ルートスルー(RT)リソースレコードと同時に使用する。
MB
1035
メールボックス(MB)リソースレコード。特定のメールボックスを持つDNSホストを指定する試験的なレコード。関連するそのほかの試験的なレコードとして、メールグループ(MG)リソースレコード、メールボックスリネーム(MR)リソースレコード、メールボックス情報(MINFO)リソースレコードがある。
MG
1035
メールグループ(MG)リソースレコード。DNSドメインによって指定されるメールグループ(メーリングリスト)のメンバであるメールボックスを指定する。関連するほかの試験的なレコードとして、MBリソースレコード、MRリソースレコード、MINFOリソースレコードがある。
MINFO
1035
MINFOリソースレコードは、特定のメーリングリストまたはメールボックス管理担当者のメールボックスを指定する試験的なレコード。関連する試験的なレコードには、ほかにMBリソースレコード、MGリソースレコード、MRリソースレコードがある。
MR
1035
MRリソースレコードは、特定のメールボックスの適切な別名であるもう1つのメールボックスを指定する実験的なレコード。関連するほかの試験的なレコードとして、MBリソースレコード、MGリソースレコード、MINFOリソースレコードがある。
RP
1183
特定のDNSドメインまたはホストの責任者(Responsible Person:RP)を示す。
RT
1183
ルートスルー(RT)リソースレコード。宛先ホストへの経路を決定するための、中間に入るホストを指定する。RTレコードは、ISDNリソースレコード、X.25リソースレコードと同時に使用する。構文と意味はMXレコードタイプに似ていて、ほとんど同じように使用される。
TXT
1035
テキスト(TXT)リソースレコード。一般的なテキストの情報をDNSデータベース内の項目に関連付ける。主に、ホストの場所(たとえば「26Sビルの2499号室」)を示すのに使用される。1つのTXTレコードの長さは最大64KBまでで、複数の文字列を含むことができる。
WKS
1035
既知のサービス(WKS)リソースレコード。特定のIPアドレス上の特定のプロトコルによって提供されるサービスを記述する。プロトコルは通常UDPまたはTCPだが、Windows 2000プロトコルファイル(%SystemRoot%\System32\Drivers\Etc\Protocol)に示されているどのプロトコルも指定できる。サービスは、Windows 2000サービスファイル(%SystemRoot%\System32\ Drivers\Etc\Services)に示されているポート番号256より下のポート番号を指定できる。
X.25
1183
X.25リソースレコードは、A(アドレス)リソースレコードの形を変えたもの。FQDNをIPアドレスにマップする代わりに、X.25リソースレコードは名前をX.121アドレスにマップする。X.121は、X.25ネットワークで使用するアドレスの形式を規定するISO(International Organization for Standardization)規格。X.25リソースレコードは、ルートスルー(RT)リソースレコードと同時に使用するようになっている。
■|RFCで定義されていないリソースレコード
Windows 2000は、RFCで定義されているリソースレコードタイプのほかに表5.4のリソースレコードタイプを使用します。
表5.4RFCで定義されていないリソースレコード
名前
説明
|
WINS
Windows 2000 DNSサーバーは、自分が権限を持っているDNSゾーンに存在しないDNSのホスト部分の検索に、WINSサーバーを使用できる。
WINS逆引き参照(WINS-R)
このエントリは、与えられたIPアドレスからDNS名のホスト部分を取得する逆引き参照ゾーンとして使用される。DNSサーバーは、照会されたIPアドレスの権限を持っているゾーンにそのアドレスのレコードが含まれていなくて、かつWINS-Rリソースレコードに含まれている場合は、NetBIOSadapter status照会を出す。
ATMA
ATMAリソースレコードはATMフォーラムによって定義され、DNSドメイン名をATMアドレスにマップするため使用される。詳細については、ATMフォーラムの『ATM Name System Specification Version 1.0』を参照。
■|委任とGlueレコード
委任とGlueレコードは、サブドメインを別のゾーンに委任するために、ゾーンに追加するレコードです。「委任」は、委任対象のゾーンの権限を持っているネームサーバーを含んでいる親ゾーンにあるNSレコードで定義されます。Glueレコードは、委任対象ゾーンの権限を持っているネームサーバーのAレコードにより定義されます。
たとえば、DNSドメインreskit.comのネームサーバーが、noam.reskit.comゾーンの権限をネームサーバーnoamNS.noam.reskit.comに委任する場合は、次に示すレコードをreskit.comゾーンに追加します。
noam.reskit.com.INNS noamNS.noam.reskit.com
noamNS.noam.reskit.com.INA 172.16.54.1
委任は、名前解決のために必要です。委任対象ゾーンの権限を持っているネームサーバーが、委任対象ゾーンと同じドメインのメンバの場合は、Glueレコードも必要になります。この例でGlueレコードが必要なのは、noamNS.noam.reskit.com.が委任対象のドメインであるnoam.reskit.comのメンバだからです。別のドメインのメンバなら、リゾルバは標準の名前解決を実行して、権限を持つ名前サーバーの名前からIPアドレスを得ることができます。
リゾルバが子ゾーンの名前についての照会を、親ゾーンの権限を持っているネームサーバーに提出すると、親ゾーンの権限を持つサーバーはそのゾーンをチェックします。委任によって、照会された子ゾーンの権限を持っているネームサーバーが判断できます。その結果、親ゾーンの権限を持つサーバーは、リゾルバを照会することができます。
5.4.3ゾーン
リソースレコードを格納する内部データ構造は、DNS規格で定められていないため、DNSサーバーによって異なります。一般に、サーバーはそのサーバーにテキストファイルで格納されているゾーンを使用しますが、これは必須ではありません。Windows 2000では、DNSデータベースサービスをActive Directoryデータベースに統合できます。その場合、ゾーン情報もActive Directoryデータベースに格納されます。
最も一般的なDNSサーバーとして利用されるBIND(Berkeley Internet Name Domain)は、通常、表5.5に示すファイル名を使用します。
表5.5BINDで使用されているゾーン名
名前
説明
|
db.<ドメイン名>
前方参照ゾーン。たとえばDNSドメインがreskit.comの場合、ファイル名はdb.reskit.comになる。
db.<アドレス>
逆引き参照ゾーン。たとえば、ネットワークのアドレスがクラスCネットワークアドレスの172.16.32である場合、ファイル名はdb.172.16.32になる。
db.cache
「ルートヒントファイル」とも呼ぶ。このファイルには、ルートDNSドメインを維持するネームサーバーの名前とIPアドレスが入っている。このファイルは、基本的にインターネットルートDNSサーバーを使用するすべてのサーバーで同じだが、プライベートのルートDNSサーバーを使用するサーバーでは修正しなければならない(「ルートDNSサーバー」とは、名前空間のルートの権限を持つDNSサーバーのこと)。
db.127.0.0.1
ループバックアドレス用に使用される。基本的にすべてのネームサーバーで同じ。
データベースファイルの名前はDNSサーバーの構成時に指定します。その際、ファイル名を自由に付けることができます。既定では、Microsoft Windows 2000 DNSサーバーは代表的なBIND DNSサーバーと同じファイル名は使用せず、<ゾーン名>.dnsという名前を使用します。しかし、DNS dbファイルを別のDNSサーバーから移植する場合は、Microsoft Windows 2000 DNSサーバーでBINDのファイル名を使用するように設定することができます。
次に、ゾーンの中身について説明します。さらに、もう1つの追加ファイルであるBOOTファイルについても取り上げます。BOOTファイルはBINDサーバーによって使用されますが、DNS規格では定められていません。
■|前方参照ゾーン
前方参照ゾーンには、DNSドメイン内の名前を解決するのに必要な情報が入っています。SOAレコードとNSレコードは必ず含んでいなければなりません。PTRリソースレコードを除くすべてのタイプのリソースレコードを含むことができます。
■|逆引き参照ゾーン
逆引き参照ゾーンには、逆引き参照を実行するために必要な情報が入っています。通常は、SOAレコード、NSレコード、PTRレコード、CNAMEレコードを含んでいます。
クライアントはほとんどの照会で名前を指定し、その名前に対応するIPアドレスを要求します。通常、このタイプの照会は「前方参照」と言われます。
しかし、すでにコンピュータのIPアドレスを知っているクライアントがそのコンピュータのDNS名を調べたい場合もあります。IPアドレスからDNS名を知ることは、DNSサーバーのセキュリティを維持するためにも重要であり、TCP/IPネットワークのトラブルシューティングにも利用されます。DNS規格は、「逆引き参照」によってこうした処理を実現させています。
ただし、DNS名前空間のすべてのDNSドメインを検索しなければ逆引き参照に答えることができないとしたら、逆引き照会の検索対象が大きすぎて現実的とは言えません。
この問題を解決するために、in-addr.arpaと呼ばれる特別なDNSドメインが作成されました。このドメインは、IPアドレスのドット形式10進表記の数字を逆順にしたものを使用します。この配列により、in-addr.arpaドメインの下位の枝の管理をクラスA、B、またはCのIPネットワークを割り当てるのと同じように、企業や組織に委任することができます。クラスレス逆引き参照ゾーンの詳しい作成方法については、本書の「第6章 Windows 2000 DNS」を参照してください。また、RFC 2317『Classless IN-ADDR.ARPA delegation』も参照してください。
図5.5に、in-addr.arpa名前空間の枝を示します。
図5.5 in-addr.arpa名前空間
in-addr.arpaドメインツリーでは、PTRリソースレコードを格納し、IPアドレスから対応するFQDNへの逆引きマッピングを提供する必要があります。
IPアドレス172.16.44.1に対応するFQDNを見つける必要があるクライアントは、1.44.16.172.in-addr.arpaというドメイン名のPTRレコードについて照会します。
逆照会
逆引き参照のほかに、一部のDNSサーバーは「逆照会」と呼ばれるものもサポートします。逆引き参照と同様に、逆照会を行うクライアントはIPアドレスを伝え、FQDNを要求します。しかし、サーバーはin-addr.arpaドメインを使用して回答を見つけたり、ほかのサーバーに照会を行ったりせず、自分のゾーンで回答を探す処理しか行いません。回答が見つからなければ、エラーメッセージを返します。このため、逆照会では、サーバーもクライアントも、そのIPアドレスがサーバーのゾーンにないだけなのか、それともそのIPアドレス自体が存在しないのかを知る方法はありません。
逆参照のサポートはオプションであり、サーバーが確実な回答を提供できることがあまりないため、逆参照の使用は限られています。nslookupの初期のバージョンなど、特定のアプリケーションだけが逆参照を使用します。
Windows 2000サーバーは逆参照要求を受け取ると、照会の中で指定されているIPアドレスを角括弧([ ])で囲んで返します。たとえば、172.16.72.1についての逆照会を受け取ると、[172.16.72.1]を付けて返します。
逆参照の詳細については、RFC 1035を参照してください。
5.4.4ルートヒントファイル
「ルートヒントファイル」は「キャッシュヒントファイル」とも呼ばれ、権限を持っているDNSドメインの外部のホストに対する名前解決に必要なホスト情報を含んでいます。また、ルートDNSサーバーの名前とアドレスも含んでいます。
ネットワークがインターネットに接続している場合は、インターネット上のルートDNSサーバーのレコードが入ったルートヒントファイルが必要です。Windows 2000では、現在のインターネットルートDNSのマッピングが入ったルートヒントファイルがCache.dnsという名前で[%SystemRoot%\System32\Dns]フォルダにインストールされます。
この場合、キャッシュファイルのNSレコードとAレコードを、プライベートTCP/IPネットワークのルートの権限を持っているDNSサーバーのNSレコードとAレコードに置き換えなければなりません。
たとえば、2台の内部ルートDNSサーバー(InternalRoot1.reskit.com.とInternalRoot2 .reskit.com)を構築した場合を考えてみます。これらの内部ルートDNSサーバーを指すルートヒントファイルを、ネットワークのほかのDNSサーバー上に作成します。そうすれば、自分で解決できない照会を受け取ったほかのDNSサーバーは、ルートヒントファイルに指定された内部ルートサーバーに照会することができます。
次に示すreskitのルートヒントファイルには、reskit.comドメインのネームサーバーのNSリソースレコードと、名前からIPアドレスへのマッピングが入っています。
; インターネットの接続されていないreskit.comの内部ルートヒントファイル
. 86400INNSInternalRoot1.reskit.com.
. 86400INNSInternalRoot2.reskit.com.
InternalRoot1.reskit.com. 86400 IN NS172.16.64.1
InternalRoot2.reskit.com. 86400 IN NS172.16.64.2
注
Windows 2000の[DNSサーバーの構成]ウィザードは、ネットワークがインターネットに接続されているかどうかをできる限り調べます。そして、接続されていない場合は自分をルートサーバとして設定し、独自のキャッシュファイルを作成します。
5.4.5ブートファイル
ブートファイルは実際にはRFCで定義されてはいません。また、サーバーもRFCに準拠する必要はありません。ここでは、補足としてブートファイルを取り上げておきます。ブートファイルは、BINDだけに実装されているDNSの機能です。
Microsoftが実装するDNSは、既定ではこのファイルを使用しません。使用する必要があるときは、既存のBINDブートファイルをMicrosoft DNSサーバーに移植できます。Windows 2000 DNSサーバーは、BINDブートファイルの命令のサブセットだけをサポートします。しかも、BIND 4.x.xサーバーによって使用されるタイプの命令だけをサポートします。
BINDブートファイルは、DNSサーバーの起動時の動きを制御します。コマンドは行の先頭に記述しなければならず、コマンド前に空白を置くことはできません。表5.6に、Windows 2000がサポートするブートファイルコマンドの一部を示します。
表5.6ブートファイルコマンドの説明
コマンド
説明
|
Directory
ブートファイルで参照されるほかのファイルが置かれているディレクトリを指定する。
Cache
DNSサーバーがルートドメインのネームサーバーと通信するときに利用するファイルを指定する。このコマンドとその参照先のファイルは、必ず存在しなければならない。
Primary
ネームサーバーが権限を持つプライマリゾーンと、そのゾーンのリソースレコードが入ったゾーンファイルを指定する。このコマンドは複数指定できる。
Secondary
ネームサーバーが権限を持つセカンダリゾーンと、ゾーン転送の転送元として使用するマスタサーバーのIPアドレスのリストを指定する。また、このゾーンを保存するためのローカルファイルの名前も定義する。このコマンドは複数指定できる。
表5.7に、Windows 2000がサポートするブートファイルコマンドの一部の構文を示します。
表5.7Windows 2000がサポートするブートファイルコマンドの構文
構文
例
|
directory <ディレクトリ>
directory c:\winnts\system32\dns
cache <ファイル名>
cache cache
primary <ドメイン> <ファイル名>
primary reskit.com reskit.com.dnsprimary dev.reskit.com dev.reskit.com.dns
secondary <ドメイン> <ホストのリスト><ローカルファイル名>
secondary test.reskit.com 157.55.200.100 test.reskit.com.dns
forwarders <ホストのリスト>
forwarders 172.16.64.4 172.16.64.8
slave(forwardersのパラメータの後ろに付ける)
forwarders 172.16.64.4 172.16.64.8 slave
BINDブートファイルの詳細については、Web ResourcesのWebサイト(http://windows. microsoft.com/windows2000/reskit/webresources)で「Microsoft TechNet」のリンクを参照してください。そして、「structure」「domain name system」「boot file」というキーワードを入力して検索を実行してください。
5.5ゾーン転送
マスタサーバー上のゾーンに変更を加えたときは、「ゾーン転送」という仕組みを使用し、変更後のゾーンをそのゾーンのすべてのセカンダリサーバーに複製を作成しなければなりません。最初のDNS仕様では、利用できるゾーン転送の形が「完全ゾーン転送」と呼ばれるものだけでした。新しいRFCでは、「増分ゾーン転送」と呼ばれるもう1つのゾーン転送について記述されています。ここでは、両方のタイプのゾーン転送を取り上げます。また、ゾーンファイルに変更が加えられたときに、ゾーンのマスタサーバーがセカンダリサーバーにゾーンの転送を通知できる仕組み、つまりDNS通知についても取り上げます。
5.5.1完全ゾーン転送
最初のDNS仕様で定義されている完全ゾーン転送では、ゾーンのマスタサーバーが、ゾーンデータベース全体をそのゾーンのセカンダリサーバーに送信します。セカンダリサーバーは、次の手順で完全ゾーン転送を開始します。
ゾーンのセカンダリサーバーが特定の時間(SOAリソースレコードの更新間隔のフィールドで指定された値)だけ待機し、マスタサーバーにポーリングしてSOAを要求します。
ゾーンのマスタサーバーがSOAリソースレコードを返します。
ゾーンのセカンダリサーバーは、返されたシリアル番号を、自分のレコードのシリアル番号と比較します。ゾーンのマスタサーバーから転送されたシリアル番号が、自分のシリアル番号より大きいときは、自分のゾーンデータベースが古くなったと判断し、AXFR要求(完全ゾーン転送の要求)を送信します。
ゾーンのマスタサーバーが、ゾーンデータベース全体をセカンダリサーバーに送信します。
ゾーンのマスタサーバーがセカンダリサーバーのポーリングに応答しない場合、セカンダリサーバーは、SOAリソースレコードの再試行間隔のフィールドに指定されている時間が経過した後に、ポーリングを続けます。最後にゾーン転送が成功してから、有効期間のフィールドに指定されている時間が経過しても応答がないときは、ゾーンを破棄します。
注
4.9.4より前のバージョンのBINDを実行しているネームサーバーは、完全ゾーン転送の実行中に、1メッセージあたり1つのリソースレコードしか送受信できません。BIND 4.9.4以降を実行しているネームサーバーとWindows 2000サーバーは、1つのメッセージで複数のリソースレコードを送受信できるため、完全ゾーン転送時のパフォーマンスが向上します。 しかし、Windows 2000を実行するネームサーバーは、ゾーンのセカンダリサーバーの中にWindowsを実行していないものがあると、既定では、1メッセージあたり1つのリソースレコードを送信します(旧バージョンとの互換性維持のためです)。ゾーンのセカンダリサーバー(Windows以外のサーバー)がBIND 4.9.4以降を実行している場合は、1メッセージあたり複数のリソースレコードを送信するようにWindows 2000を設定すると、パフォーマンスが向上します。詳細については、Web ResourcesのWebサイト(http://windows.microsoft.com/windows2000/ reskit/webresources)で「Microsoft TechNet」のリンクを参照してください。そして、「DNS Compatibility」、「BIND」、「4.9.4」というキーワードを入力して検索を実行してください。
5.5.2増分ゾーン転送
完全ゾーン転送は、特にDNS構成が複雑になると、ネットワーク帯域幅を大量に使用する可能性があります。この問題を解決するために、新しい規格である増分ゾーン転送がRFC 1995で追加されました。増分ゾーン転送では、ゾーンの変更された部分だけを送信しなければなりません。
増分ゾーン転送のしくみは、完全ゾーン転送とほぼ同じです。ゾーンのセカンダリサーバーは、ゾーンのマスタサーバーにポーリングするタイミングや再試行のタイミングなどをSOAリソースレコードによって決定します。一方、ゾーン転送を実行する必要があるときは、AXFR照会の代わりに増分ゾーン転送照会(IXFR照会)を送信し、増分ゾーン転送をマスタサーバーに要求します。
ゾーンのマスタサーバーは、ゾーンの最新のバージョン履歴を保持し、ゾーンの最近のバージョン更新で行われたレコードの変更を記録します。ゾーンのマスタサーバーは、IXFR照会を受け取った時点でゾーンに新しいバージョンがあった場合、セカンダリサーバーのゾーンとマスタサーバーの最新のゾーンとの間に行われたレコードの変更だけを、ゾーンのセカンダリサーバーに送信することができます。マスタサーバーは、更新内容の古い順に送信します。
セカンダリサーバーは増分ゾーン転送を受け取ると、ゾーンの新しいバージョンを作成し、更新前のリソースレコードを古い順に更新後のリソースレコードに置き換えていきます。すべての更新が終わると、ゾーンの古いバージョンを新しいバージョンに置き換えます。
ゾーンのマスタサーバーは必ずしも増分ゾーン転送を行う必要はありません。増分ゾーン転送をサポートしていない場合、増分ゾーン転送を実行するために必要なデータが不足している場合、あるいは増分ゾーン転送の方が完全ゾーン転送より多くの帯域幅を必要とするような場合は、完全ゾーン転送を実行します。
増分ゾーン転送によって必要なネットワーク帯域幅は狭くなりますが、マスタサーバー側にバージョン履歴を記録するためのディスク容量が必要になります。ディスクの空き容量を増やしたいときは、バージョン履歴を削除できます。
5.5.3DNS通知
RFC 1996で定義されている「DNS通知(DNS NOTIFY)」は、DNS規格へ加えられた改訂です。その内容は、ゾーンのマスタサーバーがそのゾーンの特定のセカンダリサーバーに変更を通知することによって、通知を受けたセカンダリサーバーがゾーン転送を開始する必要があるかどうかを確認できるようにするというものです。DNS通知は、セカンダリサーバー間でゾーンの一貫性を向上させるのに役立ちます。
変更内容の通知先のセカンダリサーバーを決定するために、ゾーンのマスタサーバーは通知リストを保持します。その内容は、通知先セカンダリサーバーのIPアドレスのリストです。ゾーンのマスタサーバーは、ゾーンの更新が行われたときにリストに含まれているサーバーだけに通知を行います。
ゾーンのマスタサーバーのローカルゾーンが更新されると、次のイベントが行われます。
更新後のゾーンファイルがディスクに書き込まれると、SOAレコードのシリアル番号のフィールドが更新されます。
マスタサーバーが通知リストに含まれているほかのサーバーに通知メッセージを送信します。
通知メッセージを受け取ったゾーンのすべてのセカンダリサーバーは、通知元マスタサーバーにSOAタイプの照会を送信することによってこれに応答し、照会によって受け取ったレコードから、通知元サーバーのゾーンがローカルコンピュータに格納されているゾーンのコピーより新しいかどうかを調べます。
通知を受けたセカンダリサーバーは、通知元マスタサーバーのゾーンに含まれるSOAレコードで使用されているシリアル番号の方が、ローカルコンピュータに格納されているゾーンのコピーに含まれるシリアル番号より大きい(新しい)と判断すると、AXFRゾーン転送またはIXFRゾーン転送を要求します。
注
Windows 2000を実行しているサーバーでは、ゾーンの変更の通知方法を設定できます。
5.6動的更新
動的更新は、ゾーンのプライマリサーバー上でクライアントがゾーンデータを動的に更新する方法を定めた新しい規格(RFC 2136)です。
もともと、DNSはゾーンデータベースへの静的な更新だけをサポートするように設計されました。静的DNSの設計上の制約により、リソースレコードの追加、削除、変更は、DNSシステム管理者が手作業で行うしかありません。
たとえば、DNSシステム管理者がゾーンのプライマリサーバー上のレコードを編集すると、変更後のゾーンデータベースがゾーン転送中に、セカンダリサーバーに伝達されます。この設計は、変更の回数が少なくて更新の頻度が低い場合には問題はありませんが、そうでないときは収拾がつかなくなります。
一方、動的更新では、動的更新をサポートする別のコンピュータやデバイスによって開始された更新を許可するように、ゾーンのプライマリサーバーを設定できます。たとえば、AリソースレコードまたはPTRリソースレコードを登録しているワークステーションや、DHCPサーバーから更新を受け取ることができます。更新は、標準のUPDATEメッセージの形式を使用して送信され、個々のリソースレコード(RR)またはリソースレコードの集合(RRset)の追加または削除を含むことができます。UPDATEメッセージ形式の詳細については、RFC 2136を参照してください。
動的更新の要求に応えるための前提条件を設定することもできます。前提条件が設定されている場合は、すべての条件が満たされないと更新が行われません。設定可能な前提条件の例をいくつか紹介します。
必要なRRまたはRRsetがすでに存在しているか、更新より前に使用されていること
必要なRRまたはRRsetが存在しないか、更新より前に使用されていないこと
指定されたRRまたはRRsetの更新の開始を要求側が認められていること
更新を行うには、それぞれの前提条件が満たされていなければなりません。設定されているすべての条件が満たされると、ゾーンのプライマリサーバーはローカルゾーンの更新を始めることができます。互いの更新結果に依存していなければ、複数の更新を同時に処理することができます。
5.7DNSの規格
1987年に規格として受け入れられて以来、核となるDNS規格(RFC 1034と1305)は十分に確立されましたが、その間にも数多くの改訂が行われています。これらの改訂は、追加のRFCやインターネットドラフトとして個別に作成され、IETFに提出されたものです。RFCやインターネットドラフトは、広く公開され、多くの評価を経た上で、インターネット全体の規格として受け入れられるようになります。
表5.8に、Windows 2000がサポートするRFCの規格および規格勧告を示します。
表5.8Windows 2000がサポートするDNS関連のRFC規格
番号
ステータス
タイトル
|
1034
Standard(規格)
Domain Names - Concepts and Facilities
1035
Standard(規格)
Domain Names - Implementation and Specification
1123
Standard(規格)
Requirements for Internet Hosts - Application and Support
1886
Proposed(規格勧告)
DNS Extensions to Support IP Version 6
1995
Proposed(規格勧告)
Incremental Zone Transfer in DNS
1996
Proposed(規格勧告)
A Mechanism for Prompt DNS Notification of Zone Changes
2136
Proposed(規格勧告)
Dynamic Updates in the Domain Name System (DNS UPDATE)
2181
Standards Track(評価中の仕様)
Clarifications to the DNS Specification
2308
Standards Track(評価中の仕様)
Negative Caching of DNS Queries (DNS NCACHE)
5.8補足情報
DNSの概念の詳細については、『DNS & BIND第3版』(Paul Albitz、Cricket Liu著、小館 光正 訳、高田 広章、小島 育夫 監訳、1999年、オーム社)を参照してください。
RFC(Request for Comments)とインターネットドラフトの詳細については、Web Resourcesページ(http://windows.microsoft.com/windows2000/reskit/webresources)にある「IETF」へのリンクを参照してください。