Nelson's log

DNSSEC examination

I was curious what was up with DNSSEC these days. A little bit of a dive on deployment and the way it all works in practice.

Bottom line: use a DNSSEC-aware nameserver like Google Public DNS and you will be protected from DNS records that were signed but tampered with. However very few DNS names are signed.

You can see quick DNSSEC tests in a browser. This page displays a DNSSEC Secured!” if you are secure. This site should fail to load entirely (name won’t resolve) in a secured system.


My main question is how widely DNSSEC is deployed. This little name-and-shame site gives a pretty depressing answer, the top 25 sites according to Alexa all don’t support it. Particularly curious why Google doesn’t publish DNSSEC records. They’re not dumb or lazy, they take security very seriously, I imagine they think it isn’t important or useful for some good reason.

Verisign’s DNS Scoreboard says some 625,000 domains are DNSSEC secured. That’s like 0.4%, although it is growing.


Example DNSSEC records

The Verisign Labs DNSSEC debugger is the best web tool I’ve seen for examining DNSSEC records. Note the little “more/less” buttons in the display, if you click “more” enough you get to see the full response like dig gives you. You can also use dig to check things with “dig +dnssec”, then look for the extra records and the “AD” flag in the response.

Here are some test domains and their properties. Note I wrote this in Dec 2015, things may change afterwards.

DNS server behavior

How do various public DNS servers handle DNSSEC records?

Bottom line it looks like there’s two types of servers. Those that do support DNSSEC and won’t return any data if a declared DNSSEC record is broken, and those that are ignorant of DNSSEC entirely. That’s to be expected.

I’ve long been a skeptic of OpenDNS, and their lack of DNSSEC support is another reason to not like them. Back in 2010 they proudly announced they were going to back DNSCurve instead. No one else has supported it since then, so I assume it’s basically a dead end. Their arguments for DNSCurve was that no one was using DNSSEC and that DNSSEC’s choice of crypto algorithms was weak. Adoption is still a problem for DNSSEC, but it supports many different crypto algorithms now so I assume that’s less of a problem.

I’d like to note that my OpenWRT DNS server seems to not pass on the AD flags. I’ve got it configured to use Google DNS upstream, so I get the benefit of the protection since Google simply won’t return records for broken domains, but clients won’t get to see if the records are properly signed or not. I think this is fixable, either by changing to a different DNS resolver in OpenWRT or maybe just telling dnsmasq to add DNSSEC.

Client support

The whole point of DNSSEC is to authenticate the DNS record all the way to the client. But I don’t think many (any?) consumer clients are validating DNSSEC themselves. Instead they are trusting their DNS server to validate for them. That violates the end-to-end principle.

On testing, I believe MacOS 10.9 does nothing with DNSSEC. If I manually set my DNS server to (a Verizon server that does not do DNSSEC), Chrome can load the test pages with broken DNSSEC signatures. I suspect MacOS is just assuming you should trust your DNS server.

I didn’t test it, but I think stock Ubuntu does not do DNSSEC either. The glibc resolver doesn’t seem to have it. I did run across some libraries that do DNSSEC; libval, ldns, and knot. And if you’re running bind or dnsmasq you can enable DNSSEC on those.

I found one Chrome extension that verifies DNSSEC itself. Neat! But it requires a native binary plugin and that was more than I felt like dealing with.

Final thoughts

DNSSEC seems to mostly work, just adoption is slow. On the server side, the root DNS servers didn’t support it until July 2010; before then it would have been very awkward to use. For clients, Google DNS started doing DNSSEC in May 2013, so that’s been a good long while now. But end user clients aren’t doing anything themselves.

One question I didn’t explore is overhead. All those extra DNS records take memory and bandwidth to serve. And verifying signatures takes CPU time. I don’t think that’s prohibitive at the edges given all the room for caching, but the big DNS server operators may be worried.