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

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 04 February 2014 01:21 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 5E4391A02D7 for <dnsop@ietfa.amsl.com>; Mon, 3 Feb 2014 17:21:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 DsNzZm2iHYJD for <dnsop@ietfa.amsl.com>; Mon, 3 Feb 2014 17:21:51 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 128321A02DC for <dnsop@ietf.org>; Mon, 3 Feb 2014 17:21:51 -0800 (PST)
Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B2FD68A031 for <dnsop@ietf.org>; Tue, 4 Feb 2014 01:21:50 +0000 (UTC)
Date: Mon, 3 Feb 2014 20:21:48 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20140204012148.GE16180@mx1.yitter.info>
References: <20140130004530.C660CE086E0@rock.dv.isc.org> <20140203151958.GA1673@nic.fr> <6BE00F1A-1F8D-4B30-A5C7-10E7466109C2@vpnc.org> <ACF06352-98E5-4368-A8C9-5AB50783C2D3@hopcount.ca> <20140203212333.1259EE44493@rock.dv.isc.org> <CF15D98C.197C0B%jonne.soininen@renesasmobile.com> <CAKr6gn1dpWz3LP9bpA2JebRDSN7GeOW65+Q1tW_dv=9KzgZaCQ@mail.gmail.com> <A6D7CE2E-BF9C-4077-A571-0C455E5DAE1F@nominum.com> <CAKr6gn08xayJCK_GtGNeYbet6tD=GwPJoSYL3tbRXomfxckHWA@mail.gmail.com> <ED2AE016-766D-41DE-A428-DEC49A350E8C@nominum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ED2AE016-766D-41DE-A428-DEC49A350E8C@nominum.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Tue, 04 Feb 2014 01:21:52 -0000

On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote:
> 
> purely on the basis that some of us don't like what they did.  We
> need a better reason than that, and thus far none has been stated.

In the particular case of .onion, I'm not sure I agree none has been
stated.  But let me try again:

    If you want to use a name in DNS protocol slots, then you need a DNS
    name.  You didn't get a DNS name, and instead you used a label
    that wasn't under your control.  That's been against the rules in the
    DNS since forever.  Now you want to short-circuit the allocation
    mechanism.  But we have an allocation mechanism for this.  In the
    normal case, you apply to ICANN.  In an unusual case where the
    protocol depends on this, then you can use this special-use
    registry.  So you need to show that your protocol needs to depend
    on this special-use label, and then we can register it under the
    special use mechanism.  Otherwise go to ICANN.

What we ought to be arguing about, in effect, is precisely why this
needs a special-names registration.  Now, _maybe_ there is an argument
that this is a DNS-looking series of labels but it never goes into the
DNS namespace (that's what I've heard once).  In that case, there
might be an argument.  ("Put this in the default local zones, always
NXDOMAIN, because we want to protect the DNS.")  Maybe the argument is
instead that sometimes these names are handed to DNS resolvers and are
supposed to resolve.  In _that_ case, it seems to me that the "this is
a DNS name" consideration is also pretty high.  I'm unsure we've had
clear and consistent arguments about this for each of the cases.

In the chapin draft, the argument is different, and it appears to be
purely a local-resolution-only one -- that is, always "protection of
the DNS" because of de facto resolution and security decisions
deployed on the Net.  I haven't read it closely enough to decide
whether this is true for every label in the list.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com