On Thu, Sep 2, 2021, at 04:39, Martin Casanova wrote:
> Lets assume a singed domain is being transferred but the new registrar
> (still...) does not support DNSSEC and is therefore not able to delete
> or modify the DS/KeyData at the registry. In that case the domain can
> not be resolved anymore by validating resolvers until the DS/KeyData is
> deleted at the registry somehow.
More precisely, things will continue to work as long as the nameservers
continue to publish the relevant DNSKEY. By itself a change of registrar
does not change anything, except
- if the registrar was also the DNS provider then it will stop provide
DNS resolution (typically), hence customer has to change providers, and then
its domain will start to fail DNSSEC validation as the current keys won't
be at new provider
- the customer won't be able to manage its KSK rotations if it can't
provide new ones through registrar to push to registry.
Note also RFC 8063 "Key Relay Mapping for the Extensible Provisioning Protocol"
that
touches these subjects. AFAIK only "nl" registry implemented it.
> What is your policy/solution for this case? Here I outlined some
> possibilities:
>
> - Keeping track (based on login <svcExtension> at login?) which
> registrars do DNSSEC and prohibit transfers of singed domains in case
> secDNS-1.1 is missing?
> This unnecessarily limits transfers of singed domains to DNSSSEC
> unable registrars if the domain was signed via CDS where the domain was
> singed by the name-server owner. (no registrar involved)
>
> - Deleting the DS/KeyData when the nameservers changes? (This would
> raise further questions..)
> - Support ticket of registrar and manual deletion by the registry ?
> - ...
All these cases exist in the wild indeed, which may show that there
is no one size fits all situation here.
Plus at least:
- registrars need to be specifically "accredited" for DNSSEC in advance,
through
a separate test; hence the registry knows which ones are DNSSEC-"enabled"
and which one aren't, and hence at time of transfer the registry can deny
the transfer from DNSSEC enabled to NON DNSSEC enabled
- the transfer command has an extension with an attribute "keepDS" for example
to tell the registry if it should keep or drop the current DS records once
the transfer is finished (note also that for some other registries,
the transfer command is extended so that the registrar has to provide the
new nameservers at that moment, and hence it can provoke immediate side effects
regarding DNS resolution and DNSSEC validation)
- and also, not at the technical level, the agreement signed by registrar
may force it to support DNSSEC... it is like that in gTLD world, see
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en :
"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."
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
