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

Paul Wouters <> Sun, 25 August 2019 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6249B120803 for <>; Sun, 25 Aug 2019 09:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SWjcVZOigv8J for <>; Sun, 25 Aug 2019 09:21:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F12C1200A1 for <>; Sun, 25 Aug 2019 09:21:48 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 46GgPj4chDzF0L; Sun, 25 Aug 2019 18:21:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1566750105; bh=9VwySDo047PUvxf3m7/qsxwzDSrEBD906iBitWD0wp4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OxtbSLyzOEFSR1OW7GI2IKb1sN4zcElxIHr2RK6cHQWWnozKjxTaXlrgwYe1oEc1L 86ZN3bLSty8bgTRt83/+QCN7dJs2wmEpuHgP/e9OaZWgaUcoZdAZcCecj6itTk7nV8 XyCVxTA8NwzzTfbMvSYzzY791+DLhzuyf+VdI6oc=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id AOzbLLsFUokZ; Sun, 25 Aug 2019 18:21:43 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sun, 25 Aug 2019 18:21:42 +0200 (CEST)
Received: by (Postfix, from userid 1000) id C44BA59CFF1; Sun, 25 Aug 2019 12:21:41 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 C44BA59CFF1
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7F2D400083A; Sun, 25 Aug 2019 12:21:41 -0400 (EDT)
Date: Sun, 25 Aug 2019 12:21:41 -0400 (EDT)
From: Paul Wouters <>
To: dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Aug 2019 16:21:50 -0000

On Fri, 23 Aug 2019 at 14:18, <> 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
>               Authors         : Warren Kumari
>                                 Andrew Sullivan
>               Filename        : draft-ietf-dnsop-alt-tld-12.txt
>               Pages           : 11
>               Date            : 2019-08-23

I am not a big fan, and I don't think many alternative projects will
pick .alt even if just for cosmetic reasons, but I don't have any
reason to object either. It's cheap and if it remains unused, that
is okay.

And one advantage is that if people want to claim a TLD, we can point
them to .alt, so it should decrease the pressure on using RFC 6761 which
will prevent more bureaucratic time used up in dnsop meetings.

Has Issues:

I think the document is contradicting and not clear at all on what to do
with queries. It mixes up "should not be resolved" with "should not be
handled specially" based on some assumed difference of stub resolver and
resolver and Caching Server. On top of that, a stub resolver and caching
server are likely to use the same underlying library calls, so asking
for different behaviour is unrealistic for implementors.

It would also be good to stick to the DNS Terminology, which I think it
does not do with the list of different players in the resolving chain.

 	Writers of name resolution APIs and libraries which operate in
 	the DNS context should not attempt to look these names up in the


 	Caching DNS servers SHOULD NOT recognize these names as special

These two cannot both be true. The latter is also really false since the
.alt is marked as Special Domain, so caching resolvers _should_ handle it

Likely the best advise to implementors is to use a Query Minimization
based answer of the non-existence of .alt that prevents further leakage
of the specific name within .alt that was used. I would like to see this
very prominently stated instead of the scattered bullet list on what to

 	Authoritative DNS servers SHOULD NOT recognize these names as

Why not? I think they should refuse to load any .alt zones. It is
supposed to be Special Use for non-DNS protocols. Why let it be abused
as "real" DNS zones? Do we want to support "almost DNS like" protocols
that would re-use authoritative DNS server code? That seems very

 	DNS server operators SHOULD be aware that queries for names
 	ending in .alt are not DNS names

I read this first as "DNS servers" not as "humans". I don't think RFC
2119 language should apply to humans (well, I think it should but I
think we are not the Human Police either :)

 	DNS Registries/Registrars MUST NOT grant requests to register
 	".alt" names in the normal way to any person or entity.

This is outside the scope of IETF. If ICANN wants to make a statement
about this, they should do so elsewhere? Since registrars/registries
cannot do this anyway, the advise is silly. And for any alt-root
operators, this line isn't going to change their behaviour anyway. Plus,
due to the above processing rules, DNS libraries will prevent them from
running an alt-root .alt DNS zone anyway.

 	Earlier versions of this document requested

I think this section can be removed, or moved to an appendix.

 	(and their stub
 	resolver library has not been updated to ignore queries for names
 	ending in .alt)

This again goes against the "do not treat special" directive.
Apparently, it is wanted that stub resolvers threat this differently.

 	configured iterative resolver

Stick to DNS Terminology...

 	(or, if the resolver implements [RFC8198], a entry for .alt)
 	this query will likely be sent to the DNS root servers.

This does not parse. Also, I think the "local root" drafts/RFC would be
more appropriate to cite here than Aggressive NSEC. But really, none of
this should be cited here I think. It is not needed for the explanation
at this place.

 	One of the motivations for the creation of the .alt pseudo-TLD is
 	that unmanaged labels in the managed root name space are subject to
 	unexpected takeover.  This could occur if the manager of the root
 	name space decides to delegate the unmanaged label.

This reads as if ICANN is the MITM this document is protecting for,
which I don't think is the intension. I would also place the actual
concern (your squatted domain might get delegated for real by another
legitimate entity) in the introduction or abstract. It is not a security
consideration of the draft itself. So it does not belong in the Security

 	The unmanaged and "registration not required" nature of labels
 	beneath .alt provides the opportunity for an attacker to re-use the
 	chosen label and thereby possibly compromise applications dependent
 	on the special host name.

Similar here. It is not a Security Consideration for creating .alt, but
a security consideration of the non-DNS protocol that is unspecified and
so we should not talk about it here.

At best, perhaps you want to say:

 	Using non-DNS namespaces for applications that are normally only
 	used within the DNS namespace will have a number of security
 	concerns related to the unexpected interaction of the non-DNS
 	space with the DNS space. Any design of a non-DNS namespace MUST
 	take these risks into account and (re)consider the use of a real
 	DNS namespace domain name instead. If that is not possible,
 	leaking of any non-DNS namespace into the .alt DNS namespace
 	MUST NOT cause fatal security or privacy issues.


 	A short label was deemed desirable for a number of reasons, including:


 	some queries will undoubtedly leak into the DNS.

I don't see why the label length would matter here :P

 	as there are not protocol police

This sentence does not parse. Also, while dnsop might understand
"protocol police", I don't think this term should appear in RFCs.

I think the affiliation of Andrew Sullivan needs updating.