idnits 2.17.00 (12 Aug 2021) /tmp/idnits42388/draft-ietf-dnsop-edns-client-subnet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2014) is 2744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 263 -- Looks like a reference, but probably isn't: '1' on line 936 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop C. Contavalli 3 Internet-Draft W. van der Gaast 4 Intended status: Informational Google 5 Expires: May 19, 2015 D. Lawrence 6 Akamai Technologies 7 W. Kumari 8 Google 9 November 15, 2014 11 Client Subnet in DNS Requests 12 draft-ietf-dnsop-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 the 18 subsequent reply can be cached. 20 IESG Note 22 [RFC Editor: Please remove this note prior to publication ] 24 This informational document describes an existing, implemented and 25 deployed system. A subset of the operators using this is at 26 http://www.afasterinternet.com/participants.htm . The authors believe 27 that it is better to document this system (even if not everyone 28 agrees with the concept) than leave it undocumented and proprietary. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 19, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 71 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 8 72 6.3. Handling edns-client-subnet Replies and Caching . . . . . 9 73 6.4. Transitivity . . . . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 12 76 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 14 80 10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 14 81 11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 16 83 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 16 84 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19 86 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 87 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 15.2. Informative References . . . . . . . . . . . . . . . . . 20 90 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 Appendix A. Document History . . . . . . . . . . . . . . . . . . 20 92 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 A.4. -03* . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 network topology 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 handle query sources that are often not topologically close. The 116 motivation for a user to configure such a Centralized Resolver varies 117 but is usually because of some enhanced experience, such as greater 118 cache security or applying policies regarding where users may 119 connect. (Although political censorship usually comes to mind here, 120 the same actions may be used by a parent when setting controls on 121 where a minor may connect.) Similarly, many ISPs and other 122 organizations use a Centralized Resolver infrastructure that can be 123 distant from the clients the resolvers serve. The cases all lead to 124 less than optimal replies from topology-sensitive Authoritative 125 Nameservers. 127 This draft defines an EDNS0 [RFC6891] option to convey network 128 information that is relevant to the DNS message. It will carry 129 sufficient network information about the originator for the 130 Authoritative Nameserver to tailor responses. It will also provide 131 for the Authoritative Nameserver to indicate the scope of network 132 addresses for which the tailored answer is intended. This EDNS0 133 option is intended for those recursive and authority servers that 134 would benefit from the extension and not for general purpose 135 deployment. It is completely optional and can safely be ignored by 136 servers that choose not to implement it or enable it. 138 This draft also includes guidelines on how to best cache those 139 results and provides recommendations on when this protocol extension 140 should be used. 142 2. Requirements Notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. Terminology 150 Stub Resolver: A simple DNS protocol implementation on the client 151 side as described in [RFC1034] section 5.3.1. 153 Authoritative Nameserver: A nameserver that has authority over one 154 or more DNS zones. These are normally not contacted by clients 155 directly but by Recursive Resolvers. Described in [RFC1035] 156 chapter 6. 158 Recursive Resolver: A nameserver that is responsible for resolving 159 domain names for clients by following the domain's delegation 160 chain. Recursive Resolvers frequently use caches to be able to 161 respond to client queries quickly. Described in [RFC1035] chapter 162 7. 164 Intermediate Nameserver: Any nameserver (possibly a Recursive 165 Resolver) in between the Stub Resolver and the Authoritative 166 Nameserver. 168 Centralized Resolvers: Recursive Resolvers that serve a 169 topologically diverse network address space. 171 Optimized Reply: A reply from a nameserver that is optimized for the 172 node that sent the request, normally based on performance (i.e. 173 lowest latency, least number of hops, topological distance, ...). 175 Topologically Close: Refers to two hosts being close in terms of 176 number of hops or time it takes for a packet to travel from one 177 host to the other. The concept of topological distance is only 178 loosely related to the concept of geographical distance: two 179 geographically close hosts can still be very distant from a 180 topological perspective, and two geographically distant hosts can 181 be quite close on the network. 183 4. Overview 185 The general idea of this document is to provide an EDNS0 option to 186 allow Recursive Resolvers, if they are willing, to forward details 187 about the origin network from which a query is coming when talking to 188 Authoritative Nameservers. 190 The format of this option is described in Section 5, and is meant to 191 be added in queries sent by Intermediate Nameservers in a way 192 transparent to Stub Resolvers and end users, as described in 193 Section 6.1. 195 As described in Section 6.2, an Authoritative Nameserver could use 196 this EDNS0 option as a hint to better locate the network of the end 197 user and provide a better answer. 199 Its reply would also contain an edns-client-subnet option, clearly 200 indicating that the server made use of this information, and that the 201 answer is tied to the network of the client. 203 As described in Section 6.3, Intermediate Nameservers would use this 204 information to cache the reply. 206 Some Intermediate Nameservers may also have to be able to forward 207 edns-client-subnet queries they receive. This is described in 208 Section 6.4. 210 The mechanisms provided by edns-client-subnet raise various security 211 related concerns, related to cache growth, the ability to spoof EDNS0 212 options, and privacy. Section 10 explores various mitigation 213 techniques. 215 The expectation, however, is that this option will only be used by 216 Recursive Resolvers and Authoritative Nameservers that incur 217 geolocation issues. 219 Most Recursive Resolvers, Authoritative Nameservers and Stub 220 Resolvers will never know about this option, and will continue 221 working as they had been. 223 Failure to support this option or its improper handling will, at 224 worst, cause suboptimal identification of client location, which is a 225 common occurrence in current content delivery network (CDN) setups 226 and not a cause of concern. 228 Section 6.1 also provides a mechanism for Stub Resolvers to signal 229 Recursive Resolvers that they do not want edns-client-subnet 230 treatment for specific requests. 232 Additionally, operators of Intermediate Nameservers with edns-client- 233 subnet enabled are allowed to choose how many bits of the address of 234 received queries to forward, or to reduce the number of bits 235 forwarded for queries already including an edns-client-subnet option. 237 5. Option Format 239 This draft uses an EDNS0 [RFC6891]) option to include client address 240 information in DNS messages. The option is structured as follows: 242 +0 (MSB) +1 (LSB) 243 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 244 0: | OPTION-CODE | 245 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 246 2: | OPTION-LENGTH | 247 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 248 4: | FAMILY | 249 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 6: | SOURCE NETMASK | SCOPE NETMASK | 251 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 7: | ADDRESS... / 253 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 255 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for edns-client- 256 subnet is 8 (0x00 0x08). 258 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 259 length of the payload (everything after OPTION-LENGTH) in octets. 261 o FAMILY, 2 octets, indicates the family of the address contained in 262 the option, using address family codes as assigned by IANA in 263 IANA-AFI [2]. 265 The format of the address part depends on the value of FAMILY. This 266 document only defines the format for FAMILY 1 (IP version 4) and 2 267 (IP version 6), which are as follows: 269 o SOURCE NETMASK, unsigned octet representing the length of the 270 netmask pertaining to the query. In replies, it mirrors the same 271 value as in the requests. It can be set to 0 to disable client- 272 based lookups, in which case the ADDRESS field MUST be absent. 274 o SCOPE NETMASK, unsigned octet representing the length of the 275 netmask pertaining to the reply. In requests, it SHOULD be set to 276 the longest cacheable length supported by the Intermediate 277 Nameserver. For backwards compatibiilty with draft versions of 278 this specification, in requests it MAY be set to 0 to have the 279 Authoritative Nameserver treat the longest cacheable length as the 280 SOURCE NETMASK length. In responses, this field is set by the 281 Authoritative Nameserver to indicate the coverage of the response. 282 It might or might not match SOURCE NETMASK; it could be shorter or 283 longer. 285 o ADDRESS, variable number of octets, contains either an IPv4 or 286 IPv6 address, depending on FAMILY, truncated in the request to the 287 number of bits indicated by the SOURCE NETMASK field, with bits 288 set to 0 to pad up to the end of the last octet used. (This need 289 not be as many octets as a complete address would take.) In the 290 reply, if the SCOPE NETMASK of the request was 0 then ADDRESS must 291 contain the same octets as in the request. Otherwise, the bits 292 for ADDRESS will be significant through the maximum of the SOURCE 293 NETMASK or SCOPE NETMASK, and 0 filled to the end of an octet. 295 All fields are in network byte order ("big-endian", per [RFC1700], 296 Data Notation). 298 6. Protocol Description 300 6.1. Originating the Option 302 The edns-client-subnet option should generally be added by Recursive 303 Resolvers when querying other servers, as described in Section 11. 305 In this option, the server should include the IP address of the 306 client that caused the query to be generated, truncated to the number 307 of bits specified in the SOURCE NETMASK field. 309 A Stub Resolver MAY generate DNS queries with an edns-client-subnet 310 option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that 311 the Recursive Resolver MUST NOT add address information of the client 312 to its queries. The subsequent Recursive Resolver query to the 313 Authoritative Nameserver will then either not include an edns-client- 314 subnet option or MAY optionally include its own address information, 315 which is what the Authoritative Nameserver will use anyway to 316 generate the reply in lieu of no option. This allows the answer to 317 be handled by the same caching mechanism as other requests, with an 318 explicit indicator of the applicable scope. Subsequent Stub Resolver 319 requests for /0 can then be answered from this cached response. 321 The Stub Resolver may also add non-empty edns-client-subnet options 322 to its queries, but Recursive Resolvers are not required to use this 323 information. 325 For privacy reasons, and because the whole IP address is rarely 326 required to determine an optimized reply, the ADDRESS field in the 327 option SHOULD be truncated to a certain number of bits, chosen by the 328 administrators of the Intermediate Nameserver, as described in 329 Section 10. 331 If the Stub Resolver requests additional privacy via a SOURCE NETMASK 332 that is shorter than the maximum cacheable SCOPE NETMASK that the 333 Recursive Resolver allows, the Recursive Resolver SHOULD issue the 334 query with its longer SCOPE NETMASK. 336 6.2. Generating a Response 338 When a query containing an edns-client-subnet option is received, an 339 Authoritative Nameserver supporting edns-client-subnet MAY use the 340 address information specified in the option in order to generate an 341 optimized reply. 343 Authoritative Nameservers that have not implemented or enabled 344 support for the edns-client-subnet option may safely ignore it within 345 incoming queries. Per [RFC6891] section 6.1.2, such a server MUST 346 NOT include an edns-client-subnet option within replies, to indicate 347 lack of support for the option. 349 Requests with wrongly formatted options (e.g., wrong size) MUST be 350 rejected and a FORMERR response MUST be returned to the sender, as 351 described by [RFC6891], Transport Considerations. 353 If the Authoritative Nameserver decides to use information from the 354 edns-client-subnet option to calculate a response, it MUST include 355 the option in the response to indicate that the information was used 356 and SHOULD be cached accordingly. If the option was not included in 357 a query, it MUST NOT be included in the response. 359 The FAMILY and SOURCE NETMASK in the response MUST match those in the 360 request. The first SOURCE NETMASK bits of the ADDRESS in the 361 response MUST match those in the request, even if fewer bits were 362 used to form the response. Echoing back the address and netmask 363 helps to mitigate certain attack vectors, as described in Section 10. 365 The SCOPE NETMASK in the reply indicates the netmask of the network 366 for which the answer is intended. 368 A SCOPE NETMASK value longer than the SOURCE NETMASK indicates that 369 the address and netmask provided in the query was not specific enough 370 to select a single, best response. The ADDRESS MUST be extended to 371 SCOPE NETMASK significant bits to indicate the network for which it 372 is optimal, but the Recursive Resolver SHOULD still provide the 373 result as the answer to the triggering client request even if the 374 client is in a different address range. 376 Conversely, a shorter SCOPE NETMASK indicates that more bits than 377 necessary were provided, and the answer is suitable for a broader 378 range of addresses. 380 If a non-zero SCOPE NETMASK was supplied in the request, the SCOPE 381 NETMASK of the response MUST be no longer than the SCOPE NETMASK of 382 the request. 384 As not all netblocks are the same size, an Authoritative Nameserver 385 may return different values of SCOPE NETMASK for different networks. 387 In both cases, the value of the SCOPE NETMASK in the reply has strong 388 implications with regard to how the reply will be cached by 389 Intermediate Nameservers, as described in Section 6.3. 391 If the edns-client-subnet option in the request is not used at all, a 392 server supporting edns-client-subnet MUST indicate that no bits of 393 the ADDRESS in the request have been used by specifying a SCOPE 394 NETMASK of 0, equivalent to the networks 0.0.0.0/0 or ::/0. This 395 could happen, for example, because the reply is invariant across the 396 network space. The answer is suitable for all clients for the 397 duration of its TTL. 399 The specific logic that an Authoritative Nameserver uses to choose an 400 optimized reply is not in the scope of this document. Implementers 401 are encouraged, however, to consider carefully their selection of 402 SCOPE NETMASK for the reply in the event that an optimal reply cannot 403 be determined. 405 6.3. Handling edns-client-subnet Replies and Caching 407 When an Intermediate Nameserver receives a reply containing an edns- 408 client-subnet option, it will return a reply to its client and SHOULD 409 cache the result. 411 If the FAMILY, SOURCE NETMASK, and SOURCE NETMASK bits of ADDRESS in 412 the reply don't match the fields in the corresponding request, the 413 full reply MUST be dropped, as described in Section 10. 415 In the cache, any resource record in the answer section will be tied 416 to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK 417 fields, as detailed below. Note that the additional and authority 418 sections from a DNS response message are specifically excluded here. 419 Any information cached from these sections MUST NOT be tied to a 420 network. 422 If another query is received matching the name and type of an entry 423 in the cache, the resolver will check whether the FAMILY and ADDRESS 424 of the client matches one of the networks in the cache for that 425 entry. 427 If the address of the client is within any of the networks in the 428 cache, then the cached response MUST be returned as usual. If the 429 address of the client matches multiple networks in the cache, the 430 entry with the longest SCOPE NETMASK value MUST be returned, as with 431 most route-matching algorithms. 433 If the address of the client does not match any network in the cache, 434 then the Recursive Resolver MUST behave as if no match was found and 435 perform resolution as usual. This is necessary to avoid suboptimal 436 replies in the cache from being returned to the wrong clients, and to 437 avoid a single request coming from a client on a different network 438 from polluting the cache with a suboptimal reply for all the users of 439 that resolver. 441 Note that every time a Recursive Resolver queries an Authoritative 442 Nameserver by forwarding the edns-client-subnet option that it 443 received from another client, a short SOURCE NETMASK in the original 444 request could cause a suboptimal reply to be returned by the 445 Authoritative Nameserver. 447 When the request includes a longer SCOPE NETMASK, the reply returned 448 may still be cached as optimal for the ADDRESS and SCOPE NETMASK of 449 the reply. This might still be suboptimal for the original client. 451 To avoid this suboptimal reply from being served from cache for other 452 clients for which a better reply would be available, the Recursive 453 Resolver MUST check the SCOPE NETMASK that was returned by the 454 Authoritative Nameserver: 456 o If the SCOPE NETMASK in the reply is longer than the SOURCE 457 NETMASK, it means that the reply might be suboptimal. A Recursive 458 Resolver MUST return this entry from cache only to queries that do 459 not contain or allow a longer SOURCE NETMASK to be forwarded, or 460 to queries originating from the network covered by the ADDRESS and 461 SCOPE NETMASK.. 463 o If the SCOPE NETMASK in the reply is shorter than or equal to the 464 SOURCE NETMASK, the reply is optimal, and SHOULD be returned from 465 cache to any client within the network indicated by ADDRESS and 466 SCOPE NETMASK. 468 As another reply is received, the reply will be tied to a different 469 network. The server SHOULD keep in cache both replies, and return 470 the most appropriate one depending on the address of the client. Per 471 standard DNS caching behavior, all records SHOULD be retained until 472 their TTL expires. Subsequent queries to refresh the data should 473 always specify the longest SCOPE NETMASK that the Recursive Resolver 474 is willing to cache, even if previous responses indicated that a 475 shorter netmask was the optimal response. 477 Although omitting network-specific caching will significantly 478 simplify an implementation, the resulting drop in cache hits is very 479 likely to defeat most latency benefits provided by edns-client- 480 subnet. Therefore, when implementing this option for latency 481 purposes, implementing full caching support as described in this 482 section is STRONGLY RECOMMENDED. 484 Any reply containing an edns-client-subnet option considered invalid 485 should be treated as if no edns-client-subnet option was specified at 486 all. 488 Replies coming from servers not supporting edns-client-subnet or 489 otherwise not containing an edns-client-subnet option SHOULD be 490 considered as containing a SCOPE NETMASK of 0 (e.g., cache the result 491 for 0.0.0.0/0 or ::/0) for all the supported families. 493 In any case, the response from the resolver to the client MUST NOT 494 contain the edns-client-subnet option if none was present in the 495 client's original request. If the original client request contained 496 a valid edns-client-subnet option that was used during recursion, the 497 Recursive Resolver MUST include the edns-client-subnet option from 498 the Authoritative Nameserver response in the response to the client. 500 Enabling support for edns-client-subnet in a recursive resolver will 501 significantly increase the size of the cache, reduce the number of 502 results that can be served from cache, and increase the load on the 503 server. Implementing the mitigation techniques described in 504 Section 10 is strongly recommended. 506 6.4. Transitivity 508 Generally, edns-client-subnet options will only be present in DNS 509 messages between a Recursive Resolver and an Authoritative 510 Nameserver, i.e., one hop. In certain configurations however, for 511 example multi-tier nameserver setups, it may be necessary to 512 implement transitive behaviour on Intermediate Nameservers. 514 It is important that any Intermediate Nameserver that forwards edns- 515 client-subnet options received from their clients MUST fully 516 implement the caching behaviour described in Section 6.3. 518 Intermediate Nameservers, including Recursive Resolvers, supporting 519 edns-client-subnet MUST forward options with SOURCE NETMASK set to 0 520 (i.e., completely anonymized), such an option MUST NOT be replaced 521 with an option with more accurate address information. 523 An Intermediate Nameserver MAY also forward edns-client-subnet 524 options with actual address information. This information MAY match 525 the source IP address of the incoming query, and MAY have more or 526 less address bits than the Nameserver would normally include in a 527 locally originated edns-client-subnet option. 529 If for any reason the Intermediate Nameserver does not want to use 530 the information in an edns-client-subnet option it receives (too 531 little address information, network address from a range not 532 authorized to use the server, private/unroutable address space, etc), 533 it SHOULD drop the query and return a REFUSED response. Note again 534 that an edns-client-subnet option with 0 address bits MUST NOT be 535 refused. 537 7. IANA Considerations 539 IANA has already assigned option code 8 in the "DNS EDNS0 Option 540 Codes (OPT)" registry to edns-client-subnet. 542 The IANA is requested to update the reference ("draft-vandergaast- 543 edns-client-subnet") to refer to this RFC when published. 545 8. DNSSEC Considerations 547 The presence or absence of an [RFC6891] EDNS0 OPT resource record 548 containing an edns-client-subnet option in a DNS query does not 549 change the usage of the resource records and mechanisms used to 550 provide data origin authentication and data integrity to the DNS, as 551 described in [RFC4033], [RFC4034] and [RFC4035]. OPT records are not 552 signed. 554 9. NAT Considerations 556 Special awareness of edns-client-subnet in devices that perform 557 Network Address Translation (NAT) as described in [RFC2663] is not 558 required; queries can be passed through as-is. The client's network 559 address SHOULD NOT be added, and existing edns-client-subnet options, 560 if present, SHOULD NOT be modified by NAT devices. 562 In large-scale global networks behind NAT (but, for example, with a 563 Centralized Resolver infrastructure), an internal Intermediate 564 Nameserver might have detailed network layout information, and might 565 know which external subnets are used for egress traffic by each 566 internal network. In such cases, the Intermediate Nameserver MAY use 567 that information when originating edns-client-subnet options. 569 In other cases, Recursive Resolvers sited behind a NAT device SHOULD 570 NOT originate edns-client-subnet options with their IP address, and 571 instead rely on downstream Intermediate Nameservers doing so. They 572 MAY, however, choose to include the option with their internal 573 address for the purposes of signaling a shorter, more anonymous 574 SOURCE NETMASK. 576 If an Authoritative Nameserver on the publicly routed Internet 577 receives a request that specifies an ADDRESS in [RFC1918] or 578 [RFC4193] private address space, it SHOULD ignore ADDRESS and look up 579 its answer based on the address of the Recursive Resolver. In the 580 reply it SHOULD set SCOPE NETMASK to cover all of the relevant 581 private space. For example, a request for ADDRESS 10.1.2.0 with a 582 SOURCE NETMASK of 24 would get a returned SCOPE NETMASK of 8. The 583 Intermediate Nameserver MAY elect to cache the answer under one entry 584 for special-purpose addresses [RFC6890]; see Section 10.3. 586 10. Security Considerations 588 10.1. Privacy 590 With the edns-client-subnet option, the network address of the client 591 that initiated the resolution becomes visible to all servers involved 592 in the resolution process. Additionally, it will be visible from any 593 network traversed by the DNS packets. 595 To protect users' privacy, Recursive Resolvers are strongly 596 encouraged to conceal part of the IP address of the user by 597 truncating IPv4 addresses to 24 bits. No recommendation is provided 598 for IPv6 at this time, but IPv6 addresses should be similarly 599 truncated in order to not allow unique identification of the client. 601 When a non-zero SCOPE NETMASK is provided by the Recursive Resolver 602 that is longer than SOURCE NETMASK, users can often obtain more 603 optimal mapping if the resolver is well-used. Replies will have 604 answers optimized up to SCOPE NETMASK bits for a subset of the SOURCE 605 NETMASK. Subsequent requests within the TTL from clients within the 606 cached range will be served the optimal answer, while still 607 preserving privacy of the user. 609 ISPs will often have more detailed knowledge of their own networks. 610 That is, they will know if all 24-bit prefixes in a /20 are in the 611 same area. In those cases, for optimal cache utilization and 612 improved privacy, the ISP's Recursive Resolver SHOULD truncate IP 613 addresses in this /20 to just 20 bits, instead of 24 as recommended 614 above. 616 Users who wish their full IP address to be hidden can include an 617 edns-client-subnet option specifying the wildcard address 0.0.0.0/0 618 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). 620 As described in previous sections, this option will be forwarded 621 across all the Recursive Resolvers supporting edns-client-subnet, 622 which MUST NOT modify it to include the network address of the 623 client. 625 Note that even without an edns-client-subnet option, any server 626 queried directly by the user will be able to see the full client IP 627 address. Recursive Resolvers or Authoritative Nameservers MAY use 628 the source IP address of requests to return a cached entry or to 629 generate an optimized reply that best matches the request. 631 10.2. Birthday Attacks 633 edns-client-subnet adds information to the DNS question tuple 634 (q-tuple). This allows an attacker to send a caching Intermediate 635 Nameserver multiple queries with spoofed IP addresses either in the 636 edns-client-subnet option or as the source IP. These queries will 637 trigger multiple outgoing queries with the same name, type and class, 638 just different address information in the edns-client-subnet option. 640 With multiple queries for the same name in flight, the attacker has a 641 higher chance of success in sending a matching response (with the 642 address 0.0.0.0/0 to get it cached for many hosts). 644 To counter this, every edns-client-subnet option in a response packet 645 MUST contain the FAMILY and SOURCE NETMASK fields from the 646 corresponding request, along with identical ADDRESS bits for SOURCE 647 NETMASK length. Intermediate Nameservers processing a response MUST 648 verify that these match, and MUST discard the entire reply if they do 649 not. 651 10.3. Cache Pollution 653 It is simple for an arbitrary resolver or client to provide false 654 information in the edns-client-subnet option, or to send UDP packets 655 with forged source IP addresses. 657 This could be used to: 659 o pollute the cache of intermediate resolvers, by filling it with 660 results that will rarely (if ever) be used. 662 o reverse engineer the algorithms (or data) used by the 663 Authoritative Nameserver to calculate the optimized answer. 665 o mount a denial-of-service attack against an Intermediate 666 Nameserver, by forcing it to perform many more recursive queries 667 than it would normally do, due to how caching is handled for 668 queries containing the edns-client-subnet option. 670 Even without malicious intent, Centralized Resolvers providing 671 answers to clients in multiple networks will need to cache different 672 replies for different networks, putting more memory pressure on the 673 cache. 675 To mitigate those problems: 677 o Recursive Resolvers implementing edns-client-subnet should only 678 enable it in deployments where it is expected to bring clear 679 advantages to the end users. For example, when expecting clients 680 from a variety of networks or from a wide geographical area. Due 681 to the high cache pressure introduced by edns-client-subnet, the 682 feature SHOULD be disabled in all default configurations. 684 o Recursive Resolvers SHOULD limit the number of networks and 685 answers they keep in the cache for a given query. 687 o Recursive Resolvers SHOULD limit the number of total different 688 networks that they keep in cache. 690 o Recursive Resolvers should never send edns-client-subnet options 691 with a SCOPE NETMASK that is longer than they are willing to 692 cache. Similarly, if using the backwards-compatible SCOPE NETMASK 693 of 0, the request should not set a SOURCE NETMASK of more bits 694 than they are willing to cache. 696 o Recursive Resolvers should implement algorithms to improve the 697 cache hit rate, given the size constraints indicated above. 698 Recursive Resolvers MAY, for example, decide to discard more 699 specific cache entries first. 701 o Authoritative Nameservers and Recursive Resolvers should discard 702 edns-client-subnet options that are either obviously forged or 703 otherwise known to be wrong. They SHOULD at least treat 704 unroutable addresses, such as some of the address blocks defined 705 in [RFC6890], as equivalent to the Recursive Resolver's own 706 identity. They SHOULD ignore and never forward edns-client-subnet 707 options specifying other routable addresses that are known not to 708 be served by the query source. 710 o Authoritative Nameservers consider the edns-client-subnet option 711 just as a hint to provide better results. They can decide to 712 ignore the content of the edns-client-subnet option based on black 713 or white lists, rate limiting mechanisms, or any other logic 714 implemented in the software. 716 11. Sending the Option 718 When implementing a Recursive Resolver, there are two strategies on 719 deciding when to include an edns-client-subnet option in a query. At 720 this stage, it's not clear which strategy is best. 722 11.1. Probing 724 A Recursive Resolver can send the edns-client-subnet option with 725 every outgoing query. However, it is RECOMMENDED that Resolvers 726 remember which Authoritative Nameservers did not return the option 727 with their response, and omit client address information from 728 subsequent queries to those Nameservers. 730 Additionally, Recursive Resolvers MAY be configured to never send the 731 option when querying root, top-level, and effective top-level domain 732 servers. These domains are delegation-centric and are very unlikely 733 to generate different replies based on the address of the client. 735 When probing, it is important that several things are probed: support 736 for edns-client-subnet, support for EDNS0, support for EDNS0 options, 737 or possibly an unreachable Nameserver. Various implementations are 738 known to drop DNS packets with OPT RRs (with or without options), 739 thus several probes are required to discover what is supported. 741 Probing, if implemented, MUST be repeated periodically (i.e. daily). 742 If an Authoritative Nameserver indicates edns-client-subnet support 743 for one zone, it is to be expected that the Nameserver supports edns- 744 client-subnet for all its zones. Likewise, an Authoritative 745 Nameserver that uses edns-client-subnet information for one of its 746 zones, MUST indicate support for the option in all its responses. If 747 the option is supported but not actually used for generating a 748 response, its SCOPE NETMASK value SHOULD be set to 0. 750 11.2. Whitelist 752 As described previously, it is expected that only a few Recursive 753 Resolvers will need to use edns-client-subnet, and that it will 754 generally be enabled only if it offers a clear benefit to the users. 756 To avoid the complexity of implementing a probing and detection 757 mechanism (and the possible query loss/delay that may come with it), 758 an implementation could decide to use a statically configured 759 whitelist of Authoritative Namesevers to send the option to. 760 Implementations MAY also allow additionally configuring this based on 761 other criteria, such as zone or query type. 763 An additional advantage of using a whitelist is that partial client 764 address information is only disclosed to Nameservers that are known 765 to use the information, improving privacy. 767 A major drawback is scalability. The operator needs to track which 768 Authoritative Nameservers support edns-client-subnet, making it 769 harder for new Authoritative Nameservers to start using the option. 771 12. Example 773 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 774 www.example.com, by forwarding the query to the Recursive 775 Resolver R from IP address IP, asking for recursion. 777 2. RNS, supporting edns-client-subnet, looks up www.example.com in 778 its cache. An entry is found neither for www.example.com, nor 779 for example.com. 781 3. RNS builds a query to send to the root and .com servers. The 782 implementation of R provides facilities so an administrator can 783 configure RNS not to forward edns-client-subnet in certain 784 cases. In particular, RNS is configured to not include an edns- 785 client-subnet option when talking to delegation-centric 786 nameservers, as described in Section 6.1. Thus, no edns-client- 787 subnet option is added, and resolution is performed as usual. 789 4. RNS now knows the next server to query, Authoritative Nameserver 790 ANS, responsible for example.com. 792 5. RNS prepares a new query for www.example.com, including an edns- 793 client-subnet option with: 795 * OPTION-CODE, set to 0x00 0x08. 797 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 798 octets plus the 3 octets that will be used for ADDRESS. 800 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 802 * SOURCE NETMASK, set to 0x18, as RNS is configured to conceal 803 the last 8 bits of every IPv4 address. 805 * SCOPE NETMASK, set to 0x1B, as RNS is willing to cache 806 answers up to a /27. 808 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 809 bits of the IPv4 address. 811 6. The query is sent. Server ANS understands and uses edns-client- 812 subnet. It parses the edns-client-subnet option, and generates 813 an optimized reply. 815 7. Due to the internal implementation of ANS, it finds an answer 816 that is optimal for several /27 ranges within the ADDRESS/SOURCE 817 NETMASK of the request. It chooses one randomly. (Note well, 818 this is just one example of how ANS could pick a suitable 819 answer. Other selection methods are possible.) 821 8. The Authoritative Nameserver ANS adds an edns-client-subnet 822 option in the reply, containing: 824 * OPTION-CODE, set to 0x00 0x08. 826 * OPTION-LENGTH, set to 0x00 0x08 for the following fixed 4 827 octets plus the 4 octets that will be used for ADDRESS . 829 * FAMILY, set to 0x00 0x01, the same as the request. 831 * SOURCE NETMASK, set to 0x18, copied from the request. 833 * SCOPE NETMASK, set to 0x1B, indicating a /27 network. 835 * ADDRESS, set to 0xC0 0x00 0x02 0xE0, copied from the request. 837 9. RNS receives the reply containing an edns-client-subnet option. 838 The resolver verifies that FAMILY, SOURCE NETMASK, and the 839 SOURCE NETMASK bits of ADDRESS match the request. If not, the 840 message is discarded. 842 10. The reply is interpreted as usual. Since the reply contains an 843 edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and 844 FAMILY in the response are used to cache the entry. 846 11. RNS sends a response to stub resolver SR, without including an 847 edns-client-subnet option. 849 12. RNS receives another request to resolve www.example.com. This 850 time, a reply is cached. The reply, however, is tied to a 851 particular network. If the address of the client matches any 852 network in the cache, then the reply is returned from the cache. 853 Otherwise, another query is performed. If multiple results 854 match, the one with the longest SCOPE NETMASK is chosen, as per 855 common best-network match algorithms. 857 13. Contributing Authors 859 The below individuals contributed significantly to the draft. The 860 RFC Editor prefers a maximum of 5 names on the front page, and so we 861 have listed additional authors in this section 863 Edward Lewis 864 ICANN 865 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA 866 Email: edward.lewis@icann.org 868 Sean Leach 869 Fastly 870 POBox 78266 871 San Francisco, CA 94107 873 14. Acknowledgements 875 The authors wish to thank Darryl Rodden for his work as a co-author 876 on previous versions, and the following people for reviewing early 877 drafts of this document and for providing useful feedback: Paul S. 878 R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 879 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 880 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 881 Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew 882 Dempsky from OpenDNS, Patrick W. Gilmore and Jason Moreau from 883 Akamai, Colm MacCarthaigh, Richard Sheehan and all the other people 884 that replied to our emails on various mailing lists. 886 15. References 888 15.1. Normative References 890 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 891 STD 13, RFC 1034, November 1987. 893 [RFC1035] Mockapetris, P., "Domain names - implementation and 894 specification", STD 13, RFC 1035, November 1987. 896 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 897 October 1994. 899 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 900 E. Lear, "Address Allocation for Private Internets", BCP 901 5, RFC 1918, February 1996. 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 907 Rose, "DNS Security Introduction and Requirements", RFC 908 4033, March 2005. 910 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 911 Rose, "Resource Records for the DNS Security Extensions", 912 RFC 4034, March 2005. 914 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 915 Rose, "Protocol Modifications for the DNS Security 916 Extensions", RFC 4035, March 2005. 918 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 919 Addresses", RFC 4193, October 2005. 921 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 922 "Special-Purpose IP Address Registries", BCP 153, RFC 923 6890, April 2013. 925 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 926 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 928 15.2. Informative References 930 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 931 Translator (NAT) Terminology and Considerations", RFC 932 2663, August 1999. 934 15.3. URIs 936 [1] http://www.iana.org/assignments/address-family-numbers/ 938 Appendix A. Document History 940 [RFC Editor: Please delete this section before publication.] 942 A.1. -00 944 o Document moved to experimental track, added experiment description 945 in header with details in a new section. 947 o Specifically note that edns-client-subnet applies to the answer 948 section only. 950 o Warn that caching based on edns-client-subnet is optional but very 951 important for performance reasons. 953 o Updated NAT section. 955 o Added recommendation to not use the default /24 recommendation for 956 the source netmask field if more detailed information about the 957 network is available. 959 o Rewritten problem statement to be more clear about the goal of 960 edns-client-subnet and the fact that it's entirely optional. 962 o Wire format changed to include the original address and netmask in 963 responses in defence against birthday attacks. 965 o Security considerations now includes a section about birthday 966 attacks. 968 o Renamed edns-client-ip in edns-client-subnet, following 969 suggestions on the mailing list. 971 o Clarified behavior of resolvers when presented with an invalid 972 edns-client-subnet option. 974 o Fully take multi-tier DNS setups in mind and be more clear about 975 where the option should be originated. 977 o Added a few definitions in the Terminology section, and a few more 978 aesthetic changes in the rest of the document. 980 A.2. -01 982 o Document version number reset from -02 to -00 due to the rename to 983 edns-client-subnet. 985 o Clarified example (dealing with TLDs, and various minor errors). 987 o Referencing RFC5035 instead of RFC1918. 989 o Added a section on probing (and how it should be done) vs. 990 whitelisting. 992 o Moved description on how to forward edns-client-subnet option in 993 dedicated section. 995 o Queries with wrongly formatted edns-client-subnet options should 996 now be rejected with FORMERR. 998 o Added an "Overview" section, providing an introduction to the 999 document. 1001 o Intermediate Nameservers can now remove an edns-client-subnet 1002 option, or reduce the SOURCE NETMASK to increase privacy. 1004 o Added a reference to DoS attacks in the Security section. 1006 o Don't use "network range", as it seems to have different meaning 1007 in other contexts, and turned out to be confusing. 1009 o Use shorter and longer netmasks, rather than higher or lower. Add 1010 a better explanation in the format section. 1012 o Minor corrections in various other sections. 1014 A.3. -02 1016 o Added IANA-assigned option code. 1018 A.4. -03* 1020 o [*] There was no -03 version of the draft; these changes, however, 1021 were made after -02. 1023 o Allow non-zero SCOPE NETMASK for Recursive Resolvers to indicate 1024 their maximum cacheable mask length, and updated the example 1025 accordingly. 1027 o A note on Authoritative Nameservers receiving requests that 1028 specify private address space. 1030 o A note to always ask for the longest acceptable SCOPE NETMASK, 1031 even if a prior answer indicated that a shorter netmask was 1032 optimal. 1034 o Marked up a couple of references. 1036 o Minor grammatical consistency edits. 1038 Authors' Addresses 1040 Carlo Contavalli 1041 Google 1042 1600 Amphitheater Parkway 1043 Mountain View, CA 94043 1044 US 1046 Email: ccontavalli@google.com 1047 Wilmer van der Gaast 1048 Google 1049 Belgrave House, 76 Buckingham Palace Road 1050 London SW1W 9TQ 1051 UK 1053 Email: wilmer@google.com 1055 David C Lawrence 1056 Akamai Technologies 1057 8 Cambridge Center 1058 Cambridge, MA 02142 1059 US 1061 Email: tale@akamai.com 1063 Warren Kumari 1064 Google 1065 1600 Amphitheatre Parkway 1066 Mountain View, CA 94043 1067 US 1069 Email: warren@kumari.net