Home / Blogs

DNSSEC Status Report: Signing Infrastructure Well Underway, User Experience Still Needs Work

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.

By Jeremy Hitchcock, DNS and networking engineer, CEO at Dyn Inc

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

How to inform applications of DNSSEC status By Paul Roberts  –  Apr 21, 2010 4:24 am PDT

I would be interested to see if the browser vendors are able to modify their code to indicate when DNSSEC validation has failed, so the green address bar and padlock icon become indicative that DNSSEC validation (as well as SSL verification) was successful.

Unfortunatly I don't see how this can currently be achieved. Windows 7 does not ship with a validating resolver, so it relies upon the up-stream DNS server to perform the validation. Another problem is that if a validation failure occurs, the DNS server replies with a "server failure" response, which means it is not possible to differentiate between a genuine DNS type failure, and DNSSEC validation failure. Sure the user will be protected because they won't be able to reach the site, but they will not have an indication WHY they couldn't reach the site.

I understand why "server failure" is used (so that it is compatible with older, non-DNSSEC aware DNS servers), but as with all these things, we end up with a compromise and not really an ideal solution. :-(

Add Your Comments

 To post your comments, please login or create an account.

Related

Topics

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign

IPv4 Markets

Sponsored byIPXO

Brand Protection

Sponsored byAppdetex

Domain Management

Sponsored byMarkMonitor

Threat Intelligence

Sponsored byWhoisXML API