EN JA
unbound.conf(5)
unbound.conf(5) unbound 1.4.20 unbound.conf(5)

名称

unbound.conf - unbound 設定ファイル

書式

unbound.conf

解説

unbound.conf は、 unbound(8) を設定するために使用されます。ファイル形式には、属性と値があります。いくつかの属性には、それらの内部の属性があります。記法は、次の通りです: 属性: 値。

コメントは、# で始まり、ぎょうの終りまで続きます。空行は、行の初めの空白類のように無視されます。

使用法の前に unbound.conf をチェックするために、ユーティリティ unbound-checkconf(8) を使用することができます。

使用例

例の設定ファイルは、以下に表示されます。これを /etc/unbound/unbound.conf をコピーし、次でサーバを開始します:


$ unbound -c /etc/unbound/unbound.conf

ほとんどの設定は、デフォルトです。次でサーバを停止します:


$ kill `cat /etc/unbound/unbound.pid`

下記は、最小の設定ファイルです。ソース配布は、すべてのオプションがある大規模な example.conf ファイルを含んでいます。


# unbound(8) のための unbound.conf(5) 設定ファイル.
server:
directory: "/etc/unbound"
username: unbound
# make sure unbound can access entropy from inside the chroot.
# unbound が chroot の内部からのエントロピ (entropy) にアクセス
# することができることを確かめます.
# e.g. on linux the use these commands (on BSD, devfs(8) is used):
# 例えば, linux で、これらのコマンドを使用します (BSD で, devfs(8)
# が使用されます):
# mount --bind -n /dev/random /etc/unbound/dev/random
# と mount --bind -n /dev/log /etc/unbound/dev/log
chroot: "/etc/unbound"
# logfile: "/etc/unbound/unbound.log" # ログファイルを使用するため
# にコメントを外す.
pidfile: "/etc/unbound/unbound.pid"
# verbosity: 1 # よりログ記録するためにコメントを外し,
# 増加します.
# すべてのインタフェースで listen (接続を受け付け) し, ローカルの
# サブネットからの問い合わせに答える.
interface: 0.0.0.0
interface: ::0
access-control: 10.0.0.0/8 allow
access-control: 2001:DB8::/64 allow

ファイル形式

キーワード間に空白類がなければなりません。属性キーワードは、コロン ':' で終わります。それに続く属性は、属性または値を含んでいます。

include: デイレクティブを使用してファイルをインクルードすることができます。どんな場所でも現われることができ、引数として単一のファイル名を受け付けます。処理は、あたかもインクルードされたテキストが、その時点で設定ファイルにコピーされたかのように、継続します。また、chroot を使用するなら、インクルードされたファイルの動作のためのフルパス名を使用し、デーモンが開始されるディレクトリが、その chroot の作業ディレクトリと等しいなら、インクルードされた名前の動作のための相対的なパスネームを使用します。複数のファイルをインクルードするために、ワイルドカードを使用することができます、 glob(7) を参照。

サーバオプション

