[dns-operations] dotless domains

[Doug Barton]

On 09/21/2012 20:22, Mark Andrews wrote:
> 
> 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.

If I can make http://yahoo work on the LAN, I can create a security
issue. But if I can do that, it's overwhelmingly likely that I can also
direct http://yahoo.com  where I'd like it to go as well. So this does
not create a new problem.

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

Nope. I'm saying that there are ways to make it work, and where there is
a will (and $$), that it will be made to work.

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

To some extent I agree with you, but I also don't care. :)

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

So you're saying that the risk already exists with existing TLDs, and
given the expansion of the name space it's going to get harder and
harder to choose short hostnames that don't clash .... that cries out to
me for an intelligent application of the search string. Limiting the
ability of gTLD holders to innovate because we need to update the end
systems seems like a violation of the "smart edges, dumb core" rule as
well.

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)