17.2. BIND
本章では、Red Hat Enterprise Linuxnbsp;Hat Enterprise Linuxnbsp;Linux に含まれる DNS サーバーである
BIND
(Berkeley Internet Name Domain)について説明します。ここでは、その設定ファイルの構造にフォーカスし、ローカルとリモートの両方での管理方法を記述しています。
17.2.1. named サービスの設定
named
サービスは起動時に、表17.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; };
chroot 環境での BIND の実行
bind-chroot パッケージをインストールすると、BIND サービスは
/var/named/chroot
環境で実行されます。その場合、初期化スクリプトは mount --bind コマンドを使って上記の設定ファイルをマウントするので、この環境外で設定が管理できます。自動的にマウントされるため、/var/named/chroot
ディレクトリーに何もコピーする必要はありません。これにより、chroot
環境で実行する場合は BIND
設定ファイルの特別な処理を行う必要がないため、メンテナンスが容易になります。BIND
が chroot
環境で実行されていない場合には、すべて整理できます。
以下のディレクトリーは、
/var/named/chroot
ディレクトリーで空の場合、/var/named/chroot
に自動的にマウントされます。/var/named/chroot
にマウントする場合は、空のままにする必要があります。
/var/named
/etc/pki/dnssec-keys
/etc/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
17.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(Classless Inter-Domain Routing)ネットワーク表記(例: 10.0.1.0/24
)です。定義済みのキーワードの一覧は、表17.2「事前定義されたアクセス制御リスト」を参照してください。表17.2 事前定義されたアクセス制御リスト キーワード 説明 any
すべての IP アドレスと一致します。 localhost
ローカルシステムが使用している IP アドレスと一致します。 localnets
ローカルシステムが接続している任意のネットワークの IP アドレスと一致します。 none
いずれの IP アドレスにも一致しません。 acl
ステートメントは、特にオプション
などの他のステートメントと併用できます。例17.2「acl をオプションと併用する」 ブラックリスト(black-hats
およびred-hats
)の 2 つのアクセス制御リストを定義し、red-hats
に通常のアクセスを付与する間にブラックリストにblack-hats
を追加します。例17.2 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 ステートメント名はファイルへの絶対パスとなります。例17.3 /etc/named.conf へのファイルの追加
include "/etc/named.rfc1912.zones";
-
options
options
ステートメントでは、グローバルサーバー設定オプションや他のステートメントのデフォルトを設定できます。名前付き
の作業ディレクトリーの場所、許可されたクエリーのタイプなどを指定できます。以下の形式を取ります。options { option; ... };
よく使用される option ディレクティブの一覧は、表17.3「一般的に使用されるオプション」を参照してください。表17.3 一般的に使用されるオプション オプション 説明 allow-query
権限のあるリソースレコード用のネームサーバーにクエリーを許可されるホストを指定します。CIDR 表記では、アクセス制御リスト、IP アドレスのコレクション、またはネットワークを受け入れます。デフォルトではすべてのホストが許可されています。 allow-query-cache
再帰クエリーなど権限の必要ないデータ用のネームサーバーにクエリーを許可されるホストを指定します。デフォルトでは、 localhost
とlocalnets
のみが許可されています。blackhole
ネームサーバーへのクエリーを許可されないホストを指定します。このオプションは、特定のホストまたはネットワークにリクエストがあるサーバーをいっぱいにする場合に使用する必要があります。デフォルトのオプションは none
です。directory
named
サービス用の作業ディレクトリーを指定します。デフォルトのオプションは/var/named/
です。dnssec-enable
DNSSEC 関連のリソースレコードを返すかどうかを指定します。デフォルトのオプションは yes
です。dnssec-validation
リソースレコードが DNSSEC を介して認証されていることを確認するかどうかを指定します。デフォルトのオプションは yes
です。forwarders
解決用に要求を転送するネームサーバーの有効な IP アドレス一覧を指定します。 進む
forwarders
ディレクティブの動作を指定します。以下のオプションを取ります。first
: サーバーは、独自の名前の解決を試行する前に、forwarders
ディレクティブに一覧表示されるネームサーバーをクエリーします。only
:forwarders
ディレクティブに一覧表示されるネームサーバーをクエリーできない場合、サーバーは独自の名前の解決を試行しません。
listen-on
クエリーをリッスンする IPv4 ネットワークインターフェースを指定します。ゲートウェイとしても機能する DNS サーバーでは、このオプションを使用して、1 つのネットワークからのみ発信されたクエリーに対応できます。デフォルトでは、すべての IPv4 インターフェースが使用されます。 listen-on-v6
クエリーをリッスンする IPv6 ネットワークインターフェースを指定します。ゲートウェイとしても機能する DNS サーバーでは、このオプションを使用して、1 つのネットワークからのみ発信されたクエリーに対応できます。デフォルトでは、すべての 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(DDoS)攻撃を防止するには、allow-query-cache
オプションを使用して、特定のクライアントサブセットの再帰 DNS サービスのみを制限することが推奨されます。利用可能なオプションの詳細の一覧については、「インストールされているドキュメント」 で参照されている 『BIND 9 管理者リファレンスマニュアル』 およびnamed.conf
man ページを参照してください。例17.4 options ステートメントの使用
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 は、表17.4「一般的に使用されるオプション」で説明されているようにzone
ステートメントオプションになります。zone-name 属性は、/var/named/
ディレクトリーにある対応するゾーンファイル内で使用される$ORIGIN
ディレクティブに割り当てられたデフォルト値であるため、特に重要になります。named
デーモンはゾーンの名前を、ゾーンファイル内に一覧表示された非完全修飾型のドメイン名のいずれかに追記します。たとえば、zone
ステートメントがexample.com
の名前空間を定義する場合は、zone-name としてexample.com
を使用し、example.com
ゾーンファイル内のホスト名の最後に配置されるようにします。ゾーンファイルの詳細は、「ゾーンファイルの編集」 を参照してください。表17.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
: ゾーンが不明な場合にクエリーを解決するルートネームサーバーをポイントする特別な種類のゾーン。hint
ゾーンでは、デフォルト以外の設定は必要ありません。master
: このゾーンに対してネームサーバーを権威として指定します。ゾーンの設定ファイルがシステムに存在する場合は、ゾーンをmaster
として設定する必要があります。slave
: このゾーンに対してネームサーバーをスレーブサーバーとして指定します。マスターサーバーはmasters
ディレクティブで指定します。
プライマリーまたはセカンダリーのネームサーバーの/etc/named.conf
ファイルに対するほとんどの変更には、zone
ステートメントの追加、修正、または削除が含まれ、通常はzone
ステートメントオプションの小さなサブセットのみが、ネームサーバーの効率的な機能のために必要となります。例17.5「プライマリーネームサーバーのゾーンステートメント」では、ゾーンはexample.com
として識別されており、タイプはmaster
にセットされて、named
サービスは/var/named/example.com.zone
ファイルを読み込むように指示されています。これはまた、ゾーンの転送にセカンダリーネームサーバー (192.168.0.2
) のみを許可します。例17.5 プライマリーネームサーバーのゾーンステートメント
zone "example.com" IN { type master; file "example.com.zone"; allow-transfer { 192.168.0.2; }; };
セカンダリーサーバーのzone
ステートメントは、若干異なります。タイプはslave
に設定され、masters
ディレクティブはマスターサーバーの IP アドレスの名前
を指定します。例17.6「セカンダリーネームサーバーのゾーンステートメント」 では、example.com
ゾーンに関する情報に対して、named
サービスがIP
アドレスにプライマリーサーバーをクエリーするように設定されます。受信した情報はその後、/var/named/slaves/example.com.zone
ファイルに保存されます。すべてのスレーブゾーンを/var/named/slaves
ディレクトリーに置く必要があります。そうでないと、ゾーンの送信に失敗します。例17.6 セカンダリーネームサーバーのゾーンステートメント
zone "example.com" { type slave; file "slaves/example.com.zone"; masters { 192.168.0.1; }; };
17.2.1.2. その他のステートメントタイプ
以下のタイプのステートメントは、通常、
/etc/named.conf
ではあまり使用されません。
-
controls
controls
ステートメントにより各種設定が可能になり、named
サービスを管理するための rndc コマンドの使用に必要なさまざまなセキュリティー要件を設定できるようになります。rndc ユーティリティーとその使用方法についての詳細は、「rndc ユーティリティーの使用」 を参照してください。-
key
key
ステートメントでは、名前で特定のキーを定義できます。キーは、安全な更新や、あるいは、rndc コマンドの使用など各種動作を認証するために使用されます。以下の 2 つのオプションがkey
と合わせて使用されます。algorithm algorithm-name
: 使用されるアルゴリズムのタイプ (たとえば、hmac-md5
)。secret "key-value"
: 暗号化キー。
rndc ユーティリティーとその使用方法についての詳細は、「rndc ユーティリティーの使用」 を参照してください。-
logging
logging
ステートメントでは、channels と呼ばれる複数の種類のログを使用できます。ステートメント内でchannel
オプションを使用すると、独自のファイル名(ファイル
)、サイズ制限(サイズ)、バージョン管理(バージョン
)、重要度(重大度
)を使用してログのカスタムタイプを作成できます。カスタマイズされたチャネルが定義されると、
category
オプションを使用して、チャネルを分類し、named
サービスの再起動時にロギングを開始します。デフォルトでは、named
は標準メッセージをrsyslog
デーモンに送信して、受信したデーモンはメッセージを/var/log/messages
に配置します。それらの重要度レベルとして、default_syslog
(情報ロギングメッセージを処理) とdefault_debug
(特にデバッギングメッセージを処理) などがあります。default
と呼ばれるデフォルトカテゴリは、組み込み型チャンネルを使用して特別な設定なしで通常のロギングを行います。ロギングプロセスのカスタマイズは詳細なプロセスとなるため、本章の範囲外になります。カスタム BIND ログの作成に関する詳細は、「インストールされているドキュメント」 で参照されている 『BIND 9 Administrator Reference Manual』 を参照してください。-
server
server
ステートメントにより、named
サービスがリモートのネームサーバーに対しての反応の仕方に影響する、特に通知とゾーン転送に関して影響するオプションを指定できるようになります。transfer-format
オプションは、各メッセージと共に送信されるリソースレコードの数を制御します。これには、1-answer
(リソースレコード 1 つのみ)、またはmany-answer
(複数リソースレコード) のいずれかになります。many-answers
オプションはより効率的ですが、以前のバージョンの BIND ではサポートされていないことに注意してください。-
ステートメントを使うと、安全な DNS (DNSSEC) に使用される各種パブリックキーを指定できるようになります。
trusted-keys
ステートメントでは、セキュアな DNS(DNSSEC)に使用されるソートされた公開鍵を指定できます。このトピックの詳細については、「DNSSEC (DNS Security Extensions)」 を参照してください。-
match-clients
view
ステートメントでは、ホストがネームサーバーをクエリーするネットワークに応じて、特別なビューを作成できます。これにより、他のホストが全く異なる情報を受け取る間、ゾーンに関する応答が 1 つの応答を受け取ることができます。また、信頼されないホスト以外のホストでは他のゾーンに対するクエリーしか実行できません。view はその名前が一意になっていれば、複数のものを使用できます。match-clients
オプションを使用すると、特定のビューに適用する IP アドレスを指定できます。options
ステートメントがビュー内で使用されると、設定済みのグローバルオプションが上書きされます。最後に、ほとんどのview
ステートメントには、match-clients
リストに適用される複数のzone
ステートメントが含まれます。特定のクライアントの IP アドレスに一致する最初のステートメントが使用されるため、view
ステートメントが一覧表示される順序が重要である点に注意してください。このトピックに関する詳細は、「複数表示」 を参照してください。
17.2.1.3. コメントタグ
ステートメントのほかに、
/etc/named.conf
ファイルにはコメントも含まれています。コメントは named
サービスには無視されますが、ユーザーに追加情報を提供する時に役に立ちます。以下に有効なコメントタグを示します。
-
//
//
文字の後のテキストはいずれもその行末までコメントとみなされます。以下に例を示します。notify yes; // notify all secondary nameservers
-
#
#
文字の後のテキストはいずれもその行末までコメントとみなされます。以下に例を示します。notify yes; # notify all secondary nameservers
/*
and*/
/*
と*/
によって囲まれたテキストのブロックはコメントとみなされます。以下に例を示します。notify yes; /* notify all secondary nameservers */