< draft-ietf-dprive-bcp-op-09.txt   draft-ietf-dprive-bcp-op-10.txt >
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun IT Internet-Draft Sinodun IT
Intended status: Best Current Practice B. Overeinder Intended status: Best Current Practice B. Overeinder
Expires: November 5, 2020 R. van Rijswijk-Deij Expires: December 20, 2020 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
May 4, 2020 June 18, 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-09 draft-ietf-dprive-bcp-op-10
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,
and how the decisions and alternatives impact the privacy of users. and how the decisions and alternatives impact the privacy of users.
This document also presents a framework to assist writers of a DNS This document also presents a non-normative framework to assist
Recursive Operator Privacy Statement (analogous to DNS Security writers of a DNS Recursive Operator Privacy Statement (analogous to
Extensions (DNSSEC) Policies and DNSSEC Practice Statements described DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice
in RFC6841). Statements described in RFC6841).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2020. This Internet-Draft will expire on December 20, 2020.
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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Privacy related documents . . . . . . . . . . . . . . . . . . 5 3. Privacy-related documents . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Recommendations for DNS privacy services . . . . . . . . . . 6 5. Recommendations for DNS privacy services . . . . . . . . . . 6
5.1. On the wire between client and server . . . . . . . . . . 7 5.1. On the wire between client and server . . . . . . . . . . 7
5.1.1. Transport recommendations . . . . . . . . . . . . . . 7 5.1.1. Transport recommendations . . . . . . . . . . . . . . 7
5.1.2. Authentication of DNS privacy services . . . . . . . 8 5.1.2. Authentication of DNS privacy services . . . . . . . 8
5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11 5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 12
5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12 5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
5.1.7. Impact of Encryption on DNS Monitoring . . . . . . . 12 5.1.7. Impact of Encryption on Monitoring by DNS Privacy
Service Operators . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 13
5.2. Data at rest on the server . . . . . . . . . . . . . . . 13 5.2. Data at rest on the server . . . . . . . . . . . . . . . 14
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Data minimization of network traffic . . . . . . . . 15 5.2.2. Data minimization of network traffic . . . . . . . . 15
5.2.3. IP address pseudonymization and anonymization methods 16 5.2.3. IP address pseudonymization and anonymization methods 16
5.2.4. Pseudonymization, anonymization, or discarding of 5.2.4. Pseudonymization, anonymization, or discarding of
other correlation data . . . . . . . . . . . . . . . 17 other correlation data . . . . . . . . . . . . . . . 16
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
5.3. Data sent onwards from the server . . . . . . . . . . . . 18 5.3. Data sent onwards from the server . . . . . . . . . . . . 17
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 20 6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19
6.1. Recommended contents of a DROP statement . . . . . . . . 20 6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20
6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Current policy and privacy statements . . . . . . . . . . 22 6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22
6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 23 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33
A.1. Potential increases in DNS privacy . . . . . . . . . . . 33 A.1. Potential increases in DNS privacy . . . . . . . . . . . 33
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34
A.3. Related operational documents . . . . . . . . . . . . . . 34 A.3. Related operational documents . . . . . . . . . . . . . . 34
Appendix B. IP address techniques . . . . . . . . . . . . . . . 34 Appendix B. IP address techniques . . . . . . . . . . . . . . . 35
B.1. Google Analytics non-prefix filtering . . . . . . . . . . 35 B.1. Categorization of techniques . . . . . . . . . . . . . . 36
B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 36 B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37
B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 36 B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37
B.4. Cryptographic Prefix-Preserving Pseudonymization . . . . 36 B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37
B.5. Top-hash Subtree-replicated Anonymization . . . . . . . . 37 B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 37
B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 37 B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38
B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 37 B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38
Appendix C. Example DROP statement . . . . . . . . . . . . . . . 38 B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 38
C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39
C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix C. Current policy and privacy statements . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40
D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40
D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43
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 which aim to increase the privacy of the DNS
system and these are now seeing some deployment. This latest system and these are now seeing some deployment. This latest
evolution of the DNS presents new challenges to operators and this evolution of the DNS presents new challenges to operators and this
document attempts to provide an overview of considerations for document attempts to provide an overview of considerations for
privacy focused DNS services. privacy focused 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 instead
of the default network resolver because they offer a specific feature of the default network resolver either because they offer a specific
(e.g. good reachability, encrypted transport, strong privacy policy, feature (e.g., good reachability or encrypted transport) or because
filtering (or lack of), etc.). These open resolvers have tended to the network resolver lacks a specific feature (e.g., strong privacy
be at the forefront of adoption of privacy related enhancements but policy or unfiltered responses). These open resolvers have tended to
be at the forefront of adoption of privacy-related enhancements but
it is anticipated that operators of other resolver services will it is anticipated that operators of other resolver services will
follow. 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 exists. identifiers for each user. Therefore, a trust relationship exists.
The ability of the operator to provide a transparent, well The ability of the operator to provide a transparent, well
documented, and secure privacy service will likely serve as a major documented, and secure privacy service will likely serve as a major
differentiating factor for privacy conscious users if they make an differentiating factor for privacy conscious users if they make an
active selection of which resolver to use. active selection of which resolver to use.
It should also be noted that the choice of a user to configure a It should also be noted that the choice of a user to configure a
single resolver (or a fixed set of resolvers) and an encrypted single resolver (or a fixed set of resolvers) and an encrypted
transport to use in all network environments has both advantages and transport to use in all network environments has both advantages and
disadvantages. For example the user has a clear expectation of which disadvantages. For example, the user has a clear expectation of
resolvers have visibility of their query data however this resolver/ which resolvers have visibility of their query data. However, this
transport selection may provide an added mechanism to track them as resolver/transport selection may provide an added mechanism to track
they move across network environments. Commitments from operators to them as they move across network environments. Commitments from
minimize such tracking are also likely to play a role in user resolver operators to minimize such tracking as users move between
selection of resolvers. networks are also likely to play a role in user selection of
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. It is an untested area that simply using a DNS significant activity. Providing detailed practice advice about these
resolution service constitutes consent from the user for the operator areas to the operator is out of scope, but Section 5.3.3 describes
to process their query data. The impact of recent legislative some mitigations of data sharing risk.
changes on data pertaining to the users of both Internet Service
Providers and public DNS resolvers is not fully understood at the
time of writing.
This document has two main goals: This document has two main goals:
o To provide operational and policy guidance related to DNS over o 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 DNS Recursive Operator Privacy (DROP) statement o To introduce the DNS Recursive Operator Privacy (DROP) statement
and present a framework to assist writers of this document. A and present a framework to assist writers of a DROP statement. A
DROP statement is a document that an operator can publish DROP statement is a document that an operator should publish which
outlining their operational practices and commitments with regard outlines their operational practices and commitments with regard
to privacy thereby providing a means for clients to evaluate the to privacy, thereby providing a means for clients to evaluate the
privacy properties of a given DNS privacy service. In particular, measurable and claimed privacy properties of a given DNS privacy
the framework identifies the elements that should be considered in service. The framework identifies a set of elements and specifies
formulating a DROP statement. 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 or recommendations as to the contents. legal advice as to the contents.
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 difference 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 errata or updates statement. Readers are advised to seek out any updates that apply to
that apply to this document. this document.
2. Scope 2. Scope
"DNS Privacy Considerations" [I-D.ietf-dprive-rfc7626-bis] describes "DNS Privacy Considerations" [RFC7626] describes the general privacy
the general privacy issues and threats associated with the use of the issues and threats associated with the use of the DNS by Internet
DNS by Internet users and much of the threat analysis here is lifted users and much of the threat analysis here is lifted from that
from that document and from [RFC6973]. However this document is document and from [RFC6973]. However this document is limited in
limited in scope to best practice considerations for the provision of scope to best practice considerations for the provision of DNS
DNS privacy services by servers (recursive resolvers) to clients privacy services by servers (recursive resolvers) to clients (stub
(stub resolvers or forwarders). Privacy considerations specifically resolvers or forwarders). Choices that are made exclusively by the
from the perspective of an end user, or those for operators of end user, or those for operators of authoritative nameservers are out
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 (taken from [I-D.ietf-dprive-rfc7626-bis]): 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 like to align with privacy best unencrypted transports but who would otherwise like to align with
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 of the DNS. the potential to either increase or decrease the privacy properties
Note this does not imply that some documents are good or bad, better of the DNS. Note this does not imply that some documents are good or
or worse, just that (for example) some features may bring functional bad, better or worse, just that (for example) some features may bring
benefits at the price of a reduction in privacy and conversely some functional benefits at the price of a reduction in privacy and
features increase privacy with an accompanying increase in conversely some features increase privacy with an accompanying
complexity. A selection of the most relevant documents are listed in increase in complexity. A selection of the most relevant documents
Appendix A for reference. are 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] with one modification:
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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. o Threat mitigations to be minimally compliant.
o Optimizations to be moderately compliant. o Optimizations to be moderately compliant.
o Additional options to be maximally compliant. o Additional options to be maximally compliant.
In other words, these requirements are specified here as all being
normative requirements, and are classified only by different levels
of compliance in the rest of the document.
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: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Passive surveillance of traffic on the wire * Passive surveillance of traffic on the wire
[I-D.ietf-dprive-rfc7626-bis] Section 5.1
DNS Privacy Threats: DNS Privacy Threats:
o 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 A DNS privacy service can mitigate these threats by providing service
over one or more of the following transports over one or more of the following transports
o DNS-over-TLS [RFC7858] and [RFC8310]. o DNS over TLS (DoT) [RFC7858] and [RFC8310].
o DoH [RFC8484]. o 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, use of these transports for DNS IPSec, DNSCrypt, or VPNs. However, use of these transports for DNS
are not standardized and any discussion of best practice for are not standardized in DNS specific RFCs and any discussion of best
providing such a service is out of scope for this document. practice for providing such a service is out of scope for this
document.
Whilst encryption of DNS traffic can protect against active injection Whilst encryption of DNS traffic can protect against active injection
this does not diminish the need for DNSSEC, see Section 5.1.4. this does not diminish the need for DNSSEC, see Section 5.1.4.
5.1.2. Authentication of DNS privacy services 5.1.2. Authentication of DNS privacy services
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Active attacks on resolver configuration * Active attacks on client resolver configuration
[I-D.ietf-dprive-rfc7626-bis] Section 6.1.2
Mitigations: Mitigations:
DNS privacy services should ensure clients can authenticate the DNS privacy services should ensure clients can authenticate the
server. Note that this, in effect, commits the DNS privacy service server. Note that this, in effect, commits the DNS privacy service
to a public identity users will trust. to a public identity users will trust.
When using DNS-over-TLS clients that select a 'Strict Privacy' usage When using DoT clients that select a 'Strict Privacy' usage profile
profile [RFC8310] (to mitigate the threat of active attack on the [RFC8310] (to mitigate the threat of active attack on the client)
client) require the ability to authenticate the DNS server. To require the ability to authenticate the DNS server. To enable this,
enable this, DNS privacy services that offer DNS-over-TLS should DNS privacy services that offer DNS-over-TLS need to provide
provide credentials in the form of either X.509 certificates credentials in the form of either X.509 certificates [RFC5280] or
[RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310]. Subject Public Key Info (SPKI) pin sets [RFC8310].
When offering DoH [RFC8484], HTTPS requires authentication of the When offering DoH [RFC8484], HTTPS requires authentication of the
server as part of the protocol. server as part of the protocol.
Server operators should also follow the best practices with regard to Server operators should also follow the best practices with regard to
Online Certificate Status Protocol (OCSP) [RFC2560] as described in certificate revocation as described in [RFC7525].
[RFC7525].
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:
o Invalid certificates, resulting in an unavailable service. o Invalid certificates, resulting in an unavailable service which
might force a user to fallback to cleartext.
o Mis-identification of a server by a client e.g. typos in URLs or o Mis-identification of a server by a client e.g., typos in DoH URL
authentication domain names [RFC8310]. 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:
o Follow the guidance in Section 6.5 of [RFC7525] with regards to o Follow the guidance in Section 6.5 of [RFC7525] with regards to
certificate revocation. certificate revocation.
o Automate the generation, publication, and renewal of certificates. o Automate the generation, publication, and renewal of certificates.
For example, ACME [RFC8555] provides a mechanism to actively For example, ACME [RFC8555] provides a mechanism to actively
skipping to change at page 9, line 37 skipping to change at page 9, line 41
a number of certificate authorities. a number of certificate authorities.
o Monitor certificates to prevent accidental expiration of o Monitor certificates to prevent accidental expiration of
certificates. certificates.
o Choose a short, memorable authentication domain name for the o 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. DNS-over-TLS 5.1.3.1. DoT
DNS Privacy Threats: DNS Privacy Threats:
o Known attacks on TLS such as those described in [RFC7457]. o Known attacks on TLS such as those described in [RFC7457].
o Traffic analysis, for example: [Pitfalls-of-DNS-Encryption]. o Traffic analysis, for example: [Pitfalls-of-DNS-Encryption].
o Potential for client tracking via transport identifiers. o Potential for client tracking via transport identifiers.
o Blocking of well known ports (e.g. 853 for DNS-over-TLS). o Blocking of well known ports (e.g., 853 for DoT).
Mitigations: Mitigations:
In the case of DNS-over-TLS, TLS profiles from Section 9 and the In the case of DoT, TLS profiles from Section 9 of [RFC8310] and the
Countermeasures to DNS Traffic Analysis from section 11.1 of Countermeasures to DNS Traffic Analysis from section 11.1 of
[RFC8310] provide strong mitigations. This includes but is not [RFC8310] provide strong mitigations. This includes but is not
limited to: limited to:
o Adhering to [RFC7525]. o Adhering to [RFC7525].
o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]. o Implementing only (D)TLS 1.2 or later as specified in [RFC8310].
o Implementing EDNS(0) Padding [RFC7830] using the guidelines in o Implementing EDNS(0) Padding [RFC7830] using the guidelines in
[RFC8467] or a successor specification. [RFC8467] or a successor specification.
o Servers should not degrade in any way the query service level o 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 resumption
mechanism, such as TLS session resumption [RFC5077] with TLS 1.2, mechanism, such as TLS session resumption [RFC5077] with TLS 1.2,
section 2.2 of [RFC8446], or Domain Name System (DNS) Cookies section 2.2 of [RFC8446], or Domain Name System (DNS) Cookies
[RFC7873]. [RFC7873].
o A DNS-over-TLS privacy service on both port 853 and 443. This o A DoT privacy service on both port 853 and 443. If the operator
practice may not be possible if e.g. the operator deploys DoH on deploys DoH on the same IP address this requires the use of the
the same IP address. 'dot' ALPN value [dot-ALPN].
Optimizations: Optimizations:
o Concurrent processing of pipelined queries, returning responses as o Concurrent processing of pipelined queries, returning responses as
soon as available, potentially out of order as specified in soon as available, potentially out of order as specified in
[RFC7766]. This is often called 'OOOR' - out-of-order responses [RFC7766]. This is often called 'OOOR' - out-of-order responses
(providing processing performance similar to HTTP multiplexing). (providing processing performance similar to HTTP multiplexing).
o Management of TLS connections to optimize performance for clients o Management of TLS connections to optimize performance for clients
using either: using [RFC7766] and EDNS(0) Keepalive [RFC7828]
* [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or Additional Options:
* DNS Stateful Operations [RFC8490]. Management of TLS connections to optimize performance for clients
using DNS Stateful Operations [RFC8490].
5.1.3.2. DoH 5.1.3.2. DoH
DNS Privacy Threats: DNS Privacy Threats:
o Known attacks on TLS such as those described in [RFC7457]. o Known attacks on TLS such as those described in [RFC7457].
o Use of HTTP/2 padding and/or EDNS(0) padding as described in
Section 9 of [RFC8484]
o Traffic analysis, for example: [DNS-Privacy-not-so-private]. o Traffic analysis, for example: [DNS-Privacy-not-so-private].
o Potential for client tracking via transport identifiers. o Potential for client tracking via transport identifiers.
Mitigations: Mitigations:
o Clients must be able to forego the use of HTTP Cookies [RFC6265] o Clients must be able to forgo the use of HTTP Cookies [RFC6265]
and still use the service. and still use the service.
o Clients should not be required to include any headers beyond the o Clients should not be required to include any headers beyond the
absolute minimum to obtain service from a DoH server. (See absolute minimum to obtain service from a DoH server. (See
Section 6.1 of [I-D.ietf-httpbis-bcp56bis].) Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)
5.1.4. DNSSEC 5.1.4. DNSSEC
DNS Privacy Threats: DNS Privacy Threats:
o Users may be directed to bogus IP addresses for e.g. websites o Users may be directed to bogus IP addresses which, depending on
where they might reveal personal information to attackers. the application, protocol and authentication method, might lead
users to reveal personal information to attackers. One example is
a website that doesn't use TLS or its TLS authentication can
somehow be subverted.
Mitigations: Mitigations:
o 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. 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
skipping to change at page 12, line 31 skipping to change at page 12, line 41
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, fallback to cleartext or accept no DNS service for the
outage. 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 un-encrypted 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 DNS Monitoring 5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service
Operators
DNS Privacy Threats: DNS Privacy Threats:
o Increased use of encryption impacts operator ability to manage o Increased use of encryption can impact DNS privacy service
their network [RFC8404]. operator ability to monitor traffic and therefore manage their DNS
servers [RFC8404].
Many monitoring solutions for DNS traffic rely on the plain text 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. There are, when traffic between clients and resolvers is encrypted. Many DNS
however, legitimate reasons for DNS privacy service operators to privacy service operators still have need to inspect DNS traffic,
inspect DNS traffic, e.g. to monitor for network security threats. e.g., to monitor for network security threats. Operators may
Operators may therefore need to invest in alternative means of therefore need to invest in alternative means of monitoring that
monitoring that relies on either the resolver software directly, or relies on either the resolver software directly, or exporting DNS
exporting DNS traffic from the resolver using e.g. [dnstap]. traffic from the resolver using e.g., [dnstap].
Optimization: Optimization:
When implementing alternative means for traffic monitoring, operators When implementing alternative means for traffic monitoring, operators
of a DNS privacy service should consider using privacy conscious of a DNS privacy service should consider using privacy conscious
means to do so (see section Section 5.2 for more details on data 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 handling and also the discussion on the use of Bloom Filters in
Appendix B. Appendix B.
5.1.8. Limitations of fronting a DNS privacy service with a pure TLS 5.1.8. Limitations of fronting a DNS privacy service with a pure TLS
proxy proxy
DNS Privacy Threats: DNS Privacy Threats:
o Limited ability to manage or monitor incoming connections using o Limited ability to manage or monitor incoming connections using
DNS specific techniques. DNS specific techniques.
o Misconfiguration of the target server could lead to data leakage o Misconfiguration (e.g., of the target server address in the proxy
if the proxy to target server path is not encrypted. configuration) could lead to data leakage if the proxy to target
server path is not encrypted.
Optimization: Optimization:
Some operators may choose to implement DNS-over-TLS using a TLS proxy Some operators may choose to implement DoT using a TLS proxy (e.g.
(e.g. [nginx], [haproxy], or [stunnel]) in front of a DNS nameserver [nginx], [haproxy], or [stunnel]) in front of a DNS nameserver
because of proven robustness and capacity when handling large numbers because of proven robustness and capacity when handling large numbers
of client connections, load balancing capabilities and good tooling. of client connections, load balancing capabilities and good tooling.
Currently, however, because such proxies typically have no specific Currently, however, because such proxies typically have no specific
handling of DNS as a protocol over TLS or DTLS using them can handling of DNS as a protocol over TLS or DTLS using them can
restrict traffic management at the proxy layer and at the DNS server. restrict traffic management at the proxy layer and at the DNS server.
For example, all traffic received by a nameserver behind such a proxy For example, all traffic received by a nameserver behind such a proxy
will appear to originate from the proxy and DNS techniques such as 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 ACLs, RRL, or DNS64 will be hard or impossible to implement in the
nameserver. nameserver.
skipping to change at page 14, line 19 skipping to change at page 14, line 31
o Secondary use. o Secondary use.
o Disclosure. o Disclosure.
Other Threats Other Threats
o Contravention of legal requirements not to process user data. o Contravention of legal requirements not to process user data.
Mitigations: Mitigations:
The following are common activities for DNS service operators and in The following are recommendations relating to common activities for
all cases should be minimized or completely avoided if possible for DNS service operators and in all cases such activities should be
DNS privacy services. If data is retained it should be encrypted and minimized or completely avoided if possible for DNS privacy services.
either aggregated, pseudonymized, or anonymized whenever possible. If data is retained it should be encrypted and either aggregated,
In general the principle of data minimization described in [RFC6973] pseudonymized, or anonymized whenever possible. In general the
should be applied. principle of data minimization described in [RFC6973] should be
applied.
o Transient data (e.g. that is used for real time monitoring and o Transient data (e.g., that is used for real time monitoring and
threat analysis which might be held only in memory) should be threat analysis which might be held only in memory) should be
retained for the shortest possible period deemed operationally retained for the shortest possible period deemed operationally
feasible. feasible.
o The retention period of DNS traffic logs should be only those o The retention period of DNS traffic logs should be only those
required to sustain operation of the service and, to the extent required to sustain operation of the service and, to the extent
that such exists, meet regulatory requirements. that such exists, meet regulatory requirements.
o DNS privacy services should not track users except for the o 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 o 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 be
limited to anonymized or pseudonymized data were operationally limited to anonymized or pseudonymized data where operationally
feasible, with access to full logs (if any are held) only feasible, with access to full logs (if any are held) only
permitted when necessary. permitted when necessary.
Optimizations: Optimizations:
o Consider use of full disk encryption for logs and data capture o Consider use of full disk encryption for logs and data capture
storage. storage.
5.2.2. Data minimization of network traffic 5.2.2. Data minimization of network traffic
skipping to change at page 16, line 7 skipping to change at page 16, line 19
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, how to
categorize a deterministic algorithm for data minimization of IP categorize a deterministic algorithm for data minimization of IP
addresses that produces a group of pseudonyms for a single given addresses that produces a group of pseudonyms for a single given
address. address.
5.2.3. IP address pseudonymization and anonymization methods 5.2.3. IP address pseudonymization and anonymization methods
As [I-D.ietf-dprive-rfc7626-bis] makes clear, the big privacy risk in A major privacy risk in DNS is connecting DNS queries to an
DNS is connecting DNS queries to an individual and the major vector individual and the major vector for this in DNS traffic is the client
for this in DNS traffic is the client IP address. 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.
The following table presents a high level comparison of various Appendix B provides a more detailed survey of various techniques
techniques employed or under development in 2019 and classifies them employed or under development in 2019.
according to categorization of technique and other properties.
Appendix B provides a more detailed survey of these techniques and
definitions for the categories and properties listed below. The list
of techniques includes the main techniques in current use, but does
not claim to be comprehensive.
+---------------------------+----+---+----+---+----+---+---+
| Categorization/Property | GA | d | TC | C | TS | i | B |
+---------------------------+----+---+----+---+----+---+---+
| Anonymization | X | X | X | | | | X |
| Pseudoanonymization | | | | X | X | X | |
| Format preserving | X | X | X | X | X | X | |
| Prefix preserving | | | X | X | X | | |
| Replacement | | | X | | | | |
| Filtering | X | | | | | | |
| Generalization | | | | | | | X |
| Enumeration | | X | | | | | |
| Reordering/Shuffling | | | X | | | | |
| Random substitution | | | X | | | | |
| Cryptographic permutation | | | | X | X | X | |
| IPv6 issues | | | | | X | | |
| CPU intensive | | | | X | | | |
| Memory intensive | | | X | | | | |
| Security concerns | | | | | | X | |
+---------------------------+----+---+----+---+----+---+---+
Table 1: Classification of techniques
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
depend on the requirements of that application and consideration of
the threat analysis of the particular situation.
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]
that can be used as input to existing analysis tools. In that case,
use of a format-preserving technique is essential. This, though, is
not cost-free - several authors (e.g. [Brenker-and-Arnes] have
observed that, as the entropy in an IPv4 address is limited, given a
de-identified log from a target, if an attacker is capable of
ensuring packets are captured by the target and the attacker can send
forged traffic with arbitrary source and destination addresses to
that target, any format-preserving pseudonymization is vulnerable to
an attack along the lines of a cryptographic chosen plaintext attack.
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:
o Fingerprinting of the client OS via various means including: IP o Fingerprinting of the client OS via various means including: IP
TTL/Hoplimit, TCP parameters (e.g. window size, ECN support, TTL/Hoplimit, TCP parameters (e.g., window size, ECN support,
SACK), OS specific DNS query patterns (e.g. for network SACK), OS specific DNS query patterns (e.g., for network
connectivity, captive portal detection, or OS specific updates). connectivity, captive portal detection, or OS specific updates).
o Fingerprinting of the client application or TLS library by e.g. o Fingerprinting of the client application or TLS library by e.g.,
TLS version/Cipher suite combinations or other connection HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS
parameters. version/Cipher suite combinations, or other connection parameters.
o Correlation of queries on multiple TCP sessions originating from o Correlation of queries on multiple TCP sessions originating from
the same IP address. the same IP address.
o Correlating of queries on multiple TLS sessions originating from o Correlating of queries on multiple TLS sessions originating from
the same client, including via session resumption mechanisms. the same client, including via session resumption mechanisms.
o Resolvers _might_ receive client identifiers e.g. MAC addresses o Resolvers _might_ receive client identifiers e.g., MAC addresses
in EDNS(0) options - some Customer-premises equipment (CPE) in EDNS(0) options - some Customer-premises equipment (CPE)
devices are known to add them. devices are known to add them [MAC-address-EDNS].
o HTTP headers (e.g., User-Agent, Accept, Accept-Encoding).
Mitigations: Mitigations:
o 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: [RFC6973] Threats:
o Surveillance: o Surveillance:
skipping to change at page 18, line 27 skipping to change at page 17, line 41
5.3.1. Protocol recommendations 5.3.1. Protocol recommendations
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Transmission of identifying data upstream. * Transmission of identifying data upstream.
Mitigations: Mitigations:
As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS As specified in [RFC8310] for DoT but applicable to any DNS Privacy
Privacy services the server should: services the server should:
o Implement QNAME minimization [RFC7816]. o Implement QNAME minimization [RFC7816].
o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
EDNS(0) Client Subnet (ECS) option and not send an ECS option in EDNS(0) Client Subnet (ECS) option ([RFC7871] Section 7.1.2).
upstream queries.
Optimizations: Optimizations:
o 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 whitelisting upstream servers to send ECS and ideally use a policy of allowlisting upstream servers to send ECS
to in order to minimize data leakage. Operators should make clear in to in order to minimize data leakage. Operators should make clear in
any policy statement what prefix length they actually send and the any policy statement what prefix length they actually send and the
specific policy used. specific policy used.
Whitelisting 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 allows the operator to
decide which upstream servers apply privacy policies that the decide which upstream servers apply privacy policies that the
operator is happy with. However some operators consider whitelisting operator is happy with. However some operators consider allowlisting
to incur significant operational overhead compared to dynamic to incur significant operational overhead compared to dynamic
detection of ECS on authoritative servers. detection of ECS on authoritative servers.
Additional options: Additional options:
o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020] o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
(NXDOMAIN: There Really Is Nothing Underneath) to reduce the (NXDOMAIN: There Really Is Nothing Underneath) to reduce the
number of queries to authoritative servers to increase privacy. number of queries to authoritative servers to increase privacy.
o Run a copy of the root zone on loopback [RFC7706] to avoid making o Run a copy of the root zone on loopback [RFC7706] to avoid making
skipping to change at page 20, line 21 skipping to change at page 19, line 33
o Secondary use. o Secondary use.
o Disclosure. o Disclosure.
DNS Privacy Threats: DNS Privacy Threats:
o Contravention of legal requirements not to process user data. o Contravention of legal requirements not to process user data.
Mitigations: Mitigations:
Operators should not provide identifiable data to third-parties Operators should not share identifiable data with third-parties.
without explicit consent from clients (we take the stance here that
simply using the resolution service itself does not constitute If operators choose to share identifiable data with third-parties in
consent). 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 research)
but also the wider Internet community. See the policy published by but also the wider Internet community. See the policy published by
SURFnet [SURFnet-policy] on data sharing for research as an example. SURFnet [SURFnet-policy] on data sharing for research as an example.
6. DNS Recursive Operator Privacy (DROP) statement 6. DNS Recursive Operator Privacy (DROP) statement
The following section outlines the recommended contents of a DROP To be compliant with this Best Common Practices document, a DNS
statement an operator might choose to publish. An example statement Recursive Operator SHOULD publish a DNS Recursive Operator Privacy
for a specific scenario is provided for guidance only in Appendix C. Statement. Adopting the outline, and including the headings in the
order provided, is a benefit to persons comparing multiple operators'
DROP statements.
6.1. Recommended contents of a DROP statement Appendix C provides a comparison of some existing policy and privacy
statements.
6.1. Outline of a DROP statement
The contents of Section 6.1.1 and Section 6.1.2 are non-normative,
other than the order of the headings. Material under each topic is
present to assist the operator developing their own DROP statement
and:
o Relates _only_ to matters around to the technical operation of DNS
privacy services, and not on any other matters.
o Does not attempt to offer an exhaustive list for the contents of a
DROP statement.
o Is not intended to form the basis of any legal/compliance
documentation.
Appendix D provides an example (also non-normative) of a DROP
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 PII. 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 and in each case whether it is aggregated, pseudonymized, or
anonymized and the conditions of data transfer. anonymized and the conditions of data transfer. Where possible
provide details of the techniques used for the above 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 any partners, third-party 4. Associated entities. Declare and explicitly enumerate any
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
This section should explain the current operational practices of the [NOTE FOR RFC EDITOR: Please update this section to use letters for
service. 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.
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 section Section 5 2. Client facing capabilities. With reference to Section 5 provide
provide specific details of which capabilities are provided on specific details of which capabilities are provided on which
which client facing addresses and ports: client facing addresses and ports:
1. For DoT, specify the authentication domain name to be used 1. For DoT, specify the authentication domain name to be used
(if any). (if any).
2. For DoT, specify the SPKI pin sets to be used (if any) and 2. For DoT, specify the SPKI pin sets to be used (if any) and
policy for rolling keys. policy for rolling keys.
3. Upstream capabilities. With reference to section Section 5.3 3. Upstream capabilities. With reference to section Section 5.3
provide specific details of which capabilities are provided provide specific details of which capabilities are provided
upstream for data sent to authoritative servers. upstream for data sent to authoritative servers.
skipping to change at page 22, line 33 skipping to change at page 22, line 23
is being provided. is being provided.
1. Specify the operator entity or entities that will control the 1. Specify the operator entity or entities that will control the
data and be responsible for their treatment, and their legal data and be responsible for their treatment, and their legal
place of business. place of business.
2. Specify, either directly or by pointing to the applicable 2. Specify, either directly or by pointing to the applicable
privacy policy, the relevant privacy laws that apply to the privacy policy, the relevant privacy laws that apply to the
treatment of the data, the rights that users enjoy in regard treatment of the data, the rights that users enjoy in regard
to their own personal information that is treated by the to their own personal information that is treated by the
service, and how they can contact the operator to enforce service, and how they can contact the operator to exercise
them. them.
3. Additionally specify the countries in which the servers 3. Additionally specify the countries in which the servers
handling the DNS requests and the data are located (if the handling the DNS requests and the data are located (if the
operator applies a geolocation policy so that requests from operator applies a geolocation policy so that requests from
certain countries are only served by certain servers, this certain countries are only served by certain servers, this
should be specified as well). should be specified as well).
4. Specify whether the operator has any agreement in place with 4. Specify whether the operator has any agreement in place with
law enforcement agencies, or other public and private parties law enforcement agencies, or other public and private
dealing with security and intelligence, to give them access parties, to give them access to the servers and/or to the
to the servers and/or to the data. data.
6.2. Current policy and privacy statements
A tabular comparison of policy and privacy statements from various
DNS Privacy service operators based loosely on the proposed DROP
structure can be found at [policy-comparison]. The analysis is based
on the data available in December 2019.
We note that the existing set of policies vary widely in style,
content and detail and it is not uncommon for the full text for a
given operator to equate to more than 10 pages of moderate font sized
A4 text. It is a non-trivial task today for a user to extract a
meaningful overview of the different services on offer.
It is also noted that Mozilla have published a DoH resolver policy
[DoH-resolver-policy], which describes the minimum set of policy
requirements that a party must satisfy to be considered as a
potential partner for Mozilla's Trusted Recursive Resolver (TRR)
program.
6.3. 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 Independent monitoring or analysis could be performed where possible
of: of:
o ECS, QNAME minimization, EDNS(0) padding, etc. o ECS, QNAME minimization, EDNS(0) padding, etc.
o Filtering. o Filtering.
o Uptime. o 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 third
party auditor to verify their compliance with their published DROP party auditor to verify their compliance with their published DROP
statement. statement.
7. IANA considerations 7. IANA considerations
None None
8. Security considerations 8. Security considerations
skipping to change at page 24, line 13 skipping to change at page 23, line 28
D.dnsop-dns-tcp-requirements]. D.dnsop-dns-tcp-requirements].
9. Acknowledgements 9. Acknowledgements
Many thanks to Amelia Andersdotter for a very thorough review of the Many thanks to Amelia Andersdotter for a very thorough review of the
first draft of this document and Stephen Farrell for a thorough first draft of this document and Stephen Farrell for a thorough
review at WGLC and for suggesting the inclusion of an example DROP review at WGLC and for suggesting the inclusion of an example DROP
statement. Thanks to John Todd for discussions on this topic, and to statement. Thanks to John Todd for discussions on this topic, and to
Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review. Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review.
Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York,
John Reed, Lorenzo Colitti for comments at the mic. Thanks to Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to
Loganaden Velvindron for useful updates to the text. Loganaden Velvindron for useful updates to the text.
Sara Dickinson thanks the Open Technology Fund for a grant to support Sara Dickinson thanks the Open Technology Fund for a grant to support
the work on this document. the work on this document.
10. Contributors 10. Contributors
The below individuals contributed significantly to the document: The below individuals contributed significantly to the document:
John Dickinson John Dickinson
skipping to change at page 24, line 39 skipping to change at page 24, line 7
Jim Hague Jim Hague
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
11. Changelog 11. Changelog
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 draft-ietf-dprive-bcp-op-09
o Fix references so they match the correct section numbers in draft- o Fix references so they match the correct section numbers in draft-
ietf-dprive-rfc7626-bis-05 ietf-dprive-rfc7626-bis-05
draft-ietf-dprive-bcp-op-08 draft-ietf-dprive-bcp-op-08
o Address IETF Last call comments. o Address IETF Last call comments.
draft-ietf-dprive-bcp-op-07 draft-ietf-dprive-bcp-op-07
o Editorial changes following AD review. o Editorial changes following AD review.
o Change all URIs to Informational References. o Change all URIs to Informational References.
draft-ietf-dprive-bcp-op-06
o Final minor changes from second WGLC. o Final minor changes from second WGLC.
draft-ietf-dprive-bcp-op-05 draft-ietf-dprive-bcp-op-05
o Remove some text on consent: o Remove some text on consent:
* Paragraph 2 in section 5.3.3 * Paragraph 2 in section 5.3.3
* Item 6 in the DROP Practice statement (and example) * Item 6 in the DROP Practice statement (and example)
skipping to change at page 26, line 37 skipping to change at page 26, line 25
o Update DoH reference to RFC8484 and add more text on DoH o Update DoH reference to RFC8484 and add more text on DoH
o Split threat descriptions into ones directly referencing RFC6973 o Split threat descriptions into ones directly referencing RFC6973
and other DNS Privacy threats and other DNS Privacy threats
o Improve threat descriptions throughout o Improve threat descriptions throughout
o Remove reference to the DNSSEC TLS Chain Extension draft until new o Remove reference to the DNSSEC TLS Chain Extension draft until new
version submitted. version submitted.
o Clarify use of whitelisting for ECS o Clarify use of allowlisting for ECS
o Re-structure the DPPPS, add Result filtering section. o Re-structure the DPPPS, add Result filtering section.
o Remove the direct inclusion of privacy policy comparison, now just o Remove the direct inclusion of privacy policy comparison, now just
reference dnsprivacy.org and an example of such work. reference dnsprivacy.org and an example of such work.
o Add an appendix briefly discussing DNSSEC o Add an appendix briefly discussing DNSSEC
o Update affiliation of 1 author o Update affiliation of 1 author
draft-ietf-dprive-bcp-op-00 draft-ietf-dprive-bcp-op-00
o Initial commit of re-named document after adoption to replace o Initial commit of re-named document after adoption to replace
draft-dickinson-dprive-bcp-op-01 draft-dickinson-dprive-bcp-op-01
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-ietf-dprive-rfc7626-bis-04 (work in
progress), January 2020.
[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, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
DOI 10.17487/RFC6265, April 2011, <https://www.rfc- Rose, "DNS Security Introduction and Requirements",
editor.org/info/rfc6265>. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<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, <https://www.rfc-
editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[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
skipping to change at page 28, line 10 skipping to change at page 28, line 5
[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, <https://www.rfc-
editor.org/info/rfc7830>. 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.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
editor.org/info/rfc7871>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[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>.
[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, <https://www.rfc-
editor.org/info/rfc8310>. editor.org/info/rfc8310>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
skipping to change at page 28, line 41 skipping to change at page 28, line 27
editor.org/info/rfc8404>. editor.org/info/rfc8404>.
[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>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
12.2. Informative References 12.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", 2019,
<http://dl.ifip.org/db/conf/im/im2019/189282.pdf>. <http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.
[Brenker-and-Arnes] [Brenker-and-Arnes]
Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS
skipping to change at page 29, line 24 skipping to change at page 29, line 19
<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>. [dnsdist] PowerDNS, "dnsdist Overview", 2019, <https://dnsdist.org>.
[dnstap] dnstap.info, "DNSTAP", 2019, <http://dnstap.info>. [dnstap] dnstap.info, "DNSTAP", 2019, <http://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]
IANA (iana.org), "TLS Application-Layer Protocol
Negotiation (ALPN) Protocol IDs", 2020,
<https://www.iana.org/assignments/tls-extensiontype-
values/tls-extensiontype-values.xhtml#alpn-protocol-ids>.
[Geolocation-Impact-Assessement] [Geolocation-Impact-Assessement]
Conversion Works, "Anonymize IP Geolocation Accuracy Conversion Works, "Anonymize IP Geolocation Accuracy
Impact Assessment", 2017, Impact Assessment", 2017,
<https://support.google.com/analytics/ <https://support.google.com/analytics/
answer/2763052?hl=en>. answer/2763052?hl=en>.
[haproxy] haproxy.org, "HAPROXY", 2019, <https://www.haproxy.org/>. [haproxy] haproxy.org, "HAPROXY", 2019, <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", 2006,
<http://mharvan.net/talks/noms-ip_anon.pdf>. <http://mharvan.net/talks/noms-ip_anon.pdf>.
[I-D.bellis-dnsop-xpf] [I-D.bellis-dnsop-xpf]
Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For", Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",
draft-bellis-dnsop-xpf-04 (work in progress), March 2018. draft-bellis-dnsop-xpf-04 (work in progress), March 2018.
[I-D.ietf-dnsop-dns-tcp-requirements] [I-D.ietf-dnsop-dns-tcp-requirements]
Kristoff, J. and D. Wessels, "DNS Transport over TCP - Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", draft-ietf-dnsop-dns-tcp- Operational Requirements", draft-ietf-dnsop-dns-tcp-
requirements-05 (work in progress), November 2019. requirements-06 (work in progress), May 2020.
[I-D.ietf-httpbis-bcp56bis] [I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft- Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-09 (work in progress), November ietf-httpbis-bcp56bis-09 (work in progress), November
2019. 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>.
skipping to change at page 30, line 32 skipping to change at page 30, line 36
[ipcrypt-analysis] [ipcrypt-analysis]
Aumasson, J., "Analysis of ipcrypt?", 2018, Aumasson, J., "Analysis of ipcrypt?", 2018,
<https://www.ietf.org/mail-archive/web/cfrg/current/ <https://www.ietf.org/mail-archive/web/cfrg/current/
msg09494.html>. msg09494.html>.
[ISC-Knowledge-database-on-cache-snooping] [ISC-Knowledge-database-on-cache-snooping]
ISC Knowledge Database, "DNS Cache snooping - should I be ISC Knowledge Database, "DNS Cache snooping - should I be
concerned?", 2018, <https://kb.isc.org/docs/aa-00482>. concerned?", 2018, <https://kb.isc.org/docs/aa-00482>.
[MAC-address-EDNS]
DNS-OARC mailing list, "Embedding MAC address in DNS
requests for selective filtering IDs", 2016,
<https://lists.dns-oarc.net/pipermail/dns-
operations/2016-January/014143.html>.
[nginx] nginx.org, "NGINX", 2019, <https://nginx.org/>. [nginx] nginx.org, "NGINX", 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., van Rijswijk-Deij, R., de Boer, P., and A.
Pras, "Passive Observations of a Large DNS Service: 2.5 Pras, "Passive Observations of a Large DNS Service: 2.5
Years in the Life of Google", 2018, Years in the Life of Google", 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] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.
skipping to change at page 31, line 5 skipping to change at page 31, line 16
Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
Encryption", 2014, <https://dl.acm.org/ Encryption", 2014, <https://dl.acm.org/
citation.cfm?id=2665959>. citation.cfm?id=2665959>.
[policy-comparison] [policy-comparison]
dnsprivacy.org, "Comparison of policy and privacy dnsprivacy.org, "Comparison of policy and privacy
statements 2019", 2019, statements 2019", 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", 2019,
<https://github.com/PowerDNS/pdns/blob/master/pdns/
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, 2007,
<http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>. <http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999, <https://www.rfc-
editor.org/info/rfc2560>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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,
DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
editor.org/info/rfc6265>.
[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>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
editor.org/info/rfc7626>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706, Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, <https://www.rfc- DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
editor.org/info/rfc7706>. editor.org/info/rfc7706>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
editor.org/info/rfc7871>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[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>.
[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, <https://www.rfc-
editor.org/info/rfc8027>. 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
skipping to change at page 32, line 28 skipping to change at page 32, line 41
[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>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019, RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>. <https://www.rfc-editor.org/info/rfc8490>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[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>.
skipping to change at page 33, line 23 skipping to change at page 33, line 34
[Xu-et-al.] [Xu-et-al.]
Fan, J., Xu, J., Ammar, M., and S. 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/ 2004, <http://an.kaist.ac.kr/~sbmoon/paper/
intl-journal/2004-cn-anon.pdf>. 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 characteristic of the document.
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)' o 'Specification for DNS over Transport Layer Security (TLS)'
[RFC7858], referred to here as 'DNS-over-TLS'. [RFC7858].
o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094], o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094].
referred to here as 'DNS-over-DTLS'. Note that this document has Note that this document has the Category of Experimental.
the Category of Experimental.
o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH. o 'DNS Queries over HTTPS (DoH)' [RFC8484].
o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310]. o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310].
o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for
EDNS(0)' [RFC8467]. 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] o 'DNS Query Name minimization to Improve Privacy' [RFC7816].
referred to here as 'QNAME minimization'.
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]. o 'Client Subnet in DNS Queries' [RFC7871].
o 'Domain Name System (DNS) Cookies' [RFC7873]). o 'Domain Name System (DNS) Cookies' [RFC7873]).
skipping to change at page 34, line 25 skipping to change at page 34, line 33
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 o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS
1.3 1.3
o 'A DNS Packet Capture Format' [RFC8618]. o 'A DNS Packet Capture Format' [RFC8618].
o Passive DNS [RFC8499]. o Passive DNS [RFC8499].
Section 8 of [RFC8484] outlines the privacy considerations of DoH. o Section 8 of [RFC8484] outlines the privacy considerations of DoH.
Note that depending on the specifics of a DoH implementation there Note that depending on the specifics of a DoH implementation there
may be increased identification and tracking compared to other DNS may be increased identification and tracking compared to other DNS
transports. transports.
A.3. Related operational documents A.3. Related operational documents
o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]. o 'DNS Transport over TCP - Implementation Requirements' [RFC7766].
o 'Operational requirements for DNS-over-TCP' o 'Operational requirements for DNS-over-TCP'
[I-D.ietf-dnsop-dns-tcp-requirements]. [I-D.ietf-dnsop-dns-tcp-requirements].
o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828]. o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828].
o 'DNS Stateful Operations' [RFC8490]. o 'DNS Stateful Operations' [RFC8490].
Appendix B. IP address techniques Appendix B. IP address techniques
The following table presents a high level comparison of various
techniques employed or under development in 2019, and classifies them
according to categorization of technique and other properties. Both
the specific techniques and the categorisations are described in more
detail in the following sections. The list of techniques includes
the main techniques in current use, but does not claim to be
comprehensive.
+---------------------------+----+---+----+---+----+---+---+
| Categorization/Property | GA | d | TC | C | TS | i | B |
+---------------------------+----+---+----+---+----+---+---+
| Anonymization | X | X | X | | | | X |
| Pseudoanonymization | | | | X | X | X | |
| Format preserving | X | X | X | X | X | X | |
| Prefix preserving | | | X | X | X | | |
| Replacement | | | X | | | | |
| Filtering | X | | | | | | |
| Generalization | | | | | | | X |
| Enumeration | | X | | | | | |
| Reordering/Shuffling | | | X | | | | |
| Random substitution | | | X | | | | |
| Cryptographic permutation | | | | X | X | X | |
| IPv6 issues | | | | | X | | |
| CPU intensive | | | | X | | | |
| Memory intensive | | | X | | | | |
| Security concerns | | | | | | X | |
+---------------------------+----+---+----+---+----+---+---+
Table 1: Classification of techniques
Legend of techniques: 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
depend on the requirements of that application and consideration of
the threat analysis of the particular situation.
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]
that can be used as input to existing analysis tools. In that case,
use of a format-preserving technique is essential. This, though, is
not cost-free - several authors (e.g., [Brenker-and-Arnes] have
observed that, as the entropy in an IPv4 address is limited, given a
de-identified log from a target, if an attacker is capable of
ensuring packets are captured by the target and the attacker can send
forged traffic with arbitrary source and destination addresses to
that target, any format-preserving pseudonymization is vulnerable to
an attack along the lines of a cryptographic chosen plaintext attack.
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 o 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 o Prefix preservation. Values such as IP addresses and MAC
addresses contain prefix information that can be valuable in addresses contain prefix information that can be valuable in
analysis, e.g. manufacturer ID in MAC addresses, subnet in IP analysis, e.g., manufacturer ID in MAC addresses, subnet in IP
addresses. Prefix preservation ensures that prefixes are de- addresses. Prefix preservation ensures that prefixes are de-
identified consistently; e.g. if two IP addresses are from the identified consistently; e.g., if two IP addresses are from the
same subnet, a prefix preserving de-identification will ensure same subnet, a prefix preserving de-identification will ensure
that their de-identified counterparts will also share a subnet. that their de-identified counterparts will also share a subnet.
Prefix preservation may be fixed (i.e. based on a user selected Prefix preservation may be fixed (i.e. based on a user selected
prefix length identified in advance to be preserved ) or general. prefix length identified in advance to be preserved ) or general.
o Replacement. A one-to-one replacement of a field to a new value o Replacement. A one-to-one replacement of a field to a new value
of the same type, for example using a regular expression. of the same type, for example, using a regular expression.
o Filtering. Removing (and thus truncating) or replacing data in a o Filtering. Removing (and thus truncating) or replacing data in a
field. Field data can be overwritten, often with zeros, either field. Field data can be overwritten, often with zeros, either
partially (grey marking) or completely (black marking). partially (grey marking) or completely (black marking).
o Generalization. Data is replaced by more general data with o Generalization. Data is replaced by more general data with
reduced specificity. One example would be to replace all TCP/UDP reduced specificity. One example would be to replace all TCP/UDP
port numbers with one of two fixed values indicating whether the port 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 non-ephemeral (>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. e.g., a numeric value or a timestamp.
o Enumeration. With data from a well-ordered set, replace the first o Enumeration. With data from a well-ordered set, replace the first
data item data using a random initial value and then allocate data item 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 o Reordering/shuffling. Preserving the original data, but
rearranging its order, often in a random manner. rearranging its order, often in a random manner.
o Random substitution. As replacement, but using randomly generated o Random substitution. As replacement, but using randomly generated
replacement values. replacement values.
o Cryptographic permutation. Using a permutation function, such as o Cryptographic permutation. Using a permutation function, such as
a hash function or cryptographic block cipher, to generate a a hash function or cryptographic block cipher, to generate a
replacement de-identified value. replacement de-identified value.
B.1. Google Analytics non-prefix filtering B.2. Specific techniques
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-Assessement] which suggest that the
impact of this on reducing the accuracy of determining the user's impact of this on reducing the accuracy of determining the user's
location from their IP address is less than might be hoped; the location from their IP address is less than might be hoped; the
average discrepancy in identification of the user city for UK users average discrepancy in identification of the user city for UK users
is no more than 17%. is no more than 17%.
Anonymization: Format-preserving, Filtering (grey marking). Anonymization: Format-preserving, Filtering (grey marking).
B.2. dnswasher B.2.2. dnswasher
Since 2006, PowerDNS have included a de-identification tool Since 2006, PowerDNS have included a de-identification tool dnswasher
Appendix B.2 with their PowerDNS product. This is a PCAP filter that [PowerDNS-dnswasher] with their PowerDNS product. This is a PCAP
performs a one-to-one mapping of end user IP addresses with an filter that performs a one-to-one mapping of end user IP addresses
anonymized address. A table of user IP addresses and their de- with an anonymized address. A table of user IP addresses and their
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 running over a large amount of data the
address translation tables can grow to a significant size. address translation tables can grow to a significant size.
Anonymization: Format-preserving, Enumeration. Anonymization: Format-preserving, Enumeration.
B.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 anonymised 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 TCPdrpiv is not deterministic; different of a random value means that TCPdrpiv 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, and because of the need to allocated anonymized
addresses sequentially cannot be used in parallel processing. addresses sequentially cannot be used in parallel processing.
Anonymization: Format-preserving, prefix preservation (general). Anonymization: Format-preserving, prefix preservation (general).
B.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, so has a non-trivial 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 pre-calculating
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.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 pre-calculated 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 pre-calculated structures to a few Mb 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.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 32bit 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.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 be able to monitor the DNS queries of an individual user.
By using a Bloom filter, it is possible to determine with a high By using a Bloom filter, it is possible to determine with a high
probability if, for example, a particular query was made, but the set probability if, for example, a particular query was made, but the set
of queries made cannot be recovered from the filter. Similarly, by of queries made cannot be recovered from the filter. Similarly, by
mixing queries from a sufficient number of users in a single filter, mixing queries from a sufficient number of users in a single filter,
it becomes practically impossible to determine if a particular user it becomes practically impossible to determine if a particular user
performed a particular query. Large numbers of queries can be performed a particular query. Large numbers of queries can be
tracked in a memory-efficient way. As filter status is stored, this tracked in a memory-efficient way. As filter status is stored, this
approach cannot be used to regenerate traffic, and so cannot be used approach cannot be used to regenerate traffic, and so cannot be used
with tools used to process live traffic. with tools used to process live traffic.
Anonymized: Generalization. Anonymized: Generalization.
Appendix C. Example DROP statement Appendix C. Current policy and privacy statements
A tabular comparison of policy and privacy statements from various
DNS Privacy service operators based loosely on the proposed DROP
structure can be found at [policy-comparison]. The analysis is based
on the data available in December 2019.
We note that the existing set of policies vary widely in style,
content and detail and it is not uncommon for the full text for a
given operator to equate to more than 10 pages of moderate font sized
A4 text. It is a non-trivial task today for a user to extract a
meaningful overview of the different services on offer.
It is also noted that Mozilla have published a DoH resolver policy
[DoH-resolver-policy], which describes the minimum set of policy
requirements that a party must satisfy to be considered as a
potential partner for Mozilla's Trusted Recursive Resolver (TRR)
program.
Appendix D. Example DROP statement
The following example DROP statement is very loosely based on some The following example DROP statement is very loosely based on some
elements of published privacy statements for some public resolvers, elements of published privacy statements for some public resolvers,
with additional fields populated to illustrate the what the full with additional fields populated to illustrate the what the full
contents of a DROP statement might look like. This should not be contents of a DROP statement might look like. This should not be
interpreted as interpreted as
o having been reviewed or approved by any operator in any way o having been reviewed or approved by any operator in any way
o having any legal standing or validity at all o having any legal standing or validity at all
o being complete or exhaustive o being complete or exhaustive
This is a purely hypothetical example of a DROP statement to outline This is a purely hypothetical example of a DROP statement to outline
example contents - in this case for a public resolver operator example contents - in this case for a public resolver operator
providing a basic DNS Privacy service via one IP address and one DoH providing a basic DNS Privacy service via one IP address and one DoH
URI with security based filtering. It does aim to meet minimal URI with security based filtering. It does aim to meet minimal
compliance as specified in Section 5. compliance as specified in Section 5.
C.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
Personally-Identifiable Information (PII), and we take a personal data, and we take a conservative approach in treating IP
conservative approach in treating IP addresses as PII in all addresses as personal data in all jurisdictions in which our
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 1. IP addresses. Our normal course of data management does not
have any IP address information or other PII logged to disk have any IP address information or other personal data logged
or transmitted out of the location in which the query was to disk or transmitted out of the location in which the query
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 2. 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 we
can conduct debugging and analyze abuse phenomena. We also can conduct debugging and analyze abuse phenomena. We also
use the collected information for the creation and sharing of use the collected information for the creation and sharing of
telemetry (timestamp, geolocation, number of hits, first telemetry (timestamp, geolocation, number of hits, first
seen, last seen) for contributors, public publishing of 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 + Request 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. UDP,
TCP, DoT, TCP, DoT,
DoH DoH
+ Origin IP general geolocation information: i.e. geocode, + Origin IP general geolocation information: i.e. geocode,
region ID, city ID, and metro code 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 + Absolute arrival time
+ 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,
skipping to change at page 40, line 25 skipping to change at page 42, line 13
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 Services also builds, stores, and may
share certain DNS data streams which store high level share certain DNS data streams which store high level
information about domain resolved, query types, result codes, information about domain resolved, query types, result codes,
and timestamp. These streams do not contain IP address and timestamp. These streams do not contain IP address
information of requestor and cannot be correlated to IP information of requestor and cannot be correlated to IP
address or other PII. We do not and never will share any of address or other personal data. We do not and never will
its data with marketers, nor will it use this data for share any of its data with marketers, nor will it use this
demographic analysis. 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 which 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 defence
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
skipping to change at page 41, line 10 skipping to change at page 42, line 45
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 blocks access to those malicious domains when
your system attempts to contact them. An NXDOMAIN is your system attempts to contact them. An NXDOMAIN is
returned for blocked sites. returned for blocked sites.
1. Censorship. We will not provide a censoring component 1. 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 whitelisting 2. 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 whitelist 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.
C.2. Practice D.2. Practice
1. Deviations from Policy. None currently in place. 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) 1. 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 2. We offer DNS over TLS as specified in RFC7858 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 RFC7766.
1. The DoT authentication domain name used is (insert domain 1. The DoT authentication domain name used is (insert domain
name). name).
2. We do not publish SPKI pin sets. 2. We do not publish SPKI pin sets.
3. We offer DNS-over-HTTPS as specified in RFC8484 on (insert 3. We offer DNS over HTTPS as specified in RFC8484 on (insert
URI template). Both POST and GET are supported. URI template). Both POST and GET are supported.
4. Both services offer TLS 1.2 and TLS 1.3. 4. Both services offer TLS 1.2 and TLS 1.3.
5. Both services pad DNS responses according to RFC8467. 5. Both services pad DNS responses according to RFC8467.
6. Both services provide DNSSEC validation. 6. Both services provide DNSSEC validation.
3. Upstream capabilities. 3. Upstream capabilities.
 End of changes. 136 change blocks. 
340 lines changed or deleted 417 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/