12.2. /etc/named.conf

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

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

以下のタイプのステートメントが一般的に/etc/named.confで 使用できます:

12.2.1.1. aclステートメント

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-hatsred-hatsの2つのアクセス制御リストを 示していますが、black-hatsリスト内のホストは、ネームサーバーへのアクセスを拒否されて、 red-hatsリスト内のホストは通常のアクセスが許可されています。

12.2.1.2. includeステートメント

includeステートメントはファイルをnamed.confファイルにインクルードできるようにします。この方法で壊れやすい設定データ(keysなど)は限定権限を付けて個別のファイルに保管することが可能です。

includeステートメントは次のような形を取ります:

include  "<file-name>"

このステートメントでは、<file-name>は ファイルへの絶対パスで入れ換えます。

12.2.1.3. optionsステートメント

optionsステートメントはグローバルサーバーの設定オプションを定義して他のステートメントのデフォルトをセットします。これは named の作業ディレクトリの場所、許可できるクエリのタイプ、その他を指定するのに使用されます。

optionsステートメントは以下の形をとります:

options { 
        <option>;
	[<option>; ...] 
};

このステートメントでは、<option>ディレクティブは 有効なオプションで入れ換えます。

次のようなオプションが一般的に使用されます:

  • allow-query — どのホストにこのネームサーバーへのクエリを許可するかを指定します。 デフォルトでは、すべてのホストのクエリが許可されます。ここでアクセス制御リストや一連のIPアドレス又は ネットワークを使用して、特定のホストだけにネームサーバーへのクエリを許可することができます。

  • allow-recursionallow-queryと似ていますが、 これは繰り返しクエリに適用されます。デフォルトでは、すべてのホストにネームサーバーへの繰り返し クエリを行うことが許可されます。

  • blackhole — どのホストがサーバーへのクエリを許可されないか を指定します。

  • directorynamed作業ディレクトリをデフォルトの /var/named以外のディレクトリに指定します。

  • forwardforwardersディレクティブの転送動作を指定します。

    以下のようなオプションが許可されます:

    • firstnamedがその名前を自分で解決しようとする 前に、forwardersディレクティブに記されているネームサーバーにクエリが実行 されるよう指定します。

    • onlyforwardersディレクティブに指定されているネームサーバーへのクエリが失敗した場合、namedが自分で名前解決しないように指定します。

  • forwarders — 解決を求めて要求が転送されるネームサーバーの 有効なIPアドレスの一覧を指定します。

  • listen-onnamedがクエリの監視をする 場所であるネットワークインターフェイスを指定します。デフォルトではすべてのインターフェイスが 使用されます。

    このディレクティブを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-filenamedによって作成された プロセス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ページを参照してください。

12.2.1.4. zoneステートメント

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-statisticsnamedにこのゾーンについての統計を保持するよう設定し、デフォルトの場所(/var/named/named.stats)か、serverステートメントの statistics-fileオプションに記されているファイルのいずれかにこれを書きこみます。serverのステートメントに関する詳細は項12.2.2で御覧下さい。

12.2.1.5. zoneステートメントのサンプル

マスターネームサーバーやスレーブネームサーバーの/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.comzoneステートメントの例を示します。

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ファイルに保存されます。

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

以下に、named.confの中で利用でき、使用頻度に低いステートメントタイプの一覧を示します。

12.2.3. コメントタグ

以下にnamed.conf内で使用される有効な コメントタグの一覧を示します: