(Editor’s note:  Andrew Sullivan, author of this post, works for Shinkuro, is a member of the DNSSEC  Deployment Initiative, and is co-chair of the DNS Extensions working group at the IETF.  In the past, he was part of the DNS group at Afilias, and worked on Afilias  projects starting with the launch of the .info top level domain in 2001.)

Now that the largest TLDs on the Internet are either already DNSSEC-capable or about to be signed, what do we do with DNSSEC?

This might seem like a strange question.  If we didn’t know in advance how DNSSEC would improve things, why did we other?  The answer is in two parts.

In one way, DNSSEC deployment automatically improves things.  We had an integral part of the Internet (the DNS) that was designed back when cryptography was both expensive and controlled, and when the Internet population was small.  It had no security.  So we had to plug that hole: alter the DNS so that if you got an answer from it, you could be absolutely sure whether you got the answer you should have, and not something from some random person on the Internet.  That’s stage 1. It isn’t over yet, and won’t be until every DNS answer on the Internet can be validated.  But we’re on the way, and for many domains it is now just a matter of time before this is reality.

Stage 2 of DNSSEC deployment is the really exciting part.  The DNS contains mappings of host names to addresses, of course, and securing those lookups is one thing that DNSSEC gives us.  But we can put other kinds of data into the DNS as well, and turn the DNSSEC-enabled DNS into a successful public key infrastructure.  This solves a problem that has dogged the online world for years.

Consider the web.  The way secure connections are made on the web today relies on a third party — the certificate authority or CA. Suppose you are visiting the web site https://secure.example.com.  The secure web site presents your browser with a certificate.  In the usual case, your browser now looks into a big list of CAs it trusts. If one of those CAs provided (either directly or indirectly through another certificate) assurances about the certificate from secure.example.com, then you trust the site you are visiting. Otherwise, you get a warning (sometimes a big, scary one) saying that the site cannot be validated.  This is an oversimplification of how https validation works, but that’s roughly all there is to it.

The reliance on CAs means two things.  First, it means the operator of secure.example.com has to have registered with one of the certificate authorities (and not just any one — one of the ones you have in your list).  This involves money and not a little time managing the keys appropriate to each host or collection of hosts.  If the operator of the service does not register with one of the certificate authorities, then when you connect you will get a certificate that cannot be validated.  Maybe you won’t be able to connect, and you will be foiled in what you are trying to do.  Or maybe you will accept the unknown connection, which means that you could be giving your credit card to anyone at all on the Internet.

Second, it means that you have to trust all these third parties, and keep the list of those parties in your browser up to date.  That might not sound like a problem, except for two things.  First, we know people don’t always install updates right away.  Second, some of the CAs have made some pretty big blunders in the past.  Since you probably have other things to do, it is unlikely that you will go through the list of CAs and make decisions one at a time about whether that CA is responsible. 

DNSSEC makes it possible to replace this machinery.  With DNSSEC, you can trust that the DNS data you get about secure.example.com is the real thing: nobody can spoof it.  This means that if the administrator of  secure.example.com could put the necessary key information into the DNS, you could just look it up there, and be sure that the data you got back was right.  Then you could use that data to secure your web connection.  In this ca se, you don’t have to trust any third parties, and the site operator doesn’t have to involve any third parties (or pay any money to them) either.  The work needed to make this happen is already being done at the Internet Engineering Task Force (IETF) in the DNS-based Authentication of Named Entities (DANE) working group. Participation is open.  For more details, see http://tools.ietf.org/wg/dane. But the technique needn’t be just for the web.  On the web, most secure sites are using certificates signed by a CA today, and so one could argue that there is no reason to fool with  something that is working.  But other services aren’t like that.  The overwhelming majority of SMTP servers that use TLS are using self-signed certificates.  This means the authentication mechanisms already available to us are not even being used.  This contributes to the spam problem — but it is too much hassle to use CA-signed certificates for mail systems, so nobody does it.

Authentication for VPNs is also an area ripe for developments using DNSSEC.  Today, configuration of VPNs is often a headache for IT staff, who often either have to touch every computer that will participate in a VPN in order to set it up, or else distribute software via some unsecured channel and use “leap of faith” as the first step in the validation chain.  DNSSEC could be used to perform that initial bootstrap of trust, freeing up IT staff time and making VPN connections much easier.  SSH has already shown part of the way to do this, using the SSHFP resource record.  Once you have a provably trustworthy, globally-available database, it becomes obvious that many problems of establishing initial trust go away.

DNSSEC is not magic, of course.  Nothing will help you get to the right server if the operation at secure.example.com has been taken over by a bad guy.  Putting keys or certificates into the DNS will not make website operators’ lives better if the person who runs the DNS won’t co-operate.  But those are not new problems, and they are problems that are best solved with management direction.  And none of this leveraging of DNSSEC is ready today: the tools don’t exist, the protocols are only just being designed, and DNSSEC itself is still hard enough to use that people make mistakes all the time.  But DNSSEC gives us an incredibly exciting opportunity to make practical, easy to use security gains available to everyone on the Internet.  It’s time to concentrate on stage 2.