draft-arkko-abcd-distributed-resolver-selection-00.txt   draft-arkko-abcd-distributed-resolver-selection.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational M. Thomson Intended status: Informational M. Thomson
Expires: May 7, 2020 Mozilla Expires: September 11, 2020 Mozilla
T. Hardie T. Hardie
Google Google
November 04, 2019 March 10, 2020
Selecting Resolvers from a Set of Distributed DNS Resolvers Selecting Resolvers from a Set of Distributed DNS Resolvers
draft-arkko-abcd-distributed-resolver-selection-00 draft-arkko-abcd-distributed-resolver-selection-01
Abstract Abstract
This memo discusses the use of a set of different DNS resolvers to This memo discusses the use of a set of different DNS resolvers to
reduce privacy problems related to resolvers learning the Internet reduce privacy problems related to resolvers learning the Internet
usage patterns of their clients. usage patterns of their clients.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 7, 2020. This Internet-Draft will expire on September 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Operational Context . . . . . . . . . . . . . . . . . . . . . 4 2. Operational Context . . . . . . . . . . . . . . . . . . . . . 4
3. Goals and Constraints . . . . . . . . . . . . . . . . . . . . 4 3. Goals and Constraints . . . . . . . . . . . . . . . . . . . . 4
4. Query distribution strategies . . . . . . . . . . . . . . . . 5 4. Query distribution strategies . . . . . . . . . . . . . . . . 6
4.1. Client-based . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Client-based . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Analysis of client-based selection . . . . . . . . . 6 4.1.1. Analysis of client-based selection . . . . . . . . . 6
4.1.2. Enhancements to client-based selection . . . . . . . 7 4.1.2. Enhancements to client-based selection . . . . . . . 7
4.2. Name-based . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Name-based . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Name reduction . . . . . . . . . . . . . . . . . . . 8 4.2.1. Name reduction . . . . . . . . . . . . . . . . . . . 8
5. Early conclusions . . . . . . . . . . . . . . . . . . . . . . 9 5. Early conclusions . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Analysis conclusions . . . . . . . . . . . . . . . . . . 9 5.1. Analysis conclusions . . . . . . . . . . . . . . . . . . 9
5.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 9 5.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 9
5.3. Poor distribution strategies . . . . . . . . . . . . . . 9 5.3. Poor distribution strategies . . . . . . . . . . . . . . 9
6. Effects of query distribution . . . . . . . . . . . . . . . . 10 6. Effects of query distribution . . . . . . . . . . . . . . . . 10
6.1. Caching considerations . . . . . . . . . . . . . . . . . 10 6.1. Caching considerations . . . . . . . . . . . . . . . . . 10
6.2. Consistency considerations . . . . . . . . . . . . . . . 10 6.2. Consistency considerations . . . . . . . . . . . . . . . 10
6.3. Resolver load distribution and failover . . . . . . . . . 10 6.3. Resolver load distribution and failover . . . . . . . . . 11
6.4. Query performance . . . . . . . . . . . . . . . . . . . . 11 6.4. Query performance . . . . . . . . . . . . . . . . . . . . 11
6.5. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Further work . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Further work . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The DNS [DNS] is a complex system with many different security The DNS [DNS] is a complex system with many different security
issues, challenges, deployment models and usage patterns. This issues, challenges, deployment models and usage patterns. This
document focuses on one narrow aspect within DNS and its security. document focuses on one narrow aspect within DNS and its security.
Traditionally, systems are configured with a single DNS recursive Traditionally, systems are configured with a single DNS recursive
resolver, or a set of primary and alternate recursive resolvers. resolver, or a set of primary and alternate recursive resolvers.
skipping to change at page 3, line 18 skipping to change at page 3, line 18
of data. Similarly, outside attacks may occur towards any DNS of data. Similarly, outside attacks may occur towards any DNS
services. For a service with many clients, these risks are services. For a service with many clients, these risks are
particularly undesirable. particularly undesirable.
This memo discusses whether DNS clients can improve their privacy This memo discusses whether DNS clients can improve their privacy
through the potential use of a set of multiple recursive resolver through the potential use of a set of multiple recursive resolver
services. The goal is indeed an improvement only. There is no services. The goal is indeed an improvement only. There is no
expectation that it would be possible to have no part of the DNS expectation that it would be possible to have no part of the DNS
infrastructure aware of what queries are being made, but perhaps infrastructure aware of what queries are being made, but perhaps
there are mitigations that would make possible information collection there are mitigations that would make possible information collection
from the DNS infrastruture harder. from the DNS infrastructure harder.
It should be understood that this is a narrow aspect within a bigger It should be understood that this is a narrow aspect within a bigger
set of topics even within privacy issues around DNS, let alone other set of topics even within privacy issues around DNS, let alone other
security issues, deployment models, or the many protocol questions security issues, deployment models, or the many protocol questions
within DNS. Some of these other topics include detecting the within DNS. Some of these other topics include detecting the
tampering DNS query responses [DNSSEC], encrypting DNS queries [DOT] tampering DNS query responses [DNSSEC], encrypting DNS queries [DOT]
[DOH], application-specific DNS resolution mechanisms, or centralised [DOH], application-specific DNS resolution mechanisms, or centralised
deployment models. Those other topics are not covered in this memo deployment models. Those other topics are not covered in this memo
and need to be dealt with elsewhere. and need to be dealt with elsewhere.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
because these could share a commonality that might be exploited to because these could share a commonality that might be exploited to
link them. For instance, some web sites use names that are appear link them. For instance, some web sites use names that are appear
unrelated to their primary name for hosting some kinds of content, unrelated to their primary name for hosting some kinds of content,
like static images or videos. If queries for these unrelated like static images or videos. If queries for these unrelated
names were sent to different services, that effectively allows names were sent to different services, that effectively allows
multiple resolvers to learn that the client accessed the web site. multiple resolvers to learn that the client accessed the web site.
A distribution scheme also needs to consider stability of query A distribution scheme also needs to consider stability of query
routing over time. A resolver can observe the absence of queries and routing over time. A resolver can observe the absence of queries and
infer things about the state of a client cache, which can reveal that infer things about the state of a client cache, which can reveal that
queries were made to other resolvers. queries were made to other resolvers. In general, different queries
for the same resolution context, such as sub-resources for a web page
load, which have some probability of being related or linked, should
be sent to the same resolver. Failure to do so reveals information
to more than one resolver.
In effect, there are two goals in tension: In effect, there are two goals in tension:
o to split queries between as many different resolvers as possible; o split queries between as many different resolvers as possible; and
and
o to reduce the spread of information about related queries across o reduce the spread of linkable queries across multiple resolvers.
multiple resolvers.
The need to limit replication of private information about queries The need to limit replication of private information about queries
eliminates naive distribution schemes, such as those discussed in eliminates naive distribution schemes, such as those discussed in
Section 5.3. The designs described in Section 4 all attempt to Section 5.3. The designs described in Section 4 all attempt to
balance these different goals using different properties from the balance these different goals using different properties from the
context of a query (Section 4.1) or the query name itself context of a query (Section 4.1) or the query name itself
(Section 4.2). (Section 4.2).
4. Query distribution strategies 4. Query distribution strategies
This section introduces and analyzes several potential strategies for This section introduces and analyzes several potential strategies for
distributing queries to different resolvers. Each strategy is distributing queries to different resolvers. Each strategy is
formulated as an algorithm for choosing a resolver Ri from a set of n formulated as an algorithm for choosing a resolver Ri from a set of n
resolvers R1, R2, ..., Rn. resolvers {R1, R2, ..., Rn}.
The designs presented in Section 4 assume that the stub resolver The designs presented in Section 4 assume that the stub resolver
performing distribution of queries has varying degrees of contextual performing distribution of queries has varying degrees of contextual
information. In general, more contextual information allows for information. In general, more contextual information allows for
finer-grained distribution of information between resolvers. finer-grained distribution of information between resolvers.
4.1. Client-based 4.1. Client-based
The simplest strategy is to distribute each different client to a The simplest strategy is to distribute each different client to a
different resolver. This reduces the number of users any particular different resolver. This reduces the number of users any particular
skipping to change at page 8, line 46 skipping to change at page 8, line 51
manually curated equivalence list [2] for web sites that aims to manually curated equivalence list [2] for web sites that aims to
maps the complete set of unrelated names used by services to a maps the complete set of unrelated names used by services to a
single service name. single service name.
o Other technologies, such as the proposed first party sets [3] or o Other technologies, such as the proposed first party sets [3] or
the abandoned DBOUND [DBOUND] provide domain owners a means to the abandoned DBOUND [DBOUND] provide domain owners a means to
declare some form of equivalence for different names. declare some form of equivalence for different names.
Each of these techniques are imperfect in different ways. They may Each of these techniques are imperfect in different ways. They may
also skew the distribution of queries in ways that might concentrate also skew the distribution of queries in ways that might concentrate
information on particular resolvers. information on particular resolvers. Moreover, resolver choice based
solely on the name to be resolved rather than per-client information
reduces the anonymity set of queries sent to each resolver. In
contrast to a client-based strategy, attackers can predict the target
resolver for a given name using a name-based strategy. This may have
implications for on-path attacker attempts to identify otherwise
encrypted queries. Of course, even a name-based mechanism might use
some non-public information as well for its choice, which might
reduce these issues.
5. Early conclusions 5. Early conclusions
5.1. Analysis conclusions 5.1. Analysis conclusions
Both the client-based and more advanced name-based strategies provide Both the client-based and more advanced name-based strategies may
benefits. The former provides primarily a systemic benefit, while provide benefits. The former may provide primarily a systemic
the latter provides also some privacy benefits to each individual benefit, while the latter may provide also some privacy benefits to
client. However, neither strategy is perfect, and can leak the same each individual client. However, neither strategy is perfect, and
information to multiple resolvers in some cases. can leak the same information to multiple resolvers in some cases.
5.2. Recommendations 5.2. Recommendations
Both strategies are, however, likely generally beneficial in the Both strategies are, however, likely generally beneficial in the
common cases, and can improve the overall privacy situation. And common cases, and can improve the overall privacy situation. And
they are certainly a considerable privacy improvement over a they are certainly a considerable privacy improvement over a
situation where a large number of clients use a single resolver. situation where a large number of clients use a single resolver.
Their use may also reduce any pressures against specific resolvers, Their use may also reduce any pressures against specific resolvers,
as information available in these specific resolvers does not as information available in these specific resolvers does not
skipping to change at page 11, line 15 skipping to change at page 11, line 25
The choice of different resolvers would also need to work well with The choice of different resolvers would also need to work well with
whatever mechanisms exist for failover to alternate resolvers when whatever mechanisms exist for failover to alternate resolvers when
one is not responsive. The same is true of IPv4/IPv6 connectivity, one is not responsive. The same is true of IPv4/IPv6 connectivity,
the availability of communications to specific ports, etc. And the the availability of communications to specific ports, etc. And the
dynamic situation should obviously not lead to extensive leakage to dynamic situation should obviously not lead to extensive leakage to
different resolvers, either. different resolvers, either.
6.4. Query performance 6.4. Query performance
Distribution of queries between resolvers also means that clients are Distribution of queries between resolvers also means that clients are
exposed to greater variations in performance. exposed to greater variations in performance [HBSHF19]. In contrast,
using a single resolver, as would result from the client-based method
in Section 4.1, promotes use of a persistent connection.
6.5. Debugging 6.5. Debugging
The use of multiple resolvers may complicate debugging. The use of multiple resolvers may complicate debugging.
7. Further work 7. Further work
Should there be interest in the deployment of ideas laid out in this Should there be interest in the deployment of ideas laid out in this
memo, further work is needed. There would have to be ways to memo, further work is needed. There would have to be ways to
configure systems to use multiple resolvers, including for instance: configure systems to use multiple resolvers, including for instance:
o Central configuration mechanisms to enable the use of multiple o Central configuration mechanisms to enable the use of multiple
resolvers, perhaps through usual network configuration mechanisms resolvers, perhaps through usual network configuration mechanisms
or choices made by applications using resolver services directly. or choices made by applications using resolver services directly.
It may also be necessary to employ discovery mechanisms, such as, It may also be necessary to employ discovery mechanisms, such as,
e.g., [I-D.schinazi-httpbis-doh-preference-hints] (but see e.g., [I-D.schinazi-httpbis-doh-preference-hints] or
Section 3). [I-D.pauly-dprive-adaptive-dns-privacy] (but see Section 3)
o Mechanisms to allow both failover to working resolvers when a o Mechanisms to allow both failover to working resolvers when a
resolver is unreachable, resolver is unreachable,
o Additional testing for potential operational issues discussed in o Additional testing for potential operational issues discussed in
Section 2 would be beneficial. Section 2 would be beneficial.
Finally, more work is needed to determine factors other than privacy Finally, more work is needed to determine factors other than privacy
that could motivate having queries routed to the same resolver. The that could motivate having queries routed to the same resolver. The
choice between different approaches is often a combination of several choice between different approaches is often a combination of several
skipping to change at page 12, line 29 skipping to change at page 12, line 42
[PMON] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [PMON] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
8.2. Informative References 8.2. Informative References
[DBOUND] Levine, J., "Publishing Organization Boundaries in the [DBOUND] Levine, J., "Publishing Organization Boundaries in the
DNS", draft-levine-dbound-dns-03 (work in progress), April DNS", draft-levine-dbound-dns-03 (work in progress), April
2019. 2019.
[HBSHF19] Austin Hounsel, ., Kevin Borgolte, ., Paul Schmidt, .,
Jordan Holland, ., and . Nick Feamster, "Analyzing the
Costs (and Benefits) of DNS, DoT, andDoH for the Modern
Web", ANRW '19, July 22, 2019, Montreal, QC, Canada ,
n.d., <https://dl.acm.org/doi/10.1145/3340301.3341129>.
[I-D.pauly-dprive-adaptive-dns-privacy]
Kinnear, E., Pauly, T., Wood, C., and P. McManus,
"Adaptive DNS: Improving Privacy of Name Resolution",
draft-pauly-dprive-adaptive-dns-privacy-01 (work in
progress), November 2019.
[I-D.schinazi-httpbis-doh-preference-hints] [I-D.schinazi-httpbis-doh-preference-hints]
Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference
Hints for HTTP", draft-schinazi-httpbis-doh-preference- Hints for HTTP", draft-schinazi-httpbis-doh-preference-
hints-00 (work in progress), July 2019. hints-01 (work in progress), January 2020.
[MSCVUS] Wikipedia, ., "Microsoft Corp. v. United States", [MSCVUS] Wikipedia, ., "Microsoft Corp. v. United States",
https://en.wikipedia.org/wiki/ https://en.wikipedia.org/wiki/
Microsoft_Corp._v._United_States , n.d.. Microsoft_Corp._v._United_States , n.d..
8.3. URIs 8.3. URIs
[1] https://publicsuffix.org/ [1] https://publicsuffix.org/
[2] https://github.com/mozilla-services/shavar-prod- [2] https://github.com/mozilla-services/shavar-prod-
lists/blob/master/disconnect-entitylist.json lists/blob/master/disconnect-entitylist.json
[3] https://github.com/krgovind/first-party-sets [3] https://github.com/krgovind/first-party-sets
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank Christian Huitema, Ari Keraenen, Mark The authors would like to thank Christian Huitema, Ari Keraenen, Mark
Nottingham, Stephen Farrell, Gonzalo Camarillo, Mirja Kuehlewind, Nottingham, Stephen Farrell, Gonzalo Camarillo, Mirja Kuehlewind,
David Allan, Daniel Migault Goran AP Eriksson, and many others for David Allan, Daniel Migault, Goran AP Eriksson, Christopher Wood, and
interesting discussions in this problem space. many others for interesting discussions in this problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Martin Thomson Martin Thomson
Mozilla Mozilla
 End of changes. 21 change blocks. 
30 lines changed or deleted 54 lines changed or added

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