DNS tunnelling abuses the trust your network places in port 53 to smuggle data out and run command-and-control traffic in. Most security stacks watch HTTP and scan files, but let DNS queries pass without inspecting what is actually inside them. That gap is where attackers operate.
This post is for the technical IT manager or security engineer who already knows what DNS filtering does and wants the layer underneath: how the tunnel works, how attackers stay below detection thresholds, and what kind of inspection actually catches it. The angle here is the attack technique itself, not domain reputation lists.
What is DNS tunnelling and why does it bypass filtering?
DNS tunnelling encodes data inside the fields of standard DNS queries and responses, turning a name-resolution protocol into a two-way data channel. Because the queries look syntactically valid and travel over port 53, perimeter controls that only check domain reputation wave them through. The payload, the entropy, and the record types are never examined.
The Domain Name System was built to translate names into IP addresses, not to validate the content of what it carries. It has no structural security checks. An attacker who controls an authoritative name server for a domain can receive any data a victim machine encodes into a lookup for that domain, and reply with instructions in the answer. To the network, it is just DNS doing its job.
That is the core problem. Filtering asks “is this domain known to be bad?” Tunnelling defeats that question by using domains that are not on any list yet, or by hiding the whole exchange inside encrypted web traffic. For the design rationale behind why DNS sits where it does in a Zero Trust stack, our piece on DNS as a Zero Trust blind spot covers the architecture. Here the focus is the exfiltration mechanics.
How does encoding and split-payload exfiltration work?
Attackers convert files into alphanumeric strings, split them into small fragments, and send each fragment as a subdomain in a separate lookup. The receiving name server logs every query, decodes the fragments, and reconstructs the original file. No single packet looks alarming.
The fragmentation is forced by the protocol. A DNS label is capped at 63 characters and a full name at 255, so a large file cannot travel in one query. It has to be chopped into hundreds or thousands of pieces. Each piece rides out as something like MFRGGZDF.exfil.attacker-domain.com, and the volume of lookups is the only obvious signal, which is exactly the signal patient attackers learn to suppress.
Encoding choice matters more than it looks. DNS is case-insensitive, which corrupts Base64 because Base64 relies on distinct upper and lower case. Base32 uses only uppercase letters and digits, so the encoded data survives the round trip intact. When you see long Base32-looking labels stacked under one parent domain, that pattern is worth a closer look.
Which DNS records do attackers abuse, and how does C2 reply?
Attackers favour record types that carry the most arbitrary data: TXT, NULL, and CNAME. The victim encodes outbound data into query names, and the command-and-control server encodes instructions back into the answer records. TXT and NULL records hold larger free-form payloads, which makes them efficient carriers for both exfiltration and inbound commands.
This is what turns tunnelling from one-way leakage into a full control channel. A C2 server can answer a routine-looking lookup with a TXT record that contains a command, a configuration update, or the next staging address. The victim polls, decodes the answer, acts, and encodes the result into its next query. The whole conversation happens inside traffic almost every firewall permits by default.
CNAME records add another wrinkle. Because they legitimately point one name at another, chains of CNAME responses can move data while looking like ordinary alias resolution. The further attackers drift from obviously suspicious record types, the more they blend into normal traffic.
Iodine versus dnscat2: how do the main tools differ?
The two best-known open-source tunnelling tools solve different problems. Iodine builds a full network tunnel to route IPv4 traffic over DNS, while dnscat2 is built for command execution and interactive sessions. Both reliably slip past basic perimeter controls that only inspect domains rather than payloads.
| Capability | Iodine | dnscat2 |
|---|---|---|
| Primary purpose | Full IPv4 tunnel over DNS | Command and control, interactive shell |
| Record types used | NULL and other non-standard types for bandwidth | TXT and CNAME for encrypted sessions |
| Output | Routable network interface | Encrypted interactive session |
| Typical use | Bypassing captive portals, moving bulk traffic | Remote control, staged payloads |
| Detection by domain reputation alone | Misses it | Misses it |
Iodine optimises for throughput. It uses record types like NULL to push more data per query and gives the attacker something close to a real network connection. dnscat2 trades raw bandwidth for stealth and control, wrapping its sessions in encryption and using TXT and CNAME records to keep a quiet, persistent channel open.
For a defender, the practical takeaway is that signature-based blocking of one tool does not protect you. The behaviours these tools produce, high query volumes, unusual record types, high-entropy labels, are the durable detection surface. The specific tool is interchangeable.
Why do standard SASE stacks leave a blind spot?
Most Secure Access Service Edge deployments lean on static domain reputation, which cannot see two things: infrastructure too new to be classified, and DNS hidden inside encrypted web sessions. Both are routine in modern campaigns, so reputation-only filtering misses the attacks that matter most.
DNS over HTTPS is the sharper edge of this. DoH wraps DNS queries inside ordinary HTTPS on port 443, so to a classic DNS filter the lookups simply vanish. The traffic looks like someone browsing a website. Unless the platform performs full TLS decryption at the Secure Web Gateway layer, the malicious queries are invisible. Vendors tend to frame DoH as a privacy win, which is true for users and equally true for attackers.
The other half is timing. Reputation lists are reactive by nature: a domain has to be observed and categorised before it can be blocked. Attackers exploit that lag directly. According to EfficientIP’s DNS threat intelligence published in March 2026, newly registered domains accounted for 11% of dangerous DNS requests and newly observed domains for a further 8%, precisely the categories a reputation list has not caught up with yet.
How do real-time payload and entropy analysis catch tunnelling?
Deep inspection looks at the query itself rather than just the domain’s reputation. It calculates Shannon entropy to flag the random-looking encoded strings that tunnelling produces, and it tracks abnormal record-type mixes and label lengths. These statistical signals separate automated machine behaviour from normal human browsing.
Entropy is the workhorse here. Human-readable domains have predictable letter distributions. A subdomain carrying Base32-encoded stolen data looks statistically random, so its entropy score is high. A resolver doing real-time analysis can score every label and surface the ones that behave like encoded payloads rather than like words.
Volume and structure add corroboration. A single host firing thousands of unique subdomain lookups at one parent domain, or leaning heavily on TXT and NULL records, is behaving like a tunnel, not a browser. None of these signals is conclusive alone, which is why they are weighed together rather than used as single triggers.
A real caution applies. Legitimate cloud services, CDNs, and software-update agents generate dynamic, random-looking subdomains too, and entropy analysis will flag them if used alone. That is the false-positive trap. Detection has to be a weighted score that also accounts for domain age, registrar reputation, and the client’s own history, not a single entropy threshold pulling the trigger.
How do you detect low-throughput and dormant-domain campaigns?
The hardest campaigns to catch are the slow ones. Instead of flooding the resolver, low-throughput malware sends single queries at long intervals, sometimes once an hour, so the traffic blends into normal network noise and never trips a rate limit. Detection requires behavioural tracking over long timeframes, not snapshot thresholds.
The staging side compounds this. Attackers pre-register large pools of domains and keep them dormant, activating only a few at a time so reputation systems never see enough activity to classify them. EfficientIP’s March 2026 intelligence described one campaign, BaitHook, that generated roughly 580,000 unique C2 domains in 2025, and reported that 23% of malicious DNS traffic was already labelled as suspect-domain staging. That is a pre-positioned inventory, built to outlast any blocklist.
So the defensive posture has to shift from “block known-bad now” to “watch behaviour across weeks.” A domain that has been queried twice in a month by one quiet host is far more interesting than its query count suggests. Persistent baselining of each client, rather than per-query alarms, is what surfaces the patient exfiltration that volumetric rules are designed to miss.
How do you secure the IT-OT bridge without software agents?
Industrial devices on a production floor cannot run security agents, yet they still use DNS and still get probed by malware looking to map the network. Protecting them means inspecting their DNS at the network boundary with hardware, because you cannot install anything on the device itself. This is the secure integration problem at the IT-OT bridge.
Most SASE designs quietly assume every client runs a heavy endpoint or SASE agent that ties DNS queries back to a process. Legacy operational technology and IoT systems break that assumption completely. They have no agent, no posture client, and often no patch path. In European industrial mid-market environments, that is the norm, not the exception.
The workable answer is an agentless physical bridge that sits inline and inspects outbound DNS for everything behind it. Jimber handles this with its NIAC hardware, an agentless IT-OT bridge that monitors DNS requests at the network boundary so legacy operational systems stay covered without any change to their configuration. The devices keep running as they are. The inspection happens around them.
How do NIS2 and CyberFundamentals change the stakes?
European frameworks turn DNS inspection from good practice into a documented obligation. The NIS2 directive and Belgium’s CyberFundamentals (CyFun) framework expect organisations to control and log the channels through which data can leave, and they attach board-level liability to failures. DNS is one of those channels.
NIS2 went live in Belgium in October 2024, and essential entities were required to reach Basic or Important CyberFundamentals verification by 18 April 2026, a deadline that has now passed. DNS filtering is not named in Article 21 by itself, but a documented DNS policy with logging, identity context, and threat intelligence is one of the clearest pieces of evidence of network-level threat detection an auditor can see. Controlling exfiltration channels sits directly inside those technical and organisational measures.
The regulatory pressure is not abstract. According to the Centre for Cybersecurity Belgium’s annual report published in early 2026, reported incidents rose 70% to 635 in 2025, a jump the CCB links to NIS2 reporting obligations taking hold. At the European level, ENISA’s sectorial threat landscape from November 2025 found public administration was the target in 38.2% of successful incidents, which keeps regulators focused on exactly the mid-market and public-sector organisations that struggle most with DNS visibility.
Forrester’s findings make the visibility gap concrete. In a Forrester Consulting study published in July 2025, 95% of organisations reported a DNS-related incident in the prior year, and 67% admitted they lacked sufficient visibility into their own DNS traffic and deep DNS analytics. You cannot evidence control over a channel you cannot see.
What does effective DNS inspection look like in a SASE platform?
Stopping tunnelling needs three capabilities working together: full DoH decryption at the Secure Web Gateway, real-time payload and entropy analysis, and enforcement that DNS resolves only through controlled internal resolvers. Platforms like Jimber integrate DNS inspection directly into the cloud-native SWG so encrypted covert channels can be opened and analysed rather than waved through.
To catch DoH tunnels, the platform has to decrypt and inspect HTTPS at the gateway, because that is the only place the hidden queries become visible. Jimber performs this inside the SWG layer rather than chaining legacy proxies, which keeps the inspection latency low. The same engine that handles TLS termination for web traffic is the one that exposes DNS smuggled inside it. Our deep dive on encrypted traffic inspection for TLS 1.3 and QUIC covers the protocol-level trade-offs that make this harder in 2026.
Forcing clients onto internal recursive resolvers closes the bypass route, but it can break legitimate tools used by guests or external staff. The pragmatic fix is a transparent redirect: externally aimed DNS queries are silently steered to the secured inspection layer instead of being dropped, so resolution still works while everything stays inspected. For the agentless devices that cannot be steered by software, the NIAC bridge enforces the same control at the network boundary.
One honest caveat. Decrypting HTTPS to inspect DoH and scoring entropy on every query costs compute, and at scale that can add latency. With efficient algorithms and a cloud-native architecture, that inspection can run with sub-millisecond impact per request, but it is a real engineering constraint, not a free lunch. The trade-off is worth naming when you evaluate any platform, including this one. Jimber’s broader approach to this sits inside the secure web gateway and SASE model.
If your current stack stops at domain reputation, it is blind to the exfiltration techniques that actually matter in 2026. Book a Jimber demo and we will walk through how DoH decryption, entropy analysis, and agentless boundary inspection close the DNS channel for your environment, including the OT side most platforms leave exposed.
FAQ
What is the difference between DNS filtering and DNS inspection?
DNS filtering blocks domains using static reputation lists of known-bad sites. DNS inspection analyses the content of the query itself in real time, detecting anomalies like high-entropy subdomains and unusual record types inside otherwise legitimate-looking connections.
Can DNSSEC stop data exfiltration over DNS?
No. DNSSEC validates the authenticity and integrity of DNS responses. It does not inspect query payloads or stop malware from encoding stolen data into outbound lookups to attacker-controlled domains, so it offers no protection against tunnelling.
How does DNS over HTTPS bypass traditional security systems?
DoH encrypts queries using standard TLS, so the traffic looks like normal web browsing on port 443. Standard DNS filters cannot inspect the lookups at all unless the platform performs full decryption at the Secure Web Gateway layer.
Why is Base32 preferred over Base64 for DNS exfiltration?
DNS is case-insensitive, which corrupts Base64 because it depends on distinct upper and lower case. Base32 uses only uppercase letters and digits, so the encoded data stays intact and the attacker can reconstruct it reliably on the receiving server.
How does low-throughput exfiltration evade detection?
Instead of sending many queries quickly, low-throughput malware sends single queries at long intervals, sometimes once an hour. This matches normal background network noise and slips under typical rate-limiting and volumetric alerting rules.
How do you detect tunnelling when attackers use dormant staged domains?
Reputation lists miss freshly activated domains by design. Detection relies on behavioural baselining per client over weeks, combined with payload and entropy scoring, so a quiet host querying a brand-new domain stands out even without prior threat intelligence on that domain.
