There has been a lot of criticism about the worthiness of DNSSEC. Low adoption rates and resistance and reluctance by Registrars to take on the perceived burden of signing domains and passing-on cryptographic material are at the crux of the criticism.

I’m a believer in DNSSEC as a unique and worthwhile security protocol and as a new platform for innovation. It’s the reason I’ve long advocated for and continue to work toward a new model of DNSSEC provisioning. I don’t just want to see it widely adopted; I want to see it universally adopted so we can make the internet a better place.

DNSSEC – A platform for innovation

DNSSEC will allow us to continue to innovate and make the Internet more secure at the same time. At an ICANN meeting in June, I saw demos of various email applications encrypted using public keys in the DNS and secured with DNSSEC, as well as mail gateways encrypting traffic, chat encryption and web site encryption.

In practical terms, with the application of DNSSEC, this means I can publish my public part of a PGP key for my email address in the DNS. Whenever someone sends me an email, the sender mail gateway can lookup in the DNS to see if my key is available by doing a DNS query. If it’s available, it will encrypt the email.

Before we can get everyone to see just how relevant this technology is, we have to recognize the challenge of DNSSEC adoption.

A look back at DNS protocol

They say to make good decisions today, you have to understand history.

The DNS is a protocol designed more than 30 years ago, when everyone on the Internet knew and trusted each other. Over time, as the Internet grew, malicious actors discovered opportunities to exploit the DNS. Adding DNSSEC signatures prevents this. It provides data authenticity and integrity by signing the resource record sets with a private key. As best practice, people on the Internet can validate using the public key. When this best practice is followed, whenever there is a concern of an attack to the DNS, you can do a query plus DNSSEC, which will give you the record plus an RRSIG. It sounds like such a simple and great solution. Adopt DNSSEC and you can protect yourself from the bad guys. But to be effective, we’ve got to get everyone on board. And there are a lot of doubters out there.

Toward universal DNSSEC adoption

I believe the problem of low adoption rates lies with the DNSSEC provisioning model, which is currently based on the triple-R model—Registrant/Registrar/Registrant. When the DNSSEC was invented, only a few people challenged or questioned in vain whether the RRR model was best for implementation. The challenge with this model is that it puts the onus on Registrants to implement DNSSEC and, further, it puts Registrars in a position of putting it in place.

From the get-go, Registrars told us they didn’t want to do it. Some of them cursed. I understand. It costs them money and offers little value-add. Plus, we’ve made DNSSEC adoption an unnecessarily complicated process. Right now, only the truly tech savvy Registrants are willing to sign a domain, if they can find a Registrar to support them. And sadly, not many Registrars do. In Canada, for example, of more than 150 .CA Registrars, only 11 offer DNSSEC capability.

It should be a lot simpler. Right now, if a Registrant wants to sign their domain, they have to provide .CA with a key to include in the .CA Zone file to create the chain of trust. But they can’t do that directly. Within the RRR model, Registrants aren’t allowed to talk to the Registry directly. That leaves them in the position of finding a Registrar who’s interested in managing the cryptographic material of each individual Registrant.

Furthermore, as shown in the diagram below, if a registrant uses a web-hosting provider for their domain and the web-hosting provider uses a content delivery network provider to manage the DNS and Web content, in this case, the CDN is the DNS Operator (confused yet?). If the CDN signs the domain, then he needs to relay the DNSSEC keys to the hosting provider, then to registrar, then to registry… It simply does not work.

What if the Registries were in charge of DNSSEC?

In fact, Registries, like .CA are much better positioned to manage the DNSSEC provision process, in partnership with DNS Operators. After all, DNSSEC is a DNS operator function, not a Registrar function.

The DNS operator is the entity that manages the zone and signs DNSSEC. So why are we forcing Registrars to manage any of this?
The new way would see Registries like .CA create a web interface and RESTful interface and some standards to allow DNNSSEC bootstrap by the DNS operators. This means slaying a sacred cow in the RRR model. There are few precedents where the DNS operator has direct access to a top level domain to manage DNSSEC material.

But we can change this. We can slay the sacred cow—take the pressure off the Registrars, who don’t want anything to do with this anyway, and give DNS operators direct access to the Registry. Here’s what we’re proposing.

It’s actually simple, providing we give the DNS operator the means to prove they control and operate the zone. They do this by adding _delegate TXT record and enabling the process via an interface that tells. CA (or the Registry) that they want to get signed. If all is good, .CA can trigger the bootstrap process.

Of course, the Registrars who also act as DNS operators can remain involved within the new setup. Much simpler!

The path for a Registrant DNS operators or Registrar/Hosting company DNS Operators would be slightly different.

You can see in the above diagram that the first step to a prototype would be building a web interface for low volume activities, like for a Registrant that is also the DNS Operators. Registrar/Hosting DNS Operators, on the other hand, would require a RESTful API for better backend integration and automation.

My colleagues and I are currently working on these prototypes. In the meantime, send me your thoughts on DNSSEC provisioning. We want your input! And stay tuned for an update.