A user clicks a link, a script on a compromised website fires, and the machine quietly asks the network a question: what is the address for this domain? If an answer comes back, the connection is made and the payload starts to arrive. DNS filtering works at that exact moment, between your devices and the internet's naming system, deciding which names deserve an answer. Done well, it stops a large share of commodity attacks before a single byte of malware reaches the endpoint.
How DNS filtering actually works
Every time a device contacts something on the internet by name, it asks a resolver to translate that name into an IP address. Normally that resolver is your router, your ISP, or a public service, and it answers almost anything it is asked. A filtering resolver still answers, but it checks the name first.
If the domain appears on a blocklist, matches a blocked category, or has been flagged by threat intelligence, the resolver returns something harmless instead of the real address — a "no such domain" response, a null address like 0.0.0.0, or a redirect to a local block page explaining what happened. Because no valid address is returned, the device never opens the connection. Nothing downloads, so nothing needs cleaning up.
There are two common places to put that filtering:
- In the cloud. You point your router or devices at a filtering resolver such as Quad9, NextDNS, or a similar service. Setup takes minutes, and filtering follows the device even on other networks.
- On your own network. You run a local resolver such as Pi-hole or AdGuard Home on a small always-on machine or a container. You control the lists, the logs, and the rules, but you also own the maintenance.
Blocklists, categories, and reputation
These are not the same thing. A blocklist is a static list of known-bad domains. Category filtering blocks whole subjects — gambling, adult content, newly registered domains — which is useful for a shared office or a family network. Reputation feeds look at behaviour: a domain registered yesterday, hosted on infrastructure used for phishing last week, and receiving traffic from thousands of freshly infected hosts. Combining all three catches more, but it also raises the risk of blocking something you actually need.
What DNS filtering catches well
The technique is strongest against threats that need to announce themselves by name:
- Malware command-and-control domains, where an infected host checks in for instructions.
- Phishing pages on domains that are already known to be malicious.
- Ransomware delivery domains and fake update pages.
- Cryptomining and ad-fraud domains, which often overlap with malware infrastructure.
- Trackers and telemetry, if you care about that — a useful side effect, not a security control.
- Malicious redirects from search results or malvertising on otherwise ordinary websites.
In each case, the block happens before the connection, which means no exploit code, no drive-by download, and no user prompt to click through.
What it cannot do
DNS filtering is a checkpoint, not a wall. It only sees name lookups, and plenty of attacks skip that step entirely.
- Direct IP connections. Malware that already knows its destination address never asks for a name.
- Compromised legitimate domains. If attackers plant a malicious file on a file-sharing service or a legitimate website, the domain itself looks fine and the lookup is allowed.
- Anything already on the device. An infection that arrived by USB, email attachment, or a supply-chain compromise is past this layer.
- Encrypted DNS bypassing your resolver. A browser or app using its own DNS-over-HTTPS endpoint can simply ignore the resolver you configured.
- Brand-new phishing domains. If nobody has reported the domain yet, no list will know about it.
The encryption blind spot
DNS-over-HTTPS and DNS-over-TLS are genuinely good for privacy, and genuinely annoying for a network administrator. If a browser is set to use its own encrypted resolver, your filtering never sees the query. In practice you handle this with device management, browser policy, or by enforcing encrypted DNS to a resolver you trust — not by trying to break encryption on the wire.
Choosing an approach for a home or small office
For most small networks, the cloud option wins on simplicity. You change the DNS servers in your router's WAN settings, and every device that uses the router's resolver is covered. A filtering service with per-device profiles is worth the small monthly cost if you want different rules for staff laptops, guest Wi-Fi, and kids' tablets.
Run a local resolver if you want full visibility: query logs, your own lists, and no dependency on a third party seeing your traffic. Budget an hour for the first setup and a few minutes a month afterwards. Put it on hardware that stays on, and give it a static address so a DHCP change does not silently break internet access for the whole office.
Setting it up, step by step
- List the devices and decide who gets strict filtering and who gets the light touch. Guest networks can be stricter with no complaints.
- Pick a filtering resolver, or install a local one and note its IP address.
- Set that address as the DNS server in your router. Change it in both the WAN settings and, if available, the DHCP settings so clients are told to use it.
- Enable logging and keep the log for at least a couple of weeks. You will need it to diagnose what broke and to spot a device making odd requests.
- Test before you trust it. Visit a known test domain from a filtering provider's own test page to confirm blocking is active, then check that ordinary browsing, video calls, and printing still work.
- Add an endpoint layer. Antivirus or endpoint protection still matters, because DNS filtering stops lookups and nothing else.
Tuning out false positives
Aggressive lists break things. Expect a first week of small surprises: a payment processor, a school portal, a video doorbell that phones home to a domain someone flagged. Keep an allowlist and add entries as they come up, but write down why. A long undocumented allowlist eventually defeats the point.
Check your logs for patterns rather than one-off blocks. A single device making hundreds of lookups to newly registered domains at 3 a.m. is more interesting than any individual entry on a blocklist. Also review your lists periodically: overlapping feeds cause duplicate effort, and stale lists block domains that changed ownership years ago.
A practical starting point
If you want a sensible default this week: point your router at a reputable filtering resolver, keep a light category policy that blocks known malware and phishing rather than half the internet, turn logging on, and run endpoint protection alongside it. That combination handles the everyday threats most small networks actually face — a malicious link in an email, a bad redirect, an ad network serving something nasty.
Then revisit it. Filtering is not a one-time install. Add devices, check the logs, allowlist what your business genuinely needs, and treat every alert as a question to answer. A quiet DNS log is not proof you are safe. It is proof that the first checkpoint is doing its job.
Photo: Al Nahian / Pexels
