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

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.  

-- 

JG

James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 12/2/22, 6:41 AM, "regext on behalf of Michael Bauland" <regext-bounces@ietf.org on behalf of Michael.Bauland@knipp.de> wrote:

    Hello,

    I've recently come across a case in the context of CDS/CDNSKEY and I'm 
    unsure what is the best/correct way to handle the situation.

    CDS/CDNSKEY records are meant to notify the registry about a change in 
    the DS/DNSKEY records, similar to sending an EPP request.

    What should the registry do, if
    1. the serverUpdateProhibited EPP state is set?
    2. the clientUpdateProhibited EPP state is set?

    I tend to say that in Case 1, the domain may not be changed at all and 
    as a consequence CDS/CDNSKEYs should be ignored.

    For Case 2 my preference is that this is only a kind of safeguard 
    against unintended changes by the registrar, and the DNSSEC update is 
    most likely intended and should go through. Furthermore, some registrars 
    might set this state regularly, which would then take away the 
    registrant's possibility to roll over their DNSKEY. This most likely is 
    not intended.
    However, one could of course argue: update prohibited means update 
    prohibited, and as long as that state is set, no changes (other than 
    removing this state) should be possible.

    What do others think about these cases?

    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://secure-web.cisco.com/1mEpKtXjsuVbK-xXNutAu2eLBX3bt-bjQqZChp1HEVcTMmoCcnfG_0hMFCo-Ofk6lXl_mTcEgh18oXp1y9xBCLBIC96tcHfPB2EzViMvxW7b5j7MPJ0Mmwlbi0E1p4cY-ho7Ovt1EDkg5DdwoskqCbaGAU0AEeESOH2-Zw3qYdWQruN3Wrvbt1WYQ7COdIo49RfNj5p2K_fzit1-pi_9yTtkVO8bl4Vok6E9VvpWGP2G8RhZhtB6Fr8LRi219iUiq6io42GCY1aX5J-qt52SPBvJsXQhqvz1q0GcNsZlPXX0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext