Domain Name System Operations                                   P. Vixie
Internet-Draft                                   Farsight Security, Inc.
Intended status: Informational                               V. Schryver
Expires: June 19, 2017                            Rhyolite Software Software, LLC
                                                       December 16, 2016

                    DNS Response Policy Zones
                         draft-vixie-dns-rpz-02 (RPZ)
                         draft-vixie-dns-rpz-04

Abstract

   This document describes a method for expressing DNS response policy
   inside a specially constructed DNS zone, and for recursive name
   servers to use such poicy policy to return modified results to DNS clients.
   The modified DNS results can stop access to selected HTTP servers,
   redirect users to "walled gardens," gardens", block objectionable email, and
   otherwise defend against attack.  These "DNS Firewalls" are widely
   used in fighting Internet crime and abuse.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 19, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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
   translate it into languages other than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  Discussion Venue  . . . . . . . . . . . . . . . . . . . .   3
   2.  Zone Format . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   3.  Policy Actions  . . . . . . . . . . . . . . . . . . . . . . .   4   5
     3.1.  The "NXDOMAIN" Action (CNAME .) . . . . . . . . . . . . . . . . . .   4   5
     3.2.  The "NODATA" Action (CNAME *.)  . . . . . . . . . . . . .   5
     3.3.  The "PASSTHRU" Action (CNAME rpz-passthru.) . . . . . . .   4
     3.3.   5
     3.4.  The "PASSTHRU" "DROP" Action (CNAME rpz-drop.) . . . . . . . . . . .   6
     3.5.  The "TCP-Only" Action (CNAME rpz-tcp-only.) . . . . . . .   5
     3.4.   6
     3.6.  The "DROP" "Local Data" Action (arbitrary RR types)  . . . . . .   6
   4.  Policy Triggers . . . . . . . . . . . . . . .   5
     3.5.  The "TCP-Only" Action . . . . . . . .   8
     4.1.  The "Client IP Address" Trigger (.rpz-client-ip)  . . . .   9
     4.2.  The "QNAME" Trigger ("example.com") . . . . . .   5
     3.6. . . . . .  10
     4.3.  The "Local Data" Action "Response IP Address" Trigger (.rpz-ip) . . . . . . .  10
     4.4.  The "NSDNAME" Trigger (.rpz-nsdname)  . . . . . . . . . .   6
   4.  Policy Triggers  11
     4.5.  The "NSIP" Trigger (.rpz-nsip)  . . . . . . . . . . . . .  12
   5.  Precedence Rules  . . . . . . . . . .   6
     4.1.  The "Client IP Address" trigger (.rpz-client-ip) . . . .   7
     4.2.  The "QNAME" trigger ("example.com") . . . . . . . .  13
     5.1.  "CNAME or DNAME Chain Position" Precedence Rule . . .   8
     4.3.  The "Response IP address" trigger (.rpz-ip) . .  14
     5.2.  "RPZ Ordering" Precedence Rule  . . . . .   8
     4.4.  The "NSDNAME" trigger (.rpz-nsdname) . . . . . . . .  14
     5.3.  "Domain Name Matching" Precedence Rule  . .   9
     4.5.  The "NSIP" trigger (.rpz-nsip) . . . . . . .  14
     5.4.  "Trigger Type" Precedence Rule  . . . . . . . .  10
   5.  Application of the Policy . . . . .  15
     5.5.  "Name Order" Precedence Rule  . . . . . . . . . . . . .  11
     5.1. .  15
     5.6.  "Prefix Length" Precedence Rules. Rule . . . . . . . . . . . . .  16
     5.7.  "IP Address Order" Precedence Rule  . . . . . . . .  12 . . .  16
   6.  Subscriber Behavior  Application of the Policy . . . . . . . . . . . . . . . . . .  17
     6.1.  Per-Zone Action Overrides . . . . .  14 . . . . . . . . . . .  18
   7.  Producer Behavior . . . . . . . . . . . . . . . . . . . . . .  15  19
   8.  History and Evolution  Subscriber Behavior . . . . . . . . . . . . . . . . . . . .  16 .  20
   9.  IANA  Implementation Considerations . . . . . . . . . . . . . . . .  20
     9.1.  Avoid Waiting for QNAME Recursion . . . . .  17
   10. Security Considerations . . . . . . .  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  .  17
   11. Acknowledgements . . . . . . . . .  22
     9.5.  Reduce Zone Size using Implied Rules  . . . . . . . . . .  23
   10. History and Evolution . . .  17
   12. References . . . . . . . . . . . . . . . . .  23
   11. IANA Considerations . . . . . . . .  18
     12.1.  Normative References . . . . . . . . . . . . .  24
   12. Security Considerations . . . . .  18
     12.2.  Informative References . . . . . . . . . . . . . .  25
     12.1.  DNS Data Security  . . .  19
   Appendix A.  Examples . . . . . . . . . . . . . . . .  25
     12.2.  DNSSEC . . . . . .  19
   Authors' Addresses . . . . . . . . . . . . . . . . . . .  25
     12.3.  TSIG . . . .  20 . . . . . . . . . . . . . . . . . . . . . .  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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document describes DNS Firewalls, a method of expressing DNS
   [RFC1034] response policy information inside specially constructed
   DNS zones, known as Response Policy Zones (RPZs).  RPZs allow DNS reputation
   data
   Internet security policy producers and subscribers to cooperate in
   the application of policies to modify DNS responses in real time.
   Using the policy information, DNS resolution for low-reputation potentially unsafe
   DNS data can be made to deliberately fail or to return local data
   such as an alias to a "walled garden".

   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,
   consists of a trigger (left hand side or owner name) and an action. action
   (right hand side).  A full description of the expressible policies is
   given in Section 3 (actions) and Section 4
   (triggers), while Section 6 explains how the rules are applied. (triggers).

   Configuration examples are given using ISC BIND Version 9 (BIND9)
   [ISC-ARM] syntax, because work to add RPZ to that platform was
   started earliest (in 2009).  The RPZ specification itself is free to
   implement and free to use in operation.  It has been implemented in
   other name server software.  We expect that in time, additional
   recursive DNS implementations will also implement DNS Firewalls as
   described by this RPZ specification.

1.1.  Discussion Venue

   The discussion venue for this document is the DNS Firewalls mailing
   list.  http://lists.redbarn.org/mailman/listinfo/dnsfirewalls offers
   subscriptions and archives.  See also https://dnsrpz.info/

   [NOTE TO EDITOR: This section must be removed before this Internet
   Draft is published as an RFC.]

