DNS exists to translate example.com into an IP address. It is the most boring, most trusted protocol on the internet — so trusted that firewalls, captive portals, and locked-down corporate networks routinely allow DNS queries to leave even when they block nearly everything else. DNS tunneling weaponizes that trust by stuffing arbitrary data into the parts of a DNS exchange that were meant to carry names and answers.
The result is a low-bandwidth, high-latency, but remarkably resilient channel that can carry stolen data out of a network (exfiltration) or carry attacker commands in (command-and-control, or C2). It is slow, but it works where nothing else does.
The mechanics
The setup requires one thing: the attacker controls an authoritative nameserver for a domain they own — say t.evil-c2.com. Whenever any resolver anywhere needs to answer a query for a subdomain of evil-c2.com, the global DNS hierarchy will eventually route that query to the attacker's server. That routing is the tunnel.
To send data out, malware on the victim machine encodes the payload — say, a chunk of a stolen file — into the labels of a DNS name:
MFRGGZDF.MZXW6.t.evil-c2.com
Base32-encoded data stuffed into subdomain labels
The victim's machine asks its normal recursive resolver to look this name up. The resolver, doing its ordinary job, walks the DNS hierarchy and hands the query to the attacker's authoritative server. The attacker decodes the labels back into the original bytes. No data ever left over a "suspicious" port — it left as a perfectly ordinary name resolution.
To send data back in, the attacker's server answers with record types that can carry payload: a TXT record can hold a few hundred bytes of arbitrary text, while CNAME, NULL, or even crafted A/AAAA answers can encode commands. The malware reads the answer, executes the instruction, and encodes the response into its next query. Round and round — a full bidirectional channel built entirely from name lookups.
In recursive mode, the malware never talks to the attacker's server directly — it talks only to the network's own trusted resolver, which unwittingly relays everything. To the local network, the infected host is just making DNS queries to the resolver it's supposed to use. That's what makes egress filtering so hard to apply here.
Direct vs. recursive tunneling
| Mode | How it routes | Trade-off |
|---|---|---|
| Direct | Malware sends queries straight to the attacker's nameserver IP | Faster, but easily blocked if outbound port 53 to arbitrary hosts is filtered |
| Recursive | Malware uses the network's own resolver, which relays to the attacker | Slower and noisier, but blends in and survives strict egress rules |
Several mature tools implement this — iodine, dnscat2, and others — originally as research, network-testing, or captive-portal-bypass utilities. Like most dual-use tooling, the same code that demonstrates the technique academically is what gets repurposed in real intrusions.
What it's good and bad at
DNS tunneling is not a high-speed pipe. Each query carries at most a couple hundred usable bytes, queries are throttled by caching and round-trip latency, and the whole thing is chatty. Exfiltrating a large database this way would take an absurd amount of time and generate a mountain of queries.
What it is good at is exactly the jobs that need a trickle, not a flood: leaking credentials and small secrets, maintaining a quiet C2 heartbeat, or beaconing out of a network that otherwise has no path to the internet at all. It is a channel of last resort that is annoyingly hard to close — which is why it persists.
Detecting and defending
Because the traffic is technically legitimate DNS, defense is about spotting anomalous DNS, not blocking the protocol.
Signals that something's off
- Query volume to one domain. A single second-level domain receiving thousands of unique subdomain lookups from one host is a glaring tell.
- High-entropy, long labels. Real hostnames are short and word-like; encoded payloads look like random base32/hex strings and run near the length limit.
- Unusual record types. A spike in
TXTorNULLqueries from endpoints that have no reason to request them. - Low cache-hit ratios. Tunnels need unique names every time (or the cache would answer and break the channel), so caching never helps them.
Controls
- Funnel all DNS through controlled resolvers and block direct outbound port 53 from endpoints, forcing the noisier recursive mode and giving you one place to inspect.
- Deploy DNS firewalling / Response Policy Zones (RPZ) and threat-intelligence feeds to block known tunnel domains.
- Apply statistical / behavioral analytics on DNS logs for the entropy and volume patterns above.
- Rate-limit per-client query volume to a single domain.
The uncomfortable truth is that you cannot turn DNS off, and "allow all DNS" is the default almost everywhere. Defense means treating your DNS logs as a security data source, not just operational plumbing.
The bigger picture
DNS tunneling sits in the same family as every other covert-channel technique: take a protocol everyone trusts and overload it with a meaning it was never designed to carry. It's a close relative of the broader privacy concern that DNS queries reveal far more than people expect — the subject we explore in DNS leaks and in the case for encrypted DNS. Whether the goal is surveillance of your browsing or smuggling data past a firewall, the lesson is the same: the internet's phone book sees everything, and that visibility cuts both ways.