idnits 2.17.1 draft-vandergaast-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 non-RFC2606-compliant FQDNs in the document. -- 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 4, 2013) is 3949 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsext C. Contavalli 3 Internet-Draft W. van der Gaast 4 Intended status: Experimental Google 5 Expires: January 5, 2014 S. Leach 6 VeriSign 7 E. Lewis 8 Neustar 9 July 4, 2013 11 Client Subnet in DNS Requests 12 draft-vandergaast-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 reply can be cached. 20 IESG Note 22 This document describes an experimental EDNS0 option. The purpose of 23 this experiment is to discover if the information carried in an edns- 24 client-subnet option is sufficiently helpful to Authoritative 25 Nameservers to give better Optimized Replies, and to measure the 26 latency improvement from this better reply, taking into account a 27 likely lower cache hit rate at (and generally higher load on) the 28 Recursive Resolver, and possibly other operational aspects. Details 29 on how this experiment will be carried out can be found in 30 Section 12. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 5, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. Originating the Option . . . . . . . . . . . . . . . . . . 11 73 5.2. Generating a Response . . . . . . . . . . . . . . . . . . 11 74 5.3. Handling edns-client-subnet Replies and Caching . . . . . 12 75 5.4. Transitivity . . . . . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 17 78 8. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 18 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . 19 82 9.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . . 20 83 10. Sending the Option . . . . . . . . . . . . . . . . . . . . . . 22 84 10.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 10.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . . 22 86 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 12. Experiment Details . . . . . . . . . . . . . . . . . . . . . . 26 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 89 Appendix A. Document Editing History . . . . . . . . . . . . . . 28 90 Appendix A.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . 28 91 Appendix A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . 28 92 Appendix A.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . 29 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30 95 14.2. Informative References . . . . . . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 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 that the tailored answer is 137 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 1.1. 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 2. 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 3. Overview 189 The general idea of this document is to provide an EDNS0 option so 190 that Recursive Resolvers can, if they are willing to, forward details 191 about the network a query is coming from when talking to other 192 Nameservers. 194 The format of this option is described in Section 4, 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 5.1. 199 As described in Section 5.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 5.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 5.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 9 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 keep working as usual. 226 Failure to support this option or its improper handling will at worst 227 cause sub-optimal geolocation, which is a pretty common occurrence in 228 current CDN setups and not a cause of concern. 230 Section 5.1 also provides a mechanism for Stub Resolvers to signal 231 Recursive Resolvers that they do not want an edns-client-subnet with 232 their network to be added. 234 Additionally, owners of resolvers with edns-client-subnet enabled are 235 allowed to choose how many bits of the address of received queries to 236 forward, or to reduce the number of bits forwarded for queries 237 already including an edns-client-subnet option. 239 4. Option Format 241 This draft uses an EDNS0 ([RFC2671]) option to include client IP 242 information in DNS messages. The option is structured as follows: 244 +0 (MSB) +1 (LSB) 245 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 246 0: | OPTION-CODE | 247 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 248 2: | OPTION-LENGTH | 249 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 4: | FAMILY | 251 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 6: | SOURCE NETMASK | SCOPE NETMASK | 253 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 254 7: | ADDRESS... / 255 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 257 o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-client- 258 subnet is 8. 260 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 261 length of the payload (everything after OPTION-LENGTH) in bytes. 263 o FAMILY, 2 octets, indicates the family of the address contained in 264 the option, using address family codes as assigned by IANA in 265 IANA-AFI [1]. 267 The format of the address part depends on the value of FAMILY. This 268 document only defines the format for FAMILY 1 (IP version 4) and 2 269 (IP version 6), which are as follows: 271 o SOURCE NETMASK, unsigned byte representing the length of the 272 netmask pertaining to the query. In replies, it mirrors the same 273 value as in the requests. 275 o SCOPE NETMASK, unsigned byte representing the length of the 276 netmask pertaining to the reply. In requests, it MUST be set to 277 0. In responses, this may or may not match SOURCE NETMASK. 279 o ADDRESS, variable number of octets, contains either an IPv4 or 280 IPv6 address (depending on FAMILY), truncated to the number of 281 bits indicated by the SOURCE NETMASK field, with bits set to 0 to 282 pad up to the end of the last octet used. 284 All fields are in network byte order. Throughout the document, we 285 will often refer to "longer" or "shorter" netmasks, corresponding to 286 netmasks that have a "higher" or "lower" value when represented as 287 integers. 289 5. Protocol Description 291 5.1. Originating the Option 293 The edns-client-subnet option should generally be added by Recursive 294 Resolvers when querying other servers, as described in Section 10. 296 In this option, the server should include the IP of the client that 297 caused the query to be generated, truncated to a number of bits 298 specified in the SOURCE NETMASK field. 300 The IP of the client can generally be determined by looking at the 301 source IP indicated in the IP header of the request. 303 A Stub Resolver MAY generate DNS queries with an edns-client-subnet 304 option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that 305 the Recursive Resolver MUST NOT add address information of the client 306 to its queries. The Stub Resolver may also add non-empty edns- 307 client-subnet options to its queries, but Recursive Resolvers are not 308 required to accept/use this information. 310 For privacy reasons, and because the whole IP address is rarely 311 required to determine an optimized reply, the ADDRESS field in the 312 option SHOULD be truncated to a certain number of bits, chosen by the 313 administrators of the server, as described in Section 9. 315 5.2. Generating a Response 317 When a query containing an edns-client-subnet option is received, an 318 Authoritative Nameserver supporting edns-client-subnet MAY use the 319 address information specified in the option in order to generate an 320 optimized reply. 322 Authoritative servers that have not implemented or enabled support 323 for the edns-client-subnet may safely ignore the option within 324 incoming queries. Such a server MUST NOT include an edns-client- 325 subnet option within replies, to indicate lack of support for the 326 option. 328 Requests with wrongly formatted options (i.e. wrong size) MUST be 329 rejected and a FORMERR response must be returned to the sender, as 330 described by [RFC2671], Transport Considerations. 332 If the Authoritative Nameserver decides to use information from the 333 edns-client-subnet option to calculate a response, it MUST include 334 the option in the response to indicate that the information was used 335 (and has to be cached accordingly). If the option was not included 336 in a query, it MUST NOT be included in the response. 338 The FAMILY, ADDRESS and SOURCE NETMASK in the response MUST match 339 those in the request. Echoing back the address and netmask helps to 340 mitigate certain attack vectors, as described in Section 9. 342 The SCOPE NETMASK in the reply indicates the netmask of the network 343 that the answer is intended for. 345 A SCOPE NETMASK value larger than the SOURCE NETMASK indicates that 346 the address and netmask provided in the query was not specific enough 347 to select a single, best response, and that an optimal reply would 348 require at least SCOPE NETMASK bits of address information. 350 Conversely, a shorter SCOPE NETMASK indicates that more bits than 351 necessary were provided. 353 As not all netblocks are the same size, an Authoritative Nameserver 354 may return different values of SCOPE NETMASK for different networks. 356 In both cases, the value of the SCOPE NETMASK in the reply has strong 357 implications with regard to how the reply will be cached by 358 Intermediate Nameservers, as described in Section 5.3. 360 If the edns-client-subnet option in the request is not used at all 361 (for example if an optimized reply was temporarily unavailable or not 362 supported for the requested domain name), a server supporting edns- 363 client-subnet MUST indicate that no bits of the ADDRESS in the 364 request have been used by specifying a SCOPE NETMASK of 0 (equivalent 365 to the networks 0.0.0.0/0 or ::/0). 367 If no optimized answer could be found at all for the FAMILY, ADDRESS 368 and SOURCE NETMASK indicated in the query, the Authoritative 369 Nameserver SHOULD still return the best result it knows of (i.e. by 370 using the query source IP address instead, or a sensible default), 371 and indicate that this result should only be cached for the FAMILY, 372 ADDRESS and SOURCE NETMASK indicated in the request. The server will 373 indicate this by copying the SOURCE NETMASK into the SCOPE NETMASK 374 field. 376 5.3. Handling edns-client-subnet Replies and Caching 378 When an Intermediate Nameserver receives a reply containing an edns- 379 client-subnet option, it will return a reply to its client and may 380 cache the result. 382 If the FAMILY, ADDRESS and SOURCE NETMASK fields in the reply don't 383 match the fields in the corresponding request, the full reply MUST be 384 dropped, as described in Section 9. 386 In the cache, any resource record in the answer section will be tied 387 to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK 388 fields, as detailed below. Note that the additional and authority 389 sections from a DNS response message are specifically excluded here. 391 If another query is received matching the entry in the cache, the 392 resolver will verify that the FAMILY and ADDRESS that represent the 393 client match any of the networks in the cache for that entry. 395 If the address of the client is within any of the networks in the 396 cache, then the cached response MUST be returned as usual. In case 397 the address of the client matches multiple networks in the cache, the 398 entry with the highest SCOPE NETMASK value MUST be returned, as with 399 most route-matching algorithms. 401 If the address of the client does not match any network in the cache, 402 then the Recursive Resolver MUST behave as if no match was found and 403 perform resolution as usual. This is necessary to avoid sub-optimal 404 replies in the cache from being returned to the wrong clients, and to 405 avoid a single request coming from a client on a different network 406 from polluting the cache with a sub-optimal reply for all the users 407 of that resolver. 409 Note that every time a Recursive Resolver queries an Authoritative 410 Nameserver by forwarding the edns-client-subnet option that it 411 received from another client, a low SOURCE NETMASK in the original 412 request could cause a sub-optimal reply to be returned by the 413 Authoritative Nameserver. 415 To avoid this sub-optimal reply from being served from cache for 416 clients for which a better reply would be available, the Recursive 417 Resolver MUST check the SCOPE NETMASK that was returned by the 418 Authoritative Nameserver: 420 o If the SCOPE NETMASK in the reply is longer than the SOURCE 421 NETMASK, it means that the reply might be sub-optimal. A 422 Recursive Resolver MUST return this entry from cache only to 423 queries that do not contain or allow a longer SOURCE NETMASK to be 424 forwarded. 426 o If the SCOPE NETMASK in the reply is shorter or equal to the 427 SOURCE NETMASK, the reply is optimal, and SHOULD be returned from 428 cache to any client within the network indicated by ADDRESS and 429 SCOPE NETMASK. 431 When another request is performed, the existing entries SHOULD be 432 kept in the cache until their TTL expires, as per standard behavior. 434 As another reply is received, the reply will be tied to a different 435 network. The server SHOULD keep in cache both replies, and return 436 the most appropriate one depending on the address of the client. 438 Although omitting this behaviour will significantly simplify an 439 implementation, the resulting drop in cache hits is very likely to 440 defeat most latency benefits provided by edns-client-subnet. 441 Therefore, when implementing this option for latency purposes, 442 implementing full caching support as described in this section is 443 STRONGLY RECOMMENDED. 445 Any reply containing an edns-client-subnet option considered invalid 446 should be treated as if no edns-client-subnet option was specified at 447 all. 449 Replies coming from servers not supporting edns-client-subnet or 450 otherwise not containing an edns-client-subnet option SHOULD be 451 considered as containing a SCOPE NETMASK of 0 (e.g., cache the result 452 for 0.0.0.0/0 or ::/0) for all the supported families. 454 In any case, the response from the resolver to the client MUST NOT 455 contain the edns-client-subnet option if none was present in the 456 client's original request. If the original client request contained 457 a valid edns-client-subnet option that was used during recursion, the 458 Recursive Resolver MUST include the edns-client-subnet option from 459 the Authoritative Nameserver response in the response to the client. 461 Enabling support for edns-client-subnet in a recursive resolver will 462 significantly increase the size of the cache, reduce the number of 463 results that can be served from cache, and increase the load on the 464 server. Implementing the mitigation techniques described in 465 Section 9 is strongly recommended. 467 5.4. Transitivity 469 Generally, edns-client-subnet options will only be present in DNS 470 messages between a Recursive Resolver and an Authoritative 471 Nameserver, i.e. one hop. In certain configurations however (for 472 example multi-tier nameserver setups), it may be necessary to 473 implement transitive behaviour on Intermediate Nameservers. 475 It is important that any Intermediate Nameserver that implements 476 transitive behaviour (i.e. forward edns-client-subnet options 477 received from their clients) MUST fully implement the caching 478 behaviour described in Section 5.3. 480 Intermediate Nameservers (including Recursive Resolvers) supporting 481 edns-client-subnet MUST forward options with SOURCE NETMASK set to 0 482 (i.e. anonymized), such an option MUST NOT be replaced with an option 483 with more accurate address information. 485 An Intermediate Nameserver MAY also forward edns-client-subnet 486 options with actual address information. This information MAY match 487 the source IP address of the incoming query, and MAY have more or 488 less address bits than the Nameserver would normally include in a 489 locally originated edns-client-subnet option. 491 If for any reason the Intermediate Nameserver does not want to use 492 the information in an edns-client-subnet option it receives (too 493 little address information, network address from an IP range not 494 authorized to use the server, private/unroutable address space, ...) 495 it SHOULD drop the query and return a REFUSED response. Note again 496 that an edns-client-subnet option with 0 address bits MUST NOT be 497 refused. 499 6. IANA Considerations 501 IANA has assigned option code 8 in the "DNS EDNS0 Option Codes (OPT)" 502 registry to edns-client-subnet. 504 7. DNSSEC Considerations 506 The presence or absence of an OPT resource record containing an edns- 507 client-subnet option in a DNS query does not change the usage of 508 those resource records and mechanisms used to provide data origin 509 authentication and data integrity to the DNS, as described in 510 [RFC4033], [RFC4034] and [RFC4035]. 512 8. NAT Considerations 514 Special awareness of edns-client-subnet in devices that perform NAT 515 as described in [RFC2663] is not required, queries can be passed 516 through as-is. The client's network address SHOULD NOT be added, and 517 existing edns-client-subnet options, if present, SHOULD NOT be 518 modified by NAT devices. 520 In large-scale global networks behind NAT (but for example with 521 centralized DNS infrastructure), an internal Intermediate Nameserver 522 may have detailed network layout information, and may know which 523 external subnets are used for egress traffic by each internal 524 network. In such cases, the Intermediate Nameserver MAY use that 525 information when originating edns-client-subnet options. 527 In other cases, Recursive Resolvers sited behind NAT SHOULD NOT 528 originate edns-client-subnet options with their external IP address, 529 and instead rely on downstream Intermediate Nameservers doing so. 531 9. Security Considerations 533 9.1. Privacy 535 With the edns-client-subnet option, the network address of the client 536 that initiated the resolution becomes visible to all servers involved 537 in the resolution process. Additionally, it will be visible from any 538 network traversed by the DNS packets. 540 To protect users' privacy, Recursive Resolvers are strongly 541 encouraged to conceal part of the IP address of the user by 542 truncating IPv4 addresses to 24 bits. No recommendation is provided 543 for IPv6 at this time, but IPv6 addresses should be similarly 544 truncated in order to not allow to uniquely identify the client. 546 ISPs will often have more detailed knowledge of their own networks. 547 I.e. they will know if all 24-bit prefixes in a /20 are in the same 548 area. In those cases, for optimal cache utilization and improved 549 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 550 this /20 to just 20 bits, instead of 24 as recommended above. 552 Users who wish their full IP address to be hidden can include an 553 edns-client-subnet option specifying the wildcard address 0.0.0.0/0 554 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). 555 As described in previous sections, this option will be forwarded 556 across all the Recursive Resolvers supporting edns-client-subnet, 557 which MUST NOT modify it to include the network address of the 558 client. 560 Note that even without edns-client-subnet options, any server queried 561 directly by the user will be able to see the full client IP address. 562 Recursive Resolvers or Authoritative Nameservers MAY use the source 563 IP address of requests to return a cached entry or to generate an 564 optimized reply that best matches the request. 566 9.2. Birthday Attacks 568 edns-client-subnet adds information to the q-tuple. This allows an 569 attacker to send a caching Intermediate Nameserver multiple queries 570 with spoofed IP addresses either in the edns-client-subnet option or 571 as the source IP. These queries will trigger multiple outgoing 572 queries with the same name, type and class, just different address 573 information in the edns-client-subnet option. 575 With multiple queries for the same name in flight, the attacker has a 576 higher chance of success in sending a matching response (with the 577 address 0.0.0.0/0 to still get it cached for many hosts). 579 To counter this, every edns-client-subnet option in a response packet 580 MUST contain the full FAMILY, ADDRESS and SOURCE NETMASK fields from 581 the corresponding request. Intermediate Nameservers processing a 582 response MUST verify that these match, and MUST discard the entire 583 reply if they do not. 585 9.3. Cache Pollution 587 It is simple for an arbitrary resolver or client to provide false 588 information in the edns-client-subnet option, or to send UDP packets 589 with forged source IP addresses. 591 This could be used to: 593 o pollute the cache of intermediate resolvers, by filling it with 594 results that will rarely (if ever) be used. 596 o reverse engineer the algorithms (or data) used by the 597 Authoritative Nameserver to caclulate the optimized answer. 599 o mount a DoS attack against an intermediate resolver, by forcing it 600 to perform many more recursive queries than it would normally do, 601 due to how caching is handled for queries containing the edns- 602 client-subnet option. 604 Even without malicious intent, Third-party Resolvers providing 605 answers to clients in multiple networks will need to cache different 606 replies for different networks, putting more pressure on the cache. 608 To mitigate those problems: 610 o Recursive Resolvers implementing edns-client-subnet should only 611 enable it in deployments where it is expected to bring clear 612 advantages to the end users. For example, when expecting clients 613 from a variety of networks or from a wide geographical area. Due 614 to the high cache pressure introduced by edns-client-subnet, the 615 feature must be disabled in all default configurations. 617 o Recursive Resolvers should limit the number of networks and 618 answers they keep in the cache for a given query. 620 o Recursive Resolvers should limit the number of total different 621 networks that they keep in cache. 623 o Recursive Resolvers should never send edns-client-subnet options 624 with SOURCE NETMASKs providing more bits in the ADDRESS than they 625 are willing to cache responses for. 627 o Recursive Resolvers should implement algorithms to improve the 628 cache hit rate, given the size constraints indicated above. 629 Recursive Resolvers may, for example, decide to discard more 630 specific cache entries first. 632 o Authoritative Nameservers and Recursive Resolvers should discard 633 known to be wrong or known to be forged edns-client-subnet 634 options. They must at least ignore unroutable addresses, such as 635 some of the address blocks defined in [RFC5735] and [RFC4193], and 636 should ignore and never forward edns-client-subnet options 637 specifying networks or addresses that are known not to be served 638 by those servers when feasible. 640 o Authoritative Nameservers consider the edns-client-subnet option 641 just as a hint to provide better results. They can decide to 642 ignore the content of the edns-client-subnet option based on black 643 or white lists, rate limiting mechanisms, or any other logic 644 implemented in the software. 646 10. Sending the Option 648 When implementing a Recursive Resolver, there are two strategies on 649 deciding when to include an edns-client-subnet option in a query. At 650 this stage it's not clear which strategy is best. 652 10.1. Probing 654 A Recursive Resolver can send the edns-client-subnet option with 655 every outgoing query. However, it is RECOMMENDED that Resolvers 656 remember which Authoritative Nameservers did not return the option 657 with their response, and omit client address information from 658 subsequent queries to those Nameservers. 660 Additionally, Recursive Resolvers MAY be configured to never send the 661 option when querying root and TLD servers, as these are unlikely to 662 generate different replies based on the IP of the client. 664 When probing, it is important that several things are probed: support 665 for edns-client-subnet, support for EDNS0, support for EDNS0 options, 666 or possibly an unreachable Nameserver. Various implementations are 667 known to drop DNS packets with OPT RRs (with or without options), 668 thus several probes are required to discover what is supported. 670 Probing, if implemented, MUST be repeated periodically (i.e. daily). 671 If an Authoritative Nameserver indicates edns-client-subnet support 672 for one zone, it is to be expected that the Nameserver supports edns- 673 client-subnet for all its zones. Likewise, an Authoritative 674 Nameserver that uses edns-client-subnet information for one of its 675 zones, MUST indicate support for the option in all its responses. If 676 the option is supported but not actually used for generating a 677 response, its SCOPE NETMASK value SHOULD be set to 0. 679 10.2. Whitelist 681 As described previously, it is expected that only a few Recursive 682 Resolvers will need to use edns-client-subnet, and that it will 683 generally be enabled only if it offers a clear benefit to the users. 685 To avoid the complexity of implementing a probing and detection 686 mechanism (and the possible query loss/delay that may come with it), 687 an implementation could decide to use a statically configured 688 whitelist of Authoritative Namesevers to send the option to. 689 Implementations MAY also allow additionally configuring this based on 690 other criteria (i.e. zone, qtype). 692 An additional advantage of using a whitelist is that partial client 693 address information is only disclosed to Nameservers that are known 694 to use the information, improving privacy. 696 A major drawback is scalability. The operator needs to track which 697 Nameservers support edns-client-subnet, making it harder for new 698 Authoritative Nameservers to start using the option. 700 11. Example 702 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 703 www.example.com, by forwarding the query to the Recursive 704 Resolver R from IP address IP, asking for recursion. 706 2. R, supporting edns-client-subnet, looks up www.example.com in 707 its cache. An entry is found neither for www.example.com, nor 708 for example.com. 710 3. R builds a query to send to the root and .com servers. The 711 implementation of R provides facilities so an administrator can 712 configure R not to forward edns-client-subnet in certain cases. 713 In particular, R is configured to not include an edns-client- 714 subnet option when talking to TLD or root nameservers, as 715 described in Section 5.1. Thus, no edns-client-subnet option is 716 added, and resolution is performed as usual. 718 4. R now knows the next server to query: Authoritative Nameserver 719 ANS, responsible for example.com. 721 5. R prepares a new query for www.example.com, including an edns- 722 client-subnet option with: 724 * OPTION-CODE, set to 8. 726 * OPTION-LENGTH, set to 0x00 0x07. 728 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 730 * SOURCE NETMASK, set to 0x18, as R is configured to conceal 731 the last 8 bits of every IPv4 address. 733 * SCOPE NETMASK, set to 0x00, as specified by this document for 734 all requests. 736 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 737 bits of the IPv4 address. 739 6. The query is sent. Server ANS understands and uses edns-client- 740 subnet. It parses the edns-client-subnet option, and generates 741 an optimized reply. 743 7. Due to the internal implementation of the Authoritative 744 Nameserver ANS, ANS finds a reply that is optimal for the whole 745 /16 of the client that performed the request. 747 8. The Authoritative Nameserver ANS adds an edns-client-subnet 748 option in the reply, containing: 750 * OPTION-CODE, set to 8. 752 * OPTION-LENGTH, set to 0x00 0x07. 754 * FAMILY, set to 0x00 0x01. 756 * SOURCE NETMASK, set to 0x18, copied from the request. 758 * SCOPE NETMASK, set to 0x10, indicating a /16 network. 760 * ADDRESS, set to 0xC0 0x00 0x02, copied from the request. 762 9. The Recursive Resolver R receives the reply containing an edns- 763 client-subnet option. The resolver verifies that FAMILY, SOURCE 764 NETMASK, and ADDRESS match the request. If not, the option is 765 discarded. 767 10. The reply is interpreted as usual. Since the reply contains an 768 edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and 769 FAMILY in the response are used to cache the entry. 771 11. R sends a response to stub resolver SR, without including an 772 edns-client-subnet option. 774 12. R receives another request to resolve www.example.com. This 775 time, a reply is cached. The reply, however, is tied to a 776 particular network. If the address of the client matches any 777 network in the cache, then the reply is returned from the cache. 778 Otherwise, another query is performed. If multiple results 779 match, the one with the longest SCOPE NETMASK is chosen, as per 780 common best-network match algorithms. 782 12. Experiment Details 784 This document describes an experiment to be conducted on the 785 Internet. Participation requires the careful eye on the proposed 786 EDNS0 option. What is described in this document may need to be 787 altered or adjusted as experience dictates. 789 During the experiment, participants will enable edns-client-subnet 790 support on their Nameservers (both Intermediate Nameservers and 791 Authoritative Nameservers). 793 Intermediate Nameservers will be configured with whitelists so edns- 794 client-subnet options will be sent only to Authoritative Nameservers 795 participating in the experiment. Some participants might also choose 796 to experiment with the probing behaviour described in Section 10.1. 798 Authoritative Nameservers could be configured with a whitelist but 799 maintainers are strongly encouraged to accept edns-client-subnet 800 options from anywhere to encourage openness. ns1-ns4.google.com are 801 configured as such and can be used to test client/resolver 802 implementations. 804 Pending official code point allocation (as described in Section 6), a 805 temporary EDNS0 option code will be in use. This code is not 806 guaranteed to be used in further stages of this effort - assuming the 807 are further stages. 809 The effects of edns-client-subnet will be measured using data of 24- 810 hour periods with and without the option enabled on a Recursive 811 Resolver. Metrics to be compared include: 813 o Cache hit rate on the Recursive Resolver. 815 o Average response time on the Recursive Resolver. 817 o Increase in query rate on both Recursive Resolvers and 818 Authoritative Nameservers. 820 o Most importantly, difference in load times as measured by user 821 agents (especially web browsers). 823 Success of the experiment will depend on the level of improvement in 824 the last mentioned metric. Others are for operational reasons (i.e. 825 does one need to provision for extra Nameservers?). 827 Possible side-effects from using edns-client-subnet will also be 828 investigated. These may include interoperability problems within the 829 DNS and decreased (or possibly increased) ease of troubleshooting. 831 13. Acknowledgements 833 The authors wish to thank Darryl Rodden for his work as a co-author 834 on previous versions, and the following people for reviewing early 835 drafts of this document and for providing useful feedback: Paul S. R. 836 Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 837 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 838 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 839 Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew 840 Dempsky from OpenDNS, Patrick W. Gilmore from Akamai, Colm 841 MacCarthaigh, Richard Sheehan and all the other people that replied 842 to our emails on various mailing lists. 844 Appendix A. Document Editing History 846 [This section should be removed by the RFC editor before publishing] 848 Appendix A.1. -02 850 o Added IANA-assigned option code. 852 Appendix A.2. -00 854 o Document moved to experimental track, added experiment description 855 in header with details in a new section. 857 o Specifically note that edns-client-subnet applies to the answer 858 section only. 860 o Warn that caching based on edns-client-subnet is optional but very 861 important for performance reasons. 863 o Updated NAT section. 865 o Added recommendation to not use the default /24 recommendation for 866 the source netmask field if more detailed information about the 867 network is available. 869 o Rewritten problem statement to be more clear about the goal of 870 edns-client-subnet and the fact that it's entirely optional. 872 o Wire format changed to include the original address and netmask in 873 responses in defence against birthday attacks. 875 o Security considerations now includes a section about birthday 876 attacks. 878 o Renamed edns-client-ip in edns-client-subnet, following 879 suggestions on the mailing list. 881 o Clarified behavior of resolvers when presented with an invalid 882 edns-client-subnet option. 884 o Fully take multi-tier DNS setups in mind and be more clear about 885 where the option should be originated. 887 o Added a few definitions in the Terminology section, and a few more 888 aesthetic changes in the rest of the document. 890 Appendix A.3. -01 892 o Document version number reset from -02 to -00 due to the rename to 893 edns-client-subnet. 895 o Clarified example (dealing with TLDs, and various minor errors). 897 o Referencing RFC5035 instead of RFC1918. 899 o Added a section on probing (and how it should be done) vs. 900 whitelisting. 902 o Moved description on how to forward edns-client-subnet option in 903 dedicated section. 905 o Queries with wrongly formatted edns-client-subnet options should 906 now be rejected with FORMERR. 908 o Added an "Overview" section, providing an introduction to the 909 document. 911 o Intermediate Nameservers can now remove an edns-client-subnet 912 option, or reduce the SOURCE NETMASK to increase privacy. 914 o Added a reference to DoS attacks in the Security section. 916 o Don't use "network range", as it seems to have different meaning 917 in other contexts, and turned out to be confusing. 919 o Use shorter and longer netmasks, rather than higher or lower. Add 920 a better explanation in the format section. 922 o Minor corrections in various other sections. 924 14. References 926 14.1. Normative References 928 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 929 STD 13, RFC 1034, November 1987. 931 [RFC1035] Mockapetris, P., "Domain names - implementation and 932 specification", STD 13, RFC 1035, November 1987. 934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 935 Requirement Levels", BCP 14, RFC 2119, March 1997. 937 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 938 RFC 2671, August 1999. 940 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 941 Rose, "DNS Security Introduction and Requirements", 942 RFC 4033, March 2005. 944 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 945 Rose, "Resource Records for the DNS Security Extensions", 946 RFC 4034, March 2005. 948 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 949 Rose, "Protocol Modifications for the DNS Security 950 Extensions", RFC 4035, March 2005. 952 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 953 Addresses", RFC 4193, October 2005. 955 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 956 RFC 5735, January 2010. 958 14.2. Informative References 960 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 961 Translator (NAT) Terminology and Considerations", 962 RFC 2663. 964 URIs 966 [1] 968 Authors' Addresses 970 Carlo Contavalli 971 Google 972 1600 Amphitheater Parkway 973 Mountain View, CA 94043 974 US 976 Email: ccontavalli@google.com 978 Wilmer van der Gaast 979 Google 980 Belgrave House, 76 Buckingham Palace Road 981 London SW1W 9TQ 982 UK 984 Email: wilmer@google.com 986 Sean Leach 987 VeriSign 988 21355 Ridgetop Circle 989 Dulles, VA 20166 990 US 992 Email: sleach@verisign.com 994 Edward Lewis 995 Neustar 996 46000 Center Oak Plaza 997 Sterling, VA 20166 998 US 1000 Email: ed.lewis@neustar.biz