End-to-End DNSSEC using Unbound DNS

Given all the hoopla surrounding the topic of DNSSEC, it's definitely time to get prepared for it.  After all, the last of the root name servers ( J-ROOT ) will all be serving a Deliberately Unvalidatable Root Zone or (DURZ) by May 5^th.

On July 1^st however, there will be distribution of a validatable, production, signed root zone. Signing of the root zone is key for creating the "chain of trust" or a secure delegation hierarchy.   DNSSEC securely signed zones vouch for their children's keys, but some higher level entity must vouch for the keys of these zones.  The signing of the root will act as a trust anchor for top-level domains such as .com, .edu, etc.  These zones will trust on down the hierarchy when configured to do so.

Please see http://www.root-dnssec.org/documentation/ for details on the DNSSEC Signing of the root name servers.  In the last article, we discussed 10 reasons to use the Unbound DNS Server.  One of Unbound's main capabilities is its ability to perform DNSSEC validation.  So, we thought we'd write an article explaining how you can setup the Unbound DNS server to perform DNSSEC validation as part of an end-to-end example of how DNSSEC works.

Installing Unbound DNS

For the purposes of this exercise, we installed Unbound on the Fedora 12 distribution.  A minimal install of the base 200 packages or RPMs was performed. Given the option of installing from source code or pre-built binaries, we opted to install from source to ensure the latest version of Unbound DNS software was used.  The following prerequisites were required for building Unbound:

yum install subversion
yum install libevent libevent-devel
yum install openssl openssl-devel
yum install gcc make

NOTE:
Linux package names and their versions will vary between different Linux distributions, so you should consult your distribution’s package repositories and documentation prior to preparing to configure, build, and install Unbound.

Following the installation of the above dependencies, build Unbound from source as follows:

svn co http://unbound.nlnetlabs.nl/svn/trunk unboundcd unbound./configure && make && make install

Once Unbound is configured, built and installed from source, enable the remote management component. A set of self-signed SSL keys are installed into the /usr/local/etc/unbound directory that will allow us to control the Unbound DNS server.  This is performed using the unbound-control-setup as shown:

# unbound-control-setupsetup in directory /usr/local/etc/unboundgenerating unbound_server.keyGenerating RSA private key, 1536 bit long modulus................++++........................++++e is 65537 (0x10001)generating unbound_control.keyGenerating RSA private key, 1536 bit long modulus................................................................++++..++++e is 65537 (0x10001)create unbound_server.pem (self signed certificate)create unbound_control.pem (signed client certificate)Signature oksubject=/CN=unbound-controlGetting CA Private KeySetup success. Certificates created. Enable in unbound.conf file to use

NOTE: For the purposes of this demonstration, we chose to install from source code.  Production servers should never have development libraries, compilers, and build tools installed, so it's strongly recommended that you do not build software on the same systems that are targeted for production.

Configuring Unbound

We'll start by using a minimal configuration of Unbound which launches unbound in a chroot owned and run as the user unbound:unbound.  The following is a basic configuration for setting up the Unbound DNS server:

server:
verbosity: 1        interface: 127.0.0.1        interface: 192.168.0.101        access-control: 192.168.0.0/16 allow        chroot: "/usr/local/etc/unbound"        username: "unbound"        directory: "/usr/local/etc/unbound"        pidfile: "/usr/local/etc/unbound/unbound.pid"        root-hints: "root-hints.txt"
remote-control:
control-enable: yes        control-interface: 127.0.0.1        control-port: 953        server-key-file: "/usr/local/etc/unbound/unbound_server.key"        server-cert-file:"/usr/local/etc/unbound/unbound_server.pem"        control-key-file:"/usr/local/etc/unbound/unbound_control.key"        control-cert file:"/usr/local/etc/unbound/unbound_control.pem"

In our configuration we specify the interface directive to bind the DNS service to the loopback and primary Ethernet (eth0) interface on our system. The access-control directive configures an Access Control List of sorts by defining and allowing an address range to query our name server with recursive queries.NOTE: it is also important to ensure that if you are running iptables, that you include udp/53 and tcp/53 inbound rules so that remote client workstations can query the name server. In writing this blog, we ended up adding the following rules to /etc/sysconfig/iptables:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

