BIND設定ファイル

BINDネームサーバーであるnamedサーバーは、/etc/named.confファイルで設定を行います。すべてのゾーンファイルは、/var/namedディレクトリに置かれます。

警告警告
 

BIND設定ツールを使用している場合は、/etc/named.confファイルと/var/namedディレクトリ内のファイルを手動で編集しないでください。これらのファイルを手動で変更すると、次回BIND設定ツールを使用するときにこれらのファイルが上書きされてしまいます。

namedを起動するには/etc/named.confファイルにエラーがあってはなりません。いくつかのステートメントで使用される誤ったオプションはサーバーを停止するほど重大ではないと考えられていますが、ステートメントそのものの中にエラーがあった場合には、namedが起動できなくなります。

/etc/named.conf

/etc/named.confファイルは、大かっこ{ }内に置かれたネストされたオプションを使用するステートメントの集まりです。サンプルの/etc/named.confファイルは、図14-2同様に設定されています。

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

図 14-2. /etc/named.conf設定のサンプル

"<statement-name>" は、aclincludeserverviewzoneステートメントだけで必要です。<statement-N-class> は、zoneステートメントだけで指定することができます。

コメントは、ネストしたC形式の文字/* */の中か、//文字か、#文字の後に記述することができます。

以下のステートメントは、/etc/named.confで使用することができます。

ゾーンステートメントのサンプル

マスターネームサーバーやスレーブネームサーバーの/etc/named.confファイルに対する変更は、zoneステートメントの追加、変更、削除などに関わるものです。これらのzone ステートメントには、数多くのオプションを含めることができまが、ほとんどのネームサーバーは、そのうちのほんのわずかしか利用しません。以下のzoneステートメントは、マスタースレーブネームサーバー関係で利用することのできる非常に基本的な例です。

domain.comドメインのホストとして動作するプライマリネームサーバー上のzoneステートメントの例を図14-5に示します。

zone "domain.com" IN {
  type master;
  file "domain.com.zone";
  allow-update { none; };
};

図 14-5. 簡単なマスターzoneステートメントの例

このzoneステートメントは、ゾーンをdomain.comと名づけ、typemasterとして設定し、named/var/named/domain.com.zoneファイルを読んでそのゾーンを設定し、他のホストによる更新を認めないよう命令しています。

スレーブサーバーのdomain.comzoneステートメントの例を、図14-6に示します。

zone "domain.com" {
  type slave;
  file "domain.com.zone";
  masters { 192.168.0.1; };
};

図 14-6. 簡単なスレーブzoneステートメントの例

このzoneステートメントは、スレーブサーバーのnamed192.168.0.1マスターサーバーでdomain.comと呼ばれるゾーンの設定情報を見つけるよう命令します。スレーブサーバーがマスターサーバーから受け取った情報は、/var/named/domain.com.zoneファイルに保存されます。

ゾーンファイル

特定のネーム空間についての情報が記載されているゾーンファイルは、named作業ディレクトリに保存されます。デフォルトは、/var/namedです。各ゾーンファイル名は、zoneステートメントのfileオプションデータに従い、通常はexample.com.zoneなどのように、該当するドメインに関係し、ゾーンデータが記載されているアプリケーションファイルが識別できるような名前が付けられます。

各ゾーンファイルには、ディレクティブとリソースレコードが含まれている場合があります。ディレクティブは、ネームサーバーに対して、あることを実行したり、ゾーンに特別の設定を適用したりするよう命令するものです。リソースレコードは、ゾーンのパラメータを定義し、ゾーンのネーム空間内でのアイデンティティを特定のシステムに割り当てるものです。ディレクティブはオプションですが、リソースレコードはネームサービスをそのゾーンに提供するため必須です。すべてのディレクティブとリソースレコードは、定められた行に記載されなくてはなりません。

コメントは、ゾーンファイルのセミコロン(;)の後に置かれます。

ゾーンファイルディレクティブ

ディレクティブは、ディレクティブ名の先頭に置かれる$文字によって識別され、通常はゾーンファイルの先頭に置かれます。

以下のディレクティブが最も一般的に使用されます。

  • $INCLUDE ディレクティブが使用されている場所で、このゾーンファイル内に別のゾーンファイルをインクルードするようnamedに命令します。このディレクティブにより、おもなゾーンファイル以外にも追加ゾーン設定を保存することができます。

  • $ORIGIN ホストだけしか指定していないレコードなど、資格のないレコードに付けるドメイン名を設定します。

    たとえば、ゾーンファイルには以下のような行が含まれていてもかまいません。

    $ORIGIN domain.com.

    この時点で、リソースレコードで使用され、末尾のドット(.)で終了していないあらゆるリソースレコードにこのドメイン名が追加されます。言い換えれば、ゾーンレコードがネームサーバーによって読み込まれる場合、以下に示す最初の行は、2行目の記述のように解釈されるということです。

    ftp               IN   CNAME   server1
    ftp.domain.com.   IN   CNAME   server1.domain.com.

    注意注意
     

    /etc/named.confのゾーンに$ORIGINに割り当てる値と同じ名前を付けた場合、$ORIGINディレクティブを使用する必要はありません。ゾーンの名前はデフォルトでは$ORIGINディレクティブ値として使用されます。

  • $TTL デフォルトのTime to Live(TTL)値をゾーンに設定します。これは、ゾーンのリソースレコードの有効期間を知らせるためにネームサーバーに秒単位で与えられる数です。リソースレコードにも自分自身のTTL値を含めることができ、このTTL値によってこのディレクティブが無効になります。

    この値を増加させると、リモートネームサーバーは、このゾーンの情報をより長時間キャッシュします。こうすると、このゾーンについて行われるクエリの数は減りますが、リソースレコード変更を伝えるのに要する時間は長くなります。

