14.2. BIND

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

14.2.1. named サービスの設定

named サービスが始まると、表14.1「named サービスの設定ファイル」 説明してあるように、ファイルから設定を読み込みます。

表14.1 named サービスの設定ファイル

パス 詳細
/etc/named.conf 主要設定ファイル
/etc/named/ 主要設定ファイル内に含まれている設定ファイル用の補助ディレクトリ
設定ファイルは、弓括弧で囲まれた入り子オプションを持つステートメントの集合で成り立っています。このファイルを編集する時は、構文エラーを出さないように注意する必要があります。もしエラーがあると named サービスは開始しません。標準的な /etc/named.conf ファイルは以下のような構成となります: 
statement-1 ["statement-1-name"] [statement-1-class] {
  option-1;
  option-2;
  option-N;
};
statement-2 ["statement-2-name"] [statement-2-class] {
  option-1;
  option-2;
  option-N;
};
statement-N ["statement-N-name"] [statement-N-class] {
  option-1;
  option-2;
  option-N;
};

注記

bind-chroot パッケージをインスト－ルしているならば、BIND サービスは /var/named/chroot 環境内で実行出来ます。その場合、初期化スクリプトが、mount --bind コマンドを使用して上記の設定ファイルをマウントするため、この環境外でも設定の管理ができるようになります。

14.2.1.1. 一般的なステートメントのタイプ

以下のタイプのステートメントが一般的に /etc/named.conf で使用されます:
acl
acl (Access Control List) (アクセス制御リスト) ステートメントにより、ホストのグループを定義できるようになるため、それらのホストはネームサーバーへのアクセスを許可/拒否できるようになります。以下の形式を取ります: 
acl acl-name {
  match-element;
  ...
};
acl-name ステートメント名はアクセス制御リストの名前です。そして match-element オプションは通常、個別の IP アドレス (10.0.1.1 など) または、CIDR (クラスレス ドメイン間ルーティング) ネットワーク表記 (例えば、10.0.1.0/24) です。定義済みキーワードの一覧については 表14.2「事前定義のアクセス制御一覧」 を参照してください。

表14.2 事前定義のアクセス制御一覧

キーワード 詳細
any すべての IP アドレスに一致
localhost ローカルシステムで使用中のすべての IP アドレスに一致
localnets ローカルシステムが接続しているすべてのネットワーク上の IP アドレスに一致
none いずれの IP アドレスにも一致しない
acl ステートメントは options などの他のステートメントとの併用で特に便利です。例14.2「options との併用で acl の使用」 は black-hats と red-hats の２つのアクセス制御一覧を定義して、red-hats に通常アクセスを許可する一方で black-hats をブラックリストに追加します。

例14.2 options との併用で acl の使用

acl black-hats {
  10.0.2.0/24;
  192.168.0.0/24;
  1234:5678::9abc/24;
};
acl red-hats {
  10.0.1.0/24;
};
options {
  blackhole { black-hats; };
  allow-query { red-hats; };
  allow-query-cache { red-hats; };
};
include
include ステートメントにより、ファイルを /etc/named.conf 内に含むことが出来るため、機密性のあるデータを制限付き権限で別のファイルに配置することができます。以下の形式を取ります 
include "file-name"
file-name ステートメント名はファイルへの絶対パスとなります。

例14.3 /etc/named.conf へファイルをインクルードする

include "/etc/named.rfc1912.zones";
options
options ステートメントにより、グローバルサーバー設定オプションを定義できると共に他のステートメントのデフォルトをセットすることも出来ます。これは named の作業ディレクトリの場所、許可されるクエリのタイプ、及びその他多くを指定するのに使用されます。以下の形式を取ります: 
options {
  option;
  ...
};
頻繁に使用される option 指示文の一覧については、以下の 表14.3「一般的に使用されるオプション」 をご覧下さい。

表14.3 一般的に使用されるオプション

