I don't have much of an opinion either way, but from a basic troubleshooting perspective if EPP update prohibited applies to CDS/CDNSKEY then there might be a best practice to make sure the appropriate update prohibited status is set in RDAP, thus allowing the DNS admin some notion of why things are not working.
Reading RFC 8078, the abstract does hint to CDS/CDNSKEY being a work-around to EPP. Section 3 also discusses acceptance policy and there is no notion of an EPP like mechanism in there. Although it does seem like Section 3.4 would make a good EPP extension which could strike the right balance. -andy On Fri, Dec 2, 2022 at 8:54 AM Michael Bauland <[email protected]> wrote: > > Hi, > > On 02.12.2022 14:07, Gould, James wrote: > > Michael, > > > > The prohibited statuses apply to client requests, which matches Case 2. > > The prohibited statuses can apply to client requests via multiple channels > > (e.g., EPP or Web UI). The prohibited statuses don't apply to server > > actions (e.g., auto renew, transitioning RGP statuses). Use of CDS/CDNSKEY > > records to signal a server-side change is an interesting case, where does > > posting CDS/CDNSKEY records represent a client request that is processed by > > the server asynchronously? I view the CDS/CDNSKEY as a new operation > > (e.g., DNSSEC automation update), supported by IETF RFCs, that does not > > apply to the existing EPP prohibited statuses. All domain changes come > > down to an update, but EPP included prohibited statuses on a per operation > > / command basis. > > > > I would then define Case 3, where CDS/CDNSKEY records represent is a new > > client operation that does not apply to the existing EPP prohibited > > statuses. If we did want to prohibit this new operation via EPP, then a > > new prohibited status would be warranted. > > I tend to agree. Changing the DNSSEC data here is not an operation > requested/initiated by the client (i.e., registrar), but it's something > the server (registry) does, because it got triggered via the DNS. For > this reason the clientUpdateProhibited flag should be ignored. > > The RFC states: > "Requests to update the object (other than to remove this status) > MUST be rejected." > > The question is then, is the server looking for CDS records in the DNS a > request? I don't think it is. It is the server carrying out some > maintenance work (e.g., key rollover), admittedly for the registrant (or > rather the registrant's DNS provider). Nevertheless, it's the server's > decision, when and if a found CDS records leads to an update of the > domain's DNSSEC data. > > Cheers, > > Michael > > > -- > ____________________________________________________________________ > | | > | knipp | Knipp Medien und Kommunikation GmbH > ------- Technologiepark > Martin-Schmeisser-Weg 9 > 44227 Dortmund > Germany > > Dipl.-Informatiker Fon: +49 231 9703-0 > Fax: +49 231 9703-200 > Dr. Michael Bauland SIP: [email protected] > Software Development E-mail: [email protected] > > Register Court: > Amtsgericht Dortmund, HRB 13728 > > Chief Executive Officers: > Dietmar Knipp, Elmar Knipp > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
