DNS Tunneling

DNS tunneling is a technique that hides non-DNS data, such as stolen files or command-and-control traffic, inside ordinary DNS queries and responses. An implant encodes the data into the subdomains it looks up, and an attacker-controlled name server decodes it and answers back. Because networks rarely block DNS, the channel slips past filters that would stop almost anything else.

DNS is the one protocol nearly every network has to leave open, so it becomes a quiet way to carry data past defenses that watch everything else. The same trick serves two different jobs, works with off-the-shelf tools, and has carried some of the most serious intrusions on record.

This page explains how DNS tunneling actually works, what it is used for, the real tools and attacks behind it, why you cannot simply block it, and how defenders detect it, including what changes as DNS itself becomes encrypted.

Explain It Like I'm 10

Imagine a building where one mail clerk may carry any envelope in or out, and nobody checks what is inside, because the mail always has to keep moving. So instead of hiding a message in the envelope, you hide it in the address on the front. The clerk carries it to the one office that can turn that address back into a message, and brings back the reply written on the next address. DNS tunneling works the same way: it hides data in the web addresses a computer looks up, because those lookups are always allowed through.

How DNS tunneling actually works

Normal DNS is simple: a computer asks "what is the address for this name?" and a server answers. DNS tunneling abuses that request-and-answer exchange to move data that has nothing to do with looking up a website. It works because DNS resolution will happily route a query for any domain to whichever name server is responsible for it, and the attacker owns a domain, so they own the server that receives the query.

The outbound half: data in the query

To send data out, malware encodes it into the subdomain of a lookup for a domain the attacker controls. MITRE ATT&CK documents this directly: the NightClub malware "can use a DNS tunneling plugin to exfiltrate data by adding it to the subdomain portion of a DNS request." The queries are crafted to look unremarkable. The Uroburos toolkit, for instance, "encoded outbound C2 communications in DNS requests consisting of character strings made to resemble standard domain names." To the network, it looks like a machine resolving an odd but plausible hostname.

The inbound half: data in the answer

The reply comes back the same way, encoded into DNS records. Commands "may be embedded into different DNS records, for example, TXT or A records," and both the commands and their results ride inside this ordinary-looking traffic. TXT records are a favorite because they are meant to hold arbitrary text, which makes them roomy containers for encoded data.

Put end to end, the round trip is what turns this into a channel. The victim's machine looks up a long, encoded name; ordinary DNS resolution, doing exactly its job, forwards that query hop by hop until it reaches the name server responsible for the attacker's domain, which is the attacker's own server. That server reads the data out of the subdomain, acts on it, and encodes its reply into the record it sends back. Neither side ever opens a connection a firewall would think to question. In MITRE's more general terms, this is protocol tunneling: "explicitly encapsulating a protocol within another" to avoid detection and network filtering.

Two jobs: command-and-control and data exfiltration

The same mechanism serves two distinct purposes, and it is worth keeping them separate.

As a command-and-control channel, DNS tunneling lets an attacker send instructions to malware and receive results, all over DNS, with the commands and their results embedded in the ordinary-looking query traffic. It works as a stealthy primary channel, and it works just as well as a fallback: when a noisier channel like HTTP is blocked, malware can quietly switch to DNS and keep operating.

The exfiltration variant

As data exfiltration, it is a way to steal data out of a network over a protocol that is not the main C2 channel, what MITRE calls exfiltration over an alternative protocol. There is a catch that shapes how attackers use it: DNS is a low-bandwidth pipe. Squeezing data through lookups is slow and noisy, so DNS exfiltration tends to carry small, high-value things, such as credentials or system metadata, rather than bulk files, and careful operators throttle it deliberately to stay quiet. MITRE catalogs this under exfiltration over an alternative protocol, in variants that range from unencrypted encoding to fully encrypted channels, but the DNS-tunneling shape is the same each time.

The tools, and the real attacks

DNS tunneling is not theoretical, and it is not hand-built each time. Documented tools and named campaigns have used it for years.

The tools

Two utilities come up constantly. iodine is a general-purpose tool that, in its own words, "lets you tunnel IPv4 data through a DNS server," which is also a reminder that the technique has legitimate uses. dnscat2 is more pointed: it is "designed to create an encrypted command-and-control (C&C) channel over the DNS protocol, which is an effective tunnel out of almost every network." Both are used by penetration testers and, in the same breath, by real intruders.

The attacks

The marquee case is SUNBURST, the malware behind the 2020 SolarWinds supply-chain compromise, which used DNS for command-and-control traffic designed to mimic normal SolarWinds API communications. The disguise is the point: the tunnel was built to look like the traffic that software was already supposed to generate, so it blended into an environment that trusted it.

Other campaigns fill out the pattern:

