Subject: Re: [DNSOP] Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
On 9/19/23 21:48, Tim Wicinski wrote:
>
> This starts a Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/>
I have read the document and I am supportive of the idea, but I find the
document not ready. Some issues I have with the document in the current form:
- It "deprecates" RFC8078 but does not offer a solution for all cases of
8078, such as when all nameservers are in-domain of the child.
- Section 4.3 is named "Triggers" but it basically only describes
"Timers". Some of us have significant scar tissue on this matter,
and I don't see new information or a new technology here that
resolves this old discussion. It feels a lot like restating RFC8078.
- Style: I think the document is a lot more verbose and repetitive than
it needs to be. Condensing this would increase clarity of the
document.
- There is the non-RRR model flavour of this and the RRR-model flavour.
What the parent can do greatly depends on the flavour and I think the
document instead focused on only using something that works with either
flavour.
- It seems WHOIS/RDAP could be better integrated for relaying a secure
signal instead of relying on insecure DNS lookups with the RRR-flavour.
For example, advising parents with delegation information (eg TLDs) to
lookup NS records in their own WHOIS/RDAP databse instead of using DNS
queries.
- There are issues with very long domain names not fitting in the
current signal. Why not use hashed FQDNs as part of the signal part.
Additionally this might have some privacy and security advantages too.
(including friendlier to query minimalization :-)
- I find Section 4.1 and 4.2 and the Security Considerations a bit of
of a weird split. A bullet list of things to do is specified but
then additional things are specified in the Security Considerations.
- The "_signal" name is very generic. It would be clearer to use a more
descriptive name that also has less chance of being used by completely
different technologies.
I think the goal of the document is to further widepsread automated
deployment of DNSSEC. This happens by the bigger DNS hosters, mostly
for delegations under a TLD. I think it best to limit the solution to
this space, and not try to fold in supporting other cases. Enterprise
deployments can use CDS/CDNSKEY with hooks in IXFR/AXFR detecting these
records automatically. All in-domain nameservers are people who registered
their own stuff and are running their own nameservers. Just let them to
EPP/Registrar UI. This of course goes back to like 2001 when the .nl.nl
experiment concluded what we really needed was a Security Contact.
The main use case is non-technical people getting a domain with DNS/web
hosting, where the DNS hoster uses DNSSEC and would like to tell the TLD
to enable DNSSEC. If the Hoster is the Registrar, there is no problem.
It should be able to use EPP to get a DS into the Registry. If the
DNS hoster is not the Registrar, then this EPP path is not available.
But usually those DNS hosters _are_ Registrars already, but only for their
own zones and their customers zone. Just this customer is using their
DNS service but not their registrar service. Place the information there,
eg via EPP. This would be much more secure than DNS timers/triggers.
If this is truly too complicated (which I think it should not be), DNS
signals could be used, but I would simplify it by telling the customer
that for moving the domain to the new DNS hoster, to add a special NS
record that indicates the DNSSEC information, eg:
customer.example IN NS ns0.dnshoster.tld.
customer.example IN NS ns1.dnshoster.tld.
customer.example IN NS <hash of DNSKEY>._cds.dnshoster.tld.
The DNS hoster can confirm they are the hoster by simply putting a
(signed) A/AAAA record at <hash of DNSKEY>._cds.dnshoster.tld. using one
of the real nameserver IPs as RDATA. This prevents people from
adding the DNS hoster without permission.
The parent can check all incoming NS records via their EPP system for
a match of "_cds" and do its "trigger" work. It could even suppress
actually including the special NS record in the parent zone but if it gets
published there is no real harm. Once DNSSEC is enabled by the Registry,
the DNS hoster can remove its special NS record and use CDS for further
updates, or the CDS nul record to delete all DS records.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
