DNS filtering for schools and libraries

DNS filtering for schools and libraries blocks harmful and malicious sites at the DNS lookup, before any connection opens. It covers every device on your WiFi without agents or new hardware. To hold up under scrutiny, it must also stop encrypted-DNS bypass, lock Safe Search on Google, Bing and YouTube, and produce reports your compliance lead can evidence.

What is DNS filtering for schools and libraries?

Every web connection starts with a DNS lookup. A device asks a resolver to turn a name into an IP address. DNS filtering adds a policy check to that answer. If the domain sits in a blocked category or carries a threat signal, the resolver withholds the real address. The browser never opens a connection, so the content, malware or ad never loads.

A resolver that does this is called protective DNS. On a school or library network it does three jobs at once:

• It enforces your content policy.
• It blocks phishing and malware domains.
• It locks search engines into their safe modes.

Where does the filtering happen, and what does a firewall miss?

Filtering happens at the lookup, before the device has an address to connect to. A firewall works later, on the connection itself. Without decryption it sees an IP address, a port and little else.

Most web traffic now runs over HTTPS on port 443. Much of it goes to content delivery networks, which host thousands of unrelated sites behind shared addresses. If you block one of those IPs, you block legitimate sites with it. If you allow it, the harmful site gets through.

A firewall can inspect HTTPS, but only after you install a trusted certificate on each device. You can do that on school-owned laptops. You cannot do it on a visitor's cell phone in a library, or on a student's own tablet on high school WiFi. DNS filtering needs nothing on the device. It applies to anything that takes its DNS settings from your network.

Why does a school DNS content filter matter on your network?

Schools: E-Rate, CIPA, and compliance standards

In the US, the Children's Internet Protection Act (CIPA) requires K-12 schools and libraries receiving E-Rate discounts to enforce internet safety policies and filtering measures. It requires school boards and administrators to have appropriate filtering and monitoring in place and to review how well they work. It gives administrators key responsibility for online safety, including understanding the filtering and monitoring systems.

US compliance standards for K-12 schools set out what that means in practice:

• Assign clear roles.
• Review your provision at least annually.
• Block harmful and inappropriate content without unreasonably affecting teaching and learning.

KCSIE points schools to the UK Safer Internet Centre's definition of appropriate filtering. That definition expects your provider to be an Internet Watch Foundation (IWF) member and to block the IWF list of child sexual abuse content. It also expects the provider to block the police-assessed list of unlawful terrorist content from the Counter Terrorism Internet Referral Unit (CTIRU). Put both questions to any vendor on your shortlist.

US schools face the Children's Internet Protection Act (CIPA) instead. We cover the certification steps in our separate guide to CIPA-compliant WiFi filtering. For the policy side, see Web filtering for schools: Policies that work.

Do libraries need content filtering?

In practice, yes. The legal duty depends on where you operate and how you are funded.

In the US, CIPA applies to public libraries that take E-Rate discounts for internet access. Those libraries must run a technology protection measure that blocks images which are obscene, child sexual abuse material, or harmful to minors. The Federal Communications Commission (FCC) lets a library disable the filter for an adult doing bona fide research or for another lawful purpose.

In the UK, no statute requires a public library to filter. Many library services filter anyway, and many seek Friendly WiFi accreditation. Friendly WiFi is a government-initiated certification scheme for public WiFi. Its minimum standard requires you to filter pornography and IWF-listed child sexual abuse content wherever children may be present.

Libraries have a harder job than schools. One network serves a child at homework club and an adult researching a medical condition. Your policy has to protect the child without overblocking the adult. Splitting those audiences onto separate networks is usually the cleanest answer. How to Set Up Network Segmentation for Guests and Staff walks through the approach.

How does DNS filtering for schools and libraries work?

You change one setting: the DNS servers your DHCP scopes hand to devices. Access points, controllers and switches stay where they are. Each device then sends its lookups to the protective resolver, and the resolver applies your policy.

Content categories and threat protection

The resolver checks each domain against two sets of signals.

• Content categories, such as adult content, gambling, weapons or proxies and anonymizers. You choose which to block for each audience.
• Threat intelligence, covering phishing, malware, command-and-control and newly registered domains used in attacks.

