DNS Tunneling and Egress Control: Closing the Channel That Almost Always Works

When an egress firewall blocks outbound traffic to the internet, there is one protocol it almost always has to leave open: DNS. Name resolution has to work, or nothing else does. That requirement makes the resolver a channel, and DNS tunneling is what happens when an attacker encodes data into queries and answers to move it in and out of a network.
The technique is old, which is part of the problem. It appears in public tooling, it survives in environments with otherwise careful egress rules, and it is often assumed to be covered by a control that only looks at the payload of an HTTP request.

How the channel is built

A tunnelling client controls a domain and a name server for it. To send data outbound, the client encodes the data into a label of a query for a subdomain it owns, such as a base32 or base64 string followed by the attacker's domain. The recursive resolver forwards the query, the attacker's name server receives it, and the encoded content is recovered from the label.
To send data inbound, the attacker's name server returns a resource record whose content carries the encoded response, for example in a TXT record or in a carefully sized A record.
The volume per query is small, so a tunnel is slow. That is not a defence. Slow exfiltration of a few credentials or a configuration file is often enough, and the traffic looks like DNS.

The signatures that survive casual inspection

Detection rests on the fact that most legitimate DNS traffic is boring. Records are cached, names are repeated, and query lengths are short. A tunnel breaks those properties in specific ways.
Query name length and entropy stand out. Legitimate subdomains are words. A long, high-entropy label, especially one that changes on every query, is unusual. Volume per domain is a second signal: one parent domain receiving thousands of queries, or many distinct subdomains under one parent, is not how normal resolution behaves.
Query type is a third. A high rate of TXT queries, or of null or unusual record types, is uncommon in ordinary client traffic. Response size is a fourth: answers much larger than typical for the name being resolved, particularly for names that should not be answering at all.
Client behaviour matters as much as the content. One host that produces an outsized share of an organisation's total DNS queries, or a host whose queries never repeat, is worth investigating regardless of the content of the queries.

Why "block it at the firewall" is not a complete answer

Many organisations route all client DNS through an internal resolver and block direct outbound DNS from clients. That is the right first control, and it closes the easiest version of the attack. It does not close the channel, because the attacker's encoded data still travels through the resolver to the attacker's authoritative name server.
What the internal-resolver-only design does give you is visibility. Every query from every client passes through a point you control, which is where the detection belongs.

A layered control set

Four layers work together.
Route all client DNS to a resolver you own, and block client-initiated DNS to external resolvers at the network edge. This removes the cases where a host speaks directly to an attacker's name server.
Log queries at the resolver with the requesting client, the query name, the query type, and the response size. Most resolvers can do this, and the resulting data set supports every detection below.
Baseline normal behaviour. Record typical query length and entropy per client, the most-queried domains, and the daily query count per host. The detections only work relative to a baseline.
Apply the detections. Long high-entropy labels, a single parent domain with an unusual number of distinct subdomains, an unusually high TXT query rate, and any client whose query volume diverges sharply from its own baseline.

Where the attacker goes next

If DNS is closed as a channel, the pressure moves to whatever else egress allows. That is the argument for treating egress policy as an inventory exercise rather than a firewall rule set. Every allowed destination and protocol is a candidate channel, and the honest position is that most networks allow more than they can enumerate.
The practical approach is to allow egress by destination and purpose rather than by protocol, to log what actually traverses each allowance, and to review the allowances that produce no legitimate traffic. A DNS resolver that follows this model is a control, not a convenience.

What to take away

DNS tunnelling works because name resolution cannot be fully blocked. The countermeasure is not to block it but to centralise it, log it, baseline it, and alert on the specific properties that ordinary resolution never produces: long high-entropy labels, high subdomain counts under one parent, unusual query types, and hosts that suddenly behave unlike themselves.

References

• MITRE ATT&CK, T1071.004: Application Layer Protocol - DNS
• MITRE ATT&CK, T1048: Exfiltration Over Alternative Protocol
• IETF, RFC 1035: Domain Names - Implementation and Specification
• CISA, Secure by Design: Egress filtering guidance (verify current URL)