Registrars have the opportunity to fundamentally change the landscape of the Internet’s security infrastructure by working to close the DNSSEC functionality gap. Virtually everything every Internet user does on the Internet depends on the DNS. DNSSEC is not just about protecting the DNS, it is about building a secure infrastructure foundation upon which new and innovative services and applications can be built to benefit us all. Registrars are the linchpins to advancing the deployment of DNSSEC.

In September, I published the first of a three-part series on DNSSEC adoption in the domain name industry. We discussed the technical and policy challenges that impede greater DNSSEC adoption. In today’s article, we will explore the functionality gap that exists in the domain name business processes.

Typically, a domain name owner chooses a registrar which bundles service for both the registration and hosting of a domain name. If the domain name owner wants to sign their name, then the registrar (acting as the DNS service provider) creates the DNSSEC key information, signs the zone of the domain name, and shares the DNSSEC public key information directly with the registry. These steps are as prescribed by the IETF standards (RFC4033, RFC4034, RFC4035, and RFC5910).

In other cases, domain name owners don’t use their registrar for DNS hosting. Instead, they work with a third-party DNS service provider, or host the names themselves. In these cases, if the domain name owner wants to sign their name, the DNS service provider must do the DNSSEC signing for them. The functionality gap exists in this case.

The DNS service provider is responsible for creating the key information and signing the domain name’s zone on behalf of the domain name owner. For the DNSSEC chain of trust to be maintained, that public key information must be handed off to the registrar. The registrar in turn either passes that key to the registry, or uses it to create a DS record and then hands the DS record over to the registry.

The most common handoff mechanism is for the domain name owner to copy-and-paste the public key information from the DNS service provider to a web form provided by the registrar. The public key information can be a sequence of several hundred apparently random characters, or more; copy-and-paste is a best-case scenario assuming the format used by the DNS service provider is compatible with the format accepted by the registrar. As you can imagine, a lot has to go right in these handoffs, and much of this process is not standardized.

Of course, the registrar must be able both to provide a full DS record to a registry, and pass just the public key information to the registry. In the latter case the registry will create the DS record and insert it into the Top Level Domain (TLD) zone file. Registrars must perform both functions because registries decide how they wish DS records to be created and registrars must work with many different registries.

Further, registries may dictate the cryptographic parameters to be used, e.g., the type of key algorithm used and the minimum key size, which would then create additional technical burdens on registrars that have to compute the DS record for the registry. ICANN’s 2013 Registrar Accreditation Agreement (RAA) mandates that registrars allow domain name owners to add, remove and change DNSSEC key information. Thus, even registrars who choose not to include DNSSEC in their own DNS services will have to include a minimum of DNSSEC related functionality in their name services.

In this scenario, the registrar bears an administrative burden for a service the domain name owner chose to obtain from a third-party. The lack of technical standards and proven best practices to support this functionality gap is a critical weakness in current DNSSEC deployment.

Because registrars are the central party through which all DNSSEC interactions with the registry must pass, they should work collaboratively with DNS service providers and other technical experts to motivate and direct a solution to this gap. The alternative is to have a solution passed to them that was developed without full knowledge and consideration of issues that are important to them.

There has been so much progress around DNSSEC in recent years. We cannot let these critical yet granular key-passing processes impede the deployment of DNSSEC and its promise to deliver a more secure Internet infrastructure for every Internet user.