Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())
Nicolas Williams <Nicolas.Williams@oracle.com> Wed, 16 June 2010 21:55 UTC
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: idna-update@alvestrand.no
Delivered-To: idna-update@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD1C939E20C for <idna-update@alvestrand.no>; Wed, 16 Jun 2010 23:55:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIk4jQzBNNzP for <idna-update@alvestrand.no>; Wed, 16 Jun 2010 23:55:51 +0200 (CEST)
X-Greylist: from auto-whitelisted by SQLgrey-1.6.8
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 46EF639E352 for <idna-update@alvestrand.no>; Wed, 16 Jun 2010 23:55:51 +0200 (CEST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5GLtlno007405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jun 2010 21:55:48 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5GJHvrE009816; Wed, 16 Jun 2010 21:55:46 GMT
Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 351018291276725299; Wed, 16 Jun 2010 14:54:59 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Jun 2010 14:54:58 -0700
Date: Wed, 16 Jun 2010 16:54:50 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Dave Thaler <dthaler@microsoft.com>
Subject: Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())
Message-ID: <20100616215450.GA25472@oracle.com>
References: <20100614172631.GQ9605@oracle.com> <9B57C850BB53634CACEC56EF4853FF652C05FF86@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20100614193133.GS9605@oracle.com> <9B57C850BB53634CACEC56EF4853FF652C060349@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20100614234218.GB24077@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20100614234218.GB24077@oracle.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090201.4C194865.00A7:SCFMA922111,ss=1,fgs=0
Cc: "cheshire@apple.com" <cheshire@apple.com>, "john+ietf@jck.com" <john+ietf@jck.com>, "idna-update@alvestrand.no" <idna-update@alvestrand.no>
X-BeenThere: idna-update@alvestrand.no
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: IDNA update work <idna-update.alvestrand.no>
List-Unsubscribe: <http://www.alvestrand.no/mailman/options/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=unsubscribe>
List-Archive: <http://www.alvestrand.no/pipermail/idna-update>
List-Post: <mailto:idna-update@alvestrand.no>
List-Help: <mailto:idna-update-request@alvestrand.no?subject=help>
List-Subscribe: <http://www.alvestrand.no/mailman/listinfo/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 21:55:57 -0000
On Mon, Jun 14, 2010 at 06:42:19PM -0500, Nicolas Williams wrote: > On Mon, Jun 14, 2010 at 08:20:55PM +0000, Dave Thaler wrote: > > > > As discussed in draft-iab-idn-encoding section 3, it's not that simple. > > > > The ACE form applies in the public DNS but does not apply in many > > > > private DNS clouds. > > > > > > I'm not sure I care about those, but one could always implement lists of domains > > > below which to apply alternative algorithms. > > > > You may not care about them but unfortunately people who provide > > getaddrinfo/getnameinfo libraries for applications in general need to > > care about them. > > For the matter of this discussion, I don't care. If I were implementing > I'd consider providing a local administrative configuration interface by > which to provide lists of private cloud domains that use alternative IDN > schemes. (Actually, I'd probably want a distributed configuration > method for that, preferably using DNS itself, but really, that's a > tangent I don't want to go on because it's a distraction from the > purpose of this thread.) Alright, let's explore that. What would that look like? It could look like a simple NS-like RR -- let's call it the IDNRULES RR. The RRset name would be a domainname for which the same zone also has NS RRs. The RDATA would indicate what IDN rules apply. A contrived example for foó.example., foóbar.example. and óther.example.: xn--fo-6ja.example. IN IDNRULES "IDNA2008" xn--fo-6ja.example. IN IDNRULES "UTF-8;tolower;NFC" xn--fobar-1ta.example. IN IDNRULES "UTF-8" xn--ther-pqa.example. IN IDNRULES "ISO8859-1" These RRsets would mean that: - foó.example. supports IDNs encoded as A-labels per-IDNA2008 - foó.example. _also_ supports IDNs encoded in UTF-8 provided that names are first case-folded to lower case, then normalized to NFC - foóbar.example. supports IDNs encoded in UTF-8 without having to casefold nor normalize; presumably the server can do normalization- and case-insensitive matching (preserving too) -- pretty advanced, and probably no server on the market supports this. - óther.example. supports only IDNs encoded in ISO8859-1 (the server may or may not know how to do case-insensitive matching for non-ASCII ISO8859-1 characters) So, to resolve tést.{foó, foóbar, óther}.example. the _resolver_ would first have to split the input string into labels using whatever fullstops are legal in the current locale, then lookup each of those domains' IDNA rules in the example. TLD zone, do whatever codeset conversions and pre-processing may be required to meet the rules found, then do the next query. And so on. Sounds good, BUT there's issues w.r.t. stub resolvers and caching: stub resolvers suddenly have to get pretty fancy, even if the are using caching servers, because suddenly recursive caching servers are not useful for looking up IDNs! Makes you think that private DNS clouds with IDN rules other than IETF Standards-Track IDNA rules are not desirable. And I'd agree. What's the point of this post? First: to note that private DNS clouds with non-standard IDN rules are a big PITA since right now they can only be supported by nodes that either happen to implement those rules (and not IDNA) or which have local configuration partitioning the DNS namespace by IDN rulesets, and distributed configuration, though it could be possible, would also be a PITA since stub resolvers would have to get pretty smart. Second: to outline a meta-IDN system that could work if IDNA2008 should founder (but let's hope not). Third: I had to write this down :) Nico --
- IDNA and getnameinfo() and getaddrinfo() Nicolas Williams
- Re: IDNA and getnameinfo() and getaddrinfo() Nicolas Williams
- Re: IDNA and getnameinfo() and getaddrinfo() Nicolas Williams
- Re: IDNA and getnameinfo() and getaddrinfo() Shawn Steele
- Re: IDNA and getnameinfo() and getaddrinfo() Nicolas Williams
- RE: IDNA and getnameinfo() and getaddrinfo() Shawn Steele
- Re: IDNA and getnameinfo() and getaddrinfo() Nicolas Williams
- RE: IDNA and getnameinfo() and getaddrinfo() Shawn Steele
- Re: IDNA and getnameinfo() and getaddrinfo() Nicolas Williams
- Distributed configuration of "private" IDNA (Re: … Nicolas Williams
- Re: Distributed configuration of "private" IDNA (… John C Klensin
- Re: Distributed configuration of "private" IDNA (… Paul Hoffman
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- Re: Distributed configuration of "private" IDNA (… Andrew Sullivan
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- Re: Distributed configuration of "private" IDNA (… Andrew Sullivan
- Re: Distributed configuration of "private" IDNA (… John C Klensin
- RE: Distributed configuration of "private" IDNA (… Dave Thaler
- RE: Distributed configuration of "private" IDNA (… Dave Thaler
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- RE: Distributed configuration of "private" IDNA (… Shawn Steele
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- RE: Distributed configuration of "private" IDNA (… Shawn Steele
- Re: Distributed configuration of "private" IDNA (… Nicolas Williams
- RE: Distributed configuration of "private" IDNA (… Shawn Steele
- Re: Distributed configuration of "private" IDNA (… Andrew Sullivan
- RE: Distributed configuration of "private" IDNA (… Shawn Steele
- Re: Distributed configuration of "private" IDNA (… Patrik Fältström
- Re: Distributed configuration of "private" IDNA (… Andrew Sullivan
- RE: Distributed configuration of "private" IDNA (… Shawn Steele
- RE: Distributed configuration of "private" IDNA (… Shawn Steele