[DNSOP] Re: Call for Adoption: draft-davies-internal-tld

Ted Lemon <mellon@fugue.com> Wed, 23 April 2025 12:01 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0745C1FF0B44 for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 05:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=fugue.com header.b="OdvRgBnW"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="PV8/Fuh1"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am89s6qHtBVX for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 05:01:07 -0700 (PDT)
Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id ECD781FF0B34 for <dnsop@ietf.org>; Wed, 23 Apr 2025 05:01:07 -0700 (PDT)
Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id B6E3E11402F2; Wed, 23 Apr 2025 08:01:07 -0400 (EDT)
Received: from phl-imap-10 ([10.202.2.85]) by phl-compute-12.internal (MEProxy); Wed, 23 Apr 2025 08:01:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue.com; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1745409667; x=1745496067; bh=CWIjZ6aX7n 2g0neMQJEoaVVFv83rsBlEeGRzk6AqdaE=; b=OdvRgBnWc8642GhsyZvkA8UrZV MrETWENu9W1Vo1vnBtRs1aPleq1eG8DjYatt9wRZmQp0kSdtc3NR19ZF3YjXQYU5 jQb7K/6JmvPRaSJbszCYGlW7a7KC3uWmmsw7OeYHt9U57Z6mhaegYK4Q/uFzOdxB q1vNg0BuNkWDrlA2MQjS52KxX9hMp9PxBu99D0yB089bPB0tkzY6u36+itRhcp0e Lc4g2ZW2b2iWZFa4sn5FHeyTGWj11ImSDQljpCoZkgFK7MT1fn8xoPlno7iUuaoG cftgXqbL7hWCp1kfNcogHT4pzN49jGKDs/llLtByTvANUx0gDrN90r3chm4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1745409667; x=1745496067; bh=CWIjZ6aX7n2g0neMQJEoaVVFv83rsBlEeGR zk6AqdaE=; b=PV8/Fuh1fJl1MmLqpu52/icuK62sq5Arc80Ocmpdmw1YQ9WCOgo ElEOwB4kK+wOAHJdYoronBVo2bpbtUi4fbl3oSSjHAtlnDZMK2aJI63Q2yc131w/ Cb/QVZkwQ6Z55GYbCg0jcwrh2zDupAoIrraBXPZRd2UjlJh++j4T0J7qtURMmg2H E3gZPP5ifoG99/Ol65jWgTez+u6mQWBypIybL2qDrq/ekRN07SRmcQ9ZSszMSAi2 4W8b8FBbVISePK/bbcSvwk9lhmQyIFxaCgR6Gp97gwNVymhg1w2ZW5PiwVDQ2Y6r IG//gMkpP84VQWls/ShnamC2/Tf7u26x3kw==
X-ME-Sender: <xms:gtYIaJBuDbkQjNThCkreIFZ73CLHjZqLNytD1ZP1VAXohh6PRrcWmA> <xme:gtYIaHiPw_DNjo1e8-6rUFXGmLt74aAwTLaWp3ofIN3uFFGQUIbqyRB9jm_QmIYrI a4odC4oIhC9pe4Mkzs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgeeiheegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerredt jeenucfhrhhomhepfdfvvgguucfnvghmohhnfdcuoehmvghllhhonhesfhhughhuvgdrtg homheqnecuggftrfgrthhtvghrnhepkeefgfekteeileeuffeuhfethffgleelheefheeg hfefuddtieffhefhvdetteeunecuffhomhgrihhnpehitggrnhhnrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgvlhhlohhnsehf uhhguhgvrdgtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprh gtphhtthhopegrnhgurhgvfiesuggvphhhthdrtghomhdprhgtphhtthhopehpvghtvghr peegtdguvghsvggtrdhiohesughmrghrtgdrihgvthhfrdhorhhgpdhrtghpthhtohepug hnshhophesihgvthhfrdhorhhgpdhrtghpthhtohepphhsphgrtggvkhesihhstgdrohhr ghdprhgtphhtthhopehptghhqdgunhhsohhpqdeisehuqddurdhphhhitghohhdrtghomh
X-ME-Proxy: <xmx:gtYIaEk-KoDT4rDvT7gRYuVP7inSwp9s-ygn88S_rlMMdOvgCTmvVw> <xmx:g9YIaDyHIYT7La51My7kCUfnD6eMSgUL9qsKCReikNY8kGJIy69HZg> <xmx:g9YIaORAWlFLxDE3fO8zU1_O1tmh4CDJzrHOf2iHSn1v3S4CdbssLw> <xmx:g9YIaGYV0cTwEBpJZ7kOunu383dO3FfhBs_3ekzU8OmrKsfudzKtzg> <xmx:g9YIaHOc8ybkjhFmXtVgiGET2gzXTKyiC2mgKFq4FBZS6Wi6vMbrRx6k>
Feedback-ID: i1136489e:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id D696F3C0068; Wed, 23 Apr 2025 08:01:06 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: Teb8ce65f3fed0dd8
Date: Wed, 23 Apr 2025 05:00:46 -0700
From: Ted Lemon <mellon@fugue.com>
To: Petr Špaček <pspacek@isc.org>, Andrew McConachie <andrew@depht.com>
Message-Id: <ac48e27d-479f-42f3-b87f-891220ef2fe8@app.fastmail.com>
In-Reply-To: <cc84f69c-c349-4d91-b942-80221b564a9b@isc.org>
References: <m1u5h1G-0000LcC@stereo.hq.phicoh.net> <83666fd3-a51f-46e1-a5ac-0b9a46361480@desec.io> <49E3B1B6-E960-4A46-9C5D-2721FD57132D@depht.com> <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org> <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com> <cc84f69c-c349-4d91-b942-80221b564a9b@isc.org>
Content-Type: multipart/alternative; boundary="f5e41fee1caa4787ab820a1fc74a5249"
Message-ID-Hash: 76EEYXGT76UFKJ7MBEEV4X4RPU4QRRAN
X-Message-ID-Hash: 76EEYXGT76UFKJ7MBEEV4X4RPU4QRRAN
X-MailFrom: mellon@fugue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Peter Thomassen <peter=40desec.io@dmarc.ietf.org>, Philip Homburg <pch-dnsop-6@u-1.phicoh.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ShP79VvhMUprZworyWgD8EYniws>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

