idnits 2.17.00 (12 Aug 2021) /tmp/idnits39876/draft-ietf-dnsop-edns-client-subnet-06.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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2015) is 2349 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) == Outdated reference: draft-hardie-privsec-metadata-insertion has been published as RFC 8165 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: June 17, 2016 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 December 15, 2015 11 Client Subnet in DNS Queries 12 draft-ietf-dnsop-edns-client-subnet-06 14 Abstract 16 This document defines an EDNS0 extension to carry information about 17 the network that originated a DNS query, and the network for which 18 the subsequent response can be cached. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 17, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 57 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Originating the Option . . . . . . . . . . . . . . . . . 8 62 7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8 63 7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9 64 7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 9 65 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10 66 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10 67 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12 68 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 12 69 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 13 70 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 13 71 7.4. Delegations and Negative Answers . . . . . . . . . . . . 14 72 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 15 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 16 75 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17 78 11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 17 79 11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 18 80 12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 19 81 12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19 82 12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 20 83 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 85 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 86 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 16.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Appendix A. Document History . . . . . . . . . . . . . . . . . . 25 90 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 95 1. Introduction 97 Many Authoritative Nameservers today return different responses based 98 on the perceived topological location of the user. These servers use 99 the IP address of the incoming query to identify that location. 100 Since most queries come from intermediate Recursive Resolvers, the 101 source address is that of the Recursive Resolver rather than of the 102 query originator. 104 Traditionally, and probably still in the majority of instances, 105 Recursive Resolvers are reasonably close in the topological sense to 106 the Stub Resolvers or Forwarding Resolvers that are the source of 107 queries. For these resolvers, using their own IP address is 108 sufficient for authority servers that tailor responses based upon 109 location of the querier. 111 Increasingly, though, a class of Recursive Resolvers has arisen that 112 handle query sources that are often not topologically close. The 113 motivation for a user to configure such a Centralized Resolver varies 114 but is usually because of some enhanced experience, such as greater 115 cache security or applying policies regarding where users may 116 connect. (Although political censorship usually comes to mind here, 117 the same actions may be used by a parent when setting controls on 118 where a minor may connect.) Similarly, many ISPs and other 119 organizations use a Centralized Resolver infrastructure that can be 120 distant from the clients the resolvers serve. These cases all lead 121 to less than desirable responses from topology-sensitive 122 Authoritative Nameservers. 124 This document defines an EDNS0 [RFC6891] option to convey network 125 information that is relevant to the DNS message. It will carry 126 sufficient network information about the originator for the 127 Authoritative Nameserver to tailor responses. It will also provide 128 for the Authoritative Nameserver to indicate the scope of network 129 addresses for which the tailored answer is intended. This EDNS0 130 option is intended for those recursive and authority servers that 131 would benefit from the extension and not for general purpose 132 deployment. It is completely optional and can safely be ignored by 133 servers that choose not to implement it or enable it. 135 This document also includes guidelines on how to best cache those 136 results and provides recommendations on when this protocol extension 137 should be used. 139 At least a dozen different client and server implementations have 140 been written based on earlier versions of this specification. The 141 protocol is in active production use today. While the 142 implementations interoperate, there is varying behavior around edge 143 cases that were poorly specified. Known incompatibilities are 144 described in this document, and the authors believe that it is better 145 to describe the system as it is working today, even if not everyone 146 agrees with the details of the original specification ( 147 [I-D.vandergaast-edns-client-subnet]). The alternative is an 148 undocumented and proprietary system. 150 A revised proposal to improve upon the minor flaws in this protocol 151 will be forthcoming to the IETF. 153 2. Privacy Note 155 If we were just beginning to design this mechanism, and not 156 documenting existing protocol, it is unlikely that we would have done 157 things exactly this way. 159 The IETF is actively working on enhancing DNS privacy 160 [DPRIVE_Working_Group], and the re-injection of metadata has been 161 identified as a problematic design pattern 162 [I-D.hardie-privsec-metadata-insertion] 164 As noted above, however, this document primarily describes existing 165 behavior of a deployed method, to further the understanding of the 166 Internet community. 168 We encourage the deployment of means to allow users to make use of 169 the opt-out provided. We also recommend that others avoid techniques 170 that may introduce additional metadata in future work, as it may 171 damage user trust. 173 3. Requirements Notation 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 4. Terminology 181 ECS: EDNS Client Subnet. 183 Client: A Stub Resolver, Forwarding Resolver, or Recursive Resolver. 184 A client to a Recursive Resolver or a Forwarding Resolver. 186 Server: A Forwarding Resolver, Recursive Resolver or Authoritative 187 Nameserver. 189 Stub Resolver: A simple DNS protocol implementation on the client 190 side as described in [RFC1034] section 5.3.1. A client to a 191 Recursive Resolver or a Forwarding Resolver. 193 Authoritative Nameserver: A nameserver that has authority over one 194 or more DNS zones. These are normally not contacted by Stub 195 Resolver or end user clients directly but by Recursive Resolvers. 196 Described in [RFC1035] Section 6. 198 Recursive Resolver: A nameserver that is responsible for resolving 199 domain names for clients by following the domain's delegation 200 chain. Recursive Resolvers frequently use caches to be able to 201 respond to client queries quickly. Described in [RFC1035] 202 Section 7. 204 Forwarding Resolver: A nameserver that does not do iterative 205 resolution itself, but instead passes that responsibility to 206 another Recursive Resolver, called a "Forwarder" in [RFC2308] 207 section 1. 209 Intermediate Nameserver: Any nameserver in between the Stub Resolver 210 and the Authoritative Nameserver, such as a Recursive Resolver or 211 a Forwarding Resolver. 213 Centralized Resolvers: Intermediate Nameservers that serve a 214 topologically diverse network address space. 216 Tailored Response: A response from a nameserver that is customized 217 for the node that sent the query, often based on performance (i.e. 218 lowest latency, least number of hops, topological distance, ...). 220 Topologically Close: Refers to two hosts being close in terms of 221 number of hops or time it takes for a packet to travel from one 222 host to the other. The concept of topological distance is only 223 loosely related to the concept of geographical distance: two 224 geographically close hosts can still be very distant from a 225 topological perspective, and two geographically distant hosts can 226 be quite close on the network. 228 5. Overview 230 The general idea of this document is to provide an EDNS0 option to 231 allow Recursive Resolvers, if they are willing, to forward details 232 about the origin network from which a query is coming when talking to 233 other Nameservers. 235 The format of this option is described in Section 6, and is meant to 236 be added in queries sent by Intermediate Nameservers in a way 237 transparent to Stub Resolvers and end users, as described in 238 Section 7.1. ECS is only defined for the Internet (IN) DNS class. 240 As described in Section 7.2, an Authoritative Nameserver could use 241 this EDNS0 option as a hint to better locate the network of the end 242 user and provide a better answer. 244 Its response would contain an edns-client-subnet (ECS) option, 245 clearly indicating that the server made use of this information, and 246 that the answer is tied to the network of the client. 248 As described in Section 7.3, Intermediate Nameservers would use this 249 information to cache the response. 251 Some Intermediate Nameservers may also have to be able to forward ECS 252 queries they receive. This is described in Section 7.5. 254 The mechanisms provided by ECS raise various security related 255 concerns related to cache growth, the ability to spoof EDNS0 options, 256 and privacy. Section 11 explores various mitigation techniques. 258 The expectation, however, is that this option will primarily be used 259 between Recursive Resolvers and Authoritative Nameservers that are 260 sensitive to network location issues. Most Recursive Resolvers, 261 Authoritative Nameservers and Stub Resolvers will never need to know 262 about this option, and will continue working as they had been. 264 Failure to support this option or its improper handling will, at 265 worst, cause suboptimal identification of client location, which is a 266 common occurrence in current content delivery network (CDN) setups. 268 Section 7.1 also provides a mechanism for Stub Resolvers to signal 269 Recursive Resolvers that they do not want ECS treatment for specific 270 queries. 272 Additionally, operators of Intermediate Nameservers with ECS enabled 273 are allowed to choose how many bits of the address of received 274 queries to forward, or to reduce the number of bits forwarded for 275 queries already including an ECS option. 277 6. Option Format 279 This protocol uses an EDNS0 [RFC6891]) option to include client 280 address information in DNS messages. The option is structured as 281 follows: 283 +0 (MSB) +1 (LSB) 284 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 285 0: | OPTION-CODE | 286 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 287 2: | OPTION-LENGTH | 288 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 289 4: | FAMILY | 290 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 291 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 292 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 293 8: | ADDRESS... / 294 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 296 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 297 0x08). 299 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 300 length of the payload (everything after OPTION-LENGTH) in octets. 302 o FAMILY, 2 octets, indicates the family of the address contained in 303 the option, using address family codes as assigned by IANA in 304 Address Family Numbers [Address_Family_Numbers]. 306 The format of the address part depends on the value of FAMILY. This 307 document only defines the format for FAMILY 1 (IP version 4) and 2 308 (IP version 6), which are as follows: 310 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost 311 number of significant bits of ADDRESS to be used for the lookup. 312 In responses, it mirrors the same value as in the queries. 314 o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost 315 number of significant bits of ADDRESS that the response covers. 316 In queries, it MUST be set to 0. 318 o ADDRESS, variable number of octets, contains either an IPv4 or 319 IPv6 address, depending on FAMILY, which MUST be truncated to the 320 number of bits indicated by the SOURCE PREFIX-LENGTH field, 321 padding with 0 bits to pad to the end of the last octet needed. 323 o A server receiving an ECS option that uses more ADDRESS octets 324 than are needed, or that has non-zero bits set beyond SOURCE 325 PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a 326 signal to the developer of the software making the request to fix 327 their implementation. 329 All fields are in network byte order ("big-endian", per [RFC1700], 330 Data Notation). 332 7. Protocol Description 334 7.1. Originating the Option 336 The ECS option should generally be added by Recursive Resolvers when 337 querying Authoritative Nameservers, as described in Section 12. The 338 option can also be initialized by a Stub Resolver or Forwarding 339 Resolver. 341 7.1.1. Recursive Resolvers 343 The setup of the ECS option in a Recursive Resolver depends on the 344 client query that triggered the resolution process. 346 In the usual case, where no ECS option was present in the client 347 query, the Recursive Resolver initializes the option by setting the 348 FAMILY of the client's address. It then uses the value of its 349 maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For 350 privacy reasons, and because the whole IP address is rarely required 351 to determine a tailored response, this length SHOULD be shorter than 352 the full address, as described in Section 11. 354 If the triggering query included an ECS option itself, it MUST be 355 examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's 356 outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of 357 the incoming query's SOURCE PREFIX-LENGTH or the server's maximum 358 cacheable prefix length. 360 Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the 361 ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits, 362 with trailing 0 bits added, if needed, to fill the final octet. The 363 total number of octets used MUST only be enough to cover SOURCE 364 PREFIX-LENGTH bits, rather than the full width that would normally be 365 used by addresses in FAMILY. 367 FAMILY and ADDRESS information MAY be used from the ECS option in the 368 incoming query. Passing the existing address data is supportive of 369 the Recursive Resolver being used as the target of a Forwarding 370 Resolver, but could possibly run into policy problems with regard to 371 usage agreements between the Recursive Resolver and Authoritative 372 Nameserver. See Section 12.2 for more discussion on this point. If 373 the Recursive Resolver will not forward the FAMILY and ADDRESS data 374 from the incoming ECS option, it SHOULD return a REFUSED response. 376 Subsequent queries to refresh the data MUST, if unrestricted by an 377 incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- 378 LENGTH that the Recursive Resolver is willing to cache, even if a 379 previous response indicated that a shorter prefix length was 380 sufficient. 382 7.1.2. Stub Resolvers 384 A Stub Resolver MAY generate DNS queries with an ECS option set to 385 indicate its own level of privacy via SOURCE PREFIX-LENGTH. An 386 Intermediate Nameserver that receives such a query MUST NOT make 387 queries that include more bits of client address than in the 388 originating query. 390 A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add 391 address information of the client to its queries. The subsequent 392 Recursive Resolver query to the Authoritative Nameserver will then 393 either not include an ECS option or MAY optionally include its own 394 address information, which is what the Authoritative Nameserver will 395 almost certainly use to generate any Tailored Response in lieu of an 396 option. This allows the answer to be handled by the same caching 397 mechanism as other queries, with an explicit indicator of the 398 applicable scope. Subsequent Stub Resolver queries for /0 can then 399 be answered from this cached response. 401 A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include 402 FAMILY and ADDRESS data, but should be prepared to handle a REFUSED 403 response if the Intermediate Nameserver that it queries has a policy 404 that denies forwarding of the ADDRESS. If there is no ADDRESS set, 405 i.e. SOURCE PREFIX-LENGTH is set to 0, FAMILY MUST be set to 0. 407 7.1.3. Forwarding Resolvers 409 Forwarding Resolvers essentially appear to be Stub Resolvers to 410 whatever Recursive Resolver is ultimately handling the query, but 411 look like a Recursive Resolver to their client. A Forwarding 412 Resolver using this option MUST prepare it as described in the 413 Section 7.1.1 section above. In particular, a Forwarding Resolver 414 that implements this protocol MUST honor SOURCE PREFIX-LENGTH 415 restrictions indicated in the incoming query from its client. See 416 also Section 7.5. 418 Since the Recursive Resolver it contacts will treat it like a Stub 419 Resolver, the Recursive Resolver's policies regarding incoming 420 ADDRESS information will apply in the same way. If the Forwarding 421 Resolver receives a REFUSED response when it sends a query which 422 includes a non-zero ADDRESS, it MUST retry with FAMILY and ADDRESS 423 set to 0. 425 7.2. Generating a Response 427 7.2.1. Authoritative Nameserver 429 When a query containing an ECS option is received, an Authoritative 430 Nameserver supporting ECS MAY use the address information specified 431 in the option in order to generate a tailored response. 433 Authoritative Nameservers that have not implemented or enabled 434 support for the ECS option ought to safely ignore it within incoming 435 queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include 436 an ECS option within replies, to indicate lack of support for it. 437 Implementers of Intermediate Nameservers should be aware, however, 438 that some nameservers incorrectly echo back unknown EDNS0 options. 439 In this protocol that should be mostly harmless, as SCOPE PREFIX- 440 LENGTH should come back as 0, thus marking the response as covering 441 all networks. 443 A query with a wrongly formatted option (e.g., an unknown FAMILY) 444 MUST be rejected and a FORMERR response MUST be returned to the 445 sender, as described by [RFC6891], Transport Considerations. 447 An Authoritative Nameserver that implements this protocol and 448 receives an ECS option MUST include an ECS option in its response to 449 indicate that it SHOULD be cached accordingly, regardless of whether 450 the client information was needed to formulate an answer. (Note that 451 the [RFC6891] requirement to reserve space for the OPT record could 452 mean that the answer section of the response will be truncated and 453 fallback to TCP indicated accordingly.) If an ECS option was not 454 included in a query, one MUST NOT be included in the response even if 455 the server is providing a Tailored Response -- presumably based on 456 the address from which it received the query. 458 The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST 459 match those in the query, unless the query specified only the SOURCE 460 PREFIX-LENGTH for privacy (with FAMILY and ADDRESS set to 0). 461 Echoing back these values helps to mitigate certain attack vectors, 462 as described in Section 11. 464 The SCOPE PREFIX-LENGTH in the response indicates the network for 465 which the answer is intended. 467 A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH 468 indicates that the provided prefix length was not specific enough to 469 select the most appropriate Tailored Response. Future queries for 470 the name within the specified network SHOULD use the longer SCOPE 471 PREFIX-LENGTH. 473 Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits 474 than necessary were provided, and the answer is suitable for a 475 broader range of addresses. This could be as short as 0, to indicate 476 that the answer is suitable for all addresses in FAMILY. 478 As the logical topology of any part of the network with regard to the 479 tailored response can vary, an Authoritative Nameserver may return 480 different values of SCOPE PREFIX-LENGTH for different networks. 482 Since some queries can result in multiple RRsets being added to the 483 response, there is an unfortunate ambiguity from the original 484 specification as to how SCOPE PREFIX-LENGTH would apply to each 485 individual RRset. For example, multiple types in response to an ANY 486 metaquery could all have different applicable SCOPE PREFIX-LENGTH 487 values, but this protocol only has the ability to signal one. The 488 response SHOULD therefore include the longest relevant PREFIX-LENGTH 489 of any RRset in the answer, which could have the unfortunate side- 490 effect of redundantly caching some data that could be cached more 491 broadly. For the specific case of a CNAME chain, the Authoritative 492 Nameserver SHOULD only place the CNAME to have it cached 493 unambiguously appropriately. Most modern Recursive Resolvers restart 494 the query with the canonical name, so the remainder of the chain is 495 typically ignored anyway. For message-focused resolvers, rather than 496 RRset-focused ones, this will mean caching the entire CNAME chain at 497 the longest PREFIX-LENGTH of any RRset in the chain. 499 The specific logic that an Authoritative Nameserver uses to choose a 500 tailored response is not in the scope of this document. Implementers 501 are encouraged, however, to consider carefully their selection of 502 SCOPE PREFIX-LENGTH for the response in the event that the best 503 tailored response cannot be determined, and what the implications 504 would be over the life of the TTL. 506 If the Authoritative Nameserver operator configures a more specific 507 (longer prefix length) Tailored Response within a configured less 508 specific (shorter prefix length) Tailored Response, then 509 implementations can either: 511 1. Deaggregate the shorter prefix response into multiple longer 512 prefix responses, or, 514 2. Alert the operator that the order of queries will determine which 515 answers get cached, and either warn and continue or treat this as 516 an error and refuse to load the configuration. 518 This choice should be documented for the operator, for example in the 519 user manual. 521 7.2.2. Intermediate Nameserver 523 When an Intermediate Nameserver uses ECS, whether it passes an ECS 524 option in its own response to its client is predicated on whether the 525 client originally included the option. Because a client that did not 526 use an ECS option might not be able to understand it, the server MUST 527 NOT provide one in its response. If the client query did include the 528 option, the server MUST include one in its response, especially as it 529 could be talking to a Forwarding Resolver which would need the 530 information for its own caching. 532 If an Intermediate Nameserver receives a response which has a longer 533 SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in 534 its query, it SHOULD still provide the result as the answer to the 535 triggering client request even if the client is in a different 536 address range. The Intermediate Nameserver MAY instead opt to retry 537 with a longer SOURCE PREFIX-LENGTH to get a better reply before 538 responding to its client, as long as it does not exceed a SOURCE 539 PREFIX-LENGTH specified in the query that triggered resolution, but 540 this obviously has implications for the latency of the overall 541 lookup. 543 The logic for using the cache to determine whether the Intermediate 544 Nameserver already knows the response to provide to its client is 545 covered in the next section. 547 7.3. Handling ECS Responses and Caching 549 When an Intermediate Nameserver receives a response containing an ECS 550 option and without the TC bit set, it SHOULD cache the result based 551 on the data in the option. If the TC bit was set, the Intermediate 552 Resolver SHOULD retry the query over TCP to get the complete answer 553 section for caching. 555 If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of 556 ADDRESS in the response don't match the non-zero fields in the 557 corresponding query, the full response MUST be dropped, as described 558 in Section 11. For a response to a query which specified only the 559 SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS 560 fields should contain the appropriate non-zero information for 561 caching. 563 If no ECS option is contained in the response, the Intermediate 564 Nameserver SHOULD treat this as being equivalent to having received a 565 SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client 566 addresses. See further discussion on the security implications of 567 this in Section 11. 569 If a REFUSED response is received from an Authoritative Nameserver, 570 an ECS-aware resolver MUST retry the query without ECS to distinguish 571 the response from one where the Authoritative Nameserver is not 572 responsible for the name, which is a common convention for the 573 REFUSED status. Similarly, a client of a Recursive Resolver should 574 retry for REFUSED because it is not sufficiently clear whether the 575 REFUSED was because of the ECS option or some other reason. 577 7.3.1. Caching the Response 579 In the cache, all resource records in the answer section MUST be tied 580 to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- 581 LENGTH fields, as limited by the Intermediate Nameserver's own 582 configuration for maximum cacheable prefix length. Note that the 583 additional and authority sections from a DNS response message are 584 specifically excluded here. Any records from these sections MUST NOT 585 be tied to a network. See more at Section 7.4. 587 Records that are cached as /0 because of a query's SOURCE PREFIX- 588 LENGTH of 0 MUST be distinguished from those that are cached as /0 589 because of a response's SCOPE PREFIX-LENGTH of 0. The former should 590 only be used for other /0 queries that the Intermediate Resolver 591 receives, but the latter is suitable as a response for all networks. 593 Although omitting network-specific caching will significantly 594 simplify an implementation, the resulting drop in cache hits is very 595 likely to defeat most latency benefits provided by ECS. Therefore, 596 when implementing this option for latency purposes, implementing full 597 caching support as described in this section is strongly recommended. 599 Enabling support for ECS in an Intermediate Nameserver will 600 significantly increase the size of the cache, reduce the number of 601 results that can be served from cache, and increase the load on the 602 server. Implementing the mitigation techniques described in 603 Section 11 is strongly recommended. 605 7.3.2. Answering from Cache 607 Cache lookups are first done as usual for a DNS query, using the 608 query tuple of . Then the appropriate RRset MUST 609 be chosen based on longest prefix matching. The client address to 610 use for comparison will depend on whether the Intermediate Nameserver 611 received an ECS option in its client query. 613 o If no ECS option was provided, the client's address is used. 615 o If there was an ECS option, the ADDRESS from it MAY be used if 616 local policy allows. Policy can vary depending on the agreements 617 the operator of the Intermediate Nameserver has with Authoritative 618 Nameserver operators; see Section 12.2. If policy does not allow, 619 a REFUSED response must be sent. 621 If a matching network is found and the relevant data is unexpired, 622 the response is generated as per Section 7.2. 624 If no matching network is found, the Intermediate Nameserver MUST 625 perform resolution as usual. This is necessary to avoid Tailored 626 Responses in the cache from being returned to the wrong clients, and 627 to avoid a single query coming from a client on a different network 628 from polluting the cache with a Tailored Response for all the users 629 of that resolver. 631 7.4. Delegations and Negative Answers 633 The prohibition against tying ECS data to records from the Authority 634 and Additional section left an unfortunate ambiguity in the original 635 specification, primarily with regard to negative answers. The 636 expectation of the original authors was that ECS would only really be 637 used for address requests and the positive result in the response's 638 answer section, the use case that was driving the definition of the 639 protocol. 641 The delegations case is a bit easier to tease out. In operational 642 practice, if an authoritative server is using address information to 643 provide customized delegations, it is the resolver that will be using 644 the answer for its next iterative query. Addresses in the Additional 645 section SHOULD therefore ignore ECS data, and the authority SHOULD 646 return a zero SCOPE PREFIX-LENGTH on delegations. A recursive 647 resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation 648 as though it were zero. 650 For negative answers, some independent implementations of both 651 resolvers and authorities did not see the section restriction as 652 necessarily meaning that a given name and type must only have either 653 positive ECS-tagged answers or a negative answer. They support being 654 able to tell one part of the network that the data does not exist, 655 while telling another part of the network that it does. 657 Several other implementations, however, do not support being able to 658 mix positive and negative answers, and thus interoperability is a 659 problem. It is recommended that no specific behaviour regarding 660 negative answers be relied upon. 662 This issue is expected to be revisited in a future revision of the 663 protocol, possibly blessing the mixing of positive and negative 664 answers. There are implications for cache data structures that 665 developers should consider when writing new ECS code. 667 7.5. Transitivity 669 Generally, ECS options will only be present in DNS messages between a 670 Recursive Resolver and an Authoritative Nameserver, i.e., one hop. 671 In certain configurations however, for example multi-tier nameserver 672 setups, it may be necessary to implement transitive behaviour on 673 Intermediate Nameservers. 675 Any Intermediate Nameserver that forwards ECS options received from 676 their clients MUST fully implement the caching behaviour described in 677 Section 7.3. 679 An Intermediate Nameserver MAY forward ECS options with address 680 information. This information MAY match the source IP address of the 681 incoming query, and MAY have more or fewer address bits than the 682 Nameserver would normally include in a locally originated ECS option. 683 If an Intermediate Nameservers receives a query with SOURCE PREFIX- 684 LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace 685 it with more accurate address information. 687 If for any reason the Intermediate Nameserver does not want to use 688 the information in an ECS option it receives (too little address 689 information, network address from a range not authorized to use the 690 server, private/unroutable address space, etc), it SHOULD drop the 691 query and return a REFUSED response. Note again that a query MUST 692 NOT be refused solely because it provides 0 address bits. 694 Be aware that at least one major existing implementation does not 695 return REFUSED and instead just process the query as though the 696 problematic information were not present. This can lead to anomalous 697 situations, such as a response from the Intermediate Nameserver that 698 indicates it is tailored for one network (the one passed in the 699 original query, since ADDRESS must match) when actually it is for 700 another network (the one which contains the address that the 701 Intermediate Nameserver saw as making the query). 703 8. IANA Considerations 705 IANA has already assigned option code 8 in the "DNS EDNS0 Option 706 Codes (OPT)" registry to ECS. 708 The IANA is requested to update the reference ("draft-vandergaast- 709 edns-client-subnet") to refer to this RFC when published. 711 9. DNSSEC Considerations 713 The presence or absence of an [RFC6891] EDNS0 OPT resource record 714 containing an ECS option in a DNS query does not change the usage of 715 the resource records and mechanisms used to provide data origin 716 authentication and data integrity to the DNS, as described in 717 [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. 719 Use of this option, however, does imply increased DNS traffic between 720 any given Recursive Resolver and Authoritative Nameserver, which 721 could be another barrier to further DNSSEC adoption in this area. 723 10. NAT Considerations 725 Special awareness of ECS in devices that perform Network Address 726 Translation (NAT) as described in [RFC2663] is not required; queries 727 can be passed through as-is. The client's network address SHOULD NOT 728 be added, and existing ECS options, if present, SHOULD NOT be 729 modified by NAT devices. 731 In large-scale global networks behind a NAT device (but for example 732 with Centralized Resolver infrastructure), an internal Intermediate 733 Nameserver might have detailed network layout information, and may 734 know which external subnets are used for egress traffic by each 735 internal network. In such cases, the Intermediate Nameserver MAY use 736 that information when originating ECS options. 738 In other cases, if a Recursive Resolvers knows it is sited behind a 739 NAT device, it SHOULD NOT originate ECS options with their external 740 IP address, and instead rely on downstream Intermediate Nameservers 741 to do so. They MAY, however, choose to include the option with their 742 internal address for the purposes of signaling a shorter, more 743 anonymous SOURCE PREFIX-LENGTH. 745 If an Authoritative Nameserver on the publicly routed Internet 746 receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] 747 private address space, it SHOULD ignore ADDRESS and look up its 748 answer based on the address of the Recursive Resolver. In the 749 response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the 750 relevant private space. For example, a query for ADDRESS 10.1.2.0 751 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX- 752 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the 753 answer under one entry for special-purpose addresses [RFC6890]; see 754 Section 11.3. 756 11. Security Considerations 758 11.1. Privacy 760 With the ECS option, the network address of the client that initiated 761 the resolution becomes visible to all servers involved in the 762 resolution process. Additionally, it will be visible from any 763 network traversed by the DNS packets. 765 To protect users' privacy, Recursive Resolvers are strongly 766 encouraged to conceal part of the IP address of the user by 767 truncating IPv4 addresses to 24 bits. 56 bits are recommended for 768 IPv6, based on [RFC6177]. 770 ISPs should have more detailed knowledge of their own networks. That 771 is, they might know that all 24-bit prefixes in a /20 are in the same 772 area. In those cases, for optimal cache utilization and improved 773 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 774 this /20 to just 20 bits, instead of 24 as recommended above. 776 Users who wish their full IP address to be hidden can include an ECS 777 option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 778 0). As described in previous sections, this option will be forwarded 779 across all the Recursive Resolvers supporting ECS, which MUST NOT 780 modify it to include the network address of the client. 782 Note that even without an ECS option, any server queried directly by 783 the user will be able to see the full client IP address. Recursive 784 Resolvers or Authoritative Nameservers MAY use the source IP address 785 of queries to return a cached entry or to generate a Tailored 786 Response that best matches the query. 788 11.2. Birthday Attacks 790 ECS adds information to the DNS query tupe (q-tuple). This allows an 791 attacker to send a caching Intermediate Nameserver multiple queries 792 with spoofed IP addresses either in the ECS option or as the source 793 IP. These queries will trigger multiple outgoing queries with the 794 same name, type and class, just different address information in the 795 ECS option. 797 With multiple queries for the same name in flight, the attacker has a 798 higher chance of success to send a matching response with the SCOPE 799 PREFIX-LENGTH set to 0 to get it cached for all hosts. 801 To counter this, the ECS option in a response packet MUST contain the 802 full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the 803 corresponding query. Intermediate Nameservers processing a response 804 MUST verify that these match, and SHOULD discard the entire response 805 if they do not. 807 That requirement to discard is "SHOULD" instead of "MUST" because it 808 stands in opposition to the instruction in Section 7.3 which states 809 that a response lacking an ECS option should be treated as though it 810 had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an 811 attacker does not need to worry about matching the original ECS 812 option data and just needs to flood back responses that have no ECS 813 option at all. 815 This type of attack could be detected in ongoing operations by 816 marking whether the responding nameserver had previously been sending 817 ECS option, and/or by taking note of an incoming flood of bogus 818 responses and flagging the relevant query for re-resolution. This is 819 more complex than existing nameserver responses to spoof floods, and 820 would also need to be sensitive to a nameserver legitimately stopping 821 ECS replies even though it had previously given them. 823 11.3. Cache Pollution 825 It is simple for an arbitrary resolver or client to provide false 826 information in the ECS option, or to send UDP packets with forged 827 source IP addresses. 829 This could be used to: 831 o pollute the cache of intermediate resolvers, by filling it with 832 results that will rarely (if ever) be used. 834 o reverse engineer the algorithms (or data) used by the 835 Authoritative Nameserver to calculate Tailored Responses. 837 o mount a denial-of-service attack against an Intermediate 838 Nameserver, by forcing it to perform many more recursive queries 839 than it would normally do, due to how caching is handled for 840 queries containing the ECS option. 842 Even without malicious intent, Centralized Resolvers providing 843 answers to clients in multiple networks will need to cache different 844 responses for different networks, putting more memory pressure on the 845 cache. 847 To mitigate those problems: 849 o Recursive Resolvers implementing ECS should only enable it in 850 deployments where it is expected to bring clear advantages to the 851 end users. For example, when expecting clients from a variety of 852 networks or from a wide geographical area. Due to the high cache 853 pressure introduced by ECS, the feature SHOULD be disabled in all 854 default configurations. 856 o Recursive Resolvers SHOULD limit the number of networks and 857 answers they keep in the cache for any given query. 859 o Recursive Resolvers SHOULD limit the number of total different 860 networks that they keep in cache. 862 o Recursive Resolvers MUST NOT send an ECS option with a SOURCE 863 PREFIX-LENGTH providing more bits in the ADDRESS than they are 864 willing to cache responses for. 866 o Recursive Resolvers should implement algorithms to improve the 867 cache hit rate, given the size constraints indicated above. 868 Recursive Resolvers MAY, for example, decide to discard more 869 specific cache entries first. 871 o Authoritative Nameservers and Recursive Resolvers should discard 872 ECS options that are either obviously forged or otherwise known to 873 be wrong. They SHOULD at least treat unroutable addresses, such 874 as some of the address blocks defined in [RFC6890], as equivalent 875 to the Recursive Resolver's own identity. They SHOULD ignore and 876 never forward ECS options specifying other routable addresses that 877 are known not to be served by the query source. 879 o Authoritative Nameservers consider the ECS option just as a hint 880 to provide better results. They can decide to ignore the content 881 of the ECS option based on black or white lists, rate limiting 882 mechanisms, or any other logic implemented in the software. 884 12. Sending the Option 886 When implementing a Recursive Resolver, there are two strategies on 887 deciding when to include an ECS option in a query. At this stage, 888 it's not clear which strategy is best. 890 12.1. Probing 892 A Recursive Resolver can send the ECS option with every outgoing 893 query. However, it is RECOMMENDED that Resolvers remember which 894 Authoritative Nameservers did not return the option with their 895 response, and omit client address information from subsequent queries 896 to those Nameservers. 898 Additionally, Recursive Resolvers SHOULD be configured to never send 899 the option when querying root, top-level, and effective top-level 900 (ie, ("public suffix") [Public_Suffix_List] domain servers. These 901 domains are delegation-centric and are very unlikely to generate 902 different responses based on the address of the client. 904 When probing, it is important that several things are probed: support 905 for ECS, support for EDNS0, support for EDNS0 options, or possibly an 906 unreachable Nameserver. Various implementations are known to drop 907 DNS packets with OPT RRs (with or without options), thus several 908 probes are required to discover what is supported. 910 Probing, if implemented, MUST be repeated periodically, e.g., daily. 911 If an Authoritative Nameserver indicates ECS support for one zone, it 912 is to be expected that the Nameserver supports ECS for all of its 913 zones. Likewise, an Authoritative Nameserver that uses ECS 914 information for one of its zones, MUST indicate support for the 915 option in all of its responses to ECS queries. If the option is 916 supported but not actually used for generating a response, its SCOPE 917 PREFIX-LENGTH MUST be set to 0. 919 12.2. Whitelist 921 As described previously, it is expected that only a few Recursive 922 Resolvers will need to use ECS, and that it will generally be enabled 923 only if it offers a clear benefit to the users. 925 To avoid the complexity of implementing a probing and detection 926 mechanism (and the possible query loss/delay that may come with it), 927 an implementation could use a whitelist of Authoritative Nameservers 928 to send the option to, likely specified by their domain name. 929 Implementations MAY also allow additionally configuring this based on 930 other criteria, such as zone or query type. As of the time of this 931 writing, at least one implementation makes use of a whitelist. 933 An advantage of using a whitelist is that partial client address 934 information is only disclosed to Nameservers that are known to use 935 the information, improving privacy. 937 A drawback is saleability. The operator needs to track which 938 Authoritative Nameservers support ECS, making it harder for new 939 Authoritative Nameservers to start using the option. 941 Similarly, Authoritative Nameservers can also use whitelists to limit 942 the feature to only certain clients. For example, a CDN that does 943 not want all of their mapping trivially walked might require a legal 944 agreement with the Recursive Resolver operator, to clearly describe 945 the acceptable use of the feature. 947 The maintenance of access control mechanisms is out of scope for this 948 protocol definition. 950 13. Example 952 1. A stub resolver, SR, with IP address 192.0.2.37 tries to resolve 953 www.example.com, by forwarding the query to the Recursive 954 Resolver, RNS, from IP address IP, asking for recursion. 956 2. RNS, supporting ECS, looks up www.example.com in its cache. An 957 entry is found neither for www.example.com, nor for example.com. 959 3. RNS builds a query to send to the root and .com servers. The 960 implementation of RNS provides facilities so an administrator 961 can configure it not to forward ECS in certain cases. In 962 particular, RNS is configured to not include an ECS option when 963 talking to TLD or root nameservers, as described in Section 7.1. 964 Thus, no ECS option is added, and resolution is performed as 965 usual. 967 4. RNS now knows the next server to query: the Authoritative 968 Nameserver, ANS, responsible for example.com. 970 5. RNS prepares a new query for www.example.com, including an ECS 971 option with: 973 * OPTION-CODE, set to 8. 975 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 976 octets plus the 3 octets that will be used for ADDRESS. 978 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 980 * SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to 981 conceal the last 8 bits of every IPv4 address. 983 * SCOPE PREFIX-LENGTH, set to 0x00, as specified by this 984 document for all queries. 986 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 987 bits of the IPv4 address. 989 6. The query is sent. ANS understands and uses ECS. It parses the 990 ECS option, and generates a Tailored Response. 992 7. Due its internal implementation, ANS finds a response that is 993 tailored for the whole /16 of the client that performed the 994 query. 996 8. ANS adds an ECS option in the response, containing: 998 * OPTION-CODE, set to 8. 1000 * OPTION-LENGTH, set to 0x00 0x07. 1002 * FAMILY, set to 0x00 0x01. 1004 * SOURCE PREFIX-LENGTH, set to 0x18, copied from the query. 1006 * SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network. 1008 * ADDRESS, set to 0xC0 0x00 0x02, copied from the query. 1010 9. RNS receives the response containing an ECS option. It verifies 1011 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. 1012 If not, the message is discarded. 1014 10. The response is interpreted as usual. Since the response 1015 contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and 1016 FAMILY in the response are used to cache the entry. 1018 11. RNS sends a response to stub resolver SR, without including an 1019 ECS option. 1021 12. RNS receives another query to resolve www.example.com. This 1022 time, a response is cached. The response, however, is tied to a 1023 particular network. If the address of the client matches any 1024 network in the cache, then the response is returned from the 1025 cache. Otherwise, another query is performed. If multiple 1026 results match, the one with the longest SCOPE PREFIX-LENGTH is 1027 chosen, as per common best-network match algorithms. 1029 14. Contributing Authors 1031 The below individuals contributed significantly to the document. The 1032 RFC Editor prefers a maximum of 5 names on the front page, and so we 1033 have listed additional authors in this section 1035 Edward Lewis 1036 ICANN 1037 12025 Waterfront Drive, Suite 300 1038 Los Angeles CA 90094-2536 1039 USA 1040 Email: edward.lewis@icann.org 1041 Sean Leach 1042 Fastly 1043 POBox 78266 1044 San Francisco CA 94107 1046 Jason Moreau 1047 Akamai Technologies 1048 8 Cambridge Ctr 1049 Cambridge MA 02142-1413 1050 USA 1052 15. Acknowledgements 1054 The authors wish to thank Darryl Rodden for his work as a co-author 1055 on previous versions, and the following people for reviewing early 1056 drafts of this document and for providing useful feedback: Paul S. 1057 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 1058 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 1059 Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, 1060 Edward Lewis, and Eric Burger from Neustar; David Ulevitch and 1061 Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from 1062 Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya 1063 Jinmei from Infoblox; Andrew Sullivan from Dyn; John Dickinson from 1064 Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs; 1065 Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn 1066 Gillmor from the ACLU, Russ Housley and all of the other people that 1067 replied to our emails on various mailing lists. 1069 16. References 1071 16.1. Normative References 1073 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1074 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1075 . 1077 [RFC1035] Mockapetris, P., "Domain names - implementation and 1078 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1079 November 1987, . 1081 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1082 DOI 10.17487/RFC1700, October 1994, 1083 . 1085 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1086 and E. Lear, "Address Allocation for Private Internets", 1087 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1088 . 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1092 RFC2119, March 1997, 1093 . 1095 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1096 Rose, "DNS Security Introduction and Requirements", RFC 1097 4033, DOI 10.17487/RFC4033, March 2005, 1098 . 1100 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1101 Rose, "Resource Records for the DNS Security Extensions", 1102 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1103 . 1105 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1106 Rose, "Protocol Modifications for the DNS Security 1107 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1108 . 1110 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1111 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1112 . 1114 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1115 Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/ 1116 RFC6177, March 2011, 1117 . 1119 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1120 "Special-Purpose IP Address Registries", BCP 153, RFC 1121 6890, DOI 10.17487/RFC6890, April 2013, 1122 . 1124 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1125 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 1126 RFC6891, April 2013, 1127 . 1129 16.2. Informative References 1131 [Address_Family_Numbers] 1132 "Address Family Numbers", 1133 . 1136 [DPRIVE_Working_Group] 1137 "DPRIVE Working Group", 1138 . 1140 [I-D.hardie-privsec-metadata-insertion] 1141 Hardie, T., "Design considerations for Metadata 1142 Insertion", draft-hardie-privsec-metadata-insertion-00 1143 (work in progress), October 2015. 1145 [I-D.vandergaast-edns-client-subnet] 1146 Contavalli, C., Gaast, W., Leach, S., and E. Lewis, 1147 "Client Subnet in DNS Requests", draft-vandergaast-edns- 1148 client-subnet-02 (work in progress), July 2013. 1150 [Public_Suffix_List] 1151 "Public Suffix List", . 1153 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1154 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1155 . 1157 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1158 Translator (NAT) Terminology and Considerations", RFC 1159 2663, DOI 10.17487/RFC2663, August 1999, 1160 . 1162 Appendix A. Document History 1164 [RFC Editor: Please delete this section before publication.] 1166 -05 to -06: 1168 o Integrated David Lawrence comments. 1170 o Ran spellcheck again. One ady I';; laern to tyoe/ 1172 -04 to -05: 1174 o Moved comment about retrying for REFUSED to section on "Handling 1175 ECS Responses". (Jinmei) 1177 o Clarify that a new proposal for an improved ECS protool is 1178 expected. 1180 o "Forwarders" had been used as though they were the source of a 1181 forwarded query rather than the targeted of one; clarified and 1182 defined as "Forwarding Resolver". (Jinmei) 1184 o "representing the leftmost significant bits" => "representing the 1185 leftmost number of significant bits". (Jinmei) 1187 o Minor other clarifying text. (Jinmei) 1189 o Jinmei's affiliation. 1191 o Minor wording clarifications. (David Kahn Gillmor) 1193 o Russ Housely's GenART review. 1195 -03 to -04: 1197 o Privacy note per Ted Hardie's suggestion. 1199 o MUST use minimum octet length to cover PREFIX bits. 1201 o Expose note about documenting deployed, if flawed, protocol. 1203 -02 to -03: 1205 o Some cleanup of the whitelist text. 1207 -01 to -02 (IETF) 1209 o Clean up the open issues, mostly by saying that they were out of 1210 scope for this document. 1212 o How in the world did no reviewers note that "Queries" had been 1213 spelled as "Querys" in the title? (Aaron Falk did.) 1215 -00 to -01 (IETF) 1217 o Note ambiguity with multiple RRsets appearing in reply, eg, for an 1218 ANY query or CNAME chain. (Duane Wessels) 1220 o Open issue questioning the guidance about resolvers behind a NAT. 1221 How do they know they are? What real requirement is this 1222 imposing? (Duane Wessels) 1224 o Some other wording changes based on Duane's review of an earlier 1225 draft. 1227 -IND to -00 (IETF) 1229 o Made the document describe how things are actually 1230 implmented now. This makes the document be more of a "this is how 1231 we are doing things, this provides information on that". There 1232 may be a future document that describes additional funcationality. 1234 o NETMASK was not a good desription, changed to PREFIX-LENGTH 1235 (Jinmei, others). Stole most of the definition for prefix length 1236 from RFC4291. 1238 o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include 1239 IPv6 (Tatuya Jinmei) 1241 o Comment that ECS cannot be used to hand NXDOMAIN to some clients 1242 and not others, primarily because of interoperability issues. 1243 (Tatuya Jinmei) 1245 o Added text explaining that implmentations need to document thier 1246 behavior with overlapping networks. 1248 o Soften "optimized reply" language. (Andrew Sullivan). 1250 o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0) 1252 o Some more grammar / working cleanups. 1254 o Replaced a whole heap of occurances of "edns-client-subnet" with 1255 "ECS" for readability. (John Dickinson) 1257 o More clearly describe the process from the point of view of each 1258 type of nameserver. (John Dickinson) 1260 o Birthday attack still possible if attacker floods with ECS-less 1261 responses. (Yuri Schaeffer) 1263 o Added some open issues directly to the text. 1265 A.1. -00 1267 o Document moved to experimental track, added experiment description 1268 in header with details in a new section. 1270 o Specifically note that ECS applies to the answer section only. 1272 o Warn that caching based on ECS is optional but very important for 1273 performance reasons. 1275 o Updated NAT section. 1277 o Added recommendation to not use the default /24 recommendation for 1278 the source prefix-length field if more detailed information about 1279 the network is available. 1281 o Rewritten problem statement to be more clear about the goal of ECS 1282 and the fact that it's entirely optional. 1284 o Wire format changed to include the original address and prefix 1285 length in responses in defence against birthday attacks. 1287 o Security considerations now includes a section about birthday 1288 attacks. 1290 o Renamed edns-client-ip in ECS, following suggestions on the 1291 mailing list. 1293 o Clarified behavior of resolvers when presented with an invalid ECS 1294 option. 1296 o Fully take multi-tier DNS setups in mind and be more clear about 1297 where the option should be originated. 1299 o A note on Authoritative Nameservers receiving queries that specify 1300 private address space. 1302 o A note to always ask for the longest acceptable SOURCE prefix 1303 length, even if a prior answer indicated that a shorter prefix 1304 length was suitable. 1306 o Marked up a few more references. 1308 o Added a few definitions in the Terminology section, and a few more 1309 aesthetic changes in the rest of the document. 1311 A.2. -01 1313 o Document version number reset from -02 to -00 due to the rename of 1314 base document. 1316 o Clarified example (dealing with TLDs, and various minor errors). 1318 o Referencing RFC5035 instead of RFC1918. 1320 o Added a section on probing (and how it should be done) vs. 1321 whitelisting. 1323 o Moved description on how to forward ECS option in dedicated 1324 section. 1326 o Queries with wrongly formatted ECS options should now be rejected 1327 with FORMERR. 1329 o Added an "Overview" section, providing an introduction to the 1330 document. 1332 o Intermediate Nameservers can now remove an ECS option, or reduce 1333 the SOURCE PREFIX-LENGTH to increase privacy. 1335 o Added a reference to DoS attacks in the Security section. 1337 o Don't use "network range", as it seems to have different meaning 1338 in other contexts, and turned out to be confusing. 1340 o Use shorter and longer prefix lengths, rather than higher or 1341 lower. Add a better explanation in the format section. 1343 o Minor corrections in various other sections. 1345 A.3. -02 1347 o Added IANA-assigned option code. 1349 Authors' Addresses 1351 Carlo Contavalli 1352 Google 1353 1600 Amphitheater Parkway 1354 Mountain View, CA 94043 1355 US 1357 Email: ccontavalli@google.com 1359 Wilmer van der Gaast 1360 Google 1361 Belgrave House, 76 Buckingham Palace Road 1362 London SW1W 9TQ 1363 UK 1365 Email: wilmer@google.com 1366 David C Lawrence 1367 Akamai Technologies 1368 8 Cambridge Center 1369 Cambridge, MA 02142 1370 US 1372 Email: tale@akamai.com 1374 Warren Kumari 1375 Google 1376 1600 Amphitheatre Parkway 1377 Mountain View, CA 94043 1378 US 1380 Email: warren@kumari.net