Threat Feeds via Response Policy Zone (RPZ)¶

Introduction¶

DomainTools delivers some threat feeds as DNS Response Policy Zones (RPZ) via DNS zone transfers.

An RPZ-enabled DNS resolver using the RPZ feed will deliberately respond with an NXDOMAIN ("no such domain") status code for queries for matching domains or subdomains in the Threat Feed. This effectively makes the listed domains unavailable for users of this DNS firewall.

These RPZ feeds include:

Newly Observed Domains (NOD)¶

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)¶

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.

Configure RPZ access¶

DomainTools delivers the RPZ feeds over DNS 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.

RPZ Provider Allowlist¶

Before attempting to connect to the RPZ provider, provide two sets of IP addresses to DomainTools Enterprise Support:

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

These two sets of addresses are typically the same.

RPZ Provider DNS Server Addresses¶

You will also need to 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

RPZ TSIG Information¶

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 DomainTools Enterprise Support for the details.

TSIG key: Provided by DomainTools Enterprise Support
TSIG key algorithm: hmac-sha512
TSIG key name: Provided by DomainTools Enterprise Support

Recommendation: Local RPZ Allowlist Zone¶

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.

RPZ Response Format¶

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. The DNS firewall rules are listed with 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   .

RPZ Troubleshooting¶

The DNS resolver using the RPZ feed will respond with an NXDOMAIN ("no such domain") status code for queries for matching domains in the RPZ feed. The NXDOMAIN response will include 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 troubleshoot the RPZ feed. In addition, see your RPZ related debugging logs for your DNS resolver.

This SOA record will identify that it came from the RPZ. 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.

Walled Garden¶

A walled garden is an alternative policy action that redirects blocked domains to an internal page instead of returning NXDOMAIN. 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.