NAMED.CONF(5) | File Formats Manual | NAMED.CONF(5) |
named.conf
named(8)
—
用の設定ファイル
BIND 8 は、以前のリリースと比べて遥かに設定可能なものになっています。 完全に新しい設定項目があります。例えばアクセス制御リストやカテゴリ別の ログなどです。以前はゾーンすべてに対して適用されていたオプションの多くが、 選択的に使えるようになっています。 こうした機能に加え、 将来必要とされる設定がどのようなものになるかをよく考えた結果、 新たに設定ファイルのフォーマットを作ることにしました。
BIND 8 の設定には、一般的な特徴が 2 つあります。 それは、ステートメントとコメントです。 ステートメントはすべてセミコロンで終わります。ステートメントの多くは サブステートメントを持っており、サブステートメントもセミコロンで終わります。
次のようなステートメントをサポートしています :
logging
options
zone
acl
key
trusted-keys
server
controls
ndc
ユーティリティが使用する制御チャネルを宣言します。
include
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 つのステートメントとしか結びつかない要素は、その ステートメントについて述べているセクションにだけ記述があります。
acl
ステートメントで定義される
address_match_list
の名称です。
123
,
45.67
, 89.123.45.67
などです。
my.test.domain
"
のようにです。
zones/master/my.test.domain
"
のようにです。
0
から 65535
までの値に限定されており、そのうち
1024 以下の値は、
典型的には、所有者が
root
のプロセスのみに制限されています。
場合によっては、適当に大きな番号を選択するように、穴埋めとしてアスタリスク文字
(``*'')
を使うことができます。
127/8
は、 ネットワーク
127.0.0.0
で、ネットマスクは
255.0.0.0
です。
1.2.3.0/28
はネットワーク
1.2.3.0
で、ネットマスクは
255.255.255.240
です。
unlimited
か単語
default
です。
size_spec
の最大値は、マシンの符号なし
long
型整数の最大値になります。
unlimited
は、値を無制限に使用できるよう要求したり、
取り得る最大の値を要求したりするために使用します。
default
は、サーバが始動したときに有効だった制限が使われます。
number
には、次のようなスケールファクタを続けることもできます
: K
または
k
はキロバイトを、
M
または
m
はメガバイトを、そして
G
または
g
はギガバイトを表します。
これらはそれぞれ、
1024, 1024*1024, 1024*1024*1024
倍であることを表します。
スケールファクタの変換時に、整数値の格納場所でオーバフローが発生しても、
現状では黙って無視します。
その結果、期待した結果よりも小さな値、おそらくは負の値にさえなってしまいます。
本当に大きな値を安全に設定したいなら
unlimited
を使うのが最良の方法です。
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
が問い合わせを待つアドレスを決定するためにも使われます。
アドレスマッチリストを構成する要素は、次のうちのどれでもありえます
:
key
ステートメントで定義された
key_idacl
ステートメントで定義されたアドレスマッチリスト名要素は、エクスクラメーションマーク
(``!'')
で始めると無効にできます。
また、アドレスマッチリスト名に
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/24
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; # このチャネルに送られたメッセージはみなはじく };
いったんチャネルが定義されると、再設定はできません。そのため、組み込みの チャネルは直接変更できないわけです。しかし、定義したチャネルでのカテゴリを 指し示すことによって、デフォルトのログ用機能を変更することができます。
カテゴリはたくさんあります。そのため、見たいと思うログをどこへでも送る
ことができ、見たくないログは見ないですますことができます。カテゴリに対して
チャネルのリストを指定しなかった場合は、代わりに
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
category default {
default_syslog; default_debug; };
config
parser
queries
lame-servers
statistics
panic
category panic { default_syslog;
default_stderr; };
update
ncache
xfer-in
xfer-out
db
eventlib
category eventlib {
default_debug; };
packet
category packet { default_debug;
};
notify
cname
security
os
insist
maintenance
load
response-checks
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
もちろん冗談に決まっていますが
)。
directory
named-xfer
dump-file
SIGINT
シグナルをサーバが受け取ったとき
( ndc dumpdb
が送った場合のように)
に、
データベースのダンプを落とすファイルへのパス名です。
指定されていない場合のデフォルトは、
named_dump.db です。
memstatistics-file
deallocate-on-exit
が yes
になっている場合に、
サーバが終了時にメモリ使用統計を書き出すファイルへのパス名です。
指定されていない場合のデフォルトは、
named.memstats です。
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
をオンにすると、膨大な量のメモリを消費する可能性があります。
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
ゾーンの新しいコピーがロードされるときはいつでも送信された
NOTIFY
メッセージも受け取る
IP
アドレスのグローバルリストを定義します。
このオプションは、ゾーンのコピーが素早く「内密の」サーバ上で確実に収束
する助けになります。
also-notify
リストが
zone
ステートメントで与えられた場合、
options also-notify
ステートメントは上書きされます。
zone notify
ステートメントが
no
に設定されている場合、
グローバルの
also-notify
リストの IP
アドレスは、このゾーンに対する
NOTIFY メッセージを
送信されません。デフォルトでは、このリストは空です
(グローバルな notification
リストはないということです)。
フォワード機能は、少数のサーバ上で大きなサイト単位のキャッシュを作成する ために使用することができます。これによって、外部のネームサーバへの リンクを越えたトラフィックを軽減できます。フォワード機能は、直接 インターネットに接続できないが、ともかく外部のホスト名を見つけ出したい というサーバの問い合わせを許可するためにも使用できます。 フォワードが発生するのは、そうした問い合わせに対してサーバが 権限を持たず、キャッシュにその応答が入っていない場合だけです。
forward
forwarders
リストが空でない場合にだけ意味があります。
first
という値がデフォルトですが、このときサーバは、まずフォワードを行うサーバに
問い合わせを行い、フォワードを行うサーバが要求に対して応答しない場合、
自分で応答を探します。
only
が指定された場合、サーバは、ただフォワードを行うサーバに問い合わせを
行うだけです。
forwarders
フォワード機能は、ゾーン単位をもとにして設定することもできます。
このときは、グローバルのフォワード用オプションが、さまざまな方法で
上書きできるようになります。
特定のゾーンに対し、
別のフォワード用サーバを使用したり、別の
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
one-answer
転送されるリソースレコードそれぞれについて
1 つの DNS
メッセージを使用します。
many-answers
できるだけ多くのリソースレコードを
1
つのメッセージに押し込みます。
many-answers
の方が効率的ではありますが、BIND
8.1
および、パッチの当たった
BIND 4.9.5 でのみ
理解されるものです。デフォルトでは、
one-answer
になります。
transfer-format
は、
server
ステートメントを使用してサーバ単位で上書きすることができます。
transfers-in
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
ステートメントを含めることでゾーン単位で上書きすることができます。多種のシステムリソースをサーバがどこまで使用してよいか制限可能です。 オペレーティングシステムによっては、 この制限をいくつかサポートしていないものもあります。 そうしたシステムでは、サポートされていない制限を使用すると警告が発生します。 また、オペレーティングシステムによっては、 リソース制限自体をサポートしていないものも あります。そうしたシステムでは、
リソース制限を指定する際には、スケールを変えた値を使用することができます。
例えば、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-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
max-ncache-ttl
max-ncache-ttl
は、サーバで、このような応答の最大保存時間を設定するために使います。
秒単位です。
デフォルトの
max-ncache-ttl
は 10800 秒 (3
時間) です。
max-ncache-ttl
通常の
(肯定)
応答に対しては、最大保存時間を超えてはいけません
(7 日)。
もし、この値が 7
日以上に設定されていた場合、
黙って 7
日に切り詰めてしまうでしょう。min-roots
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
allow-query
allow-query
に関する説明を参照してください。
allow-update
allow-transfer
allow-transfer
に関する説明を参照してください。
transfer-source
transfer-source
どのローカルアドレスが、
このゾーンを取得するために使用される
TCP
接続と結びつけられるかを
指定します。
これが設定されていない場合は、システムが制御する値がデフォルトになります。
この値は、通常は、リモート側の終端に「最も近い」インタフェースのアドレスです。
このアドレスは、
もし指定されているのであれば、このゾーンに対するリモート側の終端の
allow-transfer
オプション中に出てこなくてはなりません。
max-transfer-time-in
max-transfer-time-in
の説明を参照してください。
dialup
dialup
の説明を参照してください。
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
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"; };
named
設定ファイルJanuary 7, 1999 | BSD 4 |