Sinodun IT

Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom sara@sinodun.com

NLnet Labs

Science Park 400 Amsterdam 1098 XH Netherlands benno@nlnetLabs.nl

NLnet Labs

Science Park 400 Amsterdam 1098 XH Netherlands roland@nlnetLabs.nl

Salesforce.com, Inc.

Salesforce Tower 415 Mission Street, 3rd Floor San Francisco CA 94105 United States of America allison.mankin@gmail.com

Internet dprive DNS 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, as well as understanding how those decisions and the 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 RFC 6841.

Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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

• .  Introduction
• .  Scope
• .  Privacy-Related Documents
• .  Terminology
• .  Recommendations for DNS Privacy Services
  • .  On the Wire between Client and Server
    • .  Transport Recommendations
    • .  Authentication of DNS Privacy Services
    • .  Protocol Recommendations
    • .  DNSSEC
    • .  Availability
    • .  Service Options
    • .  Impact of Encryption on Monitoring by DNS Privacy Service Operators
    • .  Limitations of Fronting a DNS Privacy Service with a Pure TLS Proxy
  • .  Data at Rest on the Server
    • .  Data Handling
    • .  Data Minimization of Network Traffic
    • .  IP Address Pseudonymization and Anonymization Methods
    • .  Pseudonymization, Anonymization, or Discarding of Other Correlation Data
    • .  Cache Snooping
  • .  Data Sent Onwards from the Server
    • .  Protocol Recommendations
    • .  Client Query Obfuscation
    • .  Data Sharing
• .  Recursive Operator Privacy Statement (RPS)
  • .  Outline of an RPS
    • .  Policy
    • .  Practice
  • .  Enforcement/Accountability
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Documents
  • .  Potential Increases in DNS Privacy
  • .  Potential Decreases in DNS Privacy
  • .  Related Operational Documents
• .  IP Address Techniques
  • .  Categorization of Techniques
  • .  Specific Techniques
    • .  Google Analytics Non-Prefix Filtering
    • .  dnswasher
    • .  Prefix-Preserving Map
    • .  Cryptographic Prefix-Preserving Pseudonymization
    • .  Top-Hash Subtree-Replicated Anonymization
    • .  ipcipher
    • .  Bloom Filters
• .  Current Policy and Privacy Statements
• .  Example RPS
  • .  Policy
  • .  Practice
• Acknowledgements
• Contributors
• Authors' Addresses

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 that aim to increase the privacy of the DNS, 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" , 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 public 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 (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 there are both advantages and disadvantages to a user choosing to configure a single resolver (or a fixed set of resolvers) and an encrypted transport to use in all network environments. 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 for tracking 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 describes some mitigations of data-sharing risk. This document has two main goals:

• 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.
• 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 that 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 of an RPS.

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 factors -- e.g., differing security policies or minor differences 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.

Scope "DNS Privacy Considerations" describes the general privacy issues and threats associated with the use of the DNS by Internet users; much of the threat analysis here is lifted from that document and . 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.

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 that 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 is listed in for reference.

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 when, and only when, they appear in all capitals, as shown here. DNS terminology is as described in , except with regard to the definition of privacy-enabling DNS server in . In this document we use the full definition of a DNS over (D)TLS privacy-enabling DNS server as given in , i.e., that such a server should also offer at least one of the credentials described in and implement the (D)TLS profile described in . Other Terms:

RPS:

Recursive operator Privacy Statement; see .

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.

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:

• Threats described in , "Privacy Considerations for Internet Protocols"
  • Privacy terminology, threats to privacy, and mitigations as described in Sections , , and of .
• DNS Privacy Threats
  • These are threats to the users and operators of DNS privacy services that are not directly covered by . 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:

• Threat mitigation for well-understood and documented privacy threats to the users of the service and, in some cases, the operators of the service.
• Optimization of privacy services from an operational or management perspective.
• 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:

• Threat mitigations to be minimally compliant.
• Optimizations to be moderately compliant.
• 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 that correspond to the three named levels of compliance stated above. However, compliance (to the indicated level) remains a normative requirement.

On the Wire between Client and Server In this section, we consider both data on the wire and the service provided to the client.

Transport Recommendations

Threats described in :

Surveillance:

Passive surveillance of traffic on the wire.

DNS Privacy Threats:

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:

• DNS over TLS (DoT) .
• DNS over HTTPS (DoH) .