これらのオプションは、 server: 節の一部です。
verbosity: <number>
冗長レベル、レベル 0 は、冗長を意味せず、エラーだけ生じます。レベル 1 は、操作上の情報を与えます。レベル 2 は、詳細な操作上の情報を与えます。レベル 3 は、問い合わせレベル情報、1 つの問い合わせごとの出力を与えます。レベル 4 は、アルゴリズムのレベル情報を与えます。レベル 5 は、キャッシュミスのためのクライアント識別をログ記録します。デフォルトは、レベル 1 です。冗長性をコマンド行から増加することができます、 unbound(8) 参照。
statistics-interval: <seconds>
すべてのスレッドに対してログ記録のための統計値を印刷している間の秒数。値 0 または ""で無効にされます。デフォルトは、無効です。ヒストグラムの統計値は、応答が統計値の間隔の間に送信された場合のみ、印刷され、要求リストの統計値が、すべての間隔 (しかし、0 でありうる) のために印刷されます。これは、中央値の計算がデータが存在することを要求するからです。
statistics-cumulative: <yes または no>
有効にされたなら、統計値は、統計値をログ記録した後に、統計値カウンタをクリアせずに、 unbound を開始して以来、累積されます。デフォルトは、no です。
extended-statistics: <yes または no>
有効にされたなら、拡張された統計値は、 unbound-control(8) から印刷 (表示) されます。より多くの統計値の経過を追うことは、時間がかかるので、デフォルトは、オフです。カウンタは、 unbound-control(8) でリストされます。
num-threads: <number>
クライアントに役立つために作成するスレッドの数。スレッド化を行なわないためには、1 を使用します。
port: <port number>
サーバが問い合わせに応答するポート番号、デフォルトは、53 です。
interface: <ip address[@port]>
ネットワークに接続するために使用するインタフェース。このインタフェースは、クライアントからの問い合わせのために listen (接続を受け付け) され、クライアントへの答えは、それから与えられます。いくつかのインタフェースで動作するために複数回与えることができます。何も与えられないなら、デフォルトは、ローカルホストに listen (接続を受け付け) することです。インタフェースは、リロード (kill -HUP) で変更されませんが、再始動のみできます。 (インタフェースとポート番号の間に空白なしで) @port でポート番号を指定することができ、指定されないなら、( port からの) デフォルトのポートが使用されます。
interface-automatic: <yes または no>
UDP のの問い合わせで、発信元のインタフェースを検出し、それらを応答にコピーします。この機能は、実験的で、必要性は、特別のソケットオプションのための OS でサポートします。デフォルト値は、no です。
outgoing-interface: <ip address>
ネットワークに接続するために使用するインタフェース。このインタフェースは、問い合わせを信頼できるサーバに送信し、それらの応答を受信するために使用されます。いくつかのインタフェースで動作するために複数回与えることができます。どれも与えられないなら、デフォルト (すべて) が使用されます。 interface:outgoing-interface: 行で同じインタフェースを指定することができ、次に、インタフェースは、両方の目的のために使用されます。発信している問い合わせは、なりすましに立ち向かうためにランダムな発信インタフェースを通して送信されます。
outgoing-range: <number>
オープンするポートの数。ファイル記述子のこの数は、1 つのスレッドごとにオープンすることができます。少なくとも 1 でなければなりません。デフォルトは、コンパイルオプションに依存します。より大きな数は、オペレーティングシステムからの特別のリソースを必要とします。性能のために、非常に大きな値は、最良で、これを可能にするために libevent を使用します。
outgoing-port-permit: <port number or range>
問い合わせを送信するために使用される、このポートまたはポートの範囲をオープンする unbound を許可します。多くの許可された発信ポートは、なりすましの試みに備えて増加します。これらのポートは、他のデーモンによって必要ではないことを確かめます。デフォルトで、IANA によって割り当てられていない 1024 以上のポートだけが使用されます。ポート番号、または空白なしで形式 "low-high"の範囲を与えます。
outgoing-port-permitoutgoing-port-avoid 文は、許可されたポートを加えて、許可されたポートの設定から回避されたポートを引いて、設定ファイルの行の順序で処理されます。処理は、許可されたポートの設定で 1024 以上のポートを割り付けた non IANA で始まります。
outgoing-port-avoid: <port number or range>
問い合わせを送信するために使用のために、このポートまたはポートの範囲をオープンする unbound を許可しません。 unbound が、別のデーモンが必要とするポートを横取りしないことを確かめるために、これを使用します。ポートは、IP4 と IP6 の両方の、すべての発信インタフェースで回避されます。デフォルトで、IANA によって割り当てられていない 1024 以上のポートだけが使用されます。ポート番号または空白なしで、形式 "low-high"の範囲を与えます。
outgoing-num-tcp: <number>
スレッドごとに割り付ける発信 TCP バッファの数。デフォルトは、10 です。 0 に設定されるなら、または do_tcp が "no"であるなら、信頼性のあるサーバへの TCP の問い合わせが、行われます。
incoming-num-tcp: <number>
スレッドごとに割り付ける着信 TCP バッファの数。デフォルトは、10 です。 0 に設定されるなら、または do_tcp が "no"であるなら、クライアントからの TCP の問い合わせは、受け付けられません。
edns-buffer-size: <number>
EDNS 再構築バッファサイズとして通知するバイトサイズの数。これは、通信相手に向けた UDP 上のデータグラムに置かれる値です。実際のバッファサイズは、(TCP と UDP の両方のための) msg-buffer-size によって決定されます。その値より大きく設定しないでください。推奨された RFC であるデフォルトは、4096 です。タイムアウトと通常思われる、フラグメント再構築問題があるなら、 1480 の値は、それを固定することができます。生成された TCP フォールバックの量は、(また、恐らく、このリゾルバ (resolver) については、発信 tcp 番号を調整することを考えてください) 行き過ぎているので、最も強制的なパス MTU 問題さえ 512 のバイパスに設定することは、極端なことと思われません。
msg-buffer-size: <number>
メッセージバッファのバイトサイズの数。デフォルトは、64 Kb のパケットで十分な、65552 バイトで、最大の DNS メッセージサイズです。これより大きなメッセージを送信したり、受信することはできません。より少ないメモリを使用するように縮小することができますが、大きなリソースのレコードのためにのように、DNS データためにいくつかの要求は、クライアントへの SERVFAIL 応答の結果となります。
msg-cache-size: <number>
メッセージのキャッシュのバイトサイズの数。デフォルトは、4 メガバイトです。バイト単位の平板な数は、キロバイト、メガバイトまたはギガバイト (1 メガバイトの 1024*1024 バイト) のための、'k'、'm' または 'g' を追加します。
msg-cache-slabs: <number>
メッセージのキャッシュのスラブ (slab) の数。スラブは、スレッドによってロックの競合を縮小します。 2 のべき乗に設定されなければなりません。 cpu の数に (近い数に) 設定することは、合理的な推測です。
num-queries-per-thread: <number>
すべてのスレッドが同時にサービスする問い合わせの数。サービスを必要とする、より多くの問い合わせが到着し、問い合わせを押しやる ( jostle-timeout 参照) ことができるなら、問い合わせは、落とされます。これは、タイムアウトの後に再び送信することをクライアントに強制します。既存の問い合わせで作業するサーバの時間を許可します。デフォルトは、コンパイルオプション、512 または 1024 に依存します。
jostle-timeout: <msec>
サーバが非常に忙しいとき、使用されるタイムアウト。通常、権限のあるサーバへの 1 つのラウンドトリップの結果となる値に設定します。あまりにも多くの問い合わせが到着するなら、問い合わせの 50% は、完了して実行することが許可され、他の 50% は、それらが既に許可された時間を越えるて費やしているなら、新しい着信問い合わせで置き換えられます。これは、遅い問い合わせまたは高い問い合わせの割合によってサービスの拒否から保護します。デフォルトは、200 ミリ秒です。結果は、長続きする問い合わせのための qps が約 (numqueriesperthread / 2) / (長い問い合わせに対する平均時間) qps であるということです。短い問い合わせのための qps は、スレッドごとの約 (numqueriesperthread / 2) / (jostletimeout 全体の秒) qps を指定でき、デフォルトで約 (1024/2)*5 = 2560 qps です。
so-rcvbuf: <number>
0 でないなら、SO_RCVBUF ソケットオプションを着信問い合わせ UDP ポート 53 でより多くのバッファ空間を取得するために設定します。それで、ビジーサーバの短いスパイク (spike) は、パケットを落としません (netstat -su のカウンタを参照)。デフォルトは、0 (システム値を使用する) です。そうでなければ、要求されるバイトの数、ビジーサーバで "4m"を試みます。 OS は、最大でそれを制限し、linux で、unbound は、制限を回避するために root パーミッションを必要とするか、または管理者は、sysctl net.core.rmem_max を使用することができます。 BSD で、/etc/sysctl.conf の kern.ipc.maxsockbuf を変更します。 OpenBSD で、ヘッダを変更し、カーネルを再コンパイルします。 Solaris で、ndd -set /dev/udp udp_max_buf 8388608 Ns 。
so-sndbuf: <number>
0 でないなら、SO_SNDBUF ソケットオプションを発信問い合わせ UDP ポート 53 でより多くのバッファ空間を取得するために設定します。これは、非常にビジーのサーバのために、答えのトラフィックでスパイクを扱い、そうでなければ、'send: resource temporarily unavailable' をログ記録することができ、また、バッファのオーバランは、netstat -su によって目に見えます。デフォルトは、0 (システム値を使用する) です。要求されるバイトの数を指定して、非常にビジーのサーバで "4m"を試みます。 OS は、最大でそれを制限し、linux で、unbound は、制限を回避するために root パーミッションを必要とするか、または管理者は、net.core.wmem_max を使用することができます。 BSD で、Solaris の変更は、so-rcvbuf に似ています。
rrset-cache-size: <number>
RRset キャッシュのバイトサイズの数。デフォルトは、4 メガバイトです。バイト単位の平板な数は、キロバイト、メガバイトまたはギガバイト (1 メガバイトの 1024*1024 バイト) のための、'k'、'm' または 'g' を追加します。
rrset-cache-slabs: <number>
RRset キャッシュのスラブの数。スラブは、スレッドによってロックの競合を縮小します。 2 のべき乗に設定されなければなりません。
cache-max-ttl: <seconds>
キャッシュの RRset とメッセージのための有効期限の最大。デフォルトは、86400 秒 (1 日) です。最大の効果があるなら、クライアントへの応答は、まだオリジナル (より大きな) の値に基づいた、減少された TTL を取得します。内部の TTL の期限が切れるとき、キャッシュ項目は、期限が切れます。信頼する (非常に大きな) TTL 値ではなく、しばしばデータを問い合わせるためにリゾルバを強制するために低く設定することができます。
cache-min-ttl: <seconds>
キャッシュ中の RRsets とメッセージのための有効期限の最小値。デフォルトは、0 です。最小の効果があるなら、データは、対象とするドメインの所有者より長くキャッシュされ、したがって、より少ない問い合わせは、データを検索するために行なわれます。特に 1 時間かそこらより多い、より高い値は、それ以上実際のデータと調和しないキャッシュ中のデータとして問題となるかもしれず、0 は、キャッシュ中のデータが、対象とするドメインの所有者のようであることをよく確かめます。
infra-host-ttl: <seconds>
ホストのキャッシュのエントリのための有効期限。ホストのキャッシュは、往復のタイミング、lameness と EDNS サポート情報を含んでいます。デフォルトは、900 です。
infra-cache-slabs: <number>
インフラストラクチャのキャッシュのスラブの数。スラブは、スレッドによってロック競合を縮小します。 2 のべき乗に設定されなければなりません。
infra-cache-numhosts: <number>
情報がキャッシュされるホストの数。デフォルトは、10000 です。
do-ip4: <yes または no>
ip4 の問い合わせが答えられるか、または発行されるかどうかで、有効または無効にします。デフォルトは、yes です。
do-ip6: <yes または no>
ip6 の問い合わせが答えられるか、または発行されるかどうかで、デフォルトは、yes です。無効にされているなら、問い合わせは、IPv6 で答えられず、問い合わせは、インターネットのネームサーバに IPv6 で送信されません。
do-udp: <yes または no>
UDP の問い合わせが答えられるか、または発行されるかどうかで、有効または無効にします。デフォルトは、yes です。
do-tcp: <yes または no>
TCP の問い合わせが答えられるか、または発行されるかどうかで、有効または無効にします。デフォルトは、yes です。
tcp-upstream: <yes または no>
上流の問い合わせが転送のために TCP のみを使用しているかどうかで、有効または無効にします。デフォルトは、no です。トンネル化のシナリオで役に立ちます。
ssl-upstream: <yes または no>
上流の問い合わせが、転送のために SSL のみを使用しているかどうかで、有効または無効にします。デフォルトは、no です。トンネル化のシナリオで役に立ちます。 SSL は、TCP wireformat で平板な DNS を含んでいます。別のサーバは、これをサポートしなければなりません ( ssl-service-key を参照)。
ssl-service-key: <file>
有効にされるなら、サーバは、その TCP ソケットで SSL サービスを提供します。クライアントは、ssl-upstream: yes を使用しなければなりません: ファイルは、TLS セッションのための秘密鍵です。パブリックな証明書は、ssl-service-pem ファイルにあります。デフォルトは、""で、オフにされます。 (もしあれば) chroot の前に、root パーミッションが保持される間に、秘密鍵が読み込まれるので、変更されるなら、(リロードが十分ではない) 再開を要求します。通常の DNS TCP サービスは、提供されず、エラーを与えます、このサービスは、異なる port: 設定または interface 設定の @port 接尾辞で最も良く実行されます。
ssl-service-pem: <file>
ssl サービスのための公開鍵の証明書 pem ファイル。デフォルトは、""で、オフにされます。
ssl-port: <number>
TCP SSL サービスを提供するポート番号、デフォルトは、443、@number が SSL サービスを取得するように、そのポート番号で設定されたインタフェースのみ。
do-daemonize: <yes または no>
デーモンとしてのバックグラウンドに unbound サーバをフォーク (fork) するかどうかで、有効または無効にします。デフォルトは、yes です。
access-control: <IP netblock> <action>
netblock は、クラスががないネットワークブロックのために追加された /size がある IP4 または IP6 のアドレスとして与えられます。アクションは、 deny, refuse, allow または allow_snoop を指定できます。
アクション deny は、その netblock からのホストから問い合わせを停止します。
また、アクション refuse は、問い合わせを停止しますが、 DNS rcode REFUSED エラーメッセージを送り返します。
アクション allow は、その netblock からのクライアントにアクセスを与えます。それは、(ほとんどすべてのクライアントが必要とするものである) 再帰的なクライアントのためにだけにアクセスを与えます。再帰的でない問い合わせは、拒否されます。
allow アクションは、再帰的でない問い合わせが、設定されるローカルデータにアクセスすることができます。理由は、これが unbound サーバの再帰的な検索アルゴリズムを含んでいないということで、静的なデータは、応答で役に立ちます。これは、通常、再帰的でない問い合わせが信頼できるデータのために行なわれるところの動作をサポートします。再帰的てない問い合わせについて、動的なキャッシュからのあらゆる応答は、拒否されます。
また、アクション allow_snoop は、再帰的でないアクセスを与えます。これは、再帰的と再帰的でないアクセスの両方を与えます。名前 allow_snoop は、キャッシュをせんさく、(悪質な動作のために) キャッシュの内容を調べるために再帰的でない問い合わせを使用する技術のために参照されます。しかしながら、また、再帰的でない問い合わせは、(キャッシュの内容を調べたいとき) 価値のあるデバッグのツールになることができます。その場合に、管理ホストのための allow_snoop を使用します。
デフォルトで、ローカルホストだけが許可 ( allow) され、残りは、拒否 ( refuse) されます。デフォルトは、それがプロトコルにフレンドリであるので、拒否 ( refuse) されます。 DNS プロトコルは、ポリシのために落とされたパケットを扱うように設計されていなくて、落すことは、再び試みられた問い合わせ (たぶん行きすぎた) 結果となるかもしれません。
chroot: <directory>
chroot が有効にされるなら、オリジナルの root からフルパスとして (コマンド行から) 設定ファイル (configfile) を渡すべきです。 chroot が実行された後に、設定ファイルのパスの現在消滅した部分は、リロードの後に、設定ファイルを再読み込みすることができるように削除されます。
他のすべてのファイルのパス (作業 dir、ログファイル、root hint とキーファイル) は、次のいくつかの方法で指定することができます: 新しい root に関連する絶対パスとして、作業ディレクトリへの相対パス、またはオリジナルの root に関連する絶対パスとして。最後の場合に、パスは、未使用の部分を削除するために調節されます。
pidfile は、作業ディレクトリへの相対パスまたはオリジナルの root に関連する絶対パスのいずれかを指定できます。それは、ちょうど chroot とパーミッションを落とすより前に書き込まれます。これは、pidfile が /var/run/unbound.pid となり、 chroot が /var/unbound となることができます、例えば。
さらに、unbound は、chroot の内部から /dev/random (エントロピのための) にアクセスする必要があります。
与えられるなら、chroot は、与えられたディレクトリに行なわれます。デフォルトは、"/var/unbound"です。 ""が与えられるなら、chroot は、実行されません。
username: <name>
与えられるなら、ポートをバインドした後に、ユーザの特権は、落とされます。デフォルトは、"unbound"です。 username: ""を与えらるなら、ユーザの変更は、実行されません。
このユーザがポートをバインドすることができないなら、 (シグナル HUP によって) リロードは、オープンされたポートをまだ保持します。設定ファイルのポート番号を変更し、その新しいポート番号が特権を要求するなら、リロードは、失敗します。再始動が、必要です。
directory: <directory>
プログラムのために作業ディレクトリを設定します。デフォルトは、"/var/unbound"です。
logfile: <filename>
""が与えられるなら、ログ記録は、stderr に行きます、すなわち、一度もデーモン化されません。ログファイルは、次の形式で追加されます:
[seconds since 1970] unbound[pid:tid]: type: message.
このオプションが与えられるなら、use-syslog は、オプションで、 "no"に設定されます。ログファイルは、SIGHUP で、設定ファイルが再読み込みされるとき、 (追加のために) 再オープンされます。
use-syslog: <yes または no>
syslog(3) を使用して、syslogd にログメッセージを奏せ因するために unbound を設定します。ログ機能 LOG_DAEMON は、識別 "unbound"で使用されます。ログファイルの設定は、use-syslog がオンにされるとき、上書きされます。デフォルトは、syslog にログ記録することです。
log-time-ascii: <yes または no>
UTC ascii でタイムスタンプを使用するためにログファイルに行を設定します。デフォルトは、角括弧で 1970 年以来の秒数を印刷する、no です。 syslog がログファイルに印刷されたタイムスタンプを書式化する場合に、 syslog を使用するなら、効果は、ありません。
log-queries: <yes または no>
ログのタイムスタンプと IP アドレス、名前、タイプとクラスを付けて、問い合わせごとに 1 行でログに印刷 (出力) します。デフォルトは、no です。サーバ (著しく) をより遅くする、これらの行を印刷するのに時間がかかることに注意してください。名前の変な (印刷不可能) 文字は、'?' として印刷されます。
pidfile: <filename>
プロセス ID は、ファイルに書き込まれます。デフォルトは、"/var/unbound/unbound.pid"です。それで、
kill -HUP `cat /var/unbound/unbound.pid`
でリロードをトリガします。
kill -QUIT `cat /var/unbound/unbound.pid`
は、優雅に終了します。
root-hints: <filename>
このファイルから root ヒントを読み込みます。デフォルトは、IN クラスのために組み込みのヒント使用する、 nothing です。ファイルは、root ネームサーバ名とアドレスだけがある、ゾーンファイルの形式があります。デフォルトは、サーバが変更するとき、時代遅れになりますが、 root-hint ファイルを使用することはよいことです。
hide-identity: <yes または no>
有効にされるなら、id.server と hostname.bind の問い合わせは、拒否されます。
identity: <string>
報告する識別子を設定します。デフォルトである、""に設定されるなら、サーバのホスト名が返されます。
hide-version: <yes または no>
有効にされるなら、version.server と version.bind の問い合わせは、拒否されます。
version: <string>
報告するバージョンを設定します。デフォルトである、""に設定されるなら、パッケージのバージョンが返されます。
target-fetch-policy: <"list of numbers">
日和見的にネームサーバのターゲットアドレスを取って来るべきかどうか判断するために、unbound によって使用されるターゲットのフェッチ (取って来る) ポリシを設定します。ポリシは、依存性の深さごとに記述されます。
値の数は、unbound が問い合わせの答えを追求する、最大の依存性の深さを決定します。-1 の値は、依存性の深さのためにすべてのターゲットを日和見的に取って来ることを意味します。 0 の値は、オンデマンドのみを取って来ることを意味します。正の値は、多くのターゲットを日和見的に取って来ます。
引用 ("") 間のリストを囲んで、数の間に空白を置きます。デフォルトは、"3 2 1 0 0"です。すべて 0、"0 0 0 0 0"に設定することは、BIND 9 に近い振る舞いを与えます、一方、"-1 -1 -1 -1 -1"に設定することは、BIND 8 に近いとうわさされる振る舞いを与えます。
harden-short-bufsize: <yes または no>
問い合わせからの非常に小さな EDNS バッファサイズは、無視されます。 unbound は、可能であれば、これらを送信するのに賢明な正当なプロトコルであり、これらの問い合わせへの非常に小さな答えを与えることを試みるので、デフォルトは、オフです。
harden-large-queries: <yes または no>
非常に大きな問い合わせは、無視されます。これらを送信するのに正当なプロトコルで、TSIG または EDNS ペイロードが非常に大きいなら、操作のために必要となるかのしれないので、デフォルトは、オフです。
harden-glue: <yes または no>
それがサーバの権限内にある場合のみ、グルー (glue) を信頼します。デフォルトは、no です。
harden-dnssec-stripped: <yes または no>
trust-anchored ゾーンのための DNSSEC データを要求し、そのようなデータが不在であるなら、ゾーンは、偽りとなります。オフにされ、DNSSEC データが、受信されない、(または、DNSKEY データが、有効にできない) なら、ゾーンは、安全でなくなり、これは、信頼アンカがないように振る舞います。パケットから DNSSEC データを削除する (ある種類の) ファイアウォールに侵入する後ろにしばしばいるか、またはまたはゾーンが、符号ありから符号なしにしばしば悪く符号ありに変更されるうなら、これをオフに切り替えられるかもしれません。オフにされるなら、ゾーンのためのセキュリティを無効にするダウングレード攻撃の危険があります。デフォルトは、no です。
harden-below-nxdomain: <yes または no>
draft-vixie-dnsext-resimprove から、既に nxdomain であると知られている別の名前より下の名前のために問い合わせする nxdomain に返します。 DNSSEC は、空の非端末のための noerror に命じ、したがって、これは、可能です。非常に古いソフトウェアは、(通常 IP アドレスの逆引きのために起こる) 空の非端末のために nxdomain を返し、したがって、これと互換性がないかもしれません。これを回避することを試みるために、古いソフトウェアに DNSSEC がないので、 DNSSEC 安全な nxdomains のみが使用されます。デフォルトは、オフです。
harden-referral-path: <yes または no>
インフラストラクチャのデータのための追加の問い合わせを実行することによって、照会パスを固めます。信頼アンカが設定され、ゾーンが署名されるなら、応答を有効にします。これは、ネームサーバ NS 設定と答えへの照会パスで遭遇するネームサーバのアドレスに DNSSEC 検証を強制します。認証サーバに負担させ、RFC 標準でなく、生成されるロードを特別に問い合わせるために、性能上の問題を導くかもしれないので、デフォルトでオフです。実験的なオプション。それを有効にするなら、チェックされる最大の深さを増加させるために target-fetch-policy の後に、より多くの数を追加することを考慮します。
use-caps-for-id: <yes または no>
なりすなしの試みを妨害するために、問い合わせで 0x20 エンコードランダムビットを使用します。これは、権限のあるサーバに送信する問い合わせ名の小文字と大文字を混乱させ、応答が、まだ正確な大文字小文字であるかどうかチェックします。デフォルトで無効にされます。この機能は、草案 dns-0x20 の実験的な実装です。
private-address: <IP address or subnet>
IPv6 アドレスまたはクラスがないサブネットの IPv4 を与えます。これらは、利用者のプライベートネットワークのアドレスで、パブリックなインターネット名のために返されることを許可されません。そのようなアドレスのあらゆる出来事は、DNS の答えから削除されます。さらに、DNSSEC 検証ソフト (validator) は、答えを偽りとマークします。これは、利用者のプライベートネットワークの他の部分にブラウザによってリモートアクセスを許可して、ユーザのブラウザがネットワークプロキシに変えられるところで、いわゆる DNS Rebinding に対して保護します。いくつかの名前を利用者のプライベートアドレスを含むを許可することができ、デフォルトで、設定されたすべての local-data が、許可され、 private-domain を使用して追加の名前を指定することができます。プライベートアドレスは、デフォルトで有効になりません。後のリリースでデフォルトによって RFC1918 プライベート IP アドレス空間に対して、これを有効にするように考慮します。 RFC 基準は、これらのアドレスがパブリックなインターネットで目に見えるべきでないと記述しているので、それは、.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 fd00::/8 と fe80::/10 のためのプライベートアドレスを有効にします。それを使用するとともに、127.0.0.0/8 をオンにすることは、多くのスポンブロックリスト (spamblocklist) を妨害します。
private-domain: <domain name>
プライベートアドレスを含む、このドメインと、そのすべてのサブドメインを許可します。複数のドメイン名がプライベートアドレスを含むことができるように複数の回を与えます。デフォルトは、none です。
unwanted-reply-threshold: <number>
設定されるなら、望まれない応答の合計数は、すべてのスレッドの経過を追います。しきい値に到達するとき、防御的なアクションが取られ、警告は、ログに印刷 (出力) されます。防御的なアクションは、できればあらゆる害になるもの (poison) をフラッシュして、 rrset とメッセージのキャッシュをクリアすることです。 1000 万の値が、推奨されます。デフォルトは、0 (オフにされる) です。
do-not-query-address: <IP address>
与えられた IP アドレスを問い合わせしません。 IP4 または IP6 を指定できます。クラスがない委任の netblock を示すために、例えば、10.2.3.4/24 または 2001::11/64 のように、/num を追加します、
do-not-query-localhost: <yes または no>
yes であるなら、ローカルホストは、do-not-query-address エントリ、 IP6 ::1 と IP4 127.0.0.1/8 の両方に追加されます。 no であるなら、ローカルホストは、問い合わせを送信するために使用することができます。デフォルトは、yes です。
prefetch: <yes または no>
yes であるなら、メッセージのキャッシュの要素は、キャッシュを最新に保持するために、それらの有効期限が切れる前に、あらかじめ取って来られます。デフォルトは、no です。それをオンにすることは、約 10 パーセントより多くのトラフィックを与え、マシンでロードしますが、ポピュラな項目は、キャッシュの有効期限が切れません。
prefetch-key: <yes または no>
yes であるなら、DS レコードに遭遇するとき、検証プロセスで以前に DNSKEY を取って来ます。これは、要求の待ち時間を低下させます。それは、もう少しの CPU を使用します。また、キャッシュが 0 に設定されるなら、それは、使用しません。デフォルトは、no です。
rrset-roundrobin: <yes または no>
yes であるなら、unbound は、応答の順序で RRSet をローテートします (乱数は、速度とスレッドセーフのために、問い合わせ ID から取られます)。デフォルトは、no です。
minimal-responses: <yes または no>
yes であるなら、unbound は、それらのセクションが必要でないなら、応答メッセージに権限/付加セクションを挿入しません。これは、応答サイズを著しく縮小し、いくつかの応答のための TCP フォールバックを回避します。これは、少しのスピードアップとなります。 DNS プロトコル RFC が、これらのセクションを強制し、追加の内容は、役に立ち、クライアントのために往復 (roundtrip) を保存するので、デフォルトは、no です。
module-config: <"module names">
空白にによって区切られたモジュール名のリストである、モジュール設定は、引用 ("") で文字列を囲みます。モジュールは、validator iterator (検証ソフト、イテレータ (反復子)) を指定できます。これを "iterator" に設定することは、non-validating (有効でない) サーバの結果となります。これを "validator iterator"に設定することは、DNSSEC 検証をオンにします。モジュールの順序は、重要です。また、検証が有用であるために信頼アンカを設定しなければなりません。
trust-anchor-file: <filename>
検証のための信頼されたキーがあるファイル。 DS と DNSKEY エントリの両方がファイルに現われることができます。ファイルの形式は、標準の DNS ゾーンファイル形式です。デフォルトは、""、または信頼アンカファイルである、no です。
auto-trust-anchor-file: <filename>
RFC5011 調査で追跡される、1 つのゾーンのための信頼アンカがあるファイル。調査は、1 か月ごとに数回ですが、マシンは、頻繁にオンラインでなければなりません。初期ファイルは、 trust-anchor-file に記述されているような内容のものを指定できます。ファイルは、アンカが更新されときに、書き込まれるので、 unbound ユーザは、書き込み許可がなければなりません。
trust-anchor: <"Resource Record">
検証のために使用するキーのための DS または DNSKEY RR。 trust-anchor-files に加えて複数の信頼されたキーを指定するために、複数のエントリを与えることができます。リソースレコードは、ゾーンファイルと同じ形式で、それらを印刷する 'dig' または 'drill' と同じ形式で入力されます。そのまわりの ""と共に、単一の行になければなりません。カット &ペーストの容易さのために TTL を指定することができますが、無視されます。クラスを指定することができますが、クラス IN が、デフォルトです。
trusted-keys-file: <filename>
検証のための信頼されたキーがあるファイル。いくつかのエントリ、1 つのエントリごとに 1 つのファイルがある、 1 つ以上のファイルを指定します。 trust-anchor-file のようですが、異なるファイル形式があります。形式は、BIND-9 スタイルの形式で、 trusted-keys { name flag proto algo "key"; };節が読み込まれます。この文でワイルドカードを使用することは可能で、ワイルドカードは、開始とリロードで展開されます。
dlv-anchor-file: <filename>
DLV (DNSSEC Lookaside Validation) のための信頼されたキーがあるファイル。 DS と DNSKEY エントリの両方は、 trust-anchor-file: 文と同じ形式で、ファイルで使用することができます。 1 つの DLV だけを設定することができます、より多いと遅くなります。設定された DLV は、root の信頼された DLV として使用され、これは、root のための lookaside (注意をそらす) であることを意味します。デフォルトは ""、または dlv アンカファイルである no です。
dlv-anchor: <"Resource Record">
trust-anchor によく似て、これは、DS または DNSKEY インラインがある DLV アンカです。
domain-insecure: <domain name>
安全でないドメイン名を設定し、信頼の DNSSEC チェーンは、ドメイン名に関して無視されます。それで、上記のドメイン名の信頼アンカは、次に、DS レコードが無視されるような、 DS レコードでドメインを安全にすることができません。また、DLV からのキーは、ドメインに対して無視されます。あたかも署名なしかのように処理される複数のドメインを指定するために複数回与えることができます。利用者がドメインのための信頼アンカを設定するなら、それらは、この設定を上書きし (ドメインは、安全にされます)。
利用者が、外部検索のための信頼アンカが (署名なしの) 内部ドメインに影響しないことをあなたが確かめたいなら、これは、役に立ちます。外部的に DS レコードは、その内部ドメインのための検証の失敗を作成することができます。
val-override-date: <rrsig-style date spec>
デフォルトは、このデバッグ機能を無効にする ""または "0"です。 RRSIG スタイルの日付を与えることにより有効にされるなら、その日付は、現在の日付の代わりに、RRSIG の始まりと有効期限を確認するために使用されます。利用者が署名の始まりとの始まりと有効期限をデバッグしないなら、これを設定しないでください。値-1 は、いくつかの特別のアプリケーションのために役に立つ日付をすべて無視します。
val-sig-skew-min: <seconds>
有効にされた署名に適用するクロックスキュー (clock skew) の秒の最小数。署名の生存期間 (有効期限-始まり) の 10% の値は、この設定によって制限して使用されます。デフォルトは、夏時間の差を考慮に入れる 3600 (1 時間) です。短い有効な署名のより厳密なチェックのためのこの値をより低くします。
val-sig-skew-max: <seconds>
有効にされた署名に適用するクロックスキュー (clock skew) の秒の最大数。署名の生存期間 (有効期限-始まり) の 10% の値は、この設定によって制限して使用されます。デフォルトは、安定したドメインで問題を設定するタイムゾーンを考慮に入れる 86400 (24 時間) です。非常に低い min と max の両方を設定することは、クロックスキュー (clock skew) の許可量を無効にします。非常に高い min と max の両方を設定することは、検証ソフトに署名のタイムスタンプをそれほど厳密にチェックさせません。
val-bogus-ttl: <number>
偽りのデータのための有効期限。これは、確認に失敗したデータです。無効の署名または他のチェックのためです。そのデータからの TTL は、信頼することができず、この値が、代わりに使用されます。値は、秒単位で、デフォルトは、60 です。時間の間隔は、偽りのデータの繰り返される再検証を防ぎます。
val-clean-additional: <yes または no>
適切に署名されない安全なメッセージの追加セクションからデータを削除するように検証ソフトに指示します。安全でない、偽り、確定できない、または未チックのメッセージは、影響されません。デフォルトは、yes です。潜在的に追加のセクションの不良データからの認証のために、この検証ソフトを当てにするユーザを保護するために、この設定を使用します。
val-log-level: <number>
検証ソフトが検証の失敗をログに印刷 (出力) します。冗長の設定にかかわらず。デフォルトは、オフである、0 です。 1 で、すべてのユーザに対して、行を失敗する問い合わせは、ログに印刷 (出力) されます。このように、利用者は、検証で起こることをモニタすることができます。検証がこれらの問い合わせのためになぜ失敗しているか調べるために、 dig または drill のような診断ツールを使用します。 2 で、失敗した問い合わせのみ印刷されますが、なぜ、unbound が間違っていると考えるかの理由とどのサーバが、欠陥のあるデータを送信したかも印刷されます。
val-permissive-mode: <yes または no>
予測できないものとして偽りのメッセージをマークするように検証ソフトに指示します。セキュリティチェックは、行なわれますが、結果が偽りであるなら (セキュリティに失敗した)、いつものように、応答は、 SERVFAIL があるクライアントから非通知ではありません。クライアントは、偽りのデータを受信します。安全であると分かるメッセージについて、AD ビットは、応答で設定されています。また、ログ記録は、十分な検証のために実行されます。デフォルト値は、"no"です。
ignore-cd-flag: <yes または no>
クライアントからの CD フラグを無視し、それらへの偽りの答えを返すことを拒否することを unbound に指示します。したがって、CD (Checking Disabled, 無効にされたチェック) フラグは、これ以上チェックを無効ににしません。 CD フラグを設定したが、DNSSEC それら自体を有効にできない古い (w2008) サーバが、クライアントで、次に unbound が、DNSSEC 保護があるそれらに供給するなら、これは、役に立ちます。デフォルト値は、"no"です。
val-nsec3-keysize-iterations: <"list of values">
引用に囲まれ、空白によって区切られる、キーサイズ (keysize) と繰り返しカウント値のリスト。デフォルトは、"1024 150 2048 500 4096 2500"です。これは、メッセージが多くのハッシュの繰り返しを実行する代わりに安全でないと単にマークされる前に、最大の許可された NSEC3 繰り返しカウントを決定します。リストは、昇順でなければならず、少なくとも 1 つのエントリがなければなりません。それを "1024 65535"に設定するなら、NSEC3 繰り返し値への制限はありません。このテーブルは、短くしておかれなければなりません。非常に長いリストは、より遅い操作を引き起こすかもしれません。
add-holddown: <seconds>
今回のための目に見えた後のみ、新しい信頼アンカを追加するために RFC5011 autotrust 更新のための auto-trust-anchor-file プローブメカニズムに指示します。デフォルトは、RFC により 30 日です。
del-holddown: <seconds>
この長さのための無効にされたリストで保持された後に、無効にされた信頼アンカを削除するために RFC5011 autotrust 更新のための auto-trust-anchor-file プローブメカニズムに指示します。デフォルトは、RFC により 30 日です。
keep-missing: <seconds>
この長さのための目に見えなかった後に、失われた信頼アンカを削除するために RFC5011 autotrust 更新のための auto-trust-anchor-file プローブメカニズムに指示します。これは、ターゲットゾーンが信頼アンカの取り消しを実行しないなら、状態ファイルをクリーンアップするので、習慣的な (非 5011) ロールオーバ (rollover) を実行するゾーンがある自動プローブメカニズム作業を行ないます。デフォルトは、366 日です。値 0 は、RFC により、失われたアンカを削除しません。
key-cache-size: <number>
キーキャッシュのバイトサイズの数。デフォルトは、4 メガバイトです。バイト単位の平板な数は、キロバイト、メガバイトまたはギガバイト (1 メガバイトの 1024*1024 バイト) のための、'k'、'm' または 'g' を追加します。
key-cache-slabs: <number>
キーキャッシュのスラブの数。スラブは、スレッドによってロック競合を縮小します。 2 のべき乗に設定されなければなりません。 cpus の数 (に近い数) の設定することは、合理的な推測です。
neg-cache-size: <number>
積極的な否定のキャッシュのバイトサイズの数。デフォルトは、1 メガバイトです。バイト単位の平板な数は、キロバイト、メガバイトまたはギガバイト (1 メガバイトの 1024*1024 バイト) のための、'k'、'm' または 'g' を追加します。
local-zone: <zone> <type>
ローカルゾーンを設定します。タイプは、ローカルデータから一致がないなら、与える答えを決定します。タイプは、deny, refuse, static, transparent, redirect, nodefault, typetransparent で、下記に説明されています。その後、デフォルトの設定が、リストされます。ローカルゾーンにデータを入力するために local-data: を使用します。ローカルゾーンのための答えは、信頼できる DNS の答えです。デフォルトで、ゾーンは、クラス IN です。
照会、ワイルドカード、CNAME/DNAME サポート、または DNSSEC 信頼できるサービスと共に、より複雑な信頼できるデータを必要とするなら、下記のスタブゾーンセクションで詳しく述べたように、そのためのスタブゾーンをセットアップします。
deny
問い合わせを落として、答えを送信しません。ローカルデータからの一致があるなら、問い合わせが答えられます。
refuse
rcode REFUSED と共に、エラーメッセージの応答を送信します。ローカルデータからの一致があるなら、問い合わせが答えられます。
static
ローカルデータからの一致があるなら、問い合わせが答えられます。そうでなければ、問い合わせは、nodata または nxdomain で答えられます。否定の答えについて、SOA は、ゾーン apex ドメインのためのローカルデータとして存在するなら、答えに含まれます。
transparent
ローカルデータからの一致があるなら、問い合わせが答えられます。そうでなければ、問い合わせに異なる名前があるなら、問い合わせは、通常解決されます。問い合わせがローカルデータで与えられた名前のためであるが、そのようなタイプのデータがローカルデータで与えられないなら、 noerror nodata の答えが返されます。ローカルゾーンがローカルデータで与えられないなら、透過的なゾーンが、デフォルトで作成されます。
typetransparent
ローカルデータからの一致があるなら、問い合わせが答えられます。問い合わせが異なる名前、または同じ名前のためで、異なるタイプのためでなかったなら、問い合わせは、通常解決されます。それで、透過的に類似しているが、ローカルデータにリストされないタイプは、通常、解決されるので、A レコードがローカルデータにあるなら、それは、AAAA 問い合わせのための nodata 応答を引き起こしません。
redirect
問い合わせは、ゾーン名のためのローカルデータから答えられます。ゾーン名の下にローカルデータがないかもしれません。これは、ゾーンのための問い合わせとゾーンのためのローカルデータがあるゾーンのすべてのサブドメインに答えます。エンドユーザに異なるアドレスのレコードを返すドメインをリダイレクトするために使用することができ、ウェブブラウザでユーザは、接尾辞 example.com でサイトにアクセスすることができないので、 local-zone: "example.com."のリダイレクトと www.example.com のための local-data: "example.com. A 127.0.0.1"問い合わせ、 www.foo.example.com は、リダイレクトされます。
nodefault
AS112 ゾーンのためのデフォルト内容をオフにするために使用されます。また、他のタイプは、ゾーンのためのデフォルト内容をオフにします。 'nodefault' オプションには、与えられたゾーンのためのデフォルト内容をオフにする以外の効果がありません。

