DNSSEC first steps

DNSSEC is a security extension to the Domain Name System which offers

origin authentication of DNS data
data integrity
authenticated denial of existence

This is useful in helping to protect against attacks such as DNS cache poisoning.

Information on DNSSEC can be found at

We have built a development DNS infrastructure in order to be able to experiment with DNSSEC without risk of adversely affecting the production DNS service. This consists of a hidden master and two secondary authoritative servers running ISC BIND on Debian GNU/Linux.

We wanted to use a zone that was small, static, low-profile and from a DNSSEC-capable registrar – ‘oxford-university.edu.’ matched on all counts.

There are two types of keys used in DNSSEC, zone signing keys (ZSK) that sign the individual resource records in the zone file, and key signing keys (KSK) that sign the ZSKs. The public part of the KSK is registered with the parent zone. This allows frequent changing of ZSK without having to bother the parent zone every time – this only has to be done with a change of KSK. The general consensus seems to be that ZSKs should be changed every month and KSKs every year.

There are various cryptographic algorithms to choose from. To start with, we’ve chosen to generate our KSK with 2048-bit RSASHA1-NSEC3-SHA1, the ZSK with 1024-bit RSASHA1-NSEC3-SHA1, and to use the SHA-256 hash function to generate the digest of the KSK that is used by the parent zone in the Delegation Signer (DS) record.

Now that we’ve gone to the trouble of generating keys, signing our zone and giving our parent a DS record, what does this achieve? Any DNSSEC-enabled DNS resolver in the world can now follow a chain of trust all the way from the top (root) of the DNS tree down to an individual resource record in our zone. The resolver must be configured to trust the public component of the root’s KSK.

The excellent site http://dnsviz.net/ offers a visualisation tool which makes it easier to understand the chain of trust. In this example we’re drilling down to the A record for www.oxford-university.edu.

The double ellipse at the top of the diagram indicates that we’re using root’s KSK as the trust anchor and the blue/green arrows represent trusted relationships.

In contrast, here’s what happens when we try to validate the A record for bad.oxford-university.edu which has a deliberately broken signature.

The red colour at the bottom of the diagram shows that the signature for bad.oxford-university.edu is bogus.

Digging around

We can use the dig utility on a host with a DNSSEC-enabled resolver to explore a little (some output lines have been omitted for clarity).

Lookup a known valid record

$ dig good.oxford-university.edu. a

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7141
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; ANSWER SECTION:
good.oxford-university.edu. 14400 IN    A       163.1.0.90

Lookup a known bogus record

$ dig bad.oxford-university.edu. a

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16837
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Here we’ve received SERVFAIL which has prevented us from using a potentially compromised answer.

Lookup a known bogus record with checking disabled

We can look up the bogus record again, but this time setting the Checking Disabled (CD) bit in our query

$ dig +cd bad.oxford-university.edu. a

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27875
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; ANSWER SECTION:
bad.oxford-university.edu. 14400 IN     A       163.1.0.90

Now that we don’t care about validation, we get an answer returned.

Next steps

Key generation and roll-over is one of the key (sorry!) components of managing a signed zone. We may run our production DNS service on an appliance in the medium-term which would take care of the tedium of key management so it doesn’t make sense to invest time in developing a local solution at this stage.

The root zone was signed on 2010-07-15. The uk zone was signed on 2010-03-01. We need JANET(UK) to sign the ac.uk zone before there is a possibility of a chain of trust from the root to our ox.ac.uk zone. At the time of writing, JANET(UK) has not given any indication as to when it might get round to signing ac.uk.