RFC 8023

Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions

📅 published November 2016, from ietf

RFC 8023 ✨ Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions 💅

Okay bestie, let's get into it 🎀 This one is a report (aka Informational, so it's not a Standards Track thing) written by M. Thomas (Salesforce), A. Mankin (Salesforce) and L. Zhang (UCLA). It was published as an Independent Submission in November 2016, and it's giving "here's what happened at a very important meeting" 🦋

It doesn't obsolete or update any other RFCs, so it's just vibing on its own 🌸

Honest tea: the whole point is the drama around name collisions in the DNS, which happen when private names leak into the global DNS 🫠

Abstract 🧚

So this doc is a report on the workshop "Root Causes and Mitigation of Name Collisions" 💖 It went down in London, UK, from March 8 to 10, 2014. The goal was to get people talking about why name collisions happen and how to fix them 🙌 The report gives a bit of background and then sums up what the workshop discussed 📝

Status of This Memo 🌈

Quick reality check: this is not an Internet Standards Track spec. It's just published for info 🎀

It's a contribution to the RFC Series, independent from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's valuable for implementation or deployment 💅 Documents the RFC Editor approves aren't a candidate for any level of Internet Standard. See Section 2 of RFC 7841 for that.

For current status, errata, and feedback, check out http://www.rfc-editor.org/info/rfc8023 ✨

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please actually read those, bestie, because they explain your rights and restrictions 🫶

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 🦋

Okay so this is the big picture, and everyone in the Internet research and engineering community already knows it 😭 Lots of installed systems ask the DNS root about names under a whole bunch of top-level domains (TLDs) 💅 A lot of those TLDs aren't delegated, so the answer is an NXDOMAIN response [RFC7719], which basically means "that name doesn't exist" 🙈

Back in November 2010, the ICANN SSAC report [SAC045] pointed out that adding new TLDs to the DNS root could cause name collisions for names used outside the global Internet 👀 Some systems follow old practices that were never really vetted, and they send queries to the global DNS with name suffixes that people assumed would never become TLDs 💀 Lots of these systems rely, explicitly or implicitly, on the global DNS saying "nope, that suffix doesn't exist" 🫠 Once a new TLD gets delegated, the global DNS might answer differently than it did before 😱

So a name collision happens when you try to resolve a name from a private namespace, the query goes out to the public DNS, and the answer says the name is in the global DNS [NCRI] 🌀 When public and private namespaces overlap, you can get resolution results nobody meant to happen, which can be harmful 🚨 The impact of this global change on installed systems will vary, because name collisions can come from lots of different causes 🎀

In a globally distributed system like the Internet, it's hard but super important to agree on policies for where ownership and autonomy boundaries are 🧚 Name space governance matters a lot so names in the global DNS stay predictable ✨

To keep things unique and interoperable, ICANN (through its coordination of the IANA functions) handles certain responsibilities for Internet DNS root zone management, like generic and country code Top-Level Domains (gTLDs and ccTLDs) 🌸 Before ICANN was created in 1998, seven generic TLDs were defined early on in Internet development [RFC1591] 🍓 Since ICANN formed, ICANN has administered and delegated generic, internationalized, and country code TLDs 💖 During all that, the IETF community realized it needed to reserve name spaces for creating limited sets of internal names without worrying about clashing with current or future TLDs in the global DNS [RFC2606] 🫶

