dnsop L. Pan Internet-Draft Intended status: Informational Y. Fu Expires: November 12, 2017 CNNIC May 11, 2017 ISP Location in DNS Queries draft-pan-dnsop-edns-isp-location-01 Abstract This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry < COUNTRY, AREA, ISP > isp location information about the network that originated a DNS query and the network for which the subsequent response can be cached. It is inspired by EDNS Client Subnet (ECS) with some privacy considerations, goals to reduce the "guess location of client's IP" work on Authoritative Nameservers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 12, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Pan & Fu Expires November 12, 2017 [Page 1] Internet-Draft ISP Location in DNS Queries May 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Path Calculation and Tailored DNS Response . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 7 6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8 6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 8 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 9 6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 9 6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 9 6.3. Handling EIL Responses and Caching . . . . . . . . . . . 9 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 10 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 10 6.3.3. Support ECS and EIL at the same time . . . . . . . . 10 6.4. Delegations and Negative Answers . . . . . . . . . . . . 11 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 12 6.6. Response Accuracy . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 12 7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 13 7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Appendix A. Example . . . . . . . . . . . . . . . . . . . . . 13 10.1. Example 1: P-Model . . . . . . . . . . . . . . . . . . . 14 10.2. Example 2: I-Model . . . . . . . . . . . . . . . . . . . 14 10.3. Example 3: L-Model . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Pan & Fu Expires November 12, 2017 [Page 2] Internet-Draft ISP Location in DNS Queries May 2017 1. Introduction As described in EDNS Client Subnet (ECS) [RFC7871], many Authoritative Nameservers today return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location. ECS is an EDNS0 [RFC6891] option to carry client subnet information in DNS queries for Authoritative Nameserver. Compared to source IP address of DNS query, ECS will help Authoritative Nameserver to guess the client's location more precisely because of the DNS forwarding query structure. However, ECS raises some privacy concerns because it leaks client subnet information on the resolution path to the Authoritative Nameserver. Meanwhile, many Authoritative Nameservers support GeoIP feature, for example, BIND-GeoIP [BIND-GeoIP], PowerDNS-GeoIP [PowerDNS-GeoIP], Amazon-Geolocation-Routing [Amazon-Geolocation-Routing], DYN-Traffic- Director-ECS [DYN-Traffic-Director-ECS], gdnsd-GeoIP [gdnsd-GeoIP], etc. These geographically aware Authoritative Nameservers guess the user's geolocation by the client subnet of ECS or by the source IP address of DNS query, return tailor DNS response based on the user's geolocation. To sum up, these Authoritative Nameservers use ECS client subnet information for GeoIP feature's user geolocation detecting. This document is an improved solution for ECS-enabled GeoIP feature of Authoritative Nameserver, describes an EDNS ISP Location (EIL) extension to address the privacy problem of ECS, find the right balance between privacy improvement and user experience optimization. EIL is defined to convey isp location < COUNTRY, AREA, ISP > information that is relevant to the DNS message. It will directly provide the same sufficient information for the GeoIP-based Authoritative Nameserver that enabling ECS, to decide the response without guessing geolocation of the IP address. EIL is intended for those Local Forwarding Resolvers, Recursive Resolvers and Authoritative Nameservers that would benefit from the extension and not for general purpose deployment like ECS scenario. It could be applied for tailor DNS response. EIL can safely be ignored by servers that choose not to implement or enable it. 1.1. Path Calculation and Tailored DNS Response Separate the consideration of path calculation (Data Provider) and tailored DNS response (Authoritative Nameserver). Pan & Fu Expires November 12, 2017 [Page 3] Internet-Draft ISP Location in DNS Queries May 2017 Data Providers make path calculations to optimize content delivery on the Internet based on the network topology, considering many factors such as IP, RIPs, FIBs, AS Path hops, system load, content availability, path latency, etc. Note that, Data Providers have the full details of the clients, they can make any complex path calculations without ECS and EIL. Authoritative Nameservers configure tailored DNS response based on the result of path calculations, allocate IP addresses to different datacenters. Usually, users from the same < COUNTRY, AREA, ISP > isp location are allocated to the same datacenter, the same best "network topologically close" datacenter. For example, client IP addresses from < China, Beijing, Telecom > are allocated to DataCenter-1, client IP addresses from < China, Beijing, Unicom > are allocated to DataCenter-2, etc. Above is the GeoIP-based Tailored DNS Response. Therefore, if the GeoIP-based Authoritative Nameservers enable ECS, they can use the client subnet information of ECS instead of resolver's address for GeoIP detecting. Moreover, the GeoIP-based Authoritative Nameservers can directly use the < COUNTRY, AREA, ISP > information of EIL without GeoIP detecting. Again, we emphasize that tailored DNS response does not affect path calculation. Data Providers can make path calculations based on network topology, decide network topological close datacenter for each IP address. Authoritative Nameservers allocate tailored DNS response to each IP address based on the "network topological close" result of path calculations. EIL tell Authoritative Nameserver like that, "I want to know what is best IP address for clients from < China, Beijing, Telecom > at network topology path calculations result", but not "I want to know what is the nearest IP address for clients from < China, Beijing, Telecom > at physical topology path calculations result". EIL is satisfied if Authoritative Nameservers aggregate the IP addresses from the same < COUNTRY, AREA, ISP > isp location to visit the same datacenters, we call that GeoIP-based tailored DNS responses, and these tailored responses have "network topological close" distance to the users. ECS is satisfied if Authoritative Nameservers make tailored DNS response down to subnet precise level. For example, (subnet-1, ..., subnet-100) are from the same < COUNTRY, AREA, ISP > isp location, Data Provider applies (subnet-1, ..., subnet-50) visit DataCenter-1, (subnet-51, ..., subnet-100) visit DataCenter-2. Pan & Fu Expires November 12, 2017 [Page 4] Internet-Draft ISP Location in DNS Queries May 2017 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] keywords. 3. Terminology Basic terms used in this specification are defined in the documents [RFC1034], [RFC1035], [RFC7719] and [RFC7871]. EIL: EDNS ISP Location. ECS: EDNS Client Subnet, described in [RFC7871]. Local Forwarding Resolver: Forwarding Resolver is described in [RFC7871]. It is the first Forwarding Resolver which receives DNS queries from Stub Resolver, usually deployed nearby the first-hop router such as public Wi-Fi hotspot routers and home routers. Recursive Resolver: described in [RFC7871]. It is the last-hop before Authoritative Nameserver in the DNS query path. Intermediate Nameserver: described in [RFC7871]. Any nameserver in between the Stub Resolver and the Authoritative Nameserver, such as a Recursive Resolver or a Forwarding Resolver. Intermediate Forwarding Resolver: Any Forwarding Resolver in between the Local Forwarding Resolver and Recursive Resolver. Authoritative Nameserver: described in [RFC7719] and [RFC2182]. It is a server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers. 4. Overview This document provides an EDNS0 option to allow Local Forwarding Resolvers and Recursive Resolvers, if they are willing, to forward details about the isp location of client when talking to other nameservers. The format of EIL option is described in Section 5. EIL can be added in queries sent by Local Forwarding Resolvers or Recursive Resolvers Pan & Fu Expires November 12, 2017 [Page 5] Internet-Draft ISP Location in DNS Queries May 2017 in a way that is transparent to Stub Resolvers and end users. EIL is only defined for the Internet (IN) DNS class. Like ECS, Authoritative Nameservers could provide a better answer by using precise isp location in EIL. Intermediate Nameservers could send EIL query and cache the EIL response. This document also provides a mechanism to signal Intermediate Nameservers that they do not want EIL treatment for specific queries. The security concerns for EIL are like ECS, such as cache growth, spoof EDNS0 option and privacy, etc. Mitigation techniques are discussed in Section 6. 5. The EIL EDNS0 option The EIL is an EDNS0 option to include the isp location of client in DNS messages. It is 14 octets which is structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | OPTION-CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | OPTION-LENGTH | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: | COUNTRY-CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 6: | AREA-CODE | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 12: | ISP | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Total: 14 octets. o OPTION-CODE, 2 octets, defined in [RFC6891]. EDNS option code should be assigned by the IANA. o OPTION-LENGTH, 2 octets, defined in [RFC6891], contains the length of the payload (everything after OPTION-LENGTH) in octets. o COUNTRY-CODE, 2 octets, uppercase, defined in [ISO3166], indicates the country information of the client's IP. For example, China's COUNTRY-CODE is CN. Pan & Fu Expires November 12, 2017 [Page 6] Internet-Draft ISP Location in DNS Queries May 2017 o AREA-CODE, 6 octets, uppercase, defined in [ISO3166] country subdivision code, indicates the area information of the client's IP. For example, The AREA-CODE of Fujian Province in China is 35. o ISP, 4 octets, uppercase, indicates the ISP information of the client's IP, using shortcut names. ISP shortcut names are unique within the context of the COUNTRY-CODE. For example, the shortcut name of China Telecommunications Corporation is TEL, the shortcut name of China United Network Communications is UNI, the shortcut name of China Mobile is MOB, etc. All fields are in network byte order ("big-endian", per [RFC1700], Data Notation). The aim to use short names in the fields is to limit the data size of EIL, decrease the DDoS risk. The null value 0x20 signifies that the field is unknown. If all fields in EIL are set to null value, it means that client doesn't want to use EIL. Authoritative Nameservers can send EIL response with the * value 0x2A in AREA-CODE field or ISP field (not COUNTRY-CODE field), which signifies that the field is wildcard match. For example, < CN, *, TEL > indicates: all area in China, Telecom ISP. Example code is in Github at: https://github.com/abbypan/dns_test_eil . 6. Protocol Description 6.1. Originating the Option The EIL can be initialized by Public Recursive Resolver, ISP Recursive Resolver, or Local Forwarding Resolver. 6.1.1. P-Model: Public Recursive Resolver Public Recursive Resolvers are not close to many users because the service providers couldn't deploy servers in every country and every ISP's network, which will affect the response accuracy of Authoritative Nameservers. To encounter this problem, ECS shifts the client subnet information to Authoritative Nameserver, but rises user privacy concerns. Therefore, to keep balance between precise and privacy, when a Public Recursive Resolver receives a DNS query, it can guess isp location of client's IP and generate the EIL OPT data, then send EIL query to the Pan & Fu Expires November 12, 2017 [Page 7] Internet-Draft ISP Location in DNS Queries May 2017 Authoritative Nameserver. This will move the "guess location of client's IP" work from Authoritative Nameserver back to Public Recursive Resolver, lighten the burden of Authoritative Nameserver, but increase DDoS risk on Public Recursive Resolver. In order to improve the user's privacy, if a Recursive Resolver receives a DNS query with ECS, it can guess the isp location of SOURCE-PREFIX from the ECS OPT data, and make a new DNS query with EIL, then send the query to Authoritative Nameserver which supports EIL. P-model is the most recommended and close to the ECS. 6.1.2. I-Model: ISP Recursive Resolver ISP Recursive Resolver only serves its customers, each of whom has a static isp location. ISP Recursive Resolver can add EIL transparent to end user, and then Authoritative Nameserver doesn't need to "guess location of client's IP". EIL will be benefit if the Authoritative Nameserver could not find the approximate isp location of ISP Recursive Resolver, which is crucial to DNS response accuracy in ECS. 6.1.3. L-Model: Local Forwarding Resolver Local Forwarding Resolver is usually on the first-hop router, such as public Wi-Fi hotspot routers and Cisco/Linksys/Netgear/TP-LINK home routers. When a Local Forwarding Resolver that implements EIL receives a DNS query from an end user, it surely can know about the isp location of client's IP, and generate the EIL OPT data, then send the EIL query to the intermediate Recursive Resolver. Intermediate Recursive Resolver sends the EIL query to the Authoritative Nameserver. In this scenario, both Public Recursive Resolver and Authoritative Nameserver don't need to "guess location of client's IP", because the Local Forwarding Resolver supplies the isp location precisely. That is, EIL can reduce dependence on the IP geolocation database quality, which is crucial to DNS response accuracy in ECS. If a Local Forwarding Resolver had sent a query with EIL, and receives a REFUSE response, it MUST regenerate a query with no EIL. Pan & Fu Expires November 12, 2017 [Page 8] Internet-Draft ISP Location in DNS Queries May 2017 6.2. Generating a Response 6.2.1. Whitelist EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which can be discussed or maintained by the DNSOP working group. Authoritative Nameservers that supporting EIL must only response the EIL queries matched the whitelist. Recursive Resolver that supporting EIL must only cache the EIL responses matched the whitelist. 6.2.2. Authoritative Nameserver Using the isp location specified in the EIL option of DNS query, an Authoritative Nameserver can generate a tailored response. Authoritative Nameservers that have not implemented or enabled support for the EIL ought to safely ignore it within incoming queries, response the query as a normal case without EDNS0 option. Such a server MUST NOT include an EIL option within replies to indicate lack of support for it. An Authoritative Nameserver that has implemented this protocol and receives an EIL option MUST include an EIL option in its response to indicate that it SHOULD be cached accordingly. An Authoritative Nameserver will return a more appropriate tailored response for the query with an EIL option containing more precisely AREA-CODE. 6.2.3. Intermediate Nameserver Like ECS, Intermediate Nameserver passes a DNS response with an EIL option to its client when the client indicates support EIL. If an Intermediate Nameserver receives a response that has a larger area than the AREA-CODE provided in its query, it SHOULD still provide the result as the answer to the triggering client request even if the client is in a smaller area. 6.3. Handling EIL Responses and Caching If an Intermediate Nameserver had sent a query with EIL, and receives a NOERROR response without EIL option, it SHOULD treat this answer as suitable for all clients. Other handling considerations are similar with ECS [RFC7871], SECTION 7.3. Pan & Fu Expires November 12, 2017 [Page 9] Internet-Draft ISP Location in DNS Queries May 2017 6.3.1. Caching the Response In the cache, all resource records in the Answer section MUST be tied to the isp location specified in the response. The Answer section is valid for all areas which the EIL option covered. For example, an EIL option < CN, 35, TEL > covers all 9 Cities in Fujian Province of China Telecommunications ISP. Same with ECS, The Additional and Authority sections are excluded. Enabling support for EIL in an Intermediate Nameserver will increase the size of the cache, and prevent "client subnet leak" privacy concern of ECS. 6.3.2. Answering from Cache Cache lookups are first done as usual for a DNS query, using the query tuple of < name, type, class >. Then, the appropriate RRset MUST be chosen based on the isp location matching. If there was an EIL option, the Intermediate Nameserver will lookup for < same COUNTRY-CODE, same ISP, same AREA-CODE > of the same query tuple in the cache. Otherwise, try to find < same COUNTRY-CODE, same ISP, same AREA-CODE > of the same query tuple in the cache. If no EIL option was provided, the safest choice of the Intermediate Nameserver is dealing the query as a normal case without EDNS0 option. If no EIL option was provided, but the Intermediate Nameserver want to be more aggressive, it can guess the isp location from the source IP of the query, then respond as if there was an EIL option with the guessed information. Users can be benefit when the Intermediate Nameserver has a more precise IP location database than the Authoritative Nameserver, especially in global public DNS service like GoogleDNS(8.8.8.8). If no matching is found, the Intermediate Nameserver MUST perform resolution as usual. 6.3.3. Support ECS and EIL at the same time Name servers can support ECS and EIL at the same time. ECS and EIL can't be both initiated at the same DNS packet. It is better for user privacy if name servers initiate the EIL query prior to the ECS query. Pan & Fu Expires November 12, 2017 [Page 10] Internet-Draft ISP Location in DNS Queries May 2017 If Authoritative Nameservers support both ECS and EIL, Recursive resolvers can cache both ECS response and EIL response, there are some choices for Recursive Resolvers when they receive DNS queries. Receive EIL query: Search in EIL cache. If cache is matched, return EIL response. Otherwise, send EIL query to Authoritative Nameserver. Receive ECS query: Search in ECS cache. If cache is matched, return ECS response. Otherwise, send ECS query to Authoritative Nameserver. Receive DNS query without EDNS option: Search in ECS cache. If cache is matched, return ECS response. Otherwise, Guess the isp location information of the client's IP, build EIL option for the query packet. Search in EIL cache. If cache is matched, return EIL response. Otherwise, send EIL query to Authoritative Nameserver. Receive DNS query with not-ECS/not-EIL option: Search in not-EDNS cache. If cache is matched, return response. Otherwise, send the DNS query to Authoritative Nameserver. Receive ECS query, improve user privacy: Guess the isp location information of the client's IP, build EIL option for the query packet. Search in EIL cache. If cache is matched, return EIL response RR with origin ECS option. Otherwise, send EIL query to Authoritative Nameserver. 6.4. Delegations and Negative Answers EIL's delegation case is similar with ECS, Additional and Authority Sections SHOULD ignore EIL. For negative answers, Authoritative Nameservers return traditional negative answers without EIL. Pan & Fu Expires November 12, 2017 [Page 11] Internet-Draft ISP Location in DNS Queries May 2017 6.5. Transitivity EIL's transitivity concerns are similar with ECS. Name servers should only enable EIL where it is expected to benefit the end users, such as dealing with some latency-sensitive CDN domain queries in a complex network environment. 6.6. Response Accuracy Authoritative Nameservers that support ECS-enabled GeoIP feature can support EIL smoothly. Compared to ECS, EIL can reduce dependence on the IP geolocation database quality. EIL will rise the response accuracy of Authoritative Nameserver if its database can not find approximate isp location of ECS client subnet, ensure user latency. EIL will help Authoritative Nameservers to avoid cross-isp visit if its database can not find approximate isp location of ECS client subnet, save IP transit cost. 7. Security Considerations 7.1. DNSSEC EIL is not signed. 7.2. Privacy As mentioned in [RFC7871]'s abstract section, since ECS has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. The biggest privacy concern on ECS is that client subnet information is personally identifiable. The more domains publish their zones on a third-party Authoritative Nameserver, the more end user privacy information can be gathered by the Authoritative Nameserver according to the ECS queries. EIL is to improve user privacy which is inspired by ECS, prevented leaks in the client subnet information. Like ECS, EIL will leak the global zonefile configurations of the Authoritative Nameservers more easily than normal case. 7.3. Target Censorship DNS traffic is plain text by default. It is easily to be blocked or poisoned by internet target censorship. To bypass the censorship, it is better to encrypt the DNS traffic or use some proxy tunnel. Pan & Fu Expires November 12, 2017 [Page 12] Internet-Draft ISP Location in DNS Queries May 2017 EIL's isp location information covers bigger area than ECS's client subnet information. Therefore, compared to ECS in plain text condition, EIL is weaker at blocking record attack, but stronger at targeted DNS poisoning attack. 7.4. Cache Size Like ECS, cache size will raise if a Public Recursive Resolver supports EIL. The cache size of ECS grows up with the number of client subnets. The cache size of EIL is related to the row count in the < COUNTRY-CODE, AREA-CODE, ISP > isp location whitelist. Therefore, under IPv6 environment, the cache size of EIL will be smaller than ECS. 7.5. DDoS To migrate the DDoS problem: o If an Authority Server receives a DNS query with unknown data in EIL option, it SHOULD return the default response whose EIL option with null value. o Nameservers OPTIONAL only implement EIL when the query is from a TCP connection. More migration techniques described in [RFC7871], Section 11.3. 8. IANA Considerations This document defines EIL, need request IANA to assign a new EDNS0 option code to EIL. 9. Acknowledgements EIL is inspired by ECS, the authors especially thanks to C. Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari. Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr Špaček, Brian Hartvigsen, Ask Bjoern Hansen. Thanks a lot to all in the DNSOP, DNSPRIV and DNSEXT mailing list. 10. Appendix A. Example Authoritative Nameserver of www.example.com has enabled EIL. Stub DNS query A resource record of www.example.com . Pan & Fu Expires November 12, 2017 [Page 13] Internet-Draft ISP Location in DNS Queries May 2017 10.1. Example 1: P-Model Stub DNS -> Local Forwarding Resolver (61.48.7.2) -> Public Forwarding Resolver(AliDNS, 223.5.5.5) -> Public Recursive Resolver(AliDNS, 202.108.250.231) -> Authoritative Nameserver Public Forwarding Resolver 223.5.5.5 could enable EIL and generate the EIL OPT data < CN, 11, UNI > based on 61.48.7.2. P-Model will not leak client subnet to Authoritative Nameserver. 10.2. Example 2: I-Model Stub DNS -> Local Forwarding Resolver -> ISP Forwarding Resolver(202.106.196.115) -> ISP Recursive Resolver(61.135.23.92) -> Authoritative Nameserver ISP Recursive Resolver 61.135.23.92 could enable EIL and generate the EIL OPT data < CN, 11, UNI > based on 61.135.23.92. If Authoritative Nameserver doesn't know much about 61.135.23.92, EIL will be helpful. 10.3. Example 3: L-Model Stub DNS -> Local Fowarding Resolver(58.60.109.234) -> ... -> Authoritative Nameserver Local Fowarding Resolver 58.60.109.234 could enable EIL and generate the option data is < CN, 44, TEL > based on 58.60.109.234. L-Model can give the most precisely isp location information for DNS resolution. 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. Pan & Fu Expires November 12, 2017 [Page 14] Internet-Draft ISP Location in DNS Queries May 2017 [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2182] ELZ, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", RFC 2182, July 1997. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", RFC 6891, April 2013. [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, December 2015. [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, May 2016. 11.2. Informative References [Amazon-Geolocation-Routing] Amazon, "Amazon Route 53: Geolocation Routing", . [BIND-GeoIP] ISC BIND, "Using the GeoIP Features in BIND 9.10", . [DYN-Traffic-Director-ECS] DYN, "What happens when a DNS query for a Traffic Director instance is received with ECS information", . [gdnsd-GeoIP] gdnsd, "GdnsdPluginGeoip", . [ISO3166] ISO 3166, "Country Codes", . Pan & Fu Expires November 12, 2017 [Page 15] Internet-Draft ISP Location in DNS Queries May 2017 [PowerDNS-GeoIP] PowerDNS, "PowerDNS GeoIP backend", . Authors' Addresses Lanlan Pan Beijing CN Email: abbypan@gmail.com URI: https://github.com/abbypan Yu Fu CNNIC No.4 South 4th Street, Zhongguancun Beijing CN Email: fuyu@cnnic.cn Pan & Fu Expires November 12, 2017 [Page 16]