Is a DNS firewall authoritative DNS or recursive DNS?

Usually recursive DNS. A DNS firewall sits on the resolver path used by clients and applies policy before returning answers. Authoritative DNS providers publish your zone data; DNS firewalls decide whether users on a network should be allowed to resolve a name.

RPZ stands for Response Policy Zone. It is a DNS zone format used by recursive resolvers to override answers for policy reasons. A matching policy can return NXDOMAIN, NODATA, a sinkhole IP, a CNAME rewrite, or allow the original answer.

Can RPZ block malware?

Yes, if the malicious domain is in a threat feed before the client resolves it. RPZ is effective against known bad domains and command-and-control names, but it is not a full endpoint security replacement.

Can DNS filtering break legitimate services?

Yes. Blocking shared SaaS domains, CDN hostnames, or wildcard domains can cause broad collateral damage. Use tested feeds, staged rollout, logging, and allowlist exceptions for business-critical services.

Does DNSSEC conflict with RPZ?

It can. RPZ intentionally changes answers, while DNSSEC validates that answers match signed zone data. Recursive resolvers that apply RPZ typically do so as a local policy decision and must handle validation order carefully. Treat filtered answers as local policy, not authentic upstream DNS data.

DNS Firewall and RPZ Explained - Policy Control at the Resolver

Learn how DNS firewalls and Response Policy Zones (RPZ) block malicious domains, enforce resolver policy, and complement authoritative DNS security.

Updated 5 May 2026

TL;DR

A DNS firewall applies policy at the recursive resolver: block known-malicious domains, sinkhole command-and-control names, prevent access to phishing domains, or enforce corporate allow/deny lists. RPZ (Response Policy Zone) is the common DNS-native mechanism for this: a policy zone tells resolvers to return NXDOMAIN, NODATA, a sinkhole IP, or a CNAME rewrite for matching names. It protects users and networks; it does not replace authoritative DNS hardening for your own domains.

What you'll learn

Understand the difference between authoritative DNS security and resolver-side DNS filtering
Learn how RPZ policy zones work
Choose between NXDOMAIN, NODATA, sinkhole, and passthru actions
Avoid common operational mistakes with DNS filtering

A DNS firewall is policy enforcement at the DNS resolver. Instead of letting every query resolve normally, the resolver checks a policy list first. If a domain is known malware, phishing, command-and-control, newly registered, or forbidden by company policy, the resolver can block or rewrite the answer.

RPZ (Response Policy Zone) is the DNS-native way many resolvers implement that policy. It looks like a DNS zone, but instead of publishing your domain to the internet, it tells recursive resolvers what to do with matching names.

Authoritative DNS vs DNS Firewall

DNScale is authoritative DNS: it publishes answers for zones you own. A DNS firewall is usually recursive DNS: it controls what users inside a network can resolve.

Layer	Purpose	Example
Authoritative DNS	Publish your domain's records	`www.example.com A 203.0.113.10`
Recursive DNS	Resolve names for users	User asks resolver for `www.example.com`
DNS firewall	Apply policy during recursion	Block `malware.example` or sinkhole it

You still need authoritative DNS hardening: DNSSEC, CAA, registrar lock, and account security. A DNS firewall protects users and networks from resolving dangerous names.

How RPZ Works

An RPZ feed is distributed as a DNS zone to recursive resolvers. Each record expresses a policy.

Example policy entries:

bad-domain.example.rpz.local.       CNAME .
phishing.example.rpz.local.         CNAME rpz-drop.
tracker.example.rpz.local.          CNAME passthru.
*.malware.example.rpz.local.        A 192.0.2.10

Common actions:

Action	Effect	Use case
NXDOMAIN	Pretend the name does not exist	Hard block malware
NODATA	Return no records for the type	Softer block
Sinkhole IP	Return a controlled IP	Malware telemetry or block page
CNAME rewrite	Redirect to a policy target	Warning page
Passthru	Explicitly allow	Override a broad feed

Exact syntax depends on the resolver, but the operational model is the same: policy is evaluated before the normal answer is returned.

Good Uses

Block known phishing domains.
Block malware command-and-control domains.
Sinkhole domains involved in active incidents.
Prevent access to typo-squatted domains targeting your brand.
Enforce internal policy for high-risk categories.
Protect unmanaged devices on guest or office networks.

Bad Uses

Replacing endpoint protection entirely.
Blocking broad CDN domains without testing.
Applying consumer blocklists to production servers.
Filtering authoritative answers for your own public zones instead of fixing the zone.
Running without logs, owner review, or exception process.

Deployment Pattern

Start with a resolver that supports RPZ or equivalent policy feeds.
Choose feeds by quality, update frequency, and false-positive history.
Enable logging in monitor-only mode if supported.
Roll out to a small user group.
Add allowlist exceptions for business-critical services.
Move to broader enforcement.
Review blocked-domain logs weekly.
Test incident-response sinkholes before a real incident.

Monitoring

Track:

Top blocked domains
Top clients generating blocked queries
New spikes in NXDOMAIN or sinkhole responses
Feed version and update age
False-positive tickets
Allowlist changes

A useful DNS firewall is observable. A silent blocklist becomes a debugging tax.

RPZ and DNSSEC

DNSSEC verifies that DNS answers are authentic. RPZ intentionally changes answers for local policy. That means resolver behavior must be deliberate: either policy is applied before validation, or the resolver marks the result as locally modified.

Do not present RPZ-modified answers as DNSSEC-authenticated upstream data. They are local security policy.

Frequently asked questions

Is a DNS firewall authoritative DNS or recursive DNS?: Usually recursive DNS. A DNS firewall sits on the resolver path used by clients and applies policy before returning answers. Authoritative DNS providers publish your zone data; DNS firewalls decide whether users on a network should be allowed to resolve a name.
What is RPZ?: RPZ stands for Response Policy Zone. It is a DNS zone format used by recursive resolvers to override answers for policy reasons. A matching policy can return NXDOMAIN, NODATA, a sinkhole IP, a CNAME rewrite, or allow the original answer.
Can RPZ block malware?: Yes, if the malicious domain is in a threat feed before the client resolves it. RPZ is effective against known bad domains and command-and-control names, but it is not a full endpoint security replacement.
Can DNS filtering break legitimate services?: Yes. Blocking shared SaaS domains, CDN hostnames, or wildcard domains can cause broad collateral damage. Use tested feeds, staged rollout, logging, and allowlist exceptions for business-critical services.
Does DNSSEC conflict with RPZ?: It can. RPZ intentionally changes answers, while DNSSEC validates that answers match signed zone data. Recursive resolvers that apply RPZ typically do so as a local policy decision and must handle validation order carefully. Treat filtered answers as local policy, not authentic upstream DNS data.

Ready to manage your DNS with confidence?

DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

Start free