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.