idnits 2.17.1 draft-pan-dnsop-edns-isp-location-01.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 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2017) is 2535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: November 12, 2017 CNNIC 6 May 11, 2017 8 ISP Location in DNS Queries 9 draft-pan-dnsop-edns-isp-location-01 11 Abstract 13 This document describes an Extension Mechanisms for DNS (EDNS0) 14 option that is in active use to carry < COUNTRY, AREA, ISP > isp 15 location information about the network that originated a DNS query 16 and the network for which the subsequent response can be cached. 18 It is inspired by EDNS Client Subnet (ECS) with some privacy 19 considerations, goals to reduce the "guess location of client's IP" 20 work on Authoritative Nameservers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 12, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Path Calculation and Tailored DNS Response . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 6 62 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 64 6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 7 65 6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8 66 6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 8 67 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 68 6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 9 69 6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 9 70 6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 9 71 6.3. Handling EIL Responses and Caching . . . . . . . . . . . 9 72 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 10 73 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 10 74 6.3.3. Support ECS and EIL at the same time . . . . . . . . 10 75 6.4. Delegations and Negative Answers . . . . . . . . . . . . 11 76 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 12 77 6.6. Response Accuracy . . . . . . . . . . . . . . . . . . . . 12 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 12 82 7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 86 10. Appendix A. Example . . . . . . . . . . . . . . . . . . . . . 13 87 10.1. Example 1: P-Model . . . . . . . . . . . . . . . . . . . 14 88 10.2. Example 2: I-Model . . . . . . . . . . . . . . . . . . . 14 89 10.3. Example 3: L-Model . . . . . . . . . . . . . . . . . . . 14 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 11.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 As described in EDNS Client Subnet (ECS) [RFC7871], many 98 Authoritative Nameservers today return different responses based on 99 the perceived topological location of the user. These servers use 100 the IP address of the incoming query to identify that location. ECS 101 is an EDNS0 [RFC6891] option to carry client subnet information in 102 DNS queries for Authoritative Nameserver. Compared to source IP 103 address of DNS query, ECS will help Authoritative Nameserver to guess 104 the client's location more precisely because of the DNS forwarding 105 query structure. 107 However, ECS raises some privacy concerns because it leaks client 108 subnet information on the resolution path to the Authoritative 109 Nameserver. 111 Meanwhile, many Authoritative Nameservers support GeoIP feature, for 112 example, BIND-GeoIP [BIND-GeoIP], PowerDNS-GeoIP [PowerDNS-GeoIP], 113 Amazon-Geolocation-Routing [Amazon-Geolocation-Routing], DYN-Traffic- 114 Director-ECS [DYN-Traffic-Director-ECS], gdnsd-GeoIP [gdnsd-GeoIP], 115 etc. These geographically aware Authoritative Nameservers guess the 116 user's geolocation by the client subnet of ECS or by the source IP 117 address of DNS query, return tailor DNS response based on the user's 118 geolocation. To sum up, these Authoritative Nameservers use ECS 119 client subnet information for GeoIP feature's user geolocation 120 detecting. 122 This document is an improved solution for ECS-enabled GeoIP feature 123 of Authoritative Nameserver, describes an EDNS ISP Location (EIL) 124 extension to address the privacy problem of ECS, find the right 125 balance between privacy improvement and user experience optimization. 126 EIL is defined to convey isp location < COUNTRY, AREA, ISP > 127 information that is relevant to the DNS message. It will directly 128 provide the same sufficient information for the GeoIP-based 129 Authoritative Nameserver that enabling ECS, to decide the response 130 without guessing geolocation of the IP address. 132 EIL is intended for those Local Forwarding Resolvers, Recursive 133 Resolvers and Authoritative Nameservers that would benefit from the 134 extension and not for general purpose deployment like ECS scenario. 135 It could be applied for tailor DNS response. EIL can safely be 136 ignored by servers that choose not to implement or enable it. 138 1.1. Path Calculation and Tailored DNS Response 140 Separate the consideration of path calculation (Data Provider) and 141 tailored DNS response (Authoritative Nameserver). 143 Data Providers make path calculations to optimize content delivery on 144 the Internet based on the network topology, considering many factors 145 such as IP, RIPs, FIBs, AS Path hops, system load, content 146 availability, path latency, etc. Note that, Data Providers have the 147 full details of the clients, they can make any complex path 148 calculations without ECS and EIL. 150 Authoritative Nameservers configure tailored DNS response based on 151 the result of path calculations, allocate IP addresses to different 152 datacenters. Usually, users from the same < COUNTRY, AREA, ISP > isp 153 location are allocated to the same datacenter, the same best "network 154 topologically close" datacenter. For example, client IP addresses 155 from < China, Beijing, Telecom > are allocated to DataCenter-1, 156 client IP addresses from < China, Beijing, Unicom > are allocated to 157 DataCenter-2, etc. Above is the GeoIP-based Tailored DNS Response. 159 Therefore, if the GeoIP-based Authoritative Nameservers enable ECS, 160 they can use the client subnet information of ECS instead of 161 resolver's address for GeoIP detecting. Moreover, the GeoIP-based 162 Authoritative Nameservers can directly use the < COUNTRY, AREA, ISP > 163 information of EIL without GeoIP detecting. 165 Again, we emphasize that tailored DNS response does not affect path 166 calculation. Data Providers can make path calculations based on 167 network topology, decide network topological close datacenter for 168 each IP address. Authoritative Nameservers allocate tailored DNS 169 response to each IP address based on the "network topological close" 170 result of path calculations. EIL tell Authoritative Nameserver like 171 that, "I want to know what is best IP address for clients from < 172 China, Beijing, Telecom > at network topology path calculations 173 result", but not "I want to know what is the nearest IP address for 174 clients from < China, Beijing, Telecom > at physical topology path 175 calculations result". 177 EIL is satisfied if Authoritative Nameservers aggregate the IP 178 addresses from the same < COUNTRY, AREA, ISP > isp location to visit 179 the same datacenters, we call that GeoIP-based tailored DNS 180 responses, and these tailored responses have "network topological 181 close" distance to the users. 183 ECS is satisfied if Authoritative Nameservers make tailored DNS 184 response down to subnet precise level. For example, (subnet-1, ..., 185 subnet-100) are from the same < COUNTRY, AREA, ISP > isp location, 186 Data Provider applies (subnet-1, ..., subnet-50) visit DataCenter-1, 187 (subnet-51, ..., subnet-100) visit DataCenter-2. 189 2. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in 194 [RFC2119] when they appear in ALL CAPS. When these words are not in 195 ALL CAPS (such as "should" or "Should"), they have their usual 196 English meanings, and are not to be interpreted as [RFC2119] 197 keywords. 199 3. Terminology 201 Basic terms used in this specification are defined in the documents 202 [RFC1034], [RFC1035], [RFC7719] and [RFC7871]. 204 EIL: EDNS ISP Location. 206 ECS: EDNS Client Subnet, described in [RFC7871]. 208 Local Forwarding Resolver: Forwarding Resolver is described in 209 [RFC7871]. It is the first Forwarding Resolver which receives DNS 210 queries from Stub Resolver, usually deployed nearby the first-hop 211 router such as public Wi-Fi hotspot routers and home routers. 213 Recursive Resolver: described in [RFC7871]. It is the last-hop 214 before Authoritative Nameserver in the DNS query path. 216 Intermediate Nameserver: described in [RFC7871]. Any nameserver in 217 between the Stub Resolver and the Authoritative Nameserver, such as a 218 Recursive Resolver or a Forwarding Resolver. 220 Intermediate Forwarding Resolver: Any Forwarding Resolver in between 221 the Local Forwarding Resolver and Recursive Resolver. 223 Authoritative Nameserver: described in [RFC7719] and [RFC2182]. It 224 is a server that knows the content of a DNS zone from local 225 knowledge, and thus can answer queries about that zone without 226 needing to query other servers. 228 4. Overview 230 This document provides an EDNS0 option to allow Local Forwarding 231 Resolvers and Recursive Resolvers, if they are willing, to forward 232 details about the isp location of client when talking to other 233 nameservers. 235 The format of EIL option is described in Section 5. EIL can be added 236 in queries sent by Local Forwarding Resolvers or Recursive Resolvers 237 in a way that is transparent to Stub Resolvers and end users. EIL is 238 only defined for the Internet (IN) DNS class. 240 Like ECS, Authoritative Nameservers could provide a better answer by 241 using precise isp location in EIL. Intermediate Nameservers could 242 send EIL query and cache the EIL response. This document also 243 provides a mechanism to signal Intermediate Nameservers that they do 244 not want EIL treatment for specific queries. 246 The security concerns for EIL are like ECS, such as cache growth, 247 spoof EDNS0 option and privacy, etc. Mitigation techniques are 248 discussed in Section 6. 250 5. The EIL EDNS0 option 252 The EIL is an EDNS0 option to include the isp location of client in 253 DNS messages. 255 It is 14 octets which is structured as follows: 257 +0 (MSB) +1 (LSB) 258 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 259 0: | OPTION-CODE | 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 2: | OPTION-LENGTH | 262 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 263 4: | COUNTRY-CODE | 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 6: | AREA-CODE | 266 | | 267 | | 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 12: | ISP | 270 | | 271 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 273 Total: 14 octets. 275 o OPTION-CODE, 2 octets, defined in [RFC6891]. EDNS option code 276 should be assigned by the IANA. 278 o OPTION-LENGTH, 2 octets, defined in [RFC6891], contains the length 279 of the payload (everything after OPTION-LENGTH) in octets. 281 o COUNTRY-CODE, 2 octets, uppercase, defined in [ISO3166], indicates 282 the country information of the client's IP. For example, China's 283 COUNTRY-CODE is CN. 285 o AREA-CODE, 6 octets, uppercase, defined in [ISO3166] country 286 subdivision code, indicates the area information of the client's 287 IP. For example, The AREA-CODE of Fujian Province in China is 35. 289 o ISP, 4 octets, uppercase, indicates the ISP information of the 290 client's IP, using shortcut names. ISP shortcut names are unique 291 within the context of the COUNTRY-CODE. For example, the shortcut 292 name of China Telecommunications Corporation is TEL, the shortcut 293 name of China United Network Communications is UNI, the shortcut 294 name of China Mobile is MOB, etc. 296 All fields are in network byte order ("big-endian", per [RFC1700], 297 Data Notation). 299 The aim to use short names in the fields is to limit the data size of 300 EIL, decrease the DDoS risk. 302 The null value 0x20 signifies that the field is unknown. If all 303 fields in EIL are set to null value, it means that client doesn't 304 want to use EIL. 306 Authoritative Nameservers can send EIL response with the * value 0x2A 307 in AREA-CODE field or ISP field (not COUNTRY-CODE field), which 308 signifies that the field is wildcard match. For example, < CN, *, 309 TEL > indicates: all area in China, Telecom ISP. 311 Example code is in Github at: https://github.com/abbypan/dns_test_eil 312 . 314 6. Protocol Description 316 6.1. Originating the Option 318 The EIL can be initialized by Public Recursive Resolver, ISP 319 Recursive Resolver, or Local Forwarding Resolver. 321 6.1.1. P-Model: Public Recursive Resolver 323 Public Recursive Resolvers are not close to many users because the 324 service providers couldn't deploy servers in every country and every 325 ISP's network, which will affect the response accuracy of 326 Authoritative Nameservers. To encounter this problem, ECS shifts the 327 client subnet information to Authoritative Nameserver, but rises user 328 privacy concerns. 330 Therefore, to keep balance between precise and privacy, when a Public 331 Recursive Resolver receives a DNS query, it can guess isp location of 332 client's IP and generate the EIL OPT data, then send EIL query to the 333 Authoritative Nameserver. This will move the "guess location of 334 client's IP" work from Authoritative Nameserver back to Public 335 Recursive Resolver, lighten the burden of Authoritative Nameserver, 336 but increase DDoS risk on Public Recursive Resolver. 338 In order to improve the user's privacy, if a Recursive Resolver 339 receives a DNS query with ECS, it can guess the isp location of 340 SOURCE-PREFIX from the ECS OPT data, and make a new DNS query with 341 EIL, then send the query to Authoritative Nameserver which supports 342 EIL. 344 P-model is the most recommended and close to the ECS. 346 6.1.2. I-Model: ISP Recursive Resolver 348 ISP Recursive Resolver only serves its customers, each of whom has a 349 static isp location. ISP Recursive Resolver can add EIL transparent 350 to end user, and then Authoritative Nameserver doesn't need to "guess 351 location of client's IP". 353 EIL will be benefit if the Authoritative Nameserver could not find 354 the approximate isp location of ISP Recursive Resolver, which is 355 crucial to DNS response accuracy in ECS. 357 6.1.3. L-Model: Local Forwarding Resolver 359 Local Forwarding Resolver is usually on the first-hop router, such as 360 public Wi-Fi hotspot routers and Cisco/Linksys/Netgear/TP-LINK home 361 routers. 363 When a Local Forwarding Resolver that implements EIL receives a DNS 364 query from an end user, it surely can know about the isp location of 365 client's IP, and generate the EIL OPT data, then send the EIL query 366 to the intermediate Recursive Resolver. Intermediate Recursive 367 Resolver sends the EIL query to the Authoritative Nameserver. 369 In this scenario, both Public Recursive Resolver and Authoritative 370 Nameserver don't need to "guess location of client's IP", because the 371 Local Forwarding Resolver supplies the isp location precisely. That 372 is, EIL can reduce dependence on the IP geolocation database quality, 373 which is crucial to DNS response accuracy in ECS. 375 If a Local Forwarding Resolver had sent a query with EIL, and 376 receives a REFUSE response, it MUST regenerate a query with no EIL. 378 6.2. Generating a Response 380 6.2.1. Whitelist 382 EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which 383 can be discussed or maintained by the DNSOP working group. 384 Authoritative Nameservers that supporting EIL must only response the 385 EIL queries matched the whitelist. Recursive Resolver that 386 supporting EIL must only cache the EIL responses matched the 387 whitelist. 389 6.2.2. Authoritative Nameserver 391 Using the isp location specified in the EIL option of DNS query, an 392 Authoritative Nameserver can generate a tailored response. 394 Authoritative Nameservers that have not implemented or enabled 395 support for the EIL ought to safely ignore it within incoming 396 queries, response the query as a normal case without EDNS0 option. 397 Such a server MUST NOT include an EIL option within replies to 398 indicate lack of support for it. 400 An Authoritative Nameserver that has implemented this protocol and 401 receives an EIL option MUST include an EIL option in its response to 402 indicate that it SHOULD be cached accordingly. 404 An Authoritative Nameserver will return a more appropriate tailored 405 response for the query with an EIL option containing more precisely 406 AREA-CODE. 408 6.2.3. Intermediate Nameserver 410 Like ECS, Intermediate Nameserver passes a DNS response with an EIL 411 option to its client when the client indicates support EIL. 413 If an Intermediate Nameserver receives a response that has a larger 414 area than the AREA-CODE provided in its query, it SHOULD still 415 provide the result as the answer to the triggering client request 416 even if the client is in a smaller area. 418 6.3. Handling EIL Responses and Caching 420 If an Intermediate Nameserver had sent a query with EIL, and receives 421 a NOERROR response without EIL option, it SHOULD treat this answer as 422 suitable for all clients. 424 Other handling considerations are similar with ECS [RFC7871], SECTION 425 7.3. 427 6.3.1. Caching the Response 429 In the cache, all resource records in the Answer section MUST be tied 430 to the isp location specified in the response. The Answer section is 431 valid for all areas which the EIL option covered. For example, an 432 EIL option < CN, 35, TEL > covers all 9 Cities in Fujian Province of 433 China Telecommunications ISP. 435 Same with ECS, The Additional and Authority sections are excluded. 437 Enabling support for EIL in an Intermediate Nameserver will increase 438 the size of the cache, and prevent "client subnet leak" privacy 439 concern of ECS. 441 6.3.2. Answering from Cache 443 Cache lookups are first done as usual for a DNS query, using the 444 query tuple of < name, type, class >. Then, the appropriate RRset 445 MUST be chosen based on the isp location matching. 447 If there was an EIL option, the Intermediate Nameserver will lookup 448 for < same COUNTRY-CODE, same ISP, same AREA-CODE > of the same query 449 tuple in the cache. Otherwise, try to find < same COUNTRY-CODE, same 450 ISP, same AREA-CODE > of the same query tuple in the cache. 452 If no EIL option was provided, the safest choice of the Intermediate 453 Nameserver is dealing the query as a normal case without EDNS0 454 option. 456 If no EIL option was provided, but the Intermediate Nameserver want 457 to be more aggressive, it can guess the isp location from the source 458 IP of the query, then respond as if there was an EIL option with the 459 guessed information. Users can be benefit when the Intermediate 460 Nameserver has a more precise IP location database than the 461 Authoritative Nameserver, especially in global public DNS service 462 like GoogleDNS(8.8.8.8). 464 If no matching is found, the Intermediate Nameserver MUST perform 465 resolution as usual. 467 6.3.3. Support ECS and EIL at the same time 469 Name servers can support ECS and EIL at the same time. ECS and EIL 470 can't be both initiated at the same DNS packet. It is better for 471 user privacy if name servers initiate the EIL query prior to the ECS 472 query. 474 If Authoritative Nameservers support both ECS and EIL, Recursive 475 resolvers can cache both ECS response and EIL response, there are 476 some choices for Recursive Resolvers when they receive DNS queries. 478 Receive EIL query: 479 Search in EIL cache. 480 If cache is matched, return EIL response. 481 Otherwise, send EIL query to Authoritative Nameserver. 483 Receive ECS query: 484 Search in ECS cache. 485 If cache is matched, return ECS response. 486 Otherwise, send ECS query to Authoritative Nameserver. 488 Receive DNS query without EDNS option: 489 Search in ECS cache. 490 If cache is matched, return ECS response. 491 Otherwise, 492 Guess the isp location information of the client's IP, 493 build EIL option for the query packet. 494 Search in EIL cache. 495 If cache is matched, return EIL response. 496 Otherwise, send EIL query to Authoritative Nameserver. 498 Receive DNS query with not-ECS/not-EIL option: 499 Search in not-EDNS cache. 500 If cache is matched, return response. 501 Otherwise, send the DNS query to Authoritative Nameserver. 503 Receive ECS query, improve user privacy: 504 Guess the isp location information of the client's IP, 505 build EIL option for the query packet. 506 Search in EIL cache. 507 If cache is matched, return EIL response RR with origin ECS option. 508 Otherwise, send EIL query to Authoritative Nameserver. 510 6.4. Delegations and Negative Answers 512 EIL's delegation case is similar with ECS, Additional and Authority 513 Sections SHOULD ignore EIL. 515 For negative answers, Authoritative Nameservers return traditional 516 negative answers without EIL. 518 6.5. Transitivity 520 EIL's transitivity concerns are similar with ECS. 522 Name servers should only enable EIL where it is expected to benefit 523 the end users, such as dealing with some latency-sensitive CDN domain 524 queries in a complex network environment. 526 6.6. Response Accuracy 528 Authoritative Nameservers that support ECS-enabled GeoIP feature can 529 support EIL smoothly. 531 Compared to ECS, EIL can reduce dependence on the IP geolocation 532 database quality. EIL will rise the response accuracy of 533 Authoritative Nameserver if its database can not find approximate isp 534 location of ECS client subnet, ensure user latency. EIL will help 535 Authoritative Nameservers to avoid cross-isp visit if its database 536 can not find approximate isp location of ECS client subnet, save IP 537 transit cost. 539 7. Security Considerations 541 7.1. DNSSEC 543 EIL is not signed. 545 7.2. Privacy 547 As mentioned in [RFC7871]'s abstract section, since ECS has some 548 known operational and privacy shortcomings, a revision will be worked 549 through the IETF for improvement. The biggest privacy concern on ECS 550 is that client subnet information is personally identifiable. The 551 more domains publish their zones on a third-party Authoritative 552 Nameserver, the more end user privacy information can be gathered by 553 the Authoritative Nameserver according to the ECS queries. 555 EIL is to improve user privacy which is inspired by ECS, prevented 556 leaks in the client subnet information. 558 Like ECS, EIL will leak the global zonefile configurations of the 559 Authoritative Nameservers more easily than normal case. 561 7.3. Target Censorship 563 DNS traffic is plain text by default. It is easily to be blocked or 564 poisoned by internet target censorship. To bypass the censorship, it 565 is better to encrypt the DNS traffic or use some proxy tunnel. 567 EIL's isp location information covers bigger area than ECS's client 568 subnet information. Therefore, compared to ECS in plain text 569 condition, EIL is weaker at blocking record attack, but stronger at 570 targeted DNS poisoning attack. 572 7.4. Cache Size 574 Like ECS, cache size will raise if a Public Recursive Resolver 575 supports EIL. The cache size of ECS grows up with the number of 576 client subnets. The cache size of EIL is related to the row count in 577 the < COUNTRY-CODE, AREA-CODE, ISP > isp location whitelist. 578 Therefore, under IPv6 environment, the cache size of EIL will be 579 smaller than ECS. 581 7.5. DDoS 583 To migrate the DDoS problem: 585 o If an Authority Server receives a DNS query with unknown data in 586 EIL option, it SHOULD return the default response whose EIL option 587 with null value. 589 o Nameservers OPTIONAL only implement EIL when the query is from a 590 TCP connection. 592 More migration techniques described in [RFC7871], Section 11.3. 594 8. IANA Considerations 596 This document defines EIL, need request IANA to assign a new EDNS0 597 option code to EIL. 599 9. Acknowledgements 601 EIL is inspired by ECS, the authors especially thanks to C. 602 Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari. 604 Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr 605 Špaček, Brian Hartvigsen, Ask Bjoern Hansen. 607 Thanks a lot to all in the DNSOP, DNSPRIV and DNSEXT mailing list. 609 10. Appendix A. Example 611 Authoritative Nameserver of www.example.com has enabled EIL. 613 Stub DNS query A resource record of www.example.com . 615 10.1. Example 1: P-Model 617 Stub DNS 618 -> Local Forwarding Resolver (61.48.7.2) 619 -> Public Forwarding Resolver(AliDNS, 223.5.5.5) 620 -> Public Recursive Resolver(AliDNS, 202.108.250.231) 621 -> Authoritative Nameserver 623 Public Forwarding Resolver 223.5.5.5 could enable EIL and generate 624 the EIL OPT data < CN, 11, UNI > based on 61.48.7.2. 626 P-Model will not leak client subnet to Authoritative Nameserver. 628 10.2. Example 2: I-Model 630 Stub DNS 631 -> Local Forwarding Resolver 632 -> ISP Forwarding Resolver(202.106.196.115) 633 -> ISP Recursive Resolver(61.135.23.92) 634 -> Authoritative Nameserver 636 ISP Recursive Resolver 61.135.23.92 could enable EIL and generate the 637 EIL OPT data < CN, 11, UNI > based on 61.135.23.92. 639 If Authoritative Nameserver doesn't know much about 61.135.23.92, EIL 640 will be helpful. 642 10.3. Example 3: L-Model 644 Stub DNS 645 -> Local Fowarding Resolver(58.60.109.234) 646 -> ... 647 -> Authoritative Nameserver 649 Local Fowarding Resolver 58.60.109.234 could enable EIL and generate 650 the option data is < CN, 44, TEL > based on 58.60.109.234. 652 L-Model can give the most precisely isp location information for DNS 653 resolution. 655 11. References 657 11.1. Normative References 659 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 660 RFC 1034, November 1987. 662 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 663 Specification", RFC 1035, November 1987. 665 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 666 October 1994. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", RFC 2119, March 1997. 671 [RFC2182] ELZ, R., Bush, R., Bradner, S., and M. Patton, "Selection 672 and Operation of Secondary DNS Servers", RFC 2182, July 673 1997. 675 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 676 for DNS (EDNS(0))", RFC 6891, April 2013. 678 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 679 Terminology", RFC 7719, December 2015. 681 [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W. 682 Kumari, "Client Subnet in DNS Queries", RFC 7871, May 683 2016. 685 11.2. Informative References 687 [Amazon-Geolocation-Routing] 688 Amazon, "Amazon Route 53: Geolocation Routing", 689 . 692 [BIND-GeoIP] 693 ISC BIND, "Using the GeoIP Features in BIND 9.10", 694 . 696 [DYN-Traffic-Director-ECS] 697 DYN, "What happens when a DNS query for a Traffic Director 698 instance is received with ECS information", 699 . 701 [gdnsd-GeoIP] 702 gdnsd, "GdnsdPluginGeoip", 703 . 705 [ISO3166] ISO 3166, "Country Codes", 706 . 708 [PowerDNS-GeoIP] 709 PowerDNS, "PowerDNS GeoIP backend", 710 . 713 Authors' Addresses 715 Lanlan Pan 716 Beijing 717 CN 719 Email: abbypan@gmail.com 720 URI: https://github.com/abbypan 722 Yu Fu 723 CNNIC 724 No.4 South 4th Street, Zhongguancun 725 Beijing 726 CN 728 Email: fuyu@cnnic.cn