draft-ietf-dprive-bcp-op-12.txt

dprive                                                      S. Dickinson
Internet-Draft                                                Sinodun IT
Intended status: Best Current Practice                     B. Overeinder
Expires: January 7, 2021                            R. van Rijswijk-Deij
                                                              NLnet Labs
                                                               A. Mankin
                                                              Salesforce
                                                            July 6, 2020


           Recommendations for DNS Privacy Service Operators
                      draft-ietf-dprive-bcp-op-12

Abstract

   This document presents operational, policy, and security
   considerations for DNS recursive resolver operators who choose to
   offer DNS Privacy services.  With these recommendations, the operator
   can make deliberate decisions regarding which services to provide,
   and how the decisions and alternatives impact the privacy of users.

   This document also presents a non-normative framework to assist
   writers of a Recursive operator Privacy statement (analogous to DNS
   Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
   described in RFC6841).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Dickinson, et al.        Expires January 7, 2021                [Page 1]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Privacy-related documents . . . . . . . . . . . . . . . . . .   5
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Recommendations for DNS privacy services  . . . . . . . . . .   6
     5.1.  On the wire between client and server . . . . . . . . . .   7
       5.1.1.  Transport recommendations . . . . . . . . . . . . . .   7
       5.1.2.  Authentication of DNS privacy services  . . . . . . .   8
       5.1.3.  Protocol recommendations  . . . . . . . . . . . . . .   9
       5.1.4.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.5.  Availability  . . . . . . . . . . . . . . . . . . . .  12
       5.1.6.  Service options . . . . . . . . . . . . . . . . . . .  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
               pure TLS proxy  . . . . . . . . . . . . . . . . . . .  13
     5.2.  Data at rest on the server  . . . . . . . . . . . . . . .  14
       5.2.1.  Data handling . . . . . . . . . . . . . . . . . . . .  14
       5.2.2.  Data minimization of network traffic  . . . . . . . .  15
       5.2.3.  IP address pseudonymization and anonymization methods  16
       5.2.4.  Pseudonymization, anonymization, or discarding of
               other correlation data  . . . . . . . . . . . . . . .  16
       5.2.5.  Cache snooping  . . . . . . . . . . . . . . . . . . .  17
     5.3.  Data sent onwards from the server . . . . . . . . . . . .  17
       5.3.1.  Protocol recommendations  . . . . . . . . . . . . . .  17
       5.3.2.  Client query obfuscation  . . . . . . . . . . . . . .  18
       5.3.3.  Data sharing  . . . . . . . . . . . . . . . . . . . .  19
   6.  Recursive operator Privacy Statement (RPS)  . . . . . . . . .  19
     6.1.  Outline of an RPS . . . . . . . . . . . . . . . . . . . .  20
       6.1.1.  Policy  . . . . . . . . . . . . . . . . . . . . . . .  20
       6.1.2.  Practice  . . . . . . . . . . . . . . . . . . . . . .  21
     6.2.  Enforcement/accountability  . . . . . . . . . . . . . . .  22
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  22
   8.  Security considerations . . . . . . . . . . . . . . . . . . .  22
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  23
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  23



Dickinson, et al.        Expires January 7, 2021                [Page 2]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     12.2.  Informative References . . . . . . . . . . . . . . . . .  29
   Appendix A.  Documents  . . . . . . . . . . . . . . . . . . . . .  33
     A.1.  Potential increases in DNS privacy  . . . . . . . . . . .  33
     A.2.  Potential decreases in DNS privacy  . . . . . . . . . . .  34
     A.3.  Related operational documents . . . . . . . . . . . . . .  34
   Appendix B.  IP address techniques  . . . . . . . . . . . . . . .  35
     B.1.  Categorization of techniques  . . . . . . . . . . . . . .  36
     B.2.  Specific techniques . . . . . . . . . . . . . . . . . . .  37
       B.2.1.  Google Analytics non-prefix filtering . . . . . . . .  37
       B.2.2.  dnswasher . . . . . . . . . . . . . . . . . . . . . .  37
       B.2.3.  Prefix-preserving map . . . . . . . . . . . . . . . .  38
       B.2.4.  Cryptographic Prefix-Preserving Pseudonymization  . .  38
       B.2.5.  Top-hash Subtree-replicated Anonymization . . . . . .  38
       B.2.6.  ipcipher  . . . . . . . . . . . . . . . . . . . . . .  39
       B.2.7.  Bloom filters . . . . . . . . . . . . . . . . . . . .  39
   Appendix C.  Current policy and privacy statements  . . . . . . .  39
   Appendix D.  Example RPS  . . . . . . . . . . . . . . . . . . . .  40
     D.1.  Policy  . . . . . . . . . . . . . . . . . . . . . . . . .  40
     D.2.  Practice  . . . . . . . . . . . . . . . . . . . . . . . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44

