< draft-pan-dnsop-edns-isp-location-01.txt   draft-pan-dnsop-edns-isp-location-02.txt >
dnsop L. Pan dnsop L. Pan
Internet-Draft Internet-Draft
Intended status: Informational Y. Fu Intended status: Informational Y. Fu
Expires: November 12, 2017 CNNIC Expires: January 18, 2018 CNNIC
May 11, 2017 July 17, 2017
ISP Location in DNS Queries ISP Location in DNS Queries
draft-pan-dnsop-edns-isp-location-01 draft-pan-dnsop-edns-isp-location-02
Abstract Abstract
This document describes an Extension Mechanisms for DNS (EDNS0) Nowadays, many Authoritative Nameservers support GeoIP feature, they
option that is in active use to carry < COUNTRY, AREA, ISP > isp guess the user's geolocation by the client subnet of EDNS Client
location information about the network that originated a DNS query Subnet (ECS) or by the source IP address of DNS query, return tailor
and the network for which the subsequent response can be cached. DNS response based on the user's geolocation. However, ECS raises
some privacy concerns because it leaks client subnet information on
the resolution path to the Authoritative Nameserver.
It is inspired by EDNS Client Subnet (ECS) with some privacy This document is inspired by EDNS Client Subnet (ECS), describes an
considerations, goals to reduce the "guess location of client's IP" improved solution for GeoIP-enabled Authoritative Nameservers,
work on Authoritative Nameservers. defines an EDNS ISP Location (EIL) extension to address the privacy
problem of ECS, tries to 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-enabled
Authoritative Nameserver as ECS, to decide the response without
guessing geolocation of the IP address.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2017. This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Path Calculation and Tailored DNS Response . . . . . . . 3 1.1. Path Calculation and Tailored DNS Response . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 6 5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 8
6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 6.1. Originating the Option . . . . . . . . . . . . . . . . . 8
6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 7 6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 8
6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8 6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8
6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 8 6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 9
6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9
6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 9
6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 9 6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 9
6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 9 6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 10
6.3. Handling EIL Responses and Caching . . . . . . . . . . . 9 6.3. Handling EIL Responses and Caching . . . . . . . . . . . 10
6.3.1. Caching the Response . . . . . . . . . . . . . . . . 10 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 10
6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 10 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 10
6.3.3. Support ECS and EIL at the same time . . . . . . . . 10 6.3.3. Support ECS and EIL at the same time . . . . . . . . 11
6.4. Delegations and Negative Answers . . . . . . . . . . . . 11 6.4. Delegations and Negative Answers . . . . . . . . . . . . 12
6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Response Accuracy . . . . . . . . . . . . . . . . . . . . 12 6.6. Response Accuracy . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 12 7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 13
7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 14
7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Appendix A. Example . . . . . . . . . . . . . . . . . . . . . 13 10. Appendix A. GeoIP-enabled Nameservers Example . . . . . . . . 14
10.1. Example 1: P-Model . . . . . . . . . . . . . . . . . . . 14 10.1. BIND-GeoIP . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Example 2: I-Model . . . . . . . . . . . . . . . . . . . 14 10.2. PowerDNS-GeoIP . . . . . . . . . . . . . . . . . . . . . 15
10.3. Example 3: L-Model . . . . . . . . . . . . . . . . . . . 14 10.3. Amazon-Geolocation-Routing . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.4. DYN-Traffic-Director-ECS . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.5. gdnsd-GeoIP . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11. Appendix B. EIL Example . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. P-Model . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2. I-Model . . . . . . . . . . . . . . . . . . . . . . . . 17
11.3. L-Model . . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
As described in EDNS Client Subnet (ECS) [RFC7871], many Nowadays, many Authoritative Nameservers support GeoIP feature, such
Authoritative Nameservers today return different responses based on as BIND-GeoIP [BIND-GeoIP], PowerDNS-GeoIP [PowerDNS-GeoIP], Amazon-
the perceived topological location of the user. These servers use Geolocation-Routing [Amazon-Geolocation-Routing], DYN-Traffic-
the IP address of the incoming query to identify that location. ECS Director-ECS [DYN-Traffic-Director-ECS], gdnsd-GeoIP [gdnsd-GeoIP]
is an EDNS0 [RFC6891] option to carry client subnet information in (More details are given in Appendix A). These geographically aware
DNS queries for Authoritative Nameserver. Compared to source IP Authoritative Nameservers guess the user's geolocation by the client
address of DNS query, ECS will help Authoritative Nameserver to guess subnet of ECS or by the source IP address of DNS query, return tailor
the client's location more precisely because of the DNS forwarding DNS response based on the user's geolocation.
query structure.
However, ECS raises some privacy concerns because it leaks client ECS is an EDNS0 [RFC6891] option, described in [RFC7871], carries
subnet information on the resolution path to the Authoritative client subnet information in DNS queries for Authoritative
Nameserver. 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.
Meanwhile, many Authoritative Nameservers support GeoIP feature, for GeoIP-enabled Authoritative Nameservers use ECS for user geolocation
example, BIND-GeoIP [BIND-GeoIP], PowerDNS-GeoIP [PowerDNS-GeoIP], detecting. However, ECS raises some privacy concerns because it
Amazon-Geolocation-Routing [Amazon-Geolocation-Routing], DYN-Traffic- leaks client subnet information on the resolution path to the
Director-ECS [DYN-Traffic-Director-ECS], gdnsd-GeoIP [gdnsd-GeoIP], Authoritative Nameserver.
etc. These geographically aware Authoritative Nameservers guess the
user's geolocation by the client subnet of ECS or by the source IP This document describes an improved solution for GeoIP-enabled
address of DNS query, return tailor DNS response based on the user's Authoritative Nameserver, defines an EDNS ISP Location (EIL)
geolocation. To sum up, these Authoritative Nameservers use ECS extension to address the privacy problem of ECS, tries to find the
client subnet information for GeoIP feature's user geolocation right balance between privacy improvement and user experience
detecting. optimization.
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 > EIL is defined to convey isp location < COUNTRY, AREA, ISP >
information that is relevant to the DNS message. It will directly information that is relevant to the DNS message. It will directly
provide the same sufficient information for the GeoIP-based provide the same sufficient information for the GeoIP-enabled
Authoritative Nameserver that enabling ECS, to decide the response Authoritative Nameserver as ECS, to decide the response without
without guessing geolocation of the IP address. guessing geolocation of the IP address.
EIL is intended for those Local Forwarding Resolvers, Recursive EIL is intended for those Local Forwarding Resolvers, Recursive
Resolvers and Authoritative Nameservers that would benefit from the Resolvers and Authoritative Nameservers that would benefit from the
extension and not for general purpose deployment like ECS scenario. extension and not for general purpose deployment. It could be
It could be applied for tailor DNS response. EIL can safely be applied for tailor DNS response like ECS scenario. EIL can safely be
ignored by servers that choose not to implement or enable it. ignored by servers that choose not to implement or enable it.
1.1. Path Calculation and Tailored DNS Response 1.1. Path Calculation and Tailored DNS Response
Separate the consideration of path calculation (Data Provider) and Separate the consideration of path calculation (Data Provider) and
tailored DNS response (Authoritative Nameserver). tailored DNS response (Authoritative Nameserver).
Data Providers make path calculations to optimize content delivery on Data Providers make path calculations to optimize content delivery on
the Internet based on the network topology, considering many factors the Internet based on the network topology, considering many factors
such as IP, RIPs, FIBs, AS Path hops, system load, content such as IP, RIPs, FIBs, AS Path hops, system load, content
skipping to change at page 4, line 21 skipping to change at page 4, line 32
Authoritative Nameservers configure tailored DNS response based on Authoritative Nameservers configure tailored DNS response based on
the result of path calculations, allocate IP addresses to different the result of path calculations, allocate IP addresses to different
datacenters. Usually, users from the same < COUNTRY, AREA, ISP > isp datacenters. Usually, users from the same < COUNTRY, AREA, ISP > isp
location are allocated to the same datacenter, the same best "network location are allocated to the same datacenter, the same best "network
topologically close" datacenter. For example, client IP addresses topologically close" datacenter. For example, client IP addresses
from < China, Beijing, Telecom > are allocated to DataCenter-1, from < China, Beijing, Telecom > are allocated to DataCenter-1,
client IP addresses from < China, Beijing, Unicom > are allocated to client IP addresses from < China, Beijing, Unicom > are allocated to
DataCenter-2, etc. Above is the GeoIP-based Tailored DNS Response. DataCenter-2, etc. Above is the GeoIP-based Tailored DNS Response.
Therefore, if the GeoIP-based Authoritative Nameservers enable ECS, Therefore, if the GeoIP-enabled Authoritative Nameservers support
they can use the client subnet information of ECS instead of ECS, they can use the client subnet information of ECS instead of
resolver's address for GeoIP detecting. Moreover, the GeoIP-based resolver's address for geolocation detecting. Alternative, the
Authoritative Nameservers can directly use the < COUNTRY, AREA, ISP > GeoIP-enabled Authoritative Nameservers can directly use the <
information of EIL without GeoIP detecting. COUNTRY, AREA, ISP > information of EIL without geolocation
detecting.
Again, we emphasize that tailored DNS response does not affect path Again, we emphasize that tailored DNS response does not affect path
calculation. Data Providers can make path calculations based on calculation. Data Providers can make path calculations based on
network topology, decide network topological close datacenter for network topology, decide network topological close datacenter for
each IP address. Authoritative Nameservers allocate tailored DNS each IP address. Authoritative Nameservers allocate tailored DNS
response to each IP address based on the "network topological close" response to each IP address based on the "network topological close"
result of path calculations. EIL tell Authoritative Nameserver like result of path calculations. EIL tell Authoritative Nameserver like
that, "I want to know what is best IP address for clients from < that, "I want to know what is best IP address for clients from <
China, Beijing, Telecom > at network topology path calculations China, Beijing, Telecom > at network topology path calculations
result", but not "I want to know what is the nearest IP address for result", but not "I want to know what is the nearest IP address for
clients from < China, Beijing, Telecom > at physical topology path clients from < China, Beijing, Telecom > at physical topology path
calculations result". calculations result".
EIL is satisfied if Authoritative Nameservers aggregate the IP EIL is satisfied if Authoritative Nameservers aggregate the IP
addresses from the same < COUNTRY, AREA, ISP > isp location to visit addresses from the same < COUNTRY, AREA, ISP > isp location to visit
the same datacenters, we call that GeoIP-based tailored DNS the same datacenters, we call that GeoIP-based tailored DNS
responses, and these tailored responses have "network topological responses, and these tailored responses have the best "network
close" distance to the users. topological close" distance to the users which are generated from
network topology path calculations result.
ECS is satisfied if Authoritative Nameservers make tailored DNS ECS is satisfied if Authoritative Nameservers make tailored DNS
response down to subnet precise level. For example, (subnet-1, ..., response down to subnet precise level. For example, (subnet-1, ...,
subnet-100) are from the same < COUNTRY, AREA, ISP > isp location, subnet-100) are from the same < COUNTRY, AREA, ISP > isp location,
Data Provider applies (subnet-1, ..., subnet-50) visit DataCenter-1, Data Provider applies (subnet-1, ..., subnet-50) visit DataCenter-1,
(subnet-51, ..., subnet-100) visit DataCenter-2. (subnet-51, ..., subnet-100) visit DataCenter-2.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 46 skipping to change at page 6, line 9
Intermediate Forwarding Resolver: Any Forwarding Resolver in between Intermediate Forwarding Resolver: Any Forwarding Resolver in between
the Local Forwarding Resolver and Recursive Resolver. the Local Forwarding Resolver and Recursive Resolver.
Authoritative Nameserver: described in [RFC7719] and [RFC2182]. It Authoritative Nameserver: described in [RFC7719] and [RFC2182]. It
is a server that knows the content of a DNS zone from local is a server that knows the content of a DNS zone from local
knowledge, and thus can answer queries about that zone without knowledge, and thus can answer queries about that zone without
needing to query other servers. needing to query other servers.
4. Overview 4. Overview
This document provides an EDNS0 option to allow Local Forwarding EIL is an EDNS0 option to allow Local Forwarding Resolvers and
Resolvers and Recursive Resolvers, if they are willing, to forward Recursive Resolvers, if they are willing, to forward details about
details about the isp location of client when talking to other the isp location of client when talking to other nameservers. EIL
nameservers. can be added in queries sent by Local Forwarding Resolvers or
Recursive Resolvers in a way that is transparent to Stub Resolvers
The format of EIL option is described in Section 5. EIL can be added and end users.
in queries sent by Local Forwarding Resolvers or Recursive Resolvers
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 Like ECS, Authoritative Nameservers could provide a better answer by
using precise isp location in EIL. Intermediate Nameservers could using precise isp location in EIL. Intermediate Nameservers could
send EIL query and cache the EIL response. This document also send EIL query and cache the EIL response. This document also
provides a mechanism to signal Intermediate Nameservers that they do provides a mechanism to signal Intermediate Nameservers that they do
not want EIL treatment for specific queries. not want EIL treatment for specific queries.
EIL is only defined for the Internet (IN) DNS class.
The format of EIL option is described in Section 5.
The security concerns for EIL are like ECS, such as cache growth, The security concerns for EIL are like ECS, such as cache growth,
spoof EDNS0 option and privacy, etc. Mitigation techniques are spoof EDNS0 option and privacy, etc. Mitigation techniques are
discussed in Section 6. discussed in Section 6.
5. The EIL EDNS0 option 5. The EIL EDNS0 option
The EIL is an EDNS0 option to include the isp location of client in The EIL is an EDNS0 option to include the isp location of client in
DNS messages. DNS messages.
It is 14 octets which is structured as follows: It is 14 octets which is structured as follows:
skipping to change at page 7, line 29 skipping to change at page 8, line 8
The aim to use short names in the fields is to limit the data size of The aim to use short names in the fields is to limit the data size of
EIL, decrease the DDoS risk. EIL, decrease the DDoS risk.
The null value 0x20 signifies that the field is unknown. If all 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 fields in EIL are set to null value, it means that client doesn't
want to use EIL. want to use EIL.
Authoritative Nameservers can send EIL response with the * value 0x2A Authoritative Nameservers can send EIL response with the * value 0x2A
in AREA-CODE field or ISP field (not COUNTRY-CODE field), which in AREA-CODE field or ISP field (not COUNTRY-CODE field), which
signifies that the field is wildcard match. For example, < CN, *, signifies that the field is wildcard match. For example, < CN, *,
TEL > indicates: all area in China, Telecom ISP. TEL > indicates "all area in China, Telecom ISP".
Example code is in Github at: https://github.com/abbypan/dns_test_eil Example code is in Github at: https://github.com/abbypan/dns_test_eil
. .
6. Protocol Description 6. Protocol Description
6.1. Originating the Option 6.1. Originating the Option
The EIL can be initialized by Public Recursive Resolver, ISP The EIL can be initialized by Public Recursive Resolver, ISP
Recursive Resolver, or Local Forwarding Resolver. Recursive Resolver, or Local Forwarding Resolver.
Examples are given in Appendix B.
6.1.1. P-Model: Public Recursive Resolver 6.1.1. P-Model: Public Recursive Resolver
Public Recursive Resolvers are not close to many users because the Public Recursive Resolvers are not close to many users because the
service providers couldn't deploy servers in every country and every service providers couldn't deploy servers in every country and every
ISP's network, which will affect the response accuracy of ISP's network, which will affect the response accuracy of
Authoritative Nameservers. To encounter this problem, ECS shifts the Authoritative Nameservers. To encounter this problem, ECS shifts the
client subnet information to Authoritative Nameserver, but rises user client subnet information to Authoritative Nameserver, but rises user
privacy concerns. privacy concerns.
Therefore, to keep balance between precise and privacy, when a Public Therefore, to keep balance between precise and privacy, when a Public
skipping to change at page 9, line 10 skipping to change at page 9, line 35
which is crucial to DNS response accuracy in ECS. which is crucial to DNS response accuracy in ECS.
If a Local Forwarding Resolver had sent a query with EIL, and If a Local Forwarding Resolver had sent a query with EIL, and
receives a REFUSE response, it MUST regenerate a query with no EIL. receives a REFUSE response, it MUST regenerate a query with no EIL.
6.2. Generating a Response 6.2. Generating a Response
6.2.1. Whitelist 6.2.1. Whitelist
EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which
can be discussed or maintained by the DNSOP working group. can be discussed and maintained by the DNSOP working group.
Authoritative Nameservers that supporting EIL must only response the Authoritative Nameservers that supporting EIL must only response the
EIL queries matched the whitelist. Recursive Resolver that EIL queries matched the whitelist. Recursive Resolver that
supporting EIL must only cache the EIL responses matched the supporting EIL must only cache the EIL responses matched the
whitelist. whitelist.
6.2.2. Authoritative Nameserver 6.2.2. Authoritative Nameserver
Using the isp location specified in the EIL option of DNS query, an Using the isp location specified in the EIL option of DNS query, an
Authoritative Nameserver can generate a tailored response. Authoritative Nameserver can generate a tailored response.
skipping to change at page 12, line 15 skipping to change at page 13, line 7
6.5. Transitivity 6.5. Transitivity
EIL's transitivity concerns are similar with ECS. EIL's transitivity concerns are similar with ECS.
Name servers should only enable EIL where it is expected to benefit Name servers should only enable EIL where it is expected to benefit
the end users, such as dealing with some latency-sensitive CDN domain the end users, such as dealing with some latency-sensitive CDN domain
queries in a complex network environment. queries in a complex network environment.
6.6. Response Accuracy 6.6. Response Accuracy
Authoritative Nameservers that support ECS-enabled GeoIP feature can GeoIP-enabled Authoritative Nameservers that support ECS can support
support EIL smoothly. EIL smoothly.
Compared to ECS, EIL can reduce dependence on the IP geolocation Compared to ECS, EIL can reduce dependence on the IP geolocation
database quality. EIL will rise the response accuracy of database quality. EIL will rise the response accuracy of
Authoritative Nameserver if its database can not find approximate isp Authoritative Nameserver if its database can not find approximate isp
location of ECS client subnet, ensure user latency. EIL will help location of ECS client subnet, ensure user latency. EIL will help
Authoritative Nameservers to avoid cross-isp visit if its database Authoritative Nameservers to avoid cross-isp visit if its database
can not find approximate isp location of ECS client subnet, save IP can not find approximate isp location of ECS client subnet, save IP
transit cost. transit cost.
7. Security Considerations 7. Security Considerations
skipping to change at page 13, line 47 skipping to change at page 14, line 42
9. Acknowledgements 9. Acknowledgements
EIL is inspired by ECS, the authors especially thanks to C. EIL is inspired by ECS, the authors especially thanks to C.
Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari. Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari.
Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr
&#352;pa&#269;ek, Brian Hartvigsen, Ask Bjoern Hansen. &#352;pa&#269;ek, Brian Hartvigsen, Ask Bjoern Hansen.
Thanks a lot to all in the DNSOP, DNSPRIV and DNSEXT mailing list. Thanks a lot to all in the DNSOP, DNSPRIV and DNSEXT mailing list.
10. Appendix A. Example 10. Appendix A. GeoIP-enabled Nameservers Example
10.1. BIND-GeoIP
As described in BIND-GeoIP [BIND-GeoIP], BIND 9.10 is able to use
data from MaxMind GeoIP databases to achieve restrictions based on
the (presumed) geographic location of that address. The ACL itself
is still address-based, but the GeoIP-based specification mechanisms
can easily populate an ACL with addresses in a certain geographic
location.
acl "example" {
geoip country US;
geoip region CA;
geoip city "Redwood City"; /* names, etc., must be quoted if they contain spaces */
};
10.2. PowerDNS-GeoIP
As described in PowerDNS-GeoIP [PowerDNS-GeoIP], PowerDNS supports
many geolocation placeholders, such as %co = 3-letter country, %cn =
continent, %re = region, %ci = city.
domains:
- domain: geo.example.com
ttl: 30
records:
geo.example.com:
- soa: ns1.example.com hostmaster.example.com 2014090125 7200 3600 1209600 3600
- ns:
content: ns1.example.com
ttl: 600
- ns: ns2.example.com
- mx: 10 mx.example.com
fin.eu.service.geo.example.com:
- a: 192.0.2.2
- txt: hello world
- aaaa: 2001:DB8::12:34DE:3
# this will result first record being handed out 30% of time
swe.eu.service.geo.example.com:
- a:
content: 192.0.2.3
weight: 50
- a: 192.0.2.4
services:
# syntax 1
service.geo.example.com: '%co.%cn.service.geo.example.com'
# syntax 2
service.geo.example.com: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com']
# alternative syntax
services:
service.geo.example.com:
default: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com' ]
10.0.0.0/8: 'internal.service.geo.example.com'
10.3. Amazon-Geolocation-Routing
As described in Amazon-Geolocation-Routing
[Amazon-Geolocation-Routing], Amazon Route 53 lets you choose the
resources that serve your traffic based on the geographic location of
your users, meaning the location that DNS queries originate from. It
allows you to route some queries for a continent to one resource and
to route queries for selected countries on that continent to a
different resource.
When a browser or other viewer uses a DNS resolver that does support
edns-client-subnet, the DNS resolver sends Amazon Route 53 a
truncated version of the user's IP address. Amazon Route 53
determines the location of the user based on the truncated IP address
rather than the source IP address of the DNS resolver; this typically
provides a more accurate estimate of the user's location. Amazon
Route 53 then responds to geolocation queries with the DNS record for
the user's location.
10.4. DYN-Traffic-Director-ECS
As described in DYN-Traffic-Director-Geographic-Groups and DYN-
Traffic-Director-ECS [DYN-Traffic-Director-ECS], Dyn provides the
ability to control DNS responses on a granular/customized
geographical rule set. Part of the rulesets will be the
identification of the global regions, countries, or states and
provinces that use a specific DNS server group. DYN uses the ECS
information for the geolocation lookup. Once a geolocation is found
and a response is selected, it will provide a DNS response back to
the source IP address.
10.5. gdnsd-GeoIP
As described in gdnsd-GeoIP [gdnsd-GeoIP], gdnsd uses MaxMind's GeoIP
binary databases to map address and CNAME results based on geography
and monitored service availability. gdnsd supports geolocation codes,
such as continent, country, region/subdivision, city.
11. Appendix B. EIL Example
Authoritative Nameserver of www.example.com has enabled EIL. Authoritative Nameserver of www.example.com has enabled EIL.
Stub DNS query A resource record of www.example.com . Stub DNS query A resource record of www.example.com .
10.1. Example 1: P-Model 11.1. P-Model
Stub DNS Stub DNS
-> Local Forwarding Resolver (61.48.7.2) -> Local Forwarding Resolver (61.48.7.2)
-> Public Forwarding Resolver(AliDNS, 223.5.5.5) -> Public Forwarding Resolver(AliDNS, 223.5.5.5)
-> Public Recursive Resolver(AliDNS, 202.108.250.231) -> Public Recursive Resolver(AliDNS, 202.108.250.231)
-> Authoritative Nameserver -> Authoritative Nameserver
Public Forwarding Resolver 223.5.5.5 could enable EIL and generate 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. the EIL OPT data < CN, 11, UNI > based on 61.48.7.2.
P-Model will not leak client subnet to Authoritative Nameserver. P-Model will not leak client subnet to Authoritative Nameserver.
10.2. Example 2: I-Model 11.2. I-Model
Stub DNS Stub DNS
-> Local Forwarding Resolver -> Local Forwarding Resolver
-> ISP Forwarding Resolver(202.106.196.115) -> ISP Forwarding Resolver(202.106.196.115)
-> ISP Recursive Resolver(61.135.23.92) -> ISP Recursive Resolver(61.135.23.92)
-> Authoritative Nameserver -> Authoritative Nameserver
ISP Recursive Resolver 61.135.23.92 could enable EIL and generate the 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. 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 If Authoritative Nameserver doesn't know much about 61.135.23.92, EIL
will be helpful. will be helpful.
10.3. Example 3: L-Model 11.3. L-Model
Stub DNS Stub DNS
-> Local Fowarding Resolver(58.60.109.234) -> Local Fowarding Resolver(58.60.109.234)
-> ... -> ...
-> Authoritative Nameserver -> Authoritative Nameserver
Local Fowarding Resolver 58.60.109.234 could enable EIL and generate 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. 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 L-Model can give the most precisely isp location information for DNS
resolution. resolution.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
skipping to change at page 15, line 28 skipping to change at page 18, line 28
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", RFC 6891, April 2013. for DNS (EDNS(0))", RFC 6891, April 2013.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, December 2015. Terminology", RFC 7719, December 2015.
[RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W. [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871, May Kumari, "Client Subnet in DNS Queries", RFC 7871, May
2016. 2016.
11.2. Informative References 12.2. Informative References
[Amazon-Geolocation-Routing] [Amazon-Geolocation-Routing]
Amazon, "Amazon Route 53: Geolocation Routing", Amazon, "Amazon Route 53: Geolocation Routing",
<http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ <http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/
routing-policy.html#routing-policy-geo>. routing-policy.html#routing-policy-geo>.
[BIND-GeoIP] [BIND-GeoIP]
ISC BIND, "Using the GeoIP Features in BIND 9.10", ISC BIND, "Using the GeoIP Features in BIND 9.10",
<https://kb.isc.org/article/AA-01149/0>. <https://kb.isc.org/article/AA-01149/0>.
[DYN-Traffic-Director-ECS] [DYN-Traffic-Director-ECS]
DYN, "What happens when a DNS query for a Traffic Director DYN, "What happens when a DNS query for a Traffic Director
instance is received with ECS information", instance is received with ECS information",
<https://help.dyn.com/edns-client-subnet-faq-info/#q6>. <https://help.dyn.com/edns-client-subnet-faq-info/#q6>.
[DYN-Traffic-Director-Geographic-Groups]
DYN, "Predefined Geographic Groups of Traffic Director",
<https://help.dyn.com/traffic-director-predefined-
geographic-regions/>.
[gdnsd-GeoIP] [gdnsd-GeoIP]
gdnsd, "GdnsdPluginGeoip", gdnsd, "GdnsdPluginGeoip",
<https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip>. <https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip>.
[ISO3166] ISO 3166, "Country Codes", [ISO3166] ISO 3166, "Country Codes",
<http://www.iso.org/iso/country_codes>. <http://www.iso.org/iso/country_codes>.
[PowerDNS-GeoIP] [PowerDNS-GeoIP]
PowerDNS, "PowerDNS GeoIP backend", PowerDNS, "PowerDNS GeoIP backend",
<https://doc.powerdns.com/md/authoritative/backend- <https://doc.powerdns.com/md/authoritative/backend-
geoip/>. geoip/>.
Authors' Addresses Authors' Addresses
Lanlan Pan Lanlan Pan
Beijing Beijing
CN China
Email: abbypan@gmail.com Email: abbypan@gmail.com
URI: https://github.com/abbypan URI: https://github.com/abbypan
Yu Fu Yu Fu
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing Beijing
CN China
Email: fuyu@cnnic.cn Email: fuyu@cnnic.cn
 End of changes. 36 change blocks. 
98 lines changed or deleted 214 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/