DNS Tunneling: The Hidden Highway Out of Your Network

Imagine this: it’s a quiet Thursday afternoon. You’re quietly analyzing the latest threats from your EDR and firewall consoles, checking all alerts of outbound calls to strange addresses. Every one of them has been blocked.

Yet, even as you sip your coffee, a vicious malware is spreading across the entire enterprise network, a crippling and expensive ransomware attack imminent. This malware is not operating in the dark: it has an open phone line back to its masters. But this line is not a TCP connection you will see on your firewall. It is passing undetected, hidden deep inside a torrent of DNS queries, intermingled with the rushing river of thousands upon thousands of totally innocent DNS requests, forwarded by your trusted, internal DNS resolver. By the time you’re aware of this anomaly, it’s too late.

At the heart of the Internet lies the Domain Name System, or DNS: a core service which, since its introduction in the early 1980s, has been the de facto standard name resolution system used by the wider Internet. Its job is, ultimately, to convert human friendly domain names, like www.hpe.com, into the native addressing schemes of the Internet, IPv4 and IPv6 addresses.

But its modern use has grown far beyond a simple, static mapping of hostnames to IP addresses. Modern software uses DNS to implement everything from load balancing to service discovery, through various uses and abuses of the protocol to accomplish a plethora of modern computing tasks. Its indispensable nature and insidious complexity mean it’s often treated like a sleeping monster—best not provoked. For cybersecurity, this means that DNS is implicitly trusted.

Every email sent, every website visited, every Active Directory logon – it all begins with a DNS query. Its ubiquity and implicit trust are what make it such a juicy and vulnerable target, and is precisely why DNS is so often used by modern threat actors, including major ransomware operations and government-backed APTs. Many of these make extensive use of Cobalt Strike’s C2, or “Command and Control” functionality (TA0011), specifically its DNS Beacon feature, which leverages DNS for C2 communications (T1071.004). Cobalt Strike, a commercial software package which bills itself as “Software for Adversary Simulations and Red Team Operations”, is a powerful hacking tool that has seen extensive use by criminal organizations and APTs around the world.

This is superbly effective because, as threat actors have long known, recognized, and abused, network and even security engineers will view DNS as something between that monster and a dumb pipe. It has to exist, and it has to work. Even if the DNS protocol is being blocked at the perimeter firewall, if Internet access is to work unabated, there must be an internal DNS resolver, and it must be allowed free communication with external DNS resolvers. The nature of DNS means that it is fraught with technical peril to try and restrict DNS traffic, and the recursive nature of DNS resolvers means that trying to restrict the destination of DNS traffic is nearly impossible.

So DNS becomes a hidden information highway, a blind spot that attackers can use to smuggle data in and out of even the most heavily fortified networks. This technique, known as DNS tunneling, allows threat actors to wrap malicious commands and package stolen data all inside seemingly innocent DNS queries and their responses, creating a covert communication channel that can bypass billions of dollars worth of cumulative security investment.

Here, we’ll dive into an exploration of this pervasive threat. We’ll begin with an overview of DNS itself, tearing down the mechanics of those aforementioned “recursive” queries, and the chain of trust which makes it work. Then we’ll dive deep into the world of DNS data smuggling, taking a look at how attackers can create a full TCP/IP tunnel inside DNS traffic to an external Internet endpoint, bypassing network controls designed to prevent such access. We’ll dissect real-world examples of different tunneling techniques, looking at the sort of traffic and log entries they’d generate. Then, we’ll discuss a framework for detecting these covert channels, with a multi-layered mitigation strategy designed to make DNS tunneling as difficult and noisy as possible, rendering it unusable for all but the most determined threat actors.

The goal is not just to understand the threat, but to arm and prepare network professionals with the knowledge and strategies needed to put eyeballs on this blind spot, and close the hidden highway for good.

The Domain Name System

Before we get into how to abuse DNS, we must begin with its basic and most proper usage: its design and function. Fundamentally, DNS is a globally distributed, hierarchical database that maps domain names to “resource records”. The most typical example of a resource record, or RR, is an IP address.

