Re: [DNSOP] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

I thinnk you're agreeing that we should add notifications even though we 
can imagine a wide range of so-far nonexistent ways to limit the cost of 
scanning.

My thought is that the notify is for the domain to be signed, so there's 
no scanning, just parent checks to see whether it likes the new keys and 
if so, installs them.  I suppose the notification might get lost, but 
sending another one is likely to be faster than waiting for a scan.

> On Fri, Oct 13, 2023 at 10:48 AM John Levine <johnl@taugh.com> wrote:
>
>> I was looking at these two drafts. The first one says that scanning
>> for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
>> second one says to scan for DS bootstrap.  I am experiencing cognitive
>> dissonance.
>>
>
> I believe a more concise summary of the Notify vs CDS would be:
>
>   - Notify is better than scanning
>   - This is analogous to "Winning $1,000,000 in the lottery is better than
>   winning $10."
>
> It also is more helpful to consider the parties and benefits of using
> Notify.
> CDS scanning will always be necessary, for the use cases relevant here.
>
>   - Notify does not impact the scanning activity at all.
>   - Notify *does* reduce the time for a *specific* domain to have the CDS
>   processing done.
>   - Notify benefits the Registrant, not the Registry or Registrar.
>
>
> Similarly, the bootstrap process is likely to be further refined, if it is
> not already refined thusly:
>
>   - The DNS operator should maintain bootstrap zones for each scanning
>   entity (TLD or Registrar, as appropriate)
>   - Each scanning entity would then "walk" the corresponding bootstrap zone
>   - The feedback between initial DS publication at the TLD parent and the
>   bootstrap zone would look a lot like the mechanism used for CDS itself:
>      - Publish (CDS or bootstrap)
>      - Check TLD until DS is observed
>      - Change/remove record (CDS or bootstrap)
>   - This turns the relevant bootstrap zones into what are effectively
>   FIFOs, with the scanning entity having some ability to control the size of
>   the zone being scanned (by scanning more frequently)
>   - Since each of the bootstrap zones are DNSSEC signed with NSEC, they
>   can be very efficiently walked (this is a feature, not a bug)
>   - The scanner can further be optimized into a poll-then-scan-if-needed,
>   by using SOA record polling on the zone. Only scan if the poll returns a
>   new SOA SN.
>   - The use of Notify would be a trigger for the poll-then-scan, with the
>   Notify being scoped to the bootstrap zone itself
>
>
> Hopefully this fixes your cognitive issue. :-)
>
> Brian
>
>
>
>>
>> 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 issues in section 3 about why scanning is bad and
>> in section 4 about where to send the notification are exactly the same
>> as what's there now.
>>
>> I suppose you could overload NOTIFY(CDS) and the parent does one or
>> the other depending on whether the zone already is signed but it seems
>> to me that the operations are different so the notification might as
>> well be different too.
>>
>> Bonus update: if we do this, in the bootstrap draft take out section
>> 4.3 on triggers and instead say to use notify.
>>
>> R's,
>> John
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly