DNS Tunneling: Exfiltration & C2 Hidden in DNS

Most networks block a lot. Outbound web traffic gets proxied, unusual ports get firewalled, and file uploads to unknown hosts get flagged. DNS almost always gets a pass. It has to resolve for anything else to work, so port 53 stays open and the queries flow out with little scrutiny. Attackers noticed. If you can hide data inside DNS queries, you can carry it straight through defenses that would stop it on any other channel.

DNS tunneling is that trick. It turns name resolution into a covert transport for stolen data and for command-and-control. It is not fast and it is not quiet if you are looking, but it is remarkably persistent, and on networks that do not inspect their DNS it runs unseen.

How the channel works

DNS tunneling exploits the way name resolution reaches across the internet. A resolver that does not know an answer forwards the query up the hierarchy to the authoritative server for that domain. The attacker owns both ends of that arrangement.

The setup looks like this:

• The attacker registers a domain, for example tunnel.example, and configures its authoritative name server to be a machine they control.
• Malware on the victim encodes data into the labels of a hostname under that domain, then asks the local resolver to look it up. A query might look like <encoded-data>.tunnel.example.
• The victim's resolver, not knowing the answer, forwards the query out to the attacker's authoritative server, which is the intended recipient all along.
• The attacker's server reads the encoded data out of the query name. To send data back, it encodes a reply into the DNS answer, using a record type such as TXT that can carry arbitrary text.

The victim's machine never connects directly to the attacker. It talks only to the local resolver, exactly as it does for any normal lookup. The resolver does the forwarding, unaware it is relaying a tunnel. That indirection is what lets the channel slip past egress controls that would block a direct connection.

What attackers use it for

DNS tunneling serves two jobs, both catalogued in ATT&CK.

• Data exfiltration. Encoding stolen data into outbound queries is Exfiltration Over Alternative Protocol (T1048). The bandwidth is poor because each query carries only a small payload, but for slowly draining a database of records or a set of credentials, that is often enough. Attackers who want to stay under the radar prefer this low-and-slow pace anyway.
• Command and control. Using DNS as the two-way channel for tasking an implant is Application Layer Protocol: DNS (T1071.004). The implant beacons out with queries and receives commands in the answers. Because DNS is allowed almost everywhere, this C2 survives on networks that block direct outbound connections entirely.

The trade-off is always the same. DNS gives up throughput in exchange for reach and resilience. That trade suits an attacker who values getting out at all over getting out fast.

Why detection is behavioural

There is no malware signature in a DNS query. The abuse is in the shape of the traffic, not its content, so detection means characterizing what normal DNS looks like on your network and flagging what deviates.

The strongest signals cluster around a few properties.

Signal	Normal DNS	Tunneling pattern
Query volume to one domain	Modest, human-paced	High and sustained to a single domain
Label length	Short, readable names	Long labels near the maximum allowed
Label entropy	Low, dictionary-like	High, close to random from encoding
Record types	Mostly A and AAAA	Heavy TXT, NULL, or CNAME use
Response size	Small	Consistently large answers
Unique subdomains	Repeated, cacheable	A flood of distinct one-off subdomains

No single row is conclusive on its own. A content delivery network or a security product may legitimately generate long or high-entropy names. The signal strengthens when several properties line up at once: a large volume of long, high-entropy, non-repeating subdomains under one registered domain, answered mostly by TXT records. That combination rarely has an innocent explanation.

The complication of encrypted DNS

DNS over HTTPS and DNS over TLS encrypt queries between the client and resolver. That is good for privacy and it defeats on-path DNS spoofing, but it also hides the query contents from network inspection. If a device tunnels over an encrypted DNS channel to a resolver you do not control, the entropy and label-length signals are no longer visible to your sensors.

The answer is policy rather than payload inspection. Force clients to use approved resolvers, block or steer unauthorized encrypted DNS endpoints at the egress, and do the behavioural analysis at the resolver where the queries are once again visible. If all DNS funnels through infrastructure you run, encryption on the last hop does not blind you.

How to defend against DNS tunneling

The defenses stack. Control where DNS can go, log it centrally, analyze its shape, and cut off the direct paths that tunneling relies on.

1. Funnel all DNS through controlled resolvers. Block outbound port 53 to anywhere except your own resolvers, and steer or block unauthorized DoH and DoT so clients cannot resolve around you. This is the precondition for everything else. Deployment guidance in NIST SP 800-81-2 covers running DNS securely.
2. Log and retain DNS query data. You cannot detect what you do not record. Centralize resolver logs with the query name, type, client, and volume.
3. Analyze query shape. Alert on high per-domain query volume, long or high-entropy labels, an unusual share of TXT or NULL records, and a flood of unique subdomains under a single domain. Combine the signals rather than trusting any one.
4. Baseline and threshold. Learn what your environment's normal DNS looks like so that anomalies stand out. New domains generating heavy traffic from a single host deserve a look.
5. Restrict egress broadly. Tunneling is a fallback when direct channels are blocked. Tight egress control makes DNS the attacker's only option, which concentrates their traffic on the one channel you are inspecting.
6. Filter known-bad and newly registered domains. Reputation and category filtering at the resolver cuts off many commodity tunneling toolkits before they establish a channel.

