idnits 2.17.1 draft-vixie-dns-rpz-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2016) is 2687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations P. Vixie 3 Internet-Draft Farsight Security, Inc. 4 Intended status: Informational V. Schryver 5 Expires: June 19, 2017 Rhyolite Software, LLC 6 December 16, 2016 8 DNS Response Policy Zones (RPZ) 9 draft-vixie-dns-rpz-04 11 Abstract 13 This document describes a method for expressing DNS response policy 14 inside a specially constructed DNS zone, and for recursive name 15 servers to use such policy to return modified results to DNS clients. 16 The modified DNS results can stop access to selected HTTP servers, 17 redirect users to "walled gardens", block objectionable email, and 18 otherwise defend against attack. These "DNS Firewalls" are widely 19 used in fighting Internet crime and abuse. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 19, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may not be modified, and derivative works of it may not 54 be created, except to format it for publication as an RFC or to 55 translate it into languages other than English. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Discussion Venue . . . . . . . . . . . . . . . . . . . . 3 61 2. Zone Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Policy Actions . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. The "NXDOMAIN" Action (CNAME .) . . . . . . . . . . . . . 5 64 3.2. The "NODATA" Action (CNAME *.) . . . . . . . . . . . . . 5 65 3.3. The "PASSTHRU" Action (CNAME rpz-passthru.) . . . . . . . 5 66 3.4. The "DROP" Action (CNAME rpz-drop.) . . . . . . . . . . . 6 67 3.5. The "TCP-Only" Action (CNAME rpz-tcp-only.) . . . . . . . 6 68 3.6. The "Local Data" Action (arbitrary RR types) . . . . . . 6 69 4. Policy Triggers . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. The "Client IP Address" Trigger (.rpz-client-ip) . . . . 9 71 4.2. The "QNAME" Trigger ("example.com") . . . . . . . . . . . 10 72 4.3. The "Response IP Address" Trigger (.rpz-ip) . . . . . . . 10 73 4.4. The "NSDNAME" Trigger (.rpz-nsdname) . . . . . . . . . . 11 74 4.5. The "NSIP" Trigger (.rpz-nsip) . . . . . . . . . . . . . 12 75 5. Precedence Rules . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. "CNAME or DNAME Chain Position" Precedence Rule . . . . . 14 77 5.2. "RPZ Ordering" Precedence Rule . . . . . . . . . . . . . 14 78 5.3. "Domain Name Matching" Precedence Rule . . . . . . . . . 14 79 5.4. "Trigger Type" Precedence Rule . . . . . . . . . . . . . 15 80 5.5. "Name Order" Precedence Rule . . . . . . . . . . . . . . 15 81 5.6. "Prefix Length" Precedence Rule . . . . . . . . . . . . . 16 82 5.7. "IP Address Order" Precedence Rule . . . . . . . . . . . 16 83 6. Application of the Policy . . . . . . . . . . . . . . . . . . 17 84 6.1. Per-Zone Action Overrides . . . . . . . . . . . . . . . . 18 85 7. Producer Behavior . . . . . . . . . . . . . . . . . . . . . . 19 86 8. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 20 87 9. Implementation Considerations . . . . . . . . . . . . . . . . 20 88 9.1. Avoid Waiting for QNAME Recursion . . . . . . . . . . . . 21 89 9.2. Check Parents Domains versus Zone Cuts . . . . . . . . . 21 90 9.3. Abbreviate the Data Path for NSDNAME and NSIP Checks . . 22 91 9.4. Use Glue for NSDNAME and NSIP Checks . . . . . . . . . . 22 92 9.5. Reduce Zone Size using Implied Rules . . . . . . . . . . 23 93 10. History and Evolution . . . . . . . . . . . . . . . . . . . . 23 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 12.1. DNS Data Security . . . . . . . . . . . . . . . . . . . 25 97 12.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 12.3. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 12.4. Counterintelligence . . . . . . . . . . . . . . . . . . 25 100 12.5. NSIP, NSDNAME, Glue, and Authoritative RRsets . . . . . 26 101 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 104 14.2. Informative References . . . . . . . . . . . . . . . . . 27 105 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 108 1. Introduction 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This document describes DNS Firewalls, a method of expressing DNS 115 [RFC1034] response policy information inside specially constructed 116 DNS zones, known as Response Policy Zones (RPZs). RPZs allow 117 Internet security policy producers and subscribers to cooperate in 118 the application of policies to modify DNS responses in real time. 119 Using the policy information, DNS resolution for potentially unsafe 120 DNS data can be made to deliberately fail or to return local data 121 such as an alias to a "walled garden". 123 A site's DNS response policy consists of the set of rules expressed 124 in all of the RPZs that it uses. Each rule, expressed as an RRset, 125 consists of a trigger (left hand side or owner name) and an action 126 (right hand side). A full description of the expressible policies is 127 given in Section 3 (actions) and Section 4 (triggers). 129 Configuration examples are given using ISC BIND Version 9 (BIND9) 130 [ISC-ARM] syntax, because work to add RPZ to that platform was 131 started earliest (in 2009). The RPZ specification itself is free to 132 implement and free to use in operation. It has been implemented in 133 other name server software. We expect that in time, additional 134 recursive DNS implementations will also implement DNS Firewalls as 135 described by this RPZ specification. 137 1.1. Discussion Venue 139 The discussion venue for this document is the DNS Firewalls mailing 140 list. http://lists.redbarn.org/mailman/listinfo/dnsfirewalls offers 141 subscriptions and archives. See also https://dnsrpz.info/ 143 [NOTE TO EDITOR: This section must be removed before this Internet 144 Draft is published as an RFC.] 146 2. Zone Format 148 A DNS Response Policy Zone (RPZ) is a DNS zone. Like any DNS zone, 149 an RPZ consists of RRsets or sets of resource records (RRs) with a 150 common owner name and type. RRsets other than SOA, NS, and DNSSEC- 151 related [RFC4034] specify actions and triggers. The owner name (left 152 hand side) of each RRset expresses a policy trigger, while the RDATA 153 (right hand side) encodes the action to be taken when the trigger 154 matches. Depending on the type of trigger (see Section 4), a 155 particular characteristic of the DNS response is checked. 156 Characteristics that can be checked include the domain name (QNAME), 157 the IP address of the querying client, IP addresses or domain names 158 in the answer section of the response, and authoritative name server 159 names and addresses. 161 Because an RPZ is a valid DNS zone, its contents can be transferred 162 between DNS servers in whole (AXFR) [RFC5936] or incrementally as 163 changes occur (IXFR) [RFC1995], can be authenticated and protected by 164 TSIG transaction signatures [RFC2845], and can have update 165 propagation expedited by real time change notifications (NOTIFY) 166 [RFC1996], all subject to familiar DNS access controls. An RPZ need 167 not support query access since query access is never required. It is 168 the zone transfer of RPZ content from producers to subscribers which 169 effectively publishes the policy data. However, it is the 170 subscribers' configurations of their recursive name servers which 171 promote RPZ payload data into the control plane data of their 172 individual name servers. 174 Every valid DNS zone including an RPZ has an SOA record and at least 175 one NS record at its apex, which is why the SOA and NS records of an 176 RPZ cannot themselves be used to encode DNS response policy rules. 178 The RPZ's SOA record is real, with a serial number used for NOTIFY 179 and IXFR, and timers used for AXFR and IXFR. The MNAME field or 180 domain name of the primary source of the zone and the RNAME field or 181 mailbox of the person responsible for the zone SHOULD be used by RPZ 182 providers to label their policy zones. 184 The apex NS RRset will never be used since RPZ does not rely on query 185 access. Similarly, no parent delegation is required for normal 186 operation of the RPZ. Thus, by convention, a single NS record having 187 the deliberately bogus RDATA of "LOCALHOST." is used as a 188 placeholder. 190 While loading an RPZ, any data which is not syntactically valid for 191 DNS should cause normal error processing as would occur for any DNS 192 zone. If an RR found in an RPZ is meaningless or unusable for 193 response policy purposes, then the containing RRset SHOULD be 194 ignored, and an error MAY be logged. 196 The format of RPZs has undergone several revisions since work began 197 (see Section 10, History and Evolution). All policy triggers and 198 actions described here are valid as of Format 3. Policy triggers 199 from a higher format number than a recursive name server's 200 implementation level are expected to be harmless to that 201 implementation. Policy actions from a higher format number are 202 likely to be misinterpreted as CNAME Local Data by older 203 implementations. When possible, implementations SHOULD treat policy 204 triggers or actions of higher format numbers as they treat other 205 errors, as described above. 207 3. Policy Actions 209 An RPZ resource record can specify any of six results or actions. 211 3.1. The "NXDOMAIN" Action (CNAME .) 213 A single resource record (RR) consisting of a CNAME whose target is 214 the root domain (.) will cause a response of NXDOMAIN to be returned. 215 This is the most commonly used RPZ action. 217 $ORIGIN RPZ.EXAMPLE.ORG. 218 example.com CNAME . ; return NXDOMAIN 219 *.example.com CNAME . ; return NXDOMAIN 221 3.2. The "NODATA" Action (CNAME *.) 223 A single RR consisting of a CNAME whose target is the wildcard top- 224 level domain (*.) will cause a response of NODATA (ANCOUNT=0) to be 225 returned regardless of query type. 227 $ORIGIN RPZ.EXAMPLE.ORG. 228 example.com CNAME *. ; return NODATA 229 *.example.com CNAME *. ; return NODATA 231 3.3. The "PASSTHRU" Action (CNAME rpz-passthru.) 233 It is sometimes necessary to exempt some DNS responses from a policy 234 rule that covers an entire domain or a large IP address block. 235 Exempting some clients of a DNS resolver from all RPZ rewriting can 236 also be useful for research into attackers and for debugging. The 237 PASSTHRU action is intended to override other, usually more general 238 policies. The trigger for the PASSTHRU action MUST have a higher 239 precedence than the policies that it should override (see Section 5, 240 Precedence Rules). 242 In the example below, the first PASSTHRU record exempts requests for 243 a particular host from the NXDOMAIN policy action of the subsequent 244 records. The second PASSTHRU record exempts responses to the DNS 245 client at 192.0.2.1 from being modified: 247 $ORIGIN RPZ.EXAMPLE.ORG. 248 ok.example.com CNAME rpz-passthru. 249 32.1.2.0.192.rpz-client-ip CNAME rpz-passthru. 250 example.com CNAME . 251 *.example.com CNAME . 253 3.4. The "DROP" Action (CNAME rpz-drop.) 255 The DROP policy that results in discarding the request and response 256 is specified by a CNAME whose target is "rpz-drop". For example, the 257 following rule mandates that nothing be sent to a DNS client trying 258 to resolve "EXAMPLE.COM", not even a DNS error response: 260 $ORIGIN RPZ.EXAMPLE.ORG. 261 example.com CNAME rpz-drop. 263 3.5. The "TCP-Only" Action (CNAME rpz-tcp-only.) 265 The TCP-Only action is specified by a CNAME whose target is 266 "rpz-tcp-only". It changes UDP responses to short, truncated DNS 267 responses that require the DNS client to try again with TCP. It is 268 used to mitigate distributed DNS reflection attacks and is similar to 269 the "slip" parameter of DNS Response Rate Limiting (RRL) [ISC-RRL]. 271 $ORIGIN RPZ.EXAMPLE.ORG. 272 example.com CNAME rpz-tcp-only. 274 3.6. The "Local Data" Action (arbitrary RR types) 276 A set of RRsets with a common trigger owner name (see Section 4) that 277 includes neither a special CNAME RPZ encoding of an action nor one of 278 the problematic record types listed below specifies data to be used 279 to generate synthetic DNS responses. The most common Local Data is a 280 CNAME RR pointing to a walled garden, although other record types are 281 also used. 283 $ORIGIN RPZ.EXAMPLE.ORG. 284 bad1.example.com CNAME garden.example.net. 285 bad2.example.com A garden-web.example.net. 286 bad2.example.com MX garden-mail.example.net. 287 32.3.2.0.192.rpz-client-ip A quarantine.example.net. 289 Note that because an RPZ is a valid DNS zone, if the action of a 290 policy rule contains a CNAME RR, then no other RRs are allowed for 291 that owner name (trigger). 293 The special RPZ encodings which are not to be taken as Local Data are 294 CNAMEs with targets that are: 296 + "." (NXDOMAIN action), 297 + "*." (NODATA action), 298 + a top level domain starting with "rpz-", 299 + a child of a top level domain starting with "rpz-". 301 The problematic types and records which also do not encode Local Data 302 actions include: 304 + SOA records, 305 + NS records, 306 + DNAME records, 307 + all DNSSEC-related records (see [RFC4034]). 309 RRsets of problematic record types MUST NOT be included in RPZ data, 310 because their appearance in responses would be invalid or confuse DNS 311 clients. 313 When a Local Data policy rule matches, the RRsets of Local Data are 314 used to generate the response as if they comprised all of the 315 authoritative data for the QNAME. If the requested type (QTYPE) is 316 ANY, then all of these Local Data RRsets are returned. Otherwise, 317 the RRset of the requested RR type is returned, or a CNAME is 318 returned if it is available. If no CNAME nor RRset of the requested 319 type is available, then the response is normally NODATA (ANCOUNT=0). 320 Using the example above, if client 192.0.2.3 asks for MX records, it 321 will receive NODATA, because the policy rule with the matching Client 322 IP Address trigger contains RRsets of RRtype A but none of RRtype MX. 324 This normal NODATA response when there are no Local Data records of 325 the requested type can be changed with the LOCAL-DATA-OR-PASSTHRU or 326 LOCAL-DATA-OR-DISABLED overrides described in Section 6.1. 328 A special form of Local Data involves a CNAME RR with a wildcarded 329 target name. Wildcards are not valid as CNAME targets in ordinary 330 DNS zones. However, a wildcard in an RPZ Local Data CNAME target 331 causes the matching QNAME to be prepended to the target in the 332 rewritten response, which communicates this QNAME value to the walled 333 garden DNS server for that DNS server's logs. 335 For example a policy Local Data action of "CNAME *.EXAMPLE.COM" 336 applied to a QNAME of "EVIL.EXAMPLE.ORG." will result in a synthetic 337 response that starts with the RR 338 "EVIL.EXAMPLE.ORG CNAME EVIL.EXAMPLE.ORG.EXAMPLE.COM". Resolving the 339 CNAME target "EVIL.EXAMPLE.ORG.EXAMPLE.COM" into an RRset of the 340 originally requested type generally requires sending a request for 341 that type and a QNAME of "EVIL.EXAMPLE.ORG.EXAMPLE.COM" to a DNS 342 server for the walled garden, "EXAMPLE.COM". As usual when a CNAME 343 is encountered while computing a response, the response from the 344 walled garden DNS server concerning "EVIL.EXAMPLE.ORG.EXAMPLE.COM" 345 determines the rest of the final rewritten response. 347 In the example below, a client that asks for A RRs for 348 "BAD.EXAMPLE.COM" will receive a response starting with 349 "BAD.EXAMPLE.COM CNAME BAD.EXAMPLE.COM.GARDEN.EXAMPLE.NET". The DNS 350 server using RPZ will then probably try to resolve 351 "BAD.EXAMPLE.COM.GARDEN.EXAMPLE.NET" by requesting A RRs from the 352 authority for "GARDEN.EXAMPLE.NET". That authority should answer 353 with NODATA, NXDOMAIN, or an A RRset, but in any case can log the 354 request to show that a request for "BAD.EXAMPLE.COM" has been 355 received. 357 $ORIGIN RPZ.EXAMPLE.ORG. 358 bad.example.com CNAME *.garden.example.net. 360 4. Policy Triggers 362 There are five types of RPZ triggers, and they are encoded by RRset 363 owner names (left hand sides) in an RPZ. 365 Two of these trigger types match characteristics of the DNS query: 366 Client IP Address and QNAME. While these two trigger typess are 367 independent of cache contents or recursion results, still 368 conceptually they must be checked only once the response is ready, 369 because they compete for precedence (see Section 5) with other 370 trigger types which depend on what happens during recursion. 372 The other three trigger types are based on characteristics of the DNS 373 response, that is, on the RDATA to be returned to the client, or in 374 some cases, on NS-related RDATA used while recursively obtaining the 375 final response, regardless of whether or not those NS or NS-related 376 records are themselves to be returned to the client. These three 377 trigger types are: Response IP Address, NSDNAME, and NSIP. 379 Neither the TTL fields of RRs in the answer section nor the query 380 type (QTYPE) in the question section of responses are used as RPZ 381 triggers, although the QTYPE is used to select appropriate RRsets 382 among the RRsets of matching Local Data rules (Section 3.6). 384 All policies are conceptually applied after recursion, even though in 385 practice recursion can sometimes be skipped, if doing so would not 386 change the RPZ result (see Section 5, Precedence Rules and Section 9, 387 Implementation Considerations). As a result, the recursive DNS 388 resolver's cache contains either nothing or "truth", even if this 389 truth is hidden by current policy. If the policy changes, the 390 original, unmodified data is available for processing under the 391 changed policy. 393 4.1. The "Client IP Address" Trigger (.rpz-client-ip) 395 The IP addresses of DNS clients sending requests can be used as 396 triggers, which can be useful for disabling RPZ rewriting for DNS 397 clients used for testing or investigating, or for quarantining 398 compromised clients. Client IP Address policy RRsets have owner 399 names that are subdomains of "rpz-client-ip" relativized to the RPZ 400 apex name, preceded by an encoded IP address or block of addresses. 402 For example, the following would drop all requests from clients in 403 192.0.2.0/24 and give truthful answers to requests from a client at 404 2001:db8::3. 406 $ORIGIN RPZ.EXAMPLE.ORG. 407 24.0.2.0.192.rpz-client-ip CNAME rpz-drop. 408 128.3.zz.db8.2001.rpz-client-ip CNAME rpz-passthru. 410 4.1.1. IP address encoding in triggers 412 The IPv4 address or address block "B1.B2.B3.B4/prefix" is encoded in 413 an RPZ trigger as "prefix.B4.B3.B2.B1", with the address octets 414 reversed just as in the IN-ADDR.ARPA naming convention described in 415 [RFC1034]. The prefix length ("prefix") is a decimal integer from 1 416 to 32. All four octets, B4, B3, B2, and B1, must be present and are 417 also decimal integers. To avoid confusion with octal notation, 418 leading zeros MUST be suppressed. 420 For example, the address block 192.0.2.0/24 is encoded as 421 "24.0.2.0.192". 423 The IPv6 address or address block beginning at 424 "W1:W2:W3:W4:W5:W6:W7:W8" is encoded in a format similar to the 425 standard IPv6 text representation (see [RFC5952]), again reversed: 426 "prefix.W8.W7.W6.W5.W4.W3.W2.W1". The prefix length ("prefix") is a 427 decimal integer from 1 to 128. Each of W8,...,W1 is a one- to four- 428 digit hexadecimal number representing 16 bits of the IPv6 address. 429 As in [RFC5952], in order to avoid confusion with octal notation, 430 leading zeroes MUST be suppressed. 432 All 8 hextets must be present unless a "zz" label is present. The 433 "zz" label is analogous to the double-colon (::) in [RFC5952], and it 434 is required and allowed just as the double-colon is required and 435 allowed in that document. In particular, the longest possible 436 sequence of zero-valued fields MUST be compressed to "zz". If there 437 exists more than one sequence of zero-valued fields of identical 438 length, then only the last such sequence is compressed. Note that 439 [RFC5952] specifies compressing the first such sequence, but our 440 notation here reverses the order of fields, and so must also reverse 441 the selection of which zero sequence to compress. 443 For example, the address 2001:db8::3 with a prefix length of 128 444 would be encoded as "128.3.zz.db8.2001". 446 In the case of an address block, either IPv4 or IPv6, the address 447 part MUST NOT contain any non-zero bits after the section indicated 448 by the prefix length. For example, "8.2.0.0.10.rpz-client-ip" is not 449 a valid trigger, because in the address "10.0.0.2" expressed in 450 binary notation, a one occurs outside the first 8 bits or prefix of 451 the address block. 453 4.2. The "QNAME" Trigger ("example.com") 455 The QNAME policy trigger matches requested domains, that is, the 456 QNAME field of the question sections in DNS requests and responses. 457 (See [RFC1035].) The owner name of an RPZ QNAME policy RRset is the 458 relativized name of the domain name about which policy is being 459 expressed. For example, if the RPZ apex name is "RPZ.EXAMPLE.ORG", 460 an RRset at "EXAMPLE.COM.RPZ.EXAMPLE.ORG" would affect responses to 461 requests about "EXAMPLE.COM". 463 Wildcards work as expected, so the owner name 464 "*.EXAMPLE.COM.RPZ.EXAMPLE.ORG" would match queries for any subdomain 465 of "EXAMPLE.COM". To control the policy for both a name and its 466 subdomains, two policy RRsets must be used, one for the domain itself 467 and another for a wildcard subdomain. In the following example, 468 queries for both "EXAMPLE.COM" and all subdomains of "EXAMPLE.COM" 469 will result in synthetic NXDOMAIN responses. 471 $ORIGIN RPZ.EXAMPLE.ORG. 472 example.com CNAME . 473 *.example.com CNAME . 475 4.3. The "Response IP Address" Trigger (.rpz-ip) 477 The Response IP Address trigger matches IP addresses that would 478 appear in the unaltered DNS response contents, specifically the RDATA 479 of A or AAAA records in the answer sections of DNS responses. IP 480 addresses in the authority and additional sections are not 481 considered. Response IP Address policy RRsets have owner names that 482 are subdomains of "rpz-ip" relativized to the RPZ apex name, and an 483 encoded IP address or block of addresses. The IP address encodings 484 are identical to those described in Section 4.1.1 for Client IP 485 Address triggers. 487 For example, to force an NXDOMAIN response whenever a truthful 488 response would contain an answer section A RRset having an address in 489 192.0.2.0/24 unless address 192.0.2.2 is present, the RPZ would 490 contain these records: 492 $ORIGIN RPZ.EXAMPLE.ORG. 493 24.0.2.0.192.rpz-ip CNAME . 494 32.2.2.0.192.rpz-ip CNAME rpz-passthru. 496 In another example, to answer NODATA (ANCOUNT=0) whenever a truthful 497 response would contain an answer AAAA RRset having an address 498 2001:db8:101::/48 unless address 2001:db8:101::3 was present, the RPZ 499 would contain these records: 501 $ORIGIN RPZ.EXAMPLE.ORG. 502 48.zz.101.db8.2001.rpz-ip CNAME *. 503 128.3.zz.101:db8.2001.rpz-ip CNAME rpz-passthru. 505 Please refer to Section 5 (Precedence Rules) to understand how the 506 above exception mechanisms work. 508 4.4. The "NSDNAME" Trigger (.rpz-nsdname) 510 The NSDNAME policy trigger matches name server names (NS RR) of all 511 name servers in the data paths for all RRsets that would be present 512 in the answer section of the unaltered DNS response. 514 The data path for a given answer RRset consists of all delegation 515 points from (and including) the root zone down to the closest 516 enclosing NS RRset for the owner name of that RRset. Names in the 517 RDATA of answer RRs including CNAME, DNAME, SRV, and MX are not 518 themselves directly relevant, but CNAME and DNAME target names are 519 indirectly relevant if they cause RRsets to be added to the answer 520 section, in which case it is the data paths of the added RRsets that 521 matter. In the case of a DNAME answer, the owner name of an added 522 synthetic CNAME is likely to differ from the target name in the DNAME 523 RR. Recall also that the target of a CNAME is not added to the 524 response if the QTYPE is ANY or CNAME or if this target cannot be 525 resolved (e.g. NXDOMAIN or SERVFAIL errors). 527 NSDNAME policies are encoded as RRsets in subdomains of "rpz-nsdname" 528 but otherwise are much like QNAME policies (Section 4.2). For 529 example, to force an NXDOMAIN answer whenever a name server for the 530 requested domain or one of its parents is "NS.EXAMPLE.COM", the RPZ 531 would contain the following: 533 $ORIGIN RPZ.EXAMPLE.ORG. 534 ns.example.com.rpz-nsdname CNAME . 536 The NS records used for this calculation are either delegations (NS 537 RRs in the authority sections of answers from authorities for the 538 parent zone) or authoritative data from the zone itself. An 539 implementation MAY use either, both, or whichever is currently 540 available. See Section 9.4 about some implementation considerations 541 for this choice, and Section 12.5 about security considerations. 543 An RPZ implementation MAY be configurable to avoid checking all the 544 way up to the root and to perform only partial NSDNAME checks; see 545 Section 9.3 on "min-ns-dots". 547 4.5. The "NSIP" Trigger (.rpz-nsip) 549 The NSIP policy trigger matches name server addresses, that is A or 550 AAAA RRs referenced by an NS RRset. NSIP is like NSDNAME 551 (Section 4.4) except that the matching is by name server address 552 rather than name server name. NSIP policies are expressed as 553 subdomains of "rpz-nsip" and have the same subdomain naming 554 convention as that described for encoding IP addresses in Response IP 555 Address triggers (Section 4.1.1). 557 In a process similar to that for an NSDNAME trigger, an NSIP trigger 558 is checked by considering all of the IP addresses for all of the name 559 servers in the data paths for all RRsets that would be present in the 560 answer section of the unaltered DNS response. 562 As with NSDNAME triggers, the data path for a given RRset consists of 563 all delegation points from (and including) the root zone down to the 564 closest enclosing NS RRset for the owner name of that RRset. Also 565 like NSDNAME triggers, the RDATA in these RRsets (other than the IP 566 addresses of the name servers) are not directly relevant. 568 For example, to force an NXDOMAIN answer whenever one of the name 569 servers for the requested domain (QNAME) or one of its ancestors has 570 an address in the 192.0.2.0/24 block, the RPZ would contain the 571 following: 573 $ORIGIN RPZ.EXAMPLE.ORG. 574 24.0.2.0.192.rpz-nsip CNAME . 576 The NS, A, and AAAA records used for this calculation are either 577 delegations and glue (RRs in authority and additional sections of 578 answers from authorities for the parent zone) or authoritative data 579 from the zone itself. As with NSIP, an implementation MAY use 580 either, both, or whichever is currently available; see Section 9.4 on 581 "ns-wait-recurse". 583 An RPZ implementation MAY also be configurable to avoid checking all 584 the way up to the root and to perform only partial NSIP checks; see 585 Section 9.3 on "min-ns-dots". 587 5. Precedence Rules 589 More than one policy trigger among the various DNS RPZs connected to 590 the name server's control plane can match while computing a given DNS 591 response, but only a single policy rule can rewrite the response. 592 The policy rule with the best match will be selected according to the 593 precedence rules outlined below. 595 These precedence rules exist and are ordered to ensure that RPZ 596 subscribers and publishers have the same understanding of what a set 597 of policy zones will do, and to ensure that subscribers can use local 598 zones to override published policy zones. 600 In theory and for standardization, all matching policy rules are 601 considered simultaneously, and the precedence rules are used to 602 choose the single best RPZ rule. In actual implementations, policy 603 triggers are usually considered in a sequence that mirrors the 604 process of generating the DNS response, because checking RPZ triggers 605 is conveniently made a part of that process. For example, Client IP 606 Address triggers are often checked early as the DNS request is being 607 received and as the client IP address is being checked in the access 608 control list (ACL) that determines which DNS client IP addresses can 609 ask for recursion. Likewise the QNAME is available for RPZ trigger 610 matching before any response IP addresses are known, so QNAME 611 triggers are usually checked immediately after Client IP Address 612 triggers and before Response IP Address triggers. NSIP and NSDNAME 613 triggers are generally checked last. 615 As far as the DNS client can determine, it MUST seem that all 616 matching triggers are found and weighed using these precedence rules, 617 even though in practice, shortcuts are taken. Shortcuts MUST NOT 618 affect the outcome. For example, according to the precedence rules, 619 a matched QNAME trigger in the first policy zone makes all Response 620 IP Address, NSIP, and NSDNAME triggers moot. There is no need to 621 look for those matches, because they cannot further affect the 622 response. 624 The actions specified in policy rules are not used in the calculation 625 of precedence. The actions of policy rules determined by per-zone 626 action overrides (Section 6.1), other than those that disable them, 627 likewise do not affect the calculation of precedence. Override 628 actions which disable policy rules affect this calculation only by 629 removing those rules from consideration. 631 Precedence rules are applied in the order listed here; the comparison 632 between two matching policy rules to choose the better match is 633 determined by the first dispositive precedence rule in this list. 634 Note however that if the best match selects a disabled rule (caused 635 by the DISABLED override described in Section 6.1), then the next 636 best match is used, and so on until a policy rule that is not 637 disabled is selected or no matches remain. 639 5.1. "CNAME or DNAME Chain Position" Precedence Rule 641 This precedence rule applies only when the original query type is not 642 ANY, CNAME, nor DNAME, and only when a CNAME or DNAME is encountered 643 while resolving the original QNAME, in what we will call the first 644 "stage of resolution". In this case, we know that the recursive name 645 server ([RFC1035]) may follow the CNAME (or the synthetic CNAME 646 constructed while applying a DNAME) by starting a second stage of 647 resolution starting at this CNAME's target. Additional stages of 648 resolution may ensue if further CNAMEs or DNAMEs are encountered, 649 until the final response is computed. 651 A policy rule match which occurs at an earlier stage of resolution is 652 preferred to a policy rule match which occurs at a later stage. 654 Recall that only one policy rule, from among all those matched at all 655 stages of resolving a CNAME or DNAME chain, can affect the final 656 response; this is true even if the selected rule has a PASSTHRU 657 action. 659 5.2. "RPZ Ordering" Precedence Rule 661 This precedence rule applies when the matches being compared refer to 662 policy rules in different RPZs. 664 Matches on rules in an RPZ specified earlier in the ordered list of 665 RPZs take precedence over matches on rules in an RPZ specified later. 667 5.3. "Domain Name Matching" Precedence Rule 669 This precedence rules applies to a set of QNAME rules or a set of 670 NSDNAME rules in a single RPZ. The rule triggers are compared. 672 This rule is the same as that used by DNS servers to choose the RRs 673 with which to respond to a request. In particular, an exact name 674 match is better than one involving a wildcard, and among wildcard 675 matches, the trigger (owner domain name) that has the largest number 676 of labels is best. 678 Since a DNS response has only one QNAME in a given stage of CNAME or 679 DNAME chain resolution (as defined in Section 5.1, 680 "CNAME or DNAME Chain Position" Precedence Rule), this precedence 681 rule is sufficient to choose a single QNAME trigger over other QNAME 682 triggers in the same RPZ. However, computing a single DNS response 683 can match dozens of NSDNAME triggers in a single RPZ, of which 684 several may be equal according to this precedence rule. In that 685 case, the "Name Order" Precedence Rule (Section 5.5) selects the 686 single winner from among those chosen by this rule. 688 5.4. "Trigger Type" Precedence Rule 690 This precedence rule applies to policy rules within the same RPZ, but 691 with different trigger types. 693 In this case, matches are ranked according to trigger type in the 694 following order, from highest to lowest precedence: 696 + Client IP Address 697 + QNAME 698 + Response IP Address 699 + NSDNAME 700 + NSIP 702 5.5. "Name Order" Precedence Rule 704 This precedence rule applies to a set of NSDNAME matches whose 705 precedence has not been established by previous precedence rules. 706 Here, the matched name server domain names are compared, not the 707 owner names (triggers) of the policy rules. Therefore, it is 708 irrelevant whether the matched trigger was a wildcard or a specific 709 domain name. 711 Among the matching NSDNAME policy rules, choose the one whose matched 712 name server domain name appears last in the DNSSEC canonical DNS name 713 order described in section 6.1 of [RFC4034]. 715 Important note: if this precedence rule is reached, the matches being 716 compared originate from different NS names, not from the same name 717 matching multiple rules, as those conflicts would have been dispensed 718 with by the "Domain Name Matching" Precedence Rule (Section 5.3). 719 There is no a priori reason to prefer one NS name over another, so 720 while this tie-breaker precedence rule is dispositive, it is also 721 arbitrary. All RPZ implementations MUST make the same choices in 722 these cases to ensure consistent, predictable results among 723 installations. 725 Taking part of the example directly from section 6.1 of [RFC4034], 726 and reversing the order to take into account that the name that 727 appears last in the DNSSEC canonical order is to be taken as the best 728 match here, the following NS names are given below in order from 729 highest or best to lowest precedence: 731 + z.example 732 + zABC.a.EXAMPLE 733 + Z.a.example 734 + yljkjljk.a.example 735 + a.example 736 + example 738 5.6. "Prefix Length" Precedence Rule 740 This precedence rule applies when more than one Response IP Address 741 policy rule or more than one NSIP policy rule matches while computing 742 a response. The rule triggers themselves are compared. 744 When comparing two Response IP Address matches or two NSIP matches on 745 rules within a single RPZ, choose the match whose rule trigger has 746 the longest "internal prefix length". The internal prefix length of 747 an IPv6 address trigger is the numeric value of the first label that 748 defines it as described in Section 4.1.1 on 749 IP address encoding in triggers. For an IPv4 address trigger, the 750 internal prefix length is the numeric value of its first label plus 751 96 (that is, 128-32). This adjustment allows IPv4 and IPv6 addresses 752 to use the same internal representation, with 32-bit IPv4 addresses 753 expanded to 128 bits by zero filling as described in section 2.5.5.1 754 of [RFC4291]. 756 5.7. "IP Address Order" Precedence Rule 758 This precedence rule applies when more than one Response IP Address 759 policy rule or more than one NSIP policy rule matches while computing 760 a response, and they have the same internal prefix length. The rule 761 triggers are compared. 763 When comparing Response IP Address or NSIP triggers with equal 764 internal prefix lengths, choose the trigger which encodes the smaller 765 IP address. The IP addresses from the triggers are compared as 128 766 bit numbers, with IPv4 addresses expanded to 128 bits by zero filling 767 as described in section 2.5.5.1 of [RFC4291]. 769 Important note: if this precedence rule is reached, the matches being 770 compared originate from different IP addresses, not from the same 771 address matching multiple rules, as those conflicts would have been 772 dispensed with by the "Prefix Length" Precedence Rule (Section 5.6). 773 There is no a priori reason to prefer one IP address over another, so 774 while this tie-breaker precedence rule is dispositive, it is also 775 arbitrary. All RPZ implementations MUST make the same choices in 776 these cases to ensure consistent, predictable results among 777 installations. 779 In the following example, the internal prefix length of all three IP 780 addresses is 121 as described in Section 5.6. 782 25.0.2.0.192.rpz-ip CNAME most.example.com. 783 25.128.2.0.192.rpz-ip CNAME middle.example.com. 784 121.280.c000.zz.db8.2001.rpz-ip CNAME least.example.com. 786 The three addresses above are compared as these 128-bit hexadecimal 787 numbers, respectively: 789 0x000000000000000000000000c0000200, 790 0x000000000000000000000000c0000280, and 791 0x20010db80000000000000000c0000280. 793 Thus, the first IPv4 address is most preferred and the IPv6 address 794 is least preferred. 796 6. Application of the Policy 798 To enable the use of RPZs, the recursive name server's control plane 799 is connected to the DNS RPZ data plane by supplying an ordered list 800 of RPZs in the name server's configuration. 802 By default, policies are applied only on DNS requests that ask for 803 recursion (RD=1). Recursive DNS servers generally send their 804 requests to authority servers without asking for recursion (RD=0), 805 while stub resolvers ask for recursion (RD=1). Thus, the use of RPZ 806 at a recursive server by default affects requests from stub resolvers 807 only. An implementation SHOULD include a configuration option such 808 as "recursive-only no" to relax this restriction. 810 Also by default, RPZ policies are applied only while responding to 811 DNS requests that do not request DNSSEC metadata (DO=0) or for which 812 no DNSSEC metadata exists. An implementation MAY include a 813 configuration option such as "break-dnssec yes" to relax this 814 restriction. See Section 12.2 about the implications of responding 815 with modified DNS responses when the DNS client seems to be expecting 816 DNSSEC signatures. 818 RPZ rules do not apply to synthetic data generated by using RPZ 819 rules. For example, if RPZ supplies a CNAME pointing to a walled 820 garden, RPZ policies will not be used while following that CNAME. If 821 RPZ supplies local data giving a particular A record, RPZ policies 822 will not apply to that response IP address. 824 If an illegal record is encountered while computing a response, for 825 example an NS record with a CNAME target, and this illegal record is 826 ignored by the resolver, then it is likewise not used for RPZ rule 827 matches. 829 If a policy rule matches and results in a modified answer, then that 830 modified answer will include in its additional section the SOA RR of 831 the policy zone whose rule was used to generate the modified answer. 832 This SOA RR includes the name of the DNS RPZ and the serial number of 833 the policy data which was connected to the DNS control plane when the 834 answer was modified. 836 6.1. Per-Zone Action Overrides 838 For each DNS RPZ configured for use by a recursive name server, it 839 SHOULD be possible to specify a single, OPTIONAL overriding policy 840 action to be used for all policy triggers found in that RPZ. These 841 policy action overrides include the following: 843 NXDOMAIN 844 SHOULD be implemented and is the same as the NXDOMAIN action 845 defined in Section 3.1. 847 NODATA 848 SHOULD be implemented and is the same as the NODATA action defined 849 in Section 3.2. 851 PASSTHRU 852 SHOULD be implemented and is the same as the PASSTHRU action 853 defined in Section 3.3. 855 LOCAL-DATA-OR-PASSTHRU 856 MAY be implemented. It modifies the Local Data action 857 (Section 3.6) so that requests for RR types that would otherwise 858 give a Local Data result of NODATA (ANCOUNT=0) are instead handled 859 using the PASSTHRU action (Section 3.3). Note that computing a 860 DNS response for QTYPE ANY can never cause a Local Data NODATA 861 result. The LOCAL-DATA-OR-PASSTHRU override applies only to Local 862 Data rules and has no effect on rules with other actions. 864 DROP 865 SHOULD be implemented and is the same as the DROP action defined 866 in Section 3.4. 868 TCP-ONLY 869 SHOULD be implemented and is the same as the TCP-ONLY action 870 defined in Section 3.5. 872 CNAME domain 873 SHOULD be implemented and is a special case of the Local Data 874 action defined in Section 3.6. The overriding data is a CNAME RR 875 with the given domain as its target. 877 GIVEN 878 MAY be implemented to explicitly affirm the default, which is to 879 respect all policy actions found in this DNS RPZ. 881 DISABLED 882 SHOULD be implemented and causes any rule of the zone, when 883 selected as a "best match", to have no effect, except to log what 884 would otherwise have happened, provided sufficient logging is 885 enabled. The DISABLED override thus causes the next highest 886 precedence match (if any) to be used (see Section 5, 887 Precedence Rules). This is useful for debugging or previewing a 888 policy zone. 890 LOCAL-DATA-OR-DISABLED 891 MAY be implemented. It modifies the Local Data action 892 (Section 3.6) so that requests for RR types that would otherwise 893 give a Local Data result of NODATA (ANCOUNT=0) are instead handled 894 similarly to the DISABLED override, but without logging. In this 895 case, the next highest precedence match (if any) is used. Note 896 that computing a DNS response for QTYPE ANY can never cause a 897 Local Data NODATA result. The LOCAL-DATA-OR-DISABLED override 898 applies only to Local Data rules and has no effect on rules with 899 other actions. 901 7. Producer Behavior 903 A DNS RPZ producer SHOULD make every effort to ensure that 904 incremental zone transfers (IXFR [RFC1995]) rather than full zone 905 transfers (AXFR [RFC5936]) are used to move new policy data toward 906 subscribers. DNS RPZ subscribers are "stealth slaves" as described 907 in RFC 1996. The master MUST allow each such slave to perform the 908 needed zone transfers, for example via its access control lists 909 (ACLs). The master also SHOULD be configured as necessary to send 910 NOTIFY messages to each slave. Because minimal data latency is 911 critical both to the prevention of crime and abuse and to the 912 withdrawal of erroneous or outdated policy, a DNS RPZ producer SHOULD 913 also make every effort to minimize data latency, including ensuring 914 that NOTIFY messages are sent in a timely manner after each change of 915 the DNS RPZ on the master server. 917 In a response policy zone domain, each addition, deletion, or 918 expiration could be handled using DNS UPDATE [RFC2136] to trigger 919 normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the 920 subscribing servers well synchronized to the master RPZ. 921 Alternatively, on some primary name servers (such as ISC BIND9) it is 922 possible to generate an entirely new primary RPZ file and have the 923 server compute the differences between each new version and its 924 predecessor. In ISC BIND9 this option is called 925 "ixfr-from-differences" and is known to be performant even for 926 million-rule DNS RPZ's with significant churn on a minute by minute 927 basis. 929 It is good operational practice to include test records in each DNS 930 RPZ to help that DNS RPZ's subscribers verify that response policy 931 rewriting is working. For example, a DNS RPZ might include a QNAME 932 policy rule for "BAD.EXAMPLE.COM" as well as a Response IP Address 933 policy rule for 192.0.2.1. A subscriber can verify the correctness 934 of their installation by querying for "BAD.EXAMPLE.COM", which does 935 not exist in real DNS. If an answer is received it will be from the 936 DNS RPZ. That answer's additional data section will usually contain 937 an SOA RR denoting the fully qualified name of the DNS RPZ itself. 939 8. Subscriber Behavior 941 RPZs MUST be primary or secondary zones at subscriber recursive 942 resolvers. They can be searched using only a recursive server's own 943 storage, because additional network transactions for DNS resolvers 944 would be unworkable for this purpose. 946 Response policy zones are loaded in the usual way. For primary zones 947 this may mean loading the contents of a local file into memory or 948 connecting to a database. For secondary zones this means 949 transferring the zone from the primary server using zone transfer 950 such as IXFR [RFC1995] or AXFR [RFC5936]. All secondary zone 951 transfer relationships SHOULD be protected with transaction 952 signatures (DNS TSIG) and real time change notification SHOULD be 953 enabled using the DNS NOTIFY protocol [RFC1996]. 955 9. Implementation Considerations 957 DNS resolvers often have limited notion or no notion of a DNS zone or 958 zone file. They sometimes have special local zones, but generally 959 have no implementations of IXFR, AXFR, or NOTIFY. Therefore, an 960 external module or service that maintains local copies of policy 961 zones can be useful. 963 RPZ checks can add significant processing and network costs to the 964 processing of recursive DNS requests. This is particularly true of 965 rules with NSDNAME and NSIP triggers. However, NSDNAME and NSIP 966 triggers can be more effective than QNAME and IP triggers, because 967 miscreants can more easily change their direct domain names and IP 968 addresses (which are detected by QNAME and IP triggers) than they can 969 change their NS names and addresses. 971 To minimize the costs associated with RPZ processing, implementations 972 MAY use various optimizations, some of which are described below. 974 9.1. Avoid Waiting for QNAME Recursion 976 When data already in the resolver's cache combined with the 977 precedence rules in Section 5 are sufficient to produce a final RPZ 978 result, an implementation MAY choose not to finish computing the 979 unmodified DNS response, thus avoiding unnecessary recursion. For 980 example, a matching Client IP Address trigger (Section 4.1) in the 981 first specified RPZ always provides the result regardless of what 982 might be learned by asking (recursing to) the authority for the 983 QNAME. Of course, if the data already in the cache are not 984 dispositive, then the implementation MUST use recursion. For example 985 a matching QNAME trigger (Section 4.2) in the second RPZ could 986 potentially be overruled by a Response IP Address trigger 987 (Section 4.3) in the first RPZ. 989 Implementations which include this optimization SHOULD provide a 990 configuration switch (for example, "qname-wait-recurse") to turn it 991 on and off. The default value of the switch MAY be on or off. Some 992 security implications of avoiding unnecessary recursion are 993 considered in Section 12.4. 995 Implementations MAY cause the LOCAL-DATA-OR-DISABLED override 996 (described in Section 6.1) to imply not waiting for recursion, or to 997 require that optimization. 999 9.2. Check Parents Domains versus Zone Cuts 1001 In principle, the NSDNAME and NSIP processes of following the data 1002 path toward the root look for NS, A, and AAAA RRsets only in the 1003 apexes of zones. In practice, DNS resolvers often do not know which 1004 domain name parent-child relationships reflect zone delegations, and 1005 so RPZ implementations generally iteratively remove labels from the 1006 left end of the domain name to request NS RRsets from their caches or 1007 authoritative servers for each ancestor of the queried name. The 1008 cost of looking for an NS RRset for a domain name that is not at a 1009 delegation point is usually only asking for the RRset and receiving 1010 only an SOA from the cache. 1012 9.3. Abbreviate the Data Path for NSDNAME and NSIP Checks 1014 The process of traversing the data path from the level nearest the 1015 queried record to the top (root domain) level to check NSIP or 1016 NSDNAME triggers can be expensive. There are many NS records for the 1017 top level domains and the root, but checking them is rarely 1018 worthwhile because the root and TLDs are rarely used as NSIP or 1019 NSDNAME triggers. Some RPZ implementations have a "min-ns-dots" 1020 parameter that stops NSDNAME and NSIP checking short of the root 1021 zone, by not checking the name servers for domains whose names 1022 contain fewer than the configured minimum number of dots. 1024 9.4. Use Glue for NSDNAME and NSIP Checks 1026 Some implementations of DNS RPZ attempt to exhaustively discover all 1027 ancestral zone cuts above the query name and learn the NS RRset at 1028 the apex of each delegated zone. Other implementations use only the 1029 information which has naturally come into their caches, which often 1030 includes only delegations and glue, that is name server names and 1031 addresses sent by servers for the parent zone and not by those for 1032 the zone itself. Both of these tactics have shortcomings, but the 1033 more accurate tactic of checking delegations and glue as well as 1034 authoritative NS, A, and AAAA RRsets is generally considered too 1035 expensive. 1037 To limit the costs of checking NSDNAME and NSIP triggers, an 1038 implementation MAY have settings (for example "nsdname-wait- 1039 recurse no" or "nsip-wait-recurse no") which cause the resolver to 1040 use only the NS RRsets or only the A and AAAA RRsets already in the 1041 cache. With these settings, the resolver will not recurse if there 1042 are relevant cached entries (including negative entries) when 1043 processing NSDNAME or NSIP triggers, respectively. 1045 Note that using only already-cached instead of current and complete 1046 delegation, glue, and authoritative data can cause inconsistent RPZ 1047 behavior. Most recursive DNS server implementations do not renew 1048 delegation and glue RRsets when their TTLs expire if authoritative 1049 data are available in the cache. Requests by the RPZ part of a 1050 recursive server for NS RRsets and associated A and AAAA RRsets will 1051 often initially receive only delegations and glue from the cache. As 1052 time passes and TTLs expire, those requests tend to be answered less 1053 with delegations and glue and more with authoritative RRsets. If and 1054 when sufficient RRsets expire from the cache, the cycle repeats with 1055 RPZ once again relying more on delegations and glue. Thus, if the 1056 glue and authoritative RRsets differ, then RPZ installations that use 1057 whichever is available in the cache can produce inconsistent results. 1059 This is not an argument for NSDNAME or NSIP triggers to not use glue, 1060 because as discussed in Section 12.5, delegations and glue NS, A, and 1061 AAAA RRsets for miscreant domains are often more revealing and 1062 effective than their authoritative RRsets. 1064 9.5. Reduce Zone Size using Implied Rules 1066 In 2016, an RPZ zone of QNAME rules for many miscreant domain names 1067 contained 200 MBytes of data representing almost 8 million rules. In 1068 such an RPZ, many of the listed domain names are as undesirable as 1069 DNS servers as they are as mail senders, and so might reasonably have 1070 NSDNAME rules in addition to their QNAME rules. However, instead of 1071 paying the costs of doubling that RPZ zone to 16 million rules and 1072 400 MBytes, an RPZ implementations MAY offer a per-zone setting (for 1073 example "qname-as-ns yes") which causes the implementation to act as 1074 if for every rule with the trigger "EXAMPLE.COM", there is another 1075 rule in the RPZ with the trigger "EXAMPLE.COM.RPZ-NSDNAME" and the 1076 same policy action. 1078 An implementation MAY also offer a setting (for example "ip-as- 1079 ns yes") which similarly generates NSIP rules based on Response IP 1080 Address rules. Given an RPZ rule with a trigger of 1081 "24.0.2.0.192.rpz-ip", act as if the RPZ also contains another rule 1082 with the trigger "24.0.2.0.192.rpz-nsip" and the same policy action. 1084 10. History and Evolution 1086 An early description of RPZ can be found in a technical note from 1087 Internet Systems Consortium [ISC-RPZ]. RPZ was also described in 1088 2010 in chapter 6 of the "BIND 9 Administrator Reference Manual" 1089 [ISC-ARM]. 1091 RPZ was designed by Paul Vixie and Vernon Schryver in 2009. The 1092 initial implementation and first patch adding it to BIND were written 1093 by Vernon Schryver in late 2009. Patches for various versions of 1094 BIND9 including 9.4, 9.6, and 9.7 were distributed from FTP servers 1095 at redbarn.org and rhyolite.com starting in 2010. 1097 If all RPZ triggers and actions had been foreseen at the start in 1098 2009, they would probably have been encoded differently. Instead RPZ 1099 grew incrementally, and upward compatibility required support of the 1100 original encodings. The initial specification or Format 1 contained 1101 only QNAME triggers. Changes for Format 2 included adding triggers 1102 based on response contents (Response IP Address), the targets of NS 1103 records (NSDNAME), and contents of A and AAAA records that resolve NS 1104 records (NSIP). Format 3 included "rpz-passthru" for the PASSTHRU 1105 action and wildcards in Local Data CNAME targets to synthesize 1106 responses dynamically based on the query domain. 1108 Today, with a number of commercial RPZ providers with many users and 1109 no functional problems with the encodings, any lack of aesthetic 1110 appeal is balanced by the ever increasing weight of the installed 1111 base. For example, it is impossible to replace the original QNAME 1112 trigger encoding NXDOMAIN and NODATA policy action encodings with 1113 encodings that involve rpz-* pseudo-TLDs at RPZ providers without 1114 breaking the many existing RPZ subscriber installations. The 1115 original, deprecated PASSTHRU encoding of a CNAME pointing to the 1116 trigger QNAME might still be in use in local, private policy zones, 1117 and so it is still recognized by RPZ subscriber implementations as of 1118 2016. 1120 The initial idea for RPZ was only to deny the existence of 1121 objectionable domain names, and so there existed only QNAME triggers 1122 and NXDOMAIN actions. Given that single kind of trigger, encoding it 1123 as the owner name of a policy record was clearly best. A CNAME 1124 pointing to the root domain (.) is a legal and valid but not 1125 generally useful record, and so that became the encoding for the 1126 NXDOMAIN action. The encoding of the NODATA action as "CNAME *." 1127 followed similar reasoning. The addition of more triggers and more 1128 actions required a more general scheme, and so newer actions are 1129 encoded as CNAMEs with targets in bogus TLDs whose names start with 1130 "rpz-". Newer triggers are owner names containing DNS labels that 1131 start with "rpz-". 1133 It would have been better if all actions had been encoded as 1134 subdomains of the invalid "*" top level domain, for example 1135 "drop.rpz.*" and "passthru.rpz.*" and even "nxdomain.rpz.*". "rpz" 1136 would always be the second level domain and the action would be 1137 specified by the third level domain. That would have polluted only a 1138 single bogus TLD. Perhaps future versions of RPZ that define new 1139 actions will define those new actions using that scheme, and will use 1140 that scheme to redefine existing actions while deprecating but 1141 retaining the old definitions. 1143 11. IANA Considerations 1145 No actions are required from IANA as result of the publication of 1146 this document. 1148 12. Security Considerations 1150 12.1. DNS Data Security 1152 RPZ is a mechanism for providing "untruthful" DNS results to 1153 consenting stub resolvers from recursive servers. Nevertheless, RPZ 1154 does not exacerbate the existing vulnerability of DNS servers to 1155 falsified DNS data; it merely formalizes and facilitates modifying 1156 DNS data on its way from DNS authority servers to clients. Note that 1157 a non-consenting stub resolver can simply opt out by using a 1158 different recursive name server. 1160 12.2. DNSSEC 1162 The use of DNSSEC (see [RFC4033] and [RFC4034]) prevents the 1163 acceptance by clients of such RPZ-induced changes to DNS data. 1164 Therefore, by default, DNS resolvers using RPZ avoid modifying DNS 1165 results when DNSSEC signatures are available and are requested by the 1166 DNS client. However, when the common "break-dnssec" configuration 1167 setting is used, RPZ-using resolvers rewrite responses even in that 1168 case. They omit DNSSEC RRsets, because the modified responses cannot 1169 be verified by DNSSEC signatures. This renders the results invalid 1170 according to DNSSEC. In such a case, a querying client which checks 1171 DNSSEC reacts as though it has been subjected to a data poisoning 1172 attack and rejects the data. That reaction could entail expensive 1173 bypass operations. 1175 12.3. TSIG 1177 The policy zones might be considered sensitive, because they contain 1178 information about miscreants. Like other DNS zones in most 1179 situations, RPZs are transferred from publishers to subscribers as 1180 cleartext vulnerable to observation. DNS zones are vulnerable to 1181 forgery or modification if TSIG transaction signatures [RFC2845] are 1182 not used, and so TSIG SHOULD be used to authenticate RPZ contents and 1183 protect them from modification. 1185 12.4. Counterintelligence 1187 Recursive servers using RPZ can be optimized to avoid completing 1188 recursion if a policy rule provides a rewritten answer without 1189 needing this recursion (Section 9.1). However, the use of such an 1190 optimization allows miscreants to infer whether RPZ is in use and 1191 whether their RRs are listed, simply by observing requests sent to 1192 their own authority servers. Therefore, implementations that provide 1193 this optimization SHOULD allow it to be disabled. 1195 12.5. NSIP, NSDNAME, Glue, and Authoritative RRsets 1197 Apex ("below the cut") or authoritative NS, A, and AAAA RRsets 1198 containing the name server names and addresses for a zone often do 1199 not exactly match glue from the parent zone. Delegation and glue 1200 records or "above the cut" records from the parent zone are often 1201 incomplete or out of date compared to the NS, A, and AAAA RRs from 1202 authoritative servers for the zone itself. Regardless of any lack of 1203 completeness or accuracy, the delegation and glue records for a 1204 functioning domain are sufficently accurate for the domain to be 1205 resolvable: the authoritative servers for a zone cannot be found 1206 without a delegation and (if necessary) some glue. On the other 1207 hand, a domain with entirely broken authoritative name server data 1208 can largely work. 1210 The authoritative NS data for miscreant domains is often fanciful or 1211 even unavailable. For example, an authoritative NS RRset consisting 1212 of "NS ." is popular, because while it is wrong, it betrays nothing 1213 in particular about the miscreant who owns the domain. 1215 Thus delegations and glue are generally best for detecting and 1216 rewriting miscreant DNS data, if resource constraints prohibit 1217 checking both above-delegation and below-delegation NS and glue. 1219 13. Acknowledgements 1221 The authors gratefully acknowledge the substantial contributed 1222 material and editorial scrutiny of Anne Bennett. She directed the 1223 reorganization and clarification of the entire document. 1225 Eric Ziegast, Jeroen Massar, Ben April, Ray Bellis and Mukund 1226 Sivaraman provided improvements to the document and caught errors. 1228 14. References 1230 14.1. Normative References 1232 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1233 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1234 . 1236 [RFC1035] Mockapetris, P., "Domain names - implementation and 1237 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1238 November 1987, . 1240 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1241 DOI 10.17487/RFC1995, August 1996, 1242 . 1244 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1245 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1246 August 1996, . 1248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1249 Requirement Levels", BCP 14, RFC 2119, 1250 DOI 10.17487/RFC2119, March 1997, 1251 . 1253 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1254 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1255 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1256 . 1258 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1259 Wellington, "Secret Key Transaction Authentication for DNS 1260 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1261 . 1263 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1264 Rose, "DNS Security Introduction and Requirements", 1265 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1266 . 1268 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1269 Rose, "Resource Records for the DNS Security Extensions", 1270 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1271 . 1273 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1274 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1275 2006, . 1277 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1278 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1279 . 1281 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1282 Address Text Representation", RFC 5952, 1283 DOI 10.17487/RFC5952, August 2010, 1284 . 1286 14.2. Informative References 1288 [ISC-ARM] Internet Systems Consortium, "BIND 9 Administrator 1289 Reference Manual, 1290 https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/ 1291 Bv9ARM.ch06.html#rpz", 2016. 1293 [ISC-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS 1294 RPZ, Format 3), https://ftp.isc.org/isc/dnsrpz/isc-tn- 1295 2010-1.txt", 2010. 1297 [ISC-RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 1298 (DNS RRL), https://ftp.isc.org/isc/pubs/tn/isc-tn- 1299 2012-1.txt", 2012. 1301 Appendix A. Examples 1303 An existing data feed capable of producing an RHSBL can be trivially 1304 used to generate a DNS RPZ. If the desired policy is to alias 1305 targeted domains to a local walled garden, then for each domain name, 1306 generate the following records, one for the name itself and perhaps 1307 also one for its subdomains: 1309 bad.example.com CNAME walled-garden.example.net. 1310 *.bad.example.com CNAME walled-garden.example.net. 1312 If it is desirable to return NXDOMAIN for each domain (and its 1313 subdomains in this example), try this: 1315 bad.example.com CNAME . 1316 *.bad.example.com CNAME . 1318 Try this if there are walled gardens for mail versus everything else: 1320 bad.example.com MX 0 wgmail.example.net. 1321 bad.example.com A 192.0.2.66 1322 *.bad.example.com MX 0 wgmail.example.net. 1323 *.bad.example.com A 192.0.2.66 1325 An extended example follows: 1327 $ORIGIN rpz.example.net. 1328 $TTL 1H 1329 @ SOA LOCALHOST. named-mgr.example.net. ( 1330 1 1h 15m 30d 2h) NS LOCALHOST. 1332 ; QNAME policy records. 1333 ; There are no periods (.) after the relative owner names. 1334 nxdomain.example.com CNAME . ; NXDOMAIN policy 1335 nodata.example.com CNAME *. ; NODATA policy 1337 ; Redirect to walled garden 1338 bad.example.com A 10.0.0.1 1339 AAAA 2001:db8::1 1341 ; Rewrite all names inside "AZONE.EXAMPLE.COM" 1342 ; except "OK.AZONE.EXAMPLE.COM" 1343 *.azone.example.com CNAME garden.example.net. 1344 ok.azone.example.com CNAME rpz-passthru. 1346 ; Redirect "BZONE.EXAMPLE.COM" and "X.BZONE.EXAMPLE.COM" 1347 ; to "BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET" and 1348 ; "X.BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET", respectively. 1349 bzone.example.com CNAME *.garden.example.net. 1350 *.bzone.example.com CNAME *.garden.example.net. 1352 ; Rewrite all answers containing addresses in 192.0.2.0/24, 1353 ; except 192.0.2.1 1354 24.0.2.0.192.rpz-ip CNAME . 1355 32.1.2.0.192.rpz-ip CNAME rpz-passthru. 1357 ; Rewrite to NXDOMAIN all responses for domains for which 1358 ; "NS.EXAMPLE.COM" is an authoritative DNS server for that domain 1359 ; or any of its ancestors, or that have an authoritative server 1360 ; in 2001:db8::/32 1361 ns.example.com.rpz-nsdname CNAME . 1362 32.zz.db8.2001.rpz-nsip CNAME . 1364 ; Local Data can include many record types 1365 25.128.2.0.192.rpz-ip A 172.16.0.1 1366 25.128.2.0.192.rpz-ip A 172.16.0.2 1367 25.128.2.0.192.rpz-ip A 172.16.0.3 1368 25.128.2.0.192.rpz-ip MX 10 mx1.example.com 1369 25.128.2.0.192.rpz-ip MX 20 mx2.example.com 1370 25.128.2.0.192.rpz-ip TXT "Contact Central Services" 1371 25.128.2.0.192.rpz-ip TXT "Your system is infected." 1373 Authors' Addresses 1375 Paul Vixie 1376 Farsight Security, Inc. 1378 Email: paul@redbarn.org 1380 Vernon Schryver 1381 Rhyolite Software, LLC 1383 Email: vjs@rhyolite.com