DNS Tunneling: Why a DNS Filter Cannot Stop the Leak It Is Carrying

Quick answer. DNS tunneling hides data inside DNS queries and answers, which means the exfiltrated data is the lookup itself. A DNS-layer filter is being asked to carry the leak it is supposed to prevent, so the fix is not a smarter resolver but inspection at the point where the traffic is created. dope.security runs the proxy on the device, so it sees the process, the destination and the payload before anything leaves.

What DNS tunneling is, in one paragraph

DNS tunneling encodes data into the parts of the DNS protocol that are allowed to be arbitrary. Whoever runs the tunnel controls an authoritative name server for a domain they own. Data leaves as subdomain labels in a query, for example an encoded chunk of a customer list stitched onto the front of a hostname. Data comes back inside the answer, usually in a TXT or CNAME record. Nothing is malformed and nothing is exotic. Every packet is a legal DNS request that your resolver is built to forward, which is exactly why the technique has outlived almost every other covert channel.

That legality is the whole problem. If you are drawing up a shortlist of web controls, work through the URL filtering tools most buyers shortlist and ask each one a single question: where does inspection happen? The answer decides whether a tunnel is visible to that product at all, and it decides it before you ever look at a feature list.

The reason this matters more in 2026 than it did in 2016 is that DNS is no longer the only quiet channel. It is just the oldest one, and it remains the cleanest proof of a structural point about where security controls belong.

Why the DNS layer is structurally the wrong place to catch it

A DNS filter makes one decision: resolve this name, or do not. It reads a hostname, matches it against a category or a reputation list, and answers. That is a routing decision, and it is a good one. It is not a data decision, and it cannot be made into one, because the thing you would need to evaluate is the name itself. The filter is not looking at a request that contains data. The filter is the transport.

Vendors respond with statistical detection: flag domains with abnormally long labels, high query entropy, unusual TXT volume, or a subdomain count that no legitimate service would generate. That works, sometimes, and it is worth turning on. But it is inference from shape rather than inspection of content, so it lands you in the two places every heuristic control lands. Set the threshold tight and you break a real service that happens to encode data in DNS, and several do. Set it loose and a slow tunnel moving a few kilobytes an hour walks straight through, because a patient exfiltration looks exactly like a chatty client.

This is the same ceiling we mapped in is DNS filtering enough in 2026 and in the head-to-head on the difference between URL filtering and DNS filtering. The DNS tier sees names. Names are not payloads.

Cisco Umbrella and the DNS-layer ceiling

Cisco Umbrella is the honest test case here, because it is the most widely deployed DNS-first control in the mid-market and because Cisco documents the boundary itself. The base tier inherits the OpenDNS resolver model, so enforcement happens at resolution. Cisco's own documentation is clear that reading URLs, payloads or tenant identity requires the intelligent proxy with SSL decryption and a root certificate installed, which is the Secure Internet Gateway add-on rather than the DNS tier (documented in Cisco article 225162). With roughly 95 percent of web traffic encrypted, that is not a niche gap.

Two more documented details are worth knowing before you lean on the DNS tier as a data control. Cisco published Field Notice FN74221 after a DNS failover misconfiguration caused a global service disruption on January 19, 2025, which is a reminder that a resolver you do not run is a dependency, not just a feature. And customers consistently report pricing as their leading complaint, which matters because the capability you actually need for payload visibility sits in a higher tier. We walked the encrypted-DNS version of the same gap in how DNS over HTTPS bypasses Cisco Umbrella.

None of that makes Umbrella a bad DNS product. It makes it a DNS product. The mistake is buying a routing control and expecting it to behave like a data control.

The uncomfortable part: tunneling is no longer the interesting exfil path

If someone wants to move a customer list out of your company today, DNS tunneling is a strange amount of work. There is a browser tab open to a personal AI assistant, a personal cloud drive on the same domain as the corporate one, and a Model Context Protocol client wired into a local IDE. All three are ordinary HTTPS to a reputable hostname, and all three carry more data per second than a tunnel ever will.

That is why we treat DNS tunneling as a diagnostic rather than a threat model. A control that cannot see a tunnel also cannot see the paste into a personal chatbot, for the same reason: it never reads the payload. Encryption is closing the remaining network-side clues too, which is the argument in what Encrypted Client Hello does to web filtering. Solve the general problem and the specific one comes with it. Solve only the specific one and you have bought a signature for a technique nobody needed to use.

DNS-layer filtering versus on-device inspection: what each can see

Here is the comparison in the terms that matter for a data-loss question. Each line pairs the DNS-tier behavior with the on-device behavior.

