What Is a DNS Firewall?

Nearly every cyberattack touches DNS at some point. Phishing links need to resolve, malware needs to find its command-and-control server, and ransomware often checks in with an external domain before it encrypts anything. That makes your recursive resolver one of the best places in the network to stop an attack early, before a single packet reaches the malicious server. A DNS firewall is the technology that turns the resolver into that enforcement point. This article explains what a DNS firewall is, how Response Policy Zones (RPZ) work, how to deploy one on BIND, Unbound, Windows Server, and AWS, and how to make sure clients cannot simply route around it. It assumes you know the role of a DNS resolver and focuses on organizations running their own resolver infrastructure.

What Is a DNS Firewall?

A DNS firewall is a policy layer on a recursive resolver that inspects every query and, when a query or its answer matches a rule, returns a modified response instead of the real one. Typical actions are to block the lookup, redirect it to an internal warning page, or simply log it.

The key difference from a traditional firewall is the layer it works at. A network firewall filters by IP address and port. A DNS firewall filters by name, and optionally by the IP addresses or name servers that appear in the answer. Because attackers rotate IPs constantly but often reuse domains and name server infrastructure, name-based policy catches a lot of activity that IP blocklists miss.

DNS firewalls are a resolver-level control that your organization operates and tunes. That distinguishes them from consumer and small-business DNS filtering services, which are usually hosted resolvers with pre-built category blocking. The underlying idea is similar, but a DNS firewall gives you direct control over the policy, the threat feeds, and the logs.

How Response Policy Zones (RPZ) Work

The most widely used DNS firewall standard is Response Policy Zones, originally developed by ISC and Farsight and now supported by BIND, Unbound, Knot Resolver, PowerDNS Recursor, and many commercial products. The design is elegant: policy rules are written as ordinary DNS records in a special zone, which means they can be distributed and updated with the normal zone transfer machinery.

Each RPZ record has two parts: a trigger (what to match) and an action (what to do).

RPZ Triggers

Trigger	Matches	Example owner name in the RPZ zone
QNAME	The name being queried	bad.example.net
Response IP	An address returned in the answer	32.10.113.0.203.rpz-ip
Client IP	The IP of the client asking	24.0.2.0.192.rpz-client-ip
NSDNAME	The name of the authoritative name server for the domain	ns1.badhost.example.rpz-nsdname
NSIP	The IP of the authoritative name server	24.0.100.51.198.rpz-nsip

IP-based triggers write addresses in reverse with the prefix length first. So 32.10.113.0.203.rpz-ip means the single address 203.0.113.10/32, and 24.0.2.0.192.rpz-client-ip means the client range 192.0.2.0/24. NSDNAME and NSIP triggers are especially powerful because they block every domain hosted on known-malicious DNS infrastructure, including domains registered five minutes ago.

RPZ Actions

Actions are expressed as the record data, mostly as CNAME targets with special meanings:

Record data	Action
CNAME .	Return NXDOMAIN, as if the domain does not exist
CNAME *.	Return NODATA, meaning the name exists but has no records of the requested type
CNAME rpz-passthru.	Allow the query, overriding later rules (used for allowlists)
CNAME rpz-drop.	Drop the query silently with no response
CNAME rpz-tcp-only.	Force the client to retry over TCP
A 192.0.2.10 or CNAME walled-garden.example.com.	Return local data, such as the address of an internal block page

Deploying an RPZ Firewall on BIND

BIND supports RPZ through the response-policy statement. This named.conf excerpt defines a local policy zone you maintain by hand, plus a commercial threat feed pulled by zone transfer:

key "rpz-feed-key" {
    algorithm hmac-sha256;
    secret "c2VjcmV0LWtleS1mcm9tLXZlbmRvcg==";
};

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-recursion { 192.0.2.0/24; 127.0.0.1; };

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

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

zone "feed.rpz.vendor.example" {
    type secondary;
    primaries { 198.51.100.20 key "rpz-feed-key"; };
    file "/var/cache/bind/feed.rpz.vendor.example.db";
    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; };
};