It is noted that a DNS privacy service can also be provided over DNS over DTLS ; 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 DNSCrypt , IPsec, 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 on the paths traversed by the encrypted connection, this does not diminish the need for DNSSEC; see .

Authentication of DNS Privacy Services

Threats described in :

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 (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 DoT need to provide credentials that will be accepted by the client's trust model, in the form of either X.509 certificates or Subject Public Key Info (SPKI) pin sets . When offering DoH , HTTPS requires authentication of the server as part of the protocol.

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 service, as management of such credentials is new to those DNS operators. It is noted that SPKI pin set management is described in 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:

• Invalid certificates, resulting in an unavailable service, which might force a user to fall back to cleartext.
• Misidentification of a server by a client -- e.g., typos in DoH URL templates or authentication domain names that accidentally direct clients to attacker-controlled servers.

Mitigations:

It is recommended that operators:

• Follow the guidance in with regard to certificate revocation.
• Automate the generation, publication, and renewal of certificates. For example, Automatic Certificate Management Environment (ACME) provides a mechanism to actively manage certificates through automation and has been implemented by a number of certificate authorities.
• Monitor certificates to prevent accidental expiration of certificates.
• Choose a short, memorable authentication domain name for the service.

Protocol Recommendations

DoT

DNS Privacy Threats:

• Known attacks on TLS, such as those described in .
• Traffic analysis, for example: (focused on DoT).
• Potential for client tracking via transport identifiers.
• Blocking of well-known ports (e.g., 853 for DoT).

Mitigations:

In the case of DoT, TLS profiles from and the "Countermeasures to DNS Traffic Analysis" from provide strong mitigations. This includes but is not limited to:

• Adhering to .
• Implementing only (D)TLS 1.2 or later, as specified in .
• Implementing Extension Mechanisms for DNS (EDNS(0)) Padding using the guidelines in or a successor specification.
• 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 with TLS 1.2 () or Domain Name System (DNS) Cookies .
• 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" Application-Layer Protocol Negotiation (ALPN) value .

Optimizations:

• Concurrent processing of pipelined queries, returning responses as soon as available, potentially out of order, as specified in . This is often called "OOOR" -- out-of-order responses (providing processing performance similar to HTTP multiplexing).
• Management of TLS connections to optimize performance for clients using and EDNS(0) Keepalive

Additional Options:

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

DoH

DNS Privacy Threats:

• Known attacks on TLS, such as those described in .
• Traffic analysis, for example: (focused on DoH).
• Potential for client tracking via transport identifiers.

Mitigations:

• Clients must be able to forgo the use of HTTP cookies and still use the service.
• Use of HTTP/2 padding and/or EDNS(0) padding, as described in .
• Clients should not be required to include any headers beyond the absolute minimum to obtain service from a DoH server. (See .)

DNSSEC

DNS Privacy Threats:

Users may be directed to bogus IP addresses that, 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 whose TLS authentication can somehow be subverted.

Mitigations:

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 Resource Records (RRs) to the client so that it can perform its own validation.

The addition of encryption to DNS does not remove the need for DNSSEC ; 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 nonvalidating 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 Authentic Data (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 that supports DNSSEC has a far simpler task in terms of DNSSEC roadblock avoidance .

Availability

DNS Privacy Threats:

A failing DNS privacy service could force the user to switch providers, fall back to cleartext, or accept no DNS service for the duration of 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 (DoS) attacks, as experience has shown that unavailability of DNS resolving because of attacks is a significant motivation for users to switch services. See, for example, Section IV-C of . Techniques such as those described in can be of use to operators to defend against such attacks.

Service Options

DNS Privacy Threats:

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

Mitigations:

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

Impact of Encryption on Monitoring by DNS Privacy Service Operators

DNS Privacy Threats:

Increased use of encryption can impact a DNS privacy service operator's ability to monitor traffic and therefore manage their DNS servers .

Many monitoring solutions for DNS traffic rely on the plaintext nature of this traffic and work by intercepting traffic on the wire, either using a separate view on the connection between clients and 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 need to inspect DNS traffic -- e.g., to monitor for network security threats. Operators may therefore need to invest in an alternative means of monitoring that relies on either the resolver software directly, or exporting DNS traffic from the resolver using, for example, .

Optimization:

When implementing alternative means for traffic monitoring, operators of a DNS privacy service should consider using privacy-conscious means to do so. See for more details on data handling and the discussion on the use of Bloom Filters in .

Limitations of Fronting a DNS Privacy Service with a Pure TLS Proxy

DNS Privacy Threats:

• Limited ability to manage or monitor incoming connections using DNS-specific techniques.
• 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., , , or ) in front of a DNS nameserver because of proven robustness and capacity when handling large numbers of client connections, load-balancing capabilities, and good tooling. Currently, however, because such proxies typically have no specific handling of DNS as a protocol over TLS or DTLS, using them can restrict traffic management at the proxy layer and the DNS server. For example, all traffic received by a nameserver behind such a proxy will appear to originate from the proxy, and DNS techniques such as Access Control Lists (ACLs), Response Rate Limiting (RRL), or DNS64 will be hard or impossible to implement in the nameserver. Operators may choose to use a DNS-aware proxy, such as , that offers custom options (similar to those proposed in ) to add source information to packets to address this shortcoming. It should be noted that such options potentially significantly increase the leaked information in the event of a misconfiguration.

Data at Rest on the Server

Data Handling

Threats described in :

• Surveillance.
• Stored-data compromise.
• Correlation.
• Identification.
• Secondary use.
• Disclosure.

Other Threats

• Contravention of legal requirements not to process user data.

Mitigations:

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

• Transient data (e.g., data 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.
• The retention period of DNS traffic logs should be only as long as is required to sustain operation of the service and meet regulatory requirements, to the extent that they exist.
• 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.
• 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:

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

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 it may also include 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 trade-offs 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 , with additional observations from .

• Anonymization. To enable anonymity of an individual, there must exist a set of individuals that appear to have the same attribute(s) as the individual. To the attacker or the observer, these individuals must appear indistinguishable from each other.
• 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, it is difficult to categorize a deterministic algorithm for data minimization of IP addresses that produces a group of pseudonyms for a single given address.

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. provides a more detailed survey of various techniques employed or under development in 2020.

Pseudonymization, Anonymization, or Discarding of Other Correlation Data

DNS Privacy Threats:

• Fingerprinting of the client OS via various means, including: IP TTL/Hoplimit, TCP parameters (e.g., window size, Explicit Congestion Notification (ECN) support, selective acknowledgment (SACK)), OS-specific DNS query patterns (e.g., for network connectivity, captive portal detection, or OS-specific updates).
• Fingerprinting of the client application or TLS library by, for example, HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS version/Cipher-suite combinations, or other connection parameters.
• Correlation of queries on multiple TCP sessions originating from the same IP address.
• Correlating of queries on multiple TLS sessions originating from the same client, including via session-resumption mechanisms.
• Resolvers might receive client identifiers -- e.g., Media Access Control (MAC) addresses in EDNS(0) options. Some customer premises equipment (CPE) devices are known to add them .

Mitigations:

• Data minimization or discarding of such correlation data.

Cache Snooping

Threats described in :

Surveillance:

Profiling of client queries by malicious third parties.

Mitigations:

See for an example discussion on defending against cache snooping. Options proposed include limiting access to a server and limiting nonrecursive queries.

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.

Protocol Recommendations

Threats described in :

Surveillance:

Transmission of identifying data upstream.

Mitigations:

The server should:

• implement QNAME minimization .
• honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the EDNS(0) Client Subnet (ECS) option (). This is as specified in for DoT but applicable to any DNS privacy service.

Optimizations:

As per , the server should either:

• 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 which to send ECS 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 the operator can 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:

• "Aggressive Use of DNSSEC-Validated Cache" and "NXDOMAIN: There Really Is Nothing Underneath" to reduce the number of queries to authoritative servers to increase privacy.
• Run a local copy of the root zone to avoid making queries to the root servers that might leak information.

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., . 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 prefetch 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 prefetches. 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.

Data Sharing

Threats described in :

• Surveillance.
• Stored-data compromise.
• Correlation.
• Identification.
• Secondary use.
• Disclosure.

DNS Privacy Threats:

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 circumstances, 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 on data sharing for research as an example.

Recursive Operator Privacy Statement (RPS) To be compliant with this Best Current Practice 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. provides a comparison of some existing policy and privacy statements.

Outline of an RPS The contents of Sections and are non-normative, other than the order of the headings. Material under each topic is present to assist the operator developing their own RPS. This material:

• Relates only to matters around the technical operation of DNS privacy services, and no other matters.
• Does not attempt to offer an exhaustive list for the contents of an RPS.
• Is not intended to form the basis of any legal/compliance documentation.

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

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.
   In each case, specify whether data 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.
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.

Practice 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 , provide specific details of which capabilities (transport, DNSSEC, padding, etc.) are provided on which client-facing addresses/port combination or DoH URI template. For , clearly specify which specific authentication mechanisms are supported for each endpoint that offers DoT:
   1. The authentication domain name to be used (if any).
   2. The SPKI pin sets to be used (if any) and policy for rolling keys.
3. Upstream capabilities. With reference to , 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 that cover applicable data-processing legislation or agreements with regard to the location(s) of service provision.

Enforcement/Accountability Transparency reports may help with building user trust that operators adhere to their policies and practices. Where possible, independent monitoring or analysis could be performed of:

• ECS, QNAME minimization, EDNS(0) padding, etc.
• Filtering.
• Uptime.

This is by analogy with several TLS or website-analysis tools that are currently available -- e.g., or . Additionally, operators could choose to engage the services of a third-party auditor to verify their compliance with their published RPS.

IANA Considerations This document has no IANA actions.

Security Considerations Security considerations for DNS over TCP are given in , many of which are generally applicable to session-based DNS. Guidance on operational requirements for DNS over TCP are also available in . Security considerations for DoT are given in and , and those for DoH in . Security considerations for DNSSEC are given in , , and .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS). Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706. Informative References IFIP/IEEE International Symposium on Integrated Network Management (IM2019) HTTP is often used as a substrate for other application protocols (a.k.a. HTTP-based APIs). This document specifies best practices for writing specifications that use HTTP to define new application protocols, especially when they are defined for diverse implementation and broad deployment (e.g., in standards efforts). Work in Progress CESNET DePaul University Verisign This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. This includes both DNS over unencrypted TCP, as well as over an encrypted TLS session. The document also considers the consequences with this form of DNS communication and the potential operational issues that can arise when this best common practice is not upheld. Work in Progress Internet Systems Consortium, Inc. PowerDNS.COM B.V. PowerDNS.COM B.V. It is becoming more commonplace to install front end proxy devices in front of DNS servers to provide (for example) load balancing or to perform transport layer conversions. This document defines a meta resource record that allows a DNS server to receive information about the client's original transport protocol parameters when supplied by trusted proxies. Work in Progress PowerDNS Mozilla IANA Conversion Works IEEE/IFIP Network Operations and Management Symposium Internet.nl Google Medium PowerDNS veorq message to the Cfrg mailing list nginx.org The Tcpdump Group Fachbereich Informatik, Technische Universität Darmstadt Proceedings of the 13th Workshop on Privacy in the Electronic Society, pp. 191-200 DNS Privacy Project PowerDNS This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK] DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community. This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853. Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications. SSL Labs ISC Knowledge Database" Ipsilon Networks, Inc. ACM Computing Surveys

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 characteristics of any document with regard to potential increases or decreases in DNS privacy.

Potential Increases in DNS Privacy These documents are limited in scope to communications between stub clients and recursive resolvers:

• "Specification for DNS over Transport Layer Security (TLS)" .
• "DNS over Datagram Transport Layer Security (DTLS)" . Note that this document has the category of Experimental.
• "DNS Queries over HTTPS (DoH)" .
• "Usage Profiles for DNS over TLS and DNS over DTLS" .
• "The EDNS(0) Padding Option" and "Padding Policies for Extension Mechanisms for DNS (EDNS(0))" .

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

• "DNS Query Name Minimisation to Improve Privacy" .

Potential Decreases in DNS Privacy These documents relate to functionality that could provide increased tracking of user activity as a side effect:

• "Client Subnet in DNS Queries" .
• "Domain Name System (DNS) Cookies" ).
• "Transport Layer Security (TLS) Session Resumption without Server-Side State" , referred to here as simply TLS session resumption.
• describes client tracking prevention in TLS 1.3
• "Compacted-DNS (C-DNS): A Format for DNS Packet Capture" .
• Passive DNS .
• 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.

