14.2. BIND

本セクションでは、Red Hat Enterprise Linux に含まれている DNS サーバーの BIND (Berkeley Internet Name Domain) について説明します。ここでは、その設定ファイルの構造にフォーカスし、ローカルとリモートの両方での管理方法を記述しています。

14.2.1. 空白ゾーン

BIND は多くの「空白ゾーン」を設定し、再帰サーバーが不要なクエリーを、処理できない (このために遅延が発生したり、クエリーを送信したクライアントに SERVFAIL が返される) インターネットサーバーに送信することを防ぎます。これらの空白ゾーンにより、遅延なしで権威のある NXDOMAIN 応答が返されます。設定オプションの empty-zones-enable は空白ゾーンを作成するかどうかを制御し、disable-empty-zone はさらに、使用されるデフォルトの接頭辞のリストから 1 つ以上の空白ゾーンを無効にします。
『RFC 1918』接頭辞用に作成された空白ゾーンの数は増加しており、BIND 9.9 およびそれ以降のユーザーは、empty-zones-enable が未指定の場合 (デフォルトで yes) と明示的に yes に設定されている場合の両方で『RFC 1918』空白ゾーンを目にすることになります。

14.2.2. 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 サービスは chroot 環境で実行されます。その場合、初期化スクリプトは mount --bind コマンドを使って上記の設定ファイルをマウントするので、この環境外で設定が管理できます。マウントは自動的に行われるので、/var/named/chroot/ ディレクトリーにはなにもコピーする必要はありません。chroot 環境で BIND が実行されている場合は、この設定ファイルの管理については特別な作業が不要となり、維持が簡単になります。chroot 以外の環境で BIND を実行する際と同様の作業になります。
以下のディレクトリーは、/var/named/chroot/ 下にある対応するマウントポイントディレクトリーが空の場合、/var/named/chroot/ ディレクトリーに自動的にマウントされます。
  • /etc/named
  • /etc/pki/dnssec-keys
  • /run/named
  • /var/named
  • /usr/lib64/bind または /usr/lib/bind (アーキテクチャーに依存)
/var/named/chroot/ にターゲットファイルがない場合は、以下のファイルもマウントされます。
  • /etc/named.conf
  • /etc/rndc.conf
  • /etc/rndc.key
  • /etc/named.rfc1912.zones
  • /etc/named.dnssec.keys
  • /etc/named.iscdlv.key
  • /etc/named.root.key

重要

chroot 環境でマウントされたファイルを編集する場合は、バックアップコピーを作成し、その上でオリジナルファイルを編集する必要があります。別の方法では、「edit-a-copy」モードを無効にしてエディターを使います。たとえば、BIND の設定ファイル /etc/named.conf を chroot 環境で実行中に Vim で編集するには、root で以下のコマンドを実行します。 
~]# vim -c "set backupcopy=yes" /etc/named.conf

14.2.2.1. chroot 環境で BIND をインストールする

BIND を chroot 環境で実行するようにインストールするには、root で以下のコマンドを実行します。 
~]# yum install bind-chroot
named-chroot サービスを有効にするには、以下のコマンドを実行して、まず named サービスが実行中かどうかを確認します。 
~]$ systemctl status named
実行中の場合は、無効にする必要があります。
named 無効にするには、root で以下のコマンドを実行します。 
~]# systemctl stop named
~]# systemctl disable named
その後に named-chroot サービスを有効にするために、root で以下のコマンドを実行します。 
~]# systemctl enable named-chroot
~]# systemctl start named-chroot
named-chroot サービスのステータスを確認するには、root で以下のコマンドを実行します。 
~]# systemctl status named-chroot

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

