draft-ietf-dprive-rfc7626-bis-05.txt   draft-ietf-dprive-rfc7626-bis-06.txt 
dprive S. Bortzmeyer dprive T. Wicinski, Ed.
Internet-Draft AFNIC Internet-Draft September 22, 2020
Obsoletes: 7626 (if approved) S. Dickinson Obsoletes: 7626 (if approved)
Intended status: Informational Sinodun IT Intended status: Informational
Expires: November 5, 2020 May 4, 2020 Expires: March 26, 2021
DNS Privacy Considerations DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-05 draft-ietf-dprive-rfc7626-bis-06
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 is intended to be an analysis of the
present situation and does not prescribe solutions. This document present situation and does not prescribe solutions. This document
obsoletes RFC 7626. 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 http://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 November 5, 2020. This Internet-Draft will expire on March 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
(http://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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . 15 6.1.3. Blocking of User Selected DNS Resolution Services . . 14
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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 15.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
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 9, line 25 skipping to change at page 9, line 25
The attack surface between the stub resolver and the rest of the The attack surface between the stub resolver and the rest of the
world can vary widely depending upon how the end user's device is world can vary widely depending upon how the end user's device is
configured. By order of increasing attack surface: configured. By order of increasing attack surface:
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. machine. The recursive resolver will expose data to authoritative
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 users, the
caching resolver may exist on a server at the edge of the local caching resolver may exist on a server at the edge of the local
network. In this case, the attack surface is the local network. network. In this case, the attack surface is the local network.
Note that in large enterprise networks, the DNS resolver may not Note that in large enterprise networks, the DNS resolver may not
be located at the edge of the local network but rather at the edge be located at the edge of the local network but rather at the edge
of the overall enterprise network. In this case, the enterprise of the overall enterprise network. In this case, the enterprise
network could be thought of as similar to the Internet Access network could be thought of as similar to the Internet Access
Provider (IAP) network referenced below. Provider (IAP) network referenced below.
skipping to change at page 10, line 45 skipping to change at page 10, line 46
specific to DNS, but DNS traffic is susceptible to these attacks when specific to DNS, but DNS traffic is susceptible to these attacks when
using specific transports. using specific transports.
There are some general examples, for example, certain studies have There are some general examples, for example, certain studies have
highlighted that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes os- highlighted that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes os-
fingerprint [2] values can be used to fingerprint client OS's or that fingerprint [2] values can be used to fingerprint client OS's or that
various techniques can be used to de-NAT DNS queries dns-de-nat [3]. various techniques can be used to de-NAT DNS queries dns-de-nat [3].
Note that even when using encrypted transports the use of clear text Note that even when using encrypted transports the use of clear text
transport options to decrease latency can provide correlation of a transport options to decrease latency can provide correlation of a
users' connections e.g. using TCP Fast Open [RFC7413]. users' connections e.g. using TCP Fast Open [RFC7413].
Implementations that support encrypted transports also commonly re- Implementations that support encrypted transports also commonly re-
use connections for multiple DNS queries to optimize performance use connections for multiple DNS queries to optimize performance
(e.g. via DNS pipelining or HTTPS multiplexing). Default (e.g. via DNS pipelining or HTTPS multiplexing). Default
configuration options for encrypted transports could in principle configuration options for encrypted transports could in principle
fingerprint a specific client application. For example: fingerprint a specific client application. For example:
o TLS version or cipher suite selection o TLS version or cipher suite selection
o session resumption o session resumption
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
skipping to change at page 13, line 14 skipping to change at page 13, line 16
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 popular applications directing DNS traffic by default to specific o applications directing DNS traffic by default to limited subset of
dominant resolvers, see Section 6.1.1.2 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 additionally highly dependent on the privacy for end users are additionally highly dependent on the privacy
policies and practices of those entities. Many of the issues around policies and practices of those entities. Many of the issues around
centralization are discussed in centralization are 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
skipping to change at page 13, line 47 skipping to change at page 13, line 49
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.
For users to have the ability to manage the DNS resolver settings for Users will only be aware of and have the ability to control such
each individual application in a similar fashion to the OS DNS settings if applications provide the following functions:
settings, each application would need to expose the default settings
to the user, provide a configuration interface to change them, and
support configuration of user specified resolvers.
The system resolver resolution path is sometimes used to configure
additional DNS controls e.g. query logging, domain based query re-
direction or filtering. If all of the applications used on a given
device can be configured to use the system resolver, such controls
need only be configured on the system resolver resolution path.
However if applications offer neither the option to use the system
resolver nor equivalent application-specific DNS controls then users
should take note that for queries generated by such an application
they may not be able to
o directly inspect the DNS queries (e.g. if they are encrypted), or o communicate clearly the change in default to users
o manage them to set DNS controls across the device which are o provide configuration options to change the default
consistent with the system resolver controls.
Note that if a client device is compromised by a malicious o provide configuration options to always use the system resolver
application, the attacker can use application-specific DNS resolvers,
transport and controls of its own choosing.
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 19, line 46 skipping to change at page 19, line 28
the choices and compromises they imply), much less define solutions. the choices and compromises they imply), much less define solutions.
Possible solutions to the issues described here are discussed in Possible solutions to the issues described here are discussed in
other documents (currently too many to all be mentioned); see, for other documents (currently too many to all be mentioned); see, for
instance, 'Recommendations for DNS Privacy Operators' instance, 'Recommendations for DNS Privacy Operators'
[I-D.ietf-dprive-bcp-op]. [I-D.ietf-dprive-bcp-op].
11. IANA Considerations 11. IANA Considerations
This document makes no requests of the IANA. This document makes no requests of the IANA.
12. Acknowledgments 12. Contributions
Sara Dickinson and Stephane Bortzmeyer were the original authors on
the document, and their contribution on the initial version is
greatly apprecriated.
13. Acknowledgments
Thanks to Nathalie Boulvard and to the CENTR members for the original Thanks to Nathalie Boulvard and to the CENTR members for the original
work that led to this document. Thanks to Ondrej Sury for the work that led to this document. Thanks to Ondrej Sury for the
interesting discussions. Thanks to Mohsen Souissi and John Heidemann interesting discussions. Thanks to Mohsen Souissi and John Heidemann
for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz, for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,
Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for
proofreading, providing technical remarks, and making many proofreading, providing technical remarks, and making many
readability improvements. Thanks to Dan York, Suzanne Woolf, Tony readability improvements. Thanks to Dan York, Suzanne Woolf, Tony
Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis
for good written contributions. Thanks to Vittorio Bertola and for good written contributions. Thanks to Vittorio Bertola and
Mohamed Boucadair for a detailed review of the -bis. And thanks to Mohamed Boucadair for a detailed review of the -bis. And thanks to
the IESG members for the last remarks. the IESG members for the last remarks.
13. Changelog 14. Changelog
draft-ietf-dprive-rfc7626-bis-06
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 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.
skipping to change at page 22, line 10 skipping to change at page 22, line 4
draft-borztmeyer-dprive-rfc7626-bis-00: draft-borztmeyer-dprive-rfc7626-bis-00:
Initial commit. Differences to RFC7626: Initial commit. Differences to RFC7626:
o Update many references o Update many references
o Add discussions of encrypted transports including DoT and DoH o Add discussions of encrypted transports including DoT and DoH
o Add section on DNS payload o Add section on DNS payload
o Add section on authentication of servers o Add section on authentication of servers
o Add section on blocking of services o Add section on blocking of services
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013,
editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] 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>.
14.2. Informative References 15.2. Informative References
[aeris-dns] [aeris-dns]
Vinot, N., "Vie privee: et le DNS alors?", (In French), Vinot, N., "Vie privee: et le DNS alors?", (In French),
2015, <https://blog.imirhil.fr/vie-privee-et-le-dns- 2015,
alors.html>. <https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.
[cache-snooping-defence] [cache-snooping-defence]
ISC, , "ISC Knowledge Database: DNS Cache snooping - ISC, "ISC Knowledge Database: DNS Cache snooping - should
should I be concerned?", 2018, <https://kb.isc.org/docs/ I be concerned?", 2018,
aa-00482>. <https://kb.isc.org/docs/aa-00482>.
[castillo-garcia] [castillo-garcia]
Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous
Resolution of DNS Queries", 2008, Resolution of DNS Queries", 2008,
<http://deic.uab.es/~joaquin/papers/is08.pdf>. <http://deic.uab.es/~joaquin/papers/is08.pdf>.
[centralisation-and-data-sovereignty] [centralisation-and-data-sovereignty]
De Filippi, P. and S. McCarthy, "Cloud Computing: De Filippi, P. and S. McCarthy, "Cloud Computing:
Centralization and Data Sovereignty", October 2012, Centralization and Data Sovereignty", October 2012,
<https://papers.ssrn.com/sol3/ <https://papers.ssrn.com/sol3/
skipping to change at page 23, line 43 skipping to change at page 23, line 37
[day-at-root] [day-at-root]
Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A
Day at the Root of the Internet", ACM SIGCOMM Computer Day at the Root of the Internet", ACM SIGCOMM Computer
Communication Review, Vol. 38, Number 5, Communication Review, Vol. 38, Number 5,
DOI 10.1145/1452335.1452341, October 2008, DOI 10.1145/1452335.1452341, October 2008,
<http://www.sigcomm.org/sites/default/files/ccr/ <http://www.sigcomm.org/sites/default/files/ccr/
papers/2008/October/1452335-1452341.pdf>. papers/2008/October/1452335-1452341.pdf>.
[denis-edns-client-subnet] [denis-edns-client-subnet]
Denis, F., "Security and privacy issues of edns-client- Denis, F., "Security and privacy issues of edns-client-
subnet", August 2013, <https://00f.net/2013/08/07/edns- subnet", August 2013,
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>.
[dnsmezzo] [dnsmezzo]
skipping to change at page 25, line 13 skipping to change at page 25, line 8
progress), September 2019. progress), September 2019.
[I-D.ietf-dnsop-resolver-information] [I-D.ietf-dnsop-resolver-information]
Sood, P., Arends, R., and P. Hoffman, "DNS Resolver Sood, P., Arends, R., and P. Hoffman, "DNS Resolver
Information Self-publication", draft-ietf-dnsop-resolver- Information Self-publication", draft-ietf-dnsop-resolver-
information-01 (work in progress), February 2020. information-01 (work in progress), February 2020.
[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-08 (work in Operators", draft-ietf-dprive-bcp-op-14 (work in
progress), January 2020. progress), July 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-27 (work and Secure Transport", draft-ietf-quic-transport-30 (work
in progress), February 2020. in progress), September 2020.
[I-D.ietf-tls-sni-encryption] [I-D.ietf-tls-sni-encryption]
Huitema, C. and E. Rescorla, "Issues and Requirements for Huitema, C. and E. Rescorla, "Issues and Requirements for
SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09
(work in progress), October 2019. (work in progress), October 2019.
[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, <https://github.com/DNS-OARC/ against PCAP-files", 2011,
PacketQ>. <https://github.com/DNS-OARC/PacketQ>.
[passive-dns] [passive-dns]
Weimer, F., "Passive DNS Replication", April 2005, Weimer, F., "Passive DNS Replication", April 2005,
<https://www.first.org/conference/2005/papers/florian- <https://www.first.org/conference/2005/papers/florian-
weimer-slides-1.pdf>. weimer-slides-1.pdf>.
[pitfalls-of-dns-encryption] [pitfalls-of-dns-encryption]
Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS
Encryption", <https://dl.acm.org/citation.cfm?id=2665959>. Encryption", <https://dl.acm.org/citation.cfm?id=2665959>.
[prism] Wikipedia, "PRISM (surveillance program)", July 2015, [prism] Wikipedia, "PRISM (surveillance program)", July 2015,
<https://en.wikipedia.org/w/index.php?title=PRISM_(surveil <https://en.wikipedia.org/w/index.php?title=PRISM_(surveil
lance_program)&oldid=673789455>. lance_program)&oldid=673789455>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, <https://www.rfc- DOI 10.17487/RFC3552, July 2003,
editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, <https://www.rfc- DOI 10.17487/RFC6269, June 2011,
editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, <https://www.rfc- DOI 10.17487/RFC6891, April 2013,
editor.org/info/rfc6891>. <https://www.rfc-editor.org/info/rfc6891>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, <https://www.rfc- DOI 10.17487/RFC7624, August 2015,
editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
Nordmark, "Technical Considerations for Internet Service Nordmark, "Technical Considerations for Internet Service
Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
March 2016, <https://www.rfc-editor.org/info/rfc7754>. March 2016, <https://www.rfc-editor.org/info/rfc7754>.
skipping to change at page 27, line 21 skipping to change at page 27, line 16
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/info/rfc7816>. <https://www.rfc-editor.org/info/rfc7816>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871, Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, <https://www.rfc- DOI 10.17487/RFC7871, May 2016,
editor.org/info/rfc7871>. <https://www.rfc-editor.org/info/rfc7871>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>. <https://www.rfc-editor.org/info/rfc7873>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
(DANE) Bindings for OpenPGP", RFC 7929, (DANE) Bindings for OpenPGP", RFC 7929,
DOI 10.17487/RFC7929, August 2016, <https://www.rfc- DOI 10.17487/RFC7929, August 2016,
editor.org/info/rfc7929>. <https://www.rfc-editor.org/info/rfc7929>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[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>.
[ripe-qname-measurements] [ripe-qname-measurements]
University of Twente, "Making the DNS More Private with Vries, W., "Making the DNS More Private with QNAME
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,
<https://www.sidnlabs.nl/downloads/ <https://www.sidnlabs.nl/downloads/
yBW6hBoaSZe4m6GJc_0b7w/2211058ab6330c7f3788141ea19d3db7/ yBW6hBoaSZe4m6GJc_0b7w/2211058ab6330c7f3788141ea19d3db7/
SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>. SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.
skipping to change at page 28, line 30 skipping to change at page 28, line 22
[tor-leak] [tor-leak]
Tor, "DNS leaks in Tor", 2013, Tor, "DNS leaks in Tor", 2013,
<https://www.torproject.org/docs/ <https://www.torproject.org/docs/
faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>. faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.
[yanbin-tsudik] [yanbin-tsudik]
Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks
in the Domain Name System", October 2009, in the Domain Name System", October 2009,
<http://arxiv.org/abs/0910.2472>. <http://arxiv.org/abs/0910.2472>.
14.3. URIs 15.3. URIs
[1] https://lists.dns-oarc.net/pipermail/dns- [1] https://lists.dns-oarc.net/pipermail/dns-
operations/2016-January/014143.html operations/2016-January/014143.html
[2] http://netres.ec/?b=11B99BD [2] http://netres.ec/?b=11B99BD
[3] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS- [3] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS-
based_De-NAT_Scheme based_De-NAT_Scheme
[4] https://developers.google.com/speed/public-dns [4] https://developers.google.com/speed/public-dns
skipping to change at page 29, line 7 skipping to change at page 28, line 47
[7] https://developers.google.com/speed/public-dns/privacy [7] https://developers.google.com/speed/public-dns/privacy
[8] https://www.alexa.com/topsites [8] https://www.alexa.com/topsites
[9] https://theintercept.com/document/2014/03/12/nsa-gchqs- [9] https://theintercept.com/document/2014/03/12/nsa-gchqs-
quantumtheory-hacking-tactics/ quantumtheory-hacking-tactics/
[10] https://www.eugdpr.org/the-regulation.html [10] https://www.eugdpr.org/the-regulation.html
Authors' Addresses Author's Address
Tim Wicinski (editor)
Stephane Bortzmeyer Elkins, WV 26241
AFNIC USA
1, rue Stephenson
Montigny-le-Bretonneux
France 78180
Email: bortzmeyer+ietf@nic.fr
Sara Dickinson
Sinodun IT
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: sara@sinodun.com Email: tjw.ietf@gmail.com
 End of changes. 38 change blocks. 
95 lines changed or deleted 82 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/