NCAP Study Two was designed to understand the root cause of most of the name collisions and to also understand the impact of any choice made regarding .CORP, .HOME, and .MAIL.
Read more about Study 2:
History of the Name Collision Analysis Project
Name collision refers to the situation in which a name that is used in one namespace may be used in a different namespace, where users, software, or other functions in that domain may misinterpret it.
In the context of top level domains, the term “name collision” refers to the situation in which a name that is used in the global Domain Name System (DNS) namespace defined in the root zone as published by the root management partners -ICANN and VeriSign, (the RZM namespace) may be used in a different namespace (non-RZM) , where users, software, or other functions in that domain may misinterpret it.
DEFINING "HARM"
We propose the following broad categories based on our analysis of the literature and data reported:
- Interception and Manipulation: Private queries leaking into the public DNS that were previously answered by the root servers can be subsequently received and answered by various parties, either purposefully or unknowingly, after the delegation of a TLD string. In such a scenario, an attacker’s exploitation of name collisions will allow them to intercept and manipulate DNS queries. Through these name collision events, attackers may capitalize on a variety of passive and active attack vectors including reconnaissance/enumeration, MitM attacks, internal or personal document leakage, malicious code injection, and credential theft. Some of these attack vectors and corresponding risks stem from DNS-SD or zero-configuration protocols that utilize the DNS as a bootstrapping mechanism. Coupling those protocols with either intentional rooting of a namespace in an undelegated TLD or through unintended consequences of suffix search lists, these types of queries are often the most exploitable attack vector in a name collision scenario.
- Signaling Interruption: This is likely a spillover of Board question #2 that discusses the role played by negative answers currently returned from queries to the root. Some things that come to my mind would be breakage of applications that utilize the DNS as a signaling tool rather than as a directory (e.g. Chrome startup, Mozilla DoH, etc.). These situations again are likely due to search list processing. Do we want to talk about the impacts of signal changes when controlled interruption is deployed or the TLD is delegated (with registrations)? For example, how a browser would change its user displayed error message from something like “Domain not found: NXDOMAIN” to something around “Cannot connect to….” Another scenario is one in which conditional logic of the returned DNS answer is baked into the application and can be handled in many different ways….making it difficult/impossible to assess/track/remediate/etc. (e.g. Mozilla encoding of 127.0.53.53 into their DoH logic within the application).
