サポートコンソール開発者トライアルの開始お問い合わせ

15.2. BIND

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

15.2.1. 空白ゾーン

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

15.2.2. named サービスの設定

named サービスは起動時に、表15.1「named サービスの設定ファイル」 に記載されているファイルから設定を読み込みます。
表15.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」モードを無効にしてエディターを使います。たとえば、chroot 環境で実行されているときに BIND の設定ファイル /etc/named.conf を編集し、root で以下のコマンドを実行します。 
~]# vim -c "set backupcopy=yes" /etc/named.conf

15.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

15.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)または Classless Inter-Domain Routing (CIDR)ネットワーク表記です（例：10.0.1.0/24）。定義済みのキーワードのリストは、表15.2「事前定義のアクセス制御リスト」を参照してください。
表15.2 事前定義のアクセス制御リスト
キーワード 説明
any すべての IP アドレスにマッチします。
localhost ローカルシステムが使用している IP アドレスにマッチします。
localnets ローカルシステムが接続しているネットワーク上の IP アドレスにマッチします。
none どの IP アドレスにも一致しません。
acl ステートメントは、特に オプション などの他のステートメントと併用できます。例15.2「options と併用して acl を使用する」 2 つのアクセス制御リスト( black-hats と red-hats )を定義し、red-hats に通常のアクセスを付与する間に black-hats をブラックリストに追加します。

例15.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 ステートメント名はファイルへの絶対パスとなります。

例15.3 ファイルを /etc/named.conf に含める

include "/etc/named.rfc1912.zones";
options
options ステートメントでは、グローバルサーバー設定オプションや他のステートメントのデフォルトを設定できます。名前付き 作業ディレクトリーの場所、許可されるクエリーのタイプなどを指定できます。以下の形式を取ります。 
options {
  option;
  ...
};
よく使用される option ディレクティブのリストは、表15.3「一般的な設定オプション」を参照してください。
表15.3 一般的な設定オプション
オプション 説明
allow-query 権限のあるリソースレコード用のネームサーバーにクエリーを許可されるホストを指定します。アクセス制御リスト、IP アドレスのコレクション、または CIDR 表記のネットワークのコレクションを受け入れます。デフォルトではすべてのホストが許可されています。
allow-query-cache 再帰クエリーなど権限の必要ないデータ用のネームサーバーにクエリーを許可されるホストを指定します。デフォルトでは、localhost と localnets のみが許可されます。
blackhole ネームサーバーへのクエリーを許可されないホストを指定します。このオプションは、特定のホストやネットワークがサーバーに要求を集中させる時には使用すべきではありません。デフォルトのオプションは none です。
directory named サービスの作業ディレクトリーを指定します。デフォルトのオプションは /var/named/ です。
disable-empty-zone 使用されるデフォルトの接頭辞リストから空白ゾーンを無効にするために使用します。options ステートメントおよび view ステートメントで指定することができます。複数回の使用が可能です。
dnssec-enable DNSSEC 関連のリソースレコードを返すかどうかを指定します。デフォルトのオプションは yes です。
dnssec-validation リソースレコードが DNSSEC を通じて本物であることを証明するかどうかを指定します。デフォルトのオプションは yes です。
empty-zones-enable 空白ゾーンを作成するかどうかを制御します。options ステートメントでのみ指定可能です。
forwarders 解決のために要求を転送するネームサーバーの有効な IP アドレス一覧を指定します。
forward
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 ファイルがデフォルトで使用されます。
注記
named がランタイムデータに使用するディレクトリーは、BIND のデフォルトの場所である /var /run/named/ から新しい場所 /run/named/ に移動しました。その結果、PID ファイルはデフォルトの場所 /var/run/named/named.pid から新しい場所 /run/named/named.pid に移動しました。さらに、session-key ファイルは /run/named/session.key に移動しました。これらの場所は、options セクションのステートメントで指定する必要があります。例15.4「オプションステートメントの使用」を参照してください。
重要
分散型サービス拒否(DDoS)攻撃を防ぐために、allow-query-cache オプションを使用して、クライアントの特定サブセットのみの再帰 DNS サービスを制限することが推奨されます。
利用可能なオプションの完全なリストは、「インストールされているドキュメント」 で参照されている 『BIND 9 Administrator Reference Manual』 および named.conf の man ページを参照してください。

