At 14:07 07/12/2009, Danny Mayer wrote:
> The reason IDN support in the BIND query tools (dig, host, nslookup)
is not the default is because it relies on a 3rd party library, which
must be installed and configured by the package builder beforehand. This
is just like SSL support, needed for DNSSEC and TSIG, except that most
operating systems don't already ship with libidnkit.
>
And I haven't looked for one for Windows so it probably won't work with
Windows.
IDNA2008 is an "elementary" solution: i.e. at individual application
level. This means that we now need an IDNA system that will
identically support all the elementary needs of each of the
applications on a machine. And we need to incorporate IDNA in the
network globalilty, meaning making sure the various (ICANN, Google,
Interplus, Microsoft(?), IDNA2003, Unicode approaches) do
interoperate. This is the fundamental issue currently discussed at
the WG/IDNABIS. This cannot be attained in curbing humanity to the
current uncomplete text limitations. This is to be based upon
experimentation, adaptation, and practice of the IDNA2008 proposition.
My current conclusion is that the general solution lies in a
replacement of the punycode implementation (i.e libidnkit) by an
extended punyplus module that will perform along the IDNA2010 wrap-up
exploratory effort that was initiated yesterday
(http://iucg.org/wiki/BUD-IDNA2010). This seems to be the most
natural and the most portable place.
jfc
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