Related Operational Documents

• "DNS Transport over TCP - Implementation Requirements" .
• "DNS Transport over TCP - Operational Requirements" .
• "The edns-tcp-keepalive EDNS0 Option" .
• "DNS Stateful Operations" .

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 categorizations 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. Classification of Techniques

Categorization/Property	GA	d	TC	C	TS	i	B
Anonymization	X	X	X				X
Pseudonymization				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

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 or Compacted-DNS (C-DNS) , 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., ) have observed that, as the entropy in an IPv4 address is limited, if an attacker can

• ensure packets are captured by the target and
• send forged traffic with arbitrary source and destination addresses to that target and
• 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.

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 :

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.

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, or subnet in IP addresses. Prefix preservation ensures that prefixes are de-identified consistently; for example, 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.

Replacement.

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

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

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 nonephemeral (>1024). Another example, precision degradation, reduces the accuracy of, for example, a numeric value or a timestamp.

Enumeration.

With data from a well-ordered set, replace the first data item's data using a random initial value and then allocate ordered values for subsequent data items. When used with timestamp data, this preserves ordering but loses precision and distance.

Reordering/shuffling.

Preserving the original data, but rearranging its order, often in a random manner.

Random substitution.

As replacement, but using randomly generated replacement values.

Cryptographic permutation.

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

