[http://www.icann.org/images/gradlogo_bow.jpg]<http://www.icann.org/> News Alert http://www.icann.org/en/news/announcements/announcement-03dec13-en.htm ________________________________ New gTLD Collision Occurrence Management Plan Frequently Asked Questions 3 December 2013 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). In pursuing these goals 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 commissioned a study on the potential security impacts of the applied-for new-gTLD strings. The study was to consider whether name collisions might occur between applied-for new gTLD strings and domain names that may be in use in private namespaces ("non-delegated TLDs"). The study was also to review the possibility of name collision occurrences arising from the use of internal names for which X.509 digital certificates have been issued. A name collision occurs when users unknowingly access a name that has been delegated in the public DNS when the user's intent was to access a resource identified by the same name in a private network. Circumstances like these, where the administrative boundaries of private and public namespaces overlap and name resolution yields unintended results, present concerns and should be avoided if possible. However, the collision occurrences themselves are not the concern, but whether such collisions cause unexpected behavior or harm, the nature of the unexpected behavior or harm and the severity of consequence. On 5 August 2013, ICANN published and made available a name collision study <http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.p...> [PDF, 3.34 MB] (the "Study") that identifies categories of strings according to the occurrences of queries, as observed in root server log samples obtained from the "Day in the Life of the Internet" (DITL) initiative from DNS-OARC. The Study used as input: 1) samples of DNS requests transmitted to root servers (from the DITL initiative), complemented with 2) information from Certificate Authorities regarding the issuance of internal name certificates (e.g., TLS/SSL certificates for non-delegated names). A full description of the methodology of the Study can be found in section 3.4 of the Study. The Study also included options to mitigate the risks; however, it did not make specific recommendations for each of the categories. Based on the Study, ICANN staff published for public comment from 5 August to 17 September 2013 <http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigati...> [PDF, 166 KB] a proposal to manage the risk of name collision. On 7 October 2013, the ICANN Board New gTLD Program Committee adopted a revised proposal <http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-07oct13-...> that describes a plan to manage name collision occurrences between new gTLDs and existing private uses of the same strings. The below are frequently issued questions that have been asked regarding the plan and ICANN's answers. 1. How did ICANN compile the list of Second-Level Domain Names (SLDs) to block for the Alternate Path to Delegation? For each TLD its list of SLDs to block is composed of the SLDs that were queried for the TLD during the DITL samples of 2006 to 2013, and the 2010 DNSSEC rollout datasets. 2. What were the criteria used to consider a new gTLD ineligible for the Alternate Path to Delegation? Those new gTLDs that showed an outlier behavior in terms of additions to their list of queried SLDs from year to year were considered ineligible. In other words, ICANN considers a new TLD ineligible for the Alternate Path to Delegation in cases where the list of SLDs changes frequently and widely. The sources of data used to compile the variation in SLD lists are composed of yearly captures of DNS query data from 2006 to 2012. The 2013 dataset was not included since the strings were already known by then (and various activities or studies conducted on the known strings might bias any analysis). For these strings, the year-over-year increase of the number of SLDs queried is an outlier as compared to the population of proposed gTLDs in: (a) at least one of the year-to-year comparisons, and (b) 2012 (indicates churn is currently occurring). For example, a TLD that only is an outlier in the 2006-2007 comparisons will still be considered eligible. However, a TLD that is an outlier in the 2009-2010 and in the 2011-2012 comparisons will not be eligible for the alternate path to delegation. 3. Will the second-level-domain-name (SLD) block list be amended as a result of using other datasets while working on the Name Collision Occurrence Management Framework? There is no plan to amend the SLD block list for new gTLDs as a result of the development of the Framework. However, if there were a new discovery during the development of the Framework it will be taken into consideration. 4. Is source code for the creation of the block lists available? The process to create the blocking list is explained in detail in each of the Alternate Path to Delegation reports for every new gTLD that has signed an agreement and is considered eligible. For example see http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report... The code used to create the lists is based on the code published at https://github.com/JASdevteam/dns-oarc 5. How long should the SLDs in the block list be blocked? The blocking should be in effect until the mitigation measures described in the respective Name Collision Occurrence Assessment have been applied. 6. For a particular TLD, if the SLD "nic" appears in the DITL data (indicating that there might be a name collision issue there), why is "nic" allowed in the gTLD, and why is this risk more acceptable than the risk of any other name collision? The only name that is required to be used by contract is "whois.nic.<tld>" for the purpose of offering registry WHOIS service, i.e., "whois.nic.<tld>". Balancing the risk of using this name with the usability of having the WHOIS service available at a well-known location, ICANN decided to not include "nic" in the list of SLDs to be blocked by any new gTLD. However, the name collision response mechanism <http://www.icann.org/en/help/name-collision> is available to be used by an affected party to report significant harm caused by such domain name. Also note that the name is only available to the registry operator itself, which means that the registry has total control over the SLD. 7. Is ICANN going to update the list of blocked SLDs to include the year in which the names were queried? ICANN does not plan to update the list of blocked SLDs or to add the year in which the SLDs were queried. However, if there is interest from the community ICANN will consider adding this data when resources are available. 8. What should be done with the names in the SLD block list when they are released in regards to TMCH Sunrise and Claims? Names in the SLD block list for a TLD must be included in the Sunrise and Claims, subject to the registry's usual policies, but cannot be activated until the mitigation measures have been implemented. If a registry operator allocates names from the SLD block list during Sunrise or Claims period, it must inform the registrant that the name cannot be activated and may never be activated subject to the TLD's Name Collision Occurrence Assessment. This is a clarification to the language in section 3.2 of the Name Collision Occurrence Management Plan. The intention of the block list is to retain the behavior before a new gTLD is delegated (i.e., an NXDOMAIN response in DNS); that result is achieved by not activating the names in the list, irrespective of allocation. 9. What constitutes harm that warrants deactivation of a second-level domain name causing collisions? It is possible that name collision occurrences of some second-level names that did not appear in the dataset used for the SLD block list might occur after the applied-for gTLD begins operation. To mitigate this risk, ICANN has implemented a process to enable an affected party to report and request the temporary blocking of a recently activated domain name that causes demonstrably severe harm as a consequence of name collision. ICANN will act as the initial single point of contact for these reports, and will coordinate the notification with the relevant registry operator to ensure that the report is acted upon in an expedited manner. The assessment of harm will initially be done by ICANN in a case-by-case basis until the work on the Framework defines uniform criteria. 10. Is there going to be a name collision portal? ICANN is planning a portal to display the information available on this topic. 11. Are different types of trial delegations within the scope of the Name Collision Occurrence Management Framework? Yes, trial delegations at both TLD level (for the TLDs not eligible for the alternate path to delegation), and at the second level for SLDs under all new gTLDs, are going to be considered during the development of the Framework. If adopted, it is expected that the Framework will specify the trial delegation applicable for a particular type of collision. Additionally, during its meeting in Buenos Aires the ICANN Board passed a resolution directing staff to evaluate SSAC's SAC 062 recommendations, which explicitly asks for ICANN to consider trial delegations. 12. What is the process to consider the work being done to develop a Name Collision Occurrence Management Framework and decide whether to adopt it? The lead contractor is expected to work on a draft Framework in cooperation with the community as explained at <http://www.icann.org/en/news/announcements/announcement-2-11nov13-en.htm>. The draft Framework is then going to be published for public comment. After the public comment period has ended, comments will be summarized and the draft Framework will be updated based on public input. Finally, the New gTLD Program Committee of the ICANN Board will consider the final Framework for adoption. 13. Where can people participate in the development of the Name Collision Occurrence Management Framework? Anyone is welcome to participate in the development of the Framework. The Framework will be discussed in the public mailing list at <https://lists.dns-oarc.net/mailman/listinfo/collisions>. 14. Is the management of name collisions going to be extended to ccTLDs? The issue of name collisions was first reported to ICANN in reference to the new gTLD program. Given the number of new gTLDs that are expected, the priority of the work has been focused on new gTLDs. We recognize the issue is not unique to gTLDs; therefore ICANN is raising this issue with the Board Risk Committee to identify how to address this issue.