Protective DNS: what it is, how it works and how to deploy it on WiFi
Protective DNS is a DNS resolver that refuses to resolve domains known or predicted to be malicious, so a device never connects to a phishing page, a malware host or a command-and-control server. Purple Shield is protective DNS for any WiFi network: it checks every lookup against threat intelligence and the policy for that network, and fails closed.
- Filtering built to the Internet Watch Foundation bar
- No hardware, no agents on devices
- Fails closed, across multiple data centres
Reviewed on October 9, 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
- Protective DNS is a recursive resolver that stops devices reaching malicious domains. The UK NCSC runs one for the public sector and defines it in exactly those terms.
- It acts at the lookup, before a connection starts, so phishing pages, malware downloads and command-and-control callbacks are cut off at the first step.
- It protects the devices an agent cannot: guest phones, BYOD and IoT on networks where you cannot install software.
- Three questions separate services: what feeds the blocklist, what happens when the resolver fails, and what you can see afterwards.
- Shield flags new malicious domains up to 10 days before standard blocklists, fails closed across multiple data centres, and blocks about 241,000 threats a week at St George's Healthcare NHS Trust.
- It is a layer, not a replacement: run it behind your firewall, and know its limits before you rely on it.
What it is
What is protective DNS?
Protective DNS is a recursive DNS resolver that prevents access to domains known to be malicious. The UK NCSC runs one for the public sector and describes it in those words; Shield applies the same idea to any WiFi network.
Every connection starts with a question. Before a phone opens a web page, loads an app's content or sends a background update, it asks a DNS resolver for the address behind a name. The resolver is the one place that sees all of those questions, from every device on the network, before any connection is made.
Protective DNS puts a decision at that point. The resolver checks each name against threat intelligence and policy. If the name is safe it returns the real address. If it is a known phishing page, a malware host or the server an infected device reports to, it returns nothing useful, and the connection never starts.
- DeviceAsks for a name before it connectslookup: 3. Protective DNS resolver
- Threat intelligenceFeeds, AI detection and your own listsrules: 3. Protective DNS resolver
- Protective DNS resolverChecks the name against threats and the policy for this networkallow: 4. Authoritative DNSblock: 5. Blocked
- Authoritative DNSAnswers only for names that pass
- BlockedNo useful answer, so no connection
- A device sends a lookup to the protective DNS resolver. Threat intelligence feeds the resolver its rules. The resolver passes allowed names on to the authoritative servers and blocks the rest.
Vendors use several terms for overlapping things, which is why searches for this topic return conflicting definitions. The table fixes them in one place.
| Term | What it decides | What drives it | Example |
|---|---|---|---|
| DNS filtering | What people may see | Content categories and your own lists | Block adult content and gambling on a guest SSID |
| DNS firewall | What is dangerous | Threat feeds applied as response policy | Refuse a known malware host |
| Protective DNS | Whether the destination is malicious | Threat intelligence, detection and policy together | Cut off a command-and-control callback |
| Encrypted DNS (DoH, DoT) | Who can read the lookup in transit | A transport choice, not a safety check | A browser sending lookups over HTTPS |
What it stops
What does protective DNS stop?
It stops anything that needs a domain name to work: phishing pages, malware downloads, command-and-control callbacks and the staging domains ransomware operators use. If the name does not resolve, the attack loses its first step.
| Threat | What happens in DNS | What protective DNS does |
|---|---|---|
| Phishing | A lookalike domain is looked up when a link is opened | Blocks known phishing domains at the lookup, so the page never loads |
| Malware delivery | A download link resolves to a malware host | Refuses the host, so the payload is never fetched |
| Command and control | An infected device looks up the server that controls it | Gives no answer, so the device cannot report in or take orders |
| Ransomware staging | Operators use domains to host tools and direct the attack | Cuts the lookups that stage and steer it |
| Generated domains | Malware looks up large numbers of algorithmically generated names to find a live one | Static lists miss new names; detection that flags new malicious domains early closes the gap |
The mechanism is the same each time. The attack needs a name to resolve, and the resolver declines. That is also why protective DNS protects devices nobody manages. A guest's phone arrives infected, joins the WiFi and starts calling home. Shield blocks the callback at the lookup, so every other user on that network stops sharing it with an active threat.
CISA's #StopRansomware Guide points to protective DNS as a way to block malicious internet activity at the source, which is the same argument stated for networks rather than endpoints.
How it works
How does a protective DNS service work?
Devices are pointed at the resolver through DHCP. For each lookup it checks threat intelligence and the network's policy, then returns the true address, a block page or nothing. Rules are applied as response policy, the standard way resolvers rewrite answers.
Four things happen on every lookup.
- The device is pointed at the resolver. DHCP hands out the resolver's addresses when a device joins, so no software is needed on the device.
- The name is checked. The resolver compares it with threat intelligence, the content categories chosen for this network, and the allow and block lists for the venue.
- The answer is chosen. An allowed name resolves as normal. A blocked name gets a block page, or no answer where a threat callback should just fail.
- The decision is recorded. The lookup, the policy that stopped it and the network it came from go to reporting.
The NCSC describes its own service in the same terms: a recursive resolver with rules, held as a Response Policy Zone, built from commercial, internal and open sources, with a block page for users when a domain is stopped. A Response Policy Zone is the standard mechanism resolvers use to rewrite answers by policy, which is why protective DNS needs no change to the rest of the network.
What changes with Shield is the unit of policy. A government resolver filters for an organisation. Shield filters for each network the venue runs: a policy per SSID, per VLAN, per venue and by time of day, so a guest network, a staff network and a children's area never share one set of rules.
Intelligence
Where does protective DNS get its threat intelligence?
From known-bad feeds, from your own lists and from detection of new domains. A blocklist alone only blocks what someone has already reported. Shield's AI detection flags new malicious domains up to 10 days before standard blocklists list them.
The weakest protective DNS services are the ones that only apply a static blocklist. A blocklist is a record of what went wrong yesterday. New phishing and malware infrastructure is registered fresh, used within hours and abandoned, so any list that waits for a report is late by design.
That is the gap Shield's detection closes. It flags new malicious domains as they appear, and it blocks known phishing and malware domains and command-and-control callbacks at the lookup. Your own allow and block lists sit on top, per venue, so a domain you trust is never caught and a domain you never want is always blocked.
- StartNew malicious domain goes liveRegistered, then used for phishing or malware
- EarlyShield flags itAI detection blocks the lookup
- Up to 10 days laterStandard blocklists list itA blocklist-only resolver starts blocking here
- 10 daysearlier warning of new threats than standard blocklists
- 241,000threats a week blocked at St George's Healthcare NHS TrustMalware, phishing and command-and-control lookups stopped by Shield.
Fail closed
What happens when protective DNS fails: fail open or fail closed?
A resolver that fails open leaves the network unfiltered when it breaks. One that fails closed keeps the policy in force. Shield fails closed and runs across multiple data centres, on a platform with a 99.999% uptime SLA, so you do not trade safety for uptime.
| Design | In an outage | Risk | What it needs |
|---|---|---|---|
| Fail open | Lookups bypass the filter and the network keeps working, unprotected | Every threat and blocked category gets through until it recovers | Nothing extra, which is why many services choose it |
| Fail closed | The policy stays in force; lookups that cannot be answered do not resolve | An outage never leaves a network unfiltered | Redundancy, so one fault does not take the service down |
Fail closed is only acceptable if outages are rare and local, which is why it needs redundancy behind it. Shield runs across multiple data centres, so a fault in one does not take your service down and users stay protected wherever they are. It runs on the Purple platform, which carries 500 million logins a year at a 99.999% uptime SLA.
For passenger and public WiFi where uptime comes first, that pairing is the point. A transport hub, a hospital and a hotel group all want the network to stay up and to stay filtered, and a fail-open design makes them choose.
Speed is the other question buyers ask. A lookup is a small request, devices and resolvers cache answers, and blocking ads and trackers removes lookups altogether, with up to 62% fewer DNS queries and up to 44% less data used on a filtered network. The resolver is rarely the slow part of a page load.
Visibility
What can you see and prove with protective DNS?
Every blocked lookup, by network and venue, with the policy that stopped it. Reporting shows blocked URLs, threat analysis including callbacks stopped, and usage beside the policy, so you can answer an auditor, a board or a parent with evidence.
| Report | Question it answers | Who asks it |
|---|---|---|
| Blocked URLs by network and venue | What did the filter stop, and where? | Venue managers, safeguarding leads |
| Threat analysis, including callbacks stopped | Is any device on this network infected? | IT and security teams |
| Network usage beside the policy that shaped it | What did the policy change about how the network is used? | Operations, finance |
Change a rule from the same screen you read the report on. The evidence and the control sit together, so a request such as "block that category at the weekend" is a minute's work with a record of it. It is also what makes protective DNS credible in a review: you can show that nothing harmful got through, and show the lookups that would have.
Deploy
How do you deploy protective DNS on a WiFi network?
Point each network's DNS at the resolver, switch on threat defence and a starting policy, force devices to use it, then test and read the reporting. The first network goes live in minutes and is free for 30 days.
Deploy protective DNS on your first network
Choose the network to protect first
Pick a single SSID or VLAN, ideally the guest network, so you see results quickly. Every network you add later copies the same pattern.
Set the resolver on that network
Set the Shield addresses as the DNS servers in the DHCP scope for the network, as a per-network setting or a DHCP change on your controller. No appliance, no firewall change, nothing on devices.
Check: A device on the network is handed the Shield addresses.
Switch on threat defence and a starting policy
Turn on command-and-control blocking, known phishing and malware blocking and AI detection, then add the content categories the audience needs.
Force devices to use it
Deny outbound DNS on the VLAN to anything but the Shield addresses, so a hard-coded resolver cannot route round the control.
allow udp/53, tcp/53 to <Shield resolver addresses> deny udp/53, tcp/53 to any deny tcp/853, udp/853 to any # DNS over TLS and DNS over QUICTest, then read the reporting
Open a site in a blocked category and confirm the block page, then read blocked URLs and threat analysis to see the lookups appear.
Check: Your test lookups appear in reporting.
Extend to the next network
Give each further SSID, VLAN and venue its own policy. If your estate runs change control, Purple's engineers plan a pilot on one SSID with your team or your ICT provider.
DNS security checklist for venues
0 of 9 done
Do you need it
Do you need protective DNS, a firewall or both?
On shared WiFi you want both. A firewall inspects traffic once a connection starts; protective DNS blocks the lookup first and reaches guest and BYOD devices a firewall agent never touches. Shield runs behind your firewall, not instead of it.
| What matters | Firewall | Endpoint agent | Secure web gateway | Protective DNS (Shield) |
|---|---|---|---|---|
| Acts when | A connection starts | On the device, at any time | A web request is made | At the lookup, before any connection |
| Software on the device | No | Yes | Often a client, proxy setting or certificate | No |
| Covers guest and BYOD devices | Only traffic through it | No | Only with configuration | Yes, every device on the network |
| Hardware to run at each site | Yes | No | Sometimes | No |
Which controls does your network need?
Firewall only
Fits when
- Every device is managed and you control the network end to end.
Not when
- Guests, residents or BYOD devices join.
- You cannot see lookups that go to a malicious domain.
Protective DNS only
Fits when
- You run a small guest network and want filtering and threat defence quickly.
- There is no budget for hardware.
Not when
- You need to inspect or segment traffic between networks.
Firewall with Shield behind it
Fits when
- You run guest, student or public WiFi at one site or many.
- You want threats stopped before the connection and traffic inspected after it.
Not when
- The network carries no unmanaged devices at all.
For guest and shared networks, run protective DNS behind the firewall you already have. Read DNS filtering limits to see exactly what the pair does and does not cover.
Standards
What do the NCSC and CISA say about protective DNS?
The NCSC runs a Protective DNS service for UK public sector bodies and CISA provides one to US federal agencies. CISA's #StopRansomware Guide also recommends protective DNS. These are the reference points buyers cite when they ask for it in a tender.
Protective DNS is not a vendor invention. It is government guidance with years of running service behind it.
- UK NCSC. Its Protective Domain Name Service (PDNS), published in 2017 and reviewed in 2024, is "a recursive DNS resolver which prevents access to domains known to be malicious". It is offered to UK public sector bodies and uses Response Policy Zone rules built from commercial, internal and open sources.
- CISA. Its Protective DNS Resolver service gives US federal agencies active traffic filtering upstream of their networks, and its #StopRansomware Guide points to protective DNS for blocking malicious internet activity at the source. NSA and CISA also publish guidance on selecting a protective DNS service.
- NIST. SP 800-81 Revision 3 is the Secure Domain Name System (DNS) Deployment Guide, the general reference for running DNS securely.
If a buyer in the public sector asks whether you run protective DNS, these are the documents they mean. Shield applies the same control to venue WiFi, with a policy for each network, which a single organisation-wide resolver does not.
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
| Compared with | Where Shield wins | What it is built for |
|---|---|---|
| DNSFilter | Built for guest and public WiFi, with ad blocking included, a policy per SSID and VLAN and nothing to install | Pure-play protective DNS for managed and roaming endpoints |
| Cisco Umbrella | Purpose-built for WiFi filtering, live in minutes across a multi-site venue estate | A broad secure-access suite, from DNS security to SWG and ZTNA, for large enterprises on quote-based pricing |
| Legacy filtering appliance | No hardware, no firewall change, and it fails closed across multiple data centres | A box at every site that inspects traffic at the network edge |
Glossary
Key terms
- Recursive resolver
- The DNS server that looks up a name on a device's behalf and returns the answer. Protective DNS is a recursive resolver with a security decision attached.
- Response Policy Zone (RPZ)
- A standard mechanism that lets a resolver rewrite or refuse answers for names listed in a policy zone. The NCSC's service uses it.
- Command and control (C2)
- The server an infected device reports to and takes instructions from. Blocking its lookup cuts the device off.
- NXDOMAIN
- The DNS answer meaning the name does not exist. A resolver can return it to make a blocked name behave as if it were not there.
- Domain generation algorithm (DGA)
- Malware that generates large numbers of pseudo-random domain names to find a live control server, which defeats static blocklists.
- Fail closed
- On a fault, keep the policy in force rather than letting traffic through unfiltered. The opposite is fail open.
- DNS over HTTPS (DoH)
- A way to send DNS lookups inside HTTPS (RFC 8484). It protects the lookup in transit and does not check the destination.
- Block page
- The page shown when a name is refused. Shield shows your own branded page.
The library
All guides in this pillar
What each group of guides covers in protective DNS, so you know where to look.
Fundamentals
What protective DNS blocks and how: phishing, command and control, new domains and tunnelling.
Threats and defence
Ransomware, public-sector guidance and malware on guest WiFi.
Operating it
Logs, reporting, deployment per SSID, and latency.
Sector use
Protective DNS for hotels and multi-site retail.
Questions
Questions about protective DNS
What is protective DNS?
Protective DNS is a recursive DNS resolver that prevents access to domains known to be malicious. A device asks it for an address, and for a phishing page, a malware host or a command-and-control server it returns nothing useful, so the connection never starts.
Is protective DNS the same as DNS filtering?
They overlap. DNS filtering decides what people may see by category and list. Protective DNS decides whether a destination is malicious, using threat intelligence and detection. Shield does both in one layer, with a policy for each network.
Does protective DNS replace a firewall?
No. A firewall inspects traffic once a connection starts. Protective DNS blocks the lookup first and covers guest and BYOD devices that a firewall agent never touches. Shield runs behind the firewall you already have.
Do I need to install anything on devices?
No. Pointing the network's DNS at Shield covers every device on that WiFi, with nothing installed on iOS, Android, Windows or guest devices, and no appliance to rack.
How does protective DNS catch threats a blocklist misses?
Shield blocks known phishing and malware domains and command-and-control callbacks at the lookup, and its AI detection flags new malicious domains up to 10 days before standard blocklists list them.
What happens if the service goes down?
Protection does not lapse. Shield fails closed, so an outage never leaves a network unfiltered, and it runs across multiple data centres, so a fault in one does not take your service down. It runs on a platform with a 99.999% uptime SLA.
Can users bypass protective DNS?
Only by stepping outside the network's DNS, with a hard-coded resolver, encrypted DNS or a VPN. Denying outbound DNS to anywhere but Shield and blocking VPN domains closes those routes, and the limits are set out in the DNS filtering limits guide.
Does protective DNS slow browsing down?
No. A lookup is a small request that is cached, and blocking ads and trackers means up to 62% fewer DNS queries and up to 44% less data used on a filtered network.
Who uses Shield?
Whitbread protects its hotel guest WiFi with Shield, AGS Airports protects passengers at Aberdeen, Glasgow and Southampton, and St George's Healthcare NHS Trust blocks around 241,000 threats a week on its guest WiFi.
How do I try it?
Start the 30-day free trial on one network. Point its DNS at Shield, choose a policy and read the blocked URLs and threat analysis for yourself. A Purple expert then sends a quote built around your venues and networks.
Keep going
Where to go next
On this site
On other Purple products
The wider picture
Reviewed on October 9, 2026