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]