idnits 2.17.00 (12 Aug 2021) /tmp/idnits40361/draft-ietf-dnsop-edns-client-subnet-05.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 14, 2015) is 2350 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 16, 2016 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 December 14, 2015 11 Client Subnet in DNS Queries 12 draft-ietf-dnsop-edns-client-subnet-05 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 16, 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 Namserver. 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 Resover 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 Forwaring 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 authoritative response from a lame delegation, which is the 572 common convention for a REFUSED status. Similarly, a client of a 573 Recursive Resolver should retry for REFUSED because it is not 574 sufficiently clear whether the REFUSED was because of the ECS option 575 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. 661 This issue is expected to be revisited in a future revision of the 662 protocol, possibly blessing the mixing of positive and negative 663 answers. There are implications for cache data structures that 664 developers should consider when writing new ECS code. 666 7.5. Transitivity 668 Generally, ECS options will only be present in DNS messages between a 669 Recursive Resolver and an Authoritative Nameserver, i.e., one hop. 670 In certain configurations however, for example multi-tier nameserver 671 setups, it may be necessary to implement transitive behaviour on 672 Intermediate Nameservers. 674 Any Intermediate Nameserver that forwards ECS options received from 675 their clients MUST fully implement the caching behaviour described in 676 Section 7.3. 678 Intermediate Nameservers supporting ECS MUST forward options with 679 SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such 680 options MUST NOT be replaced with more accurate address information. 682 An Intermediate Nameserver MAY also forward ECS options with actual 683 address information. This information MAY match the source IP 684 address of the incoming query, and MAY have more or fewer address 685 bits than the Nameserver would normally include in a locally 686 originated ECS option. 688 If for any reason the Intermediate Nameserver does not want to use 689 the information in an ECS option it receives (too little address 690 information, network address from a range not authorized to use the 691 server, private/unroutable address space, etc), it SHOULD drop the 692 query and return a REFUSED response. Note again that a query MUST 693 NOT be refused solely because it provides 0 address bits. 695 Be aware that at least one major existing implementation does not 696 return REFUSED and instead just process the query as though the 697 problematic information were not present. This can lead to anomalous 698 situations, such as a response from the Intermediate Nameserver that 699 indicates it is tailored for one network (the one passed in the 700 original query, since ADDRESS must match) when actually it is for 701 another network (the one which contains the address that the 702 Intermediate Nameserver saw as making the query). 704 8. IANA Considerations 706 IANA has already assigned option code 8 in the "DNS EDNS0 Option 707 Codes (OPT)" registry to ECS. 709 The IANA is requested to update the reference ("draft-vandergaast- 710 edns-client-subnet") to refer to this RFC when published. 712 9. DNSSEC Considerations 714 The presence or absence of an [RFC6891] EDNS0 OPT resource record 715 containing an ECS option in a DNS query does not change the usage of 716 the resource records and mechanisms used to provide data origin 717 authentication and data integrity to the DNS, as described in 718 [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. 720 Use of this option, however, does imply increased DNS traffic between 721 any given Recursive Resolver and Authoritative Nameserver, which 722 could be another barrier to further DNSSEC adoption in this area. 724 10. NAT Considerations 726 Special awareness of ECS in devices that perform Network Address 727 Translation (NAT) as described in [RFC2663] is not required; queries 728 can be passed through as-is. The client's network address SHOULD NOT 729 be added, and existing ECS options, if present, SHOULD NOT be 730 modified by NAT devices. 732 In large-scale global networks behind a NAT device (but for example 733 with Centralized Resolver infrastructure), an internal Intermediate 734 Nameserver might have detailed network layout information, and may 735 know which external subnets are used for egress traffic by each 736 internal network. In such cases, the Intermediate Nameserver MAY use 737 that information when originating ECS options. 739 In other cases, if a Recursive Resolvers knows it is sited behind a 740 NAT device, it SHOULD NOT originate ECS options with their external 741 IP address, and instead rely on downstream Intermediate Nameservers 742 to do so. They MAY, however, choose to include the option with their 743 internal address for the purposes of signaling a shorter, more 744 anonymous SOURCE PREFIX-LENGTH. 746 If an Authoritative Nameserver on the publicly routed Internet 747 receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] 748 private address space, it SHOULD ignore ADDRESS and look up its 749 answer based on the address of the Recursive Resolver. In the 750 response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the 751 relevant private space. For example, a query for ADDRESS 10.1.2.0 752 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX- 753 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the 754 answer under one entry for special-purpose addresses [RFC6890]; see 755 Section 11.3. 757 11. Security Considerations 759 11.1. Privacy 761 With the ECS option, the network address of the client that initiated 762 the resolution becomes visible to all servers involved in the 763 resolution process. Additionally, it will be visible from any 764 network traversed by the DNS packets. 766 To protect users' privacy, Recursive Resolvers are strongly 767 encouraged to conceal part of the IP address of the user by 768 truncating IPv4 addresses to 24 bits. 56 bits are recommended for 769 IPv6, based on [RFC6177]. 771 ISPs should have more detailed knowledge of their own networks. That 772 is, they might know that all 24-bit prefixes in a /20 are in the same 773 area. In those cases, for optimal cache utilization and improved 774 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 775 this /20 to just 20 bits, instead of 24 as recommended above. 777 Users who wish their full IP address to be hidden can include an ECS 778 option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 779 0). As described in previous sections, this option will be forwarded 780 across all the Recursive Resolvers supporting ECS, which MUST NOT 781 modify it to include the network address of the client. 783 Note that even without an ECS option, any server queried directly by 784 the user will be able to see the full client IP address. Recursive 785 Resolvers or Authoritative Nameservers MAY use the source IP address 786 of queries to return a cached entry or to generate a Tailored 787 Response that best matches the query. 789 11.2. Birthday Attacks 791 ECS adds information to the DNS query tupe (q-tuple). This allows an 792 attacker to send a caching Intermediate Nameserver multiple queries 793 with spoofed IP addresses either in the ECS option or as the source 794 IP. These queries will trigger multiple outgoing queries with the 795 same name, type and class, just different address information in the 796 ECS option. 798 With multiple queries for the same name in flight, the attacker has a 799 higher chance of success to send a matching response with the SCOPE 800 PREFIX-LENGTH set to 0 to get it cached for all hosts. 802 To counter this, the ECS option in a response packet MUST contain the 803 full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the 804 corresponding query. Intermediate Nameservers processing a response 805 MUST verify that these match, and SHOULD discard the entire response 806 if they do not. 808 That requirement to discard is "SHOULD" instead of "MUST" because it 809 stands in opposition to the instruction in Section 7.3 which states 810 that a response lacking an ECS option should be treated as though it 811 had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an 812 attacker does not need to worry about matching the original ECS 813 option data and just needs to flood back responses that have no ECS 814 option at all. 816 This type of attack could be detected in ongoing operations by 817 marking whether the responding nameserver had previously been sending 818 ECS option, and/or by taking note of an incoming flood of bogus 819 responses and flagging the relevant query for re-resolution. This is 820 more complex than existing nameserver responses to spoof floods, and 821 would also need to be sensitive to a nameserver legitimately stopping 822 ECS replies even though it had previously given them. 824 11.3. Cache Pollution 826 It is simple for an arbitrary resolver or client to provide false 827 information in the ECS option, or to send UDP packets with forged 828 source IP addresses. 830 This could be used to: 832 o pollute the cache of intermediate resolvers, by filling it with 833 results that will rarely (if ever) be used. 835 o reverse engineer the algorithms (or data) used by the 836 Authoritative Nameserver to calculate Tailored Responses. 838 o mount a denial-of-service attack against an Intermediate 839 Nameserver, by forcing it to perform many more recursive queries 840 than it would normally do, due to how caching is handled for 841 queries containing the ECS option. 843 Even without malicious intent, Centralized Resolvers providing 844 answers to clients in multiple networks will need to cache different 845 responses for different networks, putting more memory pressure on the 846 cache. 848 To mitigate those problems: 850 o Recursive Resolvers implementing ECS should only enable it in 851 deployments where it is expected to bring clear advantages to the 852 end users. For example, when expecting clients from a variety of 853 networks or from a wide geographical area. Due to the high cache 854 pressure introduced by ECS, the feature SHOULD be disabled in all 855 default configurations. 857 o Recursive Resolvers SHOULD limit the number of networks and 858 answers they keep in the cache for any given query. 860 o Recursive Resolvers SHOULD limit the number of total different 861 networks that they keep in cache. 863 o Recursive Resolvers MUST never send an ECS option with a SOURCE 864 PREFIX-LENGTH providing more bits in the ADDRESS than they are 865 willing to cache responses for. 867 o Recursive Resolvers should implement algorithms to improve the 868 cache hit rate, given the size constraints indicated above. 869 Recursive Resolvers MAY, for example, decide to discard more 870 specific cache entries first. 872 o Authoritative Nameservers and Recursive Resolvers should discard 873 ECS options that are either obviously forged or otherwise known to 874 be wrong. They SHOULD at least treat unroutable addresses, such 875 as some of the address blocks defined in [RFC6890], as equivalent 876 to the Recursive Resolver's own identity. They SHOULD ignore and 877 never forward ECS options specifying other routable addresses that 878 are known not to be served by the query source. 880 o Authoritative Nameservers consider the ECS option just as a hint 881 to provide better results. They can decide to ignore the content 882 of the ECS option based on black or white lists, rate limiting 883 mechanisms, or any other logic implemented in the software. 885 12. Sending the Option 887 When implementing a Recursive Resolver, there are two strategies on 888 deciding when to include an ECS option in a query. At this stage, 889 it's not clear which strategy is best. 891 12.1. Probing 893 A Recursive Resolver can send the ECS option with every outgoing 894 query. However, it is RECOMMENDED that Resolvers remember which 895 Authoritative Nameservers did not return the option with their 896 response, and omit client address information from subsequent queries 897 to those Nameservers. 899 Additionally, Recursive Resolvers SHOULD be configured to never send 900 the option when querying root, top-level, and effective top-level 901 (ie, ("public suffic") [Public_Suffix_List] domain servers. These 902 domains are delegation-centric and are very unlikely to generate 903 different responses based on the address of the client. 905 When probing, it is important that several things are probed: support 906 for ECS, support for EDNS0, support for EDNS0 options, or possibly an 907 unreachable Nameserver. Various implementations are known to drop 908 DNS packets with OPT RRs (with or without options), thus several 909 probes are required to discover what is supported. 911 Probing, if implemented, MUST be repeated periodically, e.g., daily. 912 If an Authoritative Nameserver indicates ECS support for one zone, it 913 is to be expected that the Nameserver supports ECS for all of its 914 zones. Likewise, an Authoritative Nameserver that uses ECS 915 information for one of its zones, MUST indicate support for the 916 option in all of its responses to ECS queries. If the option is 917 supported but not actually used for generating a response, its SCOPE 918 PREFIX-LENGTH MUST be set to 0. 920 12.2. Whitelist 922 As described previously, it is expected that only a few Recursive 923 Resolvers will need to use ECS, and that it will generally be enabled 924 only if it offers a clear benefit to the users. 926 To avoid the complexity of implementing a probing and detection 927 mechanism (and the possible query loss/delay that may come with it), 928 an implementation could use a whitelist of Authoritative Namesevers 929 to send the option to, likely specified by their domain name. 930 Implementations MAY also allow additionally configuring this based on 931 other criteria, such as zone or query type. As of the time of this 932 writing, at least one implemetaion makes use of a whitelist. 934 An advantage of using a whitelist is that partial client address 935 information is only disclosed to Nameservers that are known to use 936 the information, improving privacy. 938 A drawback is scalability. The operator needs to track which 939 Authoritative Nameservers support ECS, making it harder for new 940 Authoritative Nameservers to start using the option. 942 Similarly, Authoritative Nameservers can also use whitelists to limit 943 the feature to only certain clients. For example, a CDN that does 944 not want all of their mapping trivially walked might require a legal 945 agreement with the Recursive Resolver operator, to clearly describe 946 the acceptable use of the feature. 948 The maintenance of access control mechanisms is out of scope for this 949 protocol definition. 951 13. Example 953 1. A stub resolver, SR, with IP address 192.0.2.37 tries to resolve 954 www.example.com, by forwarding the query to the Recursive 955 Resolver, RNS, from IP address IP, asking for recursion. 957 2. RNS, supporting ECS, looks up www.example.com in its cache. An 958 entry is found neither for www.example.com, nor for example.com. 960 3. RNS builds a query to send to the root and .com servers. The 961 implementation of RNS provides facilities so an administrator 962 can configure it not to forward ECS in certain cases. In 963 particular, RNS is configured to not include an ECS option when 964 talking to TLD or root nameservers, as described in Section 7.1. 965 Thus, no ECS option is added, and resolution is performed as 966 usual. 968 4. RNS now knows the next server to query: the Authoritative 969 Nameserver, ANS, responsible for example.com. 971 5. RNS prepares a new query for www.example.com, including an ECS 972 option with: 974 * OPTION-CODE, set to 8. 976 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 977 octets plus the 3 octets that will be used for ADDRESS. 979 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 981 * SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to 982 conceal the last 8 bits of every IPv4 address. 984 * SCOPE PREFIX-LENGTH, set to 0x00, as specified by this 985 document for all queries. 987 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 988 bits of the IPv4 address. 990 6. The query is sent. ANS understands and uses ECS. It parses the 991 ECS option, and generates a Tailored Response. 993 7. Due its internal implementation, ANS finds a response that is 994 tailored for the whole /16 of the client that performed the 995 query. 997 8. ANS adds an ECS option in the response, containing: 999 * OPTION-CODE, set to 8. 1001 * OPTION-LENGTH, set to 0x00 0x07. 1003 * FAMILY, set to 0x00 0x01. 1005 * SOURCE PREFIX-LENGTH, set to 0x18, copied from the query. 1007 * SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network. 1009 * ADDRESS, set to 0xC0 0x00 0x02, copied from the query. 1011 9. RNS receives the response containing an ECS option. It verifies 1012 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. 1013 If not, the message is discarded. 1015 10. The response is interpreted as usual. Since the response 1016 contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and 1017 FAMILY in the response are used to cache the entry. 1019 11. RNS sends a response to stub resolver SR, without including an 1020 ECS option. 1022 12. RNS receives another query to resolve www.example.com. This 1023 time, a response is cached. The response, however, is tied to a 1024 particular network. If the address of the client matches any 1025 network in the cache, then the response is returned from the 1026 cache. Otherwise, another query is performed. If multiple 1027 results match, the one with the longest SCOPE PREFIX-LENGTH is 1028 chosen, as per common best-network match algorithms. 1030 14. Contributing Authors 1032 The below individuals contributed significantly to the document. The 1033 RFC Editor prefers a maximum of 5 names on the front page, and so we 1034 have listed additional authors in this section 1036 Edward Lewis 1037 ICANN 1038 12025 Waterfront Drive, Suite 300 1039 Los Angeles CA 90094-2536 1040 USA 1041 Email: edward.lewis@icann.org 1042 Sean Leach 1043 Fastly 1044 POBox 78266 1045 San Francisco CA 94107 1047 Jason Moreau 1048 Akamai Technologies 1049 8 Cambridge Ctr 1050 Cambridge MA 02142-1413 1051 USA 1053 15. Acknowledgements 1055 The authors wish to thank Darryl Rodden for his work as a co-author 1056 on previous versions, and the following people for reviewing early 1057 drafts of this document and for providing useful feedback: Paul S. 1058 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 1059 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 1060 Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, 1061 Edward Lewis, and Eric Burger from Neustar; David Ulevitch and 1062 Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from 1063 Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya 1064 Jinmei from Infoblox; Andrew Sullivan from Dyn; John Dickinson from 1065 Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs; 1066 Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn 1067 Gillmor from the ACLU, and all of the other people that replied to 1068 our emails on various mailing lists. 1070 16. References 1072 16.1. Normative References 1074 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1075 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1076 . 1078 [RFC1035] Mockapetris, P., "Domain names - implementation and 1079 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1080 November 1987, . 1082 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1083 DOI 10.17487/RFC1700, October 1994, 1084 . 1086 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1087 and E. Lear, "Address Allocation for Private Internets", 1088 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1089 . 1091 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1092 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1093 RFC2119, March 1997, 1094 . 1096 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1097 Rose, "DNS Security Introduction and Requirements", RFC 1098 4033, DOI 10.17487/RFC4033, March 2005, 1099 . 1101 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1102 Rose, "Resource Records for the DNS Security Extensions", 1103 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1104 . 1106 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1107 Rose, "Protocol Modifications for the DNS Security 1108 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1109 . 1111 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1112 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1113 . 1115 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1116 Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/ 1117 RFC6177, March 2011, 1118 . 1120 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1121 "Special-Purpose IP Address Registries", BCP 153, RFC 1122 6890, DOI 10.17487/RFC6890, April 2013, 1123 . 1125 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1126 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 1127 RFC6891, April 2013, 1128 . 1130 16.2. Informative References 1132 [Address_Family_Numbers] 1133 "Address Family Numbers", 1134 . 1137 [DPRIVE_Working_Group] 1138 "DPRIVE Working Group", 1139 . 1141 [I-D.hardie-privsec-metadata-insertion] 1142 Hardie, T., "Design considerations for Metadata 1143 Insertion", draft-hardie-privsec-metadata-insertion-00 1144 (work in progress), October 2015. 1146 [I-D.vandergaast-edns-client-subnet] 1147 Contavalli, C., Gaast, W., Leach, S., and E. Lewis, 1148 "Client Subnet in DNS Requests", draft-vandergaast-edns- 1149 client-subnet-02 (work in progress), July 2013. 1151 [Public_Suffix_List] 1152 "Public Suffix List", . 1154 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1155 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1156 . 1158 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1159 Translator (NAT) Terminology and Considerations", RFC 1160 2663, DOI 10.17487/RFC2663, August 1999, 1161 . 1163 Appendix A. Document History 1165 [RFC Editor: Please delete this section before publication.] 1167 -05 to -06(?): 1169 o Minor wording clarifications. (David Kahn Gillmor) 1171 -04 to -05: 1173 o Moved comment about retrying for REFUSED to section on "Handling 1174 ECS Responses". (Jinmei) 1176 o Clarify that a new proposal for an improved ECS protool is 1177 expected. 1179 o "Forwarders" had been used as though they were the source of a 1180 forwarded query rather than the targeted of one; clarified and 1181 defined as "Forwarding Resolver". (Jinmei) 1183 o "representing the leftmost significant bits" => "representing the 1184 leftmost number of significant bits". (Jinmei) 1186 o Minor other clarifying text. (Jinmei) 1188 o Jinmei's affiliation. 1190 -03 to -04: 1192 o Privacy note per Ted Hardie's suggestion. 1194 o MUST use minimum octet length to cover PREFIX bits. 1196 o Expose note about documenting deployed, if flawed, protocol. 1198 -02 to -03: 1200 o Some cleanup of the whitelist text. 1202 -01 to -02 (IETF) 1204 o Clean up the open issues, mostly by saying that they were out of 1205 scope for this document. 1207 o How in the world did no reviewers note that "Queries" had been 1208 spelled as "Querys" in the title? (Aaron Falk did.) 1210 -00 to -01 (IETF) 1212 o Note ambiguity with multiple RRsets appearing in reply, eg, for an 1213 ANY query or CNAME chain. (Duane Wessels) 1215 o Open issue questioning the guidance about resolvers behind a NAT. 1216 How do they know they are? What real requirement is this 1217 imposing? (Duane Wessels) 1219 o Some other wording changes based on Duane's review of an earlier 1220 draft. 1222 -IND to -00 (IETF) 1224 o Made the document describe how things are actually 1225 implmented now. This makes the document be more of a "this is how 1226 we are doing things, this provides information on that". There 1227 may be a future document that describes additional funcationality. 1229 o NETMASK was not a good desription, changed to PREFIX-LENGTH 1230 (Jinmei, others). Stole most of the definition for prefix length 1231 from RFC4291. 1233 o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include 1234 IPv6 (Tatuya Jinmei) 1236 o Comment that ECS cannot be used to hand NXDOMAIN to some clients 1237 and not others, primarily because of interoperability issues. 1238 (Tatuya Jinmei) 1240 o Added text explaining that implmentations need to document thier 1241 behavior with overlapping networks. 1243 o Soften "optimized reply" language. (Andrew Sullivan). 1245 o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0) 1247 o Some more grammar / working cleanups. 1249 o Replaced a whole heap of occurances of "edns-client-subnet" with 1250 "ECS" for readability. (John Dickinson) 1252 o More clearly describe the process from the point of view of each 1253 type of nameserver. (John Dickinson) 1255 o Birthday attack still possible if attacker floods with ECS-less 1256 responses. (Yuri Schaeffer) 1258 o Added some open issues directly to the text. 1260 A.1. -00 1262 o Document moved to experimental track, added experiment description 1263 in header with details in a new section. 1265 o Specifically note that ECS applies to the answer section only. 1267 o Warn that caching based on ECS is optional but very important for 1268 performance reasons. 1270 o Updated NAT section. 1272 o Added recommendation to not use the default /24 recommendation for 1273 the source prefix-length field if more detailed information about 1274 the network is available. 1276 o Rewritten problem statement to be more clear about the goal of ECS 1277 and the fact that it's entirely optional. 1279 o Wire format changed to include the original address and prefix 1280 length in responses in defence against birthday attacks. 1282 o Security considerations now includes a section about birthday 1283 attacks. 1285 o Renamed edns-client-ip in ECS, following suggestions on the 1286 mailing list. 1288 o Clarified behavior of resolvers when presented with an invalid ECS 1289 option. 1291 o Fully take multi-tier DNS setups in mind and be more clear about 1292 where the option should be originated. 1294 o A note on Authoritative Nameservers receiving queries that specify 1295 private address space. 1297 o A note to always ask for the longest acceptable SOURCE prefix 1298 length, even if a prior answer indicated that a shorter prefix 1299 length was suitable. 1301 o Marked up a few more references. 1303 o Added a few definitions in the Terminology section, and a few more 1304 aesthetic changes in the rest of the document. 1306 A.2. -01 1308 o Document version number reset from -02 to -00 due to the rename of 1309 base document. 1311 o Clarified example (dealing with TLDs, and various minor errors). 1313 o Referencing RFC5035 instead of RFC1918. 1315 o Added a section on probing (and how it should be done) vs. 1316 whitelisting. 1318 o Moved description on how to forward ECS option in dedicated 1319 section. 1321 o Queries with wrongly formatted ECS options should now be rejected 1322 with FORMERR. 1324 o Added an "Overview" section, providing an introduction to the 1325 document. 1327 o Intermediate Nameservers can now remove an ECS option, or reduce 1328 the SOURCE PREFIX-LENGTH to increase privacy. 1330 o Added a reference to DoS attacks in the Security section. 1332 o Don't use "network range", as it seems to have different meaning 1333 in other contexts, and turned out to be confusing. 1335 o Use shorter and longer prefix lengths, rather than higher or 1336 lower. Add a better explanation in the format section. 1338 o Minor corrections in various other sections. 1340 A.3. -02 1342 o Added IANA-assigned option code. 1344 Authors' Addresses 1346 Carlo Contavalli 1347 Google 1348 1600 Amphitheater Parkway 1349 Mountain View, CA 94043 1350 US 1352 Email: ccontavalli@google.com 1354 Wilmer van der Gaast 1355 Google 1356 Belgrave House, 76 Buckingham Palace Road 1357 London SW1W 9TQ 1358 UK 1360 Email: wilmer@google.com 1362 David C Lawrence 1363 Akamai Technologies 1364 8 Cambridge Center 1365 Cambridge, MA 02142 1366 US 1368 Email: tale@akamai.com 1369 Warren Kumari 1370 Google 1371 1600 Amphitheatre Parkway 1372 Mountain View, CA 94043 1373 US 1375 Email: warren@kumari.net