What is DNS tunneling and how do you spot it?

DNS tunneling is a technique where an attacker hides commands or stolen data inside DNS queries and responses. Because most networks must allow DNS, the traffic often passes filters that would block other protocols. You spot it by looking for long, random-looking subdomains, high query volume to one domain, and heavy TXT record use.

Why does DNS make a good covert channel?

DNS is the phone book of the internet, and almost nothing works without it. Firewalls that block web uploads to unknown hosts will still let a laptop ask its resolver for a name. MITRE ATT&CK describes this under technique T1071.004: adversaries use DNS to blend in with existing traffic, and DNS may even be allowed before a device has finished network authentication.

The attacker controls an authoritative name server for a domain they own. Any lookup for a name under that domain ends up at their server, no matter which resolver the victim uses. That server can read the question and write whatever answer it likes.

How does the data actually travel?

Outbound data rides in the name being asked for. The client encodes a chunk of bytes, often in base32 or hex, and uses it as a subdomain. Inbound data rides in the answer, commonly a TXT record because it holds free text, though CNAME, MX and other record types work too.

RFC 1035 limits a single label to 63 octets and a full name to 255 octets. That caps how much one query can carry, roughly on the order of a hundred bytes after encoding and the parent domain. So tunnels send many queries, and that volume is the thing defenders can see.

A constructed example. A compromised build server starts sending lookups like mfrggzdfmztwq2lknnwg23tpobyxe43uov3ha3dpmr2xk.stats-cdn.example. A second later comes another with a different string. In an hour the resolver log shows tens of thousands of unique names under one parent that no developer has ever visited.

What are the signs in your logs?

No single sign proves it. Together they are hard to explain away.

1. Unusually long subdomain labels with high randomness.
2. A huge count of unique subdomains under one parent domain.
3. A host sending far more DNS queries than its peers.
4. Large or frequent TXT, NULL or other uncommon record types.
5. Queries to a recently registered domain with no web presence.
6. Regular, timer-like spacing between queries (beaconing).

Legitimate software produces some of these. Antivirus lookups, some email security checks and CDNs use odd-looking names. Build a baseline first so you can tell them apart.

How do you stop it?

The strongest control is to remove choice. Make internal clients use your own resolvers and block outbound port 53 and DNS over TLS or HTTPS to anything else. If a host cannot reach the attacker's server, either directly or through a resolver you control, the tunnel has no path unless your resolver forwards the queries.

Your resolver then becomes the place to inspect. Log every query, keep the logs, and alert on the signs above. Filtering by domain age or reputation catches many tunnels, but a patient attacker can buy a domain months ahead.

How to check or apply this

1. Confirm that clients can only reach approved resolvers, and test it from a laptop on each network segment.
2. Turn on query logging at the resolver and ship it to where you search logs.
3. Rank internal hosts by unique subdomains per parent domain over 24 hours and review the top ten.
4. Rank domains by average label length and by TXT share of responses.
5. Add a rule for first-seen domains that receive more than a threshold of unique queries.
6. Write down known noisy tools so analysts do not chase them each week.

Quick check

Sources

1. MITRE ATT&CK T1071.004, Application Layer Protocol: DNS
2. RFC 1035, Domain Names: Implementation and Specification
3. MITRE ATT&CK, Exfiltration tactic TA0010

Last reviewed: 18 October 2026.