デフォルトのゾーンは、ローカルホスト、逆 127.0.0.1 と ::1 および AS112 ゾーンです。 AS112 ゾーンは、インターネットのサーバが正しい答えを提供することができないプライベートな使用と予約された IP アドレスのための逆の DNS ゾーンです。それらは、nxdomain (逆の情報なし) 答えを与えるために、デフォルトで設定されます。デフォルトは、利用者自身のその名前のローカルゾーンを指定することによって、または 'nodefault' タイプの使用してオフに切り替えることができます。下記は、デフォルトのゾーン内容のリストです。

localhost
IP4 と IP6 のローカルホストの情報が与えられます。 NS と SOA のレコードは、完全性といくつかの DNS 更新ツールを満足させるために提供されます。デフォルト内容は、次の通りです:
local-zone: "localhost." static
local-data: "localhost. 10800 IN NS localhost."
local-data: "localhost. 10800 IN
SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "localhost. 10800 IN A 127.0.0.1"
local-data: "localhost. 10800 IN AAAA ::1"
逆の IPv4 ループバック
デフォルト内容は、次の通りです:
local-zone: "127.in-addr.arpa." static
local-data: "127.in-addr.arpa. 10800 IN NS localhost."
local-data: "127.in-addr.arpa. 10800 IN
SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "1.0.0.127.in-addr.arpa. 10800 IN
PTR localhost."
逆の IPv6 ループバック
デフォルト内容は、次の通りです:
local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." static
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN
NS localhost."
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN
SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN
PTR localhost."
逆の RFC1918 ローカル使用ゾーン
ゾーン 10.in-addr.arpa, 16.172.in-addr.arpa から 31.172.in-addr.arpa, 168.192.in-addr.arpa のための逆のデータ。 local-zone: は、静的であり、 local-data: SOA と NS レコードが提供されます。
逆の RFC3330 IP4、リンクローカル、テストネットと同報通信
ゾーン 0.in-addr.arpa, 254.169.in-addr.arpa, 2.0.192.in-addr.arpa (TEST NET 1), 100.51.198.in-addr.arpa (TEST NET 2), 113.0.203.in-addr.arpa (TEST NET 3), 255.255.255.255.in-addr.arpa のための逆のデータ。
指定されない逆の RFC4291 IP6
ゾーンのための逆のデータ。
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
逆の RFC4291 IPv6 Locally Assigned Local Addresses
ゾーン D.F.ip6.arpa のための逆のデータ。
逆の RFC4291 IPv6 Link Local Addresses
B.E.F.ip6.arpa へのゾーン 8.E.F.ip6.arpa のための逆のデータ。
逆の IPv6 Example Prefix
ゾーン 8.B.D.0.1.0.0.2.ip6.arpa のための逆のデータ。このゾーンは、チュートリアルと利用例のために使用されます。次のものがある、このゾーンでブロックを削除することができます:
local-zone: 8.B.D.0.1.0.0.2.ip6.arpa. nodefault
また、その部分を local-zone 文で透過的にすることによって、ゾーンの一部分を選択的に非ブロック化 (unblock) することができます。また、これは、他のデフォルトのゾーンで動作します。
local-data: "<resource record string>"
そのための問い合わせに応答するのに役に立つ、ローカルデータを設定します。問い合わせは、リダイレクトとして、local-zone を設定しないなら、正確に一致しなければなりません。正確に一致しなかったなら、local-zone タイプは、さらなる処理を決定します。 local-data が local-zone のサブドメインでないように設定されるなら、透過的な local-zone が設定されます。 TXT のようなレコードタイプについて、local-data: 'example. TXT "text"' などのように、シングルクォートを使用します。
照会、ワイルドカード、CNAME/DNAME サポート、または DNSSEC 信頼できるサービスと共に、より複雑な信頼できるデータを必要とするなら、下記のスタブゾーンセクションで詳しく述べたように、そのためのスタブゾーンをセットアップします。
local-data-ptr: "IPaddr name"
逆にされた IPv4 または IPv6 アドレス、とホスト名がある PTR レコードのためのローカルデータの省略表現を設定します。例えば、"192.0.2.4 www.example.com"。次のように、TTL を挿入することができます: "2001:DB8::4 7200 www.example.com"

