Where is the domain industry with the adoption of DNSSEC? After a burst of well publicized activity from 2009-2011—.org, .com, .net, and .gov adopting DNSSEC, roots signed, other Top-Level Domains (TLDs) signed—the pace of adoption appears to have slowed in recent years.

As many CircleID readers know, DNSSEC requires multiple steps in the chain of trust to be in place to improve online security. Those are:

1. The TLD Must Be Signed – Major TLDs such as .org, .info, .com, and .net have been signed, as have a good number of ccTLDs. All new gTLDs must sign the TLD zone and must accept public key material from registrars, but they are not required to enforce signed second level delegations.
2. The Registrar Must Support DNSSEC – The registrar where the domain is registered must support DNSSEC. ICANN requires that a registrar must be able to add, remove, or change public key material (DNSKEY or DS resource records) on behalf of registrants for those registries that require it (see point 1).
3. The DNS Hosting Provider Must Support DNSSEC – Very often a registrar may also provide DNS Hosting services—where they will host the domain name’s DNS records, allow management of those records, and publish them to the global DNS. Regardless of whether DNS hosting is provided by the registrar or by another company DNSSEC support is required.

Of course, for DNSSEC to be useful, both the server side and validation on the client side must support signed domains. Client-side validation is moving in a positive direction. In late 2013, APNIC Labs produced research that demonstrated that roughly 8 percent of global DNS queries involved some kind of DNSSEC validation. Last month APNIC unveiled a global validation graph that showed DNSSEC validations increasing to 12 percent.

In the United States Comcast (the country’s largest ISP) has adopted client-side validation. Some countries like Sweden and Estonia see a majority of queries using DNSSEC validation. DNSSEC technology standards have been stable and mature since 2007, with only updates, clarifications, and new functionality added since then. “Waiting until the standards are final” is no longer a valid reason to delay deployment.

Authoritative DNS is very mature, and it’s easy to get access to DNSSEC information once it is deployed. DNSSEC has been included in every major name server implementation for a few years now. Second level domains can now be signed, but adoption at that level has been frustratingly slow, due to the lack of service provider support (see point 2 above).

The final step in the deployment of DNSSEC is the use of validated information by services and applications to provide enhanced and innovative security services to users, with browsers obviously being first in line. Businesses need to see better online security as a market advantage—especially financial services firms.

More signed domains are needed to demonstrate full viability, and that’s currently a huge gap in the DNSSEC chain of trust. New TLDs will help to some degree, but more needs to be done. There are two obstacles standing in the way of more secure domains, one related to policy and one technical.

On the policy side, the new ICANN policy for gTLDs mandates signed TLD zones, but not signed second level delegation. In addition, the 2013 Registrar Accreditation Agreement (RAA) requires registrars to offer “DNSSEC services,” but only for those registries that require it.

On the technical side, it is not possible for a gTLD domain name registration with active DNSSEC to be transferred from one registrar to another without breaking the security chain of trust.

Part Two of this series will address impediments to greater DNSSEC adoption.