Skip to main content

Addressing the Consequences of Name Collisions

As directed by the ICANN Board of Directors on 18 May 2013, ICANN commissioned and today releases the results of a study that considers the likelihood and impact of name space collisions between applied-for new gTLD strings and non-delegated TLDs. Additionally, the study also reviewed the possibility of collisions arising from the use of X.509 digital certificates.

Background: In a study published in January 2013, ICANN's Security and Stability Advisory Committee (SSAC) identified fact that some certificate authorities issue X.509 certificates for domain names that are not resolvable in the public DNS. Such issues identified in SAC 057, as well as in SAC 045, are symptoms of entities that have local environments that include strong assumptions about the number of top-level domains and/or have introduced local top-level domains in private namespaces that may conflict with names yet to be allocated. These private namespaces sometimes "leak" into the public DNS (either through misconfiguration or the use of old software), meaning that requests for resources on private networks could end up querying the public-facing DNS Root Servers and hence "colliding" with the delegated new gTLD.

The Study: On 18 May 2013, the ICANN Board approved a resolution calling for a detailed study of the name collision issue. ICANN contracted with Interisle Consulting Group, LLC to collect and analyze the necessary data on all applied-for strings.

The resulting study, Name Collision in the DNS [PDF, 3.34 MB], identifies three categories of strings by the potential risk of name space collision:

  • Low Risk: 80% of applied-for strings.
  • Uncalculated Risk: 20% of applied-for strings.
  • High Risk: 2 strings (.home, .corp).

To minimize the likelihood of any impact, ICANN proposes to the community several mitigation measures to be taken as described in an accompanying staff recommendation paper, New gTLD Collision Risk Management [PDF, 166 KB]. They include:

  • Proceeding with contracting and delegation of those strings categorized as "low risk" (80%) but recommending additional mitigation measures which should not materially impact their timeline for delegation.
  • Conducting further study on those strings categorized as "uncalculated risk" (20%) anticipated to take 3-6 months to complete.
  • Delaying contracting and delegation of the two "high risk" strings until mitigation efforts can place them in the "low risk" category.

New gTLD Security and Stability: Throughout the development of the New gTLD program, the security and stability of the Domain Name System has remained the paramount concern of the ICANN community. ICANN staff has prepared an information sheet, Secure and Stable Introduction of new gTLDs [PDF, 102 KB], that describes the measures ICANN has taken to ensure the introduction of new gTLDs will not jeopardize that commitment.

Public Comment: At this time, the mitigation steps outlined in the staff recommendation paper are proposals only and community input is strongly suggested. As a result, ICANN has opened a formal process for soliciting public comment. The form for submitting public comment and the calendar for doing so is available here.

Coordinated Vulnerability Disclosure Process: ICANN takes this opportunity to inform the community that it has updated its risk management procedures for improved reporting and response to any unforeseen issues arising from the delegation of new gTLDs. Members of the community are urged to familiarize themselves with the process available for review here [PDF, 628 KB].

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