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

[Johan Stenstam <[e-mail]>]

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).

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