ICANN opens up Pandora's Box of new TLDs
frnkblk at iname.com
Mon Jun 30 13:02:29 CDT 2008
It would be helpful if someone could put together of web page of different
links so that people could test the native resolvers for each OS and
applications (web browsers primarily, but also DNS clients separated from
the OS stack such as dig and nslookup).
Perhaps some of this brokenness can be illuminated sooner rather than later.
From: Simon Waters [mailto:simonw at zynet.net]
Sent: Monday, June 30, 2008 12:21 PM
To: nanog at nanog.org
Subject: Re: ICANN opens up Pandora's Box of new TLDs
On Monday 30 June 2008 17:24:45 John Levine wrote:
> >> In the usual way. Try typing this into your browser's address bar:
> >> http://museum/
> > That was amusing. Firefox very handily took me to a search
> > results page listing results for the word "museum", none of
> > which was the actual page in question.
> Gee, it works fine for me in Firefox 184.108.40.206. I'd suggest filing a bug
> report against your OS vendor to fix their resolver library.
I think that the following hold ... but I have a headache....
Since the hostname part of the URI does not contain a dot, RFC1034 section
applies (according to RFC 2396), the name is treated as relative initially,
and the interpretation "varies from implementation to implementation".
In particular if a "museum" name exists in your current domain, and/or other
searches that may be applied to the lookup that may be correctly returned
first. The language implies that "." need not be part of the search, so the
URL need not work and the implementation could still be RFC conforming.
Certainly there is scope for confusion here. My machines resolver is
configurable - option ndots in resolv.conf - but ndots defaults to 1 - I'm
sure the folks who wrote the resolver code considered the default carefully.
Clearly an area ICANN need to ponder, if they haven't already, as changing
resolver defaults globally might undermine the stability of the root name
servers. And introducing new domains will encourage vendors to change their
resolvers default behaviour (even for areas where it is already technically
RFC conforming, if not "least surprise" conforming).
> > Thanks for all the pointers! I guess I won't be suggesting the
> > use of such TLDs as gmail and ymail as a way to shorten up
> > email addresses for people, given the inconsistent behaviour
> > of client resolvers. ^_^;
> Too bad. You might try writing the guy whose address is n at ai (yes, his
> name is Ian) and see what his experience has been.
Now that is an email address not a URI, so section 5 of RFC 2821 applies,
treating the domain as "relative" is "discouraged". So I'd expect his email
address to work (with a few exceptions - just like addresses with
apostrophes - some folks will have bad implementations).
IE gets to the correct page here. Firefox on Windows did something else
again - sigh (I'm sure it is can be corrected in the browser configuration
somewhere). There is a squid proxy behind both of them.
On the other hand if people need short domain names, my employers may have a
couple to sell of the old fashioned variety the same total length as
but without the added complications, and the ICANN fee is a lot less ;)
More information about the NANOG