オプション 詳細
allow-query 権限のあるリソースレコード用のネームサーバーにクエリを許可されるホストを指定します。これはアクセス制御一覧、IP アドレスの集合、または CIDR 表記にあるネットワーク群などを受け付けます。デフォルトではすべてのホストが許可されています。
allow-query-cache 回帰的クエリなど権限の必要ないデータ用のネームサーバーにクエリを許可されるホストを指定します。デフォルトでは、localhost と localnets のみが許可されています。
blackhole ネームサーバーにクエリを許可されないホストを指定します。このオプションは、特定のホストやネットワークがサーバーに要求を集中させる時には使用すべきではありません。デフォルトのオプションは none です。
directory named サービス用の作業ディレクトリを指定します。デフォルトのオプションは /var/named/ です。
dnssec-enable DNSSEC 関連のリソースレコードを返すかどうかを指定します。デフォルトのオプションは yes です。
dnssec-validation DNSSEC を介してリソースが純正であることを証明するかどうかを指定します。デフォルトのオプションは yes です。
forwarders 解決の為に要求を転送すべき相手のネームサーバーの有効な IP アドレス一覧を指定します。
forward
forwarders 指示文の動作を指定します。以下のオプションを受け付けます:
  • first — サーバーは、それ自身で名前の解決を試行する前に forwarders 指示文に一覧表示されているネームサーバーにクエリします。
  • only — forwarders 指示文に一覧表示されたネームサーバーにクエリすることが出来ない時は、サーバーはそれ自身での名前解決を試行しません。
listen-on クエリのリッスン先として IPv4 ネットワークインターフェイスを指定します。ゲートウェイとして機能する DNS サーバー上では、このオプションを使用することで単独ネットワークから由来するクエリのみに応答することができます。すべての IPv4 インターフェイスがデフォルトで使用されています。
listen-on-v6 クエリのリッスン先として IPv6 ネットワークインターフェイスを指定します。ゲートウェイとして機能する DNS サーバー上では、このオプションを使用することで単独ネットワークから由来するクエリのみに応答することができます。すべての IPv6 インターフェイスがデフォルトで使用されています。
max-cache-size サーバー用キャッシュとして使用されるメモリーの最大容量を指定します。最大値に到達すると、その限度を超過しないようにサーバーは記録が早期期限切れになるようにします。複数表示を持つサーバーでは、この制限は各表示のキャッシュ毎に別々に適用されます。デフォルトのオプションは 32M です。
notify
あるゾーンが更新された時にセカンダリネームサーバーに通知するかどうかを指定します。以下のオプションを受け付けます:
  • yes — サーバーはすべての セカンダリネームサーバーに通知します。
  • no — サーバーはいずれの セカンダリネームサーバーにも通知しません。
  • master-only — サーバーはゾーン用のプライマリサーバーにのみ通知します。
  • explicit — サーバーは、ゾーンステートメント内の also-notify 一覧に指定してあるセカンダリサーバーにのみ通知します。
pid-file named サービスで作成されたプロセス ID ファイルの場所を指定します。
recursion 再帰的なサーバーとして動作するかどうかを指定します。デフォルトのオプションは yes です。
statistics-file 統計ファイルの代替の場所を指定します。デフォルトでは、/var/named/named.stats ファイルがデフォルトで使用されています。

重要

配信されるサービス拒否 (DDoS) 攻撃を阻止するために、allow-query-cache オプションを使用することで、クライアントの特定サブセット用にのみ再帰的な DNS サービスを制限することをお薦めします。
利用可能なオプションの完全な一覧を見るには 「インストールされているドキュメント」 内で参照されている『BIND 9 Administrator Reference Manual』 及び named.conf man ページを参照して下さい。

例14.4 オプションステートメントの使用

options {
  allow-query       { localhost; };
  listen-on port    53 { 127.0.0.1; };
  listen-on-v6 port 53 { ::1; };
  max-cache-size    256M;
  directory         "/var/named";
  statistics-file   "/var/named/data/named_stats.txt";

  recursion         yes;
  dnssec-enable     yes;
  dnssec-validation yes;
};
zone
zone ステートメントにより、その設定ファイルの場所やゾーン特有のオプションなどのゾーンの特性を定義できるようになり、グローバル options ステートメントを上書きするのに使用することができます。以下の形式を取ります: 
zone zone-name [zone-class] {
  option;
  ...
};
zone-name 属性はゾーンの名前であり、zone-class はゾーンのオプションクラスであり、そして option は 表14.4「一般的に使用されるオプション」 で説明してあるように zone ステートメントのオプションです。
zone-name 属性は特に重要です。それは、/var/named/ ディレクトリに配置されている該当ゾーンファイル内で使用される $ORIGIN 指示文に割り当てられたデフォルトの値だからです。named デーモンはゾーンの名前を、ゾーンファイル内に一覧表示された非完全修飾型のドメイン名のいずれかに追記します。例えば、zone ステートメントが example.com 用にネームスペースを定義する場合、example.com を zone-name として使用すると、それを example.com ゾーンファイル内のホスト名の末尾に配置することができます。
ゾーンファイルの詳細情報については、「ゾーンファイルの編集」 を参照して下さい。

