Re: [DNSOP] draft-liman-tld-names-04

Andreas Gustafsson <gson@araneus.fi> Mon, 29 November 2010 15:59 UTC

Return-Path: <gson@araneus.fi>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C33528C143 for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 07:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.855
X-Spam-Level:
X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=1.744, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwtdqMJwVrQ6 for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 07:59:58 -0800 (PST)
Received: from gusev.araneus.fi (gusev.araneus.fi [83.145.227.89]) by core3.amsl.com (Postfix) with ESMTP id E800E28C169 for <dnsop@ietf.org>; Mon, 29 Nov 2010 07:59:57 -0800 (PST)
Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 6F96992578; Mon, 29 Nov 2010 18:01:05 +0200 (EET)
Received: by guava.gson.org (Postfix, from userid 101) id AB4A675E98; Mon, 29 Nov 2010 18:01:04 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19699.52799.844154.278225@guava.gson.org>
Date: Mon, 29 Nov 2010 18:01:03 +0200
To: Andrew Sullivan <ajs@shinkuro.com>
In-Reply-To: <20101129152702.GI33199@shinkuro.com>
References: <20101125175247.GH21047@shinkuro.com> <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk> <D8E75C03-0322-4594-BB27-D825AB429EA6@hopcount.ca> <C4FB358F-53D1-4A2B-A3A4-1C07222C0B51@dotat.at> <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca> <20101127185010.GB56062@farside.isc.org> <79DC22E8-18BC-44B1-8874-D094844D9E94@dotat.at> <8CEF048B9EC83748B1517DC64EA130FB43E00387CC@off-win2003-01.ausregistrygroup.local> <20101129143919.GE33199@shinkuro.com> <4CF3C0BA.1050307@abenaki.wabanaki.net> <20101129152702.GI33199@shinkuro.com>
X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf)
From: Andreas Gustafsson <gson@araneus.fi>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-liman-tld-names-04
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 29 Nov 2010 15:59:59 -0000

Andrew Sullivan wrote:
> [. . . ]
> 
>   The labels must follow the rules for ARPANET host names.  They must
>   start with a letter, end with a letter or digit, and have as
>   interior characters only letters, digits, and hyphen.  There are
>   also some restrictions on the length.  Labels must be 63 characters
>   or less.
> 
> Now, we have considerable discussion in the first part of that passage
> that explains why the restrictions that are being introduced are so
> introduced, despite the fact that the protocol itself happens not to
> have such restrictions.  So, are those rules "merely" allocation
> policy, or not?  I can't tell, and I say you can't either.  We don't
> even have the proto-2119 lanuage here that we see in RFC 1123, so we
> can't tell whether the "The labels must follow" in the last paragraph
> is a protocol restriction or a consequence of following the "prudent
> user" advice that immediately preceeds it.  It might be policy, and it
> might not be.
> 
> One way to figure out whether this is "mere" policy or whether it is
> in fact protocol is to ask people.  It turns out, however, that
> different people have responded differently to this.  Some people have
> responded by putting eight-bit labels in the public DNS.

RFC 2181 section 11 is quite clear that the DNS protocol places no
restrictions on the contents of a label other than its length, and
that eight-bit labels are specifically allowed:

   The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  The length of
   any one label is limited to between 1 and 63 octets.  A full domain
   name is limited to 255 octets (including the separators).  The zero
   length full name is defined as representing the root of the DNS tree,
   and is typically written and displayed as ".".  Those restrictions
   aside, any binary string whatever can be used as the label of any
   resource record. 

-- 
Andreas Gustafsson, gson@araneus.fi