I mentioned my work on the Google Certificate Catalog a while back. Now I’ve updated it to sign responses with DNSSEC.
I also updated the command-line utility to verify DNSSEC responses – and added a little utility to fetch the root DNSSEC keys and verify a PGP signature on them.
As always, feedback is welcome.
Given how often I say on this blog that I am not speaking for my employer, I am amused to be able to say for once that I am. Over here.
Apparently the Pirate Bay are tired of ICANN and want to start their own peer-to-peer DNS. I think their chances of wide adoption are pretty near zero, but it’s an interesting area that’s needed serious exploration for quite some time. Obviously if you’re doing P2P DNS you need to use DNSSEC or attacks become trivial. Since they also want to have multiple registrars who can nominate themselves, it seems a proposal I made to the DNS working group many years ago could be handy. Basically, the idea is to distribute keys for “islands of security” by having bilateral agreements between them, so each island signs some set of other island’s keys, if they want to. The user then bootstraps their set of keys by starting from an island or islands they trust.
When ferreting this out I found that the -01 version is already on my server, and I just uploaded -02 – not sure what the differences are, when I have some time I’ll make a diff. Probably.
I actually got these done over the weekend, but I’ve been kinda busy. After taking a more, ahem, principled approach, France seems less dramatic
but still pretty impressive. If you take a close look you’ll see I’ve also had a crack at adding the AS’ owner as well (not 100% reliable, if anyone knows how, let me know!). The UK depends on one less AS than before
and I can do Fiji
I still can’t do the world, though – but now the problem is that dot chokes on the graph.
Another interesting way to pwn the Internet is to control the routing of packets to critical nameservers. In practice, Internet routing is done by ASes (Autonomous Systems). If an AS wants to pwn a nameserver on a network it controls, it is a trivial matter: it just redirects the packets to its own nameserver. I’d draw you a picture, but I’m sure Matasano Chargen will do it prettier.
So. I thought it would be instructive to determine which ASes had control over which domains. More fun with dot.
The picture is no longer quite so rosy for the UK, but still, not bad, all things considered.
But France. I don’t know what to say about France. France is surreal. I’ve linked through to a much bigger version because, well, you’ve got to lose yourself in the spiderwebs. The SVG is here, though.
As for Fiji, I’d love to show you Fiji, but the way I’m doing it doesn’t work for Fiji right now. And hence, obviously, not for the whole world, either. Coming soon, I hope.
Update: Ben Hyde suggested I should use the (undocumented) “concentrate” option to dot, which certainly tidies up the graphs. So I did.
A remark on the IETF DNS Working Group’s mailing list got me thinking.
Suppose I were the owner of nordu.net (to pick an example at random), then I could take control of sunet.se, for about 25% of Internet users, since one of their four nameservers is server.nordu.net. Similarly, I could then take control of ripe.net for 25% of those 25% (via sunic.sunet.se). One in seven of those guys could fall victim to my ownership of nic.fr via ns-sec.ripe.net, and from there I have complete control of fr (that is, France) – ok, by now, for only a bit under 1% of the Internet, but even so, that’s kinda worrying, don’t you think? And obviously if I own sunet.se then it would be more like 3.5%…
On the other hand, uk does not suffer from this problem: it depends only on nic.uk. Which seems like a much better idea. Anyway, I got to wondering just how bad this problem actually is, which led to me having more fun with dot. So, for a taster, here’s France’s dependencies…
And here’s the UK’s
And here’s Fiji (I include this for Jasvir, who is getting married there soon, and ought to know the terrible risk he’s taking)
And all the top level domains put together
So that one is pretty but a bit hard to digest. Obviously the main news is that there are a lot of domains which could interfere with one or more TLDs!
Another way to think about this is to wonder who could pwn the most TLDs? Well, the answer (after the root, of course) is that nstld.com, gtld-servers.net, com and net come in equal first with 228 TLDs pwnable. Next up is Affilias, through a variety of domains, including org and info, able to control 187 TLDs. After that comes se (Sweden) with 158 and nordu.net, sunet.se, chalmers.se, kth.se, uninett.no, uu.se, edu, no, norid.no, lth.se and uit.no, all able to have a go at 157 TLDs.
Food for thought. Especially if you’re thinking about DNSSEC.
I’ve had feedback since I wrote about DNSSEC that my makefile didn’t work on many platforms. Why Linux and FreeBSD have to use different versions of make I have no idea, but at least it is possible to write makefiles that work on either, if you’re careful. So, I’ve updated the tarball with a version that should work most places. Give it a try.
For the geeky, here’s a diff:
iff -r 94acb807ca7c -r d4a50f0d790c Makefile
--- a/Makefile Sat Mar 07 16:41:39 2009 +0000
+++ b/Makefile Sat Mar 07 16:49:37 2009 +0000
@@ -1,4 +1,6 @@
all: run
+
+.PHONY: named.root anchors.xml isc-dlv.conf
push: dnssec.tgz
scp dnssec.tgz www.links.org:files
@@ -6,7 +8,7 @@
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
named -c named.conf -d 10 -g
-named.root!
+named.root:
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
@@ -17,7 +19,7 @@
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
-anchors.xml! iana-pgp-keys
+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
@@ -46,7 +48,7 @@
gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
rm isc-key.tmp* 363
-isc-dlv.conf! isc-pgp-keys
+isc-dlv.conf: isc-pgp-keys
rm -f dlv.isc.org.named.conf*
wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf
Since posting about DNSSEC, I’ve had lots of great feedback. So, in no particular order…
Various people have pointed out that DLV is not as bad as I suggested
Although the second measure is, as I remember it, strictly speaking against the rules (one is not supposed to calculate negative responses from the cache), clearly it can be stipulated that a DLV server must behave when serving NSEC records. Anyway, the net result is that the overhead of DLV is actually quite reasonable. I still say it should be run by every DLVed domain for every other, though. In any case, I am going to switch it on in my own caching resolver.
One thing I wanted to achieve is that a DNSSEC-ignorant resolver downstream of my caching resolver would only get validated results. I tried to do this with the dnssec-must-be-secure configuration option – but this is wrong. That option requires everything to be signed, whereas in DNSSEC it is perfectly OK for a zone to be unsigned so long as its parent delegates to it with no keys (bear in mind that with DNSSEC the nonexistence of the keys is provable, and so this is secure). In fact, BIND 5.3 behaves as I want it to with just DNSSEC enabled. In BIND 5.4 onwards I will have to switch it on with the dnssec-validation option (gee, thanks, ISC for making a backward incompatible change!).
Jelte Jansen operates a domain with various broken entries – this is very handy for testing and I now include its key in my configuration. Note that if you want to see a record that fails validation, then you need to set the CD bit (with dig, +cd or +cd +dnssec if you want to see the DNSSEC records).
Paul Hoffman wonders why I would prefer a signature (for anchors2keys) to download over HTTPS. The reason is that HTTPS download doesn’t really prove the file hasn’t been interfered with – the server will serve anything that happens to be in the filesystem over HTTPS, of course. A signature would be done with a key that I would hope is very strictly supervised, and so is far more trustworthy.
Incidentally, for DNSSEC newbies, one of the interesting features of DNSSEC is that it can be done entirely with offline keys. Proving negatives (i.e. the nonexistence of names) with such a constraint is an interesting problem – and one that I spent three years working on, leading in the end to RFC 5155.
I’m sure everyone is tired of reading my config and makefile, so there’s a tarball here.
Finally, thanks very much to all the experts for the excellent feedback.
Tony asks “what about DLV?”.
DLV is Domain Lookaside Validation. The idea is that if your resolver can’t find a trust anchor for foo.bar.example.com, then it can go and look in a lookaside zone, hosted at, say, dlv.isc.org, for trust anchors. So, it would first look for com.dlv.isc.org and then example.com.dlv.isc.org and so forth.
So, what do I think of this? It’s another way to solve the problem of having the root not signed.
How does it compare to IANA’s ITAR?
Also, I think it would be organisationally better if all the participating domains would run DLV for each other, rather than have any single party running it.
Anyway, I modified my setup to also use DLV. Here’s the new Makefile
all: run
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.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
isc-pgp-keys:
rm -f 363
wget --no-check-certificate https://www.isc.org/node/363
html2text < 363 > isc-key.tmp
awk '/^Version:/ { print; print ""; next; } { print }' < isc-key.tmp > isc-key.tmp2
gpg --import isc-key.tmp2
gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
rm isc-key.tmp* 363
isc-dlv.conf: isc-pgp-keys
rm -f dlv.isc.org.named.conf
wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf
mv dlv.isc.org.named.conf isc-dlv.conf
test:
dig -p5453 +dnssec www.dnssec.se @localhost
and here’s named.conf
options {
listen-on port 5453 { 127.0.0.1; };
pid-file "named.pid";
dnssec-enable true;
dnssec-lookaside . trust-anchor dlv.isc.org.;
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";
// include ISC DLV trust anchor
include "isc-dlv.conf";
Enjoy.
Incidentally, I have enabled “forced ITAR” on my main resolver, so we’ll see how that goes. I haven’t added DLV because, like I say, failure would not be noticed, so what’s the point of all the overhead?
A lot of solutions to all our problems begin with “first find a public key for the server”, for example, signing XRD files. But where can we get a public key for a server? Currently the only even slightly sane way is by using an X.509 certificate for the server. However, there are some problems with this approach
One obvious way to fix these is to add extensions to the certificates that prevent their use for inappropriate services. Of course, then we would have to get the CAs to support these extensions and figure out how to validate certificate requests that used them.
But I have to wonder why we’re involving CAs in this process at all? All the CA does is to establish that the person requesting the certificate is the owner of the corresponding domain. But why do we need that service? Why could the owner of the domain not simply include the certificate in the DNS – after all, only the owner of the domain can do that, so what further proof is required?
Obviously the answer is: DNS is not secure! This would allow anyone to easily spoof certificates for any domain. Well, yes – that’s why you need DNSSEC. Forgetting the details of DNSSEC, the interesting feature is that the owner of a domain also owns a private key that can sign entries in that domain (and no-one else does, if the owner is diligent). So, the domain owner can include any data they want in their zone and the consumer of the data can be sure, using DNSSEC, that the data is valid.
So, when the question “what is the public key for service X on server Y?” arises, the answer should be “look it up in the DNS with DNSSEC enabled”. The answer is every bit as secure as current CA-based certificates, and, what’s more, once the domain owner has set up his domain, there is no further cost to him – any new keys he needs he can just add to his zone and he’s done.
Does DNSSEC have any other uses? OK, it would be nice to know that the A record you just got back corresponds to the server you were looking for, but if you trust a connection just on the basis that you used the right address, you are dead meat – you’ll need some key checking on top of it (for example, by using TLS) to avoid attacks by evil proxies (such as rogue wifi hotspots) or routing attacks and so forth. For me, the real value in DNSSEC is cryptographic key distribution.
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.
Powered by WordPress