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 5th. On July 1st 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 one of our previous blog articles, we discussed 10 reasons to use 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

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

svn co http://unbound.nlnetlabs.nl/svn/trunk unbound
cd 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-setup
setup in directory /usr/local/etc/unbound
generating unbound_server.key
Generating RSA private key, 1536 bit long modulus
................++++
........................++++
e is 65537 (0x10001)
generating unbound_control.key
Generating 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 ok
subject=/CN=unbound-control
Getting CA Private Key
Setup success. Certificates created. Enable in unbound.conf file to use

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 jail 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.

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 BA3A7F42
.      IN DS 28567 5 1 1C625C7017299CEF715E19F62D5E210EA6E96D9D
.      IN 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 DCED635B6D0033D3AEC4D9A9A23F28EE38273A01
arpa. IN DS 46793 5 2 1BA7AADC6E73DC2CFBFA252393EDFB387768FF180A68C3D52B8A48A4 1E86787A

Operating the Unbound DNS Server

At this point, we should be able to start our 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 /usr/local/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: iterator
www.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.

URL	Indicator	Description
http://www.dnssec.cz		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 1st, 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.