What is DNS filtering and how does it block threats?

DNS filtering is a security control that checks every domain a device tries to look up against lists of known malicious, risky or unwanted sites, and refuses to give out the real IP address when there's a match. Instead of the genuine answer, the resolver returns an error such as NXDOMAIN, a null address such as 0.0.0.0, or the address of a block page. Because almost every connection on the internet starts with a DNS lookup, this stops malware calling home, phishing pages loading and users reaching blocked categories of content, often before a single packet is sent to the dangerous server.

DNS filtering is one of the cheapest and most effective layers of protection you can add to a home, school or business network, and it's widely used by governments for public sector networks. In this article you'll learn how DNS filtering works step by step, what kinds of threats it catches, the different ways to deploy it, how to test whether it's working, and the limitations you need to plan around.

How DNS Filtering Works

Normally, when a device wants to reach shop.example.com, it asks a recursive resolver for the IP address, and the resolver goes off and finds it. A filtering resolver adds one extra step before answering.

1. The query arrives: A device asks the resolver for login-update.example.net.
2. Policy check: The resolver looks up the domain, and often its parent domains, in its blocklists and category databases.
3. Decision: If the domain is allowed, the resolver resolves it as usual. If it's blocked, the resolver builds a different answer.
4. Response: The device receives either the real IP address or the blocked response.
5. Logging: The resolver records the query, the decision and the client that asked, which gives you visibility into what's happening on your network.

Because the check happens at the name level, it doesn't matter which application made the request. A browser, a mobile app, a script or a piece of malware all have to resolve a name before they can connect, and they all get the same filtered answer.

What a Blocked Response Looks Like

Filtering resolvers use a few different styles of response, each with trade-offs:

Response	What the device sees	Pros	Cons
NXDOMAIN	"This domain doesn't exist"	Clean, fast failure	Users get a confusing browser error
0.0.0.0 or ::	An address that goes nowhere	Fast failure, no network traffic	Looks like a broken site
Block page IP	A page explaining the block	Clear for users, can offer an appeal	HTTPS sites show a certificate warning
REFUSED	The resolver declines to answer	Simple	Some clients retry other resolvers

Block pages sound friendly, but because the resolver can't present a valid certificate for the blocked domain, HTTPS connections show a certificate error rather than the page. Many organisations install their own root certificate on managed devices to make block pages display cleanly. On unmanaged devices, NXDOMAIN or 0.0.0.0 is usually the less confusing option.

What DNS Filtering Can Block

Filtering services combine several types of data to decide what to block.

Threat Intelligence

The most valuable lists contain domains linked to active threats:

• Malware distribution: Domains hosting malicious downloads or exploit kits.
• Command and control (C2): Domains that infected machines contact for instructions. Blocking these can stop a compromise from turning into a breach, even after malware has run.
• Phishing: Fake login pages for banks, email providers and cloud services.
• Cryptojacking: Domains serving scripts that mine cryptocurrency in visitors' browsers.

These lists are fed by security vendors, honeypots, sandboxes that detonate malware samples, and shared feeds between organisations. They change constantly, which is why the filtering service needs to update in near real time.

Newly Registered and Algorithmically Generated Domains

Attackers often register a domain hours before a campaign starts. Many filtering services offer an option to block newly registered domains, typically those less than about 30 days old, because legitimate businesses rarely send customers to a brand-new domain. It catches a surprising amount of phishing.

Some malware uses domain generation algorithms (DGAs), which produce long lists of random-looking domains so the attacker only needs to register one of them. Filters use statistical models to spot names that look machine-generated, such as qx7v2kfp9tz.example.

Content Categories

Beyond security, DNS filtering is widely used to enforce acceptable-use policies. Typical categories include adult content, gambling, social media, streaming, file sharing and games. Schools use this to meet safeguarding obligations, and businesses use it to reduce distractions and legal risk.

Ads and Trackers

Home users often run filtering to block advertising and tracking domains. Tools such as Pi-hole and AdGuard Home are built around this use case, and the same mechanism that blocks ads also blocks many malicious domains.

Ways to Deploy DNS Filtering

You can apply DNS filtering at several points, and many organisations combine more than one.

Public Filtering Resolvers

The simplest option is to point your devices or router at a public resolver that filters for you. Some well-known examples:

• Quad9 (9.9.9.9): Blocks domains linked to malware and phishing using threat feeds from many security partners. It returns NXDOMAIN for blocked domains.
• Cloudflare for Families: 1.1.1.2 blocks malware, and 1.1.1.3 blocks malware and adult content. Blocked domains resolve to 0.0.0.0.
• Commercial services: Products such as Cisco Umbrella, Cloudflare Gateway, DNSFilter and NextDNS add per-user policies, categories, reporting and integrations with identity providers.

Public sector organisations in some countries get a government-run service, such as the NCSC's Protective DNS in the UK or CISA's Protective DNS for US federal agencies.

On-Premises Resolvers

If you run your own recursive resolver, such as BIND, Unbound, PowerDNS Recursor or Windows DNS Server, you can apply filtering locally. This keeps query data inside your network and lets you use your own lists. The standard mechanism for subscribing to commercial threat feeds on your own resolver is Response Policy Zones (RPZ), which lets a vendor publish blocking rules as a DNS zone your server downloads.

Endpoint Agents

Laptops leave the office. An endpoint agent installed on the device intercepts DNS locally and applies the organisation's policy wherever the device is, on home Wi-Fi or in a hotel. Most commercial filtering services offer one, and they're the only practical way to cover remote workers without a full-time VPN.

Home Routers and Appliances

Pi-hole and AdGuard Home run on a small computer such as a Raspberry Pi and act as the DNS server for your whole home network. Some home routers have filtering built in, or let you set a filtering resolver for all clients through DHCP.

