Skip to main content

NGPC Resolution for Addressing the Consequences of Name Collisions

At its 18 May 2013 meeting, the ICANN Board adopted a resolution to commission a study to identify the levels of potential impact posed by each applied-for new gTLD on the use of TLDs that are not currently delegated at the root level of the public DNS.

The study, "Name Collision in the DNS," together with a proposal to manage the risks identified in the study, was published for public comment from 5 August 2013 to 17 September 2013. During the public comment period, 75 comments were received. Based on the public comments, staff updated the proposal to manage the risks identified in the study. The report of these public comments is available at:

The ICANN Board New gTLD Program Committee (NGPC) met on 28 September 2013 to review and discuss a proposal on how to deal with name collisions. On 7 October 2013, the NGPC met again and approved an updated proposal, titled "New gTLD Collision Occurrence Management Plan," [PDF, 840 KB] to mitigate the risks of potential name collisions caused by the introduction of new gTLDs.

The Collision Occurrence Management Plan directs staff to undertake an additional study to develop a name collision occurrence management framework. The framework will include appropriate parameters and processes to assess both probability and severity of harm resulting from the occurrence of name collisions. Examples of the parameters might include number of DNS requests, type of DNS requests, type of queries, diversity of query source and appearances in internal name certificates. The framework will specify a set of collision occurrence assessments and corresponding mitigation measures, if any, that ICANN or TLD applicants may need to implement per second level domain name (SLD) seen in the "day in the life of the Internet" (DITL) dataset.

Additionally, the plan provides a registry operator with the option to proceed to delegation prior to receiving its SLD collision occurrence assessment report (subject to established processes and procedures). If the registry operator chooses this alternative path to delegation, it must initially block all SLDs that appear in the DITL dataset while the assessment is conducted.

An additional feature of the plan requires establishment of a process by each TLD operator to enable an affected party(ies) to report and request the blocking of an SLD that causes demonstrably severe harm as a consequence of name collision occurrences. This process is intended to mitigate the risk that collision occurrences from additional SLDs not observed in the study dataset could have severe impact.

The plan also includes an outreach campaign targeted to potentially affected parties to help them identify and manage the origins (causes) of name collision occurrences in their networks. As part of the outreach campaign, ICANN, under the direction of the President and CEO, will invite and collaborate with relevant parties and members of the community that share the same interest in making progress in this issue.

At its 7 October meeting, the NGPC also recommended to the ICANN Board that the issue of name collisions be monitored by the Board's Risk Committee and reviewed periodically, and that ICANN work with the community in developing a long-term plan to retain and measure root-server data.

For more information about the NGPC, please visit:

More Announcements
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"""" is not an IDN."