DNS Filtering vs Secure Web Gateway: When DNS Is Enough

DNS filtering and a secure web gateway both stop people reaching bad websites, but they see very different amounts of each connection, and choosing one where you need the other leaves a gap attackers already know how to use. A DNS filter decides on a domain name before a connection exists. A secure web gateway (SWG) sits in the connection itself and can see the URL, the file and, with decryption, the content. This guide compares the two on visibility depth, bypass routes, deployment and latency cost, malware and data loss inspection, and failure modes, then gives decision criteria by organisation size and workforce pattern with worked scenarios. It is written for network and security architects, and for buyers deciding whether DNS is enough. For gateway deployment models, PAC files and category design, see the Secure Web Gateway and Web Filtering Guide; for choosing a resolver service, see the Protective DNS Guide.

Key takeaways

They answer different questions. DNS filtering asks "should this name resolve?"; an SWG asks "should this request, this file or this upload be allowed?". The second question needs the connection, not just the name.
DNS is the coverage layer, the gateway is the depth layer. DNS filtering reaches every device that resolves names, including printers, servers and IoT; a gateway reaches only traffic steered to it, but inspects that traffic properly.
Both are bypassed, by different routes. DNS filtering loses to encrypted DNS, hard-coded resolvers and direct IP connections; a gateway loses to proxy-unaware apps, QUIC, tunnels and devices that leave the network without an agent.
DNS cannot scan or stop data loss. Malware delivered from a reputable domain, phishing on a compromised legitimate site and uploads of sensitive data are invisible at the DNS layer; these need URL, file and content inspection.
DNS alone is defensible only with compensating controls. Small, mostly SaaS organisations can run DNS filtering plus strong endpoint and email protection; once you need DLP, download scanning or cloud app controls, you need a gateway or its SSE equivalent.

The short answer

Run DNS filtering everywhere, because it is cheap and reaches devices nothing else does. Add a secure web gateway for managed user devices when you need any of: full URL policy, download scanning and sandboxing, data loss prevention on uploads, per-action control of cloud apps, or user-level audit trails. The two are not substitutes. NSA and CISA guidance on protective DNS states that traffic which connects by IP address without a lookup skips the DNS layer entirely and that protective DNS should be one part of a defence-in-depth strategy rather than the only control. Most SWG and security service edge (SSE) offerings include a DNS layer, so in practice the decision is less "which one" and more "which traffic goes through which layer, and what happens when a device leaves the network".

How each works, in words

DNS filtering

A device asks a recursive resolver for the address of a name. A filtering resolver checks the name, and often the returned IP addresses, against threat intelligence and policy before answering. NSA and CISA describe this as a policy-implementing resolver, usually built on Response Policy Zone (RPZ) functionality. If the name is blocked, the resolver returns NXDOMAIN, a sinkhole address or the address of a block page. RFC 8914 Extended DNS Errors gives resolvers standard codes to say why: 15 Blocked (operator policy), 16 Censored (an outside entity requires it), 17 Filtered (the client asked for filtering) and 18 Prohibited (the client is not authorised).

Secure web gateway

An SWG is a forward proxy with a policy engine. Traffic reaches it through explicit proxy settings, transparent redirection, an endpoint agent or a site tunnel. For HTTPS it sees the server name from the TLS handshake or the HTTP CONNECT request; with TLS inspection it terminates the session, sees the full URL, headers and body, scans downloads and uploads, then re-encrypts towards the destination. Because it holds the session, it can authenticate the user through the identity provider and apply policy per user, group, device posture and action. NIST SP 800-215 places the SWG alongside CASB and ZTNA as one of the security services in the modern enterprise network landscape.

Comparison table

Dimension	DNS filtering	Secure web gateway
Decision point	Name resolution, before any connection	Each HTTP request and response within the session
What it sees	Queried name, record type, returned IPs, source IP (or device ID via agent)	Host and server name; with TLS inspection, full URL, headers, files, form data
Protocols covered	Any protocol that resolves a name first: web, mail clients, SSH, update agents, IoT	Web protocols steered to it (HTTP, HTTPS, sometimes FTP over HTTP); other ports only via firewall or SSE features
Devices covered	Everything using your resolvers, including unmanaged and headless devices	Devices configured or steered to it; agent-based coverage is managed devices only
Policy granularity	Domain or subdomain; one verdict for the whole site	URL path, category, file type, user, group, app action (upload, share, login to personal tenant)
Malware inspection	None on content; blocks known bad and algorithmically generated domains	Download scanning, sandboxing, real-time page classification
Data loss prevention	None	Inspects uploads and posts with decryption
Latency cost	Low: one lookup, cached by TTL	Per request; higher with decryption, scanning and hairpinning to a distant point of presence
Main bypass routes	Encrypted DNS to other resolvers, hard-coded resolvers, direct IP, hosts file, VPN apps	Proxy-unaware apps, QUIC over UDP 443, tunnels and anonymisers, off-network devices without an agent, decryption exemptions
Typical cost and effort	Low; often free for eligible public sector bodies through national services	Per user licences, certificate deployment, exemption management, support load

