Log in

No account? Create an account


The state of DNSSEC deployment

« previous entry | next entry »
31st May 2011 | 23:44

DNSSEC comprises a couple of fairly independent sets of protocol extensions:

  • Transaction authentication
  • Data authentication

Transaction authentication has a few varieties: TSIG, GSS-TSIG, and SIG(0). It is mainly used to authenticate zone transfers between master and slave authoritative servers, and to authenticate DNS UPDATE messages (in Microsoft Active Directory domains, for instance). It has been widely deployed for years now. It's fairly unglamorous because it doesn't require a massive worldwide campaign to get it deployed: instead a network of clients and servers can deploy it and benefit from improved security without liaising with anyone else.

Data authentication is where all the noise is at the moment. Unlike TSIG, this is a change to the DNS data model to add fine-grained cryptographic signatures to the data in the DNS, so that users can verify that it is authentic. The deployment campaign is well under way: many of the largest TLDs are signed and accepting secure delegations. There are still barriers to deployment: many registrars are not yet ready to handle secure delegations, and many DNS hosting services don't support DNSSEC. You can work around the former to some extent using the ISC's DLV service. You can work around the latter by doing it yourself, but the tools are still a bit rough so you have to enjoy being on the bleeding edge.

The counterpart to signing the zones is deploying validating resolvers that actually check the signatures. It's harder to tell how widespread this is yet. It's fairly clear that the .gov requirement to deploy DNSSEC was interpreted as a requirement to sign the zones, but not to deploy validation. Hence they seem to have been slow to become aware of broken signatures and to fix them. If you turn validation on, you have to be willing to deal with a little more operational pain than usual for the DNS. While it is common for smaller domains to screw up their DNS, DNSSEC has new exciting failure modes that have led to occasional breakage in more important domains. But in practice for us it doesn't seem to have noticeably increased the support load - but we don't deal with .gov much :-)

What's next? There are a couple of prongs developing in parallel:

  • Applications built on DNSSEC
  • End-user security

Once you can depend on the authenticity / validity of data obtained from the DNS, you can use it to bootstrap trust in higher-level protocols. For example, you can use SSHFP records to avoid manual host key validation or leap-of-faith authentication. Or you can use TLSA records to mitigate the weaknesses of the X.509 certificate authority system.

But in order for these applications to be secure, you have to push the secure area all the way out to the end user. Here the roadmap is a bit murky because some important parts are missing.

The traditional Unix stub resolver is based on the assumption that you can just do a simple request/response with your recursive resolver which does all the hard work for you. The recursive server is usually remote, and the stub resolver usually doesn't have DNS hardening features (port randomization, query ID randomization), and the link between the two is the most likely to be attacked. Given that, a validating remote resolver is not actually much use - it adds failure modes without meaningfully improving security.

A fix that is sometimes suggested is to deploy some kind of channel security between stubs and resolvers (something like TSIG). This isn't attractive for a couple of reasons. It probably requires new protocol development to specify the key management, so it'll be a long time before it is usable. Also the stubs continue to trust their resolvers, which is not desirable for mobile devices roaming on untrustworthy networks.

Really, what you want to do is run a validating cache on your local machine, which the stub resolvers can talk to over a private socket. A shared validator keeps the stub resolvers simple, and a cache avoids repeated fetches of the same signatures and keys.

BIND 9 can in fact be run in exactly this mode, called a "lightweight resolver daemon". I think this means "lightweight configuration" and "lightweight protocol" but not "lightweight implementation" since lwresd is in fact just an alias for the full BIND named. It was originally intended to offload the complexity of dealing with IPv6 bit-labels and A6 records, but it seems to have been neglected since they were obsoleted by the simpler AAAA records. It could really do with being resurrected for DNSSEC.

There are a few improvements that could be made to lwresd: it should reconfigure itself automatically when /etc/resolv.conf is updated; it should have a command-line option to turn on validation using the built-in trust anchors; it should try bypassing the forwarding server if it doesn't support DNSSEC; and (more speculatively) the lightweight resolver protocol could be extended to provide better DNSSEC error reporting - the DNS itself just gives an uninformative "server failure" reply if validation fails (or for any of several other errors).