Before DNS, networks like ARPANET and DECNET relied on variations of hosts files to keep static records of names and corresponding addresses. These databases still exist, in the form of /etc/hosts on UNIX-like OSes, and C:\Windows\System32\drivers\etc\hosts on Windows. But as computer networks scaled, it became quickly apparent that manually creating and duplicating these files would not do.

In the world of the Internet Protocol, the “Domain Name System” was specified in RFC 882 in 1983, while its first implementation was that of named(8), the self-proclaimed “Internet domain name server” shipped with 4.3BSD, and also included in the “Network Distribution”. This portion of BSD, containing just the freely distributable networking code, would go on to be incorporated by many OSes, and code such as named would also be widely adopted by the industry.

DNS’s core function has not changed at all since the early 80s. It consists of a single namespace, structured as an inverted tree; the “root” is the top of the tree, and below the root, are a set of “Top-Level Domains”, or TLDs. These include the well-known .com, .org, and .net TLDs, but in recent decades have expanded dramatically to include many “country-code TLDs”, or ccTLDs, as well as “generic TLDs”, which includes over a thousand TLDs ranging from .men to .broadway to .pizza.

Below the TLDs are second level domains. This would be the hpe in hpe.com. And below that is the third level, the arubanetworking in arubanetworking.hpe.com. The number of domain levels is limited only by the maximum overall length of a domain name, which is determined by the DNS protocol.

When a client computer needs to resolve a domain name, to browse to a website, for example, it initiates a process that involves two distinct types of DNS servers:

• Recursive Resolver: This is the backbone of DNS. When a client makes a DNS query, it usually sends it to a recursive resolver. This resolver may be provided by the ISP, by large companies such as Google and Cloudflare who operate the large recursive resolvers 8.8.8.8 and 1.1.1.1, respectively, or by an enterprise’s own, internal DNS server. These recursive resolvers have the job of finding answers on clients’ behalves. They do this by performing a series of queries, starting from that DNS root, and working down level by level until the answer is found.
• Authoritative Name Server: These servers hold the official DNS records for a specific domain. For example, HPE operates authoritative name servers for the domain hpe.com. These servers are the be-all and end-all on the correct Resource Records for all domains under hpe.com in the tree hierarchy.

Note that DNS is insidiously complicated, and these two roles can be played by the same DNS server. That is, a server can be simultaneously authoritative for a given domain, but also functions as a recursive resolver.

Let’s step through a simplified example for www.hpe.com:

1. The user enters www.hpe.com into their browser. The browser, identifying this as unambiguously a domain name, sends the request to the system’s configured recursive resolver server. This is your 8.8.8.8 or 1.1.1.1, or ISP/organization provided DNS server.
2. The resolver will first check a cache of recently resolved domain names. If the name is in the cache, and the entry hasn’t expired, it returns the cached answer.
3. If it isn’t cached, or the entry has expired, the resolver begins the recursive query process. It begins by querying the Internet’s root name servers, the authoritative name servers for the DNS root, for the IP addresses of the name servers for the TLD of the requested domain, in this case, .com.
4. Then, the resolver will ask those authoritative name servers for the IP address of the name server for the next level of the domain, hpe.com in this case.
5. This cycle repeats for each level of the domain name. In this example, the authoritative name server for hpe.com is asked for the IP address of the www.hpe.com domain name.
6. Finally, the resolver will cache this result, and send it back to the requesting client. The cache is set to expire based on a value called the Time To Live, or TTL.

This model, while incredibly efficient, is built around a function that attackers love to exploit: any client with layer 3 access to any recursive DNS resolver can cause that server to send a query to any authoritative name server on the Internet. The recursive resolver server acts as a proxy, and forwards the client’s request onward.

Therein lies the principle which enables DNS tunneling. An attacker only has to first set up their own malicious “authoritative name server” for a domain they control. Then, malware running on a compromised machine can send specially crafted DNS queries with data embedded inside the domain name to the company’s internal recursive resolver.

