This is, imo, a far better and cleaner way to do this. Why the scheme field in draft-ietf-dnsop-generalized-notify was ignored at first is beyond me.
Ar Mer, 6 Awst 2025 am 10:13 Erik Bergström <erik.bergstrom= [email protected]> ysgrifennodd: > Hi, > > > > Thanks for the feedback. We recognize that overloading of the port field > can be problematic. > > We propose the following modification of > draft-berra-dnsop-announce-scanner. > > > > Instead of reusing the specified NOTIFY scheme defined in > draft-ietf-dnsop-generalized-notify we propose > > a new scheme, SCANNER, solely for announcing parent-side CDS/CSYNC > scanners. > > > > In draft-ietf-dnsop-generalized-notify the scheme NOTIFY is defined and > allows for more scheme to be defined. > > In draft-johani-dnsop-delegation-mgmt-via-ddns the scheme UPDATE is > defined. > > > > Any implementations of draft-ietf-dnsop-generalized-notify will safely > ignore any unknown scheme. > > > > The port field will still be overloaded to represent the scanning interval > in minutes, but only when using the new scheme SCANNER. > > > > Examples > > > > Absence of CDS/CSYNC scanners: > > > > _dsync.parent.example. IN DSYNC CDS SCANNER 0 . > > _dsync.parent.example. IN DSYNC CSYNC SCANNER 0 . > > > > > > Presence of scanners that check CDS and CSYNC once every 24 hours: > > > > _dsync.parent.example. IN DSYNC CDS SCANNER 1440 . > > _dsync.parent.example. IN DSYNC CSYNC SCANNER 1440 . > > > > > > This also allows an operator to signal that they support NOTIFY endpoints > while not running a bulk scanner across all children: > > > > _dsync.parent.example. IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net. > > _dsync.parent.example. IN DSYNC CSYNC NOTIFY 5360 > csync-scanner.example.net. > > > > _dsync.parent.example. IN DSYNC CDS SCANNER 0 . > > _dsync.parent.example. IN DSYNC CSYNC SCANNER 0 . > > > > > > This keeps the generalized-notify semantics intact and confines the > scanner signaling to a clearly delimited scheme that implementations can > safely ignore if unsupported. > > > > We haven't updated the draft with this yet, we hope to get some more > feedback before we do. > > > > Br > > Erik Bergström > > > > *From: *Petr Špaček <[email protected]> > *Date: *Wednesday, 6 August 2025 at 08:39 > *To: *[email protected] <[email protected]> > *Subject: *[DNSOP] Re: Announce Existence of Parent CDS/CSYNC scanner > > On 25. 07. 25 13:03, Joe Abley wrote: > > Hi Johan! > > > > Regarding draft-berra-dnsop-announce-scanner: > > > > I think reusing a port number field to mean a timer in units chosen to > be useful within the dimensions of the port number is a bit horrendous. > Reusing old parameters that are well-established but poorly used has been > done many times, and I think there are lots of eamples of such things > being good ideas. > > > > In this case the reuse is being proposed for a field that is far from > well-established, of which we have no real operational experience and in > fact for which the specification has not even been published. This is > madness, I think. > > > > I don't know procedurally how we would pull a consensus document from > the RFC editor queue and put it back into the machine, but I think we > should try if we can. > > I agree with all the points above. Worth a try to fix this properly > before it explodes into someone's face. > > -- > Petr Špaček > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
