Dan York

Over on the CloudFlare blog today, Olafur Gudmundsson wrote a lengthy post titled “Updating the DNS Registration Model to Keep Pace with Today’s Internet” where he outlines a critical challenge that CloudFlare has run into on their path to implementing DNSSEC for their customers.

Essentially, the issue is this – on the signing side of DNSSEC, the process works like this:

1. A “DNS Operator” may host your DNS records and sign them with DNSSEC keys.  As part of doing this, they will generate a “Delegation Signer” or “DS” record that must be provided to the parent zone (typically a top-level domain (TLD)) to complete the “global chain of trust”.
2. The DNS Operator has to communicate this DS record to the Registrar for the domain.
3. The Registrar then provides this DS record to the Registry that operates the TLD.

This needs to be done initially when the domain is first signed with DNSSEC – and then the process needs to be performed every time the Key Signing Key (KSK) for the domain is rolled over.  Typically this might be done once each year but could be done more or less frequently.  The key point is that every time there is a key rollover, the new DS record must be communicated up to the TLD.

Here’s one way that I show the process graphically:

Notice the role of the Registrar here. They are in the middle of the process.

And THAT is CloudFlare’s problem.  They say they are hosting 2 million domains for customers.  In order for CloudFlare to automate DNSSEC signing to be as simple as a clicking/tapping a button in their user interface (as they have done for IPv6), they need to be able to interact easily with the registries for all those domains – and in the current system that means interacting with all the registrars!  Making it more challenging, some registrars have a clue about DNSSEC – and many others still don’t.

It’s a challenging issue.  As Olafur notes, there are now DNS records such as CDS and CDNSKEY, defined in RFC 7344, that can help with this, but they will require registrars to do some work to look for those records. But there are larger issues here that get into business processes, too.  For instance, many registrars are also DNS operators who will gladly host your DNS records for you for a fee – they have very little incentive to help make it easy for other DNS operators to host your domain.   There are a number of other issues.

Olafur began talking about this back at IETF 91 in Hawaii and this will be a big panel discussion at next week’s DNSSEC Workshop at ICANN 52 in Singapore (which will be streamed live and also recorded).

There is also a public mailing list set up for anyone who is interested in helping work on this issue.  You can join the effort and subscribe at:

https://elists.isoc.org/mailman/listinfo/dnssec-auto-ds

This work will be ongoing for quite some time and probably wind up in the DNSOP Working Group within the IETF.  It’s a critically important challenge we need to address to bring further automation to DNSSEC deployment and help many more people secure their domains.

Your feedback on all of this is definitely welcome!  Please do leave a comment here… or on Olafur’s blog post… or on social media… or contact Olafur directly.

And… if you want to get started with DNSSEC, please do visit our Start Here page to begin!