The resolver, doing its job, will see a request for a domain which it is neither authoritative for, nor does it have cached. It follows protocol, and forwards the data-containing query up the chain, to the attacker’s authoritative server. The attacker has now successfully smuggled data out of the network, performing Exfiltration Over C2 Channel (T1041), all using the company’s internal DNS server as an unwitting accomplice! The firewall only sees a normal DNS query coming from the trusted, internal DNS server, functionally indistinguishable from the thousands of other DNS queries streaming through. The hidden highway has been paved.

It’s worth pointing out that there exists a set of extensions to DNS, called DNSSEC, “DNS Security Extensions”. DNSSEC is designed to combat man-in-the-middle and poisoning attacks by using cryptographic signatures to verify authenticity and integrity of DNS responses. However, DNSSEC is not a particularly useful tool for preventing DNS tunneling or other forms of data exfiltration. A malicious DNS server could feasibly use DNSSEC to sign its responses, and be validated by a DNSSEC-supporting resolver. Additionally, there are significant challenges in deploying DNSSEC to internal/“split-horizon” DNS configurations, such as those used by internal corporate networks, further limiting its usefulness here. Nevertheless, where it is feasibly deployed, it is a useful resource.

The Art of DNS Tunneling

DNS tunneling, then, is the technique of encapsulating the data of other protocols or programs within DNS queries and responses, a method categorized by MITRE ATT&CK as Application Layer Protocol: DNS (T1071.004). Its goal is to create a covert, bidirectional communication channel between a compromised client, and an attacker’s C2, or “Command and Control” server, all appearing as legitimate DNS traffic.

Superficially, this sounds like an easy job. But the devil is in the details, and DNS implementations have many details.

The core mechanism of DNS tunneling involves encoding data into the subdomain and hostnames of DNS queries. The DNS standard states that the only valid characters inside domain names are uppercase letters, numbers, and the hyphen symbol. Usually, attackers will use Base32 encoding, then, to send data upstream.

However, most DNS servers are more permissive and do not enforce this rule. Many DNS servers do, in fact, distinguish case – that is, they do not normalize the case of domain names. This means going from 37 possible characters to 63. Many DNS servers also recognize either + or _ as valid symbols, increasing the number of distinct characters to 64, allowing for Base64 encoding, a significant increase in data density.

Let’s assume we can use Base64 encoding. We want to send the username and password of an administrator account to the C2 server. We’ll encode this as a username and password separated by a colon character – admin:rockyou.

1. First, we Base64 encode the string. admin:rockyou becomes YWRtaW46cm9ja3lvdQ. (For comparison, the Base32 version would be MFSG22LOHJZG6Y3LPFXXK)
2. The DNS protocol has hardcoded limits on the maximum size of a subdomain label, 63 bytes, and 253 bytes for the total domain name (255 raw bytes, reduced to 253 theoretical maximum due to encoding overhead). If the message exceeds the limits, it will have to be broken up. In this simple example, we can just send the entire string in one go.
3. We craft the query by prepending the payload string to an attacker-controlled domain. For example, the domain evilapt.pizza would result in the query YWRtaW46cm9ja3lvdQ.evilapt.pizza.
4. The attacker sends this query to the internal resolver, which will act as a proxy and forward the request to the authoritative name server for evilapt.pizza. This “name server” will be a specialized piece of software, which will recognize the payload, and decode it back to admin:rockyou.

That handles getting data out. To make this bidirectional, the attacker needs to be able to get data in. This is done by encoding data into the DNS response itself, via the Resource Records we mentioned previously.

The malicious “name server” can respond with various kinds of resources records. There is no single ideal type – they all feature various trade-offs, between bandwidth, stealth, and simple viability. The two most universal are the A/AAAA records and TXT records:

• A and AAAA records: These are the records for delivering IPv4 and IPv6 addresses, respectively. They are tiny – 4 or 16 bytes – making their usefulness limited. They are only useful for transferring very small amounts of data, or for being incredibly stealthy and robust: any DNS resolver is guaranteed to handle these record types correctly.
• TXT records: The most popular and versatile type for DNS tunneling. TXT records are, as their name implies, designed to hold arbitrary human-readable text. This enables much larger payloads, up to hundreds of bytes per record! An attacker can easily encode complex commands, entire scripts, or even portions of binary files into a single TXT record response. Because these records are frequently used by legitimate services, such as SPF in email, or in various domain-verification schemes like ACME, they are less likely to be blocked by security policies.

