ICANN released the  Dotless Domain Name Security and Stability Study Report (pdf) tonight which was prepared by Carve Systems.

Dotless Domains are a big topic of conversation ever since Google announced it wanted to operate the new gTLD .search as a “Dotless Domain”

The bottom line of the report is that technically Dotless domains are possible, but there are some issues which require additional study.  As for User confusion “it seems inappropriate to simply dismiss the option to foster awareness about dotless names. Users could be informed through a variety of means, such as direct software interaction, and traditional marketing efforts. The exact recommendations would depend heavily on the results of the “user confusion” survey, focusing on Internet users.”

Here are the conclusions:

After completing the study on the security and stability impact of dotless domain names, Carve has compiled several recommendations.

During the study, it became clear that most of the application classes studied currently support dotless domain names.

Software that would use dotless names over a private network will also support them over a public network.

Based on the three concerns highlighted in the Executive Summary, namespace collision, user confusion, and technology confusion, Carve has the following high-level recommendations.

Namespace Collision Recommendations:

In the event that dotless domain names are allowed, Carve suggests that potentially dangerous strings be identified and reserved for use on internal networks only.

The criteria for classifying a dotless string as “dangerous” would be how widely the string is used to resolve internal resources on private networks.

The more a dotless TLD is used across individual private networks, the greater the potential for negative impact in the event the name becomes publicly accessible on the Internet.

One method for generating a list of dangerous strings is to identify DNS requests for dotless names that have leaked to the Internet. Root server data analysis could be used to create a list of leaked dotless names,andthislistcanbefurtheranalyzedbasedonthefrequencythatnamesappear.

The leaking frequency should be taken into consideration during the gTLD approval process to make judgments on a string’s potential impact on private networks. A high frequency would potentially lead to a string being added to a restricted list or carefully controlled via contractual obligations between ICANN and the applicant.

The DNS Operations Analysis and Research Center posted a blog article (https://www.dns- oarc.net/node/314) that contained data describing “single label” strings that leaked to public DNS servers.

A more structured analysis of this data could help to determine what strings should be reserved and/or carry additional risk when used in a dotless fashion. Based on this list, and the “Name Collision in the DNS”3 study, strings such as localhost, lan, internal, corp, home, belkin, etc are all being leaked to public DNS servers at a relatively high frequency compared to other “single label”, or dotless, strings.

User Confusion Recommendations

To address the intranet versus Internet user confusion issue in a less subjective manner, Carve recommends that studies be designed and executed to survey Internet and corporate network users.

Carve recognizes that the logistical challenges of conducting such surveys are not trivial.

However, it is the best path forward that Carve can recommend for understanding the actual impact of dotless names on users.

While the survey of Internet users would potentially focus solely on the user’s interpretation of dotless names, the corporate study could have a less subjective aspect. The corporate study could be conducted with the co-operation of private organizations, and in addition to human surveys, could also take into account the actual use of dotless names on subject private networks. This aspect of the study would take into account an analysis of the subjects DNS zone databases.

Gauging “human readiness” for dotless names is one of the most difficult areas of this study to quantify. A traditional approach to solving problems with end-users is education. Educating users would entail creating awareness of what a dotless name is and what the “rules” are. It is reasonable to assume that non- technical users have developed informal and intuitive rules about what domain names look like and how they work. Dotless names may constitute a substantial change to the average non-technical user.

Based on Carve’s understanding of how information security has evolved over the last decade, it seems inappropriate to simply dismiss the option to foster awareness about dotless names. Users could be informed through a variety of means, such as direct software interaction, and traditional marketing efforts. The exact recommendations would depend heavily on the results of the “user confusion” survey, focusing on Internet users.

Technology Confusion Recommendations

It is not possible for ICANN to individually assess all software components for stability and security concerns related to the potential deployment of dotless names on the Internet. However, ICANN should make available information and recommendations, in the form of open source case studies and white papers, designed to educate the Internet engineering community on the risks associated with creating software that places inherent trust in dotless names.