Speed matters on the threat side, because attackers register domains and use them within hours. Shield flags these threats as soon as malicious domains are identified. For a school, that is the gap between a staff member clicking a phishing link and the resolver refusing to answer.

What ad blocking does to busy shared WiFi

Libraries and schools often run dense WiFi on limited backhaul. Blocking ad and analytics domains at the DNS layer removes unnecessary traffic before it reaches your connection. Filtering out these requests leads to:

• faster page loads for users
• reduced overall data usage
• fewer DNS queries hitting the network
• lower overall web traffic volumes

On a library connection shared by public PCs and visitor cell phones, that headroom goes back to homework, job applications and video lessons.

How do you enforce Safe Search across a school network?

Category blocking stops whole sites. Search engines are harder, because Google, Bing and YouTube are essential for learning but return explicit results in their default modes. Each vendor documents a DNS method that forces its safe mode network-wide:

• Google publishes forcesafesearch.google.com. When your resolver answers Google search lookups with that address, SafeSearch is locked on and the person searching cannot switch it off.
• Bing publishes strict.bing.com, which enforces strict SafeSearch the same way.
• YouTube publishes restrict.youtube.com and restrictmoderate.youtube.com, which force Restricted Mode at strict or moderate level.

A protective DNS service handles this mapping for you, so you choose a setting rather than editing records by hand. Moderate YouTube restriction usually suits high schools, because strict mode hides many legitimate teaching videos. Test with real lesson content before you roll out to every site.

How do students bypass school WiFi filtering with DoH?

Encrypted DNS is the most common way around a DNS filter. DNS over HTTPS (DoH, defined in RFC 8484) sends lookups inside ordinary HTTPS traffic. DNS over TLS (DoT, RFC 7858) encrypts them on port 853. Either can carry a device's lookups past your resolver to a public one that applies no policy.

Students rarely need to set this up themselves, because browsers and operating systems ship with encrypted DNS options. The table maps each route to the documented way to close it.

Bypass route	How it gets around your filter	How to close it
Firefox default DoH	Firefox can send lookups to a public DoH resolver	Return no answer for Mozilla's canary domain, use-application-dns.net, which tells Firefox to keep using your network's resolver
Chrome and Edge secure DNS	Upgrades to DoH when the configured resolver has a known DoH equivalent	Set the DnsOverHttpsMode policy to off on managed devices; on unmanaged devices the upgrade only runs against your own resolver's provider
iCloud Private Relay	Relays Safari traffic and DNS through Apple's servers	Return a negative answer for mask.icloud.com and mask-h2.icloud.com, as Apple documents, and devices show Private Relay as unavailable
Android Private DNS (DoT)	Sends lookups over TLS on port 853	Block outbound port 853 at your firewall; automatic mode falls back to your resolver
Hard-coded public resolvers	Device or app ignores DHCP and queries a public resolver on port 53	Block outbound port 53 to anything except your protective resolver
VPN and proxy apps	Tunnel all traffic out of your network	Block the proxies and anonymizers category, and block VPN apps by MDM policy on managed devices

The fix combines DNS rules, firewall rules and device policy, because no single layer closes every route. Our separate guide to blocking encrypted DNS and DoH bypass covers each control in detail.

What reporting do schools and libraries need as evidence?

Filtering you cannot evidence will not satisfy a governing body, an inspection or a CIPA audit. The DfE standards expect a documented annual review. In the US, CIPA requires an internet safety policy adopted after public notice and a public hearing. Both rely on records.

Ask any provider whether it can export the following:

• Blocked lookups by category, so the safety team can see which harms the filter actually stopped.
• Results by site and by network, so a district can compare schools and a library service can compare branches.
• Trends over time, to show the effect of policy changes between reviews.
• Bypass signals, such as lookups for DoH resolver domains, the Firefox canary domain or Private Relay domains.
• Safe Search status, with evidence that the lock applied on every network.
• A policy change log, recording who changed which setting and when.
• A record of overblocking, logging which legitimate sites staff asked you to unblock and how fast you acted.

The overblocking record matters more than most teams expect. Safety standards explicitly warn against filtering that unreasonably affects teaching. A log of unblock requests and response times shows you balanced protection against learning.

