Dotless domains are dead

Kevin Murphy, August 16, 2013, Domain Policy

ICANN has banned dotless gTLDs, putting a halt to Google’s plans to run .search as a dotless search service and confounding the hopes of some portfolio applicants.

ICANN’s New gTLD Program Committee, acting with the powers of its board of directors passed the resolution on Tuesday. It was published this morning. Here’s the important bit (links added):

Resolved (2013.08.13.NG02), in light of the current security and stability risks identified in SAC053, the IAB statement and the Carve Report, and the impracticality of mitigating these risks, the NGPC affirms that the use of dotless domains is prohibited.

The current version of the Applicant Guidebook bans dotless domains (technically, it bans apex A, AAAA and MX records) but leaves the door open for registries to request an exception via Extended Evaluation.

This new decision closes that door.

The decision comes a week after the publication of Carve Systems’ study of the dotless domain issue, which concluded that the idea was potentially “dangerous” and that if ICANN intended to allow them it should do substantial outreach to hardware and software makers, essentially asking them to change their products.

The Internet Architecture Board said earlier that “dotless domains are inherently harmful to Internet security.”

Microsoft, no doubt motivated in part at least by competitive concerns in the search market, had repeatedly implored ICANN to implement a ban on security grounds.

Google had planned to run .search as a browser service that would allow users to specify preferred search engines. I doubt the dotless ban will impact its application’s chances of approval.

Donuts and Uniregistry, which together have applied for almost 400 gTLDs, had also pushed for ICANN to allow dotless domains, although I do not believe their applications explicitly mentioned such services.

IAB gives dotless domains the thumbs down

Kevin Murphy, July 11, 2013, Domain Tech

The Internet Architecture Board believes dotless domain names would be “inherently harmful to Internet security.”

The IAB, the oversight committee which is to internet technical standards what ICANN is to domain names, weighed into the debate with an article apparently published yesterday.

In it, the committee states that over time dotless domains have evolved to be used only on local networks, rather than the internet, and that to start delegating them at the top level of the DNS would be dangerous:

most users entering single-label names want them to be resolved in a local context, and they do not expect a single name to refer to a TLD. The behavior is specified within a succession of standards track documents developed over several decades, and is now implemented by hundreds of millions of Internet hosts.

By attempting to change expected behavior, dotless domains introduce potential security vulnerabilities. These include causing traffic intended for local services to be directed onto the global Internet (and vice-versa), which can enable a number of attacks, including theft of credentials and cookies, cross-site scripting attacks, etc. As a result, the deployment of dotless domains has the potential to cause significant harm to the security of the Internet

The article also says (if I understand correctly) that it’s okay for browsers to interpret words entered into address bars without dots as local resources and/or search terms rather than domain names.

It’s pretty unequivocal that dotless domains would be Bad.

The article was written because there’s currently a lot of talk about new gTLD applicants — such as Google, Donuts and Uniregistry — asking ICANN to allow them to run their TLDs without dots.

There’s a ban in the Applicant Guidebook on the “apex A records” that would be required to make dotless TLDs work, but it’s been suggested that applicants could apply to have the ban lifted on a case by case basis.

More recently, ICANN’s Security and Stability Advisory Committee has stated almost as unequivocally as the IAB that dotless domains should not be allowed.

But for some reason ICANN recently commissioned a security company to look into the issue.

This seems to have made some people, such as the At Large Advisory Committee, worried that ICANN is looking for some wiggle room to give its new gTLD paymasters what they want.

Alternatively, ICANN may just be looking for a second opinion to wave in the faces of new gTLD registries when it tells them to take a hike. It was quite vague about its motives.

It’s not just a technical issue, of course. Dotless TLDs would shake up the web search market in a big way, and not necessarily for the better.

Donuts CEO Paul Stahura today published an article on CircleID that makes the case that it is the browser makers, specifically Microsoft, that are implementing DNS all wrong, and that they’re objecting to dotless domains for competitive reasons. The IAB apparently disagrees, but it’s an interesting counterpoint nevertheless.

Microsoft objects to Google’s dotless domains plan

Kevin Murphy, June 11, 2013, Domain Tech

Microsoft has strongly urged ICANN to reject Google’s plan for a “dotless” .search gTLD.

In a letter sent a couple of weeks ago and published last night, the company says that Google risks putting the security and stability of the internet at risk if its .search idea goes ahead.

David Tennenhouse, corporate vice president of technology policy, wrote:

Dotless domains are currently used as intranet addresses controlled by private networks for internal use. Google’s proposed amendment would interfere with that private space, creating security vulnerabilities and impacting enterprise network and systems infrastructure around the globe.

It’s a parallel argument to the one going on between Verisign and everyone else with regards to gTLD strings that may conflict with naming schemes on internal corporate networks.

While they’re subtly different problems, ICANN recently commissioned a security study into dotless domains (announced 11 days after Microsoft’s letter was sent) that links the two.

As Tennenhouse says in his letter, ICANN’s Security and Stability Advisory Committee, which has Google employees on it, has already warned about the dotless name problem in SAC053 (pdf).

He also claims that Google had submitted follow-up comments to SAC053 saying dotless domains would be “actively harmful”, but this is slightly misleading.

One Google engineer did submit such a comment, but it limited itself to talking about clashes with internal name certificates, a slightly different issue, and it’s not clear it was an official Google Inc comment.

The new gTLD Applicant Guidebook currently outlaws dotless domains through its ban on “apex A records”, but that ban can be circumvented if applicants can convince a registry services evaluation panel that their dotless domain plans don’t pose a stability risk.

While Google’s original .search application envisaged a single-registrant “closed generic”, it later amended the proposal to make it “open” and include the dotless domain proposal.