2.  Zone Format

   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
   common owner name and type.  RRsets other than SOA SOA, NS, and NS DNSSEC-
   related [RFC4034] specify actions and triggers.  The owner name (left
   hand side) of each RRset expresses a policy trigger, while the RDATA
   (right hand side) encodes the action to be taken when the trigger
   matches.  Depending on the type of trigger (see Section 4), a
   particular characteristic of the DNS
   query or 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
   between DNS servers in whole (AXFR) [RFC5936] or incrementally as
   changes occur (IXFR) [RFC1995], can be authenticated and protected by
   TSIG transaction signatures [RFC2845] [RFC2845], and can have update
   propagation expedited by real time change notifications (NOTIFY)
   [RFC1996], all subject to familiar DNS access controls.  An RPZ need
   not support query access since query access is never required.  It is
   the zone transfer of RPZ content from producers to subscribers which
   effectively publishes the policy data,
   and data.  However, it is the subscriber's server configuration
   subscribers' configurations of their recursive name servers which promotes
   promote RPZ payload data into DNS the control plane data.

   Any data of their
   individual name servers.

   Every valid DNS zone (including including an RPZ) is required to have RPZ has an SOA record and at least
   one NS record at its apex, which is why the SOA and NS records of an
   RPZ cannot themselves be used to encode DNS response policy. policy rules.

   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
   domain name of the primary source of the zone and the RNAME field or
   mailbox of the person responsible for the zone are often SHOULD be used by RPZ
   providers to label their policy zones.

   As for an RPZ's

   The apex NS record(s), since query access is never
   required, they RRset will never be used. used since RPZ does not rely on query
   access.  Similarly, no parent delegation is required for normal
   operation of the RPZ.  Thus, by convention, a single NS record having
   the deliberately bogus RDATA of "LOCALHOST." is used as a
   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
   (see Section 8). 10, History and Evolution).  All POLICY policy triggers and
   actions described here are from RPZ valid as of Format 1
   unless otherwise noted. 3.  Policy triggers
   from a higher format number than a recursive name server's
   implementation level are expected to be invisible harmless to that
   implementation.  Policy actions from a higher format number are
   likely to be misinterpreted as CNAME local data 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

   An RPZ resource record can specify any of six results or actions.

3.1.  The "NXDOMAIN" Action (CNAME .)

   A single resource record (RR) consisting of a CNAME whose target is
   the root domain (.) will cause a response of NXDOMAIN to be returned.
   This is the most commonly used RPZ 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-
   level domain (*.) will cause a response of NODATA (ANCOUNT=0) to be
   returned regardless of query type.

         $ORIGIN RPZ.EXAMPLE.ORG.
         example.com                   CNAME   *.  ; return NODATA
         *.example.com                 CNAME   *.  ; return NODATA

3.3.  The "PASSTHRU" Action (CNAME rpz-passthru.)

   It is sometimes necessary to exempt some DNS responses from the
   response a 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  The trigger for the PASSTHRU action MUST have a higher
   precedence than the policies that it must override.
   See should override (see Section 5.1 about 5,
   Precedence Rules).

   In the precedence rules.

   This policy zone example below, the first PASSTHRU record

           $ORIGIN RPZ.EXAMPLE.ORG.
           ok.example.com      CNAME   rpz-passthru.

   would exempt exempts requests for ok.example.com
   a particular host from the NXDOMAIN policy or action of the following record: subsequent
   records.  The second PASSTHRU record exempts responses to the DNS
   client at 192.0.2.1 from being modified:

         $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   .

3.4.  The deprecated original encoding of "DROP" Action (CNAME rpz-drop.)

   The DROP policy that results in discarding the PASSTHRU action was a CNAME
   with a target equal to the QNAME field of the DNS request.  That
   encoding could not be used with some desirable triggers.

3.4.  The "DROP" Action

   The "DROP" policy that consists of discarding the request and
   response is specified by request and response
   is specified by a CNAME whose target is "rpz-drop".  For example, with

           $ORIGIN RPZ.EXAMPLE.ORG.
           example.com         CNAME   rpz-drop. the
   following rule mandates that nothing is be sent to a DNS client trying
   to resolve example.com, "EXAMPLE.COM", not even a DNS error response. response:

         $ORIGIN RPZ.EXAMPLE.ORG.
         example.com                   CNAME   rpz-drop.

3.5.  The "TCP-Only" Action (CNAME rpz-tcp-only.)

   The "TCP-Only" policy TCP-Only action is specified by a CNAME whose target is
   "rpz-tcp-only".  It changes UDP responses to short, truncated DNS
   responses that require the DNS client to try again with TCP.  It is
   used to mitigate distributed DNS reflection attacks and is similar to
   the "slip" parameter of DNS Response Rate Limiting (RRL) [ISC-RRL].

         $ORIGIN RPZ.EXAMPLE.ORG.
         example.com                   CNAME   rpz-tcp-only.

3.6.  The "Local Data" Action

   An RRset (arbitrary RR types)

   A set of RRsets with a common trigger owner name (see Section 4) that is
   includes neither a special CNAME RPZ encoding of an action nor one of several
   the problematic record types listed below specifies local data to be used
   to generate synthetic DNS responses.  The most common Local Data is a
   CNAME RR pointing to a walled garden, although other record types are
   also used.

         $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 of NXDOMAIN (.), NODATA (*.), that are:

      +  "."  (NXDOMAIN action),
      +  "*." (NODATA action),
      +  a top level domain starting with "rpz-", or
      +  a child of a top level domain starting with "rpz-".  Problematic record

   The problematic types include NS and DNSSEC records which also do not encode Local Data
   actions include:

      +  SOA records,
      +  NS records,
      +  DNAME records,
      +  all DNSSEC-related records (see
   [RFC4034]), [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 DNAME RRsets are also commonly
   rejected by RPZ subscribers for internal implementation and other
   reasons.  If any local data Data policy actions rule matches, the RRsets of Local Data are present, then any
   request for an RR type that is not present in
   used to generate the local data is
   answered as NODATA (ANCOUNT=0) response as if they comprised all of the recursive DNS server using
   RPZ were
   authoritative data for the query name.

   The most common local data QNAME.  If the requested type (QTYPE) is a CNAME
   ANY, then all of these Local Data RRsets are returned.  Otherwise,
   the RRset of the requested RR pointing to type is returned, or a walled garden.
   Such CNAME RRs are distinguishable from other rpz actions, because
   the is
   returned if it is available.  If no CNAME target name 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 not be receive NODATA, because the root (.), nor policy rule with the root wildcard
   (*.), nor be a subdomain matching Client
   IP Address trigger contains RRsets of a top level domain that starts 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
   "rpz-". the LOCAL-DATA-OR-PASSTHRU or
   LOCAL-DATA-OR-DISABLED overrides described in Section 6.1.

   A special form of local data Local Data involves a CNAME RR with a wildcarded
   target name.  Wildcards are not valid as CNAME targets in ordinary
   DNS zones.  This special form  However, a wildcard in an RPZ Local Data CNAME target
   causes the matching QNAME to be prepended to the
   wildcarded target to communicate in the triggering
   rewritten response, which communicates this QNAME value to the walled
   garden DNS server. server for that DNS server's logs.

   For example a policy Local Data action of "CNAME *.EXAMPLE.COM" and
   applied to a query name QNAME of "EVIL.ORG." "EVIL.EXAMPLE.ORG." will result in a synthetic
   response of "EVIL.ORG that starts with the RR
   "EVIL.EXAMPLE.ORG CNAME EVIL.ORG.EXAMPLE.COM."  The
   purpose for this special form is query logging in EVIL.EXAMPLE.ORG.EXAMPLE.COM".  Resolving the walled garden's
   DNS server.

4.  Policy Triggers

   There are five types of RPZ triggers, and they are encoded by RRset
   owner names (left hand sides) in
   CNAME target "EVIL.EXAMPLE.ORG.EXAMPLE.COM" into an RPZ.

   Two of these types of trigger match characteristics RRset of the DNS query:
   "Client IP address"
   originally requested type generally requires sending a request for
   that type and "QNAME".  They are independent a QNAME of cache
   contents or recursion results, but must be checked conceptually "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 is ready, including after 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 needed recursion.
   Recursion case can sometimes be skipped, but only if 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

   There are five types of RPZ result would
   not triggers, and they are encoded by RRset
   owner names (left hand sides) in an RPZ.

   Two of these trigger types match characteristics of the DNS query:
   Client IP Address and QNAME.  While these two trigger typess are
   independent of cache contents or recursion results, still
   conceptually they must be changed checked only once the response is ready,
   because they compete for precedence (see Section 5.1). 5) with other
   trigger types which depend on what happens during recursion.

   The other three trigger types of triggers are based on characteristics of the DNS
   response, that is, on the RDATA to be returned to the client, or in
   some cases, on NS-related RDATA used while recursively obtaining the
   final response, regardless of whether or not those NS records or
   additional data NS-related
   records are themselves to be returned to the client.  These three
   trigger types are: "Response Response IP address", "NSDNAME", Address, NSDNAME, and
   "NSIP". NSIP.

   Neither the TTL fields of RRs in the answer section nor the query
   type (QTYPE) in the question section of responses are used as RPZ
   triggers, although the QTYPE is used to select appropriate RRsets
   among the RRsets of matching Local Data rules (Section 3.6).

   All policies are conceptually applied after recursion, even though in
   practice recursion can sometimes be skipped, if doing so that 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," "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 Trigger (.rpz-client-ip)

   The IP addresses of DNS clients sending requests can be used as
   triggers, which can be useful for disabling RPZ rewriting for DNS
   clients used to test for testing or investigate. investigating, or for quarantining
   compromised clients.  Client IP address Address policy RRsets have owner
   names that are subdomains of "rpz-client-ip" relativized to the RPZ
   apex name, preceded by an encoded IP address or block of addresses.

   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
   2001:db8::3.

         $ORIGIN RPZ.EXAMPLE.ORG.
         24.0.2.0.192.rpz-client-ip      CNAME rpz-drop.
         128.3.zz.db8.2001.rpz-client-ip CNAME rpz-passthru.

