idnits 2.17.00 (12 Aug 2021) /tmp/idnits38322/draft-ietf-dnsop-edns-client-subnet-01.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 (May 26, 2015) is 2552 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 282 -- Looks like a reference, but probably isn't: '1' on line 1067 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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: November 27, 2015 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 May 26, 2015 11 Client Subnet in DNS Querys 12 draft-ietf-dnsop-edns-client-subnet-01 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 IESG Note 22 [RFC Editor: Please remove this note prior to publication ] 24 This informational document describes an existing, implemented and 25 deployed system. A subset of the operators using this is at 26 http://www.afasterinternet.com/participants.htm . The authors believe 27 that it is better to document this system (even if not everyone 28 agrees with the concept) than leave it undocumented and proprietary. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 27, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 71 6.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 7 72 6.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 8 73 6.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9 74 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 75 6.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9 76 6.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 10 77 6.3. Handling ECS Responses and Caching . . . . . . . . . . . 11 78 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 11 79 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 12 80 6.4. Delegations and Negative Answers . . . . . . . . . . . . 13 81 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 14 84 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 15 87 10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 16 88 10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 17 89 11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 18 90 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 18 91 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19 92 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 97 15.2. Informative References . . . . . . . . . . . . . . . . . 23 98 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 Appendix A. Document History . . . . . . . . . . . . . . . . . . 23 100 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 105 1. Introduction 107 Many Authoritative Nameservers today return different responses based 108 on the perceived topological location of the user. These servers use 109 the IP address of the incoming query to identify that location. 110 Since most queries come from intermediate Recursive Resolvers, the 111 source address is that of the Recursive Resolver rather than of the 112 query originator. 114 Traditionally, and probably still in the majority of instances, 115 Recursive Resolvers are reasonably close in the topological sense to 116 the Stub Resolvers or Forwarders that are the source of queries. For 117 these resolvers, using their own IP address is sufficient for 118 authority servers that tailor responses based upon location of the 119 querier. 121 Increasingly, though, a class of Recursive Resolvers has arisen that 122 handle query sources that are often not topologically close. The 123 motivation for a user to configure such a Centralized Resolver varies 124 but is usually because of some enhanced experience, such as greater 125 cache security or applying policies regarding where users may 126 connect. (Although political censorship usually comes to mind here, 127 the same actions may be used by a parent when setting controls on 128 where a minor may connect.) Similarly, many ISPs and other 129 organizations use a Centralized Resolver infrastructure that can be 130 distant from the clients the resolvers serve. These cases all lead 131 to less than desirable responses from topology-sensitive 132 Authoritative Nameservers. 134 This draft defines an EDNS0 [RFC6891] option to convey network 135 information that is relevant to the DNS message. It will carry 136 sufficient network information about the originator for the 137 Authoritative Nameserver to tailor responses. It will also provide 138 for the Authoritative Nameserver to indicate the scope of network 139 addresses for which the tailored answer is intended. This EDNS0 140 option is intended for those recursive and authority servers that 141 would benefit from the extension and not for general purpose 142 deployment. It is completely optional and can safely be ignored by 143 servers that choose not to implement it or enable it. 145 This draft also includes guidelines on how to best cache those 146 results and provides recommendations on when this protocol extension 147 should be used. 149 At least a dozen different client and server implementations had been 150 written based on the original specification, first known as draft- 151 vandergaast-edns-client-subnet. While they interoperate for the 152 primary goal, they have varying behaviour around poorly specified 153 edge cases. Known incompatibilities will be described. 155 2. Requirements Notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Terminology 163 ECS EDNS Client Subnet. 165 Client A Stub Resolver, Forwarder or Recursive Resolver. A client 166 to a Recursive Resolver or a Forwarder. 168 Server A Forwarder, Recursive Resolver or Authoritative Nameserver. 170 Stub Resolver: A simple DNS protocol implementation on the client 171 side as described in [RFC1034] section 5.3.1. A client to a 172 Recursive Resolver or a Forwarder. 174 Authoritative Nameserver: A nameserver that has authority over one 175 or more DNS zones. These are normally not contacted by Stub 176 Resolver or end user clients directly but by Recursive Resolvers. 177 Described in [RFC1035] Section 6. 179 Recursive Resolver: A nameserver that is responsible for resolving 180 domain names for clients by following the domain's delegation 181 chain. Recursive Resolvers frequently use caches to be able to 182 respond to client queries quickly. Described in [RFC1035] 183 Section 7. 185 Intermediate Nameserver: Any nameserver (possibly a Recursive 186 Resolver) in between the Stub Resolver and the Authoritative 187 Nameserver. 189 Centralized Resolvers: Recursive Resolvers that serve a 190 topologically diverse network address space. 192 Tailored Response: A response from a nameserver that is customized 193 for the node that sent the query, often based on performance (i.e. 194 lowest latency, least number of hops, topological distance, ...). 196 Topologically Close: Refers to two hosts being close in terms of 197 number of hops or time it takes for a packet to travel from one 198 host to the other. The concept of topological distance is only 199 loosely related to the concept of geographical distance: two 200 geographically close hosts can still be very distant from a 201 topological perspective, and two geographically distant hosts can 202 be quite close on the network. 204 4. Overview 206 The general idea of this document is to provide an EDNS0 option to 207 allow Recursive Resolvers, if they are willing, to forward details 208 about the origin network from which a query is coming when talking to 209 other Nameservers. 211 The format of this option is described in Section 5, and is meant to 212 be added in queries sent by Intermediate Nameservers in a way 213 transparent to Stub Resolvers and end users, as described in 214 Section 6.1. ECS is only defined for the Internet (IN) DNS class. 216 As described in Section 6.2, an Authoritative Nameserver could use 217 this EDNS0 option as a hint to better locate the network of the end 218 user and provide a better answer. 220 Its response would contain an edns-client-subnet (ECS) option, 221 clearly indicating that the server made use of this information, and 222 that the answer is tied to the network of the client. 224 As described in Section 6.3, Intermediate Nameservers would use this 225 information to cache the response. 227 Some Intermediate Nameservers may also have to be able to forward ECS 228 queries they receive. This is described in Section 6.5. 230 The mechanisms provided by ECS raise various security related 231 concerns, related to cache growth, the ability to spoof EDNS0 232 options, and privacy. Section 10 explores various mitigation 233 techniques. 235 The expectation, however, is that this option will only be used by 236 Recursive Resolvers and Authoritative Nameservers that incur 237 geolocation issues. 239 Most Recursive Resolvers, Authoritative Nameservers and Stub 240 Resolvers will never know about this option, and will continue 241 working as they had been. 243 Failure to support this option or its improper handling will, at 244 worst, cause suboptimal identification of client location, which is a 245 common occurrence in current content delivery network (CDN) setups. 247 Section 6.1 also provides a mechanism for Stub Resolvers to signal 248 Recursive Resolvers that they do not want ECS treatment for specific 249 queries. 251 Additionally, operators of Intermediate Nameservers with ECS enabled 252 are allowed to choose how many bits of the address of received 253 queries to forward, or to reduce the number of bits forwarded for 254 queries already including an ECS option. 256 5. Option Format 258 This draft uses an EDNS0 [RFC6891]) option to include client address 259 information in DNS messages. The option is structured as follows: 261 +0 (MSB) +1 (LSB) 262 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 263 0: | OPTION-CODE | 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 2: | OPTION-LENGTH | 266 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 4: | FAMILY | 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 271 7: | ADDRESS... / 272 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 274 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 275 0x08). 277 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 278 length of the payload (everything after OPTION-LENGTH) in octets. 280 o FAMILY, 2 octets, indicates the family of the address contained in 281 the option, using address family codes as assigned by IANA in 282 IANA-AFI [2]. 284 The format of the address part depends on the value of FAMILY. This 285 document only defines the format for FAMILY 1 (IP version 4) and 2 286 (IP version 6), which are as follows: 288 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost 289 significant bits of ADDRESS to be used for the lookup. In 290 responses, it mirrors the same value as in the queries. 292 o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost 293 significant bits of ADDRESS that the response covers. In queries, 294 it MUST be set to 0. 296 o ADDRESS, variable number of octets, contains either an IPv4 or 297 IPv6 address, depending on FAMILY, truncated to the number of bits 298 indicated by the SOURCE PREFIX-LENGTH field, with bits set to 0 to 299 pad to the end of the last octet needed. Trailing all-zero octets 300 SHOULD be omitted. 302 All fields are in network byte order ("big-endian", per [RFC1700], 303 Data Notation). 305 6. Protocol Description 307 6.1. Originating the Option 309 The ECS option should generally be added by Recursive Resolvers when 310 querying Authoritative Nameservers, as described in Section 11. The 311 option can also be initialized by a Stub Resolver or Forwarder. 313 6.1.1. Recursive Resolvers 315 The setup of the ECS option in a Recursive Resolver depends on the 316 client query that triggered the resolution process. 318 In the usual case, where no ECS option was present in the client 319 query, the Recursive Resolver initializes the option by setting the 320 FAMILY of the client's address. It then uses the value of its 321 maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For 322 privacy reasons, and because the whole IP address is rarely required 323 to determine a tailored response, this length SHOULD be shorter than 324 the full address, as described in Section 10. 326 If the triggering query included an ECS option itself, it MUST be 327 examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's 328 outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of 329 the incoming query's SOURCE PREFIX-LENGTH or the server's maximum 330 cacheable prefix length. 332 Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the 333 ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits, 334 with trailing 0 bits added, if needed, to fill the final octet. The 335 total number of octets used should only be enough to cover SOURCE 336 PREFIX-LENGTH bits, rather than the full width that would normally be 337 used by addresses in FAMILY. 339 FAMILY and ADDRESS information MAY be used from the ECS option 340 incoming query. Passing the existing address data is supportive of 341 the Recursive Resolver being used as the target of a Forwarder, but 342 could possibly run into policy problems with regard to usage 343 agreements between the Recursive Resolver and Authoritative 344 Namserver. See Section 11.2 for more discussion on this point. If 345 the Recursive Resolver will not forward the FAMILY and ADDRESS data 346 from the incoming ECS option, it SHOULD return a REFUSED response. 347 [*dcl* -- discussion of existing implementations] 349 Subsequent queries to refresh the data MUST, if unrestricted by an 350 incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- 351 LENGTH that the Recursive Resolver is willing to cache, even if a 352 previous response indicated that a shorter prefix length was 353 sufficient. 355 6.1.2. Stub Resolvers 357 A Stub Resolver MAY generate DNS queries with an ECS option set to 358 indicate its own level of privacy via SOURCE PREFIX-LENGTH. An 359 Intermediate Nameserver that receives such a query MUST NOT make 360 queries that include more bits of client address than in the 361 originating query. 363 A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add 364 address information of the client to its queries. The subsequent 365 Recursive Resolver query to the Authoritative Nameserver will then 366 either not include an ECS option or MAY optionally include its own 367 address information, which is what the Authoritative Nameserver will 368 almost certainly use to generate any Tailored Response in lieu of an 369 option. This allows the answer to be handled by the same caching 370 mechanism as other queries, with an explicit indicator of the 371 applicable scope. Subsequent Stub Resolver queries for /0 can then 372 be answered from this cached response. 374 A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include 375 FAMILY and ADDRESS data, but should be prepared to handle a REFUSED 376 response if the Intermediate Nameserver that it queries has a policy 377 that denies forwarding of the ADDRESS. If there is no ADDRESS set, 378 FAMILY MUST be set to 0. 380 6.1.3. Forwarders 382 Forwarders essentially appear to be Stub Resolvers to whatever 383 Recursive Resolver is ultimately handling the query, but look like a 384 Recursive Resolver to their client. A Forwarder using this option 385 MUST prepare it as described in the Section 6.1.1 section above. In 386 particular, a Forwarder that implements this protocol MUST honor 387 SOURCE PREFIX-LENGTH restrictions indicated in the incoming query 388 from its client. See also Section 6.5. 390 Since the Recursive Resolver it contacts will essentially treat it as 391 a Stub Resolver, the Forwarder must be prepared for a REFUSED 392 response if the Recursive Resolver does not permit incoming ADDRESS 393 information. The Forwarded MUST retry with FAMILY and ADDRESS set to 394 0. 396 6.2. Generating a Response 398 6.2.1. Authoritative Nameserver 400 When a query containing an ECS option is received, an Authoritative 401 Nameserver supporting ECS MAY use the address information specified 402 in the option in order to generate a tailored response. 404 Authoritative Nameservers that have not implemented or enabled 405 support for the ECS option ought to safely ignore it within incoming 406 queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include 407 an ECS option within replies, to indicate lack of support for it. 408 Implementers of Intermediate Nameservers should be aware, however, 409 that some nameservers incorrectly echo back unknown EDNS0 options. 410 In this protocol that should be mostly harmless, as SCOPE PREFIX- 411 LENGTH should come back as 0, thus marking the response as covering 412 all networks. 414 A query with a wrongly formatted option (e.g., an unknown FAMILY) 415 MUST be rejected and a FORMERR response MUST be returned to the 416 sender, as described by [RFC6891], Transport Considerations. 418 An Authoritative Nameserver that implements this protocol and 419 receives an ECS option MUST include an ECS option in its response to 420 indicate that it SHOULD be cached accordingly, regardless of whether 421 the client information was needed to formulate an answer. (Note that 422 the [RFC6891] requirement to reserve space for the OPT record could 423 mean that the answer section of the response will be truncated and 424 fallback to TCP indicated accordingly.) If an ECS option was not 425 included in a query, one MUST NOT be included in the response even if 426 the server is providing a Tailored Response -- presumably based on 427 the address from which it received the query. 429 The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST 430 match those in the query. Echoing back these values helps to 431 mitigate certain attack vectors, as described in Section 10. 433 The SCOPE PREFIX-LENGTH in the response indicates the network for 434 which the answer is intended. 436 A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH 437 indicates that the provided prefix length was not specific enough to 438 select the most appropriate Tailored Response. Future queries for 439 the name within the specified network SHOULD use the longer SCOPE 440 PREIX-LENGTH. 442 Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits 443 than necessary were provided, and the answer is suitable for a 444 broader range of addresses. This could be as short as 0, to indicate 445 that the answer is suitable for all addresses in FAMILY. 447 As the logical topology of any part of the network with regard to the 448 tailored response can vary, an Authoritative Nameserver may return 449 different values of SCOPE PREFIX-LENGTH for different networks. 451 The specific logic that an Authoritative Nameserver uses to choose a 452 tailored response is not in the scope of this document. Implementers 453 are encouraged, however, to consider carefully their selection of 454 SCOPE PREFIX-LENGTH for the response in the event that the best 455 tailored response cannot be determined. [Open issue: This seems so 456 very vague; More text here about possible strategy?] 458 If the Authoritative Nameserver operator configures a more specific 459 (longer prefix length) Tailored Response within a configured less 460 specific (shorter prefix length) Tailored Response, then 461 implementations can either: 463 1. Deaggregate the shorter prefix response into multiple longer 464 prefix responses, or, 466 2. Alert the operator that the order of queries will determine which 467 answers get cached, and either warn and continue or treat this as 468 an error and refuse to load the configuration. 470 Implementations SHOULD document their chosen behavior. 472 6.2.2. Intermediate Nameserver 474 When an Intermediate Nameserver uses ECS, whether it passes an ECS 475 option in its own response to its client is predicated on whether the 476 client originally included the option. Because a client that did not 477 use an ECS option might not be able to understand it, the server MUST 478 NOT provide one in its response. If the client query did include the 479 option, the server MUST include one in its response, especially as it 480 could be talking to a Forwarder which would need the information for 481 its own caching. [Open issue: if the Forwarder sent 0s for FAMILY 482 and ADDRESS, how could it take back a response with non-zero FAMILY 483 and ADDRESS when the spec says this mismatch MUST be dropped?] 485 If an Intermediate Nameserver receives a response which has a longer 486 SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in 487 its query, it SHOULD still provide the result as the answer to the 488 triggering client request even if the client is in a different 489 address range. The Intermediate Nameserver MAY instead opt to retry 490 with a longer SOURCE PREFIX-LENGTH to get a better reply before 491 responding to its client, as long as it does not exceed a SOURCE 492 PREFIX-LENGTH specified in the query that triggered resolution, but 493 this obviously has implications for the latency of the overall 494 lookup. 496 The logic for using the cache to determine whether the Intermediate 497 Nameserver already knows the response to provide to its client is 498 covered in the next section. 500 6.3. Handling ECS Responses and Caching 502 When an Intermediate Nameserver receives a response containing an ECS 503 option and without the TC bit set, it SHOULD cache the result based 504 on the data in the option. If the TC bit was set, the Intermediate 505 Resolver SHOULD retry the query over TCP to get the complete answer 506 section for caching. 508 If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of 509 ADDRESS in the response don't match the fields in the corresponding 510 query, the full response MUST be dropped, as described in Section 10. 512 If no ECS option is contained in the response, the Intermediate 513 Nameserver SHOULD treat this as being equivalent to having received a 514 SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client 515 addresses. See further discussion on the security implications of 516 this in Section 10. 518 6.3.1. Caching the Response 520 In the cache, any resource record in the answer section will be tied 521 to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- 522 LENGTH fields, as limited by the Intermediate Nameserver's own 523 configuration for maximum cacheable prefix length. Note that the 524 additional and authority sections from a DNS response message are 525 specifically excluded here. Any records from these sections MUST NOT 526 be tied to a network. [Open issue: this conflicts a bit with draft- 527 kumari-dnsop-multiple-responses, which wants to put data in the 528 additional section that an authoritative nameserver that does ECS 529 would probably want to tailor.] See more at Section 6.4. 531 Records that are cached as /0 because of a query's SOURCE PREFIX- 532 LENGTH of 0 MUST be distinguished from those that are cached as /0 533 because of a response's SCOPE PREFIX-LENGTH of 0. The former should 534 only be used for other /0 queries that the Intermediate Resolver 535 receives, but the latter is suitable as a response for all networks. 537 Although omitting network-specific caching will significantly 538 simplify an implementation, the resulting drop in cache hits is very 539 likely to defeat most latency benefits provided by ECS. Therefore, 540 when implementing this option for latency purposes, implementing full 541 caching support as described in this section is strongly recommended. 543 Enabling support for ECS in an Intermediate Nameserver will 544 significantly increase the size of the cache, reduce the number of 545 results that can be served from cache, and increase the load on the 546 server. Implementing the mitigation techniques described in 547 Section 10 is strongly recommended. 549 6.3.2. Answering from Cache 551 Cache lookups are first done as usual for a DNS query, using the 552 query tuple of . Then the appropriate RRset MUST 553 be chosen based on longest prefix matching. The client address to 554 use for comparison will depend on whether the Intermediate Nameserver 555 received an ECS option in its client query. 557 o If no ECS option was provided, the client's address is used. 559 o If there was an ECS option, the ADDRESS from it MAY be used if 560 local policy allows. Policy can vary depending on the agreements 561 the operator of the Intermediate Nameserver has with Authoritative 562 Nameserver operators; see Section 11.2. If policy does not allow, 563 a REFUSED response must be sent. 565 If a matching network is found and the relevant data is unexpired, 566 the response is generated as per Section 6.2. 568 If no matching network is found, the Intermediate Nameserver MUST 569 perform resolution as usual. This is necessary to avoid Tailored 570 Responses in the cache from being returned to the wrong clients, and 571 to avoid a single query coming from a client on a different network 572 from polluting the cache with a Tailored Response for all the users 573 of that resolver. 575 6.4. Delegations and Negative Answers 577 The prohibition against tying ECS data to records from the Authority 578 and Additional section left an unfortunate ambiguity in the original 579 specification, primarily with regard to negative answers. The 580 expectation of the original authors was that ECS would only really be 581 used for address records, the use case that was driving the 582 definition of the protocol. 584 The delegations case is a bit easier to tease out. In operational 585 practice, if an authoritative server is using address information to 586 provide customized delegations, it is the resolver that will be using 587 the answer for its next iterative query. Addresses in the Additional 588 section SHOULD therefore ignore ECS data, and the authority SHOULD 589 return a zero SCOPE PREFIX-LENGTH on delegations. A recursive 590 resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation 591 as though it were zero. 593 For negative answers, some independent implementations of both 594 resolvers and authorities did not see the section restriction as 595 necessarily meaning that a given name and type must only have either 596 positive ECS-tagged answers or a negative answer. They support being 597 able to tell one part of the network that the data does not exist, 598 while telling another part of the network that it does. 600 Several other implementations, however, do not support being able to 601 mix positive and negative answers, and thus interoperability is a 602 problem. 604 This issue is expected to be revisited in a future revision of the 605 protocol, possibly blessing the mixing of positive and negative 606 answers. There are implications for cache data structures that 607 developers should consider when writing new ECS code. 609 6.5. Transitivity 611 Generally, ECS options will only be present in DNS messages between a 612 Recursive Resolver and an Authoritative Nameserver, i.e., one hop. 613 In certain configurations however, for example multi-tier nameserver 614 setups, it may be necessary to implement transitive behaviour on 615 Intermediate Nameservers. 617 It is important that any Intermediate Nameserver that forwards ECS 618 options received from their clients MUST fully implement the caching 619 behaviour described in Section 6.3. 621 Intermediate Nameservers supporting ECS MUST forward options with 622 SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized), MUST 623 forward the query with SOURCE PREFIX-LENGTH set to 0 and MUST NOT be 624 replaced with an option with more accurate address information. 626 An Intermediate Nameserver MAY also forward ECS options with actual 627 address information. This information MAY match the source IP 628 address of the incoming query, and MAY have more or fewer address 629 bits than the Nameserver would normally include in a locally 630 originated ECS option. 632 If for any reason the Intermediate Nameserver does not want to use 633 the information in an ECS option it receives (too little address 634 information, network address from a range not authorized to use the 635 server, private/unroutable address space, etc), it SHOULD drop the 636 query and return a REFUSED response. Note again that an ECS option 637 with 0 address bits MUST NOT be refused. 639 Be aware that at least one major existing implementation does not 640 return REFUSED and instead just process the query as though the 641 problematic information were not present. This can lead to anomalous 642 situations, such as a response from the Intermediate Nameserver that 643 indicates it is tailored for one network (the one passed in the 644 original query, since ADDRESS must match) when actually it is for 645 another network (the one which contains the address that the 646 Intermediate Nameserver saw as making the query). 648 7. IANA Considerations 650 IANA has already assigned option code 8 in the "DNS EDNS0 Option 651 Codes (OPT)" registry to ECS. 653 The IANA is requested to update the reference ("draft-vandergaast- 654 edns-client-subnet") to refer to this RFC when published. 656 8. DNSSEC Considerations 658 The presence or absence of an [RFC6891] EDNS0 OPT resource record 659 containing an ECS option in a DNS query does not change the usage of 660 the resource records and mechanisms used to provide data origin 661 authentication and data integrity to the DNS, as described in 662 [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. 664 Use of this option, however, does imply increased DNS traffic between 665 any given Recursive Resolver and Authoritative Nameserver, which 666 could be another barrier to further DNSSEC adoption in this area. 668 9. NAT Considerations 670 Special awareness of ECS in devices that perform Network Address 671 Translation (NAT) as described in [RFC2663] is not required; queries 672 can be passed through as-is. The client's network address SHOULD NOT 673 be added, and existing ECS options, if present, SHOULD NOT be 674 modified by NAT devices. 676 In large-scale global networks behind a NAT device (but for example 677 with Centralized Resolver infrastructure), an internal Intermediate 678 Nameserver might have detailed network layout information, and may 679 know which external subnets are used for egress traffic by each 680 internal network. In such cases, the Intermediate Nameserver MAY use 681 that information when originating ECS options. 683 In other cases, Recursive Resolvers sited behind a NAT device SHOULD 684 NOT originate ECS options with their external IP address, and instead 685 rely on downstream Intermediate Nameservers doing so. They MAY, 686 however, choose to include the option with their internal address for 687 the purposes of signaling a shorter, more anonymous SOURCE PREFIX- 688 LENGTH. 690 If an Authoritative Nameserver on the publicly routed Internet 691 receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] 692 private address space, it SHOULD ignore ADDRESS and look up its 693 answer based on the address of the Recursive Resolver. In the 694 response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the 695 relevant private space. For example, a query for ADDRESS 10.1.2.0 696 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX- 697 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the 698 answer under one entry for special-purpose addresses [RFC6890]; see 699 Section 10.3. 701 10. Security Considerations 703 10.1. Privacy 705 With the ECS option, the network address of the client that initiated 706 the resolution becomes visible to all servers involved in the 707 resolution process. Additionally, it will be visible from any 708 network traversed by the DNS packets. 710 To protect users' privacy, Recursive Resolvers are strongly 711 encouraged to conceal part of the IP address of the user by 712 truncating IPv4 addresses to 24 bits. 56 bits are recommended for 713 IPv6, based on [RFC6177]. 715 ISPs should have more detailed knowledge of their own networks. That 716 is, they might know that all 24-bit prefixes in a /20 are in the same 717 area. In those cases, for optimal cache utilization and improved 718 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 719 this /20 to just 20 bits, instead of 24 as recommended above. 721 Users who wish their full IP address to be hidden can include an ECS 722 option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 723 0). As described in previous sections, this option will be forwarded 724 across all the Recursive Resolvers supporting ECS, which MUST NOT 725 modify it to include the network address of the client. 727 Note that even without an ECS option, any server queried directly by 728 the user will be able to see the full client IP address. Recursive 729 Resolvers or Authoritative Nameservers MAY use the source IP address 730 of queries to return a cached entry or to generate a Tailored 731 Response that best matches the query. 733 10.2. Birthday Attacks 735 ECS adds information to the DNS query tupe (q-tuple). This allows an 736 attacker to send a caching Intermediate Nameserver multiple queries 737 with spoofed IP addresses either in the ECS option or as the source 738 IP. These queries will trigger multiple outgoing queries with the 739 same name, type and class, just different address information in the 740 ECS option. 742 With multiple queries for the same name in flight, the attacker has a 743 higher chance of success to send a matching response with the SCOPE 744 PREFIX-LENGTH set to 0 to get it cached for all hosts. 746 To counter this, every ECS option in a response packet MUST contain 747 the full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the 748 corresponding query. Intermediate Nameservers processing a response 749 MUST verify that these match, and SHOULD discard the entire response 750 if they do not. 752 That requirement to discard is "SHOULD" instead of "MUST" because it 753 stands in opposition to the instruction in Section 6.3 which states 754 that a response lacking an ECS option should be treated as though it 755 had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an 756 attacker does not need to worry about matching the original ECS 757 option data and just needs to flood back responses that have no ECS 758 option at all. 760 This type of attack could be detected in ongoing operations by 761 marking whether the responding nameserver had previously been sending 762 ECS option, and/or by taking note of an incoming flood of bogus 763 responses and flagging the relevant query for re-resolution. This is 764 more complex than existing nameserver responses to spoof floods, and 765 would also need to be sensitive to a nameserver legitimately stopping 766 ECS replies even though it had previously given them. 768 10.3. Cache Pollution 770 It is simple for an arbitrary resolver or client to provide false 771 information in the ECS option, or to send UDP packets with forged 772 source IP addresses. 774 This could be used to: 776 o pollute the cache of intermediate resolvers, by filling it with 777 results that will rarely (if ever) be used. 779 o reverse engineer the algorithms (or data) used by the 780 Authoritative Nameserver to calculate Tailored Responses. 782 o mount a denial-of-service attack against an Intermediate 783 Nameserver, by forcing it to perform many more recursive queries 784 than it would normally do, due to how caching is handled for 785 queries containing the ECS option. 787 Even without malicious intent, Centralized Resolvers providing 788 answers to clients in multiple networks will need to cache different 789 responses for different networks, putting more memory pressure on the 790 cache. 792 To mitigate those problems: 794 o Recursive Resolvers implementing ECS should only enable it in 795 deployments where it is expected to bring clear advantages to the 796 end users. For example, when expecting clients from a variety of 797 networks or from a wide geographical area. Due to the high cache 798 pressure introduced by ECS, the feature SHOULD be disabled in all 799 default configurations. 801 o Recursive Resolvers SHOULD limit the number of networks and 802 answers they keep in the cache for a given query. 804 o Recursive Resolvers SHOULD limit the number of total different 805 networks that they keep in cache. 807 o Recursive Resolvers MUST never send an ECS option with a SOURCE 808 PREFIX-LENGTH providing more bits in the ADDRESS than they are 809 willing to cache responses for. 811 o Recursive Resolvers should implement algorithms to improve the 812 cache hit rate, given the size constraints indicated above. 813 Recursive Resolvers MAY, for example, decide to discard more 814 specific cache entries first. 816 o Authoritative Nameservers and Recursive Resolvers should discard 817 ECS options that are either obviously forged or otherwise known to 818 be wrong. They SHOULD at least treat unroutable addresses, such 819 as some of the address blocks defined in [RFC6890], as equivalent 820 to the Recursive Resolver's own identity. They SHOULD ignore and 821 never forward ECS options specifying other routable addresses that 822 are known not to be served by the query source. 824 o Authoritative Nameservers consider the ECS option just as a hint 825 to provide better results. They can decide to ignore the content 826 of the ECS option based on black or white lists, rate limiting 827 mechanisms, or any other logic implemented in the software. 829 11. Sending the Option 831 When implementing a Recursive Resolver, there are two strategies on 832 deciding when to include an ECS option in a query. At this stage, 833 it's not clear which strategy is best. 835 11.1. Probing 837 A Recursive Resolver can send the ECS option with every outgoing 838 query. However, it is RECOMMENDED that Resolvers remember which 839 Authoritative Nameservers did not return the option with their 840 response, and omit client address information from subsequent queries 841 to those Nameservers. 843 Additionally, Recursive Resolvers SHOULD be configured to never send 844 the option when querying root, top-level, and effective top-level 845 domain servers. These domains are delegation-centric and are very 846 unlikely to generate different responses based on the address of the 847 client. 849 When probing, it is important that several things are probed: support 850 for ECS, support for EDNS0, support for EDNS0 options, or possibly an 851 unreachable Nameserver. Various implementations are known to drop 852 DNS packets with OPT RRs (with or without options), thus several 853 probes are required to discover what is supported. 855 Probing, if implemented, MUST be repeated periodically, e.g., daily. 856 If an Authoritative Nameserver indicates ECS support for one zone, it 857 is to be expected that the Nameserver supports ECS for all of its 858 zones. Likewise, an Authoritative Nameserver that uses ECS 859 information for one of its zones, MUST indicate support for the 860 option in all of its responses to ECS queries. If the option is 861 supported but not actually used for generating a response, its SCOPE 862 PREFIX-LENGTH SHOULD be set to 0. 864 11.2. Whitelist 866 As described previously, it is expected that only a few Recursive 867 Resolvers will need to use ECS, and that it will generally be enabled 868 only if it offers a clear benefit to the users. 870 To avoid the complexity of implementing a probing and detection 871 mechanism (and the possible query loss/delay that may come with it), 872 an implementation could use a whitelist of Authoritative Namesevers 873 to send the option to, likely specified by their domain name. 874 Implementations MAY also allow additionally configuring this based on 875 other criteria, such as zone or query type. 877 An additional advantage of using a whitelist is that partial client 878 address information is only disclosed to Nameservers that are known 879 to use the information, improving privacy. 881 A major drawback is scalability. The operator needs to track which 882 Authoritative Nameservers support ECS, making it harder for new 883 Authoritative Nameservers to start using the option. 885 Similarly, Authoritative Nameservers can also use whitelists to limit 886 the feature to only certain clients. For example, a CDN that does 887 not want all of their mapping trivially walked might require a legal 888 agreement with the Recursive Resolver operator, to clearly describe 889 the acceptable use of the feature. 891 The maintenance of access control mechanisms is out of scope for this 892 protocol definition. 894 12. Example 896 1. A stub resolver, SR, with IP address 192.0.2.37 tries to resolve 897 www.example.com, by forwarding the query to the Recursive 898 Resolver, RNS, from IP address IP, asking for recursion. 900 2. RNS, supporting ECS, looks up www.example.com in its cache. An 901 entry is found neither for www.example.com, nor for example.com. 903 3. RNS builds a query to send to the root and .com servers. The 904 implementation of RNS provides facilities so an administrator 905 can configure it not to forward ECS in certain cases. In 906 particular, RNS is configured to not include an ECS option when 907 talking to TLD or root nameservers, as described in Section 6.1. 908 Thus, no ECS option is added, and resolution is performed as 909 usual. 911 4. RNS now knows the next server to query: the Authoritative 912 Nameserver, ANS, responsible for example.com. 914 5. RNS prepares a new query for www.example.com, including an ECS 915 option with: 917 * OPTION-CODE, set to 8. 919 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 920 octets plus the 3 octets that will be used for ADDRESS. 922 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 924 * SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to 925 conceal the last 8 bits of every IPv4 address. 927 * SCOPE PREFIX-LENGTH, set to 0x00, as specified by this 928 document for all queries. 930 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 931 bits of the IPv4 address. 933 6. The query is sent. ANS understands and uses ECS. It parses the 934 ECS option, and generates a Tailored Response. 936 7. Due its internal implementation, ANS finds a response that is 937 tailored for the whole /16 of the client that performed the 938 query. 940 8. ANS adds an ECS option in the response, containing: 942 * OPTION-CODE, set to 8. 944 * OPTION-LENGTH, set to 0x00 0x07. 946 * FAMILY, set to 0x00 0x01. 948 * SOURCE PREFIX-LENGTH, set to 0x18, copied from the query. 950 * SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network. 952 * ADDRESS, set to 0xC0 0x00 0x02, copied from the query. 954 9. RNS receives the response containing an ECS option. It verifies 955 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. 956 If not, the message is discarded. 958 10. The response is interpreted as usual. Since the response 959 contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and 960 FAMILY in the response are used to cache the entry. 962 11. RNS sends a response to stub resolver SR, without including an 963 ECS option. 965 12. RNS receives another query to resolve www.example.com. This 966 time, a response is cached. The response, however, is tied to a 967 particular network. If the address of the client matches any 968 network in the cache, then the response is returned from the 969 cache. Otherwise, another query is performed. If multiple 970 results match, the one with the longest SCOPE PREFIX-LENGTH is 971 chosen, as per common best-network match algorithms. 973 13. Contributing Authors 975 The below individuals contributed significantly to the draft. The 976 RFC Editor prefers a maximum of 5 names on the front page, and so we 977 have listed additional authors in this section 979 Edward Lewis 980 ICANN 981 12025 Waterfront Drive, Suite 300 982 Los Angeles CA 90094-2536 983 USA 984 Email: edward.lewis@icann.org 986 Sean Leach 987 Fastly 988 POBox 78266 989 San Francisco CA 94107 991 Jason Moreau 992 Akamai Technologies 993 8 Cambridge Ctr 994 Cambridge MA 02142-1413 995 USA 997 14. Acknowledgements 999 The authors wish to thank Darryl Rodden for his work as a co-author 1000 on previous versions, and the following people for reviewing early 1001 drafts of this document and for providing useful feedback: Paul S. 1003 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 1004 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 1005 Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, 1006 Edward Lewis, and Eric Burger from Neustar; David Ulevitch and 1007 Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from 1008 Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya 1009 Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn; 1010 John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer 1011 from NLnet Labs; Antonio Querubin; and all of the other people that 1012 replied to our emails on various mailing lists. 1014 15. References 1016 15.1. Normative References 1018 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1019 STD 13, RFC 1034, November 1987. 1021 [RFC1035] Mockapetris, P., "Domain names - implementation and 1022 specification", STD 13, RFC 1035, November 1987. 1024 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1025 October 1994. 1027 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1028 E. Lear, "Address Allocation for Private Internets", BCP 1029 5, RFC 1918, February 1996. 1031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, March 1997. 1034 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1035 Rose, "DNS Security Introduction and Requirements", RFC 1036 4033, March 2005. 1038 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1039 Rose, "Resource Records for the DNS Security Extensions", 1040 RFC 4034, March 2005. 1042 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1043 Rose, "Protocol Modifications for the DNS Security 1044 Extensions", RFC 4035, March 2005. 1046 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1047 Addresses", RFC 4193, October 2005. 1049 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1050 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1052 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 1053 "Special-Purpose IP Address Registries", BCP 153, RFC 1054 6890, April 2013. 1056 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1057 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 1059 15.2. Informative References 1061 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1062 Translator (NAT) Terminology and Considerations", RFC 1063 2663, August 1999. 1065 15.3. URIs 1067 [1] http://www.iana.org/assignments/address-family-numbers/ 1069 Appendix A. Document History 1071 [RFC Editor: Please delete this section before publication.] 1073 -00 to -01 (IETF) 1075 o Made the document describe how things are actually 1076 implmented now. This makes the document be more of a "this is how 1077 we are doing things, this provides information on that". There 1078 may be a future document that describes additional funcationality. 1080 o NETMASK was not a good desription, changed to PREFIX-LENGTH 1081 (Jinmei, others). Stole most of the definition for prefix length 1082 from RFC4291. 1084 o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include 1085 IPv6 (Tatuya Jinmei) 1087 o Comment that ECS cannot be used to hand NXDOMAIN to some clients 1088 and not others, primarily because of interoperability issues. 1089 (Tatuya Jinmei) 1091 o Added text explaining that implmentations need to document thier 1092 behavior with overlapping networks. 1094 o Soften "optimized reply" language. (Andrew Sullivan). 1096 o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0) 1098 o Some more grammar / working cleanups. 1100 o Replaced a whole heap of occurances of "edns-client-subnet" with 1101 "ECS" for readability. (John Dickinson) 1103 o More clearly describe the process from the point of view of each 1104 type of nameserver. (John Dickinson) 1106 o Birthday attack still possible if attacker floods with ECS-less 1107 responses. (Yuri Schaeffer) 1109 o Added some open issues directly to the text. 1111 A.1. -00 1113 o Document moved to experimental track, added experiment description 1114 in header with details in a new section. 1116 o Specifically note that ECS applies to the answer section only. 1118 o Warn that caching based on ECS is optional but very important for 1119 performance reasons. 1121 o Updated NAT section. 1123 o Added recommendation to not use the default /24 recommendation for 1124 the source prefix-length field if more detailed information about 1125 the network is available. 1127 o Rewritten problem statement to be more clear about the goal of ECS 1128 and the fact that it's entirely optional. 1130 o Wire format changed to include the original address and prefix 1131 length in responses in defence against birthday attacks. 1133 o Security considerations now includes a section about birthday 1134 attacks. 1136 o Renamed edns-client-ip in ECS, following suggestions on the 1137 mailing list. 1139 o Clarified behavior of resolvers when presented with an invalid ECS 1140 option. 1142 o Fully take multi-tier DNS setups in mind and be more clear about 1143 where the option should be originated. 1145 o A note on Authoritative Nameservers receiving queries that specify 1146 private address space. 1148 o A note to always ask for the longest acceptable SOURCE prefix 1149 length, even if a prior answer indicated that a shorter prefix 1150 length was suitable. 1152 o Marked up a few more references. 1154 o Added a few definitions in the Terminology section, and a few more 1155 aesthetic changes in the rest of the document. 1157 A.2. -01 1159 o Document version number reset from -02 to -00 due to the rename to 1160 ECS. 1162 o Clarified example (dealing with TLDs, and various minor errors). 1164 o Referencing RFC5035 instead of RFC1918. 1166 o Added a section on probing (and how it should be done) vs. 1167 whitelisting. 1169 o Moved description on how to forward ECS option in dedicated 1170 section. 1172 o Queries with wrongly formatted ECS options should now be rejected 1173 with FORMERR. 1175 o Added an "Overview" section, providing an introduction to the 1176 document. 1178 o Intermediate Nameservers can now remove an ECS option, or reduce 1179 the SOURCE PREFIX-LENGTH to increase privacy. 1181 o Added a reference to DoS attacks in the Security section. 1183 o Don't use "network range", as it seems to have different meaning 1184 in other contexts, and turned out to be confusing. 1186 o Use shorter and longer prefix lengths, rather than higher or 1187 lower. Add a better explanation in the format section. 1189 o Minor corrections in various other sections. 1191 A.3. -02 1193 o Added IANA-assigned option code. 1195 Authors' Addresses 1197 Carlo Contavalli 1198 Google 1199 1600 Amphitheater Parkway 1200 Mountain View, CA 94043 1201 US 1203 Email: ccontavalli@google.com 1205 Wilmer van der Gaast 1206 Google 1207 Belgrave House, 76 Buckingham Palace Road 1208 London SW1W 9TQ 1209 UK 1211 Email: wilmer@google.com 1213 David C Lawrence 1214 Akamai Technologies 1215 8 Cambridge Center 1216 Cambridge, MA 02142 1217 US 1219 Email: tale@akamai.com 1221 Warren Kumari 1222 Google 1223 1600 Amphitheatre Parkway 1224 Mountain View, CA 94043 1225 US 1227 Email: warren@kumari.net