DNS-Layer Security: What It Catches, and What It Structurally Can't

Quick answer: DNS layer security blocks a domain lookup before any connection opens, which makes it excellent at stopping command-and-control callbacks, phishing domains, malware hosts, and newly registered domains, on every device including ones that can't run an agent. It can't do four things, and none of them are a vendor failing: it can't see the URL path, it can't see the payload or file, it can't tell an enterprise tenant from a personal account on the same domain, and it can't enforce anything on traffic that skips the resolver. A DNS query carries a name and a record type. That's the whole protocol. For the rest you need full URL filtering with SSL inspection, which dope.security runs on the device.

New here? Start with What Is DNS Security? and the difference between URL filtering and DNS filtering.

Start with what the DNS layer genuinely catches

Anyone who frames DNS filtering as security theater hasn't run it. It's real security, it's cheap, and it does things no other layer does as efficiently.

It blocks before the connection exists. Every other control inspects a session in progress. DNS refuses to answer, so no packet ever leaves for the malicious host. There's no payload to sandbox, no TLS handshake to terminate, no partial download to clean up.

It kills command-and-control. Commodity malware, most ransomware loaders, and nearly every commodity botnet resolve a domain to call home. Break the lookup and the implant sits there doing nothing. This is the single highest-value thing DNS filtering does.

It covers devices you cannot instrument. Printers, IP cameras, badge readers, HVAC controllers, medical devices, guest and contractor laptops, and anything running an OS you have no agent for. Point DHCP at your resolver and they all inherit policy.

It catches infrastructure patterns, not just known-bad names. Newly registered domains, domains with no reputation history, algorithmically generated domains, and typosquats of your own brand are all visible as names. A good protective DNS feed blocks entire clusters of attacker infrastructure that hasn't been used yet.

It's nearly free in latency and effort. The lookup was happening regardless. A site can be protected in an afternoon by changing one DHCP setting, with no endpoint rollout and no proxy configuration.

It gives you a telemetry stream of intent. Every device announces where it wants to go, by name, before it goes. That log is one of the best detection datasets in a network.

If you're only going to deploy one control this quarter, deploy this one.

What a DNS query actually contains

Here's where the honest engineering part begins, and it's a protocol conversation, not a vendor conversation.

A DNS query is a small message. It carries a QNAME (the domain being asked about, like chat.openai.com), a QTYPE (A, AAAA, TXT, and so on), and a QCLASS. The response carries records and TTLs. Optional extensions add things like a truncated client subnet.

Now list what is not in that message: the URL path, the query string, HTTP headers, cookies, the request body, the uploaded file, the authentication token, the tenant identifier, the username, and the response content.

All of that lives inside the TLS session that opens after DNS finishes. Roughly 95% of web traffic is encrypted, so without SSL inspection a filter sees the domain and nothing else.

That gap is not a bug Cisco shipped, or DNSFilter, or Cloudflare. It's what RFC 1035 defined and what every resolver since has implemented. Blaming a DNS product for not reading a URL is like blaming a postal sorting center for not reading the letter.

The four things DNS-layer security structurally can't do

1. It can't see the URL path

github.com and github.com/some-org/exfil-repo produce the identical DNS query. So do drive.google.com/file/d/legit and drive.google.com/file/d/malicious. So does every page on a site where 99% of the content is fine and one path is not.

This forces an all-or-nothing choice on shared infrastructure. Content delivery networks, cloud storage, developer platforms, and site builders all host good and bad content behind the same name. DNS gives you one lever: resolve, or don't.

2. It can't see the payload or the file

A DNS filter can allow a file-sharing domain. It cannot tell you that the file moving across that connection is your customer database, a signed installer, or a malware dropper. The bytes are inside the session, and the session hasn't started yet when DNS makes its decision.

The same applies in reverse. Data leaving your organization through an allowed, legitimate domain is invisible at the DNS layer, because the domain is not the thing that's wrong.

3. It can't tell an enterprise tenant from a personal account

This is the one that matters most in 2026, and it's the cleanest illustration of the limit.

A DNS filter can allow chat.openai.com or block it. It cannot allow your enterprise ChatGPT tenant while blocking a personal login, because the tenant identifier lives inside the encrypted request, not in the domain name. Same for Claude, same for Google, same for Microsoft 365. One domain, two completely different risk profiles, one indistinguishable query.

So you get a binary you don't want. Block the domain and you break the sanctioned, licensed, contractually protected version your company pays for. Allow it and personal accounts flow through with your data.

Cloud Application Control in dope.security handles this by inspecting decrypted TLS and reading the tenant header inside the request, applying enterprise-only access by tool and syncing enforcement across the fleet in under a minute. That's not a smarter blocklist. It's a different layer with different visibility.

4. It can't enforce anything that bypasses the resolver

DNS enforcement assumes the device asks your resolver. Several common things break that assumption.

