idnits 2.17.00 (12 Aug 2021) /tmp/idnits39393/draft-ietf-dnsop-edns-client-subnet-04.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 (September 25, 2015) is 2430 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1123 -- Looks like a reference, but probably isn't: '3' on line 1126 -- Looks like a reference, but probably isn't: '4' on line 1128 -- Looks like a reference, but probably isn't: '5' on line 1132 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 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: March 28, 2016 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 September 25, 2015 11 Client Subnet in DNS Queries 12 draft-ietf-dnsop-edns-client-subnet-04 14 Abstract 16 This draft defines an EDNS0 extension to carry information about the 17 network that originated a DNS query, and the network for which the 18 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 March 28, 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 . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Originating the Option . . . . . . . . . . . . . . . . . 7 62 7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8 63 7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9 64 7.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9 65 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 66 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9 67 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 11 68 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 12 69 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 12 70 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 13 71 7.4. Delegations and Negative Answers . . . . . . . . . . . . 14 72 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 15 75 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 85 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 86 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 16.2. Informative References . . . . . . . . . . . . . . . . . 24 89 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 Appendix A. Document History . . . . . . . . . . . . . . . . . . 25 91 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Introduction 98 Many Authoritative Nameservers today return different responses based 99 on the perceived topological location of the user. These servers use 100 the IP address of the incoming query to identify that location. 101 Since most queries come from intermediate Recursive Resolvers, the 102 source address is that of the Recursive Resolver rather than of the 103 query originator. 105 Traditionally, and probably still in the majority of instances, 106 Recursive Resolvers are reasonably close in the topological sense to 107 the Stub Resolvers or Forwarders that are the source of queries. For 108 these resolvers, using their own IP address is sufficient for 109 authority servers that tailor responses based upon location of the 110 querier. 112 Increasingly, though, a class of Recursive Resolvers has arisen that 113 handle query sources that are often not topologically close. The 114 motivation for a user to configure such a Centralized Resolver varies 115 but is usually because of some enhanced experience, such as greater 116 cache security or applying policies regarding where users may 117 connect. (Although political censorship usually comes to mind here, 118 the same actions may be used by a parent when setting controls on 119 where a minor may connect.) Similarly, many ISPs and other 120 organizations use a Centralized Resolver infrastructure that can be 121 distant from the clients the resolvers serve. These cases all lead 122 to less than desirable responses from topology-sensitive 123 Authoritative Nameservers. 125 This draft defines an EDNS0 [RFC6891] option to convey network 126 information that is relevant to the DNS message. It will carry 127 sufficient network information about the originator for the 128 Authoritative Nameserver to tailor responses. It will also provide 129 for the Authoritative Nameserver to indicate the scope of network 130 addresses for which the tailored answer is intended. This EDNS0 131 option is intended for those recursive and authority servers that 132 would benefit from the extension and not for general purpose 133 deployment. It is completely optional and can safely be ignored by 134 servers that choose not to implement it or enable it. 136 This draft also includes guidelines on how to best cache those 137 results and provides recommendations on when this protocol extension 138 should be used. 140 At least a dozen different client and server implementations had been 141 written based on the original specification, first known as draft- 142 vandergaast-edns-client-subnet [1]. The protocol is in active 143 production use among several major Internet companies, a subset of 144 which are listed at http://www.afasterinternet.com/participants.htm . 145 While they interoperate for the primary goal, they have varying 146 behaviour around poorly specified edge cases. Known 147 incompatibilities will be described. The authors believe that it is 148 better to document this system, even if not everyone agrees with the 149 concept or the details of the original specification, rather than 150 leave it undocumented and proprietary. 152 2. Privacy Note 154 If we were just beginning to design this mechanism, and not 155 documenting existing protocol, it is unlikely that we would have done 156 things exactly this way. 158 The IETF is actively working on enhancing DNS privacy [3], and the 159 re-injection of metadata has been identified as a problematic design 160 pattern [4]. 162 As noted above, however, this document primarily describes existing 163 behavior of a deployed method, to further the understanding of the 164 Internet community. 166 We encourage the deployment of means to allow users to make use of 167 the opt-out provided. We also recommend that others avoid techniques 168 that may introduce additional metadata in future work, as it may 169 damage user trust. 171 3. Requirements Notation 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 4. Terminology 179 ECS EDNS Client Subnet. 181 Client A Stub Resolver, Forwarder or Recursive Resolver. A client 182 to a Recursive Resolver or a Forwarder. 184 Server A Forwarder, Recursive Resolver or Authoritative Nameserver. 186 Stub Resolver: A simple DNS protocol implementation on the client 187 side as described in [RFC1034] section 5.3.1. A client to a 188 Recursive Resolver or a Forwarder. 190 Authoritative Nameserver: A nameserver that has authority over one 191 or more DNS zones. These are normally not contacted by Stub 192 Resolver or end user clients directly but by Recursive Resolvers. 193 Described in [RFC1035] Section 6. 195 Recursive Resolver: A nameserver that is responsible for resolving 196 domain names for clients by following the domain's delegation 197 chain. Recursive Resolvers frequently use caches to be able to 198 respond to client queries quickly. Described in [RFC1035] 199 Section 7. 201 Intermediate Nameserver: Any nameserver (possibly a Recursive 202 Resolver) in between the Stub Resolver and the Authoritative 203 Nameserver. 205 Centralized Resolvers: Recursive Resolvers that serve a 206 topologically diverse network address space. 208 Tailored Response: A response from a nameserver that is customized 209 for the node that sent the query, often based on performance (i.e. 210 lowest latency, least number of hops, topological distance, ...). 212 Topologically Close: Refers to two hosts being close in terms of 213 number of hops or time it takes for a packet to travel from one 214 host to the other. The concept of topological distance is only 215 loosely related to the concept of geographical distance: two 216 geographically close hosts can still be very distant from a 217 topological perspective, and two geographically distant hosts can 218 be quite close on the network. 220 5. Overview 222 The general idea of this document is to provide an EDNS0 option to 223 allow Recursive Resolvers, if they are willing, to forward details 224 about the origin network from which a query is coming when talking to 225 other Nameservers. 227 The format of this option is described in Section 6, and is meant to 228 be added in queries sent by Intermediate Nameservers in a way 229 transparent to Stub Resolvers and end users, as described in 230 Section 7.1. ECS is only defined for the Internet (IN) DNS class. 232 As described in Section 7.2, an Authoritative Nameserver could use 233 this EDNS0 option as a hint to better locate the network of the end 234 user and provide a better answer. 236 Its response would contain an edns-client-subnet (ECS) option, 237 clearly indicating that the server made use of this information, and 238 that the answer is tied to the network of the client. 240 As described in Section 7.3, Intermediate Nameservers would use this 241 information to cache the response. 243 Some Intermediate Nameservers may also have to be able to forward ECS 244 queries they receive. This is described in Section 7.5. 246 The mechanisms provided by ECS raise various security related 247 concerns related to cache growth, the ability to spoof EDNS0 options, 248 and privacy. Section 11 explores various mitigation techniques. 250 The expectation, however, is that this option will primarily be used 251 between Recursive Resolvers and Authoritative Nameservers that are 252 sensitive to network location issues. Most Recursive Resolvers, 253 Authoritative Nameservers and Stub Resolvers will never need to know 254 about this option, and will continue working as they had been. 256 Failure to support this option or its improper handling will, at 257 worst, cause suboptimal identification of client location, which is a 258 common occurrence in current content delivery network (CDN) setups. 260 Section 7.1 also provides a mechanism for Stub Resolvers to signal 261 Recursive Resolvers that they do not want ECS treatment for specific 262 queries. 264 Additionally, operators of Intermediate Nameservers with ECS enabled 265 are allowed to choose how many bits of the address of received 266 queries to forward, or to reduce the number of bits forwarded for 267 queries already including an ECS option. 269 6. Option Format 271 This protocol uses an EDNS0 [RFC6891]) option to include client 272 address information in DNS messages. The option is structured as 273 follows: 275 +0 (MSB) +1 (LSB) 276 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 277 0: | OPTION-CODE | 278 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 279 2: | OPTION-LENGTH | 280 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 281 4: | FAMILY | 282 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 283 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 284 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 285 7: | ADDRESS... / 286 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 288 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 289 0x08). 291 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 292 length of the payload (everything after OPTION-LENGTH) in octets. 294 o FAMILY, 2 octets, indicates the family of the address contained in 295 the option, using address family codes as assigned by IANA in 296 IANA-AFI [5]. 298 The format of the address part depends on the value of FAMILY. This 299 document only defines the format for FAMILY 1 (IP version 4) and 2 300 (IP version 6), which are as follows: 302 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost 303 significant bits of ADDRESS to be used for the lookup. In 304 responses, it mirrors the same value as in the queries. 306 o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost 307 significant bits of ADDRESS that the response covers. In queries, 308 it MUST be set to 0. 310 o ADDRESS, variable number of octets, contains either an IPv4 or 311 IPv6 address, depending on FAMILY, which MUST be truncated to the 312 number of bits indicated by the SOURCE PREFIX-LENGTH field, 313 padding with 0 bits to pad to the end of the last octet needed. 315 o A server receiving an ECS option that uses more ADDRESS octets 316 than are needed, or that has non-zero bits set beyond SOURCE 317 PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a 318 signal to the developer of the software making the request to fix 319 their implementation. 321 All fields are in network byte order ("big-endian", per [RFC1700], 322 Data Notation). 324 7. Protocol Description 326 7.1. Originating the Option 328 The ECS option should generally be added by Recursive Resolvers when 329 querying Authoritative Nameservers, as described in Section 12. The 330 option can also be initialized by a Stub Resolver or Forwarder. 332 7.1.1. Recursive Resolvers 334 The setup of the ECS option in a Recursive Resolver depends on the 335 client query that triggered the resolution process. 337 In the usual case, where no ECS option was present in the client 338 query, the Recursive Resolver initializes the option by setting the 339 FAMILY of the client's address. It then uses the value of its 340 maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For 341 privacy reasons, and because the whole IP address is rarely required 342 to determine a tailored response, this length SHOULD be shorter than 343 the full address, as described in Section 11. 345 If the triggering query included an ECS option itself, it MUST be 346 examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's 347 outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of 348 the incoming query's SOURCE PREFIX-LENGTH or the server's maximum 349 cacheable prefix length. 351 Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the 352 ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits, 353 with trailing 0 bits added, if needed, to fill the final octet. The 354 total number of octets used MUST only be enough to cover SOURCE 355 PREFIX-LENGTH bits, rather than the full width that would normally be 356 used by addresses in FAMILY. 358 FAMILY and ADDRESS information MAY be used from the ECS option in the 359 incoming query. Passing the existing address data is supportive of 360 the Recursive Resolver being used as the target of a Forwarder, but 361 could possibly run into policy problems with regard to usage 362 agreements between the Recursive Resolver and Authoritative 363 Namserver. See Section 12.2 for more discussion on this point. If 364 the Recursive Resolver will not forward the FAMILY and ADDRESS data 365 from the incoming ECS option, it SHOULD return a REFUSED response. 366 An ECS-aware resolver MUST retry the query without ECS to distinguish 367 the response from a lame delegation, which is the common convention 368 for a REFUSED status. 370 Subsequent queries to refresh the data MUST, if unrestricted by an 371 incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- 372 LENGTH that the Recursive Resolver is willing to cache, even if a 373 previous response indicated that a shorter prefix length was 374 sufficient. 376 7.1.2. Stub Resolvers 378 A Stub Resolver MAY generate DNS queries with an ECS option set to 379 indicate its own level of privacy via SOURCE PREFIX-LENGTH. An 380 Intermediate Nameserver that receives such a query MUST NOT make 381 queries that include more bits of client address than in the 382 originating query. 384 A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add 385 address information of the client to its queries. The subsequent 386 Recursive Resolver query to the Authoritative Nameserver will then 387 either not include an ECS option or MAY optionally include its own 388 address information, which is what the Authoritative Nameserver will 389 almost certainly use to generate any Tailored Response in lieu of an 390 option. This allows the answer to be handled by the same caching 391 mechanism as other queries, with an explicit indicator of the 392 applicable scope. Subsequent Stub Resolver queries for /0 can then 393 be answered from this cached response. 395 A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include 396 FAMILY and ADDRESS data, but should be prepared to handle a REFUSED 397 response if the Intermediate Nameserver that it queries has a policy 398 that denies forwarding of the ADDRESS. If there is no ADDRESS set, 399 FAMILY MUST be set to 0. 401 7.1.3. Forwarders 403 Forwarders essentially appear to be Stub Resolvers to whatever 404 Recursive Resolver is ultimately handling the query, but look like a 405 Recursive Resolver to their client. A Forwarder using this option 406 MUST prepare it as described in the Section 7.1.1 section above. In 407 particular, a Forwarder that implements this protocol MUST honor 408 SOURCE PREFIX-LENGTH restrictions indicated in the incoming query 409 from its client. See also Section 7.5. 411 Since the Recursive Resolver it contacts will essentially treat it as 412 a Stub Resolver, the Forwarder must be prepared for a REFUSED 413 response if the Recursive Resolver does not permit incoming ADDRESS 414 information. The Forwarded MUST retry with FAMILY and ADDRESS set to 415 0. 417 7.2. Generating a Response 419 7.2.1. Authoritative Nameserver 421 When a query containing an ECS option is received, an Authoritative 422 Nameserver supporting ECS MAY use the address information specified 423 in the option in order to generate a tailored response. 425 Authoritative Nameservers that have not implemented or enabled 426 support for the ECS option ought to safely ignore it within incoming 427 queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include 428 an ECS option within replies, to indicate lack of support for it. 429 Implementers of Intermediate Nameservers should be aware, however, 430 that some nameservers incorrectly echo back unknown EDNS0 options. 431 In this protocol that should be mostly harmless, as SCOPE PREFIX- 432 LENGTH should come back as 0, thus marking the response as covering 433 all networks. 435 A query with a wrongly formatted option (e.g., an unknown FAMILY) 436 MUST be rejected and a FORMERR response MUST be returned to the 437 sender, as described by [RFC6891], Transport Considerations. 439 An Authoritative Nameserver that implements this protocol and 440 receives an ECS option MUST include an ECS option in its response to 441 indicate that it SHOULD be cached accordingly, regardless of whether 442 the client information was needed to formulate an answer. (Note that 443 the [RFC6891] requirement to reserve space for the OPT record could 444 mean that the answer section of the response will be truncated and 445 fallback to TCP indicated accordingly.) If an ECS option was not 446 included in a query, one MUST NOT be included in the response even if 447 the server is providing a Tailored Response -- presumably based on 448 the address from which it received the query. 450 The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST 451 match those in the query, unless the query specified only the SOURCE 452 PREFIX-LENGTH for privacy (with FAMILY and ADDRESS set to 0). 453 Echoing back these values helps to mitigate certain attack vectors, 454 as described in Section 11. 456 The SCOPE PREFIX-LENGTH in the response indicates the network for 457 which the answer is intended. 459 A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH 460 indicates that the provided prefix length was not specific enough to 461 select the most appropriate Tailored Response. Future queries for 462 the name within the specified network SHOULD use the longer SCOPE 463 PREFIX-LENGTH. 465 Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits 466 than necessary were provided, and the answer is suitable for a 467 broader range of addresses. This could be as short as 0, to indicate 468 that the answer is suitable for all addresses in FAMILY. 470 As the logical topology of any part of the network with regard to the 471 tailored response can vary, an Authoritative Nameserver may return 472 different values of SCOPE PREFIX-LENGTH for different networks. 474 Since some queries can result in multiple RRsets being added to the 475 response, there is an unfortunate ambiguity from the original draft 476 as to how SCOPE PREFIX-LENGTH would apply to each individual RRset. 477 For example, multiple types in response to an ANY metaquery could all 478 have different applicable SCOPE PREFIX-LENGTH values, but this 479 protocol only has the ability to signal one. The response SHOULD 480 therefore include the longest relevant PREFIX-LENGTH of any RRset in 481 the answer, which could have the unfortunate side-effect of 482 redundantly caching some data that could be cached more broadly. For 483 the specific case of a CNAME chain, the Authoritative Nameserver 484 SHOULD only place the CNAME to have it cached unambiguously 485 appropriately. Most modern Recursive Resolvers restart the query 486 with the canonical name, so the remainder of the chain is typically 487 ignored anyway. For message-focused resolvers, rather than RRset- 488 focused ones, this will mean caching the entire CNAME chain at the 489 longest PREFIX-LENGTH of any RRset in the chain. 491 The specific logic that an Authoritative Nameserver uses to choose a 492 tailored response is not in the scope of this document. Implementers 493 are encouraged, however, to consider carefully their selection of 494 SCOPE PREFIX-LENGTH for the response in the event that the best 495 tailored response cannot be determined, and what the implications 496 would be over the life of the TTL. 498 If the Authoritative Nameserver operator configures a more specific 499 (longer prefix length) Tailored Response within a configured less 500 specific (shorter prefix length) Tailored Response, then 501 implementations can either: 503 1. Deaggregate the shorter prefix response into multiple longer 504 prefix responses, or, 506 2. Alert the operator that the order of queries will determine which 507 answers get cached, and either warn and continue or treat this as 508 an error and refuse to load the configuration. 510 Implementations SHOULD document their chosen behavior. 512 7.2.2. Intermediate Nameserver 514 When an Intermediate Nameserver uses ECS, whether it passes an ECS 515 option in its own response to its client is predicated on whether the 516 client originally included the option. Because a client that did not 517 use an ECS option might not be able to understand it, the server MUST 518 NOT provide one in its response. If the client query did include the 519 option, the server MUST include one in its response, especially as it 520 could be talking to a Forwarder which would need the information for 521 its own caching. 523 If an Intermediate Nameserver receives a response which has a longer 524 SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in 525 its query, it SHOULD still provide the result as the answer to the 526 triggering client request even if the client is in a different 527 address range. The Intermediate Nameserver MAY instead opt to retry 528 with a longer SOURCE PREFIX-LENGTH to get a better reply before 529 responding to its client, as long as it does not exceed a SOURCE 530 PREFIX-LENGTH specified in the query that triggered resolution, but 531 this obviously has implications for the latency of the overall 532 lookup. 534 The logic for using the cache to determine whether the Intermediate 535 Nameserver already knows the response to provide to its client is 536 covered in the next section. 538 7.3. Handling ECS Responses and Caching 540 When an Intermediate Nameserver receives a response containing an ECS 541 option and without the TC bit set, it SHOULD cache the result based 542 on the data in the option. If the TC bit was set, the Intermediate 543 Resolver SHOULD retry the query over TCP to get the complete answer 544 section for caching. 546 If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of 547 ADDRESS in the response don't match the non-zero fields in the 548 corresponding query, the full response MUST be dropped, as described 549 in Section 11. For a response to a query which specified only the 550 SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS 551 fields should contain the appropriate non-zero information for 552 caching. 554 If no ECS option is contained in the response, the Intermediate 555 Nameserver SHOULD treat this as being equivalent to having received a 556 SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client 557 addresses. See further discussion on the security implications of 558 this in Section 11. 560 7.3.1. Caching the Response 562 In the cache, all resource records in the answer section MUST be tied 563 to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- 564 LENGTH fields, as limited by the Intermediate Nameserver's own 565 configuration for maximum cacheable prefix length. Note that the 566 additional and authority sections from a DNS response message are 567 specifically excluded here. Any records from these sections MUST NOT 568 be tied to a network. See more at Section 7.4. 570 Records that are cached as /0 because of a query's SOURCE PREFIX- 571 LENGTH of 0 MUST be distinguished from those that are cached as /0 572 because of a response's SCOPE PREFIX-LENGTH of 0. The former should 573 only be used for other /0 queries that the Intermediate Resolver 574 receives, but the latter is suitable as a response for all networks. 576 Although omitting network-specific caching will significantly 577 simplify an implementation, the resulting drop in cache hits is very 578 likely to defeat most latency benefits provided by ECS. Therefore, 579 when implementing this option for latency purposes, implementing full 580 caching support as described in this section is strongly recommended. 582 Enabling support for ECS in an Intermediate Nameserver will 583 significantly increase the size of the cache, reduce the number of 584 results that can be served from cache, and increase the load on the 585 server. Implementing the mitigation techniques described in 586 Section 11 is strongly recommended. 588 7.3.2. Answering from Cache 590 Cache lookups are first done as usual for a DNS query, using the 591 query tuple of . Then the appropriate RRset MUST 592 be chosen based on longest prefix matching. The client address to 593 use for comparison will depend on whether the Intermediate Nameserver 594 received an ECS option in its client query. 596 o If no ECS option was provided, the client's address is used. 598 o If there was an ECS option, the ADDRESS from it MAY be used if 599 local policy allows. Policy can vary depending on the agreements 600 the operator of the Intermediate Nameserver has with Authoritative 601 Nameserver operators; see Section 12.2. If policy does not allow, 602 a REFUSED response must be sent. 604 If a matching network is found and the relevant data is unexpired, 605 the response is generated as per Section 7.2. 607 If no matching network is found, the Intermediate Nameserver MUST 608 perform resolution as usual. This is necessary to avoid Tailored 609 Responses in the cache from being returned to the wrong clients, and 610 to avoid a single query coming from a client on a different network 611 from polluting the cache with a Tailored Response for all the users 612 of that resolver. 614 7.4. Delegations and Negative Answers 616 The prohibition against tying ECS data to records from the Authority 617 and Additional section left an unfortunate ambiguity in the original 618 specification, primarily with regard to negative answers. The 619 expectation of the original authors was that ECS would only really be 620 used for address records, the use case that was driving the 621 definition of the protocol. 623 The delegations case is a bit easier to tease out. In operational 624 practice, if an authoritative server is using address information to 625 provide customized delegations, it is the resolver that will be using 626 the answer for its next iterative query. Addresses in the Additional 627 section SHOULD therefore ignore ECS data, and the authority SHOULD 628 return a zero SCOPE PREFIX-LENGTH on delegations. A recursive 629 resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation 630 as though it were zero. 632 For negative answers, some independent implementations of both 633 resolvers and authorities did not see the section restriction as 634 necessarily meaning that a given name and type must only have either 635 positive ECS-tagged answers or a negative answer. They support being 636 able to tell one part of the network that the data does not exist, 637 while telling another part of the network that it does. 639 Several other implementations, however, do not support being able to 640 mix positive and negative answers, and thus interoperability is a 641 problem. 643 This issue is expected to be revisited in a future revision of the 644 protocol, possibly blessing the mixing of positive and negative 645 answers. There are implications for cache data structures that 646 developers should consider when writing new ECS code. 648 7.5. Transitivity 650 Generally, ECS options will only be present in DNS messages between a 651 Recursive Resolver and an Authoritative Nameserver, i.e., one hop. 652 In certain configurations however, for example multi-tier nameserver 653 setups, it may be necessary to implement transitive behaviour on 654 Intermediate Nameservers. 656 It is important that any Intermediate Nameserver that forwards ECS 657 options received from their clients MUST fully implement the caching 658 behaviour described in Section 7.3. 660 Intermediate Nameservers supporting ECS MUST forward options with 661 SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such 662 options MUST NOT be replaced with more accurate address information. 664 An Intermediate Nameserver MAY also forward ECS options with actual 665 address information. This information MAY match the source IP 666 address of the incoming query, and MAY have more or fewer address 667 bits than the Nameserver would normally include in a locally 668 originated ECS option. 670 If for any reason the Intermediate Nameserver does not want to use 671 the information in an ECS option it receives (too little address 672 information, network address from a range not authorized to use the 673 server, private/unroutable address space, etc), it SHOULD drop the 674 query and return a REFUSED response. Note again that a query MUST 675 NOT be refused solely because it provides 0 address bits. 677 Be aware that at least one major existing implementation does not 678 return REFUSED and instead just process the query as though the 679 problematic information were not present. This can lead to anomalous 680 situations, such as a response from the Intermediate Nameserver that 681 indicates it is tailored for one network (the one passed in the 682 original query, since ADDRESS must match) when actually it is for 683 another network (the one which contains the address that the 684 Intermediate Nameserver saw as making the query). 686 8. IANA Considerations 688 IANA has already assigned option code 8 in the "DNS EDNS0 Option 689 Codes (OPT)" registry to ECS. 691 The IANA is requested to update the reference ("draft-vandergaast- 692 edns-client-subnet") to refer to this RFC when published. 694 9. DNSSEC Considerations 696 The presence or absence of an [RFC6891] EDNS0 OPT resource record 697 containing an ECS option in a DNS query does not change the usage of 698 the resource records and mechanisms used to provide data origin 699 authentication and data integrity to the DNS, as described in 700 [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. 702 Use of this option, however, does imply increased DNS traffic between 703 any given Recursive Resolver and Authoritative Nameserver, which 704 could be another barrier to further DNSSEC adoption in this area. 706 10. NAT Considerations 708 Special awareness of ECS in devices that perform Network Address 709 Translation (NAT) as described in [RFC2663] is not required; queries 710 can be passed through as-is. The client's network address SHOULD NOT 711 be added, and existing ECS options, if present, SHOULD NOT be 712 modified by NAT devices. 714 In large-scale global networks behind a NAT device (but for example 715 with Centralized Resolver infrastructure), an internal Intermediate 716 Nameserver might have detailed network layout information, and may 717 know which external subnets are used for egress traffic by each 718 internal network. In such cases, the Intermediate Nameserver MAY use 719 that information when originating ECS options. 721 In other cases, Recursive Resolvers sited behind a NAT device SHOULD 722 NOT originate ECS options with their external IP address, and instead 723 rely on downstream Intermediate Nameservers to do so. They MAY, 724 however, choose to include the option with their internal address for 725 the purposes of signaling a shorter, more anonymous SOURCE PREFIX- 726 LENGTH. 728 If an Authoritative Nameserver on the publicly routed Internet 729 receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] 730 private address space, it SHOULD ignore ADDRESS and look up its 731 answer based on the address of the Recursive Resolver. In the 732 response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the 733 relevant private space. For example, a query for ADDRESS 10.1.2.0 734 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX- 735 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the 736 answer under one entry for special-purpose addresses [RFC6890]; see 737 Section 11.3. 739 11. Security Considerations 741 11.1. Privacy 743 With the ECS option, the network address of the client that initiated 744 the resolution becomes visible to all servers involved in the 745 resolution process. Additionally, it will be visible from any 746 network traversed by the DNS packets. 748 To protect users' privacy, Recursive Resolvers are strongly 749 encouraged to conceal part of the IP address of the user by 750 truncating IPv4 addresses to 24 bits. 56 bits are recommended for 751 IPv6, based on [RFC6177]. 753 ISPs should have more detailed knowledge of their own networks. That 754 is, they might know that all 24-bit prefixes in a /20 are in the same 755 area. In those cases, for optimal cache utilization and improved 756 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 757 this /20 to just 20 bits, instead of 24 as recommended above. 759 Users who wish their full IP address to be hidden can include an ECS 760 option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 761 0). As described in previous sections, this option will be forwarded 762 across all the Recursive Resolvers supporting ECS, which MUST NOT 763 modify it to include the network address of the client. 765 Note that even without an ECS option, any server queried directly by 766 the user will be able to see the full client IP address. Recursive 767 Resolvers or Authoritative Nameservers MAY use the source IP address 768 of queries to return a cached entry or to generate a Tailored 769 Response that best matches the query. 771 11.2. Birthday Attacks 773 ECS adds information to the DNS query tupe (q-tuple). This allows an 774 attacker to send a caching Intermediate Nameserver multiple queries 775 with spoofed IP addresses either in the ECS option or as the source 776 IP. These queries will trigger multiple outgoing queries with the 777 same name, type and class, just different address information in the 778 ECS option. 780 With multiple queries for the same name in flight, the attacker has a 781 higher chance of success to send a matching response with the SCOPE 782 PREFIX-LENGTH set to 0 to get it cached for all hosts. 784 To counter this, the ECS option in a response packet MUST contain the 785 full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the 786 corresponding query. Intermediate Nameservers processing a response 787 MUST verify that these match, and SHOULD discard the entire response 788 if they do not. 790 That requirement to discard is "SHOULD" instead of "MUST" because it 791 stands in opposition to the instruction in Section 7.3 which states 792 that a response lacking an ECS option should be treated as though it 793 had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an 794 attacker does not need to worry about matching the original ECS 795 option data and just needs to flood back responses that have no ECS 796 option at all. 798 This type of attack could be detected in ongoing operations by 799 marking whether the responding nameserver had previously been sending 800 ECS option, and/or by taking note of an incoming flood of bogus 801 responses and flagging the relevant query for re-resolution. This is 802 more complex than existing nameserver responses to spoof floods, and 803 would also need to be sensitive to a nameserver legitimately stopping 804 ECS replies even though it had previously given them. 806 11.3. Cache Pollution 808 It is simple for an arbitrary resolver or client to provide false 809 information in the ECS option, or to send UDP packets with forged 810 source IP addresses. 812 This could be used to: 814 o pollute the cache of intermediate resolvers, by filling it with 815 results that will rarely (if ever) be used. 817 o reverse engineer the algorithms (or data) used by the 818 Authoritative Nameserver to calculate Tailored Responses. 820 o mount a denial-of-service attack against an Intermediate 821 Nameserver, by forcing it to perform many more recursive queries 822 than it would normally do, due to how caching is handled for 823 queries containing the ECS option. 825 Even without malicious intent, Centralized Resolvers providing 826 answers to clients in multiple networks will need to cache different 827 responses for different networks, putting more memory pressure on the 828 cache. 830 To mitigate those problems: 832 o Recursive Resolvers implementing ECS should only enable it in 833 deployments where it is expected to bring clear advantages to the 834 end users. For example, when expecting clients from a variety of 835 networks or from a wide geographical area. Due to the high cache 836 pressure introduced by ECS, the feature SHOULD be disabled in all 837 default configurations. 839 o Recursive Resolvers SHOULD limit the number of networks and 840 answers they keep in the cache for any given query. 842 o Recursive Resolvers SHOULD limit the number of total different 843 networks that they keep in cache. 845 o Recursive Resolvers MUST never send an ECS option with a SOURCE 846 PREFIX-LENGTH providing more bits in the ADDRESS than they are 847 willing to cache responses for. 849 o Recursive Resolvers should implement algorithms to improve the 850 cache hit rate, given the size constraints indicated above. 851 Recursive Resolvers MAY, for example, decide to discard more 852 specific cache entries first. 854 o Authoritative Nameservers and Recursive Resolvers should discard 855 ECS options that are either obviously forged or otherwise known to 856 be wrong. They SHOULD at least treat unroutable addresses, such 857 as some of the address blocks defined in [RFC6890], as equivalent 858 to the Recursive Resolver's own identity. They SHOULD ignore and 859 never forward ECS options specifying other routable addresses that 860 are known not to be served by the query source. 862 o Authoritative Nameservers consider the ECS option just as a hint 863 to provide better results. They can decide to ignore the content 864 of the ECS option based on black or white lists, rate limiting 865 mechanisms, or any other logic implemented in the software. 867 12. Sending the Option 869 When implementing a Recursive Resolver, there are two strategies on 870 deciding when to include an ECS option in a query. At this stage, 871 it's not clear which strategy is best. 873 12.1. Probing 875 A Recursive Resolver can send the ECS option with every outgoing 876 query. However, it is RECOMMENDED that Resolvers remember which 877 Authoritative Nameservers did not return the option with their 878 response, and omit client address information from subsequent queries 879 to those Nameservers. 881 Additionally, Recursive Resolvers SHOULD be configured to never send 882 the option when querying root, top-level, and effective top-level 883 domain servers. These domains are delegation-centric and are very 884 unlikely to generate different responses based on the address of the 885 client. 887 When probing, it is important that several things are probed: support 888 for ECS, support for EDNS0, support for EDNS0 options, or possibly an 889 unreachable Nameserver. Various implementations are known to drop 890 DNS packets with OPT RRs (with or without options), thus several 891 probes are required to discover what is supported. 893 Probing, if implemented, MUST be repeated periodically, e.g., daily. 894 If an Authoritative Nameserver indicates ECS support for one zone, it 895 is to be expected that the Nameserver supports ECS for all of its 896 zones. Likewise, an Authoritative Nameserver that uses ECS 897 information for one of its zones, MUST indicate support for the 898 option in all of its responses to ECS queries. If the option is 899 supported but not actually used for generating a response, its SCOPE 900 PREFIX-LENGTH MUST be set to 0. 902 12.2. Whitelist 904 As described previously, it is expected that only a few Recursive 905 Resolvers will need to use ECS, and that it will generally be enabled 906 only if it offers a clear benefit to the users. 908 To avoid the complexity of implementing a probing and detection 909 mechanism (and the possible query loss/delay that may come with it), 910 an implementation could use a whitelist of Authoritative Namesevers 911 to send the option to, likely specified by their domain name. 912 Implementations MAY also allow additionally configuring this based on 913 other criteria, such as zone or query type. As of the time of this 914 writing, at least one implemetaion makes use of a whitelist. 916 An advantage of using a whitelist is that partial client address 917 information is only disclosed to Nameservers that are known to use 918 the information, improving privacy. 920 A drawback is scalability. The operator needs to track which 921 Authoritative Nameservers support ECS, making it harder for new 922 Authoritative Nameservers to start using the option. 924 Similarly, Authoritative Nameservers can also use whitelists to limit 925 the feature to only certain clients. For example, a CDN that does 926 not want all of their mapping trivially walked might require a legal 927 agreement with the Recursive Resolver operator, to clearly describe 928 the acceptable use of the feature. 930 The maintenance of access control mechanisms is out of scope for this 931 protocol definition. 933 13. Example 935 1. A stub resolver, SR, with IP address 192.0.2.37 tries to resolve 936 www.example.com, by forwarding the query to the Recursive 937 Resolver, RNS, from IP address IP, asking for recursion. 939 2. RNS, supporting ECS, looks up www.example.com in its cache. An 940 entry is found neither for www.example.com, nor for example.com. 942 3. RNS builds a query to send to the root and .com servers. The 943 implementation of RNS provides facilities so an administrator 944 can configure it not to forward ECS in certain cases. In 945 particular, RNS is configured to not include an ECS option when 946 talking to TLD or root nameservers, as described in Section 7.1. 947 Thus, no ECS option is added, and resolution is performed as 948 usual. 950 4. RNS now knows the next server to query: the Authoritative 951 Nameserver, ANS, responsible for example.com. 953 5. RNS prepares a new query for www.example.com, including an ECS 954 option with: 956 * OPTION-CODE, set to 8. 958 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 959 octets plus the 3 octets that will be used for ADDRESS. 961 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 963 * SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to 964 conceal the last 8 bits of every IPv4 address. 966 * SCOPE PREFIX-LENGTH, set to 0x00, as specified by this 967 document for all queries. 969 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 970 bits of the IPv4 address. 972 6. The query is sent. ANS understands and uses ECS. It parses the 973 ECS option, and generates a Tailored Response. 975 7. Due its internal implementation, ANS finds a response that is 976 tailored for the whole /16 of the client that performed the 977 query. 979 8. ANS adds an ECS option in the response, containing: 981 * OPTION-CODE, set to 8. 983 * OPTION-LENGTH, set to 0x00 0x07. 985 * FAMILY, set to 0x00 0x01. 987 * SOURCE PREFIX-LENGTH, set to 0x18, copied from the query. 989 * SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network. 991 * ADDRESS, set to 0xC0 0x00 0x02, copied from the query. 993 9. RNS receives the response containing an ECS option. It verifies 994 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. 995 If not, the message is discarded. 997 10. The response is interpreted as usual. Since the response 998 contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and 999 FAMILY in the response are used to cache the entry. 1001 11. RNS sends a response to stub resolver SR, without including an 1002 ECS option. 1004 12. RNS receives another query to resolve www.example.com. This 1005 time, a response is cached. The response, however, is tied to a 1006 particular network. If the address of the client matches any 1007 network in the cache, then the response is returned from the 1008 cache. Otherwise, another query is performed. If multiple 1009 results match, the one with the longest SCOPE PREFIX-LENGTH is 1010 chosen, as per common best-network match algorithms. 1012 14. Contributing Authors 1014 The below individuals contributed significantly to the draft. The 1015 RFC Editor prefers a maximum of 5 names on the front page, and so we 1016 have listed additional authors in this section 1018 Edward Lewis 1019 ICANN 1020 12025 Waterfront Drive, Suite 300 1021 Los Angeles CA 90094-2536 1022 USA 1023 Email: edward.lewis@icann.org 1025 Sean Leach 1026 Fastly 1027 POBox 78266 1028 San Francisco CA 94107 1030 Jason Moreau 1031 Akamai Technologies 1032 8 Cambridge Ctr 1033 Cambridge MA 02142-1413 1034 USA 1036 15. Acknowledgements 1038 The authors wish to thank Darryl Rodden for his work as a co-author 1039 on previous versions, and the following people for reviewing early 1040 drafts of this document and for providing useful feedback: Paul S. 1042 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 1043 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 1044 Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, 1045 Edward Lewis, and Eric Burger from Neustar; David Ulevitch and 1046 Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from 1047 Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya 1048 Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn; 1049 John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer 1050 from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin; 1051 and all of the other people that replied to our emails on various 1052 mailing lists. 1054 16. References 1056 16.1. Normative References 1058 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1059 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1060 . 1062 [RFC1035] Mockapetris, P., "Domain names - implementation and 1063 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1064 November 1987, . 1066 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1067 DOI 10.17487/RFC1700, October 1994, 1068 . 1070 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1071 and E. Lear, "Address Allocation for Private Internets", 1072 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1073 . 1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1076 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1077 RFC2119, March 1997, 1078 . 1080 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1081 Rose, "DNS Security Introduction and Requirements", RFC 1082 4033, DOI 10.17487/RFC4033, March 2005, 1083 . 1085 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1086 Rose, "Resource Records for the DNS Security Extensions", 1087 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1088 . 1090 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1091 Rose, "Protocol Modifications for the DNS Security 1092 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1093 . 1095 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1096 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1097 . 1099 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1100 Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/ 1101 RFC6177, March 2011, 1102 . 1104 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1105 "Special-Purpose IP Address Registries", BCP 153, RFC 1106 6890, DOI 10.17487/RFC6890, April 2013, 1107 . 1109 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1110 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 1111 RFC6891, April 2013, 1112 . 1114 16.2. Informative References 1116 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1117 Translator (NAT) Terminology and Considerations", RFC 1118 2663, DOI 10.17487/RFC2663, August 1999, 1119 . 1121 16.3. URIs 1123 [1] https://tools.ietf.org/html/draft-vandergaast-edns-client- 1124 subnet-00 1126 [3] https://datatracker.ietf.org/doc/charter-ietf-dprive/ 1128 [4] https://github.com/IAB-PrivSec-program/draft-iab-privsec- 1129 metadata-insertion/blob/master/draft-iab-privsec-metadata- 1130 insertion.md 1132 [5] http://www.iana.org/assignments/address-family-numbers/ 1134 Appendix A. Document History 1136 [RFC Editor: Please delete this section before publication.] 1138 -03 to -04: 1140 o Privacy note per Ted Hardie's suggestion. 1142 o MUST use minimum octet length to cover PREFIX bits. 1144 o Expose note about documenting deployed, if flawed, protocol. 1146 -02 to -03: 1148 o Some cleanup of the whitelist text. 1150 -01 to -02 (IETF) 1152 o Clean up the open issues, mostly by saying that they were out of 1153 scope for this document. 1155 o How in the world did no reviewers note that "Queries" had been 1156 spelled as "Querys" in the title? (Aaron Falk did.) 1158 -00 to -01 (IETF) 1160 o Note ambiguity with multiple RRsets appearing in reply, eg, for an 1161 ANY query or CNAME chain. (Duane Wessels) 1163 o Open issue questioning the guidance about resolvers behind a NAT. 1164 How do they know they are? What real requirement is this 1165 imposing? (Duane Wessels) 1167 o Some other wording changes based on Duane's review of an earlier 1168 draft. 1170 -IND to -00 (IETF) 1172 o Made the document describe how things are actually 1173 implmented now. This makes the document be more of a "this is how 1174 we are doing things, this provides information on that". There 1175 may be a future document that describes additional funcationality. 1177 o NETMASK was not a good desription, changed to PREFIX-LENGTH 1178 (Jinmei, others). Stole most of the definition for prefix length 1179 from RFC4291. 1181 o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include 1182 IPv6 (Tatuya Jinmei) 1184 o Comment that ECS cannot be used to hand NXDOMAIN to some clients 1185 and not others, primarily because of interoperability issues. 1186 (Tatuya Jinmei) 1188 o Added text explaining that implmentations need to document thier 1189 behavior with overlapping networks. 1191 o Soften "optimized reply" language. (Andrew Sullivan). 1193 o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0) 1195 o Some more grammar / working cleanups. 1197 o Replaced a whole heap of occurances of "edns-client-subnet" with 1198 "ECS" for readability. (John Dickinson) 1200 o More clearly describe the process from the point of view of each 1201 type of nameserver. (John Dickinson) 1203 o Birthday attack still possible if attacker floods with ECS-less 1204 responses. (Yuri Schaeffer) 1206 o Added some open issues directly to the text. 1208 A.1. -00 1210 o Document moved to experimental track, added experiment description 1211 in header with details in a new section. 1213 o Specifically note that ECS applies to the answer section only. 1215 o Warn that caching based on ECS is optional but very important for 1216 performance reasons. 1218 o Updated NAT section. 1220 o Added recommendation to not use the default /24 recommendation for 1221 the source prefix-length field if more detailed information about 1222 the network is available. 1224 o Rewritten problem statement to be more clear about the goal of ECS 1225 and the fact that it's entirely optional. 1227 o Wire format changed to include the original address and prefix 1228 length in responses in defence against birthday attacks. 1230 o Security considerations now includes a section about birthday 1231 attacks. 1233 o Renamed edns-client-ip in ECS, following suggestions on the 1234 mailing list. 1236 o Clarified behavior of resolvers when presented with an invalid ECS 1237 option. 1239 o Fully take multi-tier DNS setups in mind and be more clear about 1240 where the option should be originated. 1242 o A note on Authoritative Nameservers receiving queries that specify 1243 private address space. 1245 o A note to always ask for the longest acceptable SOURCE prefix 1246 length, even if a prior answer indicated that a shorter prefix 1247 length was suitable. 1249 o Marked up a few more references. 1251 o Added a few definitions in the Terminology section, and a few more 1252 aesthetic changes in the rest of the document. 1254 A.2. -01 1256 o Document version number reset from -02 to -00 due to the rename to 1257 ECS. 1259 o Clarified example (dealing with TLDs, and various minor errors). 1261 o Referencing RFC5035 instead of RFC1918. 1263 o Added a section on probing (and how it should be done) vs. 1264 whitelisting. 1266 o Moved description on how to forward ECS option in dedicated 1267 section. 1269 o Queries with wrongly formatted ECS options should now be rejected 1270 with FORMERR. 1272 o Added an "Overview" section, providing an introduction to the 1273 document. 1275 o Intermediate Nameservers can now remove an ECS option, or reduce 1276 the SOURCE PREFIX-LENGTH to increase privacy. 1278 o Added a reference to DoS attacks in the Security section. 1280 o Don't use "network range", as it seems to have different meaning 1281 in other contexts, and turned out to be confusing. 1283 o Use shorter and longer prefix lengths, rather than higher or 1284 lower. Add a better explanation in the format section. 1286 o Minor corrections in various other sections. 1288 A.3. -02 1290 o Added IANA-assigned option code. 1292 Authors' Addresses 1294 Carlo Contavalli 1295 Google 1296 1600 Amphitheater Parkway 1297 Mountain View, CA 94043 1298 US 1300 Email: ccontavalli@google.com 1302 Wilmer van der Gaast 1303 Google 1304 Belgrave House, 76 Buckingham Palace Road 1305 London SW1W 9TQ 1306 UK 1308 Email: wilmer@google.com 1310 David C Lawrence 1311 Akamai Technologies 1312 8 Cambridge Center 1313 Cambridge, MA 02142 1314 US 1316 Email: tale@akamai.com 1317 Warren Kumari 1318 Google 1319 1600 Amphitheatre Parkway 1320 Mountain View, CA 94043 1321 US 1323 Email: warren@kumari.net