表14.4 一般的に使用されるオプション

オプション 詳細
allow-query このゾーンに関する情報要求が出来るクライアントを指定します。このオプションは、グローバル allow-query オプションを上書きします。デフォルトではすべてのクエリ要求が許可されます。
allow-transfer ゾーン情報の転送要求を許可されるセカンダリサーバーを指定します。デフォルトでは、すべての転送要求が許可されています。
allow-update
自身のゾーン内で動的な情報更新を許可されるホストを指定します。デフォルトオプションでは、すべての動的更新要求は拒否されます。
そのゾーンに関してホストの情報更新の許可には注意が必要です。サーバーが信頼できるネットワークにある場合意外は、このオプションで IP アドレスをセットしないで下さい。その代わりに、「Transaction SIGnatures トランザクション署名 (TSIG)」 で説明してあるように TSIG キーを使用します。
file ゾーンの設定データを収納している named 作業ディレクトリ内のファイル名を指定します。
masters 信頼できるゾーン情報の要求先の IP アドレスを指定します。このオプションは、ゾーンが type slave として定義されている場合にのみ使用されます。
notify
あるゾーンが更新された時にセカンダリネームサーバーに通知するかどうかを指定します。以下のオプションを受け付けます:
  • yes — サーバーはすべての セカンダリネームサーバーに通知します。
  • no — サーバーはいずれの セカンダリネームサーバーにも通知しません。
  • master-only — サーバーはゾーン用のプライマリサーバーにのみ通知します。
  • explicit — サーバーは、ゾーンステートメント内の also-notify 一覧に指定してあるセカンダリサーバーにのみ通知します。
type
ゾーンのタイプを指定します。以下のオプションを受け付けます:
  • delegation-only — COM、NET、ORG などのインフラストラクチャゾーンの委任ステータスを強制します。明示的あるいは暗示的な委任の無い受信回答は NXDOMAIN として取り扱われます。このオプションは、再帰的あるいはキャッシング実装で使用される TLD もしくは root のゾーンのファイルにのみ適用されます。
  • forward — このゾーンに関する情報へのすべての要求を他のネームサーバーに転送します。
  • hint — ゾーンが他の方法で認知されていない時にクエリを解決する root ネームサーバーへポイントするために使用される特殊タイプのゾーンです。
  • master — このゾーン用の権威としてネームサーバーを指名します。ゾーンの設定ファイルがシステム上に存在する場合は、ゾーンは master としてセットされる必要があります。
  • slave — このゾーン用のスレーブとしてネームサーバーを指名します。マスターサーバーは masters 指示文内に指定されています。
プライマリまたはセカンダリのネームサーバーの /etc/named.conf ファイルに対するほとんどの変更には、zone ステートメントの追加、修正、または削除が含まれ、通常は zone ステートメントオプションの小さなサブセットのみが、ネームサーバーの良好な機能のために必要となります。
例14.5「プライマリネームサーバー用のゾーンステートメント」 では、ゾーンは example.com として識別されており、タイプは master にセットされて、named サービスは /var/named/example.com.zone ファイルを読み込むように指示されています。これはまた、ゾーンの転送にセカンダリネームサーバー (192.168.0.2) だけを許可します。

例14.5 プライマリネームサーバー用のゾーンステートメント

zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-transfer { 192.168.0.2; };
};
セカンダリサーバーの zone ステートメントは少し異なります。タイプは slave にセットされて、masters 指示文は named にマスターサーバーの IP アドレスを伝えています。
例14.6「セカンダリネームサーバー用のゾーンステートメント」 では、named サービスは、192.168.0.1 IP アドレスにあるプライマリサーバーに対して example.com ゾーンの情報についてクエリをするように設定されています。受信した情報はその後、/var/named/slaves/example.com.zone ファイルに保存されます。すべてのスレーブゾーンを /var/named/slaves ディレクトリに配置することに注意して下さい。そうしないとサービスはゾーンの転送に失敗します。

例14.6 セカンダリネームサーバー用のゾーンステートメント

zone "example.com" {
  type slave;
  file "slaves/example.com.zone";
  masters { 192.168.0.1; };
};

14.2.1.2. その他のステートメントタイプ

