idnits 2.17.1 draft-pan-dnsop-edns-isp-location-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 59 lines 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 (March 13, 2017) is 2572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop L. Pan 3 Internet-Draft Y. Fu 4 Intended status: Informational CNNIC 5 Expires: September 14, 2017 March 13, 2017 7 ISP Location in DNS Queries 8 draft-pan-dnsop-edns-isp-location-00 10 Abstract 12 This document describes an Extension Mechanisms for DNS (EDNS0) 13 option that is in active use to carry information about the network 14 that originated a DNS query and the network for which the subsequent 15 response can be cached. 17 It is inspired by EDNS Client Subnet (ECS) with some privacy 18 considerations, goals to reduce the "guess geolocation of client's 19 IP" work on Authoritative Nameservers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 4 60 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 61 6.1. Originating the Option . . . . . . . . . . . . . . . . . 6 62 6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 6 63 6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 6 64 6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 6 65 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 7 66 6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 7 67 6.2.2. Authoritative Server . . . . . . . . . . . . . . . . 7 68 6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 7 69 6.3. Handling EIL Responses and Caching . . . . . . . . . . . 8 70 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 8 71 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 8 72 6.3.3. Support ECS and EIL at the same time . . . . . . . . 9 73 6.4. Delegations and Negative Answers . . . . . . . . . . . . 10 74 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 10 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 10 79 7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 As described in EDNS Client Subnet (ECS) [RFC7871], many 92 Authoritative Servers today return different responses based on the 93 perceived geolocation of the user. Traditionally, Authoritative 94 Server guesses the user's geolocation by the source IP address of dns 95 query. 97 ECS is an EDNS0 [RFC6891] option to carry client subnet information 98 in dns queries for Authoritative Server. Compared to source IP 99 address of dns query, ECS will help Authoritative Server to guess the 100 client's geolocation more precisely because of the DNS forwarding 101 query structure. However, ECS raises some privacy concerns because 102 it leaks client subnet information on the resolution path to the 103 Authoritative Server. 105 This document is an improved solution for ECS, describes an EDNS ISP 106 Location (EIL) extension to address the privacy problem of ECS, find 107 the right balance between privacy improvement and user experience 108 optimization. EIL is defined to convey ISP location information that 109 is relevant to the DNS message. It will provide sufficient 110 information for the Authoritative Server to decide the response 111 without guessing geolocation of the IP address. 113 EIL is intended for those Local Forwarding Resolvers, Recursive 114 Resolvers and Authoritative Servers that would benefit from the 115 extension and not for general purpose deployment like ECS scenario. 116 It could be applied for tailor dns response. EIL can safely be 117 ignored by servers that choose not to implement or enable it. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119] when they appear in ALL CAPS. When these words are not in 125 ALL CAPS (such as "should" or "Should"), they have their usual 126 English meanings, and are not to be interpreted as [RFC2119] key 127 words. 129 3. Terminology 131 Basic terms used in this specification are defined in the documents 132 [RFC1034], [RFC1035], [RFC7719] and [RFC7871]. 134 EIL: EDNS ISP Location. 136 ECS: EDNS Client Subnet, described in [RFC7871]. 138 Local Forwarding Resolver: Forwarding Resolver is described in 139 [RFC7871]. It is the first Forwarding Resolver which receives dns 140 queries from Stub Resolver, usually deployed nearby the first-hop 141 router such as public Wi-Fi hotspot routers and home routers. 143 Recursive Resolver: described in [RFC7871]. It is the last-hop 144 before Authoritative Server in the dns query path. 146 Intermediate Nameserver: described in [RFC7871]. Any nameserver in 147 between the Stub Resolver and the Authoritative Nameserver, such as a 148 Recursive Resolver or a Forwarding Resolver. 150 Authoritative Server: described in [RFC7719] and [RFC2182]. It is a 151 server that knows the content of a DNS zone from local knowledge, and 152 thus can answer queries about that zone without needing to query 153 other servers. 155 4. Overview 157 This document provides an EDNS0 option to allow Local Forwarding 158 Resolvers and Recursive Resolvers, if they are willing, to forward 159 details about the isp location of client when talking to other 160 nameservers. 162 The format of EIL option is described in Section 5. EIL can be added 163 in queries sent by Local Forwarding Resolvers or Recursive Resolvers 164 in a way that is transparent to Stub Resolvers and end users. EIL is 165 only defined for the Internet (IN) DNS class. 167 Like ECS, Authoritative Servers could provide a better answer by 168 using precise isp location in EIL. Intermediate Nameservers could 169 send EIL query and cache the EIL response. This document also 170 provides a mechanism to signal Intermediate Nameservers that they do 171 not want EIL treatment for specific queries. 173 The security concerns for EIL are like ECS, such as cache growth, 174 spoof EDNS0 option and privacy, etc. Mitigation techniques are 175 discussed in Section 6. 177 5. The EIL EDNS0 option 179 The EIL is an EDNS0 option to include the isp location of client in 180 DNS messages. 182 It is 14 octets which is structured as follows: 184 +0 (MSB) +1 (LSB) 185 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 186 0: | OPTION-CODE | 187 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 188 2: | OPTION-LENGTH | 189 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 190 4: | COUNTRY-CODE | 191 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 192 6: | AREA-CODE | 193 | | 194 | | 195 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 196 12: | ISP | 197 | | 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 200 Total: 14 octets. 202 o OPTION-CODE, 2 octets, defined in [RFC6891]. EDNS option code 203 should be assigned by the IANA. 205 o OPTION-LENGTH, 2 octets, defined in [RFC6891], contains the length 206 of the payload (everything after OPTION-LENGTH) in octets. 208 o COUNTRY-CODE, 2 octets, upppercase, defined in [ISO3166], 209 indicates the country information of the client's IP. For 210 example, China's COUNTRY-CODE is CN. 212 o AREA-CODE, 6 octets, uppercase, defined in [ISO3166] country 213 subdivision code, indicates the area information of the client's 214 IP. For example, The AREA-CODE of Fujian Province in China is 35. 216 o ISP, 4 octets, uppercase, indicates the ISP information of the 217 client's IP, using shortcut names. ISP shortcut names are unique 218 within the context of the COUNTRY-CODE. For example, the shortcut 219 name of China Telecommunications Corporation is TEL, the shortcut 220 name of China United Network Communications is UNI, the shortcut 221 name of China Mobile is MOB, etc. 223 EIL Structure 225 All fields are in network byte order ("big-endian", per [RFC1700], 226 Data Notation). 228 The aim to use short names in the fields is to limit the data size of 229 EIL, decrease the DDoS risk. The null value 0x20 signifies that the 230 field is unknown. If all fields in EIL are set to null value, it 231 means that client doesn't want to use EIL. 233 6. Protocol Description 235 6.1. Originating the Option 237 The EIL can be initialized by Public Recursive Resolver, ISP 238 Recursive Resolver, or Local Forwarding Resolver. 240 6.1.1. P-Model: Public Recursive Resolver 242 When a public Recursive Resolver receives a DNS query, it can guess 243 geolocation of client's IP and generate the EIL OPT data, then send 244 EIL query to the Authoritative Server. This will move the "guess 245 geolocation of client's IP" work from Authoritative Server to Public 246 Recursive Resolver, lighten the burden of Authoritative Server, but 247 increase DDoS risk on Public Recursive Resolver. 249 In order to improve the user's privacy, if a Recursive Resolver 250 receives a dns query with ECS, it can guess the isp location of 251 SOURCE-PREFIX from the ECS OPT data, and make a new dns query with 252 EIL, then send the query to Authoritative Server which supports EIL. 254 P-model is the most recommended and close to the ECS. 256 6.1.2. I-Model: ISP Recursive Resolver 258 ISP Recursive Resolver only serves its customers, each of whom has a 259 static geolocation. ISP Recursive Resolver can add EIL transparent 260 to end user, and then Authoritative Server doesn't need to "guess 261 geolocation of client's IP". 263 EIL will be benefit if the Authoritative Server could not find the 264 approximate geolocation of ISP Recursive Resolver, which is crucial 265 to DNS response accuracy in ECS. 267 6.1.3. L-Model: Local Forwarding Resolver 269 Local Forwarding Resolver is usually on the first-hop router, such as 270 public Wi-Fi hotspot routers and Cisco/Linksys/Netgear/TP-LINK home 271 routers. 273 When a Local Forwarding Resolver that implements EIL receives a DNS 274 query from an end user, it surely can know about the geolocation 275 information of client's IP, and generate the EIL OPT data, then send 276 the EIL query to the intermediate Recursive Resolver. Intermediate 277 Recursive Resolver sends the EIL query to the Authoritative Server. 279 In this scenario, both public Recursive Resolver and Authoritative 280 Server don't need to "guess geolocation of client's IP", because the 281 Local Forwarding Resolver supplies the geolocation precisely. That 282 is, EIL can reduce dependence on the IP geolocation database quality, 283 which is crucial to DNS response accuracy in ECS. 285 If a Local Fowarding Resolver had sent a query with EIL, and recieves 286 a REFUSE response, it MUST regenerate a query with no EIL. 288 6.2. Generating a Response 290 6.2.1. Whitelist 292 EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which 293 can be discussed or maintained by the DNSOP working group. 294 Authoritative Servers that supporting EIL must only response the EIL 295 queries matched the whitelist. Recursive Resolver that supporting 296 EIL must only cache the EIL responses matched the whitelist. 298 6.2.2. Authoritative Server 300 Using the isp location specified in the EIL option of dns query, an 301 Authoritative Server can generate a tailored response. 303 Authoritative Servers that have not implemented or enabled support 304 for the EIL ought to safely ignore it within incoming queries, 305 response the query as a normal case without EDNS0 option. Such a 306 server MUST NOT include an EIL option within replies to indicate lack 307 of support for it. 309 An Authoritative Server that has implemented this protocol and 310 receives an EIL option MUST include an EIL option in its response to 311 indicate that it SHOULD be cached accordingly. 313 An Authoritative Server will return a more appropriate tailored 314 response for the query with an EIL option containing more pricisely 315 AREA-CODE. 317 6.2.3. Intermediate Nameserver 319 Like ECS, Intermediate Nameserver passes a dns response with an EIL 320 option to its client when the client indicates support EIL. 322 If an Intermediate Nameserver receives a response that has a larger 323 area than the AREA-CODE provided in its query, it SHOULD still 324 provide the result as the answer to the triggering client request 325 even if the client is in a smaller area. 327 6.3. Handling EIL Responses and Caching 329 If an Intermediate Nameserver had sent a query with EIL, and receives 330 a NOERROR response without EIL option, it SHOULD treat this answer as 331 suitable for all clients. 333 Other handling considerations are similar with ECS, SECTION 7.3. 335 6.3.1. Caching the Response 337 In the cache, all resource records in the Answer section MUST be tied 338 to the isp location specified in the response. The Answer seciton is 339 valid for all areas which the EIL option covered. For example, an 340 EIL option { "COUNTRY-CODE": "CN", "AREA-CODE": "35", "ISP": "TEL" } 341 covers all 9 Cities in FuJian Province of China Telecommunications 342 ISP. 344 Same with ECS, The Additional and Authority sections are excluded. 346 Enabling support for EIL in an Intermediate Nameserver will increase 347 the size of the cache, and prevent "client subnet leak" privacy 348 concern of ECS. 350 6.3.2. Answering from Cache 352 Cache lookups are first done as usual for a DNS query, using the 353 query tuple of < name, type, class >. Then, the appropriate RRset 354 MUST be chosen based on the isp location matching. 356 If there was an EIL option, the Intermediate Nameserver will lookup 357 for < same COUNTRY-CODE, same ISP, same AREA-CODE > of the same query 358 tuple in the cache. Otherwise, try to find < same COUNTRY-CODE, same 359 ISP, same AREA-CODE > of the same query tuple in the cache. 361 If no EIL option was provided, the safest choice of the Intermediate 362 Nameserver is dealing the query as a normal case without EDNS0 363 option. 365 If no EIL option was provided, but the Intermediate Nameserver want 366 to be more aggressive, it can guess the isp location from the souce 367 IP of the query, then respond as if there was an EIL option with the 368 guessed information. Users can be benefit when the Intermediate 369 Nameserver has a more precise IP location database than the 370 Authoritative Server, especially in global public DNS service like 371 GoogleDNS(8.8.8.8). 373 If no matching is found, the Intermediate Nameserver MUST perform 374 resolution as usual. 376 6.3.3. Support ECS and EIL at the same time 378 Name servers can support ECS and EIL at the same time. ECS and EIL 379 can't be both initiated at the same dns packet. It is better for 380 user privacy if name servers initiate the EIL query prior to the ECS 381 query. 383 If Authoritative servers support both ECS and EIL, Recursive 384 resolvers can cache both ECS response and EIL response, there are 385 some choices for Recursive Resolvers when they receive dns queries. 387 Receive EIL query: 388 Search in EIL cache. 389 If cache is matched, return EIL response. 390 Otherwise, send EIL query to Authoritative Server. 392 Receive ECS query: 393 Search in ECS cache. 394 If cache is matched, return ECS response. 395 Otherwise, send ECS query to Authoritative Server. 397 Receive DNS query without EDNS option: 398 Search in ECS cache. 399 If cache is matched, return ECS response. 400 Otherwise, 401 Guess the geolocation information of the client's IP, 402 build EIL option for the query packet. 403 Search in EIL cache. 404 If cache is matched, return EIL response. 405 Otherwise, send EIL query to Authoritative Server. 407 Receive DNS query with not-ECS/not-EIL option: 408 Search in not-EDNS cache. 409 If cache is matched, return response. 410 Otherwise, send the DNS query to Authoritative Server. 412 Receive ECS query, improve user privacy: 413 Guess the geolocation information of the client's IP, 414 build EIL option for the query packet. 415 Search in EIL cache. 416 If cache is matched, return EIL response RR with origin ECS option. 417 Otherwise, send EIL query to Authoritative Server. 419 6.4. Delegations and Negative Answers 421 EIL's delegation case is similar with ECS, Additional and Authority 422 Sections SHOULD ignore EIL. 424 For negative answers, Authoritative Servers return traditional 425 negative answers without EIL. 427 6.5. Transitivity 429 EIL's transitivity concerns are similar with ECS. 431 Name servers should only enable EIL where it is expected to benefit 432 the end users, such as dealing with some latency-sensitive CDN domain 433 queries in a complex network environment. 435 7. Security Considerations 437 7.1. DNSSEC 439 EIL is not signed. 441 7.2. Privacy 443 The biggest privacy concern on ECS is that client subnet information 444 is personally identifiable. The more domains publish their zones on 445 a third-party Authoritative Server, the more end user privacy 446 information can be gathered by the Authoritative Server according to 447 the ECS queries. 449 EIL is to improve user privacy which is inspired by ECS, prevented 450 leaks in the client subnet information. 452 Like ECS, EIL will leak the global zonefile configurations of the 453 Authoritative Servers more easily than normal case. 455 7.3. Target Censorship 457 DNS traffic is plain text by default. It is easily to be blocked or 458 poisoned by internet target censorship. To bypass the censorship, it 459 is better to encrypt the dns traffic or use some proxy tunnel. 461 EIL's geolocation information covers bigger area than ECS's client 462 subnet information. Therefore, compared to ECS in plain text 463 condition, EIL is weaker at blocking record attack, but stronger at 464 targeted DNS poisoning attack. 466 7.4. Cache Size 468 Like ECS, cache size will raise if a public recursive resolver 469 supports EIL. The cache size of ECS grows up with the number of 470 client subnets. The cache size of EIL is related to the row count in 471 the < COUNTRY-CODE, AREA-CODE, ISP > geolocation whitelist. 472 Therefore, under IPv6 environment, the cache size of EIL will be 473 smaller than ECS. 475 7.5. DDoS 477 To migrate the DDoS problem: 479 o If an Authority Server receives a dns query with unknown data in 480 EIL option, it SHOULD return the default response whose EIL option 481 with null value. 483 o Nameservers OPTIONAL only implement EIL when the query is from a 484 TCP connection. 486 More migration techniques described in [RFC7871], Section 11.3. 488 8. IANA Considerations 490 This document defines EIL, need request IANA to assign a new EDNS0 491 option code to EIL. 493 9. Acknowledgements 495 EIL is inspired by ECS, the authors especially thanks to C. 496 Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari. 498 Thanks a lot to all in the DNSOP and DNSEXT mailing list. 500 This document was produced using the xml2rfc tool [RFC2629]. 502 10. References 504 10.1. Normative References 506 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 507 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 508 . 510 [RFC1035] Mockapetris, P., "Domain names - implementation and 511 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 512 November 1987, . 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 520 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 521 DOI 10.17487/RFC2182, July 1997, 522 . 524 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 525 for DNS (EDNS(0))", STD 75, RFC 6891, 526 DOI 10.17487/RFC6891, April 2013, 527 . 529 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 530 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 531 2015, . 533 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 534 Kumari, "Client Subnet in DNS Queries", RFC 7871, 535 DOI 10.17487/RFC7871, May 2016, 536 . 538 10.2. Informative References 540 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 541 DOI 10.17487/RFC1700, October 1994, 542 . 544 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 545 DOI 10.17487/RFC2629, June 1999, 546 . 548 [ISO3166] ISO 3166, "Country Codes", 549 . 551 Appendix A. Example 553 Authoritative Server of www.example.com has enabled EIL. 555 Stub DNS query A resource record of www.example.com. 557 Example 1: P-Model 559 Resolution Path: Stub DNS -> Local Forwarding Resolver (61.48.7.2) -> 560 Public Forwarding Resolver(AliDNS, 223.5.5.5) -> Public Recursive 561 Resolver(AliDNS, 202.108.250.231) -> Authoritative Server 562 Public Forwarding Resolver 223.5.5.5 could enable EIL and generate 563 the EIL OPT data { "COUNTRY-CODE": "CN", "AREA-CODE": "11", "ISP": 564 "UNI" } based on 61.48.7.2. 566 P-Model will not leak client subnet to Authoritative Server. 568 Example 2: I-Model 570 Resolution Path: Stub DNS -> Local Forwarding Resolver -> ISP 571 Forwarding Resolver(202.106.196.115) -> ISP Recursive 572 Resolver(61.135.23.92) -> Authoritative Server 574 ISP Recursive Resolver 61.135.23.92 could enable EIL and generate the 575 EIL OPT data { "COUNTRY-CODE": "CN", "AREA-CODE": "11", "ISP": "UNI" 576 } based on 61.135.23.92. 578 If Authoritative Server doesn't know much about 61.135.23.92, EIL 579 will be helpful. 581 Example 3: L-Model 583 Resolution Path: Stub DNS -> Local Fowarding Resolver(58.60.109.234) 584 -> ... -> Authoritative Server 586 Local Fowarding Resolver 58.60.109.234 could enable EIL and generate 587 the option data is { "COUNTRY-CODE": "CN", "AREA-CODE": "44", "ISP": 588 "TEL" } based on 58.60.109.234. 590 L-Model can give the most precisely isp location information for dns 591 resolution. 593 Authors' Addresses 595 Lanlan Pan 596 CNNIC 597 No.4 South 4th Street, Zhongguancun 598 Hai-Dian District, Beijing, 100190 599 P.R. China 601 Email: abbypan@gmail.com 602 Yu Fu 603 CNNIC 604 No.4 South 4th Street, Zhongguancun 605 Hai-Dian District, Beijing, 100190 606 P.R. China 608 Email: fuyu@cnnic.cn