リモート制御オプション

remote-control: 節では、リモート制御機能のための宣言があります。これが有効にされるなら、実行している unbound サーバにコマンドを送信するために、 unbound-control(8) ユーティリティを使用することができます。サーバは、接続のための SSLv3 / TLSv1 セキュリティをセットアップするためにこれらの節を使用します。また、 unbound-control(8) ユーティリティは、オプションのために remote-control セクションを読み込みます。正確な自己署名証明書をセットアップするために、 unbound-control-setup(8) ユーティリティを使用します。
control-enable: <yes または no>
オプションは、リモート制御を有効にするために使用されます、デフォルトは、"no"です。オフされるなら、サーバは、制御コマンドに対して listen (接続を受け付け) しません。
control-interface: <ip address>
制御コマンドを listen (接続を受け付け) するために、 IPv4 または IPv6 アドレスを与えます。デフォルトで、localhost (127.0.0.1 と ::1) が、listen (接続を受け付け) されます。すべてのインタフェースを listen (接続を受け付け) するために 0.0.0.0 と ::0 を使用します。
control-port: <port number>
制御コマンドを listen (接続を受け付け) するポート番号、デフォルトは、8953 です。このポート番号を変更し、許可が落されているなら、リロードは、再びポートをオープンするためには十分ではなく、その後、再開しなければなりません。
server-key-file: <private key file>
デフォルトの unbound_server.key によるサーバの秘密鍵へのパス。このファイルは、 unbound-control-setup ユーティリティによって生成されます。このファイルは、 unbound-control によってではなく、 unbound サーバによって使用されます。
server-cert-file: <certificate file.pem>
デフォルトの unbound_server.pem によるサーバ自己署名証明書へのパス。このファイルは、 unbound-control-setup ユーティリティによって生成されます。このファイルは、unbound サーバ、とさらに unbound-control によって使用されます。
control-key-file: <private key file>
デフォルトの unbound_control.key による制御クライアント秘密鍵へのパス。このファイルは、 unbound-control-setup ユーティリティによって生成されます。このファイルは、 unbound-control によって使用されます。
control-cert-file: <certificate file.pem>
デフォルトの unbound_control.pem による制御クライアント証明書へのパス。この証明書は、サーバ証明書で署名されなければなりません。このファイルは、 unbound-control-setup ユーティリティによって生成されます。このファイルは、 unbound-control によって使用されます。