/etc/named.conf では、通常、以下のタイプのステートメントが使用されます。
acl
acl (Access Control List) (アクセス制御リスト) ステートメントにより、ホストのグループを定義できるようになるため、それらのホストはネームサーバーへのアクセスを許可/拒否できるようになります。以下の形式を取ります。 
acl acl-name {
  match-element;
  ...
};
acl-name ステートメント名はアクセス制御リストの名前です。また、match-element オプションは通常、個別の IP アドレス (10.0.1.1 など) または、CIDR (Classless Inter-Domain Routing) ネットワーク表記 (たとえば、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 の 2 つのアクセス制御リストを定義し、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 です。
directorynamed サービス用の作業ディレクトリーを指定します。デフォルトのオプションは /var/named/ です。
disable-empty-zone使用されるデフォルトの接頭辞リストから空白ゾーンを無効にするために使用します。options ステートメントおよび view ステートメントで指定できます。複数回の使用が可能です。
dnssec-enableDNSSEC 関連のリソースレコードを返すかどうかを指定します。デフォルトのオプションは yes です。
dnssec-validationリソースレコードが DNSSEC を通じて本物であることを証明するかどうかを指定します。デフォルトのオプションは yes です。
empty-zones-enable空白ゾーンを作成するかどうかを制御します。options ステートメントでのみ指定可能です。
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-filenamed サービスで作成されたプロセス ID ファイルの場所を指定します。
recursion再帰的なサーバーとして動作するかどうかを指定します。デフォルトのオプションは yes です。
statistics-file統計ファイルの代替の場所を指定します。デフォルトでは、/var/named/named.stats ファイルがデフォルトで使用されています。

注記

named がランタイムデータ用に使用するディレクトリーは、BIND のデフォルトの場所である /var/run/named/ から新たな場所の /run/named/ に移りました。この結果、PID ファイルはデフォルトの /var/run/named/named.pid から新しい場所の /run/named/named.pid に移りました。また、session-key ファイルは /run/named/session.key に移動しました。これらの場所は、options セクションのステートメントで指定する必要があります。例14.4「オプションステートメントの使用」を参照してください。

重要

分散型サービス妨害 (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;

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

表14.4 Zone ステートメントで一般的に使用されるオプション

オプション説明
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「プライマリーネームサーバー用の Zone ステートメント」では、ゾーンは example.com として識別されており、タイプは master にセットされて、named サービスは /var/named/example.com.zone ファイルを読み込むように指示されています。これはまた、ゾーンの転送にセカンダリーネームサーバー (192.168.0.2) のみを許可します。

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

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

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

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

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

以下のタイプのステートメントは、通常、/etc/named.conf ではあまり使用されません。
controls
controls ステートメントにより各種設定が可能になり、named サービスを管理するための rndc コマンドの使用に必要なさまざまなセキュリティー要件を設定できるようになります。
rndc ユーティリティーとその使用法の詳細は、「rndc ユーティリティーの使用」を参照してください。
key
key ステートメントを使うと、特定のキーを名前で定義できるようになります。キーは、安全な更新や、あるいは、rndc コマンドの使用など各種動作を認証するために使用されます。２つのオプションが key と使用されます。
  • algorithm algorithm-name - 使用されるアルゴリズムのタイプ (たとえば、hmac-md5)。
  • secret "key-value" - 暗号化キーです。
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 ステートメントにより、ネームサーバーをクエリーしているホストが存在するネットワークに応じて特別な表示を作成できるようになります。これによって、一部のホストはゾーンに関して１つの応答を受信できるようになり、他のホストは全く異なる情報を受信できるようになります。別の観点から、一定のゾーンは特定の信頼されるホストにだけ利用可能であり、信頼できないホストは他のゾーンのクエリーしかできない可能性もあります。
view はその名前が一意になっていれば、複数のものを使用できます。match-clients オプションを使うと、特定の表示に適用する IP アドレスを指定できます。options ステートメントが 1 つの表示内で使用された場合は、すでに設定済みのグローバルオプションを上書きします。最後に、ほとんどの view ステートメントは、match-clients 一覧に適用される複数の zone ステートメントを含んでいます。
view ステートメントが記載される順序が重要であることに留意してください。特定クライアントの IP アドレスに一致する最初のステートメントが使用されます。このトピックの詳細は「複数表示」を参照してください。

14.2.2.4. コメントタグ

ステートメントのほかに、/etc/named.conf ファイルにはコメントも含まれています。コメントは named サービスには無視されますが、ユーザーに追加情報を提供する時に役に立ちます。以下に有効なコメントタグを示します。
//
// 文字の後のテキストはいずれもその行末までコメントとみなされます。例を示します。 
notify yes;  // notify all secondary nameservers
#
# 文字の後のテキストはいずれもその行末までコメントとみなされます。例を示します。 
notify yes;  # notify all secondary nameservers
/* and */
/* と */ によって囲まれたテキストのブロックはコメントとみなされます。例を示します。 
notify yes;  /* notify all secondary nameservers */

14.2.3. ゾーンファイルの編集

「ネームサーバーゾーン」で要約したように、ゾーンファイルにはネームスペースの情報が含まれています。情報はデフォルトで /var/named/ にある named 作業ディレクトリーに保存されます。各ゾーンファイルは zone ステートメント内の file オプションに従って命名されます。通常は、example.com.zone などのようにドメインに関連付けられ、ゾーンデータを含むファイルとして識別できる方法で命名されます。

表14.5 named サービスのゾーンファイル

パス説明
/var/named/named サービスの作業ディレクトリーです。ネームサーバーにはこのディレクトリーに書き込む許可が ありません。
/var/named/slaves/セカンダリーゾーンのディレクトリーです。このティレクトリは named サービスによる書き込みが可能です。
/var/named/dynamic/動的 DNS (DDNS) ゾーンや管理された DNSSEC キーなどの他のファイル用のディレクトリーです。このディレクトリーは named サービスによる書き込みが可能です。
/var/named/data/様々な統計とデバッギングファイル用のディレクトリーです。このディレクトリーは named サービスによる書き込みが可能です。
ゾーンファイルはディレクティブとリソースの記録で構成されています。ディレクティブはネームサーバーに対してタスクを実行するか、または特別なセッティングをゾーンに適用するように指示し、リソースレコードはゾーンのパラメータを定義して識別子を個々のホストに割り当てます。ディレクティブはオプションですが、リソースレコードはゾーンにネームサービスを提供するために必須です。
ディレクティブとリソースレコードはすべて、個別の行で記入します。

14.2.3.1. 一般的なディレクティブ

ディレクティブはドルマーク記号 ($) で始まり、その後にディレクティブ名が続きます。通常、ファイルの最上部に現れます。以下のディレクティブは一般的にゾーンファイルで使用されます。
$INCLUDE
$INCLUDE ディレクティブにより、それが出現する場所にもう１つのファイルを含めることができるため、他のゾーンセッティングは別個のゾーンファイルに保存できるようになります。

例14.7 $INCLUDE ディレクティブの使用

$INCLUDE /var/named/penguin.example.com
$ORIGIN
$ORIGIN ディレクティブを使うと、ホスト名だけの非完全修飾型の記録へドメイン名を追記できるようになります。デフォルトではゾーン名が使用されるので、/etc/named.conf 内でゾーンが指定されている場合は、このディレクティブの使用は不要です。
例14.8「$ORIGIN ディレクティブの使用」では、リソースレコード内で使用される名前でピリオド (.) で終了していない名前はいずれも example.com が追記されます。

例14.8 $ORIGIN ディレクティブの使用

$ORIGIN example.com.
$TTL
$TTL ディレクティブにより、ゾーン用のデフォルト TTL (Time to Live) 値をセットできるようになります。つまり、ゾーン記録が有効である時間の長さのセッティングです。各リソースレコードはそれ自身のTTL 値を含むことができるため、それがこのディレクティブを上書きします。
この値を増加させるとリモートのネームサーバーはより長い期間でゾーン情報をキャッシュ化できるようになり、ゾーンへのクエリー回数が減少し、リソースレコード変更の伝達に必要な時間を延長させることができます。

例14.9 $TTL ディレクティブの使用

$TTL 1D

14.2.3.2. 一般的なリソースレコード

以下のリソースレコードは一般的にゾーンファイル内で使用されます。
A
Address レコードは名前に割り当てられる IP アドレスを指定します。以下の形式を取ります。 
hostname IN A IP-address
hostname の値ない場合、レコードは最後に指定された hostname を指します。
例14.10「リソースレコードの使用」では、server1.example.com 用の要求は、10.0.1.3 または 10.0.1.5 を指しています。

例14.10 リソースレコードの使用

server1  IN  A  10.0.1.3
         IN  A  10.0.1.5
CNAME
Canonical Name (別名) レコードはある名前を別の名前にマッピングします。このため、このタイプのレコードは、エイリアスレコードと呼ばれることもあります。以下の形式を取ります。 
alias-name IN CNAME real-name
CNAME レコードは Web サーバー用の www のように、共通の命名基準を使用するサービスを指すために最も一般的に使用されます。しかし、それらの使用については複数の制限があります。
  • CNAME レコードは他の CNAME レコードを指してはいけません。これは主に無限のループの可能性を避けるためです。
  • CNAME レコードには他のリソースレコードタイプ (A、NS、MX など) を含めないでください。唯一の例外は、ゾーンが署名されている時の DNSSEC 関連のレコード (RRSIG、NSEC など) です。
  • ホストの完全修飾型ドメイン名 (FQDN) を指す他のリソースレコード (NS、MX、PTR) は CNAME レコードを指してはいけません。
例14.11「CNAME リソースレコードの使用」では、A レコードがホスト名を IP アドレスにバインドし、CNAME レコードが一般的に使用される www ホスト名をそれに向けています。

例14.11 CNAME リソースレコードの使用

server1  IN  A      10.0.1.5
www      IN  CNAME  server1
MX
Mail Exchange レコードは、このゾーンで制御されている特定のネームスペースに送信されるメールの行き先を指定します。以下の形式を取ります。 
IN MX preference-value email-server-name
email-server-name は完全修飾型ドメイン名 (FQDN) です。preference-value によってネームスペースのメールサーバーの数値ランキングが可能になり、一部のメールシステムに他のシステムよりも優先度を与えます。最小の preference-value を持つ MX リソースレコードが他よりも優先されます。しかし複数メールサーバーが同じ値を持つ可能性があり、その場合はメールトラフィックをサーバー間で均等に分配することになります。
例14.12「MX リソースレコードの使用」では、example.com ドメイン宛のメール受信時には最初の mail.example.com メールサーバーが mail2.example.com メールサーバーよりも優先されます。

例14.12 MX リソースレコードの使用

example.com.  IN  MX  10  mail.example.com.
              IN  MX  20  mail2.example.com.
NS
Nameserver レコードはある特定のゾーン用に正当なネームサーバーを表明します。以下の形式を取ります。 
IN NS nameserver-name
nameserver-name は完全修飾型ドメイン名 (FQDN) である必要があります。ドメインに対して 2 つのネームサーバーが正当だとして一覧表示されている時には、これらのネームサーバーがセカンダリーネームサーバーであるか、またはその 1 つがプライマリーサーバーであるかどうかは重要でありません。両方とも正当と考慮されます。

例14.13 NS リソースレコードの使用

IN  NS  dns1.example.com.
IN  NS  dns2.example.com.
PTR
Pointer レコードはネームスペースの別の部分を指します。以下の形式を取ります。 
last-IP-digit IN PTR FQDN-of-system
last-IP-digit ディレクティブは IP アドレスの末尾の番号です。FQDN-of-system は完全修飾型ドメイン名 (FQDN) になります。
PTR レコードは、主に逆引き名前解決に使用されます。これは IP アドレスを特定の名前に指定します。PTR レコードの使用例は、「逆引き名前解決ゾーンファイル」を参照してください。
SOA
Start of Authority レコードはネームスペースについての信頼できる重要な情報をネームサーバーに表明します。ディレクティブの後に配置されていて、ゾーンファイルでは最初のリソースレコードです。以下の形式を取ります。 
@  IN  SOA  primary-name-server hostmaster-email (
       serial-number
       time-to-refresh
       time-to-retry
       time-to-expire
       minimum-TTL )
ディレクティブは以下の通りです。
  • @ シンボルは $ORIGIN ディレクティブ (または$ORIGIN ディレクティブがセットされていない場合は、ゾーン名) をこのSOA リソースレコードで定義されたネームスペースとして配置します。
  • primary-name-server ディレクティブは、このドメインの正式なプライマリーネームサーバーのホスト名です。
  • hostmaster-email ディレクティブは、ネームスペースに関して連絡する相手のメールです。
  • serial-number ディレクティブは、named サービスがゾーンを再ロードする時間であることを示すためにゾーンファイルが変更される度に増加する数値です。
  • time-to-refresh ディレクティブは、ゾーンに対して変更がなされたかどうかをプライマリーネームサーバーに尋ねるまで待機する時間の長さを決定するためにセカンダリーネームサーバーが使用する数値です。
  • time-to-retry ディレクティブは、プライマリーネームサーバーが応答しない事態にリフレッシュ要求を出すまで待機する時間の長さを決定するためにセカンダリーネームサーバーによって使用される数値です。time-to-expire ディレクティブ内で指定された時間が経過するまでに、プライマリーネームサーバーがリフレッシュ要求に応答しない場合は、セカンダリーサーバーはそのネームスペースに関する要求での権威としての応答を停止します。
  • BIND 4 と 8 では、minimum-TTL ディレクティブは他のネームサーバーがゾーンの情報をキャッシュ化する時間の長さになります。BIND 9 では、これは否定的な回答がキャッシュ化される時間の長さを定義します。否定的回答のキャッシュ化は最大で 3 時間に設定できます (3H)。
BIND の設定時には、すべての時間は秒で指定されます。しかし、秒以外の時間単位を指定するのに短縮形を使用できます。たとえば、分 (M)、時間 (H)、日 (D)、および週 (W) です。表14.6「秒表示とその他の時間単位」では時間数を秒で示し、さらにその同時間を他の形式で示しています。

表14.6 秒表示とその他の時間単位

秒他の時間単位
601M
180030M
36001H
108003H
216006H
4320012H
864001D
2592003D
6048001W
31536000365D

例14.14 SOA リソースレコードの使用

@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day

14.2.3.3. コメントタグ

リソースレコードとディレクティブの他にも、ゾーンファイルもコメントを格納できます。コメントは named サービスでは無視されますが、ユーザーに追加情報を提供する際に便利です。セミコロンの後の行末までのテキストはすべてコメントとみなされます。例を示します。 
   604800  ; expire after 1 week

14.2.3.4. 使用例

下記の例は、ゾーンファイルの基本的使用法を示したものです。
14.2.3.4.1. 単純なゾーンファイル
例14.15「単純なゾーンファイル」では、標準のディレクティブとSOA 値の使用を提示しています。

例14.15 単純なゾーンファイル

$ORIGIN example.com.
$TTL 86400
@         IN  SOA  dns1.example.com.  hostmaster.example.com. (
              2001062501  ; serial
              21600       ; refresh after 6 hours
              3600        ; retry after 1 hour
              604800      ; expire after 1 week
              86400 )     ; minimum TTL of 1 day
;
;
          IN  NS     dns1.example.com.
          IN  NS     dns2.example.com.
dns1      IN  A      10.0.1.1
          IN  AAAA   aaaa:bbbb::1
dns2      IN  A      10.0.1.2
          IN  AAAA   aaaa:bbbb::2
;
;
@         IN  MX     10  mail.example.com.
          IN  MX     20  mail2.example.com.
mail      IN  A      10.0.1.5
          IN  AAAA   aaaa:bbbb::5
mail2     IN  A      10.0.1.6
          IN  AAAA   aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses
; for multiple services:
;
services  IN  A      10.0.1.10
          IN  AAAA   aaaa:bbbb::10
          IN  A      10.0.1.11
          IN  AAAA   aaaa:bbbb::11

ftp       IN  CNAME  services.example.com.
www       IN  CNAME  services.example.com.
;
;
この例では、権威ネームサーバーは dns1.example.com と dns2.example.com として設定されており、これらはそれぞれ A レコードを使用して 10.0.1.1 と 10.0.1.2 の IP アドレスに結合されています。
MX レコードで設定されているメールサーバーは、A レコードを介して mail と mail2 に向けられています。これらの名前は末尾のピリオドで終了していないため、$ORIGIN ドメインがその後に配置されており、それらを mail.example.com および mail2.example.com に広げています。
www.example.com (WWW) などの標準の名前で利用可能なサービスは、CNAME レコードを使用して適切なサービスを指すようにしてあります。
このゾーンファイルは、以下のような zone ステートメントが /etc/named.conf ファイルに追加される場合に使用されます。 
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};
14.2.3.4.2. 逆引き名前解決ゾーンファイル
逆引き名前解決ゾーンファイルは、特定のネームスペース内の IP アドレスを完全修飾型ドメイン名 (FQDN) に変換するために使用されます。これは標準のゾーンファイルに非常に似ていますが、例14.16「逆引き名前解決ゾーンファイル」にあるように IP アドレスを完全修飾型ドメイン名にリンクするために PTR リソースレコードが使われている点が異なります。

例14.16 逆引き名前解決ゾーンファイル

$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day
;
@  IN  NS   dns1.example.com.
;
1  IN  PTR  dns1.example.com.
2  IN  PTR  dns2.example.com.
;
5  IN  PTR  server1.example.com.
6  IN  PTR  server2.example.com.
;
3  IN  PTR  ftp.example.com.
4  IN  PTR  ftp.example.com.
この例では、10.0.1.1 から 10.0.1.6 までの IP アドレスは、対応する完全修飾ドメイン名を指しています。
このゾーンファイルは、以下のような zone ステートメントが /etc/named.conf ファイルに追加される場合に使用されます。 
zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};
ゾーン名以外は、この例と標準の zone ステートメントにはほとんど違いがありません。逆引き名前解決ゾーンは、IP アドレスの最初の 3 つのブロックが逆になっていて、その後に .in-addr.arpa が続く必要があります。これにより、逆引き名前解決ゾーンファイルで使用される IP 番号のシングルブロックがそのゾーンと関連付けられます。

