Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

Stephane Bortzmeyer <bortzmeyer@nic.fr> Thu, 23 January 2014 08:47 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E771A02F1 for <dnsop@ietfa.amsl.com>; Thu, 23 Jan 2014 00:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGoaso2LdGet for <dnsop@ietfa.amsl.com>; Thu, 23 Jan 2014 00:47:43 -0800 (PST)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by ietfa.amsl.com (Postfix) with ESMTP id A165C1A02ED for <dnsop@ietf.org>; Thu, 23 Jan 2014 00:47:43 -0800 (PST)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 477A739B56; Thu, 23 Jan 2014 08:47:41 +0000 (UTC)
Received: by tyrion (Postfix, from userid 1000) id A7C11F007B2; Thu, 23 Jan 2014 09:47:06 +0100 (CET)
Date: Thu, 23 Jan 2014 09:47:06 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Suzanne Woolf <suzworldwide@gmail.com>, lyman@interisle.net, markmcfadden@icc-uk.com
Message-ID: <20140123084706.GA25772@laperouse.bortzmeyer.org>
References: <20140108151128.10496.10303.idtracker@ietfa.amsl.com> <EF33329A-2895-4714-8DC1-2E103EF484D9@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <EF33329A-2895-4714-8DC1-2E103EF484D9@gmail.com>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 13.10 (saucy)
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 08:47:45 -0000

On Wed, Jan 08, 2014 at 01:18:09PM -0500,
 Suzanne Woolf <suzworldwide@gmail.com> wrote 
 a message of 215 lines which said:

> This new internet-draft is another request for additions to the RFC
> 6761 special names registry, this time motivated by an interest in
> reserving the names most commonly found in recent analysis of TLDs
> in private name spaces. The special names registration would serve
> to minimize the chances of collision between private and public DNS
> namespaces by keeping these names unassigned in the public
> namespace.

I have two technical remarks about this draft (at the end of this
message) and important policy remarks.

1) During the discussion about .onion, .bit and so on, many people on
dnsop were apparently opposed to RFC 6761 (unless the requester was
Apple) and suggested we (the IETF) should not step on ICANN shoes and
do not make an actual use of RFC 6761. What do they think about this
draft?

2) I find no mention of the risk of "reservation through abuse". I
send many requests to many resolvers for "$random.example", then the
root sees a lot of traffic for this TLD, then Interisle flags it as
"hish risk of collisions" then the TLD is added in the special
registry and no longer available. There is nothing about this risk of
"denial of service" in the draft (no Security Considerations) and
nothing about how to prevent it.

3) The suggested behaviour is very demanding: for all the TLD
mentioned, the draft requests that libraries and resolvers treat them
as special. It will mean the modification of a lot of software. If the
goal is only to prevent name collision, delegating these TLD at the
root to AS112 could be sufficient. There is no discussion in the draft
about alternative approaches.

Now the technical remarks:

4) The draft says that libraries and resolvers SHOULD "restrict these
names to local resolution". "Local resolution" is not defined
anywhere. What does it mean? If it means the resolver SHOULD be inside
the organization, how could a library know that 192.0.2.3 is local or
not? Same thing for forwarders of resolvers.

5) The draft says "authoritative domain name server software SHOULD restrict
these names to local resolution and SHOULD NOT allow queries for
strings that use these Special-Use Domain Names to be forwarded to
the public DNS for resolution" I do not understand it at
all. Authoritative name servers are... authoritative, they do not
forward to other servers.