DNS filtering vs secure web gateway: when you need the heavier tool

Choose DNS filtering at resolution under RFC 1035 when protecting unmanaged WiFi devices across 80,000+ venues in 90 countries without installing hardware. Choose a secure web gateway when inspecting full URLs, downloads, or uploads on managed devices using platforms like Microsoft Entra ID. DNS filtering stops malicious destinations before connections open, while gateways proxy and decrypt traffic.

DNS filtering vs secure web gateway: the short answer

The answer turns on one question: do you need to see inside the connection, or only where it is going?

DNS filtering decides at the domain name. It refuses to resolve a malicious or unwanted destination, so the device never connects. A secure web gateway (SWG) is a proxy that sits in the traffic path. It can read the full URL, the file and the page, but only after it decrypts TLS.

On guest WiFi, the question settles itself. You cannot install a root certificate on a guest's cell phone. Without that certificate, a gateway cannot decrypt traffic without causing certificate errors. DNS filtering protects every device on the network with nothing installed. That is why it is the default for hospitality, retail, travel hubs and events.

On managed staff laptops that handle regulated data, the gateway earns its cost. You need it to inspect uploads, enforce rules on URL paths or apply data loss prevention (DLP). DLP stops sensitive data from leaving your network.

Most venues need protective DNS on every network and a gateway on a minority of managed devices, if they need one at all. Purple Shield delivers the first part. It runs standalone on any WiFi or alongside Purple Access, with a policy per network and VLAN. For the wider boundaries of the DNS approach, see our DNS filtering limits overview.

What we compared, and why these criteria decide the choice

We scored both approaches on eight criteria. Each one maps to a decision an IT security manager or venue operations manager makes when scoping filtering. We drew each option's capabilities from its own public material and from deploying both.

Placement comes first because it shapes the other seven. DNS filtering sits at name resolution, the lookup defined in RFC 1035. Every device asks a resolver for an address before it connects. A protective DNS resolver checks the domain against threat intelligence and category policy, then answers or refuses.

Because that check happens before any connection, it catches what a firewall misses. Firewall rules key on IP addresses and ports. Malicious domains move across shared cloud addresses that a firewall cannot safely block.

A secure web gateway sits later, inside the connection. Traffic reaches it through an endpoint agent, a proxy auto-config (PAC) file or an inline appliance. To read HTTPS, the gateway terminates TLS, inspects the content and re-encrypts it. That depth needs a trusted root certificate on every device it inspects.

The eight criteria:

• Placement: where in the connection the filter makes its decision.
• Visibility: what the filter can see, from the domain name to the page content.
• Unmanaged devices: whether guest and BYOD (bring your own device) traffic is covered.
• Deployment footprint: the hardware, agents and certificates required.
• Performance: the latency and bandwidth the filter adds.
• Failure behavior: what happens when the service is unreachable.
• Bypass resistance: how easily a device routes around the filter, for example through DNS over TLS (DoT) or DNS over HTTPS (DoH).
• Privacy footprint: how much personal data the filter processes.

In the market, the line is not always clean. DNSFilter is a protective DNS service, the same category as Shield. Cisco Umbrella sells DNS-layer security and, in its higher packages, a full secure web gateway, so it spans both sides of this comparison. When you assess any vendor, check which layer each package delivers rather than relying on the product name.

How do DNS filtering and a secure web gateway compare?

Two rows deserve a closer read. On visibility, the gateway wins outright. A DNS filter sees example.com but never the path to a file on that site. We explain why in why DNS filtering cannot see full URLs. On unmanaged devices, DNS filtering wins outright, because guest coverage needs no certificate and no agent.

The remaining rows are trade-offs you can manage. You can close the encrypted DNS bypass with firewall rules. Gateway latency is tolerable on a well-sized cloud service. Failure behavior depends on the product, which is why we state Shield's plainly: it fails closed.

Where DNS filtering wins

Guest WiFi and unmanaged devices

Every device on a WiFi network uses the DNS server that DHCP hands it. Point that server at a protective resolver and every phone, laptop, gaming console and smart TV is covered. Nobody installs anything. The captive portal, the sign-in page shown before network access, stays as it is. At scale, this is the only practical way to filter guests, residents, passengers and fans.

Many sites, no new hardware

Switching to DNS filtering is a configuration change, not a project. Shield works on the WiFi you already run, including Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet.

You set a policy per network and per VLAN. A family-friendly guest network and a staff network at the same site can therefore run different rules. Your staff network may assign VLANs by role through IEEE 802.1X, the port-based network authentication standard. If so, role-specific DNS policy follows without a proxy.

Earlier threat blocking

