Domain name collisions occur when a domain name used in a private network unintentionally overlaps with a domain name in the public Domain Name System (DNS). This can lead to unexpected redirections or disruptions in network services.
The domain name collision issue was a significant factor in the development of the DNS protocol.
1980s: The Era When Pioneers Invented the DNS
Domain Name System (DNS) traces its roots back to RFC 805, titled “Computer Mail Meeting Notes,” published in February 1982. This document, authored by Jon Postel, outlined the need for a hierarchical naming system to manage the growing complexity of the ARPANET, the precursor to the modern internet.
in the middle of the note says:
Name Domains
One of the interesting ideas that emerged from this discussion was that the “user@host” model of a mailbox identifier should, in principle, be replaced by a “unique-id@location-id” model, where the unique-id would be a globally unique id for this mailbox (independent of location) and the location-id would be advice about where to find the mailbox. However, it was recognized that the “user@host” model was well established and that so many different elaborations of the “user” field were already in use that there was no point in persuing this “unique-id” idea at this time.
RFC 805, Network Working Group, J. Postel, 8 February 1982
It is interesting that nearly half century ago, the pioneers concerned about the duplicated ‘unique-id(identifier)’ concept, and now, we are still concerning about the duplicated unique identifier of modern Internet architecture – domain name.
Then in this RFC 805 proposed extending the existing “user@host” mailbox identifier to “user@host.domain,” where “domain” could represent a hierarchy of domains. This concept laid the foundation for the domain name system, which would allow for more organized and scalable addressing of computers and resources on the expanding network.
Within a few months, the first concepts and specifications for Domain Names emerged with RFC882 and RFC883.
RFC 883, Network Working Group, P. Mockapetris, November 1983
The documents also highlighted several key principles that would shape the development of DNS, including:
Top-level domains (TLDs): The need for TLDs to provide a starting point for delegation of queries, ensuring efficient routing of requests.
Unique second-level domains: The requirement for second-level domains to be unique, necessitating a registrar-type administration to prevent conflicts.
Distributed name servers: The recognition that distributing individual name servers responsible for each domain would provide better administration and maintenance.
Then after a year, in 1984, RFC 920 defined initial set of TLDs:
RFC 920, Network Working Group, J. Postel & J. Reynolds, October 1984
Finally, November 1987, by Network Working Group P. Mockapetris, RFC 1034 and RFC 1035 two fundamental documents that define the Domain Name System is published:
RFC 1034, titled “Domain Names – Concepts and Facilities,” provides a comprehensive overview of the DNS architecture, outlining its purpose, structure, and operational principles.
RFC 1035, titled “Domain Names – Implementation and Specification,” delves into the technical details of DNS implementation. It defines the message formats, resource record types, and communication protocols used by DNS servers to exchange information and resolve domain names.
This concludes the brief history of how the domain name collision issue led to the invention of DNS, a critical component of the internet infrastructure.
The 1980s initial DNS architecture worked well until the 2010s when the Internet Corporation for Assigned Names and Numbers (ICANN) began introducing new generic top-level domains (gTLDs).
In a domain name collision environment, a domain name is used in both a private network and the public network that uses Domain Name System (DNS) of the Internet. This can lead to a situation where a malicious actor at public network intercept and manipulate HTTP as well as HTTPS requests that are intended for a private network resource.
Those are the typical HTTP(S) requests that can be observed on public network side (anonymized some real names):
Malicious actors can always intercept these object requests and spoof the responses to conduct catastrophic attacks. For instance, simply placing a ransomware executable at one of the ‘exe’ executable file paths can damage private networks, or creating a phishing logon page that records login attempts in plaintext can compromise user credentials. Additionally, intercepting further HTTP(S) communications is possible by exploiting the WPAD vulnerability, which is explained in detail in another article.
Reference : [JAS Advisors. (2017). Introducing: The ORDINAL Dataset. https://www.icann.org/en/system/files/files/presentation-ordinal-datasets-colliding-domains-13may17-en.pdf]
When a private (internal) network utilizes an existing public Internet domain name as a private domain name, a domain name collision occurs, potentially causing traffic to escape the private network.
There are two typical misconfigurations can expose private networks to security risks:
1. Allowing the use of public DNS servers within a private network
The first situation involves a device connected to the private network but configured to use public DNS servers for resolving private server IP addresses. For instance, a BYOD laptop might be set to use Google Public DNS (8.8.8.8) to ensure stable Internet connectivity at home.
The problem arises when the user attempts to access an internal server. The device queries the public DNS for the server’s name, leading to a connection attempt to the public server instead of the intended internal one.
To mitigate this vulnerability, the best option is to deploy a network firewall or traffic controller that blocks all outbound DNS queries. This prevents devices on the private network from querying public DNS records, ensuring they remain within the private network.
2. Configuring private DNS servers to query public DNS servers for private domain names
The second situation involves a misconfigured private DNS server that queries public DNS servers for unregistered hostnames. For example, if a user mistypes a URL, say ‘sata.corp.ad’ instead of ‘data.corp.ad’, the private DNS server first checks its internal zone file for ‘sata.corp.ad’. If not found, it queries the public DNS for the location of ‘sata.corp.ad’. The public DNS responds with the public IP address for ‘sata.corp.ad’, which the private DNS relays, leading the internal device to connect to the public ‘sata.corp.ad’.
To mitigate this vulnerability, configure a wildcard DNS record (such as *.corp.ad) pointing to a dummy internal IP address in the private DNS. This ensures that invalid subdomain names match this record, directing mistyped hostnames to the dummy IP address.
So what is the security risk in detail?
In the corp.ad case, the public corp.ad server will simply respond with a 404 not found error and redirect the device to a warning page. However, what if a private network uses an unclaimed or expired domain that a malicious actor can easily hijack and connect it to a dangerous public server?
In such a scenario, the malicious actor could do numerous things with that server. They could redirect any Not Found URLs to a phishing page that mimics a workspace solution login form, or they could create a fake browser update page that tricks users into installing a RAT (remote access trojan). Such actions could lead to a severe security incident.