例15.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 は、表15.4「Zone ステートメントで一般的に使用されるオプション」で説明されているように zone ステートメントオプションになります。
zone-name 属性は、/var/named/ ディレクトリーにある対応するゾーンファイル内で使用される $ORIGIN ディレクティブに割り当てられるデフォルト値であるため、特に重要です。named デーモンは、ゾーンの名前を、ゾーンファイルにリストされている非完全修飾ドメイン名に追加します。たとえば、zone ステートメントが example.com の名前空間を定義する場合は、example.com を zone-name として使用して、example.com ゾーンファイル内のホスト名の最後に配置されるようにします。
ゾーンファイルの詳細は、「ゾーンファイルの編集」を参照してください。
表15.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: ゾーンが不明な場合にクエリーを解決するルートネームサーバーをポイントする特別な種類のゾーン。hint ゾーンでは、デフォルト以外の設定は必要ありません。
  • master: このゾーンに対してネームサーバーを権威として指定します。ゾーンの設定ファイルがシステムに存在する場合は、ゾーンを master として設定する必要があります。
  • slave: このゾーンに対してネームサーバーをセカンダリーサーバーとして指定します。プライマリーサーバーは masters ディレクティブで指定します。
プライマリーまたはセカンダリーネームサーバーの /etc/named.conf ファイルに対するほとんどの変更には、zone ステートメントの追加、変更、または削除が必要で、通常は zone ステートメントオプションのサブセットのみが、ネームサーバーが効率的に機能させるために必要です。
例15.5「プライマリーネームサーバー用の Zone ステートメント」 では、ゾーンは example.com として識別され、タイプは master に設定され、named サービスは /var/named/example.com.zone ファイルを読み取るように指示します。また、セカンダリーネームサーバー(192.168.0.2)のみがゾーンを転送することを許可します。

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

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

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

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

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

以下のタイプのステートメントは、一般的に /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 オプションを使用すると、独自のファイル名 (file)、サイズ制限 (size)、バージョン番号 (version)、および重要度 (severity) でログのカスタマイズされたタイプを作成できます。カスタマイズされたチャネルが定義されると、カテゴリー オプションを使用してチャネルを分類し、named サービスの再起動時にロギングを開始します。
デフォルトでは、named は標準メッセージを rsyslog デーモンに送信し、それが /var/log/messages に配置されます。default_syslog （情報ロギングメッセージを処理）や default_debug （特にデバッグメッセージを処理する）など、さまざまな重大度レベルで BIND に組み込まれています。default と呼ばれる デフォルト のカテゴリーは、組み込みチャネルを使用して、特別な設定なしで通常のロギングを行います。
ロギングプロセスのカスタマイズは詳細なプロセスとなるため、本章の範囲外になります。カスタム BIND ログ作成の詳細は「インストールされているドキュメント」で参照されている BIND 9 Administrator Reference Manual (『BIND 9 管理者リファレンスマニュアル』) を参照してください。
server
server ステートメントにより、named サービスがリモートのネームサーバーに応答する方法に影響を与えるオプションを指定できます（特に通知およびゾーン転送に関するもの）。
transfer-format オプションは、各メッセージと共に送信されるリソースレコードの数を制御します。1 つの 応答(1 つ のリソースレコードのみ)または many-answers （複数のリソースレコード）のいずれかになります。many-answers オプションはより効率的ですが、古いバージョンの BIND ではサポートされていないことに注意してください。
ステートメントを使うと、安全な DNS (DNSSEC) に使用される各種パブリックキーを指定できるようになります。
trusted-keys ステートメントでは、DNSSEC （セキュアな DNS ）に使用されるソート済み公開鍵を指定できます。このトピックの詳細については、「DNSSEC (DNS Security Extensions)」を参照してください。
match-clients
view ステートメントでは、ホストがネームサーバーをクエリーするネットワークに応じて、特別なビューを作成できます。これにより、他のホストが全く異なる情報を受け取る間、ゾーンに関する応答が 1 つの応答を受け取ることができます。また、信頼されないホスト以外のホストでは他のゾーンに対するクエリーしか実行できません。
view はその名前が一意になっていれば、複数のものを使用できます。match-clients オプションを使用すると、特定のビューに適用される IP アドレスを指定できます。options ステートメントがビュー内で使用されると、設定済みのグローバルオプションが上書きされます。最後に、ほとんどの view ステートメントには、match-clients リストに適用される複数の zone ステートメントが含まれます。
view ステートメントが特定のクライアントの IP アドレスに一致する最初のステートメントが使用されるため、view ステートメントが記載されている順序が重要である点に注意してください。このトピックの詳細については、「複数表示」を参照してください。

