Punycode & nslookup

jefsey jefsey at jefsey.com
Mon Dec 7 15:46:35 UTC 2009

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

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.


More information about the bind-users mailing list