On Dec 24, 2024, at 14:01, John Levine <jo...@taugh.com> wrote: > > > See RFC 1996, section 4.8. >
Ahh - but I’d have tagged 4.7. The query ID, whose relationship to NOTIFY is a bit different from regular queries. > Remember that the notification is just a hint. Whatever receives the NOTIFY > might decide > to try the update on its own, so I don't see any new issues here. You're > right that if a > CDS key roll doesn't happen, there is no way to tell the child what the > problem was, but > that's been true as long as there's been CDS. Trying to make sense of what I am thinking … if the goal is to automate the child-to-parent provisioning channel, we have three ingredients - CDS (and CDNSKEY), generalized NOTIFY, and EDNS0 Error Reporting. If you combine these three ingredients, you can or will (depending on your enthusiasm level) what is needed to automate the provisioning channel. Whether this gains significant operational traction is my concern. If so, good. If not, then I need there needs to be an end-to-end definition of how all these ingredients work together. Something that simplifies the complexity of the three disparate mechanisms (CDS, generalized NOTIFY, and EDNS0 Error Reporting). CDS has been around for about a decade. It is in use in a few places and reportedly working well. But still just a few places. I bet that before we see wide spread adoption of automating this channel, the combination of these ingredients needs to be sufficiently integrated, enough for operations. I don’t think the generic TLD restrictions are the bottleneck. Even though there are 3 or 4 times as many gTLDs as ccTLDs, due to backend operator consolidation, there may be more ccTLD operators than gTLD operators (handwaving…and some operators are both). From this, I suspect that CDS has got to be wrapped in something more operator friendly to gain more ccTLD operators before I’d agree that gTLD restrictions are the bottleneck. I’m not trying to tear down CDS or generalized NOTIFY, I’m just looking for what gaps still exist before there is something that makes this a no-brainer for an operator to deploy. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
