options – variable options
attach-cache
options {
[ attach-cache cache_name; ]
};
ひとつのキャッシュに対して複数のviewからデータを参照する設定ができます。デフォルトでは各view単位でキャッシュを持つことになりますが、同じポリシーで作成されたviewならば、このオプションでメモリやキャッシュ効率の向上が期待できます。
attach-cacheオプションは各view内でも記述でき、グローバルのattach-cache設定を上書きします。
キャッシュ名は共有キャッシュの名前を定義します。Bindがキャッシュを共有する設定を入れた場合には最初のviewでキャッシュが生成されて、残りのviewは単にそのキャッシュデータを参照します。これは1個のキャッシュを複数viewで参照する設定で、設定的にはoptionsの中でattach-cache設定をした場合にこのような動作になります。
もうひとつの設定は、あるviewが他のviewのキャッシュを参照するという設定です。例えばA・B・Cという3個のviewがあり、AとBがキャッシュを共有するには以下のように設定します。
view "A" {
// this view has its own cache
...
};
view "B" {
// this view refers to A’s cache
attach-cache "A";
};
view "C" {
// this view has its own cache
...
};
キャッシュを共有するviewは設定ファイル上で同じようになっていないといけない。以下に上げる項目がキャッシュを共有する同一ポリシーのview無いで同じように設定されていなければいけない。
- check-names
- cleaning-interval
- dnssec-accept-expired
- dnssec-validation
- max-cache-ttl
- max-ncache-ttl
- max-cache-size
- zero-no-soa-ttl
違うview間でキャッシュ共有するのに、同じになっていなくてもいいのかな？という項目は他にもある。例えば、事なるforwarderが設定されていて、同じリクエストに対して異なる回答が返るような場合などがそれにあたるが、回答が同じになることは道理に合わないし、むしろ害がある。
これらは管理者の責任において、ポリシーとキャッシュ設定内容が食い違わないように気を付けないといけない。
directory
サーバがデータを置くメインのディレクトリを指定する。絶対パスで指定されていない設定項目についてはここが起点になる。
デフォルトのパスは.（ドットで、カレントディレクトリ）で、namedが起動されたディレクトリになる。ここの設定は絶対パスで指定すべき。
key-directory
DNS-SECを実行する時に必要なパブリックキーやプライベートキーを置いておくディレクトリを指定する。カレントディレクトリと違う場所に指定。DNS-SEC以外のキー（bind.keys/rndc.key/session.key）には関係ないです。
managed-keys-directory
管理用キーが置いてあるディレクトリを指定する。デフォルトはカレントディレクトリ。managed-keys.bindファイルを用意していない場合、view名をSHA256ハッシュして作った文字列に .mkeys の拡張子を付けたファイルになります。
named-xfer
これは廃止されたオプションです。Bind8時代にnamed-xferプログラムの場所を指定するのに使われてました。Bind9ではnamed-xferはnamedに組み込まれたため必要なくなりました。
tkey-gssapi-keytab
GSS-TGS更新用のケルベロスkeytabファイルの指定。この設定（tkey-gssapi-keytab）が指定されていて、tkeygssapi-credentialが設定されていない場合、keytabで指定されたkeyでの全ての更新が有効になる。
tkey-gssapi-credential
サーバがGSS-TSIGプロトコルによる認証を行う場合に要求するセキュリティ要件。現在はKerberos5ん認証が利用可能で、システムのデフォルトとして一般的に /etc/krb5.keytab の準備が必要。keytab置き場は tkey-gssapi-keytab で変更可能。一般的には「DNS/server.domain」という形。tkey-gsspai-keytabの設定が無い状態でGSS-TSIGを使うにはtkeydomain の設定も必要。
tkey-domain
ドメインに付与された、TKEY生成された共有キーの名前。クライアントがTKEY交換を要求してきた場合、キーも要求してくるかもしれない。もしキーを提示した場合、共有キー名はクライアント指定の文字列＋tkey-domainになる。そうでない場合にはランダムの16進数＋tkey-domainという名前になる。多くの場合はドメイン名はサーバのドメイン名か、存在しないサブドメイン（tkey.domainnameなど）にすべき。
GSS-TSIGを使う場合にはtkey-domainは必ず設定しましょう。もしくは、tkey-gssapi-keytabを使ったkeytabを使いましょう。
tkye-dhkey
TKEYモードのDiffie-Hellmanキーを使用しているクライアントに対してここで指定したキーが使用されます。サーバではPrivateキーとPublicキーの両方を読み込む必要があります。キーの名前はサーバのホスト名が使用されることが多いです。
cache-file
テストのみで使用します。使わないように。
dump-file
ここで指定したレコードタイプ順にAdditional SectionのGlueが並べられる。デフォルトは指定なし。（NONE）
memstatistics-file
サーバ（named）が終了時にメモリ使用状況の統計情報を書き出すファイルを指定します。デフォルトは named.memstats です。
pid-file
サーバがnamedのプロセスIDを書き出すファイル名を指定します。デフォルトは /var/run/named/named.pid です。プロセスIDが記載されたファイルは、デーモンに対してシグナルを送信したいプログラムがプロセスIDを参照する場合に使用します。
pid-fileにnoneを指定するとPIDファイルの出力をしなくなり、すでにPIDファイルが存在した場合、そのファイルを削除します。noneはキーワードなのでファイル名でないのでダブルクォート等で囲む必要ナシ。
recursing-file
namedが現在再帰問い合わせをしているクエリを出力するファイルを指定する。出力トリガーは rndc recursing の実行です。デフォルトは named.recusing 。
statistics-file
rndc statsを実行した時にnamedが統計情報を出力するファイルを指定する。デフォルトはカレントディレクトリの named.stats 。フォーマットは別章で。
bindkeys-file
namedに内蔵されいてるトラストキーを上書きするキーファイルのパスを指定します。デフォルトは/etc/bind.keys。dnssec-lookaside や dnssec-validation に詳細があります。
secroots-file
rndc secrootsの実行時にセキュリティルートを出力するファイルパスを指定します。デフォルトは named.secroots です。
session-keyfile
nspudate -l で使用する、namedが作ったTSIGセッションキーを指定します。デフォルトは /var/run/named/session.key です。
session-keyname
TSIGセッションキー名を指定。デフォルトは localddns です。
session-keyalg
TSIGセッションキーが使用するアルゴリズム。デフォルトは hmac-sha256。
（hmac-sha1, hmacsha224, hmac-sha256, hmac-sha384, hmac-sha512 and hmac-md5）
port
DNSプロトコル通信を行うTCP/UDPのポート番号を指定します。デフォルトは 53 番。テストに使用するのみ。53以外にすると他のグローバルDNSサーバと通信できなくなる。
random-device
namedがDNSSEC時にゾーン署名する場合に利用する。乱数を読みだすようなデバイスやファイルを指定する。ファイルを指定する場合、ファイルが無いことが無いように注意。デフォルトは /dev/random 。random-deviceオプションはnamed起動時に有効になる。
preferred-glue
ここで指定したレコードタイプ順にAdditional SectionのGlueが並べられる。デフォルトは指定なし。（NONE）
ひとつのキャッシュに対して複数のviewからデータを参照する設定ができます。<br>
デフォルトでは各view単位でキャッシュを持つことになりますが、<br>
同じポリシーで作成されたviewならば、このオプションで<br>
メモリやキャッシュ効率の向上が期待できます。<br>
attach-cacheオプションは各view内でも記述でき、<br>
グローバルのattach-cache設定を上書きします。<br>
<br>キャッシュ名は共有キャッシュの名前を定義します。<br>
Bindがキャッシュを共有する設定を入れた場合には<br>
最初のviewでキャッシュが生成されて、残りのviewは単にそのキャッシュデータを参照します。<br>
これは1個のキャッシュを複数viewで参照する設定で、設定的にはoptionsの中で<br>
attach-cache設定をした場合にこのような動作になります。<br>
<br>
もうひとつの設定は、あるviewが他のviewのキャッシュを参照するという設定です。<br>
例えばA・B・Cという3個のviewがあり、AとBがキャッシュを共有するには<br>
以下のように設定します。