Who do I hassle about RFC 7344 & RFC 8078 (CDS & CDNSKEY) support?

One of my domain registrars has a very manual process to get the DS records set up in the parent zone. Think:

  • Write a support ticket
  • Get it bounced back with the "we don’t support DNSSEC“ reply by 1st-level support
  • Then restating the issue … and figure out what data they need and in what format
  • And days later getting it handled by the apparently single person who understands the issue and can solve the problem — if that person happens to be available.

I was thinking about sending them a request to please automate this by supporting RFC 7344 & RFC 8078.

However from rereading these RFCs I’m not sure the domain registrar is the correct recipient for this request?

Wouldn’t the parent domain registry be the more appropriate recipient for such a request?
(The problem there is that the domain registrant generally does not have a direct customer relationship with the parent domain registry. So they might not be inclined to even take note of such communication.)

Technically the parent domain registry could just use existing CDS/CDNSKEY records to update the DS records for the subdomain zones. The only issue might be the initial setup, as mentioned in RFC 8078 section 3, when the domain is not yet fully secured by DNSSEC.

Any advice appreciated.

Thanks!
fiwswe

Hi,

The RFCs don’t prescribe whether the party to process CDS/CDNSKEY records is the registry or the registrar.

Some people say that the registrar should do it, because the registry is typically in the background, acting only upon the registrar’s request. Now, I think this is a circular argument (once you start doing it differently, the argument no longer holds).

In fact, most deployments in practice are by registries, and only very few registrars support it.

One complication of the registry doing the processing is that the registrar’s state might become outdated, unless the registry tells the registrar about the DS update. One way around this is for the registrar to not store the DNSSEC state itself. Another one is for the registry to send an EPP notification to the registrar, but the problem here is that these messages need to be proactively pulled by the registrar. (Nevertheless, this is how .se does it.)

If I were you, I would request automation from both the registry and the registrar. In the unlikely event that both will implement it, they can agree on a priority order between themselves.

That said, given the bad state of DNSSEC support at your registrar in general, it seems like you might want to consider moving your business to a registrar that is better at that. Let me know if you need suggestions.

Stay secure,
Peter

2 Likes

@peter Thanks for your detailed answer.

draft-ietf-dnsop-dnssec-bootstrapping-11 - Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator seems to be pretty far along, if I understand the standardisation process correctly? That would certainly help getting the initial DNSSEC setup up and running automatically.

The registrar in question was chosen primarily for their low prices for certain TLDs. So the fact that getting DNSSEC setup using external DNS at all is possible is already a bonus :wink: I will make the suggestion to automate this to them though as it may help to keep prices low if their support does not have to do this manually.

fiwswe

Good point!

Yes, the bootstrapping protocol is currently in the RFC editor queue, i.e. the IETF has approved it and it will soon be published as an RFC.

Stay secure,
Peter

2 Likes