Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())
Nicolas.Williams at oracle.com
Fri Jun 18 02:04:27 CEST 2010
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.)
More information about the Idna-update