ICANN Committee rejects dotless domain names, won’t “pursue any additional studies”

As you may recall from prior posts on this blog, there has been significant interest in the new gTLDs (e.g., and proposals from Google to allow one of their gTLD applications (.search) to function as a dotless domain (e.g. http//search). This ask was in sharp contrast to the report from ICANN’s own Security and Stability Advisory Committee (SSAC), that said dotless was a bad idea.

Microsoft and many others in the industry (including Yahoo, Verisign) expressed concerns in allowing dotless domains on the Internet. The Internet Architecture Board (IAB) published a public statement, noting the relevant standards published by the IETF RFCs and supporting ICANN SSAC’s report SAC053 as

“a reasonable summary of the technical problems that arise from the implementation of dotless domains.” 

And a further study directed by ICANN (from Carve Systems here) arrived at the same conclusions as the SSAC. In it, Carve supported SSAC 053 that dotless domains would not be universally reachable, and serious security vulnerabilities exist and would be enabled by allowing such use. It concluded the

“inherent trust in dotless names, by users and software, may lead to confusion when handling new Internet facing dotless domains. This confusion can result in unexpected behavior and a misappropriation of trust, ultimately degrading the stability and security of the Internet.”

The “broad theme” of dotless domain names is accurate, and significant issues exist with current and legacy software and services that follow the tradition of using dotless names exclusive in the intranet space. Dotless domains are used as a core part of many intranet networks, and as such there would be serious implications and repercussions related to their use. To address some of the “technology confusion” raised in the report, Microsoft and many others in the industry have provided guidance for developers, service providers and enterprises to use unambiguous Fully Qualified Domain Names to specify locations in the tree hierarchy of the DNS.

So, after many months, I was happy to read recently that ICANN’s New gTLD Program Committee (NGPC) passed a resolution definitively rejecting the push for dotless domains. This was also supported by ICANN’s board, as announced last week. You can read more about how ICANN rejected the request to support dotless generic top-level domains on the Internet in Charlie Osborne’s article here on ZDnet.


An update on so-called dotless domains on the Internet

A couple of months ago I wrote here about the challenges with so-called “dotless” domains (e.g. http://microsoft instead of the common Such shortcuts may seem harmless at first glance, but they raise many more issues than might be solved when it comes to completing and validating an Internet URL or email address.

As you may recall, Microsoft’s position is that such shortened domains (as noted in our comment here) are not a good idea, as called out in the report from ICANN’s own Security and Stability Advisory Committee. (You can view the complete report here.) We know that many others also support the view that dotless domains would not be universally reachable, along with the serious security vulnerabilities enabled. Dotless domains would be confusing and customers might not know what to expect when they entered in such a shortened name.

In addition, the surface area to address all the different software components for stability and security concerns related to using such dotless names is tough. Not just a problem for consumers, many businesses and organizations (from small business to complex and worldwide enterprises) have current and legacy software and services that follow the tradition of using dotless names exclusive in the intranet space.

For instance, here at Microsoft, if I type in a dotless domian (e.g. “http://search“) into the address bar at work, I’ll go to my internal intranet search web page. Many companies function the same way, and you can imagine that any number of terms or strings used on a number of many different intranet networks could have serious implications and repercussions related… particularly if companies had to do additional work to parse and allocate these terms from a set of new top level domains.

I saw an example of what confusion could look like over lunch, as I attempted to register on a web site. In this case, the site failed to recognize an email address with only dotless domain as valid…


Now, multiply that by the number of websites where you enter in your email or web address and you can imagine the confusion, in addition to the work involved if every web site had to support new (and growing) dotless domains. (Certainly one of the new services that will opened up will include selling/ leasing new second level domains or Internet email addresses on the new crop of gTLDs.)

To address some of the confusion we’ve seen in the past (where companies have deployed single label domains), Microsoft and many others in the industry have provided guidance for developers, service providers and enterprises to use unambiguous Fully Qualified Domain Names. These FQDNs are sometimes referred to an absolute domain name, which specify locations in the tree hierarchy of the DNS and ensure that people get where they are expecting when they type in an address on the Internet URL and avoid any confusion.

Last week, the Internet Architecture Board (IAB) published a public statement calling attention again to the concerns on using dotless domains in the root zone, noting the relevant standards published by the IETF RFCs. In the statement, the IAB also cites the ICANN SSAC’s report SAC053 as “a reasonable summary of the technical problems that arise from the implementation of dotless domains.” The Register offers their own take in an article posted today.

I look forward to ICANN’s latest study to examine the potential risks related to dotless domain names (based on ICANN’s SSAC 053 report). Once released, Microsoft is interested to provide additional feedback and comments. The good folks at ICANN are holding their latest meeting in Durban this week, and I can imagine there will be some discussion around this (and many other pressing topics).

Also available via


ICANN, the GAC, SSAC and gTLDs: Challenges with Dotless Domains and Closed Generics

Last year, Craig Mundie posted about ICANN’s gTLD Reveal Day calling it “another step in the Internet’s evolution.”

Let’s hope we won’t see “one step up and two steps back.”

ICYMI, ICANN (the Internet Corporation for Assigned Names and Numbers organization) approved plans for new generic Top Level Domains (“gTLDs”) to add to the common domains you see today, like .com, .net, and .org among and others. It was impressive to see the level of interest in these new domains, with close to 2,000 applications for new unique domains from around the world. As Craig noted, Microsoft focused on eleven new top-level domain names that correspond to our well-known products, services and brands: .microsoft, .windows, .xbox, .office, .docs, .bing, .skype, .live, .skydrive, .hotmail and .azure…

“Our goal for our new TLDs is to promote responsible utilization of the Web and ultimately better experiences for consumers. Although we’re not yet talking about specific plans for the TLDs for which we’ve applied, we believe that – properly used – this expansion of domains can help deliver new services and capabilities to consumers and the Internet community as a whole. Appropriately utilized, the new TLDs can also protect the rights of trademark holders and brand owners, while promoting a safer and more secure computing experience.

“With so many new gTLD applications, there are bound to be cases where multiple players have applied for the same top-level domain, and ICANN has processes in place to help resolve those cases. We are just now reviewing all of the applications by other companies and organizations. We will work closely with ICANN and others to ensure competition and innovation are preserved for the industry, while also helping protect the rights and expectations of other stakeholders.”

Late last summer, ICANN’s own Security and Stability Advisory Committee (SSAC) published a report to address the issue of dotless gTLDs. This was partly in response to questions on whether or not new gTLD name registry operators would be able to use their gTLD as a valid Internet domain (e.g. http://microsoft instead of the common The SSAC strongly recommended against the use of dotless domains, and opened a comment period on this issue, to get feedback from the community (you can read more here)…

“…the combined effect of these potential ambiguities makes it very difficult in practice to predict how a dotless domain name will be resolved in different situations. The result could be anything from fully expected behavior to a security incident in which the user of a domain name (or URL with the domain name embedded) communicates unknowingly with a party other than intended; or, as in the email example in Section 3.4 above, a failure of the system to provide any service at all. Additionally, this ambiguous behavior could be used to develop methodologies to compromise the session and allow for malicious activities with, for example, DNS redirection.

“The SSAC is aware that there currently exist TLDs that attempt to resolve dotless domain names. Our initial examination reveals that resolution of these names is not consistent or universal, and in particular, applications behave differently when presented with “dotless” responses. These behaviors occur for reasons illustrated in this paper. Recommendation: Dotless domains will not be universally reachable and the SSAC recommends strongly against their use. As a result, the SSAC also recommends that the use of DNS resource records such as A, AAAA, and MX in the apex of a Top-Level Domain (TLD) be contractually prohibited where appropriate and strongly discouraged in all cases.”

As we summarized in our comments, Microsoft supports and endorses the report’s recommendations against use of dotless domains. There are significant security considerations around the use of dotless domains with new gTLDs, generally a bad idea that would create significant security risks for people using the Internet. Dotless domain names are often resolved by operating systems, browsers and other products to addresses on the local network / intranet. Our recommendation is to use Fully Qualified Domain Names (FQDNs) – sometimes referred to an absolute domain name – to ensure that people get where they are expecting when they type in an address on the Internet URL.

Last week, following broad coverage (as briefly noted on TechCrunch) on proposed dotless domains and how new gTLDs might be operated, I had a discussion with the folks over at on the topic.

As we saw in the Governmental Advisory Committee (GAC) recommendation to ICANN last week, we believe it’s contrary to the free and open ideals of the Internet for a private commercial entity to act as gatekeeper to domains that consist of generic industry terms, like .search, .cloud or .app. ICANN should follow the GAC’s clear recommendation that any non-open domains that consist of generic industry terms be required to establish that they serve a public interest goal.

Allowing dominant market leaders to control such generic domains is like trusting a fox to guard the henhouse. We urge ICANN to abide by the GAC’s advice and to follow the SSAC’s conclusions in order to preserve the freedom and openness of the Internet, protect the billions of Internet users, and foster healthy competition.

Also available via


Announcements: Supporting the next version of the Internet with IPv6 SP1

In my job at Microsoft, I worry about lots of things, not the least of which is where I parked my car this morning.MP900411803[1]

I worry about Russia’s move to abolish Daylight Saving Time, where to eat in Las Vegas, and the transition to ipv6. (Of course, our other announcement today eliminating the clock from the Windows OS should address the challenges of ever shifting DST scheduled and time zones.)

I recall a great headline last year from the good folks at ZDNet: IPv6: The end of the Internet as we know it (and I feel fine). Paraphrasing a classic REM song is fine, but in the views of some, IPv6 is not 2012. (With a nod to the Mayan calendar, which ends or renews — depending on your side of the debate — December 21, 2012, when a new Mayan Calendar count begins.) These make for great headlines. But many companies – including Microsoft – have been working on the transition to IPv6 for several years. Like any change, it’s always good to review where you and your industry is when it comes to migrating to a new technology or system.

Although IPv6 is designed to solve many of the problems of the current version of the IP (IPv4), we believe that this should be enough IP addresses for a few more years. Although IPv6 provides improved security, autoconfiguration, and extensibility, we know that a limited number of companies are reluctant to support the first release of a new product, and often wait for Service Pack 1 to be released.

So today, we are happy to announce the next move to the Internet Protocol, IPv6 SP1, the first sustained engineering service pack update to IPv6.

This innovative and just plain one better service pack will provide improved business value, ease of use and an incentive for customers to migrate to the next generation of the Internet. Its use will also expand the capabilities of the Internet and enable a variety of valuable and exciting scenarios. Realizing far too late that eventually these IPv4 addresses would be exhausted, Internet Protocol version six (IPv6) was mapped out in the 1990’s and then published in 1998 as the next step in IP.  IPv6 is 128-bit, which provides support for many more devices. 3.4 to the 128th, to be exact, or 340,282,366,920,938,463,463,374,607,431,768,211,456 IP addresses. IPv6.1 further embraces the move to social networking and the cloud by adding support for roughly twice as many addresses (2 to the 129th IP addresses – or 680,564,733,841,876,926,926,749,214,863,536,422,912) by allowing emoticon suffixes to the current set supported in IPv6.

There has been tremendous support in the marketplace for the announcement of IPv6.1.  Industry visionary Dan Jump, CEO of Contoso gave his early endorsement to the coming service pack at a joint press conference today. "Just as we’ve supported virtually every product and service Microsoft has ever brought to market, we’ve also been early testers on SP1 for IPv6. With this new release, we’ve been very happy in the support we’ve received from Microsoft. The entire Contoso family – with the exception of former CIO Albert V. Leems – are excited to see this next step in Internet. I’m personally excited to see where I’ll keep all of my new 428 octillion Internet enabled devices."

(In a separate announcement, Contoso announced that Mr. Leems announced has decided to leave the company effective immediately "to spend more time with his family.")

Please note that build-to-build upgrades for the IPv6.1 beta, Release Candidate (RC) or Release to Manufacturing (RTM) will be supported. If you have installed the beta or RC of SP1, you must uninstall it first and then install the RTM of IPv6.1. Please note that IPv6.1 will not support certain alphanumerical URL key combinations and automatically redirect users to an appropriate forwarding address.

We expect that IPv6.1 will be issued about 12 months after IPv6 day, June 8, 2011.

Tags: Windows, Microsoft, IPv6, IPv4

Delicious Bookmark this on Delicious Bookmark and Share

Also available via


Post: Configuring IPv6 addresses on Windows 7 and Windows Server 2008

Of interest is Rand Morimoto post today on IPv6 Static Addressing and DNSv6, with details on configuring IPv6 addresses on Windows 7 and Windows Server 2008. In this blog post, Rand covers…

  • How to statically address a Windows 2008 / Windows 2008 R2 Server
  • How to statically address a Windows 7 Client System
  • How to setup DNS for IPv6 on a Windows 2008 R2 Server to do name resolution of IPv6 systems


Tags: Windows, Microsoft, IPv6, IPv4, Windows 7, Windows Server 2008

Delicious Bookmark this on Delicious Bookmark and Share

Also available via