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

David Conrad <drc@virtualized.org> Mon, 05 May 2025 23:17 UTC

Return-Path: <drc@virtualized.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 820932514C0C for <dnsop@mail2.ietf.org>; Mon, 5 May 2025 16:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, MIME_HTML_MOSTLY=0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized.org
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 iuKzECSFDNqS for <dnsop@mail2.ietf.org>; Mon, 5 May 2025 16:17:37 -0700 (PDT)
Received: from mail-24420.protonmail.ch (mail-24420.protonmail.ch [109.224.244.20]) (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 1C8A92514BFF for <dnsop@ietf.org>; Mon, 5 May 2025 16:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized.org; s=protonmail3; t=1746487055; x=1746746255; bh=HVuZpJirpuK4OvHzi/6o9yV1AHqa99KtUishxaIBufw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=kubkTmv7Vnj0N2WCTqFloyzomQsAjudHyw4tgFdKpaqLqRiPS4eB6+TlRIdaUJO6D Jdou+aNL2SVouGkuy6h5bSYZ9MppxSeFkWUWTmwuQJDLqZtfQKv2RYYmkB+Pu2Ekr8 ahOqAD4BBFKTa8hIVFh2X1U2oUGiX708fW0z9EoCaBIdS03S+AtcztmFd+5m0D0DVy fFr8oXzv2d+h8VPre8I/nBctGHWuB8s6Zkhl2Yj6qj+MPJ/gmiBTAD4Umf28Rj0mq9 aKBCNEfeRA3BGKZQrpUmdZvry5877kUGIAyC+l6Gk/RxEuQo1mF9iH6j2I0RBQ/SXA WW88A+DHmzkaw==
Date: Mon, 05 May 2025 23:17:30 +0000
To: Philip Homburg <pch-dnsop-6@u-1.phicoh.com>
From: David Conrad <drc@virtualized.org>
Message-ID: <BE3A5560-740A-47A9-835B-8C8EEF2B50B9@virtualized.org>
In-Reply-To: <m1uBHRs-0000LsC@stereo.hq.phicoh.net>
References: <1C9E8ABA-4399-491B-A9F4-D9ACCB1BA72C@virtualized.org> <866409E5-0D9A-4669-8C6E-C9D1C7BDAA21@dnss.ec> <SA1PR15MB4370BAE2BD669193DDB9AE44B38D2@SA1PR15MB4370.namprd15.prod.outlook.com> <20250502171756.5AC67C762C3C@ary.qy> <SA1PR15MB43704113DF8B19A8A5A66AD6B38D2@SA1PR15MB4370.namprd15.prod.outlook.com> <4B83E121-9562-449C-A00E-2A31894ADED0@icann.org> <m1uBDWf-0000MlC@stereo.hq.phicoh.net> <9EE8E4CC-04A3-46C7-BDDF-EF538A822AA8@virtualized.org> <m1uBHRs-0000LsC@stereo.hq.phicoh.net>
Feedback-ID: 101327196:user:proton
X-Pm-Message-ID: 6840877d058b33fe1a0278e03e657b9dc2d80c51
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------b9c0c00083dc5824d52562e90e479854d72d43564dd3e5cd0bc97dd4469f2567"; charset="utf-8"
Message-ID-Hash: HXIJVMATYY6BBUFXYDN2SZPQPUIE3NO5
X-Message-ID-Hash: HXIJVMATYY6BBUFXYDN2SZPQPUIE3NO5
X-MailFrom: drc@virtualized.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
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] Re: [EXTERNAL] 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/TKWByxxVgwSPsnE3HXSmaRfS2DU>
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>

Hi,

Sorry for the slow response — I missed your response.

> Can you explain how this is relevant to the .internal discussion which is specifically reserved to be used in DNS?

I was apparently unclear, apologies. To clarify, in a previous message that I was responding to you stated:

>> The problem starts when a standards track document promotes a name that
>> does not exist for some purposes.


My references to 2606 (not 2605 as you noted), 7686, and 9476 were to point out that the IETF has, for quite some time, documented (I don’t believe documenting something is equivalent to promoting it, but that may just be me) a number of domain names that "do not exist for some purpose”, all of which are now included in https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.  I fail to see the problem such documentation causes.

I did not say .internal (or any of the others) should or should not be in the (public) DNS, rather I suggested that contrary to your assertion, problems start when users make assumptions about names that do not exist (within the DNS being implied). I personally believe having the documents that explain the intended use of particular names in one place is better than having them in random places known largely via lore, but YMMV.

> I'm perfectly fine with delaying the .internal draft until such a documentation has been created for general end-user devices.

I’m unclear how this helps anything other than providing fodder to those who argue the IETF has become too process bound.

> I'm curious what it would look like. Do we expect end-users to know to add a negative trust anchor for .internal when they arrive at work and then remove it again when they go home?
> 
> Does this involve editing a random config file somewhere on the device?

Both of which sound like good topics to include in a draft on how validating stub resolvers should handle these (and similar) names.

Regards,
-drc