Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

Stephane Bortzmeyer <> Tue, 20 September 2016 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16DD912B0FB for <>; Tue, 20 Sep 2016 06:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.222
X-Spam-Status: No, score=-8.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2Z7xiOQPeZN7 for <>; Tue, 20 Sep 2016 06:35:35 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1727B12B364 for <>; Tue, 20 Sep 2016 06:34:31 -0700 (PDT)
Received: from (localhost []) by (Postfix) with SMTP id 1B5A7280497; Tue, 20 Sep 2016 15:34:29 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 1614C280348; Tue, 20 Sep 2016 15:34:29 +0200 (CEST)
Received: from ( [IPv6:2001:67c:1348:7::86:133]) by (Postfix) with ESMTP id 141F5B38024; Tue, 20 Sep 2016 15:33:59 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 826FE3FEBD; Tue, 20 Sep 2016 15:33:57 +0200 (CEST)
Date: Tue, 20 Sep 2016 15:33:57 +0200
From: Stephane Bortzmeyer <>
To: Warren Kumari <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Operating-System: Debian GNU/Linux stretch/sid
X-Kernel: Linux 4.6.0-1-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
User-Agent: NeoMutt/20160910 (1.7.0)
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2016 13:35:40 -0000

On Fri, Sep 16, 2016 at 05:53:53PM -0400,
 Warren Kumari <> wrote 
 a message of 31 lines which said:

> However, if there is not sufficient review and feedback for the
> chairs to be able to select between them (or some other clear
> outcome), we will be stuck... and then we will continue to talk
> about this topic ad nauseam[0].

Or we could decide that the problem is not solvable in the current
context and tell that to the IESG. Some things are simply not
possible. And I'm still not convinced there is a problem to solve
(unless the real issue is "how to prevent the registration of .gnu and

The rest of this email is about
draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
and no.


Despite many remarks on this list and in IETF meetings, the draft
continues to use disparaging terms like (section 1) "squatting".

Several remarks in the draft are dishonest because they could be
applied as well to many IETF technologies. It really seems the authors
felt the draft was too short and decided to pile in anything they
could find against 6761. For instance, section 3 says:

> [RFC6761] does not mention if the protocol using the reserved name
> should be published as an RFC document.

So what? It was never a problem at IETF to rely on protocols which are
not in a RFC. (See for instance the "Specification Required" policy in
RFC 5226.)

Another instance of the same problem, section 4 says:

> c.  Reserving a string in [RFC6761] does not guarantee queries will
> not leak in the DNS.

Requiring this is outrageous: there is no way to prevent
implementations to do stupid things. RFC 1918 does not "guarantee
packets will not leak [in the public Internet]" and nobody is going to
criticize RFC 1918 for that. (Not to mention the DNS leaks of

Section 5:

> This leads to concerns about liability risks incurred by adding a
> particular string to the [RFC6761] registry.

There is no way to guard against any issue that a US lawyer may
raise. Until now, no owner of the Local or Onion trademarks
complained, or threatened to sue.


Section 1 :

> the GNU Name System (GNS) system is using block chains to build a
> decentralized name system

GNS does not use any blockchain. (Confusion with Namecoin?)

Little details

Abstract :

> RFC 6761 introduced a framework by which a particular domain name
> could be acknowledged as being special.

Actually, suffix, not domain name (RFC 6761, section 4).

Section 1 :

> An algorithmic solution frequently chosen by application developers
> consists simply in using a special tag padded at the end of a name

Why calling it "tag", instead of "label" (or "suffix" if there are
several labels)?