While it is true that you can run the Unbound DNS server without having to configure the root-hints, we will use this directive in the server section because we want to force our server to use special DNSSEC Demo root name servers operated by IANA which have a signed copy of the root zone. Create the root-hints.txt file in /usr/local/etc/unbound and populate it by using the data from the following link: https://ns.iana.org/dnssec/dnssec.hint.txt. Make sure it is owned by the unbound:unbound user.

Enabling DNSSEC In Unbound

There are numerous ways to configure and enable DNSSEC validation in Unbound:

1. Use trust-anchor to directly embed DS and/or DNSKEY records in the unbound.conf file
2. Use trust-anchor-file for supplying large numbers of DS and/or DNSKEY records using include or trust anchor files
3. Use auto-trust-anchor-file to specify RFC 5011 style auto-updatable trust anchor files for specific zone(s)
4. Use trusted-keys-file directive for supporting a Bind 9 style formatted trusted-keys block
5. Use dlv-anchor-file to specify DS and/or DNSKEY records for DNSSEC Lookaside Validation or DLV (dlv.isc.org)

Since this is an introduction to end-to-end testing, we demonstrate how to enable DNSSEC validation using the auto-trust-anchor-file directive in the server block of the configuration. For production installations of Unbound, it is highly recommended to either use RFC 5011 style auto-update of trust anchors (supported by the auto-trust-anchor-file directive), or to use DLV (dlv.isc.org) as mentioned above.

To configure the Unbound server with the auto-trust-anchor-file, create one (1) trust anchor file per zone, and populate that trust anchor file with only those DS or DNSKEY records that are associated with that zone. Make sure that the key material is up to date and is valid before you begin. Start by creating the file /usr/local/etc/unbound/root-ta.txt, and populate it with the DS record set found at https://ns.iana.org/dnssec/dsset-.  Next, create the file /usr/local/etc/unbound/arpa-ta.txt, and populate it with the DS record set found at https://ns.iana.org/dnssec/dsset-arpa. Ensure that both of these files are owned by the unbound user with read/write permissions.

Additional details about the IANA Demo DNSSEC environment and key material can be found at https://ns.iana.org/dnssec/status.html

Our final Unbound configuration should look like this when using the DS record format for the trusted-key directive:

server:
verbosity: 1        interface: 127.0.0.1        interface: 192.168.0.101        access-control: 192.168.0.0/16 allow        chroot: "/usr/local/etc/unbound"        username: "unbound"        directory: "/usr/local/etc/unbound"        pidfile: "/usr/local/etc/unbound/unbound.pid"        root-hints: "root-hints.txt"        auto-trust-anchor-file: "root-ta.txt"        auto-trust-anchor-file: "arpa-ta.txt"
remote-control:
control-enable: yes        control-interface: 127.0.0.1        control-port: 953        server-key-file: "/usr/local/etc/unbound/unbound_server.key"        server-cert-file: "/usr/local/etc/unbound/unbound_server.pem"        control-key-file: "/usr/local/etc/unbound/unbound_control.key"        control-cert-file: "/usr/local/etc/unbound/unbound_control.pem"

The contents of the /usr/local/etc/unbound/root-ta.txt file should appear like the following

IN DS 25546 5 1 EB79CCBB73DF86E527F2BD7DEDCBE083F6024E62 IN DS 25546 5 2 8C820F26C36215C94DC1797AB44E9E9C04B8FCA49CCC6E72BE26DCF2 BA3A7F42IN DS 28567 5 1 1C625C7017299CEF715E19F62D5E210EA6E96D9DIN DS 28567 5 2 9610F9726A508AE8AC3B8D07887DFB5EC09804FF7B159A7352AB84A6 B468B08C

The contents of the /usr/local/etc/unbound/arpa-ta.txt file should appear like the following:

arpa. IN DS 13589 5 1 5FCEEA550A000E2EE9F1365ACC9A7D12A95E3679 arpa. IN DS 13589 5 2 1866807648777CACAE3D0006C2CEABFDBA9CBCC664DB739E615E7BEA 35197DD7
arpa. IN DS 46793 5 1 DCED635B6D0033D3AEC4D9A9A23F28EE38273A01arpa. IN DS 46793 5 2 1BA7AADC6E73DC2CFBFA252393EDFB387768FF180A68C3D52B8A48A4 1E86787A

