Hi,

> Subject: Call for adoption: draft-berra-dnsop-announce-scanner-02  (Ends
> 2025-12-18)
> 
> This message starts a 2-week Call for Adoption for this document.
> 
> Abstract:
>   In DNS operations, automated scanners are commonly employed by the
>   operator of a parent zone to detect the presence of specific records,
>   such as CDS or CSYNC, in child zones, indicating a desire for
>   delegation updates.  However, the presence and periodicity of these
>   scanners are typically implicit and undocumented, leading to
>   inefficiencies and uncertainties.
> 
>   This document proposes an extension to the semantics of the DSYNC
>   resource record, as defined in [RFC9859], allowing parent zones to
>   explicitly signal the presence and scanning interval of such
>   automated scanners.  This enhancement aims to improve transparency
>   and coordination between child and parent zones.

Yes, please.

Again, not surprising, given that I’m one of the authors.

The rationale for me (and I point this out because this was not originally my 
idea, but something my co-authors came up with while I was on vacation :-) is 
the reality that we have a growing number of mechanisms for updating 
delegations.

And the more mechanisms there are, the more important it becomes to have a 
standardized method for children of inquiring which mechanisms their parent 
supports. This is exactly the role that the DSYNC RRset is intended to fulfill.

But now that DSYNC is there to help parents publish what mechanisms they 
support, then it would seem, well, stupid, not to be able to publish the fact 
that there is a CDS (or CSYNC) scanner, and what its requirements are. Scanners 
were the first mechanism for automatic delegation synchronization and as such 
they obviously pre-date RFC 9859 where DSYNC was defined.

We can trivially fix this now. “Trivially”, because there are no code changes 
needed, this only about publication of the *existence* of scanners (and their 
parameters) in a standardized way. 

It is this small, but noticeable, hole this draft aims to fill.

Regards,
Johan Stenstam

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to