• OilRig (Iran) has used DNS for C2, and its ISMAgent malware "falls back to its DNS tunneling mechanism if it is unable to reach the C2 server over HTTP." Tunneling here doubles as a resilient backup for when a primary channel is cut.
• ProjectSauron, a high-end espionage platform, ran its DNS exfiltration deliberately "in low-bandwidth mode" to stay under network detection, using it only for small, high-value metadata rather than bulk theft.
• DNSMessenger, documented by Cisco Talos in 2017, ran an entire command loop over DNS TXT records, with no file ever written to disk.

This is a measured trend, not a handful of anecdotes. Palo Alto's Unit 42, reviewing years of traffic, found that "well-known campaigns using DNS tunneling include SUNBURST, OilRig, xHunt, and DarkHydrus," alongside newer clusters they tracked as FinCounter and Decoy Dog. The technique persists because the payoff, a channel that hides in traffic nobody can switch off, keeps being worth the low bandwidth.

Why you can't just block DNS

The obvious question is why defenders do not simply block or strip out this traffic. The answer is that DNS is load-bearing infrastructure. As MITRE puts it, the protocol "serves an administrative function in computer networking and thus may be very common in environments," and "DNS traffic may also be allowed even before network authentication is completed." It normally travels on UDP port 53, which is open on virtually every client, server, and firewall by default. Turn it off and nothing resolves. On top of that, "DNS packets contain many fields and headers in which data can be concealed," so even inspecting it closely is not trivial.

There is also a legitimate-use wrinkle. The same tunneling technique is used to get ordinary internet connectivity past captive-portal Wi-Fi, which is part of why DNS is left so permissively open in the first place. It is genuinely dual-use, not purely an attack.

The DoH problem

The ground is also shifting. DNS is increasingly sent over encrypted transports, and DNS over HTTPS (DoH) is the one that matters most here. When queries travel inside HTTPS, the classic approach of inspecting DNS payloads at the network stops working. As Palo Alto notes, "devices that route DNS queries over HTTPS (DoH) can bypass enterprise DNS controls." That does not make DNS tunneling undetectable, but it does move the useful signals off the wire and onto endpoints and resolver logs. It is a real gap, and it is why detection strategy is changing.

In practice, that shifts where you have to watch. When the network can no longer read the queries, the signals move to the places DNS is still visible in the clear: on the endpoint that makes the lookups, and in the logs of the resolver that answers them. Teams that relied purely on network DNS monitoring have to add endpoint and resolver telemetry to keep the same visibility. That is a real operational cost, not a toggle.

How defenders actually detect DNS tunneling

Since you cannot block DNS, you read it. Tunneling leaves statistical fingerprints that ordinary lookups do not, and detection keys on those rather than on any single blocked indicator. The signals fall into three groups.

Payload signals

The content of the queries gives it away. Tunneling "often involves excessively long domain names, sometimes reaching the maximum limit of 255 characters," and those names "typically exhibit high entropy, meaning they contain random-looking sequences that lack common linguistic patterns." The record types are a tell too: TXT, NULL, and CNAME records "are often exploited for data exfiltration, as they allow the storage of arbitrary text or encoded data."

Traffic signals

Behavior gives it away as well. Tunneling relies on many lookups, so "a sudden spike in DNS request traffic can indicate tunneling," and because tools cycle through generated names, defenders watch for "high DNS query volume to randomized subdomains from the same second-level domain." Failed lookups pile up too: "excessive NXDOMAIN responses may indicate malicious activity."

Real tooling

These signals are built into detection products. Elastic ships a prebuilt rule that flags repeated nslookup executions with an explicit query type from one host as possible "command and control activity utilizing the DNS protocol." Rules like it turn the abstract signals above into something a SIEM can alert on.

The research literature pushes further into statistics. One peer-reviewed study found that Shannon entropy, a measure of randomness, "measures uncertainty of the given domain name and it provides fast and accurate results in real-time," which is why entropy scoring shows up in so many production detections.

No silver bullet

None of this is a silver bullet. Legitimate services like content delivery networks and some security telemetry can look tunnel-like, so these are signals with false positives that need tuning, not blind trust. And as DoH spreads, some of them move off the network and onto the endpoint. Detection raises the odds you catch a tunnel; it does not guarantee it. The practical starting point is a baseline of what normal DNS looks like in your environment, so the long, random, high-volume outliers have something to stand out against.

The one thing to remember

DNS tunneling works by abusing the one protocol you cannot turn off. That single fact drives everything else: you will not block your way out of it, so the job is to read DNS behavior, watch for the long, high-entropy, high-volume patterns that ordinary lookups do not produce, and increasingly to watch the endpoint as encrypted DNS moves the evidence off the network. If you want the next step, that is where detection engineering comes in, writing a specific rule for these patterns, and it sits right next to the broader question of how command-and-control channels work in general.