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

Nicolas Williams Nicolas.Williams at oracle.com
Thu Jun 17 22:39:43 CEST 2010

On Thu, Jun 17, 2010 at 04:22:09PM -0400, Andrew Sullivan wrote:
> On Thu, Jun 17, 2010 at 11:11:55AM -0500, Nicolas Williams wrote:
> > 
> > See "First: to note that...".  That is: I don't think DNS, much less
> > _application_ implementors can be expected to support private DNS clouds
> > with non-standard IDN rules.  It's just too big a PITA.
> Hold on, there.  The DNS allows _octets_ in domain name labels.  That
> ...

It does.  However, there's no way that anyone will bother making
getaddrinfo(), DNS resolver, and application implementations that
actually know when to send A-labels versus when to send something else,
much less what that something else ought to be.

> The actual facts of the matter, and those facts' interaction with
> other conventions, restrictions, and the myriad deployed stuff, is
> rather different, which is how we got to IDNA2008.  But claiming that
> "DNS can't be expected to support private DNS clouds with non-standard
> IDN rules" misses the boat by almost 25 years.  It always did.

DNS can't work interoperably with multiple IDN rulesets for the simple
reason that to do so would require code to decide amongst IDN rules to
apply in context-specific manners.  The necessary guidance for
implementors to do that is missing to begin with.  And since there
almost certainly would be more than one set of IDN rules to choose from
(ISO8859-* encoded labels, UTF-8 encoded labels, with either
un-pre-processed or normalized-and/or-case-folded Unicode, IDNA2008 ACE
encoded labels, and so on).

At best one can narrow this to two sets of rules: IDNA2008 and
just-send-8-with-all-nodes-using-the-same-locale (and input methods).
And even then there's no standard way to know when to use one or the
other, and the latter isn't really realistic except for the tiniest

If you really, really want this to work, then start thinking about
solutions along the lines of my strawman proposal for an NS-like RR that
indicates what IDN rules apply to delegated zones.  I'd rather help make
IDNA2008 better by working on the APIs aspect of the problem.


More information about the Idna-update mailing list