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

Jim Reid <jim@rfc1035.com> Thu, 17 April 2025 21:51 UTC

Return-Path: <jim@rfc1035.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 B90C61DD5B01 for <dnsop@mail2.ietf.org>; Thu, 17 Apr 2025 14:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 nU9Ga8my6Kz8 for <dnsop@mail2.ietf.org>; Thu, 17 Apr 2025 14:51:34 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (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 B5B1F1DD5AFC for <dnsop@ietf.org>; Thu, 17 Apr 2025 14:51:34 -0700 (PDT)
Received: from smtpclient.apple (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id DDB7A242109E; Thu, 17 Apr 2025 21:51:33 +0000 (UTC)
From: Jim Reid <jim@rfc1035.com>
Message-Id: <1C0FADAF-E3D0-4F0F-BEE8-FC9B4A543C94@rfc1035.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B60AF44-F8D2-424D-AEC1-5666BE3C78F4"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Date: Thu, 17 Apr 2025 22:51:33 +0100
In-Reply-To: <9067E899-0554-45FD-8A2F-3E91E8A85177@virtualized.org>
To: David Conrad <drc@virtualized.org>
References: <016201dbaee8$d1106580$73313080$@gmail.com> <B3F33508-46B5-4B19-A265-C4EAFE9D4000@strandkip.nl> <1C9E8ABA-4399-491B-A9F4-D9ACCB1BA72C@virtualized.org> <A7B914F4-78DF-4210-B8B3-49FE852646AD@rfc1035.com> <9067E899-0554-45FD-8A2F-3E91E8A85177@virtualized.org>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
Message-ID-Hash: 2YG2NUGKAPYA7WSIATX3C7CUNFVXNKBZ
X-Message-ID-Hash: 2YG2NUGKAPYA7WSIATX3C7CUNFVXNKBZ
X-MailFrom: jim@rfc1035.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: Working Group DNSOP <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] 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/Ia3qdN4MLRaMpkS9xpIsE1adxkQ>
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>


> On 17 Apr 2025, at 20:47, David Conrad <drc@virtualized.org> wrote:
> 
> My understanding is that ICANN (or anybody) needs IETF approval to modify https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. If that’s not the case, “never mind”.
> 
> I just think the reliance on lore and oral tradition as opposed to SDO documented specifications to properly develop/operate the DNS should be avoided.

I agree with that 100%. ie Nothing goes into that IANA registry unless it's supported by an RFC which documents why the string truly is special. For some definition of special.

IMO, the .internal TLD isn't special => IETF shouldn't be rubber-stamping its addition to the above IANA registry. That way lies madness. It'll drag the IETF into all sorts of layer-9+ ugliness that has little to do with engineering or protocol matters: "Since you've put .internal on this registry, the IETF must now do that for .hisjimness because $reasons" or "add names for every flavour-of-the-month cryptocurrency/blockchain scheme that comes along because the proponent claims these are special too".

If ICANN (or anyone else) needs a registry of special TLDs that won't go in the root or can't ever be sold, they are free to do that - all by themselves. IMO, they don't need to come knocking on the IETF's door. More so when the choice/use of special TLD strings are driven by considerations which have a marginal (at best) engineering basis or have no significant impact on the stability of the Internet.

Taking .internal as a case in point, we've got along just fine for 20+ years without having this name in the IANA special use registry. No doubt we'll get along just fine for at least than long if it still isn't there. So why bother?

In a nutshell, here's my question. What's the technical/engineering justification for the IETF to add .internal to the IANA special use registry? How does that make things better (or stop them getting worse)? OK, that's 2 questions. Sue me. :-)