Unbound is a validating, recursive, and caching DNS resolver.
Install DNSSEC:, and which is dependency for
pacman -S unbound expat
For querying a host that is not cached as an address the resolver needs to start at the top of the server tree and query the root servers to know where to go for the top level domain for the address being queried. Therefore it is necessary to put a "root hints" file into the unbound config directory. The simplest way to do this is to run the command:
wget ftp://FTP.INTERNIC.NET/domain/named.cache -O /etc/unbound/root.hints
It is a good idea to run this every six months or so in order to make sure the list of root servers is up to date. This can be done manually or by setting up a cron job for the task.
If you are going to use DNSSEC then you will need the root server trust key anchor in the file root.key which you is created in the same directory [/etc/unbound/] and make sure it is owned by user unbound.
The line below is the 2010 trust anchor for the root zone, and this line is the only line in the file root.key. You can independently verify the root zone anchor by going to the IANA.org Index of /root-anchors.
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
Once the file is created make unbound the owner:
# chown unbound:unbound /etc/unbound/root.key
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.
Unbound is easy to configure. Following configuration placed in /etc/unbound/unbound.conf is enough to run on both IPv4 and IPv6 without access restrictions. You can copy the unbound.conf.example file to unbound.conf and then uncomment lines or add in lines as needed:
server: username: "unbound" directory: "/etc/unbound" use-syslog: yes interface: 0.0.0.0 interface: ::0 verbosity: 1
For the case where you want the unbound server to listen to requests from the machine that it is running on then make sure that the line defining which address it is going to listen on is included:
It is also important to include a line to point to the root.hints file that was prepared before editing the unbound.conf file:
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 the line: private-address for say the 10. or 192.168. networks as:
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
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: "18.104.22.168.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: 22.214.171.124 forward-addr: 126.96.36.199 forward-addr: 188.8.131.52 forward-addr: 184.108.40.206
This will make unbound use Google and OpenDNS servers as the forward zone for external lookups.
Adding unbound to boot process
Start the service:
systemctl start unbound
Then enable it so that it starts at boot once you have tested that it works.
systemctl enable unbound
Set /etc/resolv.conf to use the local DNS server
/etc/resolv.conf (See also resolv.conf):
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.
Configuring Unbound to Validate DNSSEC
/etc/unbound/ directory to be owned by the unbound user:
chown unbound /etc/unbound
Fetch the root trust anchor:
sudo -u unbound unbound-anchor -a /etc/unbound/auto-root.key
Edit unbound.conf, adding the following line to the server: block:
systemctl restart unbound.service
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.