Overview of the RPZ Behavior features

This API service provide an endpoint to list the predefined RPZ behaviors, as well as the creation, modification and deletion of custom RPZ behaviors.

RPZ Behaviors

For most DNS devices supported by ThreatSTOP, policies are implemented using Response Policy Zones (RPZ). This currently includes ISC BIND servers and derivative products, Unbound DNS Server. Microsoft DNS Server doesn’t support RPZ actions and is limited to returning NXDOMAIN responses.

RPZ defines a zone format which provides a mechanism to override the DNS server’s responses by applying policy actions to triggers (such as the queried DNS name, or the IP addresses in the response).

For more information about RPZ, the specification is available here.

RPZ Behaviors provide a mechanism to assign the RPZ policy actions to targets and custom lists in ThreatSTOP’s DNS Policies. ThreatSTOP provides a default set of RPZ behaviors as well as a mechanism to define your own. Typically, adding a custom behavior can be used to redirect traffic to a walled garden by overriding the response of the DNS server.

Default RPZ Behaviors

RPZ behaviors are available to every account by default. They can not be changed, but can be retrieved using the API and used in DNS Policies.

Default RPZ behaviors are identifed by the global field set to 1 in the Platform API responses.

The list of default behaviors is the following. Typically, policies use the NXDOMAIN action.

Name RPZ Action Description
NXDOMAIN CNAME . Return NXDOMAIN to the client, indicating that the requested domain doesn’t exist
NODATA CNAME .* Return NODATA to the client, indicated that there is no record for the requested name
PASSTHRU CNAME rpz-passthru. Queries for this record will be allowed, regardless of other RPZ rules. They will be logged as well
DROP CNAME rpz-drop. Don’t reply to the client. If the client has multiple DNS servers configured, it will try the next one
GARDEN CNAME garden.threatstop.com. Example walled garden

Syntax for custom behaviors

RPZ behaviors have two fields:

  • a symbolic name only used to identify the behavior in the API or Admin Portal
  • the RPZ action

The RPZ action can be used to specific records supported by RPZ’s Local Data action defined in section 3.6 of the RFC. For example:

RPZ action Description
CNAME garden.example.com. Resolve record to garden.example.com
CNAME *.garden.example.com. Prepend queries name to walled garden DNS name
A <ip address> Resolve record the specified IP address

Important: The DNS name must be terminated with a trailing dot.

The client making the DNS request will receive a response with the indicated record. If the client makes a TCP/UDP connection to resulting IP address, it will be effectively redirected to the IP address.

Wildcard actions (Advanced)

Using a wildcard action (e.g. *.garden.example.com.) will result in prepending the DNS name originally requested (e.g. bad.threatstop.com.garden.example.com.). Used in conjunction with a wildcard DNS record, this can be used to capture the original requested DNS name, for example using the logs of the DNS server for garden.example.com, or as the Host header of an ensuing HTTP request

Killswitch domains

Some malware (for example, the Wannacry ransomware) was disabled by the takeover of domains it uses as a killswitch. The proper RPZ action for such IOCs is not to block them, which would have the effect of disabling the killswitch, but rather to passthru which logs the requests (revealing the infection via the ThreatSTOP reports) or to redirect to a walled garden that is highly available and mimic the behavior of the killswitch domain.