15.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 */

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

「ネームサーバーゾーン」で要約したように、ゾーンファイルにはネームスペースの情報が含まれています。これらは、デフォルトで /var/ named / にある named 作業ディレクトリーに保存されます。各ゾーンファイルは、zone ステートメントの file オプションに従って名前が付けられます。通常、ドメインに関連する方法で、example.com.zone などのゾーンデータを含むゾーンデータとしてファイルを識別します。
表15.5 named サービスのゾーンファイル
パス 説明
/var/named/ named サービスの作業ディレクトリー。ネームサーバーにはこのディレクトリーに書き込む許可が ありません。
/var/named/slaves/ セカンダリーゾーンのディレクトリーです。このディレクトリーは named サービスによって書き込み可能です。
/var/named/dynamic/ 動的 DNS (DDNS)ゾーンや管理された DNSSEC キーなどの他のファイルのディレクトリー。このディレクトリーは named サービスによって書き込み可能です。
/var/named/data/ 様々な統計とデバッギングファイル用のディレクトリーです。このディレクトリーは named サービスによって書き込み可能です。
ゾーンファイルはディレクティブとリソースの記録で設定されています。ディレクティブはネームサーバーに対してタスクを実行するか、または特別なセッティングをゾーンに適用するように指示し、リソースレコードはゾーンのパラメーターを定義して識別子を個々のホストに割り当てます。ディレクティブはオプションですが、リソースレコードはゾーンにネームサービスを提供するために必須です。
ディレクティブとリソースレコードはすべて、個別の行で記入します。

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

ディレクティブはドル記号記号($)で始まり、その後にディレクティブ名が続き、通常はファイルの上部に表示されます。通常、ファイルの最上部に現れます。以下のディレクティブは一般的にゾーンファイルで使用されます。
$INCLUDE
$INCLUDE ディレクティブを使用すると、表示される場所に別のファイルを追加して、他のゾーン設定を別のゾーンファイルに保存できるようにします。

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

$INCLUDE /var/named/penguin.example.com
$ORIGIN
$ORIGIN ディレクティブを使用すると、ホスト名のみを持つレコードなど、ドメイン名を非修飾レコードに追加できます。デフォルトではゾーン名が使用されるため、/etc/named.conf にゾーンが指定されている場合は、このディレクティブの使用は必要ありません。
例15.8「$ORIGIN ディレクティブの使用」 では、リソースレコード内で使用され、末尾がピリオド( . 文字)で終わらない名前には example.com が追加されます。

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

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

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

$TTL 1D

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

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

例15.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 レコードを指してはいけません。
例15.11「CNAME リソースレコードの使用」 では、A レコードはホスト名を IP アドレスにバインドし、CNAME レコードは一般的に使用される www ホスト名を指します。

例15.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 リソースレコードが他の値よりも優先されます。しかし複数メールサーバーが同じ値を持つ可能性があり、その場合はメールトラフィックをサーバー間で均等に分配することになります。
例15.12「MX リソースレコードの使用」 では、example.com ドメイン宛のメールを受信する場合は、最初の mail.example.com メールサーバーが mail2. example.com メールサーバーよりも優先されます。

