What is a DNS firewall and do you need one?

A DNS firewall is a recursive resolver that enforces security rules on DNS traffic, blocking, rewriting or logging lookups for domains, IP addresses and nameservers that match a policy. Where a network firewall decides which packets can pass based on addresses and ports, a DNS firewall decides which names your devices are allowed to resolve, and what answer they get when a name is dangerous. Most businesses benefit from one, because it stops a large share of malware and phishing cheaply and gives you visibility of every domain your devices try to reach. Small homes can get most of the same benefit from a filtering public resolver, without running anything themselves.

The term is used for both commercial products and for the open mechanism most of them are built on, Response Policy Zones (RPZ). In this article you'll learn what makes a DNS firewall different from plain DNS filtering, how RPZ triggers and actions work, how to build a DNS firewall with BIND, how to stop devices bypassing it, and how to decide whether you need one.

What a DNS Firewall Does

A DNS firewall sits where your normal recursive resolver sits. Every query from your network passes through it, and for each one it can:

• Allow the lookup and return the real answer.
• Block it, returning NXDOMAIN or an empty answer.
• Redirect it to a different address, such as a block page or a sinkhole server.
• Drop it silently, so the client gets no response.
• Log it, along with which client asked and which rule matched.

What makes it a firewall, rather than just a blocklist, is the depth of the rules. A DNS firewall can act not only on the name being looked up, but also on the IP addresses in the answer, and on the nameservers that serve the domain. That lets it catch threats that a simple domain blocklist misses.

DNS Firewall Versus Network Firewall

	Network firewall	DNS firewall
Works on	IP addresses, ports, protocols	Domain names, answer IPs, nameservers
Decision point	Every packet or connection	Every DNS lookup
Strength	Controls all traffic, including direct IP connections	Stops connections before they start, with clear names in logs
Weakness	IP-based rules break when attackers move servers	Can be bypassed if devices don't use the resolver
Typical rules	"Allow TCP 443 from LAN to anywhere"	"Block any domain hosted on these nameservers"

The two complement each other. In fact, the network firewall is what makes a DNS firewall hard to bypass, as you'll see later.

How Response Policy Zones Work

Response Policy Zones (RPZ) were designed by Paul Vixie and ISC and first shipped in BIND in 2010. RPZ expresses firewall rules as an ordinary DNS zone. Each record's owner name describes what to match (the trigger), and its data describes what to do (the action).

Because policy is just a zone, it can be distributed with standard zone transfers. Threat intelligence vendors publish RPZ feeds, your resolver pulls them as a secondary zone, and updates arrive within minutes using NOTIFY and incremental transfers. RPZ is supported by BIND, Unbound, PowerDNS Recursor, Knot Resolver and many commercial DNS appliances.

RPZ Triggers

Trigger	Owner name format	Matches
QNAME	bad.example.rpz.local.	The name being queried
Response IP	32.10.113.0.203.rpz-ip.rpz.local.	An address in the answer, here 203.0.113.10/32
NSDNAME	ns1.badhost.example.rpz-nsdname.rpz.local.	A nameserver name for the queried domain
NSIP	24.0.113.0.203.rpz-nsip.rpz.local.	A nameserver address, here 203.0.113.0/24
Client IP	24.0.100.51.198.rpz-client-ip.rpz.local.	The client making the query, here 198.51.100.0/24

IP triggers are written as the prefix length followed by the address octets in reverse order. The response IP and NSDNAME triggers are especially useful. Attackers register new domains constantly but tend to reuse the same hosting and the same rogue nameservers, so blocking the infrastructure catches domains no list has seen yet.

RPZ Actions

Action	Record data	Result for the client
NXDOMAIN	CNAME .	"This domain doesn't exist"
NODATA	CNAME *.	The name exists but has no records of that type
PASSTHRU	CNAME rpz-passthru.	Normal answer, used for allowlisting
DROP	CNAME rpz-drop.	No response at all
TCP-only	CNAME rpz-tcp-only.	Forces the client to retry over TCP
Local data	A 192.0.2.66 or CNAME block.example.com.	A replacement answer, such as a block page

Building a DNS Firewall With BIND

Here's a working setup for a BIND 9.18 or later recursive resolver, with a local policy zone for your own rules and a subscribed feed from a provider.

Step 1: Create a Local Policy Zone

Create /etc/bind/db.rpz.local:

$TTL 300
@       IN SOA  localhost. hostmaster.localhost. (
                2026102001 ; serial
                3600       ; refresh
                600        ; retry
                86400      ; expire
                300 )      ; minimum
        IN NS   localhost.

; Allowlist: a partner domain that a feed wrongly blocks
portal.partner.example.net      CNAME rpz-passthru.

; Block a phishing domain and all of its subdomains
phish-login.example             CNAME .
*.phish-login.example           CNAME .

; Send a malware domain to an internal block page
malware-cdn.example             A     192.0.2.66
*.malware-cdn.example           A     192.0.2.66

; Block any answer that points at a known bad host
32.10.113.0.203.rpz-ip          CNAME .

; Block every domain served by a rogue nameserver
ns1.bulletproof.example.rpz-nsdname  CNAME .

Note that a rule for phish-login.example doesn't cover its subdomains on its own, which is why the wildcard line is needed.

Step 2: Enable RPZ in named.conf

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-recursion { 127.0.0.1; 192.168.0.0/16; };

    response-policy {
        zone "rpz.local";
        zone "rpz.feed.example" policy given;
    } qname-wait-recurse no;
};