Keep data protection in view. Under CCPA/CPRA, DNS logs that can be linked to an identifiable person are personal data. Set a retention period, restrict access to named staff, and record the lawful basis in your privacy notice. Purple holds ISO 27001, GDPR, CCPA and Cyber Essentials certifications, which you can cite in your data protection impact assessment.

Where does DNS filtering sit alongside what you already run?

Protective DNS is a layer on top of your existing network, not a replacement for it. Purple is hardware-agnostic. Shield runs on WiFi from Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet, because it changes the DNS your network hands out, not the access points.

The usual stack looks like this:

• Firewall: blocks outbound ports 53 and 853 to unapproved resolvers, and keeps doing the perimeter jobs DNS cannot.
• Network segmentation: separate networks or VLANs (virtual LANs, which split one physical network into isolated logical networks) for staff, students, visitors and children's areas, each with its own policy.
• Mobile device management (MDM): enforces browser policy and blocks VPN apps on school-owned devices, including off site.
• Captive portal: the sign-in page visitors see before they get online. On Guest WiFi it is where you present your acceptable use policy and capture consent.

Shield, DNSFilter and Cisco Umbrella compared

All three filter at the DNS layer, and all three can enforce Safe Search. They differ in what they were built around.

	Purple Shield	DNSFilter	Cisco Umbrella
Where filtering happens	DNS lookup	DNS lookup	DNS lookup, with optional secure web gateway
New hardware needed	None: change the DNS your WiFi hands out	None: DNS forwarding or roaming agent	None for the DNS layer; optional virtual appliance for internal IP attribution
Safe Search enforcement	Google, Bing and YouTube	Google, Bing and YouTube	Google, Bing and YouTube
Off-network devices	Covers devices on your venue WiFi; use MDM for take-home devices	Roaming client agent	Roaming module in Cisco Secure Client
Managed from	The Purple platform, alongside Guest WiFi and Staff WiFi	DNSFilter dashboard	Cisco Umbrella dashboard, within Cisco Secure Access
Best fit	Venues already running, or moving to, Purple WiFi	MSPs and agent-based endpoint fleets	Organizations standardized on Cisco security

Choose Cisco Umbrella if your district or local government already runs Cisco Secure Access and wants a single security vendor. Choose DNSFilter if you need an agent on every take-home laptop and manage many tenants as an MSP. Choose Shield if your priority is the venue WiFi itself: filtering, threat protection and ad blocking on the network your students and visitors join, managed alongside your WiFi. For a wider market view, read The best protective DNS for guest and public WiFi.

How does it work in practice?

The two scenarios below are illustrative composites, built from the deployment patterns described above.

A county library system working towards Friendly WiFi

The situation. A library system runs public WiFi across branches on one shared network. Children's homework clubs and adult visitors use the same SSID. Its old filter ran on a firewall at each branch, and most branches allowed explicit Google image results.

What was done. The IT lead split each branch onto two networks: a children's network with a strict policy, and an adult network with a lighter one. Both pointed at a protective DNS resolver blocking pornography and IWF-listed content, which meets the Friendly WiFi minimum. Safe Search was locked on Google and Bing for both networks. YouTube Restricted Mode was set to strict for children and moderate for adults. The firewall blocked outbound DNS to every resolver except the protective one.

The measurable outcome. The team tested a fixed list of category and search terms on both networks at every branch. Every branch passed, and the results went into the Friendly WiFi application as evidence. Branch staff now handle adult unblock requests from a written allow-list process, and the service logs each request and resolution time.

A school district closing the DoH gap

The situation. A district runs high schools, with personal-device WiFi for high school seniors. A designated safeguarding lead noticed students reaching blocked social and gaming sites on their own phones. District-owned laptops showed no such problem.

What was done. The network manager reviewed the bypass routes in the table above. The resolver now returns no answer for the Firefox canary domain and the iCloud Private Relay domains. The firewall at each school blocks outbound port 853 and outbound port 53 to public resolvers. On district-owned laptops, MDM sets Chrome and Edge secure DNS to off. The proxies and anonymizers category is blocked on the high school network.