例15.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 つがプライマリーサーバーであるかどうかは重要でありません。両方とも正当と考慮されます。

例15.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)など、省略形を使用することができます。表15.6「秒表示とその他の時間単位」は、秒単位で、同等の時間 (秒単位) を別の形式で示しています。
表15.6 秒表示とその他の時間単位
秒 他の時間単位
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D

例15.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

15.2.3.3. コメントタグ

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

15.2.3.4. 使用例

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

例15.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.
;
;
この例では、権威ネームサーバーは dns 1.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 (WW)などの標準名で利用可能なサービスは、CNAME レコードを使用して適切なサーバーを参照します。
このゾーンファイルは、以下のように zone ステートメントが /etc/named.conf にて サービス と呼ばれます。 
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};
15.2.3.4.2. 逆引き名前解決ゾーンファイル
逆引き名前解決ゾーンファイルは、特定の namespace の IP アドレスを完全修飾ドメイン名(FQDN)に変換するために使用されます。これは標準のゾーンファイルと非常に似ていますが、PTR リソースレコードは、例15.16「逆引き名前解決ゾーンファイル」 に示すように、IP アドレスを完全修飾ドメイン名にリンクするために使用されます。

例15.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 アドレスは、対応する完全修飾ドメイン名を指しています。
このゾーンファイルは、以下のような /etc/named.conf ファイルの zone ステートメントを使用してサービスを呼び出します。 
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 番号の単一ブロックをゾーンに関連付けることができます。

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

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

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

サービスへの不正アクセスを防ぐには、named が選択したポートをリッスンするように設定する必要があります（デフォルトでは 953）。また、サービスと rndc ユーティリティーの両方で同じキーを使用する必要があります。
表15.7 関連ファイル
パス 説明
/etc/named.conf named サービスのデフォルトの設定ファイルです。
/etc/rndc.conf rndc ユーティリティーのデフォルト設定ファイル。
/etc/rndc.key デフォルトキーの場所
rndc 設定は /etc/rndc.conf にあります。ファイルが存在しない場合、ユーティリティーは /etc/rndc.key にあるキーを使用します。これは、rndc-confgen -a コマンドを使用してインストールプロセス時に自動的に生成されたものです。
named サービスは、「その他のステートメントタイプ」 で説明されている よう に、/etc/named.conf 設定ファイルの control ステートメントを使用して設定されます。このステートメントが存在しない限り、ループバックアドレス(127.0.0.1)からの接続のみが許可され、/etc/rndc.key にあるキーが使用されます。
このトピックの詳細は、man ページと 『BIND 9 Administrator Reference Manual』 にある「関連情報」を参照してください。
重要
非特権ユーザーが制御コマンドをサービスに送信しないようにするには、root のみが /etc/rndc.key ファイルを読み取れるようにします。 
~]# chmod o-rwx /etc/rndc.key

15.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

15.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.

15.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;
};

15.2.4.5. DNSSEC 検証の有効化

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

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

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

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

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

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

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

例15.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

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

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

例15.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

15.2.5.3. ホスト名の検索

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

例15.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

15.2.6. BIND の高度な機能

ほとんどの BIND 実装は、named サービスのみを使用して名前解決サービスを提供したり、特定のドメインの権限として機能することだけです。ただし、BIND バージョン 9 には、より安全で効率的な DNS サービスを可能にする多くの高度な機能があります。
重要
DNSSEC、TSIG、IXFR (増分ゾーン転送) などの高度な機能の使用を試みる前に、特に BIND の古いバージョンや BIND 以外のサーバーを使用している場合は、その特定の機能がネットワーク環境内のすべてのネームサーバーでサポートされていることを確認してください。
ここに記載されているすべての機能は「インストールされているドキュメント」で参照されている『BIND 9 Administrator Reference Manual』でより詳細に説明されています。

