On 6/20/23 17:48, Paul Wouters wrote:
I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed to overloading).
Agreed.
That's not what the TLDs said during "timers vs triggers". They did not
want NOTIFY's towards their production nameservers.
The draft does not propose that.
That might have
changed, but I would like to hear from the big TLDs that they are now
in favour of this and would deploy.
The drive is this time not coming from the parent side, but from discussions
around DS automation at recent ICANN DNSSEC workshops, and DNSSEC multi-signer
scenarios.
The main two arguments made there were scaling concerns for large parent zones
(although I don't think these concerns are supported by data), and better
predictability (for child-side entities) of when C* records can be expected to
be discovered and processed.
It would indeed be interesting to learn what TLD registries have to say,
specifically those who already have quite advanced CDS scanners (e.g. SWITCH,
who also have implemented authenticated bootstrapping).
If not, perhaps a level of indirection via service record should be
used to point to a specific server (which could still accept NOTIFY)
outside of the parental NS RRset.
That's the point of the NOTIFY record (whose field list may be reduced, perhaps
eventually to a CNAME, see other postings).
Also the registrars did not like being circumvented. While now some
registars might have changed their mind (or don't care since they
are both registrar and dns hosting for most of their domains), it
would be good to hear from them.
Agreed; there are various good arguments for why the scanning should be done by
the registrar (if there is one). But I don't see why this would be a problem
with regards to NOTIFY (we can make it work by prepending the child label to
the service record qname).
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
