Threat feeds via Response Policy Zone (RPZ)¶

Introduction¶

DomainTools provides threat feeds as DNS Response Policy Zones (RPZ) via DNS zone transfers. RPZ is a standard method for DNS servers to block access to malicious domains.

Your RPZ-enabled DNS resolver responds with an NXDOMAIN ("no such domain") status code for queries matching domains or subdomains in the threat feed. This effectively makes the listed domains unavailable for users of this DNS firewall.

Available feeds¶

Newly Observed Domains (NOD)¶

Newly Observed Domains are domains that DomainTools has observed for the first time in DNS traffic.

5m.nod.rpz.domaintools.com.
10m.nod.rpz.domaintools.com.
30m.nod.rpz.domaintools.com.
1h.nod.rpz.domaintools.com.
3h.nod.rpz.domaintools.com.
12h.nod.rpz.domaintools.com.
24h.nod.rpz.domaintools.com.

Newly Active Domains (NAD)¶

Newly Active Domains are existing domains that were recently seen after at least ten days of not being observed.

5m.nad.rpz.domaintools.com.
10m.nad.rpz.domaintools.com.
30m.nad.rpz.domaintools.com.
1h.nad.rpz.domaintools.com.
3h.nad.rpz.domaintools.com.
12h.nad.rpz.domaintools.com.

Risk Score Based Domain Hotlists¶

1k.domainhotlist.rpz.domaintools.com.
100k.domainhotlist.rpz.domaintools.com.
90s.domainhotlist.rpz.domaintools.com.
95s.domainhotlist.rpz.domaintools.com.
99s.domainhotlist.rpz.domaintools.com.

For detailed information about accessing these feeds via API, see the Real-Time Threat Feeds User Guide.

Zone naming format¶

The nod and nad zone name labels are constructed (left to right) from a time period, followed by a list name, followed by .rpz.domaintools.com:

[interval].[list].rpz.domaintools.com

Available time intervals: 5m, 10m, 30m, 1h, 3h, 12h, and for the nod feed, 24h.

For example, the 1 hour NOD list 1h.nod.rpz.domaintools.com contains the most recent hour of entries.

The larger time intervals are a superset that include the smaller time intervals. Smaller time intervals have smaller zone sizes and may be available a little faster.

For details about Domain Hotlist feeds, including risk score thresholds and expiration times, see the Domain Hotlist section in the Real-Time Threat Feeds User Guide.

How RPZ blocks domains¶

RPZ zones use a standard DNS format to define blocking rules. Each DNS zone is formatted in accordance with the draft specification for DNS Response Policy Zones. Each DNS firewall rule uses NXDOMAIN policy actions by default (CNAME .). Each domain entry contains both apex and wildcard *. entries (two records per domain).

For example:

$ORIGIN RPZ.EXAMPLE.ORG.
example.com                 CNAME   .
*.example.com               CNAME   .

Your DNS resolver responds with an NXDOMAIN ("no such domain") status code for queries matching domains in the RPZ feed. The NXDOMAIN response includes an SOA (Start of Authority) record in the ADDITIONAL section of the DNS response (and no ANSWER section). You can use this SOA record to verify the RPZ feed is working.

Configure your RPZ connection¶

DomainTools delivers the RPZ feeds over Incremental Zone Transfers (IXFR) and full zone transfers (AXFR). DNS NOTIFY is also used to indicate updates to the zones to trigger zone checks and transfers.

Provide your IP addresses to DomainTools¶

DomainTools restricts access to RPZ feeds by IP address to ensure security. Before you can connect, provide two sets of IP addresses to enterprisesupport@domaintools.com:

The IP address(es) from which you connect to the RPZ provider DNS server
The IP address(es) to which you would like DNS NOTIFY messages sent

You typically use the same addresses for both.

Configure your firewall¶

You must also add rules to your firewall's access control list(s) for DomainTools hosts to send UDP packets to port 53 of your DNS server, so that it can receive the DNS NOTIFY packets for timely updates.

IPv4: 104.244.14.88 Port: 53
IPv4: 104.244.14.89 Port: 53