ゾーンファイルリソースレコード

ゾーンファイルリソースレコードには、そのレコードを定義するデータのカラムがあり、ホワイトスペースによって区切られています。すべてのゾーンファイルリソースレコードは、あるタイプに割り当てられ、これによりそのレコードの目的が指定されます。以下のタイプのリソースレコードがもっとも一般的に使用されます。

  • A アドレスレコード。名前に割り当てるIPアドレスを指定する。

    <host>     IN     A     <IP-address>

    図 14-7. Aのレコード設定のサンプル

    <host>値が省略された場合、Aレコードはネーム空間の一番上のデフォルトIPアドレスをポイントします。このシステムは、すべての非FQDN要求の対象となります。

    domain.comゾーンファイルについて、以下のAレコード例を考えてみましょう。

                 IN     A       10.0.1.3
    server1      IN     A       10.0.1.5

    図 14-8. Aレコードの例

    domain.comの要求は10.0.1.3をポイントし、server1.domain.comの要求は10.0.1.5をポイントします。

  • CNAME 標準名レコード。これは、ある名前が別の名前でも知られていることをネームサーバーに知らせます。

    <alias-name>     IN     CNAME       <real-name>

    図 14-9. CNAMEのレコード設定のサンプル

    図14-9では、<alias-name>に送られたどの要求も<real-name>という名前のホストをポイントします。 共通命名スキームを使用するサービスを正しいホストにポイントするには、CNAMEレコードがもっとも一般的に使用されます。

    Aレコードが特定のホスト名をIPアドレスに設定し、CNAMEレコードが一般に使用されるwwwホスト名をそこにポイントする図14-10の例について考えてみましょう。

    server1      IN     A       10.0.1.5
    www          IN     CNAME   server1

    図 14-10. CNAMEレコードのサンプル

  • MX Mail eXchangeレコード。このゾーンによって制御されるネーム空間に送られるメールがどこへ行くのかを知らせます。

          IN     MX     <preference-value>  <email-server-name>

    図 14-11. MXのレコード設定のサンプル

    図14-11では、<preference-value>を使用することにより、このネーム空間のEメールを受け取りたいEメールサーバーを数値的にランクづけることができるため、あるEメールシステムを他のEメールシステムより優先することがきます。最低の<preference-value>を持つMXリソースレコードは、他のものよりも優先されますが、同じ値で複数のEメールサーバーを指定してEメールのトラフィックを分散させることができます。

    正しいシステムをポイントしている限りにおいて、<email-server-name>には、ホスト名かFQDNを指定することができます。

          IN     MX     10     mail.domain.com.
          IN     MX     20     mail2.domain.com.

    図 14-12. MXレコードの例

    この例では、domain.comドメイン向けEメールを受信する場合、最初のmail.domain.comEメールサーバーは、mail2.domain.comEメールサーバーよりも優先されます。

  • NS ネームサーバーレコード。あるゾーンに対して権限のあるネームサーバーを発表する。

          IN     NS     <nameserver-name>

    図 14-13. NSのレコード設定のサンプル

    <nameserver-name>はFQDNでなくてはなりません。

    図14-14では、2つのネームサーバーがあるドメインについて権限を持っていることが示されます。これらのネームサーバーがどちらもスレーブであるか、それとも1つはマスターであるかは重要ではありません。これらは両方とも権限があると考えられます。

          IN     NS     dns1.domain.com.
          IN     NS     dns2.domain.com.

    図 14-14. NSレコードの例

  • PTR PoinTeRレコード。ネーム空間の別の部分を指すよう指定される。

    PTRレコードは、逆にIPアドレスから名前をポイントするため、主に逆引き名前解決に使用されます。使用中のPTRレコードの例については、逆引き名前解決ゾーンファイルを参照してください。

  • SOA Start Of Authorityレコード。ネーム空間についての重要な権限ある情報をネームサーバーに示す。

    SOAレコードは、ディレクティブの後に置かれ、ゾーンファイル内の最初のリソースレコードとなります。

    @     IN     SOA    <primary-name-server>     <hostmaster-email> (
                        <serial-number>
                        <time-to-refresh>
    		    <time-to-retry>
    		    <time-to-expire>
    		    <minimum-TTL> )

    図 14-15. SOAのレコード設定のサンプル

    @記号は、このSOAリソースレコードによって定義されているネーム空間として$ORIGINディレクティブ($ORIGINディレクティブが設定されていない場合にはゾーンの名前)を置きます。<primary-nameserver>では、このドメインに権限を持つプライマリネームサーバーが使われ、このネーム空間についてコンタクトをとる人のEメールは、<hostmaster-email>の代わりとなります。

    namedが、このゾーンをリロードするべきであることがわかるよう<serial-number>は、ゾーンファイルが変更されるたびにインクリメントされます。<time-to-refresh>は、ゾーンに変更が行われた場合にマスターネームサーバーに問い合わせるまでどのくらい長く待つべきかをすべてのスレーブサーバーに知らせます。<serial-number>値は、スレーブが旧式のゾーンデータを使用しているかどうか、そしてリフレッシュすべきなのかどうかを判断するため、スレーブによって使用されます。

    <time-to-retry> は、マスターネームサーバーが回答していない場合に、別のリフレッシュ要求を発行するまでどのくらいの間隔待つべきかをスレーブネームサーバーに知らせます。マスターが、<time-to-expire>の経過前にリフレッシュ要求に回答しない場合、スレーブはそのネーム空間についての要求について権限をもつものとして応答するのを停止します。

    <minimum-TTL>は、他のネームサーバーが少なくともこの時間ゾーンの情報をキャッシュすることを要求します。

    BINDでは、すべての時間は秒数で表します。しかし、分(M)、時間(H)、日(D)、週(W)など秒以外の時間単位の短縮形を使用することもできます。表14-1の表は、秒数での時間量と他のフォーマットでの等価時間を示します。

    表 14-1. 他の時間単位と比較した秒数

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

    以下の例は、基本的なSOAリソースレコードがどのように表示されるかを示したものです。

    @     IN     SOA    dns1.domain.com.     hostmaster.domain.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-16. SOAレコードの例

