idnits 2.17.1 draft-vandergaast-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 (January 27, 2011) is 4837 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 (~~), 1 warning (==), 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: July 31, 2011 S. Leach 6 VeriSign 7 D. Rodden 8 Neustar 9 January 27, 2011 11 Client subnet in DNS requests 12 draft-vandergaast-edns-client-subnet-00 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 a 18 reply can be cached. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 31, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Option format . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Protocol description . . . . . . . . . . . . . . . . . . . . . 10 60 5.1. Originating the option . . . . . . . . . . . . . . . . . . 10 61 5.2. Generating a response . . . . . . . . . . . . . . . . . . 10 62 5.3. Handling edns-client-subnet replies and caching . . . . . 11 63 5.4. Transitivity . . . . . . . . . . . . . . . . . . . . . . . 13 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 16 66 8. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 17 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 9.2. Birthday attacks . . . . . . . . . . . . . . . . . . . . . 18 70 9.3. Cache pollution . . . . . . . . . . . . . . . . . . . . . 19 71 10. Sending the option . . . . . . . . . . . . . . . . . . . . . . 21 72 10.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 10.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . . 21 74 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 76 Appendix A. Document Editing History . . . . . . . . . . . . . . 26 77 Appendix A.1. Changes since edns-client-ip-01 . . . . . . . . . . 26 78 Appendix A.2. Changes since edns-client-ip-00 . . . . . . . . . . 26 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 81 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 84 1. Introduction 86 Many Authoritative nameservers today return different replies based 87 on the perceived topological location of the user. These servers use 88 the IP address of the incoming query to identify that location. 89 Since most queries come from intermediate recursive resolvers, the 90 source address is that of the recursive rather than of the query 91 originator. 93 Traditionally and probably still in the majority of instances, 94 recursive resolvers are reasonably close in the topological sense to 95 the stub resolvers or forwarders that are the source of queries. For 96 these resolvers, using their own IP address is sufficient for 97 authority servers that tailor responses based upon location of the 98 querier. 100 Increasingly though a class of remote recursive servers has arisen 101 that serves query sources without regard to topology. The motivation 102 for a query source to use a remote recursive server varies but is 103 usually because of some enhanced experience, such as greater cache 104 security or applying policies regarding where users may connect. 105 (Although political censorship usually comes to mind here, the same 106 actions may be used by a parent when setting controls on where a 107 minor may connect.) When using a remote recursive server, there can 108 no longer be any assumption of close proximity between the originator 109 and the recursive, leading to less than optimal replies from the 110 authority servers. 112 A similar situation exists within some ISPs where the recursive 113 servers are topologically distant from some edges of the ISP network, 114 resulting in less than optimal replies from the authority servers. 116 This draft defines an EDNS0 option to convey network information that 117 is relevant to the message but not otherwise included in the 118 datagram. This will provide the mechanism to carry sufficient 119 network information about the originator for the authority server to 120 tailor responses. It also provides for the authority server to 121 indicate the scope of network addresses that the tailored answer is 122 intended. This EDNS0 option is intended for those recursive and 123 authority servers that would benefit from the extension and not for 124 general purpose deployment. It is completely optional and can safely 125 be ignored by servers that choose not to implement it or enable it. 127 This draft also includes guidelines on how to best cache those 128 results and provides recommendations on when this protocol extension 129 should be used. 131 1.1. Requirements notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Terminology 139 Stub Resolver: A simple DNS protocol implementation on the client 140 side as described in [RFC1034] section 5.3.1. 142 Authoritative Nameserver: A nameserver that has authority over one 143 or more DNS zones. These are normally not contacted by clients 144 directly but by Recursive Resolvers. Described in [RFC1035] 145 chapter 6. 147 Recursive Resolver: A nameserver that is responsible for resolving 148 domain names for clients by following the domain's delegation 149 chain, starting at the root. Recursive Resolvers frequently use 150 caches to be able to respond to client queries quickly. Described 151 in [RFC1035] chapter 7. 153 Intermediate Nameserver: Any nameserver (possibly a Recursive 154 Resolver) in between the Stub Resolver and the Authoritative 155 Nameserver. 157 Third-party Nameserver: Recursive Resolvers provided by parties that 158 are not Internet Service Providers (ISPs). These services are 159 often offered as substitutes for ISP-run nameservers. 161 Optimized reply: A reply from a nameserver that is optimized for the 162 node that sent the request, normally based on performance (i.e. 163 lowest latency, least number of hops, topological distance, ...). 165 Topologically close: Refers to two hosts being close in terms of 166 number of hops or time it takes for a packet to travel from one 167 host to the other. The concept of topological distance is only 168 loosely related to the concept of geographical distance: two 169 geographically close hosts can still be very distant from a 170 topological perspective. 172 3. Overview 174 The general idea of this document is to provide an EDNS0 option so 175 that Recursive Resolvers can, if they are willing to, forward details 176 about the network a query is coming from when talking to other 177 Nameservers. 179 The format of this option is described in Section 4, and is meant to 180 be added in queries originated by Intermediate Nameservers in a way 181 transparent to Stub Resolvers and end users, as described in 182 Section 5.1. 184 As described in Section 5.2, an Authoritative Nameserver could use 185 this EDNS0 option as a hint to better locate the network of the end 186 user, and provide a better answer. 188 Its reply would contain an EDNS0 client-subnet option, clearly 189 indicating that (1) the server made use of this information and (2) 190 the answer is tied to the network of the client. 192 As described in Section 5.3, Intermediate Nameservers would use this 193 information to cache the reply. 195 Some Intermediate Nameservers may also have to be able to forward 196 edns-client-subnet queries they receive. This is described in 197 Section 5.4. 199 The mechanisms provided by edns-client-subnet raise various security 200 related concerns, related to cache growth, the ability to spoof EDNS0 201 options, and privacy. Section 9 explores various mitigation 202 techniques. 204 The expectation, however, is that this option will only be enabled 205 (and used) by Recursive Resolvers and Authoritative Nameserver that 206 incur in geolocation issues. 208 Most Recursive Resolvers, Authoritative Nameservers and Stub Resolver 209 will never know about this option, and keep working as usual. 211 Failure to support this option or its improper handling will at worst 212 cause sub-optimal geolocation, which is a pretty common occurrence in 213 current CDN setups and not a cause of concern. 215 Section 5.1 also provides a mechanism for Stub Resolvers to signal 216 Recursive Resolvers that they do not want an edns-client-subnet with 217 their network to be added. 219 Additionally, owners of resolvers with edns-client-subnet enabled are 220 allowed to choose how many bits of the address of received queries to 221 forward, or to reduce the number of bits forwarded for queries 222 already including an edns-client-subnet option. 224 4. Option format 226 This draft uses an EDNS0 ([RFC2671]) option to include client IP 227 information in DNS messages. The option is structured as follows: 229 +0 (MSB) +1 (LSB) 230 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 231 0: | OPTION-CODE | 232 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 233 2: | OPTION-LENGTH | 234 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 235 4: | FAMILY | 236 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 237 6: | SOURCE NETMASK | SCOPE NETMASK | 238 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 239 7: | ADDRESS... / 240 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 242 o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-client- 243 subnet is TBD. 245 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 246 length of the payload (everything after OPTION-LENGTH) in bytes. 248 o FAMILY, 2 octets, indicates the family of the address contained in 249 the option, using address family codes as assigned by IANA in 250 IANA-AFI [1]. 252 The format of the address part depends on the value of FAMILY. This 253 document only defines the format for FAMILY 1 (IP version 4) and 2 254 (IP version 6), which are as follows: 256 o SOURCE NETMASK, unsigned byte representing the length of the 257 netmask pertaining to the query. In replies, it mirrors the same 258 value as in the requests. 260 o SCOPE NETMASK, unsigned byte representing the length of the 261 netmask pertaining to the reply. In requests, it MUST be set to 262 0. In responses, this may or may not match SOURCE NETMASK. 264 o ADDRESS, variable number of octets, contains either an IPv4 or 265 IPv6 address (depending on FAMILY), truncated to the number of 266 bits indicated by the SOURCE NETMASK field, with bits set to 0 to 267 pad up to the end of the last octet used. 269 All fields are in network byte order. Throughout the document, we 270 will often refer to "longer" or "shorter" netmasks, corresponding to 271 netmasks that have a "higher" or "lower" value when represented as 272 integers. 274 5. Protocol description 276 5.1. Originating the option 278 The edns-client-subnet option should generally be added by Recursive 279 Resolvers when querying other servers, as described in Section 10. 281 In this option, the server should include the IP of the client that 282 caused the query to be generated, truncated to a number of bits 283 specified in the SOURCE NETMASK field. 285 The IP of the client can generally be determined by looking at the 286 source IP indicated in the IP header of the request. 288 A Stub Resolver MAY generate DNS queries with an edns-client-subnet 289 option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that 290 the Recursive Resolver MUST NOT add address information of the client 291 to its queries. The Stub Resolver may also add non-empty edns- 292 client-subnet options to its queries, but Recursive Resolvers are not 293 required to accept/use this information. 295 For privacy reasons, and because the whole IP address is rarely 296 required to determine an optimized reply, the ADDRESS field in the 297 option SHOULD be truncated to a certain number of bits, chosen by the 298 administrators of the server, as described in Section 9. 300 5.2. Generating a response 302 When a query containing an edns-client-subnet option is received, an 303 Authoritative Nameserver supporting edns-client-subnet MAY use the 304 address information specified in the option in order to generate an 305 optimized reply. 307 Authoritative servers that have not implemented or enabled support 308 for the edns-client-subnet may safely ignore the option within 309 incoming queries. Such a server MUST NOT include an edns-client- 310 subnet option within replies to indicate lack of support for the 311 option. 313 Requests with wrongly formatted options (i.e. wrong size) MUST be 314 rejected and a FORMERR response must be returned to the sender, as 315 described by [RFC2671], Transport Considerations. 317 If the Authoritative Nameserver decides to use information from the 318 edns-client-subnet option to calculate a response, it MUST include 319 the option in the response to indicate that the information was used 320 (and has to be cached accordingly). If the option was not included 321 in a query, it MUST NOT be included in the response. 323 The FAMILY, ADDRESS and SOURCE NETMASK in the response MUST match 324 those in the request. Echoing back the address and netmask helps to 325 mitigate certain attack vectors, as described in Section 9. 327 The SCOPE NETMASK in the reply indicates the netmask of the network 328 that the answer is intended for. 330 A SCOPE NETMASK value larger than the SOURCE NETMASK indicates that 331 the address and netmask provided in the query was not specific enough 332 to select a single, best response, and that an optimal reply would 333 require at least SCOPE NETMASK bits of address information. 335 Conversely, a shorter SCOPE NETMASK indicates that more bits than 336 necessary were provided. 338 As not all netblocks are the same size, an Authoritative Nameserver 339 may return different values of SCOPE NETMASK for different networks. 341 In both cases, the value of the SCOPE NETMASK in the reply has strong 342 implications with regard to how the reply will be cached by 343 Intermediate Nameservers, as described in Section 5.3. 345 If the edns-client-subnet option in the request is not used at all 346 (for example if an optimized reply was temporarily unavailable or not 347 supported for the requested domain name), a server supporting edns- 348 client-subnet MUST indicate that no bits of the ADDRESS in the 349 request have been used by specifying a SCOPE NETMASK of 0 (equivalent 350 to the networks 0.0.0.0/0 or ::/0). 352 If no optimized answer could be found at all for the FAMILY, ADDRESS 353 and SOURCE NETMASK indicated in the query, the Authoritative 354 Nameserver SHOULD still return the best result it knows of (i.e. by 355 using the query source IP address instead, or a sensible default), 356 and indicate that this result should only be cached for the FAMILY, 357 ADDRESS and SOURCE NETMASK indicated in the request. The server will 358 indicate this by copying the SOURCE NETMASK into the SCOPE NETMASK 359 field. 361 5.3. Handling edns-client-subnet replies and caching 363 When an Intermediate Nameserver receives a reply containing an edns- 364 client-subnet option, it will return a reply to its client and may 365 cache the result. 367 If the FAMILY, ADDRESS and SOURCE NETMASK fields in the reply don't 368 match the fields in the corresponding request, the full reply MUST be 369 dropped, as described in Section 9. 371 In the cache, any resource record in the answer section will be tied 372 to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK 373 fields, as detailed below. 375 If another query is received matching the entry in the cache, the 376 resolver will verify that the FAMILY and ADDRESS that represent the 377 client match any of the networks in the cache for that entry. 379 If the address of the client is within any of the networks in the 380 cache, then the cached response MUST be returned as usual. In case 381 the address of the client matches multiple networks in the cache, the 382 entry with the highest SCOPE NETMASK value MUST be returned, as with 383 most route-matching algorithms. 385 If the address of the client does not match any network in the cache, 386 then the Recursive Resolver MUST behave as if no match was found and 387 perform resolution as usual. This is necessary to avoid sub-optimal 388 replies in the cache from being returned to the wrong clients, and to 389 avoid a single request coming from a client on a different network 390 from polluting the cache with a sub-optimal reply for all the users 391 of that resolver. 393 Note that every time a Recursive Resolver queries an Authoritative 394 Nameserver by forwarding the edns-client-subnet option that it 395 received from another client, a low SOURCE NETMASK in the original 396 request could cause a sub-optimal reply to be returned by the 397 Authoritative Nameserver. 399 To avoid this sub-optimal reply from being served from cache for 400 clients for which a better reply would be available, the Recursive 401 Resolver MUST check the SCOPE NETMASK that was returned by the 402 Authoritative Nameserver: 404 o If the SCOPE NETMASK in the reply is longer than the SOURCE 405 NETMASK, it means that the reply might be sub-optimal. A 406 Recursive Resolver MUST return this entry from cache only to 407 queries that do not contain or allow a longer SOURCE NETMASK to be 408 forwarded. 410 o If the SCOPE NETMASK in the reply is shorter or equal to the 411 SOURCE NETMASK, the reply is optimal, and SHOULD be returned from 412 cache to any client within the network indicated by ADDRESS and 413 SCOPE NETMASK. 415 When another request is performed, the existing entries SHOULD be 416 kept in the cache until their TTL expires, as per standard behavior. 418 As another reply is received, the reply will be tied to a different 419 network. The server SHOULD keep in cache both replies, and return 420 the most appropriate one depending on the address of the client. 422 Any reply containing an edns-client-subnet option considered invalid 423 should be treated as if no edns-client-subnet option was specified at 424 all. 426 Replies coming from servers not supporting edns-client-subnet or 427 otherwise not containing an edns-client-subnet option SHOULD be 428 considered as containing a SCOPE NETMASK of 0 (e.g., cache the result 429 for 0.0.0.0/0 or ::/0) for all the supported families. 431 In any case, the response from the resolver to the client MUST NOT 432 contain the edns-client-subnet option if none was present in the 433 client's original request. If the original client request contained 434 a valid edns-client-subnet option that was used during recursion, the 435 Recursive Resolver MUST include the edns-client-subnet option from 436 the Authoritative Nameserver response in the response to the client. 438 Enabling support for edns-client-subnet in a recursive resolver will 439 significantly increase the size of the cache, reduce the number of 440 results that can be served from cache, and increase the load on the 441 server. Implementing the mitigation techniques described in 442 Section 9 is strongly recommended. 444 5.4. Transitivity 446 Generally, edns-client-subnet options will only be present in DNS 447 messages between a Recursive Resolver and an Authoritative 448 Nameserver, i.e. one hop. In certain configurations however (for 449 example multi-tier nameserver setups), it may be necessary to 450 implement transitive behaviour on Intermediate Nameservers. 452 It is important that any Intermediate Nameserver that implements 453 transitive behaviour (i.e. forward edns-client-subnet options 454 received from their clients) MUST fully implement the caching 455 behaviour described in Section 5.3. 457 Intermediate Nameservers (including Recursive Resolvers) supporting 458 edns-client-subnet MUST forward options with SOURCE NETMASK set to 0 459 (i.e. anonymized), such an option MUST NOT be replaced with an option 460 with more accurate address information. 462 An Intermediate Nameserver MAY also forward edns-client-subnet 463 options with actual address information. This information MAY match 464 the source IP address of the incoming query, and MAY have more or 465 less address bits than the Nameserver would normally include in a 466 locally originated edns-client-subnet option. 468 If for any reason the Intermediate Nameserver does not want to use 469 the information in an edns-client-subnet option it receives (too 470 little address information, network address from an IP range not 471 authorized to use the server, private/unroutable address space, ...) 472 it SHOULD drop the query and return a REFUSED response. Note again 473 that an edns-client-subnet option with 0 address bits MUST NOT be 474 refused. 476 6. IANA Considerations 478 We request IANA to assign an option code for edns-client-subnet, as 479 specified in [RFC2671]. Within this document, the text 'TBD' should 480 be replaced with the option code assigned by IANA. 482 7. DNSSEC Considerations 484 The presence or absence of an OPT resource record containing an edns- 485 client-subnet option in a DNS query does not change the usage of 486 those resource records and mechanisms used to provide data origin 487 authentication and data integrity to the DNS, as described in 488 [RFC4033], [RFC4034] and [RFC4035]. 490 8. NAT Considerations 492 Special awareness of edns-client-subnet in devices that perform NAT 493 as described in [RFC2663] is not required, queries can be passed 494 through as-is. The client's network address MUST NOT be added, and 495 existing edns-client-subnet options, if present, MUST NOT be modified 496 by NAT devices. 498 Recursive Resolvers sited behind NAT devices MUST NOT add their 499 external network address in an edns-client-subnet options, and MUST 500 behave exactly as described in the previous sections. 502 Note that Authoritative Nameservers or Recursive Resolvers can still 503 provide an optimized reply by looking at the source IP of the query. 505 9. Security Considerations 507 9.1. Privacy 509 With the edns-client-subnet option, the network address of the client 510 that initiated the resolution becomes visible to all servers involved 511 in the resolution process. Additionally, it will be visible from any 512 network traversed by the DNS packets. 514 To protect users' privacy, Recursive Resolvers are strongly 515 encouraged to conceal part of the IP address of the user by 516 truncating IPv4 addresses to 24 bits. No recommendation is provided 517 for IPv6 at this time, but IPv6 addresses should be similarly 518 truncated in order to not allow to uniquely identify the client. 520 Users who wish their full IP address to be hidden can include an 521 edns-client-subnet option specifying the wildcard address 0.0.0.0/0 522 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). 523 As described in previous sections, this option will be forwarded 524 across all the Recursive Resolvers supporting edns-client-subnet, 525 which MUST NOT modify it to include the network address of the 526 client. 528 Note that even without edns-client-subnet options, any server queried 529 directly by the user will be able to see the full client IP address. 530 Recursive Resolvers or Authoritative Nameservers MAY use the source 531 IP address of requests to return a cached entry or to generate an 532 optimized reply that best matches the request. 534 9.2. Birthday attacks 536 edns-client-subnet adds information to the q-tuple. This allows an 537 attacker to send a caching Intermediate Nameserver multiple queries 538 with spoofed IP addresses either in the edns-client-subnet option or 539 as the source IP. These queries will trigger multiple outgoing 540 queries with the same name, type and class, just different address 541 information in the edns-client-subnet option. 543 With multiple queries for the same name in flight, the attacker has a 544 higher chance of success in sending a matching response (with the 545 address 0.0.0.0/0 to still get it cached for many hosts). 547 To counter this, every edns-client-subnet option in a response packet 548 MUST contain the full FAMILY, ADDRESS and SOURCE NETMASK fields from 549 the corresponding request. Intermediate Nameservers processing a 550 response MUST verify that these match, and MUST discard the entire 551 reply if they do not. 553 9.3. Cache pollution 555 It is simple for an arbitrary resolver or client to provide false 556 information in the edns-client-subnet option, or to send UDP packets 557 with forged source IP addresses. 559 This could be used to: 561 o pollute the cache of intermediate resolvers, by filling it with 562 results that will rarely (if ever) be used. 564 o reverse engineer the algorithms (or data) used by the 565 Authoritative Nameserver to caclulate the optimized answer. 567 o mount a DoS attack against an intermediate resolver, by forcing it 568 to perform many more recursive queries than it would normally do, 569 due to how caching is handled for queries containing the edns- 570 client-subnet option. 572 Even without malicious intent, third-party Recursive Resolvers 573 providing answers to clients in multiple networks will need to cache 574 different replies for different networks, putting more pressure on 575 the cache. 577 To mitigate those problems: 579 o Recursive Resolvers implementing edns-client-subnet should only 580 enable it in deployments where it is expected to bring clear 581 advantages to the end users. For example, when expecting clients 582 from a variety of networks or from a wide geographical area. Due 583 to the high cache pressure introduced by edns-client-subnet, the 584 feature must be disabled in all default configurations. 586 o Recursive Resolvers should limit the number of networks and 587 answers they keep in the cache for a given query. 589 o Recursive Resolvers should limit the number of total different 590 networks that they keep in cache. 592 o Recursive Resolvers should never send edns-client-subnet options 593 with SOURCE NETMASKs providing more bits in the ADDRESS than they 594 are willing to cache responses for. 596 o Recursive Resolvers should implement algorithms to improve the 597 cache hit rate, given the size constraints indicated above. 598 Recursive Resolvers may, for example, decide to discard more 599 specific cache entries first. 601 o Authoritative Nameservers and Recursive Resolvers should discard 602 known to be wrong or known to be forged edns-client-subnet 603 options. They must at least ignore unroutable addresses, such as 604 some of the address blocks defined in [RFC5735] and [RFC4193], and 605 should ignore and never forward edns-client-subnet options 606 specifying networks or addresses that are known not to be served 607 by those servers when feasible. 609 o Authoritative Nameservers consider the edns-client-subnet option 610 just as a hint to provide better results. They can decide to 611 ignore the content of the edns-client-subnet option based on black 612 or white lists, rate limiting mechanisms, or any other logic 613 implemented in the software. 615 10. Sending the option 617 When implementing a Recursive Resolver, there are two strategies on 618 deciding when to include an edns-client-subnet option in a query. At 619 this stage it's not clear which strategy is best. 621 10.1. Probing 623 A Recursive Resolver can send the edns-client-subnet option with 624 every outgoing query. However, it is RECOMMENDED that Resolvers 625 remember which Authoritative Nameservers did not return the option 626 with their response, and omit client address information from 627 subsequent queries to those Nameservers. 629 Additionally, Recursive Resolvers MAY be configured to never send the 630 option when querying root and TLD servers, as these are unlikely to 631 generate different replies based on the IP of the client. 633 When probing, it is important that several things are probed: support 634 for edns-client-subnet, support for EDNS0, support for EDNS0 options, 635 or possibly an unreachable Nameserver. Various implementations are 636 known to drop DNS packets with OPT RRs (with or without options), 637 thus several probes are required to discover what is supported. 639 Probing, if implemented, MUST be repeated periodically (i.e. daily). 640 If an Authoritative Nameserver indicates edns-client-subnet support 641 for one zone, it is to be expected that the Nameserver supports edns- 642 client-subnet for all its zones. Likewise, an Authoritative 643 Nameserver that uses edns-client-subnet information for one of its 644 zones, MUST indicate support for the option in all its responses. If 645 the option is supported but not actually used for generating a 646 response, its SCOPE NETMASK value SHOULD be set to 0. 648 10.2. Whitelist 650 As described previously, it is expected that only a few Recursive 651 Resolvers will need to use edns-client-subnet, and that it will 652 generally be enabled only if it offers a clear benefit to the users. 654 To avoid the complexity of implementing a probing and detection 655 mechanism (and the possible query loss/delay that may come with it), 656 an implementation could decide to use a statically configured 657 whitelist of Authoritative Namesevers to send the option to. 658 Implementations MAY also allow additionally configuring this based on 659 other criteria (i.e. zone, qtype). 661 An additional advantage of using a whitelist is that partial client 662 address information is only disclosed to Nameservers that are known 663 to use the information, improving privacy. 665 A major drawback is scalability. The operator needs to track which 666 Nameservers support edns-client-subnet, making it harder for new 667 Authoritative Nameservers to start using the option. 669 11. Example 671 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 672 www.example.com, by forwarding the query to the Recursive 673 Resolver R from IP address IP, asking for recursion. 675 2. R, supporting edns-client-subnet, looks up www.example.com in 676 its cache. An entry is found neither for www.example.com, nor 677 for example.com. 679 3. R builds a query to send to the root and .com servers. The 680 implementation of R provides facilities so an administrator can 681 configure R not to forward edns-client-subnet in certain cases. 682 In particular, R is configured to not include an edns-client- 683 subnet option when talking to TLD or root nameservers, as 684 described in Section 5.1. Thus, no edns-client-subnet option is 685 added, and resolution is performed as usual. 687 4. R now knows the next server to query: Authoritative Nameserver 688 ANS, responsible for example.com. 690 5. R prepares a new query for www.example.com, including an edns- 691 client-subnet option with: 693 * OPTION-CODE, set to TBD. 695 * OPTION-LENGTH, set to 0x00 0x07. 697 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 699 * SOURCE NETMASK, set to 0x18, as R is configured to conceal 700 the last 8 bits of every IPv4 address. 702 * SCOPE NETMASK, set to 0x00, as specified by this document for 703 all requests. 705 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 706 bits of the IPv4 address. 708 6. The query is sent. Server ANS understands and uses edns-client- 709 subnet. It parses the edns-client-subnet option, and generates 710 an optimized reply. 712 7. Due to the internal implementation of the Authoritative 713 Nameserver ANS, ANS finds a reply that is optimal for the whole 714 /16 of the client that performed the request. 716 8. The Authoritative Nameserver ANS adds an edns-client-subnet 717 option in the reply, containing: 719 * OPTION-CODE, set to TBD. 721 * OPTION-LENGTH, set to 0x00 0x07. 723 * FAMILY, set to 0x00 0x01. 725 * SOURCE NETMASK, set to 0x18, copied from the request. 727 * SCOPE NETMASK, set to 0x10, indicating a /16 network. 729 * ADDRESS, set to 0xC0 0x00 0x02, copied from the request. 731 9. The Recursive Resolver R receives the reply containing an edns- 732 client-subnet option. The resolver verifies that FAMILY, SOURCE 733 NETMASK, and ADDRESS match the request. If not, the option is 734 discarded. 736 10. The reply is interpreted as usual. Since the reply contains an 737 edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and 738 FAMILY in the response are used to cache the entry. 740 11. R sends a response to stub resolver SR, without including an 741 edns-client-subnet option. 743 12. R receives another request to resolve www.example.com. This 744 time, a reply is cached. The reply, however, is tied to a 745 particular network. If the address of the client matches any 746 network in the cache, then the reply is returned from the cache. 747 Otherwise, another query is performed. If multiple results 748 match, the one with the longest SCOPE NETMASK is chosen, as per 749 common best-network match algorithms. 751 12. Acknowledgements 753 The authors wish to thank the following people for reviewing early 754 drafts of this document and for providing useful feedback: Paul S. R. 755 Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 756 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 757 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 758 Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew 759 Dempsky from OpenDNS, Patrick W. Gilmore from Akamai, Colm 760 MacCarthaigh, Richard Sheehan and all the other people that replied 761 to our emails on various mailing lists. 763 Appendix A. Document Editing History 765 Appendix A.1. Changes since edns-client-ip-01 767 o Document version number reset from -02 to -00 due to the rename to 768 edns-client-subnet. 770 o Clarified example (dealing with TLDs, and various minor errors). 772 o Referencing RFC5035 instead of RFC1918. 774 o Added a section on probing (and how it should be done) vs. 775 whitelisting. 777 o Moved description on how to forward edns-client-subnet option in 778 dedicated section. 780 o Queries with wrongly formatted edns-client-subnet options should 781 now be rejected with FORMERR. 783 o Added an "Overview" section, providing an introduction to the 784 document. 786 o Intermediate Nameservers can now remove an edns-client-subnet 787 option, or reduce the SOURCE NETMASK to increase privacy. 789 o Added a reference to DoS attacks in the Security section. 791 o Don't use "network range", as it seems to have different meaning 792 in other contexts, and turned out to be confusing. 794 o Use shorter and longer netmasks, rather than higher or lower. Add 795 a better explanation in the format section. 797 o Minor corrections in various other sections. 799 Appendix A.2. Changes since edns-client-ip-00 801 o Rewritten problem statement to be more clear about the goal of 802 edns-client-subnet and the fact that it's entirely optional. 804 o Wire format changed to include the original address and netmask in 805 responses in defence against birthday attacks. 807 o Security considerations now includes a section about birthday 808 attacks. 810 o Renamed edns-client-ip in edns-client-subnet, following 811 suggestions on the mailing list. 813 o Clarified behavior of resolvers when presented with an invalid 814 edns-client-subnet option. 816 o Fully take multi-tier DNS setups in mind and be more clear about 817 where the option should be originated. 819 o Added a few definitions in the Terminology section, and a few more 820 aesthetic changes in the rest of the document. 822 13. References 824 13.1. Normative References 826 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 827 STD 13, RFC 1034, November 1987. 829 [RFC1035] Mockapetris, P., "Domain names - implementation and 830 specification", STD 13, RFC 1035, November 1987. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 836 RFC 2671, August 1999. 838 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 839 Rose, "DNS Security Introduction and Requirements", 840 RFC 4033, March 2005. 842 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 843 Rose, "Resource Records for the DNS Security Extensions", 844 RFC 4034, March 2005. 846 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 847 Rose, "Protocol Modifications for the DNS Security 848 Extensions", RFC 4035, March 2005. 850 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 851 Addresses", RFC 4193, October 2005. 853 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 854 BCP 153, RFC 5735, January 2010. 856 13.2. Informative References 858 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 859 Translator (NAT) Terminology and Considerations", 860 RFC 2663. 862 URIs 864 [1] 866 Authors' Addresses 868 Carlo Contavalli 869 Google 870 1600 Amphitheater Parkway 871 Mountain View, CA 94043 872 US 874 Email: ccontavalli@google.com 876 Wilmer van der Gaast 877 Google 878 Gordon House, Barrow Street 879 Dublin 4 880 IE 882 Email: wilmer@google.com 884 Sean Leach 885 VeriSign 886 21355 Ridgetop Circle 887 Dulles, VA 20166 888 US 890 Email: sleach@verisign.com 892 Darryl Rodden 893 Neustar 894 46000 Center Oak Plaza 895 Sterling, VA 20166 896 US 898 Email: darryl.rodden@neustar.com