summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8023.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8023.txt')
-rw-r--r--doc/rfc/rfc8023.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc8023.txt b/doc/rfc/rfc8023.txt
new file mode 100644
index 0000000..cf22fd4
--- /dev/null
+++ b/doc/rfc/rfc8023.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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.
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 1]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+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
+
+ 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
+
+
+
+Thomas, et al. Informational [Page 2]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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].
+
+ 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.
+
+ 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
+
+
+
+Thomas, et al. Informational [Page 3]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ 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.
+
+ 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.
+
+2. Background and Context
+
+ 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].
+
+ 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
+
+
+
+Thomas, et al. Informational [Page 4]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ 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].
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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
+
+
+
+Thomas, et al. Informational [Page 5]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ 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].
+
+ 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.
+
+ 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."
+
+2.1. Brief Update
+
+ In the time frame after the workshop, a final version of the Phase
+ One Report was released in June 2014 [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].
+
+
+
+
+
+
+Thomas, et al. Informational [Page 6]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ 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.
+
+ 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].
+
+3. Workshop Structure
+
+ 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].
+
+ 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.
+
+ 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].
+
+
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 7]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+3.1. Research Findings
+
+ 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].
+
+ 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].
+
+ 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.
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 8]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+3.2. System Analysis
+
+ 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?
+
+ 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.
+
+3.3. Frameworks: Modeling, Analysis, and Mitigation
+
+ 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]).
+
+
+
+
+
+Thomas, et al. Informational [Page 9]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 10]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+3.4. Conclusions and Next Steps
+
+ 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.
+
+ 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.
+
+4. Security Considerations
+
+ 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.
+
+
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 11]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+5. Informative References
+
+ [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>.
+
+ [BLOCKLISTS] Thomas, M., Labrou, Y., and A. Simpson, "The
+ Effectiveness of Block Lists in Preventing
+ Collisions", March 2014,
+ <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/>.
+
+ [CORPCOM] Strutt, C., "Looking at corp.com as a proxy for
+ .corp", March 2014,
+ <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/>.
+
+ [DNS-OARC] Mitchell, K., "DNS-OARC", March 2014,
+ <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>.
+
+ [ENTNETWORK] Hoffman, P., "Name Collision Mitigation for
+ Enterprise Networks", March 2014,
+ <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/>.
+
+ [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>.
+
+
+
+
+Thomas, et al. Informational [Page 12]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [JASFRAMEWORK] Schmidt, J., "Name Collisions Management Framework",
+ March 2014,
+ <http://namecollisions.net/program/index.html>.
+
+ [KEEPEYE] Schneier, B., "Keeping an Eye on Name Collisions",
+ March 2014,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+
+
+
+
+
+Thomas, et al. Informational [Page 13]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ [NCOMFINAL] ICANN, "Name Collision Occurrence Management
+ Framework", July 2014,
+ <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>.
+
+ [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>.
+
+ [NEXTSTEPS] Kaliski, B., "Workshop Wrap-Up and Next Steps",
+ March 2014,
+ <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>.
+
+ [NOCA] ICANN, "Name Collision Occurrence Assessment",
+ August 2014,
+ <http://newgtlds.icann.org/sites/default/files/
+ agreements/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>.
+
+ [RFC1591] Postel, J., "Domain Name System Structure and
+ Delegation", RFC 1591, DOI 10.17487/RFC1591, March
+ 1994, <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>.
+
+ [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>.
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 14]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [SEARCHLISTS] Simpson, A., "Detecting Search Lists in
+ Authoritative DNS", March 2014,
+ <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>.
+
+ [WPNC] Verisign, "Workshop and Prize on Root Causes and
+ Mitigation of Name Collisions (WPNC)", June 2014,
+ <http://namecollisions.net/>.
+
+
+
+
+
+Thomas, et al. Informational [Page 15]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+Appendix A. Program Committee
+
+ 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.
+
+Appendix B. Workshop Material
+
+ Main Workshop Page: <http://namecollisions.net/>
+
+ 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 "Analysing the Use of the RA and RD bits in Queries to Root
+ Servers" [RARDBITS],
+
+ o "The Effectiveness of Block Lists in Preventing Collisions"
+ [BLOCKLISTS],
+
+ o "What's in a Name (Collision): Modeling and Quantifying Collision
+ Potential" [MODELING], and
+
+ o "Detecting Search Lists in Authoritative DNS" [SEARCHLISTS].
+
+ The invited talks were:
+
+ o "Keeping an Eye on Name Collisions" [KEEPEYE],
+
+ o "Looking at corp.com as a proxy for .corp" [CORPCOM],
+
+ o "Measuring DNS Behaviors from the End User Perspective"
+ [DNSENDUSER],
+
+ o "DNS-OARC" [DNS-OARC], and
+
+ o "Name Collision Mitigation for Enterprise Networks" [ENTNETWORK].
+
+ The panels and discussions were:
+
+ o "Internet Engineering and Standards Considerations" [IESCPANEL],
+
+ o "Name Collisions Management Framework" [JASFRAMEWORK], and
+
+
+
+
+Thomas, et al. Informational [Page 16]
+
+RFC 8023 Name Collisions Workshop November 2016
+
+
+ o "Workshop Wrap-Up and Next Steps" [NEXTSTEPS].
+
+Appendix C. Workshop Participants
+
+ A list of workshop participants is provided at [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.
+
+ 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
+
+ Allison Mankin
+ Salesforce
+ Email: allison.mankin@gmail.com
+
+ Lixia Zhang
+ UCLA
+ Email: lixia@cs.ucla.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas, et al. Informational [Page 17]
+