Tunneling is one exit route among several. To see how it fits into a broader command-and-control and exfiltration playbook, our Exploit Intelligence dashboard tracks the techniques and tooling attackers pair with covert channels.

How the technique evolved

DNS was designed in an era when the network was small and largely trusted, and the protocol was built to be permissive so that resolution would always succeed. That permissiveness is exactly what the technique exploits. Researchers demonstrated data-over-DNS ideas early, and the concept matured into general-purpose tunneling tools that present a familiar network interface on top of the DNS channel, so an operator can run ordinary traffic through it without hand-encoding anything.

As perimeter defenses tightened around web and arbitrary outbound traffic, DNS remained the reliable gap, and tooling followed the demand. Tunnels gained features to blend in better: variable timing to mimic human pacing, rotating subdomains to defeat naive caching-based detection, and the option to spread queries across multiple registered domains to dilute the per-domain volume signal. Defenders responded by moving detection from static rules toward baselining and scoring, which is where the contest sits now. The attacker tries to keep the traffic under the thresholds that would flag it, and doing so throttles their own throughput, which is the built-in tension that makes the channel catchable when it is used for anything substantial.

Encrypted DNS added a new wrinkle. DNS over HTTPS and DNS over TLS were introduced for legitimate privacy reasons, and they also give a tunnel a way to hide its query contents from network sensors. That shifted the defensive emphasis further toward resolver policy: if every client is forced through resolvers the organization runs, the encryption on the last hop does not blind the analysis, because the queries are visible again at the resolver.

A worked example: encoding a file into queries

Following a single small file out through the tunnel shows why the traffic looks the way it does and why the signals in the table above appear.

Suppose the implant wants to exfiltrate a short document. It cannot fit the document into one query, because a DNS name is limited to 253 characters total and each label to 63, and only certain characters are valid in a hostname. So the implant first encodes the file's bytes into a hostname-safe alphabet, typically a base32 or base16 scheme, which expands the data and produces the high-entropy, near-random labels that stand out from dictionary words.

It then splits the encoded blob into chunks that fit inside labels, and it usually prefixes each chunk with a sequence number so the receiver can reassemble the pieces in order. A single outbound lookup might carry a chunk as 01a2f3b4c5.<more-encoded-bytes>.tunnel.example. To move the whole file, the implant issues a stream of such queries, each with a different, unique subdomain. That is the source of two signals at once: a flood of distinct one-off subdomains, and a high sustained query volume aimed at one registered domain.

On the other side, the attacker's authoritative server logs every incoming query, strips the domain suffix, decodes the labels, orders the chunks by sequence number, and reconstructs the file. When the server needs to send tasking back to the implant, it places the response payload into a record type that can carry arbitrary text, commonly TXT, which is why heavy TXT use is another tell. The implant reads the answer, acts on it, and the loop continues.

The throughput is poor. Each query moves only tens of bytes of usable payload after encoding overhead, so a large exfiltration produces thousands of lookups. That inefficiency is the reason the technique suits low-and-slow theft and lightweight command and control rather than bulk transfer, and it is also why the volume signal is so reliable: moving meaningful data over DNS simply requires a lot of queries.

Detection signals in practice

Turning the traffic properties into working detection means combining them, because each one alone has innocent explanations.

• Volume concentrated on a single registered domain. A host issuing hundreds or thousands of lookups to one second-level domain over a short window, especially a domain seen for the first time, is the strongest single indicator. Aggregate by the registered domain, not the full hostname, so the flood of unique subdomains collapses into one high count.
• Label length near the maximum. Consistent use of labels approaching 63 characters, and total names approaching the 253-character limit, reflects an attacker packing each query for efficiency. Human and application traffic rarely sits at the ceiling.
• High label entropy. Encoded data looks close to random. Measuring the character distribution of labels and flagging sustained high entropy separates encoded payloads from readable names. Content delivery and security products can produce high-entropy names too, so pair entropy with volume.
• Record-type skew. A client whose lookups are dominated by TXT or NULL records, rather than the A and AAAA that make up ordinary browsing, is behaving unusually. Track the per-client record-type mix against a baseline.
• Unique-subdomain ratio. Normal DNS is cacheable and repetitive, so the same names recur. A tunnel produces a high ratio of never-before-seen subdomains to total queries under one domain. That ratio is hard for a tunnel to avoid without crippling its own throughput.
• Timing regularity. Command-and-control beacons often query on a fixed interval. Steady, machine-paced timing to one domain, distinct from bursty human activity, adds confidence when combined with the properties above.

The reliable approach is a scoring model. No single signal convicts, and several signals aligning on the same client and domain at the same time very rarely has a benign cause.

The trade-off the attacker cannot escape

Every choice a tunnel operator makes to reduce one signal raises another, and that tension is the defender's advantage. Packing each query for maximum payload produces long, high-entropy labels near the size ceiling, which is easy to flag. Backing off to shorter, more natural-looking labels wastes capacity and forces even more queries, which raises the volume signal. Spreading traffic across many registered domains dilutes per-domain volume but multiplies the number of freshly seen domains a client is contacting, which is itself suspicious. Slowing the beacon to look human-paced stretches a transfer over hours or days, which widens the window in which any single alert can fire.

