Independent Submission M. Thomas
Request for Comments: 8023
Category: Informational A. Mankin
ISSN: 2070-1721 Salesforce
L. Zhang
UCLA
November 2016
Independent Submission M. Thomas
Request for Comments: 8023
Category: Informational A. Mankin
ISSN: 2070-1721 Salesforce
L. Zhang
UCLA
November 2016
Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions
研讨会报告和名称冲突根本原因和缓解奖
Abstract
摘要
This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.
本文件提供了2014年3月8日至10日在英国伦敦举行的“名称冲突的根本原因和缓解”研讨会的背景和报告。研讨会的主要目标是促进对域名冲突的原因和潜在缓解措施的讨论。本报告提供了少量的背景和背景；然后，它提供了研讨会讨论的摘要。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8023.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8023.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Background and Context ..........................................4
2.1. Brief Update ...............................................6
3. Workshop Structure ..............................................7
3.1. Research Findings ..........................................8
3.2. System Analysis ............................................9
3.3. Frameworks: Modeling, Analysis, and Mitigation ............9
3.4. Conclusions and Next Steps ................................11
4. Security Considerations ........................................11
5. Informative References .........................................12
Appendix A. Program Committee .....................................16
Appendix B. Workshop Material .....................................16
Appendix C. Workshop Participants .................................17
Acknowledgments ...................................................17
Authors' Addresses ................................................17
1. Introduction ....................................................2
2. Background and Context ..........................................4
2.1. Brief Update ...............................................6
3. Workshop Structure ..............................................7
3.1. Research Findings ..........................................8
3.2. System Analysis ............................................9
3.3. Frameworks: Modeling, Analysis, and Mitigation ............9
3.4. Conclusions and Next Steps ................................11
4. Security Considerations ........................................11
5. Informative References .........................................12
Appendix A. Program Committee .....................................16
Appendix B. Workshop Material .....................................16
Appendix C. Workshop Participants .................................17
Acknowledgments ...................................................17
Authors' Addresses ................................................17
It has been well known within the Internet research and engineering community that many installed systems in the Internet query the domain name system (DNS) root for names under a wide range of top-level domains (TLDs). Many of these TLDs are not delegated, which results in a response indicating that the name queried does not exist (commonly called an NXDOMAIN response [RFC7719]). In the Internet Corporation for Assigned Names and Numbers (ICANN) community, it was observed as early as November 2010 by the Security and Stability Advisory Committee (SSAC) report [SAC045] that the addition of new TLDs in the DNS root could result in so-called name collisions for names used in environments other than the global Internet. Some installed systems, following established (albeit not vetted) operational practices, generate queries to the global DNS with name suffixes that, under seemingly reasonable assumptions at the time the systems were designed or configured, were not expected to be delegated as TLDs. Many of these installed systems depend explicitly
在互联网研究和工程界，众所周知，互联网上许多已安装的系统都会在域名系统（DNS）根目录中查询各种顶级域（TLD）下的名称。这些TLD中的许多未被委派，这会导致一个响应，指示查询的名称不存在（通常称为NXDOMAIN响应[RFC7719]）。在互联网名称和号码分配公司（ICANN）社区中，安全与稳定咨询委员会（SSAC）报告[SAC045]早在2010年11月就发现，在DNS根目录中添加新的TLD可能会导致在全球互联网以外的环境中使用的名称发生所谓的名称冲突。一些已安装的系统遵循既定（尽管未经审查）的操作实践，使用名称后缀生成对全局DNS的查询，在设计或配置系统时，根据看似合理的假设，这些查询预计不会被委派为TLD。这些已安装的系统中有许多明确地依赖于
or implicitly on the indication from the global DNS that the domain name suffix does not exist. After a new TLD is delegated, the global DNS may give a different response to the query involving the TLD than it did prior to the TLD's delegation.
或者在全局DNS指示域名后缀不存在时隐式地。在委派新TLD之后，全局DNS可能会对涉及TLD的查询给出与委派TLD之前不同的响应。
A name collision occurs when an attempt to resolve a name used in a private namespace results in a query to the public DNS, and the response indicates that the name is in the global DNS [NCRI]. In other words, the overlap of public and private namespaces may result in potential unintended (and, therefore, potentially harmful) resolution results. The impact of the global change on installed systems will be varied; risks to installed systems introduced by name collisions may arise due to varied causes.
如果试图解析专用命名空间中使用的名称导致查询到公共DNS，并且响应指示该名称位于全局DNS[NCRI]中，则会发生名称冲突。换句话说，公共和私有名称空间的重叠可能会导致潜在的非预期（因此可能有害）解析结果。全球变化对已安装系统的影响将是多种多样的；由于各种原因，可能会出现名称冲突给已安装系统带来的风险。
In a globally distributed system, such as the Internet, it is difficult, yet critical, to agree on policies for demarking boundaries of ownership and autonomy. Name space governance is critical to ensure predictable use of names in the global DNS.
在一个全球分布的系统中，如互联网，很难达成一致的所有权和自主性界限界定政策，但这一点至关重要。名称空间治理对于确保在全局DNS中可预测地使用名称至关重要。
In order to help ensure this uniqueness and interoperability, ICANN, through its coordination of the IANA functions, is responsible for administration of certain responsibilities associated with Internet DNS root zone management, such as generic and country code Top-Level Domains (gTLDs and ccTLDs). Prior to ICANN's creation in 1998, seven generic TLDs were defined in the early development of the Internet [RFC1591]. Since the formation of ICANN, the delegations of generic, internationalized and country code TLDs have been administered and delegated by ICANN. During these delegations, it quickly became apparent within the IETF community that there was a need to reserve name spaces that can be used for creating limited sets of internal names without fear of conflicts with current or future TLD name spaces in the global DNS [RFC2606].
为了帮助确保这种唯一性和互操作性，ICANN通过协调IANA功能，负责管理与Internet DNS根区域管理相关的某些职责，例如通用和国家代码顶级域（GTLD和CCTLD）。在ICANN于1998年创建之前，互联网早期开发中定义了七个通用TLD[RFC1591]。自ICANN成立以来，通用、国际化和国家代码TLD的授权一直由ICANN管理和授权。在这些授权期间，IETF社区内很快发现，有必要保留名称空间，用于创建有限的内部名称集，而无需担心与全球DNS中当前或未来的TLD名称空间发生冲突[RFC2606]。
While the reserved TLDs [RFC2606] aimed to enable operators to use them only as a small set of reserved names internally, with limited uses, educational awareness and operational best practices did not achieve the goal of reserving special-use domain names [RFC6761]; other suffixes, not reserved though at the time not in conflict, were often employed instead. Faulty assumptions, or encouragement in some cases by vendor documentation, of "we only use this name internally and there is no possibility of leakage to the global DNS" were made by numerous operators or administrators. Numerous reports and findings have clearly disproved these faulty assumptions by showing substantial "DNS leakage" into the global DNS through mechanisms such as search lists.
虽然保留的TLD[RFC2606]旨在使运营商仅在内部将其作为一小部分保留名称使用，但其用途有限，教育意识和操作最佳实践并未实现保留特殊用途域名[RFC6761]的目标；其他后缀，虽然在当时没有冲突，但没有保留，经常被使用。许多运营商或管理员做出错误的假设，或在某些情况下，供应商文档鼓励“我们只在内部使用此名称，不存在泄漏到全局DNS的可能性”。大量报告和调查结果表明，通过搜索列表等机制，大量“DNS泄漏”到全球DNS中，从而明确驳斥了这些错误假设。
In 2012, ICANN created a new gTLD program to add a potentially unlimited number of new gTLDs to the root zone as a mechanism to
2012年，ICANN创建了一个新的gTLD计划，以向根区域添加数量可能不受限制的新gTLD，作为
enhance competition, innovation, and consumer choice. With the potential of many new gTLDs becoming delegated in the global DNS, operators or administrators who elected to use a non-delegated name space internally may face potential "name collision" problems.
增强竞争、创新和消费者选择。由于许多新的GTL可能在全局DNS中被授权，选择在内部使用非授权名称空间的运营商或管理员可能会面临潜在的“名称冲突”问题。
This document is primarily a report on the March 2014 workshop that set out to examine the causes and mitigation of such name collisions and their associated risks. It is a companion to the Workshop and Prize on Root Causes and Mitigation of Name Collisions proceedings [WPNC], and it also provides some additional background and context.
本文件主要是2014年3月研讨会的报告，该研讨会旨在研究此类名称冲突的原因和缓解措施及其相关风险。它是关于名称冲突根本原因和缓解程序[WPNC]的研讨会和奖项的一个伴奏，它还提供了一些额外的背景和背景。
When the workshop was convened, the context and status of the work around name collisions could be described as follows.
研讨会召开时，围绕名称冲突开展的工作的背景和状态可描述如下。
Since early 2008, there had been numerous lengthy discussions within the ICANN community about the ability of the DNS root to scale to accommodate new gTLDs and the impact of making those changes on the DNS ecosystem. In March 2008, the Internet Architecture Board (IAB) observed that the introduction of suffixes in use in a number of environments could lead to instability [IAB2008]. In December 2010, the Security and Stability Advisory Committee (SSAC) issued their report on root scaling in which the committee formalized several recommendations based on "actual measurement, monitoring, and data-sharing capabilities of root zone performance" to help determine the feasibility of root scaling [SAC046]. Separately, the Root Server System Advisory Committee [RSSAC] agreed in late 2010 on the need to establish standard metrics to be collected and reported by all operators. This effort would provide the community with a baseline measure of the entire root server system's performance. With such an established baseline, any possible negative effect from additional TLDs within the root could potentially be identified. In late 2012, the ICANN Board affirmed the need to work with the root server operators via RSSAC to complete the documentation of the interactions between ICANN and the root server operators with respect to root zone scaling [IR2012].
自2008年初以来，ICANN社区内就DNS根目录是否能够扩展以适应新的GTLD以及进行这些更改对DNS生态系统的影响进行了多次冗长的讨论。2008年3月，互联网体系结构委员会（IAB）观察到，在许多环境中引入后缀可能会导致不稳定[IAB2008]。2010年12月，安全与稳定咨询委员会（SSAC）发布了关于根区扩展的报告，其中委员会根据“根区性能的实际测量、监测和数据共享能力”正式确定了若干建议，以帮助确定根区扩展的可行性[SAC046]。另外，根服务器系统咨询委员会[RSSAC]在2010年末同意，需要建立标准指标，供所有运营商收集和报告。这项工作将为社区提供整个根服务器系统性能的基线度量。有了这样一个既定的基线，就有可能确定根中额外TLD可能产生的任何负面影响。2012年末，ICANN董事会确认需要通过RSSAC与根服务器运营商合作，以完成ICANN与根服务器运营商之间关于根区域扩展的互动记录[IR2012]。
In March 2013, SSAC published an advisory titled "SSAC Advisory on Internal Name Certificates," which identified a Certificate Authority (CA) practice that, if widely exploited, "could pose a significant risk to the privacy and integrity of secure Internet communications" [SAC057]. The ICANN Board acknowledged the issues identified in the advisory report on internal name certificates [SAC057] as part of a more general category of issues. These issues included installed systems utilizing a namespace in a private network that includes a non-delegated TLD that is later delegated into the root. In May 2013, the ICANN Board commissioned a study on the use within private
2013年3月，SSAC发布了一份名为“SSAC内部姓名证书咨询”的咨询意见，其中确定了一种证书颁发机构（CA）做法，如果被广泛利用，“可能对安全互联网通信的隐私和完整性构成重大风险”[SAC057]。ICANN董事会承认，内部名称证书咨询报告[SAC057]中确定的问题属于更一般的问题类别。这些问题包括在私有网络中使用名称空间的已安装系统，该名称空间包括一个非委托TLD，该TLD随后被委托到根目录中。2013年5月，ICANN董事会委托进行了一项关于在私人网络中使用的研究
name spaces of TLDs that are not currently delegated at the root level of the global DNS [ISTUDY]. This study was focused on potential name collision events between applied-for new gTLDs and non-delegated TLDs potentially used in private namespaces. The study also examined the potential possibility of name collisions arising from the use of digital certificates referenced in the SSAC report on internal name certificates [SAC057].
当前未在全局DNS[ISTUDY]的根级别委派的TLD的命名空间。这项研究的重点是应用于新gtld和可能用于私有名称空间的非委托tld之间的潜在名称冲突事件。该研究还考察了使用SSAC内部名称证书报告[SAC057]中引用的数字证书可能导致的名称冲突。
Between the RSSAC's and SSAC's advisory statements ([RSSAC] [SAC046]) and the ICANN commissioning of a study in May 2013, there was significant progress on establishing formalized, coordinated monitoring and measurement of the root. RSSAC approached its finalization of the specific metrics that each root operator will collect and initiated discussions about where the operators will send their data for analysis once collected. To properly gauge the risks of new gTLD delegations to the root, an established baseline of normal performance of the system would be required to start sufficiently ahead of the new delegations. The execution of these RSSAC and SSAC recommendations was timed poorly with the commissioned study, resulting in a limited pool of data repositories from which any baseline and risk measurements could be established.
在RSSAC和SSAC的咨询声明（[RSSAC][SAC046]）和ICANN于2013年5月委托进行的一项研究之间，在建立正式、协调的根部监测和测量方面取得了重大进展。RSSAC最终确定了每个根运营商将收集的具体指标，并开始讨论一旦收集到数据，运营商将在何处发送数据进行分析。为了从根本上正确评估新的gTLD授权的风险，需要在新授权之前充分启动系统正常性能的既定基线。这些RSSAC和SSAC建议的执行与委托研究的时间安排不当，导致可以建立任何基线和风险度量的数据库有限。
It is common practice for each root operator to monitor its own root server, and some operators report the status and performance of their services publicly. As of ICANN's study commissioned in May 2013 [ISTUDY], there was no mechanism in place to allow a detailed view of the entire root system, short of the annual "Day in the Life" ([DITL]) data repository, which contains root DNS data over a short coordinated time period from a varying subset of root operators and was intended to be used for research purposes, not to provide overall monitoring and an operational view of system health. Due to the lack of a more comprehensive and desirable data repository for baseline and collision analysis DITL has become the de facto referential dataset for root traffic analysis.
每个根运营商监控自己的根服务器是常见的做法，一些运营商公开报告其服务的状态和性能。截至2013年5月ICANN委托进行的研究[ISTUDY]，除了年度“生命中的一天”（[DITL]）数据存储库外，没有任何机制允许详细查看整个根系，它包含来自不同根操作符子集的短协调时间内的根DNS数据，旨在用于研究目的，而不是提供系统健康的总体监控和操作视图。由于缺乏更全面、更理想的基线和冲突分析数据存储库，DITL已成为根流量分析的事实参考数据集。
The commissioned study, conducted by the Interisle Consulting Group, was published in August of 2013. Their report "Name Collisions in the DNS" [INTERISLE], based on [DITL] measurements, addressed name collisions in the DNS and also recommended options to mitigate the various name collision risks. The study identified categories of strings according to the risk they represent: low risk (80 percent of applied-for strings), uncalculated risk (20 percent of applied-for strings), and high risk (2 applied-for strings).
由Interisle咨询集团进行的委托研究于2013年8月发表。他们的报告“DNS中的名称冲突”[INTERISLE]，基于[DITL]测量，解决了DNS中的名称冲突，并推荐了缓解各种名称冲突风险的选项。该研究根据字符串所代表的风险确定了字符串类别：低风险（80%适用于字符串）、未计算风险（20%适用于字符串）和高风险（2%适用于字符串）。
At the same time as the [INTERISLE] study, ICANN published a proposal, titled "New gTLD Collision Occurrence Management Plan" [NGCOMP], to manage the risk of name collisions within the applied-for gTLDs. Based on measurements, ICANN deemed two strings, .home
在进行[INTERISLE]研究的同时，ICANN发布了一份名为“新gTLD冲突发生管理计划”[NGCOMP]的提案，以管理申请gTLD中的名称冲突风险。根据测量结果，ICANN认为有两个字符串，.home
and .corp, to be high risk because of their widespread use within internal networks and would indefinitely delay their delegation [INTERISLE]. Those strings within the uncalculated-risk classification would be delayed 2 to 3 months in their application process while ICANN conducted more research into whether the string is of high- or low-risk classification. Those in the low-risk classification would face a delay in activating domains until 120 days after contracting with ICANN to allow for the change in certificate authority practices recommended in the SSAC report on internal name certificates [SAC057].
由于它们在内部网络中的广泛使用，它们将面临高风险，并将无限期地推迟它们的授权[INTERISLE]。未计算风险分类中的字符串将在其应用过程中延迟2至3个月，而ICANN对字符串是高风险分类还是低风险分类进行了更多研究。低风险类别的域名将面临激活域名的延迟，直到与ICANN签订合同后120天，以允许更改SSAC内部名称证书报告[SAC057]中建议的证书颁发机构做法。
Within the ICANN proposal [NGCOMP], an approach termed the "alternative path to delegation" was outlined, in which a registry operator could elect to proceed with delegation, provided it initially blocked all second-level domains (SLDs) that appeared in the certain DITL datasets pending the completion of the assessment. The majority of new gTLD applicants that were eligible elected this alternative path once otherwise approved for delegation. The plan also outlined an outreach campaign to educate system administrators, software developers, and other engineers about the name collision issue and possible mitigation measures.
在ICANN提案[NGCOMP]中，概述了一种称为“授权替代路径”的方法，在该方法中，注册运营商可以选择继续进行授权，前提是在完成评估之前，注册运营商最初阻止了某些DITL数据集中出现的所有二级域（SLD）。有资格的大多数新gTLD申请人在获得授权批准后选择了这一替代途径。该计划还概述了一项推广活动，以教育系统管理员、软件开发人员和其他工程师有关名称冲突问题和可能的缓解措施。
As a further provision, the "New gTLD Collision Occurrence Management Plan" called for a follow-up study that would develop a "Name Collision Occurrence Management Framework" [NCOMF]. In February 2014, the document, "Mitigating the Risk of DNS Namespace Collisions: Phase One Report," was published by the ICANN-contracted group JAS Global Advisors [MRDNC]. The report provides a number of recommendations for addressing the name collision issue focusing on a technique termed "controlled interruption," in which a registry would temporarily resolve all SLDs (or all SLDs present in the block list) to a specific IP: 127.0.53.53. The report also makes provisions to implement an emergency plan and strategy in case name collisions had a "clear danger to human life."
作为进一步规定，“新gTLD碰撞发生管理计划”要求进行后续研究，以制定“名称碰撞发生管理框架”[NCOMF]。2014年2月，ICANN签约集团JAS Global Advisors[MRDNC]发布了文件“降低DNS命名空间冲突风险：第一阶段报告”。该报告提供了一些解决名称冲突问题的建议，重点是一种称为“受控中断”的技术，其中注册表将临时将所有SLD（或阻止列表中的所有SLD）解析为特定IP:127.0.53.53。该报告还规定，在发生“明显危及人类生命”的情况下，实施应急计划和战略
In the time frame after the workshop, a final version of the Phase One Report was released in June 2014 [MRDNC].
在研讨会结束后的时间框架内，第一阶段报告的最终版本于2014年6月发布[MRDNC]。
In July 2014, after a community review phase, a final recommendation was issued by ICANN [NCOMFINAL]; this has been followed by the publication of management documents for the implementation of a controlled interrupt for new gTLD delegations [NOCA] [NCSLDCIV] [ADDNOCA].
2014年7月，经过社区审查阶段，ICANN[NCOMFINAL]发布了最终建议；随后，发布了新gTLD代表团受控中断实施的管理文件[NOCA][NCSLDCIV][ADDNOCA]。
Much of the framework called for in the Name Collision Occurrence Management Framework [NCOMF] was not released by the time of writing this document, and the Phase One Report [MRDNC] indicated that its publication was delayed due to a security vulnerability [JASBUG] identified during the course of the work.
在编写本文档时，冲突发生管理框架[NCOMF]的名称中要求的大部分框架尚未发布，第一阶段报告[MRDNC]表明，由于在工作过程中发现了安全漏洞[JASBUG]，因此其发布被推迟。
Broad community efforts to measure the impact of name collisions were not included in the final recommendation issued by ICANN [NCOMFINAL]. At the time of this writing, RSSAC has just published its specification of common measurements to be collected by root operators, meeting one part of the needs for measurements of the root server system [RSSAC002].
ICANN发布的最终建议[NCOMFINAL]中没有包括广泛的社区努力来衡量名称冲突的影响。在撰写本文时，RSSAC刚刚发布了由根操作人员收集的通用度量规范，满足了根服务器系统度量需求的一部分[RSSAC002]。
The Workshop and Prize on Root Causes and Mitigation of Name Collisions [WPNC], sponsored by Verisign, took place March 8-10, 2014 in London, United Kingdom. The WPNC was open to the public, and it gathered subject-area specialists, researchers, and practitioners to discuss and present their views, concerns, and ideas surrounding the name collision issue. Proceedings are published at the workshop's website [WPNC].
2014年3月8日至10日，Verisign在英国伦敦举办了关于名称冲突的根本原因和缓解[WPNC]的研讨会和奖项。WPNC向公众开放，它聚集了学科领域的专家、研究人员和从业者，讨论并提出他们对名称冲突问题的看法、关注和想法。会议记录在研讨会网站[WPNC]上发布。
The workshop focused on studies of name collision risks and mitigations with the expectation to advance the global community's insight into operational uses of name suffixes that can result in name collisions and to gain a stronger understanding of the potential risks for the users of the installed systems. Additional emphasis and attention was given to discussions that might advance the state of knowledge about the architecture and impacts of DNS namespaces with multiple scopes or resolution contexts and the utilization of new methods of monitoring and understanding the needs and methods for mitigating emerging Internet risks around name collisions. A technical program committee, whose members spanned a variety of organizations and universities, was assembled. The committee issued a call for papers and evaluated all submissions to ensure the highest level of quality.
研讨会侧重于名称冲突风险和缓解措施的研究，以期推动全球社会深入了解可能导致名称冲突的名称后缀的操作使用，并更好地了解已安装系统用户的潜在风险。会议还进一步强调和关注了一些讨论，这些讨论可能会提高人们对具有多个作用域或解析上下文的DNS名称空间的体系结构和影响的认识，以及利用新的方法来监测和了解缓解名称周围新出现的互联网风险的需要和方法碰撞。成立了一个技术项目委员会，其成员遍布各种组织和大学。委员会发出征集论文的呼吁，并对所有提交的文件进行评估，以确保最高水平的质量。
A synthesis of the accepted papers and conference proceedings is captured in the subsections below. Another informal synopsis of the workshop combined with individual statements and observations is available online [COMMENTARY].
下面各小节将对接受的论文和会议记录进行综合。另一个非正式的研讨会概要，结合个人的发言和观察，可在网上查阅[评注]。
Many of the research papers focused on the analysis of DITL data to better understand various aspects of the root NXDOMAIN traffic ([TECHNIQUES], [RARDBITS], [BLOCKLISTS], [MODELING], and [SEARCHLISTS]). Note: all workshop contributions are listed in Appendix B; full papers and slides are available at the website [WPNC].
许多研究论文侧重于DITL数据的分析，以更好地理解根域流量的各个方面（[技术]、[RARDBITS]、[块列表]、[建模]和[搜索列表]）。注：附录B中列出了所有研讨会贡献；全文和幻灯片可在[WPNC]网站上查阅。
While the DITL data has become the de facto referential dataset for root traffic analysis, some presenters echoed concerns that the dataset may have become biased or polluted with "artificial" queries after the ICANN "Reveal Day," in which the list of applied-for gTLD strings was publicly disclosed. No conclusive or empirical evidence of tampering was presented; however, concerns about the integrity and reliability of future DITL collections and analysis for purposes related to new gTLDs were echoed by some panelists [IESCPANEL]. Furthermore, the statistical accuracy and completeness of DITL data -- used to draw inferential conclusions or more specifically create SLD block lists -- was examined. The efficacy of blocking domains based on sampled DNS data, e.g., DITL, was investigated by comparing measurements of SLDs within DITL and that of a multi-month root NXDOMAIN collection at the A and J roots [BLOCKLISTS]. The findings provided insights into SLD-root affinities, SLD temporal query patterns and occurrence frequencies that demonstrated the ineffectiveness of block listing domains based on sampled DNS data such as [DITL].
虽然DITL数据已成为根流量分析的事实参考数据集，但一些演讲者也表示担心，在ICANN“披露日”之后，数据集可能会出现偏差或受到“人为”查询的污染，在ICANN“披露日”中，已申请的gTLD字符串列表被公开披露。没有提出篡改的结论性或经验证据；然而，一些专家组成员对未来DITL收集和分析的完整性和可靠性表示担忧，以用于与新GTLD相关的目的[IESCPANEL]。此外，还检查了DITL数据的统计准确性和完整性——用于得出推断结论或更具体地创建SLD阻止列表。通过比较DITL内SLD的测量值与a和J根多个月根域集合的SLD测量值，研究了基于采样DNS数据（例如DITL）的阻塞域的有效性[Blocklist]。这些发现提供了对SLD根亲和力、SLD时间查询模式和出现频率的深入了解，证明了基于采样DNS数据（如[DITL]）的块列表域的无效性。
Measurements of queries specifying the recursion desired (RD) bit to the roots in DITL were quantified to identify the level and nature of naive DNS clients and to determine and assess potential impacts that could arise from the proposed SLD blocking technique to these naive clients [RARDBITS]. A substantial proportion of the root server request traffic contained queries with the RD bit specified. Both in absolute and relative terms, requests specifying the RD bit for applied-for gTLDs were found to be significantly lower when compared to existing TLDs. The root cause determination of what system or mechanism is responsible for generating the queries was inconclusive and only speculative explanations of faulty implementations of a DNS resolving server were hypothesized. However, the analysis was also not able to identify instances of actual or potential harm resulting from these naive clients, suggesting if SLD blocking techniques were to be utilized, it is unlikely there would be any negative impact to these naive clients.
对指定DITL中根的递归期望（RD）位的查询的测量进行了量化，以确定幼稚DNS客户端的级别和性质，并确定和评估提议的SLD阻塞技术可能对这些幼稚客户端产生的潜在影响[RARDBITS]。根服务器请求流量的很大一部分包含指定了RD位的查询。无论是从绝对值还是相对值来看，与现有TLD相比，为GTD指定RD位的请求被发现显著降低。关于哪个系统或机制负责生成查询的根本原因确定没有定论，只假设了DNS解析服务器错误实现的推测性解释。然而，分析也无法确定这些幼稚客户造成的实际或潜在伤害的实例，这表明如果使用SLD阻止技术，不太可能对这些幼稚客户产生任何负面影响。
Comparison of elements can often help us to understand a system as a whole. A passive study of the DNS traffic in a provisioned domain such as "corp.com" may elucidate certain name collision parallels [CORPCOM]. Such measurements were presented as a proxy for the ".corp" potential new gTLD. According to the study, significant DNS traffic volume was directed at a variety of third-level domains under "corp.com". This prompted a series of questions surrounding how name collisions can be identified, as most end-users won't recognize that problems may be due to a name collision. How will users know that the problem they are experiencing is a result of a new, colliding gTLD? Will support groups be able to diagnose a name collision event from reported symptom(s)? Will a collision-based security hole be detectable?
元素的比较通常可以帮助我们从整体上理解系统。对诸如“corp.com”之类的配置域中的DNS流量的被动研究可能会阐明某些名称冲突并行[CORPCOM]。这些测量值是作为“.corp”潜在新gTLD的替代值提供的。根据这项研究，大量DNS流量是针对“corp.com”下的各种三级域名的。这引发了一系列关于如何识别名称冲突的问题，因为大多数最终用户不会意识到问题可能是由名称冲突引起的。用户如何知道他们遇到的问题是新的、冲突的gTLD造成的？支持组是否能够根据报告的症状诊断名称冲突事件？基于碰撞的安全漏洞是否可检测？
These questions, upon which underpinnings rely on communication and educational awareness, may find recommendations or parallels from other system references during the workshop [JASFRAMEWORK] -- such as the postal and telephone system. Most telephone and postal systems have evolved over time, requiring individuals to alter the way they address their parcels or place their calls. Both systems implemented their changes in such a way that prior to the change, educational material is distributed and communicated and for a period of time and after the change, compliance of the previous standard is temporarily accepted. While the telephone and postal system operate in a very different way than the DNS, these parallels of "advanced notification, education and communication, and a grace period" were insightful for how other similar systems transitioned.
这些问题的基础依赖于沟通和教育意识，在研讨会[JASFRAMEWORK]期间，可以从其他系统参考中找到建议或相似之处，例如邮政和电话系统。大多数电话和邮政系统都是随着时间的推移而发展的，需要个人改变他们处理包裹或打电话的方式。这两个系统实施变更的方式是，在变更之前，分发和传达教育材料，在一段时间内和变更之后，暂时接受对先前标准的遵守。虽然电话和邮政系统的运作方式与DNS截然不同，但这些“先进的通知、教育和通信以及宽限期”的相似之处对于其他类似系统的过渡方式有着深刻的见解。
Statements from several TLD operators during the conference reverberated a theme for the need of improved tooling, education, and communication surrounding name collisions. The delegation of new gTLDs is an ongoing event, and there is a clear and immediate need for these operators to have visibility to monitor and measure the effects of these new gTLD delegations. A lack of tools, shared data, communication, and education surrounding name collisions has handicapped operators in their ability to quantitatively measure and proactively provide any steps for mitigation of risks. To this end, numerous techniques, frameworks, and models that focused on the concepts of analyzing, detecting, and measuring various name collision risk factors were presented and reviewed with the hope of understanding these underlying concerns and issues ([TECHNIQUES] [MODELING] [SEARCHLISTS] [DNSENDUSER] [ENTNETWORK]).
几位TLD运营商在会议期间的发言反映了一个主题，即围绕名称冲突改进工具、教育和沟通的需求。新gTLD的授权是一项持续的活动，这些运营商显然迫切需要有可见性来监控和测量这些新gTLD授权的效果。由于缺乏工具、共享数据、通信和有关名称冲突的教育，运营商无法定量衡量并主动提供任何风险缓解措施。为此，提出并审查了许多技术、框架和模型，这些技术、框架和模型侧重于分析、检测和测量各种名称冲突风险因素的概念，希望了解这些潜在的关注点和问题（[技术][建模][搜索列表][DNSENDUSER][ENTNETWORK]）。
Data-driven analysis and mitigation require operators to be versed and skilled with data analysis techniques to better understand the contextual intent and ownership of DNS queries. An overview of various DNS analysis techniques in which ways of decomposing names, measuring temporal distributions between queries, and detecting organizational/geographical affinities was presented [TECHNIQUES]. More-specific techniques were also showcased, such as a systematic way of observing and characterizing the impact of search lists within root DNS traffic allowing operators to quantify the number of unique entities that may be reliant on a particular name space [SEARCHLISTS]. While not exhaustive, the techniques presented have been proven to elucidate patterns within root DNS traffic data and could serve as the potential building blocks of a DNS analysis framework.
数据驱动的分析和缓解要求运营商精通数据分析技术，以便更好地理解DNS查询的上下文意图和所有权。概述了各种DNS分析技术，其中介绍了分解名称、测量查询之间的时间分布以及检测组织/地理亲缘关系的方法[技术]。还展示了更为具体的技术，例如观察和描述根DNS流量中搜索列表影响的系统方法，允许运营商量化可能依赖于特定名称空间的唯一实体的数量[SearchList]。虽然并非详尽无遗，但所介绍的技术已被证明可阐明根DNS流量数据中的模式，并可作为DNS分析框架的潜在构建块。
Most of the previously published work focused on name collisions has produced various quantitative analyses based on observations of Internet traffic and data, including DNS queries and web content, in which behavior and associated risks have been inferred. An understanding of the inverse of the process by starting with a fundamental model of name resolution at the client was proposed as an alternative means to define risk [MODELING]. This model deconstructed the process of name resolution at the resolver library of a client system and formalized a model from which derived metrics could be used to define and quantify associated risks. While the model presented is only a piece of the greater name collision puzzle, it provides potentially new insights into what may otherwise be considered a missing piece.
以前发表的大多数关于名称冲突的工作都基于对互联网流量和数据的观察，包括DNS查询和web内容，进行了各种定量分析，其中推断了行为和相关风险。建议从客户名称解析的基本模型入手，理解流程的逆过程，以此作为定义风险的替代方法[建模]。该模型解构了客户机系统的解析器库中的名称解析过程，并形式化了一个模型，从中可以使用派生的度量来定义和量化相关风险。虽然提出的模型只是更大的名称冲突难题的一部分，但它为可能被视为缺失的部分提供了潜在的新见解。
Just as important as understanding the root causes of name collisions, providing effective mitigation strategies is a critical piece of the name collision puzzle. Mitigation can be achieved from both higher levels, such as ICANN, as well as the enterprise level. Proposed strategies for mitigating name collisions at both of these levels were presented. While the technical details for each proposed strategy varies, underlying dependencies in both strategies require operators to monitor and educate/train their users.
与理解名称冲突的根本原因一样重要的是，提供有效的缓解策略是名称冲突难题的关键部分。缓解措施可以从较高级别（如ICANN）和企业级别实现。提出了在这两个层次上缓解名称冲突的建议策略。虽然每种拟议策略的技术细节各不相同，但这两种策略的潜在依赖性都要求运营商监控和教育/培训其用户。
In their concluding statement [NEXTSTEPS], the workshop committee stated:
研讨会委员会在其结论声明[下一步]中指出：
It occurs to the program committee that the analysis of the interactions between the different uses of domain names within local or global context is almost a nonexistent topic of research. This may have to do with the lack of accessible data, lack of theory of root causes, a lack of interest, or a bias in the participation of the workshop. We think that this is evidence that this study of the global centrally important technical system needs to be ramped up.
项目委员会意识到，在本地或全球范围内，域名不同用途之间的相互作用分析几乎是一个不存在的研究主题。这可能与缺乏可获取的数据、缺乏根本原因理论、缺乏兴趣或参与研讨会的偏见有关。我们认为，这证明，需要加强对全球中心重要技术系统的研究。
Follow-on commentary [NEXTSTEPS] from the attendees reaffirmed this opinion with recurring messages of a need to understand the root causes of name collision and the need to overcome shortcomings within our shared data collection, monitoring, and analysis of the DNS.
与会者的后续评论[NEXTSTEPS]重申了这一观点，反复强调需要了解名称冲突的根本原因，需要克服DNS共享数据收集、监控和分析中的缺陷。
Many name collision unknowns still exist. What are the root causes of these queries? What is going on within a recursive name server? What vulnerabilities or subtle attack vectors do these new gTLD delegations enable? The limited datasets available to researchers and operators are not sufficient to draw baseline measurements for these questions, forcing the community to make inferences and rank guesses as to what is going on within the DNS. Using these suboptimal data repositories to create solutions such as block lists is only dealing with the symptoms of the problem and not addressing the root cause. To properly answer these questions, the community needs to address the issue of a shortage of funding and data collection/analysis. Communication and educational outreach programs need to be improved in order raise the awareness of impacted parties and broaden participation and sharing.
许多名称冲突未知数仍然存在。这些查询的根本原因是什么？递归名称服务器中发生了什么？这些新的gTLD授权启用了哪些漏洞或微妙的攻击向量？研究人员和操作员可用的有限数据集不足以为这些问题绘制基线测量值，迫使社区对DNS内发生的情况进行推断和排名猜测。使用这些次优的数据存储库来创建解决方案（如阻止列表）只是处理问题的症状，而不是解决问题的根本原因。为了正确回答这些问题，社区需要解决资金短缺和数据收集/分析问题。需要改进沟通和教育外联计划，以提高受影响方的意识，扩大参与和分享。
Workshop participants discussed security aspects related to root cause analysis and mitigation techniques of potential name collision events. As noted in several papers and presentations, security concerns may both arise and be addressed with name collision mitigation techniques. Follow-on measurement-based research is important to security considerations for name collisions.
研讨会参与者讨论了与潜在名称冲突事件的根本原因分析和缓解技术相关的安全方面。正如在几篇论文和演示文稿中所指出的，安全问题可能会同时出现，并通过名称冲突缓解技术加以解决。基于度量的后续研究对于名称冲突的安全考虑非常重要。
[ADDNOCA] ICANN, "Addendum To Name Collision Occurrence Assessment", November 2014, <http://newgtlds.icann.org/sites/default/files/ agreements/name-collision-assessment-addendum-14nov14-en.htm>.
[ADDNOCA]ICANN，“名称碰撞发生评估附录”，2014年11月<http://newgtlds.icann.org/sites/default/files/ 协议/name-collision-assessment-address-14nov14-en.htm>。
[BLOCKLISTS] Thomas, M., Labrou, Y., and A. Simpson, "The Effectiveness of Block Lists in Preventing Collisions", March 2014, <http://namecollisions.net/program/index.html>.
[区块清单]Thomas，M.，Labrou，Y.，和A.Simpson，“区块清单在防止碰撞方面的有效性”，2014年3月<http://namecollisions.net/program/index.html>.
[COMMENTARY] Kaliski, B., "Proceedings of Name Collisions Workshop Available", March 2014, <http://www.circleid.com/posts/20140326_proceedings_ of_name_collisions_workshop_available/>.
[评论]Kaliski，B.，“名称碰撞研讨会论文集”，2014年3月<http://www.circleid.com/posts/20140326_proceedings_ 名称、碰撞、车间、可用/>。
[CORPCOM] Strutt, C., "Looking at corp.com as a proxy for .corp", March 2014, <http://namecollisions.net/program/index.html>.
[CORPCOM]Strutt，C.，“将corp.com视为.corp.的代理”，2014年3月<http://namecollisions.net/program/index.html>.
[DITL] Center for Applied Internet Data Analysis, "A Day in the Life of the Internet (DITL)", July 2011, <http://www.caida.org/projects/ditl/>.
[DITL]应用互联网数据分析中心，“互联网生活中的一天”（DITL），2011年7月<http://www.caida.org/projects/ditl/>.
[DNS-OARC] Mitchell, K., "DNS-OARC", March 2014, <http://namecollisions.net/program/index.html>.
[DNS-OARC]Mitchell，K.，“DNS-OARC”，2014年3月<http://namecollisions.net/program/index.html>.
[DNSENDUSER] Huston, G., "Measuring DNS Behaviors from the End User Perspective", March 2014, <http://namecollisions.net/program/index.html>.
[DNSENDUSER]Huston，G.“从最终用户的角度衡量DNS行为”，2014年3月<http://namecollisions.net/program/index.html>.
[ENTNETWORK] Hoffman, P., "Name Collision Mitigation for Enterprise Networks", March 2014, <http://namecollisions.net/program/index.html>.
[ENTNETWORK]Hoffman，P.，“企业网络的名称冲突缓解”，2014年3月<http://namecollisions.net/program/index.html>.
[IAB2008] IAB, "The IAB's response to ICANN's solicitation on DNS stability", March 2008, <https://www.iab.org/documents/correspondence-reports-documents/docs2008/2008-03-07-icann-new-gtlds/>.
[IAB 2008]IAB，“IAB对ICANN关于DNS稳定性的请求的回应”，2008年3月<https://www.iab.org/documents/correspondence-reports-documents/docs2008/2008-03-07-icann-new-gtlds/>.
[IESCPANEL] Woolf, S., Koch, P., Kolkman, O., Kumari, W., and J. Levine, "Internet Engineering and Standards Considerations", March 2014, <http://namecollisions.net/program/index.html>.
[IESCPANEL]Woolf，S.，Koch，P.，Kolkman，O.，Kumari，W.，和J.Levine，“互联网工程和标准考虑”，2014年3月<http://namecollisions.net/program/index.html>.
[INTERISLE] ICANN, "Name Collision in the DNS", Version 1.5, August 2013, <https://www.icann.org/en/about/staff/security/ ssr/name-collision-02aug13-en.pdf>.
[INTERISLE]ICANN，“DNS中的名称冲突”，1.5版，2013年8月<https://www.icann.org/en/about/staff/security/ ssr/name-collision-02aug13-en.pdf>。
[IR2012] ICANN, "Preliminary Report | Regular Meeting of the ICANN Board", September 2012, <http://www.icann.org/en/groups/ board/documents/prelim-report-13sep12-en.htm>.
[IR2012]ICANN，“初步报告| ICANN董事会定期会议”，2012年9月<http://www.icann.org/en/groups/ board/documents/prelim-report-13sep12-en.htm>。
[ISTUDY] ICANN, "Security Studies on the Use of Non-Delegated TLDs, and Dotless Names", May 2013, <https://www.icann.org/en/news/announcements/ announcement-28may13-en.htm>.
[ISTUDY]ICANN，“非授权TLD和无点名称使用的安全研究”，2013年5月<https://www.icann.org/en/news/announcements/ 公告-28may13-en.htm>。
[JASBUG] Common Vulnerabilities and Exposures, "Group Policy Remote Code Execution Vulnerability", CVE-2015-0008, February 2015, <http://www.cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2015-0008>.
[JASBUG]常见漏洞和暴露，“集团政策远程代码执行漏洞”，CVE-2015-000815年2月<http://www.cve.mitre.org/cgi-bin/ cvename.cgi？name=CVE-2015-0008>。
[JASFRAMEWORK] Schmidt, J., "Name Collisions Management Framework", March 2014, <http://namecollisions.net/program/index.html>.
[JASFRAMEWORK]Schmidt，J.，“名称冲突管理框架”，2014年3月<http://namecollisions.net/program/index.html>.
[KEEPEYE] Schneier, B., "Keeping an Eye on Name Collisions", March 2014, <http://namecollisions.net/program/index.html>.
[KEEPEYE]Schneier，B.，“关注名字冲突”，2014年3月<http://namecollisions.net/program/index.html>.
[MODELING] Deccio, C. and D. Wessels, "What's in a Name (Collision): Modeling and Quantifying Collision Potential", March 2014, <http://namecollisions.net/program/index.html>.
[建模]Deccio，C.和D.Wessels，“名称中的内容（碰撞）：建模和量化碰撞可能性”，2014年3月<http://namecollisions.net/program/index.html>.
[MRDNC] ICANN, "Mitigating the Risk of DNS Namespace Collisions: A Study on Namespace Collisions in the Global Internet DNS Namespace and a Framework for Risk Mitigation", February 2014, <https://www.icann.org/en/about/staff/ security/ssr/name-collision-mitigation-26feb14-en.pdf>.
[MRDNC]ICANN，“降低DNS名称空间冲突的风险：全球互联网DNS名称空间中名称空间冲突的研究和风险缓解框架”，2014年2月<https://www.icann.org/en/about/staff/ security/ssr/name-collision-migration-26feb14-en.pdf>。
[NCOMF] ICANN, "ICANN Selects Lead for Development of Name Collision Occurrence Management Framework", November 2013, <http://www.icann.org/en/news/announcements/ announcement-2-11nov13-en.htm>.
[NCOMF]ICANN，“ICANN选择开发名称冲突发生管理框架的领导”，2013年11月<http://www.icann.org/en/news/announcements/ 公告-2-11nov13-en.htm>。
[NCOMFINAL] ICANN, "Name Collision Occurrence Management Framework", July 2014, <https://www.icann.org/en/system/files/files/ name-collision-framework-30jul14-en.pdf>.
[NCOMFINAL]ICANN，“名称冲突发生管理框架”，2014年7月<https://www.icann.org/en/system/files/files/ name-collision-framework-30jul14-en.pdf>。
[NCRI] ICANN, "Name Collision Resources & Information", <http://www.icann.org/en/help/name-collision>.
[NCRI]ICANN，“名称冲突资源和信息”<http://www.icann.org/en/help/name-collision>.
[NCSLDCIV] ICANN, "Name Collision SLD Controlled Interruption Variations", September 2014, <http://newgtlds.icann.org/sites/default/files/ agreements/name-collision-sld-controlled-interruption-12sep14-en.htm>.
[NCSLDCIV]ICANN，“名称冲突SLD控制中断变化”，2014年9月<http://newgtlds.icann.org/sites/default/files/ 协议/name-collision-sld-controlled-interruption-12sep14-en.htm>。
[NEXTSTEPS] Kaliski, B., "Workshop Wrap-Up and Next Steps", March 2014, <http://namecollisions.net/program/index.html>.
[NEXTSTEPS]Kaliski，B.，“研讨会总结和下一步”，2014年3月<http://namecollisions.net/program/index.html>.
[NGCOMP] ICANN, "New gTLD Collision Risk Mitigation", August 2013, <https://www.icann.org/en/about/staff/security/ssr/ new-gtld-collision-mitigation-05aug13-en.pdf>.
[NGCOMP]ICANN，“新gTLD碰撞风险缓解”，2013年8月<https://www.icann.org/en/about/staff/security/ssr/ new-gtld-collision-Milization-05aug13-en.pdf>。
[NOCA] ICANN, "Name Collision Occurrence Assessment", August 2014, <http://newgtlds.icann.org/sites/default/files/ agreements/name-collision-assessment-04aug14-en.htm>.
[NOCA]ICANN，“名称碰撞发生评估”，2014年8月<http://newgtlds.icann.org/sites/default/files/ 协议/name-collision-assessment-04aug14-en.htm>。
[RARDBITS] Reid, J., "Analysing the Use of the RA and RD bits in Queries to Root Servers", March 2014, <http://namecollisions.net/program/index.html>.
[RARDBITS]Reid，J.“分析根服务器查询中RA和RD位的使用”，2014年3月<http://namecollisions.net/program/index.html>.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, <http://www.rfc-editor.org/info/rfc1591>.
[RFC1591]Postel，J.，“域名系统结构和授权”，RFC 1591，DOI 10.17487/RFC15911994年3月<http://www.rfc-editor.org/info/rfc1591>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <http://www.rfc-editor.org/info/rfc2606>.
[RFC2606]Eastlake 3rd，D.和A.Panitz，“保留顶级域名”，BCP 32，RFC 2606，DOI 10.17487/RFC2606，1999年6月<http://www.rfc-editor.org/info/rfc2606>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <http://www.rfc-editor.org/info/rfc6761>.
[RFC6761]Cheshire，S.和M.Krochmal，“特殊用途域名”，RFC 6761，DOI 10.17487/RFC6761，2013年2月<http://www.rfc-editor.org/info/rfc6761>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<http://www.rfc-editor.org/info/rfc7719>.
[RSSAC] Murai, J., "RSSAC response to the root scaling report", November 2010, <http://www.icann.org/en/news/ correspondence/murai-to-board-25nov10-en.pdf>.
[RSSAC]Murai，J.，“RSSAC对根结垢报告的响应”，2010年11月<http://www.icann.org/en/news/ 通信/murai-to-board-25nov10-en.pdf>。
[RSSAC002] ICANN Root Server System Advisory Committee, "Advisory on Measurements of the Root Server System", November 2014, <https://www.icann.org/en/system/files/files/ rssac-002-measurements-root-20nov14-en.pdf>.
[RSSAC002]ICANN根服务器系统咨询委员会，“根服务器系统测量咨询”，2014年11月<https://www.icann.org/en/system/files/files/ rssac-002-measurements-root-20nov14-en.pdf>。
[SAC045] ICANN Security and Stability Advisory Committee, "Invalid Top Level Domain Queries at the Root Level of the Domain Name System", SAC 045, November 2010, <https://www.icann.org/en/groups/ssac/documents/ sac-045-en.pdf>.
[SAC045]ICANN安全与稳定咨询委员会，“域名系统根级别的顶级域名查询无效”，SAC0452010年11月<https://www.icann.org/en/groups/ssac/documents/ sac-045-en.pdf>。
[SAC046] ICANN Security and Stability Advisory Committee, "Report of the Security and Stability Advisory Committee on Root Scaling", SAC 046, December 2010, <https://www.icann.org/en/groups/ssac/documents/ sac-046-en.pdf>.
[SAC046]ICANN安全与稳定咨询委员会，“安全与稳定咨询委员会关于根标度的报告”，SAC046，2010年12月<https://www.icann.org/en/groups/ssac/documents/ sac-046-en.pdf>。
[SAC057] ICANN Security and Stability Advisory Committee, "SSAC Advisory on Internal Name Certificates", SAC057, March 2013, <http://www.icann.org/en/groups/ssac/documents/ sac-057-en.pdf>.
[SAC057]ICANN安全与稳定咨询委员会，“SSAC内部姓名证书咨询”，SAC057，2013年3月<http://www.icann.org/en/groups/ssac/documents/ sac-057-en.pdf>。
[SEARCHLISTS] Simpson, A., "Detecting Search Lists in Authoritative DNS", March 2014, <http://namecollisions.net/program/index.html>.
[SearchList]Simpson，A.，“在权威DNS中检测搜索列表”，2014年3月<http://namecollisions.net/program/index.html>.
[TECHNIQUES] Thomas, M. and A. Simpson, "Analysis Techniques for Determining Cause and Ownership of DNS Queries", March 2014, <http://namecollisions.net/program/index.html>.
[技术]Thomas，M.和A.Simpson，“确定DNS查询原因和所有权的分析技术”，2014年3月<http://namecollisions.net/program/index.html>.
[WPNC] Verisign, "Workshop and Prize on Root Causes and Mitigation of Name Collisions (WPNC)", June 2014, <http://namecollisions.net/>.
[WPNC]Verisign，“名称冲突的根本原因和缓解（WPNC）研讨会和奖项”，2014年6月<http://namecollisions.net/>.
This workshop program committee consisted of Geoff Huston, Burt Kaliski, Olaf Kolkman, John Levine, Allison Mankin, Lixia Zhang, Anne-Marie Eklund Loewinder, and Andrew Sullivan.
该研讨会项目委员会由杰夫·休斯顿、伯特·卡利斯基、奥拉夫·科尔克曼、约翰·莱文、埃里森·曼金、张丽霞、安妮·玛丽·埃克伦德·勒文德和安德鲁·沙利文组成。
Main Workshop Page: <http://namecollisions.net/>
Main Workshop Page: <http://namecollisions.net/>
Name Collision Invited and Submitted Papers, Panels, and Videos:
<http://namecollisions.net/program/index.html>
Name Collision Invited and Submitted Papers, Panels, and Videos:
<http://namecollisions.net/program/index.html>
The peer-reviewed papers were:
同行评审的论文包括：
o "Analysis Techniques for Determining Cause and Ownership of DNS Queries" [TECHNIQUES],
o “确定DNS查询原因和所有权的分析技术”[技术]，
o "Analysing the Use of the RA and RD bits in Queries to Root Servers" [RARDBITS],
o “分析根服务器查询中RA和RD位的使用”[RARDBITS]，
o "The Effectiveness of Block Lists in Preventing Collisions" [BLOCKLISTS],
o “阻止列表在防止冲突方面的有效性”[阻止列表]，
o "What's in a Name (Collision): Modeling and Quantifying Collision Potential" [MODELING], and
o “名称中的内容（碰撞）：建模和量化碰撞可能性”[建模]，以及
o "Detecting Search Lists in Authoritative DNS" [SEARCHLISTS].
o “检测权威DNS中的搜索列表”[SearchList]。
The invited talks were:
应邀参加的会谈有：
o "Keeping an Eye on Name Collisions" [KEEPEYE],
o “关注名称冲突”[KEEPEYE]，
o "Looking at corp.com as a proxy for .corp" [CORPCOM],
o “将corp.com视为corp.com的代理”[CORPCOM]，
o "Measuring DNS Behaviors from the End User Perspective" [DNSENDUSER],
o “从最终用户角度衡量DNS行为”[DNSENDUSER]，
o "DNS-OARC" [DNS-OARC], and
o “DNS-OARC”[DNS-OARC]，以及
o "Name Collision Mitigation for Enterprise Networks" [ENTNETWORK].
o “企业网络的名称冲突缓解”[ENTNETWORK]。
The panels and discussions were:
小组讨论和讨论是：
o "Internet Engineering and Standards Considerations" [IESCPANEL],
o “互联网工程和标准考虑”[IESCPANEL]，
o "Name Collisions Management Framework" [JASFRAMEWORK], and
o “名称冲突管理框架”[JASFRAMEWORK]，以及
o "Workshop Wrap-Up and Next Steps" [NEXTSTEPS].
o “研讨会总结和下一步”[NEXTSTEPS]。
A list of workshop participants is provided at [WPNC].
研讨会参与者名单见[WPNC]。
Acknowledgments
致谢
We would like to thank both the program committee (Appendix A) and the workshop participants (Appendix C), with equal appreciation to those who spoke formally and those who joined in the lively discussions.
我们要感谢项目委员会（附录A）和研讨会参与者（附录C），同样感谢那些正式发言的人和那些参加生动讨论的人。
Additionally, we would like to thank the following people for their review comments: Burt Kaliski, Olaf Kolkman, Ed Lewis, Nevil Brownlee, Tim Wicinski, and Danny McPherson.
此外，我们还要感谢以下人士的评论：伯特·卡利斯基、奥拉夫·科尔克曼、埃德·刘易斯、内维尔·布朗利、蒂姆·维辛斯基和丹尼·麦克弗森。
Authors' Addresses
作者地址
Matthew Thomas Email: mthomas@verisign.com
Matthew Thomas电子邮件：mthomas@verisign.com
Allison Mankin Salesforce Email: allison.mankin@gmail.com
Allison Mankin Salesforce电子邮件：Allison。mankin@gmail.com
Lixia Zhang UCLA Email: lixia@cs.ucla.edu
Lixia Zhang UCLA电子邮件：lixia@cs.ucla.edu