The measurable outcome. Test phones running Firefox, Safari with Private Relay and Android Private DNS all fell back to the school resolver. Blocked categories then applied as intended. Bypass-signal lookups now appear in the monthly report the designated safeguarding lead reviews, which feeds the district's annual filtering review under the CIPA standards. For estates of this size, DNS filtering for MSPs and multi-site estates covers central policy management across sites.

What are the limits of DNS filtering you should know about?

Be clear with your school board about what DNS filtering cannot do.

• It works on domains, not pages. It cannot block one harmful page on an otherwise allowed domain. YouTube Restricted Mode and Safe Search narrow that gap but do not close it.
• It is filtering, not monitoring. The CIPA standards treat monitoring as a separate duty. On a shared network, DNS logs show a device, not a named student. Per-person attribution needs per-person authentication, such as IEEE 802.1X (port-based network access control using individual credentials) or iPSK (a unique pre-shared key per person). Purple's Identity-Based Networks provide both.
• It stops at your network edge. Take-home devices on home broadband need MDM or an agent.
• Determined bypass needs several layers. A VPN that is not yet categorized can still tunnel out until your firewall or MDM catches it.

None of these is a reason to skip DNS filtering. Each is a reason to pair it with the right controls and to document that pairing in your annual review.

What should you do next?

1. Map every network you run and the audience on each: staff, students, visitors and children.
2. Write a policy per audience, with the designated safeguarding lead signing off the categories.
3. Point a pilot site's DHCP DNS at a protective resolver and lock Safe Search.
4. Close the bypass routes in the table above and test with real devices.
5. Agree on your reporting package and retention period before you roll out.
6. Schedule the annual review now, so it happens.

To see how Purple handles filtering, threat protection and ad blocking on your existing WiFi, start with Shield. For related topics, browse All guides.

Frequently asked questions

Do we need new hardware to add DNS filtering to school WiFi?

No. Shield works by changing the DNS servers your network hands to devices, so your access points, controllers and switches stay in place. It runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You may add firewall rules to block outbound DNS and port 853 to other resolvers, but that is configuration on equipment you already own.

Does DNS filtering on its own meet KCSIE requirements?

No. DNS filtering covers the filtering half of KCSIE, but the DfE standards treat monitoring as a separate duty. You also need assigned roles, an annual review and a monitoring approach. Check that your filtering provider is an IWF member and blocks the CTIRU terrorist content list, as the UK Safer Internet Centre's definition of appropriate filtering expects. Then document how the filter, the monitoring and your safeguarding processes fit together.

How hard is it to migrate from Cisco Umbrella or DNSFilter?

The migration itself is a DNS change rather than a hardware project. First, rebuild your category and Safe Search policy in the new service. Run it in parallel at one pilot site and test blocked categories, Safe Search and bypass controls with real devices. Then update the DNS servers in your DHCP scopes site by site. Export your old reports first, so your annual review keeps its history.

How is Shield licensed?

Shield is a security add-on to Purple's Connect, Capture and Engage plans, alongside SecurePass and Verify. You license software, not appliances, so there is no hardware cost or refresh cycle. Your quote reflects the number of venues and networks you run. A school district or library system can bring every site under one agreement and manage it from the Purple platform.

Can a library unblock sites for adults without weakening protection for children?

Yes. The cleanest approach is separate networks: a strict policy where children are present and a lighter policy for adult visitors. In the US, CIPA lets a library disable filtering for an adult doing bona fide research or for another lawful purpose. Whatever your jurisdiction, log every unblock request and its outcome, so you can evidence that adults got access without children losing protection.

Are DNS filtering logs personal data under CCPA/CPRA?

Yes, when a log can be linked to an identifiable person. Under CCPA/CPRA that means setting a retention period, limiting access to named staff and stating your lawful basis in your privacy notice. On a shared network, logs usually identify a device rather than a person, which reduces risk. Purple holds ISO 27001, GDPR, CCPA and Cyber Essentials certifications, which supports your data protection impact assessment.

Do we still need a firewall if we run DNS filtering?

Yes. DNS filtering stops harmful and malicious domains before a connection opens, but it does not replace perimeter security. Your firewall still controls inbound access and segments networks. It also blocks outbound DNS and port 853 to unapproved resolvers, which closes the encrypted-DNS bypass. The two layers work best together: DNS decides which names resolve, and the firewall makes sure every lookup goes through your resolver.