ICANN opens up Pandora's Box of new TLDs

Frank Bulk frnkblk at iname.com
Mon Jun 30 18:02:29 UTC 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.

Frank

-----Original Message-----
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 2.0.0.14.  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
3.1
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
the
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,
and
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
"museum"
but without the added complications, and the ICANN fee is a lot less ;)






More information about the NANOG mailing list