What Is DNS Tunneling and How to Detect It

You may have heard of notorious malware variants like Zloader using DNS tunneling for command and control (C2). Instead of making regular web requests, this malware uses the Domain Name System (DNS) to communicate with its C2 servers, and this allows malicious traffic to bypass network security, such as firewalls and intrusion detection systems (IDS).

But wait, DNS doesn’t support arbitrary data transfer like HTTP, does it? Well, it doesn’t, but DNS tunneling is a workaround for that. In this post, we break down DNS tunneling for you, including how it works and how to detect it – both from within an organization’s network and from outside it. 

What Is DNS Tunneling?

DNS tunneling is a communication technique that funnels data from other protocols over DNS queries and responses. Instead of a typical DNS lookup simply resolving a domain name to an IP address, the DNS packets carry hidden information. This encapsulated data can be anything, including malicious instructions delivered to the target system (e.g., download data, run a specific process, or scan the network). 

It’s worth noting that DNS tunneling is used not only for malicious purposes. For example, network administrators can use the technique to diagnose connectivity issues in highly restricted networks where traditional protocols (e.g., SSH and HTTP) might be blocked. But since DNS tunneling is inherently designed for covert communications, it is a favored method for threat actors.

How DNS Tunneling Works

DNS tunneling uses DNS packets to send and receive data that would’ve normally been transferred over HTTP or SSH. Here’s a breakdown of how it works:

1. The attacker sets up a base: 

First, the attacker registers a domain name, such as evilc2domain[.]com, that they fully control. This domain points to a server they own and operate, which will act as the "other end" of the tunnel. The attacker also sets up an authoritative DNS server for this domain, so that the public NS record for evilc2domain[.]com points to the attacker‑controlled authoritative DNS server.

2. The attacker infects the target: 

Next, the attacker needs to compromise a computer inside the target network by infecting it with malware. This infected machine becomes the "client" in the DNS tunnel.

3. The client initiates covert communication: 

The infected client computer begins secretly communicating with the attacker's server. It does so by taking the data it wants to send (perhaps, a piece of stolen information or a request for instructions) and encoding it, often in base32 or base64 format.

This encoded data is then hidden in a label, and the client sends a DNS request to a subdomain of the malware command-and-control server with this label. For example, a piece of encoded data might look like cGFydDFvZnNlY3JldGRhdGE, and the DNS request would go to cGFydDFvZnNlY3JldGRhdGE.evilc2domain[.]com. 

It’s worth noting that the encoded information is usually compressed and only then sent as a label in the DNS request, so it won’t be possible to just paste the label into a base64 decoder and see the data. In our example, we didn’t compress it — to make it easier to understand. Also, to avoid including symbols that cannot be in a subdomain (such as “=”, for example), DNS tunneling usually relies on so-called URL-safe base64 encoding that trims those symbols.

The outgoing DNS request is usually for a TXT or CNAME record of this subdomain (sometimes other record types are used though — we’ll get to that a little later). If the piece of encoded data is longer than 63 characters (the maximum length of a DNS label), the information is divided in chunks and sent in more than one request.

4. The query travels through the network: 

This seemingly normal DNS query then leaves the infected computer and travels to the local DNS resolver within the network. Since DNS traffic is almost always allowed through firewalls, the query usually passes without suspicion. The resolver forwards the request, as it would any other, to find the authoritative name server for evilc2domain[.]com.

5. Attacker's server intercepts and decodes: 

The query eventually reaches the attacker-controlled authoritative DNS server. This server isn't there to actually resolve the subdomain to an IP address. Its purpose is to decode the incoming DNS query, extracting the hidden data that the infected client embedded. Decoding cGFydDFvZnNlY3JldGRhdGE.evilc2domain[.]com, for example, we can extract the message, “part1ofsecretdata,” using a base64 decoder.

6. Server sends back hidden commands: 

After processing the client's data, the attacker's server can then encode its own information—such as commands for the infected computer to execute, or another piece of a malicious payload—into a DNS response. This response – in the form of a TXT or CNAME record, as requested by the client — is then sent back. These record types are chosen because they can hold longer strings of characters in comparison to other DNS records. However, sometimes, attackers use NULL, A, or AAAA records just as well.

