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

Peter Thomassen <> Mon, 27 June 2022 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28DE2C14792F for <>; Mon, 27 Jun 2022 11:35:33 -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 ePSn9qd_RGyV for <>; Mon, 27 Jun 2022 11:35:29 -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 250B3C14F741 for <>; Mon, 27 Jun 2022 11:35:28 -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=4xK2c29C0z0UY3Bs+4orL0pLHL9zQRmpFfzBAYTs7kg=; b=H9kJ5TCcjc76RLzcdxdxZriJLs x2gaXdQ1C4PmZ5KGQ7h2hxut4bT4h5qv4BxRlZSbzu3ct4RfbSClzDmypWdC9j4TW1ocsVuYDT+2B gC9TBkFqDuzVTh982f9ogpVypHk3PQshrmOJ2qeJDYysM95X5UmJTRd4hRllGJAU4fi7nxKxrFHY3 oph9jqujZkk3Fu9IZykzH8ut5XnYPHhqxFEJBuOM61POpPQVWm7kLxzfhIBP608nrZhkhe6rdaS7c dTz/FmL074c9qnnyeyKIvFzidN+ra4wK7UX2UeTxOt3agwPudbjoMY6/3UZYVU8r7XirRfqtZ+Kcm 9nhTMvtw==;
Received: from ([2003:d4:6f3b:c9df:e5eb:45:e446:552f]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1o5ta1-0000cK-I1 for; Mon, 27 Jun 2022 20:35:25 +0200
Message-ID: <>
Date: Mon, 27 Jun 2022 20:35:24 +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: <>
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] 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 18:35:33 -0000

I am proposing to reserve all top-level underscore labels (_*) for special use. Why?

My understanding of the problem is:

(1) There are several naming systems. Some of them can be enabled/disabled via nsswitch; others are completely "disconnected" from OS resolution, but still use dotted strings for naming.

(2) We want to avoid naming collisions with these other systems, so we designed some part of the namespace for non-DNS use.


(3) The DNS is a very common naming system, but not necessarily the primary one. This is especially true from the perspective of someone (or some application) primarily using another naming system.

In the light of (3), I wonder if the "alt" special use TLD really solves (1) and (2). In particular, it should be noted that

- it only grants second-level domains to other namespace usage schemes;
- it calls non-DNS communities out to be using an "alternative" only (although it may be their primary choice);

As a consequence of that,

- names will feel unnecessarily long and clumsy, from the perspective of the other naming scheme's community;
- user communities of namespaces under "alt" may feel that their namespace is a second-class citizen, due to the presence of the suffix, the meaning of the suffix, and the extra length;

... so it is doubtful to me whether non-DNS communities would really follow the "alt" scheme, or just keep using top-level names. I think this is likely to happen.

On the other hand, it seems that
- the root likely doesn't need underscore names (because the root domain does not run an application which would need something like _443._tcp.);
- _foo instead of foo.alt feels more "genuine" (it actually is at the top level), and is much shorter;
- it eliminates the need to choose a specific "word" to use as the special-use TLD, so it is meaning-agnostic and language-agnostic;
- prefix characters are common in other cases already (@username, #hashtag), so _service may become natural.

Curious to hear what the WG thinks.


On 6/14/22 09:51, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>          Title           : The ALT Special Use Top Level Domain
>          Author          : Warren Kumari
> 	Filename        : draft-ietf-dnsop-alt-tld-15.txt
> 	Pages           : 11
> 	Date            : 2022-06-14
> Abstract:
>     This document reserves a string (ALT) to be used as a TLD label in
>     non-DNS contexts.  It also provides advice and guidance to developers
>     developing alternative namespaces.
>     [Ed note: Text inside square brackets ([]) is additional background
>     information, answers to frequently asked questions, general musings,
>     etc.  They will be removed before publication.  This document is
>     being collaborated on in Github at:
>     wkumari-dnsop-alt-tld.  The most recent version of the document, open
>     issues, etc should all be available here.  The authors (gratefully)
>     accept pull requests. ]
> The IETF datatracker status page for this draft is:
> There is also an htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by rsync at
> _______________________________________________
> DNSOP mailing list

Like our community service? đź’›
Please consider donating at

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525