Reserved TLDs [RFC2606] were meant to let operators use them only as a small set of internal reserved names with limited uses 🎀 But education and best practices didn't actually stop people from using special-use domain names [RFC6761] 😭 Instead, other suffixes that weren't reserved (and weren't in conflict at the time) got used a lot 🙈 Plenty of operators and admins made faulty assumptions, sometimes even encouraged by vendor documentation, like "we only use this internally and it can never leak to the global DNS" 💀 Lots of reports and findings have totally disproved that, showing real "DNS leakage" into the global DNS through things like search lists 🚨

In 2012, ICANN launched a new gTLD program to add a potentially unlimited number of new gTLDs to the root zone, to boost competition, innovation, and consumer choice 🌈 With tons of new gTLDs possibly getting delegated in the global DNS, operators or admins using a non-delegated namespace internally might run into "name collision" problems 👑

This document is mainly a report on the March 2014 workshop, which looked at the causes and mitigation of these name collisions and their risks 🦋 It's a companion to the Workshop and Prize on Root Causes and Mitigation of Name Collisions proceedings [WPNC], and it also gives some extra background and context 💅

2. Background and Context 🌸

okay bestie, let's get into the tea 🫖💅 when the workshop was convened, the name collision situation looked like this:

Since early 2008, the ICANN community had been having lots of long discussions about whether the DNS root could scale to fit new gTLDs, and what those changes would do to the rest of the DNS ecosystem 🌍. In March 2008, the Internet Architecture Board (IAB) pointed out that adding suffixes already in use in a bunch of environments could lead to instability [IAB2008]. In December 2010, the Security and Stability Advisory Committee (SSAC) released its report on root scaling. In it, they formalized several recommendations based on "actual measurement, monitoring, and data-sharing capabilities of root zone performance" to help figure out whether root scaling was feasible [SAC046]. Separately, the Root Server System Advisory Committee [RSSAC] agreed in late 2010 on the need to set up standard metrics that every operator would collect and report 📊. The idea was to give the community a baseline for how the whole root server system was performing. With that baseline in place, any negative effect from extra TLDs in the root could potentially be spotted ✨. In late 2012, the ICANN Board affirmed that it needed to work with the root server operators through RSSAC to finish documenting how ICANN and the operators interact on root zone scaling [IR2012].

In March 2013, SSAC published an advisory called "SSAC Advisory on Internal Name Certificates." It flagged 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 in that advisory as part of a broader category of problems. Those problems included installed systems that use a namespace in a private network containing a non-delegated TLD, which later gets delegated into the root. In May 2013, the ICANN Board commissioned a study on the use of TLDs that are not currently delegated at the root level of the global DNS within private name spaces [ISTUDY]. The study focused on potential name collision events between applied-for new gTLDs and non-delegated TLDs that might be used in private namespaces. It also looked at the possibility of name collisions arising from the use of digital certificates, which was the concern raised in the SSAC report on internal name certificates [SAC057].

Between the RSSAC and SSAC advisory statements ([RSSAC] [SAC046]) and ICANN commissioning its study in May 2013, there was real progress on formal, coordinated monitoring and measurement of the root 🙌. RSSAC was getting close to finalizing the specific metrics each root operator would collect, and it had started talking about where the operators would send their data for analysis once it was collected. To properly gauge the risks of new gTLD delegations to the root, you need an established baseline of normal system performance, and that baseline had to be set up well ahead of the new delegations 🕰️. Unfortunately, the RSSAC and SSAC recommendations were executed at the wrong time relative to the commissioned study. The result was a limited pool of data repositories to draw any baseline and risk measurements from 😬.

It's common practice for each root operator to monitor its own root server, and some operators publicly report the status and performance of their services 📡. But as of ICANN's study commissioned in May 2013 [ISTUDY], there was no mechanism for getting a detailed view of the entire root system. The closest thing was the annual "Day in the Life" ([DITL]) data repository. It holds root DNS data from a changing subset of root operators, collected over a short coordinated time period. It was meant for research purposes, not for overall monitoring or an operational view of system health. Because there was no more comprehensive, better-suited data repository for baseline and collision analysis, DITL became the de facto reference dataset for root traffic analysis 🫠.

The commissioned study, conducted by the Interisle Consulting Group, was published in August 2013. Their report "Name Collisions in the DNS" [INTERISLE] was based on [DITL] measurements. It addressed name collisions in the DNS and also recommended options for mitigating the various name collision risks 🛠️. The study sorted strings into categories by 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 called "New gTLD Collision Occurrence Management Plan" [NGCOMP]. The goal was to manage the risk of name collisions within the applied-for gTLDs 🧩. Based on the measurements, ICANN deemed two strings, .home and .corp, to be high risk because they are widely used within internal networks. It decided to indefinitely delay their delegation [INTERISLE]. Strings in the uncalculated-risk classification would have their application process delayed by 2 to 3 months while ICANN did more research into whether the string was high or low risk. Strings in the low-risk classification would face a delay in activating domains until 120 days after contracting with ICANN. That gave time for the change in certificate authority practices recommended in the SSAC report on internal name certificates [SAC057] 🕒.

Within the ICANN proposal [NGCOMP], there was an approach called the "alternative path to delegation." Under it, a registry operator could choose to go ahead with delegation, as long as it initially blocked all second-level domains (SLDs) that appeared in certain DITL datasets while the assessment was completed 🚧. Most of the eligible new gTLD applicants chose this alternative path once they were otherwise approved for delegation. The plan also laid out an outreach campaign to educate system administrators, software developers, and other engineers about the name collision issue and possible mitigation measures 📣.

The "New gTLD Collision Occurrence Management Plan" also called for a follow-up study to develop a "Name Collision Occurrence Management Framework" [NCOMF]. In February 2014, the ICANN-contracted group JAS Global Advisors published "Mitigating the Risk of DNS Namespace Collisions: Phase One Report" [MRDNC] 📝. The report made a number of recommendations for addressing name collisions, focusing on a technique called "controlled interruption." With controlled interruption, a registry would temporarily resolve all SLDs (or all SLDs present in the block list) to one specific IP address: 127.0.53.53. The report also included provisions for an emergency plan and strategy, in case name collisions had a "clear danger to human life" 🚨.

2.1. Brief Update

In the time 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, ICANN issued a final recommendation [NCOMFINAL]. That was followed by the publication of management documents for implementing a controlled interrupt for new gTLD delegations [NOCA] [NCSLDCIV] [ADDNOCA] 🗂️.

A lot of the framework called for in the Name Collision Occurrence Management Framework [NCOMF] had not been released by the time this document was written 😭. The Phase One Report [MRDNC] said its publication was delayed because of a security vulnerability [JASBUG] that was identified during the work.

Broad community efforts to measure the impact of name collisions were not included in the final recommendation ICANN issued [NCOMFINAL]. At the time of writing, RSSAC had just published its specification of common measurements that root operators should collect. That covers one part of the root server system's measurement needs [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. It brought together subject-area specialists, researchers, and practitioners to discuss and present their views, concerns, and ideas about the name collision issue 🗣️. Proceedings are published on the workshop's website [WPNC].

The workshop focused on studies of name collision risks and mitigations. The expectation was to advance the global community's insight into operational uses of name suffixes that can result in name collisions, and to build a stronger understanding of the potential risks for users of installed systems 🧠. Extra emphasis went to discussions that could advance knowledge about the architecture and impacts of DNS namespaces with multiple scopes or resolution contexts. It also covered new methods of monitoring, and the needs and methods for mitigating emerging Internet risks around name collisions 🔍. A technical program committee was assembled, with members from a variety of organizations and universities 🏫. 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] 💜.

3.1. Research Findings

okay so the DITL data has basically become the go-to dataset for root traffic analysis 📊✨ and tons of the papers dug into it to understand 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]. 🎀