ゾーンファイルの例

個別に見た場合、ディレクティブとリソースレコードは把握するのが困難です。しかし、共通ファイルにいっしょに置くとすべてがずっと意味のあるものになります。

図14-17に、非常に基本的なゾーンファイルを示します。

$ORIGIN domain.com.
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.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.domain.com.
      IN     NS     dns2.domain.com.

      IN     MX     10     mail.domain.com.
      IN     MX     20     mail2.domain.com.

             IN     A       10.0.1.5

server1      IN     A       10.0.1.5
server2      IN     A       10.0.1.7
dns1         IN     A       10.0.1.2
dns2         IN     A       10.0.1.3

ftp          IN     CNAME   server1
mail         IN     CNAME   server1
mail2        IN     CNAME   server2
www          IN     CNAME   server2

図 14-17. 基本的ゾーンファイルの例

この例では、標準ディレクティブとSOA値が使われています。権限のあるネームサーバーは、dns1.domain.comdns2.domain.comに設定され、これらをそれぞれ10.0.1.210.0.1.3に結び付けるAレコードがあります。

MXレコードで設定されるEメールサーバーは、CNAMEレコードを介してserver1server2をポイントします。server1server2の名前は最後がドット(.)で終わっていないため、その後ろに$ORIGINドメインが置かれ、server1.domain.com.server2.domain.comに拡張されます。関連Aリソースレコードを通して、そのIPアドレスを決定することができます。

標準名のftp.domain.comwww.domain.comで利用できる一般的なFTPとWebのサービスは、CNAMEレコードを使って、これらの名前に合ったサービスを提供するマシンにポイントされます。

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

逆引き名前解決ゾーンファイルは、特定のネーム空間のIPアドレスをFQDNに変換します。これは標準ゾーンファイルにとてもよく似ていますが、PTRリソースレコードがIPアドレスをあるシステムの名前に連結するのに使われるという点で異なっています。

PTRレコードは、図14-18に似た方法で記載されます。

<last-IP-digit>      IN     PTR    <FQDN-of-system>

図 14-18. PTRのレコード設定のサンプル

<last-IP-digit>は、特定のシステムのFQDNをポイントすべきIPアドレスの最後の数と一致します。

図14-19では、10.0.1.20から10.0.1.25までのIPアドレスが対応するFQDNにポイントされています。

$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.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.domain.com.
      IN     NS     dns2.domain.com.

20    IN     PTR    alice.domain.com.
21    IN     PTR    betty.domain.com.
22    IN     PTR    charlie.domain.com.
23    IN     PTR    doug.domain.com.
24    IN     PTR    ernest.domain.com.
25    IN     PTR    fanny.domain.com.

図 14-19. 基本的逆引きゾーン解決ファイルの例

このゾーンファイルは、図14-20に似た/etc/named.confファイルのzoneステートメントでサービスに呼びこまれます。

zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "domain.com.rr.zone";
  allow-update { none; };
};

図 14-20. 逆引き解決zoneステートメントの例

ゾーンの命名法を除き、この例と標準zoneステートメントの間にはほとんど違いがありません。逆引き名前解決ゾーンでは、IPアドレスの最初の3つのブロックを逆にし、その後に「.in-addr.arpa」を添付する必要があることに注意してください。これにより逆引き名前解決ゾーンファイルで使用されるIP番号の1つのブロックがこのゾーンで正しく添付されます。