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
named.root!
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
rndc.key:
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 rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
anchors2keys:
wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
chmod +x anchors2keys
iana-pgp-keys:
html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > 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 { 127.0.0.1; };
pid-file "named.pid";
dnssec-enable true;
include "force-dnssec.conf";
};
// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };
// include the rndc key
include "rndc.key";
controls {
inet 127.0.0.1 port 1953
allow { 127.0.0.1; }
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 www.dnssec.se @localhost
; < <>> DiG 9.3.5-P2 < <>> -p5453 +dnssec www.dnssec.se @localhost
;; global options: printcmd
;; connection timed out; no servers could be reached
[ben@euphrates ~/svn-work/peim/doc]
$ dig -p5453 +dnssec www.dnssec.se @localhost
; < <>> DiG 9.3.5-P2 < <>> -p5453 +dnssec www.dnssec.se @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
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec.se. IN A
;; ANSWER SECTION:
www.dnssec.se. 300 IN CNAME dnssec.iis.se.
www.dnssec.se. 300 IN RRSIG CNAME 5 3 300 20090302080001 20090220080001 62658 dnssec.se. y0JcIxVunryZRaccDX2PteGyxCQ2dlfeoeDYNcoPKCryBa9vGWuNJwNa MhqzMmLLr5N4SbQsIL8YrQ8+l/wBFebXB6I8dJ8OWDmz6OqihSzkDYB/ qFwEWLQi49RfCuE6Qai/PnPh0Om+7guyL15fLTMh3PtZso4axt23/vqG 5RI=
dnssec.iis.se. 3600 IN CNAME www.iis.se.
dnssec.iis.se. 3600 IN RRSIG CNAME 5 3 3600 20090302135501 20090220135501 6477 iis.se. ebDsJcmZRHkq5Y+SLTIC2Iey3fNBj7r3bk3TAeyJPXtgFE6YJqAtJmv4 m5Sn1jDZhidnI0NWyPz5dUwDFfzVnJN/DH+CZJuiynKQge4inIGt8Dzk ybaq7JSoFkHABAu+IBbVKwR4+TW92tzv2CgzdtBIsQnuOn+CQMpmuz+N rFk=
www.iis.se. 3600 IN A 212.247.7.210
www.iis.se. 3600 IN RRSIG A 5 3 3600 20090302135501 20090220135501 6477 iis.se. aIOT7U/CRcFi3CcgaHp6EqV8JHkODodQM0Pg7CKh1gby4/8pGnqABDiU +4bg8/zDlAzVUz6o4j5sjIg5uS2A1ODJzp+UodXyVL9/Q8eBfZGSDuOa FPwK9jUxj6P1iXIqoMyeAS1PG1rFgSim/xpZLhJK2l5ScQ/1+Pq6SG8T Lgc=
;; Query time: 1236 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; 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 www.dnssec.se @localhost
; < <>> DiG 9.3.5-P2 < <>> -p5453 www.dnssec.se @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
;; QUESTION SECTION:
;www.dnssec.se. IN A
;; ANSWER SECTION:
www.dnssec.se. 100 IN CNAME dnssec.iis.se.
dnssec.iis.se. 3400 IN CNAME www.iis.se.
www.iis.se. 3400 IN A 212.247.7.210
;; AUTHORITY SECTION:
iis.se. 86200 IN NS ns3.nic.se.
iis.se. 86200 IN NS ns.nic.se.
iis.se. 86200 IN NS ns2.nic.se.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; 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.