Changes

Jump to navigation Jump to search
no edit summary
Line 4: Line 4:  
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.
 
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===
+
==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. <ref>[http://domainincite.com/13994-new-gtlds-are-the-new-y2k-corp-and-home-are-doomed-and-everything-else-is-delayed New gTLDs are The New Y2K, .corp and .home are doomed, and Everything Else is Delayed, DomainIncite] Retrieved 05 Feb 2014</ref>
 
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. <ref>[http://domainincite.com/13994-new-gtlds-are-the-new-y2k-corp-and-home-are-doomed-and-everything-else-is-delayed New gTLDs are The New Y2K, .corp and .home are doomed, and Everything Else is Delayed, DomainIncite] Retrieved 05 Feb 2014</ref>
   Line 37: Line 37:  
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]].<ref>[http://domainincite.com/14569-crocker-to-speak-at-second-gtld-collisions-summit Crocker to Speak at Second gTLD Collisions Summit, DomainIncite] Retrieved 17 Feb 2014</ref><ref>[http://www.tldsecurity.net/live-stream.html Live Stream, TLD Security Forum] Retrieved 18 Feb 2014</ref> 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.<ref>[http://domainincite.com/14592-angry-gtld-applicants-lay-into-ana-and-verisign-bullshit Angry gTLD Applicants Lay into ANA and Verisign "Bullshit", DomainIncite] Retrieved 18 Feb 2014</ref>
 
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]].<ref>[http://domainincite.com/14569-crocker-to-speak-at-second-gtld-collisions-summit Crocker to Speak at Second gTLD Collisions Summit, DomainIncite] Retrieved 17 Feb 2014</ref><ref>[http://www.tldsecurity.net/live-stream.html Live Stream, TLD Security Forum] Retrieved 18 Feb 2014</ref> 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.<ref>[http://domainincite.com/14592-angry-gtld-applicants-lay-into-ana-and-verisign-bullshit Angry gTLD Applicants Lay into ANA and Verisign "Bullshit", DomainIncite] Retrieved 18 Feb 2014</ref>
   −
====Public Comment Period====
+
===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.<ref>[http://domainincite.com/14334-name-collisions-comments-call-for-more-gtld-delay Name Collisions Comments Call for More gTLD Delay, DomainIncite] Retrieved 19 Feb 2014</ref>
 
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.<ref>[http://domainincite.com/14334-name-collisions-comments-call-for-more-gtld-delay Name Collisions Comments Call for More gTLD Delay, DomainIncite] Retrieved 19 Feb 2014</ref>
   −
===Proposed Solutions===
+
==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.
 
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.
   Line 47: Line 47:  
[[.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 ([[SLD]]s).<ref>[http://domainincite.com/14501-club-offers-solution-to-name-collision-risks .Club Offers Solution to Name Collision Risk, DomainIncite] Retrieved 18 Feb 2014</ref>
 
[[.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 ([[SLD]]s).<ref>[http://domainincite.com/14501-club-offers-solution-to-name-collision-risks .Club Offers Solution to Name Collision Risk, DomainIncite] Retrieved 18 Feb 2014</ref>
   −
===NGPC Resolution===
+
==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 "[http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-07oct13-en.pdf New gTLD Collision Occurrence Management Plan]".
 
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 "[http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-07oct13-en.pdf New gTLD Collision Occurrence Management Plan]".
   Line 56: Line 56:  
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.<ref>[http://www.icann.org/en/news/announcements/announcement-08oct13-en.htm Announcement 08 OCt 2013, ICANN.org] Retrieved 19 Feb 2014</ref><ref>[http://domainnamewire.com/2013/10/09/icann-gives-new-tld-applicants-a-faster-path-to-market/ ICANN Gives New gTLD Applicants a Faster Path to Market, DomainNameWire.com] Retrieved 19 Feb 2014</ref>
 
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.<ref>[http://www.icann.org/en/news/announcements/announcement-08oct13-en.htm Announcement 08 OCt 2013, ICANN.org] Retrieved 19 Feb 2014</ref><ref>[http://domainnamewire.com/2013/10/09/icann-gives-new-tld-applicants-a-faster-path-to-market/ ICANN Gives New gTLD Applicants a Faster Path to Market, DomainNameWire.com] Retrieved 19 Feb 2014</ref>
   −
====Alternative Path to Delegation====
+
==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.<ref>[https://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en Announcement 17 Nov 2013, ICANN.org] Retrieved 19 Feb 2014</ref>
 
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.<ref>[https://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en Announcement 17 Nov 2013, ICANN.org] Retrieved 19 Feb 2014</ref>
   Line 62: Line 62:  
* 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]].
 
* 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===
+
==Risk Mitigation Report by JAS Advisors==
On 26 February 2014, ICANN posted the followup report it commissioned [[JAS Advisors]] to prepare in order to suggest a plan for risk mitigation of the name collision issue. The report, titled "Mitigating The Risk of DNS Namespace Collisions"
+
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:<ref>[http://www.icann.org/en/news/public-comment/name-collision-26feb14-en.htm Name Collision, 26 Feb 2014, ICANN.org] Retrieved 27 Feb 2014</ref>
 +
 
 +
* 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.<ref>[http://www.icann.org/en/news/announcements/announcement-26feb14-en.htm Announcement 26 Feb 2014, ICANN.org] Retrieved 27 Feb 2014</ref>
 +
 
 +
The report brought a possible new way forward for many New gTLD applicants.<ref>[http://domainincite.com/15925-new-gtld-registries-given-way-to-free-up-millions-of-blocked-names New gTLD Registries Given Way to Free up Millions of Blocked Names, DomainIncite] Retrieved 27 Feb 2014</ref>
 +
 
 +
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.<ref>[https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf Name Collision Mitigation Study Phase One] (6 June 2014) JAS Advisors ''ICANN.org'; Retrieved 11 June 2014 (PDF)</ref>
 +
 
 +
==Name Collision Occurrence Management Framework==
 +
On July 30, 2014, the New gTLD Program Committee (NGPC) approved resolutions<ref>[https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en Approved Resolutions | Meeting of the New gTLD Program Committee] Retrieved 29 September 2014</ref> for the Name Collision Occurrence Management Framework<ref>[https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf Name Collision Occurrence Management Framework] (PDF, 634 KB) Retrieved 29 September 2014</ref> 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<ref>[https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf Name Collision Occurrence Management Framework] (PDF, 634 KB) Retrieved 29 September 2014</ref>:
 +
 
 +
* 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.<ref>[https://www.icann.org/resources/pages/name-collision-ro-faqs-2014-08-01-en Frequently Asked Questions: Name Collision Occurrence Management Framework for Registries] Retrieved 29 September 2014</ref>
 +
 
 +
For additional details, refer to the ICANN website, Name Collision Resources & Information at [http://icann.org/namecollision 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.<ref>[https://community.icann.org/display/NCAP/History+of+the+Name++Collision+Analysis+Project NCAP Workspace - History of the Name Collision Analysis Project], last updated March 30, 2021</ref> In response, SSAC started the Name Collision Analysis Project with three name collision studies to address the Board's request.<ref>[https://www.icann.org/en/public-comment/proceeding/name-collision-analysis-project-ncap-study-1-13-02-2020 NCAP Study 1 Public Comment]</ref>
 +
===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 [https://www.icann.org/en/system/files/files/ncap-study-1-report-12feb20-en.pdf 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]].<ref>[https://community.icann.org/display/NCAP/NCAP+Working+Documents?preview=/79437474/158140551/5%20Feb%20NCAP%20Package_Redacted.pdf NCAP Study 2 Proposal, Community, ICANN Org]</ref>
 +
====Discussion Group====
 +
* 25 discussion group members
 +
* 14 SSAC work party members
 +
* 23 community observers
 +
* Chairs: [[James Galvin]], [[Matt Thomas]]
 +
====Tasks====
 +
# Root cause analysis (In progress)
 +
# Additional data collection (In progress)
 +
# Answering board questions (In progress)
 +
# Case studies of .corp, .home, .mail, .lan, .local, .internal (Draft in review)
 +
# 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 Comment]]s 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.<ref>[https://www.icann.org/en/public-comment/proceeding/name-collision-analysis-project-ncap-study-2-documents-27-01-2022 NCAP Study 2 Public Comment Proceedings, ICANN]</ref> The group received 3 comments on the topics of:
 +
# 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.
 +
# 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.<br/>
 +
[[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.<ref>[https://itp.cdn.icann.org/en/files/name-collision/nacp-study-2-documents-04-04-2022-en.pdf NCAP Study 2 Drafts, Public Comments, ICANN]</ref> 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.<ref>[https://itp.cdn.icann.org/en/files/name-collision/nacp-study-2-documents-04-04-2022-en.pdf NCAP Study 2 Drafts, Public Comments, ICANN]</ref>
 +
===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 [[AltRoot]]s, 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."<ref>[https://www.icann.org/en/system/files/files/octo-034-27apr22-en.pdf OCTO-034, ICANN Files]</ref>
 
==References==
 
==References==
 
{{reflist}}
 
{{reflist}}
   −
__NOTOC__
+
[[Category:Glossary]]
Bureaucrats, Check users, lookupuser, Administrators, translator
14,927

edits

Navigation menu