7. Client receives and executes: 

The infected computer receives the attacker’s DNS response, decodes the hidden information within the response, and carries out the instructions, all the while remaining undetected by most traditional security tools.

8. The covert exchange continues: 

This process can repeat as many times as needed. If large amounts of data need to be transferred, both the client and the server will break it down into smaller chunks, sending each piece in a separate DNS query or response, bit by bit, until the message is completed.

As mentioned above, most DNS tunnel tools, like Iodine and DNSCat2, compress the data before encoding, so real strings may not decode cleanly without decompression.

This way of hiding data in DNS queries and responses allows communications between a client within a network and a C2 server outside it to go unnoticed. That's why more sophisticated malware and advanced persistent threats often use DNS tunneling techniques in their operations.

How to Detect DNS Tunneling

Spotting DNS tunneling requires a bit of detective work, whether you’re doing it from within your network or by looking at external indicators. From outside, it is sometimes possible to detect DNS tunneling infrastructure thanks to its atypical DNS behavior, which can be traced using passive DNS.

Detecting DNS Tunneling From Your Network Using Passive DNS and DNS Resolver Logs

Your DNS logs are a treasure trove of information. Below are some red flags that, if found in your logs, signal the likely use of DNS tunneling, and can be discovered either through payload analysis or traffic analysis.

• Large number of requests to non-existing domains in the resolver logs: An excessive number of failed queries (NXDOMAIN) for a specific domain in DNS traffic is a strong indicator of DNS tunneling. This is because malware typically encodes hidden data within subdomains that are either not registered or configured as A records, since the queried third-level domains are merely containers for the encoded data. Therefore, organizations should monitor for high volumes of NXDOMAIN responses, particularly those linked to suspicious, unfamiliar domains.

• Too many requests to subdomains of one domain: Another red flag is an abnormally high number of requests to different subdomains of a single domain in DNS traffic logs, since each subdomain may contain a fragment of the payload. For example, the subdomains cGFydDFvZnNlY3JldGRhdGE.evilc2domain[.]com, cGFydDJvZnNlY3JldGRhdGE.evilc2domain[.]com, and cGFydDNvZnNlY3JldGRhdGE.evilc2domain[.]com are decoded as part1secretdata.evilc2domain[.]com, part2secretdata.evilc2domain[.]com, and part3secretdata.evilc2domain[.]com.

• Randomness of characters and length of subdomains: Aside from requests to many subdomains of the same domain, it’s also important to pay attention to the characteristics of the third-level domains. Are they made up of random characters that don’t make sense? Do they get very close to the maximum character length? RFC requirements state that FQDN labels must have a maximum name length of 63 characters. So, if you see many requests to subdomains with labels of over 50 characters, that’s suspicious.

• Unusual increase in DNS traffic: When used for large-scale data exfiltration or continuous C2 communication, DNS tunneling generates a high number of DNS queries. However, this signal can only be detected when organizations have a baseline for normal DNS traffic volume.

• Consistent query timing and low TTL values: Uniform timing often indicates automated malware beaconing, where compromised computers regularly communicate with the C2 server, say, every 60 seconds. Low TTL values are set by the C2 server to ensure that the DNS resolvers do not cache responses, and the client always gets fresh data.

Specialized security solutions like Zeek, Splunk, and Palo Alto DNS Security can help with identifying weird DNS behavior, like those listed above. When only one of the above signals is observed, that could still be part of a normal, legitimate DNS behavior. However, when you see two or more of the red flags, you likely need to start threat hunting for something that is using DNS tunneling to communicate with a C2 server from inside your network.

Using Newly Registered Domains Database for Proactive DNS Tunneling Detection

We’ve mentioned how unusually long strings of characters in subdomains and TXT, MX, CNAME, and NULL records are red flags, especially when they appear to be base64 encoded. 

Aside from that, the age of the domain can also be a signal. Attackers frequently register new domains for their campaigns to avoid detection. When these new malicious domains are used for DNS tunneling, they often come with newly configured or highly unusual Name Server (NS) records.

That said, it might be helpful to integrate Newly Registered Domain (NRD) feeds into your threat intelligence, and any DNS queries to NRDs should be scrutinized more heavily. 

