Unboundのソースを表示

[[Category:Domain Name System]]
[[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]