Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

Peter Thomassen <peter@desec.io> Mon, 08 May 2023 10:20 UTC

Return-Path: <peter@desec.io>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C4CC15199F; Mon, 8 May 2023 03:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ceZEL7A4O0Cu; Mon, 8 May 2023 03:20:37 -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 57F33C15199E; Mon, 8 May 2023 03:20:37 -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:Subject:From :References:Cc:To: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=Az38CNuZpFkjODlkSefNFgFQ5sZMJPEcMntvktbylsY=; b=a7jz1Kkk5p6MdevBYXaZcZivfE VbzPOWV5wUAxtJKdBmxpakpsyGujJPLkGMEYCrlBL3zZWGWo3RpnlkEshj1M4r5BALkPM3mPN2dxn WmfLx+do2iccmpLXf7aZ7XcTQ1cybItfx4elk4zF/Jijgy5I4xow5Z816awvsM7ycnqhFBOfHz3pK V5aLfTmrQhbzVa28UUIoS/gTHMlogmmjU61HTwQTuwA/eqg0jwCVDxnQWPcGafUQ4QAPHdvO49i4d dDz8Fb5kek2cx5skzDYcPCpsph2Nn4vYwuTCiSNzpE9Iuil36VUPFdh/cLscjqPxF974V0+AHgBfC +3cPb4Sw==;
Received: from [91.65.176.145] (helo=[192.168.178.70]) 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 1pvxyk-005YZL-Cs; Mon, 08 May 2023 12:20:26 +0200
Message-ID: <8f7797b2-ae60-e084-6dd6-b7b71ec022f9@desec.io>
Date: Mon, 08 May 2023 12:20:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Joe Abley <jabley@strandkip.nl>, he=40uninett.no@dmarc.ietf.org, warren@kumari.net
Cc: m9p@india.emu.st, dnsop@ietf.org, nils@desec.io
References: <1C10367C-B890-426F-A4F8-2D68E903ED39@icann.org> <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st> <CAHw9_iLyz4dhjmXm=eeqiVqQWOjYOgs45NbCtRtvrYpTFQHz=w@mail.gmail.com> <20230504.200747.619569100111463947.he@uninett.no> <8ee0d0dd-685b-f767-e5bd-d722cc873dc8@desec.io> <infYuCGtin93oe5p2i5xJp8pcRb7w42d543MM2sVkYVjvFHtzAXROt49cDyiguu_SZz7xg4xk802loka9IA_0U--Uu3cJIQOigisNvOOw7A=@strandkip.nl>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <infYuCGtin93oe5p2i5xJp8pcRb7w42d543MM2sVkYVjvFHtzAXROt49cDyiguu_SZz7xg4xk802loka9IA_0U--Uu3cJIQOigisNvOOw7A=@strandkip.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xUkQz0W1qUIEg0OxN_YiFYZZGa0>
Subject: Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2023 10:20:42 -0000

Hi Joe,

On 5/5/23 20:45, Joe Abley wrote:
> Pre-delegation checks add friction to the domain registration process.
[...]
> To look at it another way, why would we give authority to a third party to break our domains just because they are not fully-informed about how we are using them?

+1

My suggestion was not to create guidance or a best practice document for pre-delegation checks, but rather that *if* such guidance were developed, it should very prominently say what *not* to do, precisely because too many checks cause too much friction.

> And lastly, even if a delegation is genuinely broken and useless for all the world, and nobody cares enough to fix it, what harm does it do? What is the motivation to find a fix? A dribble of extra traffic relating to a mainly-unused domain to a nameserver that is already over-provisioned doesn't seem very compelling.

As a first reaction, I also agree with this (although I may be convinced by more data on cost/harm caused by the extra traffic, as Brian was hinting at).

> Even if I thought this was a problem that needed a solution, I don't think the solution is likely to be easy.

Yes. It may be easier to just arrive at a document advising against certain checks, that is, a Worst Current Practice doc ;-)

Peter

-- 
https://desec.io/