Punycode & nslookup

JFC Morfin jefsey at jefsey.com
Sat Dec 5 14:34:37 UTC 2009


>Hi! Kay,
>I take back the entire thread since this is something which really 
>match what is under warm discussion at the IETF WG/IDNSBIS.
>
>Kai Szymanski <ks at codebiz.de> 4 décembre 2009 15:41
>One of our customers wan't a Domain with "Umlaute" (german special 
>characters like "ä").
>Is it correct when i have configured the zone like
>
>zone "<http://xn--umlauttest-z5a0tyc.de>xn--umlauttest-z5a0tyc.de" {
>       type master;
>       file "master/umlauttestäöü.de.hosts";
>       allow-transfer { can_transfer; };
>       # allow-update { can_update; };
>};
>
>and the record like
>
><http://xn--umlauttest-z5a0tyc.de>xn--umlauttest-z5a0tyc.de. 
>IN      SOA     <http://ns.foobar.de>ns.foobar.de. 
><http://hostmaster.foobar.de>hostmaster.foobar.de. (
>                                       2009120401      ; Serial
>                                       8H              ; refresh
>                                       4H              ; retry
>                                       5w6d16h         ; expiry
>                                       1D )            ; minimum
>
>       IN NS <http://ns.foobar.de>ns.foobar.de.
>       IN NS <http://ns2.foobar.de>ns2.foobar.de.
>
>If so: When you enter the Domainname in a Browser: Did the Browser 
>also encode the url to punycode before asking a nameserver ?
>
><baptista at publicroot.org> 4 décembre 2009 16:05
>As for you question concerning the browser converting the domain to 
>punycode before asking a nameserver - yes that is what some browsers 
>do. I'm not sure why because it must confuse some users when that happens.

This is the IDNA concept. Conversion is to happen in Applications.


>Kai Szymanski <ks at codebiz.de> 4 décembre 2009 16:23
>my "problem" is: I can't test the zone with nslookup (only when i 
>use the puny-encoded domainname). Also other tools who uses dns to 
>resolv the entered domainname (like ping 
><http://www.xn--umlauttest-z5a0tyc.de>www.umlauttestäöü.de) did'nt work.
>
>So i thought that
>
>1. The User enters a url with Umlauts in browser
>2. Browser examine url, "see" that there is umlaut in the 
>domainname, an encoded it (internal, so the user did'nt see it) to 
>puny code and ask the default nameserver for the domainname in punycode
>Is this correct ?

>Chris Buxton <cbuxton at menandmice.com> 4 décembre 2009 18:26
>À: Bind Mailing <bind-users at lists.isc.org>
>On Dec 4, 2009, at 7:23 AM, Kai Szymanski wrote:
> > Hi Joe,
> >
> > my "problem" is: I can't test the zone with nslookup (only when i 
> use the puny-encoded domainname).
>
>nslookup will only understand IDN if BIND is compiled with that 
>option in the ./configure step.
>
> > Also other tools who uses dns to resolv the entered domainname 
> (like ping 
> <http://www.xn--umlauttest-z5a0tyc.de>www.umlauttestäöü.de) did'nt work.
>
>Other CLI tools will not work.
>
> > So i thought that
> >
> > 1. The User enters a url with Umlauts in browser
> > 2. Browser examine url, "see" that there is umlaut in the 
> domainname, an encoded it (internal, so the user did'nt see it) to 
> puny code and ask the default nameserver for the domainname in punycode
>
>The browser has to understand IDN. Most current browsers do, 
>including (I believe) IE 7 and later, Firefox 2 and later, and 
>Safari 3 and later.

This is correct. However, beware: since you talk of test. The coming 
"Fast Track" ICANN project should use IDNA2008 (more versatile but 
restrict A-labels (xn--) to lower cases). The question is when is 
IDNA2008 to be released. We hoped this month or January. The present 
debate on Eszett that raised again at the WG may delay this.

To better understand I started looking in the code where the punycode 
routine is. Has someone a file name for it?

><baptista at publicroot.org> 4 décembre 2009 19:12
>might be a good idea if it was the default option. as idn becomes 
>popular the lack of idn support for the tools will result in confusion.

Yes. But IDNA2008 is going to be much more complex to support for 
this kind of tool since zone managers may impose their own rules. So, 
in addition to know if an IDN works, it would be great to know if it 
is legitimate (TLD zone managers may decide rules, but higher level 
zone managers to disregard them).

>Does anyone have a list of idn domains? I'd like to try it out.

Just try http://jean-françois.jefsey.com - a very old introduction 
page. But that is simple (in roman script).

>Chris Buxton <cbuxton at menandmice.com> 4 décembre 2009 20:29
>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.

Do you know the hook? I am just starting investigating the code, and 
I have C only as a minor :-)

>Kai Szymanski <ks at codebiz.de> 5 décembre 2009 14:04
>What is the way for the future: Should the browser encode idn's into
>punycode and send it to the nameserver (like example below) or should
>the browser send the un-encoded idn to the nameserver and the nameserver
>have to do the "encoding-stuff" ? Or both ?

This a key architectural and network security issue. At this stage 
only the IDNA principles are documented. They imply (the IDNA name) 
that the applicatins (browser) should do the work. However, this 
implies a lot of possible different versions on the same machine. 
However, this also means the update of 16,5 millions of nameservers 
round the world. A big problem.

IMHO the current WG/IDNABIS burst is to obtain a clearer definition 
that the just announced Google DNS service can build on top (Google 
is _very_ involved in IDNA2008). This might lead punycode and value 
added punycode services to be placed in DNS front-end. This was 
discussed in WG/OPES the list is now unfortunately closed and the 
next document should have considered DNS and OPES.

This should be carefully considered in regards of pollution 
propagation. Also, we need to know better about DNS resolution in Chrome OS.

As usual in the Internet architecture,  the best is to try and test. 
I look for people interested in just doing that and reporting on results.
jfc

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20091205/6c4eff55/attachment.html>


More information about the bind-users mailing list