Attackers can also try to hijack a part of your organization’s namespace and compromise its DNS server without trying to register new domains. This way, their operation is even harder to detect because the queries would go to a known domain, so egress filters that allow “our own domain” won’t block them. So, it’s also important to monitor changes to NS records for domains in your environment. Unexpected NS changes for any of your domains are a huge red flag.

From Outside The Network – Identifying C2 Infrastructure Used for DNS Tunneling

Even without direct access to internal network logs, you can still attempt to identify C2 infrastructure used for DNS tunneling by analyzing DNS records, even though without access to DNS traffic analysis this is a much harder exercise. 

Using Subdomain Discovery to Find Suspicious FQDNs

If you suspect that a domain is used as a C2 server by malware that relies on DNS tunneling, you can start by getting a list of its subdomains using a subdomain lookup tool. Thousands of unique, nonsensical subdomains like SGVsbG8gd29ybGQ.evilc2domain[.]com indicate that this could potentially be a DNS tunneling C2 server.

Even with suspicious signals, you may still need to do some more digging into the subdomains you obtain from this process. We describe how you can obtain more information in the next sections.

Using TXT Lookup to Gather Evidence 

When a compromised client sends a DNS query with encoded data in a subdomain (step 3 of “How DNS Tunneling Works”), the attacker’s C2 server often responds by embedding commands or data within TXT records in their DNS responses. So, use a TXT record lookup tool for the FQDNs you found from the subdomain discovery above, specifically those that exhibit red flags. Look for TXT records that contain unusually long, seemingly nonsensical strings that appear to be base32 or base64 encoded.

Keep in mind that you can't just perform a TXT lookup on the root domain (e.g., evilc2domain[.]com) and expect to find the tunneling data, since the C2 server will only respond with the encoded data when presented with the specific, data-carrying subdomain query. 

When you find the FQDNs with suspicious TXT records, you may have identified a potential C2 infrastructure. 

While threat actors often use TXT records because they hold a significant amount of data compared to other record types, they sometimes also resort to using MX, CNAME, and NULL records. So, you can check the respective lookup tools as well – the MX lookup tool and the CNAME lookup tool.

Using Passive DNS Databases to Uncover Cluster Malware Infrastructure

After having gotten a list of suspicious subdomains from a subdomain discovery exercise, you can also use WhoisXML API’s DNS Chronicle API to check if those subdomains ever had A or AAAA records. If most of them never had one, the likelihood that you’re looking at DNS tunneling increases, as the data is likely embedded within the subdomain itself and does not rely on IP resolutions.

Now, to further identify other parts of the C2 infrastructure, you can:

• Search through the DNS Database Download to look for historical TXT records (or suspicious MX, CNAME, and NULL records) that resemble the suspicious records you found earlier. Sometimes, the subdomains and responses have a pattern to them. For example, in the Cobalt Strike FinHealthXDS campaign described by Palo Alto Networks, the queried subdomains had “xds.” at the start of the FQDN to indicate that it’s a command request query. By looking for other records that have the same pattern, you can potentially uncover other C2 domains used in the same campaign.
• Obtain the IP address of the suspicious subdomains’ root domain and use a reverse IP  lookup tool to find other domains hosted on the same IP. On its own, this doesn’t mean anything but these domains deserve additional scrutiny.
• Retrieve the TLS/SSL certificate of the suspicious root domain using an SSL certificate API and then check Certificate Transparency (CT) logs to see other domains listed on the certificate.

Using Active DNS to Detect DNS Tunneling

If you have access to active, real-time DNS data, detection becomes even easier since it’s like observing network activity but from the outside, with a global perspective. 

The principle is the same: look for mass requests to subdomains of a domain that return NXDOMAIN. You can then use passive DNS methods (e.g., checking for A/AAAA records, historical TXT records) to confirm suspicions and enrich threat intelligence.

Conclusion

DNS will remain one of the go-to attack vectors because it is used in, and trusted by, all networks that connect to the Internet. Stealthy methods like DNS tunneling allow attackers to abuse this trust and sneak past defenses which is why basic network security is no longer enough. Security teams need to embrace smart detection using advanced security solutions that combine both tactical and predictive threat intelligence.