review the Stubby default configuration

Stubby testrun

This command will start Stubby on the commandline in foreground. This
is a test if the configuration is valid. After the test, terminate
Stubby with CTRL+C.

sudo /usr/local/bin/stubby -l

change stub-resolver configuration

Stubby is listening on port 53 on the loopback IP-Address for
DNS-queries from applications. The resolver configuration in
/etc/resolv.conf must point to the loopback address.

In this example a very direct way is used by re-writing
/etc/resolv.conf and making it immutable with an extended
attribute. In production environments, it is cleaner to change the
resolver information in Network-Manager

BIND 9.10 is the new version of the BIND 9 DNS server from ISC
http://isc.org (not to confuse with BIND 10, which is a different DNS
server product). I will report in a series of articles about the new
features in BIND 9.10. The first beta version of BIND 9.10 has been
released this week and can be found at
ftp://ftp.isc.org/isc/bind9/9.10.0b1/.

BIND 9.10 contains a new command-line tool to test DNSSEC
installations. The tool is called delve and it works very much like
the already know dig. It is like dig with special DNSSEC
validation powers.

delve checks the DNSSEC validation chain using the same code that is
used by the BIND 9 DNS server itself. Compared with the DNSSEC testing
function in dig +sigchase, delve is much closer to what really
happen inside a DNS server.

Without extra arguments, delve will query the local DNS server (taken
from /etc/resolv.conf) for an IPv4-Address record at the given domain
name. It tries to validate the answer received, prints the result of the
validation, the requested data and the RRSIG Record (DNSSEC signature)
used to verify the data.

1.2 pretty-printing

As with dig, resource record types and network classes can be given in
almost any order on the commandline. The switch +multi (for multiline)
enables pretty printing; human readable output that is nearly
formatted for a 78 column screen.

In this example, in addition to the MX-Record (Mail-Exchanger) Record,
the DNSKEY record (DNSSEC public key) and the DS record (Delegation
signer) for dnsworkshop.org, as well as the DNSKEY and DS records
for ORG and the DNSKEY for the root-zone "." have been
requested. The trust-anchor for the Internet Root-Zone is compiled
into delve and acts as the starting trust anchor for the validation.

The switch +mtrace prints the content of any additional DNS records
that have been fetched for validation.

Table of Contents

Why a local root zone

Sometimes I get this question in my DNSSEC training classes: "now
DNSSEC seems to be a good technology, but the root-zone is controlled
by the US government. Because of that, can we trust DNSSEC?".

My answer is not to mix technology (DNSSEC) with implementation (the
DNS system of the Internet).

Both are separate. While I can understand that some people do not
trust the organisations in control of the Internet DNS root-zone, I
see no flaw in DNSSEC (at this moment).

One way to solve the trust issue with the Internet root-zone is to
host your own root-zone for the Internet. Then you are in full control
of that zone. Have that zone in your own network, or on your Laptop
computer und use it for the starting.point of all DNSSEC validation
(the trust anchor) for DNS.

Besides the trust question, there might be another reason to operate a
local root-zone: some organisations have created an internal, private
top-level domain (TLD)1. A local, dnssec-signed root-zone enables
the operator to remove or add any delegations, while still being able
to validate all DNSSEC signed data in the Internet, as well as data
that is stored in their own private DNS namespace.

The following tutorial explains the steps required to generate a local
augmented and DNSSEC signed root-zone. The tutorial requires some
understanding of DNS concepts and basic knowledge on DNSSEC. A good
starting point to learn about DNSSEC (besides a training) is the book
DNSSEC mastery by Michael W. Lucas.

All the tools used are part of the BIND DNS Server for ISC (Internet
Systems Consortium). This tutorial has been tested using BIND
9.9.4-P1. Older or newer versions of BIND might require a different
setup.

The setup

We need one or more authoritative servers to host the augmented
root-zone. For production deployments in an internal network, at least
two authoritative servers are required. For a local root-zone on a
mobile device (Laptop etc.), one single authoritative server might be
good enough.

We also need at least one caching DNS server (smart resolver). This
cannot be the same DNS server instance as the authoritative server,
however it is possible to run both (caching and authoritative server)
on the same machine, but have them listen to different IP
addresses. In this tutorial, I will use two separate machines:

authoritative server: a.myroot-server.loc:192.0.2.53

caching server: cache.loc:192.0.2.153

On both servers, the BIND configuration file will be in
/etc/named.conf and the BIND "data" directory will be /var/named.

The official Internet root-zone authoritative servers have names in
the root-servers.net domain. As we do not have the private key for
that name, and we cannot enter a DS record (delegation signer) for our
internal root-server into the .net zone, we need to change the NS
records and the SOA record. In my example, the hostname of the local
root-server is in the myroot-servers.loc domain. That name is stored
inside the loc. TLD, which we will also host on our authoritative
server.

With an text editor, we change the SOA record and the NS record(s) to
point to our own authoritative servers. We also need to add proper
glue records for every hostname used in the NS records:

The -R switch removed all signatures created by the DNSSEC keys of
the real root zone. The -t switch prints out some benchmark
information. Your signing process is probably faster, as I tested
this on a Rasberry Pi.

the augmented ".loc" TLD-Zone

Below is the content of the zone-file for the .loc TLD zone. It
contains the same NS records as we have seen in the root-zone for the
delegation of the .loc zone:

The BIND configuration file

This is the BIND configuration file named.conf for the authoritative
server. It loads both the root-zone and the .loc private TLD. Both
zones are configured as dynamic zones. After loading the zones into
the BIND DNS Server, you cannot change the zone content with an text
editor anymore. You need to use nsupdate instead. I highly recommend
nsupdate, as it catches a number of errors that can occur when
editing zone file manually:

Yes, we see a RRSIG signature for the SOA record, so the signing
process was successful.

To create a full DNSSEC chain-of-trust from the .loc TLD to the
local root-zone, we need to add the DS record (delegation signer) into
out private root-zone. We create the DS-Record from the KSK of .loc
…

The root-zone is a busy place right now. New TLDs are added all the
time. Make sure you follow these changes. A good way to get notice of
updates in the root zone is to follow @diffroot on Twitter. Please
remember, if you followed this tutorial, you need to add the changes
using nsupdate, do not use a text editor on the zone files!

Footnotes:

1]
I do not recomment hosting a private TLD, it is much easier and less
error-prone to run a private DNS delegation on the second or third level
of the DNS hierachy, such as private.example.com.

2]
Be sure to use the double >> to append to the file, a single > will
override the zonefile with the keys. Not what we want.

3]
Always double check the key data, there is a slight chance that the
sequence "257" will appear in the key material of the ZSK as well!