Other record types, like CNAME, SRV, MX, and NULL/PRIVATE, are also used. NULL in particular can contain an immense amount of data – 64 kilobytes in a single response! However, it has no legitimate use, is marked experimental by the IETF, and can be (and is often) disabled on resolvers, or blocked by DPI-enabled firewalls.

DNS tunneling has become thoroughly “commoditized”, with a collection of tools available to facilitate its use:

• Cobalt Strike’s DNS Beacon: As mentioned previously, one of its most popular C2 modules is the DNS Beacon, used to orchestrate communication between compromised clients and the attacker. Via the Malleable C2 framework, an attacker has immense ability to customize the network signature of this DNS tunneling, allowing it to remain incredibly stealthy.
• Iodine: A well known tool which creates stable TCP/IP tunnels entirely using DNS, effectively creating a VPN over DNS. It is robust, if not particularly stealthy, and uses a variety of heuristics to identify the most bandwidth efficient record types available to use. Its primary use is for bypassing captive portals and not necessarily for malware, but bypassing enterprise security this way can still be devastating, as we’ll discuss later in the article.
• dnscat2/blind/etc: Instead of creating a full TCP/IP tunnel like Iodine, these (and many other) tools will create either sockets or simple “sessions” over DNS, allowing for lighter-weight communication, more in line with the DNS Beacon of Cobalt Strike. These can be used as literal C2 client/server solutions, or to wrap individual programs, such as SSH, “inside” a bidirectional DNS tunnel.

Beyond Tunneling

While DNS tunneling for C2 and data exfiltration is the classical use case, modern threat actors are now shifting its application “left” in the cyber “kill chain”. They are using the stealth of DNS for more subtle, initial-stage activities that occur long before a full compromise is established.

OAST, or Out-of-Band Application Security Testing, is the technique of having exploit code attempt to resolve a known, specific, unique hostname, and tracking queries for that hostname on a name server, in order to determine if an exploit “worked”. This practice has been common in the security testing world for a long time, gaining traction via Burp Suite’s “Collaborator” module. There are now multiple services offering OAST “endpoints” for developers/pentesters to use, such as oast.fun

But now, threat actors are beginning to use this practice “offensively”, relying on it as an uber-stealthy indicator of compromise. For instance, earlier this year (2025, the time of writing), the Python package repository PyPI, had a threat actor upload a typosquatted package monoliht, an intentional misspelling of monolith with the hope of users accidentally typing pip install monoliht and swapping the t and h characters.

This package would silently produce requests to the oast.fun OAST service, encoding information such as the hostname, username, and current working directory into the DNS request.

In a similar vein, domain names can be used to track users, such as in phishing campaigns. By using Javascript to initiate requests to unique domain names, e.g. ones with unique hashes embedded as a subdomain, the threat actor can avoid triggering lookups to suspicious IP addresses, and instead only trigger silent DNS queries sent to the internal resolver.

This “leftward shift” is a critical development. It means defenders can no longer treat DNS tunneling indicators solely as a sign of an active, post-exploitation C2 beacon. A single, high-entropy DNS query to an unknown domain might now be the first and only indicator of a successful phishing attempt or a freshly exploited vulnerability.

Framework for Detection

Given the sophistication and variety of DNS tunneling techniques, a multi-layered detection strategy is essential. This strategy progresses from foundational statistical analysis to advanced behavioral modeling and machine learning.

Layer 1: Payload and Traffic Analysis

This first layer focuses on identifying quantifiable anomalies within DNS traffic which are hallmarks of active tunneling.

Payload Analysis (Individual Queries)

