Well more than a year ago, ICANN’s Security and Stability Advisory Committee published SSAC 053, its paper on single-label domain names—now referred to in the community as “dotless” domains—advising against their use.

In a robust comment period, the community weighed in on the utility and safety of dotless domains, with some in favor and some opposed. To address the matter, ICANN has commissioned further study of the issue with an eye toward resolving the issue for new gTLD applicants.

The missing element, as Donuts outlined in its own comment, for prohibition of dotless domains is strong technical justification for such a move. It simply was absent from the SSAC report. Since then, however, dotless domains have come under fire from additional corners, and the attacks are likely competitively motivated.

SSAC 053

In its original paper, SSAC said it found “that dotless domains would not always work as expected given current DNS implementations and existing application behavior. In particular, SSAC finds that the way in which domain names are interpreted in different contexts would lead to unpredictable and unexpected dotless domain behavior.”

The root of the issue, says the SSAC, is that in a dotless environment, you take away a level of certainty for the end-user. Take away the dot, users get misdirected, traffic “escapes,” some level of chaos ensues, they said.

The Rest of the Story

In its comment, Donuts looked to put a reasonable rest to these claims. We pointed out:

1. The varying treatment of dotless domains by applications and operating systems is due to those applications making assumptions about user intent. If some applications and systems aren’t using the DNS to resolve domain names, they should be, as that is the convention on the Internet. Dotless domain names are in fact domain names. The application (or OS) should always ask the DNS (whether it’s unsure or not) and if it gets a “non-existent” answer, then it may perform further processing on the name.

2. DNS resource records enabling dotless domain functionality have existed or do exist in some 16 ccTLDs and do not appear to have caused stability and security problems as a result. A current, working example of a dotless domain in use is http://uz/.

3. There would be no sudden or profound changes in user experience as a result of dotless domains because if some operating systems continue to ignore them, no change will occur to those users if more dotless domains are introduced.

4. Dotless domains provide important benefits to consumers. Dotless domains provide innovative navigation, strong branding benefits, and additional security, stability, consistency and trust.

5. This same “some software is implemented in a non-standard way” argument could have been made to prohibit the introduction of TLDs longer than three characters, such as .info, or IDN TLDs. They were introduced anyway and do not contribute to instability or insecurity.

User Intent, FQDNs and the Invisible Trailing Dot

The issue about user intent is most important and is the crux of this issue.

Users who type “www.example.TLD” into a browser intend to go somewhere specific. Operating systems pass this on to DNS as is. Resolvers simply append a dot to make it a fully qualified domain name (or FQDN, which is distinguished by its lack of ambiguity). Each label in the name specifies a node in the DNS hierarchy and can be interpreted only one way.

It is widely socialized to general Internet users to leave off the trailing dot. Leaving off the trailing dot makes every DNS query potentially ambiguous, so resolvers add the trailing dot to make the name fully qualified and attempt resolution. This is a form of assumption on the parts of both the operating system (or the DNS) about the user’s intent. Appending search suffixes is another assumption made to determine intent.

Resolving a dotless domain using standard DNS begins building behavior much closer to what the address bar (or other programs that use domain names) intends to do: convert strings to IP addresses. If a string is typed into an address bar of a browser and it contains only permissible characters for domain names, it should be presumed to be a domain name by the underlying operating system and browser, and not appended with other strings by intermediaries such as the operating system provider, the browser manufacturer, the ISP, local governments, etc. The only permissible appended string is the implicit root dot to form a FQDN. The string should be presented to the DNS as-is first, and if it resolves, the browser must go to that address. If it does not resolve, then and only then MAY local suffixes be applied and attempted, but only if their use was authorized by the user (or local network administrator).

For example, on a Microsoft operating system, suppose “printer” were a string and the operating system was configured by the user with the following search suffixes:

legal.wa.local

accounting.wa.example.

The OS would attempt to look up the following domain names in the DNS (in order):

1. printer.legal.wa.local.

2. printer.wa.local.

3. printer.accounting.wa.example.

4. printer.wa.example.

The OS is attempting to infer the user’s intent and “devolve”—move from something more specific and longer to something less specific and shorter. The current Microsoft OS does not attempt the step below that was the original intent (in this example):

5. printer.

If the string does not resolve, the browser (if that is the program being used) is free to do a search in the default search engine to further assist its user.

By NOT attempting to resolve with the root dot, Microsoft effectively (not actually) has appended its own suffix string, which results in navigation to a property Microsoft profits from in many cases. User reaction to the appending of bing.com to example.com (which is what effectively happens when it chooses to do a search on “printer”) would probably not be particularly good.

So Microsoft’s current OS never adds a trailing dot to “printer”. Linux, on the other hand, does attempt to resolve “printer” by adding a trailing dot and submitting that to the DNS.

With dotless support, the Internet community can begin to create a consistent, unified behavior.

Competitive motivations

