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@zynet.net] Sent: Monday, June 30, 2008 12:21 PM To: nanog@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:
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@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 ;)