• Tunneling often generates Fully Qualified Domain Names (FQDNs) that are unusually long or have a high number of subdomain labels. A simple rule that flags DNS queries over a certain length (e.g., 100 characters) or with more than a certain number of labels (e.g., 5) can be an effective first filter.
• Tunneled data is encoded, not linguistic. Calculating the Shannon entropy of subdomain labels is a classic and powerful method for detecting this randomness. A legitimate subdomain like mail has very low entropy, while an encoded one like c2VjcmV0 has very high entropy.
• A high volume of TXT, CNAME, and certainly NULL queries directed at a single domain not associated with known email or CDN services is highly suspicious.

Traffic Analysis (Patterns Over Time)

• A compromised client engaged in data exfiltration will generate a massive number of DNS queries in a short period. Monitoring for a sudden spike in queries from a single client to a single second-level domain is a key indicator.
• Malware using Domain Generation Algorithms (T1568.002) to find its C2 server often generates a high rate of queries for non-existent domains, resulting in NXDOMAIN responses. A client with an abnormally high ratio of NXDOMAIN errors is a strong signal of malicious activity.
• A small DNS query followed by an unusually large TXT record response can indicate the delivery of a malicious payload or a large command from a C2 server.
• Queries to Newly Registered Domains (NRDs) are inherently suspicious. Integrating threat intelligence feeds that track domain age and reputation is critical. A query to a domain registered within the last 24 hours should be treated with extreme prejudice.

Layer 2: Behavioral Baselining with NDR

Modern attackers can evade simple statistical analysis by using “low-and-slow” techniques. To counter this, Network Detection and Response (NDR) solutions establish a behavioral baseline of what constitutes “normal” DNS activity for the entire network and for each individual host.

By learning the typical patterns of a device: which domains it queries, at what frequency, at what times of day, and the typical size of its queries and responses, an NDR system can flag subtle deviations that would be missed by static rules. For example, a developer’s workstation that suddenly starts making periodic, low-frequency A record queries to a previously unseen domain in Eastern Europe every 30 minutes would be flagged as a high-fidelity anomaly, even if the individual queries don’t have high entropy. This is the characteristic “heartbeat” of a sleeping C2 beacon.

Layer 3: The Machine Learning Frontier

The most advanced detection methods use machine learning (ML) to identify complex, non-linear patterns indicative of maliciousness.

• Models like Random Forest and Gradient-Boosted Trees are trained on massive, labeled datasets containing millions of examples of both benign and malicious DNS traffic. They learn to classify new queries by analyzing dozens of features simultaneously—domain length, label count, entropy, TLD popularity, character distribution, n-gram analysis, and more.
• More advanced models like Convolutional Neural Networks (CNNs), Long Short-Term Memory (LSTM), or even Sentence Transformers (SBERT) networks can learn patterns directly from the raw character sequences of domain names. This approach, borrowed from Natural Language Processing (NLP), allows the model to distinguish between algorithmically generated domains and human-readable ones with stunning accuracy, often exceeding 98% on curated datasets.

Framework for Mitigation

Detection is crucial, but it’s only half of the battle. An effective defense against DNS tunneling requires a strong defense-in-depth strategy that combines architectural controls, robust policy enforcement, and proactive validation. The goal is to make tunneling so difficult, slow, and noisy that attackers are forced to use other, more easily detectable methods.

Architectural Controls

• External DNS resolvers should be restricted. Firewalls should be configured to block all outbound DNS traffic (TCP and UDP port 53) from general client endpoints directly to the internet. This policy can be enforced using the Aruba Policy Enforcement Firewall (PEF) on HPE Aruba Networking Gateways and Controllers. To ensure no query is missed, a policy should be created in HPE Aruba Networking ClearPass Policy Manager that uses Destination NAT (DNAT) on the gateways. This rule transparently intercepts any DNS query from a client to an external resolver and redirects it to the sanctioned, internal, and heavily monitored enterprise DNS resolver, creating a single point of inspection and control.
• When malicious tunneling is detected, and the corresponding domain is identified, it should be sinkholed. A DNS sinkhole is an internal DNS resolver configured to provide non-routable or internal IP addresses for known malicious domains. This severs the C2 channel. Furthermore, the sinkhole itself becomes a high-fidelity sensor; this can be integrated with HPE Aruba Networking ClearPass, which can use the sinkhole’s logs as a trigger. Any client attempting to resolve the sinkholed domain can be automatically re-authorized via a Change of Authorization (CoA) into a “Quarantined” role, which, using HPE Aruba Networking Dynamic Segmentation, instantly isolates the device from the rest of the network.

