第 12章BIND
インターネットを含む、殆どの最近のネットワーク上で、ユーザーは他のコンピュータを名前で 探します。これによりユーザーは、ネットワークリソースのネットワークアドレス番号を記憶する 煩わしさから免れます。そんな名前ベースの接続を許可するネットワークを効率的に設定するには、 DNS(Domain Name Service)あるいは、 ネームサーバーを設定します。これによりネットワーク上のホスト名を 数値アドレスに、又はその逆方向に解決するものです。
この章ではRed Hat Linuxに収納されているネームサーバーであるBIND (Berkeley Internet Name Domain)DNSサーバーの設定ファイル の構造に焦点を置きながら、それがローカル及びリモートで管理される方法を説明します。
Bind 設定ツール(redhat-config-bind)を使用したBIND設定の 仕方については、Red Hat Linux カスタマイズガイド内のBINDの設定の章を参照して下さい。
 | 警告 |
|---|---|
Bind 設定ツールを使用する場合は、手動で編集しないで下さい。 どんな変更もすべてBind 設定ツールを再使用するときに上書き されてしまいます。 |
12.1. DNSについて
ネットワーク上のホストがホスト名(完全修飾ドメイン名（FQDN）とも呼びます)を 使用して別のホストに接続する時、そのホストのマシンの名前をそのIPアドレスに関連付ける為にDNSが使用 されます。
DNS と FQDNを使用すると、システム管理者はマシンに対する名前ベースのクエリに影響することなく IPアドレスをホストに変換する柔軟性を持てる利点があります。また、管理者は名前ベースのクエリを 処理するマシンを入れ換えることが出来ます。
DNSは、通常幾つかのドメインに対し権限を所有し、他のドメイン用の DNSサーバーを参照する中央設置のサーバーを使用して実装されます。
クライアントホストがネームサーバーからの情報を要求すると、通常それはポート53に 接続されます。それからネームサーバーはリゾルバライブラリをベースにしてFQDNを 解決しようとします。このリゾルバライブラリには、要求されたホストに関して又は 以前のクエリのキャッシュデータの権限情報を収納している可能性があります。もし、 ネームサーバーがリゾルバライブラリに解答を持っていない場合は、ルート ネームサーバーと呼ばれる他のネームサーバーにクエリをして、課題となって いるFQDN用の権限を持つネームサーバーを判定します。その後、その情報を使用して その権限ネームサーバーにクエリし、要求のあったホストのIPアドレスを決定します。 逆引きのクエリをしている場合、名前ではなく不明なIPアドレスでクエリされる こと以外は同じ手順が使用されます。
12.1.1. ネームサーバーゾーン
インターネット上では、ホストのFQDNは異なるセクションの分割することが出来ます。 これらのセクションはツリーのように階級として構成され、その内容は主幹、1次分岐、 2次分岐、などとなります。次のようなFQDNを考えてみましょう：
bob.sales.example.com |
特定のシステムに関連しているIPアドレスを取得する為にFQDNを解決する方法を考える場合、 名前は右から左へ読む必要があります。それぞれの階級はピリオド(.)で 区切られています。この例では、comがこのFQDN用の トップレベルドメインを示します。exampleと 言う名前は、comの下のサブドメインで、salesは またexampleの下のサブドメインです。最も左側の名前bobは そのマシンを識別するホスト名です。
ホスト名を除く、それぞれのセクションはゾーンと呼ばれ、 特定のネーム空間を定義します。ネーム空間はその サブドメインの左側の名前を制御します。この例では2つしかサブドメインを 含んでいませんが、FQDNは最低限の1つのサブドメインが設定されている限り、 ネーム空間の構成に応じてそれ以上含むことが出来ます。
ゾーンは、ゾーンファイルの使用を通じて権限のある ネームサーバー上で定義されます。これがそのゾーンのネーム空間、その特定の ドメイン又はサブドメインで使用するメールサーバー、その他を記述します。 ゾーンファイルは、本来の権限が所在しファイルが変更される場所である プライマリネームサーバー(別名：マスターネームサーバー)と、 そのプライマリネームサーバーからそれらのゾーンファイルを受け取る セカンダリネームサーバー(別名：スレーブネームサーバー)に 保存されます。どのネームサーバーでも同時に異なるゾーン用のプライマリと セカンダリネームサーバーになることが可能で、それらもまた、複数ゾーン用の 権限として考慮できます。それはネームサーバーの構成の仕方により決定 されるものです。
12.1.2. ネームサーバーのタイプ
プライマリネームサーバー設定には4つのタイプがあります。
master —あるネーム空間に対するオリジナルの権限あるゾーンレコードを保存し、そのネーム空間に関する回答を探している他のネームサーバーからの質問に回答します。
slave — このサーバーに権限があると考えられているネーム空間に関して、他のネームサーバーからのクエリに回答します。しかし、スレーブネームサーバーは、マスターネームサーバーからネーム空間情報を入手します。
caching-only — 名前からIPへの解決を行うサービスを提供しますが、どのゾーンにも権限を持っていません。すべての解決に対して回答は一定期間メモリ内のデータベースにキャッシュされます。キャッシュ期間は通常検索されたゾーンレコードによって指定されます。
forwarding — 解決を行うべきネームサーバーの一覧に要求を転送します。指定されたネームサーバーのうちどのネームサーバーも解決することができない場合、処理は停止し、解決は失敗します。
ネームサーバーは、上記のタイプのうち1つのタイプであるか、複数のタイプであることが可能です。たとえば、あるネームサーバーはあるゾーンではマスターであり、他のゾーンではスレーブであってもかまいませんし、解決転送だけを提供するものであってもかまいません。
12.1.3. ネームサーバーとしてのBIND
BINDネームは/usr/sbin/namedを通して名前解決サービスをします。 BINDはまた、/usr/sbin/rndcと言う管理ユーティリティも含んで います。rndcに関する詳細は、項12.4の 中で御覧になれます。
BINDでは、以下の2ヶ所にその設定ファイルが格納されています：
/etc/named.conf — namedデーモン用の 設定ファイル。
/var/named/ディレクトリ — namedの 作業ディレクトリで、ゾーン、静的、キャッシュのファイルをそれぞれ格納します。
以下の数ヶ所のセクションで、BIND設定ファイルを詳細に説明します。