What Is DNS Filtering? How It Blocks Threats Before the Browser Loads
What DNS filtering is, how a filtering resolver decides what to block, where to deploy it, how encrypted DNS, VPNs and hardcoded resolvers get around it, and how to roll it out across a small fleet.
Updated: October 2026
Before a browser loads a page, it asks a DNS resolver where that page lives. Whoever answers that question can refuse to give a bad address, and the page never loads. That's the whole idea behind DNS filtering, and this guide covers how it works, how people get around it, and how to roll it out across a small company's devices.
What Is DNS Filtering?
DNS filtering is blocking at the lookup step. Every connection starts with a name, like example.com. The device asks a resolver for the matching IP address, and only then connects.
A filtering resolver checks each name against a policy before it answers. Allowed names get a normal answer. Blocked names get a refusal, a fake "no such domain" reply, or the address of a block page. The browser never reaches the real server, so nothing downloads.
That makes it cheap and fast. There's no proxy in the traffic path and no certificate on every laptop. The check happens on a query that was going to happen anyway.
How a DNS Filter Decides What to Block
The resolver compares the requested name with lists it keeps up to date. There are three kinds of list, and filtering services combine them.
Threat feeds cover domains tied to phishing, malware delivery and command-and-control servers. They change constantly, and the provider maintains them. Categories cover content types: gambling, adult sites, file sharing, social media. You choose which categories to block. Your own allow and block lists sit on top and win over both.
Filtering services often add a rule for newly registered domains, blocking names in their first days of life. Phishing kits tend to use fresh domains, so this catches campaigns before any feed lists them. It also catches the new vendor portal your finance team needs on Monday, so plan an allowlist process.
A DNS filter only sees domain names. It can't match keywords in a page or a URL path. A category rule for "file sharing" works because the provider has already sorted the domain, not because it reads the page.
The answer to a blocked lookup comes in three forms. A block page tells the user what happened and who to ask, which cuts helpdesk confusion. NXDOMAIN, the "domain doesn't exist" reply, fails quietly. A sinkhole returns an address you control, so you can log which device tried to reach a known-bad domain.
This r/sysadmin thread is a useful sanity check on expectations. The top reply says DNS filtering "should be part of a defence in depth strategy", not the whole strategy.
Where to Deploy It: Network, Device or Both
There are two places to point devices at a filtering resolver, and a small company usually needs both.
At the network level, you set the filtering resolver as the forwarder on your internal DNS servers, or hand it out through DHCP on the router. Every device in the office is covered on day one, including printers and guest phones. The catch is that it stops at the office door.
On the device, a small roaming agent sends lookups to the filtering service from wherever the laptop is: home Wi-Fi, a hotel, a phone hotspot. Policy follows the device. For a team that works from home half the week, this is the part that does the work.
The same idea runs at government scale. CISA set up its Protective DNS Resolver in 2022 as a mandatory service for federal civilian agencies, and it describes the job plainly: "preventing network traffic from reaching destinations that could be malicious." Commercial services sell the same protection to everyone else, with a console on top.
Commercial options include Cisco Umbrella, DNSFilter, Cloudflare Gateway, Control D and Quad9 as a free resolver with threat blocking. Self-hosted options include Pi-hole, AdGuard Home and Technitium for a single office. Compare them on roaming-agent support, reporting, allowlist workflow and how quickly the threat feed updates.
How Users Get Around It, and How to Close Each Gap
A DNS filter only works on lookups it can see. Four routes skip it.
Encrypted DNS in the browser is the one that surprises people. DNS over HTTPS (DoH) sends lookups inside normal HTTPS traffic to a public resolver, so your filter never sees them. In Chrome, the DnsOverHttpsMode policy controls this, and Google's policy text says that when it's unset "for managed devices DNS-over-HTTPS queries will not be sent." Set it to off on managed browsers anyway, so the behavior is written down.
Firefox checks a canary domain, use-application-dns.net. If your resolver answers it with NXDOMAIN, Firefox keeps its default DoH off on that network. Mozilla's own note is the catch: "If a user has chosen to manually enable DoH, the signal from the network will be ignored." Enterprise policy is the real switch.
DNS over TLS (DoT) uses TCP port 853. Block outbound 853 at the firewall unless you run a DoT resolver yourself.
Hardcoded resolvers are the second route. Some apps and devices ignore DHCP and ask 8.8.8.8 or 1.1.1.1 directly. Allow outbound port 53 only from your own DNS servers or the filtering service, and drop the rest. A stateful firewall handles those outbound rules without breaking the replies.
VPNs, proxies and relay services are the third. A personal VPN tunnels everything, lookups included. Apple's iCloud Private Relay does something similar for Safari. Block known VPN and relay endpoints by category, and block app installs on managed devices.
Going straight to an IP address is the fourth, and DNS filtering can't stop it by design. There's no lookup to refuse. A firewall or proxy has to handle that one.
In this r/sysadmin thread, an admin inherits a Cisco Umbrella deployment full of encrypted DNS traffic. The fix they landed on matches the list above: block DoH at the filter, block outbound TCP 853, and turn off DoH in browser policy.
What DNS Filtering Can't See
DNS filtering works on names, so its blind spots follow from that.
It can't see the path after the domain. If a phishing page sits on a shared cloud storage domain you allow for real work, the filter lets it through. It can't inspect content, so a malicious file on an allowed site downloads fine. It sees nothing on connections made straight to an IP address.
That's why it sits beside other layers, not instead of them. Email security stops the link from arriving. Endpoint protection catches the file that lands anyway. Our MSP security stack breakdown shows where DNS filtering fits among them.
What it does well is stop the click that already happened. A user who opens a phishing email and taps the link gets a block page instead of a login form. Our guide to what malware is covers what happens when that click lands somewhere unfiltered.
Rolling Out DNS Filtering Across a Small Fleet
A rollout goes smoothly when users barely notice it. This order keeps the tickets low:
- Find every resolver in use. Check DHCP scopes, internal DNS forwarders and any device with static DNS set.
- Start in monitor mode. Log without blocking for a week, then read what would have been stopped.
- Pick categories with the business. Threat categories are yours to decide. Content categories like social media are a management call.
- Set up the allowlist path first. Decide who approves exceptions and how fast, and put a contact on the block page.
- Deploy the roaming agent to laptops. Network-level filtering alone misses remote work.
- Lock the bypasses. Push browser DoH policies, block outbound TCP 853, and limit outbound port 53 to your resolvers.
- Test it. Filtering services usually publish a test domain that should always be blocked. Try it from a laptop on home Wi-Fi.
To check where devices send their lookups, run Get-DnsClientServerAddress on each Windows machine. In OpenFrame, you can run that as a script across a client's devices and collect the output in one place, so a laptop still pointed at 8.8.8.8 stands out. If lookups fail outright after the change, our guide to DNS server not responding walks through the fixes.
This short explainer from an IT services team covers the basics in plain terms, which makes it a good share for the managers approving categories.
The Short Version
DNS filtering blocks bad sites at the lookup step, before anything loads. It uses threat feeds, categories and your own lists, and it's cheap to run across every device. Deploy it on the network and on laptops, then close the four bypasses: encrypted DNS, hardcoded resolvers, VPNs and direct IPs. Treat it as one layer. It stops the click, while email security and endpoint protection handle what comes before and after.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.