bestie, some presenters were lowkey worried the dataset might have gotten biased or polluted with "artificial" queries after the ICANN "Reveal Day," when the list of applied-for gTLD strings was made public 😭. No conclusive or empirical evidence of tampering was presented, BUT some panelists still echoed concerns about the integrity and reliability of future DITL collections and analysis for new gTLD purposes [IESCPANEL]. 🙈 Also, the statistical accuracy and completeness of DITL data (the stuff used to draw inferential conclusions or make SLD block lists) got examined too 🔍. The efficacy of blocking domains based on sampled DNS data, e.g., DITL, was investigated by comparing measurements of SLDs within DITL against a multi-month root NXDOMAIN collection at the A and J roots [BLOCKLISTS]. 🦋 The findings gave insights into SLD-root affinities, SLD temporal query patterns, and occurrence frequencies, and they showed 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 figure out the level and nature of naive DNS clients, and to assess potential impacts the proposed SLD blocking technique could have on 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 than for existing TLDs. ✨ The root cause was inconclusive: only speculative explanations, like faulty implementations of a DNS resolving server, were hypothesized. 🧚 Still, the analysis couldn't identify any instances of actual or potential harm from these naive clients, which suggests that if SLD blocking techniques were used, it is unlikely there would be any negative impact to these naive clients. 🫶

3.2. System Analysis

ngl comparing elements is such a good way to understand a system as a whole 🧠💜 A passive study of the DNS traffic in a provisioned domain such as "corp.com" may point out certain name collision parallels [CORPCOM]. The study used that as a proxy for the ".corp" potential new gTLD 👀, and found significant DNS traffic volume aimed at a variety of third-level domains under "corp.com". 🌈 This raised a bunch of questions about how name collisions can even be identified, since most end-users won't recognize that a problem might be due to a name collision 😩. How will users know that their problem is caused by 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 rely on communication and educational awareness, and they may find recommendations or parallels from other system references during the workshop [JASFRAMEWORK] -- like the postal and telephone system 📮📞. Most telephone and postal systems have evolved over time, which meant individuals had to change how they address parcels or place calls. Both systems handled their changes in a similar way: before the change, educational material was distributed and communicated, and after the change, compliance with the previous standard was temporarily accepted during a grace period ⏳🎀. Even though the telephone and postal systems work very differently from the DNS, these parallels of "advanced notification, education and communication, and a grace period" were super insightful for how other similar systems transitioned 🦋✨.

