「Unbound」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(en:Unboundへの転送ページ)
 
1行目: 1行目:
  +
[[Category:Domain Name System]]
−
#redirect[[en:Unbound]]
  
  +
[[en:Unbound]]
  +
[[zh-cn:Unbound]]
  +
[https://unbound.net/ Unbound] は検証をおこなったり再帰・キャッシュをする DNS リゾルバです。
  +
  +
== インストール ==
  +
  +
[[公式リポジトリ]]から {{Pkg|unbound}} パッケージをインストールしてください。
  +
  +
さらに、[[DNSSEC]] 検証をするには {{Pkg|expat}} が必要です。
  +
  +
== 設定 ==
  +
  +
''unbound'' の設定は簡単です。サンプル設定ファイル {{ic|/etc/unbound/unbound.conf.example}} が存在するので {{ic|/etc/unbound/unbound.conf}} にコピーして、必要に応じて修正を加えるだけで、IPv4 と IPv6 の両方で動作させることができます。
  +
  +
=== アクセス制御 ===
  +
  +
IP アドレスによってクエリに応答するインターフェイスを指定できます。''localhost'' で listen するには、以下を使用:
  +
  +
interface: 127.0.0.1
  +
  +
全てのインターフェイスで listen するには、以下を使用:
  +
  +
interface: 0.0.0.0
  +
  +
{{ic|access-control}} オプションを使うことでさらに細かくアクセスを設定できます:
  +
  +
access-control: ''subnet'' ''action''
  +
  +
例:
  +
  +
access-control: 192.168.1.0/24 allow
  +
  +
''action'' は {{ic|deny}} (drop message), {{ic|refuse}} (polite error reply), {{ic|allow}} (recursive ok), {{ic|allow_snoop}} (recursive and nonrecursive ok) のどれかに置き換えます。デフォルトでは、ローカルホスト以外の全てが拒否されます。
  +
  +
=== ルートヒント ===
  +
  +
アドレスがキャッシュされていないホストを問い合わせられた場合、リゾルバはサーバーツリーの一番上からルートサーバーに問い合わせて、アドレスを問い合わせることができるトップレベルドメインの場所を知る必要があります。したがって、''unbound'' の設定ディレクトリに''ルートヒント''ファイルを配置しなければなりません。以下のコマンドを実行するのが一番シンプルな方法です:
  +
  +
{{bc|<nowiki># curl -o /etc/unbound/root.hints https://www.internic.net/domain/named.cache</nowiki>}}
  +
  +
ルートサーバーのリストを最新にするために、上記のコマンドは6ヶ月ごとに実行すると良いでしょう。手動で実行してもかまいませんが、[[cron]] ジョブでタスクを設定する方法もあります。
  +
  +
''unbound'' から {{ic|root.hints}} ファイルの場所を設定してください:
  +
  +
root-hints: "/etc/unbound/root.hints"
  +
  +
=== ローカル DNS サーバーを使うように /etc/resolv.conf を設定 ===
  +
  +
{{ic|/etc/resolv.conf}} を編集 ([[resolv.conf]] を見て下さい):
  +
  +
nameserver 127.0.0.1
  +
  +
Also if you want to be able to use the hostname of local machine names without the fully qualified domain names, then add a line with the local domain such as:
  +
  +
domain localdomain.com
  +
nameserver 127.0.0.1
  +
  +
That way you can refer to local hosts such as mainmachine1.localdomain.com as simply mainmachine1 when using the ssh command, but the drill command below still requires the fully qualified domain names in order to perform lookups.
  +
  +
Testing the server before making it default can be done using the drill command from the {{Pkg|ldns}} package with examples from internal and external forward and reverse addresses:
  +
  +
$ drill @127.0.0.1 www.cnn.com
  +
$ drill @127.0.0.1 localmachine.localdomain.com
  +
$ drill @127.0.0.1 -x w.x.y.z
  +
  +
where {{ic|w.x.y.z}} can be a local or external IP address and the {{ic|-x}} option requests a reverse lookup. Once all is working, and you have {{ic|/etc/resolv.conf}} set to use {{ic|127.0.0.1}} as the nameserver then you no longer need the {{ic|@127.0.0.1}} in the ''drill'' command, and you can test again that it uses the default DNS server - check that the server used as listed at the bottom of the output from each of these commands shows it is {{ic|127.0.0.1}} being queried.
  +
  +
=== ログ出力 ===
  +
  +
If you will want logging for ''unbound'', then create a log file which can also be in the same directory, but you can choose any location. One way is then to do as root:
  +
  +
# touch /etc/unbound/unbound.log
  +
# chown unbound:unbound /etc/unbound/unbound.log
  +
  +
Then you can include the logging parameter when you set up the main {{ic|unbound.conf}} file as below.
  +
  +
=== DNSSEC 検証 ===
  +
  +
You will need the root server trust key anchor file. It is provided by the {{Pkg|dnssec-anchors}} package (already installed as a dependency), however, ''unbound'' needs read and write access to the file. The {{ic|unbound.service}} service accomplishes this by copying the {{ic|/etc/trusted-key.key}} file to {{ic|/etc/unbound/trusted-key.key}}. You just need to point ''unbound'' to this file:
  +
{{hc|/etc/unbound/unbound.conf|
  +
server:
  +
...
  +
trust-anchor-file: trusted-key.key
  +
...
  +
}}
  +
  +
Also make sure that if a general [[#Forwarding queries|forward]] to the Google servers had been in place, then comment them out otherwise DNS queries will fail. DNSSEC validation will be done if the DNS server being queried supports it.
  +
  +
{{Note|Including DNSSEC checking significantly increases DNS lookup times for initial lookups. Once an address is cached locally, then the lookup is virtually instantaneous.}}
  +
  +
{{Pkg|ldns}} (依存パッケージとしてインストールされます) の ''drill'' を使って DNSSEC が機能しているかテストできます:
  +
  +
drill sigfail.verteiltesysteme.net # should return rcode: SERVFAIL
  +
drill sigok.verteiltesysteme.net # should return rcode: NOERROR
  +
  +
=== クエリの転送 ===
  +
  +
If you have a local network which you wish to have DNS queries for and there is a local DNS server that you would like to forward queries to then you should include this line:
  +
  +
private-address: ''local_subnet/subnet_mask''
  +
  +
例:
  +
  +
private-address: 10.0.0.0/24
  +
  +
{{note|You can use private-address to protect against DNS Rebind attacks. Therefore you may enable RFC1918 networks (10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 fd00::/8 fe80::/10). Unbound may enable this feature by default in future releases.}}
  +
  +
To include a local DNS server for both forward and reverse local addresses a set of lines similar to these below is necessary with a forward and reverse lookup (choose the IP address of the server providing DNS for the local network accordingly by changing 10.0.0.1 in the lines below):
  +
  +
local-zone: "10.in-addr.arpa." transparent
  +
  +
This line above is important to get the reverse lookup to work correctly.
  +
  +
forward-zone:
  +
name: "mynetwork.com."
  +
forward-addr: 10.0.0.1 # Home DNS
  +
  +
forward-zone:
  +
name: "10.in-addr.arpa."
  +
forward-addr: 10.0.0.1
  +
  +
{{Note|There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a [[BIND]] DNS server if it is providing authoritative DNS - but if you are referring queries to an ''unbound'' server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.}}
  +
  +
You can set up the localhost forward and reverse lookups with the following lines:
  +
  +
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-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. 2 3600 1200 604800 10800"
  +
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."
  +
  +
Then to use specific servers for default forward zones that are outside of the local machine and outside of the local network (i.e. all other queries will be forwarded to them, and then cached) add this to the configuration file (and in this example the first two addresses are the fast google DNS servers):
  +
  +
forward-zone:
  +
name: "."
  +
forward-addr: 8.8.8.8
  +
forward-addr: 8.8.4.4
  +
forward-addr: 208.67.222.222
  +
forward-addr: 208.67.220.220
  +
  +
This will make ''unbound'' use Google and OpenDNS servers as the forward zone for external lookups.
  +
  +
{{Note|OpenDNS strips DNSSEC records from responses. Do not use the above forward zone if you want to enable [[#DNSSEC validation]].}}
  +
  +
== 使用方法 ==
  +
  +
=== Unbound の起動 ===
  +
  +
''unbound'' パッケージには {{ic|unbound.service}} が入っているので、[[起動]]してください。ブート時に起動させたいときは[[有効化]]します。
  +
  +
=== Unbound の遠隔操作 ===
  +
  +
''unbound'' には {{ic|unbound-control}} ユーティリティが付いており、リモートの unbound サーバーを管理することができます。{{Pkg|pdnsd}} の [[Pdnsd#pdnsd-ctl|pdnsd-ctl]] コマンドに似ています。
  +
  +
==== unbound-control の設定 ====
  +
  +
使用する前に、以下の設定が必要です:
  +
  +
1) まず、以下のコマンドを実行してください:
  +
  +
# unbound-control-setup
  +
  +
自己署名証明書とサーバーとクライアントの秘密鍵が生成されます。これらのファイルは {{ic|/etc/unbound}} ディレクトリに保存されます。
  +
  +
2) その後、{{ic|/etc/unbound/unbound.conf}} を編集して以下の内容を記述してください。{{ic|control-enable: yes}} オプションは必須ですが、他のオプションは必要に応じて変更できます。
  +
  +
remote-control:
  +
# Enable remote control with unbound-control(8) here.
  +
# set up the keys and certificates with unbound-control-setup.
  +
control-enable: yes
  +
  +
# what interfaces are listened to for remote control.
  +
# give 0.0.0.0 and ::0 to listen to all interfaces.
  +
control-interface: 127.0.0.1
  +
  +
# port number for remote control operations.
  +
control-port: 8953
  +
  +
# unbound server key file.
  +
server-key-file: "/etc/unbound/unbound_server.key"
  +
  +
# unbound server certificate file.
  +
server-cert-file: "/etc/unbound/unbound_server.pem"
  +
  +
# unbound-control key file.
  +
control-key-file: "/etc/unbound/unbound_control.key"
  +
  +
# unbound-control certificate file.
  +
control-cert-file: "/etc/unbound/unbound_control.pem"
  +
  +
==== unbound-control を使う ====
  +
  +
''unbound-control'' で使用できるコマンドの例:
  +
  +
* 再設定しないで統計を出力
  +
# unbound-control stats_noreset
  +
  +
* キャッシュを標準出力にダンプ
  +
# unbound-control dump_cache
  +
  +
* キャッシュを消去して設定をリロード
  +
# unbound-control reload
  +
  +
詳しくは {{ic|man 8 unbound-control}} を参照してください。
  +
  +
== Adding an authoritative DNS server ==
  +
  +
For users who wish to run both a validating, recursive, caching DNS server as well as an authoritative DNS server on a single machine then it may be useful to refer to the wiki page [[en2:nsd|nsd]] which gives an example of a configuration for such a system. Having one server for authoritative DNS queries and a separate DNS server for the validating, recursive, caching DNS functions gives increased security over a single DNS server providing all of these functions. Many users have used bind as a single DNS server, and some help on migration from bind to the combination of running nsd and bind is provided in the [[en2:nsd|nsd]] wiki page.
  +
  +
== WAN と DNS ==
  +
  +
It is also possible to change the configuration files and interfaces on which the server is listening so that DNS queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with suitable port forwarding on firewall machines to forward incoming requests to the right machine.
  +
  +
== num-threads の問題 ==
  +
  +
The man page for {{ic|unbound.conf}} mentions:
  +
  +
outgoing-range: <number>
  +
Number of ports to open. This number of file descriptors can be opened per thread.
  +
  +
and some sources suggest that the {{ic|num-threads}} parameter should be set to the number of cpu cores. The sample {{ic|unbound.conf.example}} file merely has:
  +
  +
# number of threads to create. 1 disables threading.
  +
# num-threads: 1
  +
  +
However it is not possible to arbitrarily increase {{ic|num-threads}} above {{ic|1}} without causing ''unbound'' to start with warnings in the logs about exceeding the number of file descriptors. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing {{ic|num-threads}} above {{ic|1}}. If you do wish to do so then refer to [http://www.unbound.net/documentation/howto_optimise.html official documentation] and the following rule of thumb should work:
  +
  +
:''Set {{ic|num-threads}} equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.''
  +
  +
Set the {{ic|outgoing-range}} to as large a value as possible, see the sections in the referred web page above on how to overcome the limit of {{ic|1024}} in total. This services more clients at a time. With 1 core, try {{ic|950}}. With 2 cores, try {{ic|450}}. With 4 cores try {{ic|200}}. The {{ic|num-queries-per-thread}} is best set at half the number of the {{ic|outgoing-range}}.
  +
  +
Because of the limit on {{ic|outgoing-range}} thus also limits {{ic|num-queries-per-thread}}, it is better to compile with {{Pkg|libevent}}, so that there is no {{ic|1024}} limit on {{ic|outgoing-range}}. If you need to compile this way for a heavy duty DNS server then you will need to compile the programme from source instead of using the {{Pkg|unbound}} package.
  +
  +
== 参照 ==
  +
  +
* [https://github.com/jodrell/unbound-block-hosts/ Block hosts that contain advertisements]

2015年12月23日 (水) 21:47時点における版

Unbound は検証をおこなったり再帰・キャッシュをする DNS リゾルバです。

インストール

公式リポジトリから unbound パッケージをインストールしてください。

さらに、DNSSEC 検証をするには expat が必要です。

設定

unbound の設定は簡単です。サンプル設定ファイル /etc/unbound/unbound.conf.example が存在するので /etc/unbound/unbound.conf にコピーして、必要に応じて修正を加えるだけで、IPv4 と IPv6 の両方で動作させることができます。

アクセス制御

IP アドレスによってクエリに応答するインターフェイスを指定できます。localhost で listen するには、以下を使用: 

interface: 127.0.0.1

全てのインターフェイスで listen するには、以下を使用: 

interface: 0.0.0.0

access-control オプションを使うことでさらに細かくアクセスを設定できます: 

access-control: subnet action

例: 

access-control: 192.168.1.0/24 allow

action は deny (drop message), refuse (polite error reply), allow (recursive ok), allow_snoop (recursive and nonrecursive ok) のどれかに置き換えます。デフォルトでは、ローカルホスト以外の全てが拒否されます。

ルートヒント

アドレスがキャッシュされていないホストを問い合わせられた場合、リゾルバはサーバーツリーの一番上からルートサーバーに問い合わせて、アドレスを問い合わせることができるトップレベルドメインの場所を知る必要があります。したがって、unbound の設定ディレクトリにルートヒントファイルを配置しなければなりません。以下のコマンドを実行するのが一番シンプルな方法です: 

# curl -o /etc/unbound/root.hints https://www.internic.net/domain/named.cache

ルートサーバーのリストを最新にするために、上記のコマンドは6ヶ月ごとに実行すると良いでしょう。手動で実行してもかまいませんが、cron ジョブでタスクを設定する方法もあります。

unbound から root.hints ファイルの場所を設定してください: 

root-hints: "/etc/unbound/root.hints"

ローカル DNS サーバーを使うように /etc/resolv.conf を設定

/etc/resolv.conf を編集 (resolv.conf を見て下さい): 

nameserver 127.0.0.1

Also if you want to be able to use the hostname of local machine names without the fully qualified domain names, then add a line with the local domain such as: 

domain localdomain.com
nameserver 127.0.0.1

That way you can refer to local hosts such as mainmachine1.localdomain.com as simply mainmachine1 when using the ssh command, but the drill command below still requires the fully qualified domain names in order to perform lookups.

Testing the server before making it default can be done using the drill command from the ldns package with examples from internal and external forward and reverse addresses: 

$ drill @127.0.0.1 www.cnn.com
$ drill @127.0.0.1 localmachine.localdomain.com
$ drill @127.0.0.1 -x w.x.y.z

where w.x.y.z can be a local or external IP address and the -x option requests a reverse lookup. Once all is working, and you have /etc/resolv.conf set to use 127.0.0.1 as the nameserver then you no longer need the @127.0.0.1 in the drill command, and you can test again that it uses the default DNS server - check that the server used as listed at the bottom of the output from each of these commands shows it is 127.0.0.1 being queried.

ログ出力

If you will want logging for unbound, then create a log file which can also be in the same directory, but you can choose any location. One way is then to do as root: 

# touch /etc/unbound/unbound.log
# chown unbound:unbound /etc/unbound/unbound.log

Then you can include the logging parameter when you set up the main unbound.conf file as below.

DNSSEC 検証

You will need the root server trust key anchor file. It is provided by the dnssec-anchors package (already installed as a dependency), however, unbound needs read and write access to the file. The unbound.service service accomplishes this by copying the /etc/trusted-key.key file to /etc/unbound/trusted-key.key. You just need to point unbound to this file: 

/etc/unbound/unbound.conf
server:
  ...
  trust-anchor-file: trusted-key.key
  ...

Also make sure that if a general forward to the Google servers had been in place, then comment them out otherwise DNS queries will fail. DNSSEC validation will be done if the DNS server being queried supports it.

ノート: Including DNSSEC checking significantly increases DNS lookup times for initial lookups. Once an address is cached locally, then the lookup is virtually instantaneous.

ldns (依存パッケージとしてインストールされます) の drill を使って DNSSEC が機能しているかテストできます: 

drill sigfail.verteiltesysteme.net # should return rcode: SERVFAIL
drill sigok.verteiltesysteme.net   # should return rcode: NOERROR

クエリの転送

If you have a local network which you wish to have DNS queries for and there is a local DNS server that you would like to forward queries to then you should include this line: 

private-address: local_subnet/subnet_mask

例: 

private-address: 10.0.0.0/24
ノート: You can use private-address to protect against DNS Rebind attacks. Therefore you may enable RFC1918 networks (10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 fd00::/8 fe80::/10). Unbound may enable this feature by default in future releases.

To include a local DNS server for both forward and reverse local addresses a set of lines similar to these below is necessary with a forward and reverse lookup (choose the IP address of the server providing DNS for the local network accordingly by changing 10.0.0.1 in the lines below): 

local-zone: "10.in-addr.arpa." transparent

This line above is important to get the reverse lookup to work correctly. 

forward-zone:
name: "mynetwork.com."
forward-addr: 10.0.0.1        # Home DNS

forward-zone:
name: "10.in-addr.arpa."
forward-addr: 10.0.0.1
ノート: There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a BIND DNS server if it is providing authoritative DNS - but if you are referring queries to an unbound server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.

You can set up the localhost forward and reverse lookups with the following lines: 

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-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. 2 3600 1200 604800 10800"
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."

Then to use specific servers for default forward zones that are outside of the local machine and outside of the local network (i.e. all other queries will be forwarded to them, and then cached) add this to the configuration file (and in this example the first two addresses are the fast google DNS servers): 

forward-zone:
  name: "."
  forward-addr: 8.8.8.8
  forward-addr: 8.8.4.4
  forward-addr: 208.67.222.222
  forward-addr: 208.67.220.220

This will make unbound use Google and OpenDNS servers as the forward zone for external lookups.

ノート: OpenDNS strips DNSSEC records from responses. Do not use the above forward zone if you want to enable #DNSSEC validation.

使用方法

Unbound の起動

unbound パッケージには unbound.service が入っているので、起動してください。ブート時に起動させたいときは有効化します。

Unbound の遠隔操作

unbound には unbound-control ユーティリティが付いており、リモートの unbound サーバーを管理することができます。pdnsd の pdnsd-ctl コマンドに似ています。

unbound-control の設定

使用する前に、以下の設定が必要です:

1) まず、以下のコマンドを実行してください: 

# unbound-control-setup

自己署名証明書とサーバーとクライアントの秘密鍵が生成されます。これらのファイルは /etc/unbound ディレクトリに保存されます。

2) その後、/etc/unbound/unbound.conf を編集して以下の内容を記述してください。control-enable: yes オプションは必須ですが、他のオプションは必要に応じて変更できます。 

remote-control:
    # Enable remote control with unbound-control(8) here.
    # set up the keys and certificates with unbound-control-setup.
    control-enable: yes
   
    # what interfaces are listened to for remote control.
    # give 0.0.0.0 and ::0 to listen to all interfaces.
    control-interface: 127.0.0.1
   
    # port number for remote control operations.
    control-port: 8953
   
    # unbound server key file.
    server-key-file: "/etc/unbound/unbound_server.key"
   
    # unbound server certificate file.
    server-cert-file: "/etc/unbound/unbound_server.pem"
   
    # unbound-control key file.
    control-key-file: "/etc/unbound/unbound_control.key"
   
    # unbound-control certificate file.
    control-cert-file: "/etc/unbound/unbound_control.pem"

unbound-control を使う

unbound-control で使用できるコマンドの例:

  • 再設定しないで統計を出力
 # unbound-control stats_noreset
  • キャッシュを標準出力にダンプ
 # unbound-control dump_cache
  • キャッシュを消去して設定をリロード
 # unbound-control reload

詳しくは man 8 unbound-control を参照してください。

Adding an authoritative DNS server

For users who wish to run both a validating, recursive, caching DNS server as well as an authoritative DNS server on a single machine then it may be useful to refer to the wiki page nsd which gives an example of a configuration for such a system. Having one server for authoritative DNS queries and a separate DNS server for the validating, recursive, caching DNS functions gives increased security over a single DNS server providing all of these functions. Many users have used bind as a single DNS server, and some help on migration from bind to the combination of running nsd and bind is provided in the nsd wiki page.

WAN と DNS

It is also possible to change the configuration files and interfaces on which the server is listening so that DNS queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with suitable port forwarding on firewall machines to forward incoming requests to the right machine.

num-threads の問題

The man page for unbound.conf mentions: 

     outgoing-range: <number>
             Number of ports to open. This number of file  descriptors  can  be  opened  per thread.

and some sources suggest that the num-threads parameter should be set to the number of cpu cores. The sample unbound.conf.example file merely has: 

       # number of threads to create. 1 disables threading.
       # num-threads: 1

However it is not possible to arbitrarily increase num-threads above 1 without causing unbound to start with warnings in the logs about exceeding the number of file descriptors. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing num-threads above 1. If you do wish to do so then refer to official documentation and the following rule of thumb should work:

Set num-threads equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.

Set the outgoing-range to as large a value as possible, see the sections in the referred web page above on how to overcome the limit of 1024 in total. This services more clients at a time. With 1 core, try 950. With 2 cores, try 450. With 4 cores try 200. The num-queries-per-thread is best set at half the number of the outgoing-range.

Because of the limit on outgoing-range thus also limits num-queries-per-thread, it is better to compile with libevent, so that there is no 1024 limit on outgoing-range. If you need to compile this way for a heavy duty DNS server then you will need to compile the programme from source instead of using the unbound package.

参照

「https://wiki.archlinux.jp/index.php?title=Unbound&oldid=4459」から取得