Operating the Unbound DNS Server

At this point, we should be able to start the Unbound recursive, caching, and validating name server. To start the server, run the following command:unbound-control start

To check that the server has started and get its status:

unbound-control status

To stop the running Unbound DNS server:

unbound-control stop

A handy utility called unbound-host is provided that uses the libunbound library just as our Unbound DNS server does to test resolution and validation. It requires the -C command line argument enabling it to use the same unbound.conf file as the server uses.  Let's check to see if we're getting successful resolution and DNSSEC validation:

#  unbound-host -C /etc/unbound/unbound.conf www.nic.cz. -v[1272999684] libunbound[12835:0] notice: init module 0: validator[1272999684] libunbound[12835:0] notice: init module 1: iteratorwww.nic.cz. has address 217.31.205.50 (secure)www.nic.cz. has IPv6 address 2001:1488:0:3::2 (secure)www.nic.cz. has no mail handler record (secure)

Alternatively, we could issue queries to our Unbound Server using dig with the +dnssec option and check the response from our Unbound Server.  If the response from Unbound returns AD in the flags section of the reply message, we have established that the data was authentic.  If you achieve these same results, then you've successfully configured a recursive validating server with Unbound! Congratulations.

End-to-End DNSSEC Validation

To complete an end-to-end test of DNSSEC validation, we thought we'd recommend using the Mozilla Firefox browser, along with a DNSSEC validation Add-on to demonstrate how DNSSEC validation will be supported in the future. We installed the DNSSEC Validator version 0.15.1alpha using the latest version of the Mozilla Firefox browser. You can obtain the add-on by navigating to http://www.dnssec-validator.cz/. There is a link to perform the installation on that page. Once installed, modify the Validator's Preferences.

Modify the settings so that the Resolver used by the Add-on is defined using the IP address of our Unbound DNS validating resolver.  In our example, we show the add-on to be configured with 192.168.0.101, the IP address we assigned to our Unbound server.  Click OK and save the configuration.
Test the following URLS in the table shown below.  You should get the same Indicator as shown for each of the URLs.  The indicator will appear immediately to the left of the URL in the URL/Address entry field.

The domain name is secure using DNSSEC technology and the integrity of the DNS Response has not been breached during transmission.  The browser uses IP addresses that have been validated by DNSSEC Validator using DNSSEC and are trusted.

http://napul.cz

The domain name is secured with DNSSEC technology, but the DNS server resolver used cannot verify the signature validity.

http://www.rhybar.cz

WARNING! The domain name is secured by DNSSEC technology but the IP addresses to which your browser is connecting have been changed, or the DNSSEC signature validity was broken. The IP address could have been changed during transmission to your computer by an unknown attacker, or it may be a local settings conflict on your computer.

These are just a few URLs to get you started, with known results.  Safely surf the web now, and try some of your old Internet haunts.  See who's signing and who's not.  See who has been potentially compromised, and whose zone(s) are invalid or improperly signed.

This blog entry was written to demonstrate how DNSSEC works end-to-end using the Unbound DNS Server to provide recursive caching and validating DNS service.  Come July 1^st, the production root name servers on the Internet will be fully signed, and the next big phase of DNSSEC will begin, the Adoption Phase.  It is during this cycle of DNSSEC rollout that the TLDs like .com and .edu will be signed. Additionally, we'll begin to see more and more ISPs offering DNSSEC signing for customers to have their own zones signed.  
Widespread adoption will require more add-ons like the one we demonstrated in the latter part of the article, as well as, having more tools, applications, and operating systems with built-in DNSSEC validators. If you haven't worked with Unbound, we urge you to do so.  
Unbound is very lightweight, high-performing, and easy to configure.  It brings software diversity to the DNS monoculture that has been primarily owned by the ISC's BIND software.  Every ISP and/or Enterprise should consider incorporating Unbound into future deployments of DNS serving software and especially when DNSSEC widespread adoption takes hold.

Men&Mice is now offering enterprise grade support for the Unbound DNS Server.

Take a look at the Men&Mice Unbound Support Contracts