idnits 2.17.1 draft-pan-dnsop-edns-isp-location-02.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 4 instances of too long lines in the document, the longest one being 24 characters in excess of 72. == There are 9 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 (July 17, 2017) is 2474 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 812, 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: January 18, 2018 CNNIC 6 July 17, 2017 8 ISP Location in DNS Queries 9 draft-pan-dnsop-edns-isp-location-02 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 January 18, 2018. 49 Copyright Notice 51 Copyright (c) 2017 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 6 72 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 8 73 6.1. Originating the Option . . . . . . . . . . . . . . . . . 8 74 6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 8 75 6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8 76 6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 9 77 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 78 6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 9 79 6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 9 80 6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 10 81 6.3. Handling EIL Responses and Caching . . . . . . . . . . . 10 82 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 10 83 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 10 84 6.3.3. Support ECS and EIL at the same time . . . . . . . . 11 85 6.4. Delegations and Negative Answers . . . . . . . . . . . . 12 86 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 12 87 6.6. Response Accuracy . . . . . . . . . . . . . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 13 92 7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 14 93 7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 96 10. Appendix A. GeoIP-enabled Nameservers Example . . . . . . . . 14 97 10.1. BIND-GeoIP . . . . . . . . . . . . . . . . . . . . . . . 14 98 10.2. PowerDNS-GeoIP . . . . . . . . . . . . . . . . . . . . . 15 99 10.3. Amazon-Geolocation-Routing . . . . . . . . . . . . . . . 16 100 10.4. DYN-Traffic-Director-ECS . . . . . . . . . . . . . . . . 16 101 10.5. gdnsd-GeoIP . . . . . . . . . . . . . . . . . . . . . . 16 102 11. Appendix B. EIL Example . . . . . . . . . . . . . . . . . . . 16 103 11.1. P-Model . . . . . . . . . . . . . . . . . . . . . . . . 17 104 11.2. I-Model . . . . . . . . . . . . . . . . . . . . . . . . 17 105 11.3. L-Model . . . . . . . . . . . . . . . . . . . . . . . . 17 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 108 12.2. Informative References . . . . . . . . . . . . . . . . . 18 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 111 1. Introduction 113 Nowadays, many Authoritative Nameservers support GeoIP feature, such 114 as BIND-GeoIP [BIND-GeoIP], PowerDNS-GeoIP [PowerDNS-GeoIP], Amazon- 115 Geolocation-Routing [Amazon-Geolocation-Routing], DYN-Traffic- 116 Director-ECS [DYN-Traffic-Director-ECS], gdnsd-GeoIP [gdnsd-GeoIP] 117 (More details are given in Appendix A). These geographically aware 118 Authoritative Nameservers guess the user's geolocation by the client 119 subnet of ECS or by the source IP address of DNS query, return tailor 120 DNS response based on the user's geolocation. 122 ECS is an EDNS0 [RFC6891] option, described in [RFC7871], carries 123 client subnet information in DNS queries for Authoritative 124 Nameserver. Compared to source IP address of DNS query, ECS will 125 help Authoritative Nameserver to guess the client's location more 126 precisely because of the DNS forwarding query structure. 128 GeoIP-enabled Authoritative Nameservers use ECS for user geolocation 129 detecting. However, ECS raises some privacy concerns because it 130 leaks client subnet information on the resolution path to the 131 Authoritative Nameserver. 133 This document describes an improved solution for GeoIP-enabled 134 Authoritative Nameserver, defines an EDNS ISP Location (EIL) 135 extension to address the privacy problem of ECS, tries to find the 136 right balance between privacy improvement and user experience 137 optimization. 139 EIL is defined to convey isp location < COUNTRY, AREA, ISP > 140 information that is relevant to the DNS message. It will directly 141 provide the same sufficient information for the GeoIP-enabled 142 Authoritative Nameserver as ECS, to decide the response without 143 guessing geolocation of the IP address. 145 EIL is intended for those Local Forwarding Resolvers, Recursive 146 Resolvers and Authoritative Nameservers that would benefit from the 147 extension and not for general purpose deployment. It could be 148 applied for tailor DNS response like ECS scenario. EIL can safely be 149 ignored by servers that choose not to implement or enable it. 151 1.1. Path Calculation and Tailored DNS Response 153 Separate the consideration of path calculation (Data Provider) and 154 tailored DNS response (Authoritative Nameserver). 156 Data Providers make path calculations to optimize content delivery on 157 the Internet based on the network topology, considering many factors 158 such as IP, RIPs, FIBs, AS Path hops, system load, content 159 availability, path latency, etc. Note that, Data Providers have the 160 full details of the clients, they can make any complex path 161 calculations without ECS and EIL. 163 Authoritative Nameservers configure tailored DNS response based on 164 the result of path calculations, allocate IP addresses to different 165 datacenters. Usually, users from the same < COUNTRY, AREA, ISP > isp 166 location are allocated to the same datacenter, the same best "network 167 topologically close" datacenter. For example, client IP addresses 168 from < China, Beijing, Telecom > are allocated to DataCenter-1, 169 client IP addresses from < China, Beijing, Unicom > are allocated to 170 DataCenter-2, etc. Above is the GeoIP-based Tailored DNS Response. 172 Therefore, if the GeoIP-enabled Authoritative Nameservers support 173 ECS, they can use the client subnet information of ECS instead of 174 resolver's address for geolocation detecting. Alternative, the 175 GeoIP-enabled Authoritative Nameservers can directly use the < 176 COUNTRY, AREA, ISP > information of EIL without geolocation 177 detecting. 179 Again, we emphasize that tailored DNS response does not affect path 180 calculation. Data Providers can make path calculations based on 181 network topology, decide network topological close datacenter for 182 each IP address. Authoritative Nameservers allocate tailored DNS 183 response to each IP address based on the "network topological close" 184 result of path calculations. EIL tell Authoritative Nameserver like 185 that, "I want to know what is best IP address for clients from < 186 China, Beijing, Telecom > at network topology path calculations 187 result", but not "I want to know what is the nearest IP address for 188 clients from < China, Beijing, Telecom > at physical topology path 189 calculations result". 191 EIL is satisfied if Authoritative Nameservers aggregate the IP 192 addresses from the same < COUNTRY, AREA, ISP > isp location to visit 193 the same datacenters, we call that GeoIP-based tailored DNS 194 responses, and these tailored responses have the best "network 195 topological close" distance to the users which are generated from 196 network topology path calculations result. 198 ECS is satisfied if Authoritative Nameservers make tailored DNS 199 response down to subnet precise level. For example, (subnet-1, ..., 200 subnet-100) are from the same < COUNTRY, AREA, ISP > isp location, 201 Data Provider applies (subnet-1, ..., subnet-50) visit DataCenter-1, 202 (subnet-51, ..., subnet-100) visit DataCenter-2. 204 2. Requirements Language 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 208 "OPTIONAL" in this document are to be interpreted as described in 209 [RFC2119] when they appear in ALL CAPS. When these words are not in 210 ALL CAPS (such as "should" or "Should"), they have their usual 211 English meanings, and are not to be interpreted as [RFC2119] 212 keywords. 214 3. Terminology 216 Basic terms used in this specification are defined in the documents 217 [RFC1034], [RFC1035], [RFC7719] and [RFC7871]. 219 EIL: EDNS ISP Location. 221 ECS: EDNS Client Subnet, described in [RFC7871]. 223 Local Forwarding Resolver: Forwarding Resolver is described in 224 [RFC7871]. It is the first Forwarding Resolver which receives DNS 225 queries from Stub Resolver, usually deployed nearby the first-hop 226 router such as public Wi-Fi hotspot routers and home routers. 228 Recursive Resolver: described in [RFC7871]. It is the last-hop 229 before Authoritative Nameserver in the DNS query path. 231 Intermediate Nameserver: described in [RFC7871]. Any nameserver in 232 between the Stub Resolver and the Authoritative Nameserver, such as a 233 Recursive Resolver or a Forwarding Resolver. 235 Intermediate Forwarding Resolver: Any Forwarding Resolver in between 236 the Local Forwarding Resolver and Recursive Resolver. 238 Authoritative Nameserver: described in [RFC7719] and [RFC2182]. It 239 is a server that knows the content of a DNS zone from local 240 knowledge, and thus can answer queries about that zone without 241 needing to query other servers. 243 4. Overview 245 EIL is an EDNS0 option to allow Local Forwarding Resolvers and 246 Recursive Resolvers, if they are willing, to forward details about 247 the isp location of client when talking to other nameservers. EIL 248 can be added in queries sent by Local Forwarding Resolvers or 249 Recursive Resolvers in a way that is transparent to Stub Resolvers 250 and end users. 252 Like ECS, Authoritative Nameservers could provide a better answer by 253 using precise isp location in EIL. Intermediate Nameservers could 254 send EIL query and cache the EIL response. This document also 255 provides a mechanism to signal Intermediate Nameservers that they do 256 not want EIL treatment for specific queries. 258 EIL is only defined for the Internet (IN) DNS class. 260 The format of EIL option is described in Section 5. 262 The security concerns for EIL are like ECS, such as cache growth, 263 spoof EDNS0 option and privacy, etc. Mitigation techniques are 264 discussed in Section 6. 266 5. The EIL EDNS0 option 268 The EIL is an EDNS0 option to include the isp location of client in 269 DNS messages. 271 It is 14 octets which is structured as follows: 273 +0 (MSB) +1 (LSB) 274 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 275 0: | OPTION-CODE | 276 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 277 2: | OPTION-LENGTH | 278 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 279 4: | COUNTRY-CODE | 280 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 281 6: | AREA-CODE | 282 | | 283 | | 284 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 285 12: | ISP | 286 | | 287 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 289 Total: 14 octets. 291 o OPTION-CODE, 2 octets, defined in [RFC6891]. EDNS option code 292 should be assigned by the IANA. 294 o OPTION-LENGTH, 2 octets, defined in [RFC6891], contains the length 295 of the payload (everything after OPTION-LENGTH) in octets. 297 o COUNTRY-CODE, 2 octets, uppercase, defined in [ISO3166], indicates 298 the country information of the client's IP. For example, China's 299 COUNTRY-CODE is CN. 301 o AREA-CODE, 6 octets, uppercase, defined in [ISO3166] country 302 subdivision code, indicates the area information of the client's 303 IP. For example, The AREA-CODE of Fujian Province in China is 35. 305 o ISP, 4 octets, uppercase, indicates the ISP information of the 306 client's IP, using shortcut names. ISP shortcut names are unique 307 within the context of the COUNTRY-CODE. For example, the shortcut 308 name of China Telecommunications Corporation is TEL, the shortcut 309 name of China United Network Communications is UNI, the shortcut 310 name of China Mobile is MOB, etc. 312 All fields are in network byte order ("big-endian", per [RFC1700], 313 Data Notation). 315 The aim to use short names in the fields is to limit the data size of 316 EIL, decrease the DDoS risk. 318 The null value 0x20 signifies that the field is unknown. If all 319 fields in EIL are set to null value, it means that client doesn't 320 want to use EIL. 322 Authoritative Nameservers can send EIL response with the * value 0x2A 323 in AREA-CODE field or ISP field (not COUNTRY-CODE field), which 324 signifies that the field is wildcard match. For example, < CN, *, 325 TEL > indicates "all area in China, Telecom ISP". 327 Example code is in Github at: https://github.com/abbypan/dns_test_eil 328 . 330 6. Protocol Description 332 6.1. Originating the Option 334 The EIL can be initialized by Public Recursive Resolver, ISP 335 Recursive Resolver, or Local Forwarding Resolver. 337 Examples are given in Appendix B. 339 6.1.1. P-Model: Public Recursive Resolver 341 Public Recursive Resolvers are not close to many users because the 342 service providers couldn't deploy servers in every country and every 343 ISP's network, which will affect the response accuracy of 344 Authoritative Nameservers. To encounter this problem, ECS shifts the 345 client subnet information to Authoritative Nameserver, but rises user 346 privacy concerns. 348 Therefore, to keep balance between precise and privacy, when a Public 349 Recursive Resolver receives a DNS query, it can guess isp location of 350 client's IP and generate the EIL OPT data, then send EIL query to the 351 Authoritative Nameserver. This will move the "guess location of 352 client's IP" work from Authoritative Nameserver back to Public 353 Recursive Resolver, lighten the burden of Authoritative Nameserver, 354 but increase DDoS risk on Public Recursive Resolver. 356 In order to improve the user's privacy, if a Recursive Resolver 357 receives a DNS query with ECS, it can guess the isp location of 358 SOURCE-PREFIX from the ECS OPT data, and make a new DNS query with 359 EIL, then send the query to Authoritative Nameserver which supports 360 EIL. 362 P-model is the most recommended and close to the ECS. 364 6.1.2. I-Model: ISP Recursive Resolver 366 ISP Recursive Resolver only serves its customers, each of whom has a 367 static isp location. ISP Recursive Resolver can add EIL transparent 368 to end user, and then Authoritative Nameserver doesn't need to "guess 369 location of client's IP". 371 EIL will be benefit if the Authoritative Nameserver could not find 372 the approximate isp location of ISP Recursive Resolver, which is 373 crucial to DNS response accuracy in ECS. 375 6.1.3. L-Model: Local Forwarding Resolver 377 Local Forwarding Resolver is usually on the first-hop router, such as 378 public Wi-Fi hotspot routers and Cisco/Linksys/Netgear/TP-LINK home 379 routers. 381 When a Local Forwarding Resolver that implements EIL receives a DNS 382 query from an end user, it surely can know about the isp location of 383 client's IP, and generate the EIL OPT data, then send the EIL query 384 to the intermediate Recursive Resolver. Intermediate Recursive 385 Resolver sends the EIL query to the Authoritative Nameserver. 387 In this scenario, both Public Recursive Resolver and Authoritative 388 Nameserver don't need to "guess location of client's IP", because the 389 Local Forwarding Resolver supplies the isp location precisely. That 390 is, EIL can reduce dependence on the IP geolocation database quality, 391 which is crucial to DNS response accuracy in ECS. 393 If a Local Forwarding Resolver had sent a query with EIL, and 394 receives a REFUSE response, it MUST regenerate a query with no EIL. 396 6.2. Generating a Response 398 6.2.1. Whitelist 400 EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which 401 can be discussed and maintained by the DNSOP working group. 402 Authoritative Nameservers that supporting EIL must only response the 403 EIL queries matched the whitelist. Recursive Resolver that 404 supporting EIL must only cache the EIL responses matched the 405 whitelist. 407 6.2.2. Authoritative Nameserver 409 Using the isp location specified in the EIL option of DNS query, an 410 Authoritative Nameserver can generate a tailored response. 412 Authoritative Nameservers that have not implemented or enabled 413 support for the EIL ought to safely ignore it within incoming 414 queries, response the query as a normal case without EDNS0 option. 415 Such a server MUST NOT include an EIL option within replies to 416 indicate lack of support for it. 418 An Authoritative Nameserver that has implemented this protocol and 419 receives an EIL option MUST include an EIL option in its response to 420 indicate that it SHOULD be cached accordingly. 422 An Authoritative Nameserver will return a more appropriate tailored 423 response for the query with an EIL option containing more precisely 424 AREA-CODE. 426 6.2.3. Intermediate Nameserver 428 Like ECS, Intermediate Nameserver passes a DNS response with an EIL 429 option to its client when the client indicates support EIL. 431 If an Intermediate Nameserver receives a response that has a larger 432 area than the AREA-CODE provided in its query, it SHOULD still 433 provide the result as the answer to the triggering client request 434 even if the client is in a smaller area. 436 6.3. Handling EIL Responses and Caching 438 If an Intermediate Nameserver had sent a query with EIL, and receives 439 a NOERROR response without EIL option, it SHOULD treat this answer as 440 suitable for all clients. 442 Other handling considerations are similar with ECS [RFC7871], SECTION 443 7.3. 445 6.3.1. Caching the Response 447 In the cache, all resource records in the Answer section MUST be tied 448 to the isp location specified in the response. The Answer section is 449 valid for all areas which the EIL option covered. For example, an 450 EIL option < CN, 35, TEL > covers all 9 Cities in Fujian Province of 451 China Telecommunications ISP. 453 Same with ECS, The Additional and Authority sections are excluded. 455 Enabling support for EIL in an Intermediate Nameserver will increase 456 the size of the cache, and prevent "client subnet leak" privacy 457 concern of ECS. 459 6.3.2. Answering from Cache 461 Cache lookups are first done as usual for a DNS query, using the 462 query tuple of < name, type, class >. Then, the appropriate RRset 463 MUST be chosen based on the isp location matching. 465 If there was an EIL option, the Intermediate Nameserver will lookup 466 for < same COUNTRY-CODE, same ISP, same AREA-CODE > of the same query 467 tuple in the cache. Otherwise, try to find < same COUNTRY-CODE, same 468 ISP, same AREA-CODE > of the same query tuple in the cache. 470 If no EIL option was provided, the safest choice of the Intermediate 471 Nameserver is dealing the query as a normal case without EDNS0 472 option. 474 If no EIL option was provided, but the Intermediate Nameserver want 475 to be more aggressive, it can guess the isp location from the source 476 IP of the query, then respond as if there was an EIL option with the 477 guessed information. Users can be benefit when the Intermediate 478 Nameserver has a more precise IP location database than the 479 Authoritative Nameserver, especially in global public DNS service 480 like GoogleDNS(8.8.8.8). 482 If no matching is found, the Intermediate Nameserver MUST perform 483 resolution as usual. 485 6.3.3. Support ECS and EIL at the same time 487 Name servers can support ECS and EIL at the same time. ECS and EIL 488 can't be both initiated at the same DNS packet. It is better for 489 user privacy if name servers initiate the EIL query prior to the ECS 490 query. 492 If Authoritative Nameservers support both ECS and EIL, Recursive 493 resolvers can cache both ECS response and EIL response, there are 494 some choices for Recursive Resolvers when they receive DNS queries. 496 Receive EIL query: 497 Search in EIL cache. 498 If cache is matched, return EIL response. 499 Otherwise, send EIL query to Authoritative Nameserver. 501 Receive ECS query: 502 Search in ECS cache. 503 If cache is matched, return ECS response. 504 Otherwise, send ECS query to Authoritative Nameserver. 506 Receive DNS query without EDNS option: 507 Search in ECS cache. 508 If cache is matched, return ECS response. 509 Otherwise, 510 Guess the isp location information of the client's IP, 511 build EIL option for the query packet. 512 Search in EIL cache. 513 If cache is matched, return EIL response. 514 Otherwise, send EIL query to Authoritative Nameserver. 516 Receive DNS query with not-ECS/not-EIL option: 517 Search in not-EDNS cache. 518 If cache is matched, return response. 519 Otherwise, send the DNS query to Authoritative Nameserver. 521 Receive ECS query, improve user privacy: 522 Guess the isp location information of the client's IP, 523 build EIL option for the query packet. 524 Search in EIL cache. 525 If cache is matched, return EIL response RR with origin ECS option. 526 Otherwise, send EIL query to Authoritative Nameserver. 528 6.4. Delegations and Negative Answers 530 EIL's delegation case is similar with ECS, Additional and Authority 531 Sections SHOULD ignore EIL. 533 For negative answers, Authoritative Nameservers return traditional 534 negative answers without EIL. 536 6.5. Transitivity 538 EIL's transitivity concerns are similar with ECS. 540 Name servers should only enable EIL where it is expected to benefit 541 the end users, such as dealing with some latency-sensitive CDN domain 542 queries in a complex network environment. 544 6.6. Response Accuracy 546 GeoIP-enabled Authoritative Nameservers that support ECS can support 547 EIL smoothly. 549 Compared to ECS, EIL can reduce dependence on the IP geolocation 550 database quality. EIL will rise the response accuracy of 551 Authoritative Nameserver if its database can not find approximate isp 552 location of ECS client subnet, ensure user latency. EIL will help 553 Authoritative Nameservers to avoid cross-isp visit if its database 554 can not find approximate isp location of ECS client subnet, save IP 555 transit cost. 557 7. Security Considerations 559 7.1. DNSSEC 561 EIL is not signed. 563 7.2. Privacy 565 As mentioned in [RFC7871]'s abstract section, since ECS has some 566 known operational and privacy shortcomings, a revision will be worked 567 through the IETF for improvement. The biggest privacy concern on ECS 568 is that client subnet information is personally identifiable. The 569 more domains publish their zones on a third-party Authoritative 570 Nameserver, the more end user privacy information can be gathered by 571 the Authoritative Nameserver according to the ECS queries. 573 EIL is to improve user privacy which is inspired by ECS, prevented 574 leaks in the client subnet information. 576 Like ECS, EIL will leak the global zonefile configurations of the 577 Authoritative Nameservers more easily than normal case. 579 7.3. Target Censorship 581 DNS traffic is plain text by default. It is easily to be blocked or 582 poisoned by internet target censorship. To bypass the censorship, it 583 is better to encrypt the DNS traffic or use some proxy tunnel. 585 EIL's isp location information covers bigger area than ECS's client 586 subnet information. Therefore, compared to ECS in plain text 587 condition, EIL is weaker at blocking record attack, but stronger at 588 targeted DNS poisoning attack. 590 7.4. Cache Size 592 Like ECS, cache size will raise if a Public Recursive Resolver 593 supports EIL. The cache size of ECS grows up with the number of 594 client subnets. The cache size of EIL is related to the row count in 595 the < COUNTRY-CODE, AREA-CODE, ISP > isp location whitelist. 596 Therefore, under IPv6 environment, the cache size of EIL will be 597 smaller than ECS. 599 7.5. DDoS 601 To migrate the DDoS problem: 603 o If an Authority Server receives a DNS query with unknown data in 604 EIL option, it SHOULD return the default response whose EIL option 605 with null value. 607 o Nameservers OPTIONAL only implement EIL when the query is from a 608 TCP connection. 610 More migration techniques described in [RFC7871], Section 11.3. 612 8. IANA Considerations 614 This document defines EIL, need request IANA to assign a new EDNS0 615 option code to EIL. 617 9. Acknowledgements 619 EIL is inspired by ECS, the authors especially thanks to C. 620 Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari. 622 Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr 623 Špaček, Brian Hartvigsen, Ask Bjoern Hansen. 625 Thanks a lot to all in the DNSOP, DNSPRIV and DNSEXT mailing list. 627 10. Appendix A. GeoIP-enabled Nameservers Example 629 10.1. BIND-GeoIP 631 As described in BIND-GeoIP [BIND-GeoIP], BIND 9.10 is able to use 632 data from MaxMind GeoIP databases to achieve restrictions based on 633 the (presumed) geographic location of that address. The ACL itself 634 is still address-based, but the GeoIP-based specification mechanisms 635 can easily populate an ACL with addresses in a certain geographic 636 location. 638 acl "example" { 639 geoip country US; 640 geoip region CA; 641 geoip city "Redwood City"; /* names, etc., must be quoted if they contain spaces */ 642 }; 644 10.2. PowerDNS-GeoIP 646 As described in PowerDNS-GeoIP [PowerDNS-GeoIP], PowerDNS supports 647 many geolocation placeholders, such as %co = 3-letter country, %cn = 648 continent, %re = region, %ci = city. 650 domains: 651 - domain: geo.example.com 652 ttl: 30 653 records: 654 geo.example.com: 655 - soa: ns1.example.com hostmaster.example.com 2014090125 7200 3600 1209600 3600 656 - ns: 657 content: ns1.example.com 658 ttl: 600 659 - ns: ns2.example.com 660 - mx: 10 mx.example.com 661 fin.eu.service.geo.example.com: 662 - a: 192.0.2.2 663 - txt: hello world 664 - aaaa: 2001:DB8::12:34DE:3 665 # this will result first record being handed out 30% of time 666 swe.eu.service.geo.example.com: 667 - a: 668 content: 192.0.2.3 669 weight: 50 670 - a: 192.0.2.4 671 services: 672 # syntax 1 673 service.geo.example.com: '%co.%cn.service.geo.example.com' 674 # syntax 2 675 service.geo.example.com: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com'] 676 # alternative syntax 677 services: 678 service.geo.example.com: 679 default: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com' ] 680 10.0.0.0/8: 'internal.service.geo.example.com' 682 10.3. Amazon-Geolocation-Routing 684 As described in Amazon-Geolocation-Routing 685 [Amazon-Geolocation-Routing], Amazon Route 53 lets you choose the 686 resources that serve your traffic based on the geographic location of 687 your users, meaning the location that DNS queries originate from. It 688 allows you to route some queries for a continent to one resource and 689 to route queries for selected countries on that continent to a 690 different resource. 692 When a browser or other viewer uses a DNS resolver that does support 693 edns-client-subnet, the DNS resolver sends Amazon Route 53 a 694 truncated version of the user's IP address. Amazon Route 53 695 determines the location of the user based on the truncated IP address 696 rather than the source IP address of the DNS resolver; this typically 697 provides a more accurate estimate of the user's location. Amazon 698 Route 53 then responds to geolocation queries with the DNS record for 699 the user's location. 701 10.4. DYN-Traffic-Director-ECS 703 As described in DYN-Traffic-Director-Geographic-Groups and DYN- 704 Traffic-Director-ECS [DYN-Traffic-Director-ECS], Dyn provides the 705 ability to control DNS responses on a granular/customized 706 geographical rule set. Part of the rulesets will be the 707 identification of the global regions, countries, or states and 708 provinces that use a specific DNS server group. DYN uses the ECS 709 information for the geolocation lookup. Once a geolocation is found 710 and a response is selected, it will provide a DNS response back to 711 the source IP address. 713 10.5. gdnsd-GeoIP 715 As described in gdnsd-GeoIP [gdnsd-GeoIP], gdnsd uses MaxMind's GeoIP 716 binary databases to map address and CNAME results based on geography 717 and monitored service availability. gdnsd supports geolocation codes, 718 such as continent, country, region/subdivision, city. 720 11. Appendix B. EIL Example 722 Authoritative Nameserver of www.example.com has enabled EIL. 724 Stub DNS query A resource record of www.example.com . 726 11.1. P-Model 728 Stub DNS 729 -> Local Forwarding Resolver (61.48.7.2) 730 -> Public Forwarding Resolver(AliDNS, 223.5.5.5) 731 -> Public Recursive Resolver(AliDNS, 202.108.250.231) 732 -> Authoritative Nameserver 734 Public Forwarding Resolver 223.5.5.5 could enable EIL and generate 735 the EIL OPT data < CN, 11, UNI > based on 61.48.7.2. 737 P-Model will not leak client subnet to Authoritative Nameserver. 739 11.2. I-Model 741 Stub DNS 742 -> Local Forwarding Resolver 743 -> ISP Forwarding Resolver(202.106.196.115) 744 -> ISP Recursive Resolver(61.135.23.92) 745 -> Authoritative Nameserver 747 ISP Recursive Resolver 61.135.23.92 could enable EIL and generate the 748 EIL OPT data < CN, 11, UNI > based on 61.135.23.92. 750 If Authoritative Nameserver doesn't know much about 61.135.23.92, EIL 751 will be helpful. 753 11.3. L-Model 755 Stub DNS 756 -> Local Fowarding Resolver(58.60.109.234) 757 -> ... 758 -> Authoritative Nameserver 760 Local Fowarding Resolver 58.60.109.234 could enable EIL and generate 761 the option data is < CN, 44, TEL > based on 58.60.109.234. 763 L-Model can give the most precisely isp location information for DNS 764 resolution. 766 12. References 768 12.1. Normative References 770 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 771 RFC 1034, November 1987. 773 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 774 Specification", RFC 1035, November 1987. 776 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 777 October 1994. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", RFC 2119, March 1997. 782 [RFC2182] ELZ, R., Bush, R., Bradner, S., and M. Patton, "Selection 783 and Operation of Secondary DNS Servers", RFC 2182, July 784 1997. 786 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 787 for DNS (EDNS(0))", RFC 6891, April 2013. 789 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 790 Terminology", RFC 7719, December 2015. 792 [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W. 793 Kumari, "Client Subnet in DNS Queries", RFC 7871, May 794 2016. 796 12.2. Informative References 798 [Amazon-Geolocation-Routing] 799 Amazon, "Amazon Route 53: Geolocation Routing", 800 . 803 [BIND-GeoIP] 804 ISC BIND, "Using the GeoIP Features in BIND 9.10", 805 . 807 [DYN-Traffic-Director-ECS] 808 DYN, "What happens when a DNS query for a Traffic Director 809 instance is received with ECS information", 810 . 812 [DYN-Traffic-Director-Geographic-Groups] 813 DYN, "Predefined Geographic Groups of Traffic Director", 814 . 817 [gdnsd-GeoIP] 818 gdnsd, "GdnsdPluginGeoip", 819 . 821 [ISO3166] ISO 3166, "Country Codes", 822 . 824 [PowerDNS-GeoIP] 825 PowerDNS, "PowerDNS GeoIP backend", 826 . 829 Authors' Addresses 831 Lanlan Pan 832 Beijing 833 China 835 Email: abbypan@gmail.com 836 URI: https://github.com/abbypan 838 Yu Fu 839 CNNIC 840 No.4 South 4th Street, Zhongguancun 841 Beijing 842 China 844 Email: fuyu@cnnic.cn