DNS Firewalls and Response Policy Zones

Where a DNS firewall sits

Policy is applied by the recursive resolver your clients use, not by authoritative servers. That makes the firewall invisible to the rest of the Internet: the domain still resolves normally for anyone using a different resolver. For the general role of recursive servers, see Recursive Resolver Behavior Deep Dive.

Some checks happen before recursion, using only the query name. Others happen after, because they depend on the answer, such as the IP address a name resolved to or the name servers that served it. Post-answer checks catch threats that rotate through many names but reuse the same hosting.

How RPZ rules are written

Each rule in a policy zone is a trigger, encoded in the owner name, and an action, encoded in the record data. The zone's own origin is stripped before matching, so the owner name malware.example.net inside a policy zone called block.rpz.local matches queries for malware.example.net.

IP triggers are written as the prefix length followed by the address octets in reverse order. The action is usually a CNAME to a special target:

$TTL 300
@   IN SOA localhost. hostmaster.example.com. 2026101501 3600 600 86400 300
    IN NS  localhost.

; NXDOMAIN for a name and everything below it
malware.example.net             CNAME .
*.malware.example.net           CNAME .

; NODATA: the name exists but has no records of the asked type
tracker.example.org             CNAME *.

; Walled garden: answer with the address of a block page
phish.example.net               A     192.0.2.80

; Exception: always resolve normally
partner.example.com             CNAME rpz-passthru.

; Silently drop the query
c2.example.net                  CNAME rpz-drop.

; Block any answer that points into 203.0.113.0/24
24.0.113.0.203.rpz-ip           CNAME .

On BIND, policy zones are listed in the response-policy statement and loaded like any other zone. A local zone holds your own rules and a feed arrives by zone transfer from a provider:

options {
    response-policy {
        zone "allow.rpz.local";
        zone "block.rpz.local";
        zone "feed.rpz.example.net";
    };
};

zone "allow.rpz.local" { type primary; file "allow.rpz.local.db"; allow-query { none; }; };
zone "block.rpz.local" { type primary; file "block.rpz.local.db"; allow-query { none; }; };
zone "feed.rpz.example.net" {
    type secondary;
    primaries { 198.51.100.53; };
    file "feed.rpz.db";
    allow-query { none; };
};

Order matters: when several policy zones match, the first zone listed wins. Putting a small allow-list of rpz-passthru. rules first gives you a fast way to override a feed's false positive without waiting for the provider.

Testing and logging

Add a harmless canary name to your local block zone and query it from a client. A blocked name should look like an ordinary negative answer:

$ dig canary.example.com @192.0.2.53

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

$ dig canary.example.com @192.0.2.53 +short
$ dig partner.example.com @192.0.2.53 +short
203.0.113.40

That NXDOMAIN is indistinguishable from a real missing name, which is the main operational drawback of RPZ. RFC 8914, Extended DNS Errors, defines codes such as Blocked, Censored and Filtered that a resolver can attach to explain the result, and some resolvers use them. The difference between NXDOMAIN and NODATA is explained in NXDOMAIN vs NODATA vs REFUSED.

Logging is where a DNS firewall pays for itself. Every policy hit records the client address and the name it asked for. Sending those logs to your security monitoring turns them into alerts for infected or misused machines, and patterns in the logs can also reveal DNS-based data theft, discussed in DNS Tunneling (Data Exfiltration).

Limits and bypasses

• Encrypted DNS to outside resolvers. A browser or app using DNS over HTTPS to a public service never asks your resolver. Firefox checks the canary domain use-application-dns.net and disables its default DoH when the network returns a negative answer for it, but other software does not. See DoH vs DoT vs DoQ.
• Hard-coded addresses. Malware that connects to an IP address directly skips DNS completely.
• DNSSEC. A rewritten answer cannot carry a valid signature for the original zone. BIND, for example, does not rewrite signed answers for clients that request DNSSEC records unless break-dnssec is enabled, and a validating client would reject the rewrite anyway.
• False positives. Shared hosting and broad IP triggers can block legitimate sites. Review feed quality and keep the allow-list ready.
• Privacy. Query logs reveal browsing behavior, so set retention limits and access controls before you start collecting them.

How DNS Panopticon helps

When a feed blocks a name and someone asks whether the block is justified, Website Recon gives you a quick second opinion from public data. It reports the registrar and registration dates from RDAP, flags very new domains and hold statuses, shows the network and AS number that host the resolved addresses, checks URLhaus listing status, notes likely fast-flux behavior, and lists abuse contacts if you decide to report it.

Domain Visualizer resolves names through public DNS-over-HTTPS resolvers rather than your internal one. Comparing its result with what your own resolver returns is a simple way to tell whether a name is really missing or is being blocked by your policy.