Most networks allow outbound DNS because name resolution is basic plumbing: block it carelessly and users cannot reach the systems they need. Attackers have known this since before most current security tools existed, which is why DNS tunneling has stayed viable for over two decades: it doesn’t exploit a vulnerability, it exploits a protocol many organizations allow and under-monitor.

TL;DR

  • DNS tunneling encodes data — commands, files, credentials — inside DNS queries and responses, using the one outbound protocol that’s allowed through almost every firewall by design.
  • It’s not theoretical: SUNBURST (the SolarWinds backdoor) used DNS for C2 and victim identification, DNSMessenger ran entirely fileless through DNS TXT records, and the Decoy Dog campaign delivered staged payloads via TXT and CNAME records.
  • Detection doesn’t require deep packet inspection magic — subdomain entropy above ~4.0 bits/character, query labels over 50 characters, TXT queries exceeding ~10% of a client’s DNS traffic, and abnormal NXDOMAIN rates are all measurable, practical signals.
  • Popular tools (dnscat2, Iodine, DNSExfiltrator) each leave a slightly different fingerprint, but all share the same structural weakness: tunneling data through DNS is fundamentally noisier than normal DNS traffic, even when the payload itself is encrypted.
  • You almost certainly already have the logs to detect this — DNS query logging plus basic statistical thresholds catches most tunneling activity without buying a new product.

Why This Matters to You

If your DNS egress isn’t monitored — and for a large share of networks, it genuinely isn’t, because DNS is treated as infrastructure rather than an attack surface — you have a C2 and exfiltration channel that survives most network segmentation, most egress filtering, and a surprising number of “next-gen” firewalls that inspect HTTP deeply but wave DNS through with a shrug.

Table of Contents

How DNS Tunneling Actually Works

DNS resolution is designed to traverse the entire internet to find an authoritative answer, which is precisely the property attackers exploit. The core mechanic:

1. Attacker registers a domain they control the authoritative
   nameserver for (e.g. evil-domain.com)
2. Compromised host encodes data (a command result, a stolen
   file fragment, a beacon) into a subdomain label:
   <encoded-data>.evil-domain.com
3. Host issues a DNS query for that constructed hostname
4. The query traverses normal DNS infrastructure — local
   resolver, ISP resolver, root/TLD servers — completely
   normal-looking at every hop except the last
5. Because evil-domain.com's authoritative nameserver is the
   attacker's own server, the query eventually lands there,
   and the attacker decodes the embedded data from the
   subdomain that was queried
6. The response (an A, TXT, CNAME, or NULL record) can carry
   data back the other direction — commands, next-stage
   payloads, or acknowledgment — completing a bidirectional
   channel entirely inside "normal" DNS traffic

The elegance, from an attacker’s perspective: at no point does this require an unusual protocol, an unusual port, or a direct connection to attacker infrastructure from the compromised host. The compromised machine only ever “talks” to its normal, trusted DNS resolver — everything past that is invisible to host-based network monitoring and often to network-based monitoring too, unless DNS content itself is being inspected.

The Tools: dnscat2, Iodine, DNSExfiltrator

Three tools account for most observed DNS tunneling activity, each with a distinct fingerprint:

  • dnscat2 — purpose-built for command-and-control over DNS, with an encrypted channel by design. It’s the tool most associated with active, interactive C2 rather than pure data exfiltration, and its query patterns (specific label structure, consistent beacon timing) are well-documented enough that most modern detection signatures target it specifically.
  • Iodine — encapsulates full IPv4 packets inside DNS payloads, requiring a TUN/TAP virtual network device on both ends. This effectively builds a real IP tunnel over DNS, meaning anything — not just C2 traffic — can ride over it, which is more powerful and also considerably noisier than the alternatives.
  • DNSExfiltrator — purpose-built for one-directional data exfiltration rather than interactive C2, optimized to move files out over DNS queries with a focus on throughput per query rather than stealth of any individual packet.

All three share the underlying tell: legitimate DNS traffic doesn’t need to move meaningful volumes of data, so any tool that does inherently generates statistically abnormal query patterns, regardless of how well the individual queries are formatted.

Real Campaigns That Used It

This isn’t an academic technique — it’s been load-bearing in some of the most significant intrusions on record:

  • SUNBURST (SolarWinds, 2020) — the backdoor encoded victim identifiers and operational status into DNS queries as part of its C2 and reconnaissance flow, using DNS specifically because it was far less likely to be blocked or deeply inspected than HTTP-based C2 across the thousands of enterprise networks it landed in.
  • DNSMessenger (2017, still referenced as a technique template) — a fully fileless malware framework that used DNS TXT record queries to receive commands and exfiltrate results, writing nothing to disk at any stage, making traditional file-based AV detection structurally unable to see it.
  • Decoy Dog (2023) — used TXT and CNAME records specifically to deliver staged payloads to already-compromised hosts, demonstrating that DNS tunneling isn’t limited to initial beacon/exfil use cases — it can carry an entire post-compromise toolkit delivery pipeline.
  • APT32 and APT41 — both documented encoding stolen data directly into DNS subdomain labels as an exfiltration channel, favoring it specifically in environments with strict HTTP/S egress proxying but comparatively unmonitored DNS.

