BIND 8 は、以前のリリースと比べて遥かに設定可能なものになっています。完全に新しい設定項目があります。例えばアクセス制御リストやカテゴリ別のログなどです。以前はゾーンすべてに対して適用されていたオプションの多くが、選択的に使えるようになっています。こうした機能に加え、将来必要とされる設定がどのようなものになるかをよく考えた結果、新たに設定ファイルのフォーマットを作ることにしました。
BIND 8 の設定には、一般的な特徴が 2 つあります。それは、ステートメントとコメントです。ステートメントはすべてセミコロンで終わります。ステートメントの多くはサブステートメントを持っており、サブステートメントもセミコロンで終わります。
次のようなステートメントをサポートしています : サーバが何をログに残すか、そしてどこにログメッセージを送るのかを指定します。
グローバルなサーバ設定オプションを制御し、その他のステートメントに対するデフォルトを設定します。
ゾーンを定義します。
名前つきの IP アドレスマッチングリストを定義します。これは、アクセス制御やその他の用途に使われます。
認証と許可に使われる鍵情報を指定します。
DNSSEC 鍵を定義します。これは、事前にサーバに設定されており、暗黙のうちに信頼します。
個々のリモートサーバ用の設定オプションを設定します。
ユーティリティが使用する制御チャネルを宣言します。
他のファイルをインクルードします。
およびステートメントは、各設定につき 1 回のみ記述可能です。それに対し、その他のステートメントは何回でも記述可能です。各ステートメントの詳細については、次に個々のセクションで述べます。
コメントは、BIND 設定ファイル中でホワイトスペースが現れて良い所ならどこでも記述可能です。いろいろなプログラマの注意を引くように、 C や C++ 、あるいはシェルや perl の形式のコメントを書くことができます。
C のスタイルのコメントは、次の 2 つの文字から始まります。 (スラッシュと星印) そして、 (星印とスラッシュ) で終わります。この形式のコメントは、これらの文字で完全に区切られるものであるので、行の一部分のみでも複数行にまたがっても使用することができます。
C のスタイルのコメントは入れ子にはできません。例えば、次の例は不適切なものです。なぜなら、コメント全体が最初ので終わってしまうからです。 /* この行はコメントの最初です。
この行もコメントの一部です。 /* この行は、間違えてコメントを入れ子にしようとしています。 */
この行は、もうコメント内部ではありません。 */
C++ スタイルのコメントは、次の 2 文字から始まります。 (スラッシュとスラッシュ) そして、その行の終わりまでがコメントとして続きます。この種類のコメントは、複数行にわたって続きません。意味としては 1 つだが複数行にまたがるようなコメントを書きたい場合は、各行にを書かなくてはなりません。例えば、次のようにです :
// この行は、コメントの始まりです。次の行は、 // 新しいコメントになります。たとえ、意味としては // 前の行のコメントの一部分であってもです。
シェルスタイル (あるいは、お好みなら perl スタイル) のコメントは、次の文字で始まります。 (ハッシュとかポンドとか番号とかナンバ記号とかどう呼んでも良い) そして、 C++ スタイルのコメントと同様に、その行の最後までコメントが続きます。例えば、次のようにです :
# この行は、コメントの始まりです。次の行は、 # 新しいコメントになります。たとえ、意味としては # 前の行のコメントの一部分であってもです。
ゾーンファイルで書くように、 (セミコロン) をコメントの始まりに使用することはできません。セミコロンは、設定ステートメントの末尾を表すものですので、その後ろに続く文字は、何であれ次のステートメントの先頭だと解釈されてしまいます。
BIND 4.9.x の設定ファイルは、という名前の、BIND 8.2.x のソースキットに同梱されているシェルスクリプトを使用することで新しいフォーマットに変換することができます。
次から述べていることは、BIND 設定ファイルを記述する間使用される要素についてです。1 つのステートメントとしか結びつかない要素は、そのステートメントについて述べているセクションにだけ記述があります。
ステートメントで定義されるの名称です。
要素が 1 つまたはそれ以上集まったリストです。これについては、の項で述べます。
ドット (``.'') だけで区切られた、 1 つまたはそれ以上の数の 0 から 255 までの整数です。例えば、などです。
DNS 名として使用される文字列をクォーテーションで囲んだものです。例えば、のようにです。
パス名として使用される文字列をクォーテーションで囲んだものです。例えば、のようにです。
表記でちょうど 4 つの要素からなる IP アドレスです。
IP ポートを表すです。は、からまでの値に限定されており、そのうち 1024 以下の値は、典型的には、所有者が root のプロセスのみに制限されています。場合によっては、適当に大きな番号を選択するように、穴埋めとしてアスタリスク文字 (``*'') を使うことができます。
表記で指定された IP ネットワークです。その後に、``/'' が続き、そしてネットマスクのビット数が続きます。例えば、は、ネットワークで、ネットマスクはです。はネットワークで、ネットマスクはです。
共有鍵の名前を表した文字列です。これはトランザクションセキュリティに使用します。
C 言語での符号つき整数 (32 ビット整数のマシンでは 2,147,483,647) の範囲全体をとる、非負整数です。取り得る値の範囲は、使用されるコンテキストによってさらに制限されるかもしれません。
または単語か単語です。
の最大値は、マシンの符号なし long 型整数の最大値になります。は、値を無制限に使用できるよう要求したり、取り得る最大の値を要求したりするために使用します。は、サーバが始動したときに有効だった制限が使われます。
には、次のようなスケールファクタを続けることもできます : またははキロバイトを、またははメガバイトを、そしてまたははギガバイトを表します。これらはそれぞれ、 1024, 1024*1024, 1024*1024*1024 倍であることを表します。
スケールファクタの変換時に、整数値の格納場所でオーバフローが発生しても、現状では黙って無視します。その結果、期待した結果よりも小さな値、おそらくは負の値にさえなってしまいます。本当に大きな値を安全に設定したいならを使うのが最良の方法です。
またはです。あるいはとという単語でも受け付けます。とという番号でも同様です。
address_match_list = 1*
address_match_element
address_match_element = [ "!" ] (
address_match_list /
ip_address /
ip_prefix /
acl_name / "key "
key_id ) ";"
アドレスマッチリストは、主にいくつかのサーバの操作でのアクセス制御を決定するために使われます。また、アドレスマッチリストは、他のネームサーバに問い合わせる際の優先順位や、が問い合わせを待つアドレスを決定するためにも使われます。アドレスマッチリストを構成する要素は、次のうちのどれでもありえます :
( 表記 ('/' での表記) ステートメントで定義された先にステートメントで定義されたアドレスマッチリスト名別の
要素は、エクスクラメーションマーク (``!'') で始めると無効にできます。また、アドレスマッチリスト名にが前もって定義されています。リスト名に関してのさらなる情報は、ステートメントの説明のところにあります。
節が追加されたことにより、この文法の構成要素名はある種の誤用になってしまっています。なぜなら、ホストやネットワークアドレスに関係なく、アクセスの認証には認証鍵を使用することができるからです。それでもまだ、このドキュメントを通して「アドレスマッチリスト」という用語が使われています。
与えられた IP アドレスまたはプレフィックスがアドレスマッチリストと比較されるときには、要素が合致するまでリストをスキャンしていきます。合致したことをどう解釈するかは、アクセス制御、ポート定義、またはトポロジのいずれの用途にリストを使ったか、またその要素が無効にされていたかで決定します。
アクセス制御リストとしてアドレスマッチリストが使われる場合、合致した要素が無効になっていないときはアクセスを許可し、無効になっているときはアクセスを禁止します。アドレスマッチリスト中に合致するものが 1 つもない場合には、アクセスは禁止されます。節はすべてこのようにアドレスマッチリストを使用します。同様に、オプションを使うと、リストに合致しないマシンのアドレスでの問い合わせは、いずれもサーバが受け取らないようになります。
オプションと一緒にアドレスマッチリストが使用される場合、合致した要素が無効になっていない場合、リスト中で合致した位置に基づいた距離が返されます (合致した箇所がリストの先頭に近ければそれだけ、サーバとの間の距離は短いことになります)。合致した要素が無効になっている場合、サーバからもっとも遠い距離が割り当てられることになるでしょう。合致するものがなかった場合は、そのアドレスには、無効になっていないリスト要素よりは遠く、無効になっている要素よりは近い距離が返されるでしょう。
ファーストマッチアルゴリズムを使用していますので、リスト中で他の要素のサブセットを定義している要素のほうが、より広い範囲の定義をしている要素よりも、先に定義すべきです。これは、どちらか一方の要素が無効になっていようがいまいが関係ありません。例えば、では、1.2.3.13 という要素は無意味です。なぜなら、このアルゴリズムでは、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; ... ]
}; ]
... };
ステートメントは、ネームサーバに対する様々な種類のログ用オプションを設定します。その中のフレーズでは、出力方法とフォーマットオプションと重大度を名前と結びつけます。この名前は後でフレーズで使用し、様々なメッセージクラスをどのようにログに落すかを選択します。
ただ 1 つのステートメントを使用して、望むだけ多くのチャネルとカテゴリを定義できます。設定中に、複数の 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; };
};
ログ用の設定は、ステートメントがパースされたらすぐに確立されます。もし、設定ファイル全体の処理状況についてのメッセージをリダイレクトしたいのであれば、ステートメントが最初に出てくるようにしなければなりません。たとえ、設定ファイルのパース状況を表すメッセージをリダイレクトしたくなくても、ステートメントはファイルの先頭に置くことを勧めます。そうすることによって、パーサの出すメッセージを再度設定する必要が生じたときに、意識してこのルールを思い出す必要がなくなります。
ログの出力はすべて、1 つまたはそれ以上の「チャネル」へと渡ります。チャネルは好きなだけ作ることができます。
それぞれのチャネルの定義には、そのチャネル用に選択したメッセージがファイルに落されるのか、特別な syslog ファシリティに渡されるのか、または、捨てられるのかを指定する節が含まれていなくてはなりません。チャネルの定義では、チャネルが受け取るメッセージの重大度を制限することもオプションでできます (デフォルトはです)。また、が生成するタイムスタンプと、カテゴリ名と、重大度を含めるかどうかを制限することもできます。デフォルトでは、この 3 つのいずれも含めないようになっています。
チャネルに対するログの送り先のオプションにという単語を使用すると、そのチャネルに送られるメッセージはすべて捨てられるようになります。チャネルに対するその他のオプションは意味がありません。
節を使用すると、ログファイルがどれだけ大きくなっても良いかということと、ログファイルがオープンされるごとに何個のバージョンを残すのかということに関する制限を、取り込むことができます。
ログファイルに対するオプションは、単純にログが大きくなるのを制限する固い天井になるものです。ログファイルが size を超えると、ログファイルが再度オープンされるまではファイルに何も書き込みません。size を超えていても、自動的にはファイルはオープンされません。デフォルトでは、ログファイルのサイズ制限はありません。
ログファイルオプションにを使用すると、は、ログファイルがオープンされるときにファイルのバックアップバージョンの名前を変更して、指定した数だけ保持します。例えば、lamers.log というファイルの古いバージョンを 3 つ保持するように選択した場合、lamer.log がオープンされる直前に lamers.log.1 というファイルは lamers.log.2 という名前に変更され、 lamers.log.0 というファイルは lamers.log.1 という名前に変更され、そして lamers.log というファイルが lamers.log.0 という名前に変更されます。バージョン名が巡回するものはデフォルトでは保持されません。すでに存在しているログファイルは、ただ単に追加して書かれます。キーワードは、現在の BIND のリリースではと同義です。size および versions オプションの使用例は次の通りです :
channel an_example_level {
file "lamers.log" versions 3 size 20m;
print-time yes;
print-category yes;
};
節の引数は、マニュアルページに記述されている syslog ファシリティを表します。がこのファシリティに送られるメッセージをどのように扱うかについては、マニュアルページに記述があります。関数に 2 つの引数しか使用しない、とても古いバージョンの syslog を使用しているシステムをお使いの場合は、この節は黙って無視されます。
節は、syslog の「優先度」のように働きます。ただし、syslog を使用するかわりにファイルを直接書いても使用できるところが違います。与えられた重大度よりも低いレベルのメッセージは、このチャネルに対しては選択されません。与えられた重大度よりも高いレベルのメッセージが受け取られます。
syslog を使っている場合、での優先度によっても最終的に何が通り抜けるかが決定されます。例えば、チャネルのファシリティおよび重大度をおよびに定義しているが、ではしかログに落とさないようにしている場合、およびの重大度を持ったメッセージは捨てられてしまいます。状況が逆になり、がかそれ以上の重大度を持ったメッセージしか書きださないようになっている場合、は、そのチャネルから受け取ったメッセージをすべて書き出すことでしょう。
デバッグモードになっている場合、サーバはもっと多くのデバッグ情報を提供できます。サーバのデバッグレベルが 0 より大きくなっていれば、デバッグモードは有効になっています。全体でのデバッグレベルは、フラグに正の整数値を続けて指定してサーバを開始するか、または、動いているサーバにシグナルを送る (例えば、を使って) ことによって設定します。全体でのデバッグレベルは 0 にも設定でき、このときは、デバッグモードは無効になります。この状態には、サーバにシグナルを送る ( を使って) ことによってもできます。サーバでのデバッグメッセージにはすべてデバッグレベルがあります。そして、デバッグレベルが高いほどより詳細な出力になっています。例えば、特定のデバッグ重大度を次のように指定したチャネルでは、サーバがデバッグモードであればいつでも、レベル 3 またはそれ以下のレベルのデバッグ出力が得られます。
channel specific_debug_level {
file "foo";
severity debug 3;
};
それは、全体でのデバッグレベルには依りません。重大度を指定したチャネルでは、どのメッセージを出力するかを決めるためにサーバ全体のデバッグレベルを使用します。
がオンになっていれば、日付および時刻がログに落とされます。は、syslog チャネルに対しても指定できますが、通常は意味のないことです。なぜなら、syslog も日付および時刻は出力するからです。が要求されている場合、メッセージのカテゴリも同様にログに落とされます。最後に、がオンになっていれば、メッセージの重大度がログに落とされます。オプションはどういう組合せでも使うことができ、常に次のような順番で出力されます : それは time, category, severity の順です。次に示す例は、3 つすべてのオプションをオンにした例です :
28-Apr-1997 15:05:32.863 default: notice: Ready to answer queries.
でのデフォルトのログ取得用に使用されるチャネルには、次のような、事前に定義された 4 つがあります。どのようにこのチャネルを使うのかについては次節に記述があります。
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 カテゴリ」が使われます :
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; };
カテゴリ内のすべてのメッセージを捨てるには、チャネルを指定してください :
category lame-servers { null; };
category cname { null; };
次のようなカテゴリが使用可能です :
すべて捕まえます。多くのメッセージがまだカテゴリ分けされておらず、すべてここで捕まります。さらに、カテゴリに対して何のチャネルも指定しなかった場合、代わりに default カテゴリが使われます。default カテゴリを指定しなかった場合、次のような定義が使われます :
ハイレベルの設定ファイル処理です。
ローレベルの設定ファイル処理です。
サーバが受け取った問い合わせそれぞれに対して、短いログメッセージを生成します。
``Lame server on ...'' というようなメッセージです。
統計です。
サーバ内部の問題でサーバ自体がシャットダウンしなくてはならなくなると、問題の起きた元のカテゴリとこのカテゴリの両方に、問題をログとして書きこみます。 panic カテゴリを定義していない場合には、次のような定義が使われます :
動的な更新です。
ネガティブキャッシングです。
サーバが受け取っているゾーン転送です。
サーバが送っているゾーン転送です。
すべてのデータベースの操作です。
イベントシステムからのデバッグ情報です。このカテゴリには、ただ 1 つのチャネルが指定でき、そのチャネルはファイルチャネルでなくてはなりません。 eventlib カテゴリを指定しない場合は、次のような定義が使われます :
受け取ったパケットおよび送ったパケットのダンプです。このカテゴリには、ただ 1 つのチャネルが指定でき、そのチャネルはファイルチャネルでなくてはなりません。packet カテゴリを指定しない場合は、次のような定義が使われます :
NOTIFY プロトコルです。
``... points to a CNAME'' のようなメッセージです。
許可された / 許可されなかったリクエストです。
オペレーティングシステムの問題です。
内部の整合性チェックの失敗です。
定期的に行われるメンテナンスのイベントです。
ゾーンへのロードメッセージです。
応答のチェックから発生するメッセージです。例えば、 ``Malformed response ...'', ``wrong ans. name ...'', ``unrelated additional info ...'', ``invalid RR type ...'', ``bad referral ...'' といったものです。
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 ブロックが使われます。
ndc コマンドの問い合わせや chaos クラスの名の問い合わせを通してサーバがレポートするべきバージョンです。デフォルトではサーバの本当のバージョン番号になっていますが、サーバのオペレータの中にはこの文字列の方が好みという人もいます ( )。
サーバの作業ディレクトリです。設定ファイル中の絶対パスでないパス名は、どんなものでもこのディレクトリからの相対パスと受け取られます。大部分のサーバの出力ファイル (例えば、のデフォルトの置き場所は、このディレクトリです。もし、ディレクトリの指定がなければ、作業ディレクトリはデフォルトでになります。このディレクトリは、サーバが起動したディレクトリです。指定されたディレクトリは絶対パスでなくてはいけません。
内部へのゾーン転送用にサーバが使用する named-xfer プログラムへのパス名です。指定されていない場合のデフォルトは、システム依存です (例えば、です)。
シグナルをサーバが受け取ったとき ( が送った場合のように) に、データベースのダンプを落とすファイルへのパス名です。指定されていない場合のデフォルトは、です。
がになっている場合に、サーバが終了時にメモリ使用統計を書き出すファイルへのパス名です。指定されていない場合のデフォルトは、です。
サーバが自分のプロセス ID を書き出すファイルへのパス名です。指定されていない場合のデフォルトは、オペレーティングシステムに依存しますが、通常は、あるいはです。 pid-file は、のような、動作しているネームサーバにシグナルを送りたいプログラムが使用します。
サーバがシグナルを ( から) 受け取った場合に、統計を追加書き込みするファイルへのパス名です。指定されていない場合のデフォルトは、です。
これがの場合、ビットは、常にの応答にセットされます。たとえサーバが実際には信頼できるものではなくてもです。デフォルトでは、になっています。古くからあるソフトウェアが嫌うので、自分のしていることに確信が持てないでいるのであれば、をオフにしてはいけません。
これがの場合には、サーバは、終了時に自分が確保したオブジェクトを徹底して開放して、にメモリ使用レポートを書き出します。デフォルトでは、になっています。なぜなら、オペレーティングシステムにクリーンアップをやらせたほうが高速だからです。は、メモリリークを検出するために便利です。
これがの場合には、サーバは、すべてのゾーンを、要求時ダイヤルによるダイヤルアップリンクを通してゾーン転送を行っているかのように扱います。このダイヤルアップリンクは、このサーバから通信が始まった場合に立ち上げられるものです。これは、ゾーンの種類によって異なる効果をもたらし、ゾーンの保守に専念できるようになります。これによって、ごとに 1 度、願わくは、1 回の呼び出しの間という短い間隔でゾーンの保守を行えるようになります。このオプションはまた、通常のゾーン保守にかかるトラフィックをいくらか抑えることもできます。デフォルトは、です。オプションは、ステートメント中でも指定することができます。この場合は、ステートメントは上書きされます。
ゾーンがである場合、サーバは、すべてのスレーブに対してリクエストを送信するようになります。これによって、スレーブをチェックし、呼び出しが生きている間にスレーブがゾーンを検証できるようにすることで、ゾーンを最新のものにする契機ができます (サーバがをサポートする場合です)。
ゾーンがもしくはである場合、サーバは、通常のゾーンのアップデート問い合わせを抑制し、が時間切れになったときだけ問い合わせるようにします。
これがの場合、サーバは、という、もう古くなって使われていない DNS 問い合わせをシミュレーションします。デフォルトはです。
これがの場合 (デフォルトではそうです)、サーバは、追加の応答用データセクションを作る際には持っていない「糊」となるリソースレコードを取得します。サーバのキャッシュが大きくなったり、破壊されたりしないようにするため (こうなると、クライアントからもっと多くの仕事を要求されるという代償を払うことになります)、は、と一緒に使用できます。
このオプションをに設定することと、次の 3 つのオプションを設定することとは等価です : をと一緒に使用することで起こることは、指定の順番によります。
これがである場合、ネームサーバと相互に作用する各ホストに対して統計が保持されます。デフォルトではです。をオンにすると、膨大な量のメモリを消費する可能性があります。
保持する最大のホストレコード数です。この限界に達っすると、ホストの統計情報に新規ホストは追加されません。 0 に設定すると、限界はありません。デフォルト値は 0 です。
これがの場合、すべての動的に更新されるゾーンに対して、単一の IXFR データベースファイルが保持されます。これを有効にすると、ゾーン転送を非常に高速化可能な IXFR 問い合わせに、サーバは答えます。デフォルトはです。
これがである場合、 1 つのドメイン名について複数の CNAME リソースレコードか許可されます。デフォルトはです。複数の CNAME レコードを許可するということは、標準からは外れており、推奨されることではありません。以前のバージョンの BIND が複数の CNAME レコードを持つことを許しており、このレコードがいくつかのサイトでは負荷のバランスを取るために使用されていたことから、複数の CNAME のサポートを利用できるということです。
これがである場合 (それがデフォルトです)、変更を行うためにゾーンサーバが信頼できる場合に DNS NOTIFY メッセージを送るようになります。 NOTIFY を使用すると、マスタサーバとそのスレーブとの間の収束が早まります。NOTIFY メッセージを受け取り、理解するスレーブサーバはそのゾーン用にマスタサーバに接続し、ゾーン転送を行う必要があるかを点検します。そして、必要がある場合は直ちにゾーン転送を開始します。オプションはステートメント内でも指定できます。この場合は、ステートメントは上書きされます。
これがであり、 DNS の問い合わせが再帰処理を要求している場合、サーバはその問い合わせに答えるために必要な仕事をすべて行おうとします。 recursion がオンになっていない場合、サーバが答えを知らない場合は、サーバはクライアントに照会を返します。デフォルトでは、です。前述のも参照してください。
これがであれば、サーバは、否定応答用に SOA レコードと一緒に NS レコードを送ります。もし、古い BIND サーバを持っていて、 SOA と NS の両方を含んだ否定応答を理解しないフォワード用サーバとして使用している場合や、古いバージョンの sendmail を持っている場合は、このオプションを no に設定する必要があります。正しい解決策は、そういう壊れたサーバや sendmail を使用しないことです。デフォルトでは、このオプションはです。
これがであれば、サーバは自分自身の未解決の問い合わせ ID を追跡して、重複を避け、ランダム性を高めるようにします。これによって、サーバが 128 KB も多くメモリを消費するようになります。デフォルトはです。
これがの場合、サーバは、スペースやタブを扱うのと同じ方法で CR 文字を扱うようになります。NT あるいは DOS マシンで生成したゾーンファイルを UNIX システム上にロードするときに、このオプションは必要でしょう。デフォルトでは、このオプションはです。
ゾーンの新しいコピーがロードされるときはいつでも送信された NOTIFY メッセージも受け取る IP アドレスのグローバルリストを定義します。このオプションは、ゾーンのコピーが素早く「内密の」サーバ上で確実に収束する助けになります。リストがステートメントで与えられた場合、ステートメントは上書きされます。ステートメントがに設定されている場合、グローバルのリストの IP アドレスは、このゾーンに対する NOTIFY メッセージを送信されません。デフォルトでは、このリストは空です (グローバルな notification リストはないということです)。
フォワード機能は、少数のサーバ上で大きなサイト単位のキャッシュを作成するために使用することができます。これによって、外部のネームサーバへのリンクを越えたトラフィックを軽減できます。フォワード機能は、直接インターネットに接続できないが、ともかく外部のホスト名を見つけ出したいというサーバの問い合わせを許可するためにも使用できます。フォワードが発生するのは、そうした問い合わせに対してサーバが権限を持たず、キャッシュにその応答が入っていない場合だけです。
このオプションは、リストが空でない場合にだけ意味があります。という値がデフォルトですが、このときサーバは、まずフォワードを行うサーバに問い合わせを行い、フォワードを行うサーバが要求に対して応答しない場合、自分で応答を探します。が指定された場合、サーバは、ただフォワードを行うサーバに問い合わせを行うだけです。
フォワードを行うために使用される IP アドレスを指定します。デフォルトでは、これは空のリストです (フォワードを行いません)。
フォワード機能は、ゾーン単位をもとにして設定することもできます。このときは、グローバルのフォワード用オプションが、さまざまな方法で上書きできるようになります。特定のゾーンに対し、別のフォワード用サーバを使用したり、別のの振るまいをもたせたり、あるいはまったくフォワードしなかったりできます。さらなる情報については、のセクションを参照してください。
BIND 8 の将来のバージョンでは、もっと強力なフォワード用システムを提供する予定です。先に述べた文法は引き続きサポートされる予定です。
サーバは、期待するクライアントの関係に基づいてドメイン名をチェックできます。例えば、ホスト名として使用されるドメイン名は、正当なホスト名を定義している RFC に準拠するかという点でチェックされます。
チェック方法には 3 通りのやり方が利用可能です :
何のチェックも行われません。
期待するクライアントの関係から名前をチェックします。不正な名前はログに書かれますが、処理は普通に継続します。
期待するクライアントの関係から名前をチェックします。不正な名前はログに書かれ、ルールに合わないデータは拒否されます。
サーバは、名前を 3 つのエリアでチェックできます : マスタゾーンファイル、スレーブゾーンファイル、そして、サーバが発行した問い合わせへの応答です。が指定されており、クライアントの問い合わせに対する応答がクライアントに不正な名前を送る必要のあるものであった場合、サーバは、応答コードをクライアントに送ります。
デフォルトは、次の通りです :
check-names master fail;
check-names slave warn;
check-names response ignore;
は、ステートメントでも指定できます。この場合、は上書きされます。ステートメントで使用した場合、エリアは指定されません (なぜなら、ゾーンの種類からエリアは推測できるからです)。
サーバへのアクセスは、アクセスを要求したシステムの IP アドレスまたは共有秘密鍵に基づいて制限することができます。アクセス基準をどのように指定するかについての詳細は、を参照してください。
どのホストが通常の問い合せをすることができるかを指定します。は、ステートメントでも指定できます。この場合、ステートメントを上書きします。もし、allow-query オプションが指定されていない場合は、デフォルトは、すべてのホストからの問い合わせを許可します。
どのホストが再帰的な問い合わせが可能かを指定します。指定されていない場合は、デフォルトでは全てのホストから再帰的な問い合わせができます。
どのホストがゾーン転送をサーバから受け取ることを許可されるかを指定します。は、ステートメントでも指定できます。その場合、ステートメントは上書きされます。もし、allow-transfer オプションが指定されていない場合は、デフォルトでは、すべてのホストからの転送を許可します。
サーバが問い合わせを受け取らないようになったり、問い合わせを解決するために使用しないようになるアドレスのリストを指定します。これらのアドレスからの問い合わせは、応答されることはありません。
サーバが問い合わせに答えるインタフェースならびにポートは、オプションを使って指定することができます。は、オプションのポートおよびアドレスマッチリストを取ります。サーバは、アドレスマッチリストで許可されたインタフェース全てで待機します。ポートを指定しない場合は、53 番ポートが使われます。
ステートメントが複数あっても良いです。例えば、
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 ではないマシンに使用を許可します。
が指定されていない場合は、サーバは、すべてのインタフェース上で 53 番ポートでの待機をします。
サーバが問い合わせに対する答を知らない場合、そのサーバは、他のネームサーバに問い合わせを行います。は、こうした問い合わせに使用されるアドレスおよびポートを指定します。がだったり、省略されている場合、ワイルドカード IP アドレス ( ) が使用されます。がだったり、省略されている場合、特権のいらないポートがランダムに使用されます。デフォルトではです。注 : は、現在 UDP 問い合わせのみ適用されます。 TCP 問い合わせには、常にワイルドカード IP アドレスとランダムに選ばれた特権のいらないポートが使用されます。
ここで指定された時間より長く動作している内部へのゾーン転送 ( プロセス) を終了します。デフォルトでは、120 分 (2 時間) です。
サーバは 2 種類のゾーン転送方法をサポートしています。転送されるリソースレコードそれぞれについて 1 つの DNS メッセージを使用します。できるだけ多くのリソースレコードを 1 つのメッセージに押し込みます。の方が効率的ではありますが、BIND 8.1 および、パッチの当たった BIND 4.9.5 でのみ理解されるものです。デフォルトでは、になります。は、ステートメントを使用してサーバ単位で上書きすることができます。
同時に動作させることのできる内部へのゾーン転送の最大値です。デフォルトは 10 です。の数を増やすと、スレーブのゾーンの収束が早まりますが、ローカルシステムの負荷も上がってしまう恐れがあります。
このオプションは、将来、同時に動作する外部へのゾーン転送数を制限するために使用する予定です。現在、文法はチェックしていますが、それ以上のことは無視しています。
あるリモートのネームサーバから同時に実行できる内部へのゾーン転送 ( プロセス) の最大値です。デフォルトは 2 です。の数を増やすと、スレーブゾーンの収束は早まりますが、リモートのネームサーバの負荷が上がってしまう恐れがあります。は、ステートメントのフレーズを使用してサーバ単位で上書きすることができます。
は、サーバが内部に転送するゾーンをすべて取得するために使用される TCP コネクションとどのローカルアドレスとが結びつけられるかを決定します。これが設定されていない場合、システムが制御しているデフォルト値に設定されます。この値は、通常、リモート側の終端に「最も近い」インタフェースのアドレスになります。このアドレスは、もし指定されているのなら、リモート側の終端の転送ゾーン用のオプションで登場していなくてはなりません。このステートメントは、すべてのゾーンのを設定しますが、設定ファイル中のゾーンブロック内にステートメントを含めることでゾーン単位で上書きすることができます。
多種のシステムリソースをサーバがどこまで使用してよいか制限可能です。オペレーティングシステムによっては、この制限をいくつかサポートしていないものもあります。そうしたシステムでは、サポートされていない制限を使用すると警告が発生します。また、オペレーティングシステムによっては、リソース制限自体をサポートしていないものもあります。そうしたシステムでは、というメッセージがログに記録されます。
リソース制限を指定する際には、スケールを変えた値を使用することができます。例えば、1 ギガバイトの制限を指定したい場合に、をの代わりに使用することができます。は、無制限にリソースを使用する、つまり、利用可能な最大の量のリソースを要求します。は、サーバが開始したときに有効だった制限値を使用します。詳細については、のセクションのの項を参照してください。
コアダンプの最大サイズです。デフォルト値はです。
サーバが使用できるデータメモリの最大領域です。デフォルト値はです。
サーバが同時にオープンできるファイルの最大数です。デフォルト値はです。オペレーティングシステムによっては、unlimited という値を設定できず、カーネルがサポートできるオープンするファイルの最大値を決定できないものがあることに注意してください。こうしたシステムでは、を選択すると、サーバがから得られるの値よりも大きなファイル数を扱ってしまい、を返してしまうことになります。実際のカーネルの制限値がこの値よりも大きい場合は、を使用して、明示的に制限値を指定してください。
は、将来のサーバのリリースでは、インクリメンタルゾーン転送用に保持しておくトランザクションログの大きさに制限を設けるために使用する予定です。
サーバが使用できるスタックメモリの最大量です。デフォルト値はです。
サーバは、分ごとに期限の切れたリソースレコードをキャッシュから削除します。デフォルトは 60 分です。これが 0 に設定されているときは、定期的にキャッシュがクリーニングされることはありません。
サーバは、この間隔が過ぎればいつでもの印のついたゾーンすべてに対してゾーン管理タスクを実行します。デフォルトでは 60 分です。適切な値は 1 日 (1440 分) までです。この値が 0 に設定されている場合、これらのゾーンに対するゾーン管理は実行されません。
サーバは、分ごとにネットワークインタフェースリストをスキャンします。デフォルトでは 60 分です。この値が 0 に設定されている場合、インタフェースのスキャンを行うのは、設定ファイルがロードされたときだけです。スキャンした後、待機タスク (listener) は、どの新しいインタフェース上でも始動します (そのタスクがの設定がされていて許可されている場合です)。取り除かれたインタフェース上で動作している待機タスクは、消去されます。
ネームサーバの統計が分ごとにログに記録されます。デフォルトは 60 です。この値が 0 に設定されている場合、何の統計も記録されません。
ネームサーバのリストから問い合わせ先のネームサーバをサーバが 1 つ選ぶとき、他の点ではすべて対等である場合、このサーバは、自分自身からトポロジ的に最も近いものを選びます。ステートメントは、アドレスマッチリストをとり、特別な方法でそのリストを解釈します。それぞれの一番上のリスト要素は距離が割り当てられています。無効にされていない要素は、リスト中の位置に基づいて距離を取得します。ここで、リストの先頭にマッチした地点が近ければ近いほど、サーバと要素との距離が近いことになります。無効にされているマッチには、サーバからの距離の最大が割り当てられます。マッチするものがない場合は、そのアドレスは、無効にされていないリストの要素のどれよりも遠い距離を取得します。例えば、
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) 上のホストは除外されます。このネットワーク上のものは、どれよりも選ばれにくいものです。
デフォルトのトポロジはです。
複数の RR (訳注: リソースレコード) が返ってくると、通常ネームサーバは、でそれらを返します。すなわち、各要求の後に、最初の RR がリストの最後に置かれます。 RR の順番が決まっていないので、これで問題ありません。
クライアントのリゾルバのコードが、これらの RR を適切に構成しなおさなくてはなりません。すなわち、他のアドレスよりも、ローカルネット上の任意のアドレスを優先して使用するということです。しかしながら、すべてのリゾルバがこうすることができたり、適切に設定されているわけではありません。
クライアントがローカルサーバを使用しているとき、サーバ内で、クライアントのアドレスに基づいたソートが実行できます。このソートのためには、ただネームサーバを設定するだけでよく、すべてのクライアントを設定する必要はありません。
ステートメントは、アドレスマッチリストをとり、ステートメントより更に増した特別な方法でリストを解釈します。
ソートリスト中の各先頭のステートメントは、それ自身、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 ステートメントを使用すると、複数レコードが含まれる応答中のレコードの順番を設定することができます。順番が定義されていない場合、デフォルトでは、巡回順 (ラウンドロビン) になります
は次のように定義されています :
[
class class_name ][
type type_name ][
name "FQDN" ]
order ordering
クラスが指定されていない場合、デフォルトはです。が指定されていない場合、デフォルトはです。名前が指定されていない場合、デフォルトは "*"です。
の正当な値には、次のようなものがあります :
レコードは、ゾーンファイルで定義された順番で返されます。
レコードは、ある種のランダムな順番で返されます。
レコードは、ラウンドロビンに返されます。
例えば、
rrset-order {
class IN type A name "rc.vix.com" order random;
order cyclic;
};
では、サフィックスに "rc.vix.com"を持ち、クラス IN でタイプ A のレコードに対する応答は、常にランダムな順番で返されます。その他のレコードはすべて巡回順に返されます。
ステートメントが複数現れた場合、ステートメントは連結されません。最後のものが適用されます。
ステートメントが指定されていない場合、デフォルトは
rrset-order { class ANY type ANY name "*" order cyclic ; };
が使われます。
不完全なサーバの指示をキャッシュしておく秒数を設定します。 0 の場合、キャッシュしません。デフォルトは 600 (10 分) です。最大値は 1800 (30 分) です。ネットワークの負荷を軽減しパフォーマンスを上げるために、サーバが否定応答を蓄えます。は、サーバで、このような応答の最大保存時間を設定するために使います。秒単位です。デフォルトのは 10800 秒 (3 時間) です。通常の (肯定) 応答に対しては、最大保存時間を超えてはいけません (7 日)。もし、この値が 7 日以上に設定されていた場合、黙って 7 日に切り詰めてしまうでしょう。ルートサーバに対する要求を受け取るために必要なルートサーバの最小値です。デフォルトは 2 です。
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 ); ] };
ステートメントは、特定の DNS ゾーンがサーバにどのように管理されるかを指定するために使われます。ゾーンには 5 つの種類があります。
サーバは、そのゾーン用データのマスタコピーを持っていて、ゾーンに対して信頼できる応答を提供できます。
ゾーンはマスタゾーンの複製です。リストは、ゾーンの複製を更新するためにスレーブサーバが通信を行う 1 つ以上の IP アドレスを指定します。が指定されている場合、このポートに対し、ゾーンが現在使用されているものであることの確認と、ゾーン転送が行われます。が指定されている場合、指定されたファイルへゾーンの複製が書き出されます。節を使用することを強く勧めます。なぜなら、大体においてサーバの起動を早めますし、通信回線を無駄に使用することを防いでくれるからです。
ゾーンは slave ゾーンのようなものですが、ゾーン全体を複製するのではなく、マスタゾーンの NS レコードのみを複製するという点が違います。
ゾーンは、自分に向けられた問い合わせを他のサーバに振り分けるために使用します。このことは、のセクションで説明しています。これらのゾーンでのオプション仕様は、ステートメントで宣言されたグローバルオプションを上書きします。
節が zone ステートメント中に存在しないか、もしくは、に対して空リストが与えられている場合は、そのゾーンに対してフォワードは行われず、ステートメント中のは、すべて効力を失います。そのため、使用されるサーバではなく、グローバルのオプションの挙動を変更するためだけにこの種類のゾーンを使用したいのであれば、グローバルの forwarders 節も指定しなおす必要があります。
ルートネームサーバの初期集合は、ゾーンを使用して指定されます。サーバが起動する際に、ルートヒントを使用してルートネームサーバを見つけ、ルートネームサーバの最新リストを取得します。
注 : 以前の BIND リリースでは、マスタゾーンに対してはという用語を使用し、スレーブゾーンに対しては、を、hint ゾーンに対してはという用語を使用していました。
ゾーン名には、オプションでクラスを続けることができます。もし、クラスが指定されていない場合は、クラス (「インターネット」用) であると仮定されます。これは、大半の場合正しいです。
クラスは、MIT の Project Athena 由来の情報サービス用のクラスです。このクラスは、ユーザ、グループ、プリンタなどといった、さまざまなシステムデータベースに関する情報を共有するために使用されます。さらなる情報は、 ftp://athena-dist.mit.edu/pub/ATHENA/usenix/athena_changes.PS から入手できます。キーワードはと同義語です。
MIT が開発したもう 1 つのものが、1970 年代半ばに作られた LAN プロトコルである CHAOSnet です。これは、LISP ステーションや AI コミュニティで使われている他のハードウェアで、まだ時折見受けられます。CHAOSnet 用のゾーンデータは、クラスを使用して指定できます。
のに関するサブセクションを参照してください。
のサブセクションの中のに関する説明を参照してください。
どのホストが動的な DNS の更新をサーバに提出するかを指定します。デフォルトは、どのホストからも更新を許可しないというものです。
のサブセクションの中のに関する説明を参照してください。
どのローカルアドレスが、このゾーンを取得するために使用される TCP 接続と結びつけられるかを指定します。これが設定されていない場合は、システムが制御する値がデフォルトになります。この値は、通常は、リモート側の終端に「最も近い」インタフェースのアドレスです。このアドレスは、もし指定されているのであれば、このゾーンに対するリモート側の終端のオプション中に出てこなくてはなりません。
のサブセクション中のの説明を参照してください。
のサブセクション中のの説明を参照してください。
のサブセクション中のの説明を参照してください。
がこのゾーンに対してアクティブである場合のみは意味を持ちます。このゾーンに対する DNS NOTIFY メッセージを受け取るマシン群は、そのゾーン用にリストされたすべてのネームサーバ (プライマリマスタを除く) と、で指定された IP アドレスからなっています。はゾーンに対しては意味を持ちません。デフォルトでは、これは空のリストです。
は、そのゾーンがリストを持っている場合のみ意味を持ちます。値は、先にを試し、応答がなかった場合に検索を失敗させます。それに対し、は、通常の検索を許可します。
ゾーン中でオプションを使用すると、グローバルの forwarders リストが上書きされます。タイプのゾーン中でこれが指定されていなかった場合は、このゾーンに対してはフォワードも行いません。グローバルのオプションは使われないということです。
DNSSEC のフラグ、プロトコル、アルゴリズムと、 base-64 でエンコードされた鍵を表す文字列を指定します。
acl
name {
address_match_list };
ステートメントは、名前のついたアドレスマッチリストを生成します。このステートメントは、プライマリで使用しているアドレスマッチリスト、つまり、アクセス制御リスト (ACL) からその名前を取得します。
アドレスマッチリスト名は、他のところで使用する前にを使用して定義しなくてはなりません。ファイルの前方への参照は許されていません。
次のような組み込みの ACL があります :
すべてのホストを許可します。すべてのホストを拒否します。システム上のすべてのインタフェースの IP アドレスを許可します。システムがインタフェースを持ったネットワーク上のすべてのホストを許可します。
key
key_id {
algorithm
algorithm_id;
secret
secret_string; };
ステートメントは、鍵の ID を指定します。この ID は、ステートメントで使用され、単純な IP アドレスでのマッチングよりも厳格な特定のネームサーバと認証方法とを関連づけます。鍵の ID は、の定義やアドレスマッチリスト中で使用される前にステートメントを使用して作成されていなくてはなりません。
は、セキュリティ / 認証アルゴリズムを指定する文字列です。は、指定されたアルゴリズムが使用する秘密の鍵で、 base-64 でエンコードされた文字列として扱われます。言わずとも当然のことですが、為念指摘しておくと、中にを入れている場合、 named.conf をスーパユーザ以外の誰にも読み込み可能にしてはいけません。
trusted-keys {
[
domain_name
flags
protocol
algorithm
key; ] };
ステートメントは、もともと、RFC 2065 で仕様が決められている DNSSEC スタイルのセキュリティとともに使用されます。DNSSEC は、 3 つの異なったサービスを提供するものです : それは、鍵の配布、データの発生元の認証、そして、トランザクションおよび要求の認証です。DNSSEC についての完全な説明とこのドキュメントの範囲を超えた使い方を知りたい場合、そして、読者がさらなる情報に興味がある場合は、まず、RFC2065 を読むことから始めてください。そして、 http://www.ietf.org/ids.by.wg/dnssec.html から入手できるインターネットドラフトへと続いてください。
信頼された鍵はそれぞれ、ドメイン名と関連づけられています。その属性は、非負の整数値である、と、を表す base-64 でエンコードされた文字列です。
信頼された鍵の番号はすべて指定可能です。
server
ip_addr {
[ bogus
yes_or_no; ]
[ transfers
number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ keys {
key_id [
key_id ... ] }; ] };
server ステートメントは、リモートのネームサーバに関連付けられる特徴を定義します。
サーバが間違ったデータを送っていることに気がついた場合、そのサーバをにすることで、そのサーバへの問い合わせを抑止することができます。のデフォルト値はです。サーバにの印を付けると、当該サーバのアドレスを名前で検索してマッチしたときに、当該サーバに対する他のアドレスもすべての印を付けます。
サーバは、2 つのゾーン転送方式をサポートしています。1 つ目は、であり、これは、転送される各リソースレコードに 1 つの DNS メッセージを使用します。は、できるだけ多くのリソースレコードを 1 つのメッセージに押し込みます。の方が効率的ではありますが、BIND 8.1 および、パッチの当たった BIND 4.9.5 でのみ理解されるものです。サーバに対してどちらの方法を使用するかは、オプションを使用して指定することができます。が指定されていない場合は、ステートメントで指定されたが使用されます。
は、将来のリリースでのサーバで、指定されたサーバから同時に行われる内部へのゾーン転送数を制限するために使用される予定です。現在は、文法はチェックしますが、その他のことは無視されます。
節は、ステートメントで定義されたを識別するために使用されます。これは、リモートサーバと通信する際のトランザクションのセキュリティ用に使用されます。ステートメントは、それを参照するステートメントよりも先に現れなくてはなりません。
ステートメントは、将来、サーバによって使用されることを期待されています。現在は、文法はチェックされますが、その他のことは無視されます。
controls {
[ inet
ip_addr
port
ip_port
allow {
address_match_list; }; ]
[ unix
path_name
perm
number
owner
number
group
number; ] };
ステートメントは、システム管理者がローカルのネームサーバの操作に影響を与えるために使用する制御チャネルを宣言します。制御チャネルは、ユーティリティが、ネームサーバにコマンドを送り、 DNS 以外の結果を受け取るために使用します。
制御チャネルは、ファイルシステムでの FIFO です。このチャネルへのアクセスは、通常のファイルシステムのパーミッションによって制御されます。この制御チャネルは、指定されたファイルモードのビット ( を参照) とユーザおよびグループの所有者情報を使用し、が作成します。注意することは、とは違い、に対して指定されるモードのビットには、通常先頭にがついていることです。そのため、数字は 8 進数として解釈されます。さらに注意することは、およびとして指定されるユーザおよびグループの所有者情報は、数字で与えなくてはならないということです。名前ではありません。このパーミッションは、管理者のみに制限することを勧めます。そうしないと、このシステム上のユーザなら誰でもローカルネームサーバを操作できてしまいます。
制御チャネルは、インターネット接続のできる TCP/IP ソケットです。これは、指定された上の指定されたにあります。最近のクライアントは、こうしたソケットと直接対話ができます。このときの制御プロトコルは、ARPAnet 形式のテキストです。 127.0.0.1 だけをに使用することを勧めます。これは、ネームサーバを管理するために、ローカルホスト上の特権を持たないユーザを皆信用している場合だけに限ります。
include
path_name;
ステートメントは、そのステートメントが現れた地点に、指定されたファイルを挿入します。ただし、他のステートメント内で使用することはできません。ですので、というようには使用できません。
を使用して、設定ファイルを簡単に管理できるかたまりに分けるようにしてください。例えば、次のようにです :
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"; };
BIND 8 設定ファイル