14.2.4. rndc ユーティリティーの使用

rndc ユーティリティーは、ローカルとリモートマシンの両方から named サービスの管理を可能にするコマンドラインツールです。以下のような使用法になります。 
rndc [option...] command [command-option]

14.2.4.1. ユーティリティーの設定

サービスへの未承認のアクセスを防止するには、named は選択したポート (デフォルトでは 953) をリッスンするように設定し、このサービスとrndc ユーティリティーの両方が同じキーを使用する必要があります。

表14.7 関連ファイル

パス説明
/etc/named.confnamed サービス用のデフォルト設定ファイル
/etc/rndc.confrndc ユーティリティー用のデフォルト設定ファイル
/etc/rndc.keyデフォルトキーの場所
rndc 設定は /etc/rndc.conf に配置されています。ファイルが存在しない場合は、ユーティリティーは、rndc-confgen -a コマンドを使用したインストールプロセス中に自動的に生成される、/etc/rndc.key にあるキーを使用します。
named サービスは、「その他のステートメントタイプ」の説明にある /etc/named.conf 設定ファイル内の controls ステートメントを使用して設定されます。このステートメントがない場合、ループバックアドレス (127.0.0.1) からの接続のみが許可されることになり、/etc/rndc.key にあるキーが使用されます。
このトピックの詳細は、man ページと、「関連資料」 にある 『BIND 9 Administrator Reference Manual』 を参照してください。

