Skip to main content

Moving Forward with Delegation of Top-Level Domains

By Jeff Moss and John L. Crain

ICANN’s New gTLD Program Committee (NGPC) has approved resolutions allowing us to move forward in expanding the Internet’s name space while mitigating possible issues in the expansion.

A document describing the mitigation plan can be found here [PDF, 841 KB].

It’s an understatement to say that ICANN takes its obligation to preserve the Security, Stability and Resiliency (SSR) of the Identifier Systems seriously. In fact, that part of our mission is the very first thing you read in ICANN’s bylaws.

In recent months, concerns have been raised that there will be “collisions” between some of the proposed new TLD strings and those used in private name spaces. The possibility that collisions can occur in the DNS is not new. Queries for non-existing strings are currently a common occurrence throughout the DNS. They can be caused by simple typos, errors in configuration, and historic or recommended use of certain names for intranet applications. The DNS is often queried to resolve such names and this “leakage” of queries from private spaces occurs at rather remarkable volumes.

At the Board’s direction, ICANN staff commissioned a study to examine the extent of the name collision problem and to look at possible methods for mitigating the risks.

As has been noted by many community members, it is much easier to observe the occurrences of collisions than it is to assess the potential impact of a collision.

DNS data collected at the root and elsewhere reveals some interesting information about queries for the proposed new TLD strings. But to assess the precise impact of these occurrences, there needs to be additional study which would allow us to learn quite a bit more about the extent of these occurrences and to determine which strings appear most often in queries.  Ultimately, the additional study will allow us to develop targeted mitigation strategies.

The basic concept of the risk mitigation plan adopted by the NGPC is fourfold:

  • First, to document on a per TLD basis those collisions that have been identified in studies of the “Day In The Life of the Internet” (DITL) data and to place each of the Secondary Level Domain (SLD) strings identified to have had collisions on a reserved or blocked list for that specific TLD. These strings will not be allowed to be registered or to resolve until such a time as the effects of the specific collision are known and appropriate mitigation strategies are developed and implemented.
  • Second, ICANN will develop a process by which affected parties may report and request the blocking of a SLD that causes demonstrable harm as a consequence of a name collision. This process is intended to mitigate the risk of harmful collision occurrences not observed in the study.
  • Third, ICANN will develop a framework to identify the probability and severity of harm to better assess the consequences of name collisions. Remember that harm and risk are not the same thing. This framework will be an important tool in identifying the likelihood of harm but also for helping to identify mitigation techniques. Once acceptable mitigations are in place it may be possible to allow the release of strings from the list of reserved or blocked names.
  • Finally, promoting awareness and mitigation strategies through a targeted outreach campaign will help potentially affected parties identify and manage the causes of name collision occurrences arising from their own networks.

We believe the proposals outlined above afford a balanced way of moving forward. The plan minimizes the risk that collisions will cause serious harm by implementing measures to avert the problem by mitigating the associated risks and continuously monitoring the situation.

We would like to thank those who have submitted research, comments, and feedback on real world examples of name collisions. The community efforts have shown that we can put aside our self-interest, consider a complex problem and drive toward solutions to meet our common objective – ensuring that the Domain Name System continues to provide services to all users in a secure, stable and resilient manner while still allowing it to grow and innovate.

Comments

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