FYI Wolf-Ulrich Moving Forward with Delegation of Top-Level Domains by ICANN Blog on October 9, 2013 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.