Threat model: what each stops and what passes

Map threats to the layer that can actually see them. A threat that lives entirely inside a trusted domain is beyond the reach of DNS by design.

Threat	DNS filtering	Secure web gateway
Phishing on a fresh or typosquatted domain	Stops it once the domain is listed, or by newly registered domain policy	Stops it by category, reputation or page analysis
Phishing on a compromised legitimate site or a reputable hosting platform	Passes: the domain is good	Can stop it by URL path or by page classification with decryption
Malware download from a file sharing or code hosting service	Passes unless the whole service is blocked	Download scanning, file type policy and sandboxing
Command and control over known domains, or domain generation algorithms (ATT&CK T1568 Dynamic Resolution)	Strong: blocks resolution; NSA and CISA list DGA detection as a protective DNS capability	Strong for web C2 it can see; blind to non-web C2
DNS tunnelling for C2 or exfiltration (T1071.004 Application Layer Protocol: DNS)	Detectable through query volume and entropy analysis at the resolver	Not visible unless the gateway also runs a DNS layer
C2 hidden behind a trusted front domain (T1090.004 Domain Fronting)	Passes: the resolved name is legitimate	Detectable with TLS inspection comparing server name and Host header (mitigation M1020)
Sensitive data uploaded to personal storage or an unsanctioned AI tool	Only by blocking the whole domain	Per action DLP and app control
Infected IoT device or server reaching a malicious host	Strong, if the device uses your resolvers	Usually not covered: these devices are not steered to the proxy

The pattern is consistent: DNS filtering is strong against bad infrastructure and weak against bad content on good infrastructure.

Bypass routes and how each is closed

Both controls depend on traffic taking the path you designed. The routes differ, and so does the fix.

Routes around DNS filtering

Encrypted DNS to an outside resolver: browsers and operating systems can send queries over DNS over HTTPS (RFC 8484, using the application/dns-message media type) or DNS over TLS on TCP 853. RFC 8484 notes that sharing a connection with other HTTPS traffic makes DNS traffic analysis harder for on-path devices, which includes your own network controls. Close it with managed browser and OS policy, blocking of known public DoH endpoints at the proxy or firewall, and blocking outbound TCP and UDP 853. The better long-term answer is to offer encryption yourself: RFC 9462 Discovery of Designated Resolvers lets a client ask its plain resolver for SVCB records at _dns.resolver.arpa and upgrade to the encrypted resolver the same operator designates, so compliant clients encrypt without leaving your filter. The Encrypted DNS Enterprise Guide covers the client settings.
Hard-coded resolvers: malware and some appliances send queries to fixed public resolvers on port 53. Block outbound TCP and UDP 53 from everything except your resolvers, as NSA and CISA recommend, and alert on attempts.
Direct IP connections: no lookup, no decision. Only a firewall, an IP reputation feed or a gateway can stop these. Treat outbound connections to raw IPs on web ports as a detection signal.
Off-network devices: a laptop on home Wi-Fi uses the router's resolver unless a roaming client or agent forces queries to your service. The NCSC PDNS Roaming client sends DNS from remote Windows, macOS and iOS devices to PDNS over DoH.

Routes around a secure web gateway

Proxy-unaware applications: apps that ignore system proxy settings connect directly. Default-deny outbound web ports at the firewall except from the gateway, or use an agent that steers at the network layer.
QUIC and HTTP/3 over UDP 443: many proxies cannot inspect it. Disable QUIC in managed browsers and block outbound UDP 443.
Tunnels and anonymisers: VPN apps, Tor and residential proxy services (T1090 Proxy, T1572 Protocol Tunneling) carry traffic past the policy engine. Block the categories and known infrastructure, and use application control.
Decryption exemptions: every domain exempted from TLS inspection becomes a host-name-only decision for scanning and DLP. Keep the exemption list short, owned and reviewed.
Agent failure: an agent that is disabled, crashed or set to fail open sends traffic direct. Alert on agent health and use fail closed once the deployment is stable.

