Domain Collision in a World of .guru and .ninja

March 10, 2014

Since 2004 there have been only 22 common generic top-level domains (gTLDs) for use on the Internet. One of the side effects of this is the proliferation of startups with weird mishmashes of letters for names. In the coming months, there will be over 1000 new gTLDs made available to the public. Over 100 are already out there, including .wiki, .support and even .ninja.

gTLDs are issued by ICANN after an application process, and once approved they are added to what’s called the global DNS. In 2012, ICANN closed the application process on new gTLDs to add to that pool. You can see the list of what’s been issued and how many domains have been bought here.

As a responsible web hosting provider, we need to prepare for anything that might break or change as a result of the new gTLD process. And indeed, there’s an issue that might cause things to break as a result of new gTLDs being issued. It’s called “domain collision.”

“Domain collision” in a nutshell

Each gTLD that gets issued carries with it the possibility of damaging legacy internal network based systems if they were not developed using certain established best practices. The traditional standard practice has been to either use Internet addresses that are owned by the groups for whom the systems are built (Fully Qualified Domain Names or FQDNs), or to use “localhost” based address systems. If every system designer used an FQDN in their system and resolved them from the global DNS, there would be no domain collision issue. However, the Internet has not evolved this way. As such, many legacy systems have been built that utilize naming conventions for internal network systems that may soon be delegated into the global DNS.

Name collision occurs when systems unknowingly access a name that has been delegated in the global DNS when the user’s intent was to access a resource identified by the same name in a private network. This happens most frequently when a “second level” delegation gets added into the DNS (e.g. my.mail).

The Internet is designed to query the DNS and then the internal network. Let’s take the example of “my.mail” to show how systems might break as gTLDs get released. Imagine a developer wrote their internal network to access their mail program using the domain my.mail. If .mail becomes released into the global DNS — .email already has — the internal network of the developer would break once the domain my.mail is registered and added to the global DNS.

It is difficult to assess which of the world’s systems were built without attention to the development practices defined above. Therefore, we don’t really know what systems will break. As providers like ServInt will likely get calls into their customer service centers when things go awry, they need to be prepared to identify and mitigate these issues when they occur. As some systems likely to be affected will be old, legacy systems, solutions may not be simple or quick to implement.

What you can do

Prevention is simple. Ensure that your internal network is built using only FQDN standards, and not localhost-based addresses.