This is the relevant bit of the amended application:

Charleston Road Registry will operate a service that allows users to easily perform searches using the search functionality of their choice. This service will operate on the “dotless” search domain name (http://search/) and provide a simple web interface. This interface operates in two modes:

1) When the user has not set a preference for a search engine, they will be prompted to select one. The user will be provided with a simple web form that will allow them to designate a search engine by entering the second level label for any second level domain registered with in the TLD (e.g., if “foo.search” was a valid second level domain name, the user could indicated that their preferred search engine was “foo”). The user can also elect to save this preference, in which case a cookie will be set in the userʹs browser. This cookie will be used in the second mode, as described below. If the user enters an invalid name, they will be prompted again to provide a valid response.

2) If the user has already set a preferred search engine, the redirect service will redirect the initial query to the second level domain name indicated by the userʹs preference, including any query string provided by the user. For example, if the user had previously selected the “foo” search engine and had issued a query for http://search/?q=bar, the server would issue a redirect to http://foo.search/?q=bar. In this manner, the userʹs query will be consistently redirected to the search engine of their choice.

While Google seems to have preempted some concerns about monopolistic practices in the search engine market, approval of its dotless search feature would nevertheless have huge implications.

Make no mistake, dotless domains are a Big Deal and it would be a huge mistake for ICANN to treat them only as a security and stability issue.

What’s weird about Google’s proposal is that by asking ICANN to open up the floodgates for dotless domains, it risks inviting the domain name industry to eat its breakfast, lunch and dinner.

If ICANN lets registries offer TLDs domains without dots, the new gTLD program will no longer be about delegating domain names, it will be about auctioning exclusive rights to search terms.

Today, if you type “beer” into your browser’s address bar (which in all the cases I’m aware of are also search bars) you’ll be directed to a page of search results for the term “beer”.

In future, if “beer” is a domain name, what happens? Do you get search or do you get a web page, owned by the .beer registry? Would that page have value, or would it be little better than a parking page?

If browser makers decided to implement dotless domains — and of course there are plenty of reasons why they wouldn’t — every borderline useful dictionary word gTLD would be sold off in a single round.

Would that be good for the internet? I’d lean toward “no”.

Apple, Google and Microsoft still don’t understand new TLDs

Kevin Murphy, January 22, 2013, Domain Tech

The world’s most-popular web browsers are still failing to recognize new top-level domains, many months after they go live on the internet.

The version of the Safari browser that ships with the Mountain Lion iteration of Apple’s OS X appears to have even gone backwards, removing support for at least one TLD.

The most recent versions of Google’s Chrome and Microsoft’s Internet Explorer also both fail to recognize at least two of the internet’s most recently added TLDs.

According to informal tests on multiple computers this week, Safari 6 on Mountain Lion and the Windows 7 versions of Internet Explorer 9 and Chrome v24 all don’t understand .post and .cw addresses.

Remarkably, it appears that Safari 6 also no longer supports .sx domains, despite the fact that version 5 does.

Typing affected domain names into the address bars of these browsers will result in surfers being taken to a search page (usually Google) instead of their intended destination.

If you want to test your own browser, registry.sx, una.cw and ems.post are all valid, resolving domain names you can try.

The gTLD .post was entered into the DNS root last August and the first second-level domain names went live in October.

The ccTLDs .sx and .cw are for Sint Maarten (Dutch part) and Curacao respectively, two of three countries formed by the breakup of the Netherlands Antilles in 2010.

ICANN approved the delegation of .cw in October 2011 and second-level domains there have been live since at least July 2012 (that’s when the registry’s site, una.cw, went live).

SX Registry’s .sx was delegated in December 2011 and sites there have been live since early 2012. It went into general availability in November.

Safari v5 on Windows and OS X recognizes .sx as a TLD, but v6 on Mountain Lion does not.

The problems faced by .post and .cw on Chrome appear to be mostly due to the fact that neither TLD is included on the Public Suffix List, which Google uses to figure out what a TLD looks like.

A few days after we reported last May that .sx didn’t work on Chrome, SX Registry submitted its details to the PSL, which appears to have solved its problems with that browser.

It’s not at all clear to me why .sx is borked on newer versions of Safari but not the older ones.

If the problem sounds trivial, believe me: it’s not.

The blurring of the lines between search and direct navigation is one of the biggest threats to the long-term relevance of domain names, so it’s vital to the industry’s interests that the problem of universal acceptance is sorted out sooner rather than later.

Microsoft, Yahoo and others involved in new dot-brand gTLD group

HSBC, Microsoft, Yahoo and jewelry maker Richemont have told ICANN they plan to form a new GNSO stakeholder group just for single-registrant gTLD registries.

The group would comprise dot-brand registries and — potentially — other types of single-user gTLD manager.

A letter (pdf) to ICANN chair Steve Crocker, signed by executives from the four companies, reads in part:

As a completely new type of contracted party, we do not have a home to represent our unique community. In addition, the existence of conflicts with other contracted parties makes it challenging for us to reside within their stakeholder group.

Combined, the companies have applied for about 30 single-registrant gTLDs, mostly corresponding to brands.

Richemont, which is applying for dot-brands including .cartier, is also applying for the keywords .jewelry and .watches as single-user spaces.

The group plans to discuss formalizing itself at the next ICANN meeting, in Toronto this October.

During the just-concluded Prague meeting, the GNSO’s existing registries stakeholder group accepted several new gTLD applicants — I believe mainly conventional registries — into the fold as observers.

How the influx of new gTLD registries will affect the GNSO’s structure was a hot topic for the Governmental Advisory Committee during the meeting too. I guess now it has some of the answers it was looking for.