Each layer closes part of the other's gap: DNS catches the proxy-unaware app that still resolves names, and the gateway catches the threat on a reputable domain.

Deployment and latency cost

Factor	DNS filtering	Secure web gateway
Minimum viable deployment	Forward internal resolvers to the filtering service; restrict outbound DNS	Agent or PAC file on endpoints, trusted interception CA, identity integration, exemption list
Endpoint footprint	None on network; optional roaming client off network	Agent or proxy configuration and a root certificate on every inspected device
Added latency	One resolver round trip per uncached name	Every request traverses the proxy; decryption and scanning add more; distant points of presence add round trips
Breakage risk	False positive blocks on whole domains	Certificate pinning failures, broken uploads, app incompatibility with decryption
Failure impact	Resolver outage stops all name resolution: design for high availability	Gateway outage stops web access or, if fail open, removes protection

Malware and DLP inspection gaps

DNS sees no files: a malicious installer or macro document from a well-known file sharing service resolves normally. Only download scanning, sandboxing or endpoint protection sees it.
DNS sees no uploads: data loss prevention needs the request body, which needs a session. A DNS block on a whole storage or AI service is the only DNS-layer lever, and it removes legitimate use too. See the Data Loss Prevention (DLP) Guide.
Gateways without decryption are close to DNS: without TLS inspection a gateway sees the server name and can apply category and reputation, but cannot scan content or apply DLP. If you buy a gateway and never turn on decryption, you have mostly paid for a more expensive DNS filter with user identity. See the TLS Inspection Guide.

Decision criteria by organisation size and workforce

Situation	Reasonable baseline	Why
Small organisation, mostly SaaS, under about 50 users, no regulated data	DNS filtering with a roaming client on every laptop and phone; strong email filtering; endpoint protection; browser policy	Low cost and effort; covers known bad infrastructure; endpoint protection handles files
Small or mid-size with regulated or sensitive data	DNS filtering plus a cloud SWG or SSE agent on managed devices, with DLP on upload paths	Data loss and audit duties need content inspection and user identity
Mostly remote or hybrid workforce	Agent-based steering for both DNS and web, fail closed once stable	Network-only controls stop at the office door; the agent follows the device
Large enterprise, many sites and data centres	DNS filtering at internal resolvers for every network; gateway via agent for laptops and tunnels for sites; on-premises gateway where sovereignty requires	Two layers for different populations; servers and OT stay DNS only with firewall egress rules
Guest, BYOD and IoT networks	DNS filtering only, with egress firewall rules	You cannot install certificates or agents; DNS is the control you have
UK or US public sector body	Check eligibility for the NCSC PDNS or CISA Protective DNS Resolver first, then layer a gateway	National services provide the DNS layer at no cost to eligible bodies

When DNS is enough: you hold little sensitive data, staff use managed devices with good endpoint protection, email is filtered, you accept that malware and phishing on reputable platforms must be caught at the endpoint or mailbox, and no regulator or contract requires web DLP or user-level browsing logs. Record that as a risk acceptance.

When DNS is not enough: you need to stop uploads of sensitive data, inspect downloads, control actions inside cloud apps, prove who visited what, or block threats that live on trusted domains.

Worked scenarios

Scenario 1: 40-person consultancy, fully remote

Staff use company laptops and phones, all work is in SaaS, no payment card or health data. They deploy protective DNS with a roaming client on every device, point browser DoH policy at that resolver and keep endpoint and email protection, accepting that malware from reputable file sharing services must be caught at the endpoint. Twelve months later, a client contract requires controls on uploads of client data to personal storage; they add a cloud SWG agent to laptops with DLP on upload paths only, keeping DNS as the base layer.

Scenario 2: 3,000-person manufacturer, offices, plants and remote staff

Internal resolvers forward to a filtering service for every network, including plant networks where OT devices cannot take agents. Outbound TCP and UDP 53 and TCP 853 are blocked except from the resolvers. Laptops run an SSE agent that handles both the DNS layer and the web gateway, with TLS inspection on all categories except health and finance, and DLP on uploads. Plant servers get no gateway; egress is allowlisted at the firewall and DNS logs feed the SOC.

Where identity fits

