Ben Laurie blathering

Using DNSSEC Today

It’s been a while since I’ve properly paid attention to developments in the DNSSEC world, so I was surprised to learn that IANA now has an “Interim Trust Anchor Repository“. No need to wait any longer for the root to be signed, you can configure yourself to do DNSSEC right now.

Here’s how. First off, grab this Makefile

all: run

run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf
	named -c named.conf -d 10 -g

	rm -f named.root

	rndc-confgen -a -c rndc.key

itar-trusted-keys.conf: anchors2keys anchors.xml
	./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
	mv /tmp/itar-trusted-keys itar-trusted-keys.conf

anchors.xml! iana-pgp-keys
# appears to break without -v!
	rsync -v .
	gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml

	wget --no-check-certificate
	chmod +x anchors2keys

	html2text -nobs > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
	awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
	gpg --import iana-pgp-keys.tmp2
	gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
	rm iana-pgp-keys.tmp*

force-dnssec.conf: itar-trusted-keys.conf
	awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf

and this named.conf

options {
  listen-on port 5453 {; };
  pid-file "";
  dnssec-enable true;
  include "force-dnssec.conf";

// obtain this file from
zone "." { type hint; file "named.root"; };

// include the rndc key
include "rndc.key";
controls {
  inet port 1953
    allow {; }
    keys { "rndc-key"; };

// include ITAR trust anchors
include "itar-trusted-keys.conf";

and run make. After a while, with luck, you’ll have named with trust anchors configured (you can see which ones by looking at itar-trusted-keys.conf) running on port 5453 (and the rndc control channel on port 1953).

You can test it with, for example

$ dig -p5453 +dnssec @localhost      

; < <>> DiG 9.3.5-P2 < <>> -p5453 +dnssec @localhost
;; global options:  printcmd
;; connection timed out; no servers could be reached
[ben@euphrates ~/svn-work/peim/doc]
$ dig -p5453 +dnssec @localhost

; < <>> DiG 9.3.5-P2 < <>> -p5453 +dnssec @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 41806
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096
;                 IN      A

;; ANSWER SECTION:          300     IN      CNAME          300     IN      RRSIG   CNAME 5 3 300 20090302080001 20090220080001 62658 y0JcIxVunryZRaccDX2PteGyxCQ2dlfeoeDYNcoPKCryBa9vGWuNJwNa MhqzMmLLr5N4SbQsIL8YrQ8+l/wBFebXB6I8dJ8OWDmz6OqihSzkDYB/ qFwEWLQi49RfCuE6Qai/PnPh0Om+7guyL15fLTMh3PtZso4axt23/vqG 5RI=          3600    IN      CNAME          3600    IN      RRSIG   CNAME 5 3 3600 20090302135501 20090220135501 6477 ebDsJcmZRHkq5Y+SLTIC2Iey3fNBj7r3bk3TAeyJPXtgFE6YJqAtJmv4 m5Sn1jDZhidnI0NWyPz5dUwDFfzVnJN/DH+CZJuiynKQge4inIGt8Dzk ybaq7JSoFkHABAu+IBbVKwR4+TW92tzv2CgzdtBIsQnuOn+CQMpmuz+N rFk=             3600    IN      A             3600    IN      RRSIG   A 5 3 3600 20090302135501 20090220135501 6477 aIOT7U/CRcFi3CcgaHp6EqV8JHkODodQM0Pg7CKh1gby4/8pGnqABDiU +4bg8/zDlAzVUz6o4j5sjIg5uS2A1ODJzp+UodXyVL9/Q8eBfZGSDuOa FPwK9jUxj6P1iXIqoMyeAS1PG1rFgSim/xpZLhJK2l5ScQ/1+Pq6SG8T Lgc=

;; Query time: 1236 msec
;; WHEN: Sun Feb 22 14:07:14 2009
;; MSG SIZE  rcvd: 602

Because we have forced DNSSEC on the trusted domains (this is done in the included file force-dnssec.conf), the fact we get an answer at all tells us that the signatures checked out – but also the fact that the AD bit is set (“;; flags: ... ad ...“) tells you that the signatures were validated by the caching server you just set up. Note that pretty much no application will check for the AD bit, so DNSSEC is only really going to help if you have it forced on, as in this configuration. Obviously if you want to run this for real, you should run it on standard ports and point all your resolvers at it. Then you get the benefits of DNSSEC today with no application changes.

Note that ordinary queries (i.e. ones that don’t request DNSSEC) are also validated by the server, but we don’t see the DNSSEC stuff in the response

$ dig -p5453 @localhost

; < <>> DiG 9.3.5-P2 < <>> -p5453 @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 2159
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0

;                 IN      A

;; ANSWER SECTION:          100     IN      CNAME          3400    IN      CNAME             3400    IN      A

;; AUTHORITY SECTION:                 86200   IN      NS                 86200   IN      NS                 86200   IN      NS

;; Query time: 1 msec
;; WHEN: Sun Feb 22 14:41:25 2009
;; MSG SIZE  rcvd: 147

I notice that the AD bit isn’t set, though, which seems like a bug.


  1. What do you think of the ISC’s DNSSEC lookaside verification service? It has much wider coverage than the ITAR, which is limited to TLDs and will go away when the root is signed. The ISC DLV is intended to provide trust anchors at any level, and to provide better coverage after the root is signed while there are still unsigned TLDs.

    Comment by Tony Finch — 22 Feb 2009 @ 16:46

  2. > wget –no-check-certificate
    > chmod +x anchors2keys

    Anyone but me think this might be a really bad idea? 😉

    Comment by olleB — 22 Feb 2009 @ 17:32

  3. Well, I agree that one should actually take a look at anchors2keys before running it, but is it actually a worse idea than running anything else you download?

    Comment by Ben — 22 Feb 2009 @ 17:55

  4. @olleB:
    Well, uh, given the context and all, probably not actually really bad, but clearly very deeply ironic.
    Such is life.

    Comment by Micky — 22 Feb 2009 @ 18:59

  5. Maybe olleB was commenting on the ‘-no-check-certificate’ part. If someone does an MITM and replaces just one key, you are unlikely to notice it even if you look at the file.

    What do you have against GoDaddy as a CA?

    Comment by Paul Hoffman — 22 Feb 2009 @ 20:01

  6. Well, they could sign anchors2keys, or something. That would be nice.

    Nothing against GoDaddy, but a signature would be better…

    Comment by Ben — 22 Feb 2009 @ 20:38

  7. If the client is not dnssec aware/capable (DO bit set) then it will likely not understand the AD bit either. Also many cheap DSL router dns stub routines are very broken and will die on setting the bit.

    Comment by Paul Wouters — 22 Feb 2009 @ 21:13

  8. >Nothing against GoDaddy, but a signature would be better…

    It would? Why is that? Secure transmission of a message you are immediately going to process is just as good as insecure transmission of a signed message.

    Comment by Paul Hoffman — 23 Feb 2009 @ 23:17

  9. […] posting about DNSSEC, I’ve had lots of great feedback. So, in no particular […]

    Pingback by Links » Doing DNSSEC Right — 24 Feb 2009 @ 16:36

  10. If running the anchors2keys executable is a problem, switch to Unbound, which can read keys in master file format and therefore will not require this executable.

    Comment by Stéphane Bortzmeyer — 24 Feb 2009 @ 17:53

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress