DNS looks like a terrible place to move data. Names are tightly structured, messages are small, and a recursive resolver usually sits between the client and whatever finally answers.
It’s still enough to build a channel. DNS tunneling repurposes ordinary questions and answers so that application data rides inside them. The result is slow and cramped next to a real TCP connection, but it can cross a restricted network as long as the permitted DNS path still resolves the tunnel’s zone, even after other outbound routes are shut. That reach is one reason behind why attackers use DNS.
The path is already there
A DNS lookup runs in two directions. The client asks a question, and a server sends an answer back. A tunnel keeps that path and changes what the data means. Part of the query becomes a message from the client. Part of the response becomes a message in return.
To give those messages a destination, the operator controls a zone, say tunnel.example.com, delegated to authoritative infrastructure they run. A client asks its normal recursive resolver for a name beneath that zone:
QNAME: a7f3c9012e.0001.tunnel.example.com.
QTYPE: TXTThe resolver handles the name the usual way, following referrals until it queries the tunnel zone’s own authoritative server. That’s ordinary DNS delivering a question to the server responsible for the name. The resolver never needs to understand the tunnel. It only has to process valid DNS.
Data rides in the names and the answers
The upstream direction lives in the QNAME. A domain name is a sequence of labels, and the leftmost labels can carry client-chosen data, here a7f3c9012e as payload and 0001 as a sequence number so the far end can reassemble a larger message from many queries. Arbitrary bytes are first encoded into something that survives every DNS component along the path. The encoding is an implementation choice, not a DNS feature.
The downstream direction lives in the answer, and here the record type matters, because it trades capacity against stealth. (In these recursive tunnels the upstream side rides in the query name whatever the query type, and the record type shapes only the return channel.) TXT records are an obvious carrier since they hold arbitrary octets, and NULL records carry raw bytes with even less framing, though NULL is an experimental type that often doesn’t survive the path. Toward the other end, data can be encoded into the names in CNAME or MX answers, or packed into the addresses of A and AAAA records four or sixteen bytes at a time. A and AAAA answers carry far less per response, but those lookups are so ordinary that they tend to draw less scrutiny than a stream of TXT or NULL queries, even if the long, high-entropy names still stand out to anything watching the names themselves. No tunnel is committed to a single record type. It needs only that both endpoints agree on how to read the bytes and that the path preserves them.
DNS caps how much fits. A single label tops out at 63 octets and a full wire-format name at 255, and the fixed zone suffix plus the tunnel’s own framing eat into that. The payload per query is small, so anything sizable is split across many exchanges.
The answer only comes when the client asks
A conventional tunnel built on ordinary queries has a structural constraint. The authoritative side can’t push an unsolicited response back through the resolver whenever it likes. It has to wait for a query. Downstream data is therefore paced by the client’s questions, which produces polling. Even with data ready to send, the server sits idle until the client generates the next exchange to collect it.
The resolver is part of the transport
The recursive resolver doesn’t just pass traffic. It shapes the channel. The client typically talks only to the resolver its operating system configured, and the resolver does the upstream work, so the authoritative server usually sees queries arriving from a resolver rather than straight from the endpoint.
Each leg can also use a different transport. DNS runs over UDP or TCP, and the client may reach its resolver over encrypted DNS. The tunnel depends on DNS semantics, not on every packet being UDP port 53, so what you can see comes down to where you stand. Endpoint telemetry can name the process. A resolver logs QNAMEs and query types. The authoritative server sees only what reaches its zone. A passive network sensor may see very little once the transport is encrypted.
Caching works against the tunnel
DNS caching speeds up normal resolution by answering repeat questions locally. For a tunnel that’s a problem, not a help. Repeat the same QNAME and type while the previous answer is still cached and the resolver answers itself, so the authoritative server never sees the query and no new upstream message arrives.
Tunnels design around this by making every question distinct, usually by varying the name each time and sometimes by returning zero-TTL answers, so nothing is a cache hit. That also means the tunnel doesn’t own its own path. Resolvers enforce their own policies, and forwarding layers can insert further caches between client and authoritative server.
Tunnels stay narrow no matter the transport
Classic DNS over UDP was capped at 512-byte messages. EDNS lets larger UDP payloads be advertised, and general-purpose DNS implementations must also support DNS over TCP. None of that turns DNS into a bulk pipe. Name limits still bound the upstream payload, encoding and framing consume space, recursion adds latency, and middleboxes and resolver policies can change how unusual query types or sizes behave. A working tunnel lives inside those constraints rather than escaping them.
Command-and-control needs even less
Tunneling and DNS command-and-control get discussed together, but they’re different kinds of thing. Tunneling is a transport technique, command-and-control is a purpose, and one can ride on the other. They also tend to differ in scale. A tunnel may carry a continuous bidirectional stream across many exchanges, while a command channel may need only the occasional query to signal state, request a task, or return a short result.
MITRE ATT&CK classifies DNS as an Application Layer Protocol sub-technique for command and control, covering commands and results embedded in DNS traffic well beyond a high-volume tunnel. The lesson for telemetry is that the absence of a large or continuous data stream doesn’t make DNS-based command traffic benign.
Detection works on patterns
Tunneled DNS still has to look like DNS to the infrastructure carrying it, but the workload leaves statistical and behavioral traces. Signals worth investigating include:
- Many unique subdomains beneath a single parent domain
- Labels that are unusually long or encoded-looking for the environment
- Steady, repeated queries to a domain with little other use
- Query types or response sizes that stand out from the surrounding workload
- DNS activity from a process that doesn’t normally generate it
No single signal is a verdict. CDNs, tracking systems, service discovery, and anti-abuse platforms all generate strange names and high query volumes. Detection gets stronger when several observations agree, which is why MITRE’s tunneling detection guidance leans on behavioral combinations rather than one field.
Even a fully visible exchange has a limit. A resolver can show that an endpoint asked hundreds of unique questions under one domain, and measure the label lengths, the query types, the timing. It often can’t tell you what the encoded bytes mean, since the payload may be compressed or encrypted before it ever enters a name, though a known encoding or a recognized tunnel tool can be decoded or fingerprinted. DNS reveals the shape of a hidden channel. It doesn’t always explain the channel on its own.
Summary
DNS tunneling works because ordinary DNS already carries client-chosen names toward authoritative infrastructure and returns structured data the other way. A tunnel repurposes that path into a narrow, query-driven channel, and resolvers, caching, label limits, and transport behavior all shape what it can do.
Those same constraints leave traces, but no lone long label, TXT query, or burst of subdomains convicts on its own. The security value is in the context: who asked, how often, under which domain, with what name structure, and what happened around the DNS activity.