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
- [dnsext] Increasing character limit for registrat… Krishna Birth
- Re: [dnsext] Increasing character limit for regis… Matthew Dempsky
- Re: [dnsext] Increasing character limit for regis… Florian Weimer
- Re: [dnsext] Increasing character limit for regis… Paul Vixie
- Re: [dnsext] Increasing character limit for regis… Florian Weimer
- Re: [dnsext] Increasing character limit for regis… Olafur Gudmundsson
- Re: [dnsext] Increasing character limit for regis… Brian Dickson
- Re: [dnsext] Increasing character limit for regis… Mark Andrews
- Re: [dnsext] Increasing character limit for regis… hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare