DNS tunnelling and exfiltration – how it works and how to detect it

DNS is the protocol every network forgets to inspect. It is small, ubiquitous, almost always allowed outbound, and rarely proxied or logged in detail. That makes it the ideal covert channel: command-and-control traffic, data exfiltration, and beaconing can all be hidden inside what looks like ordinary name resolution. Tools like dnscat2, iodine, DNSExfiltrator, and frameworks like Cobalt Strike's DNS transport make this trivial. Understanding how DNS tunnelling works, and what it looks like when it does, is one of the higher-leverage gaps to close in many networks.

How DNS tunnelling works

DNS is a request-response protocol with a flexible payload. The query name itself can be up to 253 characters (split into labels of up to 63), and DNS responses can carry text in TXT, CNAME, NULL, and other record types. An attacker who owns a domain (say attacker.example) can encode arbitrary data as part of DNS messages:

• Outbound data – Client encodes data into subdomain labels of attacker.example and resolves it: c2VjcmV0LWRhdGE.attacker.example. The recursive resolver dutifully forwards it to the attacker's authoritative server.
• Inbound data – The attacker's server replies with data encoded in TXT, CNAME, NULL, or other record types: "your next command is base64-encoded in this TXT record."
• Polling and beaconing – The client wakes up periodically, sends a query encoding its state, and receives a command. This looks like an ordinary device doing DNS lookups.

Even with no full tunnel, DNS exfiltration is straightforward: chunk a file into base32 or hex, send each chunk as a subdomain query, and reassemble at the attacker's authoritative server. A few hundred queries per minute can move megabytes per hour out of a network that "blocks outbound traffic".

The protocol has helpful properties for attackers:

• Allowed everywhere – Almost no firewall blocks port 53 outbound to internal resolvers.
• Cached aggressively – DNS queries are designed to be high-volume and forgettable.
• Recursive resolvers do the work – The attacker never needs the victim to reach them directly; the local resolver forwards on the victim's behalf.
• Multiple record types – TXT, CNAME, MX, SRV, NULL, AAAA (encoding into IPv6 addresses) all offer payload space.
• DoH and DoT complicate inspection – If clients send DNS over HTTPS to public resolvers (1.1.1.1, 8.8.8.8), traditional DNS logging misses everything.

Real-world abuse patterns

DNS abuse is not just exotic APT tradecraft.

• C2 fallback – Frameworks like Cobalt Strike, Sliver, Empire, and dnscat2 ship with DNS transport as a stealthy alternative to HTTP(S). Often used as a fallback when HTTP beacons are blocked.
• Data exfiltration in incident response cases – Many post-breach reports note attackers using DNS to stage out sensitive files, particularly when egress filtering blocks direct outbound HTTP from sensitive zones.
• Living-off-the-land – nslookup, dig, Resolve-DnsName, and Windows' built-in resolver are all usable as transport, so endpoints need to drop or alert on no binary.
• Domain generation algorithms (DGAs) – Some malware doesn't tunnel through DNS, but uses it to find C2 servers by resolving algorithmically generated domains. The pattern (lots of NXDOMAIN responses to high-entropy names) is detectable in the same telemetry.
• DNS-rebinding-adjacent abuse – Returning short TTLs and varying answers to facilitate other attacks.

The common thread: DNS traffic is unusual when you look at it closely, but most networks never do.

Signals that DNS is being abused

DNS tunnelling tends to leave statistical fingerprints that ordinary DNS does not.

• Long, high-entropy query names – Genuine domains use English-language words and short subdomains. Encoded data looks like n4vp7y...-style randomness. Average label entropy is a strong feature.
• High query volume to a single domain – Most domains see a handful of queries per device per day. Tunnelled C2 or exfiltration generates dozens or hundreds per minute to one second-level domain.
• Unusual record types – TXT, NULL, and large CNAME chains are normal for some services but rare for most internal clients. A workstation suddenly making heavy TXT queries is suspicious.
• Repeated queries with slight variation – Same parent domain, ever-changing subdomain. Strong indicator of encoded payloads.
• Long DNS responses – Especially TXT records carrying long base64-like strings.
• Beaconing periodicity – Queries every N seconds with low jitter, even when the device is idle, look more like software than a human.
• NXDOMAIN bursts – Algorithmically generated domains usually fail to resolve; many DGAs produce visible spikes of NXDOMAIN responses.
• Resolver bypass – Clients sending queries directly to 8.8.8.8, 1.1.1.1, or a public DoH endpoint, when policy says all DNS should go through internal resolvers.

Any one of these in isolation has false positives. Combinations rarely do.

Detection strategies that work in practice

The goal is to get high-fidelity alerts without drowning analysts.

• Centralise resolver logs – Make sure all internal resolvers (Active Directory DNS, BIND, Unbound, Pi-hole, cloud resolvers) log queries and responses, with client IP, query, type, and response. Ship to a SIEM. Without this data, nothing else works.
• Block direct outbound DNS – Force all clients to use approved internal resolvers via firewall policy. Alert when any device queries an external DNS server directly.
• Control DoH/DoT – Either disable DoH in browsers via policy and block known DoH endpoints at the firewall, or run an enterprise DoH/DoT resolver and require its use. Pure ignore-and-hope is no longer viable.
• Per-client and per-domain baselines – Build daily baselines of "queries per client to a given second-level domain" and "average label entropy per domain". Alert on deviations: clients that suddenly resolve thousands of names under one domain, or whose mean label entropy spikes.
• Use existing tooling – Zeek (dns.log) produces excellent metadata; Suricata has DNS detection rules; commercial DNS security products (Cisco Umbrella, Cloudflare Gateway, Infoblox, DNSFilter) ship with tunnelling detections built in.
• Threat-intel domain blocking – Subscribe to feeds of known C2 and tunnelling domains; block at the resolver. Cheap and effective for off-the-shelf malware.
• Sinkhole and analyse – When a domain is flagged, point it at an internal sinkhole that logs the full queries. The encoded payload often makes the nature of the compromise obvious quickly.
• Endpoint visibility – EDR or eBPF agents can correlate the network event with the process that made the query (powershell.exe, cmd.exe, an unsigned binary in %TEMP%), turning a noisy DNS signal into a high-confidence detection.

Hardening: making DNS less useful to attackers

Detection alone is reactive. A few preventive measures reduce the value of DNS as a channel.

• Egress filtering with DNS proxying – Run a forced internal resolver chain; refuse DNS from any host that tries to bypass it.
• DNS response policy zones (RPZ) – Use RPZ on internal resolvers to block categories of domains (newly registered, low-reputation, known malicious) and force NXDOMAIN responses.
• Query type restrictions – Some environments can block exotic record types (NULL, large TXT queries from clients) at the resolver. Not always practical, but worth considering for high-sensitivity segments.
• Split horizon and least privilege for resolvers – Internal-only zones should resolve only internally; servers in restricted subnets should use a tighter resolver with more aggressive logging.
• Authoritative DNS hygiene – Keep your own DNS records tight; orphaned subdomains pointing at decommissioned services are subdomain-takeover bait, which can be used to host attacker infrastructure on your domain.
• Educate developers and ops – DNS-based "tricks" (custom subdomain wildcards for testing, ad-hoc TXT records for tooling) often muddy detection later. Standardise the patterns that are allowed.

DNS will always be a useful covert channel because it has to work everywhere and at scale. You will not eliminate the risk, but with centralised logging, sensible baselines, control over DoH, and process-level context from endpoint telemetry, DNS tunnelling and exfiltration stop being invisible and start being just another detection — usually one of the higher-fidelity ones you have.