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

Paul Hoffman <paul.hoffman@icann.org> Wed, 30 April 2025 16:49 UTC

Return-Path: <paul.hoffman@icann.org>
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 E30862331A39 for <dnsop@mail2.ietf.org>; Wed, 30 Apr 2025 09:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 veiLVfUv1O2o for <dnsop@mail2.ietf.org>; Wed, 30 Apr 2025 09:49:28 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) by mail2.ietf.org (Postfix) with ESMTP id 7DCB82331A33 for <dnsop@ietf.org>; Wed, 30 Apr 2025 09:49:28 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa4.dc.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 53UGnNFb015616 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Wed, 30 Apr 2025 09:49:23 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 30 Apr 2025 09:49:26 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1544.011; Wed, 30 Apr 2025 09:49:26 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Re: Call for Adoption: draft-davies-internal-tld
Thread-Index: AQHbtGsvzqWix5LQmEyJWK91ziOf+rOzfoAAgAltrAA=
Date: Wed, 30 Apr 2025 16:49:26 +0000
Message-ID: <8E36C1B8-C67B-4704-9E3B-7143863E2262@icann.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> <ac48e27d-479f-42f3-b87f-891220ef2fe8@app.fastmail.com> <BE721880-6254-48F4-9F91-567A99E0511B@icann.org> <m1u7asT-0000MtC@stereo.hq.phicoh.net> <01E23110-9A50-4187-8A54-34D514504F9B@strandkip.nl> <3A48CBC3-B55B-4FCF-B713-A7CA4C7BB7CC@strandkip.nl>
In-Reply-To: <3A48CBC3-B55B-4FCF-B713-A7CA4C7BB7CC@strandkip.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <38EEBE612097DC4C8F484E0EB21B7A9C@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-04-30_05,2025-04-24_02,2025-02-21_01
Message-ID-Hash: NWLHSQIZV3IV4QTMSOUZ6NNG3XQKE4MA
X-Message-ID-Hash: NWLHSQIZV3IV4QTMSOUZ6NNG3XQKE4MA
X-MailFrom: paul.hoffman@icann.org
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] 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/lcHME0fmrQPzr_Q01k8VaWdb3os>
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>

Coming back to the topic of insecure delegation, because some people here have said that is the reason they want the draft to be adopted in this WG.

Can anyone say who benefits from insecure delegation of .internal, and how? This might be a lack of creativity on my part, but I cannot think of any party in the DNS that would be helped by insecure delegation of .internal, and I can think of one (validating stub resolvers) that would in fact be hurt by it.

--Paul Hoffman

On Apr 24, 2025, at 09:50, Joe Abley <jabley@strandkip.nl> wrote:
> 
> Replying to myself, hooray,
> 
> On 23 Apr 2025, at 18:16, Joe Abley <jabley@strandkip.nl> wrote:
> 
>> I was a member of SSAC at the time SSAC made its recommendation to the ICANN board, but I was not one of the people who contributed significantly to the document as far as I remember, so be aware (as usual!) that everything I say may be nonsense.
>> 
>> I think the SSAC document does not discuss or propose an insecure delegation from the root zone in order to avoid the advice to the board being complicated by conflicts with existing root zone management (both in the general sense and in the sense of RZM, the software used to manage delegations from the root zone).
> 
> Some kind people reminded me of events of the past, so in case it's interesting...
> 
> It turns out that the SSAC work party responsible for that document did indeed decide not to recommend an insecure delegation for the reason above, and so it's definitively not the case that people didn't think of it or think that it was a good idea to recommend it.
> 
> I was one of the people that thought it was better not to include that specific recommendation, for the reason above, and in fact I said so loudly and stubbonly at the time. I had just forgotten.
> 
> I still think this was a reasonable recommendation to drop, and I still think that the resulting resolution shouldn't stand in the way of any particular technical implementation of the document's overall recommendation. People shouldn't read too much into the word "delegation" just because they're used to seeing it through a DNS lens. It definitely has other meanings in the context of the policies surrounding root zone management.