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

[Nicolas Williams]

On Thu, Jun 17, 2010 at 11:53:44PM +0000, Shawn Steele wrote:
> > OK, that (try UTF-8 first, then ACE) could work.  Do you prepare the
> > UTF-8 in any way?  E.g., normalize it?  Case-fold it?
> 
> That's an area that is really not good right now.  DNS is obviously
> case-insensitive in ASCII, however the UTF-8 that we've allowed is
> pretty dumb and doesn't do any mapping/filtering.  It is "obvious"
> that we should only allow UTS#46 behavior type U-Labels in the future,
> however getting to that point might be tricky since internal machines
> could already have names that conflict with that mapping..  (We could
> apply those rules to the UTF-8 string when doing lookup).  Assuming
> someone's using the canonical U-Label form, it's not a problem.
> Dave's working with some folks looking at that.

Thanks, this is useful information.  Particularly if you want anyone
else to interop with this.

> > My concern was: how do you do hostname resolution in an environment
> > with private sub-namespaces with non-IDNA IDN rules.
> 
> Well, that's where "try utf-8 1st, then ACE" happens.  Of course, if
> they don't both use UTS#46 mappings, then you've got a problem since
> one may resolve one way and not the other :(   I think the "right"
> answer would be to use UTS#46 conformant U-Labels when doing UTF-8
> lookup, however that's breaking in some environments.  
> 
> Historically, it seems to have worked due to coincidences like the
> IME's generally enter data in the same form, etc., so we're unlikely
> to see NFD requests for NFC names, but it's obviously a point of
> weakness.  I'd expect other environments got away with similar things
> in native code page requests, etc.

NFD can and has leaked.  MacOS X's HFS+ normalizes filenames to NFD on
create, and when you list directories the names appear in NFD.  (This is
why we chose to implement normalization-insensitivity in ZFS.)  If
someone were to cut-and-paste from a MacOS X HFS+ filesystem into an
IDN-unaware domainname slot, particularly a domainname registration
slot... you'd have a problem.

So I definitely recommend normalizing to NFC first, and you might as
well apply UTS#46.  (Names that breaks because of differences in
IDNA2003 and 2008 will be few and far between, and not that big a deal.
Affected users may be annoyed at first, but also presumably overjoyed as
well at the aesthetic/semantic improvement.)

Nico
--