draft-vixie-dns-rpz-00.txt   draft-vixie-dns-rpz-01.txt 
Domain Name System Operations P. Vixie Domain Name System Operations P. Vixie
Internet-Draft Farsight Security, Inc. Internet-Draft Farsight Security, Inc.
Intended status: Informational V. Schryver Intended status: Informational V. Schryver
Expires: April 14, 2017 Rhyolite Software Expires: April 21, 2017 Rhyolite Software
October 11, 2016 October 18, 2016
Response Policy Zones Response Policy Zones
draft-vixie-dns-rpz-00 draft-vixie-dns-rpz-01
Abstract Abstract
This document describes a method for expressing DNS response policy This document describes a method for expressing DNS response policy
inside a specially constructed DNS zone, and for processing the inside a specially constructed DNS zone, and for processing the
contents of such response policy zones (RPZ) inside recursive name contents of such response policy zones (RPZ) inside recursive name
servers. These "DNS Firewalls" are widely used in fighting Internet servers. These "DNS Firewalls" are widely used in fighting Internet
crime and abuse. crime and abuse.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2017. This Internet-Draft will expire on April 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
This document may not be modified, and derivative works of it may not This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to be created, except to format it for publication as an RFC or to
translate it into languages other than English. translate it into languages other than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Zone Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Zone Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Policy Actions . . . . . . . . . . . . . . . . . . . . . . . 3 3. Policy Actions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Policy Triggers . . . . . . . . . . . . . . . . . . . . . . . 5 4. Policy Triggers . . . . . . . . . . . . . . . . . . . . . . . 5
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 9 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 9
6. Producer Behavior . . . . . . . . . . . . . . . . . . . . . . 11 6. Producer Behavior . . . . . . . . . . . . . . . . . . . . . . 11
7. History and Evolution . . . . . . . . . . . . . . . . . . . . 12 7. History and Evolution . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document describes DNS Firewalls or a method of expressing DNS This document describes DNS Firewalls or a method of expressing DNS
[RFC1034] policy information inside specially constructed DNS zones, [RFC1034] policy information inside specially constructed DNS zones,
allowing DNS reputation data producers and subscribers to cooperate allowing DNS reputation data producers and subscribers to cooperate
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Configuration examples using ISC BIND Version 9 (BIND9) [ISC-ARM] are Configuration examples using ISC BIND Version 9 (BIND9) [ISC-ARM] are
given, because work to add RPZ to that platform was started in 2009. given, because work to add RPZ to that platform was started in 2009.
The RPZ specification itself is free to implement and free to use in The RPZ specification itself is free to implement and free to use in
operation, and so we expect other recursive DNS implementations to operation, and so we expect other recursive DNS implementations to
also implement DNS Firewalls as described by the RPZ specification. also implement DNS Firewalls as described by the RPZ specification.
2. Zone Format 2. Zone Format
A DNS Response Policy Zone (RPZ) is a DNS zone. As such its contents A DNS Response Policy Zone (RPZ) is a DNS zone. As such its contents
can be transferred between servers DNS in whole (AXFR) [RFC5936] or can be transferred between DNS servers in whole (AXFR) [RFC5936] or
incrementally as changes occur (IXFR) [RFC1995], authenticated and incrementally as changes occur (IXFR) [RFC1995], authenticated and
protected by TSIG transaction signatures [RFC2845], and expedited by protected by TSIG transaction signatures [RFC2845], and expedited by
real time change notifications (NOTIFY) [RFC1996], all subject to real time change notifications (NOTIFY) [RFC1996], all subject to
familiar DNS access controls. An RPZ need not support query access familiar DNS access controls. An RPZ need not support query access
since query access is never required. It is the zone transfer of RPZ since query access is never required. It is the zone transfer of RPZ
content from producers to subscribers which effectively publishes the content from producers to subscribers which effectively publishes the
policy data, and it is the subscriber's server configuration which policy data, and it is the subscriber's server configuration which
promotes RPZ payload data into DNS control plane data. 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 To be a valid DNS zone, an RPZ is required to have an SOA record and
skipping to change at page 7, line 21 skipping to change at page 7, line 25
48.zz.2.2001.rpz-ip CNAME *. 48.zz.2.2001.rpz-ip CNAME *.
128.3.zz.2.2001.rpz-ip CNAME rpz-passthru. 128.3.zz.2.2001.rpz-ip CNAME rpz-passthru.
Client IP address Client IP address
The IP addresses of DNS clients sending requests can also be The IP addresses of DNS clients sending requests can also be
triggers. This can be useful for disabling RPZ rewriting for DNS triggers. This can be useful for disabling RPZ rewriting for DNS
clients used to test or investigate. Client IP address triggers clients used to test or investigate. Client IP address triggers
are encoded like response IP address triggers except that they are are encoded like response IP address triggers except that they are
subdomains of rpz-client-ip instead of rpz-ip. For example, the subdomains of rpz-client-ip instead of rpz-ip. For example, the
following would drop all requests from clients in 192.168.1.0/24 following would drop all requests from clients in 192.168.1.0/24
and answer truthfull requests from a client at 2001:2::3. and give truthful answers to requests from a client at 2001:2::3.
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
48.zz.2.2001.rpz-client-ip CNAME *. 48.zz.2.2001.rpz-client-ip CNAME *.
128.3.zz.2.2001.rpz-client-ip CNAME rpz-passthru. 128.3.zz.2.2001.rpz-client-ip CNAME rpz-passthru.
NSDNAME [Format 2] NSDNAME [Format 2]
The NSDNAME policy trigger matches name server names (NS RR) of 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 any name server which is in the data path for an RRset present in
the answer section of a DNS response. The data path is all the answer section of a DNS response. The data path is all
delegation points from (and including) the root zone to the delegation points from (and including) the root zone to the
skipping to change at page 8, line 13 skipping to change at page 8, line 17
direct domain names and IP addresses detected by QNAME and IP direct domain names and IP addresses detected by QNAME and IP
triggers than they can their change NS names and addresses in triggers than they can their change NS names and addresses in
parent domains such as TLDs. parent domains such as TLDs.
NSDNAME policies are encoded as RRsets in sub-domains of NSDNAME policies are encoded as RRsets in sub-domains of
"rpz-nsdname" but otherwise much like QNAME policies. For "rpz-nsdname" but otherwise much like QNAME policies. For
example, to force an NXDOMAIN answer whenever a name server 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 the requested domain or one of its parents is NS.DOMAIN.COM, the
RPZ would contain the following: RPZ would contain the following:
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
NS.DOMAIN.COM.rpz-nsdname CNAME . NS.DOMAIN.COM.rpz-nsdname CNAME .
Some implementations of DNS RPZ will exhaustively discover all Some implementations of DNS RPZ will exhaustively discover all
ancestral zone cuts above the query name and will learn the NS ancestral zone cuts above the query name and will learn the NS
RRset at the apex of each delegated zone. Other implementations RRset at the apex of each delegated zone. Other implementations
will know only the zone cut information which has naturally come will know only the zone cut information which has naturally come
into the cache, which will often include only parent delegation into the cache, which will often include only parent delegation
name server names or "glue." Since apex ("below the cut") NS name server names or "glue." Since apex ("below the cut") NS
RRsets and delegation NS RRsets need not exactly match, this can RRsets and delegation NS RRsets need not exactly match, this can
lead to instability in DNS RPZ behavior in the presence of zone lead to instability in DNS RPZ behavior in the presence of zone
cuts having differences between the NS RRsets above and below a cuts having differences between the NS RRsets above and below a
zone cut. This potential inconsistency must be taken into account zone cut. This potential inconsistency must be taken into account
when designing a security policy or testing DNS RPZ. when designing a security policy or testing DNS RPZ.
The BIND9 and Unbound RPZ implementations use whatever NS RRsets The BIND9 and Unbound RPZ implementations use the NS RRsets in
that are in their caches unless there are none, in which case they their caches unless there are none, in which case they recurse.
recurse. In practice this is best, because the authoritative apex In practice this is best, because the authoritative apex NS RRsets
NS RRsets of domains operated by malefactors is often peculiar. of domains operated by malefactors is often peculiar. For
For example, RRs like "example.com NS ." claiming that the root is example, RRs like "example.com NS ." claiming that the root is
authoritative are popular choices in malefactor apex NS RRsets. authoritative are popular choices in malefactor apex NS RRsets.
NSIP [Format 2] NSIP [Format 2]
The NSIP policy trigger matches name server addresses (an A or 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 AAAA RR that's been referenced by an NS RRset). NSIP is much like
NSDNAME (described above) except that the matching is by name NSDNAME (described above) except that the matching is by name
server address rather than name server name. NSIP policies are server address rather than name server name. NSIP policies are
expressed as sub-domains of "rpz-nsip" and have the same sub- expressed as sub-domains of "rpz-nsip" and have the same sub-
domain naming convention as described for response IP policy domain naming convention as described for response IP policy
triggers above. triggers above.
In other words, an NSIP trigger is checked by first considering In other words, an NSIP trigger is checked by first considering
all of the IP address for all the named servers (or domain names all of the IP addresses for all the named servers (or domain names
in the NS records) for the query domain (QNAME), then the IP in the NS records) for the query domain (QNAME), then the IP
addresses for name servers for the parent of the qname, and so on addresses for name servers for the parent of the qname, and so on
until the name servers for the root (.) have been checked. This until the name servers for the root (.) have been checked. This
process stops immediately when the trigger is hit. process stops immediately when the trigger is hit.
This process can be very expensive, especially when it comes to This process can be very expensive, especially when it comes to
checking the many NS and IP RRs for the TLDs and the root. checking the many NS and IP RRs for the TLDs and the root.
Because the IP addresses of name servers for the root and the TLDs Because the IP addresses of name servers for the root and the TLDs
are rarely used as RPZ triggers, common RPZ implementations have a are rarely used as RPZ triggers, common RPZ implementations have a
"min-ns-dots" parameter that stops NSIP and NSDNAME checking "min-ns-dots" parameter that stops NSIP and NSDNAME checking
skipping to change at page 9, line 28 skipping to change at page 9, line 30
As with NS Domain Name or NSDNAME triggers, some implementations As with NS Domain Name or NSDNAME triggers, some implementations
of DNS RPZ will exhaustively discover all IP addresses (V4 and V6) of DNS RPZ will exhaustively discover all IP addresses (V4 and V6)
associated with each name server name. Other DNS RPZ associated with each name server name. Other DNS RPZ
implementations will only know the subset of IP addresses which implementations will only know the subset of IP addresses which
have entered the cache naturally. This can lead to instabilities have entered the cache naturally. This can lead to instabilities
in the DNS RPZ behavior since the natural entry of IP addresses in the DNS RPZ behavior since the natural entry of IP addresses
into the cache is itself unstable. This instability must be taken into the cache is itself unstable. This instability must be taken
into account when designing a security policy or testing DNS RPZ. into account when designing a security policy or testing DNS RPZ.
Also like NSDNAME triggers, the BIND9 and Unbound RPZ Also like NSDNAME triggers, the BIND9 and Unbound RPZ
implementations use whatever A or AAAA RRsets that are in their implementations use the A or AAAA RRsets that are in their caches
caches for NS domains unless there are none, in which case they for NS domains unless there are none, in which case they recurse.
recurse. In practice this is best, not only because the In practice this is best, not only because the authoritative A and
authoritative A and AAAA RRsets of name servers for the domains of AAAA RRsets of name servers for the domains of malefactors are
malefactors are often imaginitive, but because even when they are often imaginative, but because even when they are reasonable, the
reasonable, the authoritative DNS servers for their NS domains are authoritative DNS servers for their NS domains are often extremely
often extremely slow or broken. slow or broken.
5. Subscriber Behavior 5. Subscriber Behavior
RPZs must be primary or secondary zones at subscriber recursive RPZs must be primary or secondary zones at subscriber recursive
resolvers. They can only be searched in a recursive server's own resolvers. They can be searched only in a recursive server's own
storage, because additional network transactions for DNS resolvers storage, because additional network transactions for DNS resolvers
are extremely undesirable. are extremely undesirable.
By default, policies are applied only on DNS requests that ask for By default, policies are applied only on DNS requests that ask for
recursion (RD=1) and which either do not request DNSSEC metadata recursion (RD=1) and which either do not request DNSSEC metadata
(DO=0) or for which no DNSSEC metadata exists. (DO=0) or for which no DNSSEC metadata exists. This default can be
overriden; see Section 9.
Policies are checked at each stage of resolving a domain name defined 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 by a CNAME or DNAME record, stopping at the first CNAME in the chain
with an applicable policy. CNAME targets in a CNAME chain are with an applicable policy. CNAME targets in a CNAME chain are
checked as if they were query names. checked as if they were query names.
If a policy trigger results in a modified answer, then that modified 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 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 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 RR will tell both the fully qualified name of the DNS RPZ and the
skipping to change at page 10, line 51 skipping to change at page 11, line 11
RPZ Ordering RPZ Ordering
Policies from RPZs defined earlier ordered set of DNS RPZs are Policies from RPZs defined earlier ordered set of DNS RPZs are
applied instead of those defined later. applied instead of those defined later.
Within An RPZ Within An RPZ
Among policies from a single RPZ, QNAME policies are preferred Among policies from a single RPZ, QNAME policies are preferred
over IP, IP policies are preferred over NSDNAME, and NSDNAME over IP, IP policies are preferred over NSDNAME, and NSDNAME
policies are preferred over NSIP. policies are preferred over NSIP.
Name Length Name Length
Among applicable QNAME or NSDNAME policies within a DNS RPZ, Among triggered QNAME or NSDNAME policies within a DNS RPZ, choose
choose the policy that matches the smallest name. the policy that matches the smallest domain name.
Domain names are sorted using the DNSSEC canonical DNS name order
described in section 6.1 of RFC 4034 [RFC4034]. The last label of
a domain name is most significant. Labels are compared as if they
were words in a dictionary so that a label that is a prefix of a
second label is smaller than the second. Characters in labels are
sorted by their values as US-ASCII characters except that
uppercase letters are treated as if they were lowercase.
Prefix Length Prefix Length
Among applicable IP or NSIP policies, use the policy with the Among triggered IP or NSIP policies, use the policy with the
longest prefix length. longest internal policy zone prefix length. The internal prefix
length of an IPv6 address trigger is the numeric value of the
first label that defines it as described in Section 4. The
internal prefix length of an IPv4 trigger is the numeric value of
its first label plus 112. This adjustment makes IPv4 triggers
work the same as equivalent IPv4-compatible IPv6 address triggers.
It also tends to favor IPv4 triggers (See section 2.5.5.1 of RFC
4291 [RFC4291] about IPv4-compatible IPv6 addresses.)
Tie Breaker Tie Breaker
Given equal prefix lengths, use the policy that matches the Given equal internal prefix lengths, use the IP or NSIP policy
smallest IP address. that matches the smallest IP address. They are ordered by their
representations as domain names described in Section 4, including
the leading, unadjusted prefix length.
By default, when a QNAME or client IP address policy is triggered and When a QNAME or client IP address policy is triggered and the trigger
the trigger is of such high precedence that it dominates all other is of such high precedence that it dominates all other possible
possible triggers (e.g. it is in the first configured policy zone), triggers (e.g. it is in the first configured policy zone), the
the resolver continues to check and fill its cache by recursion as if resolver can be configured to continue checking and filling its cache
it did not already know the answer. This denies operators of by recursion as if it did not already know the answer. This denies
authority servers for listed domains data about whether they are operators of authority servers for listed domains information about
listed. whether they are listed.
6. Producer Behavior 6. Producer Behavior
A DNS RPZ producer should make every effort to ensure that A DNS RPZ producer should make every effort to ensure that
incremental zone transfer (IXFR [RFC1995]) rather than full zone incremental zone transfer (IXFR [RFC1995]) rather than full zone
transfer (AXFR [RFC5936]) is used to move new policy data toward transfer (AXFR [RFC5936]) is used to move new policy data toward
subscribers. Also, real time zone change notifications (DNS NOTIFY subscribers. Also, real time zone change notifications (DNS NOTIFY
[RFC1996] should be enabled and tested. DNS RPZ subscribers are
[RFC1996]) should be enabled and tested. DNS RPZ subscribers are
"stealth slaves" as described in RFC 1996, and each such server must "stealth slaves" as described in RFC 1996, and each such server must
be explicitly denoted in the master server's configuration. Because be explicitly listed in the master server's configuration as
DNS NOTIFY is a lazy protocol, it may be necessary to explicitly necessary to allow zone transfers from the stealth slave, as well to
trigger the master server's "notify" logic after each update to the ensure that zone change notifications are sent to it. Because DNS
DNS RPZ. These operational guidelines are to limit policy data NOTIFY is a lazy protocol, it may be necessary to explicitly trigger
latency, since minimal latency is critical to both prevention of the master server's "notify" logic after each update to the DNS RPZ.
crime and abuse, and to withdrawal of erroneous or outdated policy. These operational guidelines are to limit policy data latency, since
minimal 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 In the data feed for disreputable domains, each addition or deletion
or expiration can be handled using DNS UPDATE [RFC2136] to trigger or expiration can be handled using DNS UPDATE [RFC2136] to trigger
normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the
subscribing servers well synchronized to the master RPZ. subscribing servers well synchronized to the master RPZ.
Alternatively, on some primary name servers (such as ISC BIND) it is Alternatively, on some primary name servers (such as ISC BIND) it is
possible to generate an entirely new primary RPZ file and have the possible to generate an entirely new primary RPZ file and have the
server compute the differences between each new version and its server compute the differences between each new version and its
predecessor. In ISC BIND this option is called "ixfr-from- predecessor. In ISC BIND this option is called "ixfr-from-
differences" and is known to be performant even for million-rule DNS differences" and is known to be performant even for million-rule DNS
skipping to change at page 12, line 13 skipping to change at page 12, line 40
policy record for BAD.EXAMPLE.COM and an IP policy record for policy record for BAD.EXAMPLE.COM and an IP policy record for
127.0.0.2. A subscriber can verify the correctness of their 127.0.0.2. A subscriber can verify the correctness of their
installation by querying for BAD.EXAMPLE.COM which does not exist in 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. 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 That answer will contain an SOA RR denoting the fully qualified name
of the DNS RPZ itself. of the DNS RPZ itself.
7. History and Evolution 7. History and Evolution
RPZ was previously described in a technical note from Internet RPZ was previously described in a technical note from Internet
Systems Consortium [ISC-RPZ]. A more up to date description was in Systems Consortium [ISC-RPZ]. A more up to date description appeared
chapter 6 of the "BIND 9 Administrator Reference Manual" [ISC-ARM]. in chapter 6 of the "BIND 9 Administrator Reference Manual" [ISC-ARM]
as of 2010.
RPZ was designed by Paul Vixie and Vernon Schryver in 2009. The RPZ was designed by Paul Vixie and Vernon Schryver in 2009. The
initial implementation and first patch adding it to BIND was written initial implementation and first patch adding it to BIND were written
by Vernon Schryver in late 2009. Patches for various versions of by Vernon Schryver in late 2009. Patches for various versions of
BIND9 including 9.4, 9.6, and 9.7 were distributed from FTP servers BIND9 including 9.4, 9.6, and 9.7 were distributed from FTP servers
at redbarn.org and rhyolite.com 2010. at redbarn.org and rhyolite.com starting in 2010.
If all RPZ triggers and actions had been foreseen at the start in If all RPZ triggers and actions had been foreseen at the start in
2009, they would probably have been encoded differently. Instead RPZ 2009, they would probably have been encoded differently. Instead RPZ
grew incrementally, and upward compatibility required continuing grew incrementally, and upward compatibility required continuing
support of the original encodings. support of the original encodings.
Today, with a number of commercial RPZ providers with many users and Today, with a number of commercial RPZ providers with many users and
no functional problems with the encodings, any lack of aesthetic no functional problems with the encodings, any lack of aesthetic
appeal is balanced by the ever increasing weight of the installed appeal is balanced by the ever increasing weight of the installed
base. For example, it is impossible to replace the original QNAME base. For example, it is impossible to replace the original QNAME
trigger encoding NXDOMAIN and NODATA policy action encodings with trigger encoding NXDOMAIN and NODATA policy action encodings with
encodings that involve rpz-* psuedo-TLDs at RPZ providers without encodings that involve rpz-* pseudo-TLDs at RPZ providers without
breaking the many existing RPZ subscriber installations. The breaking the many existing RPZ subscriber installations. The
original, deprecated [Format 1] PASSTHRU encoding of a CNAME pointing original, deprecated [Format 1] PASSTHRU encoding of a CNAME pointing
to the trigger qname might still be in use in local, private policy to the trigger qname might still be in use in local, private policy
zones, and so it is still recognized by RPZ subscriber zones, and so it is still recognized by RPZ subscriber
implementations. implementations.
The initial RPZ idea was only to deny the existence of objectionable The initial RPZ idea was only to deny the existence of objectionable
domain names, and so there were only QNAME triggers and NXDOMAIN domain names, and so there were only QNAME triggers and NXDOMAIN
actions. Given that single kind of trigger, encoding it as the owner actions. Given that single kind of trigger, encoding it as the owner
name of a policy record was clearly best. A CNAME pointing to the name of a policy record was clearly best. A CNAME pointing to the
root domain (.) is a legal and valid but not generally useful record, root domain (.) is a legal and valid but not generally useful record,
and so that was the encoding for the NXDOMAIN action. The encoding and so that became the encoding for the NXDOMAIN action. The
of the NODATA action as "CNAME *." followed similar reasoning. encoding of the NODATA action as "CNAME *." followed similar
Requests for more kinds of triggers and actions required a more reasoning. Requests for more kinds of triggers and actions required
general scheme, and so they are encoded as CNAMES with targets in a more general scheme, and so they are encoded as CNAMES with targets
bogus TLDs owner names with DNS labels that start with "rpz_". in bogus TLDs owner names with DNS labels that start with "rpz_".
8. IANA Considerations 8. IANA Considerations
No actions are required from IANA as result of the publication of No actions are required from IANA as result of the publication of
this document. this document.
9. Security Considerations 9. Security Considerations
RPZ is a mechanism for providing "untruthful" DNS results from RPZ is a mechanism for providing "untruthful" DNS results from
recursive servers. However, RPZ does not increase the intrinsic DNS recursive servers. Nevertheless, RPZ does not exacerbate the
vulnerabilites at recursive servers to falsifying DNS data. RPZ existing vulnerability of recursive servers to falsified DNS data.
merely formalizes and facilitates modifying DNS data on its way from RPZ merely formalizes and facilitates modifying DNS data on its way
DNS authority servers to clients. Moreover, DNSSEC (see RFC 4033 from DNS authority servers to clients. However, the use of DNSSEC
[RFC4033] and RFC 4034 [RFC4034]) prevents changes to DNS data by (see RFC 4033 [RFC4033] and RFC 4034 [RFC4034]) prevents such changes
RPZ. to DNS data by RPZ.
By default, DNS resolvers using RPZ do not modify DNS results when Therefore, by default, DNS resolvers using RPZ avoid modifying DNS
DNSSEC signatures are available and requested by the DNS client. results when DNSSEC signatures are available and are requested by the
When the common "BREAK-DNSSEC" configuration setting is used, RPZ DNS client. However, when the common "BREAK-DNSSEC" configuration
using resolvers ignore DNSSEC. The result of "BREAK-DNSSEC" at DNS setting is used, RPZ-using resolvers do modify query results, even
clients using DNSSEC is functionally similar to an RPZ NXDOMAIN when this renders them DNSSEC-invalid. In such a case, a querying
policy action; the DNS client is blocked from malefactor domains. client which checks DNSSEC will ignore the invalid result, and will
effectively be blocked from malefactor domains; this behaviour is
functionally similar to that caused by an RPZ NXDOMAIN policy action.
The policy zones might be considered sensitive, because they contain The policy zones might be considered sensitive, because they contain
information about malefactors. Like other DNS zones in most information about malefactors. Like other DNS zones in most
situations, RPZs are transferred from sources to subscribers as situations, RPZs are transferred from sources to subscribers as
cleartext vulnerable to observation. However, TSIG transaction cleartext vulnerable to observation. However, TSIG transaction
signatures [RFC2845] SHOULD be used to authenticate and protect RPZ signatures [RFC2845] SHOULD be used to authenticate and protect RPZ
contents from modification. contents from modification.
Recursive servers using RPZ are often configured to complete Recursive servers using RPZ are often configured to complete
recursion even if a policy trigger provides a rewritten answer recursion even if a policy trigger provides a rewritten answer
without needing recursion. This impedes malefactors observing without needing recursion. This impedes malefactors observing
requests from their own authority servers from inferring whether RPZ requests from their own authority servers from inferring whether RPZ
is in use and whether their RRs are listed. "qname-wait-recurse" is is in use and whether their RRs are listed. "qname-wait-recurse" is
a common configuration switch that controls this behavior. a common configuration switch that controls this behavior.
10. References 10. Acknowledgements
10.1. Normative References The authors gratefully acknowledge the contributed material and
editorial scrutiny of Anne Bennett
11. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996,
<http://www.rfc-editor.org/info/rfc1995>. <http://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
skipping to change at page 14, line 34 skipping to change at page 15, line 20
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>. <http://www.rfc-editor.org/info/rfc5936>.
10.2. Informative References 11.2. Informative References
[ISC-ARM] Internet Systems Consortium, "BIND 9 Administrator [ISC-ARM] Internet Systems Consortium, "BIND 9 Administrator
Reference Manual, Reference Manual,
https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/ https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/
Bv9ARM.ch06.html#rpz", 2016. Bv9ARM.ch06.html#rpz", 2016.
[ISC-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS [ISC-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS
RPZ, Format 3), https://ftp.isc.org/isc/dnsrpz/isc-tn- RPZ, Format 3), https://ftp.isc.org/isc/dnsrpz/isc-tn-
2010-1.txt", 2010. 2010-1.txt", 2010.
skipping to change at page 15, line 13 skipping to change at page 15, line 51
2012-1.txt", 2012. 2012-1.txt", 2012.
Appendix A. Examples Appendix A. Examples
An existing data feed capable of producing an RHSBL can be trivially 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 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, targeted domains to a local walled garden, then for each domain name,
generate the following records, one for the name itself and perhaps generate the following records, one for the name itself and perhaps
also one for its sub-domains: also one for its sub-domains:
bad.domain.com CNAME walled-garden.example.net. bad.domain.com CNAME walled-garden.example.net.
*.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- If it is desirable to return NXDOMAIN for each domain (and its sub-
domains in this example), try this: domains in this example), try this:
bad.domain.com CNAME . bad.domain.com CNAME .
*.bad.domain.com CNAME . *.bad.domain.com CNAME .
If there are specific walled gardens for mail versus everything else: If there are specific walled gardens for mail versus everything else:
bad.domain.com MX 0 wgmail.example.net. bad.domain.com MX 0 wgmail.example.net.
bad.domain.com A 192.168.6.66 bad.domain.com A 192.168.6.66
*.bad.domain.com MX 0 wgmail.example.net. *.bad.domain.com MX 0 wgmail.example.net.
*.bad.domain.com A 192.168.6.66 *.bad.domain.com A 192.168.6.66
An extended example follows: An extended example follows:
$ORIGIN rpz.example.com. $ORIGIN rpz.example.com.
$TTL 1H $TTL 1H
@ SOA LOCALHOST. named-mgr.example.com. ( @ SOA LOCALHOST. named-mgr.example.com. (
1 1h 15m 30d 2h) NS LOCALHOST. 1 1h 15m 30d 2h) NS LOCALHOST.
; QNAME policy records. ; QNAME policy records.
; There are no periods (.) after the relative owner names. ; There are no periods (.) after the relative owner names.
nxdomain.domain.com CNAME . ; NXDOMAIN policy nxdomain.domain.com CNAME . ; NXDOMAIN policy
nodata.domain.com CNAME *. ; NODATA policy nodata.domain.com CNAME *. ; NODATA policy
; redirect to walled garden ; redirect to walled garden
bad.domain.com A 10.0.0.1 bad.domain.com A 10.0.0.1
AAAA 2001:2::1 AAAA 2001:2::1
; do not rewrite OK.DOMAIN.COM (so, PASSTHRU) ; do not rewrite OK.DOMAIN.COM (so, PASSTHRU)
ok.domain.com CNAME rpz-passthru. ok.domain.com CNAME rpz-passthru.
bzone.domain.com CNAME garden.example.com. bzone.domain.com CNAME garden.example.com.
; redirect X.BZONE.DOMAIN.COM to ; redirect X.BZONE.DOMAIN.COM to
; X.BZONE.DOMAIN.COM.GARDEN.EXAMPLE.COM ; X.BZONE.DOMAIN.COM.GARDEN.EXAMPLE.COM
*.bzone.domain.com CNAME *.garden.example.com. *.bzone.domain.com CNAME *.garden.example.com.
; rewrite all answers for 127/8 except 127.0.0.1 ; rewrite all answers for 127/8 except 127.0.0.1
8.0.0.0.127.rpz-ip CNAME . 8.0.0.0.127.rpz-ip CNAME .
32.1.0.0.127.rpz-ip CNAME rpz-passthru. 32.1.0.0.127.rpz-ip CNAME rpz-passthru.
; rewrite to NXDOMAIN all responses; for domains for which ; rewrite to NXDOMAIN all responses; for domains for which
; NS.DOMAIN.COM is an authoritative DNS server or a server ; NS.DOMAIN.COM is an authoritative DNS server or a server
; for a parent) or that have an authoritative server ; for a parent) or that have an authoritative server
; in 2001:2::/48 ; in 2001:2::/48
ns.domain.com.rpz-nsdname CNAME . ns.domain.com.rpz-nsdname CNAME .
48.zz.2.2001.rpz-nsip CNAME . 48.zz.2.2001.rpz-nsip CNAME .
Authors' Addresses Authors' Addresses
Paul Vixie Paul Vixie
Farsight Security, Inc. Farsight Security, Inc.
Email: paul@redbarn.org Email: paul@redbarn.org
Vernon Schryver Vernon Schryver
Rhyolite Software Rhyolite Software
 End of changes. 41 change blocks. 
102 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/