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

Shawn Steele Shawn.Steele at microsoft.com
Fri Jun 18 01:53:44 CEST 2010

> 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.

> 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.


More information about the Idna-update mailing list