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.
Answer snapshot
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.
For bot abuse against your own web application, use a different layer. A CAPTCHA challenge-response runs after DNS resolution and asks a browser session to pass a bot check before a form, login, checkout, or API action continues.
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.10Common 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.
Related Guides
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.
Related guides
Security
What Is a DDoS Attack? Types, Impact, and DNS Protection
Learn what DDoS attacks are, how volumetric, protocol, and application-layer attacks work, and how anycast DNS networks protect your infrastructure.
Security
What is DNSSEC? A Plain-Language Guide to DNS Security
DNSSEC explained from first principles — what it is, why it exists, how it works at a high level, and when you should turn it on for your domain.
Security
DNS Amplification Attacks Explained — How They Work and How to Prevent Them
Understand how DNS amplification attacks exploit open resolvers and spoofed IPs to generate massive traffic floods, and learn the prevention techniques that stop them.
Security
How DNSSEC Works — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC Explained
A walkthrough of the DNSSEC chain of trust: how KSK and ZSK signing keys, DS records, DNSKEY records, RRSIG signatures, and NSEC/NSEC3 work together to authenticate DNS answers.
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