At IETF 77, Network World was asking around about DNSSEC and talked to us about our progress. Our Dynect Platform is able to do DNSSEC key management which a single click of a button (it might be like 2-3) and our DynDNS.com domain registration service is able to accept the part of the key that needs to go to the registry. Together, it is an end-to-end DNSSEC management solution.
The Signing Infrastructure
The registries (gTLDS) are all moving towards signing in about a year. PIR and .org is going to be first with .edu, .biz, and others closely behind. The root is scheduled to be signed in the beginning of July (end of June looking at the holiday calendar) being the biggest milestone. Some of the roots already contain DNSSEC information. Other ccTLDs continue to turn DNSSEC on with countries on every continent signed.
Registrars will follow next but they have the toughest part to educate registrants and to do the bulk of the work for key management. Some popular zones in gTLDs will become signed this year and ccTLDs will continue to increase the zones that they sign.
The Validation Infrastructure
Major ISPs, who operate the bulk of the validation infrastructure, have been running trials to test large scale validation. Operating systems continue to improve their support for DNSSEC.
The user experience/application Support
One critically missing piece from the DNSSEC conversation has been the user experience. Even the DNS community is undecided how applications should handle DNSSEC responses. The cases where an answer is valid and signed is clearly defined. What happens for the non-signing DNS response or the one that is signed but is bogus?
Think about HTTPS. When you visit a site that is HTTPS and has a certificate from a certificate authority that your browser trusts, you see a padlock. You can then enter information, knowing that the channel is authenticated (who it is) and encrypted (not plain text). If you do not see a padlock, you shouldn’t enter sensitive information. When you have a bad certificate, you see a warning. What’s the equivalent for DNSSEC?
DNS validation occurs at a deep layer than most applications (the operating system just handles DNS and the application uses IP addresses) while the “secure” part of HTTP operates at the same layer (not technically true but the decryption is done at the same layer: the application layer). Anyway, there is no good mechanism for the application to tell the user there is an error. If the validation piece says that an answer is bogus, it may look there is no such answer. That’s probably better since most users tend to just click through blindly. Different networks will have different policies for validation and this will have to be coordinated with applications (whether the OS or the actual application layer).
When Everything is Signed
What’s exciting to me is what happens after there is a globally coherent, distributed, public key database. While I can see DNS records being signed, I am sure that there are others out there who are thinking about putting login keys or other crypto fingerprints into DNS. After the summer of this year, expect the attention to shift towards the validation infrastructure and the application support.