Provided by: manpages-ja_0.5.0.0.20110915-1_all bug

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)