Peter, I like the concept a lot and this is a good natural evolution, My comments/issues #1 this should cover normal notify as well as there is no reason parent should have to be updates every time an external DNS provider changes its distribution "top" #2 I would love the examples to use a different port than 53 as there is no need for the notifies to go to that overloaded port #3 As of new type vs SRV the argument against new type at apex is always size of ANY, which I do not buy but I like new types :-) #4 It should be clear that there is no need to run a "nameserver code" as the target of the NOTIFY messages, similarly there is no real reason why the issuer of the Notify is a "nameserver code" i.e. both of ends are front/back ends of provision systems
Olafur On Tue, Nov 29, 2022 at 7:37 AM Peter Thomassen <pe...@desec.io> wrote: > Dear DNSOP, > > Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation > maintenance are usually detected through scheduled scans run by the > consuming party (e.g. top-level domain registry), incurring an > uncomfortable trade-off between scanning cost and update latency. > > A similar problem exists when scheduling zone transfers, where it has been > solved using the well-known DNS NOTIFY mechanism ([RFC1996]) which enables > primaries to nudge secondaries when there's a zone update, allowing the > latter to initiate an out-of-order zone transfer and reset the serial check > timer. > > At the IETF a few weeks back, Johan and I felt a sudden enlightenment when > it occurred to us that the same approach could be used to reduce scanning > cost for CDS/CSYNC scans and the like, while maintaining low update > latency. In fact, the NOTIFY spec already does allow sending NOTIFY message > of other types. So, we not use that for hinting beyond SOA? > > We wrote up a draft, and if you'd like to read how one could make this > work, feel free to take a look: > --> > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ > > There is also an application in multi-signer setups, where Viktor had > brought up the problem of ZSK rollovers by one signer, and how the others > would know about that. That's not as well fleshed-out yet, but we figured > it shouldn't keep us from circulating the initial idea. > > Best, > Peter > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-thomassen-dnsop-generalized-dns-notify-00.txt > Date: Mon, 28 Nov 2022 13:10:10 -0800 > From: internet-dra...@ietf.org > To: Johan Stenstam <johan.stens...@internetstiftelsen.se>, Peter > Thomassen <pe...@desec.io> > > > A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-00.txt > has been successfully submitted by Peter Thomassen and posted to the > IETF repository. > > Name: draft-thomassen-dnsop-generalized-dns-notify > Revision: 00 > Title: Generalized DNS Notifications > Document date: 2022-11-28 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.txt > Status: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ > Html: > https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify > > > Abstract: > Changes in CDS/CDNSKEY, CSYNC, and other records related to > delegation maintenance are usually detected through scheduled scans > run by the consuming party (e.g. top-level domain registry), > incurring an uncomfortable trade-off between scanning cost and update > latency. > > A similar problem exists when scheduling zone transfers, and has been > solved using the well-known DNS NOTIFY mechanism ([RFC1996]). This > mechanism enables a primary nameserver to proactively inform > secondaries about zone changes, allowing the secondary to initiate an > ad-hoc transfer independently of when the next SOA check would be > due. > > This document extends the use of DNS NOTIFY beyond conventional zone > transfer hints, bringing the benefits of ad-hoc notifications to DNS > delegation maintenance in general. Use cases include DNSSEC key > rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY), and quicker > changes to a delegation's NS record set via NOTIFY(CSYNC). > > TO BE REMOVED: This document is being collaborated on in Github at: > https://github.com/peterthomassen/draft-thomassen-dnsop-generalized- > dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop- > generalized-dns-notify). The most recent working version of the > document, open issues, etc. should all be available there. The > authors (gratefully) accept pull requests. > > > > > The IETF Secretariat > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
