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

Michael De Roover <ietf@nixmagic.com> Fri, 09 May 2025 20:41 UTC

Return-Path: <ietf@nixmagic.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 1728026FB21C for <dnsop@mail2.ietf.org>; Fri, 9 May 2025 13:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IrUAIWKhF_Nj for <dnsop@mail2.ietf.org>; Fri, 9 May 2025 13:41:47 -0700 (PDT)
Received: from nixmagic.com (e1.nixmagic.com [116.203.235.171]) by mail2.ietf.org (Postfix) with ESMTP id 07B2D26FB20F for <dnsop@ietf.org>; Fri, 9 May 2025 13:41:46 -0700 (PDT)
Received: from thonkpad.lan (thonkpad.lan [192.168.10.23]) by nixmagic.com (Postfix) with ESMTPSA id 2A5F2CA7F4; Fri, 9 May 2025 20:41:46 +0000 (UTC)
From: Michael De Roover <ietf@nixmagic.com>
To: dnsop@ietf.org, John Levine <johnl@taugh.com>
Date: Fri, 09 May 2025 22:41:45 +0200
Message-ID: <4980511.GXAFRqVoOG@thonkpad.lan>
Organization: thonkpad.lan
In-Reply-To: <20250509182050.42860C882324@ary.qy>
References: <1C9E8ABA-4399-491B-A9F4-D9ACCB1BA72C@virtualized.org> <2035475.usQuhbGJ8B@thonkpad.lan> <20250509182050.42860C882324@ary.qy>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Message-ID-Hash: QD5URWRRERWFLYUPFBCTLIWCDJQMJKWQ
X-Message-ID-Hash: QD5URWRRERWFLYUPFBCTLIWCDJQMJKWQ
X-MailFrom: ietf@nixmagic.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
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/ZqDw34adhHQVZNqWfWM0VwhC1a8>
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 Friday, 9 May 2025 20:20:49 CEST John Levine wrote:
> It's easy enough to check the PSL repo and see that .internal isn't there. 
> As I think I said in another message, it's probably a heuristic that TLDs
> only contain letters.
> 
> In any event, I don't see why this is important.  On my network I have
> repurposed one of the ISO user defined codes as a local TLD, and browsers
> can reach the local web sites easily enough give or take complaints about
> self-signed SSL certs.  They can do the same thing with .internal names
> with no changes.

I think this addresses a few issues at play here - why .internal is matching 
in some places and in others it's not being the first. In Firefox it does match 
for me, while in MS Edge it does not. Nor does it in Telegram, where I did a 
few manual attempts so far. However, http:// prefix does format to URL 
regardless of what follows - including both .lan and .internal. The point here 
is that neither are currently very "standard", and only one of those is in the 
process of becoming so.

In terms of importance of this - I'll admit that it is something specific to 
having used .lan until now, along with a slew of minutiae of my own network 
and system configurations. Similarly - and because of that same reason, I also 
fail to see why DNSSEC is so important here. Just like TLS, I see no reason to 
use it internally. Internal networks just aren't intended to work like that, 
at least for TLS - in my own belief.

Self-signed.. it can be done, yes, it's even possible to be one's own CA. But 
then it requires pushing that CA to every system in that network, where things 
get messy. Nonetheless, that doesn't mean that it shouldn't be possible to do, 
or even be dismissed as irrelevant.

So that's where I return back to why I did the research, as laid out in the 
previous email. The goal I'm trying to achieve is to provide rationale for 
inclusion into the SUDN registry. This is something that Kim's draft seems to 
hint at, but may have left until IETF WG consensus to actually put in there.

I dunno, my name is not Kim. But if it is to go into the PSL, then probably it 
should go into the IANA doc first. I mean, the more consensus on this .internal 
name, the higher the chance it gets actually adopted, right?

-- 
Met vriendelijke groet,
Michael De Roover

Mail: ietf@nixmagic.com
Web: michael.de.roover.eu.org