1.  Introduction

   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
   several).  However the DNS was not originally designed with strong
   security or privacy mechanisms.  A number of developments have taken
   place in recent years which aim to increase the privacy of the DNS
   system and these are now seeing some deployment.  This latest
   evolution of the DNS presents new challenges to operators and this
   document attempts to provide an overview of considerations for
   privacy focused DNS services.

   In recent years there has also been an increase in the availability
   of "public resolvers" [RFC8499] which users may prefer to use instead
   of the default network resolver either because they offer a specific
   feature (e.g., good reachability or encrypted transport) or because
   the network resolver lacks a specific feature (e.g., strong privacy
   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
   follow.

   Whilst protocols that encrypt DNS messages on the wire provide
   protection against certain attacks, the resolver operator still has



Dickinson, et al.        Expires January 7, 2021                [Page 3]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   (in principle) full visibility of the query data and transport
   identifiers for each user.  Therefore, a trust relationship (whether
   explicit or implicit) is assumed to exist between each user and the
   operator of the resolver(s) used by that user.  The ability of the
   operator to provide a transparent, well documented, and secure
   privacy service will likely serve as a major differentiating factor
   for privacy conscious users if they make an active selection of which
   resolver to use.

   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
   transport to use in all network environments has both advantages and
   disadvantages.  For example, the user has a clear expectation of
   which resolvers have visibility of their query data.  However, this
   resolver/transport selection may provide an added mechanism to track
   them as they move across network environments.  Commitments from
   resolver operators to minimize such tracking as users move between
   networks are also likely to play a role in user selection of
   resolvers.

   More recently the global legislative landscape with regard to
   personal data collection, retention, and pseudonymization has seen
   significant activity.  Providing detailed practice advice about these
   areas to the operator is out of scope, but Section 5.3.3 describes
   some mitigations of data sharing risk.

   This document has two main goals:

   o  To provide operational and policy guidance related to DNS over
      encrypted transports and to outline recommendations for data
      handling for operators of DNS privacy services.

   o  To introduce the Recursive operator Privacy Statement (RPS) and
      present a framework to assist writers of an RPS.  An RPS is a
      document that an operator should publish which outlines their
      operational practices and commitments with regard to privacy,
      thereby providing a means for clients to evaluate both the
      measurable and claimed privacy properties of a given DNS privacy
      service.  The framework identifies a set of elements and specifies
      an outline order for them.  This document does not, however,
      define a particular privacy statement, nor does it seek to provide
      legal advice as to the contents.

   A desired operational impact is that all operators (both those
   providing resolvers within networks and those operating large public
   services) can demonstrate their commitment to user privacy thereby
   driving all DNS resolution services to a more equitable footing.
   Choices for users would (in this ideal world) be driven by other



Dickinson, et al.        Expires January 7, 2021                [Page 4]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   factors, e.g., differing security policies or minor difference in
   operator policy, rather than gross disparities in privacy concerns.

   Community insight [or judgment?] about operational practices can
   change quickly, and experience shows that a Best Current Practice
   (BCP) document about privacy and security is a point-in-time
   statement.  Readers are advised to seek out any updates that apply to
   this document.

2.  Scope

   "DNS Privacy Considerations" [RFC7626] describes the general privacy
   issues and threats associated with the use of the DNS by Internet
   users and much of the threat analysis here is lifted from that
   document and from [RFC6973].  However this document is limited in
   scope to best practice considerations for the provision of DNS
   privacy services by servers (recursive resolvers) to clients (stub
   resolvers or forwarders).  Choices that are made exclusively by the
   end user, or those for operators of authoritative nameservers are out
   of scope.

   This document includes (but is not limited to) considerations in the
   following areas:

   1.  Data "on the wire" between a client and a server.

   2.  Data "at rest" on a server (e.g., in logs).

   3.  Data "sent onwards" from the server (either on the wire or shared
       with a third party).

   Whilst the issues raised here are targeted at those operators who
   choose to offer a DNS privacy service, considerations for areas 2 and
   3 could equally apply to operators who only offer DNS over
   unencrypted transports but who would otherwise like to align with
   privacy best practice.

3.  Privacy-related documents

   There are various documents that describe protocol changes that have
   the potential to either increase or decrease the privacy properties
   of the DNS in various ways.  Note this does not imply that some
   documents are good or bad, better or worse, just that (for example)
   some features may bring functional benefits at the price of a
   reduction in privacy and conversely some features increase privacy
   with an accompanying increase in complexity.  A selection of the most
   relevant documents are listed in Appendix A for reference.




Dickinson, et al.        Expires January 7, 2021                [Page 5]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


4.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   DNS terminology is as described in [RFC8499] with one modification:
   we restate the clause in the original definition of Privacy-enabling
   DNS server in [RFC8310] to include the requirement that a DNS over
   (D)TLS server should also offer at least one of the credentials
   described in Section 8 of [RFC8310] and implement the (D)TLS profile
   described in Section 9 of [RFC8310].

   Other Terms:

   o  RPS: Recursive operator Privacy Statement, see Section 6.

   o  DNS privacy service: The service that is offered via a privacy-
      enabling DNS server and is documented either in an informal
      statement of policy and practice with regard to users privacy or a
      formal RPS.

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:

   o  Threats described in [RFC6973] 'Privacy Considerations for
      Internet Protocols'

      *  Privacy terminology, threats to privacy, and mitigations as
         described in Sections 3, 5, and 6 of [RFC6973].

   o  DNS Privacy Threats

      *  These are threats to the users and operators of DNS privacy
         services that are not directly covered by [RFC6973].  These may
         be more operational in nature such as certificate management or
         service availability issues.

   We describe three classes of actions that operators of DNS privacy
   services can take:




Dickinson, et al.        Expires January 7, 2021                [Page 6]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  Threat mitigation for well understood and documented privacy
      threats to the users of the service and in some cases to the
      operators of the service.

   o  Optimization of privacy services from an operational or management
      perspective.

   o  Additional options that could further enhance the privacy and
      usability of the service.

   This document does not specify policy - only best practice, however
   for DNS Privacy services to be considered compliant with these best
   practice guidelines they SHOULD implement (where appropriate) all:

   o  Threat mitigations to be minimally compliant.

   o  Optimizations to be moderately compliant.

   o  Additional options to be maximally compliant.

   The rest of this document does not use normative language but instead
   refers only to the three differing classes of action which correspond
   to the three named levels of compliance stated above.  However,
   compliance (to the indicated level) remains a normative requirement.

5.1.  On the wire between client and server

   In this section we consider both data on the wire and the service
   provided to the client.

5.1.1.  Transport recommendations

   [RFC6973] Threats:

   o  Surveillance:

      *  Passive surveillance of traffic on the wire

   DNS Privacy Threats:

   o  Active injection of spurious data or traffic.

   Mitigations:

   A DNS privacy service can mitigate these threats by providing service
   over one or more of the following transports

   o  DNS over TLS (DoT) [RFC7858] and [RFC8310].



Dickinson, et al.        Expires January 7, 2021                [Page 7]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  DNS over HTTPS (DoH) [RFC8484].

   It is noted that a DNS privacy service can also be provided over DNS-
   over-DTLS [RFC8094], however this is an Experimental specification
   and there are no known implementations at the time of writing.

   It is also noted that DNS privacy service might be provided over
   IPSec, DNSCrypt, or VPNs.  However, there are no specific RFCs that
   cover the use of these transports for DNS and any discussion of best
   practice for providing such a service is out of scope for this
   document.

   Whilst encryption of DNS traffic can protect against active injection
   this does not diminish the need for DNSSEC, see Section 5.1.4.

5.1.2.  Authentication of DNS privacy services

   [RFC6973] Threats:

   o  Surveillance:

      *  Active attacks on client resolver configuration

   Mitigations:

   DNS privacy services should ensure clients can authenticate the
   server.  Note that this, in effect, commits the DNS privacy service
   to a public identity users will trust.

   When using DoT, clients that select a 'Strict Privacy' usage profile
   [RFC8310] (to mitigate the threat of active attack on the client)
   require the ability to authenticate the DNS server.  To enable this,
   DNS privacy services that offer DNS-over-TLS need to provide
   credentials that will be accepted by the client's trust model, in the
   form of either X.509 certificates [RFC5280] or Subject Public Key
   Info (SPKI) pin sets [RFC8310].

   When offering DoH [RFC8484], HTTPS requires authentication of the
   server as part of the protocol.

   Server operators should also follow the best practices with regard to
   certificate revocation as described in [RFC7525].

5.1.2.1.  Certificate management

   Anecdotal evidence to date highlights the management of certificates
   as one of the more challenging aspects for operators of traditional
   DNS resolvers that choose to additionally provide a DNS privacy



Dickinson, et al.        Expires January 7, 2021                [Page 8]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   service as management of such credentials is new to those DNS
   operators.

   It is noted that SPKI pin set management is described in [RFC7858]
   but that key pinning mechanisms in general have fallen out of favor
   operationally for various reasons such as the logistical overhead of
   rolling keys.

   DNS Privacy Threats:

   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 DoH URL
      templates [RFC8484] or authentication domain names [RFC8310] which
      accidentally direct clients to attacker controlled servers.

   Mitigations:

   It is recommended that operators:

   o  Follow the guidance in Section 6.5 of [RFC7525] with regards to
      certificate revocation.

   o  Automate the generation, publication, and renewal of certificates.
      For example, ACME [RFC8555] provides a mechanism to actively
      manage certificates through automation and has been implemented by
      a number of certificate authorities.

   o  Monitor certificates to prevent accidental expiration of
      certificates.

   o  Choose a short, memorable authentication domain name for the
      service.

5.1.3.  Protocol recommendations

5.1.3.1.  DoT

   DNS Privacy Threats:

   o  Known attacks on TLS such as those described in [RFC7457].

   o  Traffic analysis, for example: [Pitfalls-of-DNS-Encryption].

   o  Potential for client tracking via transport identifiers.

   o  Blocking of well known ports (e.g., 853 for DoT).



Dickinson, et al.        Expires January 7, 2021                [Page 9]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   Mitigations:

   In the case of DoT, TLS profiles from Section 9 of [RFC8310] and the
   Countermeasures to DNS Traffic Analysis from section 11.1 of
   [RFC8310] provide strong mitigations.  This includes but is not
   limited to:

   o  Adhering to [RFC7525].

   o  Implementing only (D)TLS 1.2 or later as specified in [RFC8310].

   o  Implementing EDNS(0) Padding [RFC7830] using the guidelines in
      [RFC8467] or a successor specification.

   o  Servers should not degrade in any way the query service level
      provided to clients that do not use any form of session resumption
      mechanism, such as TLS session resumption [RFC5077] with TLS 1.2,
      section 2.2 of [RFC8446], or Domain Name System (DNS) Cookies
      [RFC7873].

   o  A DoT privacy service on both port 853 and 443.  If the operator
      deploys DoH on the same IP address this requires the use of the
      'dot' ALPN value [dot-ALPN].

   Optimizations:

   o  Concurrent processing of pipelined queries, returning responses as
      soon as available, potentially out of order as specified in
      [RFC7766].  This is often called 'OOOR' - out-of-order responses
      (providing processing performance similar to HTTP multiplexing).

   o  Management of TLS connections to optimize performance for clients
      using [RFC7766] and EDNS(0) Keepalive [RFC7828]

   Additional Options:

   Management of TLS connections to optimize performance for clients
   using DNS Stateful Operations [RFC8490].

5.1.3.2.  DoH

   DNS Privacy Threats:

   o  Known attacks on TLS such as those described in [RFC7457].

   o  Traffic analysis, for example: [DNS-Privacy-not-so-private].

   o  Potential for client tracking via transport identifiers.



Dickinson, et al.        Expires January 7, 2021               [Page 10]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   Mitigations:

   o  Clients must be able to forgo the use of HTTP Cookies [RFC6265]
      and still use the service.

   o  Use of HTTP/2 padding and/or EDNS(0) padding as described in
      Section 9 of [RFC8484]

   o  Clients should not be required to include any headers beyond the
      absolute minimum to obtain service from a DoH server.  (See
      Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)

5.1.4.  DNSSEC

   DNS Privacy Threats:

   o  Users may be directed to bogus IP addresses which, depending on
      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:

   o  All DNS privacy services must offer a DNS privacy service that
      performs Domain Name System Security Extensions (DNSSEC)
      validation.  In addition they must be able to provide the DNSSEC
      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
   [RFC4033] - they are independent and fully compatible protocols, each
   solving different problems.  The use of one does not diminish the
   need nor the usefulness of the other.

   While the use of an authenticated and encrypted transport protects
   origin authentication and data integrity between a client and a DNS
   privacy service it provides no proof (for a non-validating client)
   that the data provided by the DNS privacy service was actually DNSSEC
   authenticated.  As with cleartext DNS the user is still solely
   trusting the AD bit (if present) set by the resolver.

   It should also be noted that the use of an encrypted transport for
   DNS actually solves many of the practical issues encountered by DNS
   validating clients e.g.  interference by middleboxes with cleartext
   DNS payloads is completely avoided.  In this sense a validating
   client that uses a DNS privacy service which supports DNSSEC has a
   far simpler task in terms of DNSSEC Roadblock avoidance [RFC8027].




Dickinson, et al.        Expires January 7, 2021               [Page 11]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


5.1.5.  Availability

   DNS Privacy Threats:

   o  A failed DNS privacy service could force the user to switch
      providers, fallback to cleartext or accept no DNS service for the
      outage.

   Mitigations:

   A DNS privacy service should strive to engineer encrypted services to
   the same availability level as any unencrypted services they provide.
   Particular care should to be taken to protect DNS privacy services
   against denial-of-service attacks, as experience has shown that
   unavailability of DNS resolving because of attacks is a significant
   motivation for users to switch services.  See, for example
   Section IV-C of [Passive-Observations-of-a-Large-DNS].

   Techniques such as those described in Section 10 of [RFC7766] can be
   of use to operators to defend against such attacks.

5.1.6.  Service options

   DNS Privacy Threats:

   o  Unfairly disadvantaging users of the privacy service with respect
      to the services available.  This could force the user to switch
      providers, fallback to cleartext or accept no DNS service for the
      outage.

   Mitigations:

   A DNS privacy service should deliver the same level of service as
   offered on un-encrypted channels in terms of options such as
   filtering (or lack thereof), DNSSEC validation, etc.

5.1.7.  Impact of Encryption on Monitoring by DNS Privacy Service
        Operators

   DNS Privacy Threats:

   o  Increased use of encryption can impact DNS privacy service
      operator ability to monitor traffic and therefore manage their DNS
      servers [RFC8404].

   Many monitoring solutions for DNS traffic rely on the plain text
   nature of this traffic and work by intercepting traffic on the wire,
   either using a separate view on the connection between clients and



Dickinson, et al.        Expires January 7, 2021               [Page 12]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   the resolver, or as a separate process on the resolver system that
   inspects network traffic.  Such solutions will no longer function
   when traffic between clients and resolvers is encrypted.  Many DNS
   privacy service operators still have need to inspect DNS traffic,
   e.g., to monitor for network security threats.  Operators may
   therefore need to invest in alternative means of monitoring that
   relies on either the resolver software directly, or exporting DNS
   traffic from the resolver using e.g., [dnstap].

   Optimization:

   When implementing alternative means for traffic monitoring, operators
   of a DNS privacy service should consider using privacy conscious
   means to do so (see section Section 5.2 for more details on data
   handling and also the discussion on the use of Bloom Filters in
   Appendix B.

5.1.8.  Limitations of fronting a DNS privacy service with a pure TLS
        proxy

   DNS Privacy Threats:

   o  Limited ability to manage or monitor incoming connections using
      DNS specific techniques.

   o  Misconfiguration (e.g., of the target server address in the proxy
      configuration) could lead to data leakage if the proxy to target
      server path is not encrypted.

   Optimization:

   Some operators may choose to implement DoT using a TLS proxy (e.g.
   [nginx], [haproxy], or [stunnel]) in front of a DNS nameserver
   because of proven robustness and capacity when handling large numbers
   of client connections, load balancing capabilities and good tooling.
   Currently, however, because such proxies typically have no specific
   handling of DNS as a protocol over TLS or DTLS using them can
   restrict traffic management at the proxy layer and at the DNS server.
   For example, all traffic received by a nameserver behind such a proxy
   will appear to originate from the proxy and DNS techniques such as
   ACLs, RRL, or DNS64 will be hard or impossible to implement in the
   nameserver.

   Operators may choose to use a DNS aware proxy such as [dnsdist] which
   offers custom options (similar to that proposed in
   [I-D.bellis-dnsop-xpf]) to add source information to packets to
   address this shortcoming.  It should be noted that such options




Dickinson, et al.        Expires January 7, 2021               [Page 13]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   potentially significantly increase the leaked information in the
   event of a misconfiguration.

5.2.  Data at rest on the server

5.2.1.  Data handling

   [RFC6973] Threats:

   o  Surveillance.

   o  Stored data compromise.

   o  Correlation.

   o  Identification.

   o  Secondary use.

   o  Disclosure.

   Other Threats

   o  Contravention of legal requirements not to process user data.

   Mitigations:

   The following are recommendations relating to common activities for
   DNS service operators and in all cases data retention should be
   minimized or completely avoided if possible for DNS privacy services.
   If data is retained it should be encrypted and either aggregated,
   pseudonymized, or anonymized whenever possible.  In general the
   principle of data minimization described in [RFC6973] should be
   applied.

   o  Transient data (e.g., that is used for real time monitoring and
      threat analysis which might be held only in memory) should be
      retained for the shortest possible period deemed operationally
      feasible.

   o  The retention period of DNS traffic logs should be only those
      required to sustain operation of the service and, to the extent
      that such exists, meet regulatory requirements.

   o  DNS privacy services should not track users except for the
      particular purpose of detecting and remedying technically
      malicious (e.g., DoS) or anomalous use of the service.




Dickinson, et al.        Expires January 7, 2021               [Page 14]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  Data access should be minimized to only those personnel who
      require access to perform operational duties.  It should also be
      limited to anonymized or pseudonymized data where operationally
      feasible, with access to full logs (if any are held) only
      permitted when necessary.

   Optimizations:

   o  Consider use of full disk encryption for logs and data capture
      storage.

5.2.2.  Data minimization of network traffic

   Data minimization refers to collecting, using, disclosing, and
   storing the minimal data necessary to perform a task, and this can be
   achieved by removing or obfuscating privacy-sensitive information in
   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
   revealing other confidential information, for example on the
   structure of an internal corporate network.

   The problem of effectively ensuring that DNS traffic logs contain no
   or minimal privacy-sensitive information is not one that currently
   has a generally agreed solution or any standards to inform this
   discussion.  This section presents an overview of current techniques
   to simply provide reference on the current status of this work.

   Research into data minimization techniques (and particularly IP
   address pseudonymization/anonymization) was sparked in the late
   1990s/early 2000s, partly driven by the desire to share significant
   corpuses of traffic captures for research purposes.  Several
   techniques reflecting different requirements in this area and
   different performance/resource tradeoffs emerged over the course of
   the decade.  Developments over the last decade have been both a
   blessing and a curse; the large increase in size between an IPv4 and
   an IPv6 address, for example, renders some techniques impractical,
   but also makes available a much larger amount of input entropy, the
   better to resist brute force re-identification attacks that have
   grown in practicality over the period.

   Techniques employed may be broadly categorized as either
   anonymization or pseudonymization.  The following discussion uses the
   definitions from [RFC6973] Section 3, with additional observations
   from [van-Dijkhuizen-et-al.]

   o  Anonymization.  To enable anonymity of an individual, there must
      exist a set of individuals that appear to have the same




Dickinson, et al.        Expires January 7, 2021               [Page 15]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


      attribute(s) as the individual.  To the attacker or the observer,
      these individuals must appear indistinguishable from each other.

   o  Pseudonymization.  The true identity is deterministically replaced
      with an alternate identity (a pseudonym).  When the
      pseudonymization schema is known, the process can be reversed, so
      the original identity becomes known again.

   In practice there is a fine line between the two; for example, how to
   categorize a deterministic algorithm for data minimization of IP
   addresses that produces a group of pseudonyms for a single given
   address.

5.2.3.  IP address pseudonymization and anonymization methods

   A major privacy risk in DNS is connecting DNS queries to an
   individual and the major vector for this in DNS traffic is the client
   IP address.

   There is active discussion in the space of effective pseudonymization
   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
   use cases.  There are also as yet no standards for this that are
   unencumbered by patents.

   Appendix B provides a more detailed survey of various techniques
   employed or under development in 2019.

5.2.4.  Pseudonymization, anonymization, or discarding of other
        correlation data

   DNS Privacy Threats:

   o  Fingerprinting of the client OS via various means including: IP
      TTL/Hoplimit, TCP parameters (e.g., window size, ECN support,
      SACK), OS specific DNS query patterns (e.g., for network
      connectivity, captive portal detection, or OS specific updates).

   o  Fingerprinting of the client application or TLS library by, e.g.,
      HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS
      version/Cipher suite combinations, or other connection parameters.

   o  Correlation of queries on multiple TCP sessions originating from
      the same IP address.

   o  Correlating of queries on multiple TLS sessions originating from
      the same client, including via session resumption mechanisms.




Dickinson, et al.        Expires January 7, 2021               [Page 16]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  Resolvers _might_ receive client identifiers, e.g., MAC addresses
      in EDNS(0) options - some Customer-premises equipment (CPE)
      devices are known to add them [MAC-address-EDNS].

   Mitigations:

   o  Data minimization or discarding of such correlation data.

5.2.5.  Cache snooping

   [RFC6973] Threats:

   o  Surveillance:

      *  Profiling of client queries by malicious third parties.

   Mitigations:

   o  See [ISC-Knowledge-database-on-cache-snooping] for an example
      discussion on defending against cache snooping.

5.3.  Data sent onwards from the server

   In this section we consider both data sent on the wire in upstream
   queries and data shared with third parties.

5.3.1.  Protocol recommendations

   [RFC6973] Threats:

   o  Surveillance:

      *  Transmission of identifying data upstream.

   Mitigations:

   As specified in [RFC8310] for DoT but applicable to any DNS Privacy
   services the server should:

   o  Implement QNAME minimization [RFC7816].

   o  Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
      EDNS(0) Client Subnet (ECS) option ([RFC7871] Section 7.1.2).

   Optimizations:

   o  As per Section 2 of [RFC7871] the server should either:




Dickinson, et al.        Expires January 7, 2021               [Page 17]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


      *  not use the ECS option in upstream queries at all, or

      *  offer alternative services, one that sends ECS and one that
         does not.

   If operators do offer a service that sends the ECS options upstream
   they should use the shortest prefix that is operationally feasible
   and ideally use a policy of allowlisting upstream servers to send ECS
   to in order to reduce data leakage.  Operators should make clear in
   any policy statement what prefix length they actually send and the
   specific policy used.

   Allowlisting has the benefit that not only does the operator know
   which upstream servers can use ECS but also allows the operator to
   decide which upstream servers apply privacy policies that the
   operator is happy with.  However some operators consider allowlisting
   to incur significant operational overhead compared to dynamic
   detection of ECS support on authoritative servers.

   Additional options:

   o  Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
      (NXDOMAIN: There Really Is Nothing Underneath) to reduce the
      number of queries to authoritative servers to increase privacy.

   o  Run a copy of the root zone on loopback [RFC7706] to avoid making
      queries to the root servers that might leak information.

5.3.2.  Client query obfuscation

   Additional options:

   Since queries from recursive resolvers to authoritative servers are
   performed using cleartext (at the time of writing), resolver services
   need to consider the extent to which they may be directly leaking
   information about their client community via these upstream queries
   and what they can do to mitigate this further.  Note, that even when
   all the relevant techniques described above are employed there may
   still be attacks possible, e.g.  [Pitfalls-of-DNS-Encryption].  For
   example, a resolver with a very small community of users risks
   exposing data in this way and ought to obfuscate this traffic by
   mixing it with 'generated' traffic to make client characterization
   harder.  The resolver could also employ aggressive pre-fetch
   techniques as a further measure to counter traffic analysis.

   At the time of writing there are no standardized or widely recognized
   techniques to perform such obfuscation or bulk pre-fetches.




Dickinson, et al.        Expires January 7, 2021               [Page 18]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   Another technique that particularly small operators may consider is
   forwarding local traffic to a larger resolver (with a privacy policy
   that aligns with their own practices) over an encrypted protocol so
   that the upstream queries are obfuscated among those of the large
   resolver.

5.3.3.  Data sharing

   [RFC6973] Threats:

   o  Surveillance.

   o  Stored data compromise.

   o  Correlation.

   o  Identification.

   o  Secondary use.

   o  Disclosure.

   DNS Privacy Threats:

   o  Contravention of legal requirements not to process user data.

   Mitigations:

   Operators should not share identifiable data with third-parties.

   If operators choose to share identifiable data with third-parties in
   specific circumstance they should publish the terms under which data
   is shared.

   Operators should consider including specific guidelines for the
   collection of aggregated and/or anonymized data for research
   purposes, within or outside of their own organization.  This can
   benefit not only the operator (through inclusion in novel research)
   but also the wider Internet community.  See the policy published by
   SURFnet [SURFnet-policy] on data sharing for research as an example.

6.  Recursive operator Privacy Statement (RPS)

   To be compliant with this Best Common Practices document, a DNS
   recursive operator SHOULD publish a Recursive operator Privacy
   Statement (RPS).  Adopting the outline, and including the headings in
   the order provided, is a benefit to persons comparing RPSs from
   multiple operators.



Dickinson, et al.        Expires January 7, 2021               [Page 19]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   Appendix C provides a comparison of some existing policy and privacy
   statements.

6.1.  Outline of an RPS

   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 RPS 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
      an RPS.

   o  Is not intended to form the basis of any legal/compliance
      documentation.

   Appendix D provides an example (also non-normative) of an RPS
   statement for a specific operator scenario.

6.1.1.  Policy

   1.  Treatment of IP addresses.  Make an explicit statement that IP
       addresses are treated as personal data.

   2.  Data collection and sharing.  Specify clearly what data
       (including IP addresses) is:

       *  Collected and retained by the operator, and for what period it
          is retained.

       *  Shared with partners.

       *  Shared, sold, or rented to third-parties.

       and in each case whether it is aggregated, pseudonymized, or
       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,
       technically malicious or anomalous behavior.

   4.  Associated entities.  Declare and explicitly enumerate any
       partners, third-party affiliations, or sources of funding.





Dickinson, et al.        Expires January 7, 2021               [Page 20]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   5.  Correlation.  Whether user DNS data is correlated or combined
       with any other personal information held by the operator.

   6.  Result filtering.  This section should explain whether the
       operator filters, edits or alters in any way the replies that it
       receives from the authoritative servers for each DNS zone, before
       forwarding them to the clients.  For each category listed below,
       the operator should also specify how the filtering lists are
       created and managed, whether it employs any third-party sources
       for such lists, and which ones.

       *  Specify if any replies are being filtered out or altered for
          network and computer security reasons (e.g., preventing
          connections to malware-spreading websites or botnet control
          servers).

       *  Specify if any replies are being filtered out or altered for
          mandatory legal reasons, due to applicable legislation or
          binding orders by courts and other public authorities.

       *  Specify if any replies are being filtered out or altered for
          voluntary legal reasons, due to an internal policy by the
          operator aiming at reducing potential legal risks.

       *  Specify if any replies are being filtered out or altered for
          any other reason, including commercial ones.

6.1.2.  Practice

   [NOTE FOR RFC EDITOR: Please update this section to use letters for
   the sub-bullet points instead of numbers.  This was not done during
   review because the markdown tool used to write the document did not
   support it.]

   Communicate the current operational practices of the service.

   1.  Deviations.  Specify any temporary or permanent deviations from
       the policy for operational reasons.

   2.  Client facing capabilities.  With reference to each subsection of
       Section 5.1 provide specific details of which capabilities
       (transport, DNSSEC, padding, etc.) are provided on which client
       facing addresses/port combination or DoH URI template.  For
       Section 5.1.2, clearly specify which specific authentication
       mechanisms are supported for each endpoint that offers DoT:

       1.  The authentication domain name to be used (if any).




Dickinson, et al.        Expires January 7, 2021               [Page 21]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


       2.  The SPKI pin sets to be used (if any) and policy for rolling
           keys.

   3.  Upstream capabilities.  With reference to section Section 5.3
       provide specific details of which capabilities are provided
       upstream for data sent to authoritative servers.

   4.  Support.  Provide contact/support information for the service.

   5.  Data Processing.  This section can optionally communicate links
       to and the high level contents of any separate statements the
       operator has published which cover applicable data processing
       legislation or agreements with regard to the location(s) of
       service provision.

6.2.  Enforcement/accountability

   Transparency reports may help with building user trust that operators
   adhere to their policies and practices.

   Independent monitoring or analysis could be performed where possible
   of:

   o  ECS, QNAME minimization, EDNS(0) padding, etc.

   o  Filtering.

   o  Uptime.

   This is by analogy with several TLS or website analysis tools that
   are currently available e.g., [SSL-Labs] or [Internet.nl].

   Additionally operators could choose to engage the services of a third
   party auditor to verify their compliance with their published RPS.

7.  IANA considerations

   None

8.  Security considerations

   Security considerations for DNS-over-TCP are given in [RFC7766], many
   of which are generally applicable to session based DNS.  Guidance on
   operational requirements for DNS-over-TCP are also available in [I-
   D.dnsop-dns-tcp-requirements].  Security considerations for DoT are
   given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].





Dickinson, et al.        Expires January 7, 2021               [Page 22]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   Security considerations for DNSSEC are given in [RFC4033], [RFC4034]
   and [RFC4035].

9.  Acknowledgements

   Many thanks to Amelia Andersdotter for a very thorough review of the
   first draft of this document and Stephen Farrell for a thorough
   review at WGLC and for suggesting the inclusion of an example RPS.
   Thanks to John Todd for discussions on this topic, and to Stephane
   Bortzmeyer, Puneet Sood and Vittorio Bertola for review.  Thanks to
   Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Jon Reed,
   Lorenzo Colitti for comments at the mic.  Thanks to Loganaden
   Velvindron for useful updates to the text.

   Sara Dickinson thanks the Open Technology Fund for a grant to support
   the work on this document.

10.  Contributors

   The below individuals contributed significantly to the document:

   John Dickinson
   Sinodun Internet Technologies
   Magdalen Centre
   Oxford Science Park
   Oxford OX4 4GA
   United Kingdom

   Jim Hague
   Sinodun Internet Technologies
   Magdalen Centre
   Oxford Science Park
   Oxford OX4 4GA
   United Kingdom

11.  Changelog

   draft-ietf-dprive-bcp-op-12

   o  Change DROP to RPS throughout

   draft-ietf-dprive-bcp-op-11

   o  Improve text around use of normative language

   o  Fix section 5.1.3.2 bullets

   o  Improve text in 6.1.2. item 2.



Dickinson, et al.        Expires January 7, 2021               [Page 23]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  Rework text of 6.1.2. item 5 and update example DROP

   o  Various editorial improvements

   draft-ietf-dprive-bcp-op-10

   o  Remove direct references to draft-ietf-dprive-rfc7626-bis, instead
      have one general reference RFC7626

   o  Clarify that the DROP statement outline is non-normative and add
      some further qualifications about content

   o  Update wording on data sharing to remove explicit discussion of
      consent

   o  Move table in section 5.2.3 to an appendix

   o  Move section 6.2 to an appendix

   o  Corrections to references, typos and editorial updates from
      initial IESG comments.

   draft-ietf-dprive-bcp-op-09

   o  Fix references so they match the correct section numbers in draft-
      ietf-dprive-rfc7626-bis-05

   draft-ietf-dprive-bcp-op-08

   o  Address IETF Last call comments.

   draft-ietf-dprive-bcp-op-07

   o  Editorial changes following AD review.

   o  Change all URIs to Informational References.

   draft-ietf-dprive-bcp-op-06

   o  Final minor changes from second WGLC.

   draft-ietf-dprive-bcp-op-05

   o  Remove some text on consent:

      *  Paragraph 2 in section 5.3.3

      *  Item 6 in the DROP Practice statement (and example)



Dickinson, et al.        Expires January 7, 2021               [Page 24]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  Remove .onion and TLSA options

   o  Include ACME as a reference for certificate management

   o  Update text on session resumption usage

   o  Update section 5.2.4 on client fingerprinting

   draft-ietf-dprive-bcp-op-04

   o  Change DPPPS to DROP (DNS Recursive Operator Privacy) statement

   o  Update structure of DROP slightly

   o  Add example DROP statement

   o  Add text about restricting access to full logs

   o  Move table in section 5.2.3 from SVG to inline table

   o  Fix many editorial and reference nits

   draft-ietf-dprive-bcp-op-03

   o  Add paragraph about operational impact

   o  Move DNSSEC requirement out of the Appendix into main text as a
      privacy threat that should be mitigated

   o  Add TLS version/Cipher suite as tracking threat

   o  Add reference to Mozilla TRR policy

   o  Remove several TODOs and QUESTIONS.

   draft-ietf-dprive-bcp-op-02

   o  Change 'open resolver' for 'public resolver'

   o  Minor editorial changes

   o  Remove recommendation to run a separate TLS 1.3 service

   o  Move TLSA to purely a optimization in Section 5.2.1

   o  Update reference on minimal DoH headers.





Dickinson, et al.        Expires January 7, 2021               [Page 25]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  Add reference on user switching provider after service issues in
      Section 5.1.4

   o  Add text in Section 5.1.6 on impact on operators.

   o  Add text on additional threat to TLS proxy use (Section 5.1.7)

   o  Add reference in Section 5.3.1 on example policies.

   draft-ietf-dprive-bcp-op-01

   o  Many minor editorial fixes

   o  Update DoH reference to RFC8484 and add more text on DoH

   o  Split threat descriptions into ones directly referencing RFC6973
      and other DNS Privacy threats

   o  Improve threat descriptions throughout

   o  Remove reference to the DNSSEC TLS Chain Extension draft until new
      version submitted.

   o  Clarify use of allowlisting for ECS

   o  Re-structure the DPPPS, add Result filtering section.

   o  Remove the direct inclusion of privacy policy comparison, now just
      reference dnsprivacy.org and an example of such work.

   o  Add an appendix briefly discussing DNSSEC

   o  Update affiliation of 1 author

   draft-ietf-dprive-bcp-op-00

   o  Initial commit of re-named document after adoption to replace
      draft-dickinson-dprive-bcp-op-01

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.




Dickinson, et al.        Expires January 7, 2021               [Page 26]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   [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>.

   [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.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
              editor.org/info/rfc6973>.

   [RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
              Known Attacks on Transport Layer Security (TLS) and
              Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
              February 2015, <https://www.rfc-editor.org/info/rfc7457>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC7706]  Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
              Servers by Running One on Loopback", RFC 7706,
              DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
              editor.org/info/rfc7706>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/info/rfc7766>.

   [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve
              Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
              <https://www.rfc-editor.org/info/rfc7816>.

   [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
              edns-tcp-keepalive EDNS0 Option", RFC 7828,
              DOI 10.17487/RFC7828, April 2016, <https://www.rfc-
              editor.org/info/rfc7828>.





Dickinson, et al.        Expires January 7, 2021               [Page 27]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
              editor.org/info/rfc7830>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              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>.

   [RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
              Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
              November 2016, <https://www.rfc-editor.org/info/rfc8020>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
              DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
              July 2017, <https://www.rfc-editor.org/info/rfc8198>.

   [RFC8310]  Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
              for DNS over TLS and DNS over DTLS", RFC 8310,
              DOI 10.17487/RFC8310, March 2018, <https://www.rfc-
              editor.org/info/rfc8310>.

   [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
              for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
              October 2018, <https://www.rfc-editor.org/info/rfc8467>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
              Lemon, T., and T. Pusateri, "DNS Stateful Operations",
              RFC 8490, DOI 10.17487/RFC8490, March 2019,
              <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>.




Dickinson, et al.        Expires January 7, 2021               [Page 28]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


12.2.  Informative References

   [Bloom-filter]
              van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
              Allodi, "Privacy-Conscious Threat Intelligence Using
              DNSBLOOM", 2019,
              <http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.

   [Brenker-and-Arnes]
              Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS
              PSEUDONYMIZATION", 2005, <https://pdfs.semanticscholar.org
              /7b34/12c951cebe71cd2cddac5fda164fb2138a44.pdf>.

   [Crypto-PAn]
              CESNET, "Crypto-PAn", 2015,
              <https://github.com/CESNET/ipfixcol/tree/master/base/src/
              intermediate/anonymization/Crypto-PAn>.

   [DNS-Privacy-not-so-private]
              Silby, S., Juarez, M., Vallina-Rodriguez, N., and C.
              Troncosol, "DNS Privacy not so private: the traffic
              analysis perspective.", 2019,
              <https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.

   [dnsdist]  PowerDNS, "dnsdist Overview", 2019, <https://dnsdist.org>.

   [dnstap]   dnstap.info, "DNSTAP", 2019, <http://dnstap.info>.

   [DoH-resolver-policy]
              Mozilla, "Security/DOH-resolver-policy", 2019,
              <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]
              Conversion Works, "Anonymize IP Geolocation Accuracy
              Impact Assessment", 2017,
              <https://support.google.com/analytics/
              answer/2763052?hl=en>.

   [haproxy]  haproxy.org, "HAPROXY", 2019, <https://www.haproxy.org/>.






Dickinson, et al.        Expires January 7, 2021               [Page 29]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   [Harvan]   Harvan, M., "Prefix- and Lexicographical-order-preserving
              IP Address Anonymization", 2006,
              <http://mharvan.net/talks/noms-ip_anon.pdf>.

   [I-D.bellis-dnsop-xpf]
              Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",
              draft-bellis-dnsop-xpf-04 (work in progress), March 2018.

   [I-D.ietf-dnsop-dns-tcp-requirements]
              Kristoff, J. and D. Wessels, "DNS Transport over TCP -
              Operational Requirements", draft-ietf-dnsop-dns-tcp-
              requirements-06 (work in progress), May 2020.

   [I-D.ietf-httpbis-bcp56bis]
              Nottingham, M., "Building Protocols with HTTP", draft-
              ietf-httpbis-bcp56bis-09 (work in progress), November
              2019.

   [Internet.nl]
              Internet.nl, "Internet.nl Is Your Internet Up To Date?",
              2019, <https://internet.nl>.

   [IP-Anonymization-in-Analytics]
              Google, "IP Anonymization in Analytics", 2019,
              <https://support.google.com/analytics/
              answer/2763052?hl=en>.

   [ipcipher1]
              Hubert, B., "On IP address encryption: security analysis
              with respect for privacy", 2017,
              <https://medium.com/@bert.hubert/on-ip-address-encryption-
              security-analysis-with-respect-for-privacy-dabe1201b476>.

   [ipcipher2]
              PowerDNS, "ipcipher", 2017, <https://github.com/PowerDNS/
              ipcipher>.

   [ipcrypt]  veorq, "ipcrypt: IP-format-preserving encryption", 2015,
              <https://github.com/veorq/ipcrypt>.

   [ipcrypt-analysis]
              Aumasson, J., "Analysis of ipcrypt?", 2018,
              <https://www.ietf.org/mail-archive/web/cfrg/current/
              msg09494.html>.

   [ISC-Knowledge-database-on-cache-snooping]
              ISC Knowledge Database, "DNS Cache snooping - should I be
              concerned?", 2018, <https://kb.isc.org/docs/aa-00482>.



Dickinson, et al.        Expires January 7, 2021               [Page 30]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   [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/>.

   [Passive-Observations-of-a-Large-DNS]
              de Vries, W., van Rijswijk-Deij, R., de Boer, P., and A.
              Pras, "Passive Observations of a Large DNS Service: 2.5
              Years in the Life of Google", 2018,
              <http://tma.ifip.org/2018/wp-
              content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.

   [pcap]     tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.

   [Pitfalls-of-DNS-Encryption]
              Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
              Encryption", 2014, <https://dl.acm.org/
              citation.cfm?id=2665959>.

   [policy-comparison]
              dnsprivacy.org, "Comparison of policy and privacy
              statements 2019", 2019,
              <https://dnsprivacy.org/wiki/display/DP/
              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, R. and T. Wolf, "High-Speed Prefix-Preserving
              IP Address Anonymization for Passive Measurement Systems",
              2007,
              <http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.



Dickinson, et al.        Expires January 7, 2021               [Page 31]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <https://www.rfc-editor.org/info/rfc5077>.

   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
              Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
              <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>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
              editor.org/info/rfc7626>.

   [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>.

   [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
              Transport Layer Security (DTLS)", RFC 8094,
              DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
              editor.org/info/rfc8094>.

   [RFC8404]  Moriarty, K., Ed. and A. Morton, Ed., "Effects of
              Pervasive Encryption on Operators", RFC 8404,
              DOI 10.17487/RFC8404, July 2018, <https://www.rfc-
              editor.org/info/rfc8404>.

   [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>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.







Dickinson, et al.        Expires January 7, 2021               [Page 32]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   [RFC8618]  Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
              and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
              Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
              2019, <https://www.rfc-editor.org/info/rfc8618>.

   [SSL-Labs]
              SSL Labs, "SSL Server Test", 2019,
              <https://www.ssllabs.com/ssltest/>.

   [stunnel]  ISC Knowledge Database, "DNS-over-TLS", 2018,
              <https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.

   [SURFnet-policy]
              SURFnet, "SURFnet Data Sharing Policy", 2016,
              <https://surf.nl/datasharing>.

   [TCPdpriv]
              Ipsilon Networks, Inc., "TCPdpriv", 2005,
              <http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html>.

   [van-Dijkhuizen-et-al.]
              Van Dijkhuizen , N. and J. Van Der Ham, "A Survey of
              Network Traffic Anonymisation Techniques and
              Implementations", 2018, <https://doi.org/10.1145/3182660>.

   [Xu-et-al.]
              Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-
              preserving IP address anonymization: measurement-based
              security evaluation and a new cryptography-based scheme",
              2004, <http://an.kaist.ac.kr/~sbmoon/paper/
              intl-journal/2004-cn-anon.pdf>.

Appendix A.  Documents

   This section provides an overview of some DNS privacy-related
   documents, however, this is neither an exhaustive list nor a
   definitive statement on the characteristic of the document.

A.1.  Potential increases in DNS privacy

   These documents are limited in scope to communications between stub
   clients and recursive resolvers:

   o  'Specification for DNS over Transport Layer Security (TLS)'
      [RFC7858].

   o  'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094].
      Note that this document has the Category of Experimental.



Dickinson, et al.        Expires January 7, 2021               [Page 33]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  'DNS Queries over HTTPS (DoH)' [RFC8484].

   o  'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310].

   o  'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for
      EDNS(0)' [RFC8467].

   These documents apply to recursive and authoritative DNS but are
   relevant when considering the operation of a recursive server:

   o  'DNS Query Name minimization to Improve Privacy' [RFC7816].

A.2.  Potential decreases in DNS privacy

   These documents relate to functionality that could provide increased
   tracking of user activity as a side effect:

   o  'Client Subnet in DNS Queries' [RFC7871].

   o  'Domain Name System (DNS) Cookies' [RFC7873]).

   o  'Transport Layer Security (TLS) Session Resumption without Server-
      Side State' [RFC5077] referred to here as simply TLS session
      resumption.

   o  [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS
      1.3

   o  'A DNS Packet Capture Format' [RFC8618].

   o  Passive DNS [RFC8499].

   o  Section 8 of [RFC8484] outlines the privacy considerations of DoH.
      Note that (while that document advises exposing the minimal set of
      data needed to achieve the desired feature set) 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

   o  'DNS Transport over TCP - Implementation Requirements' [RFC7766].

   o  'Operational requirements for DNS-over-TCP'
      [I-D.ietf-dnsop-dns-tcp-requirements].

   o  'The edns-tcp-keepalive EDNS0 Option' [RFC7828].

   o  'DNS Stateful Operations' [RFC8490].



Dickinson, et al.        Expires January 7, 2021               [Page 34]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


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, if an
   attacker can

   o  ensure packets are captured by the target and



Dickinson, et al.        Expires January 7, 2021               [Page 35]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   o  send forged traffic with arbitrary source and destination
      addresses to that target and

   o  obtain a de-identified log of said traffic from 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
   and the properties of their outputs.  The following builds on the
   categorization employed in [RFC6235]:

   o  Format-preserving.  Normally when encrypting, the original data
      length and patterns in the data should be hidden from an attacker.
      Some applications of de-identification, such as network capture
      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
      the same way as the original.

   o  Prefix preservation.  Values such as IP addresses and MAC
      addresses contain prefix information that can be valuable in
      analysis, e.g., manufacturer ID in MAC addresses, subnet in IP
      addresses.  Prefix preservation ensures that prefixes are de-
      identified consistently; e.g., if two IP addresses are from the
      same subnet, a prefix preserving de-identification will ensure
      that their de-identified counterparts will also share a subnet.
      Prefix preservation may be fixed (i.e. based on a user selected
      prefix length identified in advance to be preserved ) or general.

   o  Replacement.  A one-to-one replacement of a field to a new value
      of the same type, for example, using a regular expression.

   o  Filtering.  Removing or replacing data in a field.  Field data can
      be overwritten, often with zeros, either partially (truncation or
      reverse truncation) or completely (black-marker anonymization).

   o  Generalization.  Data is replaced by more general data with
      reduced specificity.  One example would be to replace all TCP/UDP
      port numbers with one of two fixed values indicating whether the
      original port was ephemeral (>=1024) or non-ephemeral (>1024).
      Another example, precision degradation, reduces the accuracy of
      e.g., a numeric value or a timestamp.

   o  Enumeration.  With data from a well-ordered set, replace the first
      data item data using a random initial value and then allocate
      ordered values for subsequent data items.  When used with



Dickinson, et al.        Expires January 7, 2021               [Page 36]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


      timestamp data, this preserves ordering but loses precision and
      distance.

   o  Reordering/shuffling.  Preserving the original data, but
      rearranging its order, often in a random manner.

   o  Random substitution.  As replacement, but using randomly generated
      replacement values.

   o  Cryptographic permutation.  Using a permutation function, such as
      a hash function or cryptographic block cipher, to generate a
      replacement de-identified value.

B.2.  Specific techniques

B.2.1.  Google Analytics non-prefix filtering

   Since May 2010, Google Analytics has provided a facility
   [IP-Anonymization-in-Analytics] that allows website owners to request
   that all their users IP addresses are anonymized within Google
   Analytics processing.  This very basic anonymization simply sets to
   zero the least significant 8 bits of IPv4 addresses, and the least
   significant 80 bits of IPv6 addresses.  The level of anonymization
   this produces is perhaps questionable.  There are some analysis
   results [Geolocation-Impact-Assessement] which suggest that the
   impact of this on reducing the accuracy of determining the user's
   location from their IP address is less than might be hoped; the
   average discrepancy in identification of the user city for UK users
   is no more than 17%.

   Anonymization: Format-preserving, Filtering (trucation).

B.2.2.  dnswasher

   Since 2006, PowerDNS have included a de-identification tool dnswasher
   [PowerDNS-dnswasher] with their PowerDNS product.  This is a PCAP
   filter that performs a one-to-one mapping of end user IP addresses
   with an anonymized address.  A table of user IP addresses and their
   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-
   identified address therefore depends on the order that addresses
   arrive in the input, and running over a large amount of data the
   address translation tables can grow to a significant size.

   Anonymization: Format-preserving, Enumeration.






Dickinson, et al.        Expires January 7, 2021               [Page 37]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


B.2.3.  Prefix-preserving map

   Used in [TCPdpriv], this algorithm stores a set of original and
   anonymised IP address pairs.  When a new IP address arrives, it is
   compared with previous addresses to determine the longest prefix
   match.  The new address is anonymized by using the same prefix, with
   the remainder of the address anonymized with a random value.  The use
   of a random value means that TCPdrpiv is not deterministic; different
   anonymized values will be generated on each run.  The need to store
   previous addresses means that TCPdpriv has significant and unbounded
   memory requirements, and because of the need to allocated anonymized
   addresses sequentially cannot be used in parallel processing.

   Anonymization: Format-preserving, prefix preservation (general).

B.2.4.  Cryptographic Prefix-Preserving Pseudonymization

   Cryptographic prefix-preserving pseudonymization was originally
   proposed as an improvement to the prefix-preserving map implemented
   in TCPdpriv, described in [Xu-et-al.] and implemented in the
   [Crypto-PAn] tool.  Crypto-PAn is now frequently used as an acronym
   for the algorithm.  Initially it was described for IPv4 addresses
   only; extension for IPv6 addresses was proposed in [Harvan].  This
   uses a cryptographic algorithm rather than a random value, and thus
   pseudonymity is determined uniquely by the encryption key, and is
   deterministic.  It requires a separate AES encryption for each output
   bit, so has a non-trivial calculation overhead.  This can be
   mitigated to some extent (for IPv4, at least) by pre-calculating
   results for some number of prefix bits.

   Pseudonymization: Format-preserving, prefix preservation (general).

B.2.5.  Top-hash Subtree-replicated Anonymization

   Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated
   Anonymization (TSA) originated in response to the requirement for
   faster processing than Crypto-PAn.  It used hashing for the most
   significant byte of an IPv4 address, and a pre-calculated binary tree
   structure for the remainder of the address.  To save memory space,
   replication is used within the tree structure, reducing the size of
   the pre-calculated structures to a few Mb for IPv4 addresses.
   Address pseudonymization is done via hash and table lookup, and so
   requires minimal computation.  However, due to the much increased
   address space for IPv6, TSA is not memory efficient for IPv6.

   Pseudonymization: Format-preserving, prefix preservation (general).





Dickinson, et al.        Expires January 7, 2021               [Page 38]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


B.2.6.  ipcipher

   A recently-released proposal from PowerDNS, ipcipher [ipcipher1]
   [ipcipher2]  is a simple pseudonymization technique for IPv4 and IPv6
   addresses.  IPv6 addresses are encrypted directly with AES-128 using
   a key (which may be derived from a passphrase).  IPv4 addresses are
   similarly encrypted, but using a recently proposed encryption
   [ipcrypt] suitable for 32bit block lengths.  However, the author of
   ipcrypt has since indicated [ipcrypt-analysis] that it has low
   security, and further analysis has revealed it is vulnerable to
   attack.

   Pseudonymization: Format-preserving, cryptographic permutation.

B.2.7.  Bloom filters

   van Rijswijk-Deij et al.  have recently described work using Bloom
   filters [Bloom-filter] to categorize query traffic and record the
   traffic as the state of multiple filters.  The goal of this work is
   to allow operators to identify so-called Indicators of Compromise
   (IOCs) originating from specific subnets without storing information
   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
   probability if, for example, a particular query was made, but the set
   of queries made cannot be recovered from the filter.  Similarly, by
   mixing queries from a sufficient number of users in a single filter,
   it becomes practically impossible to determine if a particular user
   performed a particular query.  Large numbers of queries can be
   tracked in a memory-efficient way.  As filter status is stored, this
   approach cannot be used to regenerate traffic, and so cannot be used
   with tools used to process live traffic.

   Anonymized: Generalization.

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 RPS
   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.





Dickinson, et al.        Expires January 7, 2021               [Page 39]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


   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 RPS

   The following example RPS is very loosely based on some elements of
   published privacy statements for some public resolvers, with
   additional fields populated to illustrate the what the full contents
   of an RPS might look like.  This should not be interpreted as

   o  having been reviewed or approved by any operator in any way

   o  having any legal standing or validity at all

   o  being complete or exhaustive

   This is a purely hypothetical example of an RPS to outline example
   contents - in this case for a public resolver operator providing a
   basic DNS Privacy service via one IP address and one DoH URI with
   security based filtering.  It does aim to meet minimal compliance as
   specified in Section 5.

D.1.  Policy

   1.  Treatment of IP addresses.  Many nations classify IP addresses as
       personal data, and we take a conservative approach in treating IP
       addresses as personal data in all jurisdictions in which our
       systems reside.

   2.  Data collection and sharing.

       1.  IP addresses.  Our normal course of data management does not
           have any IP address information or other personal data logged
           to disk or transmitted out of the location in which the query
           was received.  We may aggregate certain counters to larger
           network block levels for statistical collection purposes, but
           those counters do not maintain specific IP address data nor
           is the format or model of data stored capable of being
           reverse-engineered to ascertain what specific IP addresses
           made what queries.

       2.  Data collected in logs.  We do keep some generalized location
           information (at the city/metropolitan area level) so that we
           can conduct debugging and analyze abuse phenomena.  We also
           use the collected information for the creation and sharing of



Dickinson, et al.        Expires January 7, 2021               [Page 40]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


           telemetry (timestamp, geolocation, number of hits, first
           seen, last seen) for contributors, public publishing of
           general statistics of system use (protections, threat types,
           counts, etc.)  When you use our DNS Services, here is the
           full list of items that are included in our logs:

           +  Request domain name, e.g., example.net

           +  Record type of requested domain, e.g., A, AAAA, NS, MX,
              TXT, etc.

           +  Transport protocol on which the request arrived, i.e. UDP,
              TCP, DoT,
              DoH

           +  Origin IP general geolocation information: i.e. geocode,
              region ID, city ID, and metro code

           +  IP protocol version - IPv4 or IPv6

           +  Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN,
              etc.

           +  Absolute arrival time using a precision in ms

           +  Name of the specific instance that processed this request

           +  IP address of the specific instance to which this request
              was addressed (no relation to the requestor's IP address)

           We may keep the following data as summary information,
           including all the above EXCEPT for data about the DNS record
           requested:

           +  Currently-advertised BGP-summarized IP prefix/netmask of
              apparent client origin

           +  Autonomous system number (BGP ASN) of apparent client
              origin

           All the above data may be kept in full or partial form in
           permanent archives.

       3.  Sharing of data.  Except as described in this document, we do
           not intentionally share, sell, or rent individual personal
           information associated with the requestor (i.e. source IP
           address or any other information that can positively identify
           the client using our infrastructure) with anyone without your



Dickinson, et al.        Expires January 7, 2021               [Page 41]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


           consent.  We generate and share high level anonymized
           aggregate statistics including threat metrics on threat type,
           geolocation, and if available, sector, as well as other
           vertical metrics including performance metrics on our DNS
           Services (i.e. number of threats blocked, infrastructure
           uptime) when available with our threat intelligence (TI)
           partners, academic researchers, or the public.  Our DNS
           Services share anonymized data on specific domains queried
           (records such as domain, timestamp, geolocation, number of
           hits, first seen, last seen) with our threat intelligence
           partners.  Our DNS Services also builds, stores, and may
           share certain DNS data streams which store high level
           information about domain resolved, query types, result codes,
           and timestamp.  These streams do not contain IP address
           information of requestor and cannot be correlated to IP
           address or other personal data.  We do not and never will
           share any of its data with marketers, nor will it use this
           data for demographic analysis.

   3.  Exceptions.  There are exceptions to this storage model: In the
       event of actions or observed behaviors which we deem malicious or
       anomalous, we may utilize more detailed logging to collect more
       specific IP address data in the process of normal network defence
       and mitigation.  This collection and transmission off-site will
       be limited to IP addresses that we determine are involved in the
       event.

   4.  Associated entities.  Details of our Threat Intelligence partners
       can be found at our website page (insert link).

   5.  Correlation of Data.  We do not correlate or combine information
       from our logs with any personal information that you have
       provided us for other services, or with your specific IP address.

   6.  Result filtering.

       1.  Filtering.  We utilise cyber threat intelligence about
           malicious domains from a variety of public and private
           sources and blocks access to those malicious domains when
           your system attempts to contact them.  An NXDOMAIN is
           returned for blocked sites.

           1.  Censorship.  We will not provide a censoring component
               and will limit our actions solely to the blocking of
               malicious domains around phishing, malware, and exploit
               kit domains.





Dickinson, et al.        Expires January 7, 2021               [Page 42]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


           2.  Accidental blocking.  We implement allowlisting
               algorithms to make sure legitimate domains are not
               blocked by accident.  However, in the rare case of
               blocking a legitimate domain, we work with the users to
               quickly allowlist that domain.  Please use our support
               form (insert link) if you believe we are blocking a
               domain in error.

D.2.  Practice

   1.  Deviations from Policy.  None in place since (insert date).

   2.  Client facing capabilities.

       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
           address).  It is available on port 853 and port 443.  We also
           implement RFC7766.

           1.  The DoT authentication domain name used is (insert domain
               name).

           2.  We do not publish SPKI pin sets.

       3.  We offer DNS over HTTPS as specified in RFC8484 on (insert
           URI template).  Both POST and GET are supported.

       4.  Both services offer TLS 1.2 and TLS 1.3.

       5.  Both services pad DNS responses according to RFC8467.

       6.  Both services provide DNSSEC validation.

   3.  Upstream capabilities.

       1.  Our servers implement QNAME minimization.

       2.  Our servers do not send ECS upstream.

   4.  Support.  Support information for this service is available at
       (insert link).

   5.  Data Processing.  We operate as the legal entity (insert entity)
       registered in (insert country); as such we operate under (insert
       country/region) law.  Our separate statement regarding the
       specifics of our data processing policy, practice, and agreements
       can be found here (insert link).



Dickinson, et al.        Expires January 7, 2021               [Page 43]

Internet-Draft     DNS Privacy Service Recommendations         July 2020


Authors' Addresses

   Sara Dickinson
   Sinodun IT
   Magdalen Centre
   Oxford Science Park
   Oxford  OX4 4GA
   United Kingdom

   Email: sara@sinodun.com


   Benno J. Overeinder
   NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands

   Email: benno@nlnetLabs.nl


   Roland M. van Rijswijk-Deij
   NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands

   Email: roland@nlnetLabs.nl


   Allison Mankin
   Salesforce

   Email: allison.mankin@gmail.com

















Dickinson, et al.        Expires January 7, 2021               [Page 44]