以下のタイプのステートメントは、/etc/named.conf 内では通常多くは使用されません:
controls
controls ステートメントにより各種設定が可能になり、named サービスを管理するための rndc コマンドの使用に必要な様々なセキュリティ要件を設定できるようになります。
rndc ユーティリティとその使用法の詳細については、「rndc ユーティリティの使用」 を参照してください。
key
key ステートメントによって、特定のキーを名前で定義できるようになります。キーは、安全な更新や、あるいは、rndc コマンドの使用など各種動作を認証するために使用されます。２つのオプションが key と一緒に使用されます:
  • algorithm アルゴリズム名 — 使用されるアルゴリズムのタイプ (例えば、 hmac-md5)。
  • secret "キー値" — 暗号化キーです。
rndc ユーティリティとその使用法の詳細については、「rndc ユーティリティの使用」 を参照してください。
logging
logging ステートメントにより、チャンネル (channels) と呼ばれる複数のログタイプを使用できるようになります。channel オプションをステートメント内で使用すると、それ自身のファイル名 (file)、サイズ制限 (size)、バージョン制御 (version)、及び重要度レベル (severity) などを持つカスタマイズしたログのタイプを構築することが出来ます。カスタムチャンネルが定義されると、category オプションの使用でチャンネルが分類化されて、named サービスが再開始した時にロギングが始まります。
デフォルトでは、named は標準メッセージを rsyslog デーモンに送信して、受信したデーモンはメッセージを /var/log/messages に配置します。数種類の標準チャンネルが各種重要度レベルで BIND に組み込まれています。それらの重要度レベルとして、default_syslog (情報ロギングメッセージを処理) とdefault_debug (特にデバッギングメッセージを処理) などがあります。default と呼ばれるデフォルトカテゴリは組み込み型チャンネルを使用して特別な設定無しで普通のロギングを行います。
ロギングプロセスのカスタマイズは入り込んだプロセスとなるため、この章の範囲外になります。カスタム BIND ログ作成の詳細については、「インストールされているドキュメント」 で参照してある 『BIND 9 Administrator Reference Manual (BIND 9 管理者リファレンスマニュアル)』 をご覧下さい。
server
server ステートメントにより、named サービスがリモートのネームサーバーに対しての反応の仕方に影響する、特に通知とゾーン転送に関して影響するオプションを指定できるようになります。
transfer-format オプションは、各メッセージと共に送信されるリソースレコードの数量を制御します。これは、one-answer (１つのリソースレコードのみ)、かまたは many-answers (複数のリソースレコード) のいずれかになります。many-answers オプションがより効率的ですが、BIND の旧バージョンではサポートされていないことに注意して下さい。
trusted-keys
trusted-keys ステートメントにより、安全な DNS (DNSSEC) 用に使用される各種パブリックキーを指定できるようになります。このトピックの詳細については、「DNSSEC (DNS Security Extensions)」 を参照して下さい。
view
view ステートメントにより、ネームサーバーをクエリしているホストが存在するネットワークに応じて特別な表示を作成できるようになります。これによって、一部のホストはゾーンに関して１つの応答を受信することが出来て、他のホストは全く異なる情報を受信することが出来るようになります。別の観点から、一定のゾーンは特定の信頼されるホストにだけ利用可能であり、信頼できないホストは他のゾーンのクエリしかできない可能性もあります。
複数表示はその名前が特有である限り使用できます。match-clients オプションにより、特定の表示に適用する IP アドレスを指定できるようになります。options ステートメントが 1つの表示内で使用された場合は、既に設定済みのグローバルオプションを上書きします。最後に、ほとんどの view ステートメントは、match-clients 一覧に適用される複数の zone ステートメントを含んでいます。
view ステートメント群が一覧表示されている順序が重要になることに注意して下さい。特定クライアントの IP アドレスにマッチする最初のステートメントが使用されます。このトピックの詳細については、「複数表示」 を参照して下さい。

14.2.1.3. コメントタグ

ステートメントに加えて、/etc/named.conf ファイルはコメントも含んでいます。コメントは named サービスには無視されますが、ユーザーに追加情報を提供する時に役に立ちます。以下に有効なコメントタグを示します:
//
// 文字の後のテキストはいずれもその行末までコメントと考慮されます。例えば: 
notify yes;  // すべてのセカンダリネームサーバーに通知します
#
# 文字の後のテキストはいずれもその行末までコメントと考慮されます。例えば: 
notify yes;  # すべてのセカンダリネームサーバーに通知します
/* と */
/* と */ によって囲まれたテキストのブロックはコメントと考慮されます。例えば: 
notify yes;  /* すべてのセカンダリネームサーバーに通知します */