On Mon, 16 Oct 2023, Peter Thomassen wrote:
1. the parent receives an updated NS RRset,
3. the parent obtains a copy of a signaling zone and walks the signaling
records published there (at _signal.$NS, such as
_signal.jo.ns.cloudflare.com),
If you think about it for a moment, #3 doesn't work very well, since every
parent needs to scan all the signalling zones for all the nameservers they
might be using. Cloudflare hosts at least a million zones which I'm sure
are in every public TLD, so that means we have a thousand TLDs and/or a
thousand registrars all scanning Cloudflare's signalling zone which is not
going to be small. How's that going to scale? For that matter, how's
Cloudflare going to give the TSIG or whatever to the thousand scanners to
let them do it?
2. the parent chooses to do a scan,
This is no better. For CDS scanning the scan is a single query to a
single known server only for zones that are already signed. But for this,
it has to scan all the unsigned zones, and since the NS can be anywhere,
each scan is a full recursive lookup. That's a lot of traffic to a lot of
servers all over the net.
I suggest adjusting the bootstrap draft saying to send NOTIFY(DS) to
the parent of a delegated name to tell it to do the bootstrap rather
than scanning.
The draft is not at all concerned about how the child triggers the parent,
but only with what the parent does *once the parent has determined* that it
is going to attempt DS initialization.
Right. We need to fix that gap now, when we can do it easily by updating
the drafts in progress. It's totally normal to have two drafts
progressing that depend on each other.
I wouldn't forbid the other approaches but I would note that they are not
likely to scale well to large zones like popular TLDs.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop