Rpz (Response Policy Zone
From:       https://www.zytrax.com/books/dns/ch7/rpz.html#response-policy




 
BIND9 - Response Policy Zone Configuration

Response Policy Zone (RPZ) is a BIND9.10+ feature - the basic capability was 
released with BIND9.8 but has gone through a number of iterations and upgrades.
The BIND9.10 feature set is defined here (RPZ Format 3). Earlier specifications,
and their BIND9 implementation, had somewhat fewer features that impaired their 
usefulness. The RPZ Format 3 specification anticipates future changes but has, 
so far, enabled backward and forward compatibility.

Note: RPZ is not a standard DNS feature defined by an IETF RFC (though we note 
an RFC draft submission in December 2016'ish). It is, however, an Open 
specification (currently Format 3) whose authors have made it freely available.
It is Copyrighted by ISC but annotated "Distribution of this memo is unlimited,
if full attribution is given". However, it must be noted that any specification
changes/updates are at the whim of its authors. The RPZ specification defines 
the use of standard zone files whose RR definitions invoke Policy Actions by 
using Policy Triggers in what one may call a Policy Rule Set (though this term 
is not used in the specification). RPZ is invoked (and its behavior controlled)
in BIND9 using a response-policy statement (in named.conf) which is unique to 
BIND9 and is not defined within the RPZ specification - other implementations 
will use their own configuration styles and parameter sets. RPZ, by default, 
does not invoke policy processing on DNSSEC responses (though this can be 
modified with the break-dnssec parameter). For those familiar with the 
technology, RPZ is similar to, but significantly more complex and flexible than,
DNS Black Lists (DNSBL) - a reputational anti-spam technique.

Note: There are discrepancies between the RPZ specification (Format 3) and the 
BIND9 implementation (noted as [not in Format 3] in text). This page documents 
the BIND9 implementation, verified by source code inspection, unless otherwise 
noted.

In summary, RPZ allows the operator of a name server - in most, but not all 
cases, a recursive server (resolver) - to control the behavior of responses to 
queries. This has many implications. Most are entirely positive in that known 
"bad guys" can be prevented from causing malicious damage by eliminating them 
at their source - the DNS system. However, the same technology can also be used
to implement less positive actions including outright blocking of sites or even
TLDs for commercial or other more dubious reasons by ISPs, employers or other 
organizations that operate DNS infrastructure. It can clearly be argued that 
such technology already exists, albeit in different forms. This cat is already 
out of the bag. Nevertheless, RPZ, by reducing the entry-level threshold, may 
make it more ubiquitous and, in turn, more open to potential abuse and 
collateral damage effects. As a trivial example, debugging of user access 
problems may no longer be a simple question of checking all the usual suspects 
for error-free operation. There could now be one or more levels of RPZ 
processing in the round-trip between the user, their desired internet 
destination and its response path.



response-policy statement The response-policy statement, which may appear in a global options or view clause, controls the behavior of RPZ policy processing and has, for BIND9, a rather unusual syntax:
Syntax response-policy { zone zone-name [ policy (given|disabled|passthru|drop|nxdomain|nodata|tcp-only| cname domain-name) [ recursive-only yes_or_no ] [ max-policy-ttl seconds ] [ log yes_or_no] ; ... } [ recursive-only yes_or_no ] [ max-policy-ttl seconds ] [ break-dnssec yes_or_no ] [ min-ns-dots number ] [ qname-wait-recurse yes_or_no ] [ nsip-wait-recurse yes_or_no] ; # example response-policy {zone "dontlike" ; zone "likeless" policy passthru;} recursive-only yes; Items in bold are keywords. The response-policy statement is split into two sections. A zone section in which multiple (up to 32) zones together with zone specific behavior modification parameters are defined - zone specific parameters always override global definitions in the response-policy statement. The zone section is delimited by braces {}. The global section applies behavior control parameters to all the zones defined in the response-policy statement (unless overridden with zone specific parameters) and is delimited by the terminating ;. Multiple parameters in either the zone or global section are space separated.
Where:

zone: The zone keyword starts a zone definition within the zone section of the response-policy statement. The zone-name must be a quoted string and defines the zones that will be searched (in the order in which they are defined - the zone definitions constitute an ordered set) when RPZ policy processing is invoked. There can be up to 32 zone definitions (BIND 9.10+). Each zone defined in the response-policy statement must also be defined within a normal zone clause, which may, in turn, be inside a view clause as shown below:

options { ... response-policy {zone "evenless" ; zone "noway"; }; ... }; ... zone "evenless" { type master; file "master/evenless.map"; ... }; view "mordor" { ... zone "noway" { type slave; file "slave/noway.map"; ... }; };

policy: Is an optional zone-specific parameter (cannot appear in the global section) and defines any override to the Policy Actions in the RPZ zone file.

given: Is the default action and defines no overrides - the zone file Policy Actions are unchanged. disabled: All Policy Actions for this zone are disabled but all items are logged to the rpz category thus also making it a useful testing option since it will log all RPZ trigger events. Note: Even with logging severity info; RPZ only logs the owner-name (left-hand) Trigger not the substituted (re-written) RR/target-name part. passthru: Every Trigger in the RPZ zone is actioned as a PASSTHRU irrespective of its actual Policy Action. drop: Every Trigger in the RPZ zone is actioned as a DROP irrespective of its actual Policy Action. nxdomain: Every Trigger in the RPZ zone is actioned as an NXDOMAIN irrespective of its actual Policy Action. nodata: Every Trigger in the RPZ zone is actioned as a NODATA irrespective of its actual Policy Action. tcp-only: Every Trigger in the RPZ zone is actioned as TCP-ONLY irrespective of its actual Policy Action. cname domain: Every Trigger in the RPZ zone returns a CNAME with the defined domain value irrespective of its actual Policy Action. Thus, if policy cname badguy.example.com is defined in the response-policy statement for an RPZ zone then every RR in the zone that triggers policy processing will return CNAME badguy.example.com even if the Policy Trigger and Policy Action specified, say, some-name A 192.168.2.3 (a Local-data Policy Action).

recursive-only May appear inside an specific zone definition (in the zone section) of a response-policy statement in which case it affects only that zone, or outside (in the global section) where it affects all zones (unless overridden by the same parameter inside any specific zone definition). recursive-only takes the values yes or no (seems pretty cut and dried). Yes (the default) indicates that the policy process is invoked only on recursive queries (RD bit = 1). No causes the policy process to be invoked on every query received by the server. max-policy-ttl: May appear inside an specific zone definition (in the zone section) of a response-policy statement in which case it affects only that zone, or outside (in the global section) where it affects all zones (unless overridden by the same parameter inside any specific zone definition). The outcome of policy processing changes the response in the resolvers cache. By default, irrespective, of the original response TTL, the modified response TTL is set to 5 seconds. Thus, if you want to force the responses to live in the cache for a long period then define a (much) longer ttl value with a parameter like, say, max-policy-ttl 172800 (2 days defined in seconds). Consider, however, that any updated RPZ zone files (master or slave) may modify the behavior of any policy trigger or action including removing it entirely. Modifying the default TTL value to an long time period - a superficially attractive strategy - may have the unintended consequence of marooning unnecessary records in the cache. log [BIND 9.11 feature] May only appear in a zone section. Takes the single value yes or no. Yes (default) indicates RPZ operations for the zone will be logged to the RPZ category. No suppresses RPZ logging for the zone. break-dnssec: May only appear in the global section of the response-policy statement. By default RPZ does not process queries that request DNSSEC data (DO = 1) or that have DNSSEC RRs in the answer. Setting break-dnssec yes will override this default and cause policy processing on all DNSSEC queriies. However, the constructed response will not have any DNSSEC material added and therefore cannot be verified by the client (it may have the unintended consequence of looking like a bogus response or even an injection attack to the client). min-ns-dots: May only appear in the global section of the response-policy statement. Defines the minimum number of dot separators that must appear in any query question name (the QNAME) to invoke policy processing. Thus, if min-ns-dots has a value of 1 (the default) all queries with a name (QNAME) of the form example.com, mail.example.com or those containing more dots will invoke policy processing. Those with zero dots will by-pass policy processing - in the example (and default) case this would by-pass policy processing for QNAMEs containing only root or a TLD name. qname-wait-recurse: May only appear in the global section of the response-policy statement. Takes the single value of either yes (default) or no. In normal operation, policy processing is invoked only when the results of any query are available (when the query process completes - successfully or unsuccessfully). This allows the "normal" resolver cache to contain the real results but can delay query response to the end user to an unacceptable level. The value no allows policy processing to occur when the query is received without waiting for a response. This behaviour control effectively only applies to QNAME Policy Triggers since all other triggers require query results to determine their actions. nsip-wait-recurse: [BIND 9.11 feature] May only appear in the global section of the response-policy statement. Takes the single value of either yes (default) or no. In normal operation, policy processing is invoked only when the results of any query are available (when the query process completes - successfully or unsuccessfully). This allows the "normal" resolver cache to contain the real results but can delay query response to the end user to an unacceptable level. The value no indicates that if the result of the Name Server lookup is in the cache the NS-IP Trigger will be processed normally. If the data is not available in the cache the NS-IP Trigger will be bypassed but the NS lookup operation will continue, meaning it will subsequently be cached and invoke normal NS-IP Policy Trigger operations. Essentially, no bypasses the first occurrence of all NS-IP Triggers.
response-policy examples
RPZ Zones Files RPZ uses zone files with normal RRs to define Policy Actions and Policy Triggers. The zone is defined in a normal zone clause which may be inside a view clause. RPZ zones may be queried (if a master only by a slave to read its SOA RR, if a slave, never) so their infrastructure records (SOA and NS) have to satisfy minimal zone validation rules, that is the SOA RR must exist, but since no delegation will result from, or any delegation be referred to, RPZ zones only a single NS RR is required which can take the name of localhost (further discussion at RPZ Domain Names) obviating the need for any corresponding A/AAAA RR (localhost is out-of-zone). RPZ zones can be masters or slaves in the normal manner, indeed the designers of RPZ envisaged that RPZ zone files may be distributed (using zone transfer) by commercial enterprises, affinity groups or other such organizations. RPZ zones have special characteristics that merit special attention, in particular they are likely to be big and may, by their very nature, become the target of attackers. The following items may be worth consideration:
  1. Query limiting:As noted above an RPZ master only needs to be queried by a valid slave in order to read its SOA RR (for zone transfer action). An allow-query statement listing all slave servers or referencing an ACL clause is appropriate. An RPZ slave does not need to be queried at all. An allow-query {none;}; statement is appropriate to implement this.
  2. NOTIFY: Assuming RPZ is using a typical master/slave system then an attacker, by bombarding slaves with fake NOTIFY messages, can cause significant traffic to be generated from slaves to masters (reading the SOA RR). In a common scenario where a central RPZ zone may be distributed to many 100s or even 1000s of slaves this bogus traffic could become significant and constitute a DDoS attack. Since BIND9.9 the also-notify statement allows the same parameter set as the masters statement including the reference to a masters clause and a key, meaning that TSIG may now be used to authenticate NOTIFY messages. Use of a non-standard port for NOTIFY messages should not be overlooked as a trivial, but highly effective, method to filter out any unwanted traffic. Changing this port number from time to time, perhaps even frequently, will further help to make an attacker's life more miserable - always a good thing. The following fragment shows possible NOTIFY measures: // example.com named.conf fragment options { ... }; // KEY CLAUSES SHOULD ALWAYS BE INCLUDED // include "keys/rpz-key.clause"; // WITH READ-ONLY PERMISSION FOR BIND/NAMED key "rpz-key" { ... }; masters "notify-these" { ... }; // FORCE USE OF TSIG TO SLAVE server 192.168.2.5 { keys ("rpz-key";}; }; zone "rpz.example.com" { type master; ... also-notify {"notify-these" port 7222 key "rpz-key";}; }; // SLAVE SERVER example.net named.conf FRAGMENT options { ... listen-on port 53 {192.168.2.17;}; // LOCAL IP STD PORT listen-on port 7222 {192.168.2.17;}; // FOR NOTIFIES }; // KEY CLAUSES SHOULD ALWAYS BE INCLUDED // include "keys/rpz-key.clause"; // WITH READ-ONLY PERMISSION FOR BIND/NAMED key "rpz-key" { ... }; // FORCE USE OF TSIG IN TRAFFIC FROM/TO MASTER server 10.0.150.3 { keys ("rpz-key";}; }; zone "rpz.example.com" { type slave; ... masters {10.0.150.3 port 7222 key "rpz-key";}; };
  3. Zone Transfer: Unauthorised zone transfers normally constitute only a DoS/DDoS threat (exceptionally a content disclosure threat). Clearly, in the RPZ case the DoS/DDoS threat is significant but the content disclosure threat is acute. The use of TSIG, to authorize the requestor of the zone transfer, becomes essential in this context. An attacker could create a very useful DDoS attack (especially if a bot-army was included) simply by sending zone transfer requests even though doomed to failure - it always takes time to process negative responses and the TCP overhead would be invoked even in such failure case wasting system resources. Again, the use of a non-standard port (with frequent changes) helps to reduce DoS/DDoS potential. The fragment below shows the use of zone transfer techniques: Note: If NOTIFY messages are being authorized by TSIG then the same key should be used for NOTIFY and zone transfer. This reduces the chances of operational errors and key exposure during key distribution, especially if a large number of RPZ slave servers are active. It is also good practice to use a separate key for each slave. This minimizes the number of entities involved in the case of any key compromise or normal key roll-over (periodic replacement). When a large number of slaves are involved this can result in a complex control process for the master distribution point - not to mention a huge named.conf file. // MASTER example.com NAMED.CONF FRAGMENT options { ... }; // KEY CLAUSES SHOULD ALWAYS BE INCLUDED // include "keys/rpz-key.clause"; // WITH READ-ONLY PERMISSION FOR BIND/NAMED key "rpz-key" { ... }; // ALSO-NOTIFY LIST masters "notify-these" { ... }; // FORCE USE OF TSIG IN TRAFFIC FROM/TO SLAVE server 192.168.2.5 { keys ("rpz-key";}; }; zone "rpz.example.com" { type master; ... also-notify {"notify-these" port 7222 key "rpz-key";}; }; // SLAVE SERVER EXAMPLE.NET NAMED.CONF FRAGMENT options { ... }; // KEY CLAUSES SHOULD ALWAYS BE INCLUDED // include "keys/rpz-key.clause"; // WITH READ-ONLY PERMISSION FOR BIND/NAMED key "rpz-key" { ... }; // FORCE USE OF TSIG IN TRAFFIC FROM/TO MASTER server 10.0.150.3 { keys ("rpz-key";}; }; zone "rpz.example.com" { type slave; ... masters {10.0.150.3 port 7222 key "rpz-key";}; };
  4. Zone size: RPZ zones are likely to be extremely large - perhaps > 1 million records. BIND 9.10 provides a new map option for named-compilezone and the masterfile-format statement to enable significantly faster zone load speeds. In addition, to minimize file transfer sizes, assuming one or more slaves will request zone transfers from the RPZ zone, the ixfr-from-differences statement can be used to create a difference file even if dynamic update is not being used. The following shows these features in use: Note: It appears that as of Jan 2015 Bind 9.10's map zone load feature is supported for all zones files EXCEPT RPZ zones. Strange ommission. We leave the section below intact since it can only be a matter of time before this changes since RPZ zones are likely to be among the biggest out there. RPZ really does need the fastest possible zone load service available. # convert zone from text to map format named-compilezone -f map -o master/rpz.map rpz.example.com master/rpz.zone // example.com named.conf fragment options { ... ixfr-from-differences yes; ... }; zone "rpz.example.com" { type master; file "master/rpz.map"; masterfile-format map; ... };
  5. RPZ Domain Names: RPZ zones have little visibily and therefore can beak most of the normal rules for zone naming and definition, indeed much of the documentation does in fact make this out to be a positive attribute that brings some inherent security benefits. Thus, it is permissible to use a domain name such as badguys, or slimeballs or slightly more prosaically, rpzlist. Indeed, this page uses this fact to have some fun with RPZ domain names. Since these strange'ish domain names are, by their very nature unreachable by any normal means they have instrinsic security - they cannot be queried, though that will not stop a potential attacker from attempting the query - even failed queries consitute a server load, and a lot of failed queries (from a bot army) can constitute a serious server load. So the first question regarding RPZ is - will my use of RPZ constitute a DoS/DDoS threat escalation? RPZ goes to some length to disguise its presence by allowing normal DNS operations to complete before invoking its processing. This means that a rogue operator will see no change in normal traffic originating from an RPZ-enabled site and thus no cause for alarm. (This behavior can be modified using qname-wait-recurse which should be carefully considered before implementation.) However, use of the Policy Actions NXDOMAIN and NODATA will cause domain name leakage due to the way the message is reported (the SOA RR of the RPZ domain is displayed in the Authority Section of the returned query). An obvious domain name, for example, RPZ-Badguys will be a sure give-away that RPZ is implemented and perhaps incur revenge attacks. An entirely prosaic domain name, containing no mention of RPZ, is perhaps a wiser choice, examples could include domain.example.com or first.example.com from within the end users domain name set, but with no corresponding zone RR, would still achieve the required goals. Furthermore, the suggested use of localhost (which will also appear in NXDOMAIN and NODATA responses) is a potential give-away that RPZ is in use. Any valid looking out-of-zone NS RR will suffice, such as ns27.example.net, or even a fairly visible domain-name, since it will never be used in any delegation processing.

Operational Notes:
  1. All owner-names (right-hand-names) that appear in an RPZ must be unqualified (or relative), that is they must not terminate with a dot. Unless, of course, you enjoy typing out the $ORIGIN name on each such name in which case they can be FQDNs.
  2. While it is always good practice to use an $ORIGIN name in every zone file it is practically essential for RPZ domains. BIND9 will synthesize missing $ORIGIN names from the name used in the zone file but this can have unintended side effects and reduce flexibility in zone naming as discussed next.
  3. The RPZ zone name as it appears in the $ORIGIN directive must look valid but is not otherwise significant in that it will never appear in a delegated query operation from a slave (slaves directly access the master using an IP address in a masters statement not a query operation). Indeed, for obvious reasons, users may wish to ensure RPZ zone domain names are not resolvable via any public name server.
  4. The response-policy statement will take up to 32 zone names. It is superficially attractive to group each Policy Trigger type into a separate zone file. Recall, however that policy processing will search the zone files in the order in which they appear in the response-policy statement thus significant negative search overheads could be incurred. It may make more sense to segregate files based on their search characteristics. For example, placing all address based triggers (CLIENT-IP, IP, NSIP) into a single file since these always begin with a numeric value whereas few QNAME or NSDNAME targets will. Alternatively, where such segregation is impossible or difficult, define smaller files before larger files in the response-policy statement order unless their hit frequency is extremely low. Finally, zone files are always sorted into canonical order, thus, specific rules-within-zone-files may not appear in the correct order, in this case separation into a separate zone file which appears earlier in the zone order may be the only solution.

Policy Definitions (Actions and Triggers) The RPZ policy definition uses the terms Policy Actions and Policy Triggers. This can initially appear confusing (perhaps not just initially). RPZ systems use standard RRs within a zone file to define the required policy outcomes. The Policy Triggers are defined using the owner-name (right-hand) part of the RR and the Policy Actions use a combination of the RR type and the left-hand expression as shown below:

Standard RR Formatowner-name (label)RR TypeRR Parameters
Response Policy UsePolicy TriggerDetermines Policy Action

RPZ supports (BIND9.10) the following Policy Actions and Policy Triggers:
Policy Actions
Policy Triggers