重要

権限のないユーザーが制御コマンドをサービスに送信しないようにするには、root のみが /etc/rndc.key ファイルの読み取りをできるようにします。 
~]# chmod o-rwx /etc/rndc.key

14.2.4.2. サービスステータスの確認

named サービスの現在の状態をチェックするには、以下のコマンドを使用します。 
~]# rndc status
version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

14.2.4.3. 設定とゾーンのリロード

設定ファイルとゾーンの両方をリロードするには、シェルプロンプトで以下を入力します。 
~]# rndc reload
server reload successful
これがゾーンをリロードすると同時に以前にキャッシュ化した応答を維持するため、すべての保存済みの名前解決を消失することなくゾーンファイルを変更できます。
単独ゾーンをリロードするには、reload コマンドの後にその名前を指定します。例を示します。 
~]# rndc reload localhost
zone reload up-to-date
最後に、設定ファイルと、新規に追加されたゾーンのみをリロードするには、以下を入力します。 
~]# rndc reconfig

注記

動的 DNS (DDNS) を使用するゾーンを手動で修正する場合は、freeze コマンドを最初に実行してください。 
~]# rndc freeze localhost
これが完了したら、thaw コマンドを実行して DDNS を再度有効にしてゾーンをリロードします。 
~]# rndc thaw localhost
The zone reload and thaw was successful.

