Deploy360 20 September 2013

ICANN's 2013 RAA Requires Domain Name Registrars To Support DNSSEC, IPv6

By Dan YorkDirector, Internet Technology

dnssecHow do we get more domain name registrars to support DNSSEC?  I don’t know how many times I’ve heard this:

“I want to sign my domain, but my registrar doesn’t support DNSSEC – what do I do?”

It’s been one of the proverbial questions that has indeed been a barrier to getting more domains signed.  As most of the largest top-level domains (TLDs) are now all signed, and an increasing number of smaller TLDs are getting signed, and as the tools for signing domains have become increasingly easy to use, there are fewer and fewer reasons not to add the increased level of security to your domain using DNSSEC.

Except… you need the registrar for your domain name to accept your DNSSEC information (either a DS or DNSKEY record) and pass that information up to the TLD registry (such as “.org”, “.com”, “.nl”, etc.).

That is the key role played by a registrar.  And that is the missing link for many people in having their signed domain fully integrated into the global chain-of-trust of DNSSEC.

Now, ICANN has maintained a list of registrars supporting DNSSEC and we’ve posted some tutorials about registrars and DNSSEC. A number of us have also been promoting DNSSEC to registrars at ICANN events through the DNSSEC workshops there (such as the one coming up at ICANN 48 in Buenos Aires) but the fact remains that many registrars are not yet supporting DNSSEC.

This may change soon, though, for one very simple reason.

ICANN has updated their “Registrar Accreditation Agreement (RAA)” that all “ICANN-accredited registrars” (and it’s a big list!) must sign to continue their affiliation with ICANN. The 2013 RAA, passed by the ICANN Board of Directors in June 2013, includes several provisions related to both DNSSEC and IPv6.  The final 2013 RAA, available as a PDF file, has this section 3.19:

3.19 Additional Technical Specifications to Implement IPV6, DNSSEC and IDNs. Registrar shall comply with the Additional Registrar Operations Specification attached hereto.

The actual “Additional Registrar Operation Specification” is found on page 67 of the agreement and states for DNSSEC:


Registrar must allow its customers to use DNSSEC upon request by relaying orders to add, remove or change public key material (e.g., DNSKEY or DS resource records) on behalf of customers to the Registries that support DNSSEC. Such requests shall be accepted and processed in a secure manner and according to industry best practices. Registrars shall accept any public key algorithm and digest type that is supported by the TLD of interest and appears in the registries posted at: and . All such requests shall be transmitted to registries using the EPP extensions specified in RFC 5910 or its successors.

What this means is that registrars that wish to continue their ICANN accreditation must accept DNSSEC information from customers and relay that up to the TLD registries.

My understanding from people involved with the process is that the registrars are supposed to sign this agreement this year and if they do, the agreement is supposed to come into force by January 1, 2014.

While I’d of course love to think that this means that the big huge list of ICANN-accredited registrars will all be accepting DNSSEC records by January 1, I suspect that we’ll see some implementations by then… with others to follow at some point in 2014.  The good news is that this new RAA will cause some registrars to at least get DNSSEC higher on their priorities.

The other factor here is that all the “new generic TLDs” (a.k.a. “newgtlds”) that ICANN is planning to start adding over the next months and years all mandate that DNSSEC is included as part of their operations.  For registrars to fully support those newgtlds they will need to have DNSSEC support, anyway, so even without the 2013 RAA they will have another incentive to look at DNSSEC.

Now, the 2013 RAA only affects ICANN-accredited domain name registrars and there are certainly many other registrars that are not affiliated with ICANN.  They therefore won’t be required to support passing of DNSSEC records.  I’d like to think, though, that at some point there will be enough market momentum that those registrars will need to support DNSSEC … and hopefully lists like ICANN’s can just fade away as DNSSEC becomes just something offered by at least the majority of all registrars.

We’ll see… but this is certainly a positive step for removing this missing link for getting DNSSEC-signed domains into the global chain of trust.

I’ll note, also, that the 2013 RAA requires registrars to accept IPv6 records for domain names.  From that “Additional Registrar Operation Specification” on page 67 of the RAA:

2. IPv6

To the extent that Registrar offers registrants the ability to register nameserver addresses, Registrar must allow both IPv4 addresses and IPv6 addresses to be specified.

This, too, is excellent news as it will help organizations make their content and services more easily available over IPv6 in addition to IPv4.

Yet to be seen is how this all happens in reality and in what timeframe implementations actually occur… but it’s definitely a positive step in the deployment of both protocols and of enabling a more secure and innovative Internet.

P.S. If you’re a registrar looking to get started with DNSSEC and/or IPv6, please do browse our resources – and please do let us know if there are any ways we can help you get your deployment happening!  Are there specific questions you have?  Tutorials you’d like to see?  How can we help you?

NOTE: I should mention that I first learned of these RAA requirements through a talk that Michele Neylon gave at the ICANN 47 DNSSEC Workshop in Durban, South Africa in July. Michele now heads the Registrar Stakeholders Group within ICANN.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...