Home / Blogs

Deploying DNSSEC: Lessons from Domain Registrar Implementation

DNSSEC has moved from an experimental deployment to a mainstream initiative in 2010. Many Top-Level Domain (TLD) registries have either deployed or plan to deploy DNSSEC soon. Among generic Top-Level Domains (gTLDs), the .ORG domain leads the way, while more than 20 country codes have deployed DNSSEC. COM and NET have promised to deploy DNSSEC in the next twelve months. Overall, this amounts to a tsunami of support for DNSSEC. As a domain registrar at the front end of the DNSSEC deployment effort, the NamesBeyond technical team has made a sustained investment in DNSSEC deployment so that our customers don’t get overwhelmed by this wave of changes to the core infrastructure of the Domain Name System. Along the way, we’ve learnt a lot about how to implement DNSSEC which might hold useful lessons for other organizations that plan to deploy DNSSEC in their networks.

A brief description of DNSSEC (short for DNS Security Extensions). DNSSEC was created to protect the Internet from some kinds of attacks, such as DNS cache poisoning. DNSSEC allows DNS resolvers to check the validity of DNS data, using a public key cryptography mechanism that ensures that once a user begins to navigate to a web site, they cannot be hijacked on the way. The actual technical protocol specifications are defined in detail in RFC 4034.

Lesson 1: DNSSEC is complex and difficult to explain

Most material written about DNSSEC is technically dense and complex. Explanations are filled with cryptographic or other deeply technical jargon, which makes it very difficult for business customers. The key benefits of DNSSEC, and the rationale for why a company should invest in signing their domain name is usually lost in the noise about DNSKEYs, DS records, RRsets and other equally incomprehensible terms.

One of the biggest tasks is to convert these complicated technical concepts into simple and easy to understand language. This has resulted, for example, in our Frequently Asked Questions (FAQs) page to be reviewed and updated frequently to ensure that the concepts are easy to understand while remaining technically accurate.

We have taken concepts such as “key rollovers” and be simplified them into comparisons with “changing passwords”. Concepts like Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) are simplified into comparisons with more familiar concepts such as authentication and challenge mechanisms. Public key cryptography is too much for a normal business person.

Lesson 2: Crafting a Great DNSSEC User Experience Is Challenging

In general, deploying technology in user interfaces is difficult. Technology companies understand technical issues and create user interfaces that seem logical to their engineering, quality assurance and operations teams. Implementing complex tasks such as key rollovers, hosted DNSSEC and ripple-free signed zone transfers require customers to carefully follow multiple steps, sometimes in a particular order. Customers want to ensure that regardless of the technical operation, their web sites will not go dark and their emails will not be shut down. Our user experience surveys show that customers need to have things simplified even more than they are.

For example, customers can sign their websites (zones) in two ways. If they run their own nameservers, then we provide a facility for them to add their own DS keys, which we then transmit to the registry. On the other hand, if customers use our nameservers, then all they have to do is to add their zone record, and our software takes care of the rest of the signing and transmission infrastructure. In addition, customers want to add the zone into the hosted system, and have us generate the KSK and ZSK keys and sign their zone. Finally, customers want the flexibility of switching between their own nameservers to our hosted servers, without any impact on the underlying signed zone.

Responding to these detailed technical requirements while retaining an easy to use interface has been an interesting challenge. We are now in the third iteration of the DNSSEC control panel which will allow users the ability to manage their own DNSSEC-signed zones, and are still uncovering issues with usability, help text and useful hints. One-click simplicity is the mantra.

Lesson 3: Testbed experience does not fully translate into production

NamesBeyond is an accredited registrar for the .org domain, under contract with the Public Interest Registry, and credentialed under the .ORG DNSSEC program. .ORG’s DNSSEC efforts began with the creation of a DNSSEC testbed (managed by Afilias). This testbed illustrated some of the challenges in establishing an effective DNSSEC implementation. We were able to code to the new EPP DNSSEC toolkit, and work on key rollovers and transfers, but .ORG had to create special accounts to accommodate these activities, resulting in retooling and rework from our end. Domains in the testbed could not automatically transfer over into production accounts with their attributes intact, which is inconvenient. With only one other registrar participating in the testbed, the opportunities for cross-registrar tests were rather limited. To mitigate, we’ve tested inter-registrar transfers of signed zones using two of our own registrar accounts created in the DNSSEC testbed.

Working on DNSSEC is another step for registrars in a continuing investment in strong security and advanced technology. When .ORG implements 2nd level signed zone support this June, registrars will need to be ready. When .com and .net implement DNSSEC in the next 12 months, more issues related to “thin registry” will probably be uncovered. An approach driven by simplifying usability, reducing confusion and creating a ripple-free environment for customers is the appropriate method to resolve user experience problems. As we implement DNSSEC, we expect to uncover more issues but remain confident that a disciplined approach will yield benefits for customers.

By Rajesh Kothari, Technology Manager, Lead Technologist

Filed Under


Many errors in the FAQ Stephane Bortzmeyer  –  May 31, 2010 9:09 AM

Yes, DNSSEC is hard but your lecture would be more efficient if the FAQ you mention were more accurate and better proofread. Communication to ordinary users require great care.

For example, customers can sign their websites (zones) in two ways.

Website == zone???

It is a set of extensions to DNS, which provide origin
authentication of DNS data, data integrity and authenticated denial
of existence.

And you complain about jargon? Do you believe that Joe User can understand “authenticated denial
of existence”?

The latest versions of BIND and NSD are DNSSEC aware, usually by
simply setting a compiler-option.

Even better, you believe that users actually compile server code???

What are some of the benefits of DNSSEC?

Repeated twice, one for benefits and one for problems…

(see http://www.ietfregistry/rfc/rfc4310.txt

wrong URL

Not all errors in the FAQ, but you help make my point reg. usability and user experience Rajesh Kothari  –  Jun 2, 2010 11:33 PM

We do exercise care in communicating with customers, but thank you for your admonition to continue to exercise care.

You ask, for example, whether a website is the same as a zone.  Of course as a technologist, we know the precise answer.  But customers don’t really care.  They don’t even think they are buying domain names, they believe they are buying websites.  And we know, as do you, domain name <> website.

Regarding your point about “Authenticated Denial of Existence” - thank you for pointing it out - it underscores exactly the problem I talk about - talking about DNSSEC is complex and is filled with jargon.  In spite of our efforts, we don’t have everything simplified in common user’s language.  That’s why our FAQ will go through more iterations!

Of course, not all users compile server code or even know what that means.  Having said that, you missed the point of this statement, which is to communicate that allowing software to be DNSSEC aware is simple and does not require a lot of fiddling around.

Thank you for your other helpful comments which we will incorporate in updates to our site.  We look forward to register signed domains in .ORG, .COM and other TLDs shortly.


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

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.

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




Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com

Brand Protection

Sponsored byCSC