14.2.4.4. ゾーンキーの更新

DNSSEC キーを更新してゾーンに署名するには、sign コマンドを使用します。例を示します。 
~]# rndc sign localhost
上記のコマンドでゾーンに署名するには、zone ステートメント内で auto-dnssec オプションを maintain に設定する必要があることに注意してください。例を示します。 
zone "localhost" IN {
  type master;
  file "named.localhost";
  allow-update { none; };
  auto-dnssec maintain;
};

14.2.4.5. DNSSEC 検証の有効化

DNSSEC 検証を有効にするには、root で以下のコマンドを実行します。 
~]# rndc validation on
同様に、このオプションを無効にするには、以下を入力します。 
~]# rndc validation off
/etc/named.conf でこのオプションを設定する方法は、「一般的なステートメントのタイプ」の options ステートメントを参照してください。
『Red Hat Enterprise Linux 7 セキュリティーガイド』には、DNSSEC に関する詳細なセクションがあります。

14.2.4.6. クエリーロギングの有効化

クエリロギングを有効にする (すでに有効な場合は無効にする) には、root で以下のコマンドを実行します。 
~]# rndc querylog
現在の設定を確認するには、「サービスステータスの確認」にあるように status コマンドを使用します。

14.2.5. dig ユーティリティーの使用