A DNS filter typically sees a source IP; a gateway sees an authenticated user. Servers, CI runners and automation accounts often reach the web with blanket proxy bypasses or a shared proxy credential stored in configuration. Give each workload its own egress identity or allowlist, and keep DNS filtering in front of them, since they are rarely steered through the user gateway. See the Proxy and Web Gateway Log Detection Guide for what those logs should contain.

Implementing a layered design

Baseline traffic: from a week of firewall, resolver and proxy logs, measure outbound DNS not using your resolvers, DoH and DoT to public endpoints, direct IP web connections and QUIC volume.
DNS layer first, in log-only mode: forward resolvers to the filtering service and review would-be blocks for a week; then enforce security categories.
Close DNS bypass: block outbound 53 and 853 except from resolvers, set browser and OS encrypted DNS policy to your resolver or off, and deploy roaming clients to devices that leave the network.
Pilot the gateway on a ring: IT and security staff first, with security categories enforced, acceptable use in monitor mode and decryption on a narrow category set.
Expand gateway coverage in waves, building the decryption exemption list and fixing broken apps as you go.
Close gateway bypass: disable QUIC, block UDP 443 and direct web egress, and switch the agent to fail closed.
Rollback plan: keep previous agent policy and resolver forwarding versioned; a gateway rollback falls back to DNS filtering only, never to unfiltered access without a time-limited, approved decision.

Detection and measurement

DNS coverage: share of devices whose queries reach your resolver or roaming client, compared with device inventory. Target close to 100% for managed devices.
DNS bypass attempts: blocked outbound 53, 853 and public DoH connections per week, by host; a host that keeps trying is either misconfigured or infected.
Gateway coverage: share of outbound web bytes seen by the gateway compared with firewall egress.
Inspection rate: share of HTTPS sessions decrypted and scanned, excluding approved exemptions.
Repeat C2 and newly registered domain blocks from one host: treat as an infection signal and open an incident, using the DNS Logging and Detection Guide for query analysis.

Common failure patterns

Calling DNS filtering a web gateway: buying protective DNS and reporting "web filtering in place" to the board, without stating that file, URL and upload threats are out of scope.
Leaving port 53 and 853 open: the filter works only for devices that choose to use it; malware with a hard-coded resolver does not.
Ignoring browser DoH: managed browsers left on automatic encrypted DNS can resolve through public resolvers and skip the filter entirely.
Gateway without decryption: licences paid for scanning and DLP that never see content.
Fail-open agents nobody watches: remote laptops silently browsing unfiltered after an agent crash.
No DNS layer for servers and IoT: assuming the user gateway covers everything, when headless devices never touch it.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection; SC-7(8) Route Traffic to Authenticated Proxy Servers	Gateway as the authenticated egress point
NIST SP 800-53 Rev. 5	SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver); SI-4 System Monitoring	Filtering resolver and its logs
NIST CSF 2.0	PR.IR-01; DE.CM-01	Protecting networks from unauthorised use; monitoring network services
CIS Controls v8.1	9.2 Use DNS Filtering Services; 9.3 Maintain and Enforce Network-Based URL Filters	DNS layer and URL layer as separate safeguards
ISO/IEC 27001:2022 Annex A	A.8.23 Web filtering; A.8.20 Networks security	Managing access to external websites
MITRE ATT&CK mitigations	M1021 Restrict Web-Based Content; M1037 Filter Network Traffic; M1020 SSL/TLS Inspection	Gateway and DNS controls against web-borne techniques
MITRE D3FEND	D3-DNSDL DNS Denylisting; D3-DNSTA DNS Traffic Analysis	The defensive techniques a DNS layer implements

Practitioner checklist

Every network, including guest, OT and server segments, resolves through a filtering resolver.
Outbound TCP and UDP 53 and TCP 853 are blocked except from your resolvers, with alerts on attempts.
Browser and OS encrypted DNS settings point to your resolver or are disabled on managed devices.
Devices that leave the network run a roaming DNS client or an agent that covers DNS.
Managed user devices are steered to a gateway with TLS inspection, and the exemption list has owners and expiry dates.
QUIC is disabled or UDP 443 is blocked where the gateway cannot inspect it.
DLP covers upload paths for the data you must protect, or the decision not to do so is recorded as a risk acceptance.
Agent health and fail-open events alert the SOC.
DNS and gateway logs reach the SIEM, and coverage metrics are reported monthly.

DNS Filtering vs Secure Web Gateway: Coverage, Bypass and When DNS Is Enough