Skip to main content
Resources

Name Collision Occurrence Mitigation for New ccTLDs

This page is available in:

Name Collision | Guide to Name Collision Identification and Mitigation for IT Professionals | FAQs: Name Collision Identification and Mitigation for IT Professionals | Name Collision Occurrence Mitigation for New ccTLDs | FAQs: Name Collision Occurrence Management Framework for Registries | Report a Name Collision

ICANN's mission and core values call for ICANN to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet's system of unique identifiers (names, IP numbers and protocol parameters)1. In pursuing this mission and values and following the direction of its Board of Directors as well as taking into consideration the advice of the Security and Stability Advisory Committee, ICANN has been working on understanding and mitigating issues related to "name collisions" in the Domain Name System (DNS).

A name collision occurs when a resource name that is intended to be resolved in one naming system is inadvertently resolved in a different naming system, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient.

In accordance with ICANN's "New gTLD Collision Occurrence Management" plan <https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-1-07oct13-en.pdf> [PDF, 840 KB] and "Name Collision Occurrence Management Framework" <https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 635 KB], ICANN has requested certain measures be implemented by new generic top-level domain (gTLD) operators from the 2012 round in order to help mitigate name collision risks.

The risks of name collision are not exclusive to new gTLDs and may present in both ASCII and IDN new country code top-level domains (ccTLDs). In order to help mitigate name collision risks under your future new ccTLD, ICANN strongly recommends the following measures:

For a period of at least 90 days, the new-ccTLD manager should implement continuous Controlled Interruption inserting the following records into the ccTLD zone (substituting "TLD" with the your new ccTLD string):

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

As discussed in SAC0152, the use of wildcard records in DNS is not recommended by ICANN for domain names that offer registration to third parties. Therefore, no names should be registered or, at least, not activated under the TLD until after the 90-day controlled interruption period has been completed. For more information regarding the use of wildcard records, please see <https://archive.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf> [PDF, 227 KB]

Managers of new ccTLDs are recommended to have a name collision reporting mechanism to act upon cases of severe harm caused by name collision for, at least, the early days of the life of the new ccTLD's operation (please see for example <https://forms.icann.org/en/help/name-collision/report-problems>). Examples of measures that may be taken would include: removal of wildcard records from DNS during the controlled interruption period; removal of a second-level domain name from the DNS; and in extreme cases, removal of the TLD itself from the root zone (e.g., in case of harm caused by the TLD itself – dotless name – during the controlled interruption period). Note that these measures are only intended to be temporary while the affected party effects changes in their network configuration to avoid future harm.

ICANN is fully committed to the delegation of new gTLDs in accordance with its mission and core values. ICANN appreciates your consideration of this issue and stands ready for further collaboration if requested.

1 https://www.icann.org/resources/pages/bylaws-2012-02-25-en, Article I

2 https://www.icann.org/resources/pages/sac-015-2012-02-25-en

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