[DNSOP] Re: Extending the semantics of DSYNC to enable parent to signal absence of scanner or frequency of scans.

[Peter Thomassen <[e-mail]>]

Hi Johan,

I think this is a fine thing to do.

There is a question of whether a scanner policy (existing with internal, or absence) should also be signal-able when another DSYNC record indicates a notification endpoint. I'm not sure this is useful, but I wanted to raise the point and see what others think.

Also, while learning the scanner interval might help the child operator predict when to expect the new DS RRset to be published (for example) and thus better judge whether there is a problem, there may be additional delays (e.g., when using the Accept-after-Delay method of RFC 8078 Section 3.3, which is used by some ccTLD registries). This raises the question how useful the retrieved interval is for a child operator (in the context of initializing a DS record set).

This concern of course does not change that utility of learning whether a scanner exists or not.

Best,
Peter


On 6/12/25 16:34, Johan Stenstam wrote:
> Hi all,
> 
> We just uploaded an absolutely trivial new draft that is intended to close two holes that should be easy to close once we have DSYNC published (it is in the RFC Editor queue since earlier this spring).
> 
> Announce Existence of Parent CDS/CSYNC Scanner <https://datatracker.ietf.org/doc/draft-berra-dnsop-announce-scanner/>
> datatracker.ietf.org <https://datatracker.ietf.org/doc/draft-berra-dnsop-announce-scanner/>
> 	ietf-logo-nor-180.png <https://datatracker.ietf.org/doc/draft-berra-dnsop-announce-scanner/>
> 
> <https://datatracker.ietf.org/doc/draft-berra-dnsop-announce-scanner/>
> 
> What holes may that be?
> 
> Hole #1: what is the frequency of the parent scanner?
> 
> As I work for a parent (.SE) that actually does both CDS and CSYNC scanning I know for a fact that we regularly get emails from children that are confused that we have not picked up on the CDS or CSYNC that they just published. We explain that the scanner only runs once every 24h and case is closed.
> 
> Hole #2: is there a scanner at all or not?
> 
> Up until now there has been no standardized method for finding out (a) if there is a parent-side CDS (and/or CSYNC) scanner. Sure, we publish the existence on a web page somewhere, but I’m sure that child-side software will not read that. I’m also sure that other scanner operators publish existence of their scanners in some way differently from how we do it. And also human operators will typically not bother to hunt for that information.
> 
> However, my assumption (or perhaps, my hope) is that as DSYNC gains use there will be an increasing amount of child-side software systems that look for the DSYNC RRset to figure out how to announce new CDS and/or CSYNC publications. So then we can obviously use that to send signals back directly to the child system.
> 
> Our proposal is the following:
> 
> a) To signal the ABSENCE of a scanner or the FREQUENCY of a scanner that does not support generalized notifications the parent should publish a DSYNC record with a Target of “.” I.e. the target “.” should be interpreted as “don’t send notifications here, we’re just trying to tell you something”.
> 
> b) In the ABSENCE of a scanner, set the Port to 0 (zero). I.e.:
> 
> example.    DSYNC CDS NOTIFY 0 .
> 
> is effectively a statement that says “there is no CDS scanner here, we will not se your CDS records, don’t email us to ask whether our scanner is broken, etc…”
> 
> c) In the PRESENCE of a scanner, but no support (yet) for generalized notifications, set the Port to the intended frequency of the scanner, measured in minutes. I.e.:
> 
> Example.     DSYNC CSYNC NOTIFY 1440 .
> 
> is a statement that “yes, there is a CSYNC scanner, but it only runs once every 24h and we do not (yet) support generalized notifications, please have some patience”.
> 
> Consequences:
> 
> Parent-side there is zero implementation work. Publishing these records is just policy statements.
> 
> Child-side there is limited implementation work to deal with this information from the parent. If a child-side implementation doesn’t want to deal with this information then that’s ok and nothing will break. But, presumably child side implementations are not yet set fully in stone, and by checking this data (if it is published by the parent) may allow them to set expectations correctly and thereby work better.
> 
> The draft is only a couple of pages long and we appreciate all and any comments.
> 
> Regards,
> Johan
> 
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525