draft-vixie-dns-rpz-02.txt   draft-vixie-dns-rpz-03.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: June 19, 2017 Rhyolite Software Expires: June 19, 2017 Rhyolite Software, LLC
December 16, 2016 December 16, 2016
DNS Response Policy Zones DNS Response Policy Zones (RPZ)
draft-vixie-dns-rpz-02 draft-vixie-dns-rpz-04
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 recursive name inside a specially constructed DNS zone, and for recursive name
servers to use such poicy to return modified results to DNS clients. servers to use such policy to return modified results to DNS clients.
The modified DNS results can stop access to selected HTTP servers, The modified DNS results can stop access to selected HTTP servers,
redirect users to "walled gardens," block objectionable email, and redirect users to "walled gardens", block objectionable email, and
otherwise defend against attack. These "DNS Firewalls" are widely otherwise defend against attack. These "DNS Firewalls" are widely
used in fighting Internet crime and abuse. used in fighting Internet crime and abuse.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Discussion Venue . . . . . . . . . . . . . . . . . . . . 3 1.1. Discussion Venue . . . . . . . . . . . . . . . . . . . . 3
2. Zone Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Zone Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Policy Actions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Policy Actions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The "NXDOMAIN" Action . . . . . . . . . . . . . . . . . . 4 3.1. The "NXDOMAIN" Action (CNAME .) . . . . . . . . . . . . . 5
3.2. The "NODATA" Action . . . . . . . . . . . . . . . . . . . 4 3.2. The "NODATA" Action (CNAME *.) . . . . . . . . . . . . . 5
3.3. The "PASSTHRU" Action . . . . . . . . . . . . . . . . . . 5 3.3. The "PASSTHRU" Action (CNAME rpz-passthru.) . . . . . . . 5
3.4. The "DROP" Action . . . . . . . . . . . . . . . . . . . . 5 3.4. The "DROP" Action (CNAME rpz-drop.) . . . . . . . . . . . 6
3.5. The "TCP-Only" Action . . . . . . . . . . . . . . . . . . 5 3.5. The "TCP-Only" Action (CNAME rpz-tcp-only.) . . . . . . . 6
3.6. The "Local Data" Action . . . . . . . . . . . . . . . . . 6 3.6. The "Local Data" Action (arbitrary RR types) . . . . . . 6
4. Policy Triggers . . . . . . . . . . . . . . . . . . . . . . . 6 4. Policy Triggers . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. The "Client IP Address" trigger (.rpz-client-ip) . . . . 7 4.1. The "Client IP Address" Trigger (.rpz-client-ip) . . . . 9
4.2. The "QNAME" trigger ("example.com") . . . . . . . . . . . 8 4.2. The "QNAME" Trigger ("example.com") . . . . . . . . . . . 10
4.3. The "Response IP address" trigger (.rpz-ip) . . . . . . . 8 4.3. The "Response IP Address" Trigger (.rpz-ip) . . . . . . . 10
4.4. The "NSDNAME" trigger (.rpz-nsdname) . . . . . . . . . . 9 4.4. The "NSDNAME" Trigger (.rpz-nsdname) . . . . . . . . . . 11
4.5. The "NSIP" trigger (.rpz-nsip) . . . . . . . . . . . . . 10 4.5. The "NSIP" Trigger (.rpz-nsip) . . . . . . . . . . . . . 12
5. Application of the Policy . . . . . . . . . . . . . . . . . . 11 5. Precedence Rules . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Precedence Rules. . . . . . . . . . . . . . . . . . . . . 12 5.1. "CNAME or DNAME Chain Position" Precedence Rule . . . . . 14
6. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 14 5.2. "RPZ Ordering" Precedence Rule . . . . . . . . . . . . . 14
7. Producer Behavior . . . . . . . . . . . . . . . . . . . . . . 15 5.3. "Domain Name Matching" Precedence Rule . . . . . . . . . 14
8. History and Evolution . . . . . . . . . . . . . . . . . . . . 16 5.4. "Trigger Type" Precedence Rule . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.5. "Name Order" Precedence Rule . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.6. "Prefix Length" Precedence Rule . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5.7. "IP Address Order" Precedence Rule . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Application of the Policy . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.1. Per-Zone Action Overrides . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 19 7. Producer Behavior . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 8. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 9. Implementation Considerations . . . . . . . . . . . . . . . . 20
9.1. Avoid Waiting for QNAME Recursion . . . . . . . . . . . . 21
9.2. Check Parents Domains versus Zone Cuts . . . . . . . . . 21
9.3. Abbreviate the Data Path for NSDNAME and NSIP Checks . . 22
9.4. Use Glue for NSDNAME and NSIP Checks . . . . . . . . . . 22
9.5. Reduce Zone Size using Implied Rules . . . . . . . . . . 23
10. History and Evolution . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12.1. DNS Data Security . . . . . . . . . . . . . . . . . . . 25
12.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.3. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.4. Counterintelligence . . . . . . . . . . . . . . . . . . 25
12.5. NSIP, NSDNAME, Glue, and Authoritative RRsets . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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, a method of expressing DNS This document describes DNS Firewalls, a method of expressing DNS
[RFC1034] policy information inside specially constructed DNS zones, [RFC1034] response policy information inside specially constructed
known as Response Policy Zones (RPZs). RPZs allow DNS reputation DNS zones, known as Response Policy Zones (RPZs). RPZs allow
data producers and subscribers to cooperate in the application of Internet security policy producers and subscribers to cooperate in
policies to modify DNS responses in real time. Using the policy the application of policies to modify DNS responses in real time.
information, DNS resolution for low-reputation DNS data can be made Using the policy information, DNS resolution for potentially unsafe
to deliberately fail or to return local data such as an alias to a DNS data can be made to deliberately fail or to return local data
"walled garden". such as an alias to a "walled garden".
A site's DNS response policy consists of the set of rules expressed A site's DNS response policy consists of the set of rules expressed
in all of the RPZs that it uses. Each rule, expressed as an RRset, in all of the RPZs that it uses. Each rule, expressed as an RRset,
consists of a trigger and an action. A full description of the consists of a trigger (left hand side or owner name) and an action
expressible policies is given in Section 3 (actions) and Section 4 (right hand side). A full description of the expressible policies is
(triggers), while Section 6 explains how the rules are applied. given in Section 3 (actions) and Section 4 (triggers).
Configuration examples are given using ISC BIND Version 9 (BIND9) Configuration examples are given using ISC BIND Version 9 (BIND9)
[ISC-ARM] syntax, because work to add RPZ to that platform was [ISC-ARM] syntax, because work to add RPZ to that platform was
started earliest (in 2009). The RPZ specification itself is free to started earliest (in 2009). The RPZ specification itself is free to
implement and free to use in operation. It has been implemented in implement and free to use in operation. It has been implemented in
other name server software. We expect that in time, additional other name server software. We expect that in time, additional
recursive DNS implementations will also implement DNS Firewalls as recursive DNS implementations will also implement DNS Firewalls as
described by this RPZ specification. described by this RPZ specification.
1.1. Discussion Venue 1.1. Discussion Venue
skipping to change at page 3, line 38 skipping to change at page 4, line 9
list. http://lists.redbarn.org/mailman/listinfo/dnsfirewalls offers list. http://lists.redbarn.org/mailman/listinfo/dnsfirewalls offers
subscriptions and archives. See also https://dnsrpz.info/ subscriptions and archives. See also https://dnsrpz.info/
[NOTE TO EDITOR: This section must be removed before this Internet [NOTE TO EDITOR: This section must be removed before this Internet
Draft is published as an RFC.] Draft is published as an RFC.]
2. Zone Format 2. Zone Format
A DNS Response Policy Zone (RPZ) is a DNS zone. Like any DNS zone, A DNS Response Policy Zone (RPZ) is a DNS zone. Like any DNS zone,
an RPZ consists of RRsets or sets of resource records (RRs) with a an RPZ consists of RRsets or sets of resource records (RRs) with a
common owner name and type. RRsets other than SOA and NS specify common owner name and type. RRsets other than SOA, NS, and DNSSEC-
actions and triggers. The owner name (left hand side) of each RRset related [RFC4034] specify actions and triggers. The owner name (left
expresses a policy trigger, while the RDATA (right hand side) encodes hand side) of each RRset expresses a policy trigger, while the RDATA
the action to taken when the trigger matches. Depending on the type (right hand side) encodes the action to be taken when the trigger
of trigger (see Section 4), a particular characteristic of the DNS matches. Depending on the type of trigger (see Section 4), a
query or response is checked. particular characteristic of the DNS response is checked.
Characteristics that can be checked include the domain name (QNAME),
the IP address of the querying client, IP addresses or domain names
in the answer section of the response, and authoritative name server
names and addresses.
Because an RPZ is a valid DNS zone, its contents can be transferred Because an RPZ is a valid DNS zone, its contents can be transferred
between DNS servers in whole (AXFR) [RFC5936] or incrementally as between DNS servers in whole (AXFR) [RFC5936] or incrementally as
changes occur (IXFR) [RFC1995], authenticated and protected by TSIG changes occur (IXFR) [RFC1995], can be authenticated and protected by
transaction signatures [RFC2845] and expedited by real time change TSIG transaction signatures [RFC2845], and can have update
notifications (NOTIFY) [RFC1996], all subject to familiar DNS access propagation expedited by real time change notifications (NOTIFY)
controls. An RPZ need not support query access since query access is [RFC1996], all subject to familiar DNS access controls. An RPZ need
never required. It is the zone transfer of RPZ content from not support query access since query access is never required. It is
producers to subscribers which effectively publishes the policy data, the zone transfer of RPZ content from producers to subscribers which
and it is the subscriber's server configuration which promotes RPZ effectively publishes the policy data. However, it is the
payload data into DNS control plane data. subscribers' configurations of their recursive name servers which
promote RPZ payload data into the control plane data of their
individual name servers.
Any valid DNS zone (including an RPZ) is required to have an SOA Every valid DNS zone including an RPZ has an SOA record and at least
record and at least one NS record at its apex, which is why the SOA one NS record at its apex, which is why the SOA and NS records of an
and NS records of an RPZ cannot themselves be used to encode DNS RPZ cannot themselves be used to encode DNS response policy rules.
response policy.
The RPZ's SOA record is real, with a serial number used for NOTIFY The RPZ's SOA record is real, with a serial number used for NOTIFY
and IXFR, and timers used for AXFR and IXFR. The MNAME field or and IXFR, and timers used for AXFR and IXFR. The MNAME field or
domain name of the primary source of the zone and the RNAME field or domain name of the primary source of the zone and the RNAME field or
mailbox of the person responsible for the zone are often used by RPZ mailbox of the person responsible for the zone SHOULD be used by RPZ
providers to label their policy zones. providers to label their policy zones.
As for an RPZ's apex NS record(s), since query access is never The apex NS RRset will never be used since RPZ does not rely on query
required, they will never be used. Similarly, no parent delegation access. Similarly, no parent delegation is required for normal
is required for normal operation of the RPZ. Thus, by convention, a operation of the RPZ. Thus, by convention, a single NS record having
single NS record having the deliberately bogus RDATA of "LOCALHOST." the deliberately bogus RDATA of "LOCALHOST." is used as a
is used as a placeholder. placeholder.
While loading an RPZ, any data which is not syntactically valid for
DNS should cause normal error processing as would occur for any DNS
zone. If an RR found in an RPZ is meaningless or unusable for
response policy purposes, then the containing RRset SHOULD be
ignored, and an error MAY be logged.
The format of RPZs has undergone several revisions since work began The format of RPZs has undergone several revisions since work began
(see Section 8). All POLICY described here are from RPZ Format 1 (see Section 10, History and Evolution). All policy triggers and
unless otherwise noted. Policy triggers from a higher format number actions described here are valid as of Format 3. Policy triggers
than a recursive name server's implementation level are expected to from a higher format number than a recursive name server's
be invisible to that implementation. Policy actions from a higher implementation level are expected to be harmless to that
format number are likely to be misinterpreted as CNAME local data by implementation. Policy actions from a higher format number are
older implementations. likely to be misinterpreted as CNAME Local Data by older
implementations. When possible, implementations SHOULD treat policy
triggers or actions of higher format numbers as they treat other
errors, as described above.
3. Policy Actions 3. Policy Actions
An RPZ resource record can specify any of six results or actions. An RPZ resource record can specify any of six results or actions.
3.1. The "NXDOMAIN" Action 3.1. The "NXDOMAIN" Action (CNAME .)
A single resource record (RR) consisting of a CNAME whose target is A single resource record (RR) consisting of a CNAME whose target is
the root domain (.) will cause a response of NXDOMAIN to be returned. the root domain (.) will cause a response of NXDOMAIN to be returned.
This is the most commonly used RPZ action. This is the most commonly used RPZ action.
3.2. The "NODATA" Action $ORIGIN RPZ.EXAMPLE.ORG.
example.com CNAME . ; return NXDOMAIN
*.example.com CNAME . ; return NXDOMAIN
3.2. The "NODATA" Action (CNAME *.)
A single RR consisting of a CNAME whose target is the wildcard top- 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 level domain (*.) will cause a response of NODATA (ANCOUNT=0) to be
returned regardless of query type. returned regardless of query type.
3.3. The "PASSTHRU" Action $ORIGIN RPZ.EXAMPLE.ORG.
example.com CNAME *. ; return NODATA
It is sometimes necessary to exempt some DNS responses from the *.example.com CNAME *. ; return NODATA
response policy rule that covers an entire domain or a large IP
address block. Exempting some clients of a DNS resolver from all RPZ
rewriting can also be useful for research into attackers and for
debugging. The PASSTHRU action is intended to override other,
usually more general policies. It should be written so that it
appears at a higher precedence than the policies it must override.
See Section 5.1 about the precedence rules.
This policy zone record
$ORIGIN RPZ.EXAMPLE.ORG.
ok.example.com CNAME rpz-passthru.
would exempt requests for ok.example.com from the NXDOMAIN policy or 3.3. The "PASSTHRU" Action (CNAME rpz-passthru.)
action of the following record:
$ORIGIN RPZ.EXAMPLE.ORG. It is sometimes necessary to exempt some DNS responses from a policy
example.com CNAME . rule that covers an entire domain or a large IP address block.
*.example.com CNAME . Exempting some clients of a DNS resolver from all RPZ rewriting can
also be useful for research into attackers and for debugging. The
PASSTHRU action is intended to override other, usually more general
policies. The trigger for the PASSTHRU action MUST have a higher
precedence than the policies that it should override (see Section 5,
Precedence Rules).
The deprecated original encoding of the PASSTHRU action was a CNAME In the example below, the first PASSTHRU record exempts requests for
with a target equal to the QNAME field of the DNS request. That a particular host from the NXDOMAIN policy action of the subsequent
encoding could not be used with some desirable triggers. records. The second PASSTHRU record exempts responses to the DNS
client at 192.0.2.1 from being modified:
3.4. The "DROP" Action $ORIGIN RPZ.EXAMPLE.ORG.
ok.example.com CNAME rpz-passthru.
32.1.2.0.192.rpz-client-ip CNAME rpz-passthru.
example.com CNAME .
*.example.com CNAME .
The "DROP" policy that consists of discarding the request and 3.4. The "DROP" Action (CNAME rpz-drop.)
response is specified by a CNAME whose target is "rpz-drop". For
example, with
$ORIGIN RPZ.EXAMPLE.ORG. The DROP policy that results in discarding the request and response
example.com CNAME rpz-drop. is specified by a CNAME whose target is "rpz-drop". For example, the
following rule mandates that nothing be sent to a DNS client trying
to resolve "EXAMPLE.COM", not even a DNS error response:
nothing is sent to a DNS client trying to resolve example.com, not $ORIGIN RPZ.EXAMPLE.ORG.
even a DNS error response. example.com CNAME rpz-drop.
3.5. The "TCP-Only" Action 3.5. The "TCP-Only" Action (CNAME rpz-tcp-only.)
The "TCP-Only" policy is specified by a CNAME whose target is The TCP-Only action is specified by a CNAME whose target is
"rpz-tcp-only". It changes UDP responses to short, truncated DNS "rpz-tcp-only". It changes UDP responses to short, truncated DNS
responses that require the DNS client to try again with TCP. It is responses that require the DNS client to try again with TCP. It is
used to mitigate distributed DNS reflection attacks and is similar to used to mitigate distributed DNS reflection attacks and is similar to
the "slip" parameter of DNS Response Rate Limiting (RRL) [ISC-RRL]. the "slip" parameter of DNS Response Rate Limiting (RRL) [ISC-RRL].
3.6. The "Local Data" Action $ORIGIN RPZ.EXAMPLE.ORG.
example.com CNAME rpz-tcp-only.
An RRset that is neither a special RPZ encoding of an action nor one 3.6. The "Local Data" Action (arbitrary RR types)
of several problematic record types specifies local data used to
generate synthetic DNS responses. The special RPZ encodings are
CNAMEs with targets of NXDOMAIN (.), NODATA (*.), a top level domain
starting with "rpz-", or a child of a top level domain starting with
"rpz-". Problematic record types include NS and DNSSEC (see
[RFC4034]), because their appearance in responses would be invalid or
confuse DNS clients. Local data DNAME RRsets are also commonly
rejected by RPZ subscribers for internal implementation and other
reasons. If any local data policy actions are present, then any
request for an RR type that is not present in the local data is
answered as NODATA (ANCOUNT=0) as if the recursive DNS server using
RPZ were authoritative for the query name.
The most common local data is a CNAME RR pointing to a walled garden. A set of RRsets with a common trigger owner name (see Section 4) that
Such CNAME RRs are distinguishable from other rpz actions, because includes neither a special CNAME RPZ encoding of an action nor one of
the CNAME target name will not be the root (.), nor the root wildcard the problematic record types listed below specifies data to be used
(*.), nor be a subdomain of a top level domain that starts with to generate synthetic DNS responses. The most common Local Data is a
"rpz-". CNAME RR pointing to a walled garden, although other record types are
also used.
A special form of local data involves a CNAME RR with a wildcarded $ORIGIN RPZ.EXAMPLE.ORG.
bad1.example.com CNAME garden.example.net.
bad2.example.com A garden-web.example.net.
bad2.example.com MX garden-mail.example.net.
32.3.2.0.192.rpz-client-ip A quarantine.example.net.
Note that because an RPZ is a valid DNS zone, if the action of a
policy rule contains a CNAME RR, then no other RRs are allowed for
that owner name (trigger).
The special RPZ encodings which are not to be taken as Local Data are
CNAMEs with targets that are:
+ "." (NXDOMAIN action),
+ "*." (NODATA action),
+ a top level domain starting with "rpz-",
+ a child of a top level domain starting with "rpz-".
The problematic types and records which also do not encode Local Data
actions include:
+ SOA records,
+ NS records,
+ DNAME records,
+ all DNSSEC-related records (see [RFC4034]).
RRsets of problematic record types MUST NOT be included in RPZ data,
because their appearance in responses would be invalid or confuse DNS
clients.
When a Local Data policy rule matches, the RRsets of Local Data are
used to generate the response as if they comprised all of the
authoritative data for the QNAME. If the requested type (QTYPE) is
ANY, then all of these Local Data RRsets are returned. Otherwise,
the RRset of the requested RR type is returned, or a CNAME is
returned if it is available. If no CNAME nor RRset of the requested
type is available, then the response is normally NODATA (ANCOUNT=0).
Using the example above, if client 192.0.2.3 asks for MX records, it
will receive NODATA, because the policy rule with the matching Client
IP Address trigger contains RRsets of RRtype A but none of RRtype MX.
This normal NODATA response when there are no Local Data records of
the requested type can be changed with the LOCAL-DATA-OR-PASSTHRU or
LOCAL-DATA-OR-DISABLED overrides described in Section 6.1.
A special form of Local Data involves a CNAME RR with a wildcarded
target name. Wildcards are not valid as CNAME targets in ordinary target name. Wildcards are not valid as CNAME targets in ordinary
DNS zones. This special form causes the QNAME to be prepended to the DNS zones. However, a wildcard in an RPZ Local Data CNAME target
wildcarded target to communicate the triggering QNAME value to the causes the matching QNAME to be prepended to the target in the
walled garden DNS server. For example a policy action of rewritten response, which communicates this QNAME value to the walled
"CNAME *.EXAMPLE.COM" and a query name of "EVIL.ORG." will result in garden DNS server for that DNS server's logs.
a synthetic response of "EVIL.ORG CNAME EVIL.ORG.EXAMPLE.COM." The
purpose for this special form is query logging in the walled garden's For example a policy Local Data action of "CNAME *.EXAMPLE.COM"
DNS server. applied to a QNAME of "EVIL.EXAMPLE.ORG." will result in a synthetic
response that starts with the RR
"EVIL.EXAMPLE.ORG CNAME EVIL.EXAMPLE.ORG.EXAMPLE.COM". Resolving the
CNAME target "EVIL.EXAMPLE.ORG.EXAMPLE.COM" into an RRset of the
originally requested type generally requires sending a request for
that type and a QNAME of "EVIL.EXAMPLE.ORG.EXAMPLE.COM" to a DNS
server for the walled garden, "EXAMPLE.COM". As usual when a CNAME
is encountered while computing a response, the response from the
walled garden DNS server concerning "EVIL.EXAMPLE.ORG.EXAMPLE.COM"
determines the rest of the final rewritten response.
In the example below, a client that asks for A RRs for
"BAD.EXAMPLE.COM" will receive a response starting with
"BAD.EXAMPLE.COM CNAME BAD.EXAMPLE.COM.GARDEN.EXAMPLE.NET". The DNS
server using RPZ will then probably try to resolve
"BAD.EXAMPLE.COM.GARDEN.EXAMPLE.NET" by requesting A RRs from the
authority for "GARDEN.EXAMPLE.NET". That authority should answer
with NODATA, NXDOMAIN, or an A RRset, but in any case can log the
request to show that a request for "BAD.EXAMPLE.COM" has been
received.
$ORIGIN RPZ.EXAMPLE.ORG.
bad.example.com CNAME *.garden.example.net.
4. Policy Triggers 4. Policy Triggers
There are five types of RPZ triggers, and they are encoded by RRset There are five types of RPZ triggers, and they are encoded by RRset
owner names (left hand sides) in an RPZ. owner names (left hand sides) in an RPZ.
Two of these types of trigger match characteristics of the DNS query: Two of these trigger types match characteristics of the DNS query:
"Client IP address" and "QNAME". They are independent of cache Client IP Address and QNAME. While these two trigger typess are
contents or recursion results, but must be checked conceptually when independent of cache contents or recursion results, still
the response is ready, including after any needed recursion. conceptually they must be checked only once the response is ready,
Recursion can sometimes be skipped, but only if the RPZ result would because they compete for precedence (see Section 5) with other
not be changed (see Section 5.1). trigger types which depend on what happens during recursion.
The other three types of triggers are based on characteristics of the The other three trigger types are based on characteristics of the DNS
DNS response, that is, on the RDATA to be returned to the client, or response, that is, on the RDATA to be returned to the client, or in
in some cases, on NS-related RDATA used while recursively obtaining some cases, on NS-related RDATA used while recursively obtaining the
the final response, regardless of whether or not those NS records or final response, regardless of whether or not those NS or NS-related
additional data are themselves to be returned to the client. These records are themselves to be returned to the client. These three
three trigger types are: "Response IP address", "NSDNAME", and trigger types are: Response IP Address, NSDNAME, and NSIP.
"NSIP".
All policies are conceptually applied after recursion, so that the Neither the TTL fields of RRs in the answer section nor the query
recursive DNS resolver's cache contains either nothing or "truth," type (QTYPE) in the question section of responses are used as RPZ
even if this truth is hidden by current policy. If the policy triggers, although the QTYPE is used to select appropriate RRsets
changes, the original, unmodified data is available for processing among the RRsets of matching Local Data rules (Section 3.6).
under the changed policy.
4.1. The "Client IP Address" trigger (.rpz-client-ip) All policies are conceptually applied after recursion, even though in
practice recursion can sometimes be skipped, if doing so would not
change the RPZ result (see Section 5, Precedence Rules and Section 9,
Implementation Considerations). As a result, the recursive DNS
resolver's cache contains either nothing or "truth", even if this
truth is hidden by current policy. If the policy changes, the
original, unmodified data is available for processing under the
changed policy.
4.1. The "Client IP Address" Trigger (.rpz-client-ip)
The IP addresses of DNS clients sending requests can be used as The IP addresses of DNS clients sending requests can be used as
triggers, which can be useful for disabling RPZ rewriting for DNS triggers, which can be useful for disabling RPZ rewriting for DNS
clients used to test or investigate. Client IP address policy RRsets clients used for testing or investigating, or for quarantining
have owner names that are subdomains of "rpz-client-ip" relativized compromised clients. Client IP Address policy RRsets have owner
to the RPZ apex name, preceded by an encoded IP address or block of names that are subdomains of "rpz-client-ip" relativized to the RPZ
addresses. apex name, preceded by an encoded IP address or block of addresses.
For example, the following would drop all requests from clients in For example, the following would drop all requests from clients in
192.0.2.0/24 and give truthful answers to requests from a client at 192.0.2.0/24 and give truthful answers to requests from a client at
2001:db8::3. 2001:db8::3.
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
24.0.2.0.192.rpz-client-ip CNAME rpz-drop. 24.0.2.0.192.rpz-client-ip CNAME rpz-drop.
128.3.zz.db8.2001.rpz-client-ip CNAME rpz-passthru. 128.3.zz.db8.2001.rpz-client-ip CNAME rpz-passthru.
4.1.1. IP address encoding in triggers 4.1.1. IP address encoding in triggers
The IPv4 address (or address block) "B1.B2.B3.B4/prefix" is encoded The IPv4 address or address block "B1.B2.B3.B4/prefix" is encoded in
in an RPZ trigger as "prefix.B4.B3.B2.B1", with the address octets an RPZ trigger as "prefix.B4.B3.B2.B1", with the address octets
reversed just as in the IN-ADDR.ARPA naming convention. (See reversed just as in the IN-ADDR.ARPA naming convention described in
[RFC1034].) The prefix length ("prefix") must be between 1 and 32. [RFC1034]. The prefix length ("prefix") is a decimal integer from 1
All four bytes, B4, B3, B2, and B1, must be present and must be to 32. All four octets, B4, B3, B2, and B1, must be present and are
written in decimal ASCII. also decimal integers. To avoid confusion with octal notation,
leading zeros MUST be suppressed.
For example, the address block 192.0.2.0/24 would be encoded as For example, the address block 192.0.2.0/24 is encoded as
"24.0.2.0.192". "24.0.2.0.192".
The IPv6 address (or address block beginning at) The IPv6 address or address block beginning at
"W1:W2:W3:W4:W5:W6:W7:W8" is encoded in a format similar to the "W1:W2:W3:W4:W5:W6:W7:W8" is encoded in a format similar to the
standard IPv6 text representation (see [RFC5952]), again reversed: standard IPv6 text representation (see [RFC5952]), again reversed:
"prefix.W8.W7.W6.W5.W4.W3.W2.W1". Each of W8,...,W1 is a one- to "prefix.W8.W7.W6.W5.W4.W3.W2.W1". The prefix length ("prefix") is a
four-digit hexadecimal ASCII number representing 16 bits of the IPv6 decimal integer from 1 to 128. Each of W8,...,W1 is a one- to four-
address with no leading zeroes. All 8 words must be present unless a digit hexadecimal number representing 16 bits of the IPv6 address.
"zz" label is present. The "zz" label is analogous to the double- As in [RFC5952], in order to avoid confusion with octal notation,
colon (::) in the standard IPv6 address representation. The "zz" leading zeroes MUST be suppressed.
label is expanded to zero-fill the middle portion of the IPv6
address. Exactly one "zz" label must be present if there are two or
more consecutive zero words in the address. The prefix length
("prefix") must be between 1 and 128
For example, the address 2001:db8::3 (with implied prefix length 128) All 8 hextets must be present unless a "zz" label is present. The
"zz" label is analogous to the double-colon (::) in [RFC5952], and it
is required and allowed just as the double-colon is required and
allowed in that document. In particular, the longest possible
sequence of zero-valued fields MUST be compressed to "zz". If there
exists more than one sequence of zero-valued fields of identical
length, then only the last such sequence is compressed. Note that
[RFC5952] specifies compressing the first such sequence, but our
notation here reverses the order of fields, and so must also reverse
the selection of which zero sequence to compress.
For example, the address 2001:db8::3 with a prefix length of 128
would be encoded as "128.3.zz.db8.2001". would be encoded as "128.3.zz.db8.2001".
4.2. The "QNAME" trigger ("example.com") In the case of an address block, either IPv4 or IPv6, the address
part MUST NOT contain any non-zero bits after the section indicated
by the prefix length. For example, "8.2.0.0.10.rpz-client-ip" is not
a valid trigger, because in the address "10.0.0.2" expressed in
binary notation, a one occurs outside the first 8 bits or prefix of
the address block.
The QNAME policy trigger matches on requested domains, the QNAME 4.2. The "QNAME" Trigger ("example.com")
field in the question section of DNS requests and responses. (See
[RFC1035].) The owner name of an RPZ QNAME policy RRset is the The QNAME policy trigger matches requested domains, that is, the
QNAME field of the question sections in DNS requests and responses.
(See [RFC1035].) The owner name of an RPZ QNAME policy RRset is the
relativized name of the domain name about which policy is being relativized name of the domain name about which policy is being
expressed. For example, if the RPZ apex name is RPZ.EXAMPLE.ORG, an expressed. For example, if the RPZ apex name is "RPZ.EXAMPLE.ORG",
RRset at example.com.RPZ.EXAMPLE.ORG would affect responses to an RRset at "EXAMPLE.COM.RPZ.EXAMPLE.ORG" would affect responses to
requests about example.com. requests about "EXAMPLE.COM".
Wildcards also work, and so the owner name Wildcards work as expected, so the owner name
"*.example.com.RPZ.EXAMPLE.ORG" would trigger on queries to any "*.EXAMPLE.COM.RPZ.EXAMPLE.ORG" would match queries for any subdomain
subdomain of example.com. To control the policy for both a name and of "EXAMPLE.COM". To control the policy for both a name and its
its subdomains, two policy RRsets must be used, one for the domain subdomains, two policy RRsets must be used, one for the domain itself
itself and another for a wildcard subdomain. In the following and another for a wildcard subdomain. In the following example,
example, queries for both example.com and all subdomains of queries for both "EXAMPLE.COM" and all subdomains of "EXAMPLE.COM"
example.com will result in synthetic NXDOMAIN responses. will result in synthetic NXDOMAIN responses.
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
example.com CNAME . example.com CNAME .
*.example.com CNAME . *.example.com CNAME .
4.3. The "Response IP address" trigger (.rpz-ip) 4.3. The "Response IP Address" Trigger (.rpz-ip)
The response IP policy trigger matches response contents (RDATA): it The Response IP Address trigger matches IP addresses that would
matches IP addresses that would otherwise appear in A and AAAA appear in the unaltered DNS response contents, specifically the RDATA
records in the answer section of a DNS response. IP addresses in the of A or AAAA records in the answer sections of DNS responses. IP
authority and additional sections are not considered. Response IP addresses in the authority and additional sections are not
policy RRsets have owner names that are subdomains of "rpz-ip" considered. Response IP Address policy RRsets have owner names that
relativized to the RPZ apex name, and an encoded IP address or block are subdomains of "rpz-ip" relativized to the RPZ apex name, and an
of addresses. The IP address encodes are identical to those encoded IP address or block of addresses. The IP address encodings
described in Section 4.1.1for Client IP Address triggers. are identical to those described in Section 4.1.1 for Client IP
Address triggers.
For example, to force an NXDOMAIN response whenever a truthful For example, to force an NXDOMAIN response whenever a truthful
response would contain an answer section A RRset having an address in response would contain an answer section A RRset having an address in
192.0.2.0/24 unless address 192.0.2.2 is present, the RPZ would 192.0.2.0/24 unless address 192.0.2.2 is present, the RPZ would
contain these records: contain these records:
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
24.0.2.0.192.rpz-ip CNAME . 24.0.2.0.192.rpz-ip CNAME .
32.2.2.0.192.rpz-ip CNAME rpz-passthru. 32.2.2.0.192.rpz-ip CNAME rpz-passthru.
In another example, to answer NODATA (ANCOUNT=0) whenever a truthful In another example, to answer NODATA (ANCOUNT=0) whenever a truthful
response would contain an answer AAAA RRset having an address response would contain an answer AAAA RRset having an address
2001:db8:101::/48 unless address 2001:db8:101::3 was present, the RPZ 2001:db8:101::/48 unless address 2001:db8:101::3 was present, the RPZ
would contain these records: would contain these records:
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
48.zz.101.db8.2001.rpz-ip CNAME *. 48.zz.101.db8.2001.rpz-ip CNAME *.
128.3.zz.101:db8.2001.rpz-ip CNAME rpz-passthru. 128.3.zz.101:db8.2001.rpz-ip CNAME rpz-passthru.
Please refer to Section 5.1 to understand how the above exception Please refer to Section 5 (Precedence Rules) to understand how the
mechanims work. above exception mechanisms work.
4.4. The "NSDNAME" trigger (.rpz-nsdname) 4.4. The "NSDNAME" Trigger (.rpz-nsdname)
The NSDNAME policy trigger matches name server names (NS RR) of any The NSDNAME policy trigger matches name server names (NS RR) of all
name server which is in the data path for an RRset present in the name servers in the data paths for all RRsets that would be present
answer section of a DNS response. The data path is all delegation in the answer section of the unaltered DNS response.
points from (and including) the root zone to the closest enclosing NS
RRset for the owner name of the answering RRset.
In other words, an NSDNAME trigger is checked by first considering The data path for a given answer RRset consists of all delegation
the named servers (domain names in the NS records) for the query points from (and including) the root zone down to the closest
domain (QNAME), then the name servers for the parent of the query enclosing NS RRset for the owner name of that RRset. Names in the
domain name, and so on until the name servers for the root (.) have RDATA of answer RRs including CNAME, DNAME, SRV, and MX are not
been checked or there fewer periods (.) in the domain name than the themselves directly relevant, but CNAME and DNAME target names are
value of a local "min-ns-dots" parameter. See Section 4.4.1.1 below. indirectly relevant if they cause RRsets to be added to the answer
section, in which case it is the data paths of the added RRsets that
matter. In the case of a DNAME answer, the owner name of an added
synthetic CNAME is likely to differ from the target name in the DNAME
RR. Recall also that the target of a CNAME is not added to the
response if the QTYPE is ANY or CNAME or if this target cannot be
resolved (e.g. NXDOMAIN or SERVFAIL errors).
NSDNAME policies are encoded as RRsets in subdomains of "rpz-nsdname" NSDNAME policies are encoded as RRsets in subdomains of "rpz-nsdname"
but otherwise much like QNAME policies (xref target="qname"/>). For but otherwise are much like QNAME policies (Section 4.2). For
example, to force an NXDOMAIN answer whenever a name server for the example, to force an NXDOMAIN answer whenever a name server for the
requested domain or one of its parents is ns.example.com, the RPZ requested domain or one of its parents is "NS.EXAMPLE.COM", the RPZ
would contain the following: would contain the following:
$ORIGIN RPZ.EXAMPLE.ORG. $ORIGIN RPZ.EXAMPLE.ORG.
ns.example.com.rpz-nsdname CNAME . ns.example.com.rpz-nsdname CNAME .
4.4.1. Implementation considerations for NSDNAME triggers The NS records used for this calculation are either delegations (NS
RRs in the authority sections of answers from authorities for the
parent zone) or authoritative data from the zone itself. An
implementation MAY use either, both, or whichever is currently
available. See Section 9.4 about some implementation considerations
for this choice, and Section 12.5 about security considerations.
Note that these considerations apply also to NSIP triggers described An RPZ implementation MAY be configurable to avoid checking all the
in Section 4.5 below. way up to the root and to perform only partial NSDNAME checks; see
Section 9.3 on "min-ns-dots".
4.4.1.1. Performance issues 4.5. The "NSIP" Trigger (.rpz-nsip)
The process of traversing the data path from the level nearest the The NSIP policy trigger matches name server addresses, that is A or
queried record to the top (root domain) level can be expensive, AAAA RRs referenced by an NS RRset. NSIP is like NSDNAME
especially when it comes to checking the many NS records for the top (Section 4.4) except that the matching is by name server address
level domains and the root. Because the name servers for the root rather than name server name. NSIP policies are expressed as
and the TLDs are rarely used as RPZ triggers, some RPZ subdomains of "rpz-nsip" and have the same subdomain naming
implementations have a "min-ns-dots" parameter that stops NSDNAME and convention as that described for encoding IP addresses in Response IP
NSIP checking early. Address triggers (Section 4.1.1).
Despite their costs, NSDNAME and NSIP triggers can be more effective In a process similar to that for an NSDNAME trigger, an NSIP trigger
than QNAME and IP triggers. Miscreants can more easily change their is checked by considering all of the IP addresses for all of the name
direct domain names and IP addresses (which are detected by QNAME and servers in the data paths for all RRsets that would be present in the
IP triggers) than they can their change NS names and addresses answer section of the unaltered DNS response.
(detected by NSDNAME and NSIP triggers) in parent domains such as
TLDs.
4.4.1.2. Caching of NS records and related address data As with NSDNAME triggers, the data path for a given RRset consists of
all delegation points from (and including) the root zone down to the
closest enclosing NS RRset for the owner name of that RRset. Also
like NSDNAME triggers, the RDATA in these RRsets (other than the IP
addresses of the name servers) are not directly relevant.
Some implementations of DNS RPZ will attempt to exhaustively discover For example, to force an NXDOMAIN answer whenever one of the name
all ancestral zone cuts above the query name and learn the NS RRset servers for the requested domain (QNAME) or one of its ancestors has
at the apex of each delegated zone. Other implementations will know an address in the 192.0.2.0/24 block, the RPZ would contain the
only the zone cut information which has naturally come into the following:
cache, which will often include only name server names and addresses
from the parent. Apex ("below the cut") name server names and
addresses often do not exactly match those from the parent. Such
inconsistencies can lead to instability in DNS RPZ behavior. This
potential inconsistency must be taken into account when designing a
security policy or testing DNS RPZ.
For NSDNAME and NSIP triggers, the BIND9 and Unbound RPZ $ORIGIN RPZ.EXAMPLE.ORG.
implementations (as of 2016) match the NS, A, and AAAA RRsets already 24.0.2.0.192.rpz-nsip CNAME .
in their caches unless there are none, in which case they recurse.
This strategy works well in practice, because their caches were
likely recently populated while generating the unmodified response
and checking QNAME and response IP address triggers. In addition,
the authoritative apex NS RRset (which, if obtained, would supersede
the cached NS RRset from the delegating zone) of a domain operated by
a malefactor is often peculiar. Even when it is reasonable, the
authoritative DNS servers for such a domain are often extremely slow
or broken. For example, RRs like "example.com NS ." claiming root as
the authoritative server for a second or lower level domain are
popular choices in miscreant apex NS RRsets, as are imaginative name
servers A and AAAA RRsets.
4.5. The "NSIP" trigger (.rpz-nsip) The NS, A, and AAAA records used for this calculation are either
delegations and glue (RRs in authority and additional sections of
answers from authorities for the parent zone) or authoritative data
from the zone itself. As with NSIP, an implementation MAY use
either, both, or whichever is currently available; see Section 9.4 on
"ns-wait-recurse".
The NSIP policy trigger matches name server addresses, that is A or An RPZ implementation MAY also be configurable to avoid checking all
AAAA RRs referenced by an NS RRset. NSIP is much like NSDNAME the way up to the root and to perform only partial NSIP checks; see
(described above) except that the matching is by name server address Section 9.3 on "min-ns-dots".
rather than name server name. NSIP policies are expressed as
subdomains of "rpz-nsip" and have the same subdomain naming
convention as described for response IP policy triggers above
(Section 4.1.1).
In a process very similar to that for an NSDNAME trigger 5. Precedence Rules
(Section 4.4), an NSIP trigger is checked by first considering all of
the IP addresses for all the named servers for the QNAME, then
proceeding similarly parent of the QNAME, and so on until the name
servers for the root (.) have been checked or a policy has been
matched.
Policies are applied in order of precedence (see Section 5.1) at each More than one policy trigger among the various DNS RPZs connected to
level in the data path. The data path traversal process stops the name server's control plane can match while computing a given DNS
immediately when there is at least one policy match at a given level. response, but only a single policy rule can rewrite the response.
The policy rule with the best match will be selected according to the
precedence rules outlined below.
For example, to force an NXDNAME answer whenever one of the name These precedence rules exist and are ordered to ensure that RPZ
servers for the requested domain (QNAME) or one of its parents has an subscribers and publishers have the same understanding of what a set
address in the 192.0.2.0/24 block, the RPZ would contain the of policy zones will do, and to ensure that subscribers can use local
following: zones to override published policy zones.
$ORIGIN RPZ.EXAMPLE.ORG. In theory and for standardization, all matching policy rules are
24.0.2.0.192.rpz-nsip CNAME . considered simultaneously, and the precedence rules are used to
choose the single best RPZ rule. In actual implementations, policy
triggers are usually considered in a sequence that mirrors the
process of generating the DNS response, because checking RPZ triggers
is conveniently made a part of that process. For example, Client IP
Address triggers are often checked early as the DNS request is being
received and as the client IP address is being checked in the access
control list (ACL) that determines which DNS client IP addresses can
ask for recursion. Likewise the QNAME is available for RPZ trigger
matching before any response IP addresses are known, so QNAME
triggers are usually checked immediately after Client IP Address
triggers and before Response IP Address triggers. NSIP and NSDNAME
triggers are generally checked last.
4.5.1. Implementation considerations for NSIP triggers As far as the DNS client can determine, it MUST seem that all
matching triggers are found and weighed using these precedence rules,
even though in practice, shortcuts are taken. Shortcuts MUST NOT
affect the outcome. For example, according to the precedence rules,
a matched QNAME trigger in the first policy zone makes all Response
IP Address, NSIP, and NSDNAME triggers moot. There is no need to
look for those matches, because they cannot further affect the
response.
The performance and caching considerations for the implementation of The actions specified in policy rules are not used in the calculation
NSIP triggers are essentially identical to those described for of precedence. The actions of policy rules determined by per-zone
NSDNAME triggers (Section 4.4.1). action overrides (Section 6.1), other than those that disable them,
likewise do not affect the calculation of precedence. Override
actions which disable policy rules affect this calculation only by
removing those rules from consideration.
5. Application of the Policy Precedence rules are applied in the order listed here; the comparison
between two matching policy rules to choose the better match is
determined by the first dispositive precedence rule in this list.
Note however that if the best match selects a disabled rule (caused
by the DISABLED override described in Section 6.1), then the next
best match is used, and so on until a policy rule that is not
disabled is selected or no matches remain.
5.1. "CNAME or DNAME Chain Position" Precedence Rule
This precedence rule applies only when the original query type is not
ANY, CNAME, nor DNAME, and only when a CNAME or DNAME is encountered
while resolving the original QNAME, in what we will call the first
"stage of resolution". In this case, we know that the recursive name
server ([RFC1035]) may follow the CNAME (or the synthetic CNAME
constructed while applying a DNAME) by starting a second stage of
resolution starting at this CNAME's target. Additional stages of
resolution may ensue if further CNAMEs or DNAMEs are encountered,
until the final response is computed.
A policy rule match which occurs at an earlier stage of resolution is
preferred to a policy rule match which occurs at a later stage.
Recall that only one policy rule, from among all those matched at all
stages of resolving a CNAME or DNAME chain, can affect the final
response; this is true even if the selected rule has a PASSTHRU
action.
5.2. "RPZ Ordering" Precedence Rule
This precedence rule applies when the matches being compared refer to
policy rules in different RPZs.
Matches on rules in an RPZ specified earlier in the ordered list of
RPZs take precedence over matches on rules in an RPZ specified later.
5.3. "Domain Name Matching" Precedence Rule
This precedence rules applies to a set of QNAME rules or a set of
NSDNAME rules in a single RPZ. The rule triggers are compared.
This rule is the same as that used by DNS servers to choose the RRs
with which to respond to a request. In particular, an exact name
match is better than one involving a wildcard, and among wildcard
matches, the trigger (owner domain name) that has the largest number
of labels is best.
Since a DNS response has only one QNAME in a given stage of CNAME or
DNAME chain resolution (as defined in Section 5.1,
"CNAME or DNAME Chain Position" Precedence Rule), this precedence
rule is sufficient to choose a single QNAME trigger over other QNAME
triggers in the same RPZ. However, computing a single DNS response
can match dozens of NSDNAME triggers in a single RPZ, of which
several may be equal according to this precedence rule. In that
case, the "Name Order" Precedence Rule (Section 5.5) selects the
single winner from among those chosen by this rule.
5.4. "Trigger Type" Precedence Rule
This precedence rule applies to policy rules within the same RPZ, but
with different trigger types.
In this case, matches are ranked according to trigger type in the
following order, from highest to lowest precedence:
+ Client IP Address
+ QNAME
+ Response IP Address
+ NSDNAME
+ NSIP
5.5. "Name Order" Precedence Rule
This precedence rule applies to a set of NSDNAME matches whose
precedence has not been established by previous precedence rules.
Here, the matched name server domain names are compared, not the
owner names (triggers) of the policy rules. Therefore, it is
irrelevant whether the matched trigger was a wildcard or a specific
domain name.
Among the matching NSDNAME policy rules, choose the one whose matched
name server domain name appears last in the DNSSEC canonical DNS name
order described in section 6.1 of [RFC4034].
Important note: if this precedence rule is reached, the matches being
compared originate from different NS names, not from the same name
matching multiple rules, as those conflicts would have been dispensed
with by the "Domain Name Matching" Precedence Rule (Section 5.3).
There is no a priori reason to prefer one NS name over another, so
while this tie-breaker precedence rule is dispositive, it is also
arbitrary. All RPZ implementations MUST make the same choices in
these cases to ensure consistent, predictable results among
installations.
Taking part of the example directly from section 6.1 of [RFC4034],
and reversing the order to take into account that the name that
appears last in the DNSSEC canonical order is to be taken as the best
match here, the following NS names are given below in order from
highest or best to lowest precedence:
+ z.example
+ zABC.a.EXAMPLE
+ Z.a.example
+ yljkjljk.a.example
+ a.example
+ example
5.6. "Prefix Length" Precedence Rule
This precedence rule applies when more than one Response IP Address
policy rule or more than one NSIP policy rule matches while computing
a response. The rule triggers themselves are compared.
When comparing two Response IP Address matches or two NSIP matches on
rules within a single RPZ, choose the match whose rule trigger has
the longest "internal 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.1.1 on
IP address encoding in triggers. For an IPv4 address trigger, the
internal prefix length is the numeric value of its first label plus
96 (that is, 128-32). This adjustment allows IPv4 and IPv6 addresses
to use the same internal representation, with 32-bit IPv4 addresses
expanded to 128 bits by zero filling as described in section 2.5.5.1
of [RFC4291].
5.7. "IP Address Order" Precedence Rule
This precedence rule applies when more than one Response IP Address
policy rule or more than one NSIP policy rule matches while computing
a response, and they have the same internal prefix length. The rule
triggers are compared.
When comparing Response IP Address or NSIP triggers with equal
internal prefix lengths, choose the trigger which encodes the smaller
IP address. The IP addresses from the triggers are compared as 128
bit numbers, with IPv4 addresses expanded to 128 bits by zero filling
as described in section 2.5.5.1 of [RFC4291].
Important note: if this precedence rule is reached, the matches being
compared originate from different IP addresses, not from the same
address matching multiple rules, as those conflicts would have been
dispensed with by the "Prefix Length" Precedence Rule (Section 5.6).
There is no a priori reason to prefer one IP address over another, so
while this tie-breaker precedence rule is dispositive, it is also
arbitrary. All RPZ implementations MUST make the same choices in
these cases to ensure consistent, predictable results among
installations.
In the following example, the internal prefix length of all three IP
addresses is 121 as described in Section 5.6.
25.0.2.0.192.rpz-ip CNAME most.example.com.
25.128.2.0.192.rpz-ip CNAME middle.example.com.
121.280.c000.zz.db8.2001.rpz-ip CNAME least.example.com.
The three addresses above are compared as these 128-bit hexadecimal
numbers, respectively:
0x000000000000000000000000c0000200,
0x000000000000000000000000c0000280, and
0x20010db80000000000000000c0000280.
Thus, the first IPv4 address is most preferred and the IPv6 address
is least preferred.
6. Application of the Policy
To enable the use of RPZs, the recursive name server's control plane To enable the use of RPZs, the recursive name server's control plane
is connected to the DNS RPZ data plane by supplying an ordered list is connected to the DNS RPZ data plane by supplying an ordered list
of RPZs in the name server's configuration. For each DNS RPZ in this of RPZs in the name server's configuration.
list, it should be possible to specify an optional overriding policy
action to be used for any policy triggers found in that RPZ. These
override policies should include NXDOMAIN, NODATA, PASSTHRU, DROP,
TCP-ONLY, CNAME domain, GIVEN, and DISABLED. The first five of these
actions are defined in Section 3 above. "CNAME domain" is a
restricted case of the "Local Data" action (also defined in
Section 3) in which the rewritten response is a CNAME RR targeting
"domain." GIVEN explicitly reaffirms the default, which is to
respect all policy actions found in this DNS RPZ. The overriding
DISABLED action causes triggered actions in the zone to have no
effect except to log what would have happened, provided sufficient
logging is enabled; this is useful for debugging or previewing a
policy zone.
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). Recursive DNS servers generally send their recursion (RD=1). Recursive DNS servers generally send their
requests to authority servers without asking for recursion (RD=0), requests to authority servers without asking for recursion (RD=0),
while stub resolvers ask for recursion (RD=1). Thus, RPZ at a while stub resolvers ask for recursion (RD=1). Thus, the use of RPZ
recursive server by default only affects requests from stub at a recursive server by default affects requests from stub resolvers
resolvers. This default can be overridden in some implementations only. An implementation SHOULD include a configuration option such
with configuration statements such as "recursive-only no". as "recursive-only no" to relax this restriction.
Also by default, RPZ policies are only applied to responses to DNS Also by default, RPZ policies are applied only while responding to
requests that do not request DNSSEC metadata (DO=0) or for which no DNS requests that do not request DNSSEC metadata (DO=0) or for which
DNSSEC metadata exists. This defaults can be overridden in some no DNSSEC metadata exists. An implementation MAY include a
implementations with a configuration statement such "break-dnssec configuration option such as "break-dnssec yes" to relax this
yes". See Section 10 about the implications of responding with restriction. See Section 12.2 about the implications of responding
modified DNS responses when the DNS client seems to be expecting with modified DNS responses when the DNS client seems to be expecting
DNSSEC signatures. DNSSEC signatures.
If a policy rule matches and results in a modified answer, then that RPZ rules do not apply to synthetic data generated by using RPZ
modified answer will include in its authority section the SOA RR of rules. For example, if RPZ supplies a CNAME pointing to a walled
the policy zone whose policy was used to generate the modified garden, RPZ policies will not be used while following that CNAME. If
answer. This SOA RR includes the name of the DNS RPZ and the serial RPZ supplies local data giving a particular A record, RPZ policies
number of the policy data which was connected to the DNS control will not apply to that response IP address.
plane when the answer was modified.
Conceptually, policies MUST be applied after recursion is complete
and all data needed to formulate a response is available. However,
implementations MAY short-circuit the process such as not waiting for
recursion when it is clear which modification will be made to the
response. Nevertheless, it SHOULD be possible to configure the
resolver to continue checking and filling its cache by recursion as
if it had not already made its decision, in order to deny operators
of authority servers for listed domains information about whether
they are listed, that is, in order to minimize giving hints to
miscreants about when to change their DNS data. In BIND9, for
example, this behavior is controlled with the "qname-wait-recurse"
configuration option.
When the QNAME is resolved with CNAME or DNAME, there are no response
IP address that might match a response IP address trigger, but NSIP
and NSDNAME triggers might be matched. Unless the original query
type is ANY, CNAME, or DNAME, the resolver will start over and try to
resolve the target of the CNAME. RPZ is also restarted and the CNAME
target is matched against CNAME policy rules resolved IP addresses
(if any) are matched with response IP address policy triggers, and so
forth. This process is repeated as the resolver follows the CNAME
chain.
5.1. Precedence Rules.
More than one policy trigger among the various DNS RPZs connected to If an illegal record is encountered while computing a response, for
the name server's control plane can match a given DNS response, but example an NS record with a CNAME target, and this illegal record is
only a single policy rule can affect the response. In theory and for ignored by the resolver, then it is likewise not used for RPZ rule
standardization, all possible rules are considered simultaneously and matches.
the following precedence rules are used to choose the single best RPZ
rule. In implementations, policy triggers are usually considered in
a sequence that mirrors the process of generating the DNS response,
because checking RPZ triggers is conveniently made a part of that
process. For example, client IP RPZ address triggers are often
checked early as the DNS request is being received and the client IP
address is checked in the access control list (ACL) that determines
which DNS client IP addresses can ask for recursion. The QNAME is
available for RPZ trigger matching before any response IP addresses
are known and so QNAME poliocy triggers are usually checked
immediately after client IP address triggers and before response IP
address triggers. NSIP and NSDNAME triggers are often checked last.
As far as the DNS client can determine, it MUST seem that all
matching triggers are found and weighed using the precedence rules,
but in practice, shortcuts are taken. For example, according to the
precedence rules, a matched QNAME trigger in the first policy zone
makes all response IP address, NSIP, and NSDNAME triggers moot.
There is no need to look for those matches, because they will not
affect the response.
The following list is ordered so that rules listed early override If a policy rule matches and results in a modified answer, then that
rules listed later. modified answer will include in its additional section the SOA RR of
the policy zone whose rule was used to generate the modified answer.
This SOA RR includes the name of the DNS RPZ and the serial number of
the policy data which was connected to the DNS control plane when the
answer was modified.
RPZ Ordering 6.1. Per-Zone Action Overrides
Changes triggered by records in RPZs specified earlier in the
ordered set of DNS RPZs are applied instead of triggers in policy
zone specified later.
Within An RPZ For each DNS RPZ configured for use by a recursive name server, it
Among policies from a single RPZ, client IP address policies are SHOULD be possible to specify a single, OPTIONAL overriding policy
chosen instead of QNAME policies, QNAME policies are preferred to action to be used for all policy triggers found in that RPZ. These
IP, IP policies are preferred to NSDNAME, and NSDNAME policies are policy action overrides include the following:
preferred to NSIP.
Exact name match NXDOMAIN
As in exact versus wildcard domain name matching at authority SHOULD be implemented and is the same as the NXDOMAIN action
servers, exact domain name QNAME or NSDNAME triggers are preferred defined in Section 3.1.
to wildcards.
Name Length NODATA
The preceding rule implies QNAME policies are preferred to NSDNAME SHOULD be implemented and is the same as the NODATA action defined
policies. in Section 3.2.
Among triggered QNAME or NSDNAME policies within an RPZ, choose PASSTHRU
the policy that matches the triggering domain name that appears SHOULD be implemented and is the same as the PASSTHRU action
earlier in the sorting using the DNSSEC canonical DNS name order defined in Section 3.3.
described in section 6.1 of [RFC4034]. The last labels of domain
names are most significant in that ordering. A domain name that
is a parent of another appears before the child. Labels are
compared as if they were words in a dictionary so that a label
that is a prefix of a second label appears before 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 LOCAL-DATA-OR-PASSTHRU
A preceding rule implies that IP policies within an RPZ are MAY be implemented. It modifies the Local Data action
preferred to NSIP policies. (Section 3.6) so that requests for RR types that would otherwise
give a Local Data result of NODATA (ANCOUNT=0) are instead handled
using the PASSTHRU action (Section 3.3). Note that computing a
DNS response for QTYPE ANY can never cause a Local Data NODATA
result. The LOCAL-DATA-OR-PASSTHRU override applies only to Local
Data rules and has no effect on rules with other actions.
Among triggered IP or NSIP policies, use the policy (not the DROP
matched IP address) with the longest internal policy zone prefix SHOULD be implemented and is the same as the DROP action defined
length. The internal prefix length of an IPv6 address trigger is in Section 3.4.
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 their equivalent
IPv4-compatible IPv6 address triggers. It also tends to favor
IPv4 triggers over IPv6 triggers. (See section 2.5.5.1 of
[RFC4291] about IPv4-compatible IPv6 addresses.)
Tie Breaker TCP-ONLY
Given equal internal prefix lengths, use the IP or NSIP policy SHOULD be implemented and is the same as the TCP-ONLY action
that matches the first IP address. Addresses with equal trigger defined in Section 3.5.
internal prefix lengths are ordered by their representations as
domain names described in Section 4, including the leading,
unadjusted prefix length. Because this tie breaking considers the
matched IP addresses instead of the triggered policy rules, the
first or least significant label of an IPv6 address is always
"128", and the first label of an IPv4 address is always "32".
6. Subscriber Behavior CNAME domain
SHOULD be implemented and is a special case of the Local Data
action defined in Section 3.6. The overriding data is a CNAME RR
with the given domain as its target.
RPZs must be primary or secondary zones at subscriber recursive GIVEN
resolvers. They can be searched only in a recursive server's own MAY be implemented to explicitly affirm the default, which is to
storage, because additional network transactions for DNS resolvers respect all policy actions found in this DNS RPZ.
are extremely undesirable.
Response policy zones are loaded in the usual way. For primary zones DISABLED
this may mean loading the contents of a local file into memory, or SHOULD be implemented and causes any rule of the zone, when
connecting to a database. For secondary zones this means selected as a "best match", to have no effect, except to log what
transferring the zone from the primary server using zone transfer would otherwise have happened, provided sufficient logging is
such as IXFR [RFC1995] or AXFR [RFC5936]. It is strongly recommended enabled. The DISABLED override thus causes the next highest
that all secondary zone transfer relationships be protected with precedence match (if any) to be used (see Section 5,
transaction signatures (DNS TSIG) and that real time change Precedence Rules). This is useful for debugging or previewing a
notification be enabled using the DNS NOTIFY protocol [RFC1996]. policy zone.
DNS resolvers often have limited or no notion of a DNS zone or zone LOCAL-DATA-OR-DISABLED
file. They sometimes have special local zones, but generally have no MAY be implemented. It modifies the Local Data action
implementations of IXFR, AXFR, or NOTIFY. Therefore, an external (Section 3.6) so that requests for RR types that would otherwise
module or daemon that maintains local copies of policy zones can be give a Local Data result of NODATA (ANCOUNT=0) are instead handled
useful. similarly to the DISABLED override, but without logging. In this
case, the next highest precedence match (if any) is used. Note
that computing a DNS response for QTYPE ANY can never cause a
Local Data NODATA result. The LOCAL-DATA-OR-DISABLED override
applies only to Local Data rules and has no effect on rules with
other actions.
7. Producer Behavior 7. 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 transfers (IXFR [RFC1995]) rather than full zone
transfer (AXFR [RFC5936]) is used to move new policy data toward transfers (AXFR [RFC5936]) are used to move new policy data toward
subscribers. Also, real time zone change notifications (DNS NOTIFY subscribers. DNS RPZ subscribers are "stealth slaves" as described
[RFC1996]) should be enabled and tested. DNS RPZ subscribers are in RFC 1996. The master MUST allow each such slave to perform the
"stealth slaves" as described in RFC 1996, and each such server must needed zone transfers, for example via its access control lists
be explicitly listed in the master server's configuration as (ACLs). The master also SHOULD be configured as necessary to send
necessary to allow zone transfers from the stealth slave, as well to NOTIFY messages to each slave. Because minimal data latency is
ensure that zone change notifications are sent to it. Because DNS critical both to the prevention of crime and abuse and to the
NOTIFY is a lazy protocol, it may be necessary to explicitly trigger withdrawal of erroneous or outdated policy, a DNS RPZ producer SHOULD
the master server's "notify" logic after each change of the DNS RPZ. also make every effort to minimize data latency, including ensuring
These operational guidelines are to limit policy data latency, since that NOTIFY messages are sent in a timely manner after each change of
minimal latency is critical to both prevention of crime and abuse, the DNS RPZ on the master server.
and to withdrawal of erroneous or outdated policy.
In the data feed for disreputable domains, each addition or deletion In a response policy zone domain, each addition, deletion, or
or expiration can be handled using DNS UPDATE [RFC2136] to trigger expiration could 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 BIND9) 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 BIND9 this option is called
differences" and is known to be performant even for million-rule DNS "ixfr-from-differences" and is known to be performant even for
RPZ's with significant churn on a minute by minute basis. million-rule DNS RPZ's with significant churn on a minute by minute
basis.
It is good operational practice to include test records in each DNS It is good operational practice to include test records in each DNS
RPZ to help that DNS RPZ's subscribers verify that response policy RPZ to help that DNS RPZ's subscribers verify that response policy
rewriting is working. For example, a DNS RPZ might include a QNAME rewriting is working. For example, a DNS RPZ might include a QNAME
policy record for BAD.EXAMPLE.COM and an IP policy record for policy rule for "BAD.EXAMPLE.COM" as well as a Response IP Address
192.0.2.1. A subscriber can verify the correctness of their policy rule for 192.0.2.1. A subscriber can verify the correctness
installation by querying for BAD.EXAMPLE.COM which does not exist in of their installation by querying for "BAD.EXAMPLE.COM", which does
real DNS. If an answer is received it will be from the DNS RPZ. not exist in real DNS. If an answer is received it will be from the
That answer will contain an SOA RR denoting the fully qualified name DNS RPZ. That answer's additional data section will usually contain
of the DNS RPZ itself. an SOA RR denoting the fully qualified name of the DNS RPZ itself.
8. History and Evolution 8. Subscriber Behavior
RPZ was previously described in a technical note from Internet RPZs MUST be primary or secondary zones at subscriber recursive
Systems Consortium [ISC-RPZ]. A more up to date description appeared resolvers. They can be searched using only a recursive server's own
in chapter 6 of the "BIND 9 Administrator Reference Manual" [ISC-ARM] storage, because additional network transactions for DNS resolvers
as of 2010. would be unworkable for this purpose.
Response policy 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
transferring the zone from the primary server using zone transfer
such as IXFR [RFC1995] or AXFR [RFC5936]. All secondary zone
transfer relationships SHOULD be protected with transaction
signatures (DNS TSIG) and real time change notification SHOULD be
enabled using the DNS NOTIFY protocol [RFC1996].
9. Implementation Considerations
DNS resolvers often have limited notion or no notion of a DNS zone or
zone file. They sometimes have special local zones, but generally
have no implementations of IXFR, AXFR, or NOTIFY. Therefore, an
external module or service that maintains local copies of policy
zones can be useful.
RPZ checks can add significant processing and network costs to the
processing of recursive DNS requests. This is particularly true of
rules with NSDNAME and NSIP triggers. However, NSDNAME and NSIP
triggers can be more effective than QNAME and IP triggers, because
miscreants can more easily change their direct domain names and IP
addresses (which are detected by QNAME and IP triggers) than they can
change their NS names and addresses.
To minimize the costs associated with RPZ processing, implementations
MAY use various optimizations, some of which are described below.
9.1. Avoid Waiting for QNAME Recursion
When data already in the resolver's cache combined with the
precedence rules in Section 5 are sufficient to produce a final RPZ
result, an implementation MAY choose not to finish computing the
unmodified DNS response, thus avoiding unnecessary recursion. For
example, a matching Client IP Address trigger (Section 4.1) in the
first specified RPZ always provides the result regardless of what
might be learned by asking (recursing to) the authority for the
QNAME. Of course, if the data already in the cache are not
dispositive, then the implementation MUST use recursion. For example
a matching QNAME trigger (Section 4.2) in the second RPZ could
potentially be overruled by a Response IP Address trigger
(Section 4.3) in the first RPZ.
Implementations which include this optimization SHOULD provide a
configuration switch (for example, "qname-wait-recurse") to turn it
on and off. The default value of the switch MAY be on or off. Some
security implications of avoiding unnecessary recursion are
considered in Section 12.4.
Implementations MAY cause the LOCAL-DATA-OR-DISABLED override
(described in Section 6.1) to imply not waiting for recursion, or to
require that optimization.
9.2. Check Parents Domains versus Zone Cuts
In principle, the NSDNAME and NSIP processes of following the data
path toward the root look for NS, A, and AAAA RRsets only in the
apexes of zones. In practice, DNS resolvers often do not know which
domain name parent-child relationships reflect zone delegations, and
so RPZ implementations generally iteratively remove labels from the
left end of the domain name to request NS RRsets from their caches or
authoritative servers for each ancestor of the queried name. The
cost of looking for an NS RRset for a domain name that is not at a
delegation point is usually only asking for the RRset and receiving
only an SOA from the cache.
9.3. Abbreviate the Data Path for NSDNAME and NSIP Checks
The process of traversing the data path from the level nearest the
queried record to the top (root domain) level to check NSIP or
NSDNAME triggers can be expensive. There are many NS records for the
top level domains and the root, but checking them is rarely
worthwhile because the root and TLDs are rarely used as NSIP or
NSDNAME triggers. Some RPZ implementations have a "min-ns-dots"
parameter that stops NSDNAME and NSIP checking short of the root
zone, by not checking the name servers for domains whose names
contain fewer than the configured minimum number of dots.
9.4. Use Glue for NSDNAME and NSIP Checks
Some implementations of DNS RPZ attempt to exhaustively discover all
ancestral zone cuts above the query name and learn the NS RRset at
the apex of each delegated zone. Other implementations use only the
information which has naturally come into their caches, which often
includes only delegations and glue, that is name server names and
addresses sent by servers for the parent zone and not by those for
the zone itself. Both of these tactics have shortcomings, but the
more accurate tactic of checking delegations and glue as well as
authoritative NS, A, and AAAA RRsets is generally considered too
expensive.
To limit the costs of checking NSDNAME and NSIP triggers, an
implementation MAY have settings (for example "nsdname-wait-
recurse no" or "nsip-wait-recurse no") which cause the resolver to
use only the NS RRsets or only the A and AAAA RRsets already in the
cache. With these settings, the resolver will not recurse if there
are relevant cached entries (including negative entries) when
processing NSDNAME or NSIP triggers, respectively.
Note that using only already-cached instead of current and complete
delegation, glue, and authoritative data can cause inconsistent RPZ
behavior. Most recursive DNS server implementations do not renew
delegation and glue RRsets when their TTLs expire if authoritative
data are available in the cache. Requests by the RPZ part of a
recursive server for NS RRsets and associated A and AAAA RRsets will
often initially receive only delegations and glue from the cache. As
time passes and TTLs expire, those requests tend to be answered less
with delegations and glue and more with authoritative RRsets. If and
when sufficient RRsets expire from the cache, the cycle repeats with
RPZ once again relying more on delegations and glue. Thus, if the
glue and authoritative RRsets differ, then RPZ installations that use
whichever is available in the cache can produce inconsistent results.
This is not an argument for NSDNAME or NSIP triggers to not use glue,
because as discussed in Section 12.5, delegations and glue NS, A, and
AAAA RRsets for miscreant domains are often more revealing and
effective than their authoritative RRsets.
9.5. Reduce Zone Size using Implied Rules
In 2016, an RPZ zone of QNAME rules for many miscreant domain names
contained 200 MBytes of data representing almost 8 million rules. In
such an RPZ, many of the listed domain names are as undesirable as
DNS servers as they are as mail senders, and so might reasonably have
NSDNAME rules in addition to their QNAME rules. However, instead of
paying the costs of doubling that RPZ zone to 16 million rules and
400 MBytes, an RPZ implementations MAY offer a per-zone setting (for
example "qname-as-ns yes") which causes the implementation to act as
if for every rule with the trigger "EXAMPLE.COM", there is another
rule in the RPZ with the trigger "EXAMPLE.COM.RPZ-NSDNAME" and the
same policy action.
An implementation MAY also offer a setting (for example "ip-as-
ns yes") which similarly generates NSIP rules based on Response IP
Address rules. Given an RPZ rule with a trigger of
"24.0.2.0.192.rpz-ip", act as if the RPZ also contains another rule
with the trigger "24.0.2.0.192.rpz-nsip" and the same policy action.
10. History and Evolution
An early description of RPZ can be found in a technical note from
Internet Systems Consortium [ISC-RPZ]. RPZ was also described in
2010 in chapter 6 of the "BIND 9 Administrator Reference Manual"
[ISC-ARM].
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 were 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 starting in 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 support of the grew incrementally, and upward compatibility required support of the
original encodings. The initial specification or Format 1 contained original encodings. The initial specification or Format 1 contained
only QNAME triggers. Changes for Format 2 included adding triggers only QNAME triggers. Changes for Format 2 included adding triggers
based on response contents (RDATA), the targets of NS records based on response contents (Response IP Address), the targets of NS
(NSDNAME), and contents of A and AAAA records that resolve NS records records (NSDNAME), and contents of A and AAAA records that resolve NS
(NSIP). Format 3 included "rpz-passthru" for the PASSTHRU action and records (NSIP). Format 3 included "rpz-passthru" for the PASSTHRU
wildcards in CNAME targets to synthesize local data. action and wildcards in Local Data CNAME targets to synthesize
responses dynamically based on the query domain.
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-* pseudo-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 PASSTHRU encoding of a CNAME pointing to the original, deprecated PASSTHRU encoding of a CNAME pointing to the
trigger QNAME might still be in use in local, private policy zones, trigger QNAME might still be in use in local, private policy zones,
and so it is still recognized by RPZ subscriber implementations. and so it is still recognized by RPZ subscriber implementations as of
2016.
The initial RPZ idea was only to deny the existence of objectionable The initial idea for RPZ was only to deny the existence of
domain names, and so there were only QNAME triggers and NXDOMAIN objectionable domain names, and so there existed only QNAME triggers
actions. Given that single kind of trigger, encoding it as the owner and NXDOMAIN actions. Given that single kind of trigger, encoding it
name of a policy record was clearly best. A CNAME pointing to the as the owner name of a policy record was clearly best. A CNAME
root domain (.) is a legal and valid but not generally useful record, pointing to the root domain (.) is a legal and valid but not
and so that became the encoding for the NXDOMAIN action. The generally useful record, and so that became the encoding for the
encoding of the NODATA action as "CNAME *." followed similar NXDOMAIN action. The encoding of the NODATA action as "CNAME *."
reasoning. Requests for more kinds of triggers and actions required followed similar reasoning. The addition of more triggers and more
a more general scheme, and so they are encoded as CNAMES with targets actions required a more general scheme, and so newer actions are
in bogus TLDs owner names with DNS labels that start with "rpz_". encoded as CNAMEs with targets in bogus TLDs whose names start with
"rpz-". Newer triggers are owner names containing DNS labels that
start with "rpz-".
9. IANA Considerations It would have been better if all actions had been encoded as
subdomains of the invalid "*" top level domain, for example
"drop.rpz.*" and "passthru.rpz.*" and even "nxdomain.rpz.*". "rpz"
would always be the second level domain and the action would be
specified by the third level domain. That would have polluted only a
single bogus TLD. Perhaps future versions of RPZ that define new
actions will define those new actions using that scheme, and will use
that scheme to redefine existing actions while deprecating but
retaining the old definitions.
11. 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.
10. Security Considerations 12. Security Considerations
RPZ is a mechanism for providing "untruthful" DNS results from 12.1. DNS Data Security
recursive servers. Nevertheless, RPZ does not exacerbate the
existing vulnerability of recursive servers to falsified DNS data.
RPZ merely formalizes and facilitates modifying DNS data on its way
from DNS authority servers to clients. However, the use of DNSSEC
(see [RFC4033] and [RFC4034]) prevents such changes to DNS data by
RPZ.
RPZ is a mechanism for providing "untruthful" DNS results to
consenting stub resolvers from recursive servers. Nevertheless, RPZ
does not exacerbate the existing vulnerability of DNS servers to
falsified DNS data; it merely formalizes and facilitates modifying
DNS data on its way from DNS authority servers to clients. Note that
a non-consenting stub resolver can simply opt out by using a
different recursive name server.
12.2. DNSSEC
The use of DNSSEC (see [RFC4033] and [RFC4034]) prevents the
acceptance by clients of such RPZ-induced changes to DNS data.
Therefore, by default, DNS resolvers using RPZ avoid modifying DNS Therefore, by default, DNS resolvers using RPZ avoid modifying DNS
results when DNSSEC signatures are available and are requested by the results when DNSSEC signatures are available and are requested by the
DNS client. However, when the common "break-dnssec" configuration DNS client. However, when the common "break-dnssec" configuration
setting is used, RPZ-using resolvers rewrite responses. They omit setting is used, RPZ-using resolvers rewrite responses even in that
DNSSEC RRsets, because the modified responses cannot be verified by case. They omit DNSSEC RRsets, because the modified responses cannot
DNSSEC signatures. This renders the results invalid according to be verified by DNSSEC signatures. This renders the results invalid
DNSSEC. In such a case, a querying client which checks DNSSEC will according to DNSSEC. In such a case, a querying client which checks
ignore the invalid result, and will effectively be blocked from DNSSEC reacts as though it has been subjected to a data poisoning
miscreant domains; this behaviour is functionally similar to that attack and rejects the data. That reaction could entail expensive
caused by an RPZ NXDOMAIN policy action. bypass operations.
12.3. TSIG
The policy zones might be considered sensitive, because they contain The policy zones might be considered sensitive, because they contain
information about miscreants. Like other DNS zones in most information about miscreants. Like other DNS zones in most
situations, RPZs are transferred from sources to subscribers as situations, RPZs are transferred from publishers to subscribers as
cleartext vulnerable to observation. However, TSIG transaction cleartext vulnerable to observation. DNS zones are vulnerable to
signatures [RFC2845] SHOULD be used to authenticate and protect RPZ forgery or modification if TSIG transaction signatures [RFC2845] are
contents from modification. not used, and so TSIG SHOULD be used to authenticate RPZ contents and
protect them from modification.
Recursive servers using RPZ are often configured to complete 12.4. Counterintelligence
recursion even if a policy trigger provides a rewritten answer
without needing recursion. This impedes miscreants observing
requests from their own authority servers from inferring whether RPZ
is in use and whether their RRs are listed. "qname-wait-recurse" is
a common configuration switch that controls this behavior. See
Section 5.
11. Acknowledgements Recursive servers using RPZ can be optimized to avoid completing
recursion if a policy rule provides a rewritten answer without
needing this recursion (Section 9.1). However, the use of such an
optimization allows miscreants to infer whether RPZ is in use and
whether their RRs are listed, simply by observing requests sent to
their own authority servers. Therefore, implementations that provide
this optimization SHOULD allow it to be disabled.
12.5. NSIP, NSDNAME, Glue, and Authoritative RRsets
Apex ("below the cut") or authoritative NS, A, and AAAA RRsets
containing the name server names and addresses for a zone often do
not exactly match glue from the parent zone. Delegation and glue
records or "above the cut" records from the parent zone are often
incomplete or out of date compared to the NS, A, and AAAA RRs from
authoritative servers for the zone itself. Regardless of any lack of
completeness or accuracy, the delegation and glue records for a
functioning domain are sufficently accurate for the domain to be
resolvable: the authoritative servers for a zone cannot be found
without a delegation and (if necessary) some glue. On the other
hand, a domain with entirely broken authoritative name server data
can largely work.
The authoritative NS data for miscreant domains is often fanciful or
even unavailable. For example, an authoritative NS RRset consisting
of "NS ." is popular, because while it is wrong, it betrays nothing
in particular about the miscreant who owns the domain.
Thus delegations and glue are generally best for detecting and
rewriting miscreant DNS data, if resource constraints prohibit
checking both above-delegation and below-delegation NS and glue.
13. Acknowledgements
The authors gratefully acknowledge the substantial contributed The authors gratefully acknowledge the substantial contributed
material and editorial scrutiny of Anne Bennett. She directed the material and editorial scrutiny of Anne Bennett. She directed the
reorganization and clarification of the entire document. reorganization and clarification of the entire document.
Eric Ziegast, Jeroen Massar, and Ben April provided improvements to Eric Ziegast, Jeroen Massar, Ben April, Ray Bellis and Mukund
the document and caught errors. Sivaraman provided improvements to the document and caught errors.
12. References 14. References
12.1. Normative References 14.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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
skipping to change at page 19, line 18 skipping to change at page 27, line 47
[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>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>. <http://www.rfc-editor.org/info/rfc5952>.
12.2. Informative References 14.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 19, line 41 skipping to change at page 28, line 21
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 subdomains: also one for its subdomains:
bad.example.com CNAME walled-garden.example.net. bad.example.com CNAME walled-garden.example.net.
*.bad.example.com CNAME walled-garden.example.net. *.bad.example.com CNAME walled-garden.example.net.
If it is desirable to return NXDOMAIN for each domain (and its If it is desirable to return NXDOMAIN for each domain (and its
subdomains in this example), try this: subdomains in this example), try this:
bad.example.com CNAME . bad.example.com CNAME .
*.bad.example.com CNAME . *.bad.example.com CNAME .
Try this if there are walled gardens for mail versus everything else: Try this if there are walled gardens for mail versus everything else:
bad.example.com MX 0 wgmail.example.net. bad.example.com MX 0 wgmail.example.net.
bad.example.com A 192.0.2.66 bad.example.com A 192.0.2.66
*.bad.example.com MX 0 wgmail.example.net. *.bad.example.com MX 0 wgmail.example.net.
*.bad.example.com A 192.0.2.66 *.bad.example.com A 192.0.2.66
An extended example follows: An extended example follows:
$ORIGIN rpz.example.net. $ORIGIN rpz.example.net.
$TTL 1H $TTL 1H
@ SOA LOCALHOST. named-mgr.example.net. ( @ SOA LOCALHOST. named-mgr.example.net. (
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.example.com CNAME . ; NXDOMAIN policy nxdomain.example.com CNAME . ; NXDOMAIN policy
nodata.example.com CNAME *. ; NODATA policy nodata.example.com CNAME *. ; NODATA policy
; redirect to walled garden ; Redirect to walled garden
bad.example.com A 10.0.0.1 bad.example.com A 10.0.0.1
AAAA 2001:db8::1 AAAA 2001:db8::1
; do not rewrite OK.EXAMPLE.COM (PASSTHRU) ; Rewrite all names inside "AZONE.EXAMPLE.COM"
ok.example.com CNAME rpz-passthru. ; except "OK.AZONE.EXAMPLE.COM"
bzone.example.com CNAME garden.example.net. *.azone.example.com CNAME garden.example.net.
ok.azone.example.com CNAME rpz-passthru.
; redirect X.BZONE.EXAMPLE.COM to ; Redirect "BZONE.EXAMPLE.COM" and "X.BZONE.EXAMPLE.COM"
; X.BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET ; to "BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET" and
*.bzone.example.com CNAME *.garden.example.net. ; "X.BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET", respectively.
bzone.example.com CNAME *.garden.example.net.
*.bzone.example.com CNAME *.garden.example.net.
; rewrite all answers for 192.0.2.0/24 except 192.0.2.1 ; Rewrite all answers containing addresses in 192.0.2.0/24,
24.0.2.0.192.rpz-ip CNAME . ; except 192.0.2.1
32.1.2.0.192.rpz-ip CNAME rpz-passthru. 24.0.2.0.192.rpz-ip CNAME .
32.1.2.0.192.rpz-ip CNAME rpz-passthru.
; rewrite to NXDOMAIN all responses; for domains for which ; Rewrite to NXDOMAIN all responses for domains for which
; NS.EXAMPLE.COM is an authoritative DNS server or a server ; "NS.EXAMPLE.COM" is an authoritative DNS server for that domain
; for a parent) or that have an authoritative server ; or any of its ancestors, or that have an authoritative server
; in 2001:db8::/32 ; in 2001:db8::/32
ns.example.com.rpz-nsdname CNAME . ns.example.com.rpz-nsdname CNAME .
32.zz.db8.2001.rpz-nsip CNAME . 32.zz.db8.2001.rpz-nsip CNAME .
; Local Data can include many record types
25.128.2.0.192.rpz-ip A 172.16.0.1
25.128.2.0.192.rpz-ip A 172.16.0.2
25.128.2.0.192.rpz-ip A 172.16.0.3
25.128.2.0.192.rpz-ip MX 10 mx1.example.com
25.128.2.0.192.rpz-ip MX 20 mx2.example.com
25.128.2.0.192.rpz-ip TXT "Contact Central Services"
25.128.2.0.192.rpz-ip TXT "Your system is infected."
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, LLC
Email: vjs@rhyolite.com Email: vjs@rhyolite.com
 End of changes. 127 change blocks. 
560 lines changed or deleted 993 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/