idnits 2.17.00 (12 Aug 2021) /tmp/idnits41904/draft-vandergaast-dnsop-edns-client-subnet-00.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 : ---------------------------------------------------------------------------- -- 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 (October 03, 2014) is 2780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 856 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: April 6, 2015 S. Leach 6 VeriSign 7 D. Lawrence 8 Akamai 9 W. Kumari 10 Google 11 October 03, 2014 13 Client Subnet in DNS Requests 14 draft-vandergaast-dnsop-edns-client-subnet-00 16 Abstract 18 This draft defines an EDNS0 extension to carry information about the 19 network that originated a DNS query, and the network for which the 20 subsequent reply can be cached. 22 IESG Note 24 [RFC Editor: Please remove this note prior to publication ] 26 This informational document describes an existing, implemented and 27 deployed system. It was originally going to be an Experimental 28 document, but is now detailing a deployed system. 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 April 6, 2015. 47 Copyright Notice 49 Copyright (c) 2014 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.2. Generating a Response . . . . . . . . . . . . . . . . . . 7 72 6.3. Handling edns-client-subnet Replies and Caching . . . . . 9 73 6.4. Transitivity . . . . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 11 76 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 13 80 10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 13 81 11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 14 82 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 15 83 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 15 84 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 86 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 87 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 15.2. Informative References . . . . . . . . . . . . . . . . . 19 90 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 Appendix A. Document History . . . . . . . . . . . . . . . . . . 19 92 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 Many Authoritative Nameservers today return different replies based 101 on the perceived topological location of the user. These servers use 102 the IP address of the incoming query to identify that location. 103 Since most queries come from intermediate recursive resolvers, the 104 source address is that of the Recursive Resolver rather than of the 105 query originator. 107 Traditionally and probably still in the majority of instances, 108 recursive resolvers are reasonably close in the topological sense to 109 the stub resolvers or forwarders that are the source of queries. For 110 these resolvers, using their own IP address is sufficient for 111 authority servers that tailor responses based upon location of the 112 querier. 114 Increasingly, though, a class of Recursive Resolvers has arisen that 115 serves query sources without regard to topology. The motivation for 116 a query source to use such a Third-party Resolver varies but is 117 usually because of some enhanced experience, such as greater cache 118 security or applying policies regarding where users may connect. 119 (Although political censorship usually comes to mind here, the same 120 actions may be used by a parent when setting controls on where a 121 minor may connect.) When using a Third-party Resolver, there can no 122 longer be any assumption of close proximity between the originator 123 and the recursive resolver, leading to less than optimal replies from 124 the authority servers. 126 A similar situation exists within some ISPs where the Recursive 127 Resolvers are topologically distant from some edges of the ISP 128 network, resulting in less than optimal replies from the authority 129 servers. 131 This draft defines an EDNS0 option to convey network information that 132 is relevant to the message but not otherwise included in the 133 datagram. This will provide the mechanism to carry sufficient 134 network information about the originator for the authority server to 135 tailor responses. It also provides for the authority server to 136 indicate the scope of network addresses for which the tailored answer 137 is intended. This EDNS0 option is intended for those recursive and 138 authority servers that would benefit from the extension and not for 139 general purpose deployment. It is completely optional and can safely 140 be ignored by servers that choose not to implement it or enable it. 142 This draft also includes guidelines on how to best cache those 143 results and provides recommendations on when this protocol extension 144 should be used. 146 2. Requirements Notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 3. Terminology 154 Stub Resolver: A simple DNS protocol implementation on the client 155 side as described in [RFC1034] section 5.3.1. 157 Authoritative Nameserver: A nameserver that has authority over one 158 or more DNS zones. These are normally not contacted by clients 159 directly but by Recursive Resolvers. Described in [RFC1035] 160 chapter 6. 162 Recursive Resolver: A nameserver that is responsible for resolving 163 domain names for clients by following the domain's delegation 164 chain, starting at the root. Recursive Resolvers frequently use 165 caches to be able to respond to client queries quickly. Described 166 in [RFC1035] chapter 7. 168 Intermediate Nameserver: Any nameserver (possibly a Recursive 169 Resolver) in between the Stub Resolver and the Authoritative 170 Nameserver. 172 Third-party Resolvers: Recursive Resolvers provided by parties that 173 are not Internet Service Providers (ISPs). These services are 174 often offered as substitutes for ISP-run nameservers. 176 Optimized reply: A reply from a nameserver that is optimized for the 177 node that sent the request, normally based on performance (i.e. 178 lowest latency, least number of hops, topological distance, ...). 180 Topologically close: Refers to two hosts being close in terms of 181 number of hops or time it takes for a packet to travel from one 182 host to the other. The concept of topological distance is only 183 loosely related to the concept of geographical distance: two 184 geographically close hosts can still be very distant from a 185 topological perspective. 187 4. Overview 189 The general idea of this document is to provide an EDNS0 option to 190 allow Recursive Resolvers, if they are willing, to forward details 191 about the origin network that a query is coming from when talking to 192 other Nameservers. 194 The format of this option is described in Section 5, and is meant to 195 be added in queries sent by Intermediate Nameservers in a way 196 transparent to Stub Resolvers and end users, as described in 197 Section 6.1. 199 As described in Section 6.2, an Authoritative Nameserver could use 200 this EDNS0 option as a hint to better locate the network of the end 201 user, and provide a better answer. 203 Its reply would contain an EDNS0 client-subnet option, clearly 204 indicating that (1) the server made use of this information and (2) 205 the answer is tied to the network of the client. 207 As described in Section 6.3, Intermediate Nameservers would use this 208 information to cache the reply. 210 Some Intermediate Nameservers may also have to be able to forward 211 edns-client-subnet queries they receive. This is described in 212 Section 6.4. 214 The mechanisms provided by edns-client-subnet raise various security 215 related concerns, related to cache growth, the ability to spoof EDNS0 216 options, and privacy. Section 10 explores various mitigation 217 techniques. 219 The expectation, however, is that this option will only be enabled 220 (and used) by Recursive Resolvers and Authoritative Nameserver that 221 incur geolocation issues. 223 Most Recursive Resolvers, Authoritative Nameservers and Stub Resolver 224 will never know about this option, and will continue working as they 225 had been. 227 Failure to support this option or its improper handling will, at 228 worst, cause sub-optimal geolocation, which is a pretty common 229 occurrence in current CDN setups and not a cause of concern. 231 Section 6.1 also provides a mechanism for Stub Resolvers to signal 232 Recursive Resolvers that they do not want an edns-client treatment 233 for specific requests. 235 Additionally, owners of resolvers with edns-client-subnet enabled are 236 allowed to choose how many bits of the address of received queries to 237 forward, or to reduce the number of bits forwarded for queries 238 already including an edns-client-subnet option. 240 5. Option Format 242 This draft uses an EDNS0 ([RFC6891]) option to include client IP 243 information in DNS messages. The option is structured as follows: 245 +0 (MSB) +1 (LSB) 246 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 247 0: | OPTION-CODE | 248 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 249 2: | OPTION-LENGTH | 250 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 251 4: | FAMILY | 252 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 253 6: | SOURCE NETMASK | SCOPE NETMASK | 254 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 255 7: | ADDRESS... / 256 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 258 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for edns-client- 259 subnet is 8. 261 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 262 length of the payload (everything after OPTION-LENGTH) in bytes. 264 o FAMILY, 2 octets, indicates the family of the address contained in 265 the option, using address family codes as assigned by IANA in 266 IANA-AFI [1]. 268 The format of the address part depends on the value of FAMILY. This 269 document only defines the format for FAMILY 1 (IP version 4) and 2 270 (IP version 6), which are as follows: 272 o SOURCE NETMASK, unsigned byte representing the length of the 273 netmask pertaining to the query. In replies, it mirrors the same 274 value as in the requests. 276 o SCOPE NETMASK, unsigned byte representing the length of the 277 netmask pertaining to the reply. In requests, it MUST be set to 278 0. In responses, this may or may not match SOURCE NETMASK. 280 o ADDRESS, variable number of octets, contains either an IPv4 or 281 IPv6 address (depending on FAMILY), truncated to the number of 282 bits indicated by the SOURCE NETMASK field, with bits set to 0 to 283 pad up to the end of the last octet used. 285 All fields are in network byte order. Throughout the document, we 286 will often refer to "longer" or "shorter" netmasks, corresponding to 287 netmasks that have a "higher" or "lower" value when represented as 288 integers. 290 6. Protocol Description 292 6.1. Originating the Option 294 The edns-client-subnet option should generally be added by Recursive 295 Resolvers when querying other servers, as described in Section 11. 297 In this option, the server should include the IP of the client that 298 caused the query to be generated, truncated to a number of bits 299 specified in the SOURCE NETMASK field. 301 The IP of the client can generally be determined by looking at the 302 source IP indicated in the IP header of the request. 304 A Stub Resolver MAY generate DNS queries with an edns-client-subnet 305 option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that 306 the Recursive Resolver MUST NOT add address information of the client 307 to its queries. The Stub Resolver may also add non-empty edns- 308 client-subnet options to its queries, but Recursive Resolvers are not 309 required to accept/use this information. 311 For privacy reasons, and because the whole IP address is rarely 312 required to determine an optimized reply, the ADDRESS field in the 313 option SHOULD be truncated to a certain number of bits, chosen by the 314 administrators of the server, as described in Section 10. 316 6.2. Generating a Response 318 When a query containing an edns-client-subnet option is received, an 319 Authoritative Nameserver supporting edns-client-subnet MAY use the 320 address information specified in the option in order to generate an 321 optimized reply. 323 Authoritative servers that have not implemented or enabled support 324 for the edns-client-subnet may safely ignore the option within 325 incoming queries. Such a server MUST NOT include an edns-client- 326 subnet option within replies, to indicate lack of support for the 327 option. 329 Requests with wrongly formatted options (i.e. wrong size) MUST be 330 rejected and a FORMERR response must be returned to the sender, as 331 described by [RFC6891], Transport Considerations. 333 If the Authoritative Nameserver decides to use information from the 334 edns-client-subnet option to calculate a response, it MUST include 335 the option in the response to indicate that the information was used 336 (and has to be cached accordingly). If the option was not included 337 in a query, it MUST NOT be included in the response. 339 The FAMILY, ADDRESS and SOURCE NETMASK in the response MUST match 340 those in the request. Echoing back the address and netmask helps to 341 mitigate certain attack vectors, as described in Section 10. 343 The SCOPE NETMASK in the reply indicates the netmask of the network 344 for which the answer is intended. 346 A SCOPE NETMASK value larger than the SOURCE NETMASK indicates that 347 the address and netmask provided in the query was not specific enough 348 to select a single, best response, and that an optimal reply would 349 require at least SCOPE NETMASK bits of address information. 351 Conversely, a shorter SCOPE NETMASK indicates that more bits than 352 necessary were provided. 354 As not all netblocks are the same size, an Authoritative Nameserver 355 may return different values of SCOPE NETMASK for different networks. 357 In both cases, the value of the SCOPE NETMASK in the reply has strong 358 implications with regard to how the reply will be cached by 359 Intermediate Nameservers, as described in Section 6.3. 361 If the edns-client-subnet option in the request is not used at all 362 (for example, if an optimized reply was temporarily unavailable or 363 not supported for the requested domain name), a server supporting 364 edns-client-subnet MUST indicate that no bits of the ADDRESS in the 365 request have been used by specifying a SCOPE NETMASK of 0 (equivalent 366 to the networks 0.0.0.0/0 or ::/0). 368 If no optimized answer could be found at all for the FAMILY, ADDRESS 369 and SOURCE NETMASK indicated in the query, the Authoritative 370 Nameserver SHOULD still return the best result it knows of (i.e. by 371 using the query source IP address instead, or a sensible default), 372 and indicate that this result should only be cached for the FAMILY, 373 ADDRESS and SOURCE NETMASK indicated in the request. The server will 374 indicate this by copying the SOURCE NETMASK into the SCOPE NETMASK 375 field. 377 6.3. Handling edns-client-subnet Replies and Caching 379 When an Intermediate Nameserver receives a reply containing an edns- 380 client-subnet option, it will return a reply to its client and may 381 cache the result. 383 If the FAMILY, ADDRESS and SOURCE NETMASK fields in the reply don't 384 match the fields in the corresponding request, the full reply MUST be 385 dropped, as described in Section 10. 387 In the cache, any resource record in the answer section will be tied 388 to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK 389 fields, as detailed below. Note that the additional and authority 390 sections from a DNS response message are specifically excluded here. 392 If another query is received matching the entry in the cache, the 393 resolver will verify that the FAMILY and ADDRESS that represent the 394 client match one of the networks in the cache for that entry. 396 If the address of the client is within any of the networks in the 397 cache, then the cached response MUST be returned as usual. If the 398 address of the client matches multiple networks in the cache, the 399 entry with the highest SCOPE NETMASK value MUST be returned, as with 400 most route-matching algorithms. 402 If the address of the client does not match any network in the cache, 403 then the Recursive Resolver MUST behave as if no match was found and 404 perform resolution as usual. This is necessary to avoid sub-optimal 405 replies in the cache from being returned to the wrong clients, and to 406 avoid a single request coming from a client on a different network 407 from polluting the cache with a sub-optimal reply for all the users 408 of that resolver. 410 Note that every time a Recursive Resolver queries an Authoritative 411 Nameserver by forwarding the edns-client-subnet option that it 412 received from another client, a low SOURCE NETMASK in the original 413 request could cause a sub-optimal reply to be returned by the 414 Authoritative Nameserver. 416 To avoid this sub-optimal reply from being served from cache for 417 clients for which a better reply would be available, the Recursive 418 Resolver MUST check the SCOPE NETMASK that was returned by the 419 Authoritative Nameserver: 421 o If the SCOPE NETMASK in the reply is longer than the SOURCE 422 NETMASK, it means that the reply might be sub-optimal. A 423 Recursive Resolver MUST return this entry from cache only to 424 queries that do not contain or allow a longer SOURCE NETMASK to be 425 forwarded. 427 o If the SCOPE NETMASK in the reply is shorter or equal to the 428 SOURCE NETMASK, the reply is optimal, and SHOULD be returned from 429 cache to any client within the network indicated by ADDRESS and 430 SCOPE NETMASK. 432 When another request is performed, the existing entries SHOULD be 433 kept in the cache until their TTL expires, as per standard behavior. 435 As another reply is received, the reply will be tied to a different 436 network. The server SHOULD keep in cache both replies, and return 437 the most appropriate one depending on the address of the client. 439 Although omitting this behaviour will significantly simplify an 440 implementation, the resulting drop in cache hits is very likely to 441 defeat most latency benefits provided by edns-client-subnet. 442 Therefore, when implementing this option for latency purposes, 443 implementing full caching support as described in this section is 444 STRONGLY RECOMMENDED. 446 Any reply containing an edns-client-subnet option considered invalid 447 should be treated as if no edns-client-subnet option was specified at 448 all. 450 Replies coming from servers not supporting edns-client-subnet or 451 otherwise not containing an edns-client-subnet option SHOULD be 452 considered as containing a SCOPE NETMASK of 0 (e.g., cache the result 453 for 0.0.0.0/0 or ::/0) for all the supported families. 455 In any case, the response from the resolver to the client MUST NOT 456 contain the edns-client-subnet option if none was present in the 457 client's original request. If the original client request contained 458 a valid edns-client-subnet option that was used during recursion, the 459 Recursive Resolver MUST include the edns-client-subnet option from 460 the Authoritative Nameserver response in the response to the client. 462 Enabling support for edns-client-subnet in a recursive resolver will 463 significantly increase the size of the cache, reduce the number of 464 results that can be served from cache, and increase the load on the 465 server. Implementing the mitigation techniques described in 466 Section 10 is strongly recommended. 468 6.4. Transitivity 470 Generally, edns-client-subnet options will only be present in DNS 471 messages between a Recursive Resolver and an Authoritative 472 Nameserver, i.e. one hop. In certain configurations however (for 473 example multi-tier nameserver setups), it may be necessary to 474 implement transitive behaviour on Intermediate Nameservers. 476 It is important that any Intermediate Nameserver that implements 477 transitive behaviour (i.e. forward edns-client-subnet options 478 received from their clients) MUST fully implement the caching 479 behaviour described in Section 6.3. 481 Intermediate Nameservers (including Recursive Resolvers) supporting 482 edns-client-subnet MUST forward options with SOURCE NETMASK set to 0 483 (i.e. anonymized), such an option MUST NOT be replaced with an option 484 with more accurate address information. 486 An Intermediate Nameserver MAY also forward edns-client-subnet 487 options with actual address information. This information MAY match 488 the source IP address of the incoming query, and MAY have more or 489 less address bits than the Nameserver would normally include in a 490 locally originated edns-client-subnet option. 492 If for any reason the Intermediate Nameserver does not want to use 493 the information in an edns-client-subnet option it receives (too 494 little address information, network address from an IP range not 495 authorized to use the server, private/unroutable address space, ...), 496 it SHOULD drop the query and return a REFUSED response. Note again 497 that an edns-client-subnet option with 0 address bits MUST NOT be 498 refused. 500 7. IANA Considerations 502 IANA has already assigned option code 8 in the "DNS EDNS0 Option 503 Codes (OPT)" registry to edns-client-subnet. 505 The IANA is requested to update the reference ("draft-vandergaast- 506 edns-client-subnet") to refer to this RFC when published. 508 8. DNSSEC Considerations 510 The presence or absence of an OPT resource record [TODO: Reference 511 OPT] containing an edns-client-subnet option in a DNS query does not 512 change the usage of those resource records and mechanisms used to 513 provide data origin authentication and data integrity to the DNS, as 514 described in [RFC4033], [RFC4034] and [RFC4035]. 516 9. NAT Considerations 518 Special awareness of edns-client-subnet in devices that perform NAT 519 as described in [RFC2663] is not required; queries can be passed 520 through as-is. The client's network address SHOULD NOT be added, and 521 existing edns-client-subnet options, if present, SHOULD NOT be 522 modified by NAT devices. 524 In large-scale global networks behind NAT (but for example with 525 centralized DNS infrastructure), an internal Intermediate Nameserver 526 may have detailed network layout information, and may know which 527 external subnets are used for egress traffic by each internal 528 network. In such cases, the Intermediate Nameserver MAY use that 529 information when originating edns-client-subnet options. 531 In other cases, Recursive Resolvers sited behind NAT SHOULD NOT 532 originate edns-client-subnet options with their external IP address, 533 and instead rely on downstream Intermediate Nameservers doing so. 535 10. Security Considerations 537 10.1. Privacy 539 With the edns-client-subnet option, the network address of the client 540 that initiated the resolution becomes visible to all servers involved 541 in the resolution process. Additionally, it will be visible from any 542 network traversed by the DNS packets. 544 To protect users' privacy, Recursive Resolvers are strongly 545 encouraged to conceal part of the IP address of the user by 546 truncating IPv4 addresses to 24 bits. No recommendation is provided 547 for IPv6 at this time, but IPv6 addresses should be similarly 548 truncated in order to not allow unique identification of the client. 550 ISPs will often have more detailed knowledge of their own networks. 551 I.e. they will know if all 24-bit prefixes in a /20 are in the same 552 area. In those cases, for optimal cache utilization and improved 553 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 554 this /20 to just 20 bits, instead of 24 as recommended above. 556 Users who wish their full IP address to be hidden can include an 557 edns-client-subnet option specifying the wildcard address 0.0.0.0/0 558 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). 559 As described in previous sections, this option will be forwarded 560 across all the Recursive Resolvers supporting edns-client-subnet, 561 which MUST NOT modify it to include the network address of the 562 client. 564 Note that even without edns-client-subnet options, any server queried 565 directly by the user will be able to see the full client IP address. 566 Recursive Resolvers or Authoritative Nameservers MAY use the source 567 IP address of requests to return a cached entry or to generate an 568 optimized reply that best matches the request. 570 10.2. Birthday Attacks 572 edns-client-subnet adds information to the q-tuple. This allows an 573 attacker to send a caching Intermediate Nameserver multiple queries 574 with spoofed IP addresses either in the edns-client-subnet option or 575 as the source IP. These queries will trigger multiple outgoing 576 queries with the same name, type and class, just different address 577 information in the edns-client-subnet option. 579 With multiple queries for the same name in flight, the attacker has a 580 higher chance of success in sending a matching response (with the 581 address 0.0.0.0/0 to still get it cached for many hosts). 583 To counter this, every edns-client-subnet option in a response packet 584 MUST contain the full FAMILY, ADDRESS and SOURCE NETMASK fields from 585 the corresponding request. Intermediate Nameservers processing a 586 response MUST verify that these match, and MUST discard the entire 587 reply if they do not. 589 10.3. Cache Pollution 591 It is simple for an arbitrary resolver or client to provide false 592 information in the edns-client-subnet option, or to send UDP packets 593 with forged source IP addresses. 595 This could be used to: 597 o pollute the cache of intermediate resolvers, by filling it with 598 results that will rarely (if ever) be used. 600 o reverse engineer the algorithms (or data) used by the 601 Authoritative Nameserver to caclulate the optimized answer. 603 o mount a DoS attack against an intermediate resolver, by forcing it 604 to perform many more recursive queries than it would normally do, 605 due to how caching is handled for queries containing the edns- 606 client-subnet option. 608 Even without malicious intent, Third-party Resolvers providing 609 answers to clients in multiple networks will need to cache different 610 replies for different networks, putting more pressure on the cache. 612 To mitigate those problems: 614 o Recursive Resolvers implementing edns-client-subnet should only 615 enable it in deployments where it is expected to bring clear 616 advantages to the end users. For example, when expecting clients 617 from a variety of networks or from a wide geographical area. Due 618 to the high cache pressure introduced by edns-client-subnet, the 619 feature must be disabled in all default configurations. 621 o Recursive Resolvers should limit the number of networks and 622 answers they keep in the cache for a given query. 624 o Recursive Resolvers should limit the number of total different 625 networks that they keep in cache. 627 o Recursive Resolvers should never send edns-client-subnet options 628 with SOURCE NETMASKs providing more bits in the ADDRESS than they 629 are willing to cache responses for. 631 o Recursive Resolvers should implement algorithms to improve the 632 cache hit rate, given the size constraints indicated above. 633 Recursive Resolvers may, for example, decide to discard more 634 specific cache entries first. 636 o Authoritative Nameservers and Recursive Resolvers should discard 637 known to be wrong or known to be forged edns-client-subnet 638 options. They must at least ignore unroutable addresses, such as 639 some of the address blocks defined in [RFC6890] and [RFC4193], and 640 should ignore and never forward edns-client-subnet options 641 specifying networks or addresses that are known not to be served 642 by those servers when feasible. 644 o Authoritative Nameservers consider the edns-client-subnet option 645 just as a hint to provide better results. They can decide to 646 ignore the content of the edns-client-subnet option based on black 647 or white lists, rate limiting mechanisms, or any other logic 648 implemented in the software. 650 11. Sending the Option 652 When implementing a Recursive Resolver, there are two strategies on 653 deciding when to include an edns-client-subnet option in a query. At 654 this stage, it's not clear which strategy is best. 656 11.1. Probing 658 A Recursive Resolver can send the edns-client-subnet option with 659 every outgoing query. However, it is RECOMMENDED that Resolvers 660 remember which Authoritative Nameservers did not return the option 661 with their response, and omit client address information from 662 subsequent queries to those Nameservers. 664 Additionally, Recursive Resolvers MAY be configured to never send the 665 option when querying root and TLD servers, as these are unlikely to 666 generate different replies based on the IP of the client. 668 When probing, it is important that several things are probed: support 669 for edns-client-subnet, support for EDNS0, support for EDNS0 options, 670 or possibly an unreachable Nameserver. Various implementations are 671 known to drop DNS packets with OPT RRs (with or without options), 672 thus several probes are required to discover what is supported. 674 Probing, if implemented, MUST be repeated periodically (i.e. daily). 675 If an Authoritative Nameserver indicates edns-client-subnet support 676 for one zone, it is to be expected that the Nameserver supports edns- 677 client-subnet for all its zones. Likewise, an Authoritative 678 Nameserver that uses edns-client-subnet information for one of its 679 zones, MUST indicate support for the option in all its responses. If 680 the option is supported but not actually used for generating a 681 response, its SCOPE NETMASK value SHOULD be set to 0. 683 11.2. Whitelist 685 As described previously, it is expected that only a few Recursive 686 Resolvers will need to use edns-client-subnet, and that it will 687 generally be enabled only if it offers a clear benefit to the users. 689 To avoid the complexity of implementing a probing and detection 690 mechanism (and the possible query loss/delay that may come with it), 691 an implementation could decide to use a statically configured 692 whitelist of Authoritative Namesevers to send the option to. 693 Implementations MAY also allow additionally configuring this based on 694 other criteria (i.e. zone, qtype). 696 An additional advantage of using a whitelist is that partial client 697 address information is only disclosed to Nameservers that are known 698 to use the information, improving privacy. 700 A major drawback is scalability. The operator needs to track which 701 Nameservers support edns-client-subnet, making it harder for new 702 Authoritative Nameservers to start using the option. 704 12. Example 706 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 707 www.example.com, by forwarding the query to the Recursive 708 Resolver R from IP address IP, asking for recursion. 710 2. R, supporting edns-client-subnet, looks up www.example.com in 711 its cache. An entry is found neither for www.example.com, nor 712 for example.com. 714 3. R builds a query to send to the root and .com servers. The 715 implementation of R provides facilities so an administrator can 716 configure R not to forward edns-client-subnet in certain cases. 717 In particular, R is configured to not include an edns-client- 718 subnet option when talking to TLD or root nameservers, as 719 described in Section 6.1. Thus, no edns-client-subnet option is 720 added, and resolution is performed as usual. 722 4. R now knows the next server to query: Authoritative Nameserver 723 ANS, responsible for example.com. 725 5. R prepares a new query for www.example.com, including an edns- 726 client-subnet option with: 728 * OPTION-CODE, set to 8. 730 * OPTION-LENGTH, set to 0x00 0x07. 732 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 734 * SOURCE NETMASK, set to 0x18, as R is configured to conceal 735 the last 8 bits of every IPv4 address. 737 * SCOPE NETMASK, set to 0x00, as specified by this document for 738 all requests. 740 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 741 bits of the IPv4 address. 743 6. The query is sent. Server ANS understands and uses edns-client- 744 subnet. It parses the edns-client-subnet option, and generates 745 an optimized reply. 747 7. Due to the internal implementation of the Authoritative 748 Nameserver ANS, ANS finds a reply that is optimal for the whole 749 /16 of the client that performed the request. 751 8. The Authoritative Nameserver ANS adds an edns-client-subnet 752 option in the reply, containing: 754 * OPTION-CODE, set to 8. 756 * OPTION-LENGTH, set to 0x00 0x07. 758 * FAMILY, set to 0x00 0x01. 760 * SOURCE NETMASK, set to 0x18, copied from the request. 762 * SCOPE NETMASK, set to 0x10, indicating a /16 network. 764 * ADDRESS, set to 0xC0 0x00 0x02, copied from the request. 766 9. The Recursive Resolver R receives the reply containing an edns- 767 client-subnet option. The resolver verifies that FAMILY, SOURCE 768 NETMASK, and ADDRESS match the request. If not, the option is 769 discarded. 771 10. The reply is interpreted as usual. Since the reply contains an 772 edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and 773 FAMILY in the response are used to cache the entry. 775 11. R sends a response to stub resolver SR, without including an 776 edns-client-subnet option. 778 12. R receives another request to resolve www.example.com. This 779 time, a reply is cached. The reply, however, is tied to a 780 particular network. If the address of the client matches any 781 network in the cache, then the reply is returned from the cache. 782 Otherwise, another query is performed. If multiple results 783 match, the one with the longest SCOPE NETMASK is chosen, as per 784 common best-network match algorithms. 786 13. Contributing Authors 788 The below individuals contributed significantly to the draft. The 789 RFC Editor prefers a maximum of 5 names on the front page, and so we 790 have listed additional authors in this section. 792 Edward Lewis 794 ICANN 796 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA 798 Email: edward.lewis@icann.org 800 14. Acknowledgements 802 The authors wish to thank Darryl Rodden for his work as a co-author 803 on previous versions, and the following people for reviewing early 804 drafts of this document and for providing useful feedback: Paul S. 805 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 806 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 807 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 808 Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew 809 Dempsky from OpenDNS, Patrick W. Gilmore from Akamai, Colm 810 MacCarthaigh, Richard Sheehan and all the other people that replied 811 to our emails on various mailing lists. 813 15. References 815 15.1. Normative References 817 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 818 STD 13, RFC 1034, November 1987. 820 [RFC1035] Mockapetris, P., "Domain names - implementation and 821 specification", STD 13, RFC 1035, November 1987. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 827 Rose, "DNS Security Introduction and Requirements", RFC 828 4033, March 2005. 830 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 831 Rose, "Resource Records for the DNS Security Extensions", 832 RFC 4034, March 2005. 834 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 835 Rose, "Protocol Modifications for the DNS Security 836 Extensions", RFC 4035, March 2005. 838 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 839 Addresses", RFC 4193, October 2005. 841 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 842 "Special-Purpose IP Address Registries", BCP 153, RFC 843 6890, April 2013. 845 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 846 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 848 15.2. Informative References 850 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 851 Translator (NAT) Terminology and Considerations", RFC 852 2663, August 1999. 854 15.3. URIs 856 [1] http://www.iana.org/assignments/address-family-numbers/ 858 Appendix A. Document History 860 [RFC Editor: Please delete this section before publication.] 862 A.1. -00 864 o Document moved to experimental track, added experiment description 865 in header with details in a new section. 867 o Specifically note that edns-client-subnet applies to the answer 868 section only. 870 o Warn that caching based on edns-client-subnet is optional but very 871 important for performance reasons. 873 o Updated NAT section. 875 o Added recommendation to not use the default /24 recommendation for 876 the source netmask field if more detailed information about the 877 network is available. 879 o Rewritten problem statement to be more clear about the goal of 880 edns-client-subnet and the fact that it's entirely optional. 882 o Wire format changed to include the original address and netmask in 883 responses in defence against birthday attacks. 885 o Security considerations now includes a section about birthday 886 attacks. 888 o Renamed edns-client-ip in edns-client-subnet, following 889 suggestions on the mailing list. 891 o Clarified behavior of resolvers when presented with an invalid 892 edns-client-subnet option. 894 o Fully take multi-tier DNS setups in mind and be more clear about 895 where the option should be originated. 897 o Added a few definitions in the Terminology section, and a few more 898 aesthetic changes in the rest of the document. 900 A.2. -01 902 o Document version number reset from -02 to -00 due to the rename to 903 edns-client-subnet. 905 o Clarified example (dealing with TLDs, and various minor errors). 907 o Referencing RFC5035 instead of RFC1918. 909 o Added a section on probing (and how it should be done) vs. 910 whitelisting. 912 o Moved description on how to forward edns-client-subnet option in 913 dedicated section. 915 o Queries with wrongly formatted edns-client-subnet options should 916 now be rejected with FORMERR. 918 o Added an "Overview" section, providing an introduction to the 919 document. 921 o Intermediate Nameservers can now remove an edns-client-subnet 922 option, or reduce the SOURCE NETMASK to increase privacy. 924 o Added a reference to DoS attacks in the Security section. 926 o Don't use "network range", as it seems to have different meaning 927 in other contexts, and turned out to be confusing. 929 o Use shorter and longer netmasks, rather than higher or lower. Add 930 a better explanation in the format section. 932 o Minor corrections in various other sections. 934 A.3. -02 936 o Added IANA-assigned option code. 938 Authors' Addresses 939 Carlo Contavalli 940 Google 941 1600 Amphitheater Parkway 942 Mountain View, CA 94043 943 US 945 Email: ccontavalli@google.com 947 Wilmer van der Gaast 948 Google 949 Belgrave House, 76 Buckingham Palace Road 950 London SW1W 9TQ 951 UK 953 Email: wilmer@google.com 955 Sean Leach 956 VeriSign 957 21355 Ridgetop Circle 958 Dulles, VA 20166 959 US 961 Email: sleach@verisign.com 963 David 964 Akamai 965 8 Cambridge Center 966 Cambridge, MA 02142 967 US 969 Email: tale@akamai.com 971 Warren Kumari 972 Google 973 1600 Amphitheatre Parkway 974 Mountain View, CA 94043 975 US 977 Email: warren@kumari.net