DNS Response Policy Zones (RPZ): How to Use Them to Block Malware and Phishing Domains

What Is DNS RPZ and Why Should You Care?

Every time you visit a website, your computer asks a DNS resolver to translate the domain name into an IP address. If that domain is hosting malware or running a phishing campaign, the resolver unknowingly hands over the keys to the castle. DNS Response Policy Zones (RPZ) flip this script by letting you enforce custom policies at the resolver level — blocking, redirecting, or logging queries to known‑bad domains before any connection is made.

RPZ is often called a “DNS firewall”. It’s one of the most efficient ways to protect an entire network because it works silently in the background, doesn’t require endpoint software, and can block threats that even URL filters might miss. For IT teams, MSPs, and security‑conscious domain investors, RPZ is a game‑changer for proactive defense.

How DNS RPZ Works

RPZ is a mechanism defined by the Internet Systems Consortium (ISC) and implemented in BIND, Unbound, PowerDNS, and other authoritative/resolver software. A response policy zone is a specially formatted DNS zone file that the resolver checks against every incoming query before returning an answer. The zone contains rules that override the normal resolution for matching domains.

Each rule generally has three components:

• Trigger – the domain name (e.g., evil-phish.example.com)
• Policy action – what to do when a match occurs
• Optional override data – IP or name to substitute

The most common policy actions are:

• CNAME *. – redirect to a walled garden or block page
• NXDOMAIN – return “domain does not exist” (effectively blocks the query)
• DROP – silently drop the query (no response, client times out)
• Local‑Data – return a custom IP (e.g., a local warning server)
• Passthru – allow the domain despite other policies

You feed the resolver one or more RPZ files (often updated automatically from threat intelligence feeds), and the resolver applies those rules to every user query. It’s a simple but incredibly powerful concept.

Setting Up RPZ: Practical Steps

1. Choose Your RPZ Feeds

The first step is deciding which threats to block. You can:

• Use a commercial feed like Spamhaus DBL, Suricata, or ThreatFox
• Create your own custom blocklist of domains you’ve identified as malicious
• Combine multiple sources (but watch for overlaps and performance)

Pro tip: Run a DNS Analyzer on your current resolver configuration to baseline performance before adding RPZ – that way you can measure the impact.

2. Configure Your Resolver

For BIND, add a stanza like this to named.conf:

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

Then enable RPZ in the options block:

response-policy {
    zone "rpz.blocklist.local";
};

For Unbound, use rpz: sections in the config file. For PowerDNS, use the gpgsql backend or static zone files with RPZ semantics.

3. Populate the RPZ Zone File

A minimal RPZ zone entry looks like this:

$TTL 3600
@   IN  SOA localhost. root.localhost. (1 3600 900 604800 86400)
    IN  NS  localhost.

; Block specific malicious domains
evil-phish.com        CNAME .
malware-download.net  CNAME .
phishing-login.com    CNAME .

The CNAME . syntax says “return NXDOMAIN” – the domain simply doesn’t exist to the client.

4. Automate Updates

Manually editing zone files is tedious. Use a script that fetches a threat feed (e.g., via wget or a Python script), converts it to RPZ format, and signals the resolver to reload the zone. Most modern resolvers support rndc reload or systemctl reload without dropping queries.

Real‑World Example: Blocking a Phishing Campaign

Imagine a phishing campaign targeting your company’s login page. The attackers registered yourcompany-secure-login.com and are sending emails with links to that domain. Without RPZ, users who click the link reach a convincing fake.

With RPZ, you add that domain to your blocklist. When a user’s resolver receives a query for yourcompany-secure-login.com, it responds with NXDOMAIN. The user sees a “page not found” error in the browser instead of the phishing page. Even if they clicked the malicious link, the attack is neutralized at the DNS level.

Bonus: You can set up a local‑data policy to redirect to an internal warning page that says “This site has been blocked – please report this link.” That turns a security incident into user education.

Actionable Advice for Maximum Effectiveness

• Leverage multiple policy zones – Create one zone for malware, another for phishing, and a third for custom internal blocks. Apply them with a priority order using the response-policy zone list in BIND.
• Use RPZ with threat intelligence feeds – Services like Spamhaus, Feodo Tracker, and URLhaus provide regularly updated lists of malicious domains. Automate fetching them into your RPZ zone.
• Log RPZ hits – Enable query logging for your resolver and grep for RPZ overrides. This helps you fine‑tune the blocklist and identify compromised clients on your network.
• Combine with WHOIS/Lookup analysis – When you spot a suspicious domain in your logs, use a WHOIS Lookup to see registrant details and registration dates. Many phishing domains are less than 30 days old. This cross‑reference can help you decide whether to add a domain to your custom blocklist.
• Test before deploying widely – Set the policy action to “passthru” temporarily while logging. Review the logs to ensure you aren’t blocking legitimate services (like CDNs). Then switch to NXDOMAIN.
• Don’t forget about DNS over HTTPS (DoH) – Users with browsers configured to use DoH (e.g., Cloudflare 1.1.1.1) will bypass your local resolver and its RPZ. Enforce network‑level DNS using firewall rules or use a DoH proxy that supports RPZ.

Alternatives and Considerations

RPZ is not the only DNS‑based security tool. Alternatives include:

• DNS sinkholing – Hardcode malicious domains in a zone file without RPZ (less flexible).
• DNS filtering services (e.g., Quad9, OpenDNS) – Easy but give up control over your own policy.
• Pi‑hole – Great for home use, but not designed for enterprise scale and complex RPZ feeds.

RPZ’s biggest advantage is granular control – you can write custom policies for any domain, combine multiple threat feeds, and integrate it into a larger security stack (SIEM, firewalls). The trade‑off is complexity: you need a capable resolver and a plan for maintaining the zone files.

Conclusion

DNS Response Policy Zones let you stop malware and phishing before a single packet touches the network. By implementing RPZ with automated threat feeds and careful logging, you create a proactive defense that scales from small offices to large enterprises. Start with a simple blocklist of known malicious domains, monitor the results, and iterate. Your users – and your security team – will thank you.

Ready to tighten your DNS security even further? Check out our DNS Analyzer to audit your current resolver configuration, or use the Domain History tool to investigate suspicious domains before adding them to your blocklist.