Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

Peter Thomassen <peter@desec.io> Wed, 26 July 2023 00:20 UTC

Return-Path: <peter@desec.io>
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 A6C97C151B03; Tue, 25 Jul 2023 17:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 XwlBmadH9LRx; Tue, 25 Jul 2023 17:20:16 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316B0C151536; Tue, 25 Jul 2023 17:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BFspoK3b99YpMknahYwh+oUj5NYYc6S4bTiwb3dPI2E=; b=XB8fjIPcPkabeXL3glJ82VdAfb FEz+1gEFAwJc4gk8UmEVzuGyzDZvOb70Ge4F9q3Le9omo6k8vBKxuSdeYfBi9ZawajhJb6hNBfNoy tYc+cEun+hZ8JUj4Fxh/hAaM8BoDnZxL/DMVtfxenVXCU+n66Shg+kO0gZj7+d9iR9vNkwD9jAxJ2 2/cSFyxwBv+jVnkAl1aouXPIFrQiOPr4gclwawC9SaylSLhlrZAtgPDsLGc/FNCQloZwU9pYPt5HY OKs/ru2VNhicUZTkDrE7G8HVM15OgkADoevlv5lDrRUAUw93JiQ0UFEZFItQNg3+uijP0iQ4G/egH hhqzzJlA==;
Received: from [2a00:20:d049:28e0:5fad:a3a2:2b75:a6f8] by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1qOSGD-00GnfT-5i; Wed, 26 Jul 2023 02:20:13 +0200
Message-ID: <bd1f2498-52cb-4788-488a-1d98cc434bfe@desec.io>
Date: Tue, 25 Jul 2023 17:20:06 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: en-US
To: James Mitchell <james.mitchell@iana.org>, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: "regext@ietf.org" <regext@ietf.org>
References: <f22489a2b7c14b3bb4d250dabb4b5999@verisign.com> <205E819D-ABFA-435C-8C23-1E0BE949AD64@iana.org>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <205E819D-ABFA-435C-8C23-1E0BE949AD64@iana.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/ryFxFu7hKjVyvSaB0_TcGkvPUCI>
Subject: Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
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: Wed, 26 Jul 2023 00:20:20 -0000

Not being an EPP expert, it seems to me that if the below works (which it seems to have?), it addresses pretty much all concerns in a very reasonable way. Would there be any reasons for not making this the recommended practice?

Peter

On 7/25/23 14:39, James Mitchell wrote:
> Feedback my own and not from IANA.
> 
> If I recall correctly, the approach I took when building an EPP server several years ago was:
> 
>   * allow deletion of domains with linked subordinate hosts – there is no need to prevent this if the registrar can simply rename the subordinate hosts and free themselves of this restriction
>   * when the domain is removed from DNS (deletion, but also client/serverHold) then the delegation and any glue is removed from the DNS – queries for the name result in NXDomain. I believe we left lame delegations from other domains for simplicity, but these lame nameservers could also have been pulled from the DNS.
>   * when the domain is purged, purge all subordinate hosts, including all their nameserver associations, and remove those records from the DNS. At this point there are no NS records with target at or below the deleted domain - no lame delegations.
>   * domains with one remaining name server remain published in the DNS
> 
> It may be worth noting that we used a narrow glue policy - only publish glue address records for name servers below the delegation. A wide glue policy may require slightly different actions to prevent promoting glue records to authoritative.
> 
> Host rename always seemed a dangerous operation – we ended up allowing it but restricted to renaming hosts within the same domain, eg ns1.example.com to nsa.example.com, but not to nsa.another-example.com.
> 
> I was not okay with allowing a third-party registrar to prevent deletion of a domain by creating subordinate hosts, and I was not okay by allowing one registrar to change the delegation for another domain (through a rename outside the existing domain boundary).
> 
> Best,
> 
> James Mitchell
> 
>     On Jul 11, 2023, at 12:07 PM, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
> 
>     Folks, we could really use feedback from people with DNS expertise to help
>     document a set of best practices for managing existing DNS delegations at the
>     TLD level when EPP domain and host objects are deleted. As described in this
>     draft:
> 
>     https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/__;!!PtGJab4!41ouVfZv-H-PkXJbxqURrX_y9d7JQb9SgFWJPcgp_h5k9ANClcwQBC_sayAWJb2Vf3GsszmkeckGNdzGeTAzkX7_dChe_p3b2Lnb-bPfrw$ [datatracker[.]ietf[.]org]
> 
>     EPP includes recommendations to not blindly delete objects associated with
>     existing delegations because, among other reasons, doing so can lead to DNS
>     resolution failure. That's led some domain name registrars to implement
>     creative practices that expose domains to risks of both lame delegation [1]
>     and management hijacking. The draft includes descriptions of current known
>     practices and suggests that some should be avoided, some are candidates for
>     "best", and there are others that haven't been used that might also be
>     candidates for "best". The authors would like to learn if others agree with
>     our assessments and/or can suggest improvements.
> 
>     Please help. ICANN's SSAC is also looking at this issue and expert opinions
>     will help us improve DNS resolution resilience. I plan to mention this quickly
>     at IETF-117 given that the WG agenda is already full, but on-list discussion
>     would be extremely valuable.
> 
>     Scott
> 
>     [1] As described in draft-ietf-dnsop-rfc8499bis.
> 
>     _______________________________________________
>     DNSOP mailing list
>     DNSOP@ietf.org
>     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!41ouVfZv-H-PkXJbxqURrX_y9d7JQb9SgFWJPcgp_h5k9ANClcwQBC_sayAWJb2Vf3GsszmkeckGNdzGeTAzkX7_dChe_p3b2Ll6XinPdw$ [ietf[.]org]
> 
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525