DNSSEC and indirection

What can DNSSEC do, apart from provide full employment for DNS nerds? Most of the work so far has been on securing the DNS itself, which is important but not particularly sexy. Looking back at a DNSSEC article I wrote a year ago, the main changes in the last year have been the very unsexy business of rolling out and improving DNSSEC support. A lot of this work is still some distance from end users - TLD and registrar support, better software tools. I recently registered a domain name with Gandi and had it up and running DNSSEC very quickly - but I had to host it on my own servers since Gandi's hosting services don't support DNSSEC. So there's still a long way to go. Better large-scale DNS management software such as AtomiaDNS should help with deployment at hosting providers.

Infrastructure is interesting to the extent that you can build interesting things on it. Perhaps the most important thing about DNSSEC is that it is a new, very cheap and scalable, public key infrastructure. The IETF DANE working group has been working on a specification for TLSA resource records which use the DNSSEC PKI to constrain the X.509 PKI in order to reduce the problems caused by insecure certification authorities. This spec is now in the last stages of the IETF process before being passed to the RFC editor for publication.

The next job is to tie this into the many application protocols that use TLS. For instance I have submitted a draft describing how to use DNSSEC to secure SMTP between MTAs. and Matt Miller has one on DNSSEC and XMPP. This ought to be straightforward, but there's a knotty question about how to deal with indirection records such as MX and SRV (and to a lesser extent CNAME and DNAME).

The present situation is that our security protocols ignore any indirection in the DNS, because it can't be trusted. So if you connect to the gmail.com XMPP servers, their certificates authenticate themselves as gmail.com rather than as the targets of the respective SRV records. This is rather inconvenient for hosting providers, which either need certificates that can authenticate huge numbers of names, or protocols or extensions that allow the client to tell the server which name it is expecting.

DNSSEC can change this. A signed SRV or MX record is a trustworthy delegation of responsibility from a domain to its hosting provider. When it finds a signed indirection, a client only needs to check the target server host name against the certificate it presents. Service providers only need certificates for their server host names, not for every customer domain. My draft for email and Matt Miller's for XMPP allow clients and servers to trust the DNS in this way.

Unfortunately getting from where we are to this shiny future is going to make correct configuration harder, along the lines of Google's cockup that I reported yesterday.