スタブ (stub) ゾーンオプション

複数の stub-zone: 節があるかもしれません。各々は、name: と 0 以上のホスト名または IP でアドレスです。 stub ゾーンについて、ネームサーバのこのリストが使用されます。クラス IN が仮定されます。サーバは、再カーソルではなく権限のあるサーバであるべきです。 unbound は、スタブゾーンのために再帰的な処理自体を実行します。

パブリックなインターネットサーバを使用してアクセスすることができないリゾルバ (resolver) によって使用される権限のあるデータを設定するために、スタブゾーンを使用することができます。これは、company-local データまたはプライベートなゾーンのために役に立ちます。異なるホスト (または異なるポート) の権限のあるサーバをセットアップします。 stub-addr: <ip address of host[@port]>がある unbound のための設定エントリを入力します。次に、unbound リゾルバ (resolver) は、そのためにパブリックなインターネットを参照せずに、データにアクセスすることができます。

このセットアップによって、 DNSSEC の署名されたゾーンは、その権限のあるサーバによって、役立てることができます、その場合に、unbound が、データを有効にすることができ、プライベートなゾーンのための返答で AD ビットを (権限のあるサーバは、AD ビットを設定しません) 設定することができるように、公開鍵がある信頼されたキーの入力を設定に置くことができます。このセットアップは、unbound がプライベートなゾーンのための問い合わせに答えることができるようにし、さらに AD ビット ('authentic') を設定することができますが、AA ('authoritative') ビットは、これらの応答で設定されません。