Authenticate with TSIG¶

DomainTools uses TSIG (Secret Key Transaction Authentication for DNS) for authorization to use the RPZ feeds. This uses shared secrets and one-way hashing to authenticate DNS messages coming from approved DNS servers. Contact enterprisesupport@domaintools.com for the details.

TSIG key: DomainTools Enterprise Support provides this
TSIG key algorithm: hmac-sha512
TSIG key name: DomainTools Enterprise Support provides this

Test your RPZ configuration¶

When your DNS resolver blocks a domain using RPZ, the response includes an SOA (Start of Authority) record that identifies which RPZ feed was used. For example, the following label tells you what RPZ feed was used and the SOA RNAME field indicates the primary DNS server (under rpz.domaintools.com) that hosts this RPZ zone:

;; ADDITIONAL SECTION:
3h.nod.rpz.domaintools.com. 86400 IN SOA rpz-ns1.domaintools.com. noc.domaintools.com. 946684799 600 300 86400 86400

DomainTools uses the SOA SERIAL number as the timestamp (in Unix epoch format) for when this feed was last regenerated.

The RPZ threat feeds also have a testing domain entry and its corresponding wildcard which you can use to verify the RPZ feed is loaded and working. You can do a DNS lookup, like with dig, for test.rpz.domaintools.test and it should respond with the NXDOMAIN and the ADDITIONAL section SOA record indicating its originating RPZ feed. If the ADDITIONAL section SOA record response isn't under the specific feed name, such as 3h.nod.rpz.domaintools.com., then it didn't come from the RPZ.

See your RPZ related debugging logs for your DNS resolver for additional troubleshooting information.

Advanced configuration¶

Maintain a local allowlist¶

DomainTools recommends that you maintain an allowlist Response Policy Zone as needed for overrides when you have more specific information about a domain than DomainTools.

Log NAD matches instead of blocking¶

Because NAD feeds may include legitimate domains that happen to be inactive for extended periods, DomainTools recommends that you begin by logging instead of automatically blocking domains on the Newly Active Domains (NAD) list.

The following BIND (Berkeley Internet Name Domain) named configuration shows how to log the response policy rewrites (at the default info severity level):

logging {
  channel named-rpz {
    file "/var/log/named/named-rpz.log" versions 3 size 250k;
    print-time yes;
    print-category yes;
    print-severity yes;
  };
  category rpz {
    named-rpz;
  };
};

Or to log to the default logger:

logging {
  category rpz { default_syslog; };
};

The NAD (newly active domains) feeds contain existing domains that were recently seen after at least ten days of not being observed. It's recommended to not block on these NAD rules, but log only. You can do this by overriding the default NXDOMAIN behavior, for example, with BIND named:

  response-policy {
    zone "5m.nad.rpz.domaintools.com" policy DISABLED;
  };

An example single-line log output indicating a "disabled" match:

19-Nov-2025 21:00:11.305 rpz: info: client @0x7f10a0973168
127.0.0.1#55312 (test.rpz.domaintools.test): disabled rpz
QNAME NXDOMAIN rewrite test.rpz.domaintools.test/A/IN via
test.rpz.domaintools.test.5m.nad.rpz.domaintools.com

Redirect to a walled garden¶

A walled garden redirects blocked domains to an internal page instead of returning NXDOMAIN. This allows you to inform users why a domain is blocked. While the RPZ feeds define an NXDOMAIN response as the policy action, you can configure the DNS firewall to redirect users of the matching domain to a walled garden instead, restricting their access to specific external services or content. An example of configuring the RPZ for a walled garden for BIND named follows:

 response-policy {
   # walled garden
   # override the NXDOMAIN and redirect to other domain instead
   zone "1k.domainhotlist.rpz.domaintools.com" policy CNAME captive.internal;
 };

Based on this example, an internal website named captive.internal can be used to share information about the "Firewall" policies. That target URL's domain name will also need to be configured.

The walled garden scenario can be useful for restricting website access but can't work for anti-spam blocking. You may need to use separate DNS firewalls for walled garden website access versus DNS resolution used for email servers.