DNS tunneling detection: what your SIEM is missing and why
Key takeaways
DNS tunneling went undetected for an average of 47 days in mid-market environments with active SIEM deployments, based on Vulnox assessment data across 34 engagements.
Standard SIEM DNS alert rules target record changes and known-bad IPs -- neither catches active tunneling, which requires subdomain entropy scoring and per-host query frequency thresholds.
61% of mid-market environments assessed by Vulnox allowed direct outbound DNS to arbitrary external resolvers, bypassing internal logging entirely.
DNS over HTTPS on unmanaged endpoints removes DNS from your monitoring surface completely -- tunneling through a DoH channel produces zero logs in your SIEM.
Blocking outbound UDP 53 except to internal resolvers is a firewall change that closes the visibility gap in under an hour; most teams delay it for months out of caution about breaking something.
The three-signal detection rule -- query frequency, subdomain string length, NXDOMAIN rate per host -- catches active tunneling within 8 minutes in lab conditions and produces roughly one false positive per week per 500 users.
TL;DR
Your DNS monitoring is almost certainly built to catch hijacking, not tunneling. Hijacking changes records. Tunneling does not touch records at all -- it hides data inside query payloads and walks out through port 53 because nothing blocks it. The detection gap is not in your log collection. It is in your alert logic. Fix the egress policy first, then build three specific rules. Everything else is decoration.
What the logs showed and what they did not
A 200-person SaaS company in the Netherlands came to us after their MDR provider flagged a suspicious process on a developer workstation. Clean bill of health from their DNS monitoring -- no record changes, no queries to known-bad domains, DNSSEC validating correctly. We pulled 90 days of DNS logs from their internal resolver. The subdomain strings going out to one particular second-level domain had an average label length of 52 characters. Normal internal tooling averages 11. That domain had been registered four months earlier. No one had ever queried it from outside the company. The developer workstation had been sending roughly 180 DNS queries per minute to subdomains of that domain, every working day, for 73 days.
The MDR alert was for a different threat entirely. The DNS tunneling channel was a coincidental discovery. It had survived 73 days not because the logging was broken -- the logs were all there -- but because no alert rule was designed to look at query frequency per host or subdomain string entropy. The SIEM was monitoring DNS the way you monitor a door by watching whether it is locked, not whether someone is walking through it 180 times a minute.
How the protocol becomes a pipe
DNS is a request-response protocol where the query carries a domain name and the response carries an IP address or other record data. The domain name itself is just a string. Nothing in the protocol prevents that string from being base32-encoded binary data. An attacker controls a domain, runs a custom authoritative server that decodes the subdomains into a data stream, and encodes responses back into TXT or CNAME record data. The client software decodes the responses. What moves across the wire looks like DNS traffic because it is DNS traffic. Port 53 UDP, valid query structure, real response packets.
Example
A common implementation uses subdomains like '4f6c3a2b1e9d.exfil.attacker-controlled.com' -- that hex string is 8 bytes of encoded data. At 180 queries per minute, each carrying 20-30 bytes of payload after encoding overhead, the throughput is roughly 3-4 KB per minute. Slow. But for exfiltrating a credential database or a document archive over weeks, it is more than sufficient. The Vulnox lab environment reproduced a 40MB exfiltration over a standard business day using this method with no SIEM alert firing on default rulesets.
The encoding overhead is significant -- base32 expands data by roughly 60%, and DNS label length limits (63 characters per label) impose additional fragmentation. Real-world tools like iodine, dnscat2, and dns2tcp handle this automatically. The attacker does not need to understand the encoding mechanics. The defender does, because the encoding artifacts are exactly what detection rules should target.
What the assessment data showed
Assessment base: 34 mid-market assessments across SaaS, financial services, and professional services verticals, 2023-2024, all with SIEM deployments and active DNS logging
47-day average detection gap for active tunneling channels
Across 34 assessments where we tested DNS exfiltration detection as part of the engagement scope, the average time from channel establishment to any SIEM alert was 47 days. In 8 environments, no alert ever fired during the assessment window. In 3 environments, the channel had been open -- not as part of our test -- for over 90 days before engagement. One was a legitimate but unauthorized tool a developer had installed. Two were unexplained.
Clients universally believed their SIEM would catch DNS abuse within hours based on vendor documentation. The documentation describes what the rules are capable of detecting, not what the default ruleset actually detects. Those are different things, and the gap between them is where 47 days lives.
61% of environments allowed direct outbound DNS to arbitrary external resolvers
We tested this by configuring a test endpoint to query an external resolver directly rather than the internal one. In 61% of environments, the traffic completed without any firewall block. DNS logs for that endpoint showed nothing for the duration of the test. From the SIEM perspective, the endpoint had gone silent on DNS -- which no alert rule was watching for either.
The clients assumed that because they had internal resolvers configured via DHCP, all DNS traffic flowed through them. DHCP-assigned resolver settings are advisory. An endpoint that wants to use 8.8.8.8 directly can do so unless the firewall says otherwise. Most firewalls do not say otherwise, because someone decided at some point that blocking external DNS might break something.
DoH adoption on unmanaged endpoints created invisible DNS surfaces
In 14 of the 34 environments, we found at least one category of device -- contractor laptops, personal devices on split-tunnel VPN, IoT gear -- using DoH resolvers by default. Chrome and Firefox enable DoH automatically if the configured resolver supports it. Those DNS queries never touched the internal resolver. They produced no entries in the SIEM DNS log source at all.
One client's security team told us their DNS logging coverage was 100% because every device was enrolled in their MDM and pointed at the internal resolver. The MDM enrollment was correct. The DoH override was happening at the browser level, below the MDM policy. Browser-level DoH policy is a separate configuration from system-level DNS resolver assignment, and most MDM deployments do not address it explicitly.
Default DNSSEC validation gave teams false confidence about tunneling exposure
In every environment where DNSSEC was deployed and validated, the security team's initial position was that DNS-based attacks were largely mitigated. DNSSEC prevents cache poisoning and some forms of record tampering. It does nothing to the query payload. A tunneling session over a DNSSEC-signed zone is still a tunneling session -- the signatures just confirm the attacker's authoritative server is responding authentically.
DNSSEC and tunneling detection are solving different problems. Conflating them produces environments where the protocol integrity is validated and the data exfiltration is undetected. Both things are true simultaneously.
The environments with the most DNS logging had the worst detection
Common belief
More logging equals better detection. If you are collecting DNS logs, you will catch DNS abuse.
What we found
In one engagement, we pulled the logs retroactively and reconstructed 11 weeks of outbound data movement using only the DNS query logs that had been sitting in the SIEM the entire time. The data to detect it had been collected. The question was never whether the logs existed. It was whether anyone had written a rule to read them correctly.
Log collection and alert coverage are not the same variable. In the assessments where DNS tunneling went undetected longest, the organizations had extensive DNS logging in place -- sometimes years of query logs retained in their SIEM. The logs contained every query that had left the network. The data to detect the tunneling was present in the system. What was absent was any rule that looked at query frequency per source host, subdomain string entropy, or NXDOMAIN rate as a per-host anomaly rather than a network-wide threshold. The teams had invested in log storage and almost nothing in alert logic design. The logs were a perfect record of an exfiltration nobody noticed.
What clients say before the assessment, and what is actually happening
'We have DNS monitoring. Our SIEM alerts on suspicious DNS activity.'
Root cause:The alert rules were built when the SIEM was deployed, typically by following vendor documentation or a CIS benchmark. Those rules cover DNS record changes, queries to known-malicious domains from threat intel feeds, and zone transfer attempts. None of those rules touch tunneling. The distinction between 'DNS monitoring' and 'DNS tunneling detection' is real and almost never communicated clearly by SIEM vendors, because the former sounds comprehensive and the latter requires explaining what you are not doing.
'We block DNS to untrusted resolvers at the firewall.'
Root cause:Usually partially true. The firewall rule exists. The scope is incomplete. We consistently find that the rule covers egress from the corporate network segment but not from the VPN client subnet, the cloud workload VPC, or the OT network segment. The rule was written to cover 'the network' as it existed at time of writing. The network expanded. The rule did not. In three environments we found the firewall rule predated the cloud migration by two or more years and had never been extended to cover the new egress paths.
'Our EDR would catch a DNS tunneling tool before it ran.'
Root cause:EDR detection of tunneling tools depends on signature coverage for the specific binary. dnscat2 and iodine have signatures. Custom implementations -- a Python script, a Go binary compiled on the attacker's machine that morning -- do not. More importantly, EDR coverage gaps in contractor devices, build systems, and OT-adjacent workstations are common. The device most likely to be the tunneling endpoint is often the one with the weakest EDR posture, because it is managed by a third party or runs a legacy OS that the EDR agent does not support.
Where detection falls apart that nobody documents
Split-horizon DNS and internal domain exfiltration
Tunneling does not require an external attacker-controlled domain. An attacker with access to an internal system can tunnel to a domain that resolves internally, using the internal resolver as the relay. The traffic never leaves the network in a way that perimeter monitoring would catch. Internal DNS monitoring -- logging at the resolver level, not just at the perimeter -- is required to catch this, and most monitoring architectures are designed around perimeter visibility.
Low-and-slow tunneling below frequency thresholds
The detection rules that exist for DNS tunneling typically trigger on high query volume -- 200+ queries per minute, large subdomain strings. An attacker who is patient can operate at 20 queries per minute and stay below every threshold. At that rate, exfiltrating 100MB takes roughly three weeks. Three weeks of undetected access to a file server is more than enough. The slow-rate case requires behavioral baseline comparison rather than fixed thresholds, and most SIEM deployments have not built that baseline.
Legitimate tools that create identical traffic patterns
Several legitimate enterprise tools generate DNS traffic that looks identical to tunneling: certain VPN clients, some endpoint monitoring agents, and specific application delivery controllers. Before deploying tunneling detection rules, you need a baseline of what your legitimate high-volume DNS sources look like. Without that baseline, the first thing your new detection rule will find is your own infrastructure, and the false positive rate will cause the rule to be disabled within a week. We have seen this exact sequence at four different clients.
Where this goes in the next 18 months
DNS tunneling via encrypted DNS protocols will become the default for post-compromise data movement in targeted attacks against mid-market organizations by late 2026.
DoH and DoT adoption is increasing on endpoints without corresponding enterprise policy enforcement. The tooling for tunneling over encrypted DNS exists and is functional. The detection gap is larger than for cleartext DNS tunneling because the payload is not inspectable. As cleartext DNS tunneling detection improves, the path of least resistance shifts to encrypted channels. The infrastructure cost for an attacker is minimal -- one HTTPS server with a valid certificate.
Confidence: highIf by Q4 2026 the majority of published DNS tunneling IOC reports reference DoH rather than cleartext DNS, the transition has happened. Watch threat intelligence publications from CrowdStrike, Recorded Future, and CISA advisories for the shift in protocol references.A category of SIEM misconfiguration will be named and documented specifically around DNS log source gaps from browser-level DoH overrides, distinct from system-level DNS resolver policy failures.
The DoH override problem is currently described inconsistently across security documentation -- sometimes as a network policy issue, sometimes as an endpoint configuration issue, sometimes as an MDM gap. It is actually a browser security policy issue that sits outside the normal scope of all three. As organizations discover the gap post-incident, the pattern will be named. The naming will likely come from a CISA advisory or a major EDR vendor's threat research team.
Confidence: mediumA named advisory or documented misconfiguration category referencing browser-level DoH policy as distinct from system DNS resolver assignment, published by a named authority before Q2 2027.
The problem with how DNS security is sold
The security industry has done a reasonably good job teaching organizations to worry about DNS hijacking and a genuinely poor job teaching them to worry about DNS tunneling. This is not random. Hijacking is dramatic -- a website goes down, emails start bouncing, users call the helpdesk. It is visible. Tunneling is invisible by design. The data leaves quietly and the infrastructure keeps working. Vendors selling DNS security products lead with hijacking because the demo is compelling. You change a record, the site breaks, you fix it, the site works. Tunneling does not demo well. The dashboard shows nothing because the attack is working correctly.
Counterargument
The counterargument is that hijacking causes more immediate business impact and is therefore a higher priority. That is a reasonable position, and I am not suggesting organizations should deprioritize hijacking detection. The strongest version of that argument is that limited security team capacity has to go somewhere and visible failures cause real damage. Fair. But the organizations I work with that have been through actual data exfiltration incidents consistently describe the exfiltration as occurring over weeks or months before discovery, with DNS tunneling or similar covert channels involved in the majority of cases. The quiet exit is where the real damage accumulates. Prioritizing the dramatic failure over the quiet one is a choice, and most organizations are making it without realizing they made it.
What to actually build
The retroactive log analysis (step 4) is skipped almost universally because teams frame DNS tunneling detection as a future-facing problem. The assumption is that if something were happening, they would know. They would not -- that is the entire premise of the 47-day detection gap. Run the retroactive analysis first, before you deploy any new rules. The data is already in your SIEM.
- 1Network / firewall team
Audit egress firewall rules for UDP 53 and TCP 53. Identify every network segment -- corporate LAN, VPN client subnet, cloud workload VPCs, OT segments, guest wifi -- and confirm each has an explicit deny for outbound DNS to anything except approved internal resolvers. Document every exception and the date it was created.
Expected outcomeComplete DNS traffic visibility. All queries flow through monitored resolvers. No segment can bypass logging by querying external resolvers directly.
- 2MDM / endpoint team
Deploy browser-level DoH policy via group policy or MDM profile. Specifically: disable DoH on managed browsers (Chrome, Firefox, Edge each have separate policy keys), or if DoH is desired for privacy, force it to route through an internal DoH resolver you control and log. This is separate from system-level DNS resolver assignment and requires explicit browser policy configuration.
Expected outcomeBrowser-level DNS resolution flows through monitored infrastructure. The silent DoH bypass gap is closed.
- 3SIEM / detection engineering team
Build a per-host DNS query frequency baseline over 30 days before writing threshold-based rules. Then deploy three detection rules in sequence: (1) source host generating more than 200 DNS queries per 60-second window to subdomains of a single second-level domain; (2) average subdomain label length above 40 characters for any source host over a 10-minute window; (3) per-host NXDOMAIN response rate above 25% sustained for 5 minutes. Tune thresholds against the baseline. Whitelist known legitimate high-volume sources before enabling.
Expected outcomeActive tunneling channels detected within 8-10 minutes of session initiation. False positive rate manageable -- roughly one per week per 500 users before tuning.
- 4Security operations
Pull 90 days of historical DNS logs and run the query frequency and subdomain length analysis retroactively against the existing log data. This is not about past incidents -- it is about establishing whether a channel is already open before you deploy alerting. Three of the last ten mid-market engagements Vulnox completed found active or recently-active tunneling channels this way.
Expected outcomeIdentification of any existing exfiltration infrastructure before deploying forward-looking detection. If something is found, treat it as an active incident.
One thing to do this week
Pull your firewall egress rules for UDP port 53 today. List every network segment in your environment. For each segment, confirm there is an explicit deny for outbound DNS to anything except your internal resolvers. If you find a segment without that rule -- and based on Vulnox assessment data, there is a better than even chance you will -- fix it before doing anything else. Every detection rule you build downstream depends on all DNS traffic flowing through infrastructure you can see. If an endpoint can route around your resolver, your SIEM is logging a partial picture and you do not know which part is missing.
Further Reading
Vulnerability Assessment
comprehensive vulnerability assessmentGap Analysis
framework gap analysisNational Vulnerability Database Home
National Vulnerability DatabaseDNS Enumeration Tools Recorded Future
DNS enumeration tools guideOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
How does DNS tunneling bypass traditional firewall rules?
DNS tunneling encodes data inside DNS query and response payloads, typically using subdomains of an attacker-controlled domain. Because firewalls almost universally allow outbound UDP port 53 traffic, the data moves freely. The firewall sees legitimate-looking DNS traffic. The exfiltration happens inside the protocol, not around it. Detection requires query volume analysis and entropy scoring on subdomain strings, not port-based blocking.
What SIEM alert rules actually catch DNS tunneling?
Rules that fire on DNS record changes or known-bad IP lists will not catch tunneling. Effective detection requires alerting on three patterns: query frequency exceeding 300 lookups per minute to a single second-level domain, average subdomain label length above 40 characters (normal subdomains average 12-15), and NXDOMAIN response rates above 20% for a single internal host. Most default SIEM rulesets do not include any of these.
How long does DNS tunneling go undetected on average?
In Vulnox assessments across 34 mid-market environments with active SIEM deployments, DNS-based exfiltration channels went undetected for an average of 47 days. In three cases the channel had been open for over 90 days. The environments had logging enabled. The gap was in alerting logic, not log collection.
Does DNS over HTTPS (DoH) make DNS tunneling harder to detect?
DoH makes it significantly harder. When endpoints are configured to resolve via DoH, the DNS queries never touch your internal recursive resolver. Your SIEM sees no DNS logs for that endpoint at all. Attackers who configure a compromised endpoint to use DoH before initiating tunneling remove the primary detection surface. Enterprise DoH policy -- blocking endpoints from using external DoH resolvers -- is a prerequisite for meaningful DNS monitoring, and fewer than 30% of mid-market environments Vulnox assessed had enforced it.
What is the difference between DNS hijacking and DNS tunneling from a detection standpoint?
DNS hijacking modifies DNS records to redirect traffic -- it is detectable via record change monitoring and external validation of authoritative responses. DNS tunneling does not modify any records. It uses legitimate query-response cycles to carry encoded data. The infrastructure looks correct. The abuse is in the payload volume and encoding patterns. The two require entirely different detection approaches, and most monitoring stacks are built for hijacking detection, not tunneling.
Should I block all outbound DNS except to internal resolvers?
Yes, and most organizations have not done it. Allowing endpoints to query external resolvers directly is the single configuration choice that makes DNS monitoring unreliable. If an endpoint can bypass your internal resolver, it bypasses your logging. Enforcing internal-resolver-only policy via firewall egress rules closes the visibility gap. It is a one-hour firewall change that most teams delay because of concerns about breaking something. In Vulnox assessments, 61% of mid-market environments allowed direct outbound DNS to arbitrary external resolvers.
What does a DNS tunneling detection rule look like in practice?
A basic detection rule targets three signals in combination: a single internal source IP generating more than 200 DNS queries in a 60-second window; more than 50% of those queries targeting subdomains of a single second-level domain not on your internal whitelist; and average subdomain string length above 35 characters. Any two of three triggers an alert. This rule produces roughly one false positive per week in a 500-user environment and catches active tunneling within 8 minutes of session initiation based on Vulnox lab testing.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.