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 <jo...@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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