Specific Techniques

Google Analytics Non-Prefix Filtering Since May 2010, Google Analytics has provided a facility 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 that 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 (truncation).

dnswasher Since 2006, PowerDNS has included a de-identification tool, 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 when running over a large amount of data, the address translation tables can grow to a significant size.

Anonymization:

Format-preserving, Enumeration.

Prefix-Preserving Map Used in , this algorithm stores a set of original and anonymized 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 TCPdpriv 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. The need to allocate anonymized addresses sequentially means that TCPdpriv cannot be used in parallel processing.

Anonymization:

Format-preserving, prefix preservation (general).

Cryptographic Prefix-Preserving Pseudonymization Cryptographic prefix-preserving pseudonymization was originally proposed as an improvement to the prefix-preserving map implemented in TCPdpriv, described in and implemented in the 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 . 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 and so has a nontrivial calculation overhead. This can be mitigated to some extent (for IPv4, at least) by precalculating results for some number of prefix bits.

Pseudonymization:

Format-preserving, prefix preservation (general).

Top-Hash Subtree-Replicated Anonymization Proposed in , 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 precalculated 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 precalculated structures to a few megabytes 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).

ipcipher A recently released proposal from PowerDNS, ipcipher , 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 suitable for 32-bit block lengths. However, the author of ipcrypt has since indicated that it has low security, and further analysis has revealed it is vulnerable to attack.