15.2.6.1. 複数表示

オプションとして、リクエストが発信されたネットワークに応じて異なる情報をクライアントに提供することができます。これは主に、ローカルネットワーク外のクライアントからの機密 DNS エントリーを拒否するために使用され、ローカルネットワーク内のクライアントからのクエリーを許可します。
複数のビューを設定するには、view ステートメントを /etc/named.conf 設定ファイルに追加します。match-clients オプションを使用して IP アドレス全体またはネットワーク全体を照合し、特別なオプションとゾーンデータを指定します。

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

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

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

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

15.2.6.4. DNSSEC (DNS Security Extensions)

DNSSEC( Domain Name System Security Extensions )は、DNS データの発信元認証、認証された存在拒否、およびデータの整合性を提供します。特定のドメインがセキュアとしてマークされている場合、検証に失敗したリソースレコードごとに SERVFAIL 応答が返されます。
DNSSEC 署名のドメインまたは DNSSEC 対応リゾルバーをデバッグするには、「dig ユーティリティーの使用」 で説明されているように、dig ユーティリティーを使用できます。便利なオプションは +dnssec (DNSSEC OK ビット)、+cd (応答の検証に再帰的ネームサーバー)、および +bufsize=512 (パケットサイズを 512B に変更してファイアウォール経由で取得する。

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

表15.3「一般的な設定オプション」で説明されているように、Internet Protocol version 6 (IPv6) は AAAA リソースレコードと listen-on-v6 ディレクティブを使用してサポートされます。

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

ネームサーバー設定時にユーザーが一般的な間違いを回避するためのアドバイスリストを以下に示します。
セミコロンと弓形括弧の正しい使用
/etc/named.conf ファイルのセミコロンまたは一致しない中括弧を使用すると、named サービスが起動しないようにすることができます。
期間( . 文字)を正しく使用
ゾーンファイル内では、ドメイン名の末尾のピリオドは完全修飾型ドメイン名を示します。省略した場合、named サービスはゾーンの名前または $ORIGIN の値を追加して完了します。
ゾーンファイルを編集する時のシリアル番号増加
シリアル番号が増加していない場合、プライマリーネームサーバーは正しくて新しい情報を持ちますが、セカンダリーネームサーバーは決して変更を通知されません。そのため、そのゾーンのデータをリフレッシュする試みをしません。
ファイヤーウォールの設定
ファイアウォールが named サービスから他のネームサーバーへの接続をブロックしている場合、ファイアウォール設定を変更することが推奨されます。
警告
DNS クエリーに固定 UDP ソースポートを使用すると、攻撃者がキャッシュポイズニング攻撃をより簡単に実施できるセキュリティー脆弱性が発生する可能性があります。これを防ぐために、デフォルトでは DNS はランダムな一時ポートから送信します。ランダムな UDP ソースポートからの発信クエリーを許可するようにファイアウォールを設定します。デフォルトでは、1024 から 65535 の範囲が使用されます。

15.2.8. 関連情報

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

15.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/
名前付き 設定ファイルのサンプルを含むディレクトリー。
rndc(8)
rndc ネームサーバー制御ユーティリティーの man ページ。その使用方法に関するドキュメントが含まれています。
named(8)
と いう名前 のインターネットドメイン名サーバーの man ページです。これには、BIND ネームサーバーデーモンの制御に使用できる各種の引数が記載されています。
lwresd(8)
軽量リゾルバーデーモン lwresd の man ページには、デーモンとその使用方法が記載されています。
named.conf(5)
の man ページには、named 設定ファイル内で利用可能なオプションの包括的な一覧が記載されています。
rndc.conf(5)
man ページには、rndc 設定ファイル内で利用可能なオプションの包括的なリストが記載されています。

15.2.8.2. オンラインリソース

https://access.redhat.com/site/articles/770133
Red Hat Enterprise Linux 6 と比較しての違いを含む、chroot 環境で BIND を実行するという Red Hat ナレッジベースアーティクルです。
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』
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.