4.1.1.  IP address encoding in triggers

   The IPv4 address (or or address block) block "B1.B2.B3.B4/prefix" is encoded in
   an RPZ trigger as "prefix.B4.B3.B2.B1", with the address octets
   reversed just as in the IN-ADDR.ARPA naming convention.  (See
   [RFC1034].) convention described in
   [RFC1034].  The prefix length ("prefix") must be between 1 and 32. is a decimal integer from 1
   to 32.  All four bytes, octets, B4, B3, B2, and B1, must be present and must be
   written in are
   also decimal ASCII. integers.  To avoid confusion with octal notation,
   leading zeros MUST be suppressed.

   For example, the address block 192.0.2.0/24 would be is encoded as
   "24.0.2.0.192".

   The IPv6 address (or or address block beginning at) at
   "W1:W2:W3:W4:W5:W6:W7:W8" is encoded in a format similar to the
   standard IPv6 text representation (see [RFC5952]), again reversed:
   "prefix.W8.W7.W6.W5.W4.W3.W2.W1".  The prefix length ("prefix") is a
   decimal integer from 1 to 128.  Each of W8,...,W1 is a one- to
   four-digit four-
   digit hexadecimal ASCII number representing 16 bits of the IPv6
   address address.
   As in [RFC5952], in order to avoid confusion with no octal notation,
   leading zeroes. zeroes MUST be suppressed.

   All 8 words hextets must be present unless a "zz" label is present.  The
   "zz" label is analogous to the double-
   colon double-colon (::) in [RFC5952], and it
   is required and allowed just as the standard IPv6 address representation.  The "zz"
   label double-colon is expanded to zero-fill required and
   allowed in that document.  In particular, the middle portion longest possible
   sequence of the IPv6
   address.  Exactly one "zz" label must zero-valued fields MUST be present if compressed to "zz".  If there are two or
   exists more consecutive zero words in than one sequence of zero-valued fields of identical
   length, then only the address.  The prefix length
   ("prefix") must be between 1 last such sequence is compressed.  Note that
   [RFC5952] specifies compressing the first such sequence, but our
   notation here reverses the order of fields, and 128 so must also reverse
   the selection of which zero sequence to compress.

   For example, the address 2001:db8::3 (with implied with a prefix length 128) of 128
   would be encoded as "128.3.zz.db8.2001".

   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.

4.2.  The "QNAME" trigger Trigger ("example.com")

   The QNAME policy trigger matches on requested domains, that is, the
   QNAME field in of the question section of 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
   expressed.  For example, if the RPZ apex name is RPZ.EXAMPLE.ORG, "RPZ.EXAMPLE.ORG",
   an RRset at example.com.RPZ.EXAMPLE.ORG "EXAMPLE.COM.RPZ.EXAMPLE.ORG" would affect responses to
   requests about example.com. "EXAMPLE.COM".

   Wildcards also work, and work as expected, so the owner name
   "*.example.com.RPZ.EXAMPLE.ORG"
   "*.EXAMPLE.COM.RPZ.EXAMPLE.ORG" would trigger on match queries to for any subdomain
   of example.com. "EXAMPLE.COM".  To control the policy for both a name and its
   subdomains, two policy RRsets must be used, one for the domain itself
   and another for a wildcard subdomain.  In the following example,
   queries for both example.com "EXAMPLE.COM" and all subdomains of
   example.com "EXAMPLE.COM"
   will result in synthetic NXDOMAIN responses.

         $ORIGIN RPZ.EXAMPLE.ORG.
         example.com                 CNAME   .
         *.example.com               CNAME   .

4.3.  The "Response IP address" trigger Address" Trigger (.rpz-ip)

   The response Response IP policy Address trigger matches response contents (RDATA): it
   matches IP addresses that would otherwise
   appear in the unaltered DNS response contents, specifically the RDATA
   of A and or AAAA records in the answer section sections of a DNS response. responses.  IP
   addresses in the authority and additional sections are not
   considered.  Response IP Address policy RRsets have owner names that
   are subdomains of "rpz-ip" relativized to the RPZ apex name, and an
   encoded IP address or block of addresses.  The IP address encodes encodings
   are identical to those described in Section 4.1.1for 4.1.1 for Client IP
   Address triggers.

   For example, to force an NXDOMAIN response whenever a truthful
   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
   contain these records:

         $ORIGIN RPZ.EXAMPLE.ORG.
         24.0.2.0.192.rpz-ip         CNAME   .
         32.2.2.0.192.rpz-ip         CNAME   rpz-passthru.

   In another example, to answer NODATA (ANCOUNT=0) whenever a truthful
   response would contain an answer AAAA RRset having an address
   2001:db8:101::/48 unless address 2001:db8:101::3 was present, the RPZ
   would contain these records:

         $ORIGIN RPZ.EXAMPLE.ORG.
         48.zz.101.db8.2001.rpz-ip    CNAME  *.
         128.3.zz.101:db8.2001.rpz-ip CNAME  rpz-passthru.

   Please refer to Section 5.1 5 (Precedence Rules) to understand how the
   above exception
   mechanims mechanisms work.

