draft-ietf-dprive-rfc7626-bis-08.txt   draft-ietf-dprive-rfc7626-bis-09.txt 
dprive T. Wicinski, Ed. dprive T. Wicinski, Ed.
Internet-Draft October 15, 2020 Internet-Draft March 9, 2021
Obsoletes: 7626 (if approved) Obsoletes: 7626 (if approved)
Intended status: Informational Intended status: Informational
Expires: April 18, 2021 Expires: September 10, 2021
DNS Privacy Considerations DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-08 draft-ietf-dprive-rfc7626-bis-09
Abstract Abstract
This document describes the privacy issues associated with the use of This document describes the privacy issues associated with the use of
the DNS by Internet users. It is intended to be an analysis of the the DNS by Internet users. It provides general observations about
present situation and does not prescribe solutions. This document typical current privacy practices. It is intended to be an analysis
obsoletes RFC 7626. of the present situation and does not prescribe solutions. This
document obsoletes RFC 7626.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 April 18, 2021. This Internet-Draft will expire on September 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 22 skipping to change at page 2, line 24
4.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 6 4.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 6
4.2.1. Data in the DNS Payload . . . . . . . . . . . . . . . 8 4.2.1. Data in the DNS Payload . . . . . . . . . . . . . . . 8
4.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 8 4.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 8
5. Risks On the Wire . . . . . . . . . . . . . . . . . . . . . . 8 5. Risks On the Wire . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Unencrypted Transports . . . . . . . . . . . . . . . . . 8 5.1. Unencrypted Transports . . . . . . . . . . . . . . . . . 8
5.2. Encrypted Transports . . . . . . . . . . . . . . . . . . 10 5.2. Encrypted Transports . . . . . . . . . . . . . . . . . . 10
6. Risks in the Servers . . . . . . . . . . . . . . . . . . . . 11 6. Risks in the Servers . . . . . . . . . . . . . . . . . . . . 11
6.1. In the Recursive Resolvers . . . . . . . . . . . . . . . 12 6.1. In the Recursive Resolvers . . . . . . . . . . . . . . . 12
6.1.1. Resolver Selection . . . . . . . . . . . . . . . . . 12 6.1.1. Resolver Selection . . . . . . . . . . . . . . . . . 12
6.1.2. Active Attacks on Resolver Configuration . . . . . . 14 6.1.2. Active Attacks on Resolver Configuration . . . . . . 14
6.1.3. Blocking of User Selected DNS Resolution Services . . 14 6.1.3. Blocking of DNS Resolution Services . . . . . . . . . 15
6.1.4. Encrypted Transports and Recursive Resolvers . . . . 15 6.1.4. Encrypted Transports and Recursive Resolvers . . . . 15
6.2. In the Authoritative Name Servers . . . . . . . . . . . . 16 6.2. In the Authoritative Name Servers . . . . . . . . . . . . 16
7. Other risks . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Other risks . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Re-identification and Other Inferences . . . . . . . . . 17 7.1. Re-identification and Other Inferences . . . . . . . . . 17
7.2. More Information . . . . . . . . . . . . . . . . . . . . 18 7.2. More Information . . . . . . . . . . . . . . . . . . . . 18
8. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 18 8. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 18
9. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 20
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Updates since RFC7626 . . . . . . . . . . . . . . . 27 Appendix A. Updates since RFC7626 . . . . . . . . . . . . . . . 27
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document is an analysis of the DNS privacy issues, in the spirit This document is an analysis of the DNS privacy issues, in the spirit
of Section 8 of [RFC6973]. of Section 8 of [RFC6973].
The Domain Name System (DNS) is specified in [RFC1034], [RFC1035], The Domain Name System (DNS) is specified in [RFC1034], [RFC1035],
and many later RFCs, which have never been consolidated. It is one and many later RFCs, which have never been consolidated. It is one
of the most important infrastructure components of the Internet and of the most important infrastructure components of the Internet and
often ignored or misunderstood by Internet users (and even by many often ignored or misunderstood by Internet users (and even by many
skipping to change at page 4, line 13 skipping to change at page 4, line 15
the point of view of privacy, these forwarders are like resolvers, the point of view of privacy, these forwarders are like resolvers,
except that they do not see all of the requests being made (due to except that they do not see all of the requests being made (due to
caching in the first resolver). caching in the first resolver).
At the time of writing, almost all this DNS traffic is currently sent At the time of writing, almost all this DNS traffic is currently sent
unencrypted. However, there is increasing deployment of DNS-over-TLS unencrypted. However, there is increasing deployment of DNS-over-TLS
(DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in
mobile devices, browsers, and by providers of anycast recursive DNS mobile devices, browsers, and by providers of anycast recursive DNS
resolution services. There are a few cases where there is some resolution services. There are a few cases where there is some
alternative channel encryption, for instance, in an IPsec VPN tunnel, alternative channel encryption, for instance, in an IPsec VPN tunnel,
at least between the stub resolver and the resolver. at least between the stub resolver and the resolver. Some recent
analysis on service quality of encrypted DNS traffic can be found in
[dns-over-encryption].
Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
This has practical consequences when considering encryption of the This has practical consequences when considering encryption of the
traffic as a possible privacy technique. Some encryption solutions traffic as a possible privacy technique. Some encryption solutions
are only designed for TCP, not UDP, although new solutions are still are only designed for TCP, not UDP, although new solutions are still
emerging [I-D.ietf-quic-transport] [I-D.ietf-dprive-dnsoquic]. emerging [I-D.ietf-quic-transport] [I-D.ietf-dprive-dnsoquic].
Another important point to keep in mind when analyzing the privacy Another important point to keep in mind when analyzing the privacy
issues of DNS is the fact that DNS requests received by a server are issues of DNS is the fact that DNS requests received by a server are
triggered by different reasons. Let's assume an eavesdropper wants triggered by different reasons. Let's assume an eavesdropper wants
skipping to change at page 5, line 15 skipping to change at page 5, line 20
explicit actions. For instance, just reading a local HTML page, even explicit actions. For instance, just reading a local HTML page, even
without selecting the hyperlinks, may trigger DNS requests. without selecting the hyperlinks, may trigger DNS requests.
For privacy-related terms, the terminology is from [RFC6973]. For privacy-related terms, the terminology is from [RFC6973].
2. Scope 2. Scope
This document focuses mostly on the study of privacy risks for the This document focuses mostly on the study of privacy risks for the
end user (the one performing DNS requests). The risks of pervasive end user (the one performing DNS requests). The risks of pervasive
surveillance [RFC7258] are considered as well as risks coming from a surveillance [RFC7258] are considered as well as risks coming from a
more focused surveillance. more focused surveillance. In this document, the term 'end user' is
used as defined in [RFC8890].
This document does not attempt a comparison of specific privacy This document does not attempt a comparison of specific privacy
protections provided by individual networks or organizations, it protections provided by individual networks or organizations, it
makes only general observations about typical current practices. makes only general observations about typical current practices.
Privacy risks for the holder of a zone (the risk that someone gets Privacy risks for the holder of a zone (the risk that someone gets
the data) are discussed in [RFC5936] and [RFC5155]. the data) are discussed in [RFC5936] and [RFC5155].
Privacy risks for recursive operators (including access providers and Privacy risks for recursive operators (including access providers and
operators in enterprise networks) such as leakage of private operators in enterprise networks) such as leakage of private
skipping to change at page 6, line 27 skipping to change at page 6, line 30
lack of search capabilities, only a given QNAME will reveal the lack of search capabilities, only a given QNAME will reveal the
resource records associated with that name (or that name's non- resource records associated with that name (or that name's non-
existence). In other words: one needs to know what to ask for, in existence). In other words: one needs to know what to ask for, in
order to receive a response. There are many ways in which supposedly order to receive a response. There are many ways in which supposedly
"private" resources currently leak. A few examples are DNSSEC NSEC "private" resources currently leak. A few examples are DNSSEC NSEC
zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The
zone transfer QTYPE [RFC5936] is often blocked or restricted to zone transfer QTYPE [RFC5936] is often blocked or restricted to
authenticated/authorized access to enforce this difference (and maybe authenticated/authorized access to enforce this difference (and maybe
for other reasons). for other reasons).
Another differencce between the DNS data and a particular DNS Another difference between the DNS data and a particular DNS
transaction (i.e., a DNS name lookup). DNS data and the results of a transaction (i.e., a DNS name lookup). DNS data and the results of a
DNS query are public, within the boundaries described above, and may DNS query are public, within the boundaries described above, and may
not have any confidentiality requirements. However, the same is not not have any confidentiality requirements. However, the same is not
true of a single transaction or a sequence of transactions; those true of a single transaction or a sequence of transactions; those
transactions are not / should not be public. A single transactions transactions are not / should not be public. A single transaction
reveals both the originator of the query and the query contents which reveals both the originator of the query and the query contents which
potentially leaks sensitive information about a specific user. A potentially leaks sensitive information about a specific user. A
typical example from outside the DNS world is: the web site of typical example from outside the DNS world is: the web site of
Alcoholics Anonymous is public; the fact that you visit it should not Alcoholics Anonymous is public; the fact that you visit it should not
be. Furthermore, the ability to link queries reveals information be. Furthermore, the ability to link queries reveals information
about individual use patterns. about individual use patterns.
4.2. Data in the DNS Request 4.2. Data in the DNS Request
The DNS request includes many fields, but two of them seem The DNS request includes many fields, but two of them seem
particularly relevant for the privacy issues: the QNAME and the particularly relevant for the privacy issues: the QNAME and the
source IP address. "source IP address" is used in a loose sense of source IP address. "source IP address" is used in a loose sense of
"source IP address + maybe source port number", because the port "source IP address + maybe source port number", because the port
number is also in the request and can be used to differentiate number is also in the request and can be used to differentiate
between several users sharing an IP address (behind a Carrier-Grade between several users sharing an IP address (behind a Carrier-Grade
NAT (CGN), for instance [RFC6269]). NAT (CGN), for instance [RFC6269]).
The QNAME is the full name sent by the user. It gives information The QNAME is the full name sent by the user. It gives information
about what the user does ("What are the MX records of example.net?" about what the user does ("What are the MX records of example.net?"
means he probably wants to send email to someone at example.net, means he probably wants to send email to someone at example.net,
which may be a domain used by only a few persons and is therefore which may be a domain used by only a few persons and is therefore
very revealing about communication relationships). Some QNAMEs are very revealing about communication relationships). Some QNAMEs are
skipping to change at page 7, line 38 skipping to change at page 7, line 42
resolver, the source IP address is the address of the user's machine. resolver, the source IP address is the address of the user's machine.
Therefore, all the issues and warnings about collection of IP Therefore, all the issues and warnings about collection of IP
addresses apply here. For the communication between the recursive addresses apply here. For the communication between the recursive
resolver and the authoritative name servers, the source IP address resolver and the authoritative name servers, the source IP address
has a different meaning; it does not have the same status as the has a different meaning; it does not have the same status as the
source address in an HTTP connection. It can be typically the IP source address in an HTTP connection. It can be typically the IP
address of the recursive resolver that, in a way, "hides" the real address of the recursive resolver that, in a way, "hides" the real
user. However, hiding does not always work. Sometimes EDNS(0) user. However, hiding does not always work. Sometimes EDNS(0)
Client subnet [RFC7871] is used (see one privacy analysis in Client subnet [RFC7871] is used (see one privacy analysis in
[denis-edns-client-subnet]). Sometimes the end user has a personal [denis-edns-client-subnet]). Sometimes the end user has a personal
recursive resolver on her machine. In both cases, the IP address recursive resolver on their machine. In both cases, the IP address
originating queries to the authoritative server is as sensitive as it originating queries to the authoritative server is as sensitive as it
is for HTTP [sidn-entrada]. is for HTTP [sidn-entrada].
A note about IP addresses: there is currently no IETF document that A note about IP addresses: there is currently no IETF document that
describes in detail all the privacy issues around IP addressing in describes in detail all the privacy issues around IP addressing in
general, although [RFC7721] does discuss privacy considerations for general, although [RFC7721] does discuss privacy considerations for
IPv6 address generation mechanisms. In the meantime, the discussion IPv6 address generation mechanisms. In the meantime, the discussion
here is intended to include both IPv4 and IPv6 source addresses. For here is intended to include both IPv4 and IPv6 source addresses. For
a number of reasons, their assignment and utilization characteristics a number of reasons, their assignment and utilization characteristics
are different, which may have implications for details of information are different, which may have implications for details of information
skipping to change at page 9, line 32 skipping to change at page 9, line 35
o The recursive resolver can be on the end user's device. In o The recursive resolver can be on the end user's device. In
(currently) a small number of cases, individuals may choose to (currently) a small number of cases, individuals may choose to
operate their own DNS resolver on their local machine. In this operate their own DNS resolver on their local machine. In this
case, the attack surface for the connection between the stub case, the attack surface for the connection between the stub
resolver and the caching resolver is limited to that single resolver and the caching resolver is limited to that single
machine. The recursive resolver will expose data to authoritative machine. The recursive resolver will expose data to authoritative
resolvers as discussed in Section 6.2. resolvers as discussed in Section 6.2.
o The recursive resolver may be at the local network edge. For o The recursive resolver may be at the local network edge. For
many/most enterprise networks and for some residential users, the many/most enterprise networks and for some residential networks,
caching resolver may exist on a server at the edge of the local the caching resolver may exist on a server at the edge of the
network. In this case, the attack surface is the local network. local network. In this case, the attack surface is the local
Note that in large enterprise networks, the DNS resolver may not network. Note that in large enterprise networks, the DNS resolver
be located at the edge of the local network but rather at the edge may not be located at the edge of the local network but rather at
of the overall enterprise network. In this case, the enterprise the edge of the overall enterprise network. In this case, the
network could be thought of as similar to the Internet Access enterprise network could be thought of as similar to the Internet
Provider (IAP) network referenced below. Access Provider (IAP) network referenced below.
o The recursive resolver can be in the IAP network. For most o The recursive resolver can be in the IAP network. For most
residential users and potentially other networks, the typical case residential networks and potentially other networks, the typical
is for the end user's device to be configured (typically case is for the user's device to be configured (typically
automatically through DHCP or RA options) with the addresses of automatically through DHCP or RA options) with the addresses of
the DNS proxy in the Customer Premise Equipment (CPE), which in the DNS proxy in the Customer Premise Equipment (CPE), which in
turns points to the DNS recursive resolvers at the IAP. The turns points to the DNS recursive resolvers at the IAP. The
attack surface for on-the-wire attacks is therefore from the end attack surface for on-the-wire attacks is therefore from the end
user system across the local network and across the IAP network to user system across the local network and across the IAP network to
the IAP's recursive resolvers. the IAP's recursive resolvers.
o The recursive resolver can be a public DNS service (or a privately o The recursive resolver can be a public DNS service (or a privately
run DNS resolver hosted on the public internet). Some machines run DNS resolver hosted on the public internet). Some machines
may be configured to use public DNS resolvers such as those may be configured to use public DNS resolvers such as those
operated by Google Public DNS or OpenDNS. The end user may have operated by Google Public DNS or OpenDNS. The user may have
configured their machine to use these DNS recursive resolvers configured their machine to use these DNS recursive resolvers
themselves -- or their IAP may have chosen to use the public DNS themselves -- or their IAP may have chosen to use the public DNS
resolvers rather than operating their own resolvers. In this resolvers rather than operating their own resolvers. In this
case, the attack surface is the entire public Internet between the case, the attack surface is the entire public Internet between the
end user's connection and the public DNS service. It can be noted user's connection and the public DNS service. It can be noted
that if the user selects a single resolver with a small client that if the user selects a single resolver with a small client
population (even when using an encrypted transport) it can population (even when using an encrypted transport) it can
actually serve to aid tracking of that user as they move across actually serve to aid tracking of that user as they move across
network environments. network environments.
It is also noted that typically a device connected _only_ to a modern It is also noted that typically a device connected _only_ to a modern
cellular network is cellular network is
o directly configured with only the recursive resolvers of the IAP o directly configured with only the recursive resolvers of the IAP
and and
skipping to change at page 11, line 25 skipping to change at page 11, line 29
o the maximum number of messages to send or o the maximum number of messages to send or
o a maximum connection time before closing a connections and re- o a maximum connection time before closing a connections and re-
opening. opening.
If libraries or applications offer user configuration of such options If libraries or applications offer user configuration of such options
(e.g. [getdns]) then they could in principle help to identify a (e.g. [getdns]) then they could in principle help to identify a
specific user. Users may want to use only the defaults to avoid this specific user. Users may want to use only the defaults to avoid this
issue. issue.
Whilst there are known attacks on older versions of TLS the most Whilst there are known attacks on older versions of TLS, the most
recent recommendations [RFC7525] and the development of TLS 1.3 recent recommendations [RFC7525] and the development of TLS 1.3
[RFC8446] largely mitigate those. [RFC8446] largely mitigate those.
Traffic analysis of unpadded encrypted traffic is also possible Traffic analysis of unpadded encrypted traffic is also possible
[pitfalls-of-dns-encryption] because the sizes and timing of [pitfalls-of-dns-encryption] because the sizes and timing of
encrypted DNS requests and responses can be correlated to unencrypted encrypted DNS requests and responses can be correlated to unencrypted
DNS requests upstream of a recursive resolver. DNS requests upstream of a recursive resolver.
6. Risks in the Servers 6. Risks in the Servers
skipping to change at page 12, line 40 skipping to change at page 12, line 44
resolver. These individual changes, including the change in DNS resolver. These individual changes, including the change in DNS
resolver, are not normally communicated directly to the user by the resolver, are not normally communicated directly to the user by the
OS when the network is joined. The choice of network has OS when the network is joined. The choice of network has
historically determined the default system DNS resolver selection; historically determined the default system DNS resolver selection;
the two are directly coupled in this model. the two are directly coupled in this model.
The vast majority of users do not change their default system DNS The vast majority of users do not change their default system DNS
settings and so implicitly accept the network settings for DNS. The settings and so implicitly accept the network settings for DNS. The
network resolvers have therefore historically been the sole network resolvers have therefore historically been the sole
destination for all of the DNS queries from a device. These destination for all of the DNS queries from a device. These
resolvers may have may have varied privacy policies depending on the resolvers may have varied privacy policies depending on the network.
network. Privacy policies for these servers may or may not be Privacy policies for these servers may or may not be available and
available and users need to be aware that privacy guarantees will users need to be aware that privacy guarantees will vary with the
vary with network. network.
All major OS's expose the system DNS settings and allow users to All major OS's expose the system DNS settings and allow users to
manually override them if desired. manually override them if desired.
More recently, some networks and end users have actively chosen to More recently, some networks and users have actively chosen to use a
use a large public resolver, e.g., Google Public DNS [3], Cloudflare large public resolver, e.g., Google Public DNS [3], Cloudflare [4],
[4], or Quad9 [5]. There can be many reasons: cost considerations or Quad9 [5]. There can be many reasons: cost considerations for
for network operators, better reliability or anti-censorship network operators, better reliability or anti-censorship
considerations are just a few. Such services typically do provide a considerations are just a few. Such services typically do provide a
privacy policy and the end user can get an idea of the data collected privacy policy and the user can get an idea of the data collected by
by such operators by reading one e.g., Google Public DNS - Your such operators by reading one e.g., Google Public DNS - Your Privacy
Privacy [6]. [6].
In general, as with many other protocols, issues around In general, as with many other protocols, issues around
centralization also arise with DNS. The picture is fluid with centralization also arise with DNS. The picture is fluid with
several competing factors contributing which can also vary by several competing factors contributing which can also vary by
geographic region. These include: geographic region. These include:
o ISP outsourcing, including to third party and public resolvers o ISP outsourcing, including to third party and public resolvers
o regional market domination by one or only a few ISPs o regional market domination by one or only a few ISPs
o applications directing DNS traffic by default to a limited subset o applications directing DNS traffic by default to a limited subset
of resolvers, see Section 6.1.1.2 of resolvers, see Section 6.1.1.2
An increased proportion of the global DNS resolution traffic being An increased proportion of the global DNS resolution traffic being
served by only a few entities means that the privacy considerations served by only a few entities means that the privacy considerations
for end users are highly dependent on the privacy policies and for users are highly dependent on the privacy policies and practices
practices of those entities. Many of the issues around of those entities. Many of the issues around centralization are
centralization are discussed in discussed in [centralisation-and-data-sovereignty].
[centralisation-and-data-sovereignty].
6.1.1.1. Dynamic Discovery of DoH and Strict DoT 6.1.1.1. Dynamic Discovery of DoH and Strict DoT
Whilst support for opportunistic DoT can be determined by probing a Whilst support for opportunistic DoT can be determined by probing a
resolver on port 853, there is currently no standardized discovery resolver on port 853, there is currently no standardized discovery
mechanism for DoH and Strict DoT servers. mechanism for DoH and Strict DoT servers.
This means that clients which might want to dynamically discover such This means that clients which might want to dynamically discover such
encrypted services, and where users are willing to trust such encrypted services, and where users are willing to trust such
services, are not able to do so. At the time of writing, efforts to services, are not able to do so. At the time of writing, efforts to
skipping to change at page 13, line 50 skipping to change at page 14, line 7
Encrypted DNS Deployment Initiative [EDDI]. Encrypted DNS Deployment Initiative [EDDI].
6.1.1.2. Application-specific Resolver Selection 6.1.1.2. Application-specific Resolver Selection
An increasing number of applications are offering application- An increasing number of applications are offering application-
specific encrypted DNS resolution settings, rather than defaulting to specific encrypted DNS resolution settings, rather than defaulting to
using only the system resolver. A variety of heuristics and using only the system resolver. A variety of heuristics and
resolvers are available in different applications including hard- resolvers are available in different applications including hard-
coded lists of recognized DoH/DoT servers. coded lists of recognized DoH/DoT servers.
Users will only be aware of and have the ability to control such Generally, users are not aware of application specific DNS settings,
settings if applications provide the following functions: and may not have control over those settings. To address these
limitations, users will only be aware of and have the ability to
control such settings if applications provide the following
functions:
o communicate clearly to users the change when the default o communicate clearly to users the change when the default
application resolver changes away from the system resolver application resolver changes away from the system resolver
o provide configuration options to change the default o provide configuration options to change the default application
resolver, including a choice to always use the system resolver
o provide configuration options to always use the system resolver o provide mechanisms for users to locally inspect, selectively
forward, and filter queries (either via the application itself or use
of the system resolver)
Application-specific changes to default destinations for users' DNS Application-specific changes to default destinations for users' DNS
queries might increase or decrease user privacy - it is highly queries might increase or decrease user privacy - it is highly
dependent on the network context and the application-specific dependent on the network context and the application-specific
default. This is an area of active debate and the IETF is working on default. This is an area of active debate and the IETF is working on
a number of issues related to application-specific DNS settings. a number of issues related to application-specific DNS settings.
6.1.2. Active Attacks on Resolver Configuration 6.1.2. Active Attacks on Resolver Configuration
The previous section discussed DNS privacy, assuming that all the The previous section discussed DNS privacy, assuming that all the
skipping to change at page 14, line 38 skipping to change at page 15, line 5
control any insecure DNS resolution, both passively monitoring the control any insecure DNS resolution, both passively monitoring the
queries and responses and substituting their own responses. Even if queries and responses and substituting their own responses. Even if
encrypted DNS such as DoH or DoT is used, unless the client has been encrypted DNS such as DoH or DoT is used, unless the client has been
configured in a secure way with the server identity, an active configured in a secure way with the server identity, an active
attacker can impersonate the server. This implies that opportunistic attacker can impersonate the server. This implies that opportunistic
modes of DoH/DoT as well as modes where the client learns of the DoH/ modes of DoH/DoT as well as modes where the client learns of the DoH/
DoT server via in-network mechanisms such as DHCP are vulnerable to DoT server via in-network mechanisms such as DHCP are vulnerable to
attack. In addition, if the client is compromised, the attacker can attack. In addition, if the client is compromised, the attacker can
replace the DNS configuration with one of its own choosing. replace the DNS configuration with one of its own choosing.
6.1.3. Blocking of User Selected DNS Resolution Services 6.1.3. Blocking of DNS Resolution Services
User privacy can also be at risk if there is blocking of access to User privacy can also be at risk if there is blocking of access to
remote recursive servers that offer encrypted transports e.g., when remote recursive servers that offer encrypted transports e.g., when
the local resolver does not offer encryption and/or has very poor the local resolver does not offer encryption and/or has very poor
privacy policies. For example, active blocking of port 853 for DoT privacy policies. For example, active blocking of port 853 for DoT
or of specific IP addresses could restrict the resolvers available to or of specific IP addresses could restrict the resolvers available to
the user. The extent of the risk to end user privacy is highly the user. The extent of the risk to user privacy is highly dependent
dependent on the specific network and user context; a user on a on the specific network and user context; a user on a network that is
network that is known to perform surveillance would be compromised if known to perform surveillance would be compromised if they could not
they could not access such services, whereas a user on a trusted access such services, whereas a user on a trusted network might have
network might have no privacy motivation to do so. no privacy motivation to do so.
As a matter of policy, some recursive resolvers use their position in As a matter of policy, some recursive resolvers use their position in
the query path to selectively block access to certain DNS records. the query path to selectively block access to certain DNS records.
This is a form of Rendezvous-Based Blocking as described in This is a form of Rendezvous-Based Blocking as described in
Section 4.3 of [RFC7754]. Such blocklists often include servers Section 4.3 of [RFC7754]. Such blocklists often include servers
known to be used for malware, bots or other security risks. In order known to be used for malware, bots or other security risks. In order
to prevent circumvention of their blocking policies, some networks to prevent circumvention of their blocking policies, some networks
also block access to resolvers with incompatible policies. also block access to resolvers with incompatible policies.
It is also noted that attacks on remote resolver services, e.g., It is also noted that attacks on remote resolver services, e.g.,
DDoS, could force users to switch to other services that do not offer DDoS, could force users to switch to other services that do not offer
encrypted transports for DNS. encrypted transports for DNS.
skipping to change at page 16, line 28 skipping to change at page 16, line 43
of authoritative name servers are limited by caching; they see only of authoritative name servers are limited by caching; they see only
the requests for which the answer was not in the cache. For the requests for which the answer was not in the cache. For
aggregated statistics ("What is the percentage of LOC queries?"), aggregated statistics ("What is the percentage of LOC queries?"),
this is sufficient, but it prevents an observer from seeing this is sufficient, but it prevents an observer from seeing
everything. Similarly the increasing deployment of QNAME everything. Similarly the increasing deployment of QNAME
minimisation [ripe-qname-measurements] reduces the data visible at minimisation [ripe-qname-measurements] reduces the data visible at
the authoritative name server. Still, the authoritative name servers the authoritative name server. Still, the authoritative name servers
see a part of the traffic, and this subset may be sufficient to see a part of the traffic, and this subset may be sufficient to
violate some privacy expectations. violate some privacy expectations.
Also, the end user often has some legal/contractual link with the Also, the user often has some legal/contractual link with the
recursive resolver (he has chosen the IAP, or he has chosen to use a recursive resolver (he has chosen the IAP, or he has chosen to use a
given public resolver), while having no control and perhaps no given public resolver), while having no control and perhaps no
awareness of the role of the authoritative name servers and their awareness of the role of the authoritative name servers and their
observation abilities. observation abilities.
As noted before, using a local resolver or a resolver close to the As noted before, using a local resolver or a resolver close to the
machine decreases the attack surface for an on-the-wire eavesdropper. machine decreases the attack surface for an on-the-wire eavesdropper.
But it may decrease privacy against an observer located on an But it may decrease privacy against an observer located on an
authoritative name server. This authoritative name server will see authoritative name server. This authoritative name server will see
the IP address of the end client instead of the address of a big the IP address of the end client instead of the address of a big
skipping to change at page 17, line 13 skipping to change at page 17, line 26
even "junk" can leak information; for instance, if there is a typing even "junk" can leak information; for instance, if there is a typing
error in the TLD, the user will send data to a TLD that is not the error in the TLD, the user will send data to a TLD that is not the
usual one.) usual one.)
Many domains, including TLDs, are partially hosted by third-party Many domains, including TLDs, are partially hosted by third-party
servers, sometimes in a different country. The contracts between the servers, sometimes in a different country. The contracts between the
domain manager and these servers may or may not take privacy into domain manager and these servers may or may not take privacy into
account. Whatever the contract, the third-party hoster may be honest account. Whatever the contract, the third-party hoster may be honest
or not but, in any case, it will have to follow its local laws. For or not but, in any case, it will have to follow its local laws. For
example, requests to a given ccTLD may go to servers managed by example, requests to a given ccTLD may go to servers managed by
organizations outside of the ccTLD's country. End users may not organizations outside of the ccTLD's country. Users may not
anticipate that, when doing a security analysis. anticipate that, when doing a security analysis.
Also, it seems (see the survey described in [aeris-dns]) that there Also, it seems (see the survey described in [aeris-dns]) that there
is a strong concentration of authoritative name servers among is a strong concentration of authoritative name servers among
"popular" domains (such as the Alexa Top N list). For instance, "popular" domains (such as the Alexa Top N list). For instance,
among the Alexa Top 100K [7], one DNS provider hosts today 10% of the among the Alexa Top 100K [7], one DNS provider hosts today 10% of the
domains. The ten most important DNS providers host together one domains. The ten most important DNS providers host together one
third of the domains. With the control (or the ability to sniff the third of the domains. With the control (or the ability to sniff the
traffic) of a few name servers, you can gather a lot of information. traffic) of a few name servers, you can gather a lot of information.
skipping to change at page 21, line 42 skipping to change at page 22, line 5
<https://00f.net/2013/08/07/edns-client-subnet/>. <https://00f.net/2013/08/07/edns-client-subnet/>.
[ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002, [ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002,
<http://www.caida.org/projects/ditl/>. <http://www.caida.org/projects/ditl/>.
[dns-footprint] [dns-footprint]
Stoner, E., "DNS Footprint of Malware", OARC Workshop, Stoner, E., "DNS Footprint of Malware", OARC Workshop,
October 2010, <https://www.dns-oarc.net/files/workshop- October 2010, <https://www.dns-oarc.net/files/workshop-
201010/OARC-ers-20101012.pdf>. 201010/OARC-ers-20101012.pdf>.
[dns-over-encryption]
Lu, C., Liu, B., Li, Z., Hao, S., Duan, H., Zhang, M.,
Leng, C., Liu, Y., Zhang, Z., and J. Wu, "An End-to-End,
Large-Scale Measurement of DNS-over-Encryption", IMC
'19 Amsterdam, Netherlands, DOI 10.1145/3355369.3355580,
October 2019,
<http://dl.acm.org/citation.cfm?id=3355369.3355580>.
[dnsmezzo] [dnsmezzo]
Bortzmeyer, S., "DNSmezzo", 2009, Bortzmeyer, S., "DNSmezzo", 2009,
<http://www.dnsmezzo.net/>. <http://www.dnsmezzo.net/>.
[EDDI] EDDI, "Encrypted DNS Deployment Initiative", 2020, [EDDI] EDDI, "Encrypted DNS Deployment Initiative", 2020,
<https://www.encrypted-dns.org>. <https://www.encrypted-dns.org>.
[fangming-hori-sakurai] [fangming-hori-sakurai]
Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of
Privacy Disclosure in DNS Query", 2007 International Privacy Disclosure in DNS Query", 2007 International
skipping to change at page 23, line 8 skipping to change at page 23, line 19
[I-D.ietf-dprive-bcp-op] [I-D.ietf-dprive-bcp-op]
Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A.
Mankin, "Recommendations for DNS Privacy Service Mankin, "Recommendations for DNS Privacy Service
Operators", draft-ietf-dprive-bcp-op-14 (work in Operators", draft-ietf-dprive-bcp-op-14 (work in
progress), July 2020. progress), July 2020.
[I-D.ietf-dprive-dnsoquic] [I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf- of DNS over Dedicated QUIC Connections", draft-ietf-
dprive-dnsoquic-00 (work in progress), April 2020. dprive-dnsoquic-01 (work in progress), October 2020.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-31 (work and Secure Transport", draft-ietf-quic-transport-34 (work
in progress), September 2020. in progress), January 2021.
[morecowbell] [morecowbell]
Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
"NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January
2015, <https://pdfs.semanticscholar.org/2610/2b99bdd6a258a 2015, <https://pdfs.semanticscholar.org/2610/2b99bdd6a258a
98740af8217ba8da8a1e4fa.pdf>. 98740af8217ba8da8a1e4fa.pdf>.
[packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries [packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries
against PCAP-files", 2011, against PCAP-files", 2011,
<https://github.com/DNS-OARC/PacketQ>. <https://github.com/DNS-OARC/PacketQ>.
skipping to change at page 25, line 45 skipping to change at page 26, line 10
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8744] Huitema, C., "Issues and Requirements for Server Name [RFC8744] Huitema, C., "Issues and Requirements for Server Name
Identification (SNI) Encryption in TLS", RFC 8744, Identification (SNI) Encryption in TLS", RFC 8744,
DOI 10.17487/RFC8744, July 2020, DOI 10.17487/RFC8744, July 2020,
<https://www.rfc-editor.org/info/rfc8744>. <https://www.rfc-editor.org/info/rfc8744>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020,
<https://www.rfc-editor.org/info/rfc8890>.
[ripe-qname-measurements] [ripe-qname-measurements]
Vries, W., "Making the DNS More Private with QNAME Vries, W., "Making the DNS More Private with QNAME
Minimisation", April 2019, Minimisation", April 2019,
<https://labs.ripe.net/Members/wouter_de_vries/make-dns-a- <https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-
bit-more-private-with-qname-minimisation>. bit-more-private-with-qname-minimisation>.
[sidn-entrada] [sidn-entrada]
Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.
Simon, "A privacy framework for 'DNS big data' Simon, "A privacy framework for 'DNS big data'
applications", November 2014, applications", November 2014,
skipping to change at page 27, line 7 skipping to change at page 27, line 20
[7] https://www.alexa.com/topsites [7] https://www.alexa.com/topsites
[8] https://theintercept.com/document/2014/03/12/nsa-gchqs- [8] https://theintercept.com/document/2014/03/12/nsa-gchqs-
quantumtheory-hacking-tactics/ quantumtheory-hacking-tactics/
[9] https://www.eugdpr.org/the-regulation.html [9] https://www.eugdpr.org/the-regulation.html
Appendix A. Updates since RFC7626 Appendix A. Updates since RFC7626
Update many references; Add discussions of encrypted transports Update many references; Added discussions of encrypted transports
including DoT and DoH; Added section on DNS payload; Add section on including DoT and DoH; Added section on DNS payload; Added section on
authentication of servers; Add section on blocking of services. With authentication of servers; Added section on blocking of services.
the publishing of RFC7816 on QNAME minimisation, text, references, With the publishing of RFC7816 on QNAME minimisation, text,
and initial attempts to measure deployment were added to reflect references, and initial attempts to measure deployment were added to
this. The text and references on the Snowden revelations were reflect this. The text and references on the Snowden revelations
updated. were updated.
The "Risks overview" section was changed to "Scope" to help clarify The "Risks overview" section was changed to "Scope" to help clarify
the risks being considered. Text was adding on cellular network DNS, the risks being considered. Text was adding on cellular network DNS,
blocking and security. Considerations for recursive resolvers were blocking and security. Considerations for recursive resolvers were
collected and placed together. Addded a discussion on resolver collected and placed together. Addded a discussion on resolver
selection. selection.
Appendix B. Changelog Appendix B. Changelog
draft-ietf-dprive-rfc7626-bis-05 draft-ietf-dprive-rfc7626-bis-08
o Second batch of Editorial updates from IESG last call o Second batch of Editorial updates from IESG last call
draft-ietf-dprive-rfc7626-bis-07 draft-ietf-dprive-rfc7626-bis-07
o First batch of Editorial updates from IESG last call o First batch of Editorial updates from IESG last call
draft-ietf-dprive-rfc7626-bis-06 draft-ietf-dprive-rfc7626-bis-06
o Removed Sara and Stephane as editors, made chairs as Editor. o Removed Sara and Stephane as editors, made chairs as Editor.
skipping to change at page 27, line 40 skipping to change at page 28, line 4
draft-ietf-dprive-rfc7626-bis-06 draft-ietf-dprive-rfc7626-bis-06
o Removed Sara and Stephane as editors, made chairs as Editor. o Removed Sara and Stephane as editors, made chairs as Editor.
o Replaced the text in 6.1.1.2 with the text from the -04 version. o Replaced the text in 6.1.1.2 with the text from the -04 version.
o Clarified text about resolver selection in 6.1.1. o Clarified text about resolver selection in 6.1.1.
draft-ietf-dprive-rfc7626-bis-05 draft-ietf-dprive-rfc7626-bis-05
o Editorial updates from second IESG last call o Editorial updates from second IESG last call
o Section renumbering as suggested by Vittorio Bertola o Section renumbering as suggested by Vittorio Bertola
draft-ietf-dprive-rfc7626-bis-04 draft-ietf-dprive-rfc7626-bis-04
o Tsvart review: Add reference to DNS-over-QUIC, fix typo. o Tsvart review: Add reference to DNS-over-QUIC, fix typo.
o Secdir review: Add text in Section 3 on devices using many o Secdir review: Add text in Section 3 on devices using many
networks. Update bullet in 3.4.1 on cellular encryption. networks.
o Update bullet in 3.4.1 on cellular encryption.
o Section 3.5.1.1 - re-work the section to try to address multiple o Section 3.5.1.1 - re-work the section to try to address multiple
comments. comments.
o Section 3.5.1.4 - remove this section as now covered by 3.5.1.1. o Section 3.5.1.4 - remove this section as now covered by 3.5.1.1.
o Section 3.5.1.5.2 - Remove several paragraphs and more directly o Section 3.5.1.5.2 - Remove several paragraphs and more directly
reference RFC8484 by including bullet points quoting text from reference RFC8484 by including bullet points quoting text from
Section 8.2 of RFC8484. Retain the last 2 paragraphs as they are Section 8.2 of RFC8484. Retain the last 2 paragraphs as they are
information for users, not implementors. information for users, not implementors.
 End of changes. 40 change blocks. 
71 lines changed or deleted 92 lines changed or added

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