The Overlooked Vulnerabilities of the DNS Protocol: What is DNS Tunneling?

What is DNS Tunneling and How Does It Work?

DNS is often called the “phonebook of the internet,” translating human-friendly domain names into IP addresses. Under normal conditions, a DNS query contains only the information needed to resolve a hostname to an IP address. DNS tunneling exploits this protocol by inserting arbitrary data into DNS queries and responses, effectively encoding other communications within the DNS traffic . In a typical DNS tunnel, an attacker sets up a malicious domain and an authoritative DNS server for that domain. Malware or a compromised device inside the target network will then encode data (e.g. stolen information or command-and-control messages) into DNS queries for subdomains of the attacker’s domain . These queries travel as normal DNS requests through the organization’s DNS servers and resolvers, eventually reaching the attacker’s authoritative DNS server, which decodes the hidden data. The attacker’s server can likewise encode responses to send commands or data back to the compromised system. In essence, DNS tunneling establishes a covert, bidirectional channel over DNS, a channel that most network defenses don’t inspect closely, since DNS is usually viewed as benign name resolution traffic.

DNS tunneling represents a critical, yet often underestimated, vulnerability within the DNS protocol. In this first part of our series, we explored what DNS tunneling is, how it operates by exploiting legitimate DNS requests, and the differences between normal DNS traffic flows and tunneled traffic. We also reviewed some of the open-source tools commonly used to facilitate DNS tunneling, highlighting how accessible and adaptable these methods have become.

From a technical standpoint, DNS tunneling works by encoding data from other protocols or applications into DNS messages . For example, an infected client might take a chunk of payload, say part of a file or a command, base32 or base64 encode it, and append it as a subdomain in a DNS query (e.g. <encoded-data>.malicious-domain.com). When the organization’s DNS resolver receives this query, it thinks it’s a normal lookup for an external domain and forwards it to a public DNS resolver, which in turn asks the attacker’s authoritative name server. The authoritative server, controlled by the attacker, receives the query, decodes the data from the subdomain, and may respond with a DNS answer that also contains encoded data in a TXT record or in the field of an A record. The compromised client then decodes that data from the DNS answer. In this way, the attacker and malware establish a two-way communication tunnel hidden inside DNS traffic. Practically any type of data can be tunneled, attackers can exfiltrate sensitive files in small chunks, or send commands to a backdoor implant, all obscured as DNS queries and replies.

Because DNS is such a fundamental service, it is almost always allowed to operate freely. Most DNS queries use UDP on port 53 with fallback to TCP for large responses, and this port is typically open through firewalls and allowed on almost every network . Attackers leverage this by sending their malicious traffic over DNS, knowing that it will bypass many restrictions that would stop other channels. In summary, DNS tunneling repurposes a ubiquitous infrastructure protocol for covert communication. Next, we’ll examine why this technique is so dangerous for companies.

Open-Source DNS Tunneling Tools and Their Capabilities

There are several open-source tools that implement DNS tunneling, each with its own features and use-cases. These tools are often used by penetration testers to bypass captive portals or by attackers to establish C2 channels. Below is a list of some well-known DNS tunneling tools and a comparison of their functionality:

Each of the DNS tunneling-specific tools above can be used maliciously to bypass network defenses. Notably, they are all freely available, lowering the barrier for attackers. Next, we will visualize how normal DNS traffic flows in a network versus how a DNS tunneling attack leverages that flow for illegitimate purposes.

Normal DNS Traffic Flow vs. DNS Tunneling

To better understand DNS tunneling, it’s helpful to contrast it with normal DNS resolution. Figure 1 shows a simplified normal DNS query flow within an organization, while Figure 2 illustrates a DNS tunneling scenario (malicious flow). We will describe each in turn:

In a typical corporate network, clients (user workstations or devices) send DNS queries to a local DNS server (often an internal DNS or one provided by the organization). This DNS server is within the company’s network perimeter, protected by the firewall, and will resolve names on behalf of clients. If the local DNS server doesn’t know the answer (the domain is external), it will forward the query out through the firewall to a public DNS resolver (such as an ISP’s resolver or a service like Google DNS). The firewall permits these DNS requests (UDP/53) to pass because DNS is necessary for connectivity. The public resolver then performs the recursive resolution: it contacts the appropriate authoritative DNS servers for the domain in question. For example, if the client is resolving example.com, the resolver will query the root servers, then the .com TLD servers, and finally the authoritative server for example.com to get the IP address. The answer (the resolved IP) comes back from the authoritative DNS server to the public resolver, and then back through the firewall to the company’s DNS server, and finally to the client. All of this happens in the background within milliseconds, enabling the client to connect to the desired host. In the normal flow, all DNS queries are for legitimate hostnames and the responses are IP addresses or other genuine DNS records. The key point is that the authoritative servers involved belong to the real owners of the domains being queried (e.g., the authoritative server for google.com is Google’s DNS server). The DNS traffic contents are just domain names and IP addresses, no hidden messages.

Now consider a scenario where malware inside the network is performing DNS tunneling. The setup looks similar on the surface, the client still queries the internal DNS server, which forwards the query out to a public resolver, and an authoritative server eventually provides an answer. The crucial difference is the query itself and the ownership of the authoritative server. In a DNS tunneling attack, the attacker has registered a domain, say, attacker-domain.com, and set up an authoritative name server (NS) for it under their control (red server in the diagram). The malware doesn’t ask for something like login.microsoft.com; instead it queries a subdomain that encodes data, such as abcd1234.attacker-domain.com, where abcd1234 is encoded stolen data or a command. This query goes to the company DNS server, then out to the public resolver. The public resolver sees that the query is for attacker-domain.com and thus needs to go to that domain’s name server, which is the attacker’s malicious DNS server. The query reaches the attacker’s DNS server, which recognizes the encoded data (the abcd1234 subdomain) as part of the secret communications. It then formulates a DNS answer. For example, it might return a TXT record for abcd1234.attacker-domain.com with some encoded content, perhaps the next chunk of exfiltrated data, or the instruction “OK” for the malware to proceed. That answer travels back to the public resolver, through the firewall, into the company DNS, and back to the malware client. To any intermediate observer, this was just a DNS lookup for an external domain. However, in reality the DNS query/response carried hidden information. The authoritative server in this case is the attacker’s server (not a legitimate one), so the attacker can respond with anything. Essentially, the firewall and public DNS see a query to an innocuously named domain and allow it, not realizing it’s a Trojan horse carrying data out. Over time, the malware will keep sending these queries to carry chunks of data or to poll for commands. The attacker’s name server will keep responding with the necessary info encoded in DNS responses. This covert communication can continue as long as the DNS traffic is not detected as abnormal. A few characteristics of malicious DNS tunneling traffic (as in Figure 2) contrast with normal DNS (Figure 1): the queries often contain long, random-looking subdomains (since they carry binary data encoded as text), the queried domain is often one that nobody in the organization would normally use, and the frequency of queries might be high (to send more data) or at odd intervals. These anomalies can be used to detect tunneling, which we’ll discuss next. But without specific DNS monitoring, those differences can easily be missed, allowing the tunneling to run unhindered.

In the following parts of this series, we will dive deeper into why DNS tunneling is so dangerous for businesses and organizations, and why it remains relatively easy to execute even today. Understanding these risks is crucial for building a comprehensive cybersecurity defense.

To stay ahead of these threats, we invite you to start a free trial of SafeDNS today. Our advanced Protective DNS solution helps detect and block DNS tunneling activities, safeguarding your network and devices from covert attacks. Don’t wait until it’s too late. Secure your infrastructure with SafeDNS now.