DNS Filtering vs Web Filtering: What Each Can Block
Two ways to enforce the same internet policy, with different reach and different blind spots. Here is what each one sees, where each one fits, and how one category database can power both.
The two approaches in short
Both are forms of web filtering in the broad sense. The difference is where they sit and how much of each request they can read.
What is DNS filtering?
DNS filtering steps in when a device turns a name like shop.example.com into an address. The resolver checks the name against a policy, usually by category, and refuses lookups for blocked domains.
How does DNS filtering work?
- A device asks its resolver for the address of a domain.
- The resolver looks up the domain's categories.
- The policy for that network or client is applied.
- Allowed: the real address comes back. Blocked: a block answer comes back.
- The decision is logged with the category.
What is web filtering?
Web filtering in the narrower sense means URL filtering in a proxy, firewall, browser extension or agent. It sits in the path of the traffic itself and can read the full address, so it can treat two pages on one site differently.
How does URL-level filtering work?
- A browser or app opens a connection to a site.
- The filter reads the host name, and the full URL if it can.
- It looks up categories for the domain and the path.
- The policy decides: allow, block page, warn or limit.
- The decision is logged with the URL and category.
What is DNS blocking, exactly?
DNS blocking is the answer a DNS filter gives for a blocked name. There are three common styles, and the choice affects what users see.
NXDOMAIN"This name does not exist"
Clean and fast. The browser shows a generic error, so users may think the site is down.
0.0.0.0A dead-end address
The connection fails at once. Common in hosts files and home blockers.
Block page IPRedirect to a block page
Friendly for users on plain HTTP. On HTTPS sites the browser warns about the certificate unless one is trusted.
What each one sees: domain vs full URL
This is the single biggest difference between DNS filtering vs URL filtering. Take one request and look at the parts each layer can read.
A DNS filter knows that someone asked for forum.example.org. It cannot know which board they opened. If the forum is mostly about cooking but has one betting board, the DNS filter can only block or allow the whole forum.
A web filter that sees the path can allow the forum and block the betting board. That precision is the main reason organisations add a URL-level layer on top of DNS.
DNS filtering vs web filtering, side by side
| Question | DNS filtering | Web filtering (URL level) |
|---|---|---|
| Decision point | When the domain name is looked up | When the connection or request is made |
| Granularity | Whole domain or subdomain | Domain, path, query and sometimes page content |
| Device coverage | Everything that uses the resolver: laptops, phones, TVs, IoT | Traffic that passes the proxy, firewall, browser or agent |
| Setup effort | Low: change the resolver address | Medium to high: proxy settings, certificates or agents |
| Performance | Very light; lookups are cached | Heavier, especially with HTTPS inspection |
| Block experience | Often a browser error on HTTPS sites | A proper block page that names the category |
| Bypass risk | Other resolvers, encrypted DNS, VPNs, hard-coded addresses | VPNs and proxies; device agents are harder to bypass |
| Reporting | Domains and categories per network or client | Full URLs, users, time spent and categories |
| Typical buyers | ISPs, MSPs, schools, small businesses, home users | Enterprises, schools with managed devices, regulated sectors |
Neither is better in general. DNS filtering wins on reach and simplicity; web filtering wins on precision and reporting. Our overview of what is URL filtering covers the URL side in more depth.
What each can block: a practical matrix
Real policies come down to specific cases. Here is how the two layers handle the ones admins ask about most.
| Case | DNS filtering | Web filtering |
|---|---|---|
| An adult or gambling site | Yes, whole domain | Yes |
| A known malware or phishing domain | Yes, before any connection | Yes |
| A newly registered scam domain | Yes, if categorized on day one | Yes, same condition |
| One section of a large platform | No, all or nothing | Yes, if the path is visible |
| A file type, such as executables | No | Yes, with inspection |
| Explicit search results | Partly, by forcing safe search host names | Yes, by enforcing safe search parameters |
| Smart TVs, consoles and IoT devices | Yes, if they use the resolver | Usually not |
| Apps that ignore the system resolver | No | Sometimes, at the firewall |
| VPN and proxy services | Their websites and some endpoints | Websites, plus traffic patterns at a firewall |
Notice that the "Yes" answers on the DNS side all depend on one thing: the domain already has the right category when the lookup happens. The URL side has the same dependency, plus the extra reach of path rules. In both columns, the quality of the category data decides how many of these cases actually work in practice.
HTTPS, encrypted DNS and what changes
Nearly all web traffic is encrypted now. That changes what each layer can see, and it is the source of most confusion in the dns filtering vs web filtering debate.
HTTPS hides the path
Without inspection, a network filter sees the host name but not the page. It filters at domain level, just like DNS.
Inspection needs trust
Reading the full URL on the network means decrypting traffic, which needs a certificate installed on every managed device.
Encrypted DNS
Browsers and apps can send lookups over encrypted channels to public resolvers, skipping the network's DNS filter.
Hidden server names
Newer TLS features can hide the host name in the handshake, which pushes filtering toward DNS and the device itself.
Block pages break
A DNS redirect to a block page triggers a certificate warning on HTTPS sites unless the block page certificate is trusted.
The device is the answer
Agents and browser extensions see the URL before encryption, which is why managed fleets often filter on the device.
The practical response is to block the categories that enable bypass. Our VPN / Proxy / Anonymizers category includes public encrypted DNS resolvers and proxy services; see the VPN and proxy category.
When to combine DNS and web filtering
Most mature setups use both, with each layer doing what it does best. A layered design looks like this.
DNS alone is often enough when
- The network has many unmanaged devices
- The policy is mostly whole-site blocks
- Speed of rollout matters most
- You serve many small clients, as an ISP or MSP
Add a URL layer when
- You need rules for parts of large platforms
- Auditors want user-level reports
- Regulation asks for detailed controls
- Students or staff routinely find workarounds
Which layer fits which network
The right mix depends on who uses the network and which devices you control. These are sensible defaults for common environments.
| Environment | DNS filtering role | Web filtering role |
|---|---|---|
| School (CIPA) | Baseline for every device on campus: Adult, Gambling, Violence, Hate/Discrimination, VPN / Proxy / Anonymizers, Malware / Phishing / Suspicious | On managed student devices: path rules, safe search, AI / LLM Tools by grade, reports for safeguarding staff |
| Office | Security categories and adult content for all devices, including printers and phones | Firewall rules for File Sharing/P2P, Cloud Storage / File Hosting and user reports |
| Guest Wi-Fi | Usually the only layer: Adult, Malware / Phishing / Suspicious, File Sharing/P2P | Rarely used, since guest devices cannot trust an inspection certificate |
| Regulated | First line against phishing and new domains | Full URL logging, data-leak controls on storage and AI tools, inspection bypass for Online Banking and Health & Medicine |
| Home | Router or resolver presets by age | Device or browser controls for younger children |
Schools can read more in our guides to K-12 school web filtering and CIPA web filtering.
Common DNS filtering mistakes
Most failed DNS filter rollouts fail for the same handful of reasons. None of them are about the filter itself.
Leaving port 53 open
If devices can reach any outside resolver, anyone who changes a setting skips the filter. Allow DNS only to your resolver.
Ignoring encrypted DNS
Browsers can switch to encrypted lookups on their own. Disable it by policy on managed devices and block known endpoints.
Allowing all unknown domains
Fresh domains are where scams start. Use day-one categories and consider a rule for very young domains.
Blocking infrastructure
Blocking CDN, update or authentication hosts breaks unrelated sites. Keep CDN / Hosting / Infrastructure allowed.
No way to ask for access
Users who only see browser errors call the help desk. A block page or a simple request form saves time.
Never reading the logs
Category reports show bypass attempts and wrong labels early. Review them weekly at first.
How to test what each layer blocks
Before you trust a setup, test it from a normal user device on each network segment. This short routine catches most gaps.
When results look wrong, compare the category in your logs with our free web filter lookup before you add an override.
How the same category data powers both
Both layers ask the same question: what kind of site is this domain? So one category database can feed a resolver, a firewall and an agent, and every report uses the same labels.
One category file
120 million domains, 59 categories plus the IAB taxonomy, several ranked labels per domain, daily new-domain deltas.
Export formats are available to licensed customers. Our guides to blocklist formats and DNS filtering integration show how each one plugs in.
Why freshness matters more at the DNS layer
A DNS filter has no second chance: if a new phishing domain is unknown at lookup time, the connection goes through. We categorize about 300,000 newly registered domains every day and check each again after a week and after a month, because many sites add their real content later.
Deployment patterns for vendors
If you build filtering products, the layer you choose shapes how you use category data. These are the patterns we see most among licence holders.
ISP or telco resolver
Opt-in family filtering and malware protection for every subscriber, with category choices in a customer portal.
DNS, very high volumeMSP multi-tenant DNS
One resolver platform, a policy per client, and monthly reports by category.
DNS, many small tenantsNext-generation firewall
Domain categories for unencrypted decisions, path rules where inspection is on.
Network, URL levelSecure web gateway or SASE
Full URL policies for remote users, with category data in each point of presence.
Cloud proxyBrowser extension or agent
Full URL visibility on managed devices, with a local copy of the data for speed.
DeviceRouter and parental control
Compact category lists pushed to home devices, with age-based presets.
DNS or deviceVendors who sell more than one of these can license the data once for the group. See OEM licensing, our managed DNS filter notes, and ISP web filtering.
Privacy, logging and compliance
The two layers also differ in how much they record about people. That matters for data protection rules, works councils and school privacy policies.
DNS logs
- Record domains, not pages or search terms
- Often tied to a network or device, not a named person
- Easier to keep short and to anonymise
- Enough for security alerts and category trends
URL logs
- Record full addresses, which can reveal personal details
- Usually tied to a signed-in user
- Need clear retention rules and access controls
- Useful for investigations and safeguarding reviews
A common middle path is to log categories and domains for everyone, and keep full URLs only for flagged categories or for a short time. Check the guidance that applies to you; our compliance web filtering guide covers the main frameworks.
Frequently asked questions
What is DNS filtering?
A control that acts when a device looks up a domain name. The resolver checks the name against a policy, usually by category, and refuses or redirects lookups for blocked domains.
What is the difference between DNS filtering and web filtering?
DNS filtering sees only the domain and decides before a connection starts. Web filtering sees the full URL where it can, so it can act on individual pages.
What is DNS blocking?
The answer a DNS filter returns for a blocked name: "does not exist", a dead-end address, or a redirect to a block page.
Is DNS filtering enough on its own?
For many networks it is a strong first layer. It cannot act on parts of a site, and it needs bypass controls to stop other resolvers and VPNs.
Does DNS filtering work with HTTPS?
Yes. The lookup happens before encryption starts, so HTTPS does not hide the domain from the resolver. Block pages are the weak spot, because of certificate warnings.
Can one category database power both layers?
Yes. The same domain labels drive the DNS decision, and the web filter adds path rules where it sees the full URL. Try any domain in our domain lookup tool.
How is the data delivered?
As CSV, Parquet or JSON files that run in your own systems, with a lookup API and export formats such as RPZ for licensed customers. Starter database tiers start from $999; enterprise and OEM licences are quoted per deployment.
One database, every layer
Power your resolver, firewall and agent with the same 120 million categorized domains and the same 59 categories.
Tell us which layer you build and how many queries you handle.
License the database