Skip to main content
Resources

Frequently Asked Questions: Name Collision for IT Professionals

Introduction
Susceptible Parties, Effects & Risks
Risk Mitigation & Troubleshooting
ICANN's Role
Controlled Interruption & 127.0.53.53


Introduction

What is a name collision?

A name collision occurs when an attempt to resolve a name that is used in a private name space (e.g. under a non-delegated top-level domain (TLD) or a short, unqualified name) results in the resolution of a DNS query to the public domain name system (DNS). For an analogy, consider calling for "Mary" in your office where there's only one "Mary", and then calling out "Mary" in a shopping mall and expecting that "office Mary" will respond.

Circumstances like these, where the administrative boundaries of private and public namespaces overlap and create name resolution uncertainty and should be avoided where possible.

Is name collision a new issue?

Name collision occurrences are not new. Though observed throughout the history of the Internet, queries for un-delegated TLDs at the root level of the DNS [PDF, 507 KB], have received renewed attention because certain applied-for new TLD strings could be identical to name labels used in private networks.

Top

Susceptible Parties, Effects & Risks

Could my organization/company network be affected by name collision?

Studies have shown that it's unlikely that name collisions will affect significant numbers of corporate networks or Internet users. In a well-managed environment, the likelihood for name collision is low and the likelihood that a name collision could result in material damage is even lower as, chances are, disruptions will be noticed quite quickly. Without proper network management, however, there is a risk.

Do name collisions represent a significant risk?

A study on namespace collisions in the global Internet Domain Name System (DNS) namespace, conducted by JAS Global Advisors, indicated that the addition of new top-level domains (TLDs) does not fundamentally or significantly increase or change the risks associated with DNS namespace collisions. The modalities, risks, and etiologies of the inevitable DNS namespace collisions in new TLD namespaces will resemble the collisions that already occur routinely in the other parts of the DNS.

Top

Risk Mitigation & Troubleshooting

How can system administrators prevent name collision?

ICANN's Guide to Name Collision Identification and Mitigation for IT Professionals (version 1.1) [PDF, 476 KB] recommends that every organization that is not already using fully qualified domain names (FQDNs) from the public DNS should consider the following strategy:

  • Monitor name services, compile a list of private TLDs or short unqualified names you use internally, and compare the list you create against the list of applied-for new TLD strings.
  • Formulate a plan to mitigate causes of leakage; for example, you may need to change the root of your private name space to use a name you have registered in the global DNS, or change affected systems over to use FQDNs.
  • Prepare users for the impending change in name usage by notifying them in advance or providing training.
  • Implement a plan to mitigate the potential collision.
  • Continue to monitor old private name usage as well as new FQDN usage at name servers and along your network perimeter, and use these data to mitigate any causes you may discover once you've begun mitigating leaks..

How should a system administrator address name collision once it has been identified?

System administrators that encounter a system error due to name collision are encouraged to take the following steps:

  1. Report the problem to ICANN »
    Instances where there is a reasonable belief of demonstrable, severe harm as a consequence of a name collision should be reported.
  2. Read the Guide to Name Collision Identification and Mitigation for IT Professionals (version 1.1) [PDF, 476 KB] and implement the measures outlined therein.
  3. Learn more about name collision by visiting https://www.icann.org/namecollision.
  4. Spread the word about the potential for name collision occurrence and mitigation in your professional circle.

Top

ICANN's Role

Why is ICANN involved in name collision mitigation?

Name collision occurrences have received renewed attention because many new top-level domain strings applied-for through ICANN's New gTLD Program are identical to name space labels used in private networks. ICANN's core focus is supporting a secure, stable and resilient Internet. Determining the risk and severity of potential name collision, and proposing means of mitigating risk became of great importance.

In a study published in January 2013, ICANN's Security and Stability Advisory Committee (SSAC) confirmed that that some private namespaces sometimes "leak" into the public DNS (either through misconfiguration or the use of old software). ICANN's Board of Directors, staff and the Internet community, set out to address name collision together. ICANN considers it essential that it does everything possible to minimize potential impact and to offer clear advice on dealing with the issue.

What has ICANN done to address name collision?

ICANN has taken several steps to address name collision including commissioning an independent report on mitigating name collisions, issuing advice to IT professionals worldwide on how to proactively identify and manage private name space leakage into the public DNS, and conducting an outreach campaign to raise awareness of the potential issue of name collision.

In addition, in 2014 August ICANN released the Name Collision Occurrence Management Framework [PDF, 634 KB], which is a set of requirements developed to manage the name collision occurrences between new gTLDs and existing private use of the same strings. The framework was developed with input from many sources including the Internet community, a report published by JAS Global Advisors LLC, and the Security and Stability Advisory Committee.

For additional information on how ICANN has worked to address name collision, read the following:

Top

Controlled Interruption & 127.0.53.53

What is Controlled Interruption?

Controlled interruption is a method of notifying system administrators who have configured their networks incorrectly (knowingly or unknowingly) of the namespace collision issue, and helping them mitigate potential issues.

Controlled interruption is intended to catch errant DNS queries. When an errant query is caught, a registry takes a "controlled" action to prevent harm and alert the user that a fix is needed. That action takes the form of responding to the DNS query with a special IP address (127.0.53.53). The word "interruption" refers to an activity that once seemed to work despite the errant query, but is now prevented from working.

System administrators affected by a new gTLD registry performing controlled interruption might encounter the following "flags":

  • * 3600 IN MX 10 your-dns-needs-immediate-attention.<TLD>.
  • * 3600 IN SRV 10 10 0 your-dns-needs-immediate-attention.<TLD>.
  • * 3600 IN TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision"

What is 127.0.53.53?

127.0.53.53 is a special IPv4 address that will appear in system logs alerting system administrators that there is a potential name collision issue, enabling a quick diagnosis and remediation. The "53" is used as a mnemonic to indicate a DNS-related problem owing to the use of network port 53 for the DNS service. Instances where there is a reasonable belief of demonstrable severe harm as a consequence of a name collision should be reported at https://forms.icann.org/en/help/name-collision/report-problems. Additional information on name collision can be found at https://www.icann.org/namecollision.

I've encountered 127.0.53.53 (or another flag) in my system logs – what should I do now?

System administrators who encounter a system error due to name collision are encouraged to take the following steps:

  1. Report the problem to ICANN »
    Instances where there is a reasonable belief of demonstrable, severe harm as a consequence of a name collision should be reported.
  2. Read the Guide to Name Collision Identification and Mitigation for IT Professionals (version 1.1) [PDF, 476 KB] and implement the measures outlined therein.
  3. Learn more about name collision by visiting https://www.icann.org/namecollision.
  4. Spread the word about the potential for name collision occurrence and mitigation in your professional circle.

Top

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."