These instructions provide a basic tutorial introduction to DNSSEC and instructions on how to access our testbed.
In this example, we've delegated a domain called uk-dnssec below the domain nic.uk. uk-dnssec has two subdomains: smallzone and bigzone. In turn, smallzone has three subdomains, a, b, and c, and bigzone has more than 100,000 subdomains, starting alphabetially with aaa and ending with zymurgy.
Note: the names in the bigzone zone have been populated by merging a list of english and latin words. Any similarities between data in bigzone to names in the Nominet-managed zones (e.g. co.uk, org.uk, etc.) is purely coincidental.
In this example, the portion of the DNS tree inside the box is secured by DNSSEC. Moreover, the child zones have been signed by the parent zones, so together they comprise what is referred to as an `island of trust', that is, a hierarchy of DNSSEC-secured zones which may be validated via a single key. This key is referred to as a `trust anchor', as it anchors the security of the zones within the island.
Again, the following zones are within the island of trust:
- uk-dnssec.nic.uk.
- smallzone.uk-dnssec.nic.uk.
- bigzone.uk-dnssec.nic.uk.
One of the hopes for DNSSEC is that, while initially there will be many small separate islands of trust, that over time these islands will converge until the entire DNS becomes a single `island' of trust.
Looking at DNSSEC
DNS data is principally a collection resource records, commonly referred to as `RR's. DNSSEC doesn't modify the existing RRs associated with a particular configuration; it merely adds new records to the DNS data which permit the validation of the existing ones.
This can be seen by comparing the contents of an unsigned zone:
uk-dnssec.nic.uk
with that of a signed zone:
uk-dnssec.nic.uk.signed
While it may not be immediately apparent due to the reformatting, all the records in the unsigned zone are also in the signed zone; however four additional RR types have been added to the signed zone:
- DNSKEY RRs, which contain the public keys of the keys used to sign data in the zone.
- NSEC RRs, or `Next Secure' RR which show the interval between names in the zone. These are used in DNSSEC for `authenticated denial of existence', in other words, to show in a cryptographically strong way that a name doesn't exist in the zone.
- RRSIG RRs, or `Resource Record Signature' RR, which contain the signatures of the other RRs in the zone, including the DNSKEY and NSEC RRs. Note that for each set of RRs for which the zone is authoratative there exists a corresponding RRSIG RR.
- DS RRs, or `Designated Signer' RRs. These are in the top-most zone (uk-dnssec.nic.uk) only. DS RRs are hashes of the keys of the children zones, and is how DNSSEC maintains a trust hierarchy throughout an island of trust. Note that the addition of the DS RR is the principal change between the original DNSSEC specification (RFC 2535) and the new specification, dubbed `DNSSECbis'.
All three unsigned zones in this example are available at:
- uk-dnssec.nic.uk (686 bytes)
- smallzone.uk-dnssec.nic.uk (685 bytes)
- bigzone.uk-dnssec.nic.uk (6,502,149 bytes)
The signed versions are available at:
- uk-dnssec.nic.uk.signed (7,046 bytes)
- smallzone.uk-dnssec.nic.uk.signed (1,401 bytes)
- bigzone.uk-dnssec.nic.uk.signed (71,566,016 bytes)
Using DNSSEC
The preferred method for examining DNSSEC is with the dig (Domain Information Groper) command which is part of BIND (Berkely Internet Name Daemon) version 9.3.0 or later. The instructions for use provide numerous examples of the use of dig. The current version of BIND is available from the Internet Systems Consortium.
Using dig we can look at what the normal DNS response is for the A RR for www.uk-dnsssec.nic.uk :
$ dig @dnssec-resolv.nominet.org.uk www.uk-dnssec.nic.uk.
; <<>> DiG 9.3.1 <<>> @dnssec-resolv.nominet.org.uk www.uk-dnssec.nic.uk.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61678
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;www.uk-dnssec.nic.uk. IN A
;; ANSWER SECTION:
www.uk-dnssec.nic.uk. 96253 IN A 10.11.12.13
;; AUTHORITY SECTION:
uk-dnssec.nic.uk. 96253 IN NS ns0-dnssec.nic.uk.
uk-dnssec.nic.uk. 96253 IN NS ns1-dnssec.nic.uk.
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 29 14:55:25 2005
;; MSG SIZE rcvd: 104
With the addition of the following flags:
- +dnssec -- request DNSSEC
- +multiline -- format output in a more human readable format
. . . we can also see the DNSSEC RRs associated with the A RR returned in the previous result, in this case an RRSIG RR:
$ dig @dnssec-resolv.nominet.org.uk +dnssec +multiline www.uk-dnssec.nic.uk.
; <<>> DiG 9.3.1 <<>> @dnssec-resolv.nominet.org.uk +dnssec +multiline www.uk-dnssec.nic.uk.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56868
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.uk-dnssec.nic.uk. IN A
;; ANSWER SECTION:
www.uk-dnssec.nic.uk. 96221 IN A 10.11.12.13
www.uk-dnssec.nic.uk. 96221 IN RRSIG A 5 4 172800 20050528153354 (
20050428153354 3149 uk-dnssec.nic.uk.
RTDXj2ZrDAzW4XZgR6nNovArIAt0MbhxNHjDgce84VzN
y5sSgg8DNizmvw9zRZd73p1lFkmTTb79RQTKcmhHPLeV
YEXl8kaKl3vkN+ObbeOlbl8ONHKNP8IUeFZJRY/du47z
/Ao7dJ6IoZLI9Mf0LUGHffRQFc4BCJwcFrgPcUzWR+jO
5f0nMkh5c1RDZsCndl343NfjReQz8S/fWe3m9aXDjNhs
seM4BVI2lGssFLoWjcHb3+GsshIu6ErOQtxSw10TRuBM
83BdwSOfRRdK8XXKRieOMS3+WammFJGpIY4nHapCopXG
4OkpmqS94ImIdBt8psZaBiTC6Ga5ayOSMA== )
;; Query time: 8 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 29 14:55:57 2005
;; MSG SIZE rcvd: 369
One important difference in the second result is that the ad (`Authenticated Data') flag has been set. This indicates that the resolver has successfully checked the signature contained in the RRSIG RR against the key in the resolver (more on this in the next section).
Note that dig version 9.3.0 or later must be used to properly view DNSSEC data.
Adding trust anchors to a resolver
In order for a resolver to authenticate DNSSEC data, DNSSEC must be enabled and the trust anchors for that data must be added to the resolver. To do this in BIND, add the following settings to the named.conf file. Note that BIND version 9.3.0 or later must be used.
options {
. . .
recursion yes;
dnssec-enable yes;
. . .
};
. . .
trusted-keys {
"uk-dnssec.nic.uk." 257 3 5 "
AQPJO6LjrCHhzSF9PIVV7YoQ8iE31FXvghx+14E+jsv
4uWJR9jLrxMYmsFOGAKWhiis832ISbPTYtF8sxbNVEo
tgf9eePruAFPIg6ZixG4yMO9XGLXmcKTQ/cVudqkU00
V7M0cUzsYrhc4gPH/NKfQJBC5dbBkbIXJkksPLvFe8l
ReKYqocYP6Bng1eBTtkA+N+6mSXzCwSApbNysFnm6yf
QwtKlr75pm+pd0/Um+uBkR4nJQGYNt0mPuw4QVBu1Tf
F5mQYIFoDYASLiDQpvNRN3US0U5DEG9mARulKSSw448
urHvOBwT9Gx5qF2NE4H9ySjOdftjpj62kjbLmc8/v+z
";
};
You can then check to see whether DNSSEC is properly enabled by looking to see whether the ad flag is set in response to the following query:
$ dig @[your resolver] +dnssec +multiline www.uk-dnssec.nic.uk.