New comments now seem to indicate motivation, for competitive reasons, to do away with dotless domains before they arrive for new TLDs. Microsoft recently submitted a detailed comment on dotless, warning about perceived danger. The issue perhaps is otherwise. Microsoft’s latest operating system does not treat TLDs as domain names even though they clearly are. Other operating systems (like Linux), which are not affiliated with search engines, check the dotless domain name first in the DNS, without appending anything the user did not type in.

In Microsoft Windows, either the dotless domain runs a search or appends a suffix. In no case is the dotless domain looked up using the DNS. Any browser run on this OS performs this way. Very few browsers or other clients append any string at all, and so in a default case, the browser (again, any browser on this OS) is directed to Bing where a search on the dotless domain is performed.

By choosing not to attempt resolution of a dotless domain, Microsoft is choosing self-interest over best attempts at using the DNS to actually get the user to a destination the user is most likely to have intended. Rather, Microsoft can control the user experience by not resolving a dotless domain and sending a user to a monetized search page.

Other operating systems don’t behave this way. They operate in a more consistent and predictable way by consulting the DNS first then they use other means to judge the user’s intent instead of skipping over these steps in favor of alternate search.

The issue turns to what is the user intent when no dots are present in a string. No RFC addresses resolution “order of operations” and because of this, browsers and operating systems are free to append anything, even if there ARE dots present. Allowing individual DNS clients to establish behavior for handling a dotless query leads to an inconsistent experience—but resolution of dotless domains leads to more consistent, standardized behavior, which increases security and stability.

If example.com is a domain name by the IETF specification (since all operating systems add the trailing dot in this case) then a dotless domain name is also a domain name. The question is, does ICANN allow increased innovation and user benefits by inserting “A” records for certain TLDs on a case-by-case basis, or forever cede authority over this part of the DNS to Microsoft and others who collect and monetize that traffic by directing it to their default search engines?

If ICANN cedes this part of the DNS, it sets a major precedent. What’s to stop Microsoft from extending it to appending non-user input “search suffixes” to the end of, for example, “google.com” or any other domain name? As in dotless domains, there is no IETF spec that says they can’t, only pushback from ICANN and the DNS community.

Other search provider input

Yahoo and Google have made their thoughts known as well.

Google agrees that dotless domains are beneficial and present minimal risk. In fact, dotless is part of their application for .SEARCH. A dotless, Google-run .SEARCH in fact would not create ambiguity or confusion. It again reduces ambiguity by introducing consistent behavior for DNS clients without individual client implementations having to each guess the user’s intent. It would begin to form a standard resolution order of operations that the industry can then formalize.

Microsoft disagrees, based on other interests:

“Allowing Google to extend its current dominance in search and search advertising to the .search gTLD will result in serious harm to competition globally in search and search advertising. The .search gTLD has the potential to become a significant chokepoint for Internet search queries. Google states that acquiring the .search gTLD will “make it easier for users to identify and make use of search funct[ionality] on the Internet” as controlled by Google.”

“Further, any effort by Google to leverage its existing dominance in search and search advertising to funnel users to its .search gTLD would quickly create awareness among hundreds of millions—if not billions—of Internet users.”

Further, Microsoft has elicited participation from Yahoo, which depends on Microsoft for search revenue, in its effort.

Yahoo claims that internal networks would be affected by dotless domains but corporations have full control over internal name resolution and corporate networks are generally configured to attempt resolution internally before external resolution. Their claim, quoting the SSAC report, that dotless domains “would not always work as expected” and “would lead to unexpected dotless domain behavior” already happens from operating system to operating system, client to client. Google’s dotless domain proposal would bring standardization and order to an already unstandardized mechanism, perhaps driving for new standards to be authored by the community.

RFC1123

The argument that dotless domains are prohibited by the Applicant Guidebook (AGB) is off base. Why? Because of RFC1123.

Internet Standard RFC1123, written in 1989, recommends implementations require two or more interior dots but in practice, a significant portion of the Internet resolves with a single interior dot. Also, RFC1123 has been clarified by RFC2181, which states “Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.” In fact, according to RFC2181, the only restriction on domain names has to do with the length of labels and the overall length, not the composition of the name.

RFC1035 2.3.1 (Preferred name syntax) does not mandate domains must contain a dot. Minimally, a single label must begin and end with alpha-numeric characters, including a dash, and must be 63 characters or less.

These RFC requirements regarding TLDs are in the AGB. The AGB allows dotless domains because the RFC specs allow them.

Handling Dotless Consideration (RSEP)

In its comment, Donuts said that while the SSAC053 report “might be viewed as addressing an arcane technical issue…in fact the subject involves potential registry services that deserve and require other inputs.” We advocated, and still advocate, use of ICANN’s RSEP function as the mechanism for evaluating registry proposals such as dotless domains.

Conclusion

ICANN must oppose companies, even large ones such as Microsoft or its partner, Yahoo, from overriding the DNS. ICANN must defend the DNS and new innovative uses of it, and not subjugate and preclude the use of the DNS to other naming schemes.