named.confファイルは、左右の大括弧 { }で囲まれた組み込みオプションを使用した一連のステートメントです。多くの小さなエラーが namedサービスの開始を阻止しますので、管理者はnamed.confを編集する時に構文上のエラーを避けるように注意する必要があります。
![]() | 警告 |
---|---|
ドメイン名サービス設定ツールを使用している場合は、/etc/named.confファイル、あるいは/var/namedディレクトリ内のファイルを手動で編集しないでください。これらのファイルへの手動変更はすべて、次回にドメイン名サービス設定ツールが使用される時点に上書きされてしまいます。 |
標準的な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>; }; |
以下のタイプのステートメントが一般的に/etc/named.confで 使用できます:
aclステートメント(access control statement)は ネームサーバーへ許可又は拒否されるホストのグループを定義します。
aclステートメントは次の形をとります:
acl <acl-name> { <match-element>; [<match-element>; ...] }; |
このステートメント内では、<acl-name>を アクセス制御リストの名前で入れ換え、<match-element>を セミコロンで隔離されたIPアドレスで入れ換えます。殆どの場合、個々のIPアドレス、又は IPネットワーク表記(10.0.1.0/24など)を使用してacl ステートメント内のIPアドレスを識別します。
次のアクセス制御リストは、設定を簡素がする為にキーワードとして 既に定義されています:
any — すべてのIPアドレスと一致。
localhost — ローカルシステムによって 使用されているIPアドレスと一致。
localnets — ローカルシステムが接続しているネットワークのIPアドレスと一致。
none — どのIPアドレスとも一致しない。
他のステートメント(optionsステートメントなど)と一緒に使用した場合、aclステートメントは BINDネームサーバーの誤用を防止するのに役に立ちます。
次の例は、2つのアクセス制御リストを定義し、optionsステートメントを使用して ネームサーバーによるそれらの取扱方法を指定しています:
acl black-hats { 10.0.2.0/24; 192.168.0.0/24; }; acl red-hats { 10.0.1.0/24; }; options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; }; } |
上記の例は、black-hatsとred-hatsの2つのアクセス制御リストを 示していますが、black-hatsリスト内のホストは、ネームサーバーへのアクセスを拒否されて、 red-hatsリスト内のホストは通常のアクセスが許可されています。
includeステートメントはファイルをnamed.confファイルにインクルードできるようにします。この方法で壊れやすい設定データ(keysなど)は限定権限を付けて個別のファイルに保管することが可能です。
includeステートメントは次のような形を取ります:
include "<file-name>" |
このステートメントでは、<file-name>は ファイルへの絶対パスで入れ換えます。
optionsステートメントはグローバルサーバーの設定オプションを定義して他のステートメントのデフォルトをセットします。これは named の作業ディレクトリの場所、許可できるクエリのタイプ、その他を指定するのに使用されます。
optionsステートメントは以下の形をとります:
options { <option>; [<option>; ...] }; |
このステートメントでは、<option>ディレクティブは 有効なオプションで入れ換えます。
次のようなオプションが一般的に使用されます:
allow-query — どのホストにこのネームサーバーへのクエリを許可するかを指定します。 デフォルトでは、すべてのホストのクエリが許可されます。ここでアクセス制御リストや一連のIPアドレス又は ネットワークを使用して、特定のホストだけにネームサーバーへのクエリを許可することができます。
allow-recursion — allow-queryと似ていますが、 これは繰り返しクエリに適用されます。デフォルトでは、すべてのホストにネームサーバーへの繰り返し クエリを行うことが許可されます。
blackhole — どのホストがサーバーへのクエリを許可されないか を指定します。
directory — named作業ディレクトリをデフォルトの /var/named以外のディレクトリに指定します。
forward — forwardersディレクティブの転送動作を指定します。
以下のようなオプションが許可されます:
first — namedがその名前を自分で解決しようとする 前に、forwardersディレクティブに記されているネームサーバーにクエリが実行 されるよう指定します。
only — forwardersディレクティブに指定されているネームサーバーへのクエリが失敗した場合、namedが自分で名前解決しないように指定します。
forwarders — 解決を求めて要求が転送されるネームサーバーの 有効なIPアドレスの一覧を指定します。
listen-on — namedがクエリの監視をする 場所であるネットワークインターフェイスを指定します。デフォルトではすべてのインターフェイスが 使用されます。
このディレクティブをDNS上で使用するとDNSサーバーはゲートウェイとしても機能し、 BINDは、そのネットワークの 1つから届くクエリのみに回答するように設定できます。
以下にlisten-onディレクティブの例を示します。
options { listen-on { 10.0.1.1; }; }; |
この例では、プライベートネットワーク用ネットワークインターフェイスから到着した要求(10.0.1.1)だけが受け付けられます。
notify — ゾーンが更新された時にnamedから スレーブサーバーにnamedから通知を出すかどうかを制御します。 次のようなオプションが受け付けられます:
yes — スレーブサーバーに通知します。
no — スレーブサーバーに通知しません。
explicit — ゾーンステートメント内にある also-notifyリストに指定してあるスレーブサーバーにのみ通知します。
pid-file — namedによって作成された プロセスIDファイルの場所を指定します。
root-delegation-only — TLD (op-level domains)と、オプションの排除リストをもつ root ゾーン内での代行プロパティの強制執行を始動します。代行(Delegation)とは、単独ゾーンを複数のサブゾーンに分離するプロセスのことです。代行ゾーンを作成するには、NS records(NameServer records)として知られる項目が使用されます。ネームサーバー記録(NameServer records)(代行記録)は特定のゾーン用に権限的ネームサーバーを指名します。
以下のroot-delegation-onlyの例は、代行のない対応が予期され、信用される送信元としての TLD の排除リストを指定します:
options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; }; |
statistics-file — 統計ファイル用に別の場所を指定することができます。 デフォルトでは、named統計は、/var/named/named.statsファイルに 保存されています。
他にも数十のオプションが利用できます。その多くは正常に機能するためにそれぞれ他のオプションに 依存します。詳細に関しては、 項12.7.1内のBIND 9 アドミニストレータ リファレンスマニュアル、及びbind.confのmanページを参照してください。
zoneステートメントはその設定ファイルの場所やゾーン独自のオプションなど ゾーンの特徴を指定します。このステートメントは、グローバルoptionsステートメントを 上書きするのに使用できます。
zoneステートメントは以下のような形をとります:
zone <zone-name> <zone-class> { <zone-options>; [<zone-options>; ...] }; |
このステートメントでは、<zone-name>がゾーンの名前であり、 <zone-class>がゾーンのオプションクラスで、 <zone-options>がゾーンの特徴となるオプションの一覧です。
<zone-name>の属性はゾーンステートメントにとって重要です。/var/named/ディレクトリに位置している対応のゾーンファイルで使用される$ORIGINディレクティブに、割り当てられるデフォルト値なのです。namedデーモンはゾーンファイル内にリストしてあるいずれかの非完全修飾ドメイン名にゾーンの名前を付け加えます。
例えば、zoneステートメントが example.com用にネーム空間を定義する場合、example.comを <zone-name> として使用すると、それはexample.com ゾーンファイルの中でホスト名の末尾に配置されます。
ゾーンファイルに関する詳細は項12.3で御覧下さい。
最も一般的なzoneステートメントオプションには次の ようなものがあります:
allow-query — このゾーンについての情報を要求することのできるクライアントを指定します。 デフォルトでは、すべてのクエリ要求を許可します。
allow-transfer — ゾーン情報の転送を要求することが許可されたスレーブサーバーを指定します。 デフォルトでは、すべての転送要求を許可します。
allow-update — ゾーン内の情報を動的に更新することのできるホストを指定します。 デフォルトでは、すべての動的更新要求を拒否します。
ホストがゾーン情報を更新するのを許可する場合には十分注意が必要です。指定されたホストが完全に 信頼されていない場合には、このオプションを有効にしないでください。もし可能であれば管理者に手動で ゾーンのレコードを更新してもらい、namedサービスをリロードするのがよいでしょう。
file — ゾーンの設定データが記載されたnamed作業ディレクトリの 中のファイル名を指定します。
masters — 権限のあるゾーン情報の要求先のIPアドレスを指定します。 ゾーンが typeslaveとして定義されている場合にのみ使用します。
notify — ゾーンが更新された時にnamedがスレーブサーバーを通知するかどうかを指定します。 このディレクティブは、次のようなオプションを受けつけます。
yes — スレーブサーバーに通知します。
no — スレーブサーバーに通知しません。
explicit — ゾーンステートメント内にある also-notifyリストに指定してあるスレーブサーバーにのみ通知します。
type — ゾーンのタイプを定義します。
以下に有効なオプションを示します:
delegation-only — COM, NET, 又は ORG などのインフラストラクチャゾーンの代行ステータスを強制執行します。明示された、あるいは暗示された代行はNXDOMAINとして扱われます。このオプションは再帰的、又はキャッシュ化実装で使用される TLD や root ゾーンでのみ適用できます。
forward — 他のネームサーバーにこのゾーンの情報を求めるすべての要求を転送します。
hint — ルートネームサーバーをポイントするのに使用される特別なタイプのゾーンです。 ルートネームサーバーは、他の方法ではあるゾーンのことがわからない場合に、クエリを解決します。hint ゾーンでは、デフォルトを越えた設定は必要ありません。
master — このゾーン用の権限としてのネームサーバーを 示します。システムにそのゾーンの設定ファイルがある場合、そのゾーンはmasterとして 設定しなくてはなりません。
slave — このネームサーバーをこのゾーンのスレーブサーバーと 指名します。さらに、このゾーン用にマスターネームサーバーのIPアドレスを指定します。
zone-statistics — namedにこのゾーンについての統計を保持するよう設定し、デフォルトの場所(/var/named/named.stats)か、serverステートメントの statistics-fileオプションに記されているファイルのいずれかにこれを書きこみます。serverのステートメントに関する詳細は項12.2.2で御覧下さい。
マスターネームサーバーやスレーブネームサーバーの/etc/named.confファイルに対する変更は、 zoneステートメントの追加、変更、削除などに関わるものです。これらのzoneステートメント には、数多くのオプションを含めることができまが、ほとんどのネームサーバーは、そのうちのほんのわずかしか利用しません。 以下のzoneステートメントは、マスター/スレーブネームサーバー関係で利用することのできる非常に 基本的な例です。
以下に example.com をホストするプライマリネームサーバー(192.168.0.1)用の zoneステートメントの1例を示します:
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; }; |
ステートメントでは、ゾーンはexample.comとして識別され、タイプはmasterに設定され、namedサービスは /var/named/example.com.zoneファイルを読み込むように指示されます。 また、namedは他のホストの更新を許可しないように指示しています。
example.com用のスレーブサーバーのzoneステートメントは 前の例とは若干異なります。スレーブサーバー用には、タイプがslaveにセットされ、allow-update行の場所には、namedに対して マスターサーバーのIPアドレスを伝えるディレクティブがあります。
以下にexample.comのzoneステートメントの例を示します。
zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; }; |
このzoneステートメントは、スレーブサーバー上のnamedを設定して、example.comゾーンに関する情報を得るために192.168.0.1の IPアドレスでマスターサーバーを見付けます。スレーブサーバーがマスターサーバーから取得する情報は /var/named/example.com.zoneファイルに保存されます。
以下に、named.confの中で利用でき、使用頻度に低いステートメントタイプの一覧を示します。
controls — namedサービス管理用の rndcコマンドを使用するのに必要な各種のセキュリティ要求を設定します。
controlsステートメントがどのように構成されているか、及び利用できるオプションは、項12.4.1を参照して下さい。
key "<key-name>" — 名前によって特定の鍵を定義します。鍵は安全な更新やrndc コマンドの使用などのさまざまな行動の認証に使用されるものです。keyでは 以下の2つのオプションが使用されます:
algorithm <algorithm-name> — dsa又はhmac-md5など、 使用されるアルゴリズムのタイプ。
secret "<key-value>" — 暗号化した鍵。
keyステートメントの書き方については項12.4.2を参照してください。
logging — channelと呼ばれる 複数タイプのログの使用を許可します。loggingステートメント内で channelオプションを使用することにより、自己のファイル名(file)、 サイズ限定(size)、バージョン指定(version)、及び重要度の レベル(severity)などを持つカスタムタイプのログを構成することができます。 1度カスタムチャンネルが定義されると、categoryオプションを使用して チャンネルを分類化でき、namedが再起動した時にログが始まります。
ディフォルトでは、namedは、syslogデーモンへ 標準のメッセージをログします。そしてそれを/var/log/messagesに 配置します。これが起こるのは、幾つかの標準チャンネルが数種の重要度レベルで BINDに組み込まれており、その1つとして情報ログのメッセージ(default_syslog)を 処理するもの、もう1つは特にデバッグを処理するメッセージ(default_debug)を処理する ものなどがあるからです。defaultと呼ばれるデフォルトのカテゴリーは、特殊な設定なしに 通常のログを取る組み込みチャンネルを使用します。
ログプロセスのカスタマイズは、かなり細かなプロセスでこの章の説明範囲から越えてしまうものです。カスタムの BIND ログの作成法に関する詳細は、項12.7.1の中のBIND 9 管理者リファレンスマニュアルを御覧下さい。
server — 特に通知とゾーン転送に関して、 namedがリモートネームサーバーに対してどう対処すべきかを左右するオプションを指定します。
transfer-formatオプションは、1つのリソースレコードが それぞれのメッセージ(one-answer)と共に送信されるか、又は 複数のリソースレコードがそれぞれのメッセージ(many-answers)と 一緒に送信されるかを制御します。many-answersはより効率的ですが 最新のBINDネームサーバーだけがそれを理解します。
trusted-keys — この中にはセキュアDNS (DNSSEC)で使用される各種の公共鍵が含まれています。BINDセキュリティに関する詳細は項12.5.3で御覧下さい。
view "<view-name>" — どのネットワークがネームサーバーに問い合わせをしているホストがオンに なっているかに応じて特別なビューを作成します。 これにより、 幾つかのホストはあるゾーンに関して1つの回答を受けることができ、その他のホストは全く別の情報を受け取るようにできます。別の方法として、特定のゾーンだけが特定の信頼できる ホストに利用可能となり、信用できないホストは単に他のゾーンに関するクエリをするだけということも出来ます。
名前が独自であれば、複数のビューも使用できます。match-clients オプションは、特定のビューに適用するIP アドレスを指定します。どのような optionsステートメントでもビューの中で使用でき、既にnamed用に 設定してあるグローバルオプションを上書き出来ます。殆どのviewステートメントは match-clientsリストに適用できる複数のzoneステートメントを 含んでいます。特定クライアントのIPアドレスに適合する最初のviewステートメントが採用される為、viewステートメントがリストされている順序が重要です。
viewステートメントに関する詳細は項12.5.2で御覧下さい。