idnits 2.17.1 draft-pan-dnsop-edns-isp-location-04.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 13 instances of too long lines in the document, the longest one being 49 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2018) is 2221 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'DYN-Traffic-Director-Geographic-Groups' is defined on line 1026, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop L. Pan 3 Internet-Draft 4 Intended status: Informational Y. Fu 5 Expires: September 28, 2018 CNNIC 6 March 27, 2018 8 ISP Location in DNS Queries 9 draft-pan-dnsop-edns-isp-location-04 11 Abstract 13 Nowadays, many Authoritative Nameservers support GeoIP feature, they 14 guess the user's geolocation by the client subnet of EDNS Client 15 Subnet (ECS) or by the source IP address of DNS query, return tailor 16 DNS response based on the user's geolocation. However, ECS raises 17 some privacy concerns because it leaks client subnet information on 18 the resolution path to the Authoritative Nameserver. 20 This document is inspired by EDNS Client Subnet (ECS), describes an 21 improved solution for GeoIP-enabled Authoritative Nameservers, 22 defines an EDNS ISP Location (EIL) extension to address the privacy 23 problem of ECS, tries to find the right balance between privacy 24 improvement and user experience optimization. 26 EIL is defined to convey isp location < COUNTRY, AREA, ISP > 27 information that is relevant to the DNS message. It will directly 28 provide the same sufficient information for the GeoIP-enabled 29 Authoritative Nameserver as ECS, to decide the response without 30 guessing geolocation of the IP address. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 28, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Path Calculation and Tailored DNS Response . . . . . . . 4 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Problem of ECS . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. Recursive Resolver . . . . . . . . . . . . . . . . . . . 6 73 4.3. GeoIP-enabled Authoritative Nameserver . . . . . . . . . 7 74 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . 7 76 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 77 6.1. Originating the Option . . . . . . . . . . . . . . . . . 9 78 6.1.1. P-Model: Public recursive resolver . . . . . . . . . 9 79 6.1.2. I-Model: ISP recursive resolver . . . . . . . . . . . 9 80 6.1.3. L-Model: local forwarding resolver . . . . . . . . . 10 81 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 10 82 6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 10 83 6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 10 84 6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 11 85 6.3. Handling EIL Responses and Caching . . . . . . . . . . . 11 86 6.3.1. Answering from Cache . . . . . . . . . . . . . . . . 11 87 6.3.2. Delegations and Negative Answers . . . . . . . . . . 12 88 6.4. Deploy . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 6.4.1. Transitivity . . . . . . . . . . . . . . . . . . . . 12 90 6.4.2. Compatibility with non-EDNS and ECS . . . . . . . . . 12 91 6.4.3. Support ECS and EIL at the same time . . . . . . . . 13 92 6.5. Why not use AS number to build EIL . . . . . . . . . . . 14 93 7. Benefit and Cost . . . . . . . . . . . . . . . . . . . . . . 15 94 7.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 7.2. Recursive Resolver . . . . . . . . . . . . . . . . . . . 15 96 7.3. GeoIP-enabled Authoritative Nameserver . . . . . . . . . 16 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 99 8.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 8.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 8.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 17 102 8.4. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 105 11. Appendix A. GeoIP-enabled Authoritative Nameservers Example . 17 106 11.1. BIND-GeoIP . . . . . . . . . . . . . . . . . . . . . . . 18 107 11.2. PowerDNS-GeoIP . . . . . . . . . . . . . . . . . . . . . 18 108 11.3. Amazon-Geolocation-Routing . . . . . . . . . . . . . . . 19 109 11.4. DYN-Traffic-Director-ECS . . . . . . . . . . . . . . . . 20 110 11.5. gdnsd-GeoIP . . . . . . . . . . . . . . . . . . . . . . 20 111 11.6. Windows-Server-GeoLocation . . . . . . . . . . . . . . . 20 112 12. Appendix B. EIL Example . . . . . . . . . . . . . . . . . . . 20 113 12.1. P-Model . . . . . . . . . . . . . . . . . . . . . . . . 20 114 12.2. I-Model . . . . . . . . . . . . . . . . . . . . . . . . 21 115 12.3. L-Model . . . . . . . . . . . . . . . . . . . . . . . . 21 116 13. Appendix C. Frequent GeoIP-enabled Authoritative Nameserver's 117 Response Accuracy Problem . . . . . . . . . . . . . . . . . . 21 118 13.1. Public Recursive Resolver with non-ECS Authoritative 119 Nameserver . . . . . . . . . . . . . . . . . . . . . . . 21 120 13.2. IP2Geo Database Quality . . . . . . . . . . . . . . . . 22 121 13.3. Unstable ISP Network Topology . . . . . . . . . . . . . 22 122 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 123 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 124 14.2. Informative References . . . . . . . . . . . . . . . . . 23 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 127 1. Introduction 129 Nowadays, many authoritative nameservers support GeoIP feature, such 130 as [BIND-GeoIP], [PowerDNS-GeoIP], [Amazon-Geolocation-Routing], 131 [DYN-Traffic-Director-ECS], [gdnsd-GeoIP], 132 [Windows-Server-GeoLocation] (More details are given in Appendix A). 133 These geographically aware authoritative nameservers guess the user's 134 geolocation by the client subnet of ECS or by the source IP address 135 of DNS query, return tailor DNS response based on the user's 136 geolocation. 138 ECS is an EDNS0 [RFC6891] option, described in [RFC7871], carries 139 client subnet information in DNS queries for authoritative 140 nameserver. Compared to source IP address of DNS query, ECS will 141 help authoritative nameserver to guess the client's location more 142 precisely because of the DNS forwarding query structure. 144 GeoIP-enabled authoritative nameservers use ECS for user geolocation 145 detecting. However, ECS raises some privacy concerns because it 146 leaks client subnet information on the resolution path to the 147 authoritative nameserver. 149 This document describes an improved solution for GeoIP-enabled 150 authoritative nameserver, defines an EDNS ISP Location (EIL) 151 extension to address the privacy problem of ECS, tries to find the 152 right balance between privacy improvement and user experience 153 optimization. 155 EIL is defined to convey isp location < COUNTRY, AREA, ISP > 156 information that is relevant to the DNS message. It will directly 157 provide the same sufficient information for the GeoIP-enabled 158 authoritative nameserver as ECS, to decide the response without 159 guessing geolocation of the IP address. 161 EIL is intended for those local forwarding resolvers, recursive 162 resolvers and authoritative nameservers that would benefit from the 163 extension and not for general purpose deployment. It could be 164 applied for tailor DNS response like ECS scenario. EIL can safely be 165 ignored by servers that choose not to implement or enable it. 167 1.1. Path Calculation and Tailored DNS Response 169 Separate the consideration of path calculation (data provider) and 170 tailored DNS response (authoritative nameserver). 172 Data providers make path calculations to optimize content delivery on 173 the Internet based on the network topology, considering many factors 174 such as IP, RIPs, FIBs, AS Path hops, system load, content 175 availability, path latency, etc. Note that, data providers have the 176 full details of the clients, they can make any complex path 177 calculations without ECS and EIL. 179 authoritative nameservers configure tailored DNS response based on 180 the result of path calculations, allocate IP addresses to different 181 datacenters, each IP address serves many client subnets. Usually, 182 users from the same < COUNTRY, AREA, ISP > isp location are allocated 183 to the same datacenter, the same best "network topologically close" 184 datacenter. For example, client IP addresses from < China, Beijing, 185 Telecom > are allocated to DataCenter-1, client IP addresses from < 186 China, Beijing, Unicom > are allocated to DataCenter-2, etc. Above 187 is the GeoIP-based Tailored DNS Response. 189 Therefore, if the GeoIP-enabled authoritative nameservers support 190 ECS, they can use the client subnet information of ECS instead of 191 resolver's address for geolocation detecting. Alternative, the 192 GeoIP-enabled authoritative nameservers can directly use the < 193 COUNTRY, AREA, ISP > information of EIL without geolocation 194 detecting. 196 Again, we emphasize that tailored DNS response does not affect path 197 calculation. Data Providers can make path calculations based on 198 network topology, decide network topological close datacenter for 199 each IP address. authoritative nameservers allocate tailored DNS 200 response to each IP address based on the "network topological close" 201 result of path calculations. EIL tell authoritative nameserver like 202 that, "I want to know what is best IP address for clients from < 203 China, Beijing, Telecom > at network topology path calculations 204 result", but not "I want to know what is the nearest IP address for 205 clients from < China, Beijing, Telecom > at physical topology path 206 calculations result". 208 EIL is satisfied if authoritative nameservers aggregate the IP 209 addresses from the same < COUNTRY, AREA, ISP > isp location to visit 210 the same datacenters, we call that GeoIP-based tailored DNS 211 responses, and these tailored responses have the best "network 212 topological close" distance to the users which are generated from 213 network topology path calculations result. 215 ECS is satisfied if authoritative nameservers make tailored DNS 216 response down to subnet precise level. For example, (subnet-1, ..., 217 subnet-100) are from the same < COUNTRY, AREA, ISP > isp location, 218 Data Provider applies (subnet-1, ..., subnet-50) visit DataCenter-1, 219 (subnet-51, ..., subnet-100) visit DataCenter-2. 221 2. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in 226 [RFC2119] when they appear in ALL CAPS. When these words are not in 227 ALL CAPS (such as "should" or "Should"), they have their usual 228 English meanings, and are not to be interpreted as [RFC2119] 229 keywords. 231 3. Terminology 233 Basic terms used in this specification are defined in the documents 234 [RFC1034], [RFC1035], [RFC7719] and [RFC7871]. 236 EIL: EDNS ISP Location. 238 ECS: EDNS Client Subnet, described in [RFC7871]. 240 Local Forwarding Resolver: forwarding resolver is described in 241 [RFC7871]. It is the first forwarding resolver which receives DNS 242 queries from stub resolver, usually deployed nearby the first-hop 243 router such as public Wi-Fi hotspot routers and home routers. 245 Recursive Resolver: described in [RFC7871]. It is the last-hop 246 before authoritative nameserver in the DNS query path. 248 Intermediate Nameserver: described in [RFC7871]. Any nameserver in 249 between the stub resolver and the authoritative nameserver, such as a 250 recursive resolver or a Forwarding Resolver. 252 Intermediate Forwarding Resolver: Any Forwarding Resolver in between 253 the local forwarding resolver and recursive resolver. 255 authoritative nameserver: described in [RFC7719] and [RFC2182]. It 256 is a server that knows the content of a DNS zone from local 257 knowledge, and thus can answer queries about that zone without 258 needing to query other servers. 260 4. Problem of ECS 262 As mentioned in [RFC7871]'s abstract section, since ECS has some 263 known operational and privacy shortcomings, a revision will be worked 264 through the IETF for improvement. 266 4.1. Client 268 Common users have little power to defense passive monitoring, 269 expecially in the plain-text traffic. 271 ECS's client subnet leakage has rise some user privacy concerns. 273 4.2. Recursive Resolver 275 Recursive Resolver must deal with ECS's cache problem, such as low 276 cache hitrate, rise response time, redundant cache size, etc. 278 Mukund Sivaraman described some scenarios in [CLIENT-SUBNET-BIS]. 280 ECS is precise because it is based on client subnet. But IPv6 281 addresses will boom, we can foresee it to increase more burden on 282 global recursive resolvers. 284 4.3. GeoIP-enabled Authoritative Nameserver 286 Resolver's IP can on behalf of many client subnets if they are 287 topological close. But this scenario has been varied by public 288 recursive resolver. ECS push client subnets to authoritative 289 nameserver, wants to solve the "public recursive resolver's IP is 290 topological far from client subnet" problem. 292 However, ECS rises GeoIP-enabled authoritative nameserver's 293 dependence on IP2Geo database quality. 295 Many GeoIP-enabled authoritative nameserver, most of the time, use < 296 COUNTRY, AREA, ISP > information to decide the tailored response. 297 Every GeoIP-enabled authoritative nameserver must operate IP2Geo 298 database carefully and catch up with topology change. The work is 299 inevitable, but ECS aggravate this, because the number of client 300 subnets is far greater than the number of recursive resolvers. 302 GeoIP-enabled authoritative nameserver needs a more precise IP2Geo 303 database, updates it more frequent than before, to catch up with the 304 huge client subnet network topology, but not the dns resolver's IP 305 network topology. Every GeoIP-enabled authoritative nameserver 306 should cost more on IP2Geo database. 308 5. Overview 310 EIL is an EDNS0 option to allow local forwarding resolvers and 311 recursive resolvers, if they are willing, to forward details about 312 the isp location of client when talking to other nameservers. EIL 313 can be added in queries sent by local forwarding resolvers or 314 recursive resolvers in a way that is transparent to Stub Resolvers 315 and end users. 317 Like ECS, authoritative nameservers could provide a better answer by 318 using precise isp location in EIL. Intermediate Nameservers could 319 send EIL query and cache the EIL response. This document also 320 provides a mechanism to signal Intermediate Nameservers that they do 321 not want EIL treatment for specific queries. 323 EIL is only defined for the Internet (IN) DNS class. 325 5.1. The EIL EDNS0 option 327 The EIL is an EDNS0 option to include the isp location of client in 328 DNS messages. 330 It is 16 octets which is structured as follows: 332 +0 (MSB) +1 (LSB) 333 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 334 0: | OPTION-CODE | 335 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 336 2: | OPTION-LENGTH | 337 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 338 4: | COUNTRY | 339 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 340 6: | AREA | 341 | | 342 | | 343 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 344 12: | ISP | 345 | | 346 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 348 Total: 16 octets. 350 o OPTION-CODE, 2 octets, defined in [RFC6891]. EDNS option code 351 should be assigned by the IANA. 353 o OPTION-LENGTH, 2 octets, defined in [RFC6891], contains the length 354 of the payload (everything after OPTION-LENGTH) in octets. 356 o COUNTRY, 2 octets, uppercase, defined in [ISO3166], indicates the 357 country information of the client's IP. For example, China's 358 COUNTRY is CN. 360 o AREA, 6 octets, uppercase, defined in [ISO3166] country 361 subdivision code, indicates the area information of the client's 362 IP. For example, The AREA of Fujian Province in China is 35. 364 o ISP, 4 octets, uppercase, indicates the ISP information of the 365 client's IP, using shortcut names. ISP shortcut names are unique 366 within the context of the COUNTRY. For example, the shortcut name 367 of China Telecommunications Corporation is TEL, the shortcut name 368 of China United Network Communications is UNI, the shortcut name 369 of China Mobile is MOB, etc. 371 All fields are in network byte order ("big-endian", per [RFC1700], 372 Data Notation). 374 The aim to use short names in the fields is to limit the data size of 375 EIL, decrease the DDoS risk. 377 The null value 0x20 signifies that the field is unknown. If all 378 fields in EIL are set to null value, it means that client doesn't 379 want to use EIL. 381 authoritative nameservers can send EIL response with the * value 0x2A 382 in AREA field or ISP field (not COUNTRY field), which signifies that 383 the field is wildcard match. For example, < CN, *, TEL > indicates 384 "all area in China, Telecom ISP". 386 Example code is at [DNS-TEST-EIL] . 388 6. Protocol Description 390 6.1. Originating the Option 392 The EIL can be initialized by Public recursive resolver, ISP 393 recursive resolver, or local forwarding resolver. 395 Examples are given in Appendix B. 397 6.1.1. P-Model: Public recursive resolver 399 Public recursive resolvers are not close to many users because the 400 service providers couldn't deploy servers in every country and every 401 ISP's network, which will affect the response accuracy of 402 authoritative nameservers. To encounter this problem, ECS shifts the 403 client subnet information to authoritative nameserver, but rises user 404 privacy concerns. 406 Therefore, to keep balance between precise and privacy, when a Public 407 recursive resolver receives a DNS query, it can guess isp location of 408 client's IP and generate the EIL OPT data, then send EIL query to the 409 authoritative nameserver. This will move the "guess location of 410 client's IP" work from authoritative nameserver back to Public 411 recursive resolver, lighten the burden of authoritative nameserver, 412 but increase DDoS risk on Public recursive resolver. 414 In order to improve the user's privacy, if a recursive resolver 415 receives a DNS query with ECS, it can guess the isp location of 416 SOURCE-PREFIX from the ECS OPT data, and make a new DNS query with 417 EIL, then send the query to authoritative nameserver which supports 418 EIL. 420 P-model is the most recommended and close to the ECS. 422 6.1.2. I-Model: ISP recursive resolver 424 ISP recursive resolver only serves its customers, each of whom has a 425 static isp location. ISP recursive resolver can add EIL transparent 426 to end user, and then authoritative nameserver doesn't need to "guess 427 location of client's IP". 429 EIL will be benefit if the authoritative nameserver could not find 430 the approximate isp location of ISP recursive resolver, which is 431 crucial to DNS response accuracy in ECS. 433 6.1.3. L-Model: local forwarding resolver 435 local forwarding resolver is usually on the first-hop router, such as 436 public Wi-Fi hotspot routers and Cisco/Linksys/Netgear/TP-LINK home 437 routers. 439 When a local forwarding resolver that implements EIL receives a DNS 440 query from an end user, it surely can know about the isp location of 441 client's IP, and generate the EIL OPT data, then send the EIL query 442 to the intermediate recursive resolver. Intermediate recursive 443 resolver sends the EIL query to the authoritative nameserver. 445 In this scenario, both Public recursive resolver and authoritative 446 nameserver don't need to "guess location of client's IP", because the 447 local forwarding resolver supplies the isp location precisely. That 448 is, EIL can reduce dependence on the IP geolocation database quality, 449 which is crucial to DNS response accuracy in ECS. 451 If a local forwarding resolver had sent a query with EIL, and 452 receives a REFUSE response, it MUST regenerate a query with no EIL. 454 6.2. Generating a Response 456 6.2.1. Whitelist 458 EIL contains a whitelist for COUNTRY, AREA and ISP, which can be 459 discussed and maintained by the DNSOP working group. authoritative 460 nameservers that supporting EIL must only response the EIL queries 461 matched the whitelist. recursive resolver that supporting EIL must 462 only cache the EIL responses matched the whitelist. 464 6.2.2. Authoritative Nameserver 466 Using the isp location specified in the EIL option of DNS query, an 467 authoritative nameserver can generate a tailored response. 469 authoritative nameservers that have not implemented or enabled 470 support for the EIL ought to safely ignore it within incoming 471 queries, response the query as a normal case without EDNS0 option. 472 Such a server MUST NOT include an EIL option within replies to 473 indicate lack of support for it. 475 An authoritative nameserver that has implemented this protocol and 476 receives an EIL option MUST include an EIL option in its response to 477 indicate that it SHOULD be cached accordingly. 479 An authoritative nameserver will return a more appropriate tailored 480 response for the query with an EIL option containing more precisely 481 AREA. 483 6.2.3. Intermediate Nameserver 485 Like ECS, Intermediate Nameserver passes a DNS response with an EIL 486 option to its client when the client indicates support EIL. 488 If an Intermediate Nameserver receives a response that has a larger 489 area than the AREA provided in its query, it SHOULD still provide the 490 result as the answer to the triggering client request even if the 491 client is in a smaller area. 493 6.3. Handling EIL Responses and Caching 495 If an Intermediate Nameserver had sent a query with EIL, and receives 496 a NOERROR response without EIL option, it SHOULD treat this answer as 497 suitable for all clients. 499 Other handling considerations are similar with ECS [RFC7871], SECTION 500 7.3. 502 In the cache, all resource records in the Answer section MUST be tied 503 to the isp location specified in the response. The Answer section is 504 valid for all areas which the EIL option covered. For example, an 505 EIL option < CN, 35, TEL > covers all 9 Cities in Fujian Province of 506 China Telecommunications ISP. 508 Same with ECS, The Additional and Authority sections are excluded. 510 Enabling support for EIL in an Intermediate Nameserver will increase 511 the size of the cache, and prevent "client subnet leak" privacy 512 concern of ECS. 514 6.3.1. Answering from Cache 516 Cache lookups are first done as usual for a DNS query, using the 517 query tuple of < name, type, class >. Then, the appropriate RRset 518 MUST be chosen based on the isp location matching. 520 If there was an EIL option, the Intermediate Nameserver will lookup 521 for < same COUNTRY, same ISP, same AREA > of the same query tuple in 522 the cache. Otherwise, try to find < same COUNTRY, same ISP, same 523 AREA > of the same query tuple in the cache. 525 If no EIL option was provided, the safest choice of the Intermediate 526 Nameserver is dealing the query as a normal case without EDNS0 527 option. 529 If no EIL option was provided, but the Intermediate Nameserver want 530 to be more aggressive, it can guess the isp location from the source 531 IP of the query, then respond as if there was an EIL option with the 532 guessed information. Users can be benefit when the Intermediate 533 Nameserver has a more precise IP location database than the 534 authoritative nameserver, especially in global public DNS service 535 like GoogleDNS(8.8.8.8). 537 If no matching is found, the Intermediate Nameserver MUST perform 538 resolution as usual. 540 6.3.2. Delegations and Negative Answers 542 EIL's delegation case is similar with ECS, Additional and Authority 543 Sections SHOULD ignore EIL. 545 For negative answers, authoritative nameservers return traditional 546 negative answers without EIL. 548 6.4. Deploy 550 6.4.1. Transitivity 552 EIL's transitivity concerns are similar with ECS. 554 Name servers should only enable EIL where it is expected to benefit 555 the end users, such as dealing with some latency-sensitive CDN domain 556 queries in a complex network environment. 558 6.4.2. Compatibility with non-EDNS and ECS 560 For realworld compatibility, EIL is designed as an additional feature 561 to ECS. If a nameserver supports EIL, it must support ECS first. So 562 there are three scenarios: non-EDNS, ECS but non-EIL, ECS and EIL. 564 o GeoIP-enabled authoritative nameservers map ECS's client subnet 565 into EIL's geolocation to get tailor response, they can simply add 566 EIL support. Some realtime client subnet sensitive CDN domains, 567 such as Akamai, they may not support GeoIP feature and EIL. 569 o EIL-enabled recursive resolvers only send EIL queries to EIL- 570 enabled authoritative nameservers. At the same time, they can 571 also send ECS queries. 573 The indicator that authoritative nameservers used to generate tailor 574 response is showed as follows: 576 +-------------------------+-----------------+------------------------+----------------------------------------------+ 577 | | AUTH (non-EDNS) | AUTH (ECS but non-EIL) | AUTH (ECS and EIL) | 578 +-------------------------+-----------------+------------------------+----------------------------------------------+ 579 | RECUR (non-EDNS) | Resolver's IP | Resolver's IP | Resolver's IP | 580 +-------------------------+-----------------+------------------------+----------------------------------------------+ 581 | RECUR (ECS but non-EIL) | Resolver's IP | Client Subnet | Client Subnet | 582 +-------------------------+-----------------+------------------------+----------------------------------------------+ 583 | RECUR (ECS and EIL) | Resolver's IP | Client Subnet | Client Subnet or EIL's < COUNTRY, AREA, ISP >| 584 +-------------------------+-----------------+------------------------+----------------------------------------------+ 586 6.4.3. Support ECS and EIL at the same time 588 Name servers can support ECS and EIL at the same time. ECS and EIL 589 can't be both initiated at the same DNS packet. It is better for 590 user privacy if name servers initiate the EIL query prior to the ECS 591 query. 593 If authoritative nameservers support both ECS and EIL, recursive 594 resolvers can cache both ECS response and EIL response, there are 595 some choices for recursive resolvers when they receive DNS queries. 597 Receive EIL query: 598 Search in EIL cache. 599 If cache is matched, return EIL response. 600 Otherwise, send EIL query to authoritative nameserver. 602 Receive ECS query: 603 Search in ECS cache. 604 If cache is matched, return ECS response. 605 Otherwise, send ECS query to authoritative nameserver. 607 Receive DNS query without EDNS option: 608 Search in ECS cache. 609 If cache is matched, return ECS response. 610 Otherwise, 611 Guess the isp location information of the client's IP, 612 build EIL option for the query packet. 613 Search in EIL cache. 614 If cache is matched, return EIL response. 615 Otherwise, send EIL query to authoritative nameserver. 617 Receive DNS query with not-ECS/not-EIL option: 618 Search in not-EDNS cache. 619 If cache is matched, return response. 620 Otherwise, send the DNS query to authoritative nameserver. 622 Receive ECS query, improve user privacy: 623 Guess the isp location information of the client's IP, 624 build EIL option for the query packet. 625 Search in EIL cache. 626 If cache is matched, return EIL response RR with origin ECS option. 627 Otherwise, send EIL query to authoritative nameserver. 629 6.5. Why not use AS number to build EIL 631 AS number is not an ideal object to balance between response accuracy 632 and user privacy, for example: 634 o AS24151 can directly guide to China Internet Network Infomation 635 Center, it is not good for user privacy. 637 o AS4134 contains a huge amount of IP prefixes whose geolocation 638 covers from South China to North China, AS number can not afford 639 the response accuracy consideration. 641 o < COUNTRY-CODE, AREA-CODE, AS-NUMBER > may be a considerable 642 trade-off choice on public recursive resolver, but inconvenience 643 on local forwarding resolver. 645 7. Benefit and Cost 647 7.1. Client 649 EIL is transparent to client. 651 EIL is to help mitigate client subnet leakage on the resolution path, 652 without sensitive identity information. 654 7.2. Recursive Resolver 656 ECS sends the query with client subnet, which means that recursive 657 resolvers have to send a new query to authoritative nameservers with 658 client_subnet_b, even it has known the response about topological 659 close client_subnet_a. In fact, thousands of subnets visit only a 660 few servers, there are many redundacy queries, the recursive's cache 661 hitrate is low. 663 Because of ECS's low cache hitrate, recursive servers's ECS tailored 664 response latency will be longer, the average of response time will 665 rise with the redundacy queries rate from recursive resolvers to 666 authoritative nameservers. 668 Recursive's ECS cache size grows up with the number of client 669 subnets. 671 To sum it up, above problems all rise with the client subnet amount, 672 especially when IPv6 addresses boom. Extend the subnet range in the 673 ECS response may be mitigating, but not work for wide range client 674 subnets. Recursive can make some guess optimization, if it has known 675 response for client_subnet_a, then guess to return the same response 676 for toplogical close client_subnet_b without send the redundancy 677 query. 679 Therefore, if the ECS revision wants to make more effective client 680 subnets aggregation for recursive resolver, then EIL can be an 681 considerable choice. EIL wants to summary toplogical close client 682 subnets into < COUNTRY, AREA, ISP > for GeoIP-enabled authoritative 683 nameserver. With EIL response cache, recursive resolvers can 684 directly response for many ECS client subnets queries, which will 685 rise cache hitrate and reduce response latency. The cache size of 686 EIL is related to the row count in the < COUNTRY, AREA, ISP > isp 687 location whitelist. Therefore, under IPv6 environment, the cache 688 size of EIL will be much smaller than ECS. 690 Note that, the EIL's IP2Geo mapping work will make recursive resolver 691 to cost more cpu. 693 7.3. GeoIP-enabled Authoritative Nameserver 695 Client subnet is the best factor if the company has good network 696 topology monitor ability, offen is for big company. However, for 697 many authoritative servers that only deployed GeoDNS, the accuracy 698 limitation is commonly because of the IP2Geo database quality, and 699 the small ISPs change to another next-hop big ISP suddenly. 701 For the GeoIP-enabled authoritative nameserver, the response 702 accurancy depends on the IP geolocation database quality. If 703 authoritative nameserver can not find approximate isp location of 704 ECS's client subnet, they can not return best tailored response. 706 Even though GeoIP-enabled authoritative nameservers know about the 707 precise isp location of ECS's client subnet, they may not know about 708 the latest toplogical path change of the isp to update the tailored 709 response in time. In the case of "small ISP -> big ISP (change 710 frequency) -> ... -> website", both small ISP's client ip/resolver ip 711 is not good factor for GeoDNS. Big companies work hard to catch up 712 with the client ip's connect topology change, and adjust their 713 authoritative nameservers' tailored response, but smaller companies 714 only deploy IP2Geo may not afford. 716 EIL wants to give downstream a chance to tell authoritative 717 nameserver its best path quickly and proactively, help to rise the 718 response accuracy, avoid cross-isp visit, save IP transit cost for 719 Data Provider. EIL directly provide sufficient information for the 720 GeoIP-enabled authoritative nameserver. Compared to ECS, EIL can 721 reduce GeoIP-enabled authoritative nameserver's dependence on the IP 722 geolocation database quality. 724 8. Security Considerations 726 8.1. DNSSEC 728 EIL is not signed. 730 8.2. Privacy 732 The biggest privacy concern on ECS is that client subnet information 733 is personally identifiable. The more domains publish their zones on 734 a third-party authoritative nameserver, the more end user privacy 735 information can be gathered by the authoritative nameserver according 736 to the ECS queries. 738 EIL is to improve user privacy which is inspired by ECS, prevented 739 leaks in the client subnet information. 741 Like ECS, EIL will leak the global zonefile configurations of the 742 authoritative nameservers more easily than normal case. 744 8.3. Target Censorship 746 DNS traffic is plain text by default. It is easily to be blocked or 747 poisoned by internet target censorship. To bypass the censorship, it 748 is better to encrypt the DNS traffic or use some proxy tunnel. 750 EIL's isp location information covers bigger area than ECS's client 751 subnet information. Therefore, compared to ECS in plain text 752 condition, EIL is weaker at blocking record attack, but stronger at 753 targeted DNS poisoning attack. 755 8.4. DDoS 757 To migrate the DDoS problem: 759 o If an Authority Server receives a DNS query with unknown data in 760 EIL option, it SHOULD return the default response whose EIL option 761 with null value. 763 o Nameservers OPTIONAL only implement EIL when the query is from a 764 TCP connection. 766 More migration techniques described in [RFC7871], Section 11.3. 768 9. IANA Considerations 770 This document defines EIL, need request IANA to assign a new EDNS0 771 option code to EIL. 773 10. Acknowledgements 775 EIL is inspired by ECS, the authors especially thanks to C. 776 Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari. 778 Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr 779 Špaček, Brian Hartvigsen, Ask Bjoern Hansen, Dave Lawrence. 781 Thanks a lot to all in the DNSOP, DNSPRIV mailing list. 783 11. Appendix A. GeoIP-enabled Authoritative Nameservers Example 784 11.1. BIND-GeoIP 786 As described in [BIND-GeoIP], BIND 9.10 is able to use data from 787 MaxMind GeoIP databases to achieve restrictions based on the 788 (presumed) geographic location of that address. The ACL itself is 789 still address-based, but the GeoIP-based specification mechanisms can 790 easily populate an ACL with addresses in a certain geographic 791 location. 793 acl "example" { 794 geoip country US; 795 geoip region CA; 796 geoip city "Redwood City"; /* names, etc., must be quoted if they contain spaces */ 797 }; 799 11.2. PowerDNS-GeoIP 801 As described in [PowerDNS-GeoIP], PowerDNS supports many geolocation 802 placeholders, such as %co = 3-letter country, %cn = continent, %re = 803 region, %ci = city. 805 domains: 806 - domain: geo.example.com 807 ttl: 30 808 records: 809 geo.example.com: 810 - soa: ns1.example.com hostmaster.example.com 2014090125 7200 3600 1209600 3600 811 - ns: 812 content: ns1.example.com 813 ttl: 600 814 - ns: ns2.example.com 815 - mx: 10 mx.example.com 816 fin.eu.service.geo.example.com: 817 - a: 192.0.2.2 818 - txt: hello world 819 - aaaa: 2001:DB8::12:34DE:3 820 # this will result first record being handed out 30% of time 821 swe.eu.service.geo.example.com: 822 - a: 823 content: 192.0.2.3 824 weight: 50 825 - a: 192.0.2.4 826 services: 827 # syntax 1 828 service.geo.example.com: '%co.%cn.service.geo.example.com' 829 # syntax 2 830 service.geo.example.com: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com'] 831 # alternative syntax 832 services: 833 service.geo.example.com: 834 default: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com' ] 835 10.0.0.0/8: 'internal.service.geo.example.com' 837 11.3. Amazon-Geolocation-Routing 839 As described in [Amazon-Geolocation-Routing], Amazon Route 53 lets 840 you choose the resources that serve your traffic based on the 841 geographic location of your users, meaning the location that DNS 842 queries originate from. It allows you to route some queries for a 843 continent to one resource and to route queries for selected countries 844 on that continent to a different resource. 846 When a browser or other viewer uses a DNS resolver that does support 847 edns-client-subnet, the DNS resolver sends Amazon Route 53 a 848 truncated version of the user's IP address. Amazon Route 53 849 determines the location of the user based on the truncated IP address 850 rather than the source IP address of the DNS resolver; this typically 851 provides a more accurate estimate of the user's location. Amazon 852 Route 53 then responds to geolocation queries with the DNS record for 853 the user's location. 855 11.4. DYN-Traffic-Director-ECS 857 As described in and 858 [DYN-Traffic-Director-ECS], Dyn provides the ability to control DNS 859 responses on a granular/customized geographical rule set. Part of 860 the rulesets will be the identification of the global regions, 861 countries, or states and provinces that use a specific DNS server 862 group. DYN uses the ECS information for the geolocation lookup. 863 Once a geolocation is found and a response is selected, it will 864 provide a DNS response back to the source IP address. 866 11.5. gdnsd-GeoIP 868 As described in [gdnsd-GeoIP], gdnsd uses MaxMind's GeoIP binary 869 databases to map address and CNAME results based on geography and 870 monitored service availability. gdnsd supports geolocation codes, 871 such as continent, country, region/subdivision, city. 873 11.6. Windows-Server-GeoLocation 875 As described in [Windows-Server-GeoLocation], Windows server can be 876 configured DNS Policy to respond to DNS client queries based on the 877 geographical location of both the client and the resource to which 878 the client is attempting to connect, providing the client with the IP 879 address of the closest resource. 881 12. Appendix B. EIL Example 883 Authoritative nameserver of www.example.com has enabled EIL. 885 Stub DNS query A resource record of www.example.com . 887 12.1. P-Model 889 Stub DNS 890 -> local forwarding resolver (61.48.7.2) 891 -> Public Forwarding Resolver(AliDNS, 223.5.5.5) 892 -> Public recursive resolver(AliDNS, 202.108.250.231) 893 -> authoritative nameserver 895 Public Forwarding Resolver 223.5.5.5 could enable EIL and generate 896 the EIL OPT data < CN, 11, UNI > based on 61.48.7.2. 898 P-Model will not leak client subnet to authoritative nameserver. 900 12.2. I-Model 902 Stub DNS 903 -> local forwarding resolver 904 -> ISP Forwarding Resolver(202.106.196.115) 905 -> ISP recursive resolver(61.135.23.92) 906 -> authoritative nameserver 908 ISP recursive resolver 61.135.23.92 could enable EIL and generate the 909 EIL OPT data < CN, 11, UNI > based on 61.135.23.92. 911 If authoritative nameserver doesn't know much about 61.135.23.92, EIL 912 will be helpful. 914 ISP recursive resolver generates static EIL query, simply manages 915 response cache as tranditionl non-ECS/non-EIL scenario. 917 EIL helps ISP recursive resolver to give upstream an explicit correct 918 isp location information. 920 12.3. L-Model 922 Stub DNS 923 -> Local Fowarding Resolver(58.60.109.234) 924 -> ... 925 -> authoritative nameserver 927 Local Fowarding Resolver 58.60.109.234 could enable EIL and generate 928 the option data is < CN, 44, TEL > based on 58.60.109.234. 930 L-Model can give the most precisely isp location information for DNS 931 resolution. 933 13. Appendix C. Frequent GeoIP-enabled Authoritative Nameserver's 934 Response Accuracy Problem 936 13.1. Public Recursive Resolver with non-ECS Authoritative Nameserver 938 If authoritative nameserver doesn't support ECS, the clients that use 939 public recursive resolver(such as 8.8.8.8) may receive disaster 940 latency IP. 942 In this scenario, we must pray that public recursive resolver's IP is 943 topological close to client's IP. 945 13.2. IP2Geo Database Quality 947 If authoritative nameserver's IP2Geo database misidentify client IP's 948 information, then the client may be assigned to some high letency 949 cross-isp IP address. 951 With EIL, public recursive resolver and ISP recursive resolver can 952 help to give more precise information for GeoIP-enabled authoritative 953 nameservers. 955 13.3. Unstable ISP Network Topology 957 Some small ISPs may change their upstreams frequently. Authoritative 958 nameservers offen can not catch up the variation in time. 960 EIL gives downstream a chance to proactively tell authoritative 961 nameservers the latest best topological close response itself wants 962 now. Downstream can assure itself has got explicit tailored response 963 with EIL. 965 For example, 218.247.200.100's isp location information is < China, 966 Beijing, PengBoShi >. In I-Model, PengBoShi's resolver can send EIL 967 < CN, 11, TEL > to authoritative nameservers, indicates that the best 968 topological close response forclient 218.247.200.100 is from China 969 Beijing Telecom. 971 14. References 973 14.1. Normative References 975 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 976 RFC 1034, November 1987. 978 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 979 Specification", RFC 1035, November 1987. 981 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 982 October 1994. 984 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 985 Requirement Levels", RFC 2119, March 1997. 987 [RFC2182] ELZ, R., Bush, R., Bradner, S., and M. Patton, "Selection 988 and Operation of Secondary DNS Servers", RFC 2182, July 989 1997. 991 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 992 for DNS (EDNS(0))", RFC 6891, April 2013. 994 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 995 Terminology", RFC 7719, December 2015. 997 [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W. 998 Kumari, "Client Subnet in DNS Queries", RFC 7871, May 999 2016. 1001 14.2. Informative References 1003 [Amazon-Geolocation-Routing] 1004 Amazon, "Amazon Route 53: Geolocation Routing", 1005 . 1008 [BIND-GeoIP] 1009 ISC BIND, "Using the GeoIP Features in BIND 9.10", 1010 . 1012 [CLIENT-SUBNET-BIS] 1013 Sivaraman, Mukund., "CLIENT-SUBNET bis appetite?", 1014 . 1017 [DNS-TEST-EIL] 1018 Pan, Lanlan., "dns_test_eil", . 1021 [DYN-Traffic-Director-ECS] 1022 DYN, "What happens when a DNS query for a Traffic Director 1023 instance is received with ECS information", 1024 . 1026 [DYN-Traffic-Director-Geographic-Groups] 1027 DYN, "Predefined Geographic Groups of Traffic Director", 1028 . 1031 [gdnsd-GeoIP] 1032 gdnsd, "GdnsdPluginGeoip", 1033 . 1035 [ISO3166] ISO 3166, "Country Codes", 1036 . 1038 [PowerDNS-GeoIP] 1039 PowerDNS, "PowerDNS GeoIP backend", 1040 . 1043 [Windows-Server-GeoLocation] 1044 Microsoft, "Use DNS Policy for Geo-Location Based Traffic 1045 Management with Primary Servers", 1046 . 1049 Authors' Addresses 1051 Lanlan Pan 1052 Beijing 1053 China 1055 Email: abbypan@gmail.com 1056 URI: https://github.com/abbypan 1058 Yu Fu 1059 CNNIC 1060 No.4 South 4th Street, Zhongguancun 1061 Beijing 1062 China 1064 Email: fuyu@cnnic.cn