< draft-ietf-dprive-bcp-op-07.txt   draft-ietf-dprive-bcp-op-08.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: June 20, 2020 R. van Rijswijk-Deij Expires: July 27, 2020 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
December 18, 2019 January 24, 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-07 draft-ietf-dprive-bcp-op-08
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 framework to assist writers of a DNS
Recursive Operator Privacy Statement (analogous to DNS Security Recursive Operator Privacy Statement (analogous to DNS Security
Extensions (DNSSEC) Policies and DNSSEC Practice Statements described Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
in RFC6841). in RFC6841).
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 June 20, 2020. This Internet-Draft will expire on July 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . 11
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 DNS Monitoring . . . . . . . 12
5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13 5.1.8. Limitations of fronting a DNS privacy service with a
pure TLS proxy . . . . . . . . . . . . . . . . . . . 13
5.2. Data at rest on the server . . . . . . . . . . . . . . . 13 5.2. Data at rest on the server . . . . . . . . . . . . . . . 13
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Data minimization of network traffic . . . . . . . . 14 5.2.2. Data minimization of network traffic . . . . . . . . 15
5.2.3. IP address pseudonymization and anonymization methods 15 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 . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . 18
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19
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 . . . . . . . 20
6.1. Recommended contents of a DROP statement . . . . . . . . 20 6.1. Recommended contents 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. Current policy and privacy statements . . . . . . . . . . 22
6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 23 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33
A.1. Potential increases in DNS privacy . . . . . . . . . . . 32 A.1. Potential increases in DNS privacy . . . . . . . . . . . 33
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 33 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34
A.3. Related operational documents . . . . . . . . . . . . . . 33 A.3. Related operational documents . . . . . . . . . . . . . . 34
Appendix B. IP address techniques . . . . . . . . . . . . . . . 34 Appendix B. IP address techniques . . . . . . . . . . . . . . . 34
B.1. Google Analytics non-prefix filtering . . . . . . . . . . 35 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 35
B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 35 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 36
B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 35 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 36
B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 36 B.4. Cryptographic Prefix-Preserving Pseudonymization . . . . 36
B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 36 B.5. Top-hash Subtree-replicated Anonymization . . . . . . . . 37
B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 36 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 37
B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 37 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 37
Appendix C. Example DROP statement . . . . . . . . . . . . . . . 37 Appendix C. Example DROP statement . . . . . . . . . . . . . . . 38
C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 37 C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 38
C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 40 C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
o DROP: DNS Recursive Operator Privacy statement, see Section 6. o DROP: DNS Recursive Operator Privacy statement, see Section 6.
o DNS privacy service: The service that is offered via a privacy- o DNS privacy service: The service that is offered via a privacy-
enabling DNS server and is documented either in an informal enabling DNS server and is documented either in an informal
statement of policy and practice with regard to users privacy or a statement of policy and practice with regard to users privacy or a
formal DROP statement. formal DROP statement.
5. Recommendations for DNS privacy services 5. Recommendations for DNS privacy services
In the following sections we first outline the threats relevant to
the specific topic and then discuss the potential actions that can be
taken to mitigate them.
We describe two classes of threats: We describe two classes of threats:
o Threats described in [RFC6973] 'Privacy Considerations for o Threats described in [RFC6973] 'Privacy Considerations for
Internet Protocols' Internet Protocols'
* Privacy terminology, threats to privacy and mitigations as * Privacy terminology, threats to privacy, and mitigations as
described in Sections 3, 5 and 6 of [RFC6973]. described in Sections 3, 5, and 6 of [RFC6973].
o DNS Privacy Threats o DNS Privacy Threats
* These are threats to the users and operators of DNS privacy * These are threats to the users and operators of DNS privacy
services that are not directly covered by [RFC6973]. These may services that are not directly covered by [RFC6973]. These may
be more operational in nature such as certificate management or be more operational in nature such as certificate management or
service availability issues. service availability issues.
We describe three classes of actions that operators of DNS privacy We describe three classes of actions that operators of DNS privacy
services can take: services can take:
skipping to change at page 8, line 6 skipping to change at page 8, line 10
o DNS-over-TLS [RFC7858] and [RFC8310]. o DNS-over-TLS [RFC7858] and [RFC8310].
o DoH [RFC8484]. o 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 and any discussion of best practice for
providing such a service is out of scope for this document. 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:
skipping to change at page 8, line 38 skipping to change at page 8, line 42
When using DNS-over-TLS clients that select a 'Strict Privacy' usage When using DNS-over-TLS clients that select a 'Strict Privacy' usage
profile [RFC8310] (to mitigate the threat of active attack on the profile [RFC8310] (to mitigate the threat of active attack on the
client) require the ability to authenticate the DNS server. To client) require the ability to authenticate the DNS server. To
enable this, DNS privacy services that offer DNS-over-TLS should enable this, DNS privacy services that offer DNS-over-TLS should
provide credentials in the form of either X.509 certificates provide credentials in the form of either X.509 certificates
[RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310]. [RFC5280] or 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
Online Certificate Status Protocol (OCSP) [RFC2560] as described in
[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.
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 URLs or
authentication domain names. authentication domain names [RFC8310].
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
manage certificates through automation and has been implemented by manage certificates through automation and has been implemented by
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 name for the service. o Choose a short, memorable authentication domain name for the
service.
5.1.3. Protocol recommendations 5.1.3. Protocol recommendations
5.1.3.1. DNS-over-TLS 5.1.3.1. DNS-over-TLS
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].
skipping to change at page 9, line 45 skipping to change at page 10, line 4
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 DNS-over-TLS).
Mitigations: Mitigations:
In the case of DNS-over-TLS, TLS profiles from Section 9 and the In the case of DNS-over-TLS, TLS profiles from Section 9 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 DNS-over-TLS privacy service on both port 853 and 443. This
practice may not be possible if e.g. the operator deploys DoH on practice may not be possible if e.g. the operator deploys DoH on
the same IP address. the same IP address.
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
skipping to change at page 11, line 15 skipping to change at page 11, line 19
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 for e.g. websites
where they might reveal personal information to attackers. where they might reveal personal information to attackers.
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 DNSSEC validation. In addition they must be able to performs Domain Name System Security Extensions (DNSSEC)
provide the DNSSEC RRs to the client so that it can perform its validation. In addition they must be able to provide the DNSSEC
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
solving different problems. The use of one does not diminish the solving different problems. The use of one does not diminish the
need nor the usefulness of the other. need nor the usefulness of the other.
While the use of an authenticated and encrypted transport protects While the use of an authenticated and encrypted transport protects
origin authentication and data integrity between a client and a DNS origin authentication and data integrity between a client and a DNS
privacy service it provides no proof (for a non-validating client) privacy service it provides no proof (for a non-validating client)
that the data provided by the DNS privacy service was actually DNSSEC that the data provided by the DNS privacy service was actually DNSSEC
authenticated. As with cleartext DNS the user is still solely authenticated. As with cleartext DNS the user is still solely
trusting the AD bit (if present) set by the resolver. trusting the AD bit (if present) set by the resolver.
It should also be noted that the use of an encrypted transport for It should also be noted that the use of an encrypted transport for
DNS actually solves many of the practical issues encountered by DNS DNS actually solves many of the practical issues encountered by DNS
validating clients e.g. interference by middleboxes with cleartext validating clients e.g. interference by middleboxes with cleartext
DNS payloads is completely avoided. In this sense a validating DNS payloads is completely avoided. In this sense a validating
client that uses a DNS privacy service which supports DNSSEC has a client that uses a DNS privacy service which supports DNSSEC has a
far simpler task in terms of DNS Roadblock avoidance. far simpler task in terms of DNSSEC Roadblock avoidance [RFC8027].
5.1.5. Availability 5.1.5. Availability
DNS Privacy Threats: DNS Privacy Threats:
o A failed DNS privacy service could force the user to switch o A failed DNS privacy service 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:
skipping to change at page 12, line 22 skipping to change at page 12, line 28
DNS Privacy Threats: DNS Privacy Threats:
o Unfairly disadvantaging users of the privacy service with respect o Unfairly disadvantaging users of the privacy service with respect
to the services available. This could force the user to switch to the services available. This could force the user to switch
providers, fallback to cleartext or accept no DNS service for the providers, 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 such options 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 DNS Monitoring
DNS Privacy Threats: DNS Privacy Threats:
o Increased use of encryption impacts operator ability to manage o Increased use of encryption impacts operator ability to manage
their network [RFC8404]. their network [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. There are,
however, legitimate reasons for operators to inspect DNS traffic, however, legitimate reasons for DNS privacy service operators to
e.g. to monitor for network security threats. Operators may inspect DNS traffic, e.g. to monitor for network security threats.
therefore need to invest in alternative means of monitoring that Operators may therefore need to invest in alternative means of
relies on either the resolver software directly, or exporting DNS monitoring that relies on either the resolver software directly, or
traffic from the resolver using e.g. [dnstap]. exporting DNS 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 A. Appendix B.
5.1.8. Limitations of using a pure TLS proxy 5.1.8. Limitations of fronting a DNS privacy service with a pure TLS
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 of the target server could lead to data leakage
if the proxy to target server path is not encrypted. 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 DNS-over-TLS using a TLS proxy
(e.g. [nginx], [haproxy] or [stunnel]) in front of a DNS nameserver (e.g. [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.
Operators may choose to use a DNS aware proxy such as [dnsdist] which Operators may choose to use a DNS aware proxy such as [dnsdist] which
offer custom options (similar to that proposed in offers custom options (similar to that proposed in
[I-D.bellis-dnsop-xpf]) to add source information to packets to [I-D.bellis-dnsop-xpf]) to add source information to packets to
address this shortcoming. It should be noted that such options address this shortcoming. It should be noted that such options
potentially significantly increase the leaked information in the potentially significantly increase the leaked information in the
event of a misconfiguration. event of a misconfiguration.
5.2. Data at rest on the server 5.2. Data at rest on the server
5.2.1. Data handling 5.2.1. Data handling
[RFC6973] Threats: [RFC6973] Threats:
skipping to change at page 14, line 14 skipping to change at page 14, line 22
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 common activities for DNS service operators and in
all cases should be minimized or completely avoided if possible for all cases should be minimized or completely avoided if possible for
DNS privacy services. If data is retained it should be encrypted and DNS privacy services. If data is retained it should be encrypted and
either aggregated, pseudonymized or anonymized whenever possible. In either aggregated, pseudonymized, or anonymized whenever possible.
general the principle of data minimization described in [RFC6973] In general the principle of data minimization described in [RFC6973]
should be applied. 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.
skipping to change at page 15, line 7 skipping to change at page 15, line 17
Data minimization refers to collecting, using, disclosing, and Data minimization refers to collecting, using, disclosing, and
storing the minimal data necessary to perform a task, and this can be storing the minimal data necessary to perform a task, and this can be
achieved by removing or obfuscating privacy-sensitive information in achieved by removing or obfuscating privacy-sensitive information in
network traffic logs. This is typically personal data, or data that network traffic logs. This is typically personal data, or data that
can be used to link a record to an individual, but may also include can be used to link a record to an individual, but may also include
revealing other confidential information, for example on the revealing other confidential information, for example on the
structure of an internal corporate network. structure of an internal corporate network.
The problem of effectively ensuring that DNS traffic logs contain no The problem of effectively ensuring that DNS traffic logs contain no
or minimal privacy-sensitive information is not one that currently or minimal privacy-sensitive information is not one that currently
has a generally agreed solution or any Standards to inform this has a generally agreed solution or any standards to inform this
discussion. This section presents and overview of current techniques discussion. This section presents an overview of current techniques
to simply provide reference on the current status of this work. to simply provide reference on the current status of this work.
Research into data minimization techniques (and particularly IP Research into data minimization techniques (and particularly IP
address pseudonymization/anonymization) was sparked in the late address pseudonymization/anonymization) was sparked in the late
1990s/early 2000s, partly driven by the desire to share significant 1990s/early 2000s, partly driven by the desire to share significant
corpuses of traffic captures for research purposes. Several corpuses of traffic captures for research purposes. Several
techniques reflecting different requirements in this area and techniques reflecting different requirements in this area and
different performance/resource tradeoffs emerged over the course of different performance/resource tradeoffs emerged over the course of
the decade. Developments over the last decade have been both a the decade. Developments over the last decade have been both a
blessing and a curse; the large increase in size between an IPv4 and blessing and a curse; the large increase in size between an IPv4 and
skipping to change at page 16, line 16 skipping to change at page 16, line 26
The following table presents a high level comparison of various The following table presents a high level comparison of various
techniques employed or under development in 2019 and classifies them techniques employed or under development in 2019 and classifies them
according to categorization of technique and other properties. according to categorization of technique and other properties.
Appendix B provides a more detailed survey of these techniques and Appendix B provides a more detailed survey of these techniques and
definitions for the categories and properties listed below. The list definitions for the categories and properties listed below. The list
of techniques includes the main techniques in current use, but does of techniques includes the main techniques in current use, but does
not claim to be comprehensive. not claim to be comprehensive.
+---------------------------+----+---+----+---+----+---+---+ +---------------------------+----+---+----+---+----+---+---+
| Categorisation/Property | GA | d | TC | C | TS | i | B | | Categorization/Property | GA | d | TC | C | TS | i | B |
+---------------------------+----+---+----+---+----+---+---+ +---------------------------+----+---+----+---+----+---+---+
| Anonymisation | X | X | X | | | | X | | Anonymization | X | X | X | | | | X |
| Pseudoanonymisation | | | | X | X | X | | | Pseudoanonymization | | | | X | X | X | |
| Format preserving | X | X | X | X | X | X | | | Format preserving | X | X | X | X | X | X | |
| Prefix preserving | | | X | X | X | | | | Prefix preserving | | | X | X | X | | |
| Replacement | | | X | | | | | | Replacement | | | X | | | | |
| Filtering | X | | | | | | | | Filtering | X | | | | | | |
| Generalisation | | | | | | | X | | Generalization | | | | | | | X |
| Enumeration | | X | | | | | | | Enumeration | | X | | | | | |
| Reordering/Shuffling | | | X | | | | | | Reordering/Shuffling | | | X | | | | |
| Random substitution | | | X | | | | | | Random substitution | | | X | | | | |
| Crytpographic permutation | | | | X | X | X | | | Cryptographic permutation | | | | X | X | X | |
| IPv6 issues | | | | | X | | | | IPv6 issues | | | | | X | | |
| CPU intensive | | | | X | | | | | CPU intensive | | | | X | | | |
| Memory intensive | | | X | | | | | | Memory intensive | | | X | | | | |
| Security concerns | | | | | | X | | | Security concerns | | | | | | X | |
+---------------------------+----+---+----+---+----+---+---+ +---------------------------+----+---+----+---+----+---+---+
Table 1: Classification of techniques Table 1: Classification of techniques
GA = Google Analytics, d = dnswasher, TC = TCPdpriv, C = CryptoPAn, GA = Google Analytics, d = dnswasher, TC = TCPdpriv, C = CryptoPAn,
TS = TSA, i = ipcipher, B = Bloom filter TS = TSA, i = ipcipher, B = Bloom filter
skipping to change at page 17, line 8 skipping to change at page 17, line 17
that can be used as input to existing analysis tools. In that case, that can be used as input to existing analysis tools. In that case,
use of a format-preserving technique is essential. This, though, is use of a format-preserving technique is essential. This, though, is
not cost-free - several authors (e.g. [Brenker-and-Arnes] have not cost-free - several authors (e.g. [Brenker-and-Arnes] have
observed that, as the entropy in an IPv4 address is limited, given a 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 de-identified log from a target, if an attacker is capable of
ensuring packets are captured by the target and the attacker can send ensuring packets are captured by the target and the attacker can send
forged traffic with arbitrary source and destination addresses to forged traffic with arbitrary source and destination addresses to
that target, any format-preserving pseudonymization is vulnerable to that target, any format-preserving pseudonymization is vulnerable to
an attack along the lines of a cryptographic chosen plaintext attack. 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 TLS version/Cipher suite combinations or other connection
parameters. parameters.
o Correlation of queries on multiple TCP session 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 CPE devices are known to add them. in EDNS(0) options - some Customer-premises equipment (CPE)
devices are known to add them.
o HTTP headers (e.g., User-Agent, Accept, Accept-Encoding). 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:
skipping to change at page 19, line 24 skipping to change at page 19, line 33
Additional options: Additional options:
Since queries from recursive resolvers to authoritative servers are Since queries from recursive resolvers to authoritative servers are
performed using cleartext (at the time of writing), resolver services performed using cleartext (at the time of writing), resolver services
need to consider the extent to which they may be directly leaking need to consider the extent to which they may be directly leaking
information about their client community via these upstream queries information about their client community via these upstream queries
and what they can do to mitigate this further. Note, that even when and what they can do to mitigate this further. Note, that even when
all the relevant techniques described above are employed there may all the relevant techniques described above are employed there may
still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For
example, a resolver with a very small community of users risks example, a resolver with a very small community of users risks
exposing data in this way and OUGHT obfuscate this traffic by mixing exposing data in this way and ought to obfuscate this traffic by
it with 'generated' traffic to make client characterization harder. mixing it with 'generated' traffic to make client characterization
The resolver could also employ aggressive pre-fetch techniques as a harder. The resolver could also employ aggressive pre-fetch
further measure to counter traffic analysis. techniques as a further measure to counter traffic analysis.
At the time of writing there are no standardized or widely recognized At the time of writing there are no standardized or widely recognized
techniques to perform such obfuscation or bulk pre-fetches. techniques to perform such obfuscation or bulk pre-fetches.
Another technique that particularly small operators may consider is Another technique that particularly small operators may consider is
forwarding local traffic to a larger resolver (with a privacy policy forwarding local traffic to a larger resolver (with a privacy policy
that aligns with their own practices) over an encrypted protocol so that aligns with their own practices) over an encrypted protocol so
that the upstream queries are obfuscated among those of the large that the upstream queries are obfuscated among those of the large
resolver. resolver.
skipping to change at page 20, line 44 skipping to change at page 21, line 5
addresses are treated as PII. addresses are treated as PII.
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.
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 any partners, third-party
affiliations or sources of funding. 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
skipping to change at page 21, line 47 skipping to change at page 22, line 9
This section should explain the current operational practices of the This section should explain the current operational practices of the
service. 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 Section 5
provide specific details of which capabilities are provided on provide specific details of which capabilities are provided on
which client facing addresses and ports: which client facing addresses and ports:
1. For DoT, specify the authentication name to be used (if any). 1. For DoT, specify the authentication domain name to be used
(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.
4. Support. Provide contact/support information for the service. 4. Support. Provide contact/support information for the service.
skipping to change at page 23, line 21 skipping to change at page 23, line 31
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 e.g. several TLS or website analysis tools This is by analogy with several TLS or website analysis tools that
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 25 skipping to change at page 24, line 39
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-08
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 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
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)
o Remove .onion and TLSA options o Remove .onion and TLSA options
o Include ACME as a reference for certificate management o Include ACME as a reference for certificate management
skipping to change at page 25, line 34 skipping to change at page 26, line 4
o Add reference to Mozilla TRR policy o Add reference to Mozilla TRR policy
o Remove several TODOs and QUESTIONS. o Remove several TODOs and QUESTIONS.
draft-ietf-dprive-bcp-op-02 draft-ietf-dprive-bcp-op-02
o Change 'open resolver' for 'public resolver' o Change 'open resolver' for 'public resolver'
o Minor editorial changes o Minor editorial changes
o Remove recommendation to run a separate TLS 1.3 service o Remove recommendation to run a separate TLS 1.3 service
o Move TLSA to purely a optimisation in Section 5.2.1 o Move TLSA to purely a optimization in Section 5.2.1
o Update reference on minimal DoH headers. o Update reference on minimal DoH headers.
o Add reference on user switching provider after service issues in o Add reference on user switching provider after service issues in
Section 5.1.4 Section 5.1.4
o Add text in Section 5.1.6 on impact on operators. o Add text in Section 5.1.6 on impact on operators.
o Add text on additional threat to TLS proxy use (Section 5.1.7) o Add text on additional threat to TLS proxy use (Section 5.1.7)
skipping to change at page 26, line 38 skipping to change at page 27, line 11
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] [I-D.ietf-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-ietf-dprive-rfc7626-bis-03 (work in Considerations", draft-ietf-dprive-rfc7626-bis-04 (work in
progress), November 2019. 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, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, <https://www.rfc- DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
editor.org/info/rfc6265>. editor.org/info/rfc6265>.
skipping to change at page 30, line 45 skipping to change at page 31, line 11
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>.
[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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[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>.
skipping to change at page 31, line 34 skipping to change at page 32, line 5
[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>.
[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,
"DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
DOI 10.17487/RFC8027, November 2016, <https://www.rfc-
editor.org/info/rfc8027>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc- DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
editor.org/info/rfc8094>. editor.org/info/rfc8094>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<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 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
skipping to change at page 33, line 19 skipping to change at page 33, line 46
referred to here as 'DNS-over-DTLS'. Note that this document has referred to here as 'DNS-over-DTLS'. 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] referred to here as DoH.
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 to 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'. 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]).
o 'Transport Layer Security (TLS) Session Resumption without Server- o 'Transport Layer Security (TLS) Session Resumption without Server-
Side State' [RFC5077] referred to here as simply TLS session Side State' [RFC5077] referred to here as simply TLS session
resumption. resumption.
o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS
1.3
o 'A DNS Packet Capture Format' [RFC8618]. o 'A DNS Packet Capture Format' [RFC8618].
o Passive DNS [RFC8499]. o Passive DNS [RFC8499].
Note that depending on the specifics of the implementation [RFC8484] Section 8 of [RFC8484] outlines the privacy considerations of DoH.
may also provide increased tracking. Note that depending on the specifics of a DoH implementation there
may be increased identification and tracking compared to other DNS
transports.
A.3. Related operational documents A.3. Related operational documents
o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]. 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].
skipping to change at page 36, line 9 skipping to change at page 36, line 42
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 Pseudonymisation B.4. Cryptographic Prefix-Preserving Pseudonymization
Cryptographic prefix-preserving pseudonymisation 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 Anonymisation B.5. Top-hash Subtree-replicated Anonymization
Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated
Anonymisation (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).
skipping to change at page 38, line 23 skipping to change at page 39, line 11
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 use of system (protections, threat general statistics of system use (protections, threat types,
types, counts, etc.) When you use our DNS Services, here is counts, etc.) When you use our DNS Services, here is the
the full list of items that are full list of items that are included in our logs:
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
skipping to change at page 39, line 28 skipping to change at page 40, line 15
3. Sharing of data. Except as described in this document, we do 3. Sharing of data. Except as described in this document, we do
not intentionally share, sell, or rent individual personal not intentionally share, sell, or rent individual personal
information associated with the requestor (i.e. source IP information associated with the requestor (i.e. source IP
address or any other information that can positively identify address or any other information that can positively identify
the client using our infrastructure) with anyone without your the client using our infrastructure) with anyone without your
consent. We generate and share high level anonymized consent. We generate and share high level anonymized
aggregate statistics including threat metrics on threat type, aggregate statistics including threat metrics on threat type,
geolocation, and if available, sector, as well as other geolocation, and if available, sector, as well as other
vertical metrics including performance metrics on our DNS vertical metrics including performance metrics on our DNS
Services (i.e. number of threats blocked, infrastructure Services (i.e. number of threats blocked, infrastructure
uptime) when available with the 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 its 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 PII. We do not and never will share any of
its data with marketers, nor will it use this data for its data with marketers, nor will it use this data for
demographic analysis. 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 events 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
can be found at our website page (insert link). can be found at our website page (insert link).
5. Correlation of Data. We do not correlate or combine information 5. Correlation of Data. We do not correlate or combine information
skipping to change at page 40, line 42 skipping to change at page 41, line 30
1. Deviations from Policy. None currently in place. 1. Deviations from Policy. None currently in place.
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 name used is (insert domain name). 1. The DoT authentication domain name used is (insert domain
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.
1. Our servers implement QNAME minimisation. 1. Our servers implement QNAME minimization.
2. Our servers do not send ECS upstream. 2. Our servers do not send ECS upstream.
4. Support. Support information for this service is available at 4. Support. Support information for this service is available at
(insert link). (insert link).
5. Jurisdiction. 5. Jurisdiction.
1. We operate as the legal entity (insert entity) registered in 1. We operate as the legal entity (insert entity) registered in
(insert country) as (insert company identifier e.g Company (insert country) as (insert company identifier e.g Company
 End of changes. 69 change blocks. 
94 lines changed or deleted 129 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/