Building a Simple Filter With Unbound

To see how simple the core idea is, here's a minimal filtering setup with Unbound. Unbound's local-zone directive lets you override answers for any domain and everything beneath it.

Create a file of blocked domains, /etc/unbound/blocklist.conf:

server:
    local-zone: "malware-download.example." always_nxdomain
    local-zone: "phish-login.example.net." always_nxdomain
    local-zone: "tracker.example.org." always_null

always_nxdomain returns "no such domain", and always_null returns 0.0.0.0 for A queries and :: for AAAA queries. Both apply to the domain and all of its subdomains.

Include the file from your main configuration, /etc/unbound/unbound.conf:

server:
    interface: 0.0.0.0
    access-control: 192.168.1.0/24 allow
    log-local-actions: yes
    include: "/etc/unbound/blocklist.conf"

log-local-actions logs every query that matches a local zone, so you can see which device tried to reach a blocked domain. Check and reload:

sudo unbound-checkconf
sudo systemctl reload unbound

In real use you'd generate the blocklist from a feed rather than writing it by hand. This short script converts a plain list of domains, one per line, into Unbound syntax:

#!/usr/bin/env python3
"""Convert a plain domain list into an Unbound local-zone blocklist."""
import re
import sys

DOMAIN = re.compile(r"^(?=.{1,253}$)([a-z0-9-]{1,63}\.)+[a-z]{2,63}$")

def main(src: str, dst: str) -> None:
    seen = set()
    with open(src) as infile:
        for line in infile:
            name = line.split("#", 1)[0].strip().lower().rstrip(".")
            if name and DOMAIN.match(name):
                seen.add(name)

    with open(dst, "w") as outfile:
        outfile.write("server:\n")
        for name in sorted(seen):
            outfile.write(f'    local-zone: "{name}." always_nxdomain\n')

    print(f"Wrote {len(seen)} domains to {dst}")

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

Run it with python3 build_blocklist.py domains.txt /etc/unbound/blocklist.conf, then run unbound-checkconf before reloading so a bad entry can't take your resolver down.

How to Test DNS Filtering

Once filtering is in place, check that it's actually being applied. Query a domain you've blocked:

dig @192.168.1.53 malware-download.example A

A blocked domain using always_nxdomain returns:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40112
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Compare filtered and unfiltered public resolvers to see how a service handles a domain. For example, Cloudflare's malware-blocking resolver versus its standard one:

dig @1.1.1.2 suspicious.example.com A +short
dig @1.1.1.1 suspicious.example.com A +short

If the first returns 0.0.0.0 and the second returns a real address, the domain is on Cloudflare's malware list. Most commercial services also publish test domains in their documentation that are always blocked, which is the safest way to confirm a policy without going anywhere near real malware.

On Windows, the same check works with PowerShell:

Resolve-DnsName -Name malware-download.example -Server 192.168.1.53 -Type A

A blocked domain produces a "DNS name does not exist" error.

Limitations of DNS Filtering

DNS filtering is powerful, but it's not a complete security solution. Knowing where it falls short helps you put the right controls around it.

Devices Can Bypass Your Resolver

Filtering only works if devices actually use your resolver. Common ways around it include:

• Hardcoded resolvers: Some apps and devices ignore DHCP settings and send queries straight to 8.8.8.8 or another public resolver.
• DNS over HTTPS: Browsers and apps can send encrypted DNS to their own provider over port 443, invisible to your network resolver.
• VPNs and proxies: Traffic inside a VPN tunnel uses the VPN's DNS.
• Direct IP connections: Malware that connects to an IP address without a lookup never touches DNS.

To close these gaps, block outbound DNS (UDP and TCP 53, and TCP 853) from everything except your resolver, use browser policies to disable or control DoH on managed devices, and use an endpoint agent where possible.

It Works at the Domain Level

DNS filtering sees docs.example.com, not the full URL. It can't block one malicious file on an otherwise legitimate site, such as a shared cloud storage link, without blocking the whole domain. For that, you need a secure web gateway or proxy that inspects URLs.

Lists Are Never Complete

A brand-new phishing domain may be live for hours before it appears on any list. Newly registered domain blocking helps, but nothing catches everything. DNS filtering reduces risk; it doesn't remove it.

False Positives

Overly aggressive lists block legitimate services, particularly CDNs and shared hosting. Have a clear process for users to report a wrongly blocked site, and an allowlist that takes priority over blocklists.

Best Practices

• Start in monitoring mode: Many services let you log matches without blocking. Review a week of data before enforcing.
• Use security categories first: Malware, phishing, C2 and newly registered domains give the most protection for the least disruption.
• Force all DNS through your resolver: Block outbound port 53 and 853 to the internet, except from the resolver itself.
• Watch the logs: Repeated lookups of C2 domains from one device are a strong sign of infection. DNS logs are one of the best early warning systems you have.
• Protect remote devices: Use an endpoint agent or a filtering service with per-device profiles.
• Combine with other layers: Keep endpoint protection, email filtering and patching in place. DNS filtering is one layer, not the whole stack.

---

FAQ: DNS Filtering

---

Conclusion

DNS filtering works by checking every domain lookup against threat intelligence and policy lists, and refusing to hand out the real address when a domain is dangerous or unwanted. Because nearly every connection starts with DNS, that single check stops a large share of phishing, malware downloads and command-and-control traffic, and it gives you valuable logs of what your devices are trying to reach.

It's easy to start: point your network at a filtering resolver, or add a blocklist to your own. To make it effective, force all DNS through that resolver, handle encrypted DNS and remote devices, and treat it as one layer among several rather than a complete defence.