DNS sees intent before any traffic flows. A phished device must look up a domain before it can connect. So must an infected device calling home to a command-and-control server. Shield flags threats earlier in their lifecycle, before a web connection establishes. That lead time can decide whether a phishing domain is blocked before the first click or after it.

Lighter networks

Ad blocking happens at the same layer. Ad blocking reduces bandwidth usage and lowers DNS query volume when switched on. On a busy venue network with limited backhaul, that capacity comes back without new spend.

Failure that stays safe

Shield fails closed, so an outage never leaves a network unfiltered. That matters on guest networks, where you carry the reputational risk of whatever loads. We set out the trade-offs in DNS filtering fail open vs fail closed.

Smaller privacy footprint

A DNS filter processes domain names, not page content. Under CCPA/CPRA, that is a narrower set of personal data than decrypted browsing sessions. Your records of processing stay simpler as a result.

Where a secure web gateway wins

Be precise about the gateway's strengths. If you assume DNS filtering covers them, your security program will have real gaps.

Full URL and path control

Some policies live below the domain. You may want to allow a cloud storage service but block one shared folder. You may want to allow a news site but block its comment pages. Only a proxy that sees the full URL can enforce rules like these. Shared platforms are the hard case, because a DNS filter must allow or block the whole domain.

File and content inspection

A gateway can scan downloads for malware, block file types and sandbox unknown executables. DNS filtering stops connections to known-bad domains. A malicious file hosted on a trusted domain still passes through.

Data loss prevention

Your staff may handle payment card data in scope for PCI DSS, or patient records. If so, you may need to inspect uploads for sensitive content. That requires decrypted traffic and either a gateway or a dedicated DLP tool.

Per-person policy off the network

A gateway agent applies policy by named identity, synced from Microsoft Entra ID, Okta or Google Workspace. That policy follows a managed laptop onto home broadband or hotel WiFi. Shield's policy is set per network and VLAN, which suits venues and fixed sites. A remote workforce on managed devices may need per-person enforcement wherever people connect.

Application controls

Many gateways decode traffic for named applications. For example, they can let staff read a file-sharing service but block uploads to it. DNS filtering can allow or block an application's domains, but not individual actions inside the application.

If you are weighing these gaps against your risk register, read is DNS filtering enough? for the controls that sit alongside protective DNS.

What does each cost to run?

The two approaches are priced differently, so compare their cost structures rather than headline figures. We do not quote competitor prices. Confirm current terms with each vendor.

The hidden cost of a gateway is certificate and exception management. Apps that pin their certificates break under TLS inspection, so each one needs an exception. Most deployments exempt banking and health sites for privacy reasons. Every exemption becomes a rule someone must maintain. Agents also need updating across the device fleet. None of this is a flaw. It is the price of seeing inside traffic.

The running cost of DNS filtering sits in policy upkeep and bypass control. You review category decisions and handle allow requests. You also keep firewall rules for encrypted DNS current as new public resolvers appear.

What does moving between DNS filtering and a gateway involve?

From a proxy to DNS filtering on guest networks

This is the most common move. Teams often find a proxy on guest WiFi filtering little beyond hostnames, because it cannot decrypt guest traffic. The steps are:

1. Export your current proxy categories and your allow and block lists.
2. Map them to DNS categories. URL-path rules have no DNS equivalent, so decide per rule whether to allow or block the whole domain.
3. Point the DNS server in each network's DHCP scope at the protective resolver.
4. Block outbound DNS to other resolvers, DoT on port 853 and known DoH endpoints.
5. Test from a real guest device, then retire the proxy rule set for that network.

Shield's setup steps are covered on how Shield works. The encrypted DNS standards are RFC 7858 for DoT and RFC 8484 for DoH.

Adding a gateway for managed devices

This move is heavier, and it should be scoped to the devices that need it. Deploy the root certificate through your mobile device management (MDM) platform. Roll out the agent or PAC file, then build exceptions for pinned apps and privacy-sensitive categories. Complete a privacy risk assessment before inspection starts. Keep Shield in place underneath, because it still covers every device the gateway does not.

Running both

Layering the two is the strongest design on mixed sites. Shield blocks known-bad domains at resolution, across guest and staff networks alike. The gateway then inspects managed traffic in depth. Because DNS removes malicious destinations first, less hostile traffic ever reaches the proxy. Align the two category policies so a domain blocked at one layer is not allowed at the other.

How to decide between DNS filtering and a secure web gateway

Use this decision rule. If you do not own the devices, use DNS filtering. If you own the devices and must see inside the traffic, add a gateway on those devices only. Everywhere else, protective DNS is the right-sized tool.

Your next step is to list your networks and VLANs, and mark which carry unmanaged devices. Those networks get protective DNS now. Then see how Shield works for deployment. For the wider controls around identity, encryption and segmentation, read our enterprise WiFi security guide.