3.3. Frameworks: Modeling, Analysis, and Mitigation

Statements from several TLD operators during the conference echoed a theme: they really need better tooling, education, and communication around name collisions 🙏💖. New gTLD delegation is an ongoing thing, and there is a clear and immediate need for these operators to have visibility so they can monitor and measure the effects of those delegations 📈. A lack of tools, shared data, communication, and education around name collisions has held operators back from quantitatively measuring risks and proactively providing mitigation steps 😤. To help with this, numerous techniques, frameworks, and models focused on 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]). 🧩

Data-driven analysis and mitigation require operators to be versed in and skilled with data analysis techniques, so they can better understand the contextual intent and ownership of DNS queries 🤓. An overview of various DNS analysis techniques was presented [TECHNIQUES], covering ways of decomposing names, measuring temporal distributions between queries, and detecting organizational/geographical affinities 🗺️. There were also more specific techniques showcased, like a systematic way of observing and characterizing the impact of search lists within root DNS traffic, which lets operators 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 reveal patterns within root DNS traffic data and could serve as potential building blocks of a DNS analysis framework 🏗️✨.

Most of the previously published work on name collisions has produced various quantitative analyses based on observations of Internet traffic and data, including DNS queries and web content, where behavior and associated risks were inferred 🔎. An understanding of the inverse of the process, starting with a fundamental model of name resolution at the client, was proposed as an alternative way 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 is only a piece of the greater name collision puzzle, it provides potentially new insights into what might 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 puzzle 🛡️. Mitigation can be achieved at higher levels, like ICANN, as well as at the enterprise level 🏢. Proposed strategies for mitigating name collisions at both of these levels were presented. While the technical details of each strategy vary, underlying dependencies in both require operators to monitor and educate/train their users 📚🫶.

3.4. Conclusions and Next Steps

In their concluding statement [NEXTSTEPS], the workshop committee said:

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 about needing to understand the root causes of name collisions and needing to overcome shortcomings in 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 aren't enough to draw baseline measurements for these questions, so the community is forced to make inferences and rank guesses about what is going on within the DNS 🎲. Using these suboptimal data repositories to create solutions like block lists is only dealing with the symptoms of the problem, not addressing the root cause 🩹. To properly answer these questions, the community needs to address the shortage of funding and data collection/analysis 💸. Communication and educational outreach programs need to be improved in order to raise awareness among impacted parties and broaden participation and sharing 🌈🎀.

  1. Security Considerations

Okay bestie, this part is SERIOUS 🚨 Workshop participants discussed security aspects related to root cause analysis and mitigation techniques for 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 💜👑.

5. Informative References 📚✨

okay bestie, here's the whole receipts drawer 🧾💅 every source the workshop write-up leaned on, in order, with all the details so you can go find them yourself 🔍

Appendix A. Program Committee 🎀

this workshop's program committee was a squad of legends: Geoff Huston, Burt Kaliski, Olaf Kolkman, John Levine, Allison Mankin, Lixia Zhang, Anne-Marie Eklund Loewinder, and Andrew Sullivan 👑🫶

Appendix B. Workshop Material 🦋

the main workshop page is <http://namecollisions.net/> 🌸

the invited and submitted papers, panels, and videos live at <http://namecollisions.net/program/index.html> 🎬

The peer-reviewed papers were:

  • "Analysis Techniques for Determining Cause and Ownership of DNS Queries" [TECHNIQUES],
  • "Analysing the Use of the RA and RD bits in Queries to Root Servers" [RARDBITS],
  • "The Effectiveness of Block Lists in Preventing Collisions" [BLOCKLISTS],
  • "What's in a Name (Collision): Modeling and Quantifying Collision Potential" [MODELING], and
  • "Detecting Search Lists in Authoritative DNS" [SEARCHLISTS].

The invited talks were:

  • "Keeping an Eye on Name Collisions" [KEEPEYE],
  • "Looking at corp.com as a proxy for .corp" [CORPCOM],
  • "Measuring DNS Behaviors from the End User Perspective" [DNSENDUSER],
  • "DNS-OARC" [DNS-OARC], and
  • "Name Collision Mitigation for Enterprise Networks" [ENTNETWORK].

The panels and discussions were:

  • "Internet Engineering and Standards Considerations" [IESCPANEL],
  • "Name Collisions Management Framework" [JASFRAMEWORK], and
  • "Workshop Wrap-Up and Next Steps" [NEXTSTEPS].

Appendix C. Workshop Participants 🧚

a list of everyone who showed up 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
📦 where this page comes from