[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
- [regext] CDS/CDNSKEY vs. EPP update prohibited Michael Bauland
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Hollenbeck, Scott
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Bill Woodcock
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Gould, James
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Michael Bauland
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Yoshiro YONEYA
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Hollenbeck, Scott
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Eric Skoglund
- Re: [regext] CDS/CDNSKEY vs. EPP update prohibited Andrew Newton