ISC-TN-2010-1-B3 Paul Vixie, ISC December-2010 (Draft 3) Vernon Schryver, Rhyolite DNS Response Policy Zones (DNS RPZ) ISC Technical Note Series This memo describes a methodology 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). 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 e-crime, since all Internet crime relies on DNS and many new and existing domains at the time of this writing are malicious. 1 - Overview 1.1. This memo specifies a method of expressing DNS policy information inside a specially constructed DNS zone, allowing cooperating DNS reputation data producers and consumers to cooperate in the application of such policy to real time DNS responses. This does for recursive DNS servers what the anti-spam DNSBL (DNS Block List, ne RBL) and RHSBL (Right Hand Side Block List) technologies do for e-mail servers. Under this scheme, DNS resolution for low-reputation domain names can be deliberately made to fail or to return local data such as an alias to a "walled garden". No support is offered for NXDOMAIN remapping ("typo- squatting"). A full description of the expressible policies is given below in Section 2. Vixie & Schryver ISC [Page 1] ISC-TN-2010-1-B3 DNS Response Policy Zones December-2010 1.2. Configuration examples using ISC BIND Version 9 (BIND9) will be given, since this technology has already been implemented on that platform. We expect other recursive DNS implementations to also implement these features since the technology is unencumbered by the authors and our employers and since the power of a multi-producer multi- consumer multi-vendor market to fight e-crime will be much stronger than any single-producer or single-vendor market could ever be. Our goal for DNS RPZ is a new global market in DNS reputation data, since all e-crime relies on DNS and since many new and existing domain names at the time of this writing are purely malicious. 2 - Zone Format 2.1. A DNS Response Policy Zone is a DNS zone, and as such it can be transferred between servers (DNS AXFR/IXFR), protected by transaction signatures (DNS TSIG), and expedited by real time change notifications (DNS NOTIFY). As a DNS zone, it is required to have an SOA record and at least one NS record at its apex. The SOA record is real, having a serial number used for NOTIFY and IXFR, and having various timers used for AXFR. However, the NS record will never be used, and no parent delegation is required. In fact the zone name itself need not be a unique fully qualified domain name. By convention, a single NS record having the bogus value "LOCALHOST." is provided as a placeholder, and the zone's name is fully qualified to show the identity of its producer/maintainer. 2.2. The remainder of the zone is expressions of DNS policy. The policies can apply to domain names (QNAME) or the target data (RDATA) of names. Target data policy expressions are described below in section 6. The owner name of a Response Policy Zone (RPZ) QNAME policy resource record set (RRset) is the relativised name of the domain name about which policy is being expressed. For example, in a policy zone called RPZ.ISC.ORG, an RRset at WWW.VIX.COM.RPZ.ISC.ORG would affect responses to lookups of WWW.VIX.COM. DNS RPZ RRset owner names can be wildcarded according to normal rules, for example *.VIX.COM.RPZ.ISC.ORG would affect responses for any subdomain of VIX.COM. This means that in order to affect both a domain and its subdomains, policy must be entered for both that domain and its wildcard subdomain. 2.3. Four possible policies can be expressed, with these encodings: 2.3.1. NXDOMAIN. An RRset consisting of a single CNAME whose target is the root domain (.) will cause a response of NXDOMAIN to be returned. Vixie & Schryver ISC [Page 2] ISC-TN-2010-1-B3 DNS Response Policy Zones December-2010 2.3.2. NODATA. An RRset consisting of a single CNAME whose target is the wildcard top-level domain (*.) will cause a response of NODATA (ANCOUNT=0) to be returned regardless of query type. 2.3.3. NO-OP. An RRset consisting of a single CNAME whose target is the query name itself expresses an exception, preventing any policy action for this name. This can be necessary in the presence of a wildcard that would otherwise match a query name, the presence of trusted IP addresses in larger CIDR blocks, or to exempt a locally trusted name from being affected by externally supplied policy. Note that exceptions cannot be expressed for wildcard names since the CNAME target would not match any query names in that case. 2.3.4. Local data. An RRset matching the QTYPE of the original query will be returned. If some RRset exists but does not match the QTYPE of the query then NODATA (ANCOUNT=0) will be returned. 3 - Subscriber Behaviour 3.1. In ISC BIND Version 9 (BIND9), the RPZ feature is enabled in a subscriber's DNS server by an option statement called "response-policy" at the global or per-view level. For example: options { // other stuff response-policy { zone "dns-policy1.vix.com"; zone "dns-policy2.vix.com" policy given; zone "dns-policy3.vix.com" policy NO-OP; zone "dns-policy4.vix.com" policy NXDOMAIN; zone "dns-policy5.vix.com" policy NODATA; zone "dns-policy6.vix.com" policy CNAME walled-garden.isp.net; }; }; One or more RPZs can be specified in the single response-policy statement allowed at the global level and in each view. These RPZs will be tested in left to right order, stopping with the zone with a match. An "exception" policy matched in any RPZ will end all RPZ processing for the matching query. Thus, local override RPZs should be defined earlier than external RPZs. Each zone statement in the "response-policy" option can include a "policy" clause that overrides all policies expressed in RRsets in the zone other than NO-OP or exceptions. "Policy NO-OP", "policy NXDOMAIN", Vixie & Schryver ISC [Page 3] ISC-TN-2010-1-B3 DNS Response Policy Zones December-2010 and "policy NODATA" override clauses give the same results as their normal expressions in a policy zone. "Policy given" is the same as omitting a policy clause. "CNAME walled-garden.isp.net" is equivalent to replacing all records other than NO-OP exceptions with that CNAME. 3.2. Designated RPZs must be primary or secondary zones, since RPZs cannot be queried on the wire, only searched in the recursive server's own storage. A "zone" statement must therefore be given for the RPZ, with all necessary "masters" clauses, each having all necessary "key" subclauses. It is often a good idea to include "allow-query {none;};" in the zone statement to refuse ordinary, non-rewriting queries of the policy data. 4 - Producer Behaviour 4.1. Any existing data feed capable of producing an RHSBL can be trivially used to generate a DNS RPZ. If the desired policy is to alias all e-crime 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 subdomains: bad_domain CNAME walled-garden.isp.net. *.bad_domain CNAME walled-garden.isp.net. If on the other hand it's desireable to return NXDOMAIN for each domain (and its subdomains, in this example): bad_domain CNAME . *.bad_domain CNAME . Or if there are specific walled gardens for e-mail vs. everything else: bad_domain MX 0 wgmail.isp.net. bad_domain A 192.168.6.66 *.bad_domain MX 0 wgmail.isp.net. *.bad_domain A 192.168.6.66 4.2. In the data feed for e-crime domains, each addition or deletion or expiration can be handled using DNS UPDATE (see RFC 2136) in order to trigger normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the subscribing servers well synchronized to the master RPZ. Alternatively, on BIND9 servers, the RPZ master server operator can turn on "ixfr-from-differences" in order to generate DNS NOTIFY and subsequent DNS IXFR after the "rndc reload" action that ought to Vixie & Schryver ISC [Page 4] ISC-TN-2010-1-B3 DNS Response Policy Zones December-2010 accompany each new generation of a RPZ on the master server. (This is performant enough even for million-name zones which change once a minute.) 4.3. The master server should list all subscribers with "also-notify" for the RPZ, in order to ensure that DNS NOTIFY messages are sent to every subscriber. Otherwise DNS NOTIFY will only be sent to servers listed in the RPZ's apex NS RRset, which will usually be a useless placeholder (see Section 2.1). While it's theoretically possible to list subscriber nameservers in the apex NS RRset, this could lead to the false expectation that queries will sometimes be sent to those nameservers. "also-notify" is just operationally safer. Noting that DNS NOTIFY is a lazy protocol, every zone change should be accompanied by an "rndc notify" action to force immediate propagation of that change. This could be done in batches, for example do a continuous stream of DNS UPDATE and then do "rndc reload" once a minute from cron. 4.4. Large numbers of subscribers may require a hierarchical RPZ distribution network consisting of one or more RPZ master servers who feed a set of intermediate RPZ stealth slave servers who in turn feed sets of subscribers. With some kind of automatic generation of "also- notify" lists, a subscriber base numbering in the tens of thousands of slave servers is practical. 4.5. In all cases, subscribers will need to set their RPZ "masters" to include all possible RPZ masters from whom DNS NOTIFY requests might be received. So, any redundancy in the master servers must also be expressed in the slave servers. 4.6. It's strongly recommended that DNS TSIG be used to both restrict access to a RPZ (so that only subscribers can access it) and authenticate a producer (so that only the actual producer can generate and publish it.) 4.7. A data producer with a diverse subscriber base may find that some of their subscribers want an NXDOMAIN policy and others will want a walled garden approach. There are two solutions here, one is to have each subscriber do a local transform of the base NXDOMAIN policy into a local walled garden policy, the other is to offer per-subscriber walled garden editions of an RPZ for an added fee. 5 - Application Behaviour DNS RPZ could be used as a weak IP reputation system, in that applications who call gethostbyaddr() to do PTR lookups would be Vixie & Schryver ISC [Page 5] ISC-TN-2010-1-B3 DNS Response Policy Zones December-2010 affected by DNS RPZ elements in the IN-ADDR.ARPA or IP6.ARPA name spaces. This is called "weak" because most applications do not perform such lookups and that's a growing trend. In a subsequent revision to DNS RPZ, full IP reputation support will be added, such that the owner name of an RPZ RRset can be some kind of stylized notation for an IPv4 or IPv6 netblock. (Such revisions will be invisible to previous generation RPZ subscribers, but will otherwise be backward-compatible.) 6 - Target Data Policy It is also possible to express policies based on target data (RDATA). Such policy are applied after resolution, so that the cache will contain "truth" even if this truth is hidden (by policy) from requesters. If policy changes, the original data is available for processing under the new policy. The available policy encodings are as follows. 6.1. Direct A/AAAA or IP policies. If an A or AAAA RRset contains an address which is covered by policy, then the policy is applied to the response. Policy of this form is expressed as subdomains of "rpz-ip". The affected network address block is encoded an ASCII string, on octet boundaries for IPv4 and on word boundaries for IPv6, with the leading label being the size of the netblock. For example, to force an NXDOMAIN answer whenever an A RRset contains an address in 192.168.1.0/24 other than 192.168.1.2, the RPZ would contain the following: 24.0.1.168.192.rpz-ip CNAME . 32.2.1.168.192.rpz-ip CNAME 32.2.1.168.192 Similarly, to generate NODATA (ANCOUNT=0) whenever an AAAA RRset contains an address 2001:0002::/48 other than 2001:0002::3, the RPZ would contain this record: 48.zz.2.2001.rpz-ip CNAME *. 128.3.zz.2.2001.rpz-ip CNAME *. The full address is always specified with four octets of decimal ASCII for 32-bit IPv4 or eight words of hexadecimal ASCII for 128-bit IPv6. Leading zeroes of octets or words are never included. The first or least significant pair or more of zero words in IPv6 addresses must be compressed as almost usual with "zz" instead of "::". 6.2. Nameserver name or NSDNAME policies. A future specification might include policies for owner names of NS records as subdomains of "rpz- nsdname" much like the the QNAME policies described above. There is a proof of concept implementation, but it is only a proof of concept Vixie & Schryver ISC [Page 6] ISC-TN-2010-1-B3 DNS Response Policy Zones December-2010 because of problems related to validating delegations as described in http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 6.3. Nameserver address or NSIP policies. A future specification might also include policies for IPv4 and IPv6 address in NS records as subdomains of "rpz-nsip" much like the subdomains of "rpz-ip". There is also a proof of concept implementation of this mechanism, but it has larger delegation validation problems. 7 - Acknowledgements Many folks have been asking for this for many years. Barry Greene deserves special credit for unsticking this idea and championing the public release of this technology. Vixie & Schryver ISC [Page 7]