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

Reply via email to