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

David Conrad <drc@virtualized.org> Thu, 17 April 2025 15:12 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 ECE741DABAEC for <dnsop@mail2.ietf.org>; Thu, 17 Apr 2025 08:12:16 -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_DNSWL_NONE=-0.0001, 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 Iirwo-sZvibD for <dnsop@mail2.ietf.org>; Thu, 17 Apr 2025 08:12:15 -0700 (PDT)
Received: from mail-4323.protonmail.ch (mail-4323.protonmail.ch [185.70.43.23]) (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 894691DABADB for <dnsop@ietf.org>; Thu, 17 Apr 2025 08:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized.org; s=protonmail3; t=1744902733; x=1745161933; bh=5scAVLFK+ThqnQ5tk93Z9ODYbZXSWbtnjLXkMZYqntE=; 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=MMS2zFozWkOyM85/uKJonB7eMQNmEeRNDtxBK798GjDt7jsxZ9QzPPj2Bp8GXDbet zbbV3sK9hSIonaf9R5o1LDJQt2wr8QXx7wpwhH+ATJBfPXd0o71EKyMSD4eO0EdG1a 2zUhDUfvOBQxCA1DJ9jKBVXVs6FMk37eDG0fGCCzw9cm9JlUxyWlRdwhqtzI8CWVxe c3xl0OzsvzGdueNRf+bRlNkvTHKmtlUAC/cnAPMQxaIzHIhJFaEcywDN17vtnTh7pa Opx5HHFgl/vQHQzV17ezPUoD2+H/CmjqN4BOYGJt26TfwplJr8eefDjUqwETmOU1+7 JjxLjUiIpvn1w==
Date: Thu, 17 Apr 2025 15:12:08 +0000
To: Joe Abley <jabley@strandkip.nl>
From: David Conrad <drc@virtualized.org>
Message-ID: <1C9E8ABA-4399-491B-A9F4-D9ACCB1BA72C@virtualized.org>
In-Reply-To: <B3F33508-46B5-4B19-A265-C4EAFE9D4000@strandkip.nl>
References: <016201dbaee8$d1106580$73313080$@gmail.com> <B3F33508-46B5-4B19-A265-C4EAFE9D4000@strandkip.nl>
Feedback-ID: 101327196:user:proton
X-Pm-Message-ID: 6c9d16b291b96f3bd0e185f57bb3ac48ff107ccb
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------ccf85269fa3ce3ce85e26e11ef624044ce0e8982fba623380091b49d326ad3c2"; charset="utf-8"
Message-ID-Hash: XPUOJMWS2K7MXHETYWGIUQ477Q6PNVXG
X-Message-ID-Hash: XPUOJMWS2K7MXHETYWGIUQ477Q6PNVXG
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: 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/niktcmwWCLVmz22QayR-3Ddchgc>
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>

Joe,

On Apr 17, 2025, at 12:39 AM, Joe Abley <jabley@strandkip.nl> wrote:
> We should not need TLD-specific handling. TLDs in general are and should not be special.

That far off bump on the horizon you see is the ass end of a ship that sailed long ago.

As you’re no doubt aware, there are 7 TLDs currently listed in https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. Each of those can imply (but do not necessarily require) special handling, either in authoritative code, resolver code, or the surrounding client or server infrastructure. Given those seven, it seems silly to me to not add another TLD that may imply special handling by DNS developers or operators.

> The root server system is not the part of the DNS infrastructure we need to worry about.

Heh. If this were only true, the decade-long effort to develop a governance structure for the RSS could be wound down and Jim, Geoff, and others might be slightly less grumpy. However, I’d agree that the impact of .internal to the RSS will not be significant, regardless of whether .internal is documented with the other seven special use TLDs. 

> All the tiny exceptions and niggly extra considerations add up on top of a protocol that is already unwieldy and undocumented.

And I see this draft as part of an effort to reduce the last bit.

> Every little extra nibble from the duck moves us closer to mortal injury. This is Bert's camel; the additional burden is tiny and insignificant until the camel dies.

This is overly simplistic. Given the evolution of the Internet and the use of the DNS, the DNS will need to be modified. Every modification to the DNS implies (or at least should) a cost/benefit analysis. In this particular case, what I see is being proposed is the addition of an entry to the SUDN, presumably with a pointer to a document that explains why .internal is special. From my perspective, the benefit is consistency and helping DNS implementers understand the protocol and the cost is a document somewhere authoritative that says “for internal use only.” Do you see other costs?

Regards,
-drc