4.4.  The "NSDNAME" trigger Trigger (.rpz-nsdname)

   The NSDNAME policy trigger matches name server names (NS RR) of any all
   name server which is servers in the data path paths for an RRset all RRsets that would be present
   in the answer section of a the unaltered DNS response.

   The data path is all delegation
   points for a given answer RRset consists of all delegation
   points from (and including) the root zone down to the closest
   enclosing NS RRset for the owner name of the answering that RRset.

   In other words, an NSDNAME trigger is checked by first considering  Names in the named servers (domain
   RDATA of answer RRs including CNAME, DNAME, SRV, and MX are not
   themselves directly relevant, but CNAME and DNAME target names in are
   indirectly relevant if they cause RRsets to be added to the NS records) for answer
   section, in which case it is the query
   domain (QNAME), then data paths of the name servers for added RRsets that
   matter.  In the parent case of a DNAME answer, the query
   domain name, and so on until the owner name servers for of an added
   synthetic CNAME is likely to differ from the root (.) have
   been checked or there fewer periods (.) target name in the domain name than DNAME
   RR.  Recall also that the
   value target of a local "min-ns-dots" parameter.  See Section 4.4.1.1 below. 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"
   but otherwise are much like QNAME policies (xref target="qname"/>). (Section 4.2).  For
   example, to force an NXDOMAIN answer whenever a name server for the
   requested domain or one of its parents is ns.example.com, "NS.EXAMPLE.COM", the RPZ
   would contain the following:

         $ORIGIN RPZ.EXAMPLE.ORG.
         ns.example.com.rpz-nsdname  CNAME   .

4.4.1.  Implementation considerations

   The NS records used for NSDNAME triggers

   Note that these considerations apply also to NSIP triggers described this calculation are either delegations (NS
   RRs in Section 4.5 below.

4.4.1.1.  Performance issues

   The process the authority sections of traversing answers from authorities for the
   parent zone) or authoritative data path from the level nearest the
   queried record to the top (root domain) level can 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.

   An RPZ implementation MAY be expensive,
   especially when it comes configurable to avoid checking all the many NS records for the top
   level domains and the root.  Because the name servers for
   way up to the root and the TLDs are rarely used as RPZ triggers, some RPZ
   implementations have a "min-ns-dots" parameter that stops to perform only partial NSDNAME and checks; see
   Section 9.3 on "min-ns-dots".

4.5.  The "NSIP" Trigger (.rpz-nsip)

   The NSIP checking early.

   Despite their costs, NSDNAME and policy trigger matches name server addresses, that is A or
   AAAA RRs referenced by an NS RRset.  NSIP triggers can be more effective is like NSDNAME
   (Section 4.4) except that the matching is by name server address
   rather than QNAME and IP triggers.  Miscreants can more easily change their
   direct domain names and IP addresses (which name server name.  NSIP policies are detected by QNAME expressed as
   subdomains of "rpz-nsip" and have the same subdomain naming
   convention as that described for encoding IP triggers) than they can their change NS names and addresses
   (detected by in Response IP
   Address triggers (Section 4.1.1).

   In a process similar to that for an NSDNAME and trigger, an NSIP triggers) in parent domains such as
   TLDs.

4.4.1.2.  Caching trigger
   is checked by considering all of NS records and related address the IP addresses for all of the name
   servers in the data

   Some implementations paths for all RRsets that would be present in the
   answer section of the unaltered DNS RPZ will attempt to exhaustively discover response.

   As with NSDNAME triggers, the data path for a given RRset consists of
   all ancestral zone cuts above delegation points from (and including) the query name and learn root zone down to the
   closest enclosing NS RRset
   at for the apex owner name of each delegated zone.  Other implementations will know
   only that RRset.  Also
   like NSDNAME triggers, the zone cut information which has naturally come into RDATA in these RRsets (other than the
   cache, which will often include only name server names and IP
   addresses
   from the parent.  Apex ("below of the cut") name server names and
   addresses often do servers) are not exactly match those from the parent.  Such
   inconsistencies can lead directly relevant.

   For example, to instability in DNS RPZ behavior.  This
   potential inconsistency must be taken into account when designing a
   security policy force an NXDOMAIN answer whenever one of the name
   servers for the requested domain (QNAME) or testing DNS RPZ.

   For NSDNAME and NSIP triggers, one of its ancestors has
   an address in the 192.0.2.0/24 block, the BIND9 and Unbound RPZ
   implementations (as of 2016) match would contain the
   following:

         $ORIGIN RPZ.EXAMPLE.ORG.
         24.0.2.0.192.rpz-nsip       CNAME   .

   The NS, A, and AAAA RRsets already
   in their caches unless there records used for this calculation 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 either
   delegations and checking QNAME glue (RRs in authority and response IP address triggers.  In addition, additional sections of
   answers from authorities for the parent zone) or authoritative apex NS RRset (which, if obtained, would supersede
   the cached NS RRset data
   from the delegating zone) of a domain operated by
   a malefactor is often peculiar.  Even when it zone itself.  As with NSIP, an implementation MAY use
   either, both, or whichever is reasonable, currently available; see Section 9.4 on
   "ns-wait-recurse".

   An RPZ implementation MAY also be configurable to avoid checking all
   the
   authoritative DNS servers for such a domain are often extremely slow
   or broken.  For example, RRs like "example.com NS ." claiming root as way up to the authoritative server for a second or lower level domain are
   popular choices in miscreant apex NS RRsets, as are imaginative name
   servers A root and AAAA RRsets.

4.5.  The "NSIP" trigger (.rpz-nsip)

   The to perform only partial NSIP checks; see
   Section 9.3 on "min-ns-dots".

5.  Precedence Rules

   More than one policy trigger matches name server addresses, that is A or
   AAAA RRs referenced by an NS RRset.  NSIP is much like NSDNAME
   (described above) except that among the various DNS RPZs connected to
   the matching is by name server address
   rather than name server name.  NSIP policies server's control plane can match while computing a given DNS
   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.

   These precedence rules exist and are expressed as
   subdomains of "rpz-nsip" ordered to ensure that RPZ
   subscribers and publishers have the same subdomain naming
   convention as described for response IP policy triggers above
   (Section 4.1.1).

   In understanding of what a process very similar set
   of policy zones will do, and to ensure that subscribers can use local
   zones to override published policy zones.

   In theory and for an NSDNAME trigger
   (Section 4.4), an NSIP trigger is checked by first considering all of
   the IP addresses for standardization, all the named servers for the QNAME, then
   proceeding similarly parent of the QNAME, matching policy rules are
   considered simultaneously, and so on until the name
   servers for precedence rules are used to
   choose the root (.) have been checked or a single best RPZ rule.  In actual implementations, policy has been
   matched.

   Policies
   triggers are applied in order of precedence (see Section 5.1) at each
   level usually considered in a sequence that mirrors the data path.  The data path traversal
   process stops
   immediately when there of generating the DNS response, because checking RPZ triggers
   is at least one policy match at conveniently made a given level. part of that process.  For example, to force an NXDNAME answer whenever one of Client IP
   Address triggers are often checked early as the name
   servers for DNS request is being
   received and as the requested domain (QNAME) or one of its parents has an client IP address is being checked in the 192.0.2.0/24 block, the RPZ would contain the
   following:

           $ORIGIN RPZ.EXAMPLE.ORG.
           24.0.2.0.192.rpz-nsip     CNAME   .