dig ユーティリティーは、DNS ルックアップの実行とネームサーバー設定のデバッグを可能にするコマンドラインツールです。これは通常、以下のように使用されます。 
dig [@server] [option...] name type
type に使用する一般的な値の一覧は、「一般的なリソースレコード」を参照してください。

14.2.5.1. ネームサーバーのルックアップ

特定のドメイン用にネームサーバーをルックアップするには、以下の形式でコマンドを使用します。 
dig name NS
例14.17「ネームサーバールックアップのサンプル」では、dig ユーティリティーが example.com 用のネームサーバーを表示するために使用されています。

例14.17 ネームサーバールックアップのサンプル

~]$ dig example.com NS

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            99374   IN      NS      a.iana-servers.net.
example.com.            99374   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:04:06 2010
;; MSG SIZE  rcvd: 77

14.2.5.2. IP アドレスのルックアップ

特定のドメインに割り当てられた IP アドレスを検索するには、以下の形式のコマンドを使用します。 
dig name A
例14.18「IP アドレス検索のサンプル」では、dig ユーティリティーを使用して example.com の IP アドレスを表示しています。

例14.18 IP アドレス検索のサンプル

~]$ dig example.com A

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            155606  IN      A       192.0.32.10

;; AUTHORITY SECTION:
example.com.            99175   IN      NS      a.iana-servers.net.
example.com.            99175   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:07:25 2010
;; MSG SIZE  rcvd: 93