Zones listed first in response-policy take precedence, so putting your local zone first lets your own allowlist entries override the vendor feed. allow-query { none; } prevents clients from querying the policy zones directly, and the rpz logging category writes every rewrite to its own log file. qname-wait-recurse no lets BIND apply QNAME rules without first waiting for recursion to complete, which speeds up blocked lookups. The TSIG secret shown is a placeholder; your feed vendor supplies the real one.

Now the policy zone itself, /etc/bind/db.rpz.local:

$TTL 300
@   IN  SOA  localhost. dns-admin.example.com. (
        2026100101 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        300 )      ; minimum
    IN  NS   localhost.

; Block a malicious domain and everything under it
malware.example.net          CNAME  .
*.malware.example.net        CNAME  .

; Return NODATA for a tracking domain
tracker.example.org          CNAME  *.

; Send users to an internal warning page
phish.example.info           A      192.0.2.10

; Allowlist a domain the vendor feed wrongly blocks
partner.example.biz          CNAME  rpz-passthru.

; Drop queries for a known C2 domain
c2.example.biz               CNAME  rpz-drop.

; Block any answer that points to 203.0.113.10
32.10.113.0.203.rpz-ip       CNAME  .

Validate and load it:

sudo named-checkconf
sudo named-checkzone rpz.local /etc/bind/db.rpz.local
sudo rndc reload rpz.local
dig @127.0.0.1 www.malware.example.net A

named-checkconf checks the configuration syntax, named-checkzone validates the policy zone, and rndc reload loads it without restarting the server. The final dig should return status: NXDOMAIN, and a matching line should appear in /var/log/named/rpz.log. Remember to increment the serial whenever you edit the zone. For a full walkthrough of running BIND as a resolver, see how to run your own DNS server with BIND.

Deploying RPZ on Unbound

Unbound supports RPZ through its respip module. This unbound.conf excerpt loads a local policy zone written in the same RPZ format as above:

server:
    module-config: "respip validator iterator"
    interface: 0.0.0.0
    access-control: 192.0.2.0/24 allow

rpz:
    name: rpz.local
    zonefile: /etc/unbound/rpz.local.zone
    rpz-log: yes
    rpz-log-name: "local-policy"

The respip module must come first in module-config for RPZ to work. rpz-log writes a log line for every rewritten query, tagged with the rpz-log-name. Unbound can also pull an RPZ feed from a primary with primary: and url: options inside the rpz: block. Check the file with unbound-checkconf and apply it with sudo unbound-control reload.

Windows Server DNS Policies

Windows Server DNS does not implement RPZ, but query resolution policies provide similar name-based blocking on Windows resolvers:

Add-DnsServerQueryResolutionPolicy -Name "BlockMalwareDomain" `
    -Action IGNORE `
    -FQDN "EQ,*.malware.example.net,malware.example.net" `
    -PassThru

Get-DnsServerQueryResolutionPolicy

The first command tells the DNS Server service to silently ignore queries for malware.example.net and its subdomains. -Action DENY returns a failure response instead of dropping the query. The second command lists the active policies so you can confirm the rule exists.

Cloud DNS Firewalls: AWS Route 53 Resolver

In AWS, Route 53 Resolver DNS Firewall applies policy to queries from resources inside your VPCs. You create a domain list, put it in a rule group, and associate the group with a VPC:

aws route53resolver create-firewall-domain-list \
  --creator-request-id "blocklist-20261001" \
  --name "blocked-domains"

aws route53resolver update-firewall-domains \
  --firewall-domain-list-id rslvr-fdl-EXAMPLE11111 \
  --operation ADD \
  --domains "malware.example.net" "*.malware.example.net"

aws route53resolver create-firewall-rule-group \
  --creator-request-id "rulegroup-20261001" \
  --name "corp-dns-firewall"

aws route53resolver create-firewall-rule \
  --creator-request-id "rule-20261001" \
  --firewall-rule-group-id rslvr-frg-EXAMPLE22222 \
  --firewall-domain-list-id rslvr-fdl-EXAMPLE11111 \
  --priority 100 \
  --action BLOCK \
  --block-response NXDOMAIN \
  --name "block-malware"

aws route53resolver associate-firewall-rule-group \
  --creator-request-id "assoc-20261001" \
  --firewall-rule-group-id rslvr-frg-EXAMPLE22222 \
  --vpc-id vpc-0123456789abcdef0 \
  --priority 101 \
  --name "corp-vpc-association"

Replace the example IDs with the ones returned by each create command. AWS also provides managed domain lists for malware and botnet command-and-control domains that you can reference in a rule in place of your own list. Other cloud and SaaS options, such as Cloudflare Gateway, Cisco Umbrella, and Infoblox, provide the same concept as a managed service with their own threat intelligence.

Making the DNS Firewall Unavoidable

A DNS firewall only protects clients that use it. Malware authors know this, so enforcement matters as much as policy:

1. Block outbound DNS to the internet on ports 53 and 853 from everything except your resolvers.
2. Control DNS over HTTPS. Configure managed browsers to use your resolver or disable DoH, and block well-known public DoH endpoints. Firefox checks the canary domain use-application-dns.net and disables its automatic DoH rollout if your resolver returns NXDOMAIN for it, which you can do with a single RPZ record. See what DNS over HTTPS is for the background.
3. Distribute your resolvers via DHCP and endpoint management so devices use them by default.
4. Cover remote workers with a client agent or a cloud resolver that enforces the same policy off-network.

Best Practices for Running a DNS Firewall

1. Start in log-only mode. Many RPZ implementations support a log or disabled policy override per zone. Run new feeds in observation mode for a week before blocking.
2. Layer feeds by confidence. Block high-confidence malware and C2 feeds outright, and send lower-confidence categories such as newly registered domains to a warning page.
3. Maintain an allowlist using rpz-passthru. in a zone listed first.
4. Feed the logs to your SIEM. A blocked lookup is often the earliest indicator that a host is infected. Use the client IP to start incident response.
5. Block on name server infrastructure with NSDNAME and NSIP triggers to catch freshly registered domains.
6. Watch for tunneling. Pair the firewall with anomaly detection, because DNS tunneling to a fresh domain will not be on any feed yet.
7. Monitor resolver performance. Large feeds use memory, and NSIP and NSDNAME triggers can add lookup latency.

For how a DNS firewall fits alongside DNSSEC, rate limiting, and other controls, see how to secure DNS against attacks.

---

DNS Firewall FAQ

Conclusion

A DNS firewall puts security policy at the one point every connection has to pass through: the name lookup. With Response Policy Zones, you can block malicious domains, catch domains hosted on bad infrastructure, redirect users to warning pages, and log every attempt, all using standard DNS tools and zone transfers for updates. The same idea is available as Windows DNS policies, cloud resolver firewalls, and managed services if you prefer not to run BIND or Unbound yourself.

The policy is only half the job. Make the firewall unavoidable by blocking outside DNS and controlling encrypted DNS, start new feeds in log-only mode, and send the logs to whoever handles incident response. Done well, a DNS firewall becomes both a cheap prevention layer and one of your most useful early-warning systems.

Here are some useful references for going deeper on DNS firewalls and RPZ:

1. ISC BIND 9 Documentation: BIND 9 Administrator Reference Manual — covers the response-policy statement and RPZ configuration in detail.
2. IETF Draft: DNS Response Policy Zones (RPZ) — the specification of RPZ triggers and actions.
3. Unbound Documentation: Unbound — NLnet Labs documentation, including the RPZ and respip module options.
4. AWS Documentation: Route 53 Resolver DNS Firewall — how to create domain lists, rule groups, and VPC associations.
5. Microsoft Learn: DNS Policies Overview — Windows Server DNS query resolution policies.