| RFC 8932 | DNS Privacy Service Recommendations | October 2020 |
| Dickinson, et al. | Best Current Practice | [Page] |
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.¶
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 athttps://www.rfc-editor.org/info/rfc8932.¶
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 (https://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.¶
The Domain Name System (DNS) is at the core of the Internet; almost everyactivity on the Internet starts with a DNS query (and often several). However,the DNS was not originally designed with strong security or privacymechanisms.A number of developments have taken place in recent years that aim toincreasethe privacy of the DNS, and these are now seeing some deployment. Thislatest evolution of the DNS presents new challenges to operators, and thisdocument attempts to provide an overview of considerations for privacy-focusedDNS services.¶
In recent years, there has also been an increase in the availability of"publicresolvers"[RFC8499], which users may preferto use instead of the defaultnetwork resolver, either because they offer a specific feature (e.g., goodreachability or encrypted transport) or because the network resolver lacks aspecific feature (e.g., strong privacy policy or unfiltered responses). Thesepublic resolvers have tended to be at the forefront of adoption ofprivacy-relatedenhancements, but it is anticipated that operators of other resolver serviceswill follow.¶
Whilst protocols that encrypt DNS messages on the wire provide protectionagainst certain attacks, the resolver operator still has (in principle) fullvisibility of the query data and transport identifiers for eachuser. Therefore,a trust relationship (whether explicit or implicit) is assumed to existbetweeneach user and the operator of the resolver(s) used by that user. The abilityofthe operator to provide a transparent, well-documented, and secure privacyservice will likely serve as a major differentiating factor forprivacy-conscious users if they make an active selection of which resolver touse.¶
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 networkenvironments. For example, the user has aclear expectation of which resolvers have visibility of their query data.However, this resolver/transport selection may provide an added mechanism fortracking them as they move across network environments. Commitments fromresolveroperators to minimize such tracking as users move between networks are alsolikely to play a role in user selection of resolvers.¶
More recently, the global legislative landscape with regard to personal datacollection, retention, and pseudonymization has seen significant activity.Providing detailed practice advice about these areas to the operator is out ofscope, butSection 5.3.3 describes some mitigations of data-sharing risk.¶
This document has two main goals:¶
A desired operational impact is that all operators (both those providingresolvers within networks and those operating large public services) candemonstrate their commitment to user privacy, thereby driving all DNSresolutionservices to a more equitable footing. Choices for users would (in this idealworld) be driven by other factors -- e.g., differing security policies or minordifferences in operator policy -- rather than gross disparities in privacyconcerns.¶
Community insight (or judgment?) about operational practices can changequickly, and experience shows that a Best Current Practice (BCP) documentaboutprivacy and security is a point-in-time statement. Readers are advised to seekout any updates that apply to this document.¶
"DNS Privacy Considerations"[RFC7626] describesthe general privacy issuesand threats associated with the use of the DNS by Internet users; much ofthe threat analysis here is lifted from that document and[RFC6973]. However,this document is limited in scope to best-practice considerations for theprovision of DNS privacy services by servers (recursive resolvers) to clients(stub resolvers or forwarders). Choices that are made exclusively bythe end user, or those for operators of authoritative nameservers, are outof scope.¶
This document includes (but is not limited to) considerations in thefollowingareas:¶
Whilst the issues raised here are targeted at those operators who choose tooffer a DNS privacy service, considerations for areas 2 and 3 could equallyapply to operators who only offer DNS over unencrypted transports but whowouldotherwise like to align with privacy best practice.¶
There are various documents that describe protocol changes that have thepotential to either increase or decrease the privacy properties of the DNS invarious 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 functionalbenefits at the price of a reduction in privacy, and conversely some featuresincrease privacy with an accompanying increase in complexity. A selection ofthemost relevant documents is listed inAppendix A forreference.¶
The key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in thisdocument 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], except withregard to the definition of privacy-enabling DNS server inSection 6 of [RFC8499]. In this document we usethe full definition of a DNS over (D)TLS privacy-enabling DNS server as givenin[RFC8310], i.e., that such a server should also offer atleast one of the credentials described inSection 8 of [RFC8310] and implement the (D)TLS profile described inSection 9 of [RFC8310].¶
Other Terms:¶
In the following sections, we first outline the threats relevant to thespecific topic and then discuss the potential actions that can be taken tomitigate them.¶
We describe two classes of threats:¶
We describe three classes of actions that operators of DNS privacyservices can take:¶
This document does not specify policy, only best practice. However, for DNSprivacy services to be considered compliant with these best-practiceguidelines,theySHOULD implement (where appropriate) all:¶
The rest of this document does not use normative language but insteadrefersonly to the three differing classes of action that correspond to the threenamed levels of compliance stated above. However, compliance (to the indicatedlevel) remains a normative requirement.¶
In this section, we consider both data on the wire and the service provided to the client.¶
A DNS privacy service can mitigate these threats by providing service over one or more of the following transports:¶
It is noted that a DNS privacy service can also be provided over DNS overDTLS[RFC8094]; however, this is an Experimentalspecification, andthere are no knownimplementations at the time of writing.¶
It is also noted that DNS privacy service might be provided over DNSCrypt[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; seeSection 5.1.4.¶
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 DoT 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.¶
Anecdotal evidence to date highlights the management of certificates as oneofthe more challenging aspects for operators of traditional DNS resolvers thatchoose to additionally provide a DNS privacy service, as management of suchcredentials 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 forvarious reasons, such as the logistical overhead of rolling keys.¶
It is recommended that operators:¶
In the case of DoT, TLS profiles fromSection 9 of [RFC8310] and the "Countermeasures to DNS Traffic Analysis" fromSection 11.1 of [RFC8310] provide strong mitigations. This includes but is not limited to:¶
The addition of encryption to DNS does not remove the need for DNSSEC[RFC4033]; they are independent and fully compatibleprotocols,each solving different problems. The use of one does not diminish the need northe 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[RFC8027].¶
A DNS privacy service should strive to engineer encrypted services to the same availability level as any unencrypted services they provide. Particular care should to be taken to protect DNS privacy services against denial-of-service (DoS) attacks, as experience has shown that unavailability of DNS resolving because of attacks is a significant motivation for users to switch services. See, for example, Section IV-C of[Passive-Observations-of-a-Large-DNS].¶
Techniques such as those described inSection 10 of [RFC7766] can be of use to operators to defend against such attacks.¶
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,[dnstap].¶
Some operators may choose to implement DoT using a TLS proxy (e.g.,[nginx],[haproxy], or[stunnel]) in front ofa DNS nameserver because of proven robustness and capacity when handling largenumbers of client connections, load-balancing capabilities, and good tooling.Currently, however, because such proxies typically have no specific handlingof DNS as a protocol over TLS or DTLS, using them can restrict traffic managementat the proxy layer and the DNS server. For example, all traffic received by anameserver behind such a proxy will appear to originate from the proxy, and DNStechniques such as Access Control Lists (ACLs), Response Rate Limiting (RRL),or DNS64[RFC6147] will be hard or impossible to implementinthe nameserver.¶
Operators may choose to use a DNS-aware proxy, such as[dnsdist], that offers custom options (similar to thoseproposed in[DNS-XPF]) to add source informationto packetsto address this shortcoming. It should be noted that such options potentiallysignificantly increase the leaked information in the event of amisconfiguration.¶
The following are recommendations relating to common activities for DNS service operators; in all cases, data retention should be minimized or completely avoided if possible for DNS privacy services. If data is retained, it should be encrypted and either aggregated, pseudonymized, or anonymized whenever possible. In general, the principle of data minimization described in[RFC6973] should be applied.¶
Data minimization refers to collecting, using, disclosing, and storing theminimal data necessary to perform a task, and this can be achieved byremoving or obfuscating privacy-sensitive information in network traffic logs.This is typically personal data or data that can be used to link a record toan individual, but it may also include other confidential information -- forexample, on the structure of an internal corporate network.¶
The problem of effectively ensuring that DNS traffic logs contain no orminimalprivacy-sensitive information is not one that currently has a generally agreedsolution or any standards to inform this discussion. This section presents anoverview of current techniques to simply provide reference on the currentstatus of this work.¶
Research into data minimization techniques (and particularly IP addresspseudonymization/anonymization) was sparked in the late 1990s / early 2000s,partly driven by the desire to share significant corpuses of traffic capturesfor research purposes. Several techniques reflecting different requirements inthis area and different performance/resource trade-offs emerged over the courseof the decade. Developments over the last decade have been both a blessing andacurse; the large increase in size between an IPv4 and an IPv6 address, forexample, renders some techniques impractical, but also makes available a muchlarger amount of input entropy, the better to resist brute-forcere-identification attacks that have grown in practicality over the period.¶
Techniques employed may be broadly categorized as either anonymization orpseudonymization. The following discussion uses the definitions from[RFC6973],Section 3, with additionalobservations from[van-Dijkhuizen-et-al].¶
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.¶
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 ofvarious techniquesemployed or under development in 2020.¶
In this section, we consider both data sent on the wire in upstream queriesanddata shared with third parties.¶
The server should:¶
If operators do offer a service that sends the ECS options upstream, theyshoulduse the shortest prefix that is operationally feasible and ideallyuse a policy of allowlisting upstream servers to which to send ECS in order toreduce data leakage. Operators should make clear in any policy statement whatprefix 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:¶
Additional options:¶
Since queries from recursive resolvers to authoritative servers areperformedusing cleartext (at the time of writing), resolver services need to considertheextent to which they may be directly leaking information about their clientcommunity via these upstream queries and what they can do to mitigate thisfurther. Note that, even when all the relevant techniques described above areemployed, there may still be attacks possible -- e.g.,[Pitfalls-of-DNS-Encryption]. For example, a resolver with avery smallcommunity of users risks exposing data in this way and ought to obfuscate thistraffic by mixing it with "generated" traffic to make client characterizationharder. The resolver could also employ aggressive prefetch techniques as afurther measure to counter traffic analysis.¶
At the time of writing, there are no standardized or widely recognizedtechniquesto perform such obfuscation or bulk prefetches.¶
Another technique that particularly small operators may consider isforwardinglocal traffic to a larger resolver (with a privacy policy that aligns withtheirown practices) over an encrypted protocol, so that the upstream queries areobfuscated among those of the large resolver.¶
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 collectionofaggregated and/or anonymized data for research purposes, within or outside oftheir own organization. This can benefit not only the operator (throughinclusion in novel research) but also the wider Internet community. See thepolicy published by SURFnet[SURFnet-policy] on data sharingfor research asan example.¶
To be compliant with this Best Current Practice document, a DNS recursiveoperatorSHOULD publish a Recursive operator Privacy Statement (RPS). Adoptingtheoutline, and including the headings in the order provided, is a benefit topersons comparing RPSs from multiple operators.¶
Appendix C provides acomparison of some existingpolicy and privacy statements.¶
The contents of Sections6.1.1 and6.1.2 arenon-normative, other than theorder of the headings. Material under each topic is present to assist theoperator developing their own RPS. This material:¶
Appendix D provides an example (also non-normative) of anRPSstatement for a specific operator scenario.¶
Data collection and sharing. Specify clearly what data (including IP addresses) is:¶
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.¶
Result filtering. This section should explain whether the operator filters,edits, or alters in any way the replies that it receives from the authoritativeservers for each DNS zone before forwarding them to the clients. For eachcategory listed below, the operator should also specify how the filteringlistsare created and managed, whether it employs any third-party sources for suchlists, and which ones.¶
Communicate the current operational practices of the service.¶
Client-facing capabilities. With reference to each subsection ofSection 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. ForSection 5.1.2, clearly specify which specific authentication mechanisms are supported for each endpoint that offers DoT:¶
Transparency reports may help with building user trust that operatorsadhere totheir policies and practices.¶
Where possible, independent monitoring or analysis could be performed of:¶
This is by analogy with several TLS or website-analysis tools that arecurrently available -- e.g.,[SSL-Labs] or[Internet.nl].¶
Additionally, operators could choose to engage the services of a third-partyauditor to verify their compliance with their published RPS.¶
This document has no IANA actions.¶
Security considerations for DNS over TCP are given in[RFC7766], many of whichare generally applicable to session-based DNS. Guidance on operationalrequirements for DNS over TCP are also available in[DNS-OVER-TCP]. Security considerations forDoT are given in[RFC7858] and[RFC8310], and those for DoH in[RFC8484].¶
Security considerations for DNSSEC are given in[RFC4033],[RFC4034], and[RFC4035].¶
This section provides an overview of some DNS privacy-relateddocuments. However, this is neither an exhaustive list nor adefinitive statement on the characteristics of any document with regard to potential increases or decreases in DNS privacy.¶
These documents are limited in scope to communications between stubclients and recursive resolvers:¶
These documents apply to recursive and authoritative DNS but are relevantwhenconsidering the operation of a recursive server:¶
These documents relate to functionality that could provide increasedtracking ofuser activity as a side effect:¶
The following table presents a high-level comparison of various techniquesemployed or under development in 2019 and classifies them according tocategorization of technique and other properties. Both the specific techniquesand the categorizations are described in more detail in the followingsections.The list of techniques includes the main techniques in current use but doesnotclaim to be comprehensive.¶
| Categorization/Property | GA | d | TC | C | TS | i | B |
|---|---|---|---|---|---|---|---|
| Anonymization | X | X | X | X | |||
| Pseudonymization | X | X | X | ||||
| Formatpreserving | 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 | ||||||
| Cryptographicpermutation | X | X | X | ||||
| IPv6 issues | X | ||||||
| CPU intensive | X | ||||||
| Memory intensive | X | ||||||
| Security concerns | X |
Legend of techniques:¶
The choice of which method to use for a particular application will dependonthe requirements of that application and consideration of the threat analysisofthe particular situation.¶
For example, a common goal is that distributed packet captures must be in an existing data format, such as PCAP[pcap] or Compacted-DNS (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.,[Brekne-and-Arnes]) have observed that, as the entropy in an IPv4 address is limited, if an attacker can¶
any format-preserving pseudonymization is vulnerable to an attack along thelines of a cryptographic chosen-plaintext attack.¶
Data minimization methods may be categorized by the processing used and theproperties of their outputs. The following builds on the categorizationemployed in[RFC6235]:¶
Since May 2010, Google Analytics has provided a facility[IP-Anonymization-in-Analytics] that allows websiteowners to request that all their users' IP addresses are anonymized withinGoogle Analytics processing. This very basic anonymization simply sets to zerothe least significant 8 bits of IPv4 addresses, and the least significant 80bits of IPv6 addresses. The level of anonymization this produces is perhapsquestionable. There are some analysis results[Geolocation-Impact-Assessment] that suggest that the impact ofthis on reducing the accuracy of determining the user's location from their IPaddress is less than might be hoped; the average discrepancy in identificationof the user city for UK users is no more than 17%.¶
Since 2006, PowerDNS has included a de-identification tool, dnswasher[PowerDNS-dnswasher], with their PowerDNSproduct. This is aPCAP filter thatperforms a one-to-one mapping of end-user IP addresses with an anonymizedaddress. A table of user IP addresses and their de-identified counterparts iskept; the first IPv4 user addresses is translated to 0.0.0.1, the second to0.0.0.2, and so on. The de-identified address therefore depends on the orderthataddresses arrive in the input, and when running over a large amount of data, theaddress translation tables can grow to a significant size.¶
Used in[tcpdpriv],this algorithm stores a set of original and anonymized IPaddress pairs. When a new IP address arrives, it is compared with previousaddresses to determine the longest prefix match. The new address is anonymizedby using the same prefix, with the remainder of the address anonymized with arandom value. The use of a random value means that TCPdpriv is notdeterministic; different anonymized values will be generated on each run. The need to store previous addresses means that TCPdpriv has significant andunbounded memory requirements. The need to allocate anonymized addressessequentially means that TCPdpriv cannot be used in parallel processing.¶
Cryptographic prefix-preserving pseudonymization was originally proposed asanimprovement to the prefix-preserving map implemented in TCPdpriv, described in[Xu-et-al] and implemented in the[Crypto-PAn]tool.Crypto-PAn is now frequentlyused as an acronym for the algorithm. Initially, it was described for IPv4addresses only; extension for IPv6 addresses was proposed in[Harvan]. This uses a cryptographic algorithmrather than a random value, and thus pseudonymity is determined uniquely bytheencryption key, and is deterministic. It requires a separate AES encryptionforeach output bit and so has a nontrivial calculation overhead. This can bemitigated to some extent (for IPv4, at least) by precalculating results forsome number of prefix bits.¶
Proposed in[Ramaswamy-and-Wolf],Top-hash Subtree-replicated Anonymization (TSA)originated in response to the requirement for faster processing thanCrypto-PAn.It used hashing for the most significant byte of an IPv4 address and aprecalculated binary-tree structure for the remainder of the address. To savememory space, replication is used within the tree structure, reducing the sizeof the precalculated structures to a few megabytes for IPv4 addresses. Addresspseudonymization is done via hash and table lookup and so requires minimalcomputation. However, due to the much-increased address space for IPv6, TSA isnot memory efficient for IPv6.¶
A recently released proposal from PowerDNS, ipcipher[ipcipher1][ipcipher2], is a simplepseudonymization technique for IPv4 and IPv6 addresses. IPv6 addresses areencrypted directly with AES-128 using a key (which may be derived from apassphrase). IPv4 addresses are similarly encrypted, but using a recentlyproposed encryption[ipcrypt] suitable for32-bit block lengths. However, the author of ipcrypt has since indicated[ipcrypt-analysis] that it haslow security, and further analysis has revealed it is vulnerable to attack.¶
van Rijswijk-Deij et al.have recently described work using Bloom Filters[Bloom-filter]tocategorize query traffic and record the traffic as the state of multiplefilters. The goal of this work is to allow operators to identify so-calledIndicators of Compromise (IOCs) originating from specific subnets withoutstoring information about, or being able to monitor, the DNS queries of anindividual user. By using a Bloom Filter, it is possible to determine with ahigh probability if, for example, a particular query was made, but the set ofqueries made cannot be recovered from the filter. Similarly, by mixing queriesfrom a sufficient number of users in a single filter, it becomes practicallyimpossible to determine if a particular user performed a particularquery. Largenumbers of queries can be tracked in a memory-efficient way. As filter statusisstored, this approach cannot be used to regenerate traffic and so cannot beused with tools used to process live traffic.¶
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 policies vary widely in style, content, anddetail, and it is not uncommon for the full text for a given operator toequate to more than 10 pages (A4 size) of text in a moderate-sized font. It is anontrivial task today for a user to extract a meaningful overview of thedifferent services on offer.¶
It is also noted that Mozilla has published a DoH resolver policy[DoH-resolver-policy] that describes the minimum set ofpolicyrequirements that a party must satisfy to be considered as a potentialpartner for Mozilla's Trusted Recursive Resolver (TRR) program.¶
The following example RPS is very loosely based on some elements ofpublished privacy statements for some public resolvers, with additional fieldspopulated to illustrate what the full contents of an RPS mightlook like. This should not be interpreted as¶
This is a purely hypothetical example of an RPS to outline examplecontents -- in this case, for a public resolver operator providing a basic DNSPrivacy service via one IP address and one DoH URI with security-basedfiltering. It does aim to meet minimal compliance as specified inSection 5.¶
Data collection and sharing.¶
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:¶
Transport protocol on which the request arrived -- i.e., UDP, TCP, DoT, DoH¶
We may keep the following data as summary information, including all theabove EXCEPT for data about the DNS record requested:¶
All the above data may be kept in full or partial form in permanentarchives.¶
Result filtering.¶
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.¶
Client-facing capabilities.¶
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.¶
Both services provide DNSSEC validation.¶
Upstream capabilities.¶
Many thanks toAmelia Andersdotter for a very thorough review of the first draft of this document andStephen Farrell for a thorough review at Working Group Last Call and for suggesting the inclusion of an example RPS. Thanks toJohn Todd for discussions on this topic, and toStéphane Bortzmeyer,Puneet Sood, andVittorio Bertola for review. Thanks toDaniel Kahn Gillmor,Barry Green,Paul Hoffman,Dan York,Jon Reed, andLorenzo Colitti for comments at the mic. Thanks toLoganaden Velvindron for useful updates to the text.¶
Sara Dickinson thanks the Open Technology Fund for a grant to support theworkon this document.¶
The below individuals contributed significantly to the document:¶