Hi Ray, On 2/13/21 2:20 PM, Ray Bellis wrote: >> I am intrigued by your suggestion to use CSYNC RR to signal SOA Serial >> numbers and to help out in. And indeed, the flags in CSYNC's flags rdata >> field appear to have helpful names and meanings with respect to clashing >> member zones and member zone transitions. What a good catch! How did we >> miss that? > > When I had the edit pen on an earlier version of this draft I went to some > lengths *not* to abuse the semantics of existing RRs that just happened to > have RDATA that was sorta kinda compatible.
The suggestion was not to use anything sorta kinda compatible. (Coming up with some TXT-based format would be such as hack.) CSYNC actually fits very well. The purpose of CSYNC is to signal a "should-update" state, along with flags that govern the serial comparison mode and the question of immediate or delayed action. As I showed in my original post, this is exactly what's needed in catalog zones. What exactly are your doubts here? > IMNSHO, it's unnecessary, and confusing. It already has been recognized in earlier discussions that it's necessary to handle the transition of zones from one catalog to another, and it has been shown how "the flags of CSYNC" would enable that. Not addressing any of those arguments, you're suggesting that "it" (?) is unnecessary. As it stands, I'm interested in learning what would be your alternative proposal for dealing with zone transitions. As for the confusion, I'm not sure what it stems from. Who should be confused in the first place? Zone owners are not going to touch catalog zone internals, so it is auth vendors who would mostly be concerned. Given that they will (soon) have CSYNC experience anyways, I wonder how confused they really would be. Perhaps it would be worth gathering some data from them. > Getting new QTYPEs assigned is not hard these days. I'm not following how that in itself is an argument for creating a new type. I'd be delighted if you could clarify. While assiging one is not difficult, it surely is a non-negligible effort to make all other components of the ecosystem aware. For example, some people have replication that involves processing through libraries such as dnspython. This particular library already supports CSYNC. Requiring a new type would unnecessarily (!) create new adoption barries like that. Best, Peter -- https://desec.io/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
