idnits 2.17.1 draft-vandergaast-edns-client-subnet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with 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 (April 25, 2012) is 4377 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: October 27, 2012 S. Leach 6 VeriSign 7 E. Lewis 8 Neustar 9 April 25, 2012 11 Client subnet in DNS requests 12 draft-vandergaast-edns-client-subnet-01 14 Abstract 16 This draft defines an EDNS0 extension to carry information about the 17 network that originated a DNS query, and the network for which the 18 subsequent 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 October 27, 2012. 49 Copyright Notice 51 Copyright (c) 2012 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. Changes since edns-client-subnet-00 . . . . . . . . 28 91 Appendix A.2. Changes since edns-client-ip-01 . . . . . . . . . . 28 92 Appendix A.3. Changes since edns-client-ip-00 . . . . . . . . . . 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 TBD. 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 We request IANA to assign an option code for edns-client-subnet, as 502 specified in [RFC2671]. Within this document, the text 'TBD' should 503 be replaced with the option code assigned by IANA. 505 7. DNSSEC Considerations 507 The presence or absence of an OPT resource record containing an edns- 508 client-subnet option in a DNS query does not change the usage of 509 those resource records and mechanisms used to provide data origin 510 authentication and data integrity to the DNS, as described in 511 [RFC4033], [RFC4034] and [RFC4035]. 513 8. NAT Considerations 515 Special awareness of edns-client-subnet in devices that perform NAT 516 as described in [RFC2663] is not required, queries can be passed 517 through as-is. The client's network address SHOULD NOT be added, and 518 existing edns-client-subnet options, if present, SHOULD NOT be 519 modified by NAT devices. 521 In large-scale global networks behind NAT (but for example with 522 centralized DNS infrastructure), an internal Intermediate Nameserver 523 may have detailed network layout information, and may know which 524 external subnets are used for egress traffic by each internal 525 network. In such cases, the Intermediate Nameserver MAY use that 526 information when originating edns-client-subnet options. 528 In other cases, Recursive Resolvers sited behind NAT SHOULD NOT 529 originate edns-client-subnet options with their external IP address, 530 and instead rely on downstream Intermediate Nameservers doing so. 532 9. Security Considerations 534 9.1. Privacy 536 With the edns-client-subnet option, the network address of the client 537 that initiated the resolution becomes visible to all servers involved 538 in the resolution process. Additionally, it will be visible from any 539 network traversed by the DNS packets. 541 To protect users' privacy, Recursive Resolvers are strongly 542 encouraged to conceal part of the IP address of the user by 543 truncating IPv4 addresses to 24 bits. No recommendation is provided 544 for IPv6 at this time, but IPv6 addresses should be similarly 545 truncated in order to not allow to uniquely identify the client. 547 ISPs will often have more detailed knowledge of their own networks. 548 I.e. they will know if all 24-bit prefixes in a /20 are in the same 549 area. In those cases, for optimal cache utilization and improved 550 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in 551 this /20 to just 20 bits, instead of 24 as recommended above. 553 Users who wish their full IP address to be hidden can include an 554 edns-client-subnet option specifying the wildcard address 0.0.0.0/0 555 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). 556 As described in previous sections, this option will be forwarded 557 across all the Recursive Resolvers supporting edns-client-subnet, 558 which MUST NOT modify it to include the network address of the 559 client. 561 Note that even without edns-client-subnet options, any server queried 562 directly by the user will be able to see the full client IP address. 563 Recursive Resolvers or Authoritative Nameservers MAY use the source 564 IP address of requests to return a cached entry or to generate an 565 optimized reply that best matches the request. 567 9.2. Birthday attacks 569 edns-client-subnet adds information to the q-tuple. This allows an 570 attacker to send a caching Intermediate Nameserver multiple queries 571 with spoofed IP addresses either in the edns-client-subnet option or 572 as the source IP. These queries will trigger multiple outgoing 573 queries with the same name, type and class, just different address 574 information in the edns-client-subnet option. 576 With multiple queries for the same name in flight, the attacker has a 577 higher chance of success in sending a matching response (with the 578 address 0.0.0.0/0 to still get it cached for many hosts). 580 To counter this, every edns-client-subnet option in a response packet 581 MUST contain the full FAMILY, ADDRESS and SOURCE NETMASK fields from 582 the corresponding request. Intermediate Nameservers processing a 583 response MUST verify that these match, and MUST discard the entire 584 reply if they do not. 586 9.3. Cache pollution 588 It is simple for an arbitrary resolver or client to provide false 589 information in the edns-client-subnet option, or to send UDP packets 590 with forged source IP addresses. 592 This could be used to: 594 o pollute the cache of intermediate resolvers, by filling it with 595 results that will rarely (if ever) be used. 597 o reverse engineer the algorithms (or data) used by the 598 Authoritative Nameserver to caclulate the optimized answer. 600 o mount a DoS attack against an intermediate resolver, by forcing it 601 to perform many more recursive queries than it would normally do, 602 due to how caching is handled for queries containing the edns- 603 client-subnet option. 605 Even without malicious intent, Third-party Resolvers providing 606 answers to clients in multiple networks will need to cache different 607 replies for different networks, putting more pressure on the cache. 609 To mitigate those problems: 611 o Recursive Resolvers implementing edns-client-subnet should only 612 enable it in deployments where it is expected to bring clear 613 advantages to the end users. For example, when expecting clients 614 from a variety of networks or from a wide geographical area. Due 615 to the high cache pressure introduced by edns-client-subnet, the 616 feature must be disabled in all default configurations. 618 o Recursive Resolvers should limit the number of networks and 619 answers they keep in the cache for a given query. 621 o Recursive Resolvers should limit the number of total different 622 networks that they keep in cache. 624 o Recursive Resolvers should never send edns-client-subnet options 625 with SOURCE NETMASKs providing more bits in the ADDRESS than they 626 are willing to cache responses for. 628 o Recursive Resolvers should implement algorithms to improve the 629 cache hit rate, given the size constraints indicated above. 630 Recursive Resolvers may, for example, decide to discard more 631 specific cache entries first. 633 o Authoritative Nameservers and Recursive Resolvers should discard 634 known to be wrong or known to be forged edns-client-subnet 635 options. They must at least ignore unroutable addresses, such as 636 some of the address blocks defined in [RFC5735] and [RFC4193], and 637 should ignore and never forward edns-client-subnet options 638 specifying networks or addresses that are known not to be served 639 by those servers when feasible. 641 o Authoritative Nameservers consider the edns-client-subnet option 642 just as a hint to provide better results. They can decide to 643 ignore the content of the edns-client-subnet option based on black 644 or white lists, rate limiting mechanisms, or any other logic 645 implemented in the software. 647 10. Sending the option 649 When implementing a Recursive Resolver, there are two strategies on 650 deciding when to include an edns-client-subnet option in a query. At 651 this stage it's not clear which strategy is best. 653 10.1. Probing 655 A Recursive Resolver can send the edns-client-subnet option with 656 every outgoing query. However, it is RECOMMENDED that Resolvers 657 remember which Authoritative Nameservers did not return the option 658 with their response, and omit client address information from 659 subsequent queries to those Nameservers. 661 Additionally, Recursive Resolvers MAY be configured to never send the 662 option when querying root and TLD servers, as these are unlikely to 663 generate different replies based on the IP of the client. 665 When probing, it is important that several things are probed: support 666 for edns-client-subnet, support for EDNS0, support for EDNS0 options, 667 or possibly an unreachable Nameserver. Various implementations are 668 known to drop DNS packets with OPT RRs (with or without options), 669 thus several probes are required to discover what is supported. 671 Probing, if implemented, MUST be repeated periodically (i.e. daily). 672 If an Authoritative Nameserver indicates edns-client-subnet support 673 for one zone, it is to be expected that the Nameserver supports edns- 674 client-subnet for all its zones. Likewise, an Authoritative 675 Nameserver that uses edns-client-subnet information for one of its 676 zones, MUST indicate support for the option in all its responses. If 677 the option is supported but not actually used for generating a 678 response, its SCOPE NETMASK value SHOULD be set to 0. 680 10.2. Whitelist 682 As described previously, it is expected that only a few Recursive 683 Resolvers will need to use edns-client-subnet, and that it will 684 generally be enabled only if it offers a clear benefit to the users. 686 To avoid the complexity of implementing a probing and detection 687 mechanism (and the possible query loss/delay that may come with it), 688 an implementation could decide to use a statically configured 689 whitelist of Authoritative Namesevers to send the option to. 690 Implementations MAY also allow additionally configuring this based on 691 other criteria (i.e. zone, qtype). 693 An additional advantage of using a whitelist is that partial client 694 address information is only disclosed to Nameservers that are known 695 to use the information, improving privacy. 697 A major drawback is scalability. The operator needs to track which 698 Nameservers support edns-client-subnet, making it harder for new 699 Authoritative Nameservers to start using the option. 701 11. Example 703 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 704 www.example.com, by forwarding the query to the Recursive 705 Resolver R from IP address IP, asking for recursion. 707 2. R, supporting edns-client-subnet, looks up www.example.com in 708 its cache. An entry is found neither for www.example.com, nor 709 for example.com. 711 3. R builds a query to send to the root and .com servers. The 712 implementation of R provides facilities so an administrator can 713 configure R not to forward edns-client-subnet in certain cases. 714 In particular, R is configured to not include an edns-client- 715 subnet option when talking to TLD or root nameservers, as 716 described in Section 5.1. Thus, no edns-client-subnet option is 717 added, and resolution is performed as usual. 719 4. R now knows the next server to query: Authoritative Nameserver 720 ANS, responsible for example.com. 722 5. R prepares a new query for www.example.com, including an edns- 723 client-subnet option with: 725 * OPTION-CODE, set to TBD. 727 * OPTION-LENGTH, set to 0x00 0x07. 729 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 731 * SOURCE NETMASK, set to 0x18, as R is configured to conceal 732 the last 8 bits of every IPv4 address. 734 * SCOPE NETMASK, set to 0x00, as specified by this document for 735 all requests. 737 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 738 bits of the IPv4 address. 740 6. The query is sent. Server ANS understands and uses edns-client- 741 subnet. It parses the edns-client-subnet option, and generates 742 an optimized reply. 744 7. Due to the internal implementation of the Authoritative 745 Nameserver ANS, ANS finds a reply that is optimal for the whole 746 /16 of the client that performed the request. 748 8. The Authoritative Nameserver ANS adds an edns-client-subnet 749 option in the reply, containing: 751 * OPTION-CODE, set to TBD. 753 * OPTION-LENGTH, set to 0x00 0x07. 755 * FAMILY, set to 0x00 0x01. 757 * SOURCE NETMASK, set to 0x18, copied from the request. 759 * SCOPE NETMASK, set to 0x10, indicating a /16 network. 761 * ADDRESS, set to 0xC0 0x00 0x02, copied from the request. 763 9. The Recursive Resolver R receives the reply containing an edns- 764 client-subnet option. The resolver verifies that FAMILY, SOURCE 765 NETMASK, and ADDRESS match the request. If not, the option is 766 discarded. 768 10. The reply is interpreted as usual. Since the reply contains an 769 edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and 770 FAMILY in the response are used to cache the entry. 772 11. R sends a response to stub resolver SR, without including an 773 edns-client-subnet option. 775 12. R receives another request to resolve www.example.com. This 776 time, a reply is cached. The reply, however, is tied to a 777 particular network. If the address of the client matches any 778 network in the cache, then the reply is returned from the cache. 779 Otherwise, another query is performed. If multiple results 780 match, the one with the longest SCOPE NETMASK is chosen, as per 781 common best-network match algorithms. 783 12. Experiment details 785 This document describes an experiment to be conducted on the 786 Internet. Participation requires the careful eye on the proposed 787 EDNS0 option. What is described in this document may need to be 788 altered or adjusted as experience dictates. 790 During the experiment, participants will enable edns-client-subnet 791 support on their Nameservers (both Intermediate Nameservers and 792 Authoritative Nameservers). 794 Intermediate Nameservers will be configured with whitelists so edns- 795 client-subnet options will be sent only to Authoritative Nameservers 796 participating in the experiment. Some participants might also choose 797 to experiment with the probing behaviour described in Section 10.1. 799 Authoritative Nameservers could be configured with a whitelist but 800 maintainers are strongly encouraged to accept edns-client-subnet 801 options from anywhere to encourage openness. ns1-ns4.google.com are 802 configured as such and can be used to test client/resolver 803 implementations. 805 Pending official code point allocation (as described in Section 6), a 806 temporary EDNS0 option code will be in use. This code is not 807 guaranteed to be used in further stages of this effort - assuming the 808 are further stages. 810 The effects of edns-client-subnet will be measured using data of 24- 811 hour periods with and without the option enabled on a Recursive 812 Resolver. Metrics to be compared include: 814 o Cache hit rate on the Recursive Resolver. 816 o Average response time on the Recursive Resolver. 818 o Increase in query rate on both Recursive Resolvers and 819 Authoritative Nameservers. 821 o Most importantly, difference in load times as measured by user 822 agents (especially web browsers). 824 Success of the experiment will depend on the level of improvement in 825 the last mentioned metric. Others are for operational reasons (i.e. 826 does one need to provision for extra Nameservers?). 828 Possible side-effects from using edns-client-subnet will also be 829 investigated. These may include interoperability problems within the 830 DNS and decreased (or possibly increased) ease of troubleshooting. 832 13. Acknowledgements 834 The authors wish to thank Darryl Rodden for his work as a co-author 835 on previous versions, and the following people for reviewing early 836 drafts of this document and for providing useful feedback: Paul S. R. 837 Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 838 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 839 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 840 Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew 841 Dempsky from OpenDNS, Patrick W. Gilmore from Akamai, Colm 842 MacCarthaigh, Richard Sheehan and all the other people that replied 843 to our emails on various mailing lists. 845 Appendix A. Document Editing History 847 Appendix A.1. Changes since edns-client-subnet-00 849 o Document moved to experimental track, added experiment description 850 in header with details in a new section. 852 o Specifically note that edns-client-subnet applies to the answer 853 section only. 855 o Warn that caching based on edns-client-subnet is optional but very 856 important for performance reasons. 858 o Updated NAT section. 860 o Added recommendation to not use the default /24 recommendation for 861 the source netmask field if more detailed information about the 862 network is available. 864 Appendix A.2. Changes since edns-client-ip-01 866 o Document version number reset from -02 to -00 due to the rename to 867 edns-client-subnet. 869 o Clarified example (dealing with TLDs, and various minor errors). 871 o Referencing RFC5035 instead of RFC1918. 873 o Added a section on probing (and how it should be done) vs. 874 whitelisting. 876 o Moved description on how to forward edns-client-subnet option in 877 dedicated section. 879 o Queries with wrongly formatted edns-client-subnet options should 880 now be rejected with FORMERR. 882 o Added an "Overview" section, providing an introduction to the 883 document. 885 o Intermediate Nameservers can now remove an edns-client-subnet 886 option, or reduce the SOURCE NETMASK to increase privacy. 888 o Added a reference to DoS attacks in the Security section. 890 o Don't use "network range", as it seems to have different meaning 891 in other contexts, and turned out to be confusing. 893 o Use shorter and longer netmasks, rather than higher or lower. Add 894 a better explanation in the format section. 896 o Minor corrections in various other sections. 898 Appendix A.3. Changes since edns-client-ip-00 900 o Rewritten problem statement to be more clear about the goal of 901 edns-client-subnet and the fact that it's entirely optional. 903 o Wire format changed to include the original address and netmask in 904 responses in defence against birthday attacks. 906 o Security considerations now includes a section about birthday 907 attacks. 909 o Renamed edns-client-ip in edns-client-subnet, following 910 suggestions on the mailing list. 912 o Clarified behavior of resolvers when presented with an invalid 913 edns-client-subnet option. 915 o Fully take multi-tier DNS setups in mind and be more clear about 916 where the option should be originated. 918 o Added a few definitions in the Terminology section, and a few more 919 aesthetic changes in the rest of the document. 921 14. References 923 14.1. Normative References 925 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 926 STD 13, RFC 1034, November 1987. 928 [RFC1035] Mockapetris, P., "Domain names - implementation and 929 specification", STD 13, RFC 1035, November 1987. 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, March 1997. 934 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 935 RFC 2671, August 1999. 937 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 938 Rose, "DNS Security Introduction and Requirements", 939 RFC 4033, March 2005. 941 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 942 Rose, "Resource Records for the DNS Security Extensions", 943 RFC 4034, March 2005. 945 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 946 Rose, "Protocol Modifications for the DNS Security 947 Extensions", RFC 4035, March 2005. 949 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 950 Addresses", RFC 4193, October 2005. 952 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 953 BCP 153, RFC 5735, January 2010. 955 14.2. Informative References 957 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 958 Translator (NAT) Terminology and Considerations", 959 RFC 2663. 961 URIs 963 [1] 965 Authors' Addresses 967 Carlo Contavalli 968 Google 969 1600 Amphitheater Parkway 970 Mountain View, CA 94043 971 US 973 Email: ccontavalli@google.com 975 Wilmer van der Gaast 976 Google 977 Belgrave House, 76 Buckingham Palace Road 978 London SW1W 9TQ 979 UK 981 Email: wilmer@google.com 983 Sean Leach 984 VeriSign 985 21355 Ridgetop Circle 986 Dulles, VA 20166 987 US 989 Email: sleach@verisign.com 991 Edward Lewis 992 Neustar 993 46000 Center Oak Plaza 994 Sterling, VA 20166 995 US 997 Email: ed.lewis@neustar.biz