draft-ietf-dprive-bcp-op-14.txt   rfc8932.txt 
dprive S. Dickinson Internet Engineering Task Force (IETF) S. Dickinson
Internet-Draft Sinodun IT Request for Comments: 8932 Sinodun IT
Intended status: Best Current Practice B. Overeinder BCP: 232 B. Overeinder
Expires: January 14, 2021 R. van Rijswijk-Deij Category: Best Current Practice R. van Rijswijk-Deij
NLnet Labs ISSN: 2070-1721 NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
July 13, 2020 October 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-14
Abstract Abstract
This document presents operational, policy, and security This document presents operational, policy, and security
considerations for DNS recursive resolver operators who choose to considerations for DNS recursive resolver operators who choose to
offer DNS Privacy services. With these recommendations, the operator offer DNS privacy services. With these recommendations, the operator
can make deliberate decisions regarding which services to provide, can make deliberate decisions regarding which services to provide, as
and how the decisions and alternatives impact the privacy of users. well as understanding how those decisions and the alternatives impact
the privacy of users.
This document also presents a non-normative framework to assist This document also presents a non-normative framework to assist
writers of a Recursive operator Privacy Statement (analogous to DNS writers of a Recursive operator Privacy Statement, analogous to DNS
Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
described in RFC6841). described in RFC 6841.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 14, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8932.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope
3. Privacy-related documents . . . . . . . . . . . . . . . . . . 5 3. Privacy-Related Documents
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology
5. Recommendations for DNS privacy services . . . . . . . . . . 6 5. Recommendations for DNS Privacy Services
5.1. On the wire between client and server . . . . . . . . . . 7 5.1. On the Wire between Client and Server
5.1.1. Transport recommendations . . . . . . . . . . . . . . 7 5.1.1. Transport Recommendations
5.1.2. Authentication of DNS privacy services . . . . . . . 8 5.1.2. Authentication of DNS Privacy Services
5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 5.1.3. Protocol Recommendations
5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. DNSSEC
5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 12 5.1.5. Availability
5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12 5.1.6. Service Options
5.1.7. Impact of Encryption on Monitoring by DNS Privacy 5.1.7. Impact of Encryption on Monitoring by DNS Privacy
Service Operators . . . . . . . . . . . . . . . . . . 13 Service Operators
5.1.8. Limitations of fronting a DNS privacy service with a 5.1.8. Limitations of Fronting a DNS Privacy Service with a
pure TLS proxy . . . . . . . . . . . . . . . . . . . 13 Pure TLS Proxy
5.2. Data at rest on the server . . . . . . . . . . . . . . . 14 5.2. Data at Rest on the Server
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Data Handling
5.2.2. Data minimization of network traffic . . . . . . . . 15 5.2.2. Data Minimization of Network Traffic
5.2.3. IP address pseudonymization and anonymization methods 16 5.2.3. IP Address Pseudonymization and Anonymization Methods
5.2.4. Pseudonymization, anonymization, or discarding of 5.2.4. Pseudonymization, Anonymization, or Discarding of Other
other correlation data . . . . . . . . . . . . . . . 16 Correlation Data
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 5.2.5. Cache Snooping
5.3. Data sent onwards from the server . . . . . . . . . . . . 17 5.3. Data Sent Onwards from the Server
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17 5.3.1. Protocol Recommendations
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18 5.3.2. Client Query Obfuscation
5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19 5.3.3. Data Sharing
6. Recursive operator Privacy Statement (RPS) . . . . . . . . . 20 6. Recursive Operator Privacy Statement (RPS)
6.1. Outline of an RPS . . . . . . . . . . . . . . . . . . . . 20 6.1. Outline of an RPS
6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Policy
6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21 6.1.2. Practice
6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22 6.2. Enforcement/Accountability
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations
8. Security considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. References
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Documents
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 A.1. Potential Increases in DNS Privacy
12.2. Informative References . . . . . . . . . . . . . . . . . 29 A.2. Potential Decreases in DNS Privacy
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 34 A.3. Related Operational Documents
A.1. Potential increases in DNS privacy . . . . . . . . . . . 34 Appendix B. IP Address Techniques
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34 B.1. Categorization of Techniques
A.3. Related operational documents . . . . . . . . . . . . . . 35 B.2. Specific Techniques
Appendix B. IP address techniques . . . . . . . . . . . . . . . 35 B.2.1. Google Analytics Non-Prefix Filtering
B.1. Categorization of techniques . . . . . . . . . . . . . . 36 B.2.2. dnswasher
B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37 B.2.3. Prefix-Preserving Map
B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37 B.2.4. Cryptographic Prefix-Preserving Pseudonymization
B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 38 B.2.5. Top-Hash Subtree-Replicated Anonymization
B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38 B.2.6. ipcipher
B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38 B.2.7. Bloom Filters
B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 39 Appendix C. Current Policy and Privacy Statements
B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39 Appendix D. Example RPS
B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39 D.1. Policy
Appendix C. Current policy and privacy statements . . . . . . . 40 D.2. Practice
Appendix D. Example RPS . . . . . . . . . . . . . . . . . . . . 40 Acknowledgements
D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40 Contributors
D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The Domain Name System (DNS) is at the core of the Internet; almost The Domain Name System (DNS) is at the core of the Internet; almost
every activity on the Internet starts with a DNS query (and often every activity on the Internet starts with a DNS query (and often
several). However the DNS was not originally designed with strong several). However, the DNS was not originally designed with strong
security or privacy mechanisms. A number of developments have taken security or privacy mechanisms. A number of developments have taken
place in recent years which aim to increase the privacy of the DNS place in recent years that aim to increase the privacy of the DNS,
system and these are now seeing some deployment. This latest and these are now seeing some deployment. This latest evolution of
evolution of the DNS presents new challenges to operators and this the DNS presents new challenges to operators, and this document
document attempts to provide an overview of considerations for attempts to provide an overview of considerations for privacy-focused
privacy focused DNS services. DNS services.
In recent years there has also been an increase in the availability In recent years, there has also been an increase in the availability
of "public resolvers" [RFC8499] which users may prefer to use instead of "public resolvers" [RFC8499], which users may prefer to use
of the default network resolver either because they offer a specific instead of the default network resolver, either because they offer a
feature (e.g., good reachability or encrypted transport) or because specific feature (e.g., good reachability or encrypted transport) or
the network resolver lacks a specific feature (e.g., strong privacy because the network resolver lacks a specific feature (e.g., strong
policy or unfiltered responses). These public resolvers have tended privacy policy or unfiltered responses). These public resolvers have
to be at the forefront of adoption of privacy-related enhancements tended to be at the forefront of adoption of privacy-related
but it is anticipated that operators of other resolver services will enhancements, but it is anticipated that operators of other resolver
follow. services will follow.
Whilst protocols that encrypt DNS messages on the wire provide Whilst protocols that encrypt DNS messages on the wire provide
protection against certain attacks, the resolver operator still has protection against certain attacks, the resolver operator still has
(in principle) full visibility of the query data and transport (in principle) full visibility of the query data and transport
identifiers for each user. Therefore, a trust relationship (whether identifiers for each user. Therefore, a trust relationship (whether
explicit or implicit) is assumed to exist between each user and the explicit or implicit) is assumed to exist between each user and the
operator of the resolver(s) used by that user. The ability of the operator of the resolver(s) used by that user. The ability of the
operator to provide a transparent, well documented, and secure operator to provide a transparent, well-documented, and secure
privacy service will likely serve as a major differentiating factor privacy service will likely serve as a major differentiating factor
for privacy conscious users if they make an active selection of which for privacy-conscious users if they make an active selection of which
resolver to use. resolver to use.
It should also be noted that the choice of a user to configure a It should also be noted that there are both advantages and
single resolver (or a fixed set of resolvers) and an encrypted disadvantages to a user choosing to configure a single resolver (or a
transport to use in all network environments has both advantages and fixed set of resolvers) and an encrypted transport to use in all
disadvantages. For example, the user has a clear expectation of network environments. For example, the user has a clear expectation
which resolvers have visibility of their query data. However, this of which resolvers have visibility of their query data. However,
resolver/transport selection may provide an added mechanism to track this resolver/transport selection may provide an added mechanism for
them as they move across network environments. Commitments from tracking them as they move across network environments. Commitments
resolver operators to minimize such tracking as users move between from resolver operators to minimize such tracking as users move
networks are also likely to play a role in user selection of between networks are also likely to play a role in user selection of
resolvers. resolvers.
More recently the global legislative landscape with regard to More recently, the global legislative landscape with regard to
personal data collection, retention, and pseudonymization has seen personal data collection, retention, and pseudonymization has seen
significant activity. Providing detailed practice advice about these significant activity. Providing detailed practice advice about these
areas to the operator is out of scope, but Section 5.3.3 describes areas to the operator is out of scope, but Section 5.3.3 describes
some mitigations of data sharing risk. some mitigations of data-sharing risk.
This document has two main goals: This document has two main goals:
o To provide operational and policy guidance related to DNS over * To provide operational and policy guidance related to DNS over
encrypted transports and to outline recommendations for data encrypted transports and to outline recommendations for data
handling for operators of DNS privacy services. handling for operators of DNS privacy services.
o To introduce the Recursive operator Privacy Statement (RPS) and * To introduce the Recursive operator Privacy Statement (RPS) and
present a framework to assist writers of an RPS. An RPS is a present a framework to assist writers of an RPS. An RPS is a
document that an operator should publish which outlines their document that an operator should publish that outlines their
operational practices and commitments with regard to privacy, operational practices and commitments with regard to privacy,
thereby providing a means for clients to evaluate both the thereby providing a means for clients to evaluate both the
measurable and claimed privacy properties of a given DNS privacy measurable and claimed privacy properties of a given DNS privacy
service. The framework identifies a set of elements and specifies service. The framework identifies a set of elements and specifies
an outline order for them. This document does not, however, an outline order for them. This document does not, however,
define a particular privacy statement, nor does it seek to provide define a particular privacy statement, nor does it seek to provide
legal advice as to the contents. legal advice as to the contents of an RPS.
A desired operational impact is that all operators (both those A desired operational impact is that all operators (both those
providing resolvers within networks and those operating large public providing resolvers within networks and those operating large public
services) can demonstrate their commitment to user privacy thereby services) can demonstrate their commitment to user privacy, thereby
driving all DNS resolution services to a more equitable footing. driving all DNS resolution services to a more equitable footing.
Choices for users would (in this ideal world) be driven by other Choices for users would (in this ideal world) be driven by other
factors, e.g., differing security policies or minor difference in factors -- e.g., differing security policies or minor differences in
operator policy, rather than gross disparities in privacy concerns. operator policy -- rather than gross disparities in privacy concerns.
Community insight [or judgment?] about operational practices can Community insight (or judgment?) about operational practices can
change quickly, and experience shows that a Best Current Practice change quickly, and experience shows that a Best Current Practice
(BCP) document about privacy and security is a point-in-time (BCP) document about privacy and security is a point-in-time
statement. Readers are advised to seek out any updates that apply to statement. Readers are advised to seek out any updates that apply to
this document. this document.
2. Scope 2. Scope
"DNS Privacy Considerations" [RFC7626] describes the general privacy "DNS Privacy Considerations" [RFC7626] describes the general privacy
issues and threats associated with the use of the DNS by Internet issues and threats associated with the use of the DNS by Internet
users and much of the threat analysis here is lifted from that users; much of the threat analysis here is lifted from that document
document and from [RFC6973]. However this document is limited in and [RFC6973]. However, this document is limited in scope to best-
scope to best practice considerations for the provision of DNS practice considerations for the provision of DNS privacy services by
privacy services by servers (recursive resolvers) to clients (stub servers (recursive resolvers) to clients (stub resolvers or
resolvers or forwarders). Choices that are made exclusively by the forwarders). Choices that are made exclusively by the end user, or
end user, or those for operators of authoritative nameservers are out those for operators of authoritative nameservers, are out of scope.
of scope.
This document includes (but is not limited to) considerations in the This document includes (but is not limited to) considerations in the
following areas: following areas:
1. Data "on the wire" between a client and a server. 1. Data "on the wire" between a client and a server.
2. Data "at rest" on a server (e.g., in logs). 2. Data "at rest" on a server (e.g., in logs).
3. Data "sent onwards" from the server (either on the wire or shared 3. Data "sent onwards" from the server (either on the wire or shared
with a third party). with a third party).
Whilst the issues raised here are targeted at those operators who Whilst the issues raised here are targeted at those operators who
choose to offer a DNS privacy service, considerations for areas 2 and choose to offer a DNS privacy service, considerations for areas 2 and
3 could equally apply to operators who only offer DNS over 3 could equally apply to operators who only offer DNS over
unencrypted transports but who would otherwise like to align with unencrypted transports but who would otherwise like to align with
privacy best practice. privacy best practice.
3. Privacy-related documents 3. Privacy-Related Documents
There are various documents that describe protocol changes that have There are various documents that describe protocol changes that have
the potential to either increase or decrease the privacy properties the potential to either increase or decrease the privacy properties
of the DNS in various ways. Note this does not imply that some of the DNS in various ways. Note that this does not imply that some
documents are good or bad, better or worse, just that (for example) documents are good or bad, better or worse, just that (for example)
some features may bring functional benefits at the price of a some features may bring functional benefits at the price of a
reduction in privacy and conversely some features increase privacy reduction in privacy, and conversely some features increase privacy
with an accompanying increase in complexity. A selection of the most with an accompanying increase in complexity. A selection of the most
relevant documents are listed in Appendix A for reference. relevant documents is listed in Appendix A for reference.
4. Terminology 4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
DNS terminology is as described in [RFC8499] with one modification: DNS terminology is as described in [RFC8499], except with regard to
we restate the clause in the original definition of Privacy-enabling the definition of privacy-enabling DNS server in Section 6 of
DNS server in [RFC8310] to include the requirement that a DNS over [RFC8499]. In this document we use the full definition of a DNS over
(D)TLS server should also offer at least one of the credentials (D)TLS privacy-enabling DNS server as given in [RFC8310], i.e., that
such a server should also offer at least one of the credentials
described in Section 8 of [RFC8310] and implement the (D)TLS profile described in Section 8 of [RFC8310] and implement the (D)TLS profile
described in Section 9 of [RFC8310]. described in Section 9 of [RFC8310].
Other Terms: Other Terms:
o RPS: Recursive operator Privacy Statement, see Section 6. RPS: Recursive operator Privacy Statement; see Section 6.
o DNS privacy service: The service that is offered via a privacy- DNS privacy service: The service that is offered via a privacy-
enabling DNS server and is documented either in an informal enabling DNS server and is documented either in an informal
statement of policy and practice with regard to users privacy or a statement of policy and practice with regard to users privacy or a
formal RPS. formal RPS.
5. Recommendations for DNS privacy services 5. Recommendations for DNS Privacy Services
In the following sections we first outline the threats relevant to In the following sections, we first outline the threats relevant to
the specific topic and then discuss the potential actions that can be the specific topic and then discuss the potential actions that can be
taken to mitigate them. taken to mitigate them.
We describe two classes of threats: We describe two classes of threats:
o Threats described in [RFC6973] 'Privacy Considerations for * Threats described in [RFC6973], "Privacy Considerations for
Internet Protocols' Internet Protocols"
* Privacy terminology, threats to privacy, and mitigations as - Privacy terminology, threats to privacy, and mitigations as
described in Sections 3, 5, and 6 of [RFC6973]. described in Sections 3, 5, and 6 of [RFC6973].
o DNS Privacy Threats * DNS Privacy Threats
* These are threats to the users and operators of DNS privacy - These are threats to the users and operators of DNS privacy
services that are not directly covered by [RFC6973]. These may services that are not directly covered by [RFC6973]. These may
be more operational in nature such as certificate management or be more operational in nature, such as certificate-management
service availability issues. or service-availability issues.
We describe three classes of actions that operators of DNS privacy We describe three classes of actions that operators of DNS privacy
services can take: services can take:
o Threat mitigation for well understood and documented privacy * Threat mitigation for well-understood and documented privacy
threats to the users of the service and in some cases to the threats to the users of the service and, in some cases, the
operators of the service. operators of the service.
o Optimization of privacy services from an operational or management * Optimization of privacy services from an operational or management
perspective. perspective.
o Additional options that could further enhance the privacy and * Additional options that could further enhance the privacy and
usability of the service. usability of the service.
This document does not specify policy - only best practice, however This document does not specify policy, only best practice. However,
for DNS Privacy services to be considered compliant with these best for DNS privacy services to be considered compliant with these best-
practice guidelines they SHOULD implement (where appropriate) all: practice guidelines, they SHOULD implement (where appropriate) all:
o Threat mitigations to be minimally compliant. * Threat mitigations to be minimally compliant.
o Optimizations to be moderately compliant. * Optimizations to be moderately compliant.
o Additional options to be maximally compliant. * Additional options to be maximally compliant.
The rest of this document does not use normative language but instead The rest of this document does not use normative language but instead
refers only to the three differing classes of action which correspond refers only to the three differing classes of action that correspond
to the three named levels of compliance stated above. However, to the three named levels of compliance stated above. However,
compliance (to the indicated level) remains a normative requirement. compliance (to the indicated level) remains a normative requirement.
5.1. On the wire between client and server 5.1. On the Wire between Client and Server
In this section we consider both data on the wire and the service In this section, we consider both data on the wire and the service
provided to the client. provided to the client.
5.1.1. Transport recommendations 5.1.1. Transport Recommendations
[RFC6973] Threats:
o Surveillance:
* Passive surveillance of traffic on the wire Threats described in [RFC6973]:
Surveillance:
Passive surveillance of traffic on the wire.
DNS Privacy Threats: DNS Privacy Threats:
Active injection of spurious data or traffic.
o Active injection of spurious data or traffic.
Mitigations: Mitigations:
A DNS privacy service can mitigate these threats by providing
service over one or more of the following transports:
A DNS privacy service can mitigate these threats by providing service * DNS over TLS (DoT) [RFC7858] [RFC8310].
over one or more of the following transports
o DNS over TLS (DoT) [RFC7858] and [RFC8310].
o DNS over HTTPS (DoH) [RFC8484]. * DNS over HTTPS (DoH) [RFC8484].
It is noted that a DNS privacy service can also be provided over DNS It is noted that a DNS privacy service can also be provided over DNS
over DTLS [RFC8094], however this is an Experimental specification over DTLS [RFC8094]; however, this is an Experimental specification,
and there are no known implementations at the time of writing. and there are no known implementations at the time of writing.
It is also noted that DNS privacy service might be provided over It is also noted that DNS privacy service might be provided over
IPSec, DNSCrypt, or VPNs. However, there are no specific RFCs that DNSCrypt [DNSCrypt], IPsec, or VPNs. However, there are no specific
cover the use of these transports for DNS and any discussion of best RFCs that cover the use of these transports for DNS, and any
practice for providing such a service is out of scope for this discussion of best practice for providing such a service is out of
document. scope for this document.
Whilst encryption of DNS traffic can protect against active injection Whilst encryption of DNS traffic can protect against active injection
on the paths traversed by the encrypted connection this does not on the paths traversed by the encrypted connection, this does not
diminish the need for DNSSEC, see Section 5.1.4. diminish the need for DNSSEC; see Section 5.1.4.
5.1.2. Authentication of DNS privacy services
[RFC6973] Threats:
o Surveillance: 5.1.2. Authentication of DNS Privacy Services
* Active attacks on client resolver configuration Threats described in [RFC6973]:
Surveillance:
Active attacks on client resolver configuration.
Mitigations: Mitigations:
DNS privacy services should ensure clients can authenticate the
server. Note that this, in effect, commits the DNS privacy
service to a public identity users will trust.
DNS privacy services should ensure clients can authenticate the When using DoT, clients that select a "Strict Privacy" usage
server. Note that this, in effect, commits the DNS privacy service profile [RFC8310] (to mitigate the threat of active attack on the
to a public identity users will trust. client) require the ability to authenticate the DNS server. To
enable this, DNS privacy services that offer DoT need to provide
When using DoT, clients that select a 'Strict Privacy' usage profile credentials that will be accepted by the client's trust model, in
[RFC8310] (to mitigate the threat of active attack on the client) the form of either X.509 certificates [RFC5280] or Subject Public
require the ability to authenticate the DNS server. To enable this, Key Info (SPKI) pin sets [RFC8310].
DNS privacy services that offer DNS over TLS need to provide
credentials that will be accepted by the client's trust model, in the
form of either X.509 certificates [RFC5280] or Subject Public Key
Info (SPKI) pin sets [RFC8310].
When offering DoH [RFC8484], HTTPS requires authentication of the
server as part of the protocol.
Server operators should also follow the best practices with regard to When offering DoH [RFC8484], HTTPS requires authentication of the
certificate revocation as described in [RFC7525]. server as part of the protocol.
5.1.2.1. Certificate management 5.1.2.1. Certificate Management
Anecdotal evidence to date highlights the management of certificates Anecdotal evidence to date highlights the management of certificates
as one of the more challenging aspects for operators of traditional as one of the more challenging aspects for operators of traditional
DNS resolvers that choose to additionally provide a DNS privacy DNS resolvers that choose to additionally provide a DNS privacy
service as management of such credentials is new to those DNS service, as management of such credentials is new to those DNS
operators. operators.
It is noted that SPKI pin set management is described in [RFC7858] It is noted that SPKI pin set management is described in [RFC7858]
but that key pinning mechanisms in general have fallen out of favor but that key-pinning mechanisms in general have fallen out of favor
operationally for various reasons such as the logistical overhead of operationally for various reasons, such as the logistical overhead of
rolling keys. rolling keys.
DNS Privacy Threats: DNS Privacy Threats:
* Invalid certificates, resulting in an unavailable service,
which might force a user to fall back to cleartext.
o Invalid certificates, resulting in an unavailable service which * Misidentification of a server by a client -- e.g., typos in DoH
might force a user to fallback to cleartext. URL templates [RFC8484] or authentication domain names
[RFC8310] that accidentally direct clients to attacker-
o Mis-identification of a server by a client e.g., typos in DoH URL controlled servers.
templates [RFC8484] or authentication domain names [RFC8310] which
accidentally direct clients to attacker controlled servers.
Mitigations: Mitigations:
It is recommended that operators:
It is recommended that operators: * Follow the guidance in Section 6.5 of [RFC7525] with regard to
certificate revocation.
o Follow the guidance in Section 6.5 of [RFC7525] with regards to
certificate revocation.
o Automate the generation, publication, and renewal of certificates. * Automate the generation, publication, and renewal of
For example, ACME [RFC8555] provides a mechanism to actively certificates. For example, Automatic Certificate Management
manage certificates through automation and has been implemented by Environment (ACME) [RFC8555] provides a mechanism to actively
a number of certificate authorities. manage certificates through automation and has been implemented
by a number of certificate authorities.
o Monitor certificates to prevent accidental expiration of * Monitor certificates to prevent accidental expiration of
certificates. certificates.
o Choose a short, memorable authentication domain name for the * Choose a short, memorable authentication domain name for the
service. service.
5.1.3. Protocol recommendations 5.1.3. Protocol Recommendations
5.1.3.1. DoT 5.1.3.1. DoT
DNS Privacy Threats: DNS Privacy Threats:
* Known attacks on TLS, such as those described in [RFC7457].
o Known attacks on TLS such as those described in [RFC7457]. * Traffic analysis, for example: [Pitfalls-of-DNS-Encryption]
(focused on DoT).
o Traffic analysis, for example: [Pitfalls-of-DNS-Encryption].
o Potential for client tracking via transport identifiers. * Potential for client tracking via transport identifiers.
o Blocking of well known ports (e.g., 853 for DoT). * Blocking of well-known ports (e.g., 853 for DoT).
Mitigations: Mitigations:
In the case of DoT, TLS profiles from Section 9 of [RFC8310] and
the "Countermeasures to DNS Traffic Analysis" from Section 11.1 of
[RFC8310] provide strong mitigations. This includes but is not
limited to:
In the case of DoT, TLS profiles from Section 9 of [RFC8310] and the * Adhering to [RFC7525].
Countermeasures to DNS Traffic Analysis from section 11.1 of
[RFC8310] provide strong mitigations. This includes but is not
limited to:
o Adhering to [RFC7525].
o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]. * Implementing only (D)TLS 1.2 or later, as specified in
[RFC8310].
o Implementing EDNS(0) Padding [RFC7830] using the guidelines in * Implementing Extension Mechanisms for DNS (EDNS(0)) Padding
[RFC8467] or a successor specification. [RFC7830] using the guidelines in [RFC8467] or a successor
specification.
o Servers should not degrade in any way the query service level * Servers should not degrade in any way the query service level
provided to clients that do not use any form of session resumption provided to clients that do not use any form of session
mechanism, such as TLS session resumption [RFC5077] with TLS 1.2, resumption mechanism, such as TLS session resumption [RFC5077]
section 2.2 of [RFC8446], or Domain Name System (DNS) Cookies with TLS 1.2 (Section 2.2 of [RFC8446]) or Domain Name System
[RFC7873]. (DNS) Cookies [RFC7873].
o A DoT privacy service on both port 853 and 443. If the operator * A DoT privacy service on both port 853 and 443. If the
deploys DoH on the same IP address this requires the use of the operator deploys DoH on the same IP address, this requires the
'dot' ALPN value [dot-ALPN]. use of the "dot" Application-Layer Protocol Negotiation (ALPN)
value [dot-ALPN].
Optimizations: Optimizations:
* Concurrent processing of pipelined queries, returning responses
as soon as available, potentially out of order, as specified in
[RFC7766]. This is often called "OOOR" -- out-of-order
responses (providing processing performance similar to HTTP
multiplexing).
o Concurrent processing of pipelined queries, returning responses as * Management of TLS connections to optimize performance for
soon as available, potentially out of order as specified in clients using [RFC7766] and EDNS(0) Keepalive [RFC7828]
[RFC7766]. This is often called 'OOOR' - out-of-order responses
(providing processing performance similar to HTTP multiplexing).
o Management of TLS connections to optimize performance for clients
using [RFC7766] and EDNS(0) Keepalive [RFC7828]
Additional Options: Additional Options:
Management of TLS connections to optimize performance for clients
Management of TLS connections to optimize performance for clients using DNS Stateful Operations [RFC8490].
using DNS Stateful Operations [RFC8490].
5.1.3.2. DoH 5.1.3.2. DoH
DNS Privacy Threats: DNS Privacy Threats:
* Known attacks on TLS, such as those described in [RFC7457].
o Known attacks on TLS such as those described in [RFC7457]. * Traffic analysis, for example: [DNS-Privacy-not-so-private]
(focused on DoH).
o Traffic analysis, for example: [DNS-Privacy-not-so-private].
o Potential for client tracking via transport identifiers. * Potential for client tracking via transport identifiers.
Mitigations: Mitigations:
* Clients must be able to forgo the use of HTTP cookies [RFC6265]
and still use the service.
o Clients must be able to forgo the use of HTTP Cookies [RFC6265] * Use of HTTP/2 padding and/or EDNS(0) padding, as described in
and still use the service. Section 9 of [RFC8484].
o Use of HTTP/2 padding and/or EDNS(0) padding as described in
Section 9 of [RFC8484]
o Clients should not be required to include any headers beyond the * Clients should not be required to include any headers beyond
absolute minimum to obtain service from a DoH server. (See the absolute minimum to obtain service from a DoH server. (See
Section 6.1 of [I-D.ietf-httpbis-bcp56bis].) Section 6.1 of [BUILD-W-HTTP].)
5.1.4. DNSSEC 5.1.4. DNSSEC
DNS Privacy Threats: DNS Privacy Threats:
Users may be directed to bogus IP addresses that, depending on the
o Users may be directed to bogus IP addresses which, depending on application, protocol, and authentication method, might lead users
the application, protocol and authentication method, might lead to reveal personal information to attackers. One example is a
users to reveal personal information to attackers. One example is website that doesn't use TLS or whose TLS authentication can
a website that doesn't use TLS or its TLS authentication can
somehow be subverted. somehow be subverted.
Mitigations: Mitigations:
All DNS privacy services must offer a DNS privacy service that
o All DNS privacy services must offer a DNS privacy service that
performs Domain Name System Security Extensions (DNSSEC) performs Domain Name System Security Extensions (DNSSEC)
validation. In addition they must be able to provide the DNSSEC validation. In addition, they must be able to provide the DNSSEC
RRs to the client so that it can perform its own validation. Resource Records (RRs) to the client so that it can perform its
own validation.
The addition of encryption to DNS does not remove the need for DNSSEC The addition of encryption to DNS does not remove the need for DNSSEC
[RFC4033] - they are independent and fully compatible protocols, each [RFC4033]; they are independent and fully compatible protocols, each
solving different problems. The use of one does not diminish the solving different problems. The use of one does not diminish the
need nor the usefulness of the other. need nor the usefulness of the other.
While the use of an authenticated and encrypted transport protects While the use of an authenticated and encrypted transport protects
origin authentication and data integrity between a client and a DNS origin authentication and data integrity between a client and a DNS
privacy service it provides no proof (for a non-validating client) privacy service, it provides no proof (for a nonvalidating client)
that the data provided by the DNS privacy service was actually DNSSEC that the data provided by the DNS privacy service was actually DNSSEC
authenticated. As with cleartext DNS the user is still solely authenticated. As with cleartext DNS, the user is still solely
trusting the AD bit (if present) set by the resolver. trusting the Authentic Data (AD) bit (if present) set by the
resolver.
It should also be noted that the use of an encrypted transport for It should also be noted that the use of an encrypted transport for
DNS actually solves many of the practical issues encountered by DNS DNS actually solves many of the practical issues encountered by DNS
validating clients e.g. interference by middleboxes with cleartext validating clients -- e.g., interference by middleboxes with
DNS payloads is completely avoided. In this sense a validating cleartext DNS payloads is completely avoided. In this sense, a
client that uses a DNS privacy service which supports DNSSEC has a validating client that uses a DNS privacy service that supports
far simpler task in terms of DNSSEC Roadblock avoidance [RFC8027]. DNSSEC has a far simpler task in terms of DNSSEC roadblock avoidance
[RFC8027].
5.1.5. Availability 5.1.5. Availability
DNS Privacy Threats: DNS Privacy Threats:
A failing DNS privacy service could force the user to switch
o A failed DNS privacy service could force the user to switch providers, fall back to cleartext, or accept no DNS service for
providers, fallback to cleartext or accept no DNS service for the the duration of the outage.
outage.
Mitigations: Mitigations:
A DNS privacy service should strive to engineer encrypted services
to the same availability level as any unencrypted services they
provide. Particular care should to be taken to protect DNS
privacy services against denial-of-service (DoS) attacks, as
experience has shown that unavailability of DNS resolving because
of attacks is a significant motivation for users to switch
services. See, for example, Section IV-C of
[Passive-Observations-of-a-Large-DNS].
A DNS privacy service should strive to engineer encrypted services to Techniques such as those described in Section 10 of [RFC7766] can
the same availability level as any unencrypted services they provide. be of use to operators to defend against such attacks.
Particular care should to be taken to protect DNS privacy services
against denial-of-service attacks, as experience has shown that
unavailability of DNS resolving because of attacks is a significant
motivation for users to switch services. See, for example
Section IV-C of [Passive-Observations-of-a-Large-DNS].
Techniques such as those described in Section 10 of [RFC7766] can be
of use to operators to defend against such attacks.
5.1.6. Service options 5.1.6. Service Options
DNS Privacy Threats: DNS Privacy Threats:
Unfairly disadvantaging users of the privacy service with respect
o Unfairly disadvantaging users of the privacy service with respect
to the services available. This could force the user to switch to the services available. This could force the user to switch
providers, fallback to cleartext or accept no DNS service for the providers, fall back to cleartext, or accept no DNS service for
outage. the duration of the outage.
Mitigations: Mitigations:
A DNS privacy service should deliver the same level of service as
A DNS privacy service should deliver the same level of service as offered on unencrypted channels in terms of options such as
offered on un-encrypted channels in terms of options such as filtering (or lack thereof), DNSSEC validation, etc.
filtering (or lack thereof), DNSSEC validation, etc.
5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service 5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service
Operators Operators
DNS Privacy Threats: DNS Privacy Threats:
Increased use of encryption can impact a DNS privacy service
operator's ability to monitor traffic and therefore manage their
DNS servers [RFC8404].
o Increased use of encryption can impact DNS privacy service Many monitoring solutions for DNS traffic rely on the plaintext
operator ability to monitor traffic and therefore manage their DNS
servers [RFC8404].
Many monitoring solutions for DNS traffic rely on the plain text
nature of this traffic and work by intercepting traffic on the wire, nature of this traffic and work by intercepting traffic on the wire,
either using a separate view on the connection between clients and either using a separate view on the connection between clients and
the resolver, or as a separate process on the resolver system that the resolver, or as a separate process on the resolver system that
inspects network traffic. Such solutions will no longer function inspects network traffic. Such solutions will no longer function
when traffic between clients and resolvers is encrypted. Many DNS when traffic between clients and resolvers is encrypted. Many DNS
privacy service operators still have need to inspect DNS traffic, privacy service operators still need to inspect DNS traffic -- e.g.,
e.g., to monitor for network security threats. Operators may to monitor for network security threats. Operators may therefore
therefore need to invest in alternative means of monitoring that need to invest in an alternative means of monitoring that relies on
relies on either the resolver software directly, or exporting DNS either the resolver software directly, or exporting DNS traffic from
traffic from the resolver using e.g., [dnstap]. the resolver using, for example, [dnstap].
Optimization: Optimization:
When implementing alternative means for traffic monitoring,
operators of a DNS privacy service should consider using privacy-
conscious means to do so. See Section 5.2 for more details on
data handling and the discussion on the use of Bloom Filters in
Appendix B.
When implementing alternative means for traffic monitoring, operators 5.1.8. Limitations of Fronting a DNS Privacy Service with a Pure TLS
of a DNS privacy service should consider using privacy conscious Proxy
means to do so (see section Section 5.2 for more details on data
handling and also the discussion on the use of Bloom Filters in
Appendix B.
5.1.8. Limitations of fronting a DNS privacy service with a pure TLS
proxy
DNS Privacy Threats: DNS Privacy Threats:
* Limited ability to manage or monitor incoming connections using
DNS-specific techniques.
o Limited ability to manage or monitor incoming connections using * Misconfiguration (e.g., of the target-server address in the
DNS specific techniques. proxy configuration) could lead to data leakage if the proxy-
to-target-server path is not encrypted.
o Misconfiguration (e.g., of the target server address in the proxy
configuration) could lead to data leakage if the proxy to target
server path is not encrypted.
Optimization: Optimization:
Some operators may choose to implement DoT using a TLS proxy
(e.g., [nginx], [haproxy], or [stunnel]) in front of a DNS
nameserver because of proven robustness and capacity when handling
large numbers of client connections, load-balancing capabilities,
and good tooling. Currently, however, because such proxies
typically have no specific handling of DNS as a protocol over TLS
or DTLS, using them can restrict traffic management at the proxy
layer and the DNS server. For example, all traffic received by a
nameserver behind such a proxy will appear to originate from the
proxy, and DNS techniques such as Access Control Lists (ACLs),
Response Rate Limiting (RRL), or DNS64 [RFC6147] will be hard or
impossible to implement in the nameserver.
Some operators may choose to implement DoT using a TLS proxy (e.g. Operators may choose to use a DNS-aware proxy, such as [dnsdist],
[nginx], [haproxy], or [stunnel]) in front of a DNS nameserver that offers custom options (similar to those proposed in
because of proven robustness and capacity when handling large numbers [DNS-XPF]) to add source information to packets to address this
of client connections, load balancing capabilities and good tooling. shortcoming. It should be noted that such options potentially
Currently, however, because such proxies typically have no specific significantly increase the leaked information in the event of a
handling of DNS as a protocol over TLS or DTLS using them can misconfiguration.
restrict traffic management at the proxy layer and at the DNS server.
For example, all traffic received by a nameserver behind such a proxy
will appear to originate from the proxy and DNS techniques such as
ACLs, RRL, or DNS64 will be hard or impossible to implement in the
nameserver.
Operators may choose to use a DNS aware proxy such as [dnsdist] which
offers custom options (similar to that proposed in
[I-D.bellis-dnsop-xpf]) to add source information to packets to
address this shortcoming. It should be noted that such options
potentially significantly increase the leaked information in the
event of a misconfiguration.
5.2. Data at rest on the server
5.2.1. Data handling 5.2. Data at Rest on the Server
[RFC6973] Threats: 5.2.1. Data Handling
o Surveillance. Threats described in [RFC6973]:
* Surveillance.
o Stored data compromise. * Stored-data compromise.
o Correlation. * Correlation.
o Identification. * Identification.
o Secondary use. * Secondary use.
o Disclosure. * Disclosure.
Other Threats Other Threats
* Contravention of legal requirements not to process user data.
o Contravention of legal requirements not to process user data.
Mitigations: Mitigations:
The following are recommendations relating to common activities
for DNS service operators; in all cases, data retention should be
minimized or completely avoided if possible for DNS privacy
services. If data is retained, it should be encrypted and either
aggregated, pseudonymized, or anonymized whenever possible. In
general, the principle of data minimization described in [RFC6973]
should be applied.
The following are recommendations relating to common activities for * Transient data (e.g., data used for real-time monitoring and
DNS service operators and in all cases data retention should be threat analysis, which might be held only in memory) should be
minimized or completely avoided if possible for DNS privacy services. retained for the shortest possible period deemed operationally
If data is retained it should be encrypted and either aggregated, feasible.
pseudonymized, or anonymized whenever possible. In general the
principle of data minimization described in [RFC6973] should be
applied.
o Transient data (e.g., that is used for real time monitoring and
threat analysis which might be held only in memory) should be
retained for the shortest possible period deemed operationally
feasible.
o The retention period of DNS traffic logs should be only those * The retention period of DNS traffic logs should be only as long
required to sustain operation of the service and, to the extent as is required to sustain operation of the service and meet
that such exists, meet regulatory requirements. regulatory requirements, to the extent that they exist.
o DNS privacy services should not track users except for the * DNS privacy services should not track users except for the
particular purpose of detecting and remedying technically particular purpose of detecting and remedying technically
malicious (e.g., DoS) or anomalous use of the service. malicious (e.g., DoS) or anomalous use of the service.
o Data access should be minimized to only those personnel who * Data access should be minimized to only those personnel who
require access to perform operational duties. It should also be require access to perform operational duties. It should also
limited to anonymized or pseudonymized data where operationally be limited to anonymized or pseudonymized data where
feasible, with access to full logs (if any are held) only operationally feasible, with access to full logs (if any are
permitted when necessary. held) only permitted when necessary.
Optimizations: Optimizations:
* Consider use of full-disk encryption for logs and data-capture
storage.
o Consider use of full disk encryption for logs and data capture 5.2.2. Data Minimization of Network Traffic
storage.
5.2.2. Data minimization of network traffic
Data minimization refers to collecting, using, disclosing, and Data minimization refers to collecting, using, disclosing, and
storing the minimal data necessary to perform a task, and this can be storing the minimal data necessary to perform a task, and this can be
achieved by removing or obfuscating privacy-sensitive information in achieved by removing or obfuscating privacy-sensitive information in
network traffic logs. This is typically personal data, or data that network traffic logs. This is typically personal data or data that
can be used to link a record to an individual, but may also include can be used to link a record to an individual, but it may also
revealing other confidential information, for example on the include other confidential information -- for example, on the
structure of an internal corporate network. structure of an internal corporate network.
The problem of effectively ensuring that DNS traffic logs contain no The problem of effectively ensuring that DNS traffic logs contain no
or minimal privacy-sensitive information is not one that currently or minimal privacy-sensitive information is not one that currently
has a generally agreed solution or any standards to inform this has a generally agreed solution or any standards to inform this
discussion. This section presents an overview of current techniques discussion. This section presents an overview of current techniques
to simply provide reference on the current status of this work. to simply provide reference on the current status of this work.
Research into data minimization techniques (and particularly IP Research into data minimization techniques (and particularly IP
address pseudonymization/anonymization) was sparked in the late address pseudonymization/anonymization) was sparked in the late 1990s
1990s/early 2000s, partly driven by the desire to share significant / early 2000s, partly driven by the desire to share significant
corpuses of traffic captures for research purposes. Several corpuses of traffic captures for research purposes. Several
techniques reflecting different requirements in this area and techniques reflecting different requirements in this area and
different performance/resource tradeoffs emerged over the course of different performance/resource trade-offs emerged over the course of
the decade. Developments over the last decade have been both a the decade. Developments over the last decade have been both a
blessing and a curse; the large increase in size between an IPv4 and blessing and a curse; the large increase in size between an IPv4 and
an IPv6 address, for example, renders some techniques impractical, an IPv6 address, for example, renders some techniques impractical,
but also makes available a much larger amount of input entropy, the but also makes available a much larger amount of input entropy, the
better to resist brute force re-identification attacks that have better to resist brute-force re-identification attacks that have
grown in practicality over the period. grown in practicality over the period.
Techniques employed may be broadly categorized as either Techniques employed may be broadly categorized as either
anonymization or pseudonymization. The following discussion uses the anonymization or pseudonymization. The following discussion uses the
definitions from [RFC6973] Section 3, with additional observations definitions from [RFC6973], Section 3, with additional observations
from [van-Dijkhuizen-et-al.] from [van-Dijkhuizen-et-al].
o Anonymization. To enable anonymity of an individual, there must * Anonymization. To enable anonymity of an individual, there must
exist a set of individuals that appear to have the same exist a set of individuals that appear to have the same
attribute(s) as the individual. To the attacker or the observer, attribute(s) as the individual. To the attacker or the observer,
these individuals must appear indistinguishable from each other. these individuals must appear indistinguishable from each other.
o Pseudonymization. The true identity is deterministically replaced * Pseudonymization. The true identity is deterministically replaced
with an alternate identity (a pseudonym). When the with an alternate identity (a pseudonym). When the
pseudonymization schema is known, the process can be reversed, so pseudonymization schema is known, the process can be reversed, so
the original identity becomes known again. the original identity becomes known again.
In practice there is a fine line between the two; for example, how to In practice, there is a fine line between the two; for example, it is
categorize a deterministic algorithm for data minimization of IP difficult to categorize a deterministic algorithm for data
addresses that produces a group of pseudonyms for a single given minimization of IP addresses that produces a group of pseudonyms for
address. a single given address.
5.2.3. IP address pseudonymization and anonymization methods 5.2.3. IP Address Pseudonymization and Anonymization Methods
A major privacy risk in DNS is connecting DNS queries to an A major privacy risk in DNS is connecting DNS queries to an
individual and the major vector for this in DNS traffic is the client individual, and the major vector for this in DNS traffic is the
IP address. client IP address.
There is active discussion in the space of effective pseudonymization There is active discussion in the space of effective pseudonymization
of IP addresses in DNS traffic logs, however there seems to be no of IP addresses in DNS traffic logs; however, there seems to be no
single solution that is widely recognized as suitable for all or most single solution that is widely recognized as suitable for all or most
use cases. There are also as yet no standards for this that are use cases. There are also as yet no standards for this that are
unencumbered by patents. unencumbered by patents.
Appendix B provides a more detailed survey of various techniques Appendix B provides a more detailed survey of various techniques
employed or under development in 2019. employed or under development in 2020.
5.2.4. Pseudonymization, anonymization, or discarding of other 5.2.4. Pseudonymization, Anonymization, or Discarding of Other
correlation data Correlation Data
DNS Privacy Threats: DNS Privacy Threats:
* Fingerprinting of the client OS via various means, including:
IP TTL/Hoplimit, TCP parameters (e.g., window size, Explicit
Congestion Notification (ECN) support, selective acknowledgment
(SACK)), OS-specific DNS query patterns (e.g., for network
connectivity, captive portal detection, or OS-specific
updates).
o Fingerprinting of the client OS via various means including: IP * Fingerprinting of the client application or TLS library by, for
TTL/Hoplimit, TCP parameters (e.g., window size, ECN support, example, HTTP headers (e.g., User-Agent, Accept, Accept-
SACK), OS specific DNS query patterns (e.g., for network Encoding), TLS version/Cipher-suite combinations, or other
connectivity, captive portal detection, or OS specific updates). connection parameters.
o Fingerprinting of the client application or TLS library by, e.g.,
HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS
version/Cipher suite combinations, or other connection parameters.
o Correlation of queries on multiple TCP sessions originating from * Correlation of queries on multiple TCP sessions originating
the same IP address. from the same IP address.
o Correlating of queries on multiple TLS sessions originating from * Correlating of queries on multiple TLS sessions originating
the same client, including via session resumption mechanisms. from the same client, including via session-resumption
mechanisms.
o Resolvers _might_ receive client identifiers, e.g., MAC addresses * Resolvers _might_ receive client identifiers -- e.g., Media
in EDNS(0) options - some Customer-premises equipment (CPE) Access Control (MAC) addresses in EDNS(0) options. Some
devices are known to add them [MAC-address-EDNS]. customer premises equipment (CPE) devices are known to add them
[MAC-address-EDNS].
Mitigations: Mitigations:
* Data minimization or discarding of such correlation data.
o Data minimization or discarding of such correlation data. 5.2.5. Cache Snooping
5.2.5. Cache snooping
[RFC6973] Threats:
o Surveillance:
* Profiling of client queries by malicious third parties. Threats described in [RFC6973]:
Surveillance:
Profiling of client queries by malicious third parties.
Mitigations: Mitigations:
See [ISC-Knowledge-database-on-cache-snooping] for an example
o See [ISC-Knowledge-database-on-cache-snooping] for an example
discussion on defending against cache snooping. Options proposed discussion on defending against cache snooping. Options proposed
include limiting access to a server and limiting non-recursive include limiting access to a server and limiting nonrecursive
queries. queries.
5.3. Data sent onwards from the server 5.3. Data Sent Onwards from the Server
In this section we consider both data sent on the wire in upstream In this section, we consider both data sent on the wire in upstream
queries and data shared with third parties. queries and data shared with third parties.
5.3.1. Protocol recommendations 5.3.1. Protocol Recommendations
[RFC6973] Threats:
o Surveillance:
* Transmission of identifying data upstream. Threats described in [RFC6973]:
Surveillance:
Transmission of identifying data upstream.
Mitigations: Mitigations:
The server should:
As specified in [RFC8310] for DoT but applicable to any DNS Privacy * implement QNAME minimization [RFC7816].
services the server should:
o Implement QNAME minimization [RFC7816].
o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the * honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
EDNS(0) Client Subnet (ECS) option ([RFC7871] Section 7.1.2). EDNS(0) Client Subnet (ECS) option ([RFC7871], Section 7.1.2).
This is as specified in [RFC8310] for DoT but applicable to any
DNS privacy service.
Optimizations: Optimizations:
As per Section 2 of [RFC7871], the server should either:
o As per Section 2 of [RFC7871] the server should either:
* not use the ECS option in upstream queries at all, or * not use the ECS option in upstream queries at all, or
* offer alternative services, one that sends ECS and one that * offer alternative services, one that sends ECS and one that
does not. does not.
If operators do offer a service that sends the ECS options upstream If operators do offer a service that sends the ECS options upstream,
they should use the shortest prefix that is operationally feasible they should use the shortest prefix that is operationally feasible
and ideally use a policy of allowlisting upstream servers to send ECS and ideally use a policy of allowlisting upstream servers to which to
to in order to reduce data leakage. Operators should make clear in send ECS in order to reduce data leakage. Operators should make
any policy statement what prefix length they actually send and the clear in any policy statement what prefix length they actually send
specific policy used. and the specific policy used.
Allowlisting has the benefit that not only does the operator know Allowlisting has the benefit that not only does the operator know
which upstream servers can use ECS but also allows the operator to which upstream servers can use ECS, but also the operator can decide
decide which upstream servers apply privacy policies that the which upstream servers apply privacy policies that the operator is
operator is happy with. However some operators consider allowlisting happy with. However, some operators consider allowlisting to incur
to incur significant operational overhead compared to dynamic significant operational overhead compared to dynamic detection of ECS
detection of ECS support on authoritative servers. support on authoritative servers.
Additional options: Additional options:
o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020] * "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] and
(NXDOMAIN: There Really Is Nothing Underneath) to reduce the "NXDOMAIN: There Really Is Nothing Underneath" [RFC8020] to reduce
number of queries to authoritative servers to increase privacy. the number of queries to authoritative servers to increase
privacy.
o Run a copy of the root zone on loopback [RFC8806] to avoid making * Run a local copy of the root zone [RFC8806] to avoid making
queries to the root servers that might leak information. queries to the root servers that might leak information.
5.3.2. Client query obfuscation 5.3.2. Client Query Obfuscation
Additional options: Additional options:
Since queries from recursive resolvers to authoritative servers are Since queries from recursive resolvers to authoritative servers are
performed using cleartext (at the time of writing), resolver services performed using cleartext (at the time of writing), resolver services
need to consider the extent to which they may be directly leaking need to consider the extent to which they may be directly leaking
information about their client community via these upstream queries information about their client community via these upstream queries
and what they can do to mitigate this further. Note, that even when and what they can do to mitigate this further. Note that, even when
all the relevant techniques described above are employed there may all the relevant techniques described above are employed, there may
still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For still be attacks possible -- e.g., [Pitfalls-of-DNS-Encryption]. For
example, a resolver with a very small community of users risks example, a resolver with a very small community of users risks
exposing data in this way and ought to obfuscate this traffic by exposing data in this way and ought to obfuscate this traffic by
mixing it with 'generated' traffic to make client characterization mixing it with "generated" traffic to make client characterization
harder. The resolver could also employ aggressive pre-fetch harder. The resolver could also employ aggressive prefetch
techniques as a further measure to counter traffic analysis. techniques as a further measure to counter traffic analysis.
At the time of writing there are no standardized or widely recognized At the time of writing, there are no standardized or widely
techniques to perform such obfuscation or bulk pre-fetches. recognized techniques to perform such obfuscation or bulk prefetches.
Another technique that particularly small operators may consider is Another technique that particularly small operators may consider is
forwarding local traffic to a larger resolver (with a privacy policy forwarding local traffic to a larger resolver (with a privacy policy
that aligns with their own practices) over an encrypted protocol so that aligns with their own practices) over an encrypted protocol, so
that the upstream queries are obfuscated among those of the large that the upstream queries are obfuscated among those of the large
resolver. resolver.
5.3.3. Data sharing 5.3.3. Data Sharing
[RFC6973] Threats:
o Surveillance. Threats described in [RFC6973]:
* Surveillance.
o Stored data compromise. * Stored-data compromise.
o Correlation. * Correlation.
o Identification. * Identification.
o Secondary use. * Secondary use.
o Disclosure. * Disclosure.
DNS Privacy Threats: DNS Privacy Threats:
Contravention of legal requirements not to process user data.
o Contravention of legal requirements not to process user data.
Mitigations: Mitigations:
Operators should not share identifiable data with third parties.
Operators should not share identifiable data with third-parties. If operators choose to share identifiable data with third parties
in specific circumstances, they should publish the terms under
If operators choose to share identifiable data with third-parties in which data is shared.
specific circumstance they should publish the terms under which data
is shared.
Operators should consider including specific guidelines for the Operators should consider including specific guidelines for the
collection of aggregated and/or anonymized data for research collection of aggregated and/or anonymized data for research
purposes, within or outside of their own organization. This can purposes, within or outside of their own organization. This can
benefit not only the operator (through inclusion in novel research) benefit not only the operator (through inclusion in novel
but also the wider Internet community. See the policy published by research) but also the wider Internet community. See the policy
SURFnet [SURFnet-policy] on data sharing for research as an example. published by SURFnet [SURFnet-policy] on data sharing for research
as an example.
6. Recursive operator Privacy Statement (RPS) 6. Recursive Operator Privacy Statement (RPS)
To be compliant with this Best Common Practices document, a DNS To be compliant with this Best Current Practice document, a DNS
recursive operator SHOULD publish a Recursive operator Privacy recursive operator SHOULD publish a Recursive operator Privacy
Statement (RPS). Adopting the outline, and including the headings in Statement (RPS). Adopting the outline, and including the headings in
the order provided, is a benefit to persons comparing RPSs from the order provided, is a benefit to persons comparing RPSs from
multiple operators. multiple operators.
Appendix C provides a comparison of some existing policy and privacy Appendix C provides a comparison of some existing policy and privacy
statements. statements.
6.1. Outline of an RPS 6.1. Outline of an RPS
The contents of Section 6.1.1 and Section 6.1.2 are non-normative, The contents of Sections 6.1.1 and 6.1.2 are non-normative, other
other than the order of the headings. Material under each topic is than the order of the headings. Material under each topic is present
present to assist the operator developing their own RPS and: to assist the operator developing their own RPS. This material:
o Relates _only_ to matters around to the technical operation of DNS * Relates _only_ to matters around the technical operation of DNS
privacy services, and not on any other matters. privacy services, and no other matters.
o Does not attempt to offer an exhaustive list for the contents of * Does not attempt to offer an exhaustive list for the contents of
an RPS. an RPS.
o Is not intended to form the basis of any legal/compliance * Is not intended to form the basis of any legal/compliance
documentation. documentation.
Appendix D provides an example (also non-normative) of an RPS Appendix D provides an example (also non-normative) of an RPS
statement for a specific operator scenario. statement for a specific operator scenario.
6.1.1. Policy 6.1.1. Policy
1. Treatment of IP addresses. Make an explicit statement that IP 1. Treatment of IP addresses. Make an explicit statement that IP
addresses are treated as personal data. addresses are treated as personal data.
2. Data collection and sharing. Specify clearly what data 2. Data collection and sharing. Specify clearly what data
(including IP addresses) is: (including IP addresses) is:
* Collected and retained by the operator, and for what period it * Collected and retained by the operator, and for what period it
is retained. is retained.
* Shared with partners. * Shared with partners.
* Shared, sold, or rented to third-parties. * Shared, sold, or rented to third parties.
and in each case whether it is aggregated, pseudonymized, or In each case, specify whether data is aggregated, pseudonymized,
anonymized and the conditions of data transfer. Where possible or anonymized and the conditions of data transfer. Where
provide details of the techniques used for the above data possible provide details of the techniques used for the above
minimizations. data minimizations.
3. Exceptions. Specify any exceptions to the above, for example, 3. Exceptions. Specify any exceptions to the above -- for example,
technically malicious or anomalous behavior. technically malicious or anomalous behavior.
4. Associated entities. Declare and explicitly enumerate any 4. Associated entities. Declare and explicitly enumerate any
partners, third-party affiliations, or sources of funding. partners, third-party affiliations, or sources of funding.
5. Correlation. Whether user DNS data is correlated or combined 5. Correlation. Whether user DNS data is correlated or combined
with any other personal information held by the operator. with any other personal information held by the operator.
6. Result filtering. This section should explain whether the 6. Result filtering. This section should explain whether the
operator filters, edits or alters in any way the replies that it operator filters, edits, or alters in any way the replies that it
receives from the authoritative servers for each DNS zone, before receives from the authoritative servers for each DNS zone before
forwarding them to the clients. For each category listed below, forwarding them to the clients. For each category listed below,
the operator should also specify how the filtering lists are the operator should also specify how the filtering lists are
created and managed, whether it employs any third-party sources created and managed, whether it employs any third-party sources
for such lists, and which ones. for such lists, and which ones.
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
network and computer security reasons (e.g., preventing network- and computer-security reasons (e.g., preventing
connections to malware-spreading websites or botnet control connections to malware-spreading websites or botnet control
servers). servers).
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
mandatory legal reasons, due to applicable legislation or mandatory legal reasons, due to applicable legislation or
binding orders by courts and other public authorities. binding orders by courts and other public authorities.
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
voluntary legal reasons, due to an internal policy by the voluntary legal reasons, due to an internal policy by the
operator aiming at reducing potential legal risks. operator aiming at reducing potential legal risks.
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
any other reason, including commercial ones. any other reason, including commercial ones.
6.1.2. Practice 6.1.2. Practice
[NOTE FOR RFC EDITOR: Please update this section to use letters for
the sub-bullet points instead of numbers. This was not done during
review because the markdown tool used to write the document did not
support it.]
Communicate the current operational practices of the service. Communicate the current operational practices of the service.
1. Deviations. Specify any temporary or permanent deviations from 1. Deviations. Specify any temporary or permanent deviations from
the policy for operational reasons. the policy for operational reasons.
2. Client facing capabilities. With reference to each subsection of 2. Client-facing capabilities. With reference to each subsection of
Section 5.1 provide specific details of which capabilities Section 5.1, provide specific details of which capabilities
(transport, DNSSEC, padding, etc.) are provided on which client (transport, DNSSEC, padding, etc.) are provided on which client-
facing addresses/port combination or DoH URI template. For facing addresses/port combination or DoH URI template. For
Section 5.1.2, clearly specify which specific authentication Section 5.1.2, clearly specify which specific authentication
mechanisms are supported for each endpoint that offers DoT: mechanisms are supported for each endpoint that offers DoT:
1. The authentication domain name to be used (if any). a. The authentication domain name to be used (if any).
2. The SPKI pin sets to be used (if any) and policy for rolling b. The SPKI pin sets to be used (if any) and policy for rolling
keys. keys.
3. Upstream capabilities. With reference to section Section 5.3 3. Upstream capabilities. With reference to Section 5.3, provide
provide specific details of which capabilities are provided specific details of which capabilities are provided upstream for
upstream for data sent to authoritative servers. data sent to authoritative servers.
4. Support. Provide contact/support information for the service. 4. Support. Provide contact/support information for the service.
5. Data Processing. This section can optionally communicate links 5. Data Processing. This section can optionally communicate links
to and the high level contents of any separate statements the to, and the high-level contents of, any separate statements the
operator has published which cover applicable data processing operator has published that cover applicable data-processing
legislation or agreements with regard to the location(s) of legislation or agreements with regard to the location(s) of
service provision. service provision.
6.2. Enforcement/accountability 6.2. Enforcement/Accountability
Transparency reports may help with building user trust that operators Transparency reports may help with building user trust that operators
adhere to their policies and practices. adhere to their policies and practices.
Independent monitoring or analysis could be performed where possible Where possible, independent monitoring or analysis could be performed
of: of:
o ECS, QNAME minimization, EDNS(0) padding, etc. * ECS, QNAME minimization, EDNS(0) padding, etc.
o Filtering. * Filtering.
o Uptime. * Uptime.
This is by analogy with several TLS or website analysis tools that This is by analogy with several TLS or website-analysis tools that
are currently available e.g., [SSL-Labs] or [Internet.nl]. are currently available -- e.g., [SSL-Labs] or [Internet.nl].
Additionally operators could choose to engage the services of a third Additionally, operators could choose to engage the services of a
party auditor to verify their compliance with their published RPS. third-party auditor to verify their compliance with their published
RPS.
7. IANA considerations 7. IANA Considerations
None This document has no IANA actions.
8. Security considerations 8. Security Considerations
Security considerations for DNS over TCP are given in [RFC7766], many Security considerations for DNS over TCP are given in [RFC7766], many
of which are generally applicable to session based DNS. Guidance on of which are generally applicable to session-based DNS. Guidance on
operational requirements for DNS over TCP are also available in [I- operational requirements for DNS over TCP are also available in
D.dnsop-dns-tcp-requirements]. Security considerations for DoT are [DNS-OVER-TCP]. Security considerations for DoT are given in
given in [RFC7858] and [RFC8310], those for DoH in [RFC8484]. [RFC7858] and [RFC8310], and those for DoH in [RFC8484].
Security considerations for DNSSEC are given in [RFC4033], [RFC4034] Security considerations for DNSSEC are given in [RFC4033], [RFC4034],
and [RFC4035]. and [RFC4035].
9. Acknowledgements 9. References
Many thanks to Amelia Andersdotter for a very thorough review of the
first draft of this document and Stephen Farrell for a thorough
review at WGLC and for suggesting the inclusion of an example RPS.
Thanks to John Todd for discussions on this topic, and to Stephane
Bortzmeyer, Puneet Sood and Vittorio Bertola for review. Thanks to
Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Jon Reed,
Lorenzo Colitti for comments at the mic. Thanks to Loganaden
Velvindron for useful updates to the text.
Sara Dickinson thanks the Open Technology Fund for a grant to support
the work on this document.
10. Contributors
The below individuals contributed significantly to the document:
John Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Jim Hague
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
11. Changelog
draft-ietf-dprive-bcp-op-13
o Minor edits
draft-ietf-dprive-bcp-op-12
o Change DROP to RPS throughout
draft-ietf-dprive-bcp-op-11
o Improve text around use of normative language
o Fix section 5.1.3.2 bullets
o Improve text in 6.1.2. item 2.
o Rework text of 6.1.2. item 5 and update example DROP
o Various editorial improvements
draft-ietf-dprive-bcp-op-10
o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead
have one general reference RFC7626
o Clarify that the DROP statement outline is non-normative and add
some further qualifications about content
o Update wording on data sharing to remove explicit discussion of
consent
o Move table in section 5.2.3 to an appendix
o Move section 6.2 to an appendix
o Corrections to references, typos and editorial updates from
initial IESG comments.
draft-ietf-dprive-bcp-op-09
o Fix references so they match the correct section numbers in draft-
ietf-dprive-rfc7626-bis-05
draft-ietf-dprive-bcp-op-08
o Address IETF Last call comments.
o Editorial changes following AD review.
o Change all URIs to Informational References.
draft-ietf-dprive-bcp-op-06
o Final minor changes from second WGLC.
draft-ietf-dprive-bcp-op-05
o Remove some text on consent:
* Paragraph 2 in section 5.3.3
* Item 6 in the DROP Practice statement (and example)
o Remove .onion and TLSA options
o Include ACME as a reference for certificate management
o Update text on session resumption usage
o Update section 5.2.4 on client fingerprinting
draft-ietf-dprive-bcp-op-04
o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement
o Update structure of DROP slightly
o Add example DROP statement
o Add text about restricting access to full logs
o Move table in section 5.2.3 from SVG to inline table
o Fix many editorial and reference nits
draft-ietf-dprive-bcp-op-03
o Add paragraph about operational impact
o Move DNSSEC requirement out of the Appendix into main text as a
privacy threat that should be mitigated
o Add TLS version/Cipher suite as tracking threat
o Add reference to Mozilla TRR policy
o Remove several TODOs and QUESTIONS.
draft-ietf-dprive-bcp-op-02
o Change 'open resolver' for 'public resolver'
o Minor editorial changes
o Remove recommendation to run a separate TLS 1.3 service
o Move TLSA to purely a optimization in Section 5.2.1
o Update reference on minimal DoH headers.
o Add reference on user switching provider after service issues in
Section 5.1.4
o Add text in Section 5.1.6 on impact on operators.
o Add text on additional threat to TLS proxy use (Section 5.1.7)
o Add reference in Section 5.3.1 on example policies.
draft-ietf-dprive-bcp-op-01
o Many minor editorial fixes
o Update DoH reference to RFC8484 and add more text on DoH
o Split threat descriptions into ones directly referencing RFC6973
and other DNS Privacy threats
o Improve threat descriptions throughout
o Remove reference to the DNSSEC TLS Chain Extension draft until new
version submitted.
o Clarify use of allowlisting for ECS
o Re-structure the DPPPS, add Result filtering section.
o Remove the direct inclusion of privacy policy comparison, now just
reference dnsprivacy.org and an example of such work.
o Add an appendix briefly discussing DNSSEC
o Update affiliation of 1 author
draft-ietf-dprive-bcp-op-00
o Initial commit of re-named document after adoption to replace
draft-dickinson-dprive-bcp-op-01
12. References
12.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[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>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[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
skipping to change at page 28, line 11 skipping to change at line 1080
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
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>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828, edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016, <https://www.rfc- DOI 10.17487/RFC7828, April 2016,
editor.org/info/rfc7828>. <https://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, <https://www.rfc- DOI 10.17487/RFC7830, May 2016,
editor.org/info/rfc7830>. <https://www.rfc-editor.org/info/rfc7830>.
[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>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>. November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, <https://www.rfc- DOI 10.17487/RFC8310, March 2018,
editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>. October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[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>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
skipping to change at page 29, line 18 skipping to change at line 1135
<https://www.rfc-editor.org/info/rfc8490>. <https://www.rfc-editor.org/info/rfc8490>.
[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>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>. <https://www.rfc-editor.org/info/rfc8806>.
12.2. Informative References 9.2. Informative References
[Bloom-filter] [Bloom-filter]
van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L. van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
Allodi, "Privacy-Conscious Threat Intelligence Using Allodi, "Privacy-Conscious Threat Intelligence Using
DNSBLOOM", 2019, DNSBLOOM", IFIP/IEEE International Symposium on Integrated
Network Management (IM2019), 2019,
<http://dl.ifip.org/db/conf/im/im2019/189282.pdf>. <http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.
[Brenker-and-Arnes] [Brekne-and-Arnes]
Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS Brekne, T. and A. Årnes, "Circumventing IP-address
PSEUDONYMIZATION", 2005, <https://pdfs.semanticscholar.org pseudonymization", Communications and Computer Networks,
/7b34/12c951cebe71cd2cddac5fda164fb2138a44.pdf>. 2005, <https://pdfs.semanticscholar.org/7b34/12c951cebe71c
d2cddac5fda164fb2138a44.pdf>.
[BUILD-W-HTTP]
Nottingham, M., "Building Protocols with HTTP", Work in
Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09,
1 November 2019, <https://tools.ietf.org/html/draft-ietf-
httpbis-bcp56bis-09>.
[Crypto-PAn] [Crypto-PAn]
CESNET, "Crypto-PAn", 2015, CESNET, "Crypto-PAn", commit 636b237, March 2015,
<https://github.com/CESNET/ipfixcol/tree/master/base/src/ <https://github.com/CESNET/ipfixcol/tree/master/base/src/
intermediate/anonymization/Crypto-PAn>. intermediate/anonymization/Crypto-PAn>.
[DNS-OVER-TCP]
Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", Work in Progress, Internet-
Draft, draft-ietf-dnsop-dns-tcp-requirements-06, 6 May
2020, <https://tools.ietf.org/html/draft-ietf-dnsop-dns-
tcp-requirements-06>.
[DNS-Privacy-not-so-private] [DNS-Privacy-not-so-private]
Silby, S., Juarez, M., Vallina-Rodriguez, N., and C. Silby, S., Juarez, M., Vallina-Rodriguez, N., and C.
Troncosol, "DNS Privacy not so private: the traffic Troncoso, "DNS Privacy not so private: the traffic
analysis perspective.", 2019, analysis perspective.", Privacy Enhancing
Technologies Symposium, 2018,
<https://petsymposium.org/2018/files/hotpets/4-siby.pdf>. <https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.
[dnsdist] PowerDNS, "dnsdist Overview", 2019, <https://dnsdist.org>. [DNS-XPF] Bellis, R., Dijk, P. V., and R. Gacogne, "DNS X-Proxied-
For", Work in Progress, Internet-Draft, draft-bellis-
dnsop-xpf-04, 5 March 2018,
<https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04>.
[dnstap] dnstap.info, "DNSTAP", 2019, <http://dnstap.info>. [DNSCrypt] "DNSCrypt - Official Project Home Page",
<https://www.dnscrypt.org>.
[dnsdist] PowerDNS, "dnsdist Overview", <https://dnsdist.org>.
[dnstap] "dnstap", <https://dnstap.info>.
[DoH-resolver-policy] [DoH-resolver-policy]
Mozilla, "Security/DOH-resolver-policy", 2019, Mozilla, "Security/DOH-resolver-policy", 2019,
<https://wiki.mozilla.org/Security/DOH-resolver-policy>. <https://wiki.mozilla.org/Security/DOH-resolver-policy>.
[dot-ALPN] [dot-ALPN] IANA, "Transport Layer Security (TLS) Extensions: TLS
IANA (iana.org), "TLS Application-Layer Protocol Application-Layer Protocol Negotiation (ALPN) Protocol
Negotiation (ALPN) Protocol IDs", 2020, IDs", <https://www.iana.org/assignments/tls-extensiontype-
<https://www.iana.org/assignments/tls-extensiontype- values>.
values/tls-extensiontype-values.xhtml#alpn-protocol-ids>.
[Geolocation-Impact-Assessement] [Geolocation-Impact-Assessment]
Conversion Works, "Anonymize IP Geolocation Accuracy Conversion Works, "Anonymize IP Geolocation Accuracy
Impact Assessment", 2017, Impact Assessment", 19 May 2017,
<https://support.google.com/analytics/ <https://www.conversionworks.co.uk/blog/2017/05/19/
answer/2763052?hl=en>. anonymize-ip-geo-impact-test/>.
[haproxy] haproxy.org, "HAPROXY", 2019, <https://www.haproxy.org/>. [haproxy] "HAProxy - The Reliable, High Performance TCP/HTTP Load
Balancer", <https://www.haproxy.org/>.
[Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving [Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving
IP Address Anonymization", 2006, IP Address Anonymization", IEEE/IFIP Network Operations
<http://mharvan.net/talks/noms-ip_anon.pdf>. and Management Symposium, DOI 10.1109/NOMS.2006.1687580,
2006, <http://mharvan.net/talks/noms-ip_anon.pdf>.
[I-D.bellis-dnsop-xpf]
Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",
draft-bellis-dnsop-xpf-04 (work in progress), March 2018.
[I-D.ietf-dnsop-dns-tcp-requirements]
Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", draft-ietf-dnsop-dns-tcp-
requirements-06 (work in progress), May 2020.
[I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-09 (work in progress), November
2019.
[Internet.nl] [Internet.nl]
Internet.nl, "Internet.nl Is Your Internet Up To Date?", Internet.nl, "Internet.nl Is Your Internet Up To Date?",
2019, <https://internet.nl>. 2019, <https://internet.nl>.
[IP-Anonymization-in-Analytics] [IP-Anonymization-in-Analytics]
Google, "IP Anonymization in Analytics", 2019, Google, "IP Anonymization in Analytics", 2019,
<https://support.google.com/analytics/ <https://support.google.com/analytics/
answer/2763052?hl=en>. answer/2763052?hl=en>.
[ipcipher1] [ipcipher1]
Hubert, B., "On IP address encryption: security analysis Hubert, B., "On IP address encryption: security analysis
with respect for privacy", 2017, with respect for privacy", Medium, 7 May 2017,
<https://medium.com/@bert.hubert/on-ip-address-encryption- <https://medium.com/@bert.hubert/on-ip-address-encryption-
security-analysis-with-respect-for-privacy-dabe1201b476>. security-analysis-with-respect-for-privacy-dabe1201b476>.
[ipcipher2] [ipcipher2]
PowerDNS, "ipcipher", 2017, <https://github.com/PowerDNS/ PowerDNS, "ipcipher", commit fd47abe, 13 February 2018,
ipcipher>. <https://github.com/PowerDNS/ipcipher>.
[ipcrypt] veorq, "ipcrypt: IP-format-preserving encryption", 2015, [ipcrypt] veorq, "ipcrypt: IP-format-preserving encryption",
commit 8cc12f9, 6 July 2015,
<https://github.com/veorq/ipcrypt>. <https://github.com/veorq/ipcrypt>.
[ipcrypt-analysis] [ipcrypt-analysis]
Aumasson, J., "Analysis of ipcrypt?", 2018, Aumasson, J-P., "Subject: Re: [Cfrg] Analysis of
<https://www.ietf.org/mail-archive/web/cfrg/current/ ipcrypt?", message to the Cfrg mailing list, 22 February
msg09494.html>. 2018, <https://mailarchive.ietf.org/arch/msg/cfrg/
cFx5WJo48ZEN-a5cj_LlyrdN8-0/>.
[ISC-Knowledge-database-on-cache-snooping] [ISC-Knowledge-database-on-cache-snooping]
ISC Knowledge Database, "DNS Cache snooping - should I be Goldlust, S. and C. Almond, "DNS Cache snooping - should I
concerned?", 2018, <https://kb.isc.org/docs/aa-00482>. be concerned?", ISC Knowledge Database, 15 October 2018,
<https://kb.isc.org/docs/aa-00482>.
[MAC-address-EDNS] [MAC-address-EDNS]
DNS-OARC mailing list, "Embedding MAC address in DNS Hubert, B., "Embedding MAC address in DNS requests for
requests for selective filtering IDs", 2016, selective filtering", DNS-OARC mailing list, 25 January
<https://lists.dns-oarc.net/pipermail/dns- 2016, <https://lists.dns-oarc.net/pipermail/dns-
operations/2016-January/014143.html>. operations/2016-January/014143.html>.
[nginx] nginx.org, "NGINX", 2019, <https://nginx.org/>. [nginx] nginx.org, "nginx news", 2019, <https://nginx.org/>.
[Passive-Observations-of-a-Large-DNS] [Passive-Observations-of-a-Large-DNS]
de Vries, W., van Rijswijk-Deij, R., de Boer, P., and A. de Vries, W. B., van Rijswijk-Deij, R., de Boer, P-T., and
Pras, "Passive Observations of a Large DNS Service: 2.5 A. Pras, "Passive Observations of a Large DNS Service: 2.5
Years in the Life of Google", 2018, Years in the Life of Google",
DOI 10.23919/TMA.2018.8506536, 2018,
<http://tma.ifip.org/2018/wp- <http://tma.ifip.org/2018/wp-
content/uploads/sites/3/2018/06/tma2018_paper30.pdf>. content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.
[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>. [pcap] The Tcpdump Group, "Tcpdump & Libpcap", 2020,
<https://www.tcpdump.org/>.
[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", 2014, <https://dl.acm.org/ Encryption", Proceedings of the 13th Workshop on Privacy
citation.cfm?id=2665959>. in the Electronic Society, pp. 191-200,
DOI 10.1145/2665943.2665959, November 2014,
<https://dl.acm.org/citation.cfm?id=2665959>.
[policy-comparison] [policy-comparison]
dnsprivacy.org, "Comparison of policy and privacy Dickinson, S., "Comparison of policy and privacy
statements 2019", 2019, statements 2019", DNS Privacy Project, 18 December 2019,
<https://dnsprivacy.org/wiki/display/DP/ <https://dnsprivacy.org/wiki/display/DP/
Comparison+of+policy+and+privacy+statements+2019>. Comparison+of+policy+and+privacy+statements+2019>.
[PowerDNS-dnswasher] [PowerDNS-dnswasher]
PowerDNS, "dnswasher", 2019, PowerDNS, "dnswasher", commit 050e687, 24 April 2020,
<https://github.com/PowerDNS/pdns/blob/master/pdns/ <https://github.com/PowerDNS/pdns/blob/master/pdns/
dnswasher.cc>. dnswasher.cc>.
[Ramaswamy-and-Wolf] [Ramaswamy-and-Wolf]
Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving
IP Address Anonymization for Passive Measurement Systems", IP Address Anonymization for Passive Measurement Systems",
2007, DOI 10.1109/TNET.2006.890128, 2007,
<http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>. <http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
<https://www.rfc-editor.org/info/rfc6235>. <https://www.rfc-editor.org/info/rfc6235>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, <https://www.rfc- DOI 10.17487/RFC6265, April 2011,
editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, <https://www.rfc- DOI 10.17487/RFC7626, August 2015,
editor.org/info/rfc7626>. <https://www.rfc-editor.org/info/rfc7626>.
[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>.
[RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
"DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
DOI 10.17487/RFC8027, November 2016, <https://www.rfc- DOI 10.17487/RFC8027, November 2016,
editor.org/info/rfc8027>. <https://www.rfc-editor.org/info/rfc8027>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc- DOI 10.17487/RFC8094, February 2017,
editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404, Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018, <https://www.rfc- DOI 10.17487/RFC8404, July 2018,
editor.org/info/rfc8404>. <https://www.rfc-editor.org/info/rfc8404>.
[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>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., [RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
2019, <https://www.rfc-editor.org/info/rfc8618>. 2019, <https://www.rfc-editor.org/info/rfc8618>.
[SSL-Labs] [SSL-Labs] SSL Labs, "SSL Server Test", 2019,
SSL Labs, "SSL Server Test", 2019,
<https://www.ssllabs.com/ssltest/>. <https://www.ssllabs.com/ssltest/>.
[stunnel] ISC Knowledge Database, "DNS-over-TLS", 2018, [stunnel] Goldlust, S., Almond, C., and F. Dupont, "DNS over TLS",
ISC Knowledge Database", 1 November 2018,
<https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>. <https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.
[SURFnet-policy] [SURFnet-policy]
SURFnet, "SURFnet Data Sharing Policy", 2016, Baartmans, C., van Wynsberghe, A., van Rijswijk-Deij, R.,
and F. Jorna, "SURFnet Data Sharing Policy", June 2016,
<https://surf.nl/datasharing>. <https://surf.nl/datasharing>.
[TCPdpriv] [tcpdpriv] Ipsilon Networks, Inc., "TCPDRIV - Program for Eliminating
Ipsilon Networks, Inc., "TCPdpriv", 2005, Confidential Information from Traces", 2004,
<http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html>. <http://fly.isti.cnr.it/software/tcpdpriv/>.
[van-Dijkhuizen-et-al.] [van-Dijkhuizen-et-al]
Van Dijkhuizen , N. and J. Van Der Ham, "A Survey of Van Dijkhuizen, N. and J. Van Der Ham, "A Survey of
Network Traffic Anonymisation Techniques and Network Traffic Anonymisation Techniques and
Implementations", 2018, <https://doi.org/10.1145/3182660>. Implementations", ACM Computing Surveys,
DOI 10.1145/3182660, May 2018,
<https://doi.org/10.1145/3182660>.
[Xu-et-al.] [Xu-et-al] Fan, J., Xu, J., Ammar, M.H., and S.B. Moon, "Prefix-
Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-
preserving IP address anonymization: measurement-based preserving IP address anonymization: measurement-based
security evaluation and a new cryptography-based scheme", security evaluation and a new cryptography-based scheme",
2004, <http://an.kaist.ac.kr/~sbmoon/paper/ DOI 10.1016/j.comnet.2004.03.033, 2004,
intl-journal/2004-cn-anon.pdf>. <http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
anon.pdf>.
Appendix A. Documents Appendix A. Documents
This section provides an overview of some DNS privacy-related This section provides an overview of some DNS privacy-related
documents, however, this is neither an exhaustive list nor a documents. However, this is neither an exhaustive list nor a
definitive statement on the characteristic of the document. definitive statement on the characteristics of any document with
regard to potential increases or decreases in DNS privacy.
A.1. Potential increases in DNS privacy A.1. Potential Increases in DNS Privacy
These documents are limited in scope to communications between stub These documents are limited in scope to communications between stub
clients and recursive resolvers: clients and recursive resolvers:
o 'Specification for DNS over Transport Layer Security (TLS)' * "Specification for DNS over Transport Layer Security (TLS)"
[RFC7858]. [RFC7858].
o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094]. * "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094].
Note that this document has the Category of Experimental. Note that this document has the category of Experimental.
o 'DNS Queries over HTTPS (DoH)' [RFC8484]. * "DNS Queries over HTTPS (DoH)" [RFC8484].
o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310]. * "Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310].
o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for * "The EDNS(0) Padding Option" [RFC7830] and "Padding Policies for
EDNS(0)' [RFC8467]. Extension Mechanisms for DNS (EDNS(0))" [RFC8467].
These documents apply to recursive and authoritative DNS but are These documents apply to recursive and authoritative DNS but are
relevant when considering the operation of a recursive server: relevant when considering the operation of a recursive server:
o 'DNS Query Name minimization to Improve Privacy' [RFC7816]. * "DNS Query Name Minimisation to Improve Privacy" [RFC7816].
A.2. Potential decreases in DNS privacy A.2. Potential Decreases in DNS Privacy
These documents relate to functionality that could provide increased These documents relate to functionality that could provide increased
tracking of user activity as a side effect: tracking of user activity as a side effect:
o 'Client Subnet in DNS Queries' [RFC7871]. * "Client Subnet in DNS Queries" [RFC7871].
o 'Domain Name System (DNS) Cookies' [RFC7873]). * "Domain Name System (DNS) Cookies" [RFC7873]).
o 'Transport Layer Security (TLS) Session Resumption without Server- * "Transport Layer Security (TLS) Session Resumption without Server-
Side State' [RFC5077] referred to here as simply TLS session Side State" [RFC5077], referred to here as simply TLS session
resumption. resumption.
o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS * [RFC8446], Appendix C.4 describes client tracking prevention in
1.3 TLS 1.3
o 'A DNS Packet Capture Format' [RFC8618]. * "Compacted-DNS (C-DNS): A Format for DNS Packet Capture"
[RFC8618].
o Passive DNS [RFC8499]. * Passive DNS [RFC8499].
o Section 8 of [RFC8484] outlines the privacy considerations of DoH. * Section 8 of [RFC8484] outlines the privacy considerations of DoH.
Note that (while that document advises exposing the minimal set of Note that (while that document advises exposing the minimal set of
data needed to achieve the desired feature set) depending on the data needed to achieve the desired feature set), depending on the
specifics of a DoH implementation there may be increased specifics of a DoH implementation, there may be increased
identification and tracking compared to other DNS transports. identification and tracking compared to other DNS transports.
A.3. Related operational documents A.3. Related Operational Documents
o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]. * "DNS Transport over TCP - Implementation Requirements" [RFC7766].
o 'Operational requirements for DNS over TCP' * "DNS Transport over TCP - Operational Requirements"
[I-D.ietf-dnsop-dns-tcp-requirements]. [DNS-OVER-TCP].
o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828]. * "The edns-tcp-keepalive EDNS0 Option" [RFC7828].
o 'DNS Stateful Operations' [RFC8490]. * "DNS Stateful Operations" [RFC8490].
Appendix B. IP address techniques Appendix B. IP Address Techniques
The following table presents a high level comparison of various The following table presents a high-level comparison of various
techniques employed or under development in 2019, and classifies them techniques employed or under development in 2019 and classifies them
according to categorization of technique and other properties. Both according to categorization of technique and other properties. Both
the specific techniques and the categorisations are described in more the specific techniques and the categorizations are described in more
detail in the following sections. The list of techniques includes detail in the following sections. The list of techniques includes
the main techniques in current use, but does not claim to be the main techniques in current use but does not claim to be
comprehensive. comprehensive.
+---------------------------+----+---+----+---+----+---+---+ +===========================+====+===+====+===+====+===+===+
| Categorization/Property | GA | d | TC | C | TS | i | B | | Categorization/Property | GA | d | TC | C | TS | i | B |
+---------------------------+----+---+----+---+----+---+---+ +===========================+====+===+====+===+====+===+===+
| Anonymization | X | X | X | | | | X | | Anonymization | X | X | X | | | | X |
| Pseudoanonymization | | | | X | X | X | | +---------------------------+----+---+----+---+----+---+---+
| Pseudonymization | | | | X | X | X | |
+---------------------------+----+---+----+---+----+---+---+
| Format preserving | X | X | X | X | X | X | | | Format preserving | X | X | X | X | X | X | |
+---------------------------+----+---+----+---+----+---+---+
| Prefix preserving | | | X | X | X | | | | Prefix preserving | | | X | X | X | | |
+---------------------------+----+---+----+---+----+---+---+
| Replacement | | | X | | | | | | Replacement | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Filtering | X | | | | | | | | Filtering | X | | | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Generalization | | | | | | | X | | Generalization | | | | | | | X |
+---------------------------+----+---+----+---+----+---+---+
| Enumeration | | X | | | | | | | Enumeration | | X | | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Reordering/Shuffling | | | X | | | | | | Reordering/Shuffling | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Random substitution | | | X | | | | | | Random substitution | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Cryptographic permutation | | | | X | X | X | | | Cryptographic permutation | | | | X | X | X | |
+---------------------------+----+---+----+---+----+---+---+
| IPv6 issues | | | | | X | | | | IPv6 issues | | | | | X | | |
+---------------------------+----+---+----+---+----+---+---+
| CPU intensive | | | | X | | | | | CPU intensive | | | | X | | | |
+---------------------------+----+---+----+---+----+---+---+
| Memory intensive | | | X | | | | | | Memory intensive | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Security concerns | | | | | | X | | | Security concerns | | | | | | X | |
+---------------------------+----+---+----+---+----+---+---+ +---------------------------+----+---+----+---+----+---+---+
Table 1: Classification of techniques Table 1: Classification of Techniques
Legend of techniques: GA = Google Analytics, d = dnswasher, TC = Legend of techniques:
TCPdpriv, C = CryptoPAn, TS = TSA, i = ipcipher, B = Bloom filter
GA = Google Analytics
d = dnswasher
TC = TCPdpriv
C = CryptoPAn
TS = TSA
i = ipcipher
B = Bloom filter
The choice of which method to use for a particular application will The choice of which method to use for a particular application will
depend on the requirements of that application and consideration of depend on the requirements of that application and consideration of
the threat analysis of the particular situation. the threat analysis of the particular situation.
For example, a common goal is that distributed packet captures must For example, a common goal is that distributed packet captures must
be in an existing data format such as PCAP [pcap] or C-DNS [RFC8618] be in an existing data format, such as PCAP [pcap] or Compacted-DNS
that can be used as input to existing analysis tools. In that case, (C-DNS) [RFC8618], that can be used as input to existing analysis
use of a format-preserving technique is essential. This, though, is tools. In that case, use of a format-preserving technique is
not cost-free - several authors (e.g., [Brenker-and-Arnes] have essential. This, though, is not cost free; several authors (e.g.,
observed that, as the entropy in an IPv4 address is limited, if an [Brekne-and-Arnes]) have observed that, as the entropy in an IPv4
attacker can address is limited, if an attacker can
o ensure packets are captured by the target and * ensure packets are captured by the target and
o send forged traffic with arbitrary source and destination * send forged traffic with arbitrary source and destination
addresses to that target and addresses to that target and
o obtain a de-identified log of said traffic from that target * obtain a de-identified log of said traffic from that target,
any format-preserving pseudonymization is vulnerable to an attack any format-preserving pseudonymization is vulnerable to an attack
along the lines of a cryptographic chosen plaintext attack. along the lines of a cryptographic chosen-plaintext attack.
B.1. Categorization of techniques B.1. Categorization of Techniques
Data minimization methods may be categorized by the processing used Data minimization methods may be categorized by the processing used
and the properties of their outputs. The following builds on the and the properties of their outputs. The following builds on the
categorization employed in [RFC6235]: categorization employed in [RFC6235]:
o Format-preserving. Normally when encrypting, the original data Format-preserving. Normally, when encrypting, the original data
length and patterns in the data should be hidden from an attacker. length and patterns in the data should be hidden from an attacker.
Some applications of de-identification, such as network capture Some applications of de-identification, such as network capture
de-identification, require that the de-identified data is of the de-identification, require that the de-identified data is of the
same form as the original data, to allow the data to be parsed in same form as the original data, to allow the data to be parsed in
the same way as the original. the same way as the original.
o Prefix preservation. Values such as IP addresses and MAC Prefix preservation. Values such as IP addresses and MAC addresses
addresses contain prefix information that can be valuable in contain prefix information that can be valuable in analysis --
analysis, e.g., manufacturer ID in MAC addresses, subnet in IP e.g., manufacturer ID in MAC addresses, or subnet in IP addresses.
addresses. Prefix preservation ensures that prefixes are de- Prefix preservation ensures that prefixes are de-identified
identified consistently; e.g., if two IP addresses are from the consistently; for example, if two IP addresses are from the same
same subnet, a prefix preserving de-identification will ensure subnet, a prefix preserving de-identification will ensure that
that their de-identified counterparts will also share a subnet. their de-identified counterparts will also share a subnet. Prefix
Prefix preservation may be fixed (i.e. based on a user selected preservation may be fixed (i.e., based on a user-selected prefix
prefix length identified in advance to be preserved ) or general. length identified in advance to be preserved ) or general.
o Replacement. A one-to-one replacement of a field to a new value Replacement. A one-to-one replacement of a field to a new value of
of the same type, for example, using a regular expression. the same type -- for example, using a regular expression.
o Filtering. Removing or replacing data in a field. Field data can Filtering. Removing or replacing data in a field. Field data can be
be overwritten, often with zeros, either partially (truncation or overwritten, often with zeros, either partially (truncation or
reverse truncation) or completely (black-marker anonymization). reverse truncation) or completely (black-marker anonymization).
o Generalization. Data is replaced by more general data with Generalization. Data is replaced by more general data with reduced
reduced specificity. One example would be to replace all TCP/UDP specificity. One example would be to replace all TCP/UDP port
port numbers with one of two fixed values indicating whether the numbers with one of two fixed values indicating whether the
original port was ephemeral (>=1024) or non-ephemeral (>1024). original port was ephemeral (>=1024) or nonephemeral (>1024).
Another example, precision degradation, reduces the accuracy of Another example, precision degradation, reduces the accuracy of,
e.g., a numeric value or a timestamp. for example, a numeric value or a timestamp.
o Enumeration. With data from a well-ordered set, replace the first Enumeration. With data from a well-ordered set, replace the first
data item data using a random initial value and then allocate data item's data using a random initial value and then allocate
ordered values for subsequent data items. When used with ordered values for subsequent data items. When used with
timestamp data, this preserves ordering but loses precision and timestamp data, this preserves ordering but loses precision and
distance. distance.
o Reordering/shuffling. Preserving the original data, but Reordering/shuffling. Preserving the original data, but rearranging
rearranging its order, often in a random manner. its order, often in a random manner.
o Random substitution. As replacement, but using randomly generated Random substitution. As replacement, but using randomly generated
replacement values. replacement values.
o Cryptographic permutation. Using a permutation function, such as Cryptographic permutation. Using a permutation function, such as a
a hash function or cryptographic block cipher, to generate a hash function or cryptographic block cipher, to generate a
replacement de-identified value. replacement de-identified value.
B.2. Specific techniques B.2. Specific Techniques
B.2.1. Google Analytics non-prefix filtering B.2.1. Google Analytics Non-Prefix Filtering
Since May 2010, Google Analytics has provided a facility Since May 2010, Google Analytics has provided a facility
[IP-Anonymization-in-Analytics] that allows website owners to request [IP-Anonymization-in-Analytics] that allows website owners to request
that all their users IP addresses are anonymized within Google that all their users' IP addresses are anonymized within Google
Analytics processing. This very basic anonymization simply sets to Analytics processing. This very basic anonymization simply sets to
zero the least significant 8 bits of IPv4 addresses, and the least zero the least significant 8 bits of IPv4 addresses, and the least
significant 80 bits of IPv6 addresses. The level of anonymization significant 80 bits of IPv6 addresses. The level of anonymization
this produces is perhaps questionable. There are some analysis this produces is perhaps questionable. There are some analysis
results [Geolocation-Impact-Assessement] which suggest that the results [Geolocation-Impact-Assessment] that suggest that the impact
impact of this on reducing the accuracy of determining the user's of this on reducing the accuracy of determining the user's location
location from their IP address is less than might be hoped; the from their IP address is less than might be hoped; the average
average discrepancy in identification of the user city for UK users discrepancy in identification of the user city for UK users is no
is no more than 17%. more than 17%.
Anonymization: Format-preserving, Filtering (trucation). Anonymization: Format-preserving, Filtering (truncation).
B.2.2. dnswasher B.2.2. dnswasher
Since 2006, PowerDNS have included a de-identification tool dnswasher Since 2006, PowerDNS has included a de-identification tool, dnswasher
[PowerDNS-dnswasher] with their PowerDNS product. This is a PCAP [PowerDNS-dnswasher], with their PowerDNS product. This is a PCAP
filter that performs a one-to-one mapping of end user IP addresses filter that performs a one-to-one mapping of end-user IP addresses
with an anonymized address. A table of user IP addresses and their with an anonymized address. A table of user IP addresses and their
de-identified counterparts is kept; the first IPv4 user addresses is de-identified counterparts is kept; the first IPv4 user addresses is
translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de- translated to 0.0.0.1, the second to 0.0.0.2, and so on. The de-
identified address therefore depends on the order that addresses identified address therefore depends on the order that addresses
arrive in the input, and running over a large amount of data the arrive in the input, and when running over a large amount of data,
address translation tables can grow to a significant size. the address translation tables can grow to a significant size.
Anonymization: Format-preserving, Enumeration. Anonymization: Format-preserving, Enumeration.
B.2.3. Prefix-preserving map B.2.3. Prefix-Preserving Map
Used in [TCPdpriv], this algorithm stores a set of original and Used in [tcpdpriv], this algorithm stores a set of original and
anonymised IP address pairs. When a new IP address arrives, it is anonymized IP address pairs. When a new IP address arrives, it is
compared with previous addresses to determine the longest prefix compared with previous addresses to determine the longest prefix
match. The new address is anonymized by using the same prefix, with match. The new address is anonymized by using the same prefix, with
the remainder of the address anonymized with a random value. The use the remainder of the address anonymized with a random value. The use
of a random value means that TCPdpriv is not deterministic; different of a random value means that TCPdpriv is not deterministic; different
anonymized values will be generated on each run. The need to store anonymized values will be generated on each run. The need to store
previous addresses means that TCPdpriv has significant and unbounded previous addresses means that TCPdpriv has significant and unbounded
memory requirements, and because of the need to allocated anonymized memory requirements. The need to allocate anonymized addresses
addresses sequentially cannot be used in parallel processing. sequentially means that TCPdpriv cannot be used in parallel
processing.
Anonymization: Format-preserving, prefix preservation (general). Anonymization: Format-preserving, prefix preservation (general).
B.2.4. Cryptographic Prefix-Preserving Pseudonymization B.2.4. Cryptographic Prefix-Preserving Pseudonymization
Cryptographic prefix-preserving pseudonymization was originally Cryptographic prefix-preserving pseudonymization was originally
proposed as an improvement to the prefix-preserving map implemented proposed as an improvement to the prefix-preserving map implemented
in TCPdpriv, described in [Xu-et-al.] and implemented in the in TCPdpriv, described in [Xu-et-al] and implemented in the
[Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym [Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym
for the algorithm. Initially it was described for IPv4 addresses for the algorithm. Initially, it was described for IPv4 addresses
only; extension for IPv6 addresses was proposed in [Harvan]. This only; extension for IPv6 addresses was proposed in [Harvan]. This
uses a cryptographic algorithm rather than a random value, and thus uses a cryptographic algorithm rather than a random value, and thus
pseudonymity is determined uniquely by the encryption key, and is pseudonymity is determined uniquely by the encryption key, and is
deterministic. It requires a separate AES encryption for each output deterministic. It requires a separate AES encryption for each output
bit, so has a non-trivial calculation overhead. This can be bit and so has a nontrivial calculation overhead. This can be
mitigated to some extent (for IPv4, at least) by pre-calculating mitigated to some extent (for IPv4, at least) by precalculating
results for some number of prefix bits. results for some number of prefix bits.
Pseudonymization: Format-preserving, prefix preservation (general). Pseudonymization: Format-preserving, prefix preservation (general).
B.2.5. Top-hash Subtree-replicated Anonymization B.2.5. Top-Hash Subtree-Replicated Anonymization
Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated
Anonymization (TSA) originated in response to the requirement for Anonymization (TSA) originated in response to the requirement for
faster processing than Crypto-PAn. It used hashing for the most faster processing than Crypto-PAn. It used hashing for the most
significant byte of an IPv4 address, and a pre-calculated binary tree significant byte of an IPv4 address and a precalculated binary-tree
structure for the remainder of the address. To save memory space, structure for the remainder of the address. To save memory space,
replication is used within the tree structure, reducing the size of replication is used within the tree structure, reducing the size of
the pre-calculated structures to a few Mb for IPv4 addresses. the precalculated structures to a few megabytes for IPv4 addresses.
Address pseudonymization is done via hash and table lookup, and so Address pseudonymization is done via hash and table lookup and so
requires minimal computation. However, due to the much increased requires minimal computation. However, due to the much-increased
address space for IPv6, TSA is not memory efficient for IPv6. address space for IPv6, TSA is not memory efficient for IPv6.
Pseudonymization: Format-preserving, prefix preservation (general). Pseudonymization: Format-preserving, prefix preservation (general).
B.2.6. ipcipher B.2.6. ipcipher
A recently-released proposal from PowerDNS, ipcipher [ipcipher1] A recently released proposal from PowerDNS, ipcipher [ipcipher1]
[ipcipher2] is a simple pseudonymization technique for IPv4 and IPv6 [ipcipher2], is a simple pseudonymization technique for IPv4 and IPv6
addresses. IPv6 addresses are encrypted directly with AES-128 using addresses. IPv6 addresses are encrypted directly with AES-128 using
a key (which may be derived from a passphrase). IPv4 addresses are a key (which may be derived from a passphrase). IPv4 addresses are
similarly encrypted, but using a recently proposed encryption similarly encrypted, but using a recently proposed encryption
[ipcrypt] suitable for 32bit block lengths. However, the author of [ipcrypt] suitable for 32-bit block lengths. However, the author of
ipcrypt has since indicated [ipcrypt-analysis] that it has low ipcrypt has since indicated [ipcrypt-analysis] that it has low
security, and further analysis has revealed it is vulnerable to security, and further analysis has revealed it is vulnerable to
attack. attack.
Pseudonymization: Format-preserving, cryptographic permutation. Pseudonymization: Format-preserving, cryptographic permutation.
B.2.7. Bloom filters B.2.7. Bloom Filters
van Rijswijk-Deij et al. have recently described work using Bloom van Rijswijk-Deij et al. have recently described work using Bloom
filters [Bloom-filter] to categorize query traffic and record the Filters [Bloom-filter] to categorize query traffic and record the
traffic as the state of multiple filters. The goal of this work is traffic as the state of multiple filters. The goal of this work is
to allow operators to identify so-called Indicators of Compromise to allow operators to identify so-called Indicators of Compromise
(IOCs) originating from specific subnets without storing information (IOCs) originating from specific subnets without storing information
about, or be able to monitor the DNS queries of an individual user. about, or being able to monitor, the DNS queries of an individual
By using a Bloom filter, it is possible to determine with a high user. By using a Bloom Filter, it is possible to determine with a
probability if, for example, a particular query was made, but the set high probability if, for example, a particular query was made, but
of queries made cannot be recovered from the filter. Similarly, by the set of queries made cannot be recovered from the filter.
mixing queries from a sufficient number of users in a single filter, Similarly, by mixing queries from a sufficient number of users in a
it becomes practically impossible to determine if a particular user single filter, it becomes practically impossible to determine if a
performed a particular query. Large numbers of queries can be particular user performed a particular query. Large numbers of
tracked in a memory-efficient way. As filter status is stored, this queries can be tracked in a memory-efficient way. As filter status
approach cannot be used to regenerate traffic, and so cannot be used is stored, this approach cannot be used to regenerate traffic and so
with tools used to process live traffic. cannot be used with tools used to process live traffic.
Anonymized: Generalization. Anonymized: Generalization.
Appendix C. Current policy and privacy statements Appendix C. Current Policy and Privacy Statements
A tabular comparison of policy and privacy statements from various A tabular comparison of policy and privacy statements from various
DNS Privacy service operators based loosely on the proposed RPS DNS privacy service operators based loosely on the proposed RPS
structure can be found at [policy-comparison]. The analysis is based structure can be found at [policy-comparison]. The analysis is based
on the data available in December 2019. on the data available in December 2019.
We note that the existing set of policies vary widely in style, We note that the existing policies vary widely in style, content, and
content and detail and it is not uncommon for the full text for a detail, and it is not uncommon for the full text for a given operator
given operator to equate to more than 10 pages of moderate font sized to equate to more than 10 pages (A4 size) of text in a moderate-sized
A4 text. It is a non-trivial task today for a user to extract a font. It is a nontrivial task today for a user to extract a
meaningful overview of the different services on offer. meaningful overview of the different services on offer.
It is also noted that Mozilla have published a DoH resolver policy It is also noted that Mozilla has published a DoH resolver policy
[DoH-resolver-policy], which describes the minimum set of policy [DoH-resolver-policy] that describes the minimum set of policy
requirements that a party must satisfy to be considered as a requirements that a party must satisfy to be considered as a
potential partner for Mozilla's Trusted Recursive Resolver (TRR) potential partner for Mozilla's Trusted Recursive Resolver (TRR)
program. program.
Appendix D. Example RPS Appendix D. Example RPS
The following example RPS is very loosely based on some elements of The following example RPS is very loosely based on some elements of
published privacy statements for some public resolvers, with published privacy statements for some public resolvers, with
additional fields populated to illustrate the what the full contents additional fields populated to illustrate what the full contents of
of an RPS might look like. This should not be interpreted as an RPS might look like. This should not be interpreted as
o having been reviewed or approved by any operator in any way * having been reviewed or approved by any operator in any way
o having any legal standing or validity at all * having any legal standing or validity at all
o being complete or exhaustive * being complete or exhaustive
This is a purely hypothetical example of an RPS to outline example This is a purely hypothetical example of an RPS to outline example
contents - in this case for a public resolver operator providing a contents -- in this case, for a public resolver operator providing a
basic DNS Privacy service via one IP address and one DoH URI with basic DNS Privacy service via one IP address and one DoH URI with
security based filtering. It does aim to meet minimal compliance as security-based filtering. It does aim to meet minimal compliance as
specified in Section 5. specified in Section 5.
D.1. Policy D.1. Policy
1. Treatment of IP addresses. Many nations classify IP addresses as 1. Treatment of IP addresses. Many nations classify IP addresses as
personal data, and we take a conservative approach in treating IP personal data, and we take a conservative approach in treating IP
addresses as personal data in all jurisdictions in which our addresses as personal data in all jurisdictions in which our
systems reside. systems reside.
2. Data collection and sharing. 2. Data collection and sharing.
1. IP addresses. Our normal course of data management does not a. IP addresses. Our normal course of data management does not
have any IP address information or other personal data logged have any IP address information or other personal data logged
to disk or transmitted out of the location in which the query to disk or transmitted out of the location in which the query
was received. We may aggregate certain counters to larger was received. We may aggregate certain counters to larger
network block levels for statistical collection purposes, but network block levels for statistical collection purposes, but
those counters do not maintain specific IP address data nor those counters do not maintain specific IP address data, nor
is the format or model of data stored capable of being is the format or model of data stored capable of being
reverse-engineered to ascertain what specific IP addresses reverse-engineered to ascertain what specific IP addresses
made what queries. made what queries.
2. Data collected in logs. We do keep some generalized location b. Data collected in logs. We do keep some generalized location
information (at the city/metropolitan area level) so that we information (at the city / metropolitan-area level) so that
can conduct debugging and analyze abuse phenomena. We also we can conduct debugging and analyze abuse phenomena. We
use the collected information for the creation and sharing of also use the collected information for the creation and
telemetry (timestamp, geolocation, number of hits, first sharing of telemetry (timestamp, geolocation, number of hits,
seen, last seen) for contributors, public publishing of first seen, last seen) for contributors, public publishing of
general statistics of system use (protections, threat types, general statistics of system use (protections, threat types,
counts, etc.) When you use our DNS Services, here is the counts, etc.). When you use our DNS services, here is the
full list of items that are included in our logs: full list of items that are included in our logs:
+ Request domain name, e.g., example.net * Requested domain name -- e.g., example.net
+ Record type of requested domain, e.g., A, AAAA, NS, MX, * Record type of requested domain -- e.g., A, AAAA, NS, MX,
TXT, etc. TXT, etc.
+ Transport protocol on which the request arrived, i.e. UDP, * Transport protocol on which the request arrived -- i.e.,
TCP, DoT, UDP, TCP, DoT, DoH
DoH
+ Origin IP general geolocation information: i.e. geocode, * Origin IP general geolocation information -- i.e.,
region ID, city ID, and metro code geocode, region ID, city ID, and metro code
+ IP protocol version - IPv4 or IPv6 * IP protocol version -- IPv4 or IPv6
+ Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN, * Response code sent -- e.g., SUCCESS, SERVFAIL, NXDOMAIN,
etc. etc.
+ Absolute arrival time using a precision in ms * Absolute arrival time using a precision in ms
+ Name of the specific instance that processed this request * Name of the specific instance that processed this request
+ IP address of the specific instance to which this request * IP address of the specific instance to which this request
was addressed (no relation to the requestor's IP address) was addressed (no relation to the requestor's IP address)
We may keep the following data as summary information, We may keep the following data as summary information,
including all the above EXCEPT for data about the DNS record including all the above EXCEPT for data about the DNS record
requested: requested:
+ Currently-advertised BGP-summarized IP prefix/netmask of * Currently advertised BGP-summarized IP prefix/netmask of
apparent client origin apparent client origin
+ Autonomous system number (BGP ASN) of apparent client * Autonomous system number (BGP ASN) of apparent client
origin origin
All the above data may be kept in full or partial form in All the above data may be kept in full or partial form in
permanent archives. permanent archives.
3. Sharing of data. Except as described in this document, we do c. Sharing of data. Except as described in this document, we do
not intentionally share, sell, or rent individual personal not intentionally share, sell, or rent individual personal
information associated with the requestor (i.e. source IP information associated with the requestor (i.e., source IP
address or any other information that can positively identify address or any other information that can positively identify
the client using our infrastructure) with anyone without your the client using our infrastructure) with anyone without your
consent. We generate and share high level anonymized consent. We generate and share high-level anonymized
aggregate statistics including threat metrics on threat type, aggregate statistics, including threat metrics on threat
geolocation, and if available, sector, as well as other type, geolocation, and if available, sector, as well as other
vertical metrics including performance metrics on our DNS vertical metrics, including performance metrics on our DNS
Services (i.e. number of threats blocked, infrastructure Services (i.e., number of threats blocked, infrastructure
uptime) when available with our threat intelligence (TI) uptime) when available with our Threat Intelligence (TI)
partners, academic researchers, or the public. Our DNS partners, academic researchers, or the public. Our DNS
Services share anonymized data on specific domains queried services share anonymized data on specific domains queried
(records such as domain, timestamp, geolocation, number of (records such as domain, timestamp, geolocation, number of
hits, first seen, last seen) with our threat intelligence hits, first seen, last seen) with our Threat Intelligence
partners. Our DNS Services also builds, stores, and may partners. Our DNS service also builds, stores, and may share
share certain DNS data streams which store high level certain DNS data streams which store high level information
information about domain resolved, query types, result codes, about domain resolved, query types, result codes, and
and timestamp. These streams do not contain IP address timestamp. These streams do not contain the IP address
information of requestor and cannot be correlated to IP information of the requestor and cannot be correlated to IP
address or other personal data. We do not and never will address or other personal data. We do not and never will
share any of its data with marketers, nor will it use this share any of the requestor's data with marketers, nor will we
data for demographic analysis. use this data for demographic analysis.
3. Exceptions. There are exceptions to this storage model: In the 3. Exceptions. There are exceptions to this storage model: In the
event of actions or observed behaviors which we deem malicious or event of actions or observed behaviors that we deem malicious or
anomalous, we may utilize more detailed logging to collect more anomalous, we may utilize more detailed logging to collect more
specific IP address data in the process of normal network defence specific IP address data in the process of normal network defense
and mitigation. This collection and transmission off-site will and mitigation. This collection and transmission off-site will
be limited to IP addresses that we determine are involved in the be limited to IP addresses that we determine are involved in the
event. event.
4. Associated entities. Details of our Threat Intelligence partners 4. Associated entities. Details of our Threat Intelligence partners
can be found at our website page (insert link). can be found at our website page (insert link).
5. Correlation of Data. We do not correlate or combine information 5. Correlation of Data. We do not correlate or combine information
from our logs with any personal information that you have from our logs with any personal information that you have
provided us for other services, or with your specific IP address. provided us for other services, or with your specific IP address.
6. Result filtering. 6. Result filtering.
1. Filtering. We utilise cyber threat intelligence about a. Filtering. We utilize cyber-threat intelligence about
malicious domains from a variety of public and private malicious domains from a variety of public and private
sources and blocks access to those malicious domains when sources and block access to those malicious domains when your
your system attempts to contact them. An NXDOMAIN is system attempts to contact them. An NXDOMAIN is returned for
returned for blocked sites. blocked sites.
1. Censorship. We will not provide a censoring component i. Censorship. We will not provide a censoring component
and will limit our actions solely to the blocking of and will limit our actions solely to the blocking of
malicious domains around phishing, malware, and exploit malicious domains around phishing, malware, and exploit-
kit domains. kit domains.
2. Accidental blocking. We implement allowlisting ii. Accidental blocking. We implement allowlisting
algorithms to make sure legitimate domains are not algorithms to make sure legitimate domains are not
blocked by accident. However, in the rare case of blocked by accident. However, in the rare case of
blocking a legitimate domain, we work with the users to blocking a legitimate domain, we work with the users to
quickly allowlist that domain. Please use our support quickly allowlist that domain. Please use our support
form (insert link) if you believe we are blocking a form (insert link) if you believe we are blocking a
domain in error. domain in error.
D.2. Practice D.2. Practice
1. Deviations from Policy. None in place since (insert date). 1. Deviations from Policy. None in place since (insert date).
2. Client facing capabilities. 2. Client-facing capabilities.
1. We offer UDP and TCP DNS on port 53 on (insert IP address) a. We offer UDP and TCP DNS on port 53 on (insert IP address)
2. We offer DNS over TLS as specified in RFC7858 on (insert IP b. We offer DNS over TLS as specified in RFC 7858 on (insert IP
address). It is available on port 853 and port 443. We also address). It is available on port 853 and port 443. We also
implement RFC7766. implement RFC 7766.
1. The DoT authentication domain name used is (insert domain i. The DoT authentication domain name used is (insert
name). domain name).
2. We do not publish SPKI pin sets. ii. We do not publish SPKI pin sets.
3. We offer DNS over HTTPS as specified in RFC8484 on (insert c. We offer DNS over HTTPS as specified in RFC 8484 on (insert
URI template). URI template).
4. Both services offer TLS 1.2 and TLS 1.3. d. Both services offer TLS 1.2 and TLS 1.3.
5. Both services pad DNS responses according to RFC8467. e. Both services pad DNS responses according to RFC 8467.
6. Both services provide DNSSEC validation. f. Both services provide DNSSEC validation.
3. Upstream capabilities. 3. Upstream capabilities.
1. Our servers implement QNAME minimization. a. Our servers implement QNAME minimization.
2. Our servers do not send ECS upstream. b. Our servers do not send ECS upstream.
4. Support. Support information for this service is available at 4. Support. Support information for this service is available at
(insert link). (insert link).
5. Data Processing. We operate as the legal entity (insert entity) 5. Data Processing. We operate as the legal entity (insert entity)
registered in (insert country); as such we operate under (insert registered in (insert country); as such, we operate under (insert
country/region) law. Our separate statement regarding the country/region) law. Our separate statement regarding the
specifics of our data processing policy, practice, and agreements specifics of our data processing policy, practice, and agreements
can be found here (insert link). can be found here (insert link).
Acknowledgements
Many thanks to Amelia Andersdotter for a very thorough review of the
first draft of this document and Stephen Farrell for a thorough
review at Working Group Last Call and for suggesting the inclusion of
an example RPS. Thanks to John Todd for discussions on this topic,
and to Stéphane Bortzmeyer, Puneet Sood, and Vittorio Bertola for
review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman,
Dan York, Jon Reed, and Lorenzo Colitti for comments at the mic.
Thanks to Loganaden Velvindron for useful updates to the text.
Sara Dickinson thanks the Open Technology Fund for a grant to support
the work on this document.
Contributors
The below individuals contributed significantly to the document:
John Dickinson
Sinodun IT
Magdalen Centre
Oxford Science Park
Oxford
OX4 4GA
United Kingdom
Jim Hague
Sinodun IT
Magdalen Centre
Oxford Science Park
Oxford
OX4 4GA
United Kingdom
Authors' Addresses Authors' Addresses
Sara Dickinson Sara Dickinson
Sinodun IT Sinodun IT
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford
OX4 4GA
United Kingdom United Kingdom
Email: sara@sinodun.com Email: sara@sinodun.com
Benno J. Overeinder Benno J. Overeinder
NLnet Labs NLnet Labs
Science Park 400 Science Park 400
Amsterdam 1098 XH 1098 XH Amsterdam
The Netherlands Netherlands
Email: benno@nlnetLabs.nl Email: benno@nlnetLabs.nl
Roland M. van Rijswijk-Deij Roland M. van Rijswijk-Deij
NLnet Labs NLnet Labs
Science Park 400 Science Park 400
Amsterdam 1098 XH 1098 XH Amsterdam
The Netherlands Netherlands
Email: roland@nlnetLabs.nl Email: roland@nlnetLabs.nl
Allison Mankin Allison Mankin
Salesforce Salesforce.com, Inc.
Salesforce Tower
415 Mission Street, 3rd Floor
San Francisco, CA 94105
United States of America
Email: allison.mankin@gmail.com Email: allison.mankin@gmail.com
 End of changes. 405 change blocks. 
1047 lines changed or deleted 924 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/