Response Policy Zones

Response policy zones (RPZs) are a way for you to control what your queriers can and can’t look up using a recursive DNS server. By understanding the reputation of the servers and services that clients are querying, you can determine actions to take when the recursive server receives queries for certain domain names or sees information in the DNS responses that point to those malicious servers.

RPZ basics

The overall idea of how RPZ works is that you can create policies for how to handle specific queries (or responses) and choose which of a number of possible actions to take. Examples of possible actions include redirecting the client to an internal security page and storing those policies in special authoritative zones on your DNS servers. You can also share RPZ zones by transferring them from DNS server to DNS server.

You can get RPZ data from a threat intelligence provider (where they are the primary for the zone and you are the secondary); or you can make these zones yourself (where you are the primary of the Zone). When you create RPZ yourself, it is often called a “Local RPZ”. Local RPZs typically consist of whitelist and blacklist items that your organization believes are critical. By including these items in a Local RPZ, you can ensure that no RPZ from another source can block or allow sites that your organization believes to be critical.

In order to create these RPZs, you need to understand the concept of reputation. Reputation describes a zone’s history of offering malicious content. Several reputation services track and analyze the providers of malicious content. These services often referred to as Threat Intelligence: Threat Intelligence service providers have the unenviable task of chasing the bad guys, predicting their next move, and even determining the algorithms they use to generate new bad domains. Thankfully, these services also publish this reputation data for everyone else to use. RPZs make policy data available in DNS zones. The policy data is then transferred between servers using conventional DNS protocols.

The resource records in the zone are expressions of DNS policy, which apply to domain names with the NAME field (QNAMES) or to the target data (RDATA). Note that the RDATA field in DNS consists of one or more subfields carrying the actual payload for a resource record.

The owner name of an RPZ QNAME policy resource record set (RRSET) is the relative name of the domain triggering the filter. For example, in the case where the policy zone is provided by Infoblox (and called rpz.infoblox.com), the policy affecting responses to nasty.comelook.badsite.net would
 be attached to the domain name nasty.comelook.badsite.net.rpz.infoblox.com. In this example, nasty.comelook.badsite.net is the site impacted. If all of the FQDNs in badsite.net were bad, the wildcard *.badsite.net.rpz.infoblox.com would catch all subdomains under badsite.net.

Triggers

The event that determines whether a query or response matches a specific entry is called a trigger.

QNAME Trigger

The QNAME trigger operates on the NAME field of a query. A wildcard format can block a site and all subdomains, for example *.badguys.com. The QNAME trigger should follow the full query and response cycle, including iteration, if required. The recursive server must follow the delegation hierarchy related to processing name server (NS) resource records and corresponding A and AAAA records.

IP Trigger

The IP trigger matches on the IPv4 or IPv6 address in the RDATA field of resource records in a DNS response. This is useful when we know the IP address is bad, no matter what its name might be. For example, if the known bad IP address is 10.11.12.13, and the client queried for example.com MX record, if the answer contains 10.11.12.13, then the answer is blocked from the client.

IP trigger can be a double-edged sword. While it is very effective at blocking a known bad IP address, it will also block any answer that contains that IP address. In the age of cloud computing, many web sites may share the same IP address. If one of the sites causes the IP address to be blacklisted, it could end up getting every other site on the same IP address blocked.

Client IP Trigger

The client IP trigger matches on the source IP address of the client initiating a query. Since it matches a specific client IP address, it is very targeted and is very effective when used to block hosts that are known to be compromised. It can send all queries from a single client to a remediation server, for example.

NSDNAME Trigger

The NSDNAME trigger matches the name of the authoritative name server found during recursion. This is an extremely powerful trigger targeting an entire DNS name server. This trigger affects all of the domains served by the name server. Since the NSDNAME trigger works during recursion, this trigger must be used with extreme caution and only when an entire name server is known to be malicious.

NSIP Trigger

The NSIP trigger matches the IP addresses in IPv4 A records and IPv6 AAAA records corresponding to name server records associated with domains (glue records). It checks these against NSDNAME policy records, which protects against name servers with multiple or changing names. The NSIP trigger can block a name server and all the domain names it serves.

RPZ Responses

Once a trigger matches a record in a response policy zone, we can take one of the four following policy actions:

NXDOMAIN

An RRset consisting of a single CNAME whose target is the root domain “.” causing a response of NXDOMAIN (“There is no such domain name.”)

NODATA

The RRset consists of a single CNAME whose target is the wildcard top-level domain(.*), which results in a response of NODATA(“There is no data of that type attached to that domain name.”)

NO-OP/PASSTHRU

This RRset consists of a single CNAME whose target is the query name itself and expresses an exception preventing any policy action for the name. You can think of this type of response as a “pass-through,” permitting domain information to pass through a filter unencumbered. Because a rule matched in the zone, we will see an entry in the logs, providing information to the administrator.

Local data

An RRset matching the QTYPE of the original query. In the event an RRset exists but does not match the QTYPE of the query, the name server sends a NODATA response.

The short of this is we can return two types of negative responses one a success with no information (NODATA) or an error (NXDomain), we can return a redirection, or we can just log that a trigger was hit.