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.