[regext] CDS/CDNSKEY vs. EPP update prohibited

Michael Bauland <Michael.Bauland@knipp.de> Fri, 02 December 2022 11:41 UTC

Return-Path: <Michael.Bauland@knipp.de>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B59C14CEE4 for <regext@ietfa.amsl.com>; Fri, 2 Dec 2022 03:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH7mAfvj-pwA for <regext@ietfa.amsl.com>; Fri, 2 Dec 2022 03:41:15 -0800 (PST)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [IPv6:2a01:5b0:0:29::63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A9FC14CEED for <regext@ietf.org>; Fri, 2 Dec 2022 03:41:13 -0800 (PST)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [IPv6:2a01:5b0:0:25::36]) by kmx5a.knipp.de (Postfix) with ESMTP id 4NNrcQ0hpkz4v4B for <regext@ietf.org>; Fri, 2 Dec 2022 12:41:09 +0100 (CET)
Authentication-Results: kmx5a.knipp.de; dkim=none; spf=softfail (kmx5a.knipp.de: 2a01:5b0:0:25::36 is neither permitted nor denied by domain of Michael.Bauland@knipp.de) smtp.mailfrom=Michael.Bauland@knipp.de; dmarc=none
Received: from [IPV6:2a01:5b0:0:25::69] (unknown [IPv6:2a01:5b0:0:25::69]) by hp9000.do.knipp.de (Postfix) with ESMTP id 7D4927299D for <regext@ietf.org>; Fri, 2 Dec 2022 12:41:09 +0100 (MEZ)
Message-ID: <191008c7-b37c-e311-6d8d-1c43053f1d98@knipp.de>
Date: Fri, 02 Dec 2022 12:41:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
To: "regext@ietf.org" <regext@ietf.org>
Content-Language: en-GB
From: Michael Bauland <Michael.Bauland@knipp.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Rspamd-Action: no action
X-Rspamd-Server: v1117
X-Rspamd-Queue-Id: 4NNrcQ0hpkz4v4B
X-Spamd-Bar: /
X-Spamd-Result: default: False [-0.10 / 15.00]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:8391, ipnet:2a01:5b0::/32, country:DE]; DMARC_NA(0.00)[knipp.de]; MIME_TRACE(0.00)[0:+]; R_SPF_SOFTFAIL(0.00)[~all:c]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[regext@ietf.org]; LOCAL_WL_IP(0.00)[2a01:5b0:0:25::36]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]
X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: LOCAL_WL_IP
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/spw9BOlGDmETvobc8QEo9lZxCyk>
Subject: [regext] CDS/CDNSKEY vs. EPP update prohibited
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2022 11:41:17 -0000

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