Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better

Mark Andrews <marka@isc.org> Tue, 18 January 2011 23:49 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6DA28C15C for <dnsext@core3.amsl.com>; Tue, 18 Jan 2011 15:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599]
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 GhXpRTLnOe5d for <dnsext@core3.amsl.com>; Tue, 18 Jan 2011 15:49:41 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 9140F28C128 for <dnsext@ietf.org>; Tue, 18 Jan 2011 15:49:41 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7DB1F5F9863; Tue, 18 Jan 2011 23:52:04 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 5F0AAE6030; Tue, 18 Jan 2011 23:52:02 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 864BE8E3A2B; Wed, 19 Jan 2011 10:51:59 +1100 (EST)
To: Paul Vixie <vixie@isc.org>
From: Mark Andrews <marka@isc.org>
References: <AANLkTikv9muqBKbm0WpvtkyFb5DT9==P_6ySAow7u0b7@mail.gmail.com> <82ei8afq4p.fsf@mid.bfk.de> <85987.1295361055@nsa.vix.com>
In-reply-to: Your message of "Tue, 18 Jan 2011 14:30:55 -0000." <85987.1295361055@nsa.vix.com>
Date: Wed, 19 Jan 2011 10:51:59 +1100
Message-Id: <20110118235159.864BE8E3A2B@drugs.dv.isc.org>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jan 2011 23:49:42 -0000

In message <85987.1295361055@nsa.vix.com>, Paul Vixie writes:
> > From: Florian Weimer <fweimer@bfk.de>
> > Date: Tue, 18 Jan 2011 10:44:06 +0000
> > 
> > I wasn't really around when the failure of this experiment was
> > recognized.  Is there a write-up somewhere explaining why this doesn't
> > work as expected?  (Without major protocol surgery, increasing the
> > label length would share a similar fate.)
> 
> no writeup. briefly, it only works if the full end-to-end path knows
> about each new label type. so adding each label type would require 
> incrementing the EDNS version number. this was found to be impractical.

The problem is worse than that.  All the parent server need to be
able to parse the QNAME to be able to issue a referral.  You can't
find the OPT record to do EDNS version processing.

I don't know why we are talking about this at all.   I've see no
evidence that 63 characters is not enough space for any label people
are likely to be typing in even with IDN.

this-is-a-very-long-hostname-that-I-would-never-use-in-practice.isc.org

An entire sentence is encoded in that label.

If you need to encode longer sentences into labels for a database
stored in the DNS then I suggest that you use a cryptographic hash,
base32 encode the result and do collision detection.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org