Pseudonymization:

Format-preserving, cryptographic permutation.

Bloom Filters van Rijswijk-Deij et al. have recently described work using Bloom Filters 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 being 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.

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 . The analysis is based on the data available in December 2019. We note that the existing 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 (A4 size) of text in a moderate-sized font. It is a nontrivial task today for a user to extract a meaningful overview of the different services on offer. It is also noted that Mozilla has published a DoH resolver policy that 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.

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 what the full contents of an RPS might look like. This should not be interpreted as

• having been reviewed or approved by any operator in any way
• having any legal standing or validity at all
• 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 .

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 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:
      • Requested 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 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 service 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 the IP address information of the requestor and cannot be correlated to IP address or other personal data. We do not and never will share any of the requestor's data with marketers, nor will we use this data for demographic analysis.
3. Exceptions. There are exceptions to this storage model: In the event of actions or observed behaviors that we deem malicious or anomalous, we may utilize more detailed logging to collect more specific IP address data in the process of normal network defense 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 utilize cyber-threat intelligence about malicious domains from a variety of public and private sources and block 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.
      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.

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 RFC 7858 on (insert IP address). It is available on port 853 and port 443. We also implement RFC 7766.
      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 RFC 8484 on (insert URI template).
   4. Both services offer TLS 1.2 and TLS 1.3.
   5. Both services pad DNS responses according to RFC 8467.
   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).

Acknowledgements Many thanks to for a very thorough review of the first draft of this document and for a thorough review at Working Group Last Call and for suggesting the inclusion of an example RPS. Thanks to for discussions on this topic, and to , , and for review. Thanks to , , , , , and for comments at the mic. Thanks to for useful updates to the text. thanks the Open Technology Fund for a grant to support the work on this document.

Contributors The below individuals contributed significantly to the document: Sinodun IT

Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom

Sinodun IT

Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom

Authors' Addresses Sinodun IT

Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom sara@sinodun.com

NLnet Labs

Science Park 400 Amsterdam 1098 XH Netherlands benno@nlnetLabs.nl

NLnet Labs

Science Park 400 Amsterdam 1098 XH Netherlands roland@nlnetLabs.nl

Salesforce.com, Inc.

Salesforce Tower 415 Mission Street, 3rd Floor San Francisco CA 94105 United States of America allison.mankin@gmail.com