Detection: What Actually Works

The good news for defenders: DNS tunneling is statistically loud even when it’s protocol-compliant, because normal DNS traffic and “DNS carrying an encoded payload” have measurably different shapes. Four signals, usable with query logs you likely already have:

  • Subdomain entropy. Legitimate hostnames are words or recognizable strings; encoded tunnel data looks like random noise. Subdomain labels with Shannon entropy above ~3.5–4.0 bits/character are a strong indicator of encoded content rather than a human-chosen name.
  • Query and label length. DNS allows labels up to 63 characters and full names up to 255 — tunneling tools maximize payload per query by pushing close to those limits. Flagging queries with subdomain labels over 50 characters is a strong starting heuristic, but tune it against your own DNS baseline before treating it as a high-confidence alert.
  • TXT record ratio. TXT records carry more arbitrary data per response than A records, making them a favorite for the downstream (server-to-client) leg of a tunnel. Legitimate TXT queries are typically under 5% of total DNS traffic for a given client; tunneling tools routinely push a single client’s TXT ratio well past 10%.
  • NXDOMAIN rate. Tunneling tools frequently generate large volumes of queries to procedurally-constructed subdomains, many of which resolve to nothing meaningful from a legitimate-service perspective. An abnormally high NXDOMAIN rate from a single host, especially against a single second-level domain, is a reliable secondary signal — the same pattern also shows up with DGA-based malware, so it’s worth correlating with the entropy and length signals rather than alerting on NXDOMAIN rate alone.

None of these require machine learning to start — a scheduled query against your DNS logs computing these four metrics per client, per day, catches most real-world tunneling activity with basic statistical thresholds.

The DoH/DoT Complication

Everything above assumes you can actually see DNS query content — increasingly not a safe assumption. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt DNS queries in transit, which is a genuine privacy win for users but a real problem for network-level tunneling detection, because encrypted DNS traffic to a public DoH resolver (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, or countless others) looks identical to any other HTTPS connection to the naked eye of a network monitor.

An attacker running a tunnel over their own DoH endpoint, or abusing a legitimate public DoH resolver that happens to also serve their attacker-controlled zone, bypasses every one of the query-content detection techniques above entirely — there’s no plaintext subdomain to measure entropy on if the network sees only encrypted HTTPS.

This doesn’t make detection impossible, but it shifts the vantage point:

  • Block or tightly control DoH/DoT egress at the network level, forcing all DNS resolution through your organization’s monitored resolvers. Many enterprise firewalls now maintain curated lists of known public DoH endpoints specifically for this purpose.
  • Move detection to the endpoint, where the DNS query is still visible in plaintext before it gets wrapped in TLS — EDR agents that can inspect process-level DNS API calls retain visibility that network monitoring alone loses.
  • Monitor for unexpected DoH/DoT client software appearing on hosts that shouldn’t be making direct encrypted DNS queries to external resolvers, bypassing your configured internal resolver entirely — the mismatch itself is a strong signal regardless of what’s inside the encrypted payload.

MITRE ATT&CK Mapping

TacticTechniqueID
Command and ControlApplication Layer Protocol: DNST1071.004
ExfiltrationExfiltration Over Alternative ProtocolT1048

What You Can Do Today

  1. Enable and centralize DNS query logging if you haven’t already — this is the single prerequisite for every detection technique above, and many organizations simply don’t retain DNS logs at all.
  2. Force internal hosts to use only your organization’s resolvers, and block direct outbound DNS (port 53/853) to anything else. This doesn’t stop tunneling through your own resolver, but it eliminates the trivial bypass of a compromised host querying an attacker’s DNS server directly.
  3. Build the four statistical checks (entropy, label length, TXT ratio, NXDOMAIN rate) into your SIEM or a scheduled script against DNS logs — this is genuinely achievable without a dedicated DNS security product for most environments.
  4. Watch for a single client repeatedly querying subdomains of one second-level domain at high volume — legitimate services rarely generate this pattern, while every tunneling tool structurally requires it.
  5. Consider DNS response policy zones (RPZ) or a DNS security service to block known tunneling-associated infrastructure at the resolver level, catching known-bad domains before the statistical anomaly detection would even trigger.
  6. Don’t treat “it’s encrypted” as “it’s safe.” dnscat2’s encryption protects the payload content from casual inspection, but doesn’t hide the traffic pattern — encrypted tunneling traffic is exactly as statistically anomalous as unencrypted tunneling traffic to the detection methods above.
  7. Threat-hunt retroactively, not just in real time. DNS logs are cheap to store relative to full packet captures — a retrospective entropy/length sweep across 30–90 days of historical logs after any other compromise indicator often surfaces a tunnel that’s been running quietly for weeks.

Sources