[dns-operations] dotless domains

[Mark Andrews]

On 22/09/2012, at 6:51 AM, Doug Barton <dougb at dougbarton.us> wrote:

> 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."

No it is a security issue see RFC 1535.

> 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.

So you are saying anyone with a unqualified hostname that matches a
TLD label now has to suck it up and qualify all references to that hostname
despite simple hostnames being deprecated by RFC 921.

Hierarchical domains are defined as "label.label" not "label." as some
people want you to believe.

> 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.

But this isn't just changing the definition of the tld label.  It is changing
the definition of a hierarchical name to overlap that of a simple name.

> 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.

Unfortunately the risk is not *only* on them.  It's also on anyone else
that uses a simple name that matches a TLD name.   This is not idle
speculation, there are plenty of documented examples already with
just the few current TLDs.  It is a risk that can't be mitigated against
by choosing a non clashing label to begin with as the TLD namespace
is growing.

> Doug
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs