Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

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 <Michael.Bauland@knipp.de> 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:    Michael.Bauland@knipp.de
>       Software Development        E-mail: Michael.Bauland@knipp.de
>
>                                   Register Court:
>                                   Amtsgericht Dortmund, HRB 13728
>
>                                   Chief Executive Officers:
>                                   Dietmar Knipp, Elmar Knipp
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext