idnits 2.17.1 draft-vixie-dns-rpz-02.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 2688 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 6 December 16, 2016 8 DNS Response Policy Zones 9 draft-vixie-dns-rpz-02 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 poicy 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Discussion Venue . . . . . . . . . . . . . . . . . . . . 3 61 2. Zone Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Policy Actions . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. The "NXDOMAIN" Action . . . . . . . . . . . . . . . . . . 4 64 3.2. The "NODATA" Action . . . . . . . . . . . . . . . . . . . 4 65 3.3. The "PASSTHRU" Action . . . . . . . . . . . . . . . . . . 5 66 3.4. The "DROP" Action . . . . . . . . . . . . . . . . . . . . 5 67 3.5. The "TCP-Only" Action . . . . . . . . . . . . . . . . . . 5 68 3.6. The "Local Data" Action . . . . . . . . . . . . . . . . . 6 69 4. Policy Triggers . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. The "Client IP Address" trigger (.rpz-client-ip) . . . . 7 71 4.2. The "QNAME" trigger ("example.com") . . . . . . . . . . . 8 72 4.3. The "Response IP address" trigger (.rpz-ip) . . . . . . . 8 73 4.4. The "NSDNAME" trigger (.rpz-nsdname) . . . . . . . . . . 9 74 4.5. The "NSIP" trigger (.rpz-nsip) . . . . . . . . . . . . . 10 75 5. Application of the Policy . . . . . . . . . . . . . . . . . . 11 76 5.1. Precedence Rules. . . . . . . . . . . . . . . . . . . . . 12 77 6. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 14 78 7. Producer Behavior . . . . . . . . . . . . . . . . . . . . . . 15 79 8. History and Evolution . . . . . . . . . . . . . . . . . . . . 16 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 12.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 This document describes DNS Firewalls, a method of expressing DNS 96 [RFC1034] policy information inside specially constructed DNS zones, 97 known as Response Policy Zones (RPZs). RPZs allow DNS reputation 98 data producers and subscribers to cooperate in the application of 99 policies to modify DNS responses in real time. Using the policy 100 information, DNS resolution for low-reputation DNS data can be made 101 to deliberately fail or to return local data such as an alias to a 102 "walled garden". 104 A site's DNS response policy consists of the set of rules expressed 105 in all of the RPZs that it uses. Each rule, expressed as an RRset, 106 consists of a trigger and an action. A full description of the 107 expressible policies is given in Section 3 (actions) and Section 4 108 (triggers), while Section 6 explains how the rules are applied. 110 Configuration examples are given using ISC BIND Version 9 (BIND9) 111 [ISC-ARM] syntax, because work to add RPZ to that platform was 112 started earliest (in 2009). The RPZ specification itself is free to 113 implement and free to use in operation. It has been implemented in 114 other name server software. We expect that in time, additional 115 recursive DNS implementations will also implement DNS Firewalls as 116 described by this RPZ specification. 118 1.1. Discussion Venue 120 The discussion venue for this document is the DNS Firewalls mailing 121 list. http://lists.redbarn.org/mailman/listinfo/dnsfirewalls offers 122 subscriptions and archives. See also https://dnsrpz.info/ 124 [NOTE TO EDITOR: This section must be removed before this Internet 125 Draft is published as an RFC.] 127 2. Zone Format 129 A DNS Response Policy Zone (RPZ) is a DNS zone. Like any DNS zone, 130 an RPZ consists of RRsets or sets of resource records (RRs) with a 131 common owner name and type. RRsets other than SOA and NS specify 132 actions and triggers. The owner name (left hand side) of each RRset 133 expresses a policy trigger, while the RDATA (right hand side) encodes 134 the action to taken when the trigger matches. Depending on the type 135 of trigger (see Section 4), a particular characteristic of the DNS 136 query or response is checked. 138 Because an RPZ is a valid DNS zone, its contents can be transferred 139 between DNS servers in whole (AXFR) [RFC5936] or incrementally as 140 changes occur (IXFR) [RFC1995], authenticated and protected by TSIG 141 transaction signatures [RFC2845] and expedited by real time change 142 notifications (NOTIFY) [RFC1996], all subject to familiar DNS access 143 controls. An RPZ need not support query access since query access is 144 never required. It is the zone transfer of RPZ content from 145 producers to subscribers which effectively publishes the policy data, 146 and it is the subscriber's server configuration which promotes RPZ 147 payload data into DNS control plane data. 149 Any valid DNS zone (including an RPZ) is required to have an SOA 150 record and at least one NS record at its apex, which is why the SOA 151 and NS records of an RPZ cannot themselves be used to encode DNS 152 response policy. 154 The RPZ's SOA record is real, with a serial number used for NOTIFY 155 and IXFR, and timers used for AXFR and IXFR. The MNAME field or 156 domain name of the primary source of the zone and the RNAME field or 157 mailbox of the person responsible for the zone are often used by RPZ 158 providers to label their policy zones. 160 As for an RPZ's apex NS record(s), since query access is never 161 required, they will never be used. Similarly, no parent delegation 162 is required for normal operation of the RPZ. Thus, by convention, a 163 single NS record having the deliberately bogus RDATA of "LOCALHOST." 164 is used as a placeholder. 166 The format of RPZs has undergone several revisions since work began 167 (see Section 8). All POLICY described here are from RPZ Format 1 168 unless otherwise noted. Policy triggers from a higher format number 169 than a recursive name server's implementation level are expected to 170 be invisible to that implementation. Policy actions from a higher 171 format number are likely to be misinterpreted as CNAME local data by 172 older implementations. 174 3. Policy Actions 176 An RPZ resource record can specify any of six results or actions. 178 3.1. The "NXDOMAIN" Action 180 A single resource record (RR) consisting of a CNAME whose target is 181 the root domain (.) will cause a response of NXDOMAIN to be returned. 182 This is the most commonly used RPZ action. 184 3.2. The "NODATA" Action 186 A single RR consisting of a CNAME whose target is the wildcard top- 187 level domain (*.) will cause a response of NODATA (ANCOUNT=0) to be 188 returned regardless of query type. 190 3.3. The "PASSTHRU" Action 192 It is sometimes necessary to exempt some DNS responses from the 193 response policy rule that covers an entire domain or a large IP 194 address block. Exempting some clients of a DNS resolver from all RPZ 195 rewriting can also be useful for research into attackers and for 196 debugging. The PASSTHRU action is intended to override other, 197 usually more general policies. It should be written so that it 198 appears at a higher precedence than the policies it must override. 199 See Section 5.1 about the precedence rules. 201 This policy zone record 203 $ORIGIN RPZ.EXAMPLE.ORG. 204 ok.example.com CNAME rpz-passthru. 206 would exempt requests for ok.example.com from the NXDOMAIN policy or 207 action of the following record: 209 $ORIGIN RPZ.EXAMPLE.ORG. 210 example.com CNAME . 211 *.example.com CNAME . 213 The deprecated original encoding of the PASSTHRU action was a CNAME 214 with a target equal to the QNAME field of the DNS request. That 215 encoding could not be used with some desirable triggers. 217 3.4. The "DROP" Action 219 The "DROP" policy that consists of discarding the request and 220 response is specified by a CNAME whose target is "rpz-drop". For 221 example, with 223 $ORIGIN RPZ.EXAMPLE.ORG. 224 example.com CNAME rpz-drop. 226 nothing is sent to a DNS client trying to resolve example.com, not 227 even a DNS error response. 229 3.5. The "TCP-Only" Action 231 The "TCP-Only" policy is specified by a CNAME whose target is 232 "rpz-tcp-only". It changes UDP responses to short, truncated DNS 233 responses that require the DNS client to try again with TCP. It is 234 used to mitigate distributed DNS reflection attacks and is similar to 235 the "slip" parameter of DNS Response Rate Limiting (RRL) [ISC-RRL]. 237 3.6. The "Local Data" Action 239 An RRset that is neither a special RPZ encoding of an action nor one 240 of several problematic record types specifies local data used to 241 generate synthetic DNS responses. The special RPZ encodings are 242 CNAMEs with targets of NXDOMAIN (.), NODATA (*.), a top level domain 243 starting with "rpz-", or a child of a top level domain starting with 244 "rpz-". Problematic record types include NS and DNSSEC (see 245 [RFC4034]), because their appearance in responses would be invalid or 246 confuse DNS clients. Local data DNAME RRsets are also commonly 247 rejected by RPZ subscribers for internal implementation and other 248 reasons. If any local data policy actions are present, then any 249 request for an RR type that is not present in the local data is 250 answered as NODATA (ANCOUNT=0) as if the recursive DNS server using 251 RPZ were authoritative for the query name. 253 The most common local data is a CNAME RR pointing to a walled garden. 254 Such CNAME RRs are distinguishable from other rpz actions, because 255 the CNAME target name will not be the root (.), nor the root wildcard 256 (*.), nor be a subdomain of a top level domain that starts with 257 "rpz-". 259 A special form of local data involves a CNAME RR with a wildcarded 260 target name. Wildcards are not valid as CNAME targets in ordinary 261 DNS zones. This special form causes the QNAME to be prepended to the 262 wildcarded target to communicate the triggering QNAME value to the 263 walled garden DNS server. For example a policy action of 264 "CNAME *.EXAMPLE.COM" and a query name of "EVIL.ORG." will result in 265 a synthetic response of "EVIL.ORG CNAME EVIL.ORG.EXAMPLE.COM." The 266 purpose for this special form is query logging in the walled garden's 267 DNS server. 269 4. Policy Triggers 271 There are five types of RPZ triggers, and they are encoded by RRset 272 owner names (left hand sides) in an RPZ. 274 Two of these types of trigger match characteristics of the DNS query: 275 "Client IP address" and "QNAME". They are independent of cache 276 contents or recursion results, but must be checked conceptually when 277 the response is ready, including after any needed recursion. 278 Recursion can sometimes be skipped, but only if the RPZ result would 279 not be changed (see Section 5.1). 281 The other three types of triggers are based on characteristics of the 282 DNS response, that is, on the RDATA to be returned to the client, or 283 in some cases, on NS-related RDATA used while recursively obtaining 284 the final response, regardless of whether or not those NS records or 285 additional data are themselves to be returned to the client. These 286 three trigger types are: "Response IP address", "NSDNAME", and 287 "NSIP". 289 All policies are conceptually applied after recursion, so that the 290 recursive DNS resolver's cache contains either nothing or "truth," 291 even if this truth is hidden by current policy. If the policy 292 changes, the original, unmodified data is available for processing 293 under the changed policy. 295 4.1. The "Client IP Address" trigger (.rpz-client-ip) 297 The IP addresses of DNS clients sending requests can be used as 298 triggers, which can be useful for disabling RPZ rewriting for DNS 299 clients used to test or investigate. Client IP address policy RRsets 300 have owner names that are subdomains of "rpz-client-ip" relativized 301 to the RPZ apex name, preceded by an encoded IP address or block of 302 addresses. 304 For example, the following would drop all requests from clients in 305 192.0.2.0/24 and give truthful answers to requests from a client at 306 2001:db8::3. 308 $ORIGIN RPZ.EXAMPLE.ORG. 309 24.0.2.0.192.rpz-client-ip CNAME rpz-drop. 310 128.3.zz.db8.2001.rpz-client-ip CNAME rpz-passthru. 312 4.1.1. IP address encoding in triggers 314 The IPv4 address (or address block) "B1.B2.B3.B4/prefix" is encoded 315 in an RPZ trigger as "prefix.B4.B3.B2.B1", with the address octets 316 reversed just as in the IN-ADDR.ARPA naming convention. (See 317 [RFC1034].) The prefix length ("prefix") must be between 1 and 32. 318 All four bytes, B4, B3, B2, and B1, must be present and must be 319 written in decimal ASCII. 321 For example, the address block 192.0.2.0/24 would be encoded as 322 "24.0.2.0.192". 324 The IPv6 address (or address block beginning at) 325 "W1:W2:W3:W4:W5:W6:W7:W8" is encoded in a format similar to the 326 standard IPv6 text representation (see [RFC5952]), again reversed: 327 "prefix.W8.W7.W6.W5.W4.W3.W2.W1". Each of W8,...,W1 is a one- to 328 four-digit hexadecimal ASCII number representing 16 bits of the IPv6 329 address with no leading zeroes. All 8 words must be present unless a 330 "zz" label is present. The "zz" label is analogous to the double- 331 colon (::) in the standard IPv6 address representation. The "zz" 332 label is expanded to zero-fill the middle portion of the IPv6 333 address. Exactly one "zz" label must be present if there are two or 334 more consecutive zero words in the address. The prefix length 335 ("prefix") must be between 1 and 128 337 For example, the address 2001:db8::3 (with implied prefix length 128) 338 would be encoded as "128.3.zz.db8.2001". 340 4.2. The "QNAME" trigger ("example.com") 342 The QNAME policy trigger matches on requested domains, the QNAME 343 field in the question section of DNS requests and responses. (See 344 [RFC1035].) The owner name of an RPZ QNAME policy RRset is the 345 relativized name of the domain name about which policy is being 346 expressed. For example, if the RPZ apex name is RPZ.EXAMPLE.ORG, an 347 RRset at example.com.RPZ.EXAMPLE.ORG would affect responses to 348 requests about example.com. 350 Wildcards also work, and so the owner name 351 "*.example.com.RPZ.EXAMPLE.ORG" would trigger on queries to any 352 subdomain of example.com. To control the policy for both a name and 353 its subdomains, two policy RRsets must be used, one for the domain 354 itself and another for a wildcard subdomain. In the following 355 example, queries for both example.com and all subdomains of 356 example.com will result in synthetic NXDOMAIN responses. 358 $ORIGIN RPZ.EXAMPLE.ORG. 359 example.com CNAME . 360 *.example.com CNAME . 362 4.3. The "Response IP address" trigger (.rpz-ip) 364 The response IP policy trigger matches response contents (RDATA): it 365 matches IP addresses that would otherwise appear in A and AAAA 366 records in the answer section of a DNS response. IP addresses in the 367 authority and additional sections are not considered. Response IP 368 policy RRsets have owner names that are subdomains of "rpz-ip" 369 relativized to the RPZ apex name, and an encoded IP address or block 370 of addresses. The IP address encodes are identical to those 371 described in Section 4.1.1for Client IP Address triggers. 373 For example, to force an NXDOMAIN response whenever a truthful 374 response would contain an answer section A RRset having an address in 375 192.0.2.0/24 unless address 192.0.2.2 is present, the RPZ would 376 contain these records: 378 $ORIGIN RPZ.EXAMPLE.ORG. 379 24.0.2.0.192.rpz-ip CNAME . 380 32.2.2.0.192.rpz-ip CNAME rpz-passthru. 382 In another example, to answer NODATA (ANCOUNT=0) whenever a truthful 383 response would contain an answer AAAA RRset having an address 384 2001:db8:101::/48 unless address 2001:db8:101::3 was present, the RPZ 385 would contain these records: 387 $ORIGIN RPZ.EXAMPLE.ORG. 388 48.zz.101.db8.2001.rpz-ip CNAME *. 389 128.3.zz.101:db8.2001.rpz-ip CNAME rpz-passthru. 391 Please refer to Section 5.1 to understand how the above exception 392 mechanims work. 394 4.4. The "NSDNAME" trigger (.rpz-nsdname) 396 The NSDNAME policy trigger matches name server names (NS RR) of any 397 name server which is in the data path for an RRset present in the 398 answer section of a DNS response. The data path is all delegation 399 points from (and including) the root zone to the closest enclosing NS 400 RRset for the owner name of the answering RRset. 402 In other words, an NSDNAME trigger is checked by first considering 403 the named servers (domain names in the NS records) for the query 404 domain (QNAME), then the name servers for the parent of the query 405 domain name, and so on until the name servers for the root (.) have 406 been checked or there fewer periods (.) in the domain name than the 407 value of a local "min-ns-dots" parameter. See Section 4.4.1.1 below. 409 NSDNAME policies are encoded as RRsets in subdomains of "rpz-nsdname" 410 but otherwise much like QNAME policies (xref target="qname"/>). For 411 example, to force an NXDOMAIN answer whenever a name server for the 412 requested domain or one of its parents is ns.example.com, the RPZ 413 would contain the following: 415 $ORIGIN RPZ.EXAMPLE.ORG. 416 ns.example.com.rpz-nsdname CNAME . 418 4.4.1. Implementation considerations for NSDNAME triggers 420 Note that these considerations apply also to NSIP triggers described 421 in Section 4.5 below. 423 4.4.1.1. Performance issues 425 The process of traversing the data path from the level nearest the 426 queried record to the top (root domain) level can be expensive, 427 especially when it comes to checking the many NS records for the top 428 level domains and the root. Because the name servers for the root 429 and the TLDs are rarely used as RPZ triggers, some RPZ 430 implementations have a "min-ns-dots" parameter that stops NSDNAME and 431 NSIP checking early. 433 Despite their costs, NSDNAME and NSIP triggers can be more effective 434 than QNAME and IP triggers. Miscreants can more easily change their 435 direct domain names and IP addresses (which are detected by QNAME and 436 IP triggers) than they can their change NS names and addresses 437 (detected by NSDNAME and NSIP triggers) in parent domains such as 438 TLDs. 440 4.4.1.2. Caching of NS records and related address data 442 Some implementations of DNS RPZ will attempt to exhaustively discover 443 all ancestral zone cuts above the query name and learn the NS RRset 444 at the apex of each delegated zone. Other implementations will know 445 only the zone cut information which has naturally come into the 446 cache, which will often include only name server names and addresses 447 from the parent. Apex ("below the cut") name server names and 448 addresses often do not exactly match those from the parent. Such 449 inconsistencies can lead to instability in DNS RPZ behavior. This 450 potential inconsistency must be taken into account when designing a 451 security policy or testing DNS RPZ. 453 For NSDNAME and NSIP triggers, the BIND9 and Unbound RPZ 454 implementations (as of 2016) match the NS, A, and AAAA RRsets already 455 in their caches unless there are none, in which case they recurse. 456 This strategy works well in practice, because their caches were 457 likely recently populated while generating the unmodified response 458 and checking QNAME and response IP address triggers. In addition, 459 the authoritative apex NS RRset (which, if obtained, would supersede 460 the cached NS RRset from the delegating zone) of a domain operated by 461 a malefactor is often peculiar. Even when it is reasonable, the 462 authoritative DNS servers for such a domain are often extremely slow 463 or broken. For example, RRs like "example.com NS ." claiming root as 464 the authoritative server for a second or lower level domain are 465 popular choices in miscreant apex NS RRsets, as are imaginative name 466 servers A and AAAA RRsets. 468 4.5. The "NSIP" trigger (.rpz-nsip) 470 The NSIP policy trigger matches name server addresses, that is A or 471 AAAA RRs referenced by an NS RRset. NSIP is much like NSDNAME 472 (described above) except that the matching is by name server address 473 rather than name server name. NSIP policies are expressed as 474 subdomains of "rpz-nsip" and have the same subdomain naming 475 convention as described for response IP policy triggers above 476 (Section 4.1.1). 478 In a process very similar to that for an NSDNAME trigger 479 (Section 4.4), an NSIP trigger is checked by first considering all of 480 the IP addresses for all the named servers for the QNAME, then 481 proceeding similarly parent of the QNAME, and so on until the name 482 servers for the root (.) have been checked or a policy has been 483 matched. 485 Policies are applied in order of precedence (see Section 5.1) at each 486 level in the data path. The data path traversal process stops 487 immediately when there is at least one policy match at a given level. 489 For example, to force an NXDNAME answer whenever one of the name 490 servers for the requested domain (QNAME) or one of its parents has an 491 address in the 192.0.2.0/24 block, the RPZ would contain the 492 following: 494 $ORIGIN RPZ.EXAMPLE.ORG. 495 24.0.2.0.192.rpz-nsip CNAME . 497 4.5.1. Implementation considerations for NSIP triggers 499 The performance and caching considerations for the implementation of 500 NSIP triggers are essentially identical to those described for 501 NSDNAME triggers (Section 4.4.1). 503 5. Application of the Policy 505 To enable the use of RPZs, the recursive name server's control plane 506 is connected to the DNS RPZ data plane by supplying an ordered list 507 of RPZs in the name server's configuration. For each DNS RPZ in this 508 list, it should be possible to specify an optional overriding policy 509 action to be used for any policy triggers found in that RPZ. These 510 override policies should include NXDOMAIN, NODATA, PASSTHRU, DROP, 511 TCP-ONLY, CNAME domain, GIVEN, and DISABLED. The first five of these 512 actions are defined in Section 3 above. "CNAME domain" is a 513 restricted case of the "Local Data" action (also defined in 514 Section 3) in which the rewritten response is a CNAME RR targeting 515 "domain." GIVEN explicitly reaffirms the default, which is to 516 respect all policy actions found in this DNS RPZ. The overriding 517 DISABLED action causes triggered actions in the zone to have no 518 effect except to log what would have happened, provided sufficient 519 logging is enabled; this is useful for debugging or previewing a 520 policy zone. 522 By default, policies are applied only on DNS requests that ask for 523 recursion (RD=1). Recursive DNS servers generally send their 524 requests to authority servers without asking for recursion (RD=0), 525 while stub resolvers ask for recursion (RD=1). Thus, RPZ at a 526 recursive server by default only affects requests from stub 527 resolvers. This default can be overridden in some implementations 528 with configuration statements such as "recursive-only no". 530 Also by default, RPZ policies are only applied to responses to DNS 531 requests that do not request DNSSEC metadata (DO=0) or for which no 532 DNSSEC metadata exists. This defaults can be overridden in some 533 implementations with a configuration statement such "break-dnssec 534 yes". See Section 10 about the implications of responding with 535 modified DNS responses when the DNS client seems to be expecting 536 DNSSEC signatures. 538 If a policy rule matches and results in a modified answer, then that 539 modified answer will include in its authority section the SOA RR of 540 the policy zone whose policy was used to generate the modified 541 answer. This SOA RR includes the name of the DNS RPZ and the serial 542 number of the policy data which was connected to the DNS control 543 plane when the answer was modified. 545 Conceptually, policies MUST be applied after recursion is complete 546 and all data needed to formulate a response is available. However, 547 implementations MAY short-circuit the process such as not waiting for 548 recursion when it is clear which modification will be made to the 549 response. Nevertheless, it SHOULD be possible to configure the 550 resolver to continue checking and filling its cache by recursion as 551 if it had not already made its decision, in order to deny operators 552 of authority servers for listed domains information about whether 553 they are listed, that is, in order to minimize giving hints to 554 miscreants about when to change their DNS data. In BIND9, for 555 example, this behavior is controlled with the "qname-wait-recurse" 556 configuration option. 558 When the QNAME is resolved with CNAME or DNAME, there are no response 559 IP address that might match a response IP address trigger, but NSIP 560 and NSDNAME triggers might be matched. Unless the original query 561 type is ANY, CNAME, or DNAME, the resolver will start over and try to 562 resolve the target of the CNAME. RPZ is also restarted and the CNAME 563 target is matched against CNAME policy rules resolved IP addresses 564 (if any) are matched with response IP address policy triggers, and so 565 forth. This process is repeated as the resolver follows the CNAME 566 chain. 568 5.1. Precedence Rules. 570 More than one policy trigger among the various DNS RPZs connected to 571 the name server's control plane can match a given DNS response, but 572 only a single policy rule can affect the response. In theory and for 573 standardization, all possible rules are considered simultaneously and 574 the following precedence rules are used to choose the single best RPZ 575 rule. In implementations, policy triggers are usually considered in 576 a sequence that mirrors the process of generating the DNS response, 577 because checking RPZ triggers is conveniently made a part of that 578 process. For example, client IP RPZ address triggers are often 579 checked early as the DNS request is being received and the client IP 580 address is checked in the access control list (ACL) that determines 581 which DNS client IP addresses can ask for recursion. The QNAME is 582 available for RPZ trigger matching before any response IP addresses 583 are known and so QNAME poliocy triggers are usually checked 584 immediately after client IP address triggers and before response IP 585 address triggers. NSIP and NSDNAME triggers are often checked last. 586 As far as the DNS client can determine, it MUST seem that all 587 matching triggers are found and weighed using the precedence rules, 588 but in practice, shortcuts are taken. For example, according to the 589 precedence rules, a matched QNAME trigger in the first policy zone 590 makes all response IP address, NSIP, and NSDNAME triggers moot. 591 There is no need to look for those matches, because they will not 592 affect the response. 594 The following list is ordered so that rules listed early override 595 rules listed later. 597 RPZ Ordering 598 Changes triggered by records in RPZs specified earlier in the 599 ordered set of DNS RPZs are applied instead of triggers in policy 600 zone specified later. 602 Within An RPZ 603 Among policies from a single RPZ, client IP address policies are 604 chosen instead of QNAME policies, QNAME policies are preferred to 605 IP, IP policies are preferred to NSDNAME, and NSDNAME policies are 606 preferred to NSIP. 608 Exact name match 609 As in exact versus wildcard domain name matching at authority 610 servers, exact domain name QNAME or NSDNAME triggers are preferred 611 to wildcards. 613 Name Length 614 The preceding rule implies QNAME policies are preferred to NSDNAME 615 policies. 617 Among triggered QNAME or NSDNAME policies within an RPZ, choose 618 the policy that matches the triggering domain name that appears 619 earlier in the sorting using the DNSSEC canonical DNS name order 620 described in section 6.1 of [RFC4034]. The last labels of domain 621 names are most significant in that ordering. A domain name that 622 is a parent of another appears before the child. Labels are 623 compared as if they were words in a dictionary so that a label 624 that is a prefix of a second label appears before the second. 625 Characters in labels are sorted by their values as US-ASCII 626 characters except that uppercase letters are treated as if they 627 were lowercase. 629 Prefix Length 630 A preceding rule implies that IP policies within an RPZ are 631 preferred to NSIP policies. 633 Among triggered IP or NSIP policies, use the policy (not the 634 matched IP address) with the longest internal policy zone prefix 635 length. The internal prefix length of an IPv6 address trigger is 636 the numeric value of the first label that defines it as described 637 in Section 4. The internal prefix length of an IPv4 trigger is 638 the numeric value of its first label plus 112. This adjustment 639 makes IPv4 triggers work the same as their equivalent 640 IPv4-compatible IPv6 address triggers. It also tends to favor 641 IPv4 triggers over IPv6 triggers. (See section 2.5.5.1 of 642 [RFC4291] about IPv4-compatible IPv6 addresses.) 644 Tie Breaker 645 Given equal internal prefix lengths, use the IP or NSIP policy 646 that matches the first IP address. Addresses with equal trigger 647 internal prefix lengths are ordered by their representations as 648 domain names described in Section 4, including the leading, 649 unadjusted prefix length. Because this tie breaking considers the 650 matched IP addresses instead of the triggered policy rules, the 651 first or least significant label of an IPv6 address is always 652 "128", and the first label of an IPv4 address is always "32". 654 6. Subscriber Behavior 656 RPZs must be primary or secondary zones at subscriber recursive 657 resolvers. They can be searched only in a recursive server's own 658 storage, because additional network transactions for DNS resolvers 659 are extremely undesirable. 661 Response policy zones are loaded in the usual way. For primary zones 662 this may mean loading the contents of a local file into memory, or 663 connecting to a database. For secondary zones this means 664 transferring the zone from the primary server using zone transfer 665 such as IXFR [RFC1995] or AXFR [RFC5936]. It is strongly recommended 666 that all secondary zone transfer relationships be protected with 667 transaction signatures (DNS TSIG) and that real time change 668 notification be enabled using the DNS NOTIFY protocol [RFC1996]. 670 DNS resolvers often have limited or no notion of a DNS zone or zone 671 file. They sometimes have special local zones, but generally have no 672 implementations of IXFR, AXFR, or NOTIFY. Therefore, an external 673 module or daemon that maintains local copies of policy zones can be 674 useful. 676 7. Producer Behavior 678 A DNS RPZ producer should make every effort to ensure that 679 incremental zone transfer (IXFR [RFC1995]) rather than full zone 680 transfer (AXFR [RFC5936]) is used to move new policy data toward 681 subscribers. Also, real time zone change notifications (DNS NOTIFY 682 [RFC1996]) should be enabled and tested. DNS RPZ subscribers are 683 "stealth slaves" as described in RFC 1996, and each such server must 684 be explicitly listed in the master server's configuration as 685 necessary to allow zone transfers from the stealth slave, as well to 686 ensure that zone change notifications are sent to it. Because DNS 687 NOTIFY is a lazy protocol, it may be necessary to explicitly trigger 688 the master server's "notify" logic after each change of the DNS RPZ. 689 These operational guidelines are to limit policy data latency, since 690 minimal latency is critical to both prevention of crime and abuse, 691 and to withdrawal of erroneous or outdated policy. 693 In the data feed for disreputable domains, each addition or deletion 694 or expiration can be handled using DNS UPDATE [RFC2136] to trigger 695 normal DNS NOTIFY and subsequent DNS IXFR activity which can keep the 696 subscribing servers well synchronized to the master RPZ. 697 Alternatively, on some primary name servers (such as ISC BIND) it is 698 possible to generate an entirely new primary RPZ file and have the 699 server compute the differences between each new version and its 700 predecessor. In ISC BIND this option is called "ixfr-from- 701 differences" and is known to be performant even for million-rule DNS 702 RPZ's with significant churn on a minute by minute basis. 704 It is good operational practice to include test records in each DNS 705 RPZ to help that DNS RPZ's subscribers verify that response policy 706 rewriting is working. For example, a DNS RPZ might include a QNAME 707 policy record for BAD.EXAMPLE.COM and an IP policy record for 708 192.0.2.1. A subscriber can verify the correctness of their 709 installation by querying for BAD.EXAMPLE.COM which does not exist in 710 real DNS. If an answer is received it will be from the DNS RPZ. 711 That answer will contain an SOA RR denoting the fully qualified name 712 of the DNS RPZ itself. 714 8. History and Evolution 716 RPZ was previously described in a technical note from Internet 717 Systems Consortium [ISC-RPZ]. A more up to date description appeared 718 in chapter 6 of the "BIND 9 Administrator Reference Manual" [ISC-ARM] 719 as of 2010. 721 RPZ was designed by Paul Vixie and Vernon Schryver in 2009. The 722 initial implementation and first patch adding it to BIND were written 723 by Vernon Schryver in late 2009. Patches for various versions of 724 BIND9 including 9.4, 9.6, and 9.7 were distributed from FTP servers 725 at redbarn.org and rhyolite.com starting in 2010. 727 If all RPZ triggers and actions had been foreseen at the start in 728 2009, they would probably have been encoded differently. Instead RPZ 729 grew incrementally, and upward compatibility required support of the 730 original encodings. The initial specification or Format 1 contained 731 only QNAME triggers. Changes for Format 2 included adding triggers 732 based on response contents (RDATA), the targets of NS records 733 (NSDNAME), and contents of A and AAAA records that resolve NS records 734 (NSIP). Format 3 included "rpz-passthru" for the PASSTHRU action and 735 wildcards in CNAME targets to synthesize local data. 737 Today, with a number of commercial RPZ providers with many users and 738 no functional problems with the encodings, any lack of aesthetic 739 appeal is balanced by the ever increasing weight of the installed 740 base. For example, it is impossible to replace the original QNAME 741 trigger encoding NXDOMAIN and NODATA policy action encodings with 742 encodings that involve rpz-* pseudo-TLDs at RPZ providers without 743 breaking the many existing RPZ subscriber installations. The 744 original, deprecated PASSTHRU encoding of a CNAME pointing to the 745 trigger QNAME might still be in use in local, private policy zones, 746 and so it is still recognized by RPZ subscriber implementations. 748 The initial RPZ idea was only to deny the existence of objectionable 749 domain names, and so there were only QNAME triggers and NXDOMAIN 750 actions. Given that single kind of trigger, encoding it as the owner 751 name of a policy record was clearly best. A CNAME pointing to the 752 root domain (.) is a legal and valid but not generally useful record, 753 and so that became the encoding for the NXDOMAIN action. The 754 encoding of the NODATA action as "CNAME *." followed similar 755 reasoning. Requests for more kinds of triggers and actions required 756 a more general scheme, and so they are encoded as CNAMES with targets 757 in bogus TLDs owner names with DNS labels that start with "rpz_". 759 9. IANA Considerations 761 No actions are required from IANA as result of the publication of 762 this document. 764 10. Security Considerations 766 RPZ is a mechanism for providing "untruthful" DNS results from 767 recursive servers. Nevertheless, RPZ does not exacerbate the 768 existing vulnerability of recursive servers to falsified DNS data. 769 RPZ merely formalizes and facilitates modifying DNS data on its way 770 from DNS authority servers to clients. However, the use of DNSSEC 771 (see [RFC4033] and [RFC4034]) prevents such changes to DNS data by 772 RPZ. 774 Therefore, by default, DNS resolvers using RPZ avoid modifying DNS 775 results when DNSSEC signatures are available and are requested by the 776 DNS client. However, when the common "break-dnssec" configuration 777 setting is used, RPZ-using resolvers rewrite responses. They omit 778 DNSSEC RRsets, because the modified responses cannot be verified by 779 DNSSEC signatures. This renders the results invalid according to 780 DNSSEC. In such a case, a querying client which checks DNSSEC will 781 ignore the invalid result, and will effectively be blocked from 782 miscreant domains; this behaviour is functionally similar to that 783 caused by an RPZ NXDOMAIN policy action. 785 The policy zones might be considered sensitive, because they contain 786 information about miscreants. Like other DNS zones in most 787 situations, RPZs are transferred from sources to subscribers as 788 cleartext vulnerable to observation. However, TSIG transaction 789 signatures [RFC2845] SHOULD be used to authenticate and protect RPZ 790 contents from modification. 792 Recursive servers using RPZ are often configured to complete 793 recursion even if a policy trigger provides a rewritten answer 794 without needing recursion. This impedes miscreants observing 795 requests from their own authority servers from inferring whether RPZ 796 is in use and whether their RRs are listed. "qname-wait-recurse" is 797 a common configuration switch that controls this behavior. See 798 Section 5. 800 11. Acknowledgements 802 The authors gratefully acknowledge the substantial contributed 803 material and editorial scrutiny of Anne Bennett. She directed the 804 reorganization and clarification of the entire document. 806 Eric Ziegast, Jeroen Massar, and Ben April provided improvements to 807 the document and caught errors. 809 12. References 811 12.1. Normative References 813 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 814 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 815 . 817 [RFC1035] Mockapetris, P., "Domain names - implementation and 818 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 819 November 1987, . 821 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 822 DOI 10.17487/RFC1995, August 1996, 823 . 825 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 826 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 827 August 1996, . 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, 831 DOI 10.17487/RFC2119, March 1997, 832 . 834 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 835 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 836 RFC 2136, DOI 10.17487/RFC2136, April 1997, 837 . 839 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 840 Wellington, "Secret Key Transaction Authentication for DNS 841 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 842 . 844 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 845 Rose, "DNS Security Introduction and Requirements", 846 RFC 4033, DOI 10.17487/RFC4033, March 2005, 847 . 849 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 850 Rose, "Resource Records for the DNS Security Extensions", 851 RFC 4034, DOI 10.17487/RFC4034, March 2005, 852 . 854 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 855 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 856 2006, . 858 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 859 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 860 . 862 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 863 Address Text Representation", RFC 5952, 864 DOI 10.17487/RFC5952, August 2010, 865 . 867 12.2. Informative References 869 [ISC-ARM] Internet Systems Consortium, "BIND 9 Administrator 870 Reference Manual, 871 https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/ 872 Bv9ARM.ch06.html#rpz", 2016. 874 [ISC-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS 875 RPZ, Format 3), https://ftp.isc.org/isc/dnsrpz/isc-tn- 876 2010-1.txt", 2010. 878 [ISC-RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 879 (DNS RRL), https://ftp.isc.org/isc/pubs/tn/isc-tn- 880 2012-1.txt", 2012. 882 Appendix A. Examples 884 An existing data feed capable of producing an RHSBL can be trivially 885 used to generate a DNS RPZ. If the desired policy is to alias 886 targeted domains to a local walled garden, then for each domain name, 887 generate the following records, one for the name itself and perhaps 888 also one for its subdomains: 890 bad.example.com CNAME walled-garden.example.net. 891 *.bad.example.com CNAME walled-garden.example.net. 893 If it is desirable to return NXDOMAIN for each domain (and its 894 subdomains in this example), try this: 896 bad.example.com CNAME . 897 *.bad.example.com CNAME . 899 Try this if there are walled gardens for mail versus everything else: 901 bad.example.com MX 0 wgmail.example.net. 902 bad.example.com A 192.0.2.66 903 *.bad.example.com MX 0 wgmail.example.net. 904 *.bad.example.com A 192.0.2.66 906 An extended example follows: 908 $ORIGIN rpz.example.net. 909 $TTL 1H 910 @ SOA LOCALHOST. named-mgr.example.net. ( 911 1 1h 15m 30d 2h) NS LOCALHOST. 913 ; QNAME policy records. 914 ; There are no periods (.) after the relative owner names. 915 nxdomain.example.com CNAME . ; NXDOMAIN policy 916 nodata.example.com CNAME *. ; NODATA policy 918 ; redirect to walled garden 919 bad.example.com A 10.0.0.1 920 AAAA 2001:db8::1 922 ; do not rewrite OK.EXAMPLE.COM (PASSTHRU) 923 ok.example.com CNAME rpz-passthru. 924 bzone.example.com CNAME garden.example.net. 926 ; redirect X.BZONE.EXAMPLE.COM to 927 ; X.BZONE.EXAMPLE.COM.GARDEN.EXAMPLE.NET 928 *.bzone.example.com CNAME *.garden.example.net. 930 ; rewrite all answers for 192.0.2.0/24 except 192.0.2.1 931 24.0.2.0.192.rpz-ip CNAME . 932 32.1.2.0.192.rpz-ip CNAME rpz-passthru. 934 ; rewrite to NXDOMAIN all responses; for domains for which 935 ; NS.EXAMPLE.COM is an authoritative DNS server or a server 936 ; for a parent) or that have an authoritative server 937 ; in 2001:db8::/32 938 ns.example.com.rpz-nsdname CNAME . 939 32.zz.db8.2001.rpz-nsip CNAME . 941 Authors' Addresses 943 Paul Vixie 944 Farsight Security, Inc. 946 Email: paul@redbarn.org 947 Vernon Schryver 948 Rhyolite Software 950 Email: vjs@rhyolite.com