Name Collision

A Name Collision describes the circumstance in which a term attempting to reach a private Domain Name results in resolving to a public Domain Name unintentionally. Private domain names are used in Intranets and in many corporations and organizations throughout the world. A domain name on a private network that matches a name in the public Internet can create security risks, confusion, and systems failure.

New gTLD Program

Although the Name Collision issue is not new, a renewed interest in the issue came about in 2013 as ICANN's New gTLD Program was preparing to delegate hundreds of new domain names to the Root Zone. The topic was debated fiercely within the ICANN community when a report by Interisle Consulting was prepared for and released by ICANN.

Interisle Consulting Report

ICANN contracted Interisle Consulting to carry out an investigation into the effects the delegation of 100s of new gTLDs would have on the security of the existing Internet and intranets around the world. The resulting report, which was published on August 6th, 2013 by ICANN, found that there would be many name collisions for new gTLDs that could create potential security risks. ICANN's initial response to this report was to propose a delay to the New gTLD Program, based on the assessed security risk each New gTLD would carry.

• ICANN deemed two strings, .home and .corp, as "high-risk" because of the widespread use of the terms on internal networks. Currently, ICANN is indefinitely delaying the delegation of these string to the root.

• 20% of applications had been deemed an "uncalculated risk" by ICANN in the initial plan, stating that these strings would be delayed 2-3 months in their application process while ICANN conducts more research into whether the string is of "high" or "low" risk.

• 80% of applications were deemed "low risk" by ICANN. These strings would face a delay in activating domains until 120 days after contracting with ICANN, but otherwise would not face any long terms delays towards delegation.

Overall, the initial reaction to the Interisle report took the form of outrage by many New gTLD applicants, especially since the delays could potentially add on millions of dollars in costs to the applicants on their way to delegating a new gTLD. Other groups however, supported ICANN's cautionary measures and urged them to take all steps necessary to mitigate the risk that name collisions brought forth. In the months following the report's publishing, the ICANN community mobilized to create alternative solutions to the Name Collision issue, as well as argue whether or not the issue was serious enough to delay delegation of 100s of gTLDs.

The report and ICANN's proposal for how to deal with the situation were posted on ICANN's website for public comment until September 17, 2013

Reception by New gTLD Applicants

Reception by New gTLD Applicants to the Interisle Report as well as ICANN's proposed plan was varied. Many applicants were angered and cited that the timing of the report was poor, since ICANN was only months away from delegating the first New gTLDs in the program. Others pointed to the potential of millions of dollars in extra costs because of this delay. A few applicants, most notably Verisign, were more supportive of ICANN's response to the report and felt the delay was warranted in order to make sure the security of the Internet would not be compromised. Many applicants however, felt that the report and ICANN's response was too conservative and that the Name Collision issue did not pose a serious risk for the vast majority of new TLDs. Some applicants pointed out that the delegation of many New TLDs in the years before had never caused a major issue in regards to name collisions.

Donuts initially reacted to the Interisle Report and ICANN's response by saying: "We also think that name collision is an overstated issue. Rather than take the overdone step of halting or delaying these TLDs, if the issue really is such a concern, it would be wiser to focus on the second-level names where a conflict could occur."

Uniregistry's Frank Schilling stated: "We are deeply dismayed by this new report, both by its substance and its timing."

Famous Four Media has this to say: "Famous Four Media’s primary concern is the security and stability of the Internet. Since this is in the interest of all parties involved in the new gTLD program from registries to registrants and all in between Famous Four Media welcomes these proposals."

Alex Stamos presents at the TLD Security Forum in October 2013.

NTAG Response

The New gTLD Applicant's Group within ICANN sent a letter responding to the Interisle report and ICANN recommendations. The NTAG felt that the report overstated the risks of Name Collision, and called for all of the strings that were designated by ICANN as "uncalculated risk" to be moved into the "low risk" category. The NTAG stated that they agreed however, that the .home and .corp strings should remain as "high risk" and further research is required to move forward with those strings.

Community Discussions

The discussions surrounding the Interisle Report and ICANN's response occurred in the public comments on the ICANN site, as well as in several conferences organized by community members.

Artemis Internet, the applicant for .secure, held a day-long conference in San Francisco in August 2013 to discuss the Names Collision issue. Delegates from Google and Paypal were listed as panelists.

New gTLD Applicants also organized a conference on 01 Oct 2013 in Washington, D.C. Titled the TLD Security Forum, the event hosted a number of panelists and speakers, notably Steve Crocker. The afternoon sessions included some fierce debate as NTAG members clashed with representatives from ANA. ANA vice president Dan Jaffe and legal council Amy Mushahwar presented a session that had many New gTLD applicants, most notably Alex Stamos of Artemis Internet and Jeff Neuman of Neustar, arguing against them in the Q&A portion of the session. The ANA delegates raised concerns that they needed more than a month-long comment period to go over the data from the Interisle report and reach conclusions as to the risk that Name Collisions might have once New gTLDs are delegated.