None of these adjustments make the channel disappear. They move the tell from one column of the detection table to another. A defender who baselines several properties at once, rather than thresholding a single one, keeps the operator boxed in: the settings that evade one rule trip another.

DNS tunneling compared to other covert channels

Placing the technique against its alternatives clarifies when an attacker reaches for it.

Channel	Throughput	Blends with	Blocked by	Typical use
DNS tunneling	Low	Name resolution	Resolver policy and behavioral analysis	Low-and-slow exfiltration, resilient C2
HTTPS to a web host	High	Ordinary web browsing	Proxy inspection, egress filtering	Bulk transfer, general C2
ICMP tunneling	Low	Diagnostic traffic	Blocking or rate-limiting ICMP egress	Niche covert channel
Cloud storage upload	High	Sanctioned SaaS traffic	Data controls, allowlisted destinations	Large data theft under cover of SaaS

DNS earns its place by reaching out where the higher-throughput channels are blocked. On a network that proxies web traffic and denies arbitrary outbound connections, DNS may be the only path left open, which concentrates a determined attacker onto the exact channel a prepared defender is inspecting.

Common misconceptions

"Blocking port 53 stops it." You cannot block DNS wholesale, because resolution is required for the network to function. The correct move is to force all DNS through resolvers you control and inspect, and to steer or block unauthorized encrypted DNS so clients cannot resolve around you.

"DNSSEC prevents tunneling." DNSSEC authenticates records so that responses cannot be forged, which counters spoofing and cache poisoning. It does nothing to stop an attacker from encoding data into queries to a domain they own. The two address different problems.

"The payload is encrypted, so we cannot detect it." Detection here does not depend on reading the payload. It depends on the shape of the traffic: volume, label length, entropy, record-type mix, and unique-subdomain ratio. Those remain visible at a resolver you control even when the labels are encoded or the last hop is encrypted.

"Only advanced actors use it." Ready-made tunneling toolkits are widely available, and commodity intrusions use them whenever a network leaves DNS open and unwatched. The barrier to entry is low.

Frequently asked questions

What is the difference between DNS tunneling used for exfiltration and for command and control? The mechanism is the same covert channel, and the direction of emphasis differs. Exfiltration, mapping to Exfiltration Over Alternative Protocol (T1048), pushes stolen data outward in the query names. Command and control, mapping to Application Layer Protocol: DNS (T1071.004), uses the two-way channel to task an implant, with commands returned in the answers. Many tools do both over one tunnel.

Why is DNS tunneling so slow? A DNS name is capped at 253 characters with 63-character labels, and only hostname-safe characters are valid, so data must be encoded into an alphabet that expands it. Each query therefore carries only a small usable payload, and moving a meaningful amount of data requires many queries. The inefficiency is inherent to the protocol.

Does encrypted DNS (DoH or DoT) make tunneling undetectable? It hides query contents from on-path network sensors, which removes the entropy and label-length signals at the network layer. The countermeasure is policy: require clients to use approved resolvers, block or steer unauthorized encrypted DNS endpoints, and run the behavioral analysis at the resolver, where the queries are decrypted and visible again.

How is DNS tunneling different from DNS spoofing? They are unrelated beyond both involving DNS. Tunneling smuggles data through queries to a domain the attacker owns, as a covert transport. Spoofing forges DNS answers to redirect a victim to an attacker-controlled address. One is a channel for moving data, the other is a manipulation of resolution results.

What is the single most important control? Funnel all DNS through resolvers you operate and log. Block outbound port 53 to anywhere else, and steer or block unsanctioned encrypted DNS. Every behavioral detection depends on this, because you cannot analyze traffic you never see. NIST SP 800-81-2 covers deploying DNS securely.

Can legitimate services trigger tunneling alerts? Yes. Some content delivery networks, antivirus lookups, and security telemetry generate long or high-entropy names, and a few use TXT records heavily. This is why detection combines several signals and scores them rather than alerting on any one. Building a per-environment baseline and allowlisting known-good high-volume domains reduces the noise.

Where does DNS tunneling fit in an attacker's overall plan? It is typically a fallback or a resilient secondary channel rather than a first choice, chosen when direct outbound paths are blocked or when the attacker wants a low-and-slow route that survives strict egress control. Our Exploit Intelligence dashboard tracks the tooling attackers pair with covert channels like this one.

DNS tunneling thrives on a protocol defenders leave open and unwatched. It is slow, but it reaches out where other channels are blocked, which is exactly why attackers keep it in the kit. Force all DNS through resolvers you control, log every query, retain the logs long enough to baseline what normal looks like, and hunt for the shape of the traffic rather than its content. Do that, and the covert channel that once ran unseen becomes one of the easier techniques to catch.

Related guides

• DNS Spoofing Explained
• Command and Control Explained
• DNSSEC Explained
• Threat Hunting Guide