dnsop L. Pan
Internet-Draft
Intended status: Informational Y. Fu
Expires: March 30, 2018 CNNIC
September 26, 2017
ISP Location in DNS Queries
draft-pan-dnsop-edns-isp-location-03
Abstract
Nowadays, many Authoritative Nameservers support GeoIP feature, they
guess the user's geolocation by the client subnet of EDNS Client
Subnet (ECS) or by the source IP address of DNS query, return tailor
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.
This document is inspired by EDNS Client Subnet (ECS), describes an
improved solution for GeoIP-enabled 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
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 March 30, 2018.
Pan & Fu Expires March 30, 2018 [Page 1]
Internet-Draft ISP Location in DNS Queries September 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
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 . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Description . . . . . . . . . . . . . . . . . . . . 8
6.1. Originating the Option . . . . . . . . . . . . . . . . . 8
6.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 8
6.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8
6.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 9
6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9
6.2.1. Whitelist . . . . . . . . . . . . . . . . . . . . . . 9
6.2.2. Authoritative Nameserver . . . . . . . . . . . . . . 9
6.2.3. Intermediate Nameserver . . . . . . . . . . . . . . . 10
6.3. Handling EIL Responses and Caching . . . . . . . . . . . 10
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 . . . . . . . . 11
6.4. Delegations and Negative Answers . . . . . . . . . . . . 12
6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Response Accuracy . . . . . . . . . . . . . . . . . . . . 13
6.7. Why not use AS number to build EIL . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 14
7.4. Cache Size . . . . . . . . . . . . . . . . . . . . . . . 14
7.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Pan & Fu Expires March 30, 2018 [Page 2]
Internet-Draft ISP Location in DNS Queries September 2017
10. Appendix A. GeoIP-enabled Nameservers Example . . . . . . . . 15
10.1. BIND-GeoIP . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. PowerDNS-GeoIP . . . . . . . . . . . . . . . . . . . . . 15
10.3. Amazon-Geolocation-Routing . . . . . . . . . . . . . . . 16
10.4. DYN-Traffic-Director-ECS . . . . . . . . . . . . . . . . 17
10.5. gdnsd-GeoIP . . . . . . . . . . . . . . . . . . . . . . 17
11. Appendix B. EIL Example . . . . . . . . . . . . . . . . . . . 17
11.1. P-Model . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2. I-Model . . . . . . . . . . . . . . . . . . . . . . . . 17
11.3. L-Model . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Nowadays, many Authoritative Nameservers support GeoIP feature, such
as [BIND-GeoIP], [PowerDNS-GeoIP], [Amazon-Geolocation-Routing],
[DYN-Traffic-Director-ECS], [gdnsd-GeoIP] (More details are given in
Appendix A). 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.
ECS is an EDNS0 [RFC6891] option, described in [RFC7871], carries
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.
GeoIP-enabled Authoritative Nameservers use ECS for user geolocation
detecting. However, ECS raises some privacy concerns because it
leaks client subnet information on the resolution path to the
Authoritative Nameserver.
This document describes an improved solution for GeoIP-enabled
Authoritative Nameserver, 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.
Pan & Fu Expires March 30, 2018 [Page 3]
Internet-Draft ISP Location in DNS Queries September 2017
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. It could be
applied for tailor DNS response like ECS scenario. 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).
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-enabled Authoritative Nameservers support
ECS, they can use the client subnet information of ECS instead of
resolver's address for geolocation detecting. Alternative, the
GeoIP-enabled Authoritative Nameservers can directly use the <
COUNTRY, AREA, ISP > information of EIL without geolocation
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
Pan & Fu Expires March 30, 2018 [Page 4]
Internet-Draft ISP Location in DNS Queries September 2017
the same datacenters, we call that GeoIP-based tailored DNS
responses, and these tailored responses have the best "network
topological close" distance to the users which are generated from
network topology path calculations result.
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.
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
Pan & Fu Expires March 30, 2018 [Page 5]
Internet-Draft ISP Location in DNS Queries September 2017
knowledge, and thus can answer queries about that zone without
needing to query other servers.
4. Overview
EIL is 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. EIL
can be added in queries sent by Local Forwarding Resolvers or
Recursive Resolvers in a way that is transparent to Stub Resolvers
and end users.
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.
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,
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 16 octets which is structured as follows:
Pan & Fu Expires March 30, 2018 [Page 6]
Internet-Draft ISP Location in DNS Queries September 2017
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | COUNTRY-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | AREA-CODE |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
12: | ISP |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Total: 16 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.
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.
Pan & Fu Expires March 30, 2018 [Page 7]
Internet-Draft ISP Location in DNS Queries September 2017
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.
Examples are given in Appendix B.
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
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".
Pan & Fu Expires March 30, 2018 [Page 8]
Internet-Draft ISP Location in DNS Queries September 2017
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.
6.2. Generating a Response
6.2.1. Whitelist
EIL contains a whitelist for COUNTRY-CODE, AREA-CODE and ISP, which
can be discussed and 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.
Pan & Fu Expires March 30, 2018 [Page 9]
Internet-Draft ISP Location in DNS Queries September 2017
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.
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.
Pan & Fu Expires March 30, 2018 [Page 10]
Internet-Draft ISP Location in DNS Queries September 2017
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.
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.
Pan & Fu Expires March 30, 2018 [Page 11]
Internet-Draft ISP Location in DNS Queries September 2017
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.
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.
Pan & Fu Expires March 30, 2018 [Page 12]
Internet-Draft ISP Location in DNS Queries September 2017
6.6. Response Accuracy
GeoIP-enabled Authoritative Nameservers that support ECS can support
EIL smoothly.
EIL directly provide the same sufficient information for the GeoIP-
enabled Authoritative Nameserver as ECS. Compared to ECS, EIL can
reduce Authoritative Nameserver's dependence on the IP geolocation
database quality.
If Authoritative Nameserver can not find approximate isp location of
ECS client subnet, EIL's isp location can help to rise the response
accuracy, avoid cross-isp response, save IP transit cost for Data
Provider.
6.7. Why not use AS number to build EIL
AS number is not an ideal object to balance between response accuracy
and user privacy, for example:
o AS24151 can directly guide to China Internet Network Infomation
Center, it is not good for user privacy.
o AS4134 contains a huge amount of IP prefixes whose geolocation
covers from South China to North China, AS number can not afford
the response accuracy consideration.
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.
Pan & Fu Expires March 30, 2018 [Page 13]
Internet-Draft ISP Location in DNS Queries September 2017
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.
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, Dave Lawrence.
Thanks a lot to all in the DNSOP, DNSPRIV mailing list.
Pan & Fu Expires March 30, 2018 [Page 14]
Internet-Draft ISP Location in DNS Queries September 2017
10. Appendix A. GeoIP-enabled Nameservers Example
10.1. BIND-GeoIP
As described in [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 supports many geolocation
placeholders, such as %co = 3-letter country, %cn = continent, %re =
region, %ci = city.
Pan & Fu Expires March 30, 2018 [Page 15]
Internet-Draft ISP Location in DNS Queries September 2017
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 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
Pan & Fu Expires March 30, 2018 [Page 16]
Internet-Draft ISP Location in DNS Queries September 2017
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 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 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.
Stub DNS query A resource record of www.example.com .
11.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.
11.2. I-Model
Stub DNS
-> Local Forwarding Resolver
-> ISP Forwarding Resolver(202.106.196.115)
-> ISP Recursive Resolver(61.135.23.92)
-> Authoritative Nameserver
Pan & Fu Expires March 30, 2018 [Page 17]
Internet-Draft ISP Location in DNS Queries September 2017
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.
11.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.
12. References
12.1. Normative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987.
[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.
Pan & Fu Expires March 30, 2018 [Page 18]
Internet-Draft ISP Location in DNS Queries September 2017
12.2. Informative References
[Amazon-Geolocation-Routing]
Amazon, "Amazon Route 53: Geolocation Routing",
<http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/
routing-policy.html#routing-policy-geo>.
[BIND-GeoIP]
ISC BIND, "Using the GeoIP Features in BIND 9.10",
<https://kb.isc.org/article/AA-01149/0>.
[DYN-Traffic-Director-ECS]
DYN, "What happens when a DNS query for a Traffic Director
instance is received with ECS information",
<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, "GdnsdPluginGeoip",
<https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip>.
[ISO3166] ISO 3166, "Country Codes",
<http://www.iso.org/iso/country_codes>.
[PowerDNS-GeoIP]
PowerDNS, "PowerDNS GeoIP backend",
<https://doc.powerdns.com/md/authoritative/backend-
geoip/>.
Authors' Addresses
Lanlan Pan
Beijing
China
Email: abbypan@gmail.com
URI: https://github.com/abbypan
Pan & Fu Expires March 30, 2018 [Page 19]
Internet-Draft ISP Location in DNS Queries September 2017
Yu Fu
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
China
Email: fuyu@cnnic.cn
Pan & Fu Expires March 30, 2018 [Page 20]