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

Michael De Roover <ietf@nixmagic.com> Fri, 09 May 2025 21:52 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 805F52700DF2 for <dnsop@mail2.ietf.org>; Fri, 9 May 2025 14:52:34 -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 8_4qN9SuF4bh for <dnsop@mail2.ietf.org>; Fri, 9 May 2025 14:52:32 -0700 (PDT)
Received: from nixmagic.com (e1.nixmagic.com [116.203.235.171]) by mail2.ietf.org (Postfix) with ESMTP id 7E2E12700DED for <dnsop@ietf.org>; Fri, 9 May 2025 14:52:32 -0700 (PDT)
Received: from thonkpad.lan (wlan0.thonkpad.lan [192.168.10.23]) by nixmagic.com (Postfix) with ESMTPSA id 63364CAA43; Fri, 9 May 2025 21:52:31 +0000 (UTC)
From: Michael De Roover <ietf@nixmagic.com>
To: dnsop@ietf.org, Andrew Sullivan <ajs@crankycanuck.ca>
Date: Fri, 09 May 2025 23:52:31 +0200
Message-ID: <3547067.QJadu78ljV@thonkpad.lan>
Organization: thonkpad.lan
In-Reply-To: <o25foqoshjnudrk4z6ucpxypvn36kpqn4nboa6r4zzespjvm2o@dlsnqvs4cgr7>
References: <1C9E8ABA-4399-491B-A9F4-D9ACCB1BA72C@virtualized.org> <2796076.J18nJlZdWt@workstation.vm.ideapad.lan> <o25foqoshjnudrk4z6ucpxypvn36kpqn4nboa6r4zzespjvm2o@dlsnqvs4cgr7>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Message-ID-Hash: VJJL24MCL5XT2AAZJF2IFOX4NO5M4JQU
X-Message-ID-Hash: VJJL24MCL5XT2AAZJF2IFOX4NO5M4JQU
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/lc_OSel2EBLLZTotPAFheFSvyXw>
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:52:39 CEST Andrew Sullivan wrote:
> I didn't have time to write a short note, so I wrote a long one instead.
More detail is better than less, it was a good read!

> One of the things about mostly disappearing from the IETF for a while and
> returning is to be reminded how stuff stays the same, and I am nonplussed
> to see that this is one of those topics.  I contend once again that there
> is a reason people keep getting wound around this axle, and it is the
> failure to take into account different classes of things.

Truthfully, I find it a bit amusing how sensitive this WG is to the .onion 
subject. The Tor project has unilaterally decided that .onion was going to be 
their suffix for a non-DNS use, and that eventually (inevitably) made its way 
into the DNS. Leaving the DNS community with no option but to reluctantly 
accept it.

I've spoken to the Tor developers at FOSDEM (which I regularly attend) before, 
they do seem to have their hearts in the right place. I have not talked to 
them about DNS-related issues like what's at the root of this discontent, so 
what follows are my own thoughts. If it were up to me though, and I were to be 
in charge of the Tor project.. would I want to interact with the IETF about 
it? I'm here now so clearly I do, but can I blame those who (possibly) did 
not? Processes and debates are good, until they become an impediment to 
progress.

> Good examples of this are .local and .onion.  Each of these is supposed to
> tell a resolver, "Look out!  We're switching protocols!"  A conforming
> resolver will do the right thing.  Of course, this being the Internet,
> there is no way to know whether a given system will in fact be conforming,
> so the documents have to specify what to do in case such protocol switches
> don't work (and they do so).

This is where I think the IETF and the RFCs it produces shines. Regardless of 
what "consensus by the Internet community" means and who populates it (anyone 
can, if they have thick skin and know what they're talking about), it does 
serve as a meaningful anchor for people and organizations alike to use. With 
.internal, this would be related to what domain suffix is to be used, in 
internal network configs that are advanced enough to use full-fledged DNS with 
zone files. What needs to be done in establishing that name, is lowering the 
barrier enough to give people/organizations a reason to use it over the 
alternatives they can unilaterally decide on as well.

> This would seem to entail that, if you want to use a domain name outside the
> context of the global public DNS but still want to use the DNS with it, you
> should just register a domain name and use that, and not publish the
> records in a public manner.

Pretty much yes, register a second-level domain from anywhere and use that has 
been the traditional advice. My prior rebuttal to that has been that those 
domains can expire, or be taken away. For internal use, stability matters 
because it's an anchor for all activities within a given network / set of 
networks. That is where .internal would really prove useful, it is a record 
pretty much set in stone if ICANN / IANA are the ones to be responsible for 
it. And, to be clear, this email shows that I have at least two public 
domains, that is not the issue here. What matters here is stability of those 
registrations.

> And so we are at the degenerate case of giving a place within the DNS, that
> uses the DNS in a normal way, but that is officially reserved as being for
> private use.

> Perhaps this is just a long way of saying that RFC 1918-for-DNS is actually
> a terrible, no good, very bad idea, but people are going to do it anyway.

We are, and certainly I am. This is why I think .internal is so important; 
there is precedent to this being necessary, just like official delegation of 
private-use IP addresses has been prior. It gives a namespace for network 
operators with their own DNS servers to use within their internal networks. 
When I designed these networks of mine, this delegation was not made, so I 
picked .lan because, well, it was a short name and it was a LAN I was working 
with. That then expanded into what it is now. But if I had caught wind of 
.internal 10 years ago when I laid the groundwork, I'd dare to put my hand on 
the Bible that I would've at least considered it. Because it would've saved me 
so much headache moving the whole thing over today.

-- 
Met vriendelijke groet,
Michael De Roover

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