How can we automate the communication between a DNS operator and a registrar when a DNSSEC key has changed?
I saw this issue very starkly myself the other week when I received 4 email messages from one of the DNS hosting operators I use telling me that new Key Signing Keys (KSKs) had been generated for four of my domains. Now, on one level this was good, in that they were automagically rolling the KSKs over without me having to do anything. However… they had no way to tell the registrars for those domains that a new DNSKEY record (and therefore a DS record) had been created. In other words:
The global chain of trust was now broken for those four domains.
Any DNS resolver performing DNSSEC validation would now find a broken chain of trust and would send back a SERVFAIL. People behind a DNSSEC-validating DNS server would not be able to reach my site.
Now, this happens for me because I use a different operator for my DNS servers than my registrar. If you think of the different players involved in the DNSSEC process, very often a registrar is also acting as a DNS hosting operator. In other words, when you register your domain with a registrar, they are also providing the DNS services for you. In that case the DNS hosting side of the company can communicate to the registrar side of the company that there is a new key and all can work well.
However, in my case the company providing DNS services for me is different from my registrar. I am paying a company for DNS hosting – but I could instead be hosting my own authoritative DNS servers. This might be common if I were an enterprise / business that operated my own data centers, for instance.
The key point here is that a registrar needs to pass a Delegation Signer (DS) record (or in some cases a DNSKEY record) up to the registry for the top-level domain (ex., .org, .com, .whatever). This needs to happen in order to have the “global chain of trust” work and to be sure that the DNSSEC signatures are not being falsified.
Within the DNSOP working group in the IETF we’ve been debating a number of proposals about how to fix this for quite some time. One of those proposals has now been issued as an Informational RFC 7344:
http://tools.ietf.org/html/rfc7344
Formally titled “Automating DNSSEC Delegation Trust Maintenance“, the RFC specifies the creation of two new DNS record types that you would use to signal to a parent zone (for example, a top-level domain registry) that you have a new DNSSEC record that the parent zone needs to retrieve. The two records are:
- CDS
- CDNSKEY
Typically you would probably use one or the other depending upon what your TLD registry requires, but both are specified within the RFC 7344.
The RFC goes into much greater detail, but in a nutshell it would work something like this:
- As the DNS operator of EXAMPLE.ORG, I would generate a new DNSKEY record (for the KSK).
- I would also generate a DS record and publish that as a CDS record.
- The parent zone, .ORG in this example, would notice that a new CDS record has been published.
- The .ORG registry would retrieve my CDS record and then publish it as a DS record for my zone.
- Once the DS record has been published I could then stop publishing the CDS record until the next time I made a change.
The global chain of trust would now be intact.
The key challenge of this approach is step #3 – how does the parent zone notice that a new CDS record has been published?
This is a critical point and one that was debated at some length. The primary thinking is that parent zones that want to use this type of approach would create some kind of “parental agent” that would poll zones periodically to see if there are new CDS records out there. RFC 7344 gets into this in section 6.1 and suggests that there could be both polling and pushing mechanisms developed. Such software is not yet out there, but now that the RFC is out it can certainly be developed.
In any event, this RFC 7344 is now out there providing one potential solution to this “DS upload” problem. What do you think? Is this something you can see implementing? Would you like to see your registries, registrars and DNS hosting operators supporting this approach? Do you have another idea?
P.S. Want to get started with DNSSEC? Please visit our “Start Here” page to find appropriate resources…