• The query itself: a DNS filter forwards or refuses the name and cannot evaluate what the name encodes; dope.security sees the local process that generated the request, so an unknown binary talking to an unknown authoritative server is visible as a process, not as a statistical anomaly.
• Payload: DNS-layer tools log domains, so an upload and a page view produce the same record; Dopamine DLP inspects data in motion on the device and classifies what is actually leaving before it leaves.
• Tenant identity: a resolver returns the same answer for a corporate and a personal account on one domain; Cloud Application Control enforces at the tenant level, which is how you allow corporate ChatGPT and block personal ChatGPT on the same hostname.
• Off-network coverage: DNS enforcement depends on the device using your resolver, and a laptop on hotel wifi can be pointed elsewhere; the dope.endpoint agent carries policy with the device, on any network.
• Cost of visibility: most cloud-proxy stacks reach payload inspection only by routing traffic to a point of presence and back, plus a data-protection add-on; dope.security inspects TLS on the device with no detour and no separate tower of SKUs.

The pattern is consistent. Anything the network can read is being encrypted away, and anything the network cannot read was never available to it in the first place. The device is the one place where the request exists in plain form, which is the argument we make in detail in what egress filtering misses on a laptop.

What to actually do about DNS exfiltration

There is a practical answer that does not depend on buying a tunnel detector. Start by deciding which resolvers your devices are permitted to use and enforce that on the device rather than at the network edge, because the network edge only exists while the laptop is behind it. Then get process attribution: you want to know that a request came from a browser a user drove, or from something else. Then put the real control where the data is, at egress, with content inspection on the device.

Keep the DNS heuristics on. Long-label and high-entropy detection is cheap and it catches the lazy tunnel. Just do not let it be the control you report to an auditor as data-loss prevention, because it is a shape detector, not a data detector. The wider playbook is in how to prevent data exfiltration in 2026, and the architectural case for moving inspection onto the endpoint is on the Fly Direct Secure Web Gateway page.

This is the move Greylock Partners made when DNS-only filtering stopped covering the HTTPS traffic its distributed team actually used, and they went from first proposal to signed contract in 27 days. The full story is in how Greylock Partners ditched Cisco Umbrella.

What to test in a proof of concept

Do not evaluate this on a feature matrix. Run four tests on a real laptop, off the corporate network, and watch what each product reports.

• Point the device at a public resolver you do not control and see whether policy still applies.
• Move a few kilobytes out slowly over DNS to a domain you own and see whether anything at all is logged beyond a domain name.
• Paste a block of synthetic customer records into a personal AI assistant and see whether the product names the data or just the site.
• Sign in to a personal account on a SaaS domain your company also uses, and see whether the product can tell the two apart.

A product that passes the last two will almost always pass the first two. The reverse is not true, which is the entire point.

Frequently Asked Questions

Can Cisco Umbrella detect DNS tunneling?

Umbrella applies reputation and anomaly detection at the resolver, so it can flag domains and query patterns that look like a tunnel. It cannot inspect the content of the encoded data, and per Cisco's own documentation, reading payloads or distinguishing SaaS tenants requires the intelligent proxy with SSL decryption rather than the DNS tier. Treat DNS-layer detection as a shape signal and put data inspection somewhere it can read the data, such as on the device with dope.security.

Is blocking TXT records a fix for DNS tunneling?

It removes the highest-bandwidth answer type, so it is worth doing where you can, but it is not a fix. Tunnels fall back to CNAME, NULL, MX or plain A-record encoding at lower throughput, and legitimate services use TXT records for domain verification, mail authentication and license checks. You will spend the savings on exceptions.

Does an endpoint agent replace DNS security entirely?

No, and you should be suspicious of anyone who says it does. DNS reputation is a cheap, fast first filter and it belongs in your stack. The change is what you ask it to be responsible for. dope.security runs URL filtering, on-device SSL inspection, Cloud Application Control and Dopamine DLP from a single agent and a single console, so the resolver stops being the last line of defense and goes back to being the first.

How does on-device inspection affect PCI DSS and GDPR obligations?

Inspecting on the device means user traffic is not routed through a third party's data center to be decrypted, so payload inspection happens locally and the data does not take a detour through another jurisdiction. Dopamine DLP classifies via zero-retention APIs, with no training on customer data. That is a cleaner story for data residency questions than a cloud proxy that must terminate TLS somewhere you do not choose, though the specific control mapping is always a conversation with your auditor.

Do we need to install a root certificate to get payload visibility?

Any product that inspects TLS content needs a trusted certificate, including the cloud proxies. The difference is where the inspection happens and therefore what breaks. With dope.security the inspection runs on the endpoint, and when an application pins its certificate the agent surfaces an SSL error notification so an admin can create a bypass in a few clicks instead of maintaining a blind exception list by hand.

The leak is a process, not a lookup

To say the thesis again in different words: a DNS filter cannot arbitrate a channel that it is the channel for. When the payload and the address are the same string, the only control that can evaluate it is one standing where that string is assembled, which is the device. Everything else is pattern matching on the outside of an envelope.

dope.security puts the proxy on the endpoint, reads the request in plain form, names the process and the data, and enforces policy on any network without a detour. If you want to see it against your own traffic, book a 20-minute demo and bring the four tests above.