Public Comment Period

As with many ICANN policy decisions, the Interisle Report and ICANN's proposed solutions were posted on the ICANN website for a period of Public Comment in August of 2013. Many community members submitted comments. Overall, discussions revolved around two main points: many applicants submitted comments that criticized the data in the report and/or ICANN's solution plan. Other members of the community, primarily non-applicants, argued that the comment period was too short and asked ICANN to proceed with caution and allow companies time to go over the data and create their own research.

Proposed Solutions

Many solutions to the Name Collision issue were proposed by ICANN, TLD applicants, and the community at large. The initial proposal was released by ICANN immediately following the release of Interisle's report, and after the public comment period, the final plan was published.

During the same period that the public comment period occurred, a number of new gTLD applicants proposed alternative approaches to "mitigation" of the name collision issue. Neustar conducted its own analysis of the data in the Interisle report, and suggested a few alternative solutions that included moving all strings except .home, .corp, and .mail into the "low risk" category and then evaluating the risk immediately instead of mandating a 120-day period after the RA signing.

.CLUB Domain LLC, the company applying for .club, also proposed a solution of their own. The company contracted Interisle Consulting to do an evaluation of the .club string, to determine the possible name collisions that might occur if the string was delegated. They then proposed, in a letter to ICANN, a solution for strings in the "uncalculated risk" category in which they would reserve the top 50 names in each string that see DNS root traffic. The list of these string would come from an individual report much like the one .CLUB Domains commissioned for themselves. After reserving these names, the impact of collisions would be greatly reduced once the TLD was delegated. This porposal makes it possible to have more time to find a solution to the Name Collision issue while still allowing delegations of new TLDs to continue, provided they reserve a certain number of Second Level Domains (SLDs).

NGPC Resolution

On 8 October 2013, The New gTLD Program Committee (NGPC) announced their final plan for the Name Collision issue. The committee met to discuss the public comments received on the initial proposal, and then updated and released a final document titled the "New gTLD Collision Occurrence Management Plan".

The final plan left the .home and .corp strings in permanent limbo as "high risk" strings, just as the original plan stated. These string will not be delegated until ICANN and the community conduct more research and propose a mitigation plan. ICANN believes these strings will cause significant problems if delegated to the Root Zone.

An example of the block list for .boston

The plan states that ICANN will contract a Collision Occurrence Management Framework that will stipulate assessments and mitigation measures that may need to be taken for certain TLDs. This process is similar to the one outlined in the original plan, with applicants waiting to delegate until they receive their assessment report and perform the necessary mitigation measures. However, the new report focused on an "Alternative Path to Delegation" in which New gTLD applicants who are not applying for .home or .corp and were eligible, could proceed to delegation without their assessment report, provided they block all Second Level Domains (SLDs) that were found in the "Day in The Life" Internet data for their TLD. The majority of New gTLD applicants that were eligible ended up choosing this alternative path.

Finally, the plan outlined an outreach campaign to educate systems administrators, software developers, and other engineers about the Name Collision issue and the mitigation measures they could take to reduce risk.

Alternative Path to Delegation

On 17-18 November 2013, ICANN released the reports for the alternative path to delegation. Apart from .home and .corp, all but 25 strings were eligible for this path, and could choose to elect the alternative path. The 25 strings not eligible for the alternative path must wait to receive their assessment and mitigation plans from ICANN.

• You can download all of the Alternative Path to Delegation reports (including block lists) here.
• The 25 strings not eligible for the alternative path were: .blog, .box, .business, .casa, .cisco, .comcast, .dev, .family, .free, .google, .iinet, .mail, .network, .office, .orange, .philips, .prod, .sfr, .site, .taobao, .taxi, .web, .work, .world, and .zip.

Risk Mitigation Report by JAS Advisors

On 26 February 2014, ICANN posted the follow-up report it commissioned JAS Advisors to prepare in order to suggest a plan for risk mitigation of the name collision issue. It was posted for public comment for about a month and then will be decided on by the ICANN Board. The report, titled "Mitigating The Risk of DNS Namespace Collisions," makes a number of key recommendations for resolving the name collision issue for most applicants:

• Registries would be able to implement a controlled interruption zone, which would involve "wildcarding" all SLDs (or all SLDs in the block list) to specific IP that would then alert internal networks if there were any name collisions.
• ICANN would implement an emergency plan and strategy in case name collisions had a "clear danger to human life".
• ICANN and community should continue to study and analyze data from this issue.
• Apart from the .corp and .home names that were previously deemed too dangerous to ever delegate, the study recommended that .mail also be reserved permanently.

The report brought a possible new way forward for many New gTLD applicants.

The final draft of the report, "Mitigating the Risk of DNS Namespace Collisions Phase One", was published on June 10th. Important changes that were made because of a Public Comment Period for the document include a change of the Controlled Interruption Zone period from 120 to 90 days.

Name Collision Occurrence Management Framework