The advantage of this setup is that it doesn't change the relationship between the end host and the network: you continue to use the resolvers you get from DHCP (lwresd forwards queries to them) so caches remain effective and strict firewalls don't break things (as they would if you ran a full resolver).

| Leave a comment |

Comments {7}

Ewen McNeill


from: edm
date: 1st Jun 2011 01:05 (UTC)

Reading your description of desired behaviour it occurs to me that it's very much like the dnsmasq use case -- a shim that acts like a resolver daemon on one side, and a resolver stub library on the other side. So I wonder if a better approach might be to build DNSSEC support into dnsmasq and use that instead (checking the web site now suggests that it doesn't do DNSSEC validation at present).


Reply | Thread

Tony Finch


from: fanf
date: 1st Jun 2011 09:16 (UTC)

Yes, that sounds like another way of solving the problem. However it doesn't look like dnsmasq is designed to provide DNS service to other processes on localhost, which is the goal.

Reply | Parent | Thread

Re: dnsmasq

from: Dave Holland [org.uk]
date: 1st Jun 2011 09:40 (UTC)

It certainly does that.

I work in the same office as the author so I look forward to his howls of DNSSEC-related pain. :-)

Reply | Parent | Thread

Tony Finch

Re: dnsmasq

from: fanf
date: 1st Jun 2011 09:44 (UTC)

Hah. Truly the world is a small place :-) Good luck to Simon, it should be fun ...

Reply | Parent | Thread

Re: dnsmasq

from: Dave Holland [org.uk]
date: 1st Jun 2011 12:23 (UTC)

Simon says...

Making dnsmasq into a DNSSEC validator would mean moving the recursive resolution function into dnsmasq. Validation requires checking every step in the chain from the root domain to the target, hence the need to do recursion. At the moment, dnsmasq doesn't do that, it just ships DNS queries it can't answer to an upstream recursive resolver (normally provided by the ISP, or Google.)

For that reason alone, it's a non-starter: turning dnsmasq into a recursive resolver would make it much more heavyweight: if you want a BIND equivalent, use BIND......

Plus, consider the consequences of making every SoHo router in the world a recursive nameserver. At the moment, Google's authoritative nameservers have to refresh the www.google.com record once per TTL in the nameservers of every ISP in the world. That's easy. Doing the same for every SoHo router is a different scale altogether.

I think the best approach is for ISP's nameservers to the validation. Essentially, at the end of a DSL line, you just get a bit set in a DNS reply which says "I validated this answer". Of course, the answer might be a fake: you either trust the path as far as your ISP and trust that the ISP has ingress filtering which stops packets masquerading as replies from its nameservers, or you set up a single pre-shared keypair and use TSIG, which allows the nameserver to sign its replies. For the above reason, if I do anything, it will be TSIG checking.

The protocol has a bit which says to an upstream nameserver "check the answer but return it even if it fails to validate" and in replies means "I checked this answer, and it's bogus". Stub resolvers should, obviously, not use answers with this bit set. DNS caches should not cache results with it set either, lest they return the answer later, but without the "broken validation" bit. That behaviour went into dnsmasq relatively recently, so it is now, in sense, DNSSEC-ready.

Reply | Parent | Thread


from: cozminsky
date: 3rd Jun 2011 08:02 (UTC)

I've been using unbound installed locally and putting in my resolv.conf. I didn't realize lwresd had the advantage that it would use whatever was in /etc/resolv.conf as a forwarder. I've also tried a plugin for firefox (http://www.dnssec-validator.cz/), but I think it might have been responsible for chewing huge amounts of memory so have abandoned it for the time being. And for TLSA there is the https://os3sec.org/ plugin using TXT records until TLSA gets standardized.

The other thing that I think will be interesting is how dnssec will interact with NAT64/DNS64. I can't think of a solution that doesn't involve a DLV look-aside from your isp.

Reply | Thread

Tony Finch

from: fanf
date: 3rd Jun 2011 09:14 (UTC)

Good point about NAT64. That does rather depend on the "trust your ISP's resolvers" model :-(

Reply | Parent | Thread