Changes

no edit summary
Line 63: Line 63:     
==Risk Mitigation Report by JAS Advisors==
 
==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. 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>
+
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, in 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.
+
* 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 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.
 
* ICANN and community should continue to study and analyze data from this issue.
Line 71: Line 71:     
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 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}}
    
[[Category:Glossary]]
 
[[Category:Glossary]]
Bureaucrats, Check users, lookupuser, Administrators, translator
14,932

edits