14.2.5.3. ホスト名の検索

特定の IP アドレスのホスト名を検索するには、以下の形式のコマンドを使用します。 
dig -x address
例14.19「ホスト名検索のサンプル」では、dig ユーティリティーを使用して 192.0.32.10 に割り当てられたホスト名を表示しています。

例14.19 ホスト名検索のサンプル

~]$ dig -x 192.0.32.10

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> -x 192.0.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29683
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6

;; QUESTION SECTION:
;10.32.0.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
10.32.0.192.in-addr.arpa. 21600 IN      PTR     www.example.com.

;; AUTHORITY SECTION:
32.0.192.in-addr.arpa.  21600   IN      NS      b.iana-servers.org.
32.0.192.in-addr.arpa.  21600   IN      NS      c.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      d.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      ns.icann.org.
32.0.192.in-addr.arpa.  21600   IN      NS      a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     13688   IN      A       192.0.34.43
b.iana-servers.org.     5844    IN      A       193.0.0.236
b.iana-servers.org.     5844    IN      AAAA    2001:610:240:2::c100:ec
c.iana-servers.net.     12173   IN      A       139.91.1.10
c.iana-servers.net.     12173   IN      AAAA    2001:648:2c30::1:10
ns.icann.org.           12884   IN      A       192.0.34.126

;; Query time: 156 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:25:15 2010
;; MSG SIZE  rcvd: 310

14.2.6. BIND の高度な機能

ほとんどの BIND 実装では、named のみを使用して名前解決サービスを提供したり、特定ドメイン用の権威として機能させます。しかし、BIND バージョン 9 には数種の高度な機能が含まれており、より安全で効率的な DNS サービスを可能にしています。

重要

DNSSEC、TSIG、IXFR (増分ゾーン転送) などの高度な機能の使用を試みる前に、特に BIND の古いバージョンや BIND 以外のサーバーを使用している場合は、その特定の機能がネットワーク環境内のすべてのネームサーバーでサポートされていることを確認してください。
ここに記載されているすべての機能は「インストールされているドキュメント」で参照されている『BIND 9 Administrator Reference Manual (管理者参照マニュアル)』でより詳細に説明されています。

14.2.6.1. 複数表示

オプションとして、リクエストが発信されたネットワークに応じて異なる情報をクライアントに提供できます。これは主に、ローカルネットワーク外のクライアントからの要注意 DNS エントリを拒否するために、そしてそれと同時にローカルネットワーク内のクライアントからのクエリを受け付けるために使用されます。
複数表示を設定するには、view ステートメントを /etc/named.conf 設定ファイルに追加します。match-clients オプションを使用して IP アドレスかネットワーク全体とマッチするようにし、それらに特別オプションとゾーンデータを与えます。

14.2.6.2. IXFR (Incremental Zone Transfers 差分ゾーン転送)

Incremental Zone Transfers 差分ゾーン転送 (IXFR) により、セカンダリーネームサーバーはプライマリーネームサーバー上で修正されたゾーンの更新部分だけをダウンロードできます。標準の転送プロセスに比較すると、これが通知と更新のプロセスを格段に効率的にします。
IXFR は、動的な更新を使用してマスターゾーンレコードに変更を加える時にのみ使用可能なことに注意して下さい。ゾーンファイルを手動の編集で変更する場合は、Automatic Zone Transfer 自動ゾーン転送 (AXFR) が使用されます。

14.2.6.3. Transaction SIGnatures トランザクション署名 (TSIG)

Transaction SIGnatures トランザクション署名 (TSIG) は、転送を許可する前に共有の秘密鍵がプライマリーとセカンダリーの両方のサーバー上に存在することを確認します。攻撃者はゾーン転送のために IP アドレスにアクセスする必要があるだけでなく、秘密鍵を知る必要があるため、これにより標準の IP アドレスベースの転送認証メソッドが強化されます。
バージョン 9 以降は、BIND は TKEY もサポートします。これはゾーン転送を認証するもう 1 つの共有秘密鍵メソッドです。

重要

安全でないネットワーク上での通信時には、IP アドレスベース認証のみに頼らないでください。

14.2.6.4. DNSSEC (DNS Security Extensions)

