Provided by: manpages-ja_0.5.0.0.20161015+dfsg-1_all 
名称
named.conf named(8) — 用の設定ファイル
概要
BIND 8 は、以前のリリースと比べて遥かに設定可能なものになっています。 完全に新しい設定項目が
あります。例えばアクセス制御リストやカテゴリ別の ログなどです。以前はゾーンすべてに対して適
用されていたオプションの多くが、 選択的に使えるようになっています。 こうした機能に加え、 将
来必要とされる設定がどのようなものになるかをよく考えた結果、 新たに設定ファイルのフォーマッ
トを作ることにしました。
一般的な文法
BIND 8 の設定には、一般的な特徴が 2 つあります。 それは、ステートメントとコメントです。 ス
テートメントはすべてセミコロンで終わります。ステートメントの多くは サブステートメントを持っ
ており、サブステートメントもセミコロンで終わります。
次のようなステートメントをサポートしています :
logging
サーバが何をログに残すか、そしてどこにログメッセージを送るのかを指定します。
options
グローバルなサーバ設定オプションを制御し、 その他のステートメントに対するデフォルトを設定
します。
zone
ゾーンを定義します。
acl
名前つきの IP アドレスマッチングリストを定義します。これは、アクセス制御や その他の用途に
使われます。
key
認証と許可に使われる鍵情報を指定します。
trusted-keys
DNSSEC 鍵を定義します。これは、事前にサーバに設定されており、暗黙のうちに 信頼します。
server
個々のリモートサーバ用の設定オプションを設定します。
controls
ndc ユーティリティが使用する制御チャネルを宣言します。
include
他のファイルをインクルードします。
logging および options ステートメントは、各設定につき 1 回のみ記述可能です。それに対し、 そ
の他のステートメントは何回でも記述可能です。各ステートメントの 詳細については、次に個々のセ
クションで述べます。
コメントは、BIND 設定ファイル中でホワイトスペースが現れて良い 所ならどこでも記述可能です。い
ろいろなプログラマの注意を引くように、 C や C++ 、あるいは シェルや perl の形式のコメントを
書くことができます。
C のスタイルのコメントは、次の 2 つの文字から始まります。 /* (スラッシュと星印) そして、 */
(星印とスラッシュ) で終わります。 この形式のコメントは、これらの文字で完全に区切られるもので
あるので、 行の一部分のみでも複数行にまたがっても使用することができます。
C のスタイルのコメントは入れ子にはできません。例えば、次の例は 不適切なものです。なぜな
ら、コメント全体が最初の */ で終わってしまうからです。
/* この行はコメントの最初です。
この行もコメントの一部です。
/* この行は、間違えてコメントを入れ子にしようとしています。 */
この行は、もうコメント内部ではありません。 */
C++ スタイルのコメントは、次の 2 文字から始まります。 // (スラッシュとスラッシュ) そして、そ
の行の終わりまでがコメントとして 続きます。この種類のコメントは、複数行にわたって続きませ
ん。意味としては 1 つだが複数行にまたがるようなコメントを書きたい場合は、各行に // を書かな
くてはなりません。例えば、次のようにです :
// この行は、コメントの始まりです。次の行は、
// 新しいコメントになります。たとえ、意味としては
// 前の行のコメントの一部分であってもです。
シェルスタイル (あるいは、お好みなら perl スタイル) のコメントは、 次の文字で始まります。 #
(ハッシュとかポンドとか番号とかナンバ記号とかどう呼んでも良い) そして、 C++ スタイルのコメン
トと同様に、その行の最後までコメントが続きます。 例えば、次のようにです :
# この行は、コメントの始まりです。次の行は、
# 新しいコメントになります。たとえ、意味としては
# 前の行のコメントの一部分であってもです。
注: ゾーンファイルで書くように、 ; (セミコロン) をコメントの始まりに使用することはできませ
ん。 セミコロンは、設定ステートメントの末尾を表すものですので、 その後ろに続く文字は、何であ
れ次のステートメントの先頭だと 解釈されてしまいます。
BIND 4.9.x から変更する
BIND 4.9.x の設定ファイルは、 src/bin/named/named-bootconf という名前の、BIND 8.2.x のソース
キットに同梱されている シェルスクリプトを使用することで新しいフォーマットに変換する ことがで
きます。
記述方法の定義
次から述べていることは、BIND 設定ファイルを記述する間使用される要素 についてです。1 つのス
テートメントとしか結びつかない要素は、その ステートメントについて述べているセクションにだけ
記述があります。
acl_name
acl ステートメントで定義される address_match_list の名称です。
address_match_list
ip_addr, ip_prefix, key_id, acl_name 要素が 1 つまたはそれ以上集まったリストです。これにつ
いては、 アドレスマッチリスト の項で述べます。
dotted-decimal
ドット (``.'') だけで区切られた、 1 つまたはそれ以上の数の 0 から 255 までの整数です。 例
えば、 123, 45.67, 89.123.45.67 などです。
domain_name
DNS 名として使用される文字列をクォーテーションで囲んだものです。 例えば、 "my.test.domain"
のようにです。
path_name
パス名として使用される文字列をクォーテーションで囲んだものです。 例えば、
"zones/master/my.test.domain" のようにです。
ip_addr
dotted-decimal 表記でちょうど 4 つの要素からなる IP アドレスです。
ip_port
IP ポートを表す number です。 number は、 0 から 65535 までの値に限定されており、そのうち
1024 以下の値は、 典型的には、所有者が root のプロセスのみに制限されています。 場合によっ
ては、適当に大きな番号を選択するように、穴埋めとしてアスタリスク文字 (``*'') を使うことが
できます。
ip_prefix
dotted-decimal 表記で指定された IP ネットワークです。その後に、``/'' が続き、 そしてネット
マスクのビット数が続きます。 例えば、 127/8 は、 ネットワーク 127.0.0.0 で、ネットマスクは
255.0.0.0 です。 1.2.3.0/28 はネットワーク 1.2.3.0 で、ネットマスクは 255.255.255.240 で
す。
key_name
共有鍵の名前を表した文字列です。 これはトランザクションセキュリティに使用します。
number
C 言語での符号つき整数 (32 ビット整数のマシンでは 2,147,483,647) の範囲全体をとる、非負整
数です。 取り得る値の範囲は、 使用されるコンテキストによってさらに制限されるかもしれませ
ん。
size_spec
number または単語 unlimited か単語 default です。
size_spec の最大値は、マシンの符号なし long 型整数の最大値になります。 unlimited は、値を
無制限に使用できるよう要求したり、 取り得る最大の値を要求したりするために使用します。
default は、サーバが始動したときに有効だった制限が使われます。
number には、次のようなスケールファクタを続けることもできます : K または k はキロバイト
を、 M または m はメガバイトを、そして G または g はギガバイトを表します。 これらはそれぞ
れ、 1024, 1024*1024, 1024*1024*1024 倍であることを表します。
スケールファクタの変換時に、整数値の格納場所でオーバフローが発生しても、 現状では黙って無
視します。 その結果、期待した結果よりも小さな値、おそらくは負の値にさえなってしまいます。
本当に大きな値を安全に設定したいなら unlimited を使うのが最良の方法です。
yes_or_no
yes または no です。あるいは true と false という単語でも受け付けます。 1 と 0 という番号
でも同様です。
アドレスマッチリスト
文法
address_match_list = 1*address_match_element
address_match_element = [ "!" ] ( address_match_list /
ip_address / ip_prefix /
acl_name / "key " key_id ) ";"
定義と使用法
アドレスマッチリストは、 主にいくつかのサーバの操作でのアクセス制御を決定するために使われま
す。 また、アドレスマッチリストは、他のネームサーバに問い合わせる際の優先順位や、 named が問
い合わせを待つアドレスを決定するためにも使われます。 アドレスマッチリストを構成する要素
は、次のうちのどれでもありえます :
• ip-address ( dotted-decimal 表記
• ip-prefix ('/' での表記)
• key ステートメントで定義された key_id
• 先に acl ステートメントで定義されたアドレスマッチリスト名
• 別の address_match_list
要素は、エクスクラメーションマーク (``!'') で始めると無効にできます。 また、アドレスマッチリ
スト名に 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 ステートメント
文法
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.conf(5) マニュアルページに記述があります。 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 つ
があります。どのようにこのチャネルを使うのかに ついては次節 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; # このチャネルに送られたメッセージはみなはじく
};
いったんチャネルが定義されると、再設定はできません。そのため、組み込みの チャネルは直接変更
できないわけです。しかし、定義したチャネルでのカテゴリを 指し示すことによって、デフォルトの
ログ用機能を変更することができます。
category フレーズ
カテゴリはたくさんあります。そのため、見たいと思うログをどこへでも送る ことができ、見たくな
いログは見ないですますことができます。カテゴリに対して チャネルのリストを指定しなかった場合
は、代わりに 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; };
次のようなカテゴリが使用可能です :
default
すべて捕まえます。多くのメッセージがまだカテゴリ分けされておらず、 すべてここで捕まりま
す。さらに、カテゴリに対して何のチャネルも 指定しなかった場合、代わりに default カテゴリが
使われます。default カテゴリを指定しなかった場合、次のような定義が使われます :
category default { default_syslog; default_debug; };
config
ハイレベルの設定ファイル処理です。
parser
ローレベルの設定ファイル処理です。
queries
サーバが受け取った問い合わせそれぞれに対して、短いログメッセージを生成します。
lame-servers
``Lame server on ...'' というようなメッセージです。
statistics
統計です。
panic
サーバ内部の問題でサーバ自体がシャットダウンしなくてはならなくなると、 問題の起きた元のカ
テゴリとこのカテゴリの両方に、 問題をログとして書きこみます。 panic カテゴリを定義していな
い場合には、次のような定義が使われます :
category panic { default_syslog; default_stderr; };
update
動的な更新です。
ncache
ネガティブキャッシングです。
xfer-in
サーバが受け取っているゾーン転送です。
xfer-out
サーバが送っているゾーン転送です。
db
すべてのデータベースの操作です。
eventlib
イベントシステムからのデバッグ情報です。このカテゴリには、ただ 1 つの チャネルが指定で
き、そのチャネルはファイルチャネルでなくてはなりません。 eventlib カテゴリを指定しない場合
は、次のような定義が使われます :
category eventlib { default_debug; };
packet
受け取ったパケットおよび送ったパケットのダンプです。このカテゴリには、 ただ 1 つのチャネル
が指定でき、そのチャネルはファイルチャネルでなくては なりません。packet カテゴリを指定しな
い場合は、次のような定義が使われます :
category packet { default_debug; };
notify
NOTIFY プロトコルです。
cname
``... points to a CNAME'' のようなメッセージです。
security
許可された / 許可されなかったリクエストです。
os
オペレーティングシステムの問題です。
insist
内部の整合性チェックの失敗です。
maintenance
定期的に行われるメンテナンスのイベントです。
load
ゾーンへのロードメッセージです。
response-checks
応答のチェックから発生するメッセージです。例えば、 ``Malformed response ...'', ``wrong
ans. name ...'', ``unrelated additional info ...'', ``invalid RR type ...'', ``bad
referral ...'' といったものです。
options ステートメント
文法
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 ブロックが 使
われます。
パス名
version
ndc コマンドの問い合わせや chaos クラスの version.bind 名の問い合わせを通してサーバがレ
ポートするべきバージョンです。 デフォルトではサーバの本当のバージョン番号になっています
が、 サーバのオペレータの中にはこの文字列の方が好みという人もいます ( もちろん冗談に決まっ
ていますが )。
directory
サーバの作業ディレクトリです。設定ファイル中の絶対パスでない パス名は、どんなものでもこの
ディレクトリからの相対パスと受け取られます。 大部分のサーバの出力ファイル (例えば、
named.run) のデフォルトの置き場所は、このディレクトリです。もし、ディレクトリの指定が なけ
れば、作業ディレクトリはデフォルトで ~. になります。このディレクトリは、サーバが起動した
ディレクトリです。 指定されたディレクトリは絶対パスでなくてはいけません。
named-xfer
内部へのゾーン転送用にサーバが使用する named-xfer プログラムへのパス名です。 指定されてい
ない場合のデフォルトは、システム依存です (例えば、 /usr/sbin/named-xfer です)。
dump-file
SIGINT シグナルをサーバが受け取ったとき ( ndc dumpdb が送った場合のように) に、 データベー
スのダンプを落とすファイルへのパス名です。 指定されていない場合のデフォルトは、
named_dump.db です。
memstatistics-file
deallocate-on-exit が yes になっている場合に、 サーバが終了時にメモリ使用統計を書き出す
ファイルへのパス名です。 指定されていない場合のデフォルトは、 named.memstats です。
pid-file
サーバが自分のプロセス ID を書き出すファイルへのパス名です。 指定されていない場合のデフォ
ルトは、オペレーティングシステムに 依存しますが、通常は、 /var/run/named.pid あるいは
/etc/named.pid です。 pid-file は、 ndc のような、動作しているネームサーバにシグナルを送り
たい プログラムが使用します。
statistics-file
サーバが SIGILL シグナルを ( ndc stats から) 受け取った場合に、統計を追加書き込みするファ
イルへのパス名です。 指定されていない場合のデフォルトは、 named.stats です。
ブール値のオプション
auth-nxdomain
これが yes の場合、 AA ビットは、常に NXDOMAIN の応答にセットされます。たとえサーバが実際
には信頼できるものでは なくてもです。 デフォルトでは、 yes になっています。 古くからあるソ
フトウェアが嫌うので、 自分のしていることに確信が持てないでいるのであれば、 auth-nxdomain
をオフにしてはいけません。
deallocate-on-exit
これが yes の場合には、サーバは、終了時に自分が確保したオブジェクトを 徹底して開放して、
memstatistics-file にメモリ使用レポートを書き出します。 デフォルトでは、 no になっていま
す。なぜなら、オペレーティングシステムにクリーンアップを やらせたほうが高速だからです。
deallocate-on-exit は、メモリリークを検出するために便利です。
dialup
これが yes の場合には、サーバは、すべてのゾーンを、 要求時ダイヤルによるダイヤルアップリン
クを通して ゾーン転送を行っているかのように扱います。 このダイヤルアップリンクは、このサー
バから通信が始まった場合に 立ち上げられるものです。 これは、ゾーンの種類によって異なる効果
をもたらし、ゾーンの保守に 専念できるようになります。これによって、 heartbeat-interval ご
とに 1 度、願わくは、1 回の呼び出しの間という短い間隔で ゾーンの保守を行えるようになりま
す。 このオプションはまた、通常のゾーン保守にかかるトラフィックを いくらか抑えることもでき
ます。 デフォルトは、 no です。 dialup オプションは、 zone ステートメント中でも指定するこ
とができます。この場合は、 options dialup ステートメントは上書きされます。
ゾーンが master である場合、 サーバは、すべてのスレーブに対して NOTIFY リクエストを送信す
るようになります。 これによって、スレーブをチェックし、呼び出しが生きている間に スレーブが
ゾーンを検証できるようにすることで、 ゾーンを最新のものにする契機ができます (サーバが
NOTIFY をサポートする場合です)。
ゾーンが slave もしくは stub である場合、 サーバは、通常のゾーンのアップデート問い合わせを
抑制し、 heartbeat-interval が時間切れになったときだけ問い合わせるようにします。
fake-iquery
これが yes の場合、 サーバは、 IQUERY という、もう古くなって使われていない DNS 問い合わせ
をシミュレーション します。 デフォルトは no です。
fetch-glue
これが yes の場合 (デフォルトではそうです)、サーバは、追加の応答用データセクションを 作る
際には持っていない「糊」となるリソースレコードを取得します。 サーバのキャッシュが大きく
なったり、破壊されたりしないようにするため (こうなると、クライアントからもっと多くの仕事を
要求されるという 代償を払うことになります)、 fetch-glue no は、 recursion no と一緒に使用
できます。
has-old-clients
このオプションを yes に設定することと、次の 3 つのオプションを設定することとは等価です :
auth-nxdomain yes ;, maintain-ixfr-base yes ;, rfc2308-type1 no; has-old-clients を
auth-nxdomain, maintain-ixfr-base, rfc2308-type1 と一緒に使用することで起こることは、指定
の順番によります。
host-statistics
これが yes である場合、 ネームサーバと相互に作用する各ホストに対して統計が保持されます。
デフォルトでは no です。 注: host-statistics をオンにすると、膨大な量のメモリを消費する可
能性があります。
IC host-statistics-max
保持する最大のホストレコード数です。 この限界に達っすると、ホストの統計情報に新規ホストは
追加されません。 0 に設定すると、限界はありません。 デフォルト値は 0 です。
maintain-ixfr-base
これが yes の場合、すべての動的に更新されるゾーンに対して、 単一の IXFR データベースファイ
ルが保持されます。 これを有効にすると、 ゾーン転送を非常に高速化可能な IXFR 問い合わせ
に、サーバは答えます。 デフォルトは no です。
multiple-cnames
これが yes である場合、 1 つのドメイン名について複数の CNAME リソースレコードか許可されま
す。 デフォルトは no です。複数の CNAME レコードを許可するということは、標準からは 外れて
おり、推奨されることではありません。 以前のバージョンの BIND が複数の CNAME レコードを持つ
ことを許しており、 このレコードがいくつかのサイトでは負荷のバランスを取るために 使用されて
いたことから、複数の CNAME のサポートを利用できるということです。
notify
これが yes である場合 (それがデフォルトです)、 変更を行うためにゾーンサーバが信頼できる場
合に DNS NOTIFY メッセージを 送るようになります。 NOTIFY を使用すると、マスタサーバとその
スレーブとの間の収束が 早まります。NOTIFY メッセージを受け取り、理解するスレーブサーバは
そのゾーン用にマスタサーバに接続し、ゾーン転送を行う必要があるかを 点検します。そして、必
要がある場合は直ちにゾーン転送を開始します。 notify オプションは zone ステートメント内でも
指定できます。この場合は、 options notify ステートメントは上書きされます。
recursion
これが yes であり、 DNS の問い合わせが再帰処理を要求している場合、 サーバはその問い合わせ
に答えるために必要な仕事をすべて行おうとします。 recursion がオンになっていない場合、サー
バが答えを 知らない場合は、サーバはクライアントに照会を返します。デフォルトでは、 yes で
す。前述の fetch-glue も参照してください。
rfc2308-type1
これが yes であれば、サーバは、否定応答用に SOA レコードと一緒に NS レコードを 送りま
す。もし、古い BIND サーバを持っていて、 SOA と NS の両方を含んだ否定応答を理解しないフォ
ワード用サーバとして使用して いる場合や、古いバージョンの sendmail を持っている場合は、こ
の オプションを no に設定する必要があります。正しい解決策は、 そういう壊れたサーバや
sendmail を使用しないことです。デフォルトでは、 このオプションは no です。
use-id-pool
これが yes であれば、サーバは自分自身の未解決の問い合わせ ID を追跡して、 重複を避け、ラン
ダム性を高めるようにします。これによって、 サーバが 128 KB も多くメモリを消費するようにな
ります。 デフォルトは no です。
treat-cr-as-space
これが yes の場合、 サーバは、スペースやタブを扱うのと同じ方法で CR 文字を扱うように なり
ます。NT あるいは DOS マシンで生成したゾーンファイルを UNIX システム上にロードするとき
に、このオプションは必要でしょう。 デフォルトでは、このオプションは no です。
Also-Notify
also-notify
ゾーンの新しいコピーがロードされるときはいつでも送信された NOTIFY メッセージも受け取る IP ア
ドレスのグローバルリストを定義します。 このオプションは、ゾーンのコピーが素早く「内密
の」サーバ上で確実に収束 する助けになります。 also-notify リストが zone ステートメントで与え
られた場合、 options also-notify ステートメントは上書きされます。 zone notify ステートメント
が no に設定されている場合、 グローバルの also-notify リストの IP アドレスは、このゾーンに対
する NOTIFY メッセージを 送信されません。デフォルトでは、このリストは空です (グローバルな
notification リストはないということです)。
フォワード
フォワード機能は、少数のサーバ上で大きなサイト単位のキャッシュを作成する ために使用すること
ができます。これによって、外部のネームサーバへの リンクを越えたトラフィックを軽減できま
す。フォワード機能は、直接 インターネットに接続できないが、ともかく外部のホスト名を見つけ出
したい というサーバの問い合わせを許可するためにも使用できます。 フォワードが発生するのは、そ
うした問い合わせに対してサーバが 権限を持たず、キャッシュにその応答が入っていない場合だけで
す。
forward
このオプションは、 forwarders リストが空でない場合にだけ意味があります。 first という値が
デフォルトですが、このときサーバは、まずフォワードを行うサーバに 問い合わせを行い、フォ
ワードを行うサーバが要求に対して応答しない場合、 自分で応答を探します。 only が指定された
場合、サーバは、ただフォワードを行うサーバに問い合わせを 行うだけです。
forwarders
フォワードを行うために使用される IP アドレスを指定します。デフォルトでは、 これは空のリス
トです (フォワードを行いません)。
フォワード機能は、ゾーン単位をもとにして設定することもできます。 このときは、グローバルの
フォワード用オプションが、さまざまな方法で 上書きできるようになります。 特定のゾーンに対し、
別のフォワード用サーバを使用したり、別の forward only/first の振るまいをもたせたり、あるいは
まったくフォワードしなかったり できます。 さらなる情報については、 ゾーンステートメント のセ
クションを参照してください。
BIND 8 の将来のバージョンでは、もっと強力なフォワード用システムを 提供する予定です。先に述べ
た文法は引き続きサポートされる予定です。
ネームチェック
サーバは、期待するクライアントの関係に基づいてドメイン名をチェックできます。 例えば、ホスト
名として使用されるドメイン名は、正当なホスト名を 定義している RFC に準拠するかという点で
チェックされます。
チェック方法には 3 通りのやり方が利用可能です :
ignore
何のチェックも行われません。
warn
期待するクライアントの関係から名前をチェックします。不正な名前は ログに書かれますが、処理
は普通に継続します。
fail
期待するクライアントの関係から名前をチェックします。不正な名前は ログに書かれ、ルールに合
わないデータは拒否されます。
サーバは、名前を 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 アドレス または共有秘密鍵に基づいて制
限することができます。 アクセス基準をどのように指定するかについての詳細は、 アドレスマッチリ
スト を参照してください。
allow-query
どのホストが通常の問い合せをすることができるかを指定します。 allow-query は、 zone ステー
トメントでも指定できます。この場合、 options allow-query ステートメントを上書きします。も
し、allow-query オプションが 指定されていない場合は、デフォルトは、 すべてのホストからの問
い合わせを許可します。
allow-recursion
どのホストが再帰的な問い合わせが可能かを指定します。 指定されていない場合は、 デフォルト
では全てのホストから再帰的な問い合わせができます。
allow-transfer
どのホストがゾーン転送をサーバから受け取ることを許可されるかを 指定します。
allow-transfer は、 zone ステートメントでも指定できます。その場合、 options
allow-transfer ステートメントは上書きされます。もし、allow-transfer オプションが 指定さ
れていない場合は、デフォルトでは、 すべてのホストからの転送を許可します。
blackhole
サーバが問い合わせを受け取らないようになったり、問い合わせを解決するために 使用しないよ
うになるアドレスのリストを指定します。これらのアドレスからの 問い合わせは、応答されるこ
とはありません。
インタフェース
サーバが問い合わせに答えるインタフェースならびにポートは、 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 アドレスとランダムに選ばれた 特権のいらないポートが使用されます。
ゾーン転送
max-transfer-time-in
ここで指定された時間より長く動作している内部へのゾーン転送 ( named-xfer プロセス) を終了し
ます。 デフォルトでは、120 分 (2 時間) です。
transfer-format
サーバは 2 種類のゾーン転送方法をサポートしています。 one-answer 転送されるリソースレコー
ドそれぞれについて 1 つの DNS メッセージを使用します。 many-answers できるだけ多くのリソー
スレコードを 1 つのメッセージに押し込みます。 many-answers の方が効率的ではあります
が、BIND 8.1 および、パッチの当たった BIND 4.9.5 でのみ 理解されるものです。デフォルトで
は、 one-answer になります。 transfer-format は、 server ステートメントを使用してサーバ単
位で上書きすることができます。
transfers-in
同時に動作させることのできる内部へのゾーン転送の最大値です。 デフォルトは 10 です。
transfers-in の数を増やすと、スレーブのゾーンの収束が早まりますが、ローカルシステムの負荷
も 上がってしまう恐れがあります。
transfers-out
このオプションは、将来、 同時に動作する外部へのゾーン転送数を制限するために使用する 予定で
す。現在、文法はチェックしていますが、それ以上のことは無視しています。
transfers-per-ns
あるリモートのネームサーバから同時に実行できる内部へのゾーン転送 ( named-xfer プロセス) の
最大値です。デフォルトは 2 です。 transfers-per-ns の数を増やすと、スレーブゾーンの収束は
早まりますが、リモートのネームサーバの 負荷が上がってしまう恐れがあります。
transfers-per-ns は、 server ステートメントの transfers フレーズを使用してサーバ単位で上書
きすることができます。
transfer-source
transfer-source は、サーバが内部に転送するゾーンをすべて取得するために使用される TCP コネ
クションと どのローカルアドレスとが結びつけられるかを決定します。 これが設定されていない場
合、 システムが制御しているデフォルト値に設定されます。 この値は、通常、 リモート側の終端
に「最も近い」インタフェースのアドレスになります。 このアドレスは、もし指定されているのな
ら、リモート側の終端の転送ゾーン用の allow-transfer オプションで登場していなくてはなりませ
ん。 このステートメントは、すべてのゾーンの transfer-source を設定しますが、設定ファイル中
のゾーンブロック内に transfer-source ステートメントを含めることでゾーン単位で上書きするこ
とができます。
リソースの制限
多種のシステムリソースをサーバがどこまで使用してよいか制限可能です。 オペレーティングシステ
ムによっては、 この制限をいくつかサポートしていないものもあります。 そうしたシステムでは、サ
ポートされていない制限を使用すると警告が発生します。 また、オペレーティングシステムによって
は、 リソース制限自体をサポートしていないものも あります。そうしたシステムでは、
cannot set resource limits on this system
というメッセージがログに記録されます。
リソース制限を指定する際には、スケールを変えた値を使用することができます。 例えば、1 ギガバ
イトの制限を指定したい場合に、 1G を 1073741824 の代わりに使用することができます。 unlimited
は、無制限にリソースを使用する、 つまり、利用可能な最大の量のリソースを要求します。 default
は、サーバが開始したときに有効だった制限値を使用します。 詳細については、 記述方法の定義 の
セクションの size_spec の項を参照してください。
coresize
コアダンプの最大サイズです。デフォルト値は default です。
datasize
サーバが使用できるデータメモリの最大領域です。デフォルト値は default です。
files
サーバが同時にオープンできるファイルの最大数です。デフォルト値は unlimited です。オペレー
ティングシステムによっては、unlimited という値を設定できず、 カーネルがサポートできるオー
プンするファイルの最大値を 決定できないものがあることに 注意してください。こうしたシステム
では、 unlimited を選択すると、サーバが getrlimit(RLIMIT_NOFILE) から得られる rlim_max の
値よりも大きなファイル数を扱ってしまい、 sysconf(_SC_OPEN_MAX) を返してしまうことになりま
す。 実際のカーネルの制限値がこの値よりも大きい場合は、 limit files を使用して、明示的に制
限値を指定してください。
max-ixfr-log-size
max-ixfr-log-size は、将来のサーバのリリースでは、インクリメンタルゾーン転送用に保持してお
く トランザクションログの大きさに制限を設けるために使用する予定です。
stacksize
サーバが使用できるスタックメモリの最大量です。デフォルト値は default です。
定期的なタスクの間隔
cleaning-interval
サーバは、 cleaning-interval 分ごとに期限の切れたリソースレコードをキャッシュから削除しま
す。 デフォルトは 60 分です。これが 0 に設定されているときは、 定期的にキャッシュがクリー
ニングされることはありません。
heartbeat-interval
サーバは、この間隔が過ぎればいつでも dialup yes の印のついたゾーンすべてに対してゾーン管理
タスクを実行します。 デフォルトでは 60 分です。適切な値は 1 日 (1440 分) までです。 この値
が 0 に設定されている場合、 これらのゾーンに対するゾーン管理は実行されません。
interface-interval
サーバは、 interface-interval 分ごとにネットワークインタフェースリストをスキャンします。
デフォルトでは 60 分です。 この値が 0 に設定されている場合、 インタフェースのスキャンを行
うのは、設定ファイルが ロードされたときだけです。スキャンした後、待機タスク (listener)
は、どの 新しいインタフェース上でも始動します (そのタスクが listen-on の設定がされていて許
可されている場合です)。 取り除かれたインタフェース上で動作している待機タスクは、消去されま
す。
statistics-interval
ネームサーバの統計が statistics-interval 分ごとにログに記録されます。デフォルトは 60 で
す。 この値が 0 に設定されている場合、 何の統計も記録されません。
トポロジ
ネームサーバのリストから問い合わせ先のネームサーバをサーバが 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 の順番付け
応答中に複数のレコードが返されている場合、 その応答中にレコードがどの順番で置かれるかを 設定
するのが有益なことがあります。 例えば、あるゾーンに対するレコードは、ゾーンファイルで 定義さ
れた順番で常に返されるように設定されるかもしれません。 あるいは、 レコードが返されるときにラ
ンダムにシャッフルされるようにしたいということも あるでしょう。 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 ; };
が使われます。
チューニング
lame-ttl
不完全なサーバの指示をキャッシュしておく秒数を設定します。 0 の場合、キャッシュしません。
デフォルトは 600 (10 分) です。最大値は 1800 (30 分) です。
max-ncache-ttl
ネットワークの負荷を軽減しパフォーマンスを上げるために、 サーバが否定応答を蓄えます。
max-ncache-ttl は、サーバで、このような応答の最大保存時間を設定するために使います。 秒単位
です。 デフォルトの max-ncache-ttl は 10800 秒 (3 時間) です。 max-ncache-ttl 通常の (肯
定) 応答に対しては、最大保存時間を超えてはいけません (7 日)。 もし、この値が 7 日以上に設
定されていた場合、 黙って 7 日に切り詰めてしまうでしょう。
min-roots
ルートサーバに対する要求を受け取るために必要なルートサーバの最小値です。 デフォルトは 2 で
す。
zone ステートメント
文法
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 つの種類があります。
master
サーバは、 そのゾーン用データのマスタコピーを持っていて、ゾーンに対して信頼できる 応答を提
供できます。
slave
slave ゾーンはマスタゾーンの複製です。 masters リストは、ゾーンの複製を更新するためにス
レーブサーバが通信を行う 1 つ以上の IP アドレスを指定します。 port が指定されている場
合、このポートに対し、 ゾーンが現在使用されているものであることの確認と、 ゾーン転送が行わ
れます。 file が指定されている場合、 指定されたファイルへゾーンの複製が書き出されます。
file 節を使用することを強く勧めます。 なぜなら、大体においてサーバの起動を早めますし、 通
信回線を無駄に使用することを防いでくれるからです。
stub
stub ゾーンは slave ゾーンのようなものですが、ゾーン全体を複製するのではなく、 マスタゾー
ンの NS レコードのみを複製するという点が違います。
forward
forward ゾーンは、自分に向けられた問い合わせを他のサーバに振り分けるために使用します。 こ
のことは、 option ステートメント のセクションで説明しています。これらのゾーンでのオプショ
ン仕様は、 options ステートメントで宣言されたグローバルオプションを上書きします。
forwarders 節が zone ステートメント中に存在しないか、もしくは、 forwarders に対して空リス
トが与えられている場合は、 そのゾーンに対してフォワードは行われず、 options ステートメント
中の forwarders は、すべて効力を失います。そのため、使用されるサーバではなく、グローバルの
forward オプションの挙動を変更するためだけにこの種類のゾーンを使用したいのであれば、 グ
ローバルの forwarders 節も指定しなおす必要があります。
hint
ルートネームサーバの初期集合は、 hint ゾーンを使用して指定されます。サーバが起動する際
に、ルートヒントを使用して ルートネームサーバを見つけ、ルートネームサーバの最新リストを取
得します。
注 : 以前の 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 クラスを使用して指定できます。
オプション
check-names
options ステートメント の ネームチェック に関するサブセクションを参照してください。
allow-query
options ステートメント の アクセス制御 サブセクションの中の allow-query に関する説明を参照
してください。
allow-update
どのホストが動的な DNS の更新をサーバに提出するかを指定します。デフォルトは、 どのホストか
らも更新を許可しないというものです。
allow-transfer
options ステートメント の アクセス制御 サブセクションの中の allow-transfer に関する説明を
参照してください。
transfer-source
transfer-source どのローカルアドレスが、 このゾーンを取得するために使用される TCP 接続と結
びつけられるかを 指定します。 これが設定されていない場合は、システムが制御する値がデフォル
トになります。 この値は、通常は、リモート側の終端に「最も近い」インタフェースのアドレスで
す。 このアドレスは、 もし指定されているのであれば、このゾーンに対するリモート側の終端の
allow-transfer オプション中に出てこなくてはなりません。
max-transfer-time-in
options ステートメント の ゾーン転送 サブセクション中の max-transfer-time-in の説明を参照
してください。
dialup
options ステートメント の ブール値オプション サブセクション中の dialup の説明を参照してく
ださい。
notify
options ステートメント の ブール値オプション サブセクション中の notify の説明を参照してく
ださい。
also-notify
notify がこのゾーンに対してアクティブである場合のみ also-notify は意味を持ちます。 この
ゾーンに対する DNS NOTIFY メッセージを受け取るマシン群は、 そのゾーン用にリストされた すべ
てのネームサーバ (プライマリマスタを除く) と、 also-notify で指定された IP アドレスから
なっています。 also-notify は stub ゾーンに対しては意味を持ちません。デフォルトでは、これ
は空のリストです。
forward
forward は、そのゾーンが forwarders リストを持っている場合のみ意味を持ちます。 only 値
は、先に forwarders を試し、応答がなかった場合に検索を失敗させます。 それに対し、 first
は、通常の検索を許可します。
forwarders
ゾーン中で forwarders オプションを使用すると、グローバルの forwarders リストが上書きされま
す。 forward タイプのゾーン中でこれが指定されていなかった場合は、 このゾーンに対しては 何
の フォワードも行いません。グローバルのオプションは使われないということです。
pubkey
DNSSEC のフラグ、プロトコル、アルゴリズムと、 base-64 でエンコードされた鍵を表す文字列を指
定します。
acl ステートメント
文法
acl name {
address_match_list
};
定義と使用法
acl ステートメントは、名前のついたアドレスマッチリストを生成します。 このステートメント
は、プライマリで使用しているアドレスマッチリスト、つまり、 アクセス制御リスト (ACL) からその
名前を取得します。
アドレスマッチリスト名は、他のところで使用する前に acl を使用して定義しなくてはなりませ
ん。ファイルの前方への参照は許されていません。
次のような組み込みの ACL があります :
any
すべてのホストを許可します。
none
すべてのホストを拒否します。
localhost
システム上のすべてのインタフェースの IP アドレスを許可します。
localnets
システムがインタフェースを持ったネットワーク上のすべてのホストを許可します。
key ステートメント
文法
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 ステートメント
文法
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 ステートメント
文法
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 ステートメント
文法
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 ステートメント
文法
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";
};
ファイル
/etc/namedb/named.conf
BIND 8 named 設定ファイル
関連項目
named(8), ndc(8)