第 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の設定の章を参照して下さい。

警告警告
 

ドメイン名サービス設定ツールを使用する場合は、手動で編集しないで下さい。 どんな変更もすべてドメイン名サービス設定ツールを再使用するときに上書きされてしまいます。

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設定ファイルを詳細に説明します。