Learn/ Docs/ Security/ Dns Filtering

security

DNS Filtering and Blocking

How DNS is used as a security layer — from enterprise threat blocking to network-wide ad filtering

The simplest firewall is a DNS server

DNS filtering exploits a fundamental property of the internet: before your device can connect to anything, it must first ask DNS where to find it. If the DNS resolver refuses to answer — or answers with a dummy address — the connection never happens. No software to install on every device, no browser extension to manage, no traffic inspection. The query arrives, the resolver checks a list, and malicious or unwanted domains are silently blocked.

This makes DNS the internet’s most scalable filtering layer. A single filtering resolver protects every device on a network — phones, laptops, smart TVs, IoT sensors, game consoles — without any per-device configuration.

How DNS filtering works

DNS filtering intercepts the query-response cycle at the resolver level:

Device → DNS Query: "ads.tracker.com" → Filtering Resolver

                                         Check blocklist

                                         Match found?
                                        /           
                                      Yes            No
                                       ↓              ↓
                               Return 0.0.0.0    Forward to
                               (sinkhole)      authoritative

                                              Return real IP

When a blocked domain is queried, the resolver typically returns one of:

  • 0.0.0.0 or 127.0.0.1 — a “sinkhole” that causes the connection to fail immediately
  • NXDOMAIN — tells the client the domain doesn’t exist
  • A custom IP — pointing to a block page that explains why access was denied

The blocklist is the core of any DNS filtering system. Lists are maintained by the community, security vendors, and the filtering providers themselves. A typical blocklist contains tens of thousands to millions of domains categorized by type: advertising, tracking, malware, phishing, adult content, gambling, and more.

Consumer DNS filtering

Pi-hole

Pi-hole is an open-source DNS sinkhole that runs on a Raspberry Pi (or any Linux device) and blocks ads and trackers for every device on the network. With over 50,000 GitHub stars, it is one of the most popular network projects on GitHub.

Pi-hole works by acting as the DNS server for your local network. All DNS queries pass through it, and queries matching the blocklist are sinkholed. The result: ads disappear from smart TVs, mobile apps, and IoT devices — places where browser-based ad blockers cannot reach.

Pi-hole includes a web dashboard showing query statistics, top blocked domains, and per-device query logs. It is often paired with Unbound as an upstream recursive resolver for full DNS privacy — queries are resolved locally rather than forwarded to a third-party resolver.

AdGuard Home

AdGuard Home is a cross-platform alternative to Pi-hole, written in Go. It provides similar DNS filtering with some notable differences:

FeaturePi-holeAdGuard Home
DNS over HTTPSRequires additional setupNative support
DNS over QUICNoYes
Per-device controlsManual configurationBuilt-in
PlatformLinux onlyLinux, macOS, Windows, ARM
Parental controlsManualBuilt-in per-device

NextDNS

NextDNS is a cloud-hosted DNS filtering service that provides Pi-hole-like functionality without running your own hardware. It supports DoH, DoT, and DoQ, and offers configurable blocklists with a generous free tier.

NextDNS sits in an interesting middle ground — it provides the convenience of a public resolver with the customization of a self-hosted solution.

Enterprise DNS security

Enterprise DNS filtering goes beyond ad blocking. Products like Cisco Umbrella (formerly OpenDNS), Cloudflare Gateway, and Infoblox BloxOne Threat Defense use DNS as the first line of defense against malware, phishing, and data exfiltration.

Threat intelligence integration

Enterprise DNS security platforms integrate threat intelligence feeds that identify malicious domains in real time:

Threat typeHow DNS filtering helps
Malware command and control (C2)Blocks communication between infected devices and attacker infrastructure
PhishingPrevents users from reaching fake login pages
Domain generation algorithms (DGAs)Detects and blocks randomly generated domains used by botnets
DNS tunnelingIdentifies suspicious query patterns that indicate data exfiltration through DNS
Newly registered domainsBlocks or flags domains registered within the last 24–72 hours (many malicious domains are used briefly and discarded)

Quad9 blocks over 100 million malware and phishing queries per day using integrated threat intelligence, making it a free alternative for users who want basic threat protection without enterprise products.

Response Policy Zones (RPZ)

RPZ, invented by Paul Vixie in 2010, is the standard mechanism for implementing DNS-based security policies in resolver software. An RPZ is a specially formatted DNS zone that contains policy rules — essentially a DNS-native blocklist format.

When a query matches an RPZ rule, the resolver can:

  • Return NXDOMAIN (block the domain)
  • Return a specific IP (redirect to a walled garden)
  • Pass the query through (log-only mode)
  • Redirect to a different domain

RPZ is supported by BIND, Unbound, PowerDNS, Knot Resolver, and most enterprise DNS platforms. It allows organizations to subscribe to threat intelligence feeds distributed as DNS zones, which update automatically through zone transfers.

DNS-based content filtering by governments

DNS filtering is also used at the national level for censorship and content regulation. ISPs in many countries are required to block access to specific categories of content — typically gambling, piracy, and adult material — by configuring their DNS resolvers to return false responses for targeted domains.

The effectiveness of government DNS filtering depends on whether users can easily switch to alternative resolvers. In most countries, switching to Google 8.8.8.8 or Cloudflare 1.1.1.1 bypasses ISP-level DNS filtering entirely. This is why some governments have moved beyond DNS filtering to IP-level blocking or deep packet inspection.

Encrypted DNS (DoH in particular) complicates government DNS filtering because DoH queries are indistinguishable from regular HTTPS traffic. Blocking DoH would require blocking all HTTPS traffic — which is not feasible for a functioning internet.

The DNS security market

The DNS security solutions market reached approximately $1.05–1.12 billion in 2024 and is projected to reach $2.31 billion by 2033 at a 9.1% compound annual growth rate. The DNS-over-HTTPS market alone is valued at $1.64 billion (2024), projected to reach $8.08 billion by 2033 at 18.7% CAGR.

These numbers reflect the growing recognition that DNS is not just infrastructure — it is a security control plane. Every connection starts with DNS, which makes DNS the natural place to enforce the first layer of security policy.

Limitations of DNS filtering

DNS filtering is not a complete security solution:

  • IP-based access bypasses DNS. If a user or application connects directly to an IP address instead of resolving a domain name, DNS filtering is never consulted.
  • Encrypted DNS can bypass the filter. If a device uses DoH to an external resolver (like Firefox’s default Cloudflare DoH), enterprise DNS filters on the local resolver are bypassed.
  • Over-blocking is common. Blocklists contain false positives. A domain hosting both legitimate content and a single malicious page may be entirely blocked.
  • Sophisticated malware uses evasion techniques. Domain generation algorithms (DGAs) create thousands of random domains, only a few of which are active at any time. DNS tunneling encodes data in query names, using DNS as a covert communication channel.

Despite these limitations, DNS filtering remains one of the highest-value, lowest-effort security controls available. It stops the majority of commodity threats — phishing, ad-delivered malware, known C2 domains — before they can establish a connection.