On Tue, 24 Dec 2024, Edward Lewis wrote:
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).
Honestly, I have no idea. This might work but it feels like a house of
cards. We could try to invent some way to send back error status but it's
not obvious to me how you'd do it. NOTIFY isn't great since you have no
way to tell whether the party sending the notifications is the same party
that manages the child zone, or just someone rattling the doorknobs.
If registries or registrars are going to implement a DNS update scheme,
I'd think it'd more likely be Ddomain Connect or something like it that
uses OAuth to deal with the third party issue and sets up a two-way
channel that can send useful result reports.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