Policy and Configuration

• Implementing rate limits on internal resolvers can cap the number of queries a single client can make in a given time frame. While this won’t stop a patient attacker, it is highly effective at disrupting high-volume data exfiltration, making it impractical and more likely to trigger other alerts, buying your security team valuable time to respond. Additionally, policies that limit the maximum permissible length of DNS queries and block record types with no legitimate business use (e.g., NULL records) can be enforced by platforms like HPE Aruba Networking’s SSE. While blocking TXT records outright is often impossible, policies can be created to flag or apply extra scrutiny to especially large TXT responses from untrusted domains.

Proactive Defense

• Actively hunt for signs of DNS tunneling in your DNS logs, leveraging resources like Aruba Central’s Client Insights. Don’t wait for alerts. Start with queries based on known TTPs. For example: “A known threat actor is using the Cobalt Strike DNS Beacon. Let’s search for periodic A record queries to a single domain that consistently receive a 0.0.0.0 response.”
• The only way to know if your defenses work is to test them. Conduct regular, controlled red team exercises that specifically use tools like dnscat2/blind and Cobalt Strike. These exercises provide invaluable, real-world feedback on whether your detection rules on your HPE Aruba Networking EdgeConnect SD-WAN are firing, your rate limits are working, and your architectural restrictions configured in ClearPass are preventing direct egress.

Encrypted DNS

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt DNS traffic and present a monumental challenge to enterprise security. DoH is particularly problematic, described as the “ultimate Shadow IT tool” because it encapsulates DNS queries within standard HTTPS traffic on port 443 (a form of Protocol Tunneling (T1572)), making it indistinguishable from a request from a normal web page request. When browsers enable DoH by default, they bypass enterprise DNS controls and create an unmanaged, encrypted covert channel that hides both malicious tunneling and unsanctioned application usage.

Again, the best defense here is defense-in-depth:

• The primary defense is to identify and block the traffic. The HPE Aruba Networking Policy Enforcement Firewall (PEF) and HPE Aruba Networking EdgeConnect SD-WAN appliances use Deep Packet Inspection (DPI) to identify application signatures, including those for DoH and DoT. Policies can then be created in ClearPass to block this traffic at the edge.
• For the most definitive control, traffic can be steered via EdgeConnect SD-WAN to the HPE Aruba Networking Security Service Edge (SSE) platform. The integrated Secure Web Gateway (SWG) in the SSE can perform full SSL/TLS inspection at cloud scale, allowing it to decrypt the HTTPS session, positively identify the DNS query within, and block it based on policy.
• As a complementary control, use your firewall or web proxy to block access to the known IP addresses and domains of all major public DoH providers (Google, Cloudflare, NextDNS, etc.). The NSA explicitly recommends this for all enterprise environments.
• When a browser’s DoH query is blocked, it will typically fall back to using the operating system’s configured (and hopefully corporate IT managed) DNS resolver, which is then subject to the DNAT interception and monitoring policies already established.

MITRE ATT&CK Framework Reference

Conclusion

DNS is, and will remain, a foundational protocol of the internet. Its implicit trust and ubiquity ensure that threat actors will continue to abuse it in increasingly creative and sophisticated ways. The battle for DNS security is not a one-time project but a continuous process of adaptation, requiring a defense-in-depth posture that combines robust architecture, smart policy, and proactive vigilance.

Shifting our perspective from treating DNS as a monster which shouldn’t be touched, or as that of a dumb pipe, to viewing it as a potentially hostile, secret information highway allows us to begin to build a more resilient security posture. By forcing all traffic through monitored chokepoints, embracing behavioral and statistical analysis to identify malicious signals in the DNS noise, and relentlessly challenging our assumptions and networks with real-world pentesting and red teaming, we can finally erase the DNS blind spot and close that hidden highway, removing one of threat actors’ most powerful tools, and forcing them to take the fight to more visible ground.