idnits 2.17.00 (12 Aug 2021) /tmp/idnits41250/draft-ietf-dnsop-edns-client-subnet-02.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 (July 6, 2015) is 2511 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 280 -- Looks like a reference, but probably isn't: '1' on line 1083 ** 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: January 7, 2016 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 July 6, 2015 11 Client Subnet in DNS Queries 12 draft-ietf-dnsop-edns-client-subnet-02 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 January 7, 2016. 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 . . . . . . . . . . . . . . . 11 77 6.3. Handling ECS Responses and Caching . . . . . . . . . . . 11 78 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 12 79 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 12 80 6.4. Delegations and Negative Answers . . . . . . . . . . . . 13 81 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 14 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 15 84 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 87 10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 16 88 10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 17 89 11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 18 90 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19 91 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19 92 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 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 options, 232 and privacy. Section 10 explores various mitigation techniques. 234 The expectation, however, is that this option will primarily be used 235 between Recursive Resolvers and Authoritative Nameservers that are 236 sensitive to network location issues. Most Recursive Resolvers, 237 Authoritative Nameservers and Stub Resolvers will never need to know 238 about this option, and will continue working as they had been. 240 Failure to support this option or its improper handling will, at 241 worst, cause suboptimal identification of client location, which is a 242 common occurrence in current content delivery network (CDN) setups. 244 Section 6.1 also provides a mechanism for Stub Resolvers to signal 245 Recursive Resolvers that they do not want ECS treatment for specific 246 queries. 248 Additionally, operators of Intermediate Nameservers with ECS enabled 249 are allowed to choose how many bits of the address of received 250 queries to forward, or to reduce the number of bits forwarded for 251 queries already including an ECS option. 253 5. Option Format 255 This protocol uses an EDNS0 [RFC6891]) option to include client 256 address information in DNS messages. The option is structured as 257 follows: 259 +0 (MSB) +1 (LSB) 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 0: | OPTION-CODE | 262 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 263 2: | OPTION-LENGTH | 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 4: | FAMILY | 266 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 7: | ADDRESS... / 270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 272 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 273 0x08). 275 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 276 length of the payload (everything after OPTION-LENGTH) in octets. 278 o FAMILY, 2 octets, indicates the family of the address contained in 279 the option, using address family codes as assigned by IANA in 280 IANA-AFI [2]. 282 The format of the address part depends on the value of FAMILY. This 283 document only defines the format for FAMILY 1 (IP version 4) and 2 284 (IP version 6), which are as follows: 286 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost 287 significant bits of ADDRESS to be used for the lookup. In 288 responses, it mirrors the same value as in the queries. 290 o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost 291 significant bits of ADDRESS that the response covers. In queries, 292 it MUST be set to 0. 294 o ADDRESS, variable number of octets, contains either an IPv4 or 295 IPv6 address, depending on FAMILY, truncated to the number of bits 296 indicated by the SOURCE PREFIX-LENGTH field, with bits set to 0 to 297 pad to the end of the last octet needed. Trailing all-zero octets 298 SHOULD be omitted. 300 All fields are in network byte order ("big-endian", per [RFC1700], 301 Data Notation). 303 6. Protocol Description 305 6.1. Originating the Option 307 The ECS option should generally be added by Recursive Resolvers when 308 querying Authoritative Nameservers, as described in Section 11. The 309 option can also be initialized by a Stub Resolver or Forwarder. 311 6.1.1. Recursive Resolvers 313 The setup of the ECS option in a Recursive Resolver depends on the 314 client query that triggered the resolution process. 316 In the usual case, where no ECS option was present in the client 317 query, the Recursive Resolver initializes the option by setting the 318 FAMILY of the client's address. It then uses the value of its 319 maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For 320 privacy reasons, and because the whole IP address is rarely required 321 to determine a tailored response, this length SHOULD be shorter than 322 the full address, as described in Section 10. 324 If the triggering query included an ECS option itself, it MUST be 325 examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's 326 outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of 327 the incoming query's SOURCE PREFIX-LENGTH or the server's maximum 328 cacheable prefix length. 330 Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the 331 ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits, 332 with trailing 0 bits added, if needed, to fill the final octet. The 333 total number of octets used should only be enough to cover SOURCE 334 PREFIX-LENGTH bits, rather than the full width that would normally be 335 used by addresses in FAMILY. 337 FAMILY and ADDRESS information MAY be used from the ECS option in the 338 incoming query. Passing the existing address data is supportive of 339 the Recursive Resolver being used as the target of a Forwarder, but 340 could possibly run into policy problems with regard to usage 341 agreements between the Recursive Resolver and Authoritative 342 Namserver. See Section 11.2 for more discussion on this point. If 343 the Recursive Resolver will not forward the FAMILY and ADDRESS data 344 from the incoming ECS option, it SHOULD return a REFUSED response. 345 An ECS-aware resolver MUST retry the query without ECS to distinguish 346 the response from a lame delegation, which is the common convention 347 for a REFUSED status. 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, unless the query specified only the SOURCE 431 PREFIX-LENGTH for privacy (with FAMILY and ADDRESS set to 0). 432 Echoing back these values helps to mitigate certain attack vectors, 433 as described in Section 10. 435 The SCOPE PREFIX-LENGTH in the response indicates the network for 436 which the answer is intended. 438 A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH 439 indicates that the provided prefix length was not specific enough to 440 select the most appropriate Tailored Response. Future queries for 441 the name within the specified network SHOULD use the longer SCOPE 442 PREFIX-LENGTH. 444 Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits 445 than necessary were provided, and the answer is suitable for a 446 broader range of addresses. This could be as short as 0, to indicate 447 that the answer is suitable for all addresses in FAMILY. 449 As the logical topology of any part of the network with regard to the 450 tailored response can vary, an Authoritative Nameserver may return 451 different values of SCOPE PREFIX-LENGTH for different networks. 453 Since some queries can result in multiple RRsets being added to the 454 response, there is an unfortunate ambiguity from the original draft 455 as to how SCOPE PREFIX-LENGTH would apply to each individual RRset. 456 For example, multiple types in response to an ANY metaquery could all 457 have different applicable SCOPE PREFIX-LENGTH values, but this 458 protocol only has the ability to signal one. The response SHOULD 459 therefore include the longest relevant PREFIX-LENGTH of any RRset in 460 the answer, which could have the unfortunate side-effect of 461 redundantly caching some data that could be cached more broadly. For 462 the specific case of a CNAME chain, the Authoritative Nameserver 463 SHOULD only place the CNAME to have it cached unambiguously 464 appropriately. Most modern Recursive Resolvers restart the query 465 with the canonical name, so the remainder of the chain is typically 466 ignored anyway. For message-focused resolvers, rather than RRset- 467 focused ones, this will mean caching the entire CNAME chain at the 468 longest PREFIX-LENGTH of any RRset in the chain. 470 The specific logic that an Authoritative Nameserver uses to choose a 471 tailored response is not in the scope of this document. Implementers 472 are encouraged, however, to consider carefully their selection of 473 SCOPE PREFIX-LENGTH for the response in the event that the best 474 tailored response cannot be determined, and what the implications 475 would be over the life of the TTL. 477 If the Authoritative Nameserver operator configures a more specific 478 (longer prefix length) Tailored Response within a configured less 479 specific (shorter prefix length) Tailored Response, then 480 implementations can either: 482 1. Deaggregate the shorter prefix response into multiple longer 483 prefix responses, or, 485 2. Alert the operator that the order of queries will determine which 486 answers get cached, and either warn and continue or treat this as 487 an error and refuse to load the configuration. 489 Implementations SHOULD document their chosen behavior. 491 6.2.2. Intermediate Nameserver 493 When an Intermediate Nameserver uses ECS, whether it passes an ECS 494 option in its own response to its client is predicated on whether the 495 client originally included the option. Because a client that did not 496 use an ECS option might not be able to understand it, the server MUST 497 NOT provide one in its response. If the client query did include the 498 option, the server MUST include one in its response, especially as it 499 could be talking to a Forwarder which would need the information for 500 its own caching. 502 If an Intermediate Nameserver receives a response which has a longer 503 SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in 504 its query, it SHOULD still provide the result as the answer to the 505 triggering client request even if the client is in a different 506 address range. The Intermediate Nameserver MAY instead opt to retry 507 with a longer SOURCE PREFIX-LENGTH to get a better reply before 508 responding to its client, as long as it does not exceed a SOURCE 509 PREFIX-LENGTH specified in the query that triggered resolution, but 510 this obviously has implications for the latency of the overall 511 lookup. 513 The logic for using the cache to determine whether the Intermediate 514 Nameserver already knows the response to provide to its client is 515 covered in the next section. 517 6.3. Handling ECS Responses and Caching 519 When an Intermediate Nameserver receives a response containing an ECS 520 option and without the TC bit set, it SHOULD cache the result based 521 on the data in the option. If the TC bit was set, the Intermediate 522 Resolver SHOULD retry the query over TCP to get the complete answer 523 section for caching. 525 If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of 526 ADDRESS in the response don't match the non-zero fields in the 527 corresponding query, the full response MUST be dropped, as described 528 in Section 10. For a response to query which specified only the 529 SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS 530 fields should contain the appropriate non-zero information for 531 caching. 533 If no ECS option is contained in the response, the Intermediate 534 Nameserver SHOULD treat this as being equivalent to having received a 535 SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client 536 addresses. See further discussion on the security implications of 537 this in Section 10. 539 6.3.1. Caching the Response 541 In the cache, all resource records in the answer section MUST be tied 542 to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- 543 LENGTH fields, as limited by the Intermediate Nameserver's own 544 configuration for maximum cacheable prefix length. Note that the 545 additional and authority sections from a DNS response message are 546 specifically excluded here. Any records from these sections MUST NOT 547 be tied to a network. See more at Section 6.4. 549 Records that are cached as /0 because of a query's SOURCE PREFIX- 550 LENGTH of 0 MUST be distinguished from those that are cached as /0 551 because of a response's SCOPE PREFIX-LENGTH of 0. The former should 552 only be used for other /0 queries that the Intermediate Resolver 553 receives, but the latter is suitable as a response for all networks. 555 Although omitting network-specific caching will significantly 556 simplify an implementation, the resulting drop in cache hits is very 557 likely to defeat most latency benefits provided by ECS. Therefore, 558 when implementing this option for latency purposes, implementing full 559 caching support as described in this section is strongly recommended. 561 Enabling support for ECS in an Intermediate Nameserver will 562 significantly increase the size of the cache, reduce the number of 563 results that can be served from cache, and increase the load on the 564 server. Implementing the mitigation techniques described in 565 Section 10 is strongly recommended. 567 6.3.2. Answering from Cache 569 Cache lookups are first done as usual for a DNS query, using the 570 query tuple of . Then the appropriate RRset MUST 571 be chosen based on longest prefix matching. The client address to 572 use for comparison will depend on whether the Intermediate Nameserver 573 received an ECS option in its client query. 575 o If no ECS option was provided, the client's address is used. 577 o If there was an ECS option, the ADDRESS from it MAY be used if 578 local policy allows. Policy can vary depending on the agreements 579 the operator of the Intermediate Nameserver has with Authoritative 580 Nameserver operators; see Section 11.2. If policy does not allow, 581 a REFUSED response must be sent. 583 If a matching network is found and the relevant data is unexpired, 584 the response is generated as per Section 6.2. 586 If no matching network is found, the Intermediate Nameserver MUST 587 perform resolution as usual. This is necessary to avoid Tailored 588 Responses in the cache from being returned to the wrong clients, and 589 to avoid a single query coming from a client on a different network 590 from polluting the cache with a Tailored Response for all the users 591 of that resolver. 593 6.4. Delegations and Negative Answers 595 The prohibition against tying ECS data to records from the Authority 596 and Additional section left an unfortunate ambiguity in the original 597 specification, primarily with regard to negative answers. The 598 expectation of the original authors was that ECS would only really be 599 used for address records, the use case that was driving the 600 definition of the protocol. 602 The delegations case is a bit easier to tease out. In operational 603 practice, if an authoritative server is using address information to 604 provide customized delegations, it is the resolver that will be using 605 the answer for its next iterative query. Addresses in the Additional 606 section SHOULD therefore ignore ECS data, and the authority SHOULD 607 return a zero SCOPE PREFIX-LENGTH on delegations. A recursive 608 resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation 609 as though it were zero. 611 For negative answers, some independent implementations of both 612 resolvers and authorities did not see the section restriction as 613 necessarily meaning that a given name and type must only have either 614 positive ECS-tagged answers or a negative answer. They support being 615 able to tell one part of the network that the data does not exist, 616 while telling another part of the network that it does. 618 Several other implementations, however, do not support being able to 619 mix positive and negative answers, and thus interoperability is a 620 problem. 622 This issue is expected to be revisited in a future revision of the 623 protocol, possibly blessing the mixing of positive and negative 624 answers. There are implications for cache data structures that 625 developers should consider when writing new ECS code. 627 6.5. Transitivity 629 Generally, ECS options will only be present in DNS messages between a 630 Recursive Resolver and an Authoritative Nameserver, i.e., one hop. 631 In certain configurations however, for example multi-tier nameserver 632 setups, it may be necessary to implement transitive behaviour on 633 Intermediate Nameservers. 635 It is important that any Intermediate Nameserver that forwards ECS 636 options received from their clients MUST fully implement the caching 637 behaviour described in Section 6.3. 639 Intermediate Nameservers supporting ECS MUST forward options with 640 SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such 641 options MUST NOT be replaced with more accurate address information. 643 An Intermediate Nameserver MAY also forward ECS options with actual 644 address information. This information MAY match the source IP 645 address of the incoming query, and MAY have more or fewer address 646 bits than the Nameserver would normally include in a locally 647 originated ECS option. 649 If for any reason the Intermediate Nameserver does not want to use 650 the information in an ECS option it receives (too little address 651 information, network address from a range not authorized to use the 652 server, private/unroutable address space, etc), it SHOULD drop the 653 query and return a REFUSED response. Note again that a query MUST 654 NOT be refused solely because it provides 0 address bits. 656 Be aware that at least one major existing implementation does not 657 return REFUSED and instead just process the query as though the 658 problematic information were not present. This can lead to anomalous 659 situations, such as a response from the Intermediate Nameserver that 660 indicates it is tailored for one network (the one passed in the 661 original query, since ADDRESS must match) when actually it is for 662 another network (the one which contains the address that the 663 Intermediate Nameserver saw as making the query). 665 7. IANA Considerations 667 IANA has already assigned option code 8 in the "DNS EDNS0 Option 668 Codes (OPT)" registry to ECS. 670 The IANA is requested to update the reference ("draft-vandergaast- 671 edns-client-subnet") to refer to this RFC when published. 673 8. DNSSEC Considerations 675 The presence or absence of an [RFC6891] EDNS0 OPT resource record 676 containing an ECS option in a DNS query does not change the usage of 677 the resource records and mechanisms used to provide data origin 678 authentication and data integrity to the DNS, as described in 679 [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. 681 Use of this option, however, does imply increased DNS traffic between 682 any given Recursive Resolver and Authoritative Nameserver, which 683 could be another barrier to further DNSSEC adoption in this area. 685 9. NAT Considerations 687 Special awareness of ECS in devices that perform Network Address 688 Translation (NAT) as described in [RFC2663] is not required; queries 689 can be passed through as-is. The client's network address SHOULD NOT 690 be added, and existing ECS options, if present, SHOULD NOT be 691 modified by NAT devices. 693 In large-scale global networks behind a NAT device (but for example 694 with Centralized Resolver infrastructure), an internal Intermediate 695 Nameserver might have detailed network layout information, and may 696 know which external subnets are used for egress traffic by each 697 internal network. In such cases, the Intermediate Nameserver MAY use 698 that information when originating ECS options. 700 In other cases, Recursive Resolvers sited behind a NAT device SHOULD 701 NOT originate ECS options with their external IP address, and instead 702 rely on downstream Intermediate Nameservers to do so. They MAY, 703 however, choose to include the option with their internal address for 704 the purposes of signaling a shorter, more anonymous SOURCE PREFIX- 705 LENGTH. 707 If an Authoritative Nameserver on the publicly routed Internet 708 receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] 709 private address space, it SHOULD ignore ADDRESS and look up its 710 answer based on the address of the Recursive Resolver. In the 711 response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the 712 relevant private space. For example, a query for ADDRESS 10.1.2.0 713 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX- 714 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the 715 answer under one entry for special-purpose addresses [RFC6890]; see 716 Section 10.3. 718 10. Security Considerations 720 10.1. Privacy 722 With the ECS option, the network address of the client that initiated 723 the resolution becomes visible to all servers involved in the 724 resolution process. Additionally, it will be visible from any 725 network traversed by the DNS packets. 727 To protect users' privacy, Recursive Resolvers are strongly 728 encouraged to conceal part of the IP address of the user by 729 truncating IPv4 addresses to 24 bits. 56 bits are recommended for 730 IPv6, based on [RFC6177]. 732 ISPs should have more detailed knowledge of their own networks. That 733 is, they might know that all 24-bit prefixes in a /20 are in the same 734 area. In those cases, for optimal cache utilization and improved 735 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 736 this /20 to just 20 bits, instead of 24 as recommended above. 738 Users who wish their full IP address to be hidden can include an ECS 739 option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 740 0). As described in previous sections, this option will be forwarded 741 across all the Recursive Resolvers supporting ECS, which MUST NOT 742 modify it to include the network address of the client. 744 Note that even without an ECS option, any server queried directly by 745 the user will be able to see the full client IP address. Recursive 746 Resolvers or Authoritative Nameservers MAY use the source IP address 747 of queries to return a cached entry or to generate a Tailored 748 Response that best matches the query. 750 10.2. Birthday Attacks 752 ECS adds information to the DNS query tupe (q-tuple). This allows an 753 attacker to send a caching Intermediate Nameserver multiple queries 754 with spoofed IP addresses either in the ECS option or as the source 755 IP. These queries will trigger multiple outgoing queries with the 756 same name, type and class, just different address information in the 757 ECS option. 759 With multiple queries for the same name in flight, the attacker has a 760 higher chance of success to send a matching response with the SCOPE 761 PREFIX-LENGTH set to 0 to get it cached for all hosts. 763 To counter this, the ECS option in a response packet MUST contain the 764 full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the 765 corresponding query. Intermediate Nameservers processing a response 766 MUST verify that these match, and SHOULD discard the entire response 767 if they do not. 769 That requirement to discard is "SHOULD" instead of "MUST" because it 770 stands in opposition to the instruction in Section 6.3 which states 771 that a response lacking an ECS option should be treated as though it 772 had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an 773 attacker does not need to worry about matching the original ECS 774 option data and just needs to flood back responses that have no ECS 775 option at all. 777 This type of attack could be detected in ongoing operations by 778 marking whether the responding nameserver had previously been sending 779 ECS option, and/or by taking note of an incoming flood of bogus 780 responses and flagging the relevant query for re-resolution. This is 781 more complex than existing nameserver responses to spoof floods, and 782 would also need to be sensitive to a nameserver legitimately stopping 783 ECS replies even though it had previously given them. 785 10.3. Cache Pollution 787 It is simple for an arbitrary resolver or client to provide false 788 information in the ECS option, or to send UDP packets with forged 789 source IP addresses. 791 This could be used to: 793 o pollute the cache of intermediate resolvers, by filling it with 794 results that will rarely (if ever) be used. 796 o reverse engineer the algorithms (or data) used by the 797 Authoritative Nameserver to calculate Tailored Responses. 799 o mount a denial-of-service attack against an Intermediate 800 Nameserver, by forcing it to perform many more recursive queries 801 than it would normally do, due to how caching is handled for 802 queries containing the ECS option. 804 Even without malicious intent, Centralized Resolvers providing 805 answers to clients in multiple networks will need to cache different 806 responses for different networks, putting more memory pressure on the 807 cache. 809 To mitigate those problems: 811 o Recursive Resolvers implementing ECS should only enable it in 812 deployments where it is expected to bring clear advantages to the 813 end users. For example, when expecting clients from a variety of 814 networks or from a wide geographical area. Due to the high cache 815 pressure introduced by ECS, the feature SHOULD be disabled in all 816 default configurations. 818 o Recursive Resolvers SHOULD limit the number of networks and 819 answers they keep in the cache for any given query. 821 o Recursive Resolvers SHOULD limit the number of total different 822 networks that they keep in cache. 824 o Recursive Resolvers MUST never send an ECS option with a SOURCE 825 PREFIX-LENGTH providing more bits in the ADDRESS than they are 826 willing to cache responses for. 828 o Recursive Resolvers should implement algorithms to improve the 829 cache hit rate, given the size constraints indicated above. 830 Recursive Resolvers MAY, for example, decide to discard more 831 specific cache entries first. 833 o Authoritative Nameservers and Recursive Resolvers should discard 834 ECS options that are either obviously forged or otherwise known to 835 be wrong. They SHOULD at least treat unroutable addresses, such 836 as some of the address blocks defined in [RFC6890], as equivalent 837 to the Recursive Resolver's own identity. They SHOULD ignore and 838 never forward ECS options specifying other routable addresses that 839 are known not to be served by the query source. 841 o Authoritative Nameservers consider the ECS option just as a hint 842 to provide better results. They can decide to ignore the content 843 of the ECS option based on black or white lists, rate limiting 844 mechanisms, or any other logic implemented in the software. 846 11. Sending the Option 848 When implementing a Recursive Resolver, there are two strategies on 849 deciding when to include an ECS option in a query. At this stage, 850 it's not clear which strategy is best. 852 11.1. Probing 854 A Recursive Resolver can send the ECS option with every outgoing 855 query. However, it is RECOMMENDED that Resolvers remember which 856 Authoritative Nameservers did not return the option with their 857 response, and omit client address information from subsequent queries 858 to those Nameservers. 860 Additionally, Recursive Resolvers SHOULD be configured to never send 861 the option when querying root, top-level, and effective top-level 862 domain servers. These domains are delegation-centric and are very 863 unlikely to generate different responses based on the address of the 864 client. 866 When probing, it is important that several things are probed: support 867 for ECS, support for EDNS0, support for EDNS0 options, or possibly an 868 unreachable Nameserver. Various implementations are known to drop 869 DNS packets with OPT RRs (with or without options), thus several 870 probes are required to discover what is supported. 872 Probing, if implemented, MUST be repeated periodically, e.g., daily. 873 If an Authoritative Nameserver indicates ECS support for one zone, it 874 is to be expected that the Nameserver supports ECS for all of its 875 zones. Likewise, an Authoritative Nameserver that uses ECS 876 information for one of its zones, MUST indicate support for the 877 option in all of its responses to ECS queries. If the option is 878 supported but not actually used for generating a response, its SCOPE 879 PREFIX-LENGTH MUST be set to 0. 881 11.2. Whitelist 883 As described previously, it is expected that only a few Recursive 884 Resolvers will need to use ECS, and that it will generally be enabled 885 only if it offers a clear benefit to the users. 887 To avoid the complexity of implementing a probing and detection 888 mechanism (and the possible query loss/delay that may come with it), 889 an implementation could use a whitelist of Authoritative Namesevers 890 to send the option to, likely specified by their domain name. 891 Implementations MAY also allow additionally configuring this based on 892 other criteria, such as zone or query type. 894 An additional advantage of using a whitelist is that partial client 895 address information is only disclosed to Nameservers that are known 896 to use the information, improving privacy. 898 A major drawback is scalability. The operator needs to track which 899 Authoritative Nameservers support ECS, making it harder for new 900 Authoritative Nameservers to start using the option. 902 Similarly, Authoritative Nameservers can also use whitelists to limit 903 the feature to only certain clients. For example, a CDN that does 904 not want all of their mapping trivially walked might require a legal 905 agreement with the Recursive Resolver operator, to clearly describe 906 the acceptable use of the feature. 908 The maintenance of access control mechanisms is out of scope for this 909 protocol definition. 911 12. Example 913 1. A stub resolver, SR, with IP address 192.0.2.37 tries to resolve 914 www.example.com, by forwarding the query to the Recursive 915 Resolver, RNS, from IP address IP, asking for recursion. 917 2. RNS, supporting ECS, looks up www.example.com in its cache. An 918 entry is found neither for www.example.com, nor for example.com. 920 3. RNS builds a query to send to the root and .com servers. The 921 implementation of RNS provides facilities so an administrator 922 can configure it not to forward ECS in certain cases. In 923 particular, RNS is configured to not include an ECS option when 924 talking to TLD or root nameservers, as described in Section 6.1. 925 Thus, no ECS option is added, and resolution is performed as 926 usual. 928 4. RNS now knows the next server to query: the Authoritative 929 Nameserver, ANS, responsible for example.com. 931 5. RNS prepares a new query for www.example.com, including an ECS 932 option with: 934 * OPTION-CODE, set to 8. 936 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 937 octets plus the 3 octets that will be used for ADDRESS. 939 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 941 * SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to 942 conceal the last 8 bits of every IPv4 address. 944 * SCOPE PREFIX-LENGTH, set to 0x00, as specified by this 945 document for all queries. 947 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 948 bits of the IPv4 address. 950 6. The query is sent. ANS understands and uses ECS. It parses the 951 ECS option, and generates a Tailored Response. 953 7. Due its internal implementation, ANS finds a response that is 954 tailored for the whole /16 of the client that performed the 955 query. 957 8. ANS adds an ECS option in the response, containing: 959 * OPTION-CODE, set to 8. 961 * OPTION-LENGTH, set to 0x00 0x07. 963 * FAMILY, set to 0x00 0x01. 965 * SOURCE PREFIX-LENGTH, set to 0x18, copied from the query. 967 * SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network. 969 * ADDRESS, set to 0xC0 0x00 0x02, copied from the query. 971 9. RNS receives the response containing an ECS option. It verifies 972 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. 973 If not, the message is discarded. 975 10. The response is interpreted as usual. Since the response 976 contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and 977 FAMILY in the response are used to cache the entry. 979 11. RNS sends a response to stub resolver SR, without including an 980 ECS option. 982 12. RNS receives another query to resolve www.example.com. This 983 time, a response is cached. The response, however, is tied to a 984 particular network. If the address of the client matches any 985 network in the cache, then the response is returned from the 986 cache. Otherwise, another query is performed. If multiple 987 results match, the one with the longest SCOPE PREFIX-LENGTH is 988 chosen, as per common best-network match algorithms. 990 13. Contributing Authors 992 The below individuals contributed significantly to the draft. The 993 RFC Editor prefers a maximum of 5 names on the front page, and so we 994 have listed additional authors in this section 995 Edward Lewis 996 ICANN 997 12025 Waterfront Drive, Suite 300 998 Los Angeles CA 90094-2536 999 USA 1000 Email: edward.lewis@icann.org 1002 Sean Leach 1003 Fastly 1004 POBox 78266 1005 San Francisco CA 94107 1007 Jason Moreau 1008 Akamai Technologies 1009 8 Cambridge Ctr 1010 Cambridge MA 02142-1413 1011 USA 1013 14. Acknowledgements 1015 The authors wish to thank Darryl Rodden for his work as a co-author 1016 on previous versions, and the following people for reviewing early 1017 drafts of this document and for providing useful feedback: Paul S. 1018 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 1019 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 1020 Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, 1021 Edward Lewis, and Eric Burger from Neustar; David Ulevitch and 1022 Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from 1023 Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya 1024 Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn; 1025 John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer 1026 from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin; 1027 and all of the other people that replied to our emails on various 1028 mailing lists. 1030 15. References 1032 15.1. Normative References 1034 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1035 STD 13, RFC 1034, November 1987. 1037 [RFC1035] Mockapetris, P., "Domain names - implementation and 1038 specification", STD 13, RFC 1035, November 1987. 1040 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1041 October 1994. 1043 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1044 E. Lear, "Address Allocation for Private Internets", BCP 1045 5, RFC 1918, February 1996. 1047 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1048 Requirement Levels", BCP 14, RFC 2119, March 1997. 1050 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1051 Rose, "DNS Security Introduction and Requirements", RFC 1052 4033, March 2005. 1054 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1055 Rose, "Resource Records for the DNS Security Extensions", 1056 RFC 4034, March 2005. 1058 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1059 Rose, "Protocol Modifications for the DNS Security 1060 Extensions", RFC 4035, March 2005. 1062 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1063 Addresses", RFC 4193, October 2005. 1065 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1066 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1068 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 1069 "Special-Purpose IP Address Registries", BCP 153, RFC 1070 6890, April 2013. 1072 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1073 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 1075 15.2. Informative References 1077 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1078 Translator (NAT) Terminology and Considerations", RFC 1079 2663, August 1999. 1081 15.3. URIs 1083 [1] http://www.iana.org/assignments/address-family-numbers/ 1085 Appendix A. Document History 1087 [RFC Editor: Please delete this section before publication.] 1089 -02 to -03 (IETF) 1090 o Clean up the open issues, mostly by saying that they were out of 1091 scope for this document. 1093 o How in the world did no reviewers note that "Queries" had been 1094 spelled as "Querys" in the title? (Aaron Falk did.) 1096 -01 to -02 (IETF) 1098 o Note ambiguity with multiple RRsets appearing in reply, eg, for an 1099 ANY query or CNAME chain. (Duane Wessels) 1101 o Open issue questioning the guidance about resolvers behind a NAT. 1102 How do they know they are? What real requirement is this 1103 imposing? (Duane Wessels) 1105 o Some other wording changes based on Duane's review of an earlier 1106 draft. 1108 -00 to -01 (IETF) 1110 o Made the document describe how things are actually 1111 implmented now. This makes the document be more of a "this is how 1112 we are doing things, this provides information on that". There 1113 may be a future document that describes additional funcationality. 1115 o NETMASK was not a good desription, changed to PREFIX-LENGTH 1116 (Jinmei, others). Stole most of the definition for prefix length 1117 from RFC4291. 1119 o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include 1120 IPv6 (Tatuya Jinmei) 1122 o Comment that ECS cannot be used to hand NXDOMAIN to some clients 1123 and not others, primarily because of interoperability issues. 1124 (Tatuya Jinmei) 1126 o Added text explaining that implmentations need to document thier 1127 behavior with overlapping networks. 1129 o Soften "optimized reply" language. (Andrew Sullivan). 1131 o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0) 1133 o Some more grammar / working cleanups. 1135 o Replaced a whole heap of occurances of "edns-client-subnet" with 1136 "ECS" for readability. (John Dickinson) 1138 o More clearly describe the process from the point of view of each 1139 type of nameserver. (John Dickinson) 1141 o Birthday attack still possible if attacker floods with ECS-less 1142 responses. (Yuri Schaeffer) 1144 o Added some open issues directly to the text. 1146 A.1. -00 1148 o Document moved to experimental track, added experiment description 1149 in header with details in a new section. 1151 o Specifically note that ECS applies to the answer section only. 1153 o Warn that caching based on ECS is optional but very important for 1154 performance reasons. 1156 o Updated NAT section. 1158 o Added recommendation to not use the default /24 recommendation for 1159 the source prefix-length field if more detailed information about 1160 the network is available. 1162 o Rewritten problem statement to be more clear about the goal of ECS 1163 and the fact that it's entirely optional. 1165 o Wire format changed to include the original address and prefix 1166 length in responses in defence against birthday attacks. 1168 o Security considerations now includes a section about birthday 1169 attacks. 1171 o Renamed edns-client-ip in ECS, following suggestions on the 1172 mailing list. 1174 o Clarified behavior of resolvers when presented with an invalid ECS 1175 option. 1177 o Fully take multi-tier DNS setups in mind and be more clear about 1178 where the option should be originated. 1180 o A note on Authoritative Nameservers receiving queries that specify 1181 private address space. 1183 o A note to always ask for the longest acceptable SOURCE prefix 1184 length, even if a prior answer indicated that a shorter prefix 1185 length was suitable. 1187 o Marked up a few more references. 1189 o Added a few definitions in the Terminology section, and a few more 1190 aesthetic changes in the rest of the document. 1192 A.2. -01 1194 o Document version number reset from -02 to -00 due to the rename to 1195 ECS. 1197 o Clarified example (dealing with TLDs, and various minor errors). 1199 o Referencing RFC5035 instead of RFC1918. 1201 o Added a section on probing (and how it should be done) vs. 1202 whitelisting. 1204 o Moved description on how to forward ECS option in dedicated 1205 section. 1207 o Queries with wrongly formatted ECS options should now be rejected 1208 with FORMERR. 1210 o Added an "Overview" section, providing an introduction to the 1211 document. 1213 o Intermediate Nameservers can now remove an ECS option, or reduce 1214 the SOURCE PREFIX-LENGTH to increase privacy. 1216 o Added a reference to DoS attacks in the Security section. 1218 o Don't use "network range", as it seems to have different meaning 1219 in other contexts, and turned out to be confusing. 1221 o Use shorter and longer prefix lengths, rather than higher or 1222 lower. Add a better explanation in the format section. 1224 o Minor corrections in various other sections. 1226 A.3. -02 1228 o Added IANA-assigned option code. 1230 Authors' Addresses 1231 Carlo Contavalli 1232 Google 1233 1600 Amphitheater Parkway 1234 Mountain View, CA 94043 1235 US 1237 Email: ccontavalli@google.com 1239 Wilmer van der Gaast 1240 Google 1241 Belgrave House, 76 Buckingham Palace Road 1242 London SW1W 9TQ 1243 UK 1245 Email: wilmer@google.com 1247 David C Lawrence 1248 Akamai Technologies 1249 8 Cambridge Center 1250 Cambridge, MA 02142 1251 US 1253 Email: tale@akamai.com 1255 Warren Kumari 1256 Google 1257 1600 Amphitheatre Parkway 1258 Mountain View, CA 94043 1259 US 1261 Email: warren@kumari.net