I am indeed confused by all the lawyering here. To me it is clear that the “no delegation”  instruction from ICANN means they won’t delegate it and we can do what we think is correct with it for the intended use for which it has been reserved. 

There is a specific reason why we want locally-served domains to have an insecure delegation to a black hole. Not delegating in this way doesn’t make much sense—it creates a situation where you have to disable DNSSEC to get the intended behavior, which seems like a really bad idea. 

Why go to all this trouble and then wind up with an outcome that doesn’t actually do what was intended?

On Wed, Apr 23, 2025, at 4:47 AM, Petr Špaček wrote:
> On 4/23/25 11:25, Andrew McConachie wrote:
> > On 22 Apr 2025, at 15:48, Petr Špaček wrote:
> >> On 4/22/25 13:26, Andrew McConachie wrote:
> >>> This is an overly creative interpretation of the Board’s resolution. 
> >>> It implicitly adds a modifier preceding “delegation” where none 
> >>> exists. The Board did not resolve to “reserve[s] .INTERNAL from 
> >>> [normal|secure] delegation”. They resolved to “reserve .INTERNAL from 
> >>> delegation”. The resolution could not be more clear.
> >>>
> >>> The fact of the matter is that some people want “no delegation” and 
> >>> some people want “insecure delegation”. That ship has sailed, and we 
> >>> ended up with “no delegation”. DNSOP can’t change that.
> >>>
> >>> My suggestion for the people in the “insecure delegation” camp is to 
> >>> petition the SSAC to write a document asking for a different name to 
> >>> be insecurely delegated. I see the benefits of both camps, so I’m not 
> >>> advocating for one or the other. But for .internal this really can’t 
> >>> be changed at this point.
> >>
> >> Just to clarify: Are you suggesting ICANN board cannot ever issue 
> >> another resolution on this matter?
> >>
> > I can’t speak for the Board, I can only read what they publish and 
> > interpret it.
> > 
> >  From the Board paper on the subject:
> > “The BTC [Board Technical Comittee] recommends that the Board reserve 
> > the string .INTERNAL permanently from
> > delegation in the DNS root zone.”[1]
> > 
> > Or the supporting text in the resolution:
> > “
> > What is the proposal being considered?
> > 
> > The Board is considering whether to reserve .INTERNAL from insertion in 
> > the DNS root zone permanently. Applicants of the next and subsequent 
> > gTLD application rounds will not be able to apply for the .INTERNAL top- 
> > level domain.
> > “[2]
> > 
> > There is also the Board’s interpretation of what SAC113 recommended:
> > “Along with recommending that the Board identify and reserve in 
> > perpetuity a single string at the
> > top-level of the DNS, SAC113 Section 4.1 ..“[1]
> > 
> > So we have at least 2 ‘permanently’s and 1 ‘in perpetuity’. To know 
> > definitively whether those words can constrain future Board resolutions 
> > would require a time machine, which we don’t have. So the best I can do 
> > is point at those words.
> > 
> > --Andrew
> > 
> > [1] https://itp.cdn.icann.org/en/files/board-meetings/briefing- 
> > materials/briefing-materials-1-29-07-2024-en.pdf
> > [2] https://www.icann.org/en/board-activities-and-meetings/materials/ 
> > approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en
> 
> :shrug: My interpretation of [2] is that term 'delegation' in this opera 
> is firmly bound to 'application' process. From that I conjecture SUDN is 
> not in scope. But IANAL :-)
> 
> -- 
> Petr Špaček
> 
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org
>