Internet DRAFT - draft-pan-dnsop-edns-isp-location
draft-pan-dnsop-edns-isp-location
dnsop L. Pan
Internet-Draft
Intended status: Informational Y. Fu
Expires: 18 July 2024 C. Wang
China Unicom
15 January 2024
ISP Location in DNS Queries
draft-pan-dnsop-edns-isp-location-06
Abstract
Nowadays, many authoritative servers support GeoIP feature, they
guess the client'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 client's geolocation. However, ECS raises
some privacy concerns because it leaks client subnet information on
the resolution path to the authoritative server.
This document describes an improved GeoIP solution, 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 sufficient information for the GeoIP-enabled authoritative
server as ECS, decide the response without guessing client's
geolocation.
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 https://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 18 July 2024.
Pan, et al. Expires 18 July 2024 [Page 1]
Internet-Draft EIL January 2024
Copyright Notice
Copyright (c) 2024 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem of ECS . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Recursive Resolver . . . . . . . . . . . . . . . . . . . 5
3.3. GeoIP-enabled Authoritative Server . . . . . . . . . . . 5
4. EIL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The EIL EDNS0 option . . . . . . . . . . . . . . . . . . 6
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
5.1. Originating the Option . . . . . . . . . . . . . . . . . 7
5.1.1. P-Model: Public Recursive Resolver . . . . . . . . . 8
5.1.2. I-Model: ISP Recursive Resolver . . . . . . . . . . . 8
5.1.3. L-Model: Local Forwarding Resolver . . . . . . . . . 8
5.2. Generating a Response . . . . . . . . . . . . . . . . . . 9
5.2.1. Path Calculation and Tailored DNS Response . . . . . 9
5.2.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Authoritative Server . . . . . . . . . . . . . . . . 10
5.2.4. Intermediate Nameserver . . . . . . . . . . . . . . . 11
5.3. Handling EIL Responses and Caching . . . . . . . . . . . 11
5.3.1. Answering from Cache . . . . . . . . . . . . . . . . 11
5.3.2. Delegations and Negative Answers . . . . . . . . . . 12
5.4. Deploy . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1. Transitivity . . . . . . . . . . . . . . . . . . . . 12
5.4.2. Compatibility with non-EDNS and ECS . . . . . . . . . 12
5.4.3. Intermediate Servers Support ECS and EIL at the Same
Time . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Why not use AS number to build EIL . . . . . . . . . . . 14
6. Benefit and Cost . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Recursive Resolver . . . . . . . . . . . . . . . . . . . 15
6.3. GeoIP-enabled Authoritative Server . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Pan, et al. Expires 18 July 2024 [Page 2]
Internet-Draft EIL January 2024
7.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Target Censorship . . . . . . . . . . . . . . . . . . . . 17
7.4. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Appendix A. GeoIP-enabled Authoritative Servers Example . . 18
10.1. BIND . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. PowerDNS . . . . . . . . . . . . . . . . . . . . . . . . 18
10.3. Amazon . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.4. DYN . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.5. gdnsd . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.6. Windows Server . . . . . . . . . . . . . . . . . . . . . 20
11. Appendix B. EIL Example . . . . . . . . . . . . . . . . . . 20
11.1. P-Model . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. I-Model . . . . . . . . . . . . . . . . . . . . . . . . 21
11.3. L-Model . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Appendix C. Frequent GeoIP-enabled Authoritative Server's
Response Accuracy Problem . . . . . . . . . . . . . . . . 21
12.1. Public Recursive Resolver with non-ECS Authoritative
Server . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. IP2Geo Database Quality . . . . . . . . . . . . . . . . 22
12.3. Unstable ISP Network Topology . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
Nowadays, many authoritative servers support GeoIP feature, such as
[BIND-GeoIP], [PowerDNS-GeoIP], [Amazon-GeoIP], [DYN-GeoIP],
[gdnsd-GeoIP], [WindowsServer-GeoIP] (More details are given in
Appendix A). These geographically aware authoritative servers guess
the client's geolocation by the client subnet of ECS or by the source
IP address of DNS query, return tailor DNS response based on the
client's geolocation.
ECS is an EDNS0 option [RFC6891], described in [RFC7871], carries
client subnet information in DNS queries for authoritative server.
Compared to source IP address of DNS query, ECS will help
authoritative server to guess the client's geolocation more precisely
because of the DNS forwarding query structure.
GeoIP-enabled authoritative servers use ECS for client geolocation
detecting. However, ECS raises some privacy concerns because it
leaks client subnet information on the resolution path to the
authoritative server [ECS-Privacy].
Pan, et al. Expires 18 July 2024 [Page 3]
Internet-Draft EIL January 2024
This document describes an improved GeoIP solution, 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 server as ECS, decide the response without guessing
client's geolocation.
EIL is intended for those local forwarding resolvers, recursive
resolvers and authoritative servers that would benefit from the
extension and not for general purpose deployment. EIL could be
applied for tailor DNS response for GeoIP scenario. EIL can safely
be ignored by servers that choose not to implement or enable it.
2. Terminology
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.
Basic terms used in this specification are defined in the documents
[RFC1034], [RFC1035], [RFC8499] and [RFC7871].
* EIL: EDNS ISP Location.
* ECS: EDNS Client Subnet, described in [RFC7871].
* Stub Resolver: A resolver that cannot perform all resolution
itself.
* Authoritative Server: 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.
* Intermediate Nameserver: Any nameserver in between the stub
resolver and the authoritative server, such as a recursive
resolver or a forwarding resolver.
Pan, et al. Expires 18 July 2024 [Page 4]
Internet-Draft EIL January 2024
* Local Forwarding Resolver: 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: It is the last-hop before authoritative server
in the DNS query path.
3. Problem of ECS
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.
3.1. Client
Common clients have little power to defense passive monitoring,
expecially in the plain-text traffic.
ECS's client subnet leakage has rise some user privacy concerns.
3.2. Recursive Resolver
Recursive resolver must deal with ECS's cache problem, such as low
cache hitrate, rise response time, redundant cache size, etc.
Mukund Sivaraman described some scenarios in [ClientSubnet-Bis].
ECS is precise because it is based on client subnet. But IPv6
addresses will boom, we can foresee it to increase more burden on
global recursive resolvers.
3.3. GeoIP-enabled Authoritative Server
Tranditional recursive resolver's IP can on behalf of many client
subnets because they are network topological close. But this
scenario has been varied by public recursive resolver. ECS push
client subnets to authoritative server, wants to solve the "public
recursive resolver's IP is network topological far from client
subnet" problem.
Therefore, ECS rises GeoIP-enabled authoritative server's dependence
on IP2Geo database quality, because authoritative server should guess
geolocation for huge amounts of client subnet. Every GeoIP-enabled
authoritative server must operate IP2Geo database carefully and catch
up with network topology change. The work is inevitable, but ECS
aggravate this, because the number of client subnets is far greater
than the number of recursive resolvers. GeoIP-enabled authoritative
Pan, et al. Expires 18 July 2024 [Page 5]
Internet-Draft EIL January 2024
server needs a more precise IP2Geo database, updates it more frequent
than before, to catch up with the huge client subnet network
topology, but not the recursive resolver's IP network topology.
Every GeoIP-enabled authoritative server should cost more on IP2Geo
database.
4. EIL 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.
Authoritative servers 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.
4.1. The EIL EDNS0 option
The EIL is an EDNS0 option to include the < COUNTRY, AREA, ISP > isp
location of client in DNS messages.
It is 16 octets which is structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | COUNTRY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | AREA |
| |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
12: | ISP |
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Total: 16 octets.
Pan, et al. Expires 18 July 2024 [Page 6]
Internet-Draft EIL January 2024
* OPTION-CODE, 2 octets, defined in [RFC6891]. EDNS option code
should be assigned by the IANA.
* OPTION-LENGTH, 2 octets, defined in [RFC6891], contains the length
of the payload (everything after OPTION-LENGTH) in octets.
* COUNTRY, 2 octets, uppercase, defined in [ISO3166], indicates the
country information of the client's IP. For example, China's
COUNTRY is CN.
* AREA, 6 octets, uppercase, defined in [ISO3166] country
subdivision code, indicates the area information of the client's
IP. For example, The AREA of Fujian Province in China is 35.
* 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. 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 shortcut names in the ISP field 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 servers can send EIL response with the * value 0x2A in
AREA field or ISP field (not COUNTRY field), which signifies that the
field is wildcard match. For example, < CN, *, TEL > indicates "all
area in China, Telecom ISP", < CN, *, * > indicates "all area in
China".
5. Protocol Description
5.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.
Pan, et al. Expires 18 July 2024 [Page 7]
Internet-Draft EIL January 2024
5.1.1. P-Model: Public Recursive Resolver
Public recursive resolvers are not close to many clients because the
service providers couldn't deploy servers in every country and every
ISP's network, which will affect the response accuracy of
authoritative servers. To address this problem, ECS shifts the
client subnet information to authoritative server, 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 server. This will move the "guess location of client's
IP" work from authoritative server back to public recursive resolver,
lighten the burden of authoritative server, 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 server which supports EIL.
P-model is the most recommended and close to the ECS.
5.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 client, and then authoritative server doesn't need to "guess
location of client's IP".
EIL will be benefit if the authoritative server could not find the
approximate isp location of ISP recursive resolver, which is crucial
to DNS response accuracy in ECS.
5.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 client, 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 recursive resolver. Recursive resolver sends the EIL
query to the authoritative server.
Pan, et al. Expires 18 July 2024 [Page 8]
Internet-Draft EIL January 2024
In this scenario, both public recursive resolver and authoritative
server 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 the 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.
5.2. Generating a Response
5.2.1. Path Calculation and Tailored DNS Response
Separate the consideration of path calculation (data provider) and
tailored DNS response (authoritative server).
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. Data Providers can make path
calculations based on network topology, decide network topological
close datacenter for each IP address.
Authoritative servers allocate tailored DNS response to each IP
address based on the "network topological close" result of path
calculations. Based on the result of path calculation, data
providers could build up their GeoIP configuration for their domains.
Usually, clients from the same < COUNTRY, AREA, ISP > isp location
are allocated to the same best "network topologically close" target
ip addresses. For example, client IP addresses from < China,
Beijing, Telecom > are allocated to Target-IP-addresses-1 (ip1, ...,
ip4), client IP addresses from < China, Beijing, Unicom > are
allocated to Target-IP-addresses-2 (ip5, ..., ip8), etc.
Data providers publish their GeoIP configuration to Authoritative
servers. Authoritative servers load the GeoIP configuration, and
return the GeoIP-based tailored DNS response based on client's
geolocation. If the GeoIP-enabled authoritative servers support ECS,
they can use the client subnet information of ECS for client's
geolocation detecting. Alternative, if the GeoIP-enabled
authoritative servers support EIL, they can use the < COUNTRY, AREA,
ISP > information of EIL directly, without client's geolocation
detecting.
Pan, et al. Expires 18 July 2024 [Page 9]
Internet-Draft EIL January 2024
EIL tell authoritative server 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 servers 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 the best "network topological close"
distance to the clients which are generated from network topology
path calculations result.
ECS is satisfied if authoritative servers make tailored DNS response
down to subnet precise level. For example, (subnet-1, ..., subnet-
10) are from the same < COUNTRY, AREA, ISP > isp location, Data
Provider can apply (subnet-1, ..., subnet-5) visit Target-IP-
addresses-1 (ip1, ..., ip2), (subnet-6, ..., subnet-10) visit Target-
IP-addresses-1 (ip3, ..., ip4).
5.2.2. Whitelist
EIL contains a whitelist for < COUNTRY, AREA and ISP >, which can be
discussed and maintained by the DNSOP working group. Authoritative
servers 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.
5.2.3. Authoritative Server
Using the < COUNTRY, AREA and ISP > isp location specified in the EIL
option of DNS query, an authoritative server can generate a tailored
response.
Authoritative servers 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 server 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 server will return a more appropriate tailored
response for the query with an EIL option containing more precisely
AREA.
Pan, et al. Expires 18 July 2024 [Page 10]
Internet-Draft EIL January 2024
5.2.4. 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 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.
5.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 [RFC7871], SECTION
7.3.
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.
5.3.1. 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, same AREA, same ISP > 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
Pan, et al. Expires 18 July 2024 [Page 11]
Internet-Draft EIL January 2024
guessed information. Clients can be benefit when the intermediate
nameserver has a more precise IP location database than the
authoritative server, especially in global public DNS service like
GoogleDNS(8.8.8.8).
Otherwise, if no matching is found, the intermediate nameserver MUST
perform resolution as usual.
5.3.2. Delegations and Negative Answers
EIL's delegation case is similar with ECS, Additional and Authority
Sections SHOULD ignore EIL.
For negative answers, authoritative servers return traditional
negative answers without EIL.
5.4. Deploy
5.4.1. Transitivity
EIL's transitivity concerns are similar with ECS.
Name servers should only enable EIL where it is expected to benefit
the end clients, such as dealing with some latency-sensitive CDN
domain queries in a complex network environment.
5.4.2. Compatibility with non-EDNS and ECS
GeoIP-enabled authoritative servers can simply add EIL support.
Recursive Resolvers can add EIL support, and make the compatible
policy with ECS and EIL.
The indicator that authoritative servers used to generate tailor
response is showed as follows:
* RRIP: Recursive Resolver's IP
* ECS: Client Subnet
* EIL: Client Isp Location
Pan, et al. Expires 18 July 2024 [Page 12]
Internet-Draft EIL January 2024
+--------------------+----------------------=-------------------------------------+
| Recursive Resolver | AUTH |
| | non-EDNS | ECS but non-EIL | EIL but non-ECS | ECS and EIL |
+--------------------+----------+-----------------+-----------------+-------------+
| non-EDNS | RRIP | RRIP | RRIP | RRIP |
+-------------------------------+-----------------+-----------------+-------------+
| ECS but non-EIL | RRIP | ECS | RRIP | ECS |
+-------------------------------+-----------------+-----------------+-------------+
| EIL but non-ECS | RRIP | RRIP | EIL | EIL |
+--------------------+----------+-----------------+-----------------+-------------+
| ECS and EIL | RRIP | ECS | EIL | ECS/EIL |
+--------------------+----------+-----------------+-----------------+-------------+
5.4.3. Intermediate Servers Support ECS and EIL at the Same Time
Intermediate nameservers can support ECS and EIL at the same time.
However, ECS and EIL can't be both initiated at the same DNS packet.
To make more effort to protect user's privacy, we suggest that
intermediate nameservers could initiate EIL query prior to ECS query.
Alternative, they could send both ECS and EIL queries if not match in
the cache.
Pan, et al. Expires 18 July 2024 [Page 13]
Internet-Draft EIL January 2024
Receive EIL query:
Search in EIL cache.
If cache is matched, return EIL response.
Otherwise,
Send EIL query.
Receive ECS query:
Search in ECS cache.
If cache is matched, return ECS response.
Otherwise,
Send ECS query.
Receive plain 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,
Search in EIL cache.
If cache is matched, return EIL response.
Otherwise,
Send EIL query.
If authoritative server supports EIL, return EIL response.
Otherwise,
Send ECS query.
If authoritative server supports ECS, return ECS response.
Otherwise,
Send plain DNS query.
Receive plain DNS query with not-ECS/not-EIL option:
Search in not-EDNS cache.
If cache is matched, return response.
Otherwise,
Send plain DNS query.
Receive ECS query, improve user privacy with EIL:
Guess the isp location information of the client's IP,
Search in EIL cache.
If cache is matched, return EIL response RR with origin ECS option.
Otherwise,
Send EIL query.
5.5. 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:
Pan, et al. Expires 18 July 2024 [Page 14]
Internet-Draft EIL January 2024
* User privacy: AS24151 can directly guide to China Internet Network
Infomation Center, it is not good for user privacy.
* Response accurancy: 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.
Maybe < COUNTRY-CODE, AREA-CODE, ISP, AS-NUMBER > is a considerable
trade-off choice.
6. Benefit and Cost
6.1. Client
EIL is transparent to client.
EIL is to help mitigate client subnet leakage on the resolution path,
improve user privacy.
6.2. Recursive Resolver
ECS sends the query with client subnet, which means that recursive
resolvers have to send a new query to authoritative servers with
client_subnet_b, even it has known the response about network
topological close client_subnet_a. In fact, thousands of subnets
visit only a few servers, there are many redundacy queries, the
recursive's cache hitrate is low.
Because of ECS's low cache hitrate, recursive resolvers's ECS
tailored response latency will be longer, the average of response
time will rise with the redundacy queries rate from recursive
resolvers to authoritative servers.
Recursive resolver's ECS cache size grows up with the number of
client subnets, see also [EIL-Qshine] and [EIL-PST].
To sum it up, above problems all rise with the client subnet amount,
especially when IPv6 addresses boom. Extend the subnet range in the
ECS response may be mitigating, but not work for wide range client
subnets. Recursive can make some guess optimization, if it has known
response for client_subnet_a, then guess to return the same response
for toplogical close client_subnet_b without send the redundancy
query.
Therefore, if the ECS revision wants to make more effective client
subnets aggregation for recursive resolver, then EIL can be an
considerable choice. EIL wants to summary network toplogical close
client subnets into < COUNTRY, AREA, ISP > for GeoIP-enabled
Pan, et al. Expires 18 July 2024 [Page 15]
Internet-Draft EIL January 2024
authoritative server. With EIL response cache, recursive resolvers
can directly response for many ECS client subnets queries, which will
rise cache hitrate and reduce response latency. The cache size of
EIL is related to the row count in the < COUNTRY, AREA, ISP > isp
location whitelist. Therefore, under IPv6 environment, the cache
size of EIL will be much smaller than ECS.
Note that, the EIL's IP2Geo mapping work will make recursive resolver
to more computational cost.
6.3. GeoIP-enabled Authoritative Server
Client subnet is the best factor if the company has good network
topology monitor ability, offen is for big company. However, for
many authoritative servers that only deployed GeoDNS, the accuracy
limitation is commonly because of the IP2Geo database quality, and
the small ISPs change to another next-hop big ISP suddenly.
For the GeoIP-enabled authoritative server, the response accurancy
depends on the IP geolocation database quality. If authoritative
server can not find approximate isp location of ECS's client subnet,
they can not return best tailored response.
Even though GeoIP-enabled authoritative servers know about the
precise isp location of ECS's client subnet, they may not know about
the latest toplogical path change of the isp to update the tailored
response in time. In the case of "small ISP -> big ISP (change
frequency) -> ... -> website", both small ISP's client ip/resolver
ip is not good factor for GeoDNS. Big companies work hard to catch
up with the client ip's connect topology change, and adjust their
authoritative servers' tailored response, but smaller companies only
deploy IP2Geo may not afford.
EIL wants to give downstream a chance to tell authoritative server
its best path quickly and proactively, help to rise the response
accuracy, avoid cross-isp visit, save IP transit cost for Data
Provider. EIL directly provide sufficient information for the GeoIP-
enabled authoritative server. Compared to ECS, EIL can reduce GeoIP-
enabled authoritative server's dependence on the IP geolocation
database quality.
7. Security Considerations
7.1. DNSSEC
EIL is not signed.
Pan, et al. Expires 18 July 2024 [Page 16]
Internet-Draft EIL January 2024
7.2. Privacy
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 server, the more end user privacy
information can be gathered by the authoritative server 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 servers 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.
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. DDoS
To migrate the DDoS problem:
* 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.
* 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.
Pan, et al. Expires 18 July 2024 [Page 17]
Internet-Draft EIL January 2024
Thanks comments for Barry Raveendran Greene, Paul Vixie, Petr Špaček,
Brian Hartvigsen, Ask Bjørn Hansen, Dave Lawrence.
Thanks a lot to all in the DNSOP, DNSPRIV mailing list.
10. Appendix A. GeoIP-enabled Authoritative Servers Example
10.1. BIND
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
As described in [PowerDNS-GeoIP], PowerDNS supports many geolocation
placeholders, such as %co = 3-letter country, %cn = continent, %re =
region, %ci = city.
Pan, et al. Expires 18 July 2024 [Page 18]
Internet-Draft EIL January 2024
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
As described in [Amazon-GeoIP], 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.
Pan, et al. Expires 18 July 2024 [Page 19]
Internet-Draft EIL January 2024
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 client'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 client's location. Amazon
Route 53 then responds to geolocation queries with the DNS record for
the client's location.
10.4. DYN
As described in [DYN-GeoIP], 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
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.
10.6. Windows Server
As described in [WindowsServer-GeoIP], Windows server can be
configured DNS Policy to respond to DNS client queries based on the
geographical location of both the client and the resource to which
the client is attempting to connect, providing the client with the IP
address of the closest resource.
11. Appendix B. EIL Example
authoritative server 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 server
Pan, et al. Expires 18 July 2024 [Page 20]
Internet-Draft EIL January 2024
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 server.
11.2. I-Model
Stub DNS
-> local forwarding resolver
-> ISP Forwarding Resolver(202.106.196.115)
-> ISP recursive resolver(61.135.23.92)
-> authoritative server
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 server doesn't know much about 61.135.23.92, EIL
will be helpful.
ISP recursive resolver generates static EIL query, simply manages
response cache as tranditionl non-ECS/non-EIL scenario.
EIL helps ISP recursive resolver to give upstream an explicit correct
isp location information.
11.3. L-Model
Stub DNS
-> Local Fowarding Resolver(58.60.109.234)
-> ...
-> authoritative server
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. Appendix C. Frequent GeoIP-enabled Authoritative Server's Response
Accuracy Problem
12.1. Public Recursive Resolver with non-ECS Authoritative Server
If authoritative server doesn't support ECS, the clients that use
public recursive resolver(such as 8.8.8.8) may receive disaster
latency IP.
Pan, et al. Expires 18 July 2024 [Page 21]
Internet-Draft EIL January 2024
In this scenario, we must pray that public recursive resolver's IP is
network topological close to client's IP.
12.2. IP2Geo Database Quality
If authoritative server's IP2Geo database misidentify client IP's
information, then the client may be assigned to some high letency
cross-isp IP address.
With EIL, public recursive resolver and ISP recursive resolver can
help to give more precise information for GeoIP-enabled authoritative
servers.
12.3. Unstable ISP Network Topology
Some small ISPs may change their upstreams frequently. authoritative
servers offen can not catch up the variation in time.
EIL gives downstream a chance to proactively tell authoritative
servers the latest best topological close response itself wants now.
Downstream can assure itself has got explicit tailored response with
EIL.
For example, 218.247.200.100's isp location information is < China,
Beijing, PengBoShi >. In I-Model, PengBoShi's resolver can send EIL
< CN, 11, TEL > to authoritative servers, indicates that the best
topological close response forclient 218.247.200.100 is from China
Beijing Telecom.
13. References
13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
DOI 10.17487/RFC1700, October 1994,
<https://www.rfc-editor.org/info/rfc1700>.
Pan, et al. Expires 18 July 2024 [Page 22]
Internet-Draft EIL January 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
13.2. Informative References
[Amazon-GeoIP]
Amazon, "Amazon Route 53 Geolocation Routing", n.d.,
<http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/
routing-policy.html#routing-policy-geo>.
[BIND-GeoIP]
ISC, "Using the GeoIP Features in BIND 9.10", n.d.,
<https://kb.isc.org/article/AA-01149/0>.
[ClientSubnet-Bis]
Sivaraman, M., "CLIENT-SUBNET bis appetite?", n.d.,
<https://www.ietf.org/mail-archive/web/dnsop/current/
msg21616.html>.
[DYN-GeoIP]
DYN, "Understanding How Traffic Director Makes Decisions",
n.d., <https://help.dyn.com/understanding-td-decisions/>.
[ECS-Privacy]
Kintis, P., "Understanding the Privacy Implications of
ECS", n.d., <https://link.springer.com/
chapter/10.1007/978-3-319-40667-1_17>.
[EIL-PST] Pan, L., "Mitigating Client Subnet Leakage in DNS
Queries", n.d.,
<https://ieeexplore.ieee.org/document/8514164>.
Pan, et al. Expires 18 July 2024 [Page 23]
Internet-Draft EIL January 2024
[EIL-Qshine]
Pan, L., "Improving Privacy for GeoIP DNS Traffic", n.d.,
<https://eudl.eu/doi/10.1007/978-3-030-14413-5_1>.
[gdnsd-GeoIP]
gdnsd, "GdnsdPluginGeoip", n.d.,
<https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip>.
[ISO3166] ISO, "Country Codes", n.d.,
<http://www.iso.org/iso/country_codes>.
[PowerDNS-GeoIP]
PowerDNS, "PowerDNS GeoIP backend", n.d.,
<https://doc.powerdns.com/md/authoritative/backend-
geoip/>.
[WindowsServer-GeoIP]
Microsoft, "Use DNS Policy for Geo-Location Based Traffic
Management with Primary Servers", n.d.,
<https://docs.microsoft.com/en-us/windows-
server/networking/dns/deploy/primary-geo-location>.
Authors' Addresses
Lanlan Pan
Guangdong
China
Email: abbypan@gmail.com
Yu Fu
China Unicom
Beijing
China
Email: fuy186@chinaunicom.cn
Cuicui Wang
China Unicom
Beijing
China
Email: wangcc107@chinaunicom.cn
Pan, et al. Expires 18 July 2024 [Page 24]