A browser or app configured for DNS over HTTPS sends lookups straight to a public resolver over port 443, and your policy never sees them. Malware that hardcodes an IP address skips DNS entirely. A VPN or proxy tunnel carries its own resolution. A device with a manually set resolver, or one on a network you don't control, is outside the system.

None of this is exotic. It's default behavior in several browsers and standard practice in modern malware.

Threat type, does DNS catch it, what you need instead

Threat type	Does DNS-layer security catch it?	What you need in addition
Malware C2 callback by domain	Yes, reliably	Endpoint detection for the initial infection
Known phishing domain	Yes	URL filtering for phishing pages on allowed hosts
Newly registered / DGA domains	Yes, often	Monitoring to confirm intent
Typosquat of your brand	Yes	Email and brand monitoring
DNS tunneling and exfiltration	Yes, with query monitoring	Endpoint DLP for other egress paths
Malicious path on an allowed domain	No	Full URL filtering with SSL inspection
Malicious file download	No	On-device anti-malware and inspection
Sensitive file uploaded to an allowed app	No	Endpoint DLP such as Dopamine DLP
Personal account login on a sanctioned app	No	Tenant-level control such as Cloud Application Control
Sensitive data pasted into an AI prompt	No	AI prompt inspection and DLP
Traffic using DoH to a public resolver	No	On-device inspection
Malware connecting to a hardcoded IP	No	Endpoint and network controls

What Greylock found

Greylock Partners, the Silicon Valley VC firm, ran into exactly this boundary. Their DNS-only filtering missed HTTPS traffic, and the SWG component they had still backhauled through Cisco data centers. They went from first proposal to signed contract with dope.security in 27 days. The full story is here.

The lesson isn't that their DNS layer was wrong. It's that it was one layer.

What to layer on top, and where to put it

The second layer has to decrypt TLS, read the full URL, inspect the file, and identify the account. The only real design question is where that inspection happens.

Cloud proxies do it in a vendor data center, which adds roughly 40 to 80 ms near a point of presence and 150 to 400 ms when users are far from one, and Gartner has cited a 10-20% throughput drop as inspection modules stack.

dope.security does it on the endpoint. The dope.SWG agent runs an on-device SSL proxy that inspects all application and internet traffic locally, delivering up to 4x the performance of legacy proxy SWGs in under 100 MB of RAM, Mac native and Windows with identical features on both. Traffic goes straight to its destination instead of taking a detour. That's Fly Direct.

Conclusion

DNS is the right first layer and the wrong only layer. Keep your resolver policy, keep the C2 blocking, keep the coverage on devices that can't run software. Then add the layer that reads what a domain name can't express.

Start a free trial or book a 20-minute demo.

Frequently Asked Questions

What is DNS layer security?

DNS layer security enforces policy at the moment a device resolves a domain name, before any connection opens. It blocks lookups for malicious or unwanted domains, covers every device that uses your resolver including ones without an agent, and adds no measurable latency because the lookup was happening anyway.

Is DNS filtering enough on its own in 2026?

No. A DNS query contains only a domain name and a record type, so DNS filtering can't read URL paths, inspect files, or distinguish an enterprise account from a personal one on the same domain. With roughly 95% of web traffic encrypted, you need SSL inspection above it to see what's actually moving.

What are the main DNS filtering limitations?

There are four: no visibility into the URL path, no visibility into the payload or file, no ability to tell an enterprise tenant from a personal account on the same domain, and no enforcement over traffic that bypasses the resolver through DoH, a hardcoded IP, or a tunnel.

Can DNS filtering block personal ChatGPT accounts?

No. Personal and enterprise ChatGPT sessions use the same domain, and the tenant identifier sits inside the encrypted request. A DNS filter can only allow or block the domain for everyone. Blocking tenant by tenant requires decrypting TLS and reading the tenant header, which dope.security does with Cloud Application Control.

Does DNS security stop encrypted traffic threats?

Partially. It stops a connection to a known-bad domain before encryption starts, which is genuinely useful. It can't inspect anything inside an established TLS session, so malicious content served from an allowed domain passes untouched at the DNS layer.

Why can't a DNS filter just read the URL?

Because the URL is never sent to a DNS resolver. The device resolves the hostname first, then opens a TLS connection, then sends the path and headers inside that encrypted session. The resolver's job finished before the URL existed on the wire.

Should I replace DNS filtering with a secure web gateway?

Usually not. Keep both. DNS filtering blocks a large volume of commodity threats cheaply and protects unmanaged devices, which reduces what the gateway has to inspect. The gateway handles URLs, files, tenants, and prompts. They cover different moments in the same request.

Related reading

• What Is DNS Security? A Practical Guide for 2026
• DNS Security Solutions Compared: Where Each One Stops
• Recursive vs Authoritative DNS (and Why It Matters for Security)
• DNS Attack Protection: The Threats DNS Security Actually Stops
• Greylock Partners Ditched Cisco Umbrella for dope.security
• Enterprise Web Filter vs DNS vs SWG