idnits 2.17.1 draft-vandergaast-edns-client-ip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (May 21, 2010) is 5081 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) 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: November 22, 2010 S. Leach 6 Name.com 7 D. Rodden 8 Neustar 9 May 21, 2010 11 Client IP information in DNS requests 12 draft-vandergaast-edns-client-ip-01 14 Abstract 16 This draft defines an EDNS0 extension to carry relevant network range 17 information. In a query, it conveys the network address of the 18 originator. In a response, it conveys the scope of network addresses 19 that the answer is intended. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on November 22, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Option format . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Protocol description . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Originating the option . . . . . . . . . . . . . . . . . . 7 67 4.2. Generating a response . . . . . . . . . . . . . . . . . . 8 68 4.3. Handling edns-client-subnet replies and caching . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 12 71 7. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 13 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.2. Birthday attacks . . . . . . . . . . . . . . . . . . . . . 14 75 8.3. Cache pollution . . . . . . . . . . . . . . . . . . . . . 15 76 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 78 Appendix A. Document Editing History . . . . . . . . . . . . . . 20 79 Appendix A.1. Changes since -00 . . . . . . . . . . . . . . . . . 20 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 Many Authoritative nameservers today return different replies based 88 on the perceived topological location of the user. These servers use 89 the IP address of the incoming query to identify that location. 90 Since most queries come from intermediate recursive resolvers, the 91 source address is that of the recursive rather than of the query 92 originator. 94 Traditionally and probably still in the majority of instances, 95 recursive resolvers are reasonably close in the topological sense to 96 the stub resolvers or forwarders that are the source of queries. For 97 these resolvers, using their own IP address is sufficient for 98 authority servers that tailor responses based upon location of the 99 querier. 101 Increasingly though a class of remote recursive servers has arisen 102 that serves query sources without regard to topology. The motivation 103 for a query source to use a remote recursive server varies but is 104 usually because of some enhanced experience, such as greater cache 105 security or applying policies regarding where users may connect. 106 (Although political censorship usually comes to mind here, the same 107 actions may be used by a parent when setting controls on where a 108 minor may connect.) When using a remote recursive server, there can 109 no longer be any assumption of close proximity between the originator 110 and the recursive, leading to less than optimal replies from the 111 authority servers. 113 A similar situation exists within some ISPs where the recursive 114 servers are topologically distant from some edges of the ISP network, 115 resulting in less than optimal replies from the authority servers. 117 This draft defines an EDNS0 option to convey network information that 118 is relevant to the message but not otherwise included in the 119 datagram. This will provide the mechanism to carry sufficient 120 network information about the originator for the authority server to 121 tailor responses. It also provides for the authority server to 122 indicate the scope of network addresses that the tailored answer is 123 intended. This EDNS0 option is intended for those recursive and 124 authority servers that would benefit from the extension and not for 125 general purpose deployment. It is completely optional and can safely 126 be ignored by servers that choose not to implement it or enable it. 128 This draft also includes guidelines on how to best cache those 129 results and provides recommendations on when this protocol extension 130 should be used. 132 1.1. Requirements notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Terminology 140 Stub Resolver: A simple DNS protocol implementation on the client 141 side as described in [RFC1034] section 5.3.1. 143 Authoritative Nameserver: A nameserver that has authority over one 144 or more DNS zones. These are normally not contacted by clients 145 directly but by Recursive Resolvers. Described in [RFC1035] 146 chapter 6. 148 Recursive Resolver: A nameserver that is responsible for resolving 149 domain names for clients by following the domain's delegation 150 chain, starting at the root. Recursive Resolvers frequently use 151 caches to be able to respond to client queries quickly. Described 152 in [RFC1035] chapter 7. 154 Intermediate Nameserver: Any nameserver (possibly a Recursive 155 Resolver) in between the Stub Resolver and the Authoritative 156 Nameserver. 158 Third-party Nameserver: Recursive Resolvers provided by parties that 159 are not Internet Service Providers (ISPs). These services are 160 often offered as substitutes for ISP-run nameservers. 162 Optimized reply: A reply from a nameserver that is optimized for the 163 node that sent the request, normally based on performance (i.e. 164 lowest latency, least number of hops, topological distance, ...). 166 Topologically close: Refers to two hosts being close in terms of 167 number of hops or time it takes for a packet to travel from one 168 host to the other. The concept of topological distance is only 169 loosely related to the concept of geographical distance: two 170 geographically close hosts can still be very distant from a 171 topological perspective. 173 3. Option format 175 This draft uses an EDNS0 ([RFC2671]) option to include client IP 176 information in DNS messages. The option is structured as follows: 178 +0 (MSB) +1 (LSB) 179 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 180 0: | OPTION-CODE | 181 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 182 2: | OPTION-LENGTH | 183 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 184 4: | FAMILY | 185 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 186 6: | SOURCE NETMASK | SCOPE NETMASK | 187 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 188 7: | ADDRESS... / 189 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 191 o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-client- 192 subnet is TBD. 194 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 195 length of the payload (everything after OPTION-LENGTH) in bytes. 197 o FAMILY, 2 octets, indicates the family of the address contained in 198 the option, using address family codes as assigned by IANA in 199 IANA-AFI [1]. 201 The format of the address part depends on the value of FAMILY. This 202 document only defines the format for FAMILY 1 (IP version 4) and 2 203 (IP version 6), which are as follows: 205 o SOURCE NETMASK, 1 octet, in requests, indicates how many most- 206 significant bits of the SOURCE ADDRESS are included (i.e. a 207 netmask in CIDR notation). In replies, it echoes back the value 208 from the query. 210 o SCOPE NETMASK, 1 octet, in requests, it MUST be set to 0. In 211 replies, it indicates for which supernets of ADDRESS the reply can 212 be cached, or which netmask would be necessary in requests to make 213 a better choice, see next few sections. 215 o ADDRESS, variable number of octets, contains either an IPv4 or 216 IPv6 address (depending on FAMILY), truncated to the number of 217 bits indicated by the SOURCE NETMASK field, with bits set to 0 to 218 pad up to the end of the last octet used. 220 All fields are in network byte order. 222 4. Protocol description 224 The edns-client-subnet extension allows DNS servers to propagate the 225 network address of the client that initiated the resolution through 226 to Authoritative Nameservers during recursion. 228 Servers that receive queries containing an edns-client-subnet option 229 can generate answers based on the original network address of the 230 client. Those answers will generally be optimized for that client 231 and other clients in the same network. 233 The option also allows Authoritative Nameservers to specify the 234 network range for which the reply can be cached and re-used. 236 4.1. Originating the option 238 The edns-client-subnet option can be added by Intermediate 239 Nameservers or Stub Resolvers. If an Intermediate Nameserver 240 receives a query from a routable (i.e. not private IP space as 241 described in [RFC1918]) IP address and it doesn't yet have the 242 option, it MAY add an edns-client-subnet option populated with the 243 source IP address of the query. 245 Alternatively, a Stub Resolver MAY generate DNS queries with an edns- 246 client-subnet option, for example if it has better knowledge of where 247 the connection following the DNS lookup is going to enter the public 248 network, or to request anonymization by including an edns-client- 249 subnet option with the address 0.0.0.0/0. 251 If an Intermediate Nameserver supporting edns-client-subnet receives 252 a query that already has a valid edns-client-subnet option, this 253 option MUST be passed through as-is and MUST NOT be modified. 255 For privacy reasons, and because the whole IP address is rarely 256 required to determine an optimized reply, the ADDRESS field in the 257 option SHOULD be truncated to a certain number of bits, chosen by the 258 administrators of the server, as described in Section 8. 260 Intermediate Nameservers that have not implemented or enabled support 261 for the edns-client-subnet can safely ignore the option within 262 incoming queries. Such a server MUST NOT include an edns-client- 263 subnet option within replies to indicate lack of support for the 264 option. 266 A Recursive Resolver MAY be configured to not include (or drop an 267 existing) edns-client-subnet option completely when querying 268 Authoritative Nameservers from which a delegation response is 269 expected, for example TLD servers or root servers. 271 4.2. Generating a response 273 When a query containing an edns-client-subnet option is received, an 274 Authoritative Nameserver supporting edns-client-subnet MAY use the 275 address information specified in the option in order to generate an 276 optimized reply. 278 Authoritative servers that have not implemented or enabled support 279 for the edns-client-subnet may safely ignore the option within 280 incoming queries. Such a server MUST NOT include an edns-client- 281 subnet option within replies to indicate lack of support for the 282 option. 284 Requests with an edns-client-subnet option considered invalid (i.e. 285 wrong formatting, unsupported address family, private address space) 286 MUST be treated as if no edns-client-subnet option was specified. 288 If the Authoritative Nameserver decides to use information from the 289 edns-client-subnet option to calculate a response, it MUST include 290 the option in the response to indicate that the information was used 291 (and has to be cached accordingly). If the option was not included 292 in a query, it MUST NOT be included in the response. 294 The FAMILY, ADDRESS and SOURCE NETMASK in the response MUST match 295 those in the request. Echoing back the address and netmask helps to 296 mitigate certain attack vectors, as described in Section 8. 298 The SCOPE NETMASK in the reply indicates the network range that the 299 answer is intended for. 301 A SCOPE NETMASK value larger than the SOURCE NETMASK indicates that 302 the address range provided in the query was not specific enough to 303 select a single, best response, and that an optimal reply would 304 require at least SCOPE NETMASK bits of address information. 306 Conversely, a lower SCOPE NETMASK indicates that more bits than 307 necessary were provided. 309 In both cases, the value of the SCOPE NETMASK in the reply has strong 310 implications with regard to how the reply will be cached by 311 Intermediate Nameservers, as described in Section 4.3. 313 If the edns-client-subnet option in the request is not used at all 314 (for example if an optimized reply was temporarily unavailable or not 315 supported for the requested domain name), a server supporting edns- 316 client-subnet MUST indicate that no bits of the ADDRESS in the 317 request have been used by specifying a SCOPE NETMASK of 0 (equivalent 318 to the networks 0.0.0.0/0 or ::/0). 320 If no optimized answer could be found at all for the ADDRESS and 321 SOURCE NETMASK indicated in the query, the Authoritative Nameserver 322 SHOULD still return the best result it knows of (i.e. by using the 323 query source IP address instead, or a sensible default), and indicate 324 that this result should only be cached for the FAMILY, ADDRESS and 325 SOURCE NETMASK indicated in the request. The server will indicate 326 this by copying the SOURCE NETMASK into the SCOPE NETMASK field. 328 4.3. Handling edns-client-subnet replies and caching 330 When an Intermediate Nameserver receives a reply containing an edns- 331 client-subnet option, it will return a reply to its client and may 332 cache the result. 334 If the FAMILY, ADDRESS and SOURCE NETMASK fields in the reply don't 335 match the fields in the corresponding request, the full reply MUST be 336 dropped, as described in Section 8. 338 In the cache, any resource record in the answer section will be tied 339 to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK 340 fields, as detailed below. 342 If another query is received matching the entry in the cache, the 343 resolver will verify that the FAMILY and ADDRESS that represent the 344 client match any of the networks in the cache for that entry. 346 If the address of the client is within any of the networks in the 347 cache, then the cached response MUST be returned as usual. In case 348 the address of the client matches multiple networks in the cache, the 349 entry with the highest SCOPE NETMASK value MUST be returned, as with 350 most route-matching algorithms. 352 If the address of the client does not match any network in the cache, 353 then the Recursive Resolver MUST behave as if no match was found and 354 perform resolution as usual. This is necessary to avoid sub-optimal 355 replies in the cache from being returned to the wrong clients, and to 356 avoid a single request coming from a client on a different network 357 from polluting the cache with a sub-optimal reply for all the users 358 of that resolver. 360 Note that every time a Recursive Resolver queries an Authoritative 361 Nameserver by forwarding the edns-client-subnet option that it 362 received from another client, a low SOURCE NETMASK in the original 363 request could cause a sub-optimal reply to be returned by the 364 Authoritative Nameserver. 366 To avoid this sub-optimal reply from being served from cache for 367 clients for which a better reply would be available, the Recursive 368 Resolver MUST check the SCOPE NETMASK that was returned by the 369 Authoritative Nameserver: 371 o If the SCOPE NETMASK in the reply is higher than the SOURCE 372 NETMASK, it means that the reply might be sub-optimal. A 373 Recursive Resolver MUST return this entry from cache only to 374 queries that do not contain or allow a higher SOURCE NETMASK to be 375 forwarded. 377 o If the SCOPE NETMASK in the reply is lower or equal to the SOURCE 378 NETMASK, the reply is optimal, and SHOULD be returned from cache 379 to any client within the network range indicated by ADDRESS and 380 SCOPE NETMASK. 382 When another request is performed, the existing entries SHOULD be 383 kept in the cache until their TTL expires, as per standard behavior. 385 As another reply is received, the reply will be tied to a different 386 network. The server MAY keep in cache both replies, and return the 387 most appropriate one depending on the address of the client. 389 Any reply containing an edns-client-subnet option considered invalid 390 should be treated as if no edns-client-subnet option was specified at 391 all. 393 Replies coming from servers not supporting edns-client-subnet or 394 otherwise not containing an edns-client-subnet option SHOULD be 395 considered as containing a SCOPE NETMASK of 0 (e.g., cache the result 396 for 0.0.0.0/0 or ::/0) for all the supported families. 398 In any case, the response from the resolver to the client MUST NOT 399 contain the edns-client-subnet option if none was present in the 400 client's original request. If the original client request contained 401 a valid edns-client-subnet option that was used during recursion, the 402 Recursive Resolver MUST include the edns-client-subnet option from 403 the Authoritative Nameserver response in the response to the client. 405 Enabling support for edns-client-subnet in a recursive resolver will 406 significantly increase the size of the cache, reduce the number of 407 results that can be served from cache, and increase the load on the 408 server. Implementing the mitigation techniques described in 409 Section 8 is strongly recommended. 411 5. IANA Considerations 413 We request IANA to assign an option code for edns-client-subnet, as 414 specified in [RFC2671]. Within this document, the text 'TBD' should 415 be replaced with the option code assigned by IANA. 417 6. DNSSEC Considerations 419 The presence or absence of an OPT resource record containing an edns- 420 client-subnet option in a DNS query does not change the usage of 421 those resource records and mechanisms used to provide data origin 422 authentication and data integrity to the DNS, as described in 423 [RFC4033], [RFC4034] and [RFC4035]. 425 7. NAT Considerations 427 Special awareness of edns-client-subnet in devices that perform NAT 428 as described in [RFC2663] is not required, queries can be passed 429 through as-is. The client's network address MUST NOT be added, and 430 existing edns-client-subnet options, if present, MUST NOT be modified 431 by NAT devices. 433 Recursive Resolvers sited behind NAT devices MUST NOT add their 434 external network address in an edns-client-subnet options, and MUST 435 behave exactly as described in the previous sections. 437 Note that Authoritative Nameservers or Recursive Resolvers can still 438 provide an optimized reply by looking at the source IP of the query. 440 8. Security Considerations 442 8.1. Privacy 444 With the edns-client-subnet option, the network address of the client 445 that initiated the resolution becomes visible to all servers involved 446 in the resolution process. Additionally, it will be visible from any 447 network traversed by the DNS packets. 449 To protect users' privacy, Recursive Resolvers are strongly 450 encouraged to conceal part of the IP address of the user by 451 truncating IPv4 addresses to 24 bits. No recommendation is provided 452 for IPv6 at this time, but IPv6 addresses should be similarly 453 truncated in order to not allow to uniquely identify the client. 455 Users who wish their full IP address to be hidden can include an 456 edns-client-subnet option specifying the wildcard address 0.0.0.0/0 457 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). 458 As described in previous sections, this option will be forwarded 459 across all the Recursive Resolvers supporting edns-client-subnet, 460 which MUST NOT modify it to include the network address of the 461 client. 463 Note that even without edns-client-subnet options, any server queried 464 directly by the user will be able to see the full client IP address. 465 Recursive Resolvers or Authoritative Nameservers MAY use the source 466 IP address of requests to return a cached entry or to generate an 467 optimized reply that best matches the request. 469 8.2. Birthday attacks 471 edns-client-subnet adds information to the q-tuple. This allows an 472 attacker to send a caching Intermediate Nameserver multiple queries 473 with spoofed IP addresses either in the edns-client-subnet option or 474 as the source IP. These queries will trigger multiple outgoing 475 queries with the same name, type and class, just different address 476 information in the edns-client-subnet option. 478 With multiple queries for the same name in flight, the attacker has a 479 higher chance of success in sending a matching response (with the 480 address 0.0.0.0/0 to still get it cached for many hosts). 482 To counter this, every edns-client-subnet option in a response packet 483 MUST contain the full FAMILY, ADDRESS and SOURCE NETMASK fields from 484 the corresponding request. Intermediate Nameservers processing a 485 response MUST verify that these match, and MUST discard the entire 486 reply if they do not. 488 8.3. Cache pollution 490 It is simple for an arbitrary resolver or client to provide false 491 information in the edns-client-subnet option, or to send UDP packets 492 with forged source IP addresses. 494 This could be used to pollute the cache of intermediate resolvers, by 495 filling it with results that will rarely (if ever) be used, or to 496 reverse engineer the algorithms (or data) used by the Authoritative 497 Nameserver to calculate the optimized answers. 499 Even without malicious intent, third-party Recursive Resolvers 500 providing answers to clients in multiple networks will need to cache 501 different replies for different networks, putting more pressure on 502 the cache. 504 To mitigate those problems: 506 o Recursive Resolvers implementing edns-client-subnet should only 507 enable it in deployments where it is expected to bring clear 508 advantages to the end users. For example, when expecting clients 509 from a variety of networks or from a wide geographical area. Due 510 to the high cache pressure introduced by edns-client-subnet, the 511 feature must be disabled in all default configurations. 513 o Recursive Resolvers should limit the number of networks and 514 answers they keep in the cache for a given query. 516 o Recursive Resolvers should limit the number of total different 517 networks that they keep in cache. 519 o Recursive Resolvers should never send edns-client-subnet options 520 with SOURCE NETMASKs providing more bits in the ADDRESS than they 521 are willing to cache responses for. 523 o Recursive Resolvers should implement algorithms to improve the 524 cache hit rate, given the size constraints indicated above. 525 Recursive Resolvers may, for example, decide to discard more 526 specific cache entries first. 528 o Authoritative Nameservers and Recursive Resolvers should discard 529 known to be wrong or known to be forged edns-client-subnet 530 options. They must at least ignore unroutable addresses, 531 including the ones defined in [RFC1918] and [RFC4193], and should 532 ignore and never forward edns-client-subnet options specifying 533 networks or addresses that are known not to be served by those 534 servers when feasible. 536 o Authoritative Nameservers consider the edns-client-subnet option 537 just as a hint to provide better results. They can decide to 538 ignore the content of the edns-client-subnet option based on black 539 or white lists, rate limiting mechanisms, or any other logic 540 implemented in the software. 542 9. Example 544 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 545 www.example.com, by forwarding the query to the Recursive 546 Resolver R from IP address IP, asking for recursion. 548 2. R, supporting edns-client-subnet, looks up www.example.com in 549 its cache. An entry is found neither for www.example.com, nor 550 for example.com. 552 3. R builds a query to send to the root and .com servers. The 553 implementation of R does not include an edns-client-subnet 554 option when querying TLD or root nameservers, because there is 555 no expectation to receive a client-network-specific response. 556 Thus, no edns-client-subnet option is added, and resolution is 557 performed as usual. 559 4. R now knows the Authoritative Nameserver ANS responsible for 560 example.com. 562 5. R prepares a new query for www.example.com, including an edns- 563 client-subnet option with: 565 * OPTION-CODE, set to TBD. 567 * OPTION-LENGTH, set to 0x00 0x07. 569 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 571 * SOURCE NETMASK, set to 0x18, as R is configured to conceal 572 the last 8 bits of every IPv4 address. 574 * SCOPE NETMASK, set to 0x00, as specified by this document for 575 all requests. 577 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 578 bits of the IPv4 address. 580 6. The query is sent. Authoritative Nameserver ANS understands and 581 uses edns-client-subnet. It parses the edns-client-subnet 582 option, and generates an optimized reply. 584 7. Due to the internal implementation of the Authoritative 585 Nameserver ANS, ANS finds a reply that is optimal for the whole 586 /16 of the client that performed the request. 588 8. The Authoritative Nameserver ANS adds an edns-client-subnet 589 option in the reply, containing: 591 * OPTION-CODE, set to TBD. 593 * OPTION-LENGTH, set to 0x00 0x07. 595 * FAMILY, set to 0x00 0x01. 597 * SOURCE NETMASK, set to 0x18, copied from the request. 599 * SCOPE NETMASK, set to 0x10, indicating a /16 network range. 601 * ADDRESS, set to 0xC0 0x00 0x02, copied from the request. 603 9. The Recursive Resolver R receives the reply containing an edns- 604 client-subnet option. The resolver verifies that FAMILY, SOURCE 605 NETMASK, and ADDRESS match the request. If not, the option is 606 discarded. 608 10. The reply is interpreted as usual. Since the reply contains an 609 edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and 610 FAMILY in the response are used to cache the entry. 612 11. R sends a response to stub resolver SR, without including an 613 edns-client-subnet option. 615 12. R receives another request to resolve www.example.com. This 616 time, a reply is cached. The reply, however, is tied to a 617 particular network. If the address of the client matches any 618 network in the cache, then the reply is returned from the cache. 619 Otherwise, another query is performed. If multiple results 620 match, the one with the longest SCOPE NETMASK is chosen, as per 621 common best-network match algorithms. 623 10. Acknowledgements 625 The authors wish to thank the following people for reviewing early 626 drafts of this document and for providing useful feedback: Paul S. R. 627 Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 628 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 629 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 630 Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew 631 Dempsky from OpenDNS, Patrick W. Gilmore from Akamai, Colm 632 MacCarthaigh, Richard Sheehan and all the other people that replied 633 to our emails on various mailing lists. 635 Appendix A. Document Editing History 637 Appendix A.1. Changes since -00 639 o Rewritten problem statement to be more clear about the goal of 640 edns-client-subnet and the fact that it's entirely optional. 642 o Wire format changed to include the original address and netmask in 643 responses in defence against birthday attacks. 645 o Security considerations now includes a section about birthday 646 attacks. 648 o Renamed edns-client-ip in edns-client-subnet, following 649 suggestions on the mailing list. 651 o Clarified behavior of resolvers when presented with an invalid 652 edns-client-subnet option. 654 o Fully take multi-tier DNS setups in mind and be more clear about 655 where the option should be originated. 657 o Added a few definitions in the Terminology section, and a few more 658 aesthetic changes in the rest of the document. 660 11. References 662 11.1. Normative References 664 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 665 STD 13, RFC 1034, November 1987. 667 [RFC1035] Mockapetris, P., "Domain names - implementation and 668 specification", STD 13, RFC 1035, November 1987. 670 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 671 E. Lear, "Address Allocation for Private Internets", 672 BCP 5, RFC 1918, February 1996. 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 678 RFC 2671, August 1999. 680 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 681 Rose, "DNS Security Introduction and Requirements", 682 RFC 4033, March 2005. 684 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 685 Rose, "Resource Records for the DNS Security Extensions", 686 RFC 4034, March 2005. 688 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 689 Rose, "Protocol Modifications for the DNS Security 690 Extensions", RFC 4035, March 2005. 692 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 693 Addresses", RFC 4193, October 2005. 695 11.2. Informative References 697 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 698 Translator (NAT) Terminology and Considerations", 699 RFC 2663. 701 URIs 703 [1] 705 Authors' Addresses 707 Carlo Contavalli 708 Google 709 Gordon House, Barrow Street 710 Dublin 4 711 IE 713 Email: ccontavalli@google.com 715 Wilmer van der Gaast 716 Google 717 Gordon House, Barrow Street 718 Dublin 4 719 IE 721 Email: wilmer@google.com 723 Sean Leach 724 Name.com 725 125 Rampart Way, Suite 300 726 Denver, CO 80230 727 CO 729 Email: sleach@name.com 731 Darryl Rodden 732 Neustar 733 46000 Center Oak Plaza 734 Sterling, VA 20166 735 VA 737 Email: darryl.rodden@neustar.com