DNS filtering vs firewall: what each one stops, and what DNS filtering cannot
DNS filtering stops a connection by refusing to resolve the domain. A firewall permits or denies traffic once a connection is attempted. They act at different points, and DNS filtering has real limits: it does not see bare IP addresses, a VPN tunnel or the pages inside an allowed domain. Run together, with those routes closed, they cover shared WiFi.
- Filtering built to the Internet Watch Foundation bar
- No hardware, no agents on devices
- Fails closed, across multiple data centres
Reviewed on 9 October 2026
Shield in numbers
- 241,000threats a week blocked on the guest WiFi at St George's Healthcare NHS Trust
- 10 daysearlier warning of new threats than standard blocklists
- 80,000+venues on the Purple platform Shield runs on, in 90 countries
In short
Key takeaways
- DNS filtering decides at the lookup; a firewall decides at the connection. They are different layers, and shared WiFi needs both.
- DNS filtering sees domains, not pages. It cannot block one URL on an allowed domain or inspect what an allowed site sends.
- There are five routes round it: hard-coded DNS, encrypted DNS, VPNs and proxies, Private Relay, and bare IP addresses. Each has a known control.
- Most controls are enforcement rules at the firewall, which is why the two are a pair rather than rivals.
- Shield answers every lookup on the network it protects, with nothing on the device to switch off, and a Shield expert shows how your network handles VPNs and encrypted DNS before you trial.
- Test the controls after setup. A filter that has never been tested against its own bypasses is a filter you are assuming works.
The difference
What is the difference between DNS filtering and a firewall?
DNS filtering stops the lookup, before any connection. A firewall inspects and permits or denies the connection once it is attempted. DNS filtering is lighter and reaches every device on the network; a firewall sees more of the traffic that does connect.
- DeviceWants to reach a site or an appThen: 2. DNS lookup
- DNS lookupDNS filtering decides here, on the domainThen: 3. Connection attempt
- Connection attemptThe firewall decides here, on address, port and protocolThen: 4. Server
- ServerReached only if both allow it
- A device first looks up a name, where DNS filtering decides, then attempts a connection, where the firewall decides, and then reaches the server.
| What matters | DNS filtering (Shield) | Firewall or secure web gateway |
|---|---|---|
| Decides | At the lookup, before a connection starts | Once a connection is attempted |
| Decides on | The domain name | Address, port, protocol and, with inspection, the URL or content |
| Software on devices | None | None for the network firewall; a certificate or client for web inspection |
| Guest and BYOD devices | Every device on the network | Traffic through the gateway, but encrypted content is opaque without a certificate |
| Hardware at each site | None | Usually an appliance or a virtual one |
| Strongest at | Stopping threats and unwanted categories cheaply, everywhere | Segmenting networks and controlling ports, protocols and applications |
Blind spots
What can DNS filtering not see?
Anything that does not pass through a lookup, and anything inside an allowed domain. It cannot see a bare IP address, traffic between devices on the same network, or one bad page on an otherwise good site.
A DNS filter makes one kind of decision: allow or refuse a name. That is a strength, because it is cheap and reaches every device, and it is the boundary of what it can do. Be clear about the boundary before you design around it.
| Blind spot | Why DNS cannot see it | What covers it |
|---|---|---|
| One page on an allowed domain | DNS carries the host name, not the path. Allowing a domain allows everything on it | Choose categories at domain level; use a web gateway or endpoint control on devices you manage |
| Content inside an allowed domain | The resolver does not inspect what an allowed site sends | Endpoint protection and email security on managed devices |
| A connection to a bare IP address | There is no lookup to check | Firewall egress rules on known ranges |
| Traffic between devices on the same network | It never leaves through the resolver | Client isolation on guest SSIDs and VLAN segmentation |
| A tunnel to a private server | The lookups travel inside the tunnel | Block VPN and proxy categories and ports; accept that a custom tunnel to a server you cannot name is not caught by DNS |
None of these makes DNS filtering less useful on guest WiFi. They make it one layer. The remainder of this guide is about the routes users take round it, and the controls that close them.
Bypass routes
How do users bypass DNS filtering, and how do you stop each route?
Five ways: a hard-coded resolver, encrypted DNS, a VPN or proxy, iCloud Private Relay and a bare IP address. Each is closed by an enforcement rule or a policy category, and most of the rules live on the firewall.
- DeviceNeeds to look up a nameDHCP resolver: 2. Shield resolvergoes round: 3. Its own resolver
- Shield resolverHanded out by DHCPallowed: 4. Site reached
- Its own resolver8.8.8.8, DoH or DoTdenied: 5. Dropped
- Site reachedOnly if the policy allows it
- DroppedEgress rule denies other DNS
- A device normally sends its lookup to the Shield resolver handed out by DHCP and reaches the site. If it sends the lookup to a resolver of its own, the firewall egress rule drops it.
| Route | How it works | Defeats the filter? | What closes it |
|---|---|---|---|
| Hard-coded DNS | An app or device ignores the resolver DHCP gave it and queries 8.8.8.8 or another public resolver | Yes, if outbound DNS is open | Deny outbound port 53 to everything but the filter on the guest VLAN |
| Encrypted DNS | DNS over HTTPS (port 443), DNS over TLS (port 853) or DNS over QUIC (port 853) to another resolver | Yes, if the client picks another resolver | Deny port 853; answer the Firefox canary domain with NXDOMAIN; block public DoH provider hostnames with a block list |
| VPN and proxy | A tunnel carries everything, lookups included | Yes, for traffic inside the tunnel | Block VPN, proxy and anonymiser domains by category or block list; block common VPN ports |
| iCloud Private Relay | Apple devices send Safari traffic through two relays | Yes, while it is on | Return no answer or NXDOMAIN for mask.icloud.com and mask-h2.icloud.com, as Apple documents |
| Bare IP address | An app connects to an address with no lookup | Yes, for that connection | Firewall rules on known ranges |
Encrypted DNS
Does encrypted DNS break DNS filtering?
Only when the client sends its lookups to a resolver other than the network's. Encrypted DNS protects the lookup from eavesdroppers; it does not stop a network filtering the resolver it chose. The fix is to keep clients on your resolver.
Three standards encrypt the path between a device and a resolver: DNS over HTTPS (RFC 8484, carried on port 443), DNS over TLS (RFC 7858, TCP port 853) and DNS over QUIC (RFC 9250, UDP port 853). They exist so that nobody on the path can read or alter the lookup. That is a legitimate goal and it is neutral for filtering, as long as the resolver on the other end is the one the network chose.
The conflict appears when a browser or app is configured to use its own encrypted resolver. The lookup then leaves the network without ever visiting the filter. Two controls matter:
- The canary domain. Firefox checks a name, use-application-dns.net, before turning on DNS over HTTPS by default. If the network answers it with NXDOMAIN, Firefox keeps the feature off. It is a signal from the network to the browser, so it only works for browsers that honour it.
- Port and category rules. Deny port 853 outbound to everywhere, and block the hostnames of public DoH providers with a block list. Port 443 cannot be denied, so DNS over HTTPS has to be handled by hostname.
Neither needs anything on the device, and neither changes the user's browsing, which is the right trade on a guest network. If you manage the devices, the browser's own policy setting for DNS over HTTPS is the stronger control.
ECH and QUIC
Do ECH and QUIC defeat DNS filtering?
No. Encrypted Client Hello hides the server name inside the TLS handshake and QUIC moves web traffic onto UDP port 443, but a DNS filter decides at the lookup, before either is used. They weaken filters that read the server name at the firewall.
Two newer technologies are often described as the end of network filtering. The picture is narrower.
Encrypted Client Hello (ECH) encrypts the server name that a browser used to send in the clear at the start of a TLS connection. Firewalls and web gateways that filtered on that name lose it. ECH relies on the client learning the site's keys from a DNS HTTPS record (RFC 9460), and the lookup for that record still goes to a resolver. A DNS filter has already decided on the name by then.
QUIC (the transport under HTTP/3) runs over UDP rather than TCP, on port 443. A firewall that only inspects TCP web traffic misses it unless it is configured for QUIC. Again, the lookup that precedes it is untouched.
The practical conclusion is a reason to filter at DNS, not a reason to give up: the lookup remains visible to the network whichever transport follows. Where a firewall depends on reading the server name, expect it to see less each year.
Is it enough
Is DNS filtering enough for your network?
On a guest or shared network, DNS filtering is the right first layer and covers the threat and content jobs. It is not enough alone where you need page-level control, segmentation or inspection between networks. Answer three questions to find where you land.
Is DNS filtering enough?
Question 1
Do guests, residents or other unmanaged devices join this network?
See the whole decision as a list
Do guests, residents or other unmanaged devices join this network?
- Yes
Do you need to inspect or segment traffic between networks?
- Yes
Run Shield behind your firewall
- No
DNS filtering plus enforcement rules is enough
- Yes
- No, every device is managed
Do you need page-level or user-level control of staff browsing?
- Yes
Add a secure web gateway or endpoint control for managed devices
- No
DNS filtering plus enforcement rules is enough
- Yes
Close the gaps
How do you close the gaps in DNS filtering?
Keep every device on your resolver, then answer or block the encrypted routes. Four rules and two policy settings close most of them, and none needs software on the device. Test each one after you set it.
Close the five routes on a guest VLAN
Point DHCP at Shield
Set the Shield addresses as the DNS servers in the DHCP scope for the VLAN. Every device that joins is handed them.
Deny every other resolver
Allow DNS on port 53 only to the Shield addresses, deny it to everywhere else, and deny port 853 (DNS over TLS and DNS over QUIC) to everywhere.
allow udp/53, tcp/53 to <Shield resolver addresses> deny udp/53, tcp/53 to any deny tcp/853, udp/853 to anyCheck: A lookup sent straight to a public resolver fails.
Signal browsers to keep encrypted DNS off
Answer the Firefox canary domain use-application-dns.net with NXDOMAIN, and block public DoH provider hostnames with a block list in the policy.
Check: nslookup use-application-dns.net returns NXDOMAIN on the guest SSID.
Answer Private Relay
Return no answer or NXDOMAIN for mask.icloud.com and mask-h2.icloud.com, so Apple devices show that the network does not allow Private Relay.
Block VPN and proxy routes
Block VPN, proxy and anonymiser domains in the policy, by category or with your own block lists, and block the common default VPN ports at the firewall.
# Common defaults; many VPNs also run on 443, so rely on the policy category too deny udp/51820 # WireGuard default deny udp/1194 # OpenVPN default deny udp/500, udp/4500 # IPsec IKE and NAT traversalIsolate clients from each other
Turn on client isolation for the guest SSID so devices cannot reach each other on the local network.
| Test | How | Expected result |
|---|---|---|
| Resolver is Shield | Run nslookup example.com and read the Server line | A Shield resolver address |
| Hard-coded DNS is blocked | Run nslookup example.com 8.8.8.8 | The query times out |
| Canary domain is answered | Run nslookup use-application-dns.net | NXDOMAIN |
| Category blocks work | Open a site in a category you block | Your branded block page |
| A VPN app fails to connect | Try a consumer VPN app on the guest SSID | The connection fails or stays on the block page |
How Shield handles them
How does Shield handle these limits?
Shield answers every DNS lookup on the network it protects, on every device, with nothing on the device to switch off. It sits behind your firewall, fails closed across multiple data centres, and a Shield expert shows you how your network handles VPNs and encrypted DNS before you trial.
Shield is built on the argument of this guide: DNS filtering is the cheapest, widest layer, and it works best next to a firewall that enforces the routes round it. In practice that means four things.
- Behind the firewall, not instead of it. A firewall inspects traffic once a connection starts. Shield blocks the lookup first and covers guest and BYOD devices that a firewall agent never touches.
- Detection that does not wait for a list. AI detection flags new malicious domains up to 10 days before standard blocklists list them, and known phishing, malware and command-and-control domains are blocked at the lookup.
- A policy per network. Guest, staff, resident and paid networks each carry their own rules, set per SSID, per VLAN and per venue, and changed by time of day.
- Fails closed. If something goes wrong Shield does not open the network up, and it runs across multiple data centres so one fault does not take the service down.
Before you start the trial, a Shield expert walks through how your own network handles each route in the table above, so the controls are agreed before anything changes.
Proof
Running on guest WiFi at hotels, airports and hospitals
- 241,000threats a week blocked on the guest WiFi at St George's Healthcare NHS Trust
- 10 daysearlier warning of new threats than standard blocklists
- 80,000+venues on the Purple platform Shield runs on, in 90 countries
- 500 millionlogins a year across the Purple platform
- Whitbread
- AGS Airports
- St George's Healthcare NHS Trust
Compare
How Shield compares
| What matters | Firewall with Shield | Firewall on its own |
|---|---|---|
| When a bad domain is stopped | At the lookup, before the connection starts | Once a connection has started |
| Guest and BYOD devices | Covered, with no agent on any device | Out of reach of an endpoint agent |
| New threats | Flagged up to 10 days before standard blocklists | Caught when the blocklist catches up |
| Data used | Up to 44% less with ads and trackers stripped | Ads and trackers still load |
| Policy | Per network, VLAN, venue and time of day | Depends on the hardware at each site |
Glossary
Key terms
- DNS over HTTPS (DoH)
- DNS lookups carried inside HTTPS on port 443 (RFC 8484). It hides the lookup from the path and can send it to a resolver the network did not choose.
- DNS over TLS (DoT)
- DNS lookups carried over TLS on TCP port 853 (RFC 7858). A dedicated port makes it easy to deny at the firewall.
- DNS over QUIC (DoQ)
- DNS lookups carried over QUIC on UDP port 853 (RFC 9250).
- Canary domain
- use-application-dns.net, the name Firefox checks before enabling DNS over HTTPS by default. A network that answers NXDOMAIN signals that it filters DNS.
- Encrypted Client Hello (ECH)
- A TLS extension that encrypts the server name in the handshake, so filters that read it at the firewall lose it. DNS filtering decides earlier, at the lookup.
- QUIC
- The transport under HTTP/3. It runs over UDP port 443, which firewalls that only inspect TCP can miss.
- Client isolation
- A WiFi setting that stops devices on the same SSID reaching each other, closing the traffic path DNS filtering cannot see.
- Secure web gateway (SWG)
- A control that inspects web requests, often with a client or certificate on the device, giving URL and content-level policy.
The library
All guides in this pillar
What each group of guides covers in DNS filtering vs firewall, so you know where to look.
The core limits
What DNS filtering cannot see or stop, and how it fails.
Encrypted DNS and new protocols
DNS over HTTPS, DNS over TLS, ECH and QUIC.
Bypass routes
Hardcoded DNS, VPNs, mobile data, IPv6 and direct IP access.
Testing and tuning
Testing for bypass and handling false positives.
Questions
Questions about DNS filtering vs firewall
What is the difference between DNS filtering and a firewall?
DNS filtering decides at the lookup, before a connection starts, on the domain name. A firewall decides once a connection is attempted, on address, port and protocol, and with inspection on the URL. Shared WiFi needs both, and Shield runs behind the firewall you already have.
Can DNS filtering replace a firewall?
No. DNS filtering does not segment networks, control ports or inspect traffic between devices. It does stop threats and unwanted content cheaply on every device, which a firewall cannot do for guest and BYOD devices without an agent.
Is DNS filtering enough on its own?
For the threat and content jobs on a guest network, DNS filtering is the right first layer. It is not enough where you need page-level control, segmentation or inspection between networks, so run it with a firewall and close the bypass routes.
Can users get round DNS filtering with a VPN?
A VPN carries its own lookups inside the tunnel, so it can. Block VPN, proxy and anonymiser domains in the policy and the common VPN ports at the firewall. Shield answers every lookup on the network and nothing on the device can switch it off.
Does DNS over HTTPS break DNS filtering?
Only when a browser uses its own resolver instead of the network's. Answer the Firefox canary domain with NXDOMAIN, block public DoH provider hostnames with a block list, and deny port 853, and clients stay on your resolver.
Do ECH and QUIC defeat DNS filtering?
No. A DNS filter decides at the lookup, before ECH or QUIC is used. They weaken firewalls that filter on the server name or only inspect TCP, which is one reason to filter at DNS.
How do I block iCloud Private Relay on WiFi?
Apple documents returning no answer or NXDOMAIN for mask.icloud.com and mask-h2.icloud.com from the network's resolver. The device then tells the user the network does not allow Private Relay.
Can a hard-coded DNS server like 8.8.8.8 bypass the filter?
Yes, if outbound DNS is open. Deny port 53 to everything but Shield on the guest VLAN and the query fails. Run nslookup example.com 8.8.8.8 from a guest device to confirm.
What does DNS filtering not see?
Bare IP connections, one page on an allowed domain, the content an allowed site sends, traffic between devices on the same network and traffic inside a tunnel. Each has a covering control, set out in the table in this guide.
How do I test that my DNS filtering holds?
Run five tests from a guest device: the resolver is Shield, a lookup to 8.8.8.8 times out, the canary domain returns NXDOMAIN, a blocked category shows your block page and a VPN app fails to connect.
Keep going
Where to go next
On this site
On other Purple products
The wider picture
Sources and standards
- RFC 8484: DNS Queries over HTTPS (DoH)
- RFC 7858: DNS over TLS
- RFC 9250: DNS over Dedicated QUIC Connections
- RFC 9460: Service Binding and Parameter Specification via DNS (SVCB and HTTPS)
- IETF: TLS Encrypted Client Hello
- Mozilla: canary domain use-application-dns.net
- Apple: prepare your network for iCloud Private Relay
Reviewed on 9 October 2026