idnits 2.17.1 draft-ietf-dnsop-edns-client-subnet-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (April 19, 2016) is 2927 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) == Outdated reference: A later version (-08) exists of draft-hardie-privsec-metadata-insertion-02 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop C. Contavalli 3 Internet-Draft W. van der Gaast 4 Intended status: Informational Google 5 Expires: October 21, 2016 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 April 19, 2016 11 Client Subnet in DNS Queries 12 draft-ietf-dnsop-edns-client-subnet-08 14 Abstract 16 This document describes an EDNS0 extension that is in active use to 17 carry information about the network that originated a DNS query, and 18 the network for which the subsequent response can be cached. Since 19 it has some known operational and privacy shortcomings, a revision 20 will be worked through the IETF for improvement. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 21, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 59 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8 63 7.1. Originating the Option . . . . . . . . . . . . . . . . . 8 64 7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8 65 7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9 66 7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 10 67 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10 68 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10 69 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12 70 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 13 71 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 14 72 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 15 73 7.4. Delegations and Negative Answers . . . . . . . . . . . . 15 74 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 16 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 17 77 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 19 80 11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 19 81 11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 20 82 12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 21 83 12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 21 84 12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 22 85 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 24 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 16.2. Informative References . . . . . . . . . . . . . . . . . 27 91 Appendix A. Document History . . . . . . . . . . . . . . . . . . 27 92 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 97 1. Introduction 99 Many Authoritative Nameservers today return different responses based 100 on the perceived topological location of the user. These servers use 101 the IP address of the incoming query to identify that location. 102 Since most queries come from intermediate Recursive Resolvers, the 103 source address is that of the Recursive Resolver rather than of the 104 query originator. 106 Traditionally, and probably still in the majority of instances, 107 Recursive Resolvers are reasonably close in the topological sense to 108 the Stub Resolvers or Forwarding Resolvers that are the source of 109 queries. For these resolvers, using their own IP address is 110 sufficient for Authoritative Nameservers that tailor responses based 111 upon location of the querier. 113 Increasingly, though, a class of Recursive Resolvers has arisen that 114 handle query sources that are often not topologically close. The 115 motivation for having such Centralized Resolvers varies but is 116 usually because of some enhanced experience, such as greater cache 117 security or applying policies regarding where users may connect. 118 (Although political censorship usually comes to mind here, the same 119 actions may be used by a parent when setting controls on where a 120 minor may connect.) Similarly, many ISPs and other organizations use 121 a Centralized Resolver infrastructure that can be distant from the 122 clients the resolvers serve. These cases all lead to less than 123 desirable responses from topology-sensitive Authoritative 124 Nameservers. 126 This document defines an EDNS0 [RFC6891] option to convey network 127 information that is relevant to the DNS message. It will carry 128 sufficient network information about the originator for the 129 Authoritative Nameserver to tailor responses. It will also provide 130 for the Authoritative Nameserver to indicate the scope of network 131 addresses for which the tailored answer is intended. This EDNS0 132 option is intended for those Recursive Resolvers and Authoritative 133 Nameservers that would benefit from the extension and not for general 134 purpose deployment. It is completely optional and can safely be 135 ignored by servers that choose not to implement it or enable it. 137 This document also includes guidelines on how to best cache those 138 results and provides recommendations on when this protocol extension 139 should be used. 141 At least a dozen different client and server implementations have 142 been written based on earlier versions of this specification. The 143 protocol is in active production use today. While the 144 implementations interoperate, there is varying behavior around edge 145 cases that were poorly specified. Known incompatibilities are 146 described in this document, and the authors believe that it is better 147 to describe the system as it is working today, even if not everyone 148 agrees with the details of the original specification ( 149 [I-D.vandergaast-edns-client-subnet]). The alternative is an 150 undocumented and proprietary system. 152 A revised proposal to improve upon the minor flaws in this protocol 153 will be forthcoming to the IETF. 155 2. Privacy Note 157 If we were just beginning to design this mechanism, and not 158 documenting existing protocol, it is unlikely that we would have done 159 things exactly this way. 161 The IETF is actively working on enhancing DNS privacy 162 [DPRIVE_Working_Group], and the re-injection of metadata has been 163 identified as a problematic design pattern 164 [I-D.hardie-privsec-metadata-insertion] 166 As noted above, however, this document primarily describes existing 167 behavior of a deployed method, to further the understanding of the 168 Internet community. 170 We recommend that the feature be turned off by default in all 171 nameserver software, and that operators only enable it explicitly in 172 those circumstances where it provides a clear benefit for their 173 clients. We also encourage the deployment of means to allow users to 174 make use of the opt-out provided. Finally, we recommend that others 175 avoid techniques that may introduce additional metadata in future 176 work, as it may damage user trust. 178 Regrettably, support for the opt-out provisions of this specification 179 are currently limited. Only one stub resolver, getdns, is known to 180 be able to originate queries with anonymity requested, and as yet no 181 applications are known to be able to indicate that user preference to 182 the stub resolver. 184 3. Requirements Notation 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 4. Terminology 192 ECS: EDNS Client Subnet. 194 Client: A Stub Resolver, Forwarding Resolver, or Recursive Resolver. 195 A client to a Recursive Resolver or a Forwarding Resolver. 197 Server: A Forwarding Resolver, Recursive Resolver or Authoritative 198 Nameserver. 200 Stub Resolver: A simple DNS protocol implementation on the client 201 side as described in [RFC1034] section 5.3.1. A client to a 202 Recursive Resolver or a Forwarding Resolver. 204 Authoritative Nameserver: A nameserver that has authority over one 205 or more DNS zones. These are normally not contacted by Stub 206 Resolver or end user clients directly but by Recursive Resolvers. 207 Described in [RFC1035] Section 6. 209 Recursive Resolver: A nameserver that is responsible for resolving 210 domain names for clients by following the domain's delegation 211 chain. Recursive Resolvers frequently use caches to be able to 212 respond to client queries quickly. Described in [RFC1035] 213 Section 7. 215 Forwarding Resolver: A nameserver that does not do iterative 216 resolution itself, but instead passes that responsibility to 217 another Recursive Resolver, called a "Forwarder" in [RFC2308] 218 section 1. 220 Intermediate Nameserver: Any nameserver in between the Stub Resolver 221 and the Authoritative Nameserver, such as a Recursive Resolver or 222 a Forwarding Resolver. 224 Centralized Resolvers: Intermediate Nameservers that serve a 225 topologically diverse network address space. 227 Tailored Response: A response from a nameserver that is customized 228 for the node that sent the query, often based on performance (i.e. 229 lowest latency, least number of hops, topological distance, ...). 231 Topologically Close: Refers to two hosts being close in terms of 232 number of hops or time it takes for a packet to travel from one 233 host to the other. The concept of topological distance is only 234 loosely related to the concept of geographical distance: two 235 geographically close hosts can still be very distant from a 236 topological perspective, and two geographically distant hosts can 237 be quite close on the network. 239 For a more comprehensive treatment of DNS terms, please see 240 [RFC7719]. 242 5. Overview 244 The general idea of this document is to provide an EDNS0 option to 245 allow Recursive Resolvers, if they are willing, to forward details 246 about the origin network from which a query is coming when talking to 247 other Nameservers. 249 The format of the edns-client-subnet (ECS) EDNS0 option is described 250 in Section 6, and is meant to be added in queries sent by 251 Intermediate Nameservers in a way transparent to Stub Resolvers and 252 end users, as described in Section 7.1. ECS is only defined for the 253 Internet (IN) DNS class. 255 As described in Section 7.2, an Authoritative Nameserver could use 256 ECS as a hint to the network location of the end user and provide a 257 better answer. Its response would also contain an ECS option, 258 clearly indicating that the server made use of this information, and 259 that the answer is tied to the network of the client. 261 As described in Section 7.3, Intermediate Nameservers would use this 262 information to cache the response. 264 Some Intermediate Nameservers may also have to be able to forward ECS 265 queries they receive. This is described in Section 7.5. 267 The mechanisms provided by ECS raise various security related 268 concerns related to cache growth, the ability to spoof EDNS0 options, 269 and privacy. Section 11 explores various mitigation techniques. 271 The expectation, however, is that this option will primarily be used 272 between Recursive Resolvers and Authoritative Nameservers that are 273 sensitive to network location issues. Most Recursive Resolvers, 274 Authoritative Nameservers and Stub Resolvers will never need to know 275 about this option, and will continue working as they had been. 277 Failure to support this option or its improper handling will, at 278 worst, cause suboptimal identification of client network location, 279 which is a common occurrence in current content delivery network 280 (CDN) setups. 282 Section 7.1 also provides a mechanism for Stub Resolvers to signal 283 Recursive Resolvers that they do not want ECS treatment for specific 284 queries. 286 Additionally, operators of Intermediate Nameservers with ECS enabled 287 are allowed to choose how many bits of the address of received 288 queries to forward, or to reduce the number of bits forwarded for 289 queries already including an ECS option. 291 6. Option Format 293 This protocol uses an EDNS0 [RFC6891]) option to include client 294 address information in DNS messages. The option is structured as 295 follows: 297 +0 (MSB) +1 (LSB) 298 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 299 0: | OPTION-CODE | 300 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 301 2: | OPTION-LENGTH | 302 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 303 4: | FAMILY | 304 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 305 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 306 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 307 8: | ADDRESS... / 308 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 310 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 311 0x08). 313 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 314 length of the payload (everything after OPTION-LENGTH) in octets. 316 o FAMILY, 2 octets, indicates the family of the address contained in 317 the option, using address family codes as assigned by IANA in 318 Address Family Numbers [Address_Family_Numbers]. 320 The format of the address part depends on the value of FAMILY. This 321 document only defines the format for FAMILY 1 (IP version 4) and 2 322 (IP version 6), which are as follows: 324 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost 325 number of significant bits of ADDRESS to be used for the lookup. 326 In responses, it mirrors the same value as in the queries. 328 o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost 329 number of significant bits of ADDRESS that the response covers. 330 In queries, it MUST be set to 0. 332 o ADDRESS, variable number of octets, contains either an IPv4 or 333 IPv6 address, depending on FAMILY, which MUST be truncated to the 334 number of bits indicated by the SOURCE PREFIX-LENGTH field, 335 padding with 0 bits to pad to the end of the last octet needed. 337 o A server receiving an ECS option that uses either too few or too 338 many ADDRESS octets, or that has non-zero ADDRESS bits set beyond 339 SOURCE PREFIX-LENGTH, SHOULD return FORMERR to reject the packet, 340 as a signal to the developer of the software making the request to 341 fix their implementation. 343 All fields are in network byte order ("big-endian", per [RFC1700], 344 Data Notation). 346 7. Protocol Description 348 7.1. Originating the Option 350 The ECS option should generally be added by Recursive Resolvers when 351 querying Authoritative Nameservers, as described in Section 12. The 352 option can also be initialized by a Stub Resolver or Forwarding 353 Resolver. 355 7.1.1. Recursive Resolvers 357 The setup of the ECS option in a Recursive Resolver depends on the 358 client query that triggered the resolution process. 360 In the usual case, where no ECS option was present in the client 361 query, the Recursive Resolver initializes the option by setting the 362 FAMILY of the client's address. It then uses the value of its 363 maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For 364 privacy reasons, and because the whole IP address is rarely required 365 to determine a tailored response, this length SHOULD be shorter than 366 the full address, as described in Section 11. 368 If the triggering query included an ECS option itself, it MUST be 369 examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's 370 outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of 371 the incoming query's SOURCE PREFIX-LENGTH or the server's maximum 372 cacheable prefix length. 374 Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the 375 ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits, 376 with trailing 0 bits added, if needed, to fill the final octet. The 377 total number of octets used MUST only be enough to cover SOURCE 378 PREFIX-LENGTH bits, rather than the full width that would normally be 379 used by addresses in FAMILY. 381 FAMILY and ADDRESS information MAY be used from the ECS option in the 382 incoming query. Passing the existing address data is supportive of 383 the Recursive Resolver being used as the target of a Forwarding 384 Resolver, but could possibly run into policy problems with regard to 385 usage agreements between the Recursive Resolver and Authoritative 386 Nameserver. See Section 12.2 for more discussion on this point. If 387 the Recursive Resolver will not forward the FAMILY and ADDRESS data 388 from the incoming ECS option, it SHOULD return a REFUSED response. 390 Subsequent queries to refresh the data MUST, if unrestricted by an 391 incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- 392 LENGTH that the Recursive Resolver is willing to cache, even if a 393 previous response indicated that a shorter prefix length was 394 sufficient. 396 7.1.2. Stub Resolvers 398 A Stub Resolver MAY generate DNS queries with an ECS option that sets 399 SOURCE PREFIX-LENGTH to limit how network information should be 400 revealed. An Intermediate Nameserver that receives such a query MUST 401 NOT make queries that include more bits of client address than in the 402 originating query. 404 A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add 405 address information of the client to its queries. The subsequent 406 Recursive Resolver query to the Authoritative Nameserver will then 407 either not include an ECS option or MAY optionally include its own 408 address information, which is what the Authoritative Nameserver will 409 almost certainly use to generate any Tailored Response in lieu of an 410 option. This allows the answer to be handled by the same caching 411 mechanism as other queries, with an explicit indicator of the 412 applicable scope. Subsequent Stub Resolver queries for /0 can then 413 be answered from this cached response. 415 A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include 416 FAMILY and ADDRESS data, but should be prepared to handle a REFUSED 417 response if the Intermediate Nameserver that it queries has a policy 418 that denies forwarding of the ADDRESS. If there is no ADDRESS set, 419 i.e. SOURCE PREFIX-LENGTH is set to 0, then FAMILY SHOULD be set to 420 the transport over which the query is sent. This is for 421 interoperability; at least one major authoritative server will ignore 422 the option if FAMILY is not 1 or 2, even though it is irrelevant if 423 there are no ADDRESS bits. 425 7.1.3. Forwarding Resolvers 427 Forwarding Resolvers essentially appear to be Stub Resolvers to 428 whatever Recursive Resolver is ultimately handling the query, but 429 look like a Recursive Resolver to their client. A Forwarding 430 Resolver using this option MUST prepare it as described above in 431 Section 7.1.1, Recursive Resolvers. In particular, a Forwarding 432 Resolver that implements this protocol MUST honor SOURCE PREFIX- 433 LENGTH restrictions indicated in the incoming query from its client. 434 See also Section 7.5. 436 Since the Recursive Resolver it contacts will treat the Forwarding 437 Resolver like a Stub Resolver, the Recursive Resolver's policies 438 regarding incoming ADDRESS information will apply in the same way. 439 If the Forwarding Resolver receives a REFUSED response when it sends 440 a query which includes a non-zero ADDRESS, it MUST retry with no 441 ADDRESS. 443 7.2. Generating a Response 445 7.2.1. Authoritative Nameserver 447 When a query containing an ECS option is received, an Authoritative 448 Nameserver supporting ECS MAY use the address information specified 449 in the option in order to generate a tailored response. 451 Authoritative Nameservers that have not implemented or enabled 452 support for the ECS option ought to safely ignore it within incoming 453 queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include 454 an ECS option within replies, to indicate lack of support for it. 455 Implementers of Intermediate Nameservers should be aware, however, 456 that some nameservers incorrectly echo back unknown EDNS0 options. 457 In this protocol that should be mostly harmless, as SCOPE PREFIX- 458 LENGTH should come back as 0, thus marking the response as covering 459 all networks. 461 A query with a wrongly formatted option (e.g., an unknown FAMILY) 462 MUST be rejected and a FORMERR response MUST be returned to the 463 sender, as described by [RFC6891], Transport Considerations. 465 An Authoritative Nameserver that implements this protocol and 466 receives an ECS option MUST include an ECS option in its response to 467 indicate that it SHOULD be cached accordingly, regardless of whether 468 the client information was needed to formulate an answer. (Note that 469 the [RFC6891] requirement to reserve space for the OPT record could 470 mean that the answer section of the response will be truncated and 471 fallback to TCP indicated accordingly.) If an ECS option was not 472 included in a query, one MUST NOT be included in the response even if 473 the server is providing a Tailored Response -- presumably based on 474 the address from which it received the query. 476 The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST 477 match those in the query. Echoing back these values helps to 478 mitigate certain attack vectors, as described in Section 11. 480 The SCOPE PREFIX-LENGTH in the response indicates the network for 481 which the answer is intended. 483 A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH 484 indicates that the provided prefix length was not specific enough to 485 select the most appropriate Tailored Response. Future queries for 486 the name within the specified network SHOULD use the longer SCOPE 487 PREFIX-LENGTH. Factors affecting whether the Recursive Resolver 488 would use the longer length include the amount of privacy masking the 489 operator wants to provide their users, and the additional resource 490 implications for the cache. 492 Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits 493 than necessary were provided, and the answer is suitable for a 494 broader range of addresses. This could be as short as 0, to indicate 495 that the answer is suitable for all addresses in FAMILY. 497 As the logical topology of any part of the network with regard to the 498 tailored response can vary, an Authoritative Nameserver may return 499 different values of SCOPE PREFIX-LENGTH for different networks. 501 Since some queries can result in multiple RRsets being added to the 502 response, there is an unfortunate ambiguity from the original 503 specification as to how SCOPE PREFIX-LENGTH would apply to each 504 individual RRset. For example, multiple types in response to an ANY 505 metaquery could all have different applicable SCOPE PREFIX-LENGTH 506 values, but this protocol only has the ability to signal one. The 507 response SHOULD therefore include the longest relevant PREFIX-LENGTH 508 of any RRset in the answer, which could have the unfortunate side- 509 effect of redundantly caching some data that could be cached more 510 broadly. For the specific case of a CNAME chain, the Authoritative 511 Nameserver SHOULD only place the initial CNAME record in the Answer 512 section, to have it cached unambiguously appropriately. Most modern 513 Recursive Resolvers restart the query with the canonical name, so the 514 remainder of the chain is typically ignored anyway. For message- 515 focused resolvers, rather than RRset-focused ones, this will mean 516 caching the entire CNAME chain at the longest PREFIX-LENGTH of any 517 RRset in the chain. 519 The specific logic that an Authoritative Nameserver uses to choose a 520 tailored response is not in the scope of this document. Implementers 521 are encouraged, however, to consider carefully their selection of 522 SCOPE PREFIX-LENGTH for the response in the event that the best 523 tailored response cannot be determined, and what the implications 524 would be over the life of the TTL. 526 Authoritative Nameservers might have situations where one Tailored 527 Response is appropriate for a relatively broad address range, such as 528 an IPv4 /20, except for some exceptions, such as a few /24 ranges 529 within that /20. Because it can't be guaranteed that queries for all 530 longer prefix lengths would arrive before one that would be answered 531 by the shorter prefix length, an Authoritative Nameserver MUST NOT 532 overlap prefixes. 534 When the Authoritative Nameserver has a longer prefix length Tailored 535 Response within a shorter prefix length Tailored Response, then 536 implementations can either: 538 1. Deaggregate the shorter prefix response into multiple longer 539 prefix responses, or, 541 2. Alert the operator that the order of queries will determine which 542 answers get cached, and either warn and continue or treat this as 543 an error and refuse to load the configuration. 545 This choice should be documented for the operator, for example in the 546 user manual. 548 When deaggregating to correct the overlap, prefix lengths should be 549 optimized to use the minimum necessary to cover the address space, in 550 order to reduce the overhead that results from having multipe copies 551 of the same answer. As a trivial example, if the Tailored Response 552 for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then 553 the Authoritative Nameserver would need to provide Tailored Responses 554 for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 555 1.2.3/24 to B. 557 7.2.2. Intermediate Nameserver 559 When an Intermediate Nameserver uses ECS, whether it passes an ECS 560 option in its own response to its client is predicated on whether the 561 client originally included the option. Because a client that did not 562 use an ECS option might not be able to understand it, the server MUST 563 NOT provide one in its response. If the client query did include the 564 option, the server MUST include one in its response, especially as it 565 could be talking to a Forwarding Resolver which would need the 566 information for its own caching. 568 If an Intermediate Nameserver receives a response which has a longer 569 SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in 570 its query, it SHOULD still provide the result as the answer to the 571 triggering client request even if the client is in a different 572 address range. The Intermediate Nameserver MAY instead opt to retry 573 with a longer SOURCE PREFIX-LENGTH to get a better reply before 574 responding to its client, as long as it does not exceed a SOURCE 575 PREFIX-LENGTH specified in the query that triggered resolution, but 576 this obviously has implications for the latency of the overall 577 lookup. 579 The logic for using the cache to determine whether the Intermediate 580 Nameserver already knows the response to provide to its client is 581 covered in the next section. 583 7.3. Handling ECS Responses and Caching 585 When an Intermediate Nameserver receives a response containing an ECS 586 option and without the TC bit set, it SHOULD cache the result based 587 on the data in the option. If the TC bit was set, the Intermediate 588 Resolver SHOULD retry the query over TCP to get the complete answer 589 section for caching. 591 If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of 592 ADDRESS in the response don't match the non-zero fields in the 593 corresponding query, the full response MUST be dropped, as described 594 in Section 11. In a response to a query which specified only the 595 SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS 596 fields MUST contain the appropriate non-zero information that the 597 Authoritative Nameserver used to generate the answer, so that it can 598 be cached accordingly. 600 If no ECS option is contained in the response, the Intermediate 601 Nameserver SHOULD treat this as being equivalent to having received a 602 SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client 603 addresses. See further discussion on the security implications of 604 this in Section 11. 606 If a REFUSED response is received from an Authoritative Nameserver, 607 an ECS-aware resolver MUST retry the query without ECS to distinguish 608 the response from one where the Authoritative Nameserver is not 609 responsible for the name, which is a common convention for the 610 REFUSED status. Similarly, a client of a Recursive Resolver SHOULD 611 retry for REFUSED because it is not sufficiently clear whether the 612 REFUSED was because of the ECS option or some other reason. 614 7.3.1. Caching the Response 616 In the cache, all resource records in the answer section MUST be tied 617 to the network specified in the response. The appropriate prefix 618 length depends on the relationship between SOURCE PREFIX-LENGTH, 619 SCOPE PREFIX-LENGTH, and the maximum cacheable prefix length 620 configured for the cache. 622 If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH store 623 SCOPE PREFIX-LENGTH bits of ADDRESS and mark the response as valid 624 for all addresses that fall within that range. 626 Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for the 627 cache, store SOURCE PREFIX-LENGTH bits of ADDRESS and mark the 628 response as valid for all addresses that fall within that range. 630 If SOURCE PREFIX-LENGTH is shorter than the configured maximum and 631 SCOPE PREFiX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE 632 PREFIX-LENGTH bits of ADDRESS and mark the response as only valid to 633 answer client queries that specify exactly the same SOURCE PREFIX- 634 LENGTH in their own ECS option. 636 The handling of DNSSEC-related records in the answer section was 637 unspecified in the original draft and inconsistently handled in 638 existing implementations. An RRSIG must obviously be tied to the 639 RRset which it signs, but it is RECOMMENDED that all other DNSSEC 640 records be scoped at /0. See Section 9 for more. 642 Note that the additional and authority sections from a DNS response 643 message are specifically excluded here. Any records from these 644 sections MUST NOT be tied to a network. See more at Section 7.4. 646 Records that are cached as /0 because of a query's SOURCE PREFIX- 647 LENGTH of 0 MUST be distinguished from those that are cached as /0 648 because of a response's SCOPE PREFIX-LENGTH of 0. The former should 649 only be used for other /0 queries that the Intermediate Resolver 650 receives, but the latter is suitable as a response for all networks. 652 Although omitting network-specific caching will significantly 653 simplify an implementation, the resulting drop in cache hits is very 654 likely to defeat most latency benefits provided by ECS. Therefore, 655 implementing full caching support as described in this section is 656 strongly RECOMMENDED. 658 Enabling support for ECS in an Intermediate Nameserver will 659 significantly increase the size of the cache, reduce the number of 660 results that can be served from cache, and increase the load on the 661 server. Implementing the mitigation techniques described in 662 Section 11 is strongly recommended. For cache size issues, 663 implementers should consider data storage formats that allow the same 664 answer data to be shared among multiple prefixes. 666 7.3.2. Answering from Cache 668 Cache lookups are first done as usual for a DNS query, using the 669 query tuple of . Then the appropriate RRset MUST 670 be chosen based on longest prefix matching. The client address to 671 use for comparison will depend on whether the Intermediate Nameserver 672 received an ECS option in its client query. 674 o If no ECS option was provided, the client's address is used. 676 o If there was an ECS option specifying SOURCE PREFIX-LENGTH and 677 ADDRESS covering the client's address, the client address is used 678 but SOURCE PREFIX-LENGTH is initially ignored. If no covering 679 entry is found and SOURCE PREFIX-LENGTH is shorter than the 680 configured maximum length allowed for the cache, repeat the cache 681 lookup for an entry that exactly matches SOURCE PREFIX-LENGTH. 682 These special entries, which do not cover longer prefix lengths, 683 occur as described in the previous section. 685 o If there was an ECS option with an ADDRESS, the ADDRESS from it 686 MAY be used if local policy allows. Policy can vary depending on 687 the agreements the operator of the Intermediate Nameserver has 688 with Authoritative Nameserver operators; see Section 12.2. If 689 policy does not allow, a REFUSED response SHOULD be sent. See 690 Section 7.5 for more. 692 If a matching network is found and the relevant data is unexpired, 693 the response is generated as per Section 7.2. 695 If no matching network is found, the Intermediate Nameserver MUST 696 perform resolution as usual. This is necessary to avoid Tailored 697 Responses in the cache from being returned to the wrong clients, and 698 to avoid a single query coming from a client on a different network 699 from polluting the cache with a Tailored Response for all the users 700 of that resolver. 702 7.4. Delegations and Negative Answers 704 The prohibition against tying ECS data to records from the Authority 705 and Additional section left an unfortunate ambiguity in the original 706 specification, primarily with regard to negative answers. The 707 expectation of the original authors was that ECS would only really be 708 used for address requests and the positive result in the response's 709 answer section, the use case that was driving the definition of the 710 protocol. 712 For negative answers, some independent implementations of both 713 resolvers and authorities did not see the section restriction as 714 necessarily meaning that a given name and type must only have either 715 positive ECS-tagged answers or a negative answer. They support being 716 able to tell one part of the network that the data does not exist, 717 while telling another part of the network that it does. 719 Several other implementations, however, do not support being able to 720 mix positive and negative answers, and thus interoperability is a 721 problem. It is RECOMMENDED that no specific behavior regarding 722 negative answers be relied upon, but that Authoritative Nameservers 723 should conservatively expect that Intermediate Nameservers will treat 724 all negative answers as /0 and therefore SHOULD set SCOPE PREFIX- 725 LENGTH accordingly. 727 This issue is expected to be revisited in a future revision of the 728 protocol, possibly blessing the mixing of positive and negative 729 answers. There are implications for cache data structures that 730 developers should consider when writing new ECS code. 732 The delegations case is a bit easier to tease out. In operational 733 practice, if an authoritative server is using address information to 734 provide customized delegations, it is the resolver that will be using 735 the answer for its next iterative query. Addresses in the Additional 736 section SHOULD therefore ignore ECS data, and the Authoritative 737 Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations. 738 A recursive resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a 739 delegation as though it were zero. 741 7.5. Transitivity 743 Generally, ECS options will only be present in DNS messages between a 744 Recursive Resolver and an Authoritative Nameserver, i.e., one hop. 745 In certain configurations however, for example multi-tier nameserver 746 setups, it may be necessary to implement transitive behavior on 747 Intermediate Nameservers. 749 Any Intermediate Nameserver that forwards ECS options received from 750 its clients MUST fully implement the caching behavior described in 751 Section 7.3. 753 An Intermediate Nameserver MAY forward ECS options with address 754 information. This information MAY match the source IP address of the 755 incoming query, and MAY have more or fewer address bits than the 756 Nameserver would normally include in a locally originated ECS option. 758 If an Intermediate Nameserver receives a query with SOURCE PREFIX- 759 LENGTH set to 0 it MUST NOT include client address information in 760 queries made to resolve that client's request (see Section 7.1.2). 762 If for any reason the Intermediate Nameserver does not want to use 763 the information in an ECS option it receives (too little address 764 information, network address from a range not authorized to use the 765 server, private/unroutable address space, etc), it SHOULD drop the 766 query and return a REFUSED response. Note again that a query MUST 767 NOT be refused solely because it provides 0 address bits. 769 Be aware that at least one major existing implementation does not 770 return REFUSED and instead just processes the query as though the 771 problematic information were not present. This can lead to anomalous 772 situations, such as a response from the Intermediate Nameserver that 773 indicates it is tailored for one network (the one passed in the 774 original query, since ADDRESS must match) when actually it is for 775 another network (the one which contains the address that the 776 Intermediate Nameserver saw as making the query). 778 8. IANA Considerations 780 IANA has already assigned option code 8 in the "DNS EDNS0 Option 781 Codes (OPT)" registry to ECS. 783 The IANA is requested to update the reference ("draft-vandergaast- 784 edns-client-subnet") to refer to this RFC when published. 786 9. DNSSEC Considerations 788 The presence or absence of an [RFC6891] EDNS0 OPT resource record 789 containing an ECS option in a DNS query does not change the usage of 790 the resource records and mechanisms used to provide data origin 791 authentication and data integrity to the DNS, as described in 792 [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. 794 Use of this option, however, does imply increased DNS traffic between 795 any given Recursive Resolver and Authoritative Nameserver, which 796 could be another barrier to further DNSSEC adoption in this area. 798 The initial draft of this protocol, against which several 799 authoritative and recursive nameserver implementations were written, 800 did not discuss the handling of DNSSEC RRs and thus it is expected 801 that there are operational inconsistencies in handling them. 803 Given the intention of this document to describe how ECS is currently 804 deployed, specifying new requirements for DNSSEC handling is out of 805 scope. However, some recommendations can be made as to what is most 806 likely to result in successful interopration for a DNSSEC-signed ECS 807 zone, mainly from the point of view of Authoritative Nameservers. 809 Most DNSSEC records SHOULD be scoped at /0, except for the RRSIG 810 records which MUST be tied to the RRset that they sign in a Tailored 811 Response. While it is possible to conceive of a way to get other 812 DNSSEC records working in a network-specific way, it has little 813 apparent benefit or likelihood of working with deployed validating 814 resolvers. 816 One further implication here is that, despite the discussion about 817 negative answers in Section 7.4, scoping NSEC or NSEC3 records at /0 818 per the previous paragraph necessarily implies that DNSSEC-signed 819 negative answers must also be network-invariant. 821 10. NAT Considerations 823 Special awareness of ECS in devices that perform Network Address 824 Translation (NAT) as described in [RFC2663] is not required; queries 825 can be passed through as-is. The client's network address SHOULD NOT 826 be added, and existing ECS options, if present, SHOULD NOT be 827 modified by NAT devices. 829 In large-scale global networks behind a NAT device (but for example 830 with Centralized Resolver infrastructure), an internal Intermediate 831 Nameserver might have detailed network layout information, and may 832 know which external subnets are used for egress traffic by each 833 internal network. In such cases, the Intermediate Nameserver MAY use 834 that information when originating ECS options. 836 In other cases, if a Recursive Resolver knows it is sited behind a 837 NAT device, it SHOULD NOT originate ECS options with their external 838 IP address, and instead rely on downstream Intermediate Nameservers 839 to do so. It MAY, however, choose to include the option with their 840 internal address for the purposes of signaling its own limit for 841 SOURCE PREFIX-LENGTH. 843 Full treatment of special network addresses is beyond the scope of 844 this document; handling them will likely differ according to the 845 operational environments of each service provider. As a general 846 guideline, if an Authoritative Nameserver on the publicly routed 847 Internet receives a query that specifies an ADDRESS in [RFC1918] or 848 [RFC4193] private address space, it SHOULD ignore ADDRESS and look up 849 its answer based on the address of the Recursive Resolver. In the 850 response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the 851 relevant private space. For example, a query for ADDRESS 10.1.2.0 852 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX- 853 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the 854 answer under one entry for special-purpose addresses [RFC6890]; see 855 Section 11.3. 857 11. Security Considerations 859 11.1. Privacy 861 With the ECS option, the network address of the client that initiated 862 the resolution becomes visible to all servers involved in the 863 resolution process. Additionally, it will be visible from any 864 network traversed by the DNS packets. 866 To protect users' privacy, Recursive Resolvers are strongly 867 encouraged to conceal part of the IP address of the user by 868 truncating IPv4 addresses to 24 bits. 56 bits are recommended for 869 IPv6, based on [RFC6177]. 871 ISPs should have more detailed knowledge of their own networks. That 872 is, they might know that all 24-bit prefixes in a /20 are in the same 873 area. In those cases, for optimal cache utilization and improved 874 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 875 this /20 to just 20 bits, instead of 24 as recommended above. 877 Users who wish their full IP address to be hidden need to configure 878 their client software, if possible, to include an ECS option 879 specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). 880 As described in previous sections, this option will be forwarded 881 across all the Recursive Resolvers supporting ECS, which MUST NOT 882 modify it to include the network address of the client. 884 Note that even without an ECS option, any server queried directly by 885 the user will be able to see the full client IP address. Recursive 886 Resolvers or Authoritative Nameservers MAY use the source IP address 887 of queries to return a cached entry or to generate a Tailored 888 Response that best matches the query. 890 11.2. Birthday Attacks 892 ECS adds information to the DNS query tupe (q-tuple). This allows an 893 attacker to send a caching Intermediate Nameserver multiple queries 894 with spoofed IP addresses either in the ECS option or as the source 895 IP. These queries will trigger multiple outgoing queries with the 896 same name, type and class, just different address information in the 897 ECS option. 899 With multiple queries for the same name in flight, the attacker has a 900 higher chance of success to send a matching response with the SCOPE 901 PREFIX-LENGTH set to 0 to get it cached for all hosts. 903 To counter this, the ECS option in a response packet MUST contain the 904 full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the 905 corresponding query. Intermediate Nameservers processing a response 906 MUST verify that these match, and SHOULD discard the entire response 907 if they do not. 909 That requirement to discard is "SHOULD" instead of "MUST" because it 910 stands in opposition to the instruction in Section 7.3 which states 911 that a response lacking an ECS option should be treated as though it 912 had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an 913 attacker does not need to worry about matching the original ECS 914 option data and just needs to flood back responses that have no ECS 915 option at all. 917 This type of attack could be detected in ongoing operations by 918 marking whether the responding nameserver had previously been sending 919 ECS option, and/or by taking note of an incoming flood of bogus 920 responses and flagging the relevant query for re-resolution. This is 921 more complex than existing nameserver responses to spoof floods, and 922 would also need to be sensitive to a nameserver legitimately stopping 923 ECS replies even though it had previously given them. 925 11.3. Cache Pollution 927 It is simple for an arbitrary resolver or client to provide false 928 information in the ECS option, or to send UDP packets with forged 929 source IP addresses. 931 This could be used to: 933 o pollute the cache of intermediate resolvers, by filling it with 934 results that will rarely (if ever) be used. 936 o reverse engineer the algorithms (or data) used by the 937 Authoritative Nameserver to calculate Tailored Responses. 939 o mount a denial-of-service attack against an Intermediate 940 Nameserver, by forcing it to perform many more recursive queries 941 than it would normally do, due to how caching is handled for 942 queries containing the ECS option. 944 Even without malicious intent, Centralized Resolvers providing 945 answers to clients in multiple networks will need to cache different 946 responses for different networks, putting more memory pressure on the 947 cache. 949 To mitigate those problems: 951 o Recursive Resolvers implementing ECS should only enable it in 952 deployments where it is expected to bring clear advantages to the 953 end users, such as when expecting clients from a variety of 954 networks or from a wide geographical area. Due to the high cache 955 pressure introduced by ECS, the feature SHOULD be disabled in all 956 default configurations. 958 o Recursive Resolvers SHOULD limit the number of networks and 959 answers they keep in the cache for any given query. 961 o Recursive Resolvers SHOULD limit the number of total different 962 networks that they keep in cache. 964 o Recursive Resolvers MUST NOT send an ECS option with a SOURCE 965 PREFIX-LENGTH providing more bits in the ADDRESS than they are 966 willing to cache responses for. 968 o Recursive Resolvers should implement algorithms to improve the 969 cache hit rate, given the size constraints indicated above. 970 Recursive Resolvers MAY, for example, decide to discard more 971 specific cache entries first. 973 o Authoritative Nameservers and Recursive Resolvers should discard 974 ECS options that are either obviously forged or otherwise known to 975 be wrong. They SHOULD at least treat unroutable addresses, such 976 as some of the address blocks defined in [RFC6890], as equivalent 977 to the Recursive Resolver's own identity. They SHOULD ignore and 978 never forward ECS options specifying other routable addresses that 979 are known not to be served by the query source. 981 o The ECS option is just a hint to Authoritative Nameservers for 982 customizing results. They can decide to ignore the content of the 983 ECS option based on black or white lists, rate limiting 984 mechanisms, or any other logic implemented in the software. 986 12. Sending the Option 988 When implementing a Recursive Resolver, there are two strategies on 989 deciding when to include an ECS option in a query. At this stage, 990 it's not clear which strategy is best. 992 12.1. Probing 994 A Recursive Resolver can send the ECS option with every outgoing 995 query. However, it is RECOMMENDED that Resolvers remember which 996 Authoritative Nameservers did not return the option with their 997 response, and omit client address information from subsequent queries 998 to those Nameservers. 1000 Additionally, Recursive Resolvers SHOULD be configured to never send 1001 the option when querying root, top-level, and effective top-level 1002 (ie, ("public suffix") [Public_Suffix_List] domain servers. These 1003 domains are delegation-centric and are very unlikely to generate 1004 different responses based on the address of the client. 1006 When probing, it is important that several things are probed: support 1007 for ECS, support for EDNS0, support for EDNS0 options, or possibly an 1008 unreachable Nameserver. Various implementations are known to drop 1009 DNS packets with OPT RRs (with or without options), thus several 1010 probes are required to discover what is supported. 1012 Probing, if implemented, MUST be repeated periodically, e.g., daily. 1013 If an Authoritative Nameserver indicates ECS support for one zone, it 1014 is to be expected that the Nameserver supports ECS for all of its 1015 zones. Likewise, an Authoritative Nameserver that uses ECS 1016 information for one of its zones, MUST indicate support for the 1017 option in all of its responses to ECS queries. If the option is 1018 supported but not actually used for generating a response, its SCOPE 1019 PREFIX-LENGTH MUST be set to 0. 1021 12.2. Whitelist 1023 As described previously, it is expected that only a few Recursive 1024 Resolvers will need to use ECS, and that it will generally be enabled 1025 only if it offers a clear benefit to the users. 1027 To avoid the complexity of implementing a probing and detection 1028 mechanism (and the possible query loss/delay that may come with it), 1029 an implementation could use a whitelist of Authoritative Nameservers 1030 to send the option to, likely specified by their domain name. 1031 Implementations MAY also allow additionally configuring this based on 1032 other criteria, such as zone or query type. As of the time of this 1033 writing, at least one implementation makes use of a whitelist. 1035 An advantage of using a whitelist is that partial client address 1036 information is only disclosed to Nameservers that are known to use 1037 the information, improving privacy. 1039 A drawback is scalability. The operator needs to track which 1040 Authoritative Nameservers support ECS, making it harder for new 1041 Authoritative Nameservers to start using the option. 1043 Similarly, Authoritative Nameservers can also use whitelists to limit 1044 the feature to only certain clients. For example, a CDN that does 1045 not want all of their mapping trivially walked might require a legal 1046 agreement with the Recursive Resolver operator, to clearly describe 1047 the acceptable use of the feature. 1049 The maintenance of access control mechanisms is out of scope for this 1050 protocol definition. 1052 13. Example 1054 1. A stub resolver, SR, with IP address 1055 2001:0db8:fd13:4231:2112:8a2e:c37b:7334 tries to resolve 1056 www.example.com by forwarding the query to the Recursive 1057 Resolver, RNS, asking for recursion. 1059 2. RNS, supporting ECS, looks up www.example.com in its cache. An 1060 entry is found neither for www.example.com, nor for example.com. 1062 3. RNS builds a query to send to the root and .com servers. The 1063 implementation of RNS provides facilities so an administrator 1064 can configure it not to forward ECS in certain cases. In 1065 particular, RNS is configured to not include an ECS option when 1066 talking to TLD or root nameservers, as described in Section 7.1. 1067 Thus, no ECS option is added, and resolution is performed as 1068 usual. 1070 4. RNS now knows the next server to query: the Authoritative 1071 Nameserver, ANS, responsible for example.com. 1073 5. RNS prepares a new query for www.example.com, including an ECS 1074 option with: 1076 * OPTION-CODE set to 8. 1078 * OPTION-LENGTH set to 0x00 0x0b for the following fixed 4 1079 octets plus the 7 octets that will be used for ADDRESS. 1081 * FAMILY set to 0x00 0x02 as IP is an IPv6 address. 1083 * SOURCE PREFIX-LENGTH set to 0x38, as RNS is configured to 1084 conceal the last 72 bits of every IPv6 address. 1086 * SCOPE PREFIX-LENGTH set to 0x00, as specified by this 1087 document for all queries. 1089 * ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, providing 1090 only the first 56 bits of the IPv6 address. 1092 6. The query is sent. ANS understands and uses ECS. It parses the 1093 ECS option, and generates a Tailored Response. 1095 7. Due its internal implementation, ANS finds a response that is 1096 tailored for the whole /16 of the client that performed the 1097 query. 1099 8. ANS adds an ECS option in the response, containing: 1101 * OPTION-CODE set to 8. 1103 * OPTION-LENGTH set to 0x00 0x07. 1105 * FAMILY set to 0x00 0x02. 1107 * SOURCE PREFIX-LENGTH set to 0x38, copied from the query. 1109 * SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network. 1111 * ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, copied 1112 from the query. 1114 9. RNS receives the response containing an ECS option. It verifies 1115 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. 1116 If not, the message is discarded. 1118 10. The response is interpreted as usual. Since the response 1119 contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and 1120 FAMILY in the response are used to cache the entry. 1122 11. RNS sends a response to stub resolver SR, without including an 1123 ECS option. 1125 12. RNS receives another query to resolve www.example.com. This 1126 time, a response is cached. The response, however, is tied to a 1127 particular network. If the address of the client matches any 1128 network in the cache, then the response is returned from the 1129 cache. Otherwise, another query is performed. If multiple 1130 results match, the one with the longest SCOPE PREFIX-LENGTH is 1131 chosen, as per common best-network match algorithms. 1133 14. Contributing Authors 1135 The below individuals contributed significantly to the document. The 1136 RFC Editor prefers a maximum of 5 names on the front page, and so we 1137 have listed additional authors in this section 1138 Edward Lewis 1139 ICANN 1140 12025 Waterfront Drive, Suite 300 1141 Los Angeles CA 90094-2536 1142 USA 1143 Email: edward.lewis@icann.org 1145 Sean Leach 1146 Fastly 1147 POBox 78266 1148 San Francisco CA 94107 1150 Jason Moreau 1151 Akamai Technologies 1152 8 Cambridge Ctr 1153 Cambridge MA 02142-1413 1154 USA 1156 15. Acknowledgements 1158 The authors wish to thank Darryl Rodden for his work as a co-author 1159 on previous versions, and the following people for reviewing early 1160 drafts of this document and for providing useful feedback: Paul S. 1161 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 1162 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 1163 Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, 1164 Edward Lewis, and Eric Burger from Neustar; David Ulevitch and 1165 Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from 1166 Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya 1167 Jinmei from Infoblox; Andrew Sullivan from Dyn; John Dickinson from 1168 Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs; 1169 Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn 1170 Gillmor from the ACLU; Evan Hunt and Mukund Sivaraman from the 1171 Internet Software Consortium; Russ Housley from Vigilsec; Stephen 1172 Farrell from Trinity College Dublin; Alissa Cooper from Cisco; 1173 Suzanne Woolf; and all of the other people that replied to our emails 1174 on various mailing lists. 1176 16. References 1178 16.1. Normative References 1180 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1181 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1182 . 1184 [RFC1035] Mockapetris, P., "Domain names - implementation and 1185 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1186 November 1987, . 1188 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1189 DOI 10.17487/RFC1700, October 1994, 1190 . 1192 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1193 and E. Lear, "Address Allocation for Private Internets", 1194 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1195 . 1197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1198 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1199 RFC2119, March 1997, 1200 . 1202 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1203 Rose, "DNS Security Introduction and Requirements", RFC 1204 4033, DOI 10.17487/RFC4033, March 2005, 1205 . 1207 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1208 Rose, "Resource Records for the DNS Security Extensions", 1209 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1210 . 1212 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1213 Rose, "Protocol Modifications for the DNS Security 1214 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1215 . 1217 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1218 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1219 . 1221 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1222 Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/ 1223 RFC6177, March 2011, 1224 . 1226 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1227 "Special-Purpose IP Address Registries", BCP 153, RFC 1228 6890, DOI 10.17487/RFC6890, April 2013, 1229 . 1231 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1232 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 1233 RFC6891, April 2013, 1234 . 1236 16.2. Informative References 1238 [Address_Family_Numbers] 1239 "Address Family Numbers", 1240 . 1243 [DPRIVE_Working_Group] 1244 "DPRIVE Working Group", 1245 . 1247 [I-D.hardie-privsec-metadata-insertion] 1248 Hardie, T., "Design considerations for Metadata 1249 Insertion", draft-hardie-privsec-metadata-insertion-02 1250 (work in progress), March 2016. 1252 [I-D.vandergaast-edns-client-subnet] 1253 Contavalli, C., Gaast, W., Leach, S., and E. Lewis, 1254 "Client Subnet in DNS Requests", draft-vandergaast-edns- 1255 client-subnet-02 (work in progress), July 2013. 1257 [Public_Suffix_List] 1258 "Public Suffix List", . 1260 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1261 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1262 . 1264 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1265 Translator (NAT) Terminology and Considerations", RFC 1266 2663, DOI 10.17487/RFC2663, August 1999, 1267 . 1269 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1270 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1271 2015, . 1273 Appendix A. Document History 1275 [RFC Editor: Please delete this section before publication.] 1277 -07 to -08: 1279 o Jinmei observed that one section saying a /0 "MUST forward the 1280 query as-is" was in conflict with the section that said the option 1281 could be modified to contain the Recursive Resolver address. 1283 o Clarify that existing implementations don't interoperate w.r.t 1284 DNSSEC. 1286 o Removed vestiges of able to set FAMILY to 0 when specifying just a 1287 SOURCE PREFIX-LENGTH and no ADDRESS. Doesn't interoperate. 1289 o Minor wording change in reference to DNS terminology draft. 1291 o Change example to use IPv6 per Fred Baker's request. 1293 -06 to -07: 1295 o Minor comments from Suzanne, Mukund, Jinmei and from the IESG on 1296 the dnsop list. 1298 o Incorporated feedback from conference call with Mukund and Evan, 1299 notably clarifying what prefix length to associate with answers in 1300 the cache, how and why to deaggregate, and some DNSSEC stuff. 1302 -05 to -06: 1304 o Integrated David Lawrence comments. 1306 o Ran spellcheck again. One ady I';; laern to tyoe/ 1308 -04 to -05: 1310 o Moved comment about retrying for REFUSED to section on "Handling 1311 ECS Responses". (Jinmei) 1313 o Clarify that a new proposal for an improved ECS protool is 1314 expected. 1316 o "Forwarders" had been used as though they were the source of a 1317 forwarded query rather than the targeted of one; clarified and 1318 defined as "Forwarding Resolver". (Jinmei) 1320 o "representing the leftmost significant bits" => "representing the 1321 leftmost number of significant bits". (Jinmei) 1323 o Minor other clarifying text. (Jinmei) 1325 o Jinmei's affiliation. 1327 o Minor wording clarifications. (David Kahn Gillmor) 1329 o Russ Housely's GenART review. 1331 -03 to -04: 1333 o Privacy note per Ted Hardie's suggestion. 1335 o MUST use minimum octet length to cover PREFIX bits. 1337 o Expose note about documenting deployed, if flawed, protocol. 1339 -02 to -03: 1341 o Some cleanup of the whitelist text. 1343 -01 to -02 (IETF) 1345 o Clean up the open issues, mostly by saying that they were out of 1346 scope for this document. 1348 o How in the world did no reviewers note that "Queries" had been 1349 spelled as "Querys" in the title? (Aaron Falk did.) 1351 -00 to -01 (IETF) 1353 o Note ambiguity with multiple RRsets appearing in reply, eg, for an 1354 ANY query or CNAME chain. (Duane Wessels) 1356 o Open issue questioning the guidance about resolvers behind a NAT. 1357 How do they know they are? What real requirement is this 1358 imposing? (Duane Wessels) 1360 o Some other wording changes based on Duane's review of an earlier 1361 draft. 1363 -IND to -00 (IETF) 1365 o Made the document describe how things are actually 1366 implmented now. This makes the document be more of a "this is how 1367 we are doing things, this provides information on that". There 1368 may be a future document that describes additional funcationality. 1370 o NETMASK was not a good desription, changed to PREFIX-LENGTH 1371 (Jinmei, others). Stole most of the definition for prefix length 1372 from RFC4291. 1374 o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include 1375 IPv6 (Tatuya Jinmei) 1377 o Comment that ECS cannot be used to hand NXDOMAIN to some clients 1378 and not others, primarily because of interoperability issues. 1379 (Tatuya Jinmei) 1381 o Added text explaining that implmentations need to document thier 1382 behavior with overlapping networks. 1384 o Soften "optimized reply" language. (Andrew Sullivan). 1386 o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0) 1388 o Some more grammar / working cleanups. 1390 o Replaced a whole heap of occurances of "edns-client-subnet" with 1391 "ECS" for readability. (John Dickinson) 1393 o More clearly describe the process from the point of view of each 1394 type of nameserver. (John Dickinson) 1396 o Birthday attack still possible if attacker floods with ECS-less 1397 responses. (Yuri Schaeffer) 1399 o Added some open issues directly to the text. 1401 A.1. -00 1403 o Document moved to experimental track, added experiment description 1404 in header with details in a new section. 1406 o Specifically note that ECS applies to the answer section only. 1408 o Warn that caching based on ECS is optional but very important for 1409 performance reasons. 1411 o Updated NAT section. 1413 o Added recommendation to not use the default /24 recommendation for 1414 the source prefix-length field if more detailed information about 1415 the network is available. 1417 o Rewritten problem statement to be more clear about the goal of ECS 1418 and the fact that it's entirely optional. 1420 o Wire format changed to include the original address and prefix 1421 length in responses in defence against birthday attacks. 1423 o Security considerations now includes a section about birthday 1424 attacks. 1426 o Renamed edns-client-ip in ECS, following suggestions on the 1427 mailing list. 1429 o Clarified behavior of resolvers when presented with an invalid ECS 1430 option. 1432 o Fully take multi-tier DNS setups in mind and be more clear about 1433 where the option should be originated. 1435 o A note on Authoritative Nameservers receiving queries that specify 1436 private address space. 1438 o A note to always ask for the longest acceptable SOURCE prefix 1439 length, even if a prior answer indicated that a shorter prefix 1440 length was suitable. 1442 o Marked up a few more references. 1444 o Added a few definitions in the Terminology section, and a few more 1445 aesthetic changes in the rest of the document. 1447 A.2. -01 1449 o Document version number reset from -02 to -00 due to the rename of 1450 base document. 1452 o Clarified example (dealing with TLDs, and various minor errors). 1454 o Referencing RFC5035 instead of RFC1918. 1456 o Added a section on probing (and how it should be done) vs. 1457 whitelisting. 1459 o Moved description on how to forward ECS option in dedicated 1460 section. 1462 o Queries with wrongly formatted ECS options should now be rejected 1463 with FORMERR. 1465 o Added an "Overview" section, providing an introduction to the 1466 document. 1468 o Intermediate Nameservers can now remove an ECS option, or reduce 1469 the SOURCE PREFIX-LENGTH to increase privacy. 1471 o Added a reference to DoS attacks in the Security section. 1473 o Don't use "network range", as it seems to have different meaning 1474 in other contexts, and turned out to be confusing. 1476 o Use shorter and longer prefix lengths, rather than higher or 1477 lower. Add a better explanation in the format section. 1479 o Minor corrections in various other sections. 1481 A.3. -02 1483 o Added IANA-assigned option code. 1485 Authors' Addresses 1487 Carlo Contavalli 1488 Google 1489 1600 Amphitheater Parkway 1490 Mountain View, CA 94043 1491 US 1493 Email: ccontavalli@google.com 1495 Wilmer van der Gaast 1496 Google 1497 Belgrave House, 76 Buckingham Palace Road 1498 London SW1W 9TQ 1499 UK 1501 Email: wilmer@google.com 1503 David C Lawrence 1504 Akamai Technologies 1505 8 Cambridge Center 1506 Cambridge, MA 02142 1507 US 1509 Email: tale@akamai.com 1510 Warren Kumari 1511 Google 1512 1600 Amphitheatre Parkway 1513 Mountain View, CA 94043 1514 US 1516 Email: warren@kumari.net