ISC-TN-2010-1 Paul Vixie, ISC October-2011 Vernon Schryver, Rhyolite DNS Response Policy Zones (DNS RPZ, Format 3) ISC Technical Note Series This memo describes a method in use inside ISC which may be of use to other members of the Internet technical community. Use of the methods and formats depicted herein is free of any and all license or other encumbrance by the authors or their employers. Copyright Notice Copyright (C) Internet Systems Consortium, Inc. (2010-2011). All Rights Reserved. Distribution of this memo is unlimited, if full attribution is given. Abstract This memo describes a method for expressing DNS response policy inside a specially constructed DNS zone, and for processing the contents of such zones inside recursive name servers. These response policies are intended for use in fighting Internet crime and abuse. Almost all Internet crime relies on DNS, and many new and existing domains at the time of this writing are malicious. 1 - Overview This memo specifies a method of expressing DNS policy information inside specially constructed DNS zones, allowing DNS reputation data producers and consumers to cooperate in the application of policies to real time DNS responses. Using this policy information, DNS resolution for low- reputation domain names can be made to deliberately fail or to return local data such as an alias to a "walled garden". A full description of the expressible policies is given below in Section 2. Configuration examples using ISC BIND Version 9 (BIND9) are given, since this mechanism has already been implemented on that platform. We expect other recursive DNS implementations to also implement these features since the RPZ technology is unencumbered. Vixie & Schryver ISC FORMFEED[Page 1] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 The goal of DNS RPZ is to enable a global market in DNS reputation data, since almost all Internet crime and abuse relies on DNS and since many new and existing domain names at the time of this writing are purely malicious. 2 - Zone Format A DNS Response Policy Zone (RPZ) is a DNS zone, and as such its contents can be transferred between servers (DNS AXFR/IXFR), protected by transaction signatures (DNS TSIG), and expedited by real time change notifications (DNS NOTIFY), all subject to familiar DNS access controls. An RPZ usually does not support query access since it is never required for correct operation. Rather it is the zone transfer of RPZ content from producers to subscribers which effectively publishes the policy data, and it is the transferee's server configuration which promotes RPZ payload data into DNS control plane data. To be a valid DNS zone, an RPZ is required to have an SOA record and at least one NS record at its apex. The SOA record is real, with a serial number used for NOTIFY and IXFR and timers used for AXFR. Because query access is never required, an RPZ's apex NS record will never be used and no parent delegation is required. The zone name itself need not be a unique fully qualified domain name. By convention, a single NS record having the deliberately bogus value "LOCALHOST" is used as a placeholder. The zone's name can be fully qualified to show the identity of its producer or maintainer. The remainder of an RPZ consists of expressions of DNS policy. There four kinds of policy triggers: QNAME, IP, NSIP, and NSDNAME. These are expressed as resource record sets (RRsets). Each type of policy trigger can express any one of four policy actions. All elements described here are from RPZ Format 1 unless otherwise specified. Elements from a higher format number than a name server's implementation level are expected to be invisible to that implementation. 2.1 - Policy Actions Four policy actions can be encoded by RRsets in an RPZ: NXDOMAIN Action A single resource record (RR) consisting of a CNAME whose target is the root domain (.) will cause a response of NXDOMAIN to be returned. Vixie & Schryver ISC FORMFEED[Page 2] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 NODATA Action A single RR consisting of a CNAME whose target is the wildcard top- level domain (*.) will cause a response of NODATA (ANCOUNT=0) to be returned regardless of query type. PASSTHRU Action A single RR consisting of a CNAME whose target is the same as the owner name of the policy RRset expresses an exception, preventing any policy action for this name from being triggered by other subscribed response policy zones. PASSTHRU records are used with other wildcard records that would otherwise match a trusted query name, for trusted IP addresses in CIDR blocks matching other policies, or to exempt a locally trusted name from being affected by externally supplied policy. PASSTHRU records are incompatible with wildcard owner names of QNAME policy triggers (see below), since the query name and the PASSTHRU record's CNAME target name must match exactly, without wildcarding. Important note: for response address triggers (whose owner names are subdomains of "rpz-ip"), and for name server address triggers (whose owner names are subdomains of "rpz-nsip"), as well as for name server name triggers (whose owner names are subdomains of "rpz-nsdname"), the PASSTHRU record must not contain the special parent domain ("rpz- ip", "rpz-nsip", or "rpz-nsdname"). Local Data Action Any other RRset (that is, neither NXDOMAIN, NODATA, nor PASSTHRU) specifies local overriding data which will be used to generate synthetic DNS responses. If any local data policy actions are present then any questions for RR types that are not present will be answered as NODATA (ANCOUNT=0). The common local data is a CNAME RR pointing to a local walled garden. Such CNAME RRs are distinguishable from NXDOMAIN, NODATA, and PASSTHRU actions because the CNAME target name will be neither (.), (*.), nor the question name itself. [Format 3] A special form of local data involves a CNAME RR with a wildcarded target name. This form causes the QNAME to be prepended to the wildcarded target name, thus allowing the walled garden to learn the triggering QNAME value. For example a policy action of "CNAME *.EXAMPLE.COM." and a query name of "EVIL.ORG." will result in a synthetic "CNAME EVIL.ORG.EXAMPLE.COM." The main purpose for this special form is query logging in the walled garden's authority DNS server. Vixie & Schryver ISC FORMFEED[Page 3] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 2.2 - Policy Triggers Three of the types of policy triggers are based on target data (RDATA). Those policies are applied after recursion, so that the cache contains "truth" even if this truth is hidden by current policy. If the policy changes, the original data is available for processing under the changed policy. The fourth type of policy trigger is based only on the query name (QNAME) and is therefore independent of cache contents or recursion results. Four policy triggers can be encoded by RRset owner names in an RPZ: QNAME Trigger The QNAME policy trigger applies to requested domain names (QNAME). The owner name of an RPZ QNAME policy RRset is the relativized name of the domain name about which policy is being expressed. For example, if the RPZ apex name is RPZ.EXAMPLE.ORG, an RRset at DOMAIN.COM.RPZ.EXAMPLE.ORG would affect responses to requests about DOMAIN.COM. Wildcards also work, so, *.DOMAIN.COM.RPZ.EXAMPLE.ORG would trigger on queries to any subdomain of DOMAIN.COM. To control the policy for both a name and its subdomains, two policy RRsets must be used, one for the domain itself and another for a wildcard sub- domain. An example of this is: $ORIGIN RPZ.EXAMPLE.ORG. DOMAIN.COM CNAME . *.DOMAIN.COM CNAME . In this example, queries for both DOMAIN.COM and all subdomains of DOMAIN.COM will result in synthetic NXDOMAIN responses. [Format 2] IP Trigger The IP policy trigger is based on target data (RDATA). It matches IP addresses that would otherwise appear in A and AAAA records in the "answer" section of a DNS response. IP policy RRsets have owner names that are sub-domains of "rpz-ip" relativized to the RPZ apex name, and an encoded IP address or block of addresses. IPv4 addresses are encoded as "prefixlength.B4.B3.B2.B1.rpz-ip". The prefix length must be between 1 and 32. All four bytes, B4, B3, B2, and B1, must be present, and are encoded in decimal ASCII. B4 is the low order octet of the IP address and B1 is the high order octet, just as in the IN-ADDR.ARPA naming convention. Vixie & Schryver ISC FORMFEED[Page 4] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 IPv6 addresses are encoded in a format similar to the standard IPv6 text representation, "prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-ip" Each of W8,...,W1 is a one to four digit hexadecimal ASCII number representing 16 bits of the IPv6 address with no leading zeroes and reversed as in IP6.ARPA. All 8 words must be present unless a "zz" label is present which is analagous to the double-colon (::) in standard IPv6 address representation. The "zz" label is expanded so as to zero-fill the middle portion of the IPv6 address. The prefix length must be between 1 and 128. For example, to force an NXDOMAIN response whenever a truthful response would contain an A RRset having an address in 192.168.1.0/24 unless address 192.168.1.2 is present, the RPZ would contain the following: $ORIGIN RPZ.EXAMPLE.ORG. 24.0.1.168.192.rpz-ip CNAME . 32.2.1.168.192.rpz-ip CNAME 32.2.1.168.192. In another example, to answer NODATA (ANCOUNT=0) whenever a truthful response would contain an AAAA RRset having an address 2001:0002::/48 unless address 2001:0002::3 was present, the RPZ would contain these records: $ORIGIN RPZ.EXAMPLE.ORG. 48.zz.2.2001.rpz-ip CNAME *. 128.3.zz.2.2001.rpz-ip CNAME 128.3.zz.2.2001. [Format 2] NSDNAME Trigger The NSDNAME policy trigger matches name server names (NS RR) of any name server which is in the data path for an RRset present in the answer section of a DNS response. The data path shall be construed to mean all delegation points from (and including) the root zone to the closest enclosing NS RRset for the owner name of the answering RRset. NSDNAME policies are expressed in RRsets in sub-domains of "rpz- nsdname" but otherwise much like QNAME policies. For example, to force an NXDOMAIN answer whenever a name server for the requested domain or one of its parents is NS.DOMAIN.COM, the RPZ would contain the following: $ORIGIN RPZ.EXAMPLE.ORG. NS.DOMAIN.COM.rpz-nsdname CNAME . Vixie & Schryver ISC FORMFEED[Page 5] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 Note: Some implementations of DNS RPZ will exhaustively discover all ancestral zone cuts above the query name and will learn the NS RRset at the apex of each delegated zone. Other implementations of DNS RPZ will know only the zone cut information which has naturally come into the cache, which will often include only parent delegation name server names. Since apex ("below the cut") NS RRsets and delegation NS RRsets need not exactly match, this can lead to instability in DNS RPZ behavior in the presence of zone cuts having differences between the NS RRsets above and below a zone cut. This instability must be taken into account when designing a security policy or testing DNS RPZ. [Format 2] NSIP Trigger The NSIP policy trigger matches name server addresses (an A or AAAA RR that's been referenced by an NS RRset). NSIP is much like NSDNAME (described above) except that the matching is by name server address rather than name server name. NSIP policies are expressed as sub- domains of "rpz-nsip" and have the same sub-domain naming convention as described for "IP" policy triggers above. Note: Some implementations of DNS RPZ will exhaustively discover all IP addresses (V4 and V6) associated with each name server name. Other DNS RPZ implementations will only know the subset of IP addresses which have entered the cache naturally. This can lead to instability in the DNS RPZ behavior since the natural entry of IP addresses into the cache is itself unstable. This instability must be taken into account when designing a security policy or testing DNS RPZ. 3 - Subscriber Behavior RPZs must be primary or secondary zones. They can only be searched in a recursive server's own storage. By default, policies are applied only on DNS requests that ask for recursion (RD=1) and which either do not request DNSSEC metadata (DO=0) or for which no DNSSEC metadata exists. Policies are checked at each stage of resolving a domain name defined by a CNAME or DNAME record, stopping at the first CNAME in the chain with an applicable policy. If a policy trigger results in a modified answer, then that modified answer will include in its "authority" section the SOA RR of the DNS RPZ whose policy was used to generate the modified answer. This SOA RR will tell both the fully qualified name of the DNS RPZ and the serial number of the policy data which was connected to the DNS control plane at the time the answer was modified. Vixie & Schryver ISC FORMFEED[Page 6] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 RPZ zones are loaded in the usual way. For primary zones this may mean loading the contents of a local file into memory, or connecting to a database. For secondary zones this means transfering the zone from the primary server using zone transfer (such as IXFR or AXFR). It is strongly recommended that all secondary zone transfer relationships be protected with transaction signatures (DNS TSIG) and that real time change notification be enabled (DNS NOTIFY). To connect the name server's control plane to the DNS RPZ data plane, an ordered list of RPZ's should be supplied. For each DNS RPZ in this list, it should be possible to specify an overriding policy action to be used for any policy triggers found in that RPZ except in-zone PASSTHRU actions which are always honoured. These override policies should include NXDOMAIN, NODATA, PASSTHRU, GIVEN, and CNAME. GIVEN just explicitly reaffirms the default which is to respect all policy actions found in this DNS RPZ. CNAME is an instance of "local data" which probably points to a walled garden service. It is possible for more than one policy trigger among the various DNS RPZs connected to the name server's control plane to match a given DNS query or DNS response. The precedence rules for multiple matches are as follows: RPZ Ordering Policies from RPZs defined earlier ordered set of DNS RPZs are applied instead of those defined later. Within An RPZ Among policies from a single RPZ, QNAME policies are preferred over IP, IP policies are preferred over NSDNAME, and NSDNAME policies are preferred over NSIP. Name Length Among applicable QNAME or NSDNAME policies within a DNS RPZ, choose the policy that matches the smallest name. Prefix Length Among applicable IP or NSIP policies, use the policy with the longest prefix length. Tie Breaker Given equal prefix lengths, use the policy that matches the smallest IP address. Vixie & Schryver ISC FORMFEED[Page 7] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 4 - Producer Behavior A DNS RPZ producer should make every effort to ensure that incremental zone transfer (IXFR) rather than full zone transfer (AXFR) is used to move new policy data toward subscribers. Also, real time zone change notifications (DNS NOTIFY) should be enabled and tested. DNS RPZ consumers are "stealth slaves" as described in RFC 1996, and as such each such server must be explicitly denoted in the master server's configuration. And because DNS NOTIFY is a lazy protocol, it may be necessary to explicitly trigger the master server's "notify" logic after each update to the DNS RPZ. These operational guidelines are to limit policy data latency, since this latency is critical to both prevention of crime and abuse, and to withdrawal of erroneous or outdated policy. In the data feed for disreputable domains, each addition or deletion or expiration can be handled using DNS UPDATE (see RFC 2136) to trigger normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the subscribing servers well synchronized to the master RPZ. Alternatively, on some primary name servers (such as ISC BIND) it is possible to generate an entirely new primary RPZ file and have the server compute the differences between each new version and its predecessor. In ISC BIND this option is called "ixfr-from-differences" and is known to be performant even for million-rule DNS RPZ's with significant churn on a minute by minute basis. It's good operational practice to include test records in each DNS RPZ to help that DNS RPZ's subscribers verify that response policy rewriting is working. For example, a DNS RPZ might include a QNAME policy record for BAD.EXAMPLE.COM and an IP policy record for 127.0.0.2. A subscriber can verify the correctness of their installation by querying for BAD.EXAMPLE.COM which does not exist in real DNS. If an answer is received it will be from the DNS RPZ. That answer will contain an SOA RR denoting the fully qualified name of the DNS RPZ itself. Vixie & Schryver ISC FORMFEED[Page 8] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 5 - Examples An existing data feed capable of producing an RHSBL can be trivially used to generate a DNS RPZ. If the desired policy is to alias targeted domains to a local walled garden, then for each domain name, generate the following records, one for the name itself and perhaps also one for its sub-domains: bad.domain.com CNAME walled-garden.example.net. *.bad.domain.com CNAME walled-garden.example.net. If it is desirable to return NXDOMAIN for each domain (and its sub- domains in this example), try this: bad.domain.com CNAME . *.bad.domain.com CNAME . If there are specific walled gardens for mail versus everything else: bad.domain.com MX 0 wgmail.example.net. bad.domain.com A 192.168.6.66 *.bad.domain.com MX 0 wgmail.example.net. *.bad.domain.com A 192.168.6.66 A complete example demonstrating every policy trigger and policy action is as follows: Vixie & Schryver ISC FORMFEED[Page 9] ISC-TN-2010-1 DNS Response Policy Zones (Format 3) October 2011 $ORIGIN rpz.example.com. $TTL 1H @ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h) NS LOCALHOST. ; QNAME policy records. ; Note: There are no periods (.) after the (relativised) owner names. nxdomain.domain.com CNAME . ; NXDOMAIN policy nodata.domain.com CNAME *. ; NODATA policy bad.domain.com A 10.0.0.1 ; redirect to walled garden AAAA 2001:2::1 ; do not rewrite OK.DOMAIN.COM (so, PASSTHRU) ok.domain.com CNAME ok.domain.com. bzone.domain.com CNAME garden.example.com. ; redirect X.BZONE.DOMAIN.COM to X.BZONE.DOMAIN.COM.GARDEN.EXAMPLE.COM *.bzone.domain.com CNAME *.garden.example.com. ; IP policy records that rewrite all answers for 127/8 except 127.0.0.1 8.0.0.0.127.rpz-ip CNAME . 32.1.0.0.127.rpz-ip CNAME 32.1.0.0.127. ; PASSTHRU for 127.0.0.1 ; NSDNAME and NSIP policy records that rewrite to NXDOMAIN all responses ; for domains for which NS.DOMAIN.COM is an authoritative DNS server ; (or server for a parent) ; or that have an authoritative server in 2001:2::/48 ns.domain.com.rpz-nsdname CNAME . 48.zz.2.2001.rpz-nsip CNAME . 6 - Bugs As of RPZ format 3, there is no way to express a PASSTHRU action for a wildcard query name. This will be addressed in format 4. 7 - Authors Paul Vixie Internet Systems Consortium Vernon Schryver Rhyolite Software Vixie & Schryver ISC FORMFEED[Page 10]