BIND 8 は、以前のリリースと比べて遥かに設定可能なものになっています。 完全に新しい設定項目があります。例えばアクセス制御リストやカテゴリ別の ログなどです。以前はゾーンすべてに対して適用されていたオプションの多くが、 選択的に使えるようになっています。 こうした機能に加え、 将来必要とされる設定がどのようなものになるかをよく考えた結果、 新たに設定ファイルのフォーマットを作ることにしました。
BIND 8 の設定には、一般的な特徴が 2 つあります。 それは、ステートメントとコメントです。 ステートメントはすべてセミコロンで終わります。ステートメントの多くは サブステートメントを持っており、サブステートメントもセミコロンで終わります。
次のようなステートメントをサポートしています :
logging および options ステートメントは、各設定につき 1 回のみ記述可能です。それに対し、 その他のステートメントは何回でも記述可能です。各ステートメントの 詳細については、次に個々のセクションで述べます。
コメントは、BIND 設定ファイル中でホワイトスペースが現れて良い 所ならどこでも記述可能です。いろいろなプログラマの注意を引くように、 C や C++ 、あるいは シェルや perl の形式のコメントを書くことができます。
C のスタイルのコメントは、次の 2 つの文字から始まります。 /* (スラッシュと星印) そして、 */ (星印とスラッシュ) で終わります。 この形式のコメントは、これらの文字で完全に区切られるものであるので、 行の一部分のみでも複数行にまたがっても使用することができます。
C のスタイルのコメントは入れ子にはできません。例えば、次の例は 不適切なものです。なぜなら、コメント全体が最初の */ で終わってしまうからです。
/* この行はコメントの最初です。 この行もコメントの一部です。 /* この行は、間違えてコメントを入れ子にしようとしています。 */ この行は、もうコメント内部ではありません。 */
C++ スタイルのコメントは、次の 2 文字から始まります。 // (スラッシュとスラッシュ) そして、その行の終わりまでがコメントとして 続きます。この種類のコメントは、複数行にわたって続きません。意味としては 1 つだが複数行にまたがるようなコメントを書きたい場合は、各行に // を書かなくてはなりません。例えば、次のようにです :
// この行は、コメントの始まりです。次の行は、 // 新しいコメントになります。たとえ、意味としては // 前の行のコメントの一部分であってもです。
シェルスタイル (あるいは、お好みなら perl スタイル) のコメントは、 次の文字で始まります。 # (ハッシュとかポンドとか番号とかナンバ記号とかどう呼んでも良い) そして、 C++ スタイルのコメントと同様に、その行の最後までコメントが続きます。 例えば、次のようにです :
# この行は、コメントの始まりです。次の行は、 # 新しいコメントになります。たとえ、意味としては # 前の行のコメントの一部分であってもです。
注 ゾーンファイルで書くように、 ; (セミコロン) をコメントの始まりに使用することはできません。 セミコロンは、設定ステートメントの末尾を表すものですので、 その後ろに続く文字は、何であれ次のステートメントの先頭だと 解釈されてしまいます。
BIND 4.9.x の設定ファイルは、 src/bin/named/named-bootconf という名前の、BIND 8.2.x のソースキットに同梱されている シェルスクリプトを使用することで新しいフォーマットに変換する ことができます。
次から述べていることは、BIND 設定ファイルを記述する間使用される要素 についてです。1 つのステートメントとしか結びつかない要素は、その ステートメントについて述べているセクションにだけ記述があります。
size_spec の最大値は、マシンの符号なし long 型整数の最大値になります。 unlimited は、値を無制限に使用できるよう要求したり、 取り得る最大の値を要求したりするために使用します。 default は、サーバが始動したときに有効だった制限が使われます。
number には、次のようなスケールファクタを続けることもできます : K または k はキロバイトを、 M または m はメガバイトを、そして G または g はギガバイトを表します。 これらはそれぞれ、 1024, 1024*1024, 1024*1024*1024 倍であることを表します。
スケールファクタの変換時に、整数値の格納場所でオーバフローが発生しても、 現状では黙って無視します。 その結果、期待した結果よりも小さな値、おそらくは負の値にさえなってしまいます。 本当に大きな値を安全に設定したいなら unlimited を使うのが最良の方法です。
address_match_list = 1*address_match_element
address_match_element = [ "!" ] ( address_match_list /
ip_address / ip_prefix /
acl_name / "key " key_id ) ";"
アドレスマッチリストは、 主にいくつかのサーバの操作でのアクセス制御を決定するために使われます。 また、アドレスマッチリストは、他のネームサーバに問い合わせる際の優先順位や、 named が問い合わせを待つアドレスを決定するためにも使われます。 アドレスマッチリストを構成する要素は、次のうちのどれでもありえます :
要素は、エクスクラメーションマーク (``!'') で始めると無効にできます。 また、アドレスマッチリスト名に any none localhost localnets が前もって定義されています。リスト名に関してのさらなる情報は、 acl ステートメントの説明のところにあります。
key 節が追加されたことにより、この文法の構成要素名はある種の誤用 になってしまっています。なぜなら、ホストやネットワークアドレス に関係なく、アクセスの認証には認証鍵を使用することができるからです。 それでもまだ、このドキュメントを通して「アドレスマッチリスト」という 用語が使われています。
与えられた IP アドレスまたはプレフィックスがアドレスマッチリストと 比較されるときには、要素が合致するまでリストをスキャンしていきます。 合致したことをどう解釈するかは、アクセス制御、 listen-on ポート定義、またはトポロジのいずれの用途にリストを使ったか、 またその要素が無効にされていたかで決定します。
アクセス制御リストとしてアドレスマッチリストが使われる場合、合致した要素が 無効になっていないときはアクセスを許可し、無効になっているときはアクセスを 禁止します。アドレスマッチリスト中に合致するものが 1 つもない場合には、 アクセスは禁止されます。 allow-query allow-transfer allow-update allow-recursion blackhole 節はすべてこのようにアドレスマッチリストを使用します。同様に、 listen-on オプションを使うと、リストに合致しないマシンのアドレスでの問い合わせは、 いずれもサーバが受け取らないようになります。
topology オプションと一緒にアドレスマッチリストが使用される場合、合致した要素が 無効になっていない場合、リスト中で合致した位置に基づいた距離が返されます (合致した箇所がリストの先頭に近ければそれだけ、サーバとの間の距離は 短いことになります)。合致した要素が無効になっている場合、サーバから もっとも遠い距離が割り当てられることになるでしょう。合致するものが なかった場合は、そのアドレスには、無効になっていないリスト要素よりは 遠く、無効になっている要素よりは近い距離が返されるでしょう。
ファーストマッチアルゴリズムを使用していますので、リスト中で 他の要素のサブセットを定義している要素のほうが、より広い範囲の定義を している要素よりも、先に定義すべきです。これは、どちらか一方の要素が無効 になっていようがいまいが関係ありません。例えば、
1.2.3/24; !1.2.3.13では、1.2.3.13 という要素は無意味です。なぜなら、 このアルゴリズムでは、1.2.3.13 の検索を 1.2.3/24 という要素に合致 してしまうからです。
!1.2.3.13; 1.2.3/24を使うと、1.2.3.13 は要素が無効になっていることにより拒否されますが、 その他の 1.2.3.* のホストは素通りになりますので、この問題を回避できます。
logging {
[ channel channel_name {
( file path_name
[ versions ( number | unlimited ) ]
[ size size_spec ]
| syslog ( kern | user | mail | daemon | auth | syslog | lpr |
news | uucp | cron | authpriv | ftp |
local0 | local1 | local2 | local3 |
local4 | local5 | local6 | local7 )
| null );
[ severity ( critical | error | warning | notice |
info | debug [ level ] | dynamic ); ]
[ print-category yes_or_no; ]
[ print-severity yes_or_no; ]
[ print-time yes_or_no; ]
}; ]
[ category category_name {
channel_name; [ channel_name; ... ]
}; ]
...
};
logging ステートメントは、ネームサーバに対する様々な種類のログ用オプションを 設定します。 その中の channel フレーズでは、出力方法とフォーマットオプションと重大度を 名前と結びつけます。 この名前は後で category フレーズで使用し、様々なメッセージクラスをどのようにログに落すかを選択します。
ただ 1 つの logging ステートメントを使用して、望むだけ多くのチャネルとカテゴリを 定義できます。設定中に、複数の logging ステートメントがあった場合、 最初以外の logging ステートメントに対しては警告が出されます。 logging ステートメントが 1 個も存在しなかった場合、ログ用の設定は 次のようになるでしょう :
logging {
category default { default_syslog; default_debug; };
category panic { default_syslog; default_stderr; };
category packet { default_debug; };
category eventlib { default_debug; };
};
ログ用の設定は、 logging ステートメントがパースされたらすぐに確立されます。もし、設定ファイル 全体の処理状況についてのメッセージをリダイレクトしたいのであれば、 logging ステートメントが最初に出てくるようにしなければなりません。たとえ、 設定ファイルのパース状況を表すメッセージをリダイレクトしたくなくても、 logging ステートメントはファイルの先頭に置くことを勧めます。そうすることによって、 パーサの出すメッセージを再度設定する必要が生じたときに、意識して このルールを思い出す必要がなくなります。
ログの出力はすべて、1 つまたはそれ以上の「チャネル」へと渡ります。 チャネルは好きなだけ作ることができます。
それぞれのチャネルの定義には、そのチャネル用に選択したメッセージが ファイルに落されるのか、特別な syslog ファシリティに渡されるのか、 または、捨てられるのかを指定する節が含まれていなくてはなりません。 チャネルの定義では、チャネルが受け取るメッセージの重大度を制限する こともオプションでできます (デフォルトは info です)。また、 named が生成するタイムスタンプと、 カテゴリ名と、重大度を含めるかどうかを制限することもできます。 デフォルトでは、この 3 つのいずれも含めないようになっています。
チャネルに対するログの送り先のオプションに null という単語を使用すると、そのチャネルに送られるメッセージはすべて 捨てられるようになります。チャネルに対するその他のオプションは意味が ありません。
file 節を使用すると、ログファイルがどれだけ大きくなっても良いかということと、 ログファイルがオープンされるごとに 何個のバージョンを残すのかということに関する制限を、取り込むことができます。
ログファイルに対する size オプションは、単純にログが大きくなるのを制限する固い天井になるものです。 ログファイルが size を超えると、 ログファイルが再度オープンされるまで named はファイルに何も書き込みません。size を超えていても、自動的にはファイルは オープンされません。デフォルトでは、ログファイルのサイズ制限はありません。
ログファイルオプションに version を使用すると、 named は、ログファイルがオープンされるときにファイルのバックアップバージョンの 名前を変更して、指定した数だけ保持します。例えば、lamers.log というファイルの 古いバージョンを 3 つ保持するように選択した場合、lamer.log がオープンされる 直前に lamers.log.1 というファイルは lamers.log.2 という名前に変更され、 lamers.log.0 というファイルは lamers.log.1 という名前に変更され、そして lamers.log というファイルが lamers.log.0 という名前に変更されます。バージョン名 が巡回するものはデフォルトでは保持されません。 すでに存在しているログファイルは、 ただ単に追加して書かれます。 unlimited キーワードは、現在の BIND のリリースでは 99 と同義です。size および versions オプションの使用例は次の通りです :
channel an_example_level {
file "lamers.log" versions 3 size 20m;
print-time yes;
print-category yes;
};
syslog 節の引数は、 syslog(3) マニュアルページに記述されている syslog ファシリティを表します。 syslogd がこのファシリティに送られるメッセージをどのように扱うかについては、 syslog.conf5 マニュアルページに記述があります。 Fn openlog() 関数に 2 つの引数しか使用しない、とても古いバージョンの syslog を 使用しているシステムをお使いの場合は、この節は黙って無視されます。
severity 節は、syslog の「優先度」のように働きます。ただし、syslog を 使用するかわりにファイルを直接書いても使用できるところが違います。 与えられた重大度よりも低いレベルのメッセージは、 このチャネルに対しては選択されません。与えられた重大度 よりも高いレベルのメッセージが受け取られます。
syslog を使っている場合、 syslog.conf での優先度によっても最終的に何が通り抜けるかが決定されます。 例えば、チャネルのファシリティおよび重大度を daemon および debug に定義しているが、 syslog.conf では daemon.warning しかログに落とさないようにしている場合、 info および notice の重大度を持ったメッセージは捨てられてしまいます。 状況が逆になり、 named が warning かそれ以上の重大度を持ったメッセージしか書きださないように なっている場合、 syslogd は、そのチャネルから受け取ったメッセージをすべて書き出すことでしょう。
デバッグモードになっている場合、サーバはもっと多くのデバッグ情報を 提供できます。サーバのデバッグレベルが 0 より大きくなっていれば、 デバッグモードは有効になっています。全体でのデバッグレベルは、 -d フラグに正の整数値を続けて指定して named サーバを開始するか、または、動いているサーバに SIGUSR1 シグナルを送る (例えば、 ndc trace を使って) ことによって設定します。 全体でのデバッグレベルは 0 にも設定でき、このときは、デバッグモードは 無効になります。この状態には、サーバに SIGUSR2 シグナルを送る ( ndc notrace を使って) ことによってもできます。 サーバでのデバッグメッセージにはすべてデバッグレベルがあります。 そして、デバッグレベルが高いほどより詳細な出力になっています。 例えば、特定のデバッグ重大度を次のように指定したチャネル では、サーバがデバッグモードであればいつでも、レベル 3 または それ以下のレベルのデバッグ出力が得られます。
channel specific_debug_level {
file "foo";
severity debug 3;
};
それは、全体でのデバッグレベルには依りません。 dynamic 重大度を指定したチャネルでは、どのメッセージを出力するかを 決めるためにサーバ全体のデバッグレベルを使用します。
print-time がオンになっていれば、日付および時刻がログに落とされます。 print-time は、syslog チャネルに対しても指定できますが、通常は意味のないことです。 なぜなら、syslog も日付および時刻は出力するからです。 print-category が要求されている場合、メッセージのカテゴリも同様にログに落とされます。 最後に、 print-severity がオンになっていれば、メッセージの重大度がログに落とされます。 print- オプションはどういう組合せでも使うことができ、 常に次のような順番で出力されます : それは time, category, severity の順です。 次に示す例は、3 つすべての print- オプションをオンにした例です :
28-Apr-1997 15:05:32.863 default: notice: Ready to answer queries.
named でのデフォルトのログ取得用に使用されるチャネルには、次のような、 事前に定義された 4 つがあります。どのようにこのチャネルを使うのかに ついては次節 Sx category フレーズ に記述があります。
channel default_syslog {
syslog daemon; # syslog の daemon ファシリティに送る
severity info; # 優先度が info およびそれ以上のものだけ送る
};
channel default_debug {
file "named.run"; # 作業ディレクトリ内の named.run ファイルに
# 書き込む
# 注 : サーバが -f オプションつきで開始されている
# 場合は、"named.run" の代わりに標準エラー
# 出力が使われます。
severity dynamic; # サーバの現在のデバッグレベルをログに落とす
};
channel default_stderr { # 標準エラー出力に書き出す
file "<stderr>"; # ここでは、見えるように書いただけです。現在、
# 内部のファイルディスクリプタを設定ファイルの
# 文中に記述する方法はありません。
severity info; # 優先度が info およびそれ以上のものだけ送る
};
channel null {
null; # このチャネルに送られたメッセージはみなはじく
};
いったんチャネルが定義されると、再設定はできません。そのため、組み込みの チャネルは直接変更できないわけです。しかし、定義したチャネルでのカテゴリを 指し示すことによって、デフォルトのログ用機能を変更することができます。
カテゴリはたくさんあります。そのため、見たいと思うログをどこへでも送る ことができ、見たくないログは見ないですますことができます。カテゴリに対して チャネルのリストを指定しなかった場合は、代わりに default カテゴリにログが送られます。 default カテゴリを指定しなかった場合、次のような「デフォルトの default カテゴリ」が使われます :
category default { default_syslog; default_debug; };
例として、セキュリティのイベントをファイルにログとして落としたいが、 デフォルトのロギングの挙動は維持したいとしましょう。そうすると、次のように 指定することになるでしょう :
channel my_security_channel {
file "my_security_file";
severity info;
};
category security { my_security_channel;
default_syslog; default_debug; };
カテゴリ内のすべてのメッセージを捨てるには、 null チャネルを指定してください :
category lame-servers { null; };
category cname { null; };
次のようなカテゴリが使用可能です :
category default { default_syslog; default_debug; };
category panic { default_syslog; default_stderr; };
category eventlib { default_debug; };
category packet { default_debug; };
options {
[ version version_string; ]
[ directory path_name; ]
[ named-xfer path_name; ]
[ dump-file path_name; ]
[ memstatistics-file path_name; ]
[ pid-file path_name; ]
[ statistics-file path_name; ]
[ auth-nxdomain yes_or_no; ]
[ deallocate-on-exit yes_or_no; ]
[ dialup yes_or_no; ]
[ fake-iquery yes_or_no; ]
[ fetch-glue yes_or_no; ]
[ has-old-clients yes_or_no; ]
[ host-statistics yes_or_no; ]
[ host-statistics-max number; ]
[ multiple-cnames yes_or_no; ]
[ notify yes_or_no; ]
[ recursion yes_or_no; ]
[ rfc2308-type1 yes_or_no; ]
[ use-id-pool yes_or_no; ]
[ treat-cr-as-space yes_or_no; ]
[ also-notify yes_or_no; ]
[ forward ( only | first ); ]
[ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]
[ check-names ( master | slave | response ) ( warn | fail | ignore); ]
[ allow-query { address_match_list }; ]
[ allow-recursion { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ blackhole { address_match_list }; ]
[ listen-on [ port ip_port ] { address_match_list }; ]
[ query-source [ address ( ip_addr | * ) ]
[ port ( ip_port | * ) ] ; ]
[ lame-ttl number; ]
[ max-transfer-time-in number; ]
[ max-ncache-ttl number; ]
[ min-roots number; ]
[ serial-queries number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ transfers-in number; ]
[ transfers-out number; ]
[ transfers-per-ns number; ]
[ transfer-source ip_addr; ]
[ maintain-ixfr-base yes_or_no; ]
[ max-ixfr-log-size number; ]
[ coresize size_spec ; ]
[ datasize size_spec ; ]
[ files size_spec ; ]
[ stacksize size_spec ; ]
[ cleaning-interval number; ]
[ heartbeat-interval number; ]
[ interface-interval number; ]
[ statistics-interval number; ]
[ topology { address_match_list }; ]
[ sortlist { address_match_list|fR }; ]
[ rrset-order { order_spec ; [ order_spec ; ... [ [ };
};
options ステートメントは BIND で使われるグローバルオプションを 設定します。このステートメントは、設定ファイル中で 1 度だけ出現できます。 もし複数のステートメントが出現した場合は、最初に出現したステートメントが 実際に使用されるオプションを決定し、警告が行われます。options ステートメントが 存在しない場合は、各オプションがデフォルトに設定された options ブロックが 使われます。
ゾーンが master である場合、 サーバは、すべてのスレーブに対して NOTIFY リクエストを送信するようになります。 これによって、スレーブをチェックし、呼び出しが生きている間に スレーブがゾーンを検証できるようにすることで、 ゾーンを最新のものにする契機ができます (サーバが NOTIFY をサポートする場合です)。
ゾーンが slave もしくは stub である場合、 サーバは、通常のゾーンのアップデート問い合わせを抑制し、 heartbeat-interval が時間切れになったときだけ問い合わせるようにします。
also-notify
ゾーンの新しいコピーがロードされるときはいつでも送信された NOTIFY メッセージも受け取る IP アドレスのグローバルリストを定義します。 このオプションは、ゾーンのコピーが素早く「内密の」サーバ上で確実に収束 する助けになります。 also-notify リストが zone ステートメントで与えられた場合、 options also-notify ステートメントは上書きされます。 zone notify ステートメントが no に設定されている場合、 グローバルの also-notify リストの IP アドレスは、このゾーンに対する NOTIFY メッセージを 送信されません。デフォルトでは、このリストは空です (グローバルな notification リストはないということです)。
フォワード機能は、少数のサーバ上で大きなサイト単位のキャッシュを作成する ために使用することができます。これによって、外部のネームサーバへの リンクを越えたトラフィックを軽減できます。フォワード機能は、直接 インターネットに接続できないが、ともかく外部のホスト名を見つけ出したい というサーバの問い合わせを許可するためにも使用できます。 フォワードが発生するのは、そうした問い合わせに対してサーバが 権限を持たず、キャッシュにその応答が入っていない場合だけです。
フォワード機能は、ゾーン単位をもとにして設定することもできます。 このときは、グローバルのフォワード用オプションが、さまざまな方法で 上書きできるようになります。 特定のゾーンに対し、 別のフォワード用サーバを使用したり、別の forward only/first の振るまいをもたせたり、あるいはまったくフォワードしなかったり できます。 さらなる情報については、 Sx ゾーンステートメント のセクションを参照してください。
BIND 8 の将来のバージョンでは、もっと強力なフォワード用システムを 提供する予定です。先に述べた文法は引き続きサポートされる予定です。
サーバは、期待するクライアントの関係に基づいてドメイン名をチェックできます。 例えば、ホスト名として使用されるドメイン名は、正当なホスト名を 定義している RFC に準拠するかという点でチェックされます。
チェック方法には 3 通りのやり方が利用可能です :
サーバは、名前を 3 つのエリアでチェックできます : マスタゾーンファイル、 スレーブゾーンファイル、そして、サーバが発行した問い合わせへの応答 です。 check-names response fail が指定されており、クライアントの問い合わせに対する応答が クライアントに不正な名前を送る必要のあるものであった場合、 サーバは、 REFUSED 応答コードをクライアントに送ります。
デフォルトは、次の通りです :
check-names master fail;
check-names slave warn;
check-names response ignore;
check-names は、 zone ステートメントでも指定できます。この場合、 options check-names は上書きされます。 zone ステートメントで使用した場合、 エリアは指定されません (なぜなら、ゾーンの種類からエリアは推測できる からです)。
サーバへのアクセスは、アクセスを要求したシステムの IP アドレス または共有秘密鍵に基づいて制限することができます。 アクセス基準をどのように指定するかについての詳細は、 Sx アドレスマッチリスト を参照してください。
サーバが問い合わせに答えるインタフェースならびにポートは、 listen-on オプションを使って指定することができます。 listen-on は、オプションのポートおよびアドレスマッチリストを取ります。 サーバは、アドレスマッチリストで許可されたインタフェース全てで待機します。 ポートを指定しない場合は、53 番ポートが使われます。
listen-on ステートメントが複数あっても良いです。例えば、
listen-on { 5.6.7.8; };
listen-on port 1234 { !1.2.3.4; 1.2/16; };
では、IP アドレスが 5.6.7.8 のマシン用にネームサーバに 53 番ポートの使用を 許可し、1234 番ポートを 1.2 のネットワークにいて、IPアドレスが 1.2.3.4 ではない マシンに使用を許可します。
listen-on が指定されていない場合は、サーバは、すべてのインタフェース上で 53 番ポートでの 待機をします。
サーバが問い合わせに対する答を知らない場合、そのサーバは、他の ネームサーバに問い合わせを行います。 query-source は、こうした問い合わせに使用されるアドレスおよびポートを指定します。 address が * だったり、省略されている場合、ワイルドカード IP アドレス ( INADDR_ANY ) が使用されます。 port が * だったり、省略されている場合、特権のいらないポートがランダムに 使用されます。デフォルトでは
query-source address * port *;です。
注 : query-source は、現在 UDP 問い合わせのみ適用されます。 TCP 問い合わせには、常にワイルドカード IP アドレスとランダムに選ばれた 特権のいらないポートが使用されます。
多種のシステムリソースをサーバがどこまで使用してよいか制限可能です。 オペレーティングシステムによっては、 この制限をいくつかサポートしていないものもあります。 そうしたシステムでは、サポートされていない制限を使用すると警告が発生します。 また、オペレーティングシステムによっては、 リソース制限自体をサポートしていないものも あります。そうしたシステムでは、 というメッセージがログに記録されます。
リソース制限を指定する際には、スケールを変えた値を使用することができます。 例えば、1 ギガバイトの制限を指定したい場合に、 1G を 1073741824 の代わりに使用することができます。 unlimited は、無制限にリソースを使用する、 つまり、利用可能な最大の量のリソースを要求します。 default は、サーバが開始したときに有効だった制限値を使用します。 詳細については、 Sx 記述方法の定義 のセクションの size_spec の項を参照してください。
ネームサーバのリストから問い合わせ先のネームサーバをサーバが 1 つ選ぶとき、 他の点ではすべて対等である場合、このサーバは、 自分自身からトポロジ的に最も近いものを選びます。 topology ステートメントは、アドレスマッチリストをとり、 特別な方法でそのリストを解釈します。 それぞれの一番上のリスト要素は距離が割り当てられています。 無効にされていない要素は、リスト中の位置に基づいて距離を取得します。ここで、 リストの先頭にマッチした地点が近ければ近いほど、サーバと要素との距離が 近いことになります。 無効にされているマッチには、サーバからの距離の最大が割り当てられます。 マッチするものがない場合は、そのアドレスは、無効にされていないリストの要素の どれよりも遠い距離を取得します。例えば、
topology {
10/8;
!1.2.3/24;
{ 1.2/16; 3/8; };
};
の場合では、ネットワーク 10 上のサーバが最も好ましいものになります。 次が、ネットワーク 1.2.0.0 (ネットマスクが 255.255.255.0) 上のホスト およびネットワーク 3 上のホストですが、 ネットワーク 1.2.3 (ネットマスクが 255.255.255.0) 上のホストは除外されます。 このネットワーク上のものは、どれよりも選ばれにくいものです。
デフォルトのトポロジは
topology { localhost; localnets; };です。
複数の RR (訳注: リソースレコード) が返ってくると、通常ネームサーバは、 ラウンドロビン でそれらを返します。 すなわち、各要求の後に、最初の RR がリストの最後に置かれます。 RR の順番が決まっていないので、これで問題ありません。
クライアントのリゾルバのコードが、これらの RR を適切に 構成しなおさなくてはなりません。すなわち、他のアドレスよりも、 ローカルネット上の任意のアドレスを優先して使用するということです。 しかしながら、すべてのリゾルバがこうすることができたり、 適切に設定されているわけではありません。
クライアントがローカルサーバを使用しているとき、サーバ内で、クライアントの アドレスに基づいたソートが実行できます。このソートのためには、 ただネームサーバを設定するだけでよく、すべてのクライアントを設定する 必要はありません。
sortlist ステートメントは、アドレスマッチリストをとり、 topology ステートメントより更に増した特別な方法でリストを解釈します。
ソートリスト中の各先頭のステートメントは、 それ自身、1 つまたは 2 つの要素を持った 明示的なアドレスマッチリストでなくてはなりません。各先頭のリストの最初の要素 (IP アドレス、IP のプレフィックス、ACL 名、 あるいはネストされたアドレスマッチリスト) に対し、マッチが見つかるまで、問い合わせ元のアドレスをチェックします。
ひとたび問い合わせ元のアドレスがマッチしたなら、 先頭のステートメントがただ 1 つの要素のみの場合、 問い合わせ元のアドレスとマッチした要素そのものが 応答のアドレスを選択するために使用され、それが応答の先頭に移動します。 ステートメントが 2 つの要素を持ったリストであった場合、2 番目の要素は、 topology ステートメントのアドレスマッチリストのように扱われます。 各先頭要素には、 距離が割り当てられており、最も短い距離を持った応答中のアドレスが、 その応答の先頭に移動されます。
次の例では、ホストそれ自身のアドレスから受け取った問い合わせは、 ローカルに接続された ネットワーク上のアドレスを優先するような応答を受け取ります。 次に優先されるのが、 192.168.1/24 ネットワーク上のアドレスで、その後に、192.168.2/24 あるいは 192.168.3/24 ネットワークがきます。 最後の 2 つのネットワーク間にはどちらが優先かは示されていません。 192.168.1/24 ネットワーク上のホストから受け取った問い合わせは、 そのネットワーク上の他のアドレスを 192.168.2/24 および 192.168.3/24 ネットワークよりも優先します。 192.168.4/24 あるいは 192.168.5/24 ネットワーク上の ホストから受け取った問い合わせは、 直接接続されたネットワーク上のアドレスを優先する だけです。
sortlist {
{ localhost; // もし ローカルホストなら
{ localnets; // 次のネット上で
192.168.1/24; // 最初にフィットしたものにする
{ 192,168.2/24; 192.168.3/24; }; }; };
{ 192.168.1/24; // もし クラス C 192.168.1 上なら
{ 192.168.1/24; // .1 あるいは、.2 か .3 を使用する
{ 192.168.2/24; 192.168.3/24; }; }; };
{ 192.168.2/24; // もし クラス C 192.168.2 上なら
{ 192.168.2/24; // .2 あるいは、.1 か .3 を使用する
{ 192.168.1/24; 192.168.3/24; }; }; };
{ 192.168.3/24; // もし クラス C 192.168.3 上なら
{ 192.168.3/24; // .3 あるいは、.1 か .2 を使用する
{ 192.168.1/24; 192.168.2/24; }; }; };
{ { 192.168.4/24; 192.168.5/24; }; // .4 か .5 なら
}; // そのネットを優先する
};
次の例は、ローカルホストおよび直接接続されたネットワーク上のホストに対する、 理にかなった振るまいを提供するものです。 これは、BIND 4.9.x でのアドレスのソートの振るまいと 似ています。ローカルホストからの問い合わせに対して送られた応答は、 直接接続された ネットワーク上のホストを優先します。 他の直接接続されたネットワーク上のホストからの 問い合わせに対して送られた応答は、 同じネットワーク上のアドレスを優先するでしょう。 その他の問い合わせに対する応答についてはソートされません。
sortlist {
{ localhost; localnets; };
{ localnets; };
};
応答中に複数のレコードが返されている場合、 その応答中にレコードがどの順番で置かれるかを 設定するのが有益なことがあります。 例えば、あるゾーンに対するレコードは、ゾーンファイルで 定義された順番で常に返されるように設定されるかもしれません。 あるいは、 レコードが返されるときにランダムにシャッフルされるようにしたいということも あるでしょう。 rrset-order ステートメントを使用すると、 複数レコードが含まれる応答中のレコードの順番を 設定することができます。順番が定義されていない場合、デフォルトでは、巡回順 (ラウンドロビン) になります
order_spec は次のように定義されています :
[ class class_name ][ type type_name ][ name "FQDN" ] order ordering
クラスが指定されていない場合、デフォルトは ANY です。 Ictype が指定されていない場合、デフォルトは ANY です。 名前が指定されていない場合、デフォルトは "*" です。
ordering の正当な値には、次のようなものがあります :
fixed
レコードは、ゾーンファイルで定義された順番で返されます。
random
レコードは、ある種のランダムな順番で返されます。
cyclic
レコードは、ラウンドロビンに返されます。
例えば、
rrset-order {
class IN type A name "rc.vix.com" order random;
order cyclic;
};
では、サフィックスに "rc.vix.com" を持ち、 クラス IN でタイプ A のレコードに対する 応答は、常にランダムな順番で返されます。 その他のレコードはすべて巡回順に返されます。
rrset-order ステートメントが複数現れた場合、ステートメントは連結されません。 最後のものが適用されます。
rrset-order ステートメントが指定されていない場合、デフォルトは
rrset-order { class ANY type ANY name "*" order cyclic ; };
が使われます。
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type master;
file path_name;
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ forward ( only | first ); ]
[ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
[ dialup yes_or_no; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
[ pubkey number number number string; ]
};
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type ( slave | stub );
[ file path_name; ]
masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] };
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ forward ( only | first ); ]
[ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
[ transfer-source ip_addr; ]
[ max-transfer-time-in number; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
[ pubkey number number number string; ]
};
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type forward;
[ forward ( only | first ); ]
[ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
[ check-names ( warn | fail | ignore ); ]
};
zone "." [ ( in | hs | hesiod | chaos ) ] {
type hint;
file path_name;
[ check-names ( warn | fail | ignore ); ]
};
zone ステートメントは、 特定の DNS ゾーンがサーバにどのように管理されるかを指定するために 使われます。ゾーンには 5 つの種類があります。
forwarders 節が zone ステートメント中に存在しないか、もしくは、 forwarders に対して空リストが与えられている場合は、 そのゾーンに対してフォワードは行われず、 options ステートメント中の forwarders は、すべて効力を失います。そのため、使用されるサーバではなく、グローバルの forward オプションの挙動を変更するためだけにこの種類のゾーンを使用したいのであれば、 グローバルの forwarders 節も指定しなおす必要があります。
注 : 以前の BIND リリースでは、マスタゾーンに対しては primary という用語を使用し、スレーブゾーンに対しては、 secondary を、hint ゾーンに対しては cache という用語を使用していました。
ゾーン名には、オプションでクラスを続けることができます。 もし、クラスが指定されていない場合は、 in クラス (「インターネット」用) であると仮定されます。これは、大半の場合正しいです。
hesiod クラスは、MIT の Project Athena 由来の情報サービス用のクラスです。 このクラスは、ユーザ、グループ、プリンタなどといった、 さまざまなシステムデータベースに 関する情報を共有するために使用されます。さらなる情報は、 ftp://athena-dist.mit.edu/pub/ATHENA/usenix/athena_changes.PS から入手できます。 キーワード hs は hesiod と同義語です。
MIT が開発したもう 1 つのものが、1970 年代半ばに作られた LAN プロトコルである CHAOSnet です。これは、LISP ステーションや AI コミュニティで使われている 他のハードウェアで、まだ時折見受けられます。CHAOSnet 用のゾーンデータは、 chaos クラスを使用して指定できます。
acl name {
address_match_list
};
acl ステートメントは、名前のついたアドレスマッチリストを生成します。 このステートメントは、プライマリで使用しているアドレスマッチリスト、つまり、 アクセス制御リスト (ACL) からその名前を取得します。
アドレスマッチリスト名は、他のところで使用する前に acl を使用して定義しなくてはなりません。ファイルの前方への参照は許されていません。
次のような組み込みの ACL があります :
key key_id {
algorithm algorithm_id;
secret secret_string;
};
key ステートメントは、鍵の ID を指定します。この ID は、 server ステートメントで使用され、単純な IP アドレスでのマッチングよりも厳格な 特定のネームサーバと認証方法とを関連づけます。 鍵の ID は、 server の定義やアドレスマッチリスト中で使用される前に key ステートメントを使用して作成されていなくてはなりません。
algorithm_id は、セキュリティ / 認証アルゴリズムを指定する文字列です。 secret_string は、指定されたアルゴリズムが使用する秘密の鍵で、 base-64 でエンコードされた文字列として扱われます。 言わずとも当然のことですが、為念指摘しておくと、 named.conf 中に secret_string を入れている場合、 named.conf をスーパユーザ以外の誰にも読み込み可能にしてはいけません。
trusted-keys {
[ domain_name flags protocol algorithm key; ]
};
trusted-keys ステートメントは、もともと、RFC 2065 で仕様が決められている DNSSEC スタイルの セキュリティとともに使用されます。DNSSEC は、 3 つの異なったサービスを提供するものです : それは、鍵の配布、データの発生元の認証、 そして、トランザクションおよび要求の認証です。DNSSEC についての完全な説明と このドキュメントの範囲を超えた使い方を知りたい場合、 そして、読者がさらなる情報に 興味がある場合は、まず、RFC2065 を読むことから始めてください。そして、 http://www.ietf.org/ids.by.wg/dnssec.html から入手できるインターネット ドラフトへと続いてください。
信頼された鍵はそれぞれ、ドメイン名と関連づけられています。その属性は、 非負の整数値である、 flags protocol algorithm と、 key を表す base-64 でエンコードされた文字列です。
信頼された鍵の番号はすべて指定可能です。
server ip_addr {
[ bogus yes_or_no; ]
[ transfers number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ keys { key_id [ key_id ... ] }; ]
};
server ステートメントは、リモートのネームサーバに関連付けられる 特徴を定義します。
サーバが間違ったデータを送っていることに気がついた場合、そのサーバを bogus にすることで、そのサーバへの問い合わせを抑止することができます。 bogus のデフォルト値は no です。 サーバに bogus の印を付けると、当該サーバのアドレスを名前で検索してマッチしたときに、 当該サーバに対する他のアドレスもすべて bogus の印を付けます。
サーバは、2 つのゾーン転送方式をサポートしています。1 つ目は、 one-answer であり、 これは、転送される各リソースレコードに 1 つの DNS メッセージを使用します。 many-answers は、できるだけ多くのリソースレコードを 1 つのメッセージに押し込みます。 many-answers の方が効率的ではありますが、BIND 8.1 および、 パッチの当たった BIND 4.9.5 でのみ 理解されるものです。 サーバに対してどちらの方法を使用するかは、 transfer-format オプションを使用して指定することができます。 transfer-format が指定されていない場合は、 options ステートメントで指定された transfer-format が使用されます。
transfers は、将来のリリースでのサーバで、 指定されたサーバから同時に行われる内部へのゾーン転送数を 制限するために使用される予定です。 現在は、文法はチェックしますが、その他のことは 無視されます。
keys 節は、 key ステートメントで定義された key_id を識別するために使用されます。これは、リモートサーバと通信する際の トランザクションのセキュリティ用に使用されます。 key ステートメントは、それを参照する server ステートメントよりも先に現れなくてはなりません。
keys ステートメントは、将来、サーバによって使用されることを期待されています。 現在は、文法はチェックされますが、その他のことは無視されます。
controls {
[ inet ip_addr
port ip_port
allow { address_match_list; }; ]
[ unix path_name
perm number
owner number
group number; ]
};
controls ステートメントは、 システム管理者がローカルのネームサーバの操作に影響を与えるために 使用する制御チャネルを宣言します。制御チャネルは、 ndc ユーティリティが、ネームサーバにコマンドを送り、 DNS 以外の結果を受け取るために 使用します。
unix 制御チャネルは、ファイルシステムでの FIFO です。このチャネルへのアクセスは、 通常のファイルシステムのパーミッションによって制御されます。 この制御チャネルは、 指定されたファイルモードのビット ( chmod(1) を参照) とユーザおよびグループの所有者情報を使用し、 named が作成します。 注意することは、 chmod とは違い、 perm に対して指定されるモードのビットには、通常先頭に 0 がついていることです。そのため、数字は 8 進数として解釈されます。 さらに注意することは、 owner および group として指定されるユーザおよびグループの所有者情報は、数字で与えなくては ならないということです。名前ではありません。 このパーミッションは、管理者のみに制限することを勧めます。 そうしないと、このシステム上のユーザなら誰でもローカルネームサーバを 操作できてしまいます。
inet 制御チャネルは、インターネット接続のできる TCP/IP ソケットです。 これは、指定された ip_addr 上の指定された ip_port にあります。 最近の telnet クライアントは、こうしたソケットと直接対話ができます。 このときの制御プロトコルは、ARPAnet 形式のテキストです。 127.0.0.1 だけを ip_addr に使用することを勧めます。これは、ネームサーバを管理するために、 ローカルホスト上の特権を持たないユーザを皆信用している場合だけに限ります。
include path_name;
include ステートメントは、そのステートメントが現れた地点に、指定された ファイルを挿入します。ただし、他のステートメント内で使用することは できません。ですので、
acl internal_hosts { include "internal_hosts.acl"; };というようには使用できません。
include を使用して、設定ファイルを簡単に管理できるかたまりに分けるように してください。例えば、次のようにです :
include "/etc/security/keys.bind"; include "/etc/acls.bind";
この例は、任意の ACL または 認証鍵情報を取り込むために、 BIND 設定ファイルの先頭で使うことができるでしょう。
C 言語でのプログラムでするように ``#include'' とタイプしないでください。 ``#'' はコメントの開始として使用するものだからです。
実際に使用する場面でも実用的で、最も単純な設定ファイルは、 ただ単にルートサーバファイルへのフルパスを持ったヒントゾーンを 定義したものです。
zone "." in {
type hint;
file "/var/named/root.cache";
};
次の例は、もっと実世界に即したものです。
/*
* 単純な BIND 8 の設定
*/
logging {
category lame-servers { null; };
category cname { null; };
};
options {
directory "/var/named";
};
controls {
inet * port 52 allow { any; }; // これは良くない
unix "/var/run/ndc" perm 0600 owner 0 group 0; // デフォルト
};
zone "isc.org" in {
type master;
file "master/isc.org";
};
zone "vix.com" in {
type slave;
file "slave/vix.com";
masters { 10.0.0.53; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "master/127.0.0";
};
zone "." in {
type hint;
file "root.cache";
};