DNS Exercise 5 -- turning on DNSSEC Validation in your cache
============================================================

BIND is currently configured on our servers as an *authority* server.
We disabled recursion on those servers as is best practice earlier
this week.

In this exercise we will turn recursion back on so that we can
turn on DNSSEC validation.

Remember that in a normal production environment, we would not
provide authoritative DNS service and recursive service (whether
validating or not) on the same server.


1. Turn Recursive Service Back On

Edit /etc/namedb/named.conf and make sure the following configuration
statements are present in the "options" section.

options {
	...
	...

	recursion yes;
	allow-recursion { any; };

	...
	...
};

Check your configuration:

# named-checkconf

Now restart named:

# /etc/rc.d/named restart
# tail /var/log/messages


2. Check that Recursive Service is Working

# dig @127.0.0.1 facebook.com A

# dig @pcNN.sse.ws.afnog.org afnog.org MX

Do the responses you get confirm that your nameserver is working
correctly as a recursive server? Why?


3. Retrieve a Copy of the Root Zone Trust Anchor

We need a secure copy of the root zone trust anchor. For this exercise,
we are going to obtain an insecure copy, and then test it. 

In a real production environment, you should try to authenticate the
trust anchor before you use it. How might you do that?

Obtain a copy of the root zone DNSKEY RRSet from the DNS:

$ dig . dnskey +noall +answer +multiline

; <<>> DiG 9.8.3-P1 <<>> . dnskey +noall +answer +multiline
;; global options: +cmd
.			90695 IN DNSKEY	257 3 8 (
				AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
				bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
				/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
				JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
				oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
				LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
				Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
				LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
				) ; key id = 19036
.			90695 IN DNSKEY	256 3 8 (
				AwEAAc5byZvwmHUlCQt7WSeAr3OZ2ao4x0Yj/3UcbtFz
				Q0T67N7CpYmNqFmfvXxksS1/E+mtT0axFVDjiJjtklUs
				yqIm9ZlWGZKU3GZqI9Sfp1BjQkhi+yLa4m4y4z2N28rx
				WXsWHCY740PREnmUtgXRdthwABYaB2WPum3yRGxNCP1/
				) ; key id = 20580
$

Remember from our discussion that there are two keys here; one is a KSK
and one is a ZSK. The trust anchor we will install in BIND is the KSK. Which
one is the KSK?

(Hint: the KSK is longer; the KSK has different flags from the ZSK)


4. Add the Trust Anchor to your BIND Configuration

We are going to add a brand new section to our BIND configuration. As usual,
make sure you add this configuration to the right place.

# vi /etc/namedb/named.conf

managed-keys {
	"." initial-key 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
	bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
	/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
	JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
	oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
	LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
	Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
	LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};

The public part of the root zone KSK is now available to BIND9. We will
turn on validation by adding two new clauses to the "options" section:

# vi /etc/namedb/named.conf

options {
	...
	...

	dnssec-enable yes;
	dnssec-validation yes;

	...
	...
};

Finally, we will check the configuration changes we have made, and
restart BIND if everything looks good.

# named-checkconf
# /etc/rc.d/named restart
# tail /var/log/messages


5. Test your Configuration

Some example domains that are signed with DNSSEC:

  . (the root zone)
  tz (Tanzania ccTLD), na (Namibia ccTLD)
  com, net, org, biz, info (gTLDs)
  isc.org, icann.org, ripe.net

An example domain that has been deliberately signed badly:

  dnssec-failed.org

Send queries to your cache and see what responses you get for some
of those domains. Remember that you can always be sure that there'e
an SOA record in a zone. You might also guess that "www.ZONENAME"
has an A record.

# dig @127.0.0.1 tz SOA
# dig @127.0.0.1 isc.org SOA
# dig @127.0.0.1 www.dnssec-failed.org A

What results do you get if you specify the +dnssec option on dig?

# dig @127.0.0.1 na SOA +dnssec
# dig @127.0.0.1 ripe.net SOA +dnssec