name: <domain name>
スタブゾーンの名前。
stub-host: <domain name>
スタブゾーンのネームサーバの名前。それが使用される前に、それ自体が解決されます。
stub-addr: <IP address>
スタブゾーンのネームサーバの IP アドレス。 IP 4 または IP 6 を指定できます。 DNS 通信のためのデフォルトでないポートを使用するために、ポート番号がある '@' を追加します。
stub-prime: <yes または no>
このオプションは、デフォルトでオフです。有効にされるなら、ゾーンによって現在公開されたネームサーバのリストを使用し始めるところで、root のヒントに類似している、NS 設定プライミング (priming) を実行します。したがって、ヒントリストがわずかに古いなら、リゾルバ (resolver) は、正確なリストをオンラインで手に入れます。
stub-first: <yes または no>
有効にされるなら、問い合わせは、それが失敗するなら、スタブ節なしで試みられます。データを検索することができないかもしれないし、サーバが到達可能でないので、 SERVFAIL を引き起こしていたでしょう、代わりに、この節なしで試みられます。デフォルトは、no です。

転送 (forward) ゾーンオプション

複数の forward-zone: 節があるかもしれません。各々は、name: と 0 以上のホスト名または IP でアドレスです。転送されるゾーンのために、ネームサーバのこのリストは、問い合わせを転送するために使用されます。 forward-host:forward-addr: としてリストされたサーバは、問い合わせのためにさらなる再帰を扱わなければなりません。したがって、それらのサーバは、権限のあるサーバではないですが、 (ちょうど、unbound のような) 再帰的なサーバでもあります。 unbound は、転送のゾーンのためにそれ自体を再帰的に実行しません、それはリモートサーバに、それをさせます。クラス IN が仮定されます。名前 "."がある forward-zone エントリと forward-addr ターゲットは、 (それが、キャッシュから答えることができないなら) 他のサーバにすべての問い合わせを転送します。
name: <domain name>
転送ゾーンの名前。
forward-host: <domain name>
転送するサーバの名前。それが使用される前に、それ自体を解決されます。
forward-addr: <IP address>
転送するサーバの IP アドレス。 IP 4 または IP 6 を指定できます。 DNS 通信のためのデフォルトでないポートを使用するために、ポート番号がある '@' を追加します。
forward-first: <yes または no>
有効にされるなら、問い合わせは、それが失敗するなら、転送節なしで試みられます。データを検索することができないかもしれないし、サーバが到達可能でないので、 SERVFAIL を引き起こしていたでしょう、代わりに、この節なしで試みられます。デフォルトは、no です。

