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ファイルは、図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>" は、acl、include、server、view、zoneステートメントだけで必要です。<statement-N-class> は、zoneステートメントだけで指定することができます。
コメントは、ネストしたC形式の文字/* */の中か、//文字か、#文字の後に記述することができます。
以下のステートメントは、/etc/named.confで使用することができます。
acl <acl-name> あるnamedサービスが許可されるか、あるいは禁止されるIPアドレスのアクセス制御リストを設定します。たいていの場合、(10.0.1.0/24などの)個々のIPアドレスかIPネットワークの表記を使用して正確なIPを識別します。
いくつかのアクセス制御リストはすでに定義されているので、aclステートメントを設定して、これらを定義する必要はありません。
any すべてのIPアドレスと一致。
localhost ローカルシステムによって使用されているIPアドレスと一致。
localnets ローカルシステムがそのインターフェイスで接続するネットワークのIPアドレスと一致。
none どのIPアドレスとも一致しない。
aclステートメントを他の/etc/named.confステートメントとそのオプションとともに利用した場合、このステートメントは、ユーザーのBINDネームサーバーが正しく使用されていることを確認するのに役立ちます。図14-3の例を考えてみましょう。
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; };
} |
図 14-3. 使用中のaclステートメントの例
named.confには、2つのアクセス制御リスト(black-hatsとred-hats)が含まれています。
controls rndcコマンドを使ってnamedサービスを管理するのに必要なさまざまなセキュリティ要件を設定します。
controlsステートメントが、このステートメントでしか使用することのできないさまざまなオプションとともにどのように表示されるかを知るには、/etc/named.conf項を参照してください。
include "<file-name>" 現在の設定ファイル内にある指定されたファイルをインクルードして、(keysなどの)機密設定データを許可つきの別のファイルに置き、特権の与えられていないユーザーが読むのを防ぐことができます。
key "<key-name>" 名前ごとに鍵を定義します。鍵は、安全な更新やrndcコマンドの使用などさまざまな動作を認証するものです。keyでは、2つのオプションを使用することができます。
algorithm <algorithm-name> 使用されるアルゴリズムのタイプ。dsaやhmac-md5など。
secret "<key-value>" 暗号鍵。
keyステートメントの例については、図14-22を参照してください。
logging チャンネルと呼ばれるいくつかのタイプのログの使用を許可します。loggingステートメント内でchannelオプションを使用することにより、独自のファイル名(ファイル)、サイズ制限(size)、バージョン(version)、重要度(severity)などを持つカスタマイズされたタイプのログを構築することができます。いったんカスタマイズされたチャンネルが定義されると、categoryオプションを使ってチャンネルを分類し、namedが再起動されたときにロギングを開始します。
デフォルトでは、namedが標準メッセージをsyslogデーモンへログ出力します。syslogデーモンは、これをデフォルトとして/var/log/messagesに置きます。このようなことが行われるのは、情報ロギングメッセージを扱うチャンネル(default_syslog)や特にデバッグメッセージを扱うチャンネル(default_debug)などいくつかの標準チャンネルがさまざまな重大度レベルでBINDに構築されているためです。defaultと呼ばれるデフォルトカテゴリは内蔵チャンネルを使用して、特別の設定を行わずに通常のロギングを行います。
ロギングプロセスのカスタマイズは非常に詳細なプロセスであり、この章の範囲を越えています。カスタムBINDログ作成の詳細については、BIND9管理者リファレンスマニュアルを参照してください。
options フォワーダの使用、named作業ディレクトリの位置、さまざまなファイルの名前などの多種多様なオプションを割り当てます。
もっとも一般的に利用されるオプションを以下に示します。
allow-query どのホストにこのネームサーバーへのクエリを許可するかを指定します。デフォルトでは、すべてのホストのクエリが許可されます。ここでアクセス制御リストやIPアドレス、あるいはネットワークの集まりを利用して、特定のホストだけにネームサーバーへのクエリを許可することができます。
allow-recursion allow-queryと似ていますが、これは繰り返しクエリに適用されます。デフォルトでは、すべてのホストにネームサーバーへの繰り返しクエリを行うことが許可されます。
directory named作業ディレクトリをデフォルトの/var/named以外のディレクトリに変更します。
forward forwardersオプションに要求の送付先を指定した有効なIPアドレスが含まれる場合に、転送方法を管理します。
firstオプションが使用されると、forwardersオプションに指定されるネームサーバーにまずクエリが行われます。そのネームサーバーが情報を持っていない場合、namedは、自分自身でこれを解決しようとします。
onlyオプションが使用されると、フォワーダがうまくいかなかった場合、namedは自分自身でこれを解決しようとしません。
forwarders 解決を求めて要求を転送するネームサーバーの一覧を指定します。
listen-on namedがクエリがないかどうかを調べるのに使用するネットワークインターフェイスを指定します。デフォルトでは、すべてのインターフェイスが利用されます。
このオプションは、ユーザーが複数のインターフェイスネットワークを持っており、ネームサーバーの要求を行うことのできるシステムを制限したい場合に役に立ちます。たとえば、ユーザーがゲートウェイやネームサーバーとして機能しているマシンを持っており、プライベートネットワークからの要求以外は閉め出したい場合、listen-onオプションを、図14-4のように設定すればよいのです。
このようにすると、プライベートネットワーク用ネットワークインターフェイスから到着した要求(10.0.1.1)だけが受け付けられます。
notify ゾーンが更新されたときに、namedがスレーブサーバーに更新を通知するかどうかを制御します。デフォルトは、yesですが、これをnoに設定してスレーブには通知されないようにしたり、explicitに設定してalso-notify一覧のサーバーだけに通知することもできます。
pid-file このオプションにより、起動時にnamedによって作成されたプロセスIDファイルの場所を指定することができます。
statistics-file このオプションにより、統計ファイルが書かれている場所を指定することができます。デフォルトでは、named統計は、/var/named/named.statsに保存されています。
まだたくさんのオプションが利用可能ですが、その多くは相互に依存することにより適切に動作します。詳細については、BIND9管理者リファレンスマニュアルを参照してください。
server 特に通知とゾーン転送についてnamedのリモートネームサーバーに対する動作に影響を与えるオプションを指定します。
transfer-formatオプションは、1つのリソースレコードが各メッセージとともに送られるか(one-answer)、あるいは複数のリソースレコードが各メッセージとともに送られるか(many-answers)を指定します。many-answersの方が効率的ですが、より新しいBINDネームサーバーしか理解することができません。
trusted-keys DNSSECに使用される多種多様な公開鍵が含まれています。BINDセキュリティの概要については、セキュリティ項を参照してください。
view "<view-name>" ネームサーバーと連結するホストにより、特定のタイプの情報で応答する特別のビューを作成します。このオプションを利用すれば、あるホストがある特定のゾーンについて1つの回答を受け取り、他のホストがまったく異なった回答を受け取ることができます。また、あるゾーンは特定の信頼されているホストだけが利用することができ、他のゾーンについては信頼されていないホストでも今までどおりクエリを行えるようにすることができます。
名前が一意的なものでさえあれば複数のビューを使用することができます。match-clientsオプションは、特定のビューに適用されるIPアドレスを指定します。ビュー内ではどのoptionステートメントも利用することができるので、namedにすでに設定されたグローバルオプションは無効になります。ほとんどのviewステートメントには、match-clients一覧に適用される複数のzoneステートメントが含まれています。ある特定のクライアントのIPアドレスに一致する最初のviewステートメントが使用されるため、viewステートメントを一覧に表示する順番は重要です。
viewステートメントの詳細については、複数ビュー項を参照してください。
zone "<zone-name>" このネームサーバーが権限を持つゾーンを指定します。zoneステートメントは、主にそのゾーンの設定を含むファイルを指定したり、そのゾーンについての情報を/etc/named.confで使用される他のグローバルoptionステートメントを無効にするnamedに渡したりするのに使用されます。
ゾーンの名前は重要です。なぜなら、ゾーンの名前はゾーンファイルで使用される$ORIGINディレクティブに割り当てられるデフォルト値であり、この名前が非FQDNの後に付けられるためです。したがって、たとえばこのzoneステートメントがネーム空間をdomain.comと定義した場合、<zone-name>としてdomain.comを使用しなくてはなりません。そうすれば、この名前がゾーンファイルで使用されるホスト名の最後に置かれます。
もっとも一般的なzoneステートメントには以下のようなものがあります。
allow-query このゾーンについての情報を要求することのできるクライアントを指定します。デフォルトは、すべてのクエリ要求を許可することです。
allow-transfer ゾーン情報の転送を要求することが許可されたスレーブサーバーを指定します。デフォルトは、すべての転送要求を許可することです。
allow-update ゾーン内の情報を動的に更新することのできるホストを指定します。デフォルトは、すべての動的更新要求を拒否することです。
![]() | 重要 |
|---|---|
ホストがゾーン情報を更新するのを許可する場合には注意が必要です。指定されたホストが完全に信頼されていない場合には、このオプションを有効にしないでください。もし可能であれば管理者に手動でゾーンのレコードを更新してもらい、namedサービスをリロードするのがよいでしょう。 |
file ゾーンの設定データが記載されたnamed作業ディレクトリ(デフォルトでは/var/named)にあるファイルの名前を指定します。
masters ゾーンがスレーブtypeとして定義されている場合に使用されます。mastersオプションは、スレーブのnamedに権限のあるゾーン情報を要求するためのIPアドレスを知らせます。
notify optionステートメントで使用されるnotifyオプションと同じように動作します。
type ゾーンのタイプを定義します。以下のタイプが利用できます。
forward ネームサーバーにこのゾーンの情報を求めるすべての要求を転送するよう要求します。
hint ルートネームサーバーをポイントするのに使用される特別なタイプのゾーンです。ルートネームサーバーは、他の方法ではあるゾーンのことがわからない場合に、クエリを解決するために利用されるものです。/etc/named.confのデフォルトを越えてヒントゾーンを設定する必要はありません。
master このネームサーバーをこのゾーンについて権限をもつネームサーバーとして指定します。このシステムにゾーンの設定ファイルがある場合、そのゾーンはmasterタイプとして設定しなくてはなりません。
slave このネームサーバーをこのゾーンのスレーブサーバーとして指定します。namedには、このゾーンのマスターネームサーバーのIPアドレスからこのゾーンの設定ファイルを要求するよう命令します。
zone-statistics namedにこのゾーンについての統計を保持するよう命令し、デフォルト位置(/var/named/named.stats)か、あるいはserverステートメントのstatistics-fileオプションによって特に指定された場所にこれを書きこみます。
マスターネームサーバーやスレーブネームサーバーの/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と名づけ、typeをmasterとして設定し、namedに/var/named/domain.com.zoneファイルを読んでそのゾーンを設定し、他のホストによる更新を認めないよう命令しています。
スレーブサーバーのdomain.comのzoneステートメントの例を、図14-6に示します。
zone "domain.com" {
type slave;
file "domain.com.zone";
masters { 192.168.0.1; };
}; |
図 14-6. 簡単なスレーブzoneステートメントの例
このzoneステートメントは、スレーブサーバーのnamedに192.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>値が省略された場合、Aレコードはネーム空間の一番上のデフォルトIPアドレスをポイントします。このシステムは、すべての非FQDN要求の対象となります。
domain.comゾーンファイルについて、以下のAレコード例を考えてみましょう。
domain.comの要求は10.0.1.3をポイントし、server1.domain.comの要求は10.0.1.5をポイントします。
CNAME 標準名レコード。これは、ある名前が別の名前でも知られていることをネームサーバーに知らせます。
図14-9では、<alias-name>に送られたどの要求も<real-name>という名前のホストをポイントします。 共通命名スキームを使用するサービスを正しいホストにポイントするには、CNAMEレコードがもっとも一般的に使用されます。
Aレコードが特定のホスト名をIPアドレスに設定し、CNAMEレコードが一般に使用されるwwwホスト名をそこにポイントする図14-10の例について考えてみましょう。
MX Mail eXchangeレコード。このゾーンによって制御されるネーム空間に送られるメールがどこへ行くのかを知らせます。
図14-11では、<preference-value>を使用することにより、このネーム空間のEメールを受け取りたいEメールサーバーを数値的にランクづけることができるため、あるEメールシステムを他のEメールシステムより優先することがきます。最低の<preference-value>を持つMXリソースレコードは、他のものよりも優先されますが、同じ値で複数のEメールサーバーを指定してEメールのトラフィックを分散させることができます。
正しいシステムをポイントしている限りにおいて、<email-server-name>には、ホスト名かFQDNを指定することができます。
この例では、domain.comドメイン向けEメールを受信する場合、最初のmail.domain.comEメールサーバーは、mail2.domain.comEメールサーバーよりも優先されます。
NS ネームサーバーレコード。あるゾーンに対して権限のあるネームサーバーを発表する。
<nameserver-name>はFQDNでなくてはなりません。
図14-14では、2つのネームサーバーがあるドメインについて権限を持っていることが示されます。これらのネームサーバーがどちらもスレーブであるか、それとも1つはマスターであるかは重要ではありません。これらは両方とも権限があると考えられます。
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の表は、秒数での時間量と他のフォーマットでの等価時間を示します。
以下の例は、基本的な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.comとdns2.domain.comに設定され、これらをそれぞれ10.0.1.2と10.0.1.3に結び付けるAレコードがあります。
MXレコードで設定されるEメールサーバーは、CNAMEレコードを介してserver1とserver2をポイントします。server1とserver2の名前は最後がドット(.)で終わっていないため、その後ろに$ORIGINドメインが置かれ、server1.domain.com.とserver2.domain.comに拡張されます。関連Aリソースレコードを通して、そのIPアドレスを決定することができます。
標準名のftp.domain.comとwww.domain.comで利用できる一般的なFTPとWebのサービスは、CNAMEレコードを使って、これらの名前に合ったサービスを提供するマシンにポイントされます。
逆引き名前解決ゾーンファイルは、特定のネーム空間のIPアドレスをFQDNに変換します。これは標準ゾーンファイルにとてもよく似ていますが、PTRリソースレコードがIPアドレスをあるシステムの名前に連結するのに使われるという点で異なっています。
PTRレコードは、図14-18に似た方法で記載されます。
<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つのブロックがこのゾーンで正しく添付されます。