Re: [DNSOP] scanning doesn't scale, draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

[Peter Thomassen <[e-mail]>]

John,

On 10/16/23 18:19, John R Levine wrote:
> On Mon, 16 Oct 2023, Peter Thomassen wrote:
>> 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,

I did :-)

> #3 doesn't work very well, since every parent needs to scan all the signalling zones for all the nameservers they might be using.

For bystanders' context, we're discussing Section 4.3 of draft-ietf-dnsop-dnssec-bootstrapping.

No parent needs to scan anything. They might want to do so, if they think it's feasible for them, or they can find other solutions that are better for them, such as outlined below. (Or they might of course not do DS automation at all.)

A DNS operator and a parent may make an arrangement and agree on some method for how the parent can learn about the set of domains under the parent that have new signaling records. This method may be that the parent AXFR's the operator's signaling zone, which is but one of many options. Such an approach seems reasonable for large DNS operators which have many domains changing every day; a parent certainly wouldn't make such arrangements with every DNS operator in the world.

We're getting into a quite interesting topic space here, but it is entirely out of scope for this document. The document is concerned with how the parent can authenticate CDS/CDNSKEY records *after learning about their existence*; it does not deal with how to learn about their existence (beyond the very high-level, illustrative list given in Section 4.3).

> 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?

There are a bunch of very specific assumptions in here, "to make it not work". Consider the following:

- DNS operators like Cloudflare could provide a copy of the contents under, say, se._signal.jo.ns.cloudflare.com to the .se registry. If done via a separate zone, there will be no pollution from other TLDs. [*]

- Alternatively, DNS operators can provide TLD-specific catalog zones, or CSV-like feeds, even blockchain. Actually, the method of obtaining the list doesn't matter for the argument in Section 4.3.

- Someone like Cloudflare could allowlist the registry's IP addresses, and nobody needs to set up TSIG.

- The parties can agree to restrict this to only keep entries younger than a certain time period (e.g. 1 day + buffer), and in turn process it regularly. This makes a very well-tailored list of bootstrapping requests.

- It is conceivable that the processing be done by the registry, not the registrar (as is the case for today's deployments), so there is only one ingesting party that needs to be allowlisted (per parent).

- Alternatively, if the registrar does the processing, some registrar endpoint signaling is needed (as is pondered in the NOTIFY draft). But surely this is not in scope of this document.

The main point here is that *none* of this has anything to do with what the parent does *after* the trigger (whichever one) has fired -- which is what the document describes.


Why talk about triggers at all in Section 4.3? -- The parent needs to consider that, depending on the trigger mechanism, the trigger context will or will not convey reliable knowledge of the delegation's NS RRset, so for some trigger types it will have to match against its local delegation database before proceeding. Pointing this out is relevant for the authentication process, and is the purpose of Section 4.3.


We've digressed quite a bit from your criticism, which was your cognitive dissonance that this document "says to scan for DS bootstrap", which it clearly does not. I hope the cognitive dissonance has been cleared up :-)

As for how to learn about which are appropriate triggers, this indeed seems to be a gap where additional standards development could help, and I share some (not all) of your opinions. Let's put it into the NOTIFY draft, or a more general one that discusses other triggers as well (e.g. the feed-like mechanism hinted at above, or something based on catalog zones). But please let's not do it here.

>> 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.

This does not seem to make sense to me: For a conventional CDS lookup, you have to query the child's nameserver(s), which you need to resolve before you query it. The signaling records are subdomains of these names, so it adds little in terms of resolution overhead (unless you construct a case where the signaling zone is delegated to random other NS -- but why would that be the case). -- So, commonly, most of the resolution path will already be cached from the resolution process performed to get the apex CDS query.

>>> 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.

The dependency is artificial. People already do have CDS/CDNSKEY automation for some TLDs, and .ch/.li & Cloudflare (amongst others) have implemented this authentication protocol on parent/child side.

This protocol does not care what trigger mechanism .ch and Cloudflare are using between each other. That's not to say that it shouldn't be standardized; it just shows that the claimed dependency does not exist.

It also doesn't introduce nor endorse scanning. What it does is fixing an authenticity problem for parties processing CDS/CDNSKEY records. I'm not sure why this fix should wait for anything.

As can be seen in this message, the matter of triggers is complicated, and it might take quite some time to arrive at a good system that has consensus. Let's have this important discussion, but let's not hold up things that stand on their own and have no technical dependency -- even more so, as there's running code, and also code running.

> 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.

A note in that direction seems reasonable. How about adding the following paragraph after the bullet list in Section 4.3:

NEW
    The remainder of this section is concerned with how triggers may
    differ with respect to the context they provide, and in particular
    whether it is safe to infer a Child's set of Signaling Domains from
    the trigger context.  The triggers listed above are intended for
    illustration, and this specification does not recommend any
    particular one.  It is noted that concerns have been expressed
    regarding the scalability of parent-side scans.

Best,
Peter

[*]: This was discussed last year when the structure of the signaling names was figured out. It was noted that when se._signal.$NS is a separate zone, then it can't be a signaling name at the same time (because the semantics of the CDS/CDNSKEY record there would be ambiguous). That's why the _dsboot prefix was added.

-- 
https://desec.io/