[dns-operations] dotless domains

[Mark Andrews]

In message <505FD46B.6070602 at dougbarton.us>, Doug Barton writes:
> 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.

It does if "http://myname" goes to a local machine one day and the
next day it goes to a tld the next day because "myname" was added
to the root zone and that zone has A, AAAA or SRV records which
will be the case if resolvers/browsers are "fixed" to make simple
names match against tld first, which you suggest is a logical
consequence of allowing this idiocy to continue.

I've got machines named "sex" and "drugs" (sex, drugs, rock and
roll as a naming scheme).  One if not both of those names make
interesting TLDs.  Which machine should "ssh sex" or "ssh drugs"
connect to if sex and/or drugs tlds are added with address records.
Note I've been using those names for nearly 2 decades now.  Why
should I have to change my usage because some jolly come lately
with $200000 can buy a TLD.

> >> 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)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org