On July 30, 2014, the New gTLD Program Committee (NGPC) approved resolutions for the Name Collision Occurrence Management Framework to continue to manage the occurrence of collisions between new gTLDs and existing private uses of the same strings. As part of the implementation, registry operators will be provided with a Name Collision Occurrence Assessment (see Registry Agreement, Specification 6, Section 6), which will address, among other things, procedures to remove second level domains from the block list including measures to protect rights holders.

The announcement highlighted two general requirements for registries:

• Required to act on name collision reports from ICANN within two hours of the report during the first two years of the life of the TLD measured from the time of delegation of the TLD.

• Required to implement "controlled interruption" as the notification measure to alert parties that they may be leaking queries intended from private namespaces to the public DNS. Controlled interruption is required to be continuous interruption (i.e. not intermittent), and lasting for a 90-day period. Generally, if a TLD was delegated prior to a defined cut-off date, the registry operator would implement controlled interruption using MX, SRV, TXT, and A records for second level domains included in the block list. For TLDs delegated after a defined cut-off date, the registry operator would implement controlled interruption using a wildcard method. Controlled interruption (for IPv4) will use a loopback address (127.0.53.53). The 'cutoff date' is 18 August 2014.

For additional details, refer to the ICANN website, Name Collision Resources & Information at icann.org/namecollision.

NCAP

The ICANN Board asked the ICANN Security and Stability Advisory Committee (SSAC) to study the impact of name collisions and advise the Board on their effects and possible mitigation. In response, SSAC started the Name Collision Analysis Project with three name collision studies to address the Board's request.

Study 1

Study 1 concerns name collisions in the context of TLDs in the DNS (reflected in the root zone overseen by the IANA Function) and any other namespace, whether or not it is intended for use with the DNS or any other protocol.

• On November 2, 2017, the ICANN Board requested that SSAC conduct studies to present data, analysis, and points of view on Name Collision.
• In December 2017, SSAC began project planning.
• In January 2018, the SSAC NCAP Work Party and Admin formed and organized the three studies
• In June 2018, the ICANN CEO relocated the responsibility of the NCAP from SSAC to the OCTO because it was too big for the SSAC.
• In July 2019, the OCTO outsourced the completion of Study 1 to Scarfone Cybersecurity, who released the draft final report entitled Managing the Risks of Top-Level Domain Name Collisions for Public Comment on February 12, 2020.

Study 2

The ICANN Board asked the SSAC to design a study to understand the root cause of most name collisions and understand the impact of any choices made regarding .corp .home, and .mail.

Discussion Group

• 25 discussion group members
• 14 SSAC work party members
• 23 community observers
• Chairs: James Galvin, Matt Thomas

Tasks

1. Root cause analysis (In progress)
2. Additional data collection (In progress)
3. Answering board questions (In progress)
4. Case studies of .corp, .home, .mail, .lan, .local, .internal (Draft in review)
5. Name collision analysis (Development of Analysis Workflow has begun)

Critical Diagnostic Measurements

• Impact determined by Volume and Diversity across critical diagnostic measurements (CDMs), including:
• Query Volume
• Query Origin Diversity
  • IP address distribution
  • ASN distribution
• Query TYPE Diversity
• Label Diversity
• Other characteristics
  • Open-Source Intelligence (OSINT)

Public Comments

From late January to mid-March 2022, the NCAP Discussion Group sought Public Comments on two draft work products related to NCAP Study 2 goals of understanding how measurements of DNS hierarchy layers can convey the impact of name collisions. The group received 3 comments on the topics of:

1. A Prospective Study of DNS Queries for Non-Existent Top-Level Domains to understand the distribution of DNS name collision traffic throughout the DNS hierarchy and determine where and how to collect and assess DNS data.
2. Case Studies of Collision Strings (.corp, .home, .mail, .internal, .lan, and .local) based on DNS query data from A and J root servers in light of DNS evolution.
   

OCTO suggested specific amendments to the documents whereas the ISPCP and RySG gave high-level statements about the group’s approach. OCTO noted that the study descriptions are not related to understanding the root cause of most name collisions, and this relationship should be spelled out. OCTO also advised the group that the documents should be revised to specify quantitatively which, if any, of their findings had a significant impact on the RSS, end users, or resolvers. OCTO encouraged the group to support all conclusions with data. The ISPCP suggested the discussion group should be expanded to include representatives from other parts of the ICANN Community. RySG supported the continued use of the hypothesis that "controlled interruption is effective" based on the data.

Outputs

NCAP resulted in a broader definition for a name collision: when a name that is defined and used in one namespace also appears in another. Partly in reference to AltRoots, the NCAP team warned that the "indiscriminate and uncoordinated introduction of new namespaces without a careful review from the larger community may be a cause of ongoing and unavoidable name collisions, making the Internet less stable and less secure."

Top-Level Domain

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Internet Assigned Numbers Authority

ISPs and Connectivity Providers Constituency