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 <k...@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 ?
<bapti...@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 <k...@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 <cbux...@menandmice.com> 4 décembre 2009 18:26
À: Bind Mailing <bind-users@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?
<bapti...@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 <cbux...@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 <k...@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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