Python モジュールオプション

python: 節は、 python(1) スクリプトモジュールのための設定を与えます。このモジュールは、問い合わせと答えで、反復子と検証ソフトのモジュールのように動作します。スクリプトモジュールを有効にするために、それは、デーモンにコンパイルされなければならず、単語 "python"は、(通常、最初に、または検証ソフトと反復子の間で) module-config: オプションに置かなければなりません。
python-script: <python file>
ロードするスクリプトファイル。

メモリ制御使用例

下記の例の設定ので、メモリ使用量は、縮小されます。いくつかのサービスレベルは、より低く、顕著で非常に大きなデータと高い TCP のロードは、もはやサポートされません。非常に大きなデータと高い TCP ロードは、DNS に対して例外的です。 DNSSEC 検証は、有効にされ、単に信頼アンカを追加します。 3Mb 以上のメモリを使用するプログラムに関して、心配する必要がないなら、下記の例は、利用者向けではありません。 BSD-32 ビット上で、重い使用法の後に 30-40 Mb で最高に達する、完全なサービスを受信するためにデフォルトを使用します。


# メモリ使用量を縮小する設定の例
server:
num-threads: 1
outgoing-num-tcp: 1 # このは, TCP サービスを制限し, より少ない
# バッファを使用します.
incoming-num-tcp: 1
outgoing-range: 60 # より少ないメモリを使用しますが, より少ない
# 性能となります.
msg-buffer-size: 8192 # これは, サービス 'no huge stuff' を
# 制限することに注意してください.
msg-cache-size: 100k
msg-cache-slabs: 1
rrset-cache-size: 100k
rrset-cache-slabs: 1
infra-cache-numhosts: 200
infra-cache-slabs: 1
key-cache-size: 100k
key-cache-slabs: 1
neg-cache-size: 10k
num-queries-per-thread: 30
target-fetch-policy: "2 1 0 0 0 0"
harden-large-queries: "yes"
harden-short-bufsize: "yes"

関連ファイル

/var/unbound
デフォルトの unbound 作業ディレクトリ。
/var/unbound
デフォルトの chroot(2) 位置。
/var/unbound/unbound.conf
unbound の設定ファイル。
/var/unbound/unbound.pid
実行しているデーモンのプロセス ID があるデフォルトの pidfile。
unbound.log
unbound ログファイル。デフォルトは、 syslog(3) にログ記録することです。

関連項目

unbound(8), unbound-checkconf(8)

作者

unbound は、NLnet Labs によって書かれました。より詳細については、配布の CREDITS ファイルを参照してください。
March 21, 2013 NLnet Labs