Industry Trends

Domain Collision in a World of .guru and .ninja

by Jim Tricarico  • 

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.”

Today’s common gTLDs:
‘.com’ – ‘.net’ – ‘.org’ – ‘.edu’ – ‘.mil’ – ‘.gov’ – ‘.int’ ‘.biz’ – ‘.info’ – ‘.coop’ – ‘.pro’ – ‘.aero’ – ‘.museum’ – ‘.name’ ‘.travel’ – ‘.tel’ – ‘.asia’ – ‘.post’ – ‘.mobi’ – ‘.jobs’ – ‘.cat’ – ‘.xxx’

“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.

For more information on what to look out for and how to prevent domain collision with new gTLDs, you can read ICANN’s Guide to Name Collision Identification and Mitigation for IT Professionals.

Photo credit: chrishusein

Find out more about ServInt solutions

Starting at $69

Comments
  1. Domain Collision and new gTLDs described in a nutshell. http://t.co/Zx7LI0Z6I6
    NewDomainsSedo /
  2. Newly released generic top-level domains could break your internal network. Learn what you can do prevent it. http://t.co/DF869M4O9q
  3. Are you ready for .guru and .ninja? #DomainCollision in this week's #TechBench. http://t.co/DF869M4O9q
Start the conversation

Jim Tricarico

Jim Tricarico

Director of Managed Services, ServInt

Jim Tricarico joined ServInt in 2003 as a technician in ServInt’s Managed Services team. Tricarico played an active role in the development of ServInt’s VPS and SuperVPS product lines. In 2010, after years of leadership within ServInt’s support division, Jim moved up to lead ServInt’s customer support function as Director of Managed Services, a position he still holds today.

  • The New York Times
  • The Hill
  • Bloomberg
  • The Seattle Times
  • Computer World
  • Ars Technica
  • MSNBC