Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())

Nicolas Williams Nicolas.Williams at oracle.com
Wed Jun 16 23:54:50 CEST 2010

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

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 :)


More information about the Idna-update mailing list