zone "rpz.local" {
    type primary;
    file "/etc/bind/db.rpz.local";
    allow-query { none; };
};

zone "rpz.feed.example" {
    type secondary;
    primaries { 198.51.100.20; };
    file "/var/cache/bind/db.rpz.feed.example";
    allow-query { none; };
};

logging {
    channel rpz_log {
        file "/var/log/named/rpz.log" versions 5 size 20m;
        print-time yes;
        severity info;
    };
    category rpz { rpz_log; };
};

A few details are worth understanding:

• Order matters: Policy zones are checked in the order listed, and the first match wins. Putting your local zone first means its rpz-passthru allowlist entries override the feed.
• policy given: Uses the actions as written in the zone. You can override this, for example with policy nxdomain to force every feed match to return NXDOMAIN regardless of what the vendor specified.
• qname-wait-recurse no: Lets BIND apply QNAME rules without first resolving the name, which is faster and avoids contacting attacker infrastructure. Response IP and nameserver triggers still need recursion to work.
• allow-query { none; }: Stops clients reading your policy zones directly.
• Feeds: The secondary zone's name and primary server address come from your feed provider, who will also usually require TSIG keys to authenticate the transfer.

Check and load the configuration:

sudo named-checkzone rpz.local /etc/bind/db.rpz.local
sudo named-checkconf
sudo rndc reload

Step 3: Test the Rules

dig @127.0.0.1 www.phish-login.example A

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

The authority section contains the SOA of rpz.local, which tells you the answer was rewritten by policy rather than coming from the real domain. Your RPZ log records the match:

sudo tail -f /var/log/named/rpz.log

20-Oct-2026 10:14:02.511 client @0x7f3a 192.168.1.40#51515 (www.phish-login.example): rpz QNAME NXDOMAIN rewrite www.phish-login.example/A/IN via www.phish-login.example.rpz.local

That single line tells you which device, which domain and which rule, which is exactly what an incident responder needs.

Stop Devices Bypassing the DNS Firewall

A DNS firewall only protects devices that use it. Malware, misconfigured devices and some apps send DNS directly to public resolvers. Use your network firewall to make your DNS firewall the only way out.

On a Linux router using nftables, this ruleset allows DNS and DNS over TLS only from the resolver at 192.168.1.53:

table inet dns_egress {
    chain forward {
        type filter hook forward priority 0; policy accept;

        ip saddr 192.168.1.53 udp dport 53 accept
        ip saddr 192.168.1.53 tcp dport { 53, 853 } accept

        udp dport { 53, 853 } counter drop
        tcp dport { 53, 853 } counter drop
    }
}

Load it with sudo nft -f dns-egress.nft and check the counters with sudo nft list table inet dns_egress. Non-zero drop counters show you devices trying to bypass your resolver, which is worth investigating in itself.

DNS over HTTPS is harder, because it runs on port 443 alongside normal web traffic. Handle it in layers:

• On managed devices, set browser policies that disable DoH or point it at your own resolver.
• Firefox checks a canary domain, use-application-dns.net, and disables its automatic DoH if your resolver returns NXDOMAIN for it. You can add it to your local RPZ zone: use-application-dns.net CNAME .
• Block known public DoH endpoints by name in the DNS firewall, and by IP on the network firewall, using a maintained list.

Do You Need a DNS Firewall?

Whether you need one depends on how many devices you're responsible for and what you'd lose if one were compromised.

Situation	Recommendation
Home or very small office	Use a filtering public resolver such as Quad9 or Cloudflare for Families. No need to run your own.
Small business with no IT team	A cloud DNS security service with simple policies and remote device agents.
Business with an IT team and on-site resolvers	A DNS firewall on your existing resolvers using RPZ feeds, or a commercial protective DNS service.
Regulated or high-risk organisation	A DNS firewall with commercial threat feeds, full logging into your SIEM and enforced egress rules.
Schools and public sector	A protective DNS service, often provided or recommended by government or education networks.

Signs You'd Benefit

• You have more devices than you can individually monitor.
• Staff regularly receive phishing email.
• You have no central record of which domains your devices contact.
• You've had a malware incident and couldn't tell which machines were affected.
• You run your own DNS servers already, so adding RPZ is a small step.

When It's Not Enough

A DNS firewall doesn't inspect content or full URLs, can't stop direct-to-IP connections, and only knows about threats its feeds know about. It sits alongside endpoint protection, email security, patching and a network firewall. Its strengths are that it's cheap, it acts before a connection is made, and its logs are unusually easy to read.

Practical Tips

• Start with log-only rules: In BIND, a policy zone can be added with policy disabled, which logs matches without enforcing them. Review the logs, then enforce.
• Keep an allowlist: Put your own passthru zone first so you can fix false positives in minutes.
• Use short TTLs on rewritten answers: Mistakes then clear from client caches quickly.
• Watch for feed failures: If a feed's zone transfer fails, the zone eventually expires and stops protecting you. Monitor the zone serial and transfer status.
• Alert on high-value matches: A command-and-control match deserves a ticket, not just a log line.

---

FAQ: DNS Firewalls

---

Conclusion

A DNS firewall applies security policy to the lookups your devices make, blocking, redirecting or logging answers for dangerous names, IP addresses and nameservers. Response Policy Zones make this practical on standard resolvers such as BIND and Unbound, and let you subscribe to threat feeds that update automatically.

If you're responsible for more than a handful of devices, a DNS firewall is one of the best value controls you can add, as long as you also block outbound DNS so it can't be bypassed. If you're protecting a home, a filtering public resolver gets you most of the benefit without running anything at all.