Domain Name System Security Extensions ドメイン名システムセキュリティー拡張機能 (DNSSEC) は、DNS データの発信元認証、認証による存在否定、およびデータの整合性を提供します。特定のドメインが安全としてマークされている時、検証に失敗した各リソースレコードに SERFVAIL 応答が返されます。
DNSSEC 署名のドメイン、または DNSSEC 認識のリゾルバーをデバッグするには、「dig ユーティリティーの使用」にある dig ユーティリティーを使用できます。役に立つオプションとして、+dnssec (DNSSEC OK を設定することで、DNSSEC 関連のリソースレコードを要求)、+cd (応答を検証しないように再帰ネームサーバーに指示)、そして+bufsize=512 (一部のファイヤーウォールを通過するためにパケットサイズを 512B に変更) があります。

14.2.6.5. インターネットプロトコルバージョン 6 (IPv6)

Internet Protocol version 6 インターネットプロトコルバージョン 6 (IPv6) は 表14.3「一般的な設定オプション」に説明してあるように AAAA リソースレコードの使用、および listen-on-v6 ディレクティブを介してサポートされています。

14.2.7. 回避すべき一般的な間違い

ネームサーバー設定時にユーザーが一般的な間違いを回避するためのアドバイス一覧を以下に示します。
セミコロンと弓形括弧の正しい使用
/etc/named.conf ファイル内のセミコロンの欠如や、不一致な弓形括弧は named サービスの開始を阻止してしまいます。
ピリオド (. 記号) の正しい使用
ゾーンファイル内では、ドメイン名の末尾のピリオドは完全修飾型ドメイン名を示します。これが欠如していると、named サービスはゾーン名、または $ORIGIN の値を追記してそれを完結しようとします。
ゾーンファイルを編集する時のシリアル番号増加
シリアル番号が増加していない場合、プライマリーネームサーバーは正しくて新しい情報を持ちますが、セカンダリーネームサーバーは決して変更を通知されません。そのため、そのゾーンのデータをリフレッシュする試みをしません。
ファイヤーウォールの設定
ファイヤーウォールが、named サービスから他のネームサーバーへの接続をブロックしている場合は、ファイヤーウォールの設定変更が推奨されます。

警告

DNS クエリに固定 UDP ソースポートを使用すると、攻撃者がキャッシュポイズニング攻撃をより簡単に実施できるようになるセキュリティー脆弱性につながる可能性があります。これを防止するには、デフォルトで DNS がランダム短期ポートから送信するようにします。ランダムな UDP ソースポートからの送信クエリーを許可するようにファイヤーウォールを設定します。デフォルトでは、1024 から 65535 の範囲が使用されます。

14.2.8. 関連資料

以下の資料は、BIND に関するその他のリソースを提供します。

14.2.8.1. インストールされているドキュメント

BIND は、多種多様なトピックを網羅した広範囲に及ぶインストール済みのドキュメントを特徴としています。各ドキュメントはその議題のディレクトリー内に配置されています。以下の各項目には、version の部分をシステム上にインストールしてある bind パッケージのバージョンに入れ替えてください。
/usr/share/doc/bind-version/
最新のドキュメンテーションを格納しているメインのディレクトリーです。ここには、HTML と PDF 形式で『BIND 9 Administrator Reference Manual』を収納しており、BIND のリソース要件、異種タイプのネームサーバーの設定方法、ロードバランシングの実行方法、および他の高度なトピックを説明しています。
/usr/share/doc/bind-version/sample/etc/
named 設定ファイルのサンプルが格納されているディレクトリーです。
rndc(8)
rndc ネームサーバー制御ユーティリティーの man ページで、使用法に関するドキュメンテーションが含まれています。
named(8)
インターネットドメインネームサーバー named の man ページには、BIND ネームサーバーデーモンの制御に使用可能な各種引数についてのドキュメントが含まれています。
lwresd(8)
軽量のリゾルバーデーモン lwresd の man ページには、このデーモンとその使用法に関する記載があります。
named.conf(5)
この man ページには、named 設定ファイル内で利用可能なオプションの総合的一覧があります。
rndc.conf(5)
この man ページには、rndc 設定ファイル内で利用可能なオプションの総合的一覧があります。

14.2.8.2. オンラインリソース

https://access.redhat.com/site/articles/770133
chroot 環境で BIND を実行することに関する Red Hat ナレッジベースアーティクルです。Red Hat Enterprise Linux 6 と相違点も記載されています。
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/
『Red Hat Enterprise Linux 7 セキュリティーガイド』には、DNSSEC に関する詳細なセクションがあります。
https://www.icann.org/namecollision
『Name Collision Resources and Information』