Both approaches keep students away from harmful content, and both can anchor a CIPA compliance program — but they work at different layers, see different things, and fail in different ways. This guide explains how each one makes a blocking decision, where each falls short, and why so many districts end up running the two together.
Ask five vendors what "filtering" means and you will get five answers, because the word covers two genuinely different technologies.
DNS filtering makes its decision at the moment a device asks "what is the address of this domain?" — before a single page byte is transferred. It is fast, cheap to operate, and covers every device that uses your resolver, including smart boards and guest phones.
Full web filtering makes its decision while the traffic itself flows, which means it can see the specific URL, the search query, and in many configurations the content of the page. It is deeper, more precise, and able to do things DNS never can — like forcing SafeSearch or allowing one section of a site while blocking another.
Neither is simply "better." The honest comparison is about layers, not winners. This guide walks through the mechanics of each, a side-by-side table of what they catch and miss, the situations where one alone is enough, and the layered design most districts land on once 1:1 devices and encrypted traffic enter the picture.
Same goal, two different checkpoints. Web filtering inspects the request as it travels; DNS filtering intercepts it before the connection even opens.
A web filter — whether an on-device agent, a browser-level control, or a gateway the traffic passes through — inspects the request itself rather than just the name lookup. It can read the complete URL, distinguish /educational-video from /explicit-section on the same domain, enforce SafeSearch on search engines and video sites, and apply a different policy for the signed-in third grader than for the teacher on the same network.
Because HTTPS encrypts everything after the domain name, this per-URL visibility on secure sites requires the filter to be positioned where it can see inside the session — typically via a managed device agent or trusted inspection. That is more moving parts than pointing DNS at a resolver, which is exactly why the choice between the two is really a choice about how much granularity your policies need.
Every visit to a website starts with a DNS lookup: the device asks a resolver to translate a name like example-site.com into an IP address. A DNS filter sits in the role of that resolver. Before answering, it checks the domain against a categorized database — ours classifies more than 120 million domains into 57+ content categories — and compares the result to your policy.
If the domain's categories are allowed, the lookup resolves normally and the student never notices the filter existed. If a category is blocked, the resolver returns the address of a block page instead, and the connection to the harmful site simply never happens. The whole check adds milliseconds.
The pattern to notice: DNS filtering wins on coverage, speed and simplicity; web filtering wins on precision and control. Almost every row where one is weak, the other is strong.
| Capability | Web filtering | DNS filtering |
|---|---|---|
| Blocks whole harmful domains (adult, gambling, malware) | Yes | Yes, before connection |
| Blocks a specific URL or page on a mixed site | Per-URL decisions | Domain-level only |
| Enforces SafeSearch on search engines | Built-in capability | Not by itself |
| Sees inside HTTPS pages | With agent or inspection | Sees the domain only |
| Covers unmanaged & guest devices on the network | Usually managed devices only | Anything using the resolver |
| Covers non-browser apps and game launchers | Browser/agent scope | Any DNS-based connection |
| Latency added per request | Low, but inspection costs more | Milliseconds |
| Deployment effort | Agents, certificates or gateway | Point DNS at the resolver |
| Per-user / per-grade policies | Tied to student identity | Coarse (by network or site) |
| Stops malware & phishing at the lookup | Plus in-page detection | Connection never opens |
| Detail available for reports & audits | URLs, users, searches | Domains and categories |
| Follows take-home devices off campus | Agent travels with device | With a roaming DNS profile |
There are legitimate single-layer deployments. Match the tool to the environment, not to a datasheet.
You need every device on the network covered — including guests and IoT — with minimal staff time; you are a small school or library without a dedicated network team; you want malware and phishing domains stopped before any connection opens; or you need a compliant technology protection measure live this week rather than this semester. Our CIPA DNS filter for education is built for exactly this profile.
Your policies need URL-level precision on mixed platforms; you must enforce SafeSearch across search and video; you report by student, not by IP address; different grade bands need genuinely different rules on the same sites; or your board expects search-term visibility for student-safety reviews. This depth belongs on the managed 1:1 fleet where an agent can live.
You run 1:1 devices and an open campus network — which describes most districts. DNS becomes the wide net over everything that touches your network; the web layer adds precision on school-issued devices where students actually spend their day.
You are considering deep inspection of personal staff or guest devices (a privacy and consent problem), or relying on DNS alone for high schoolers who know what a resolver is. Both are signs the layer is being stretched past what it is designed to do.
Nothing in the law names a specific technology layer. A well-run DNS filter and a full web filtering deployment can each serve as the required measure.
Should show outside resolvers are blocked and take-home devices carry the roaming profile.
Should explain how guest and unmanaged devices on school internet are handled.
What the certification cannot survive is a filter that exists on paper but not in traffic.
We cover the obligations in plain English in our guide to what CIPA is and how compliance works.
A DNS resolver and a web gateway both ask the same question first: what kind of site is this? Both of our layers answer it from one continuously refreshed classification of the web.
Choosing means knowing what you are giving up. These are the misses school IT teams actually run into, layer by layer.
Agent-based web filtering only exists where the agent does. Guest phones, personal laptops, smart TVs and IoT gear on school Wi-Fi are invisible to it — exactly the devices DNS covers for free.
Certificates, agent updates, exclusions for apps that dislike inspection — deep filtering carries real operational weight. Small IT teams feel this more than any license fee.
Browser-level filtering can miss traffic from installed apps, game clients and system services that never open a browser tab — connections a resolver-level check still sees.
A DNS filter must allow or block an entire domain. Big mixed platforms — video sites, forums, cloud hosts that serve thousands of apps from one name — force a blunt choice that either over-blocks instruction or under-blocks risk.
Once a domain resolves, DNS is out of the conversation. It cannot enforce SafeSearch, see the search terms a student typed, or notice that an allowed site is serving something it should not.
A student who switches the device to a public resolver, or a browser using encrypted DNS to a third party, routes around the filter entirely unless you also block outside resolvers and manage browser settings.
The order matters: the broad layer first, then precision where it pays off. Done this way, each stage delivers protection on its own.
Point district DHCP at the filtering resolver and block outbound DNS to other servers. Every device on campus — managed or not — now gets category-level protection against adult content, gambling, malware and phishing domains at the lookup.
Deploy the agent or browser controls to school-issued Chromebooks and laptops. This is where SafeSearch enforcement, per-URL decisions and per-student reporting switch on — for the devices where that depth is appropriate.
Apply a strict baseline for elementary buildings and progressively wider policies upward. Because domains carry multiple category labels, mixed sites get sensible defaults instead of blanket blocks.
A roaming DNS profile plus the on-device agent means the take-home hours are covered by the same policy as the classroom, which is where a large share of real incidents happen.
Use DNS logs for the network-wide picture and web-layer logs for per-student detail. Together they give an E-Rate audit trail neither produces alone, and they show you which exceptions and policy tweaks next term needs.
Districts that run our stack use the same 120-million-domain classification at the resolver and in the web layer. The practical benefit shows up in the paperwork: when the same site is "Gambling" in both systems, block pages, exception requests and audit reports all tell one story.
It also means the newest risks arrive in both layers at once — the AI-tool domains we track and the constantly churning malware and phishing infrastructure aimed at schools are classified daily and blocked at the lookup and in the session alike.
If budget forces a sequence rather than a bundle, start with DNS: it protects everything immediately, satisfies the certification, and costs the least to operate.
Add web-layer depth on the 1:1 fleet as the next budget cycle allows. See pricing for how the two layers are packaged.
A properly enforced DNS filter can serve as the required technology protection measure, because it blocks access to the prohibited categories before a connection is made. Compliance also requires an internet safety policy, monitoring of minors' online activity, and student education — so pair the technical control with those program pieces, and make sure devices cannot quietly switch to an outside resolver. Many small schools and libraries run compliant programs on DNS filtering alone.
Because of what a DNS query contains. The device asks only "what is the address of this domain?" — the path, page and query string are never part of the lookup. The resolver therefore has exactly one decision available: resolve the domain or don't. Anything finer than that — allowing a site's educational section while blocking another, or filtering individual videos — requires a layer that sees the URL after the connection is made.
It changes what each layer can see, not whether filtering works. Encryption hides page paths and content, but the domain being requested is still visible at the lookup, so DNS filtering is unaffected. For the web layer, per-URL and content decisions on encrypted sites require an on-device agent or trusted inspection on managed devices. That split — DNS for everything, deeper inspection only where the district manages the device — is exactly why layering became the standard design.
The known routes are switching the device to a public resolver, using encrypted DNS to a third party, or tunneling through a VPN. All three have standard countermeasures: block outbound DNS except to your resolver, manage browser DNS settings on school devices, and block the VPN and proxy categories in policy — our classification tracks those services as their own category. On managed devices, the web-layer agent adds a second check that keeps working even if DNS is redirected.
Not noticeably. The category check happens during name resolution and adds milliseconds to a step that already exists, and answers are cached afterward. Blocking at the lookup can actually reduce load, because connections to ad-heavy, malicious or disallowed sites are never opened at all. Web-layer inspection has a modest cost on the device or gateway doing the work, which is one reason it is usually scoped to managed hardware rather than the whole network.
Not with our approach. The resolver-level filter and the web-layer controls run from the same 120M+ domain classification and the same policy concepts, so layering is a deployment decision rather than a second procurement. Districts typically switch on DNS network-wide first, then enable the deeper controls for managed grade-band groups — one vendor, one category language, one set of reports.
Both can, and both should agree. Our AI-tools blocklist covers more than 16,000 AI-tool domains sorted into categories like essay writers, homework solvers and companion chat, and it plugs into the DNS layer as a blocklist and into web-layer policy as categories. DNS enforcement catches AI apps outside the browser; the web layer lets you allow a district-approved tool for seniors while blocking it for middle schoolers.
Tell us about your buildings, devices and current filter, and we'll show you what DNS-level and web-level policy would look like on your actual traffic — including AI tools and off-campus coverage.