[dns-operations] dotless domains

Doug Barton dougb at dougbarton.us
Fri Sep 21 20:51:08 UTC 2012

On 09/21/2012 11:33 AM, sthaug at nethelp.no wrote:
>>> Surprised no one's brought up http://dk/ as an already existing scenario
>>> that doesn't work (try it in various browsers).
>> Bad example. The first *four* browsers I tried (firefox, chrome, safari,
>> and opera on osx) handle this perfectly.
> http://dk/ doesn't work particularly well on my Win 7 laptop:
> Opera 12.02		- gets me http://www.dk.no/
> Firefox	15.01		- gets me http://www.dk.com/
> Chrome 21.0.1180.89	- gets me "Oops! Google Chrome could not find dk"

For FF at least you're experiencing the "helpful" features that try to
guess what you might have meant when you type in single words. I'm
pretty sure that Opera has a similar feature, and I know that Chrome
does. I have the following settings for FF to turn off that crap:

user_pref("keyword.enabled", false);
user_pref("browser.fixup.alternate.enabled", false);

> I think it's safe to say that http://dk/ does not *reliably* work the
> way it's supposed to work. Nobody on this list should be surprised...

No, not surprised. However, I also do not think that the fact that it
doesn't work reliably is a reason to forbid it contractually.

1. ccTLDs will always be able to do it, and a non-zero number of them
already do. As a result, not allowing gTLDs to do it creates a feature
disparity that would have to be justified by serious security and
stability considerations. As in, it actually *breaks* something, as
opposed to "it doesn't work reliably."

2. We are not limited by the status quo. While the _current_ state of
things is that we cannot guarantee that single labels will work reliably
in all cases, those who are putting very large sums of money into the
process of acquiring and operating these domains (especially the .brand
domains) will not hesitate to expend effort (and $$) to bring other
developers up to speed. For example, in the browser it is a very simple
matter to first append a dot to a single label and see if it resolves
before trying the search domains.

This isn't speculation BTW, we had a similar push to educate developers
when the last TLD round went through, and it was necessary to update a
lot of software that had old, hard-coded assumptions about what TLD
strings were valid. It took a long time to fix it, but we're far out on
the tail end of that particular bell-shaped curve atm.

3. It's Ok if they fail. I realize that this idea rankles those of us
who have dedicated a lot of energy into making sure that things DON'T
break for the end users, but there are a LOT of risks inherent in the
latest round of gTLD apps. This particular problem is a relatively minor
technical issue that has readily available technical solutions. In all
likelihood it can be made to work. Or maybe it can't, so rational gTLD
operators will stop doing it. Either way, the risk is on them, and
absent actual breakage of something other than the connection between
the end user and the gTLD, I personally am happy to allow the gTLD
operator to assume that risk.


More information about the dns-operations mailing list