Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

Peter Thomassen <> Mon, 27 June 2022 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF26CC15AD33 for <>; Mon, 27 Jun 2022 16:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.785
X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4bUqgH9pb3iO for <>; Mon, 27 Jun 2022 16:14:27 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B92BC15AAD6 for <>; Mon, 27 Jun 2022 16:14:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9DVh3lsmd+vdGVFMcelW585f2L9hooRVl5IaT2HRgs4=; b=jiwPALpl7JnM/UvkMI+0+XJHIH 5HDwS7JRqzNExzJy4h5hfsoEkigN354SongFbavbUlqQoYrMc/iamG7tNBM83vyxAWnC2iJFPJmyn qsvjxAlyUEMSaWdHSMwQlhBl6iZP1SW+iVl5r6jIfsPt0ZJvplF8sDNXh4FEOvjru/GJAXnk1A53L UZzhM6TpnCJ25qOA6W/JuvdHSQ7Zk1WvFZaIx6iQKFV4jm3RD6VuuJV8TjvSJICkPSZUON8Zb2QxM oNvjCivpd+pb+1rPcdzsfh/Vj6sf16X3sbGnoE/kDZcmTItD89oxmy3+bls+DXtmM9DHUDWxDrE9n Hdib/L0A==;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1o5xvz-0007U2-Fu for; Tue, 28 Jun 2022 01:14:23 +0200
Message-ID: <>
Date: Tue, 28 Jun 2022 01:14:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
References: <20220627200529.DDB294491C6B@ary.qy>
From: Peter Thomassen <>
In-Reply-To: <20220627200529.DDB294491C6B@ary.qy>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2022 23:14:32 -0000

On 6/27/22 22:05, John Levine wrote:
> But there is a
> great deal of software that expects the names it uses to look like
> hostnames, and won't work with anything else.

The software for new applications which would use a _foo pseudo-TLD namespace is not yet written. It is for future applications, for which we can hope to push TLD-like use of things like "onion" into namespaces like "_onion".

Of course, for Tor, it is not feasible because that software is written, and (more importantly) those .onion names are already out there.

I see no reason why, if Tor was started today, the software written for it should not be able to support _onion, if that was the BCP for doing it. Tor software would be written for that purpose at the time. Or am I missing something here?

> The argument for *.alt
> is that if ICANN sells another round of vanity TLDs, as seems
> depressingly likely, here's a hostname we promise won't have new name
> collisions.

IMO the promise of "this name will never be delegated, thus have no DNS collisions" delivers a thing quite different from an as-close-as-possible alternative to a TLD namespace. In other words, it's not as tailored a solution for people who are currently "squatting" TLDs.

Really, if they're not using the DNS, what's going on is not squatting. It's just a semantic collision of dotted strings, that's it.

This is why I wrote that DNS is not necessarily the primary naming system, depending on perspective. When thinking about such other naming schemes, we should give up the DNS-centric view of "squattable namespace property". Pushing alternative naming schemes down one level, reserving the top level for DNS stuff, seems like a rather cocky attitude.

Still, a no-collision name at the top level may be useful, namely in situations where a collision-free letter-only top label is needed. That may be a worthwhile purpose, but it does not cater to the same needs.

I'm not implying how common the needs for _*-style names would be. It's just that the claimed need for "alt" to be used for alternative naming schemes mounted into the second level is not as close to a first-class citizen naming scheme as it could be. (The "alt" draft is exclusively about such non-DNS contexts; the first sentence of the abstract already says so.) I think it is better addressed with a closer-to-TLD approach.

If alternative naming scheme communities don't accept such a TLD-reminiscent proposal, then perhaps there is no solution at all.

> But I don't recall ever seeing anyone squatting on a name that isn't
> a hostname.  This should give us a hint.
It may well be that it just tells us that this hasn't been thought of before. Think of QUIC -- it wouldn't have been fair 10 years ago to say that nobody has done it, so it's not a good idea.