What Is DNS Tunneling? Hiding Data in DNS Queries

DNS tunneling encodes arbitrary data — commands, files, stolen credentials — inside DNS queries and responses, using the domain name system as a covert channel instead of its intended job of resolving names to IP addresses. It works because DNS traffic is almost universally allowed out of corporate and home networks unfiltered: firewalls that block nearly everything else typically let DNS queries pass, since blocking them would break basic internet connectivity.

That trust is what makes DNS tunneling attractive to attackers, and also what makes it hard to fully eliminate without breaking legitimate DNS traffic.

How it works

A DNS tunnel needs two things: a domain the attacker controls, and an authoritative name server for that domain that runs custom tunneling software instead of a standard DNS resolver.

1. The client encodes data into a subdomain label — something like a8f3e91b2c.tunnel.attacker-domain.com — and sends it as a normal-looking DNS query.
2. That query travels through the victim’s local resolver, then upstream through the DNS hierarchy, exactly like any other lookup, because nothing about the query format looks abnormal.
3. It eventually reaches the attacker’s authoritative name server, which decodes the subdomain back into data instead of returning a real IP address.
4. The response — also just a DNS answer, often in a TXT or CNAME record — carries data back the other direction, such as a command for the client to execute next.

Because each individual query is small, tunneling data at any real volume means chaining together large numbers of queries, encoding a fragment of the payload into each one. This is slow compared to a normal TCP connection, but it doesn’t need to be fast — it needs to be invisible.

What it’s used for

• Command-and-control (C2). Malware on a compromised host uses DNS queries to fetch commands and report status back to an attacker, without opening a suspicious outbound connection on an unusual port.
• Data exfiltration. Sensitive data gets broken into chunks and smuggled out as a stream of DNS queries, often the last resort when other outbound channels are blocked.
• Bypassing captive portals or paid Wi-Fi. Less malicious, but the same technique — since DNS is resolved before a captive portal authenticates a device, some people tunnel actual internet traffic through it to get free access.

Why it evades typical firewalls

Most firewall rules are built around ports and protocols: block inbound traffic on unused ports, restrict outbound HTTP to approved proxies, flag unusual TLS destinations. DNS, by convention, runs on port 53 and is rarely subject to the same scrutiny, because the assumption baked into most network designs is that DNS queries are short, harmless, and essential.

A WAF or web proxy inspecting HTTP traffic never sees DNS tunneling at all — it isn’t HTTP. And unlike a technique such as DNS cache poisoning, which corrupts a resolver’s cache to redirect other users, tunneling doesn’t need to trick anyone; it just uses DNS exactly as designed, for a purpose it wasn’t designed for.

Detecting it

DNS tunneling leaves patterns that look different from normal DNS traffic, even though each individual query is valid:

• Query volume and frequency. A host generating hundreds of DNS queries a minute to the same parent domain is unusual; normal browsing generates queries to many different domains, not a stream to one.
• Subdomain entropy. Encoded data looks close to random when you compute the entropy of the subdomain label. Real hostnames are short, pronounceable, and drawn from a small, human-generated vocabulary; tunneled data looks like x7q2mza9f1.
• Unusual record types. A high volume of TXT or NULL record queries to one domain is a signal — those record types carry more arbitrary data per query than a standard A record lookup, so tunneling tools favor them.
• Query length. DNS labels have a maximum length, and tunneling tools tend to use as much of it as possible to maximize throughput, producing consistently long subdomains rather than the mixed lengths of normal traffic.

Dedicated DNS security tooling and many modern firewalls build detection around exactly these signals, since blocking DNS outright isn’t an option.

Mitigations

Full prevention is difficult because DNS has to work, but a few controls meaningfully raise the cost of tunneling:

• Restrict DNS resolution to approved internal resolvers. Block hosts from querying external DNS servers directly, forcing all lookups through a resolver you control and can inspect — this is also what makes DNS over HTTPS tricky from a defender’s perspective, since it can bypass that same chokepoint if left unmanaged.
• Rate-limit and log DNS queries per host, and alert on the volume and entropy patterns above.
• Block newly registered or low-reputation domains at the DNS layer, since attacker-controlled tunneling domains are often registered close to when they’re used.
• Segment networks so that even a successful tunnel on one host has limited reach to the rest of the environment.

The takeaway

DNS tunneling abuses the fact that DNS queries are almost always allowed through firewalls unfiltered, encoding data into subdomains and record responses to build a covert channel for command-and-control or exfiltration. It doesn’t exploit a DNS vulnerability — it exploits the trust built into how networks are configured. Detecting it comes down to spotting DNS traffic that behaves nothing like normal name resolution: high query volume to one domain, high-entropy subdomains, and unusual record types.