4.5.1.  Implementation considerations for NSIP triggers

   The performance and caching considerations access
   control list (ACL) that determines which DNS client IP addresses can
   ask for recursion.  Likewise the implementation of
   NSIP QNAME is available for RPZ trigger
   matching before any response IP addresses are known, so QNAME
   triggers are essentially identical to those described for usually checked immediately after Client IP Address
   triggers and before Response IP Address triggers.  NSIP and NSDNAME
   triggers (Section 4.4.1).

5.  Application of the Policy

   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
   of RPZs in are generally checked last.

   As far as the name server's configuration.  For each DNS RPZ in this
   list, client can determine, it should be possible to specify an optional overriding policy
   action to be used for any policy MUST seem that all
   matching triggers are found in that RPZ.  These
   override policies should include NXDOMAIN, NODATA, PASSTHRU, DROP,
   TCP-ONLY, CNAME domain, GIVEN, and DISABLED.  The first five of weighed using these
   actions are defined precedence rules,
   even though in Section 3 above.  "CNAME domain" is a
   restricted case of practice, shortcuts are taken.  Shortcuts MUST NOT
   affect the "Local Data" action (also defined in
   Section 3) in which outcome.  For example, according to the rewritten response is precedence rules,
   a CNAME RR targeting
   "domain."  GIVEN explicitly reaffirms matched QNAME trigger in the default, which first policy zone makes all Response
   IP Address, NSIP, and NSDNAME triggers moot.  There is no need to
   respect all policy actions found in this DNS RPZ.
   look for those matches, because they cannot further affect the
   response.

   The overriding
   DISABLED action causes triggered actions specified in policy rules are not used 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 calculation
   of precedence.  The actions of policy zone.

   By default, policies are applied only on DNS requests that ask for
   recursion (RD=1).  Recursive DNS servers generally send their
   requests to authority servers without asking for recursion (RD=0),
   while stub resolvers ask for recursion (RD=1).  Thus, RPZ at a
   recursive server by default only affects requests from stub
   resolvers.  This default can be overridden in some implementations
   with configuration statements such as "recursive-only no".

   Also rules determined by default, RPZ policies are only applied to responses to DNS
   requests per-zone
   action overrides (Section 6.1), other than those that disable them,
   likewise do not request DNSSEC metadata (DO=0) or for which no
   DNSSEC metadata exists.  This defaults can be overridden in some
   implementations with a configuration statement such "break-dnssec
   yes".  See Section 10 about affect the implications calculation of responding with
   modified DNS responses when the DNS client seems to be expecting
   DNSSEC signatures.

   If a precedence.  Override
   actions which disable policy rule matches and results in a modified answer, then that
   modified answer will include rules affect this calculation only by
   removing those rules from consideration.

   Precedence rules are applied in its authority section the SOA RR of order listed here; the comparison
   between two matching policy zone whose policy was used rules to generate the modified
   answer.  This SOA RR includes the name of choose the DNS RPZ and better match is
   determined by the serial
   number of first dispositive precedence rule in this list.
   Note however that if the policy data which was connected to best match selects a disabled rule (caused
   by the DNS control
   plane when DISABLED override described in Section 6.1), then the answer was modified.

   Conceptually, policies MUST be applied after recursion next
   best match is complete used, and all data needed to formulate so on until 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, policy rule 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 not
   disabled is resolved with CNAME selected 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 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, or nor DNAME, and only when a CNAME or DNAME is encountered
   while resolving the resolver original QNAME, in what we will start over and try to
   resolve call the target first
   "stage of resolution".  In this case, we know that the CNAME.  RPZ is also restarted and recursive name
   server ([RFC1035]) may follow the CNAME
   target is matched against (or the synthetic CNAME policy rules resolved IP addresses
   (if any)
   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 matched with encountered,
   until the final 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 computed.

   A policy trigger among the various DNS RPZs connected rule match which occurs at an earlier stage of resolution is
   preferred to
   the name server's control plane can a policy rule match which occurs at a given DNS response, but later stage.

   Recall that only a single one policy rule rule, from among all those matched at all
   stages of resolving a CNAME or DNAME chain, can affect the response.  In theory and for
   standardization, all possible rules are considered simultaneously and final
   response; this is true even if the following selected rule has a PASSTHRU
   action.

5.2.  "RPZ Ordering" Precedence Rule

   This precedence rules are used to choose rule applies when the single best RPZ
   rule.  In implementations, matches being compared refer to
   policy triggers are usually considered rules in different RPZs.

   Matches on rules in an RPZ specified earlier in
   a sequence that mirrors the process ordered list of generating the DNS response,
   because checking
   RPZs take precedence over matches on rules in an RPZ triggers is conveniently made specified later.

5.3.  "Domain Name Matching" Precedence Rule

   This precedence rules applies to a part set of that
   process.  For example, client IP RPZ address QNAME rules or a set of
   NSDNAME rules in a single RPZ.  The rule triggers are often
   checked early as compared.

   This rule is the same as that used by DNS request is being received and servers to choose the client IP
   address RRs
   with which to respond to a request.  In particular, an exact name
   match is checked in better than one involving a wildcard, and among wildcard
   matches, the access control list (ACL) trigger (owner domain name) that determines
   which has the largest number
   of labels is best.

   Since a DNS client IP addresses can ask for recursion.  The 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
   available for RPZ sufficient to choose a single QNAME trigger matching before any response IP addresses
   are known and so over other 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 in the same RPZ.  However, computing a single DNS client response
   can determine, it MUST seem that all
   matching match dozens of NSDNAME triggers are found and weighed using 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 rules, rule applies to policy rules within the same RPZ, but in practice, shortcuts
   with different trigger types.

   In this case, matches are taken.  For example, ranked according to the
   precedence rules, a matched QNAME trigger type in the first policy zone
   makes all response
   following order, from highest to lowest precedence:

      +  Client IP address, NSIP, and Address
      +  QNAME
      +  Response IP Address
      +  NSDNAME triggers moot.
   There is no need
      +  NSIP

5.5.  "Name Order" Precedence Rule

   This precedence rule applies to look for those matches, because they will a set of NSDNAME matches whose
   precedence has not
   affect the response.

   The following list is ordered so that rules listed early override
   rules listed later.

   RPZ Ordering
      Changes triggered been established by records in RPZs specified earlier in previous precedence rules.
   Here, the
      ordered set of DNS RPZs matched name server domain names are applied instead compared, not the
   owner names (triggers) of triggers in the policy
      zone specified later.

   Within An RPZ
      Among policies from rules.  Therefore, it is
   irrelevant whether the matched trigger was a single RPZ, client IP address policies are
      chosen instead of QNAME policies, QNAME policies are preferred to
      IP, IP policies are preferred to NSDNAME, and NSDNAME policies are
      preferred to NSIP.

   Exact name match
      As in exact versus wildcard or a specific
   domain name name.

   Among the matching at authority
      servers, exact domain name QNAME or NSDNAME triggers are preferred
      to wildcards.

   Name Length
      The preceding rule implies QNAME policies are preferred to NSDNAME
      policies.

      Among triggered QNAME or NSDNAME policies within an RPZ, choose
      the policy that matches rules, choose the triggering one whose matched
   name server domain name that appears
      earlier last in the sorting using the DNSSEC canonical DNS name
   order described in section 6.1 of [RFC4034].  The last labels of domain
      names are most significant in that ordering.  A domain name that

   Important note: if this precedence rule is a parent of another appears before reached, the child.  Labels are matches being
   compared originate from different NS names, not from the same name
   matching multiple rules, as if they were words in those conflicts would have been dispensed
   with by the "Domain Name Matching" Precedence Rule (Section 5.3).
   There is no a dictionary priori reason to prefer one NS name over another, so that a label
      that
   while this tie-breaker precedence rule is a prefix 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 a second label appears before the second.
      Characters example directly from section 6.1 of [RFC4034],
   and reversing the order to take into account that the name that
   appears last in labels are sorted by their values the DNSSEC canonical order is to be taken as US-ASCII
      characters except that uppercase letters the best
   match here, the following NS names are treated as if they
      were lowercase.

   Prefix Length
      A preceding 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 implies that applies when more than one Response IP policies within an RPZ are
      preferred to Address
   policy rule or more than one NSIP policies.

      Among triggered policy rule matches while computing
   a response.  The rule triggers themselves are compared.

   When comparing two Response IP Address matches or two NSIP policies, use the policy (not matches on
   rules within a single RPZ, choose the
      matched IP address) with match whose rule trigger has
   the longest internal policy zone "internal prefix
      length. length".  The internal prefix length of
   an IPv6 address trigger is the numeric value of the first label that
   defines it as described in Section 4.  The internal prefix length of 4.1.1 on
   IP address encoding in triggers.  For an IPv4 trigger address trigger, the
   internal prefix length is the numeric value of its first label plus 112.
   96 (that is, 128-32).  This adjustment
      makes allows IPv4 triggers work the same as their equivalent
      IPv4-compatible and IPv6 address triggers.  It also tends addresses
   to favor use the same internal representation, with 32-bit IPv4 triggers over IPv6 triggers.  (See addresses
   expanded to 128 bits by zero filling as described in section 2.5.5.1
   of
      [RFC4291] about IPv4-compatible IPv6 addresses.)

   Tie Breaker
      Given equal internal prefix lengths, use the [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
      that rule matches while computing
   a response, and they have the first same internal prefix length.  The rule
   triggers are compared.

   When comparing Response IP address.  Addresses Address or NSIP triggers with equal trigger
   internal prefix lengths lengths, choose the trigger which encodes the smaller
   IP address.  The IP addresses from the triggers are ordered compared as 128
   bit numbers, with IPv4 addresses expanded to 128 bits by their representations zero filling
   as
      domain names described in Section 4, including the leading,
      unadjusted prefix length.  Because section 2.5.5.1 of [RFC4291].

   Important note: if this tie breaking considers precedence rule is reached, the
      matched matches being
   compared originate from different IP addresses instead of addresses, not from the triggered policy same
   address matching multiple rules, as those conflicts would have been
   dispensed with by the
      first or least significant label of an IPv6 "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 always
      "128", 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 label of an IPv4 address is always "32". most preferred and the IPv6 address
   is least preferred.

6.  Subscriber Behavior

   RPZs must be primary or secondary zones at subscriber  Application of the Policy

   To enable the use of RPZs, the recursive
   resolvers.  They can be searched only name server's control plane
   is connected to the DNS RPZ data plane by supplying an ordered list
   of RPZs in a recursive the name server's own
   storage, because additional network transactions configuration.

   By default, policies are applied only on DNS requests that ask for
   recursion (RD=1).  Recursive DNS servers generally send their
   requests to authority servers without asking for recursion (RD=0),
   while stub resolvers
   are extremely undesirable.

   Response policy zones are loaded in the usual way.  For primary zones
   this may mean loading ask for recursion (RD=1).  Thus, the contents use of RPZ
   at a local file into memory, or
   connecting to a database.  For secondary zones this means
   transferring the zone from the primary recursive server using zone transfer by default affects requests from stub resolvers
   only.  An implementation SHOULD include a configuration option such
   as IXFR [RFC1995] or AXFR [RFC5936].  It is strongly recommended
   that all secondary zone transfer relationships be protected with
   transaction signatures (DNS TSIG) and that real time change
   notification be enabled using the DNS NOTIFY protocol [RFC1996]. "recursive-only no" to relax this restriction.

   Also by default, RPZ policies are applied only while responding to
   DNS resolvers often have limited requests that do not request DNSSEC metadata (DO=0) or for which
   no notion of DNSSEC metadata exists.  An implementation MAY include a DNS zone or zone
   file.  They sometimes have special local zones, but generally have no
   implementations
   configuration option such as "break-dnssec yes" to relax this
   restriction.  See Section 12.2 about the implications of IXFR, AXFR, or NOTIFY.  Therefore, an external
   module or daemon responding
   with modified DNS responses when the DNS client seems to be expecting
   DNSSEC signatures.

   RPZ rules do not apply to synthetic data generated by using RPZ
   rules.  For example, if RPZ supplies a CNAME pointing to a walled
   garden, RPZ policies will not be used while following that maintains CNAME.  If
   RPZ supplies local copies of policy zones can be
   useful.

7.  Producer Behavior data giving a particular A DNS record, RPZ producer should make every effort policies
   will not apply to ensure that
   incremental zone transfer (IXFR [RFC1995]) rather than full zone
   transfer (AXFR [RFC5936]) response IP address.

   If an illegal record is encountered while computing a response, for
   example an NS record with a CNAME target, and this illegal record is
   ignored by the resolver, then it is likewise not used for RPZ rule
   matches.

   If a policy rule matches and results in a modified answer, then that
   modified answer will include in its additional section the SOA RR of
   the policy zone whose rule was used to move new generate the modified answer.
   This SOA RR includes the name of the DNS RPZ and the serial number of
   the policy data toward
   subscribers.  Also, real time zone change notifications (DNS NOTIFY
   [RFC1996]) should which was connected to the DNS control plane when the
   answer was modified.

6.1.  Per-Zone Action Overrides

   For each DNS RPZ configured for use by a recursive name server, it
   SHOULD be enabled possible to specify a single, OPTIONAL overriding policy
   action to be used for all policy triggers found in that RPZ.  These
   policy action overrides include the following:

   NXDOMAIN
      SHOULD be implemented and is the same as the NXDOMAIN action
      defined in Section 3.1.

   NODATA
      SHOULD be implemented and is the same as the NODATA action defined
      in Section 3.2.

   PASSTHRU
      SHOULD be implemented and is the same as the PASSTHRU action
      defined in Section 3.3.

   LOCAL-DATA-OR-PASSTHRU
      MAY be implemented.  It modifies the Local Data action
      (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.

   DROP
      SHOULD be implemented and is the same as the DROP action defined
      in Section 3.4.

   TCP-ONLY
      SHOULD be implemented and is the same as the TCP-ONLY action
      defined in Section 3.5.

   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.

   GIVEN
      MAY be implemented to explicitly affirm the default, which is to
      respect all policy actions found in this DNS RPZ.

   DISABLED
      SHOULD be implemented and causes any rule of the zone, when
      selected as a "best match", to have no effect, except to log what
      would otherwise have happened, provided sufficient logging is
      enabled.  The DISABLED override thus causes the next highest
      precedence match (if any) to be used (see Section 5,
      Precedence Rules).  This is useful for debugging or previewing a
      policy zone.

   LOCAL-DATA-OR-DISABLED
      MAY be implemented.  It modifies the Local Data action
      (Section 3.6) so that requests for RR types that would otherwise
      give a Local Data result of NODATA (ANCOUNT=0) are instead handled
      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

   A DNS RPZ producer SHOULD make every effort to ensure that
   incremental zone transfers (IXFR [RFC1995]) rather than full zone
   transfers (AXFR [RFC5936]) are used to move new policy data toward
   subscribers.  DNS RPZ subscribers are "stealth slaves" as described
   in RFC 1996.  The master MUST allow each such slave to perform the
   needed zone transfers, for example via its access control lists
   (ACLs).  The master also SHOULD be configured as necessary to send
   NOTIFY messages to each slave.  Because minimal data latency is
   critical both to the prevention of crime and abuse and to the
   withdrawal of erroneous or outdated policy, a DNS RPZ producer SHOULD
   also make every effort to minimize data latency, including ensuring
   that NOTIFY messages are sent in a timely manner after each change of
   the DNS RPZ on the master server.

   In a response policy zone domain, each addition, deletion, or
   expiration could be handled using DNS UPDATE [RFC2136] to trigger
   normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the
   subscribing servers well synchronized to the master RPZ.
   Alternatively, on some primary name servers (such as ISC BIND9) it is
   possible to generate an entirely new primary RPZ file and have the
   server compute the differences between each new version and its
   predecessor.  In ISC BIND9 this option is called
   "ixfr-from-differences" and is known to be performant even for
   million-rule DNS RPZ's with significant churn on a minute by minute
   basis.

   It is good operational practice to include test records in each DNS
   RPZ to help that DNS RPZ's subscribers verify that response policy
   rewriting is working.  For example, a DNS RPZ might include a QNAME
   policy rule for "BAD.EXAMPLE.COM" as well as a Response IP Address
   policy rule for 192.0.2.1.  A subscriber can verify the correctness
   of their installation by querying for "BAD.EXAMPLE.COM", which does
   not exist in real DNS.  If an answer is received it will be from the
   DNS RPZ.  That answer's additional data section will usually contain
   an SOA RR denoting the fully qualified name of the DNS RPZ itself.

8.  Subscriber Behavior

   RPZs MUST be primary or secondary zones at subscriber recursive
   resolvers.  They can be searched using only a recursive server's own
   storage, because additional network transactions for DNS resolvers
   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 tested. NSIP Checks

   Some implementations of DNS RPZ subscribers are
   "stealth slaves" as described in RFC 1996, attempt to exhaustively discover all
   ancestral zone cuts above the query name and learn the NS RRset at
   the apex of each such 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 must
   be explicitly listed in names and
   addresses sent by servers for the master server's configuration as
   necessary to allow parent zone transfers from and not by those for
   the zone itself.  Both of these tactics have shortcomings, but the stealth slave,
   more accurate tactic of checking delegations and glue as well to
   ensure that zone change notifications are sent to it.  Because DNS
   NOTIFY as
   authoritative NS, A, and AAAA RRsets is a lazy protocol, it may be necessary to explicitly trigger generally considered too
   expensive.

   To limit the master server's "notify" logic after each change 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 DNS RPZ.
   These operational guidelines are resolver to limit policy
   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 latency, since
   minimal latency is critical to both prevention 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 crime a
   recursive server for NS RRsets and associated A and AAAA RRsets will
   often initially receive only delegations and abuse, glue from the cache.  As
   time passes and TTLs expire, those requests tend to withdrawal of erroneous or outdated policy.

   In the data feed for disreputable domains, each addition or deletion
   or expiration can be handled using DNS UPDATE [RFC2136] to trigger
   normal DNS NOTIFY answered less
   with delegations and subsequent DNS IXFR activity which can keep glue and more with authoritative RRsets.  If and
   when sufficient RRsets expire from the
   subscribing servers well synchronized to cache, the master RPZ.
   Alternatively, on some primary name servers (such as ISC BIND) it is
   possible to generate an entirely new primary cycle repeats with
   RPZ file once again relying more on delegations and have the
   server compute glue.  Thus, if the differences between each new version
   glue and its
   predecessor.  In ISC BIND this option authoritative RRsets differ, then RPZ installations that use
   whichever is called "ixfr-from-
   differences" and available in the cache can produce inconsistent results.

   This is known to be performant even not an argument for million-rule DNS
   RPZ's with significant churn on a minute by minute basis.

   It is good operational practice NSDNAME or NSIP triggers to include test records not use glue,
   because as discussed in each DNS 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 to help that DNS RPZ's subscribers verify that response policy
   rewriting is working.  For example, a 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 RPZ servers as they are as mail senders, and so might include a reasonably have
   NSDNAME rules in addition to their QNAME
   policy record for BAD.EXAMPLE.COM rules.  However, instead of
   paying the costs of doubling that RPZ zone to 16 million rules and
   400 MBytes, an IP policy record for
   192.0.2.1.  A subscriber can verify RPZ implementations MAY offer a per-zone setting (for
   example "qname-as-ns yes") which causes the correctness of their
   installation by querying implementation to act as
   if for BAD.EXAMPLE.COM which does not exist in
   real DNS.  If an answer every rule with the trigger "EXAMPLE.COM", there is received it will be from another
   rule in the DNS RPZ.
   That answer will contain an SOA RR denoting RPZ with the fully qualified name 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 DNS RPZ itself.

8. 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 was previously described can be found in a technical note from
   Internet Systems Consortium [ISC-RPZ].  A more up to date description appeared  RPZ was also described in
   2010 in chapter 6 of the "BIND 9 Administrator Reference Manual" [ISC-ARM]
   as of 2010.
   [ISC-ARM].

   RPZ was designed by Paul Vixie and Vernon Schryver in 2009.  The
   initial implementation and first patch adding it to BIND were written
   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
   at redbarn.org and rhyolite.com starting in 2010.

   If all RPZ triggers and actions had been foreseen at the start in
   2009, they would probably have been encoded differently.  Instead RPZ
   grew incrementally, and upward compatibility required support of the
   original encodings.  The initial specification or Format 1 contained
   only QNAME triggers.  Changes for Format 2 included adding triggers
   based on response contents (RDATA), (Response IP Address), the targets of NS
   records (NSDNAME), and contents of A and AAAA records that resolve NS
   records (NSIP).  Format 3 included "rpz-passthru" for the PASSTHRU
   action and wildcards in Local Data CNAME targets to synthesize local data.
   responses dynamically based on the query domain.

   Today, with a number of commercial RPZ providers with many users and
   no functional problems with the encodings, any lack of aesthetic
   appeal is balanced by the ever increasing weight of the installed
   base.  For example, it is impossible to replace the original QNAME
   trigger encoding NXDOMAIN and NODATA policy action encodings with
   encodings that involve rpz-* pseudo-TLDs at RPZ providers without
   breaking the many existing RPZ subscriber installations.  The
   original, deprecated PASSTHRU encoding of a CNAME pointing to the
   trigger QNAME might still be in use in local, private policy zones,
   and so it is still recognized by RPZ subscriber implementations. implementations as of
   2016.

   The initial RPZ idea for RPZ was only to deny the existence of
   objectionable domain names, and so there were existed only QNAME triggers
   and NXDOMAIN actions.  Given that single kind of trigger, encoding it
   as the owner name of a policy record was clearly best.  A CNAME
   pointing to the root domain (.) is a legal and valid but not
   generally useful record, and so that became the encoding for the
   NXDOMAIN action.  The encoding of the NODATA action as "CNAME *."
   followed similar reasoning.  Requests for more kinds  The addition of more triggers and more
   actions required a more general scheme, and so they newer actions are
   encoded as CNAMES CNAMEs with targets in bogus TLDs owner whose names start with
   "rpz-".  Newer triggers are owner names containing DNS labels that
   start with "rpz_".

9. "rpz-".

   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
   this document.

10.

12.  Security Considerations

12.1.  DNS Data Security

   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 recursive DNS servers to
   falsified DNS data.
   RPZ data; it merely formalizes and facilitates modifying
   DNS data on its way from DNS authority servers to clients.  However, the  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 by
   RPZ. data.
   Therefore, by default, DNS resolvers using RPZ avoid modifying DNS
   results when DNSSEC signatures are available and are requested by the
   DNS client.  However, when the common "break-dnssec" configuration
   setting is used, RPZ-using resolvers rewrite responses. responses even in that
   case.  They omit DNSSEC RRsets, because the modified responses cannot
   be verified by DNSSEC signatures.  This renders the results invalid according results invalid
   according to DNSSEC.  In such a case, a querying client which checks
   DNSSEC reacts as though it has been subjected to a data poisoning
   attack and rejects the data.  That reaction could entail expensive
   bypass operations.

12.3.  TSIG

   The policy zones might be considered sensitive, because they contain
   information about miscreants.  Like other DNS zones in most
   situations, RPZs are transferred from publishers to subscribers as
   cleartext vulnerable to observation.  DNS zones are vulnerable to
   forgery or modification if TSIG transaction signatures [RFC2845] are
   not used, and so TSIG SHOULD be used to authenticate RPZ contents and
   protect them from modification.

12.4.  Counterintelligence

   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
   DNSSEC.  In such be
   resolvable: the authoritative servers for a case, zone cannot be found
   without a querying client which checks DNSSEC will
   ignore the invalid result, delegation and will effectively be blocked from (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; this behaviour domains is functionally similar to that
   caused by often fanciful or
   even unavailable.  For example, an RPZ NXDOMAIN policy action.

   The policy zones might be considered sensitive, authoritative NS RRset consisting
   of "NS ." is popular, because they contain
   information about miscreants.  Like other DNS zones while it is wrong, it betrays nothing
   in most
   situations, RPZs are transferred from sources to subscribers as
   cleartext vulnerable to observation.  However, TSIG transaction
   signatures [RFC2845] SHOULD be used to authenticate particular about the miscreant who owns the domain.

   Thus delegations and protect RPZ
   contents from modification.

   Recursive servers using RPZ glue are often configured to complete
   recursion even generally best for detecting and
   rewriting miscreant DNS data, 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 resource constraints prohibit
   checking both above-delegation and whether their RRs are listed.  "qname-wait-recurse" is
   a common configuration switch that controls this behavior.  See
   Section 5.

11. below-delegation NS and glue.

13.  Acknowledgements

   The authors gratefully acknowledge the substantial contributed
   material and editorial scrutiny of Anne Bennett.  She directed the
   reorganization and clarification of the entire document.

   Eric Ziegast, Jeroen Massar, and Ben April April, Ray Bellis and Mukund
   Sivaraman provided improvements to the document and caught errors.

12.

14.  References

12.1.

14.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              DOI 10.17487/RFC1995, August 1996,
              <http://www.rfc-editor.org/info/rfc1995>.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <http://www.rfc-editor.org/info/rfc1996>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <http://www.rfc-editor.org/info/rfc2136>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
              <http://www.rfc-editor.org/info/rfc2845>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <http://www.rfc-editor.org/info/rfc4034>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <http://www.rfc-editor.org/info/rfc5936>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <http://www.rfc-editor.org/info/rfc5952>.

12.2.

14.2.  Informative References

   [ISC-ARM]  Internet Systems Consortium, "BIND 9 Administrator
              Reference Manual,
              https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/
              Bv9ARM.ch06.html#rpz", 2016.

   [ISC-RPZ]  Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS
              RPZ, Format 3), https://ftp.isc.org/isc/dnsrpz/isc-tn-
              2010-1.txt", 2010.

   [ISC-RRL]  Vixie, P. and V. Schryver, "DNS Response Rate Limiting
              (DNS RRL), https://ftp.isc.org/isc/pubs/tn/isc-tn-
              2012-1.txt", 2012.

Appendix A.  Examples

   An existing data feed capable of producing an RHSBL can be trivially
   used to generate a DNS RPZ.  If the desired policy is to alias
   targeted domains to a local walled garden, then for each domain name,
   generate the following records, one for the name itself and perhaps
   also one for its subdomains:

       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
   subdomains in this example), try this:

       bad.example.com             CNAME   .
       *.bad.example.com           CNAME   .

   Try this if there are walled gardens for mail versus everything else:

       bad.example.com             MX      0 wgmail.example.net.
       bad.example.com             A       192.0.2.66
       *.bad.example.com           MX      0 wgmail.example.net.
       *.bad.example.com           A       192.0.2.66

   An extended example follows:

       $ORIGIN rpz.example.net.
       $TTL 1H
       @                   SOA LOCALHOST. named-mgr.example.net. (
       1 1h 15m 30d 2h) NS LOCALHOST.

       ; QNAME policy records.
       ; There are no periods (.) after the relative owner names.
       nxdomain.example.com        CNAME   .       ; NXDOMAIN policy
       nodata.example.com          CNAME   *.      ; NODATA policy

       ; redirect Redirect to walled garden
       bad.example.com             A       10.0.0.1
                                   AAAA    2001:db8::1

       ; do not rewrite OK.EXAMPLE.COM (PASSTHRU)
         ok.example.com        CNAME   rpz-passthru.
         bzone.example.com Rewrite all names inside "AZONE.EXAMPLE.COM"
       ; except "OK.AZONE.EXAMPLE.COM"
       *.azone.example.com         CNAME   garden.example.net.
       ok.azone.example.com        CNAME   rpz-passthru.

       ; Redirect "BZONE.EXAMPLE.COM" and "X.BZONE.EXAMPLE.COM"
       ; redirect X.BZONE.EXAMPLE.COM to "BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET" and
       ; X.BZONE.EXAMPLE.COM.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 Rewrite all answers for 192.0.2.0/24 containing addresses in 192.0.2.0/24,
       ; except 192.0.2.1
       24.0.2.0.192.rpz-ip         CNAME   .
       32.1.2.0.192.rpz-ip         CNAME   rpz-passthru.

       ; rewrite Rewrite to NXDOMAIN all responses; responses for domains for which
       ; NS.EXAMPLE.COM "NS.EXAMPLE.COM" is an authoritative DNS server or a server
         ; for a parent) that domain
       ; or any of its ancestors, or that have an authoritative server
       ; in 2001:db8::/32
       ns.example.com.rpz-nsdname  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

   Paul Vixie
   Farsight Security, Inc.

   Email: paul@redbarn.org

   Vernon Schryver
   Rhyolite Software Software, LLC

   Email: vjs@rhyolite.com