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]
