章 12章. BIND (Berkeley Internet Name Domain)

インターネットなど、殆どの最近のネットワーク上で、ユーザーは他のコンピュータを名前で探します。これによりユーザーは、ネットワークリソースのネットワークアドレス番号を記憶する煩わしさから免れます。このような名前ベースの接続を許可するネットワークを効率的に設定するには、 DNS(Domain Name Service)あるいは、 ネームサーバーを設定します。これによりネットワーク上のホスト名を数値アドレスに、又はその逆方向に解決します。

この章では Red Hat Enterprise Linux に収納されているネームサーバーであるBIND (Berkeley Internet Name Domain)DNSサーバーについて、その設定ファイルの構造に焦点を置きながら、ローカル及びリモートで管理する方法を説明します。

グラフィカルなドメイン名サービス設定ツール(redhat-config-bind)を使用したBINDの設定方法については、Red Hat Enterprise Linux システム管理ガイド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は、以下の場所にその設定ファイルを格納しています。

  • /etc/named.confnamedデーモン用の 設定ファイル。

  • /var/named/ディレクトリ — namedの作業ディレクトリで、ゾーン、静的、キャッシュのファイルをそれぞれ格納します。

以下の数ヶ所のセクションで、BIND設定ファイルを詳細に説明します。