Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

  1. Main Agenda
    1. New gTLD Collision Occurrence Management
      1. Rationale for Resolution 2013.10.07.NG01 – 2013.10.07.NG02

 

  1. Main Agenda:

    1. New gTLD Collision Occurrence Management

      Whereas, on 15 March 2013, the ICANN Security and Stability Advisory Committee (SSAC) published SAC 057: SSAC Advisory on Internal Name Certificates.

      Whereas, in response to the overall issues highlighted in SAC 057, the ICANN Board directed the President and CEO, in consultation with the SSAC, to commission a study on the use of TLDs that are not currently delegated at the root level of the public DNS (the "Name Collision Study").

      Whereas, the Name Collision Study, together with a proposal to manage the risks identified in the Name Collision Study (the "Proposal") was published for public comment from 5 August to 17 September. The Proposal has been revised in response to public comments.

      Whereas, the NGPC is undertaking this action pursuant to the authority granted to it by the Board on 10 April 2012, to exercise the ICANN Board's authority for any and all issues that may arise relating to the New gTLD Program.

      Resolved (2013.10.07.NG01), the NGPC directs the President, Generic Domains Division to implement the proposal to manage the occurrence of collisions between new gTLDs and existing private uses of the same strings as presented in the "New gTLD Collision Occurrence Management Plan" attached as Annex 1 [PDF, 840 KB], and in doing so to take into account further advice that may be offered by SSAC and other experts and stakeholders.

      Resolved (2013.10.07.NG02), the NGPC directs the ICANN President and CEO, and as appropriate through the President, Generic Domains Division, to appropriately target the planned outreach campaign.    The NGPC also recommends to the Board that:  (1) the ICANN Board Risk Committee expressly reviews this matter and reports back to the Board, and continues to review and report at regular intervals; (2) the Board directs the ICANN President and CEO to develop a long-term plan to manage name collision at the root; and (3) the Board directs the ICANN President and CEO to work with the community to develop a long-term plan to retain and measure root-server data.

      Rationale for Resolution 2013.10.07.NG01 – 2013.10.07.NG02

      Why the NGPC is addressing the issue now?

      In SAC 057: SSAC Advisory on Internal Name Certificates, the ICANN Security and Stability Advisory Committee (SSAC) identified a Certificate Authority (CA) practice that, if widely exploited, could pose risks to the privacy and integrity of secure Internet communications, and could impact the new gTLD Program. The SSAC thus advised ICANN to take immediate steps to mitigate the risks. The issues identified in SAC 057 are part of a more general category of issues whereby a party uses a domain name in a private network that includes a non-delegated TLD that later becomes delegated into the root as part of the new gTLD Program.

      Previously, the ICANN Board directed the ICANN President and CEO to commission a study on the use of TLDs not currently delegated at the root level of the public DNS. The study would also consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.

      The requested study was commissioned and posted on 5 August 2013 (the "Name Collision Study"). At the same time, a proposal to manage the risks identified in the Name Collision Study was posted for public comment (the "Proposal") until 17 September. At this time, NGPC is considering adopting the Proposal, which was revised in response to public comments. Adoption and implementation of the Proposal will allow ICANN to move forward with the delegation of new gTLDs in a secure and stable manner.

      What are the proposals being considered?

      The Proposal being considered by the NGPC (attached to this resolution as Annex 1) presents a plan to manage the collision occurrences between new gTLDs and existing private uses of the same strings. The Proposal has been updated in response to community feedback during the public comment forum. A core feature of the updated Proposal includes undertaking 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.

      The proposal 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 Proposal recommends a process to enable an affected party(ies) to report and request the blocking of a SLD that causes demonstrably severe harm as a consequence of name collision occurrences. This process is intended to mitigate the risk that collision occurrences not observed in the study dataset could have severe impact.

      Lastly, the Proposal describes 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 would invite and collaborate with other parties and members of the community that share the same interest in making progress in this issue. The NGPC is resolving to direct the ICANN President and CEO to appropriately target this proposed planned outreach campaign.

      The full details of the Proposal are presented in Annex 1 [PDF, 840 KB].

      The NGPC is also recommending to the ICANN Board that it direct the ICANN President and CEO to develop a long term plan to manage name collision risks related to the delegation of new TLDs, and to work with the community to develop a long-term plan to retain and measure root-server data. 

      The NGPC also is recommending to the ICANN Board that the ICANN Board Risk Committee should review this matter expressly at regular intervals and report back the Board.

      What Stakeholders or others were consulted?

      ICANN presented the findings in the Name Collision Study during the ICANN meeting in Durban, South Africa. In addition, ICANN initiated a public comment forum from 5 August to 17 September 2013, inviting the community to provide feedback on the Name Collision Study and the Proposal. During the public comment period, 75 comments were received. The public comment report summarizing the comments, and the full comments can be found at http://forum.icann.org/lists/comments-name-collision-05aug13/. In response to the public comments, staff updated the Proposal being considered by the NGPC to include additional enhancements to the plan to manage the name collision occurrences.

      What concerns or issues were raised by the community?

      Some members of the community noted a general concern that the name collision matter is being dealt with at such a late stage of the New gTLD process, and questioned why ICANN did not address the matter sooner. Commenters raising concerns about timing also requested an extension of the comment period to allow the community additional time to study and provide meaningful comment on these matters.

      Members of the community suggested that the risks identified in the Name Collision Study may be overstated, noting that only 3% of the total requests to the TLD DNS servers conflict with strings that are actually being considered under the new gTLD program. Some suggested that the scope of the problem does not warrant mitigation through a 3-6 month delay.

      Others noted that previous expansions of TLDs (e.g., .xxx, .asia) caused no known issues, and asserted that these successful delegations demonstrate that there is no need to delay any more than the two most risky strings. Some comments stated that there is no demonstrated reason to delay the delegation of any applied for TLD that is currently in the classifications of "low risk" and "uncalculated risk."

      Several members of the community commented on the validity or applicability of sample data used in the Name Collision Study, or the methodology used to evaluate the risks. These comments noted that only counting the number of requests for each string is insufficient when assessing risk, and advised that severity of consequences must be considered along with frequency. The comments also suggested that the Name Collision Study is missing critical data – namely, non-existent domains (NXD) traffic in existing TLDs or specific subdomains that receive NXD traffic in TLDs classified in the "uncalculated risk" category. Additionally, the commenters noting concerns with the methodology argue that setting the threshold for dividing strings into "low risk" and "uncategorized risk" (i.e. the 80%/20%) division is arbitrary.

      Some commenters advised ICANN to take up an aggressive campaign to educate businesses around the world about how to best prepare for name collision occurrences.

      Other commenters suggested that ICANN must be prepared to defer the introduction into the DNS of any new gTLD that its further, in-depth studies identify as presenting a threat of collision. These deferrals should remain in effect for each identified gTLD string until the threats related to that string can be substantially eliminated.

      What significant materials did Board review?

      What factors did the Board find to be significant?

      The NGPC considered several significant factors during its deliberations over whether or not to adopt the Proposal to manage name risk occurrences. The following are among the factors the NGPC found to be significant:

      • The NGPC considered the recommendations of the SSAC in SAC 057.
      • Various commenters advised that solely relying on the frequency of DNS requests to assess risk was insufficient, and ICANN must consider a series of additional parameters (e.g., request frequency, type of query, type of request, etc.) to define the risk level. Some comments asserted that ICANN used arbitrary methods for dividing strings into risk categories. ICANN agrees that other parameters, besides request frequency, should be considered in assessing the risk, particularly the potential harm caused by name collision occurrences, and will adopt the advice regarding the use of the other proposed parameters when doing the study to establish the probability and impact (e.g., harm) as a result of name collision occurrences.
      • Several commenters proposed new ideas to manage the risks associated with name collision occurrences. For example, members of the community proposed a new idea to temporarily block certain second level domains (SLDs) in an effort to provide balance between moving forward with new gTLD delegation, while preserving the DNS behavior expected by DNS resolvers of parties using names under new gTLDs in private networks that leak to the public DNS. ICANN staff agrees that temporarily blocking SLDs that appeared in the DITL data (i.e., by prohibiting these names from resolving in the newly delegated TLD) should ensure that corresponding DNS requests that currently leak into the public DNS will continue to be responded with "name error (NXDOMAIN)" responses, and that this measure will, minimize the possibility of harm while the blocking is in effect. The Proposal adopts this recommendation.
      • Several members of the community requested that the public comment period be extended to give the community more time to study the risks in their networks. ICANN believes that, given the revisions made to the Proposal, including the adoption of the temporary SLD blocking measure, the potentially affected parties will have more time to study the issues in their networks without being affected by new gTLD delegations. Additionally, in order to address effects by SLDs that were not temporarily blocked but that generate significant harm, registry operators will implement a process to enable an affected party to report and request the suspension of a domain name that by virtue of name collision occurrences is causing significant harm.
      • Several commenters noted that ICANN should implement an outreach campaign to educate potentially affected parties on the issue of the name collision occurrences and their potential impact. ICANN acknowledges the request and has revised the Proposal to include an outreach campaign as part of the updated proposal to manage name collision occurrences.

      Are there Positive or Negative Community Impacts? Are there fiscal impacts/ramifications on ICANN (Strategic Plan, Operating Plan, Budget); the community; and/or the public? Are there any Security, Stability or Resiliency issues relating to the DNS?

      SAC057 and the Name Collision Study identified several security risks to the DNS. The Proposal, as revised in response to community comments, provides a path forward to delegating new gTLDs in a secure and stable manner. The NGPC's action to direct the President, Generic Domains Division to move forward with implementing the Proposal will provide a positive impact to the community because it will allow ICANN to proceed to delegate new gTLDs when the potential for harm resulting from the delegation of an applied-for TLD is judged to be small.

      The Proposal may have a fiscal impact on ICANN, the community or the public, as there may be additional costs associated with implementing the mitigation measures in the Proposal, which may include additional resources needed to develop an outreach campaign targeted to affected parties to help them identify and manage the name collision occurrences in their networks.

      As part of ICANN's organizational administrative function, ICANN posted for public the Name Collision Study and the Proposal to manage the identified name collision risks. The report of public comments is available at: http://forum.icann.org/lists/comments-name-collision-05aug13/.

Published on 8 October 2013

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