rfc8932xml2.original.xml   rfc8932.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="bcp" docName="draft-ietf-dprive-bcp-op-14">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="DNS Privacy Service Recommendations">Recommendations for DNS
Privacy Service Operators</title>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization>Sinodun IT</organization>
<address>
<postal>
<street></street>
<street>Magdalen Centre</street>
<street>Oxford Science Park</street>
<city>Oxford</city>
<code>OX4 4GA</code>
<country>United Kingdom</country>
<region></region>
</postal>
<phone></phone>
<email>sara@sinodun.com</email>
<uri></uri>
</address>
</author>
<author initials="B." surname="Overeinder" fullname="Benno J. Overeinder">
<organization>NLnet Labs</organization>
<address>
<postal>
<street></street>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>The Netherlands</country>
<region></region>
</postal>
<phone></phone>
<email>benno@nlnetLabs.nl</email>
<uri></uri>
</address>
</author>
<author initials="R." surname="van Rijswijk-Deij" fullname="Roland M. van
Rijswijk-Deij">
<organization>NLnet Labs</organization>
<address>
<postal>
<street></street>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>The Netherlands</country>
<region></region>
</postal>
<phone></phone>
<email>roland@nlnetLabs.nl</email>
<uri></uri>
</address>
</author>
<author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization>Salesforce</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>allison.mankin@gmail.com</email>
<uri></uri>
</address>
</author>
<date year="2020" month="July" day="13"/>
<area>Internet</area> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<workgroup>dprive</workgroup>
<keyword>DNS</keyword>
<abstract> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<t>This document presents operational, policy, and security considerations for docName="draft-ietf-dprive-bcp-op-14" number="8932" obsoletes=""
DNS updates="" submissionType="IETF" category="bcp" consensus="true"
recursive resolver operators who choose to offer DNS Privacy services. With xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
these recommendations, the operator can make deliberate decisions regarding version="3">
which services to provide, and how the decisions and alternatives impact the
privacy of users.
</t>
<t>This document also presents a non-normative framework to assist writers of
a Recursive
operator Privacy Statement (analogous to DNS Security Extensions (DNSSEC)
Policies and DNSSEC Practice Statements described in RFC6841).
</t>
</abstract>
</front> <!-- xml2rfc v2v3 conversion 2.46.0 -->
<front>
<title abbrev="DNS Privacy Service Recommendations">Recommendations for DNS
Privacy Service Operators</title>
<seriesInfo name="RFC" value="8932"/>
<seriesInfo name="BCP" value="232"/>
<middle> <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization>Sinodun IT</organization>
<address>
<postal>
<extaddr>Magdalen Centre</extaddr>
<street>Oxford Science Park</street>
<city>Oxford</city>
<code>OX4 4GA</code>
<country>United Kingdom</country>
<region/>
</postal>
<email>sara@sinodun.com</email>
</address>
</author>
<author initials="B." surname="Overeinder" fullname="Benno J. Overeinder">
<organization>NLnet Labs</organization>
<address>
<postal>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>Netherlands</country>
<region/>
</postal>
<email>benno@nlnetLabs.nl</email>
</address>
</author>
<author initials="R." surname="van Rijswijk-Deij" fullname="Roland M. van Ri
jswijk-Deij">
<organization>NLnet Labs</organization>
<address>
<postal>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>Netherlands</country>
<region/>
</postal>
<email>roland@nlnetLabs.nl</email>
</address>
</author>
<author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization abbrev="Salesforce">Salesforce.com, Inc.</organization>
<address>
<postal>
<street>Salesforce Tower</street>
<street>415 Mission Street, 3rd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>United States of America</country>
</postal>
<email>allison.mankin@gmail.com</email>
</address>
</author>
<date year="2020" month="October"/>
<area>Internet</area>
<workgroup>dprive</workgroup>
<keyword>DNS</keyword>
<abstract>
<section anchor="introduction" title="Introduction"> <t>This document presents operational, policy, and security
<t>The Domain Name System (DNS) is at the core of the Internet; almost every considerations for DNS recursive resolver operators who choose to offer
activity on the Internet starts with a DNS query (and often several). However 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.
</t>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>The Domain Name System (DNS) is at the core of the Internet; almost eve
ry
activity on the Internet starts with a DNS query (and often several). However,
the DNS was not originally designed with strong security or privacy the DNS was not originally designed with strong security or privacy
mechanisms. mechanisms.
A number of developments have taken place in recent years which aim to A number of developments have taken place in recent years that aim to
increase increase
the privacy of the DNS system and these are now seeing some deployment. This 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 latest evolution of the DNS presents new challenges to operators, and this
document attempts to provide an overview of considerations for privacy focused document attempts to provide an overview of considerations for privacy-focused
DNS services. DNS services.
</t> </t>
<t>In recent years there has also been an increase in the availability of <t>In recent years, there has also been an increase in the availability of
&quot;public "public
resolvers&quot; <xref target="RFC8499"/> which users may prefer to use instead resolvers" <xref target="RFC8499" format="default"/>, which users may prefer
of the default to use instead of the default
network resolver either because they offer a specific feature (e.g., good network resolver, either because they offer a specific feature (e.g., good
reachability or encrypted transport) or because the network resolver lacks a reachability or encrypted transport) or because the network resolver lacks a
specific feature (e.g., strong privacy policy or unfiltered responses). These specific feature (e.g., strong privacy policy or unfiltered responses). These
public resolvers have tended to be at the forefront of adoption of public resolvers have tended to be at the forefront of adoption of
privacy-related privacy-related
enhancements but it is anticipated that operators of other resolver services enhancements, but it is anticipated that operators of other resolver services
will follow. will follow.
</t> </t>
<t>Whilst protocols that encrypt DNS messages on the wire provide protection <t>Whilst protocols that encrypt DNS messages on the wire provide protecti on
against certain attacks, the resolver operator still has (in principle) full against certain attacks, the resolver operator still has (in principle) full
visibility of the query data and transport identifiers for each visibility of the query data and transport identifiers for each
user. Therefore, user. Therefore,
a trust relationship (whether explicit or implicit) is assumed to exist a trust relationship (whether explicit or implicit) is assumed to exist
between between
each user and the operator of the resolver(s) used by that user. The ability each user and the operator of the resolver(s) used by that user. The ability
of of
the operator to provide a transparent, well documented, and secure privacy the operator to provide a transparent, well-documented, and secure privacy
service will likely serve as a major differentiating factor for privacy service will likely serve as a major differentiating factor for
conscious users if they make an active selection of which resolver to use. privacy-conscious users if they make an active selection of which resolver to
use.
</t> </t>
<t>It should also be noted that the choice of a user to configure a single <t>It should also be noted that there are both advantages and
resolver 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 (or a fixed set of resolvers) and an encrypted transport to use in all network
environments has both advantages and disadvantages. For example, the user has environments. For example, the user has a
a
clear expectation of which resolvers have visibility of their query data. clear expectation of which resolvers have visibility of their query data.
However, this resolver/transport selection may provide an added mechanism to However, this resolver/transport selection may provide an added mechanism for
track them as they move across network environments. Commitments from resolver tracking them as they move across network environments. Commitments from
resolver
operators to minimize such tracking as users move between networks are also operators to minimize such tracking as users move between networks are also
likely to play a role in user selection of resolvers. likely to play a role in user selection of resolvers.
</t> </t>
<t>More recently the global legislative landscape with regard to personal data <t>More recently, the global legislative landscape with regard to personal data
collection, retention, and pseudonymization has seen significant activity. collection, retention, and pseudonymization has seen significant activity.
Providing detailed practice advice about these areas to the operator is out of Providing detailed practice advice about these areas to the operator is out of
scope, but <xref target="data-sharing"/> describes some mitigations of data scope, but <xref target="data-sharing" format="default"/> describes some mitigat
sharing risk. ions of data-sharing risk.
</t> </t>
<t>This document has two main goals: <t>This document has two main goals:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>To provide operational and policy guidance related to DNS over encry
<t>To provide operational and policy guidance related to DNS over encrypted pted
transports and to outline recommendations for data handling for operators of transports and to outline recommendations for data handling for operators of
DNS privacy services.</t> DNS privacy services.</li>
<t>To introduce the Recursive operator Privacy Statement (RPS) and present a <li>To introduce the Recursive operator Privacy Statement (RPS) and pres
ent a
framework to assist writers of an RPS. An RPS is a framework to assist writers of an RPS. An RPS is a
document that an operator should publish which outlines their operational document that an operator should publish that outlines their operational
practices and commitments with regard to privacy, thereby providing a means practices and commitments with regard to privacy, thereby providing a means
for clients to evaluate both the measurable and claimed privacy properties of 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 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 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 particular privacy statement, nor does it seek to provide legal advice as to
the contents.</t> the contents of an RPS.</li>
</list> </ul>
</t> <t>A desired operational impact is that all operators (both those providin
<t>A desired operational impact is that all operators (both those providing g
resolvers within networks and those operating large public services) can resolvers within networks and those operating large public services) can
demonstrate their commitment to user privacy thereby driving all DNS demonstrate their commitment to user privacy, thereby driving all DNS
resolution resolution
services to a more equitable footing. Choices for users would (in this ideal 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 world) be driven by other factors -- e.g., differing security policies or minor
difference in operator policy, rather than gross disparities in privacy differences in operator policy -- rather than gross disparities in privacy
concerns. concerns.
</t> </t>
<t>Community insight [or judgment?] about operational practices can change
<t>Community insight (or judgment?) about operational practices can change
quickly, and experience shows that a Best Current Practice (BCP) document quickly, and experience shows that a Best Current Practice (BCP) document
about about
privacy and security is a point-in-time statement. Readers are advised to seek privacy and security is a point-in-time statement. Readers are advised to seek
out any updates that apply to this document. out any updates that apply to this document.
</t> </t>
</section> </section>
<section anchor="scope" numbered="true" toc="default">
<section anchor="scope" title="Scope"> <name>Scope</name>
<t>&quot;DNS Privacy Considerations&quot; <xref target="RFC7626"/> describes <t>"DNS Privacy Considerations" <xref target="RFC7626" format="default"/>
describes
the general privacy issues the general privacy issues
and threats associated with the use of the DNS by Internet users and much of and threats associated with the use of the DNS by Internet users; much of
the the threat analysis here is lifted from that document and <xref
threat analysis here is lifted from that document and from <xref target="RFC6973" format="default"/>. However,
target="RFC6973"/>. However this document is limited in scope to best-practice considerations for the
this document is limited in scope to best practice considerations for the
provision of DNS privacy services by servers (recursive resolvers) to clients provision of DNS privacy services by servers (recursive resolvers) to clients
(stub resolvers or forwarders). Choices that are made exclusively by (stub resolvers or forwarders). Choices that are made exclusively by
the end user, or those for operators of authoritative nameservers are out the end user, or those for operators of authoritative nameservers, are out
of scope. of scope.
</t> </t>
<t>This document includes (but is not limited to) considerations in the <t>This document includes (but is not limited to) considerations in the
following following
areas: areas:
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>Data "on the wire" between a client and a server.</li>
<t>Data &quot;on the wire&quot; between a client and a server.</t> <li>Data "at rest" on a server (e.g., in logs).</li>
<t>Data &quot;at rest&quot; on a server (e.g., in logs).</t> <li>Data "sent onwards" from the server (either on the wire or shared
<t>Data &quot;sent onwards&quot; from the server (either on the wire or shared
with a with a
third party).</t> third party).</li>
</list> </ol>
</t> <t>Whilst the issues raised here are targeted at those operators who choos
<t>Whilst the issues raised here are targeted at those operators who choose to e to
offer a DNS privacy service, considerations for areas 2 and 3 could equally 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 apply to operators who only offer DNS over unencrypted transports but who
would would
otherwise like to align with privacy best practice. otherwise like to align with privacy best practice.
</t> </t>
</section> </section>
<section anchor="privacyrelated-documents" numbered="true" toc="default">
<section anchor="privacyrelated-documents" title="Privacy-related documents"> <name>Privacy-Related Documents</name>
<t>There are various documents that describe protocol changes that have the <t>There are various documents that describe protocol changes that have th
e
potential to either increase or decrease the privacy properties of the DNS in potential to either increase or decrease the privacy properties of the DNS in
various ways. Note this does not imply that some documents are good or bad, 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 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 benefits at the price of a reduction in privacy, and conversely some features
increase privacy with an accompanying increase in complexity. A selection of increase privacy with an accompanying increase in complexity. A selection of
the the
most relevant documents are listed in <xref target="documents"/> for most relevant documents is listed in <xref target="documents" format="default"/> for
reference. reference.
</t> </t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
&quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, >REQUIRED</bcp14>",
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMEND
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> ED</bcp14>",
<xref target="RFC8174"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119" for
mat="default"/>
<xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t>DNS terminology is as described in <xref target="RFC8499"/> with one <t>
modification: we restate DNS terminology is as described in <xref target="RFC8499"/>, except with
the clause in the original definition of Privacy-enabling DNS server in regard to the definition of privacy-enabling DNS server in <xref
<xref target="RFC8310"/> to include the requirement that a DNS over (D)TLS target="RFC8499" section="6" sectionFormat="of" />. In this document we use
server should also the full definition of a DNS over (D)TLS privacy-enabling DNS server as given
offer at least one of the credentials described in Section 8 of <xref in <xref target="RFC8310"/>, i.e., that such a server should also offer at
target="RFC8310"/> and least one of the credentials described in <xref target="RFC8310" section="8"
implement the (D)TLS profile described in Section 9 of <xref sectionFormat="of"/> and implement the (D)TLS profile described in <xref
target="RFC8310"/>. target="RFC8310" section="9" sectionFormat="of"/>.
</t> </t>
<t>Other Terms:
</t>
<t>
<list style="symbols">
<t>RPS: Recursive operator Privacy Statement, see
<xref target="recursive-operator-privacy-statement-rps"/>.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor="recommendations-for-dns-privacy-services" <t>Other Terms:
title="Recommendations for DNS privacy services"> </t>
<t>In the following sections we first outline the threats relevant to the <dl>
<dt>RPS:</dt><dd>Recursive operator Privacy Statement; see
<xref target="recursive-operator-privacy-statement-rps"
format="default"/>.</dd>
<dt>DNS privacy service:</dt><dd>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.</dd>
</dl>
</section>
<section anchor="recommendations-for-dns-privacy-services" numbered="true" t
oc="default">
<name>Recommendations for DNS Privacy Services</name>
<t>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 specific topic and then discuss the potential actions that can be taken to
mitigate them. mitigate them.
</t> </t>
<t>We describe two classes of threats: <t>We describe two classes of threats:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>Threats described in <xref target="RFC6973"/> 'Privacy Considerations for <t>Threats described in <xref target="RFC6973" format="default"/>,
Internet Protocols' "Privacy Considerations for Internet Protocols"
<list style="symbols">
<t>Privacy terminology, threats to privacy, and mitigations as described in
Sections 3, 5, and 6 of <xref target="RFC6973"/>.</t>
</list></t>
<t>DNS Privacy Threats
<list style="symbols">
<t>These are threats to the users and operators of DNS privacy services that
are not directly covered by <xref target="RFC6973"/>. These may be more
operational in
nature such as certificate management or service availability issues.</t>
</list></t>
</list>
</t> </t>
<t>We describe three classes of actions that operators of DNS privacy <ul spacing="normal">
<li>Privacy terminology, threats to privacy, and mitigations as
described in Sections <xref target="RFC6973" section="3"
sectionFormat="bare"/>, <xref target="RFC6973" section="5"
sectionFormat="bare"/>, and <xref target="RFC6973" section="6"
sectionFormat="bare"/> of <xref target="RFC6973"/>.</li>
</ul>
</li>
<li>
<t>DNS Privacy Threats
</t>
<ul spacing="normal">
<li>These are threats to the users and operators of DNS privacy
services that
are not directly covered by <xref target="RFC6973"
format="default"/>. These may be more
operational in
nature, such as certificate-management or service-availability issues
.</li>
</ul>
</li>
</ul>
<t>We describe three classes of actions that operators of DNS privacy
services can take: services can take:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>Threat mitigation for well-understood and documented privacy threats
<t>Threat mitigation for well understood and documented privacy threats to the to the
users of the service and in some cases to the operators of the service.</t> users of the service and, in some cases, the operators of the service.</li>
<t>Optimization of privacy services from an operational or management <li>Optimization of privacy services from an operational or management
perspective.</t> perspective.</li>
<t>Additional options that could further enhance the privacy and usability of <li>Additional options that could further enhance the privacy and usabil
ity of
the the
service.</t> service.</li>
</list> </ul>
</t> <t>This document does not specify policy, only best practice. However, for
<t>This document does not specify policy - only best practice, however for DNS DNS
Privacy services to be considered compliant with these best practice privacy services to be considered compliant with these best-practice
guidelines guidelines,
they SHOULD implement (where appropriate) all: they <bcp14>SHOULD</bcp14> implement (where appropriate) all:
</t>
<t>
<list style="symbols">
<t>Threat mitigations to be minimally compliant.</t>
<t>Optimizations to be moderately compliant.</t>
<t>Additional options to be maximally compliant.</t>
</list>
</t> </t>
<t>The rest of this document does not use normative language but instead <ul spacing="normal">
<li>Threat mitigations to be minimally compliant.</li>
<li>Optimizations to be moderately compliant.</li>
<li>Additional options to be maximally compliant.</li>
</ul>
<t>The rest of this document does not use normative language but instead
refers refers
only to the three differing classes of action which correspond to the three only to the three differing classes of action that correspond to the three
named levels of compliance stated above. However, compliance (to the indicated named levels of compliance stated above. However, compliance (to the indicated
level) remains a normative requirement. level) remains a normative requirement.
</t> </t>
<section anchor="on-the-wire-between-client-and-server" numbered="true" to
c="default">
<name>On the Wire between Client and Server</name>
<t>In this section, we consider both data on the wire and the service pr
ovided
to the client.
</t>
<section anchor="on-the-wire-between-client-and-server" title="On the wire <section anchor="transport-recommendations" numbered="true" toc="default
between client and server"> ">
<t>In this section we consider both data on the wire and the service provided <name>Transport Recommendations</name>
to
the client.
</t>
<section anchor="transport-recommendations" title="Transport recommendations"> <dl newline="true">
<t><xref target="RFC6973"/> Threats: <dt>Threats described in <xref target="RFC6973" format="default"/>:</dt
</t> >
<t> <dd>
<list style="symbols"> <dl newline="true">
<t>Surveillance: <dt>Surveillance:</dt>
<list style="symbols"> <dd>Passive surveillance of traffic on the wire.</dd>
<t>Passive surveillance of traffic on the wire</t> </dl>
</list></t> </dd>
</list>
</t> <dt>DNS Privacy Threats:</dt>
<t>DNS Privacy Threats:
</t> <dd>Active injection of spurious data or traffic.</dd>
<t>
<list style="symbols"> <dt>Mitigations:</dt>
<t>Active injection of spurious data or traffic.</t>
</list> <dd><t>A DNS privacy service can mitigate these threats by providing
</t> service over one
<t>Mitigations: or more of the following transports:</t>
</t>
<t>A DNS privacy service can mitigate these threats by providing service over <ul spacing="normal">
one <li>DNS over TLS (DoT) <xref target="RFC7858" format="default"/>
or more of the following transports <xref target="RFC8310" format="default"/>.</li>
</t> <li>DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/>.<
<t> /li>
<list style="symbols"> </ul>
<t>DNS over TLS (DoT) <xref target="RFC7858"/> and <xref </dd>
target="RFC8310"/>.</t> </dl>
<t>DNS over HTTPS (DoH) <xref target="RFC8484"/>.</t>
</list> <t>It is noted that a DNS privacy service can also be provided over DN
</t> S over
<t>It is noted that a DNS privacy service can also be provided over DNS over
DTLS DTLS
<xref target="RFC8094"/>, however this is an Experimental specification and <xref target="RFC8094" format="default"/>; however, this is an Experimental
specification, and
there are no known there are no known
implementations at the time of writing. implementations at the time of writing.
</t> </t>
<t>It is also noted that DNS privacy service might be provided over IPSec,
DNSCrypt, or VPNs. However, there are no specific RFCs that cover the use of
these transports for DNS and any discussion of best practice for providing
such
a service is out of scope for this document.
</t>
<t>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 <xref target="dnssec"/>.
</t>
</section>
<section anchor="authentication-of-dns-privacy-services" title="Authentication <t>It is also noted that DNS privacy service might be
of DNS privacy services"> provided over DNSCrypt <xref target="DNSCrypt"/>, IPsec, or VPNs. Howe
<t><xref target="RFC6973"/> Threats: ver, there are
</t> no specific RFCs that cover the use of these transports for
<t> DNS, and any discussion of best practice for providing such a
<list style="symbols"> service is out of scope for this document.
<t>Surveillance:
<list style="symbols">
<t>Active attacks on client resolver configuration</t>
</list></t>
</list>
</t>
<t>Mitigations:
</t>
<t>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.
</t>
<t>When using DoT, clients that select a 'Strict Privacy' usage profile <xref
target="RFC8310"/>
(to mitigate the threat of active attack on the client) require the ability to
authenticate the DNS server. To enable this, DNS privacy services that offer
DNS over TLS need to provide credentials that will be accepted by the client's
trust model, in the form of either X.509 certificates <xref target="RFC5280"/>
or Subject
Public Key Info (SPKI) pin sets <xref target="RFC8310"/>.
</t>
<t>When offering DoH <xref target="RFC8484"/>, HTTPS requires authentication
of the server as
part of the protocol.
</t> </t>
<t>Server operators should also follow the best practices with regard to <t>Whilst encryption of DNS traffic can protect against active
certificate revocation as described in <xref target="RFC7525"/>. injection on the paths traversed by the encrypted connection, this
does not diminish the need
for DNSSEC; see <xref target="dnssec" format="default"/>.
</t> </t>
</section>
<section anchor="authentication-of-dns-privacy-services" numbered="true"
toc="default">
<name>Authentication of DNS Privacy Services</name>
<section anchor="certificate-management" title="Certificate management"> <dl newline="true">
<t>Anecdotal evidence to date highlights the management of certificates as one <dt>Threats described in <xref target="RFC6973" format="default"/>:</
dt>
<dd>
<dl newline="true">
<dt>Surveillance:</dt>
<dd>Active attacks on client resolver configuration.</dd>
</dl>
</dd>
<dt>Mitigations:</dt>
<dd>
<t>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.
</t>
<t>When using DoT, clients that select a "Strict Privacy" usage
profile <xref target="RFC8310" format="default"/> (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 <xref target="RFC5280" format="default"/> or Subject
Public Key Info (SPKI) pin sets <xref target="RFC8310"
format="default"/>.
</t>
<t>When offering DoH <xref target="RFC8484" format="default"/>,
HTTPS requires authentication of the server as part of the protocol.
</t>
</dd>
</dl>
<section anchor="certificate-management" numbered="true" toc="default"
>
<name>Certificate Management</name>
<t>Anecdotal evidence to date highlights the management of certifica
tes as one
of of
the more challenging aspects for operators of traditional DNS resolvers that the more challenging aspects for operators of traditional DNS resolvers that
choose to additionally provide a DNS privacy service as management of such choose to additionally provide a DNS privacy service, as management of such
credentials is new to those DNS operators. credentials is new to those DNS operators.
</t> </t>
<t>It is noted that SPKI pin set management is described in <xref <t>It is noted that SPKI pin set management is described in <xref ta
target="RFC7858"/> but that key rget="RFC7858" format="default"/> but that key-pinning mechanisms in general hav
pinning mechanisms in general have fallen out of favor operationally for e fallen out of favor operationally for
various reasons such as the logistical overhead of rolling keys. various reasons, such as the logistical overhead of rolling keys.
</t> </t>
<t>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Invalid certificates, resulting in an unavailable service which might force
a
user to fallback to cleartext.</t>
<t>Mis-identification of a server by a client e.g., typos in DoH URL templates
<xref target="RFC8484"/> or authentication domain names <xref
target="RFC8310"/> which accidentally direct
clients to attacker controlled servers.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>It is recommended that operators:
</t>
<t>
<list style="symbols">
<t>Follow the guidance in Section 6.5 of <xref target="RFC7525"/> with regards
to certificate
revocation.</t>
<t>Automate the generation, publication, and renewal of certificates. For
example,
ACME <xref target="RFC8555"/> provides a mechanism to actively manage
certificates through
automation and has been implemented by a number of certificate
authorities.</t>
<t>Monitor certificates to prevent accidental expiration of certificates.</t>
<t>Choose a short, memorable authentication domain name for the service.</t>
</list>
</t>
</section>
</section>
<section anchor="protocol-recommendations" title="Protocol recommendations"> <dl newline="true">
<dt>DNS Privacy Threats:</dt>
<section anchor="dot" title="DoT"> <dd>
<t>DNS Privacy Threats: <ul spacing="normal">
</t> <li>Invalid certificates, resulting in an unavailable service, whi
<t> ch might force a
<list style="symbols"> user to fall back to cleartext.</li>
<t>Known attacks on TLS such as those described in <xref <li>Misidentification of a server by a client -- e.g., typos in Do
target="RFC7457"/>.</t> H URL templates
<t>Traffic analysis, for example: <xref <xref target="RFC8484" format="default"/> or authentication domain
target="Pitfalls-of-DNS-Encryption"/>.</t> names <xref target="RFC8310" format="default"/> that accidentally direct
<t>Potential for client tracking via transport identifiers.</t> clients to attacker-controlled servers.</li>
<t>Blocking of well known ports (e.g., 853 for DoT).</t> </ul>
</list> </dd>
</t>
<t>Mitigations: <dt>Mitigations:</dt>
<dd>
<t>It is recommended that operators:
</t> </t>
<t>In the case of DoT, TLS profiles from Section 9 of <xref target="RFC8310"/> <ul spacing="normal">
and the <li>Follow the guidance in <xref target="RFC7525" section="6.5"
Countermeasures to DNS Traffic Analysis from section 11.1 of <xref sectionFormat="of"/> with regard to certificate revocation.</li>
target="RFC8310"/> <li>Automate the generation, publication, and renewal of certifica
provide strong mitigations. This includes but is not limited to: tes. For
example, Automatic Certificate Management Environment (ACME)
<xref target="RFC8555" format="default"/> provides a
mechanism to actively manage certificates through
automation and has been implemented by a number of certificate
authorities.</li>
<li>Monitor certificates to prevent accidental expiration of certi
ficates.</li>
<li>Choose a short, memorable authentication domain name for the s
ervice.</li>
</ul>
</dd>
</dl>
</section>
</section>
<section anchor="protocol-recommendations" numbered="true" toc="default"
>
<name>Protocol Recommendations</name>
<section anchor="dot" numbered="true" toc="default">
<name>DoT</name>
<dl newline="true">
<dt>DNS Privacy Threats:</dt>
<dd>
<ul spacing="normal">
<li>Known attacks on TLS, such as those described in <xref
target="RFC7457" format="default"/>.</li>
<li>Traffic analysis, for example: <xref
target="Pitfalls-of-DNS-Encryption" format="default"/> (focused
on DoT).</li>
<li>Potential for client tracking via transport identifiers.</li>
<li>Blocking of well-known ports (e.g., 853 for DoT).</li>
</ul>
</dd>
<dt>Mitigations:</dt>
<dd> <t>In the case of DoT, TLS profiles from <xref
target="RFC8310" section="9" sectionFormat="of"/> and the
"Countermeasures to DNS Traffic Analysis" from <xref
target="RFC8310" section="11.1" sectionFormat="of"/>
provide strong mitigations. This includes but is not
limited to:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>Adhering to <xref target="RFC7525" format="default"/>.</li>
<t>Adhering to <xref target="RFC7525"/>.</t> <li>Implementing only (D)TLS 1.2 or later, as specified in <xref t
<t>Implementing only (D)TLS 1.2 or later as specified in <xref arget="RFC8310" format="default"/>.</li>
target="RFC8310"/>.</t> <li>Implementing Extension Mechanisms for DNS (EDNS(0)) Padding
<t>Implementing EDNS(0) Padding <xref target="RFC7830"/> using the guidelines <xref target="RFC7830" format="default"/> using the guidelines
in in
<xref target="RFC8467"/> or a successor specification.</t> <xref target="RFC8467" format="default"/> or a successor specification.</li>
<t>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 <xref target="RFC5077"/> with TLS 1.2, section 2.2 of <xref
target="RFC8446"/>, or Domain
Name System (DNS) Cookies <xref target="RFC7873"/>.</t>
<t>A DoT privacy service on both port 853 and 443. If the operator deploys DoH
on the same IP address this requires the use of the 'dot' ALPN value <xref
target="dot-ALPN"/>.</t>
</list>
</t>
<t>Optimizations:
</t>
<t>
<list style="symbols">
<t>Concurrent processing of pipelined queries, returning responses as soon as
available, potentially out of order as specified in <xref
target="RFC7766"/>. This is often
called 'OOOR' - out-of-order responses (providing processing performance
similar to HTTP multiplexing).</t>
<t>Management of TLS connections to optimize performance for clients using
<xref target="RFC7766"/> and EDNS(0) Keepalive <xref target="RFC7828"/></t>
</list>
</t>
<t>Additional Options:
</t>
<t>Management of TLS connections to optimize performance for clients using DNS
Stateful Operations <xref target="RFC8490"/>.
</t>
</section>
<section anchor="doh" title="DoH"> <li>Servers should not degrade in any way the query service
<t>DNS Privacy Threats: level provided to
</t> clients that do not use any form of session resumption
<t> mechanism, such as TLS
<list style="symbols"> session resumption <xref target="RFC5077" format="default"/> with T
<t>Known attacks on TLS such as those described in <xref LS 1.2
target="RFC7457"/>.</t> (<xref target="RFC8446" section="2.2" sectionFormat="of"/>) or Doma
<t>Traffic analysis, for example: <xref in
target="DNS-Privacy-not-so-private"/>.</t> Name System (DNS) Cookies <xref target="RFC7873" format="default"/>
<t>Potential for client tracking via transport identifiers.</t> .</li>
</list>
</t>
<t>Mitigations:
</t>
<t>
<list style="symbols">
<t>Clients must be able to forgo the use of HTTP Cookies <xref
target="RFC6265"/> and still
use the service.</t>
<t>Use of HTTP/2 padding and/or EDNS(0) padding as described in Section 9 of
<xref target="RFC8484"/></t>
<t>Clients should not be required to include any headers beyond the absolute
minimum to obtain service from a DoH server. (See Section 6.1 of
<xref target="I-D.ietf-httpbis-bcp56bis"/>.)</t>
</list>
</t>
</section>
</section>
<section anchor="dnssec" title="DNSSEC"> <li>A DoT privacy service on both port 853 and 443. If the
<t>DNS Privacy Threats: operator deploys DoH
</t> on the same IP address, this requires the use of the "dot"
<t> Application-Layer Protocol Negotiation (ALPN) value <xref
<list style="symbols"> target="dot-ALPN" format="default"/>.</li>
<t>Users may be directed to bogus IP addresses which, depending on the </ul>
application, protocol and authentication method, might lead users to reveal </dd>
personal information to attackers. One example is a website that doesn't use
TLS or its TLS authentication can somehow be subverted.</t> <dt>Optimizations:</dt>
</list> <dd>
</t> <ul spacing="normal">
<t>Mitigations: <li>Concurrent processing of pipelined queries, returning
</t> responses as soon as
<t> available, potentially out of order, as specified in <xref target="
<list style="symbols"> RFC7766"
<t>All DNS privacy services must offer a DNS privacy service that performs format="default"/>. This is often
Domain called "OOOR" -- out-of-order responses (providing processing perfo
Name System Security Extensions (DNSSEC) validation. In addition they must be rmance
able to provide the DNSSEC RRs to the client so that it can perform its own similar to HTTP multiplexing).</li>
validation.</t> <li>Management of TLS connections to optimize performance for clie
</list> nts using
</t> <xref target="RFC7766" format="default"/> and EDNS(0) Keepalive
<t>The addition of encryption to DNS does not remove the need for DNSSEC <xref target="RFC7828" format="default"/></li>
<xref target="RFC4033"/> - they are independent and fully compatible </ul>
</dd>
<dt>Additional Options:</dt>
<dd>Management of TLS connections to optimize performance for client
s using DNS
Stateful Operations <xref target="RFC8490" format="default"/>.
</dd>
</dl>
</section>
<section anchor="doh" numbered="true" toc="default">
<name>DoH</name>
<dl newline="true">
<dt>DNS Privacy Threats:</dt>
<dd>
<ul spacing="normal">
<li>Known attacks on TLS, such as those described in <xref target=
"RFC7457" format="default"/>.</li>
<li>Traffic analysis, for example: <xref
target="DNS-Privacy-not-so-private" format="default"/> (focused
on DoH).</li>
<li>Potential for client tracking via transport identifiers.</li>
</ul>
</dd>
<dt>Mitigations:</dt>
<dd>
<ul spacing="normal">
<li>Clients must be able to forgo the use of HTTP cookies <xref
target="RFC6265" format="default"/> and still
use the service.</li>
<li>Use of HTTP/2 padding and/or EDNS(0) padding, as described in
<xref target="RFC8484" section="9" sectionFormat="of"/>.</li>
<li>Clients should not be required to include any headers beyond t
he absolute
minimum to obtain service from a DoH server. (See
<xref target="I-D.ietf-httpbis-bcp56bis" section="6.1" sectionFormat="of"/>.)</l
i>
</ul>
</dd>
</dl>
</section>
</section>
<section anchor="dnssec" numbered="true" toc="default">
<name>DNSSEC</name>
<dl newline="true">
<dt>DNS Privacy Threats:</dt>
<dd>Users may be directed to bogus IP addresses that, depending on t
he
application, protocol, and authentication method, might lead users to
reveal
personal information to attackers. One example is a website that does
n't use
TLS or whose TLS authentication can somehow be subverted.</dd>
<dt>Mitigations:</dt>
<dd>All DNS privacy services must offer a DNS privacy service that per
forms
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.</dd>
</dl>
<t>The addition of encryption to DNS does not remove the need for DNSS
EC
<xref target="RFC4033" format="default"/>; they are independent and fully compat
ible
protocols, protocols,
each solving different problems. The use of one does not diminish the need nor each solving different problems. The use of one does not diminish the need nor
the usefulness of the other. the usefulness of the other.
</t> </t>
<t>While the use of an authenticated and encrypted transport protects origin <t>While the use of an authenticated and encrypted transport protects
authentication and data integrity between a client and a DNS privacy service origin
it authentication and data integrity between a client and a DNS privacy se
provides no proof (for a non-validating client) that the data provided by the rvice,
DNS privacy service was actually DNSSEC authenticated. As with cleartext DNS it provides no proof (for a nonvalidating client) that the data provide
the d by the
user is still solely trusting the AD bit (if present) set by the resolver. DNS privacy service was actually DNSSEC authenticated. As with cleartex
t DNS,
the user is still solely trusting the Authentic Data (AD) bit (if
present) set by the resolver.
</t> </t>
<t>It should also be noted that the use of an encrypted transport for DNS <t>It should also be noted that the use of an encrypted transport for
actually DNS
solves many of the practical issues encountered by DNS validating clients e.g. actually solves many of the practical issues encountered by DNS validat
interference by middleboxes with cleartext DNS payloads is completely avoided. ing clients -- e.g.,
In this sense a validating client that uses a DNS privacy service which interference by middleboxes with cleartext DNS payloads is completely a
supports voided.
DNSSEC has a far simpler task in terms of DNSSEC Roadblock avoidance <xref In this sense, a validating client that uses a DNS privacy service that
target="RFC8027"/>. supports DNSSEC has a far simpler task in terms of DNSSEC roadblock avo
idance
<xref target="RFC8027" format="default"/>.
</t> </t>
</section> </section>
<section anchor="availability" numbered="true" toc="default">
<name>Availability</name>
<dl newline="true">
<dt>DNS Privacy Threats:</dt>
<section anchor="availability" title="Availability"> <dd>
<t>DNS Privacy Threats: A failing DNS privacy service could force the user to switch
</t> providers, fall back to cleartext, or accept no DNS service for
<t> the duration of the outage.
<list style="symbols"> </dd>
<t>A failed DNS privacy service could force the user to switch providers,
fallback to cleartext or accept no DNS service for the outage.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>A DNS privacy service should strive to engineer encrypted services to the
same
availability level as any unencrypted services they provide. Particular care
should to be taken to protect DNS privacy services against denial-of-service
attacks, as experience has shown that unavailability of DNS resolving because
of
attacks is a significant motivation for users to switch services. See, for
example Section IV-C of <xref target="Passive-Observations-of-a-Large-DNS"/>.
</t>
<t>Techniques such as those described in Section 10 of <xref
target="RFC7766"/> can be of use to operators to defend against such attacks.
</t>
</section>
<section anchor="service-options" title="Service options"> <dt>Mitigations:</dt>
<t>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Unfairly disadvantaging users of the privacy service with respect to the
services available. This could force the user to switch providers, fallback to
cleartext or accept no DNS service for the outage.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>A DNS privacy service should deliver the same level of service as offered
on
un-encrypted channels in terms of options such as filtering (or lack thereof),
DNSSEC validation, etc.
</t>
</section>
<section <dd><t>A DNS privacy service should strive to engineer encrypted servi
anchor="impact-of-encryption-on-monitoring-by-dns-privacy-service-operators" ces to the
title="Impact of Encryption on Monitoring by DNS Privacy Service same
Operators"> availability level as any unencrypted services they provide. Particular
<t>DNS Privacy Threats: care
</t> should to be taken to protect DNS privacy services against denial-of-se
<t> rvice
<list style="symbols"> (DoS) attacks, as experience has shown that unavailability of DNS resol
<t>Increased use of encryption can impact DNS privacy service operator ability ving because
to of attacks is a significant motivation for users to switch services. Se
monitor traffic and therefore manage their DNS servers <xref e, for
target="RFC8404"/>.</t> example, Section IV-C of <xref
</list> target="Passive-Observations-of-a-Large-DNS" format="default"/>.</t>
</t>
<t>Many monitoring solutions for DNS traffic rely on the plain text nature of <t>Techniques such as those described in <xref target="RFC7766" sectio
this n="10" sectionFormat="of"/> can be of use to operators to defend against such at
traffic and work by intercepting traffic on the wire, either using a separate tacks.
view on the connection between clients and the resolver, or as a separate </t>
process on the resolver system that inspects network traffic. Such solutions </dd>
will no longer function when traffic between clients and resolvers is </dl>
encrypted. </section>
Many DNS privacy service operators still have need to inspect DNS traffic, <section anchor="service-options" numbered="true" toc="default">
e.g., <name>Service Options</name>
to monitor for network security threats. Operators may therefore need to <dl newline="true">
invest
in alternative means of monitoring that relies on either the resolver software <dt>DNS Privacy Threats:</dt>
directly, or exporting DNS traffic from the resolver using e.g., <xref
target="dnstap"/>. <dd>Unfairly disadvantaging users of the privacy service with respect
</t> to the
<t>Optimization: services available. This could force the user to switch providers,
</t> fall back to
<t>When implementing alternative means for traffic monitoring, operators of a cleartext, or accept no DNS service for the duration of the outage.</dd
>
<dt>Mitigations:</dt>
<dd>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.
</dd>
</dl>
</section>
<section anchor="impact-of-encryption-on-monitoring-by-dns-privacy-servi
ce-operators" numbered="true" toc="default">
<name>Impact of Encryption on Monitoring by DNS Privacy Service Operat
ors</name>
<dl newline="true">
<dt>DNS Privacy Threats:</dt>
<dd>Increased use of encryption can impact a DNS privacy service opera
tor's ability
to monitor traffic and therefore manage their DNS servers <xref
target="RFC8404" format="default"/>.</dd>
</dl>
<t>Many monitoring solutions for DNS traffic rely on the plaintext nat
ure of
this
traffic and work by intercepting traffic on the wire, either using a se
parate
view on the connection between clients and the resolver, or as a separa
te
process on the resolver system that inspects network traffic. Such solu
tions
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, <xref target="dnstap" format="default"/>.
</t>
<dl newline="true">
<dt>Optimization:</dt>
<dd>When implementing alternative means for traffic monitoring, operat
ors of a
DNS DNS
privacy service should consider using privacy conscious means to do so (see privacy service should consider using privacy-conscious means to do so. See
section <xref target="data-at-rest-on-the-server"/> for more details on data <xref target="data-at-rest-on-the-server" format="default"/> for more details on
handling and also data
the discussion on the use of Bloom Filters in <xref handling and the discussion on the use of Bloom Filters in <xref
target="ip-address-techniques"/>. target="ip-address-techniques" format="default"/>.
</t> </dd>
</section> </dl>
</section>
<section anchor="limitations-of-fronting-a-dns-privacy-service-with-a-pu
re-tls-proxy" numbered="true" toc="default">
<name>Limitations of Fronting a DNS Privacy Service with a Pure TLS Pr
oxy</name>
<dl newline="true">
<section <dt>DNS Privacy Threats:</dt>
anchor="limitations-of-fronting-a-dns-privacy-service-with-a-pure-tls-proxy" <dd>
title="Limitations of fronting a DNS privacy service with a pure TLS <ul spacing="normal">
proxy"> <li>Limited ability to manage or monitor incoming connections using
<t>DNS Privacy Threats: DNS-specific
</t> techniques.</li>
<t> <li>Misconfiguration (e.g., of the target-server address in the
<list style="symbols"> proxy configuration) could lead to data leakage if the
<t>Limited ability to manage or monitor incoming connections using DNS proxy-to-target-server path
specific is not encrypted.</li>
techniques.</t> </ul>
<t>Misconfiguration (e.g., of the target server address in the proxy </dd>
configuration) could lead to data leakage if the proxy to target server path <dt>Optimization:</dt>
is not encrypted.</t>
</list> <dd><t>Some operators may choose to implement DoT using a TLS proxy (e
</t> .g.,
<t>Optimization: <xref target="nginx" format="default"/>, <xref target="haproxy" format="default"
</t> />, or
<t>Some operators may choose to implement DoT using a TLS proxy (e.g. <xref target="stunnel" format="default"/>) in front of
<xref target="nginx"/>, <xref target="haproxy"/>, or
<xref target="stunnel"/>) in front of
a DNS nameserver because of proven robustness and capacity when handling large a DNS nameserver because of proven robustness and capacity when handling large
numbers of client connections, load balancing capabilities and good tooling. numbers of client connections, load-balancing capabilities, and good tooling.
Currently, however, because such proxies typically have no specific handling Currently, however, because such proxies typically have no specific handling
of of DNS as a protocol over TLS or DTLS, using them can restrict traffic managemen
DNS as a protocol over TLS or DTLS using them can restrict traffic management t
at at the proxy layer and the DNS server. For example, all traffic received by a
the proxy layer and at the DNS server. For example, all traffic received by a nameserver behind such a proxy will appear to originate from the proxy, and DNS
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),
techniques such as ACLs, RRL, or DNS64 will be hard or impossible to implement or DNS64 <xref target="RFC6147"/> will be hard or impossible to implement
in in
the nameserver. the nameserver.
</t> </t>
<t>Operators may choose to use a DNS aware proxy such as <t>Operators may choose to use a DNS-aware proxy, such as
<xref target="dnsdist"/> which offers custom options (similar to that <xref target="dnsdist" format="default"/>, that offers custom options (similar t
proposed in <xref target="I-D.bellis-dnsop-xpf"/>) to add source information o those
proposed in <xref target="I-D.bellis-dnsop-xpf" format="default"/>) to add sourc
e information
to packets to packets
to address this shortcoming. It should be noted that such options potentially to address this shortcoming. It should be noted that such options potentially
significantly increase the leaked information in the event of a significantly increase the leaked information in the event of a
misconfiguration. misconfiguration.
</t> </t>
</section> </dd>
</section> </dl>
</section>
</section>
<section anchor="data-at-rest-on-the-server" numbered="true" toc="default"
>
<name>Data at Rest on the Server</name>
<section anchor="data-handling" numbered="true" toc="default">
<name>Data Handling</name>
<dl newline="true">
<dt>Threats described in <xref target="RFC6973" format="default"/>:</d
t>
<dd>
<ul spacing="normal">
<li>Surveillance.</li>
<li>Stored-data compromise.</li>
<li>Correlation.</li>
<li>Identification.</li>
<li>Secondary use.</li>
<li>Disclosure.</li>
</ul>
</dd>
<section anchor="data-at-rest-on-the-server" title="Data at rest on the <dt>Other Threats</dt>
server"> <dd>
<ul spacing="normal">
<li>Contravention of legal requirements not to process user data.</l
i>
</ul>
</dd>
<dt>Mitigations:</dt>
<section anchor="data-handling" title="Data handling"> <dd><t>The following are recommendations relating to common activities
<t><xref target="RFC6973"/> Threats: for DNS
</t> service operators; in all cases, data retention should be minimized or
<t> completely
<list style="symbols"> avoided if possible for DNS privacy services. If data is retained, it s
<t>Surveillance.</t> hould be
<t>Stored data compromise.</t> encrypted and either aggregated, pseudonymized, or anonymized whenever
<t>Correlation.</t> possible.
<t>Identification.</t> In general, the principle of data minimization described in <xref
<t>Secondary use.</t> target="RFC6973" format="default"/> should be applied.</t>
<t>Disclosure.</t>
</list> <ul spacing="normal">
</t> <li>Transient data (e.g., data used for real-time monitoring and thr
<t>Other Threats eat
</t> analysis, which might be held only in memory) should be retained for
<t> the shortest
<list style="symbols"> possible period deemed operationally feasible.</li>
<t>Contravention of legal requirements not to process user data.</t> <li>The retention period of DNS traffic logs should be only as
</list> long as is required to sustain operation of the service and meet
</t> regulatory requirements, to the extent that they exist.</li>
<t>Mitigations: <li>DNS privacy services should not track users except for the parti
</t> cular
<t>The following are recommendations relating to common activities for DNS
service
operators and in all cases data retention should be minimized or completely
avoided if possible for DNS privacy services. If data is retained it should be
encrypted and either aggregated, pseudonymized, or anonymized whenever
possible.
In general the principle of data minimization described in <xref
target="RFC6973"/> should be
applied.
</t>
<t>
<list style="symbols">
<t>Transient data (e.g., that is used for real time monitoring and threat
analysis
which might be held only in memory) should be retained for the shortest
possible period deemed operationally feasible.</t>
<t>The retention period of DNS traffic logs should be only those required to
sustain operation of the service and, to the extent that such exists, meet
regulatory requirements.</t>
<t>DNS privacy services should not track users except for the particular
purpose purpose
of detecting and remedying technically malicious (e.g., DoS) or anomalous use of detecting and remedying technically malicious (e.g., DoS) or anomalous use
of the service.</t> of the service.</li>
<t>Data access should be minimized to only those personnel who require access <li>Data access should be minimized to only those personnel who requ
ire access
to to
perform operational duties. It should also be limited to anonymized or perform operational duties. It should also be limited to anonymized or
pseudonymized data where operationally feasible, with access to full logs (if pseudonymized data where operationally feasible, with access to full logs (if
any are held) only permitted when necessary.</t> any are held) only permitted when necessary.</li>
</list> </ul>
</t> </dd>
<t>Optimizations:
</t>
<t>
<list style="symbols">
<t>Consider use of full disk encryption for logs and data capture storage.</t>
</list>
</t>
</section>
<section anchor="data-minimization-of-network-traffic" title="Data <dt>Optimizations:</dt>
minimization of network traffic"> <dd>
<t>Data minimization refers to collecting, using, disclosing, and storing the <ul spacing="normal">
<li>Consider use of full-disk encryption for logs and data-capture s
torage.</li>
</ul>
</dd>
</dl>
</section>
<section anchor="data-minimization-of-network-traffic" numbered="true" t
oc="default">
<name>Data Minimization of Network Traffic</name>
<t>Data minimization refers to collecting, using, disclosing, and stor
ing the
minimal data necessary to perform a task, and this can be achieved by minimal data necessary to perform a task, and this can be achieved by
removing or obfuscating privacy-sensitive information in network traffic logs. 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 This is typically personal data or data that can be used to link a record to
an an individual, but it may also include other confidential information -- for
individual, but may also include revealing other confidential information, for example, on the structure of an internal corporate network.
example on the structure of an internal corporate network.
</t> </t>
<t>The problem of effectively ensuring that DNS traffic logs contain no or <t>The problem of effectively ensuring that DNS traffic logs contain n o or
minimal minimal
privacy-sensitive information is not one that currently has a generally agreed privacy-sensitive information is not one that currently has a generally agreed
solution or any standards to inform this discussion. This section presents an solution or any standards to inform this discussion. This section presents an
overview of current techniques to simply provide reference on the current overview of current techniques to simply provide reference on the current
status of this work. status of this work.
</t> </t>
<t>Research into data minimization techniques (and particularly IP address <t>Research into data minimization techniques (and particularly IP add
pseudonymization/anonymization) was sparked in the late 1990s/early 2000s, ress
pseudonymization/anonymization) was sparked in the late 1990s / early 2000s,
partly driven by the desire to share significant corpuses of traffic captures partly driven by the desire to share significant corpuses of traffic captures
for research purposes. Several techniques reflecting different requirements in for research purposes. Several techniques reflecting different requirements in
this area and different performance/resource tradeoffs emerged over the course 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 of the decade. Developments over the last decade have been both a blessing and
a a
curse; the large increase in size between an IPv4 and an IPv6 address, for 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 example, renders some techniques impractical, but also makes available a much
larger amount of input entropy, the better to resist brute force larger amount of input entropy, the better to resist brute-force
re-identification attacks that have grown in practicality over the period. re-identification attacks that have grown in practicality over the period.
</t> </t>
<t>Techniques employed may be broadly categorized as either anonymization or <t>Techniques employed may be broadly categorized as either anonymizat ion or
pseudonymization. The following discussion uses the definitions from <xref pseudonymization. The following discussion uses the definitions from <xref
target="RFC6973"/> target="RFC6973" section="3" sectionFormat="comma"/>, with additional
Section 3, with additional observations from <xref observations from <xref target="van-Dijkhuizen-et-al" format="default"/>.
target="van-Dijkhuizen-et-al."/> </t>
</t> <ul spacing="normal">
<t> <li>Anonymization. To enable anonymity of an individual, there must
<list style="symbols"> exist a set
<t>Anonymization. To enable anonymity of an individual, there must exist a set
of of
individuals that appear to have the same attribute(s) as the individual. To individuals that appear to have the same attribute(s) as the individual. To
the attacker or the observer, these individuals must appear indistinguishable the attacker or the observer, these individuals must appear indistinguishable
from each other.</t> from each other.</li>
<t>Pseudonymization. The true identity is deterministically replaced with an <li>Pseudonymization. The true identity is deterministically replace
d with an
alternate identity (a pseudonym). When the pseudonymization schema is known, alternate identity (a pseudonym). When the pseudonymization schema is known,
the process can be reversed, so the original identity becomes known again.</t> the process can be reversed, so the original identity becomes known again.</li>
</list> </ul>
</t> <t>In practice, there is a fine line between the two; for example,
<t>In practice there is a fine line between the two; for example, how to it is difficult to categorize a deterministic algorithm for data
categorize minimization of IP addresses that produces a group of pseudonyms for
a deterministic algorithm for data minimization of IP addresses that produces a single given address.
a
group of pseudonyms for a single given address.
</t> </t>
</section> </section>
<section anchor="ip-address-pseudonymization-and-anonymization-methods"
<section anchor="ip-address-pseudonymization-and-anonymization-methods" numbered="true" toc="default">
title="IP address pseudonymization and anonymization methods"> <name>IP Address Pseudonymization and Anonymization Methods</name>
<t>A major privacy risk in DNS is connecting DNS queries to an individual and <t>A major privacy risk in DNS is connecting DNS queries to an individ
the ual, and
major vector for this in DNS traffic is the client IP address. the major vector for this in DNS traffic is the client IP address.
</t> </t>
<t>There is active discussion in the space of effective pseudonymization of IP <t>There is active discussion in the space of effective pseudonymizati
addresses in DNS traffic logs, however there seems to be no single solution on of IP
that addresses in DNS traffic logs; however, there seems to be no single sol
is widely recognized as suitable for all or most use cases. There are also as ution
yet no standards for this that are unencumbered by patents. 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.
</t> </t>
<t><xref target="ip-address-techniques"/> provides a more detailed survey of <t><xref target="ip-address-techniques" format="default"/> provides a more detailed survey of
various techniques various techniques
employed or under development in 2019. employed or under development in 2020.
</t> </t>
</section> </section>
<section anchor="pseudonymization-anonymization-or-discarding-of-other-c
orrelation-data" numbered="true" toc="default">
<name>Pseudonymization, Anonymization, or Discarding of Other Correlat
ion Data</name>
<dl newline="true">
<dt>DNS Privacy Threats:</dt>
<dd>
<ul spacing="normal">
<li>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, o
r
OS-specific updates).</li>
<li>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.</li>
<li>Correlation of queries on multiple TCP sessions originating from
the same
IP address.</li>
<li>Correlating of queries on multiple TLS sessions originating from
the same
client, including via session-resumption mechanisms.</li>
<section <li>Resolvers <em>might</em> receive client identifiers -- e.g.,
anchor="pseudonymization-anonymization-or-discarding-of-other-correlation-da Media Access Control (MAC) addresses in EDNS(0)
ta" options. Some customer premises equipment (CPE) devices are known
title="Pseudonymization, anonymization, or discarding of other correlation to add them
data"> <xref target="MAC-address-EDNS" format="default"/>.</li>
<t>DNS Privacy Threats: </ul>
</t> </dd>
<t> <dt>Mitigations:</dt>
<list style="symbols"> <dd>
<t>Fingerprinting of the client OS via various means including: IP <ul spacing="normal">
TTL/Hoplimit, <li>Data minimization or discarding of such correlation data.</li>
TCP parameters (e.g., window size, ECN support, SACK), OS specific DNS query </ul>
patterns (e.g., for network connectivity, captive portal detection, or OS </dd>
specific updates).</t> </dl>
<t>Fingerprinting of the client application or TLS library by, e.g., HTTP </section>
headers
(e.g., User-Agent, Accept, Accept-Encoding), TLS version/Cipher suite
combinations, or other connection parameters.</t>
<t>Correlation of queries on multiple TCP sessions originating from the same
IP
address.</t>
<t>Correlating of queries on multiple TLS sessions originating from the same
client, including via session resumption mechanisms.</t>
<t>Resolvers <spanx style="emph">might</spanx> receive client identifiers,
e.g., MAC addresses in EDNS(0)
options - some Customer-premises equipment (CPE) devices are known to add them
<xref target="MAC-address-EDNS"/>.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>
<list style="symbols">
<t>Data minimization or discarding of such correlation data.</t>
</list>
</t>
</section>
<section anchor="cache-snooping" title="Cache snooping"> <section anchor="cache-snooping" numbered="true" toc="default">
<t><xref target="RFC6973"/> Threats: <name>Cache Snooping</name>
</t>
<t> <dl newline="true">
<list style="symbols">
<t>Surveillance: <dt>Threats described in <xref target="RFC6973" format="default"/>:</dt>
<list style="symbols"> <dd>
<t>Profiling of client queries by malicious third parties.</t>
</list></t> <dl newline="true">
</list>
</t> <dt>Surveillance:</dt>
<t>Mitigations: <dd>Profiling of client queries by malicious third parties.</dd>
</t> </dl>
<t> </dd>
<list style="symbols">
<t>See <xref target="ISC-Knowledge-database-on-cache-snooping"/> for an <dt>Mitigations:</dt>
<dd>See <xref target="ISC-Knowledge-database-on-cache-snooping" form
at="default"/> for an
example discussion on example discussion on
defending against cache snooping. Options proposed include limiting access to defending against cache snooping. Options proposed include limiting access to
a server and limiting non-recursive queries.</t> a server and limiting nonrecursive queries.</dd>
</list> </dl>
</t>
</section>
</section>
<section anchor="data-sent-onwards-from-the-server" title="Data sent onwards </section>
from the server"> </section>
<t>In this section we consider both data sent on the wire in upstream queries <section anchor="data-sent-onwards-from-the-server" numbered="true" toc="d
efault">
<name>Data Sent Onwards from the Server</name>
<t>In this section, we consider both data sent on the wire in upstream q
ueries
and and
data shared with third parties. data shared with third parties.
</t> </t>
<section anchor="protocol-recommendations-1" numbered="true" toc="defaul
t">
<name>Protocol Recommendations</name>
<dl newline="true">
<section anchor="protocol-recommendations-1" title="Protocol recommendations"> <dt>Threats described in <xref target="RFC6973" format="default"/>:</d
<t><xref target="RFC6973"/> Threats: t>
</t> <dd>
<t> <dl newline="true">
<list style="symbols">
<t>Surveillance: <dt>Surveillance:</dt>
<list style="symbols">
<t>Transmission of identifying data upstream.</t> <dd>Transmission of identifying data upstream.</dd>
</list></t> </dl>
</list> </dd>
</t> <dt>Mitigations:</dt>
<t>Mitigations:
</t> <dd><t>The server should:</t>
<t>As specified in <xref target="RFC8310"/> for DoT but applicable to any DNS
Privacy <ul spacing="normal">
services the server should:
</t> <li>implement QNAME minimization <xref target="RFC7816"
<t> format="default"/>.</li>
<list style="symbols"> <li>honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
<t>Implement QNAME minimization <xref target="RFC7816"/>.</t> EDNS(0)
<t>Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the EDNS(0) Client Subnet (ECS) option (<xref target="RFC7871" section="7.1.2"
Client Subnet (ECS) option (<xref target="RFC7871"/> Section 7.1.2).</t> sectionFormat="comma"/>). This is as specified in <xref target="RFC8310"/> for
</list> DoT but
</t> applicable to any DNS
<t>Optimizations: privacy service.</li>
</t> </ul>
<t> </dd>
<list style="symbols">
<t>As per Section 2 of <xref target="RFC7871"/> the server should either: <dt>Optimizations:</dt>
<list style="symbols">
<t>not use the ECS option in upstream queries at all, or</t> <dd><t>As per <xref target="RFC7871" section="2"
<t>offer alternative services, one that sends ECS and one that does not.</t> sectionFormat="of"/>, the server should either:</t>
</list></t> <ul spacing="normal">
</list> <li>not use the ECS option in upstream queries at all, or</li>
</t> <li>offer alternative services, one that sends ECS and one that
<t>If operators do offer a service that sends the ECS options upstream they does not.</li>
</ul>
</dd>
</dl>
<t>If operators do offer a service that sends the ECS options upstream
, they
should should
use the shortest prefix that is operationally feasible and ideally use the shortest prefix that is operationally feasible and ideally
use a policy of allowlisting upstream servers to send ECS to in order to 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 reduce data leakage. Operators should make clear in any policy statement what
prefix length they actually send and the specific policy used. prefix length they actually send and the specific policy used.
</t> </t>
<t>Allowlisting has the benefit that not only does the operator know which <t>Allowlisting has the benefit that not only does the operator know w
upstream hich
servers can use ECS but also allows the operator to decide which upstream upstream
servers apply privacy policies that the operator is happy with. However some servers can use ECS, but also the operator can decide which upstream
operators consider allowlisting to incur significant operational overhead servers apply privacy policies that the operator is happy with. However
compared to dynamic detection of ECS support on authoritative servers. , some
</t> operators consider allowlisting to incur significant operational overhe
<t>Additional options: ad
compared to dynamic detection of ECS support on authoritative servers.
</t> </t>
<t> <t>Additional options:
<list style="symbols">
<t>Aggressive Use of DNSSEC-Validated Cache <xref target="RFC8198"/> and <xref
target="RFC8020"/>
(NXDOMAIN: There Really Is Nothing Underneath) to reduce the number of queries
to authoritative servers to increase privacy.</t>
<t>Run a copy of the root zone on loopback <xref target="RFC8806"/> to avoid
making queries to
the root servers that might leak information.</t>
</list>
</t> </t>
</section> <ul spacing="normal">
<li>"Aggressive Use of DNSSEC-Validated Cache" <xref
<section anchor="client-query-obfuscation" title="Client query obfuscation"> target="RFC8198" format="default"/> and "NXDOMAIN: There Really Is
<t>Additional options: Nothing Underneath" <xref target="RFC8020"
format="default"/> to reduce the number of queries
to authoritative servers to increase privacy.</li>
<li>Run a local copy of the root zone <xref target="RFC8806"
format="default"/> to avoid making queries to the root servers
that might leak information.</li>
</ul>
</section>
<section anchor="client-query-obfuscation" numbered="true" toc="default"
>
<name>Client Query Obfuscation</name>
<t>Additional options:
</t> </t>
<t>Since queries from recursive resolvers to authoritative servers are <t>Since queries from recursive resolvers to authoritative servers are
performed performed
using cleartext (at the time of writing), resolver services need to consider using cleartext (at the time of writing), resolver services need to consider
the the
extent to which they may be directly leaking information about their client 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 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 further. Note that, even when all the relevant techniques described above are
employed there may still be attacks possible, e.g. employed, there may still be attacks possible -- e.g.,
<xref target="Pitfalls-of-DNS-Encryption"/>. For example, a resolver with a <xref target="Pitfalls-of-DNS-Encryption" format="default"/>. For example, a res
olver with a
very small very small
community of users risks exposing data in this way and ought to obfuscate this 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 traffic by mixing it with "generated" traffic to make client characterization
harder. The resolver could also employ aggressive pre-fetch techniques as a harder. The resolver could also employ aggressive prefetch techniques as a
further measure to counter traffic analysis. further measure to counter traffic analysis.
</t> </t>
<t>At the time of writing there are no standardized or widely recognized <t>At the time of writing, there are no standardized or widely recogni zed
techniques techniques
to perform such obfuscation or bulk pre-fetches. to perform such obfuscation or bulk prefetches.
</t> </t>
<t>Another technique that particularly small operators may consider is <t>Another technique that particularly small operators may consider is
forwarding forwarding
local traffic to a larger resolver (with a privacy policy that aligns with local traffic to a larger resolver (with a privacy policy that aligns with
their their
own practices) over an encrypted protocol so that the upstream queries are own practices) over an encrypted protocol, so that the upstream queries are
obfuscated among those of the large resolver. obfuscated among those of the large resolver.
</t> </t>
</section> </section>
<section anchor="data-sharing" numbered="true" toc="default">
<name>Data Sharing</name>
<dl newline="true">
<dt>Threats described in <xref target="RFC6973" format="default"/>:</
dt>
<dd>
<ul spacing="normal">
<li>Surveillance.</li>
<li>Stored-data compromise.</li>
<li>Correlation.</li>
<li>Identification.</li>
<li>Secondary use.</li>
<li>Disclosure.</li>
</ul>
</dd>
<dt>DNS Privacy Threats:</dt>
<section anchor="data-sharing" title="Data sharing"> <dd>Contravention of legal requirements not to process user data.</dd>
<t><xref target="RFC6973"/> Threats:
</t> <dt>Mitigations:</dt>
<t>
<list style="symbols"> <dd> <t>Operators should not share identifiable data with third parties
<t>Surveillance.</t> .
<t>Stored data compromise.</t>
<t>Correlation.</t>
<t>Identification.</t>
<t>Secondary use.</t>
<t>Disclosure.</t>
</list>
</t>
<t>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Contravention of legal requirements not to process user data.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>Operators should not share identifiable data with third-parties.
</t> </t>
<t>If operators choose to share identifiable data with third-parties in <t>If operators choose to share identifiable data with third parties i
specific n
circumstance they should publish the terms under which data is shared. specific circumstances, they should publish the terms under which data
is shared.
</t> </t>
<t>Operators should consider including specific guidelines for the collection <t>Operators should consider including specific guidelines for the col lection
of of
aggregated and/or anonymized data for research purposes, within or outside of aggregated and/or anonymized data for research purposes, within or outside of
their own organization. This can benefit not only the operator (through their own organization. This can benefit not only the operator (through
inclusion in novel research) but also the wider Internet community. See the inclusion in novel research) but also the wider Internet community. See the
policy published by SURFnet <xref target="SURFnet-policy"/> on data sharing policy published by SURFnet <xref target="SURFnet-policy" format="default"/> on data sharing
for research as for research as
an example. an example.
</t> </t>
</section> </dd>
</section> </dl>
</section> </section>
</section>
<section anchor="recursive-operator-privacy-statement-rps" title="Recursive </section>
operator Privacy Statement (RPS)"> <section anchor="recursive-operator-privacy-statement-rps" numbered="true" t
<t>To be compliant with this Best Common Practices document, a DNS recursive oc="default">
operator SHOULD publish a Recursive operator Privacy Statement (RPS). Adopting <name>Recursive Operator Privacy Statement (RPS)</name>
<t>To be compliant with this Best Current Practice document, a DNS recursi
ve
operator <bcp14>SHOULD</bcp14> publish a Recursive operator Privacy Statement (R
PS). Adopting
the the
outline, and including the headings in the order provided, is a benefit to outline, and including the headings in the order provided, is a benefit to
persons comparing RPSs from multiple operators. persons comparing RPSs from multiple operators.
</t> </t>
<t><xref target="current-policy-and-privacy-statements"/> provides a <t><xref target="current-policy-and-privacy-statements" format="default"/> provides a
comparison of some existing comparison of some existing
policy and privacy statements. policy and privacy statements.
</t> </t>
<section anchor="outline-of-an-rps" numbered="true" toc="default">
<section anchor="outline-of-an-rps" title="Outline of an RPS"> <name>Outline of an RPS</name>
<t>The contents of <xref target="policy"/> and <xref target="practice"/> are <t>The contents of Sections <xref target="policy" format="counter"/> and
<xref
target="practice" format="counter"/> are
non-normative, other than the non-normative, other than the
order of the headings. Material under each topic is present to assist the order of the headings. Material under each topic is present to assist the
operator developing their own RPS and: operator developing their own RPS. This material:
</t>
<t>
<list style="symbols">
<t>Relates <spanx style="emph">only</spanx> to matters around to the technical
operation of DNS privacy services, and not on any other matters.</t>
<t>Does not attempt to offer an exhaustive list for the contents of an
RPS.</t>
<t>Is not intended to form the basis of any legal/compliance
documentation.</t>
</list>
</t> </t>
<t><xref target="example-rps"/> provides an example (also non-normative) of an <ul spacing="normal">
<li>Relates <em>only</em> to matters around the technical
operation of DNS privacy services, and no other matters.</li>
<li>Does not attempt to offer an exhaustive list for the contents of a
n
RPS.</li>
<li>Is not intended to form the basis of any legal/compliance
documentation.</li>
</ul>
<t><xref target="example-rps" format="default"/> provides an example (al
so non-normative) of an
RPS RPS
statement for a specific operator scenario. statement for a specific operator scenario.
</t> </t>
<section anchor="policy" numbered="true" toc="default">
<section anchor="policy" title="Policy"> <name>Policy</name>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>Treatment of IP addresses. Make an explicit statement that IP ad
<t>Treatment of IP addresses. Make an explicit statement that IP addresses are dresses are
treated as personal data.</t> treated as personal data.</li>
<t>Data collection and sharing. Specify clearly what data (including IP <li>
addresses) <t>Data collection and sharing. Specify clearly what data (includi
is: ng IP
<list style="symbols"> addresses) is:
<t>Collected and retained by the operator, and for what period it is </t>
retained.</t> <ul spacing="normal">
<t>Shared with partners.</t> <li>Collected and retained by the operator, and for what period
<t>Shared, sold, or rented to third-parties. it is
retained.</li>
<vspace/></t> <li>Shared with partners.</li>
</list> <li>
and in each case whether it is aggregated, pseudonymized, or anonymized and <t>Shared, sold, or rented to third parties.
the conditions of data transfer. Where possible provide details of the </t>
techniques used for the above data minimizations.</t> <t/>
<t>Exceptions. Specify any exceptions to the above, for example, technically </li>
malicious or anomalous behavior.</t> </ul>
<t>Associated entities. Declare and explicitly enumerate any partners, <t>
third-party affiliations, or sources of funding.</t> In each case, specify whether data is aggregated, pseudonymized,
<t>Correlation. Whether user DNS data is correlated or combined with any other or anonymized and
personal information held by the operator.</t> the conditions of data transfer. Where possible provide details o
<t>Result filtering. This section should explain whether the operator filters, f the
edits or alters in any way the replies that it receives from the authoritative techniques used for the above data minimizations.</t>
servers for each DNS zone, before forwarding them to the clients. For each </li>
<li>Exceptions. Specify any exceptions to the above -- for example,
technically
malicious or anomalous behavior.</li>
<li>Associated entities. Declare and explicitly enumerate any partne
rs,
third-party affiliations, or sources of funding.</li>
<li>Correlation. Whether user DNS data is correlated or combined wit
h any other
personal information held by the operator.</li>
<li>
<t>Result filtering. This section should explain whether the opera
tor 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 category listed below, the operator should also specify how the filtering
lists lists
are created and managed, whether it employs any third-party sources for such are created and managed, whether it employs any third-party sources for such
lists, and which ones. lists, and which ones.
<list style="symbols"> </t>
<t>Specify if any replies are being filtered out or altered for network and <ul spacing="normal">
computer security reasons (e.g., preventing connections to <li>Specify if any replies are being filtered out or altered for
malware-spreading websites or botnet control servers).</t> network- and
<t>Specify if any replies are being filtered out or altered for mandatory computer-security reasons (e.g., preventing connections to
malware-spreading websites or botnet control servers).</li>
<li>Specify if any replies are being filtered out or altered for
mandatory
legal reasons, due to applicable legislation or binding orders by courts legal reasons, due to applicable legislation or binding orders by courts
and other public authorities.</t> and other public authorities.</li>
<t>Specify if any replies are being filtered out or altered for voluntary <li>Specify if any replies are being filtered out or altered for
voluntary
legal reasons, due to an internal policy by the operator aiming at legal reasons, due to an internal policy by the operator aiming at
reducing potential legal risks.</t> reducing potential legal risks.</li>
<t>Specify if any replies are being filtered out or altered for any other <li>Specify if any replies are being filtered out or altered for
reason, including commercial ones.</t> any other
</list></t> reason, including commercial ones.</li>
</list> </ul>
</t> </li>
</section> </ol>
</section>
<section anchor="practice" numbered="true" toc="default">
<name>Practice</name>
<section anchor="practice" title="Practice">
<t>[NOTE FOR RFC EDITOR: Please update this section to use letters for the
sub-bullet points instead of numbers. This was not done during review because
the markdown tool used to write the document did not support it.]
</t>
<t>Communicate the current operational practices of the service. <t>Communicate the current operational practices of the service.
</t> </t>
<t>
<list style="numbers">
<t>Deviations. Specify any temporary or permanent deviations from the policy
for
operational reasons.</t>
<t>Client facing capabilities. With reference to each subsection of
<xref target="on-the-wire-between-client-and-server"/> provide specific
details of which
capabilities (transport, DNSSEC, padding, etc.) are provided on which client
facing addresses/port combination or DoH URI template. For
<xref target="authentication-of-dns-privacy-services"/>, clearly specify which
specific
authentication mechanisms are supported for each endpoint that offers DoT:
<list style="numbers">
<t>The authentication domain name to be used (if any).</t>
<t>The SPKI pin sets to be used (if any) and policy for rolling keys.
<vspace/></t> <ol spacing="normal">
</list></t> <li>Deviations. Specify any temporary or permanent deviations from the policy
<t>Upstream capabilities. With reference to section for operational reasons.</li>
<xref target="data-sent-onwards-from-the-server"/> provide specific details of <li>
which <t>Client-facing capabilities. With reference to each subsection o
capabilities are provided upstream for data sent to authoritative servers.</t> f
<t>Support. Provide contact/support information for the service.</t> <xref target="on-the-wire-between-client-and-server" format="defaul
<t>Data Processing. This section can optionally communicate links to and the t"/>, provide specific
high level contents of any separate statements the operator has published details of which
which capabilities (transport, DNSSEC, padding, etc.) are provided on
cover applicable data processing legislation or agreements with regard to the which client-facing addresses/port combination or DoH URI
location(s) of service provision.</t> template. For
</list> <xref target="authentication-of-dns-privacy-services"
format="default"/>, clearly specify which specific
authentication mechanisms are supported for each endpoint that offe
rs DoT:
</t> </t>
</section> <ol spacing="normal" type="a">
</section> <li>The authentication domain name to be used (if any).</li>
<li>
<section anchor="enforcementaccountability" <t>The SPKI pin sets to be used (if any) and policy for rollin
title="Enforcement/accountability"> g keys.
<t>Transparency reports may help with building user trust that operators </t>
<t/>
</li>
</ol>
</li>
<li>Upstream capabilities. With reference to
<xref target="data-sent-onwards-from-the-server"
format="default"/>, provide specific details of
which capabilities are provided upstream for data sent to authoritati
ve servers.</li>
<li>Support. Provide contact/support information for the service.</l
i>
<li>Data Processing. This section can optionally communicate links t
o, and the
high-level contents of, any separate statements the operator has publ
ished
that cover applicable data-processing legislation or agreements with
regard to the
location(s) of service provision.</li>
</ol>
</section>
</section>
<section anchor="enforcementaccountability" numbered="true" toc="default">
<name>Enforcement/Accountability</name>
<t>Transparency reports may help with building user trust that operators
adhere to adhere to
their policies and practices. their policies and practices.
</t> </t>
<t>Independent monitoring or analysis could be performed where possible of: <t>Where possible, independent monitoring or analysis could be performed
</t> of:
<t>
<list style="symbols">
<t>ECS, QNAME minimization, EDNS(0) padding, etc.</t>
<t>Filtering.</t>
<t>Uptime.</t>
</list>
</t> </t>
<t>This is by analogy with several TLS or website analysis tools that are <ul spacing="normal">
currently available e.g., <xref target="SSL-Labs"/> or <li>ECS, QNAME minimization, EDNS(0) padding, etc.</li>
<xref target="Internet.nl"/>. <li>Filtering.</li>
<li>Uptime.</li>
</ul>
<t>This is by analogy with several TLS or website-analysis tools that ar
e
currently available -- e.g., <xref target="SSL-Labs" format="default"/> or
<xref target="Internet.nl" format="default"/>.
</t> </t>
<t>Additionally operators could choose to engage the services of a third party <t>Additionally, operators could choose to engage the services of a thir d-party
auditor to verify their compliance with their published RPS. auditor to verify their compliance with their published RPS.
</t> </t>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA considerations"> <name>IANA Considerations</name>
<t>None <t>This document has no IANA actions.</t>
</t> </section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="security-considerations" title="Security considerations"> <t>Security considerations for DNS over TCP are given in <xref target="RFC
<t>Security considerations for DNS over TCP are given in <xref 7766" format="default"/>, many of which
target="RFC7766"/>, many of which are generally applicable to session-based DNS. Guidance on operational
are generally applicable to session based DNS. Guidance on operational requirements for DNS over TCP are also available in <xref
requirements for DNS over TCP are also available in target="I-D.ietf-dnsop-dns-tcp-requirements"/>. Security considerations for
[I-D.dnsop-dns-tcp-requirements]. Security considerations for DoT are given in DoT are given in <xref target="RFC7858" /> and <xref target="RFC8310"
[RFC7858] and <xref target="RFC8310"/>, those for DoH in [RFC8484]. format="default"/>, and those for DoH in <xref target="RFC8484"/>.
</t> </t>
<t>Security considerations for DNSSEC are given in <xref target="RFC4033"/>, <t>Security considerations for DNSSEC are given in <xref target="RFC4033"
<xref target="RFC4034"/> and <xref target="RFC4035"/>. format="default"/>,
<xref target="RFC4034" format="default"/>, and <xref target="RFC4035" format="de
fault"/>.
</t> </t>
</section> </section>
</middle>
<back>
<section anchor="acknowledgements" title="Acknowledgements"> <displayreference target="I-D.bellis-dnsop-xpf" to="DNS-XPF"/>
<t>Many thanks to Amelia Andersdotter for a very thorough review of the first <displayreference target="I-D.ietf-dnsop-dns-tcp-requirements" to="DNS-OVER-TCP"
draft />
of this document and Stephen Farrell for a thorough review at WGLC and for <displayreference target="I-D.ietf-httpbis-bcp56bis" to="BUILD-W-HTTP"/>
suggesting the inclusion of an example RPS. Thanks to John Todd for
discussions on this topic, and to Stephane Bortzmeyer, Puneet Sood and
Vittorio
Bertola for review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman,
Dan York, Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to
Loganaden Velvindron for useful updates to the text.
</t>
<t>Sara Dickinson thanks the Open Technology Fund for a grant to support the
work
on this document.
</t>
</section>
<section anchor="contributors" title="Contributors"> <references>
<t>The below individuals contributed significantly to the document: <name>References</name>
</t> <references>
<t>John Dickinson <name>Normative References</name>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Sinodun Internet Technologies FC.2119.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Magdalen Centre FC.4033.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Oxford Science Park FC.5280.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Oxford OX4 4GA FC.6973.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
United Kingdom FC.7457.xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Jim Hague FC.7525.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Sinodun Internet Technologies FC.7766.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Magdalen Centre FC.7816.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Oxford Science Park FC.7828.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Oxford OX4 4GA FC.7830.xml"/>
<vspace/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
United Kingdom FC.7858.xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.7871.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8198.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8310.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8467.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8490.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8499.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8806.xml"/>
</references>
<references>
<name>Informative References</name>
<section anchor="changelog" title="Changelog"> <reference anchor="Bloom-filter" target="http://dl.ifip.org/db/conf/im/i
<t>draft-ietf-dprive-bcp-op-13 m2019/189282.pdf">
</t> <front>
<t> <title>Privacy-Conscious Threat Intelligence Using DNSBLOOM</title>
<list style="symbols"> <author initials="R." surname="van Rijswijk-Deij"> </author>
<t>Minor edits</t> <author initials="G." surname="Rijnders"> </author>
</list> <author initials="M." surname="Bomhoff"> </author>
</t> <author initials="L." surname="Allodi"> </author>
<t>draft-ietf-dprive-bcp-op-12 <date year="2019"/>
</t> </front>
<t> <refcontent>IFIP/IEEE International Symposium on Integrated Network
<list style="symbols"> Management (IM2019)</refcontent>
<t>Change DROP to RPS throughout</t> </reference>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-11
</t>
<t>
<list style="symbols">
<t>Improve text around use of normative language</t>
<t>Fix section 5.1.3.2 bullets</t>
<t>Improve text in 6.1.2. item 2.</t>
<t>Rework text of 6.1.2. item 5 and update example DROP</t>
<t>Various editorial improvements</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-10
</t>
<t>
<list style="symbols">
<t>Remove direct references to draft-ietf-dprive-rfc7626-bis, instead have one
general reference RFC7626</t>
<t>Clarify that the DROP statement outline is non-normative and add some
further
qualifications about content</t>
<t>Update wording on data sharing to remove explicit discussion of consent</t>
<t>Move table in section 5.2.3 to an appendix</t>
<t>Move section 6.2 to an appendix</t>
<t>Corrections to references, typos and editorial updates from initial IESG
comments.</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-09
</t>
<t>
<list style="symbols">
<t>Fix references so they match the correct section numbers in
draft-ietf-dprive-rfc7626-bis-05</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-08
</t>
<t>
<list style="symbols">
<t>Address IETF Last call comments.</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-07
</t>
<t>
<list style="symbols">
<t>Editorial changes following AD review.</t>
<t>Change all URIs to Informational References.</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-06
</t>
<t>
<list style="symbols">
<t>Final minor changes from second WGLC.</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-05
</t>
<t>
<list style="symbols">
<t>Remove some text on consent:
<list style="symbols">
<t>Paragraph 2 in section 5.3.3</t>
<t>Item 6 in the DROP Practice statement (and example)</t>
</list></t>
<t>Remove .onion and TLSA options</t>
<t>Include ACME as a reference for certificate management</t>
<t>Update text on session resumption usage</t>
<t>Update section 5.2.4 on client fingerprinting</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-04
</t>
<t>
<list style="symbols">
<t>Change DPPPS to DROP (DNS Recursive Operator Privacy) statement</t>
<t>Update structure of DROP slightly</t>
<t>Add example DROP statement</t>
<t>Add text about restricting access to full logs</t>
<t>Move table in section 5.2.3 from SVG to inline table</t>
<t>Fix many editorial and reference nits</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-03
</t>
<t>
<list style="symbols">
<t>Add paragraph about operational impact</t>
<t>Move DNSSEC requirement out of the Appendix into main text as a privacy
threat
that should be mitigated</t>
<t>Add TLS version/Cipher suite as tracking threat</t>
<t>Add reference to Mozilla TRR policy</t>
<t>Remove several TODOs and QUESTIONS.</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-02
</t>
<t>
<list style="symbols">
<t>Change 'open resolver' for 'public resolver'</t>
<t>Minor editorial changes</t>
<t>Remove recommendation to run a separate TLS 1.3 service</t>
<t>Move TLSA to purely a optimization in Section 5.2.1</t>
<t>Update reference on minimal DoH headers.</t>
<t>Add reference on user switching provider after service issues in Section
5.1.4</t>
<t>Add text in Section 5.1.6 on impact on operators.</t>
<t>Add text on additional threat to TLS proxy use (Section 5.1.7)</t>
<t>Add reference in Section 5.3.1 on example policies.</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-01
</t>
<t>
<list style="symbols">
<t>Many minor editorial fixes</t>
<t>Update DoH reference to RFC8484 and add more text on DoH</t>
<t>Split threat descriptions into ones directly referencing RFC6973 and other
DNS Privacy threats</t>
<t>Improve threat descriptions throughout</t>
<t>Remove reference to the DNSSEC TLS Chain Extension draft until new version
submitted.</t>
<t>Clarify use of allowlisting for ECS</t>
<t>Re-structure the DPPPS, add Result filtering section.</t>
<t>Remove the direct inclusion of privacy policy comparison, now just
reference dnsprivacy.org and an example of such work.</t>
<t>Add an appendix briefly discussing DNSSEC</t>
<t>Update affiliation of 1 author</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-00
</t>
<t>
<list style="symbols">
<t>Initial commit of re-named document after adoption to replace
draft-dickinson-dprive-bcp-op-01</t>
</list>
</t>
<t>
</t> <reference anchor="Brekne-and-Arnes"
</section> target="https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2c
ddac5fda164fb2138a44.pdf">
<front>
<title>Circumventing IP-address pseudonymization</title>
<author initials="T." surname="Brekne"> </author>
<author initials="A." surname="Årnes"> </author>
<date year="2005"/>
</front>
<seriesInfo name="Communications and" value="Computer Networks" />
</reference>
</middle> <reference anchor="Crypto-PAn"
<back> target="https://github.com/CESNET/ipfixcol/tree/master/base/sr
<references title="Normative References"> c/intermediate/anonymization/Crypto-PAn">
<?rfc <front>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.x <title>Crypto-PAn</title>
ml"?> <author>
<?rfc <organization>CESNET</organization>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.x </author>
ml"?> <date year="2015" month="March"/>
<?rfc </front>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.x <seriesInfo name="commit" value="636b237"/>
ml"?> </reference>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6973.x <reference anchor="DNS-Privacy-not-so-private" target="https://petsympos
ml"?> ium.org/2018/files/hotpets/4-siby.pdf">
<?rfc <front>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7457.x <title>DNS Privacy not so private: the traffic analysis
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7766.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7816.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7828.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7830.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7871.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8020.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8198.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8310.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8467.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8490.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.x
ml"?>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8806.x
ml"?>
</references>
<references title="Informative References">
<reference anchor='Bloom-filter'
target='http://dl.ifip.org/db/conf/im/im2019/189282.pdf'>
<front>
<title>Privacy-Conscious Threat Intelligence Using DNSBLOOM</title>
<author initials='R.' surname='van Rijswijk-Deij'> </author>
<author initials='G.' surname='Rijnders'> </author>
<author initials='M.' surname='Bomhoff'> </author>
<author initials='L.' surname='Allodi'> </author>
<date year='2019'/>
</front>
</reference>
<reference anchor='Brenker-and-Arnes'
target='https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fd
a164fb2138a44.pdf'>
<front>
<title>CIRCUMVENTING IP-ADDRESS PSEUDONYMIZATION</title>
<author initials='T.' surname='Brekne'> </author>
<author initials='A.' surname='Arnes'> </author>
<date year='2005'/>
</front>
</reference>
<reference anchor='Crypto-PAn'
target='https://github.com/CESNET/ipfixcol/tree/master/base/src/interm
ediate/anonymization/Crypto-PAn'>
<front>
<title>Crypto-PAn</title>
<author>
<organization>CESNET</organization>
</author>
<date year='2015'/>
</front>
</reference>
<reference anchor='DNS-Privacy-not-so-private'
target='https://petsymposium.org/2018/files/hotpets/4-siby.pdf'>
<front>
<title>DNS Privacy not so private: the traffic analysis
perspective.</title> perspective.</title>
<author initials='S.' surname='Silby'> </author> <author initials="S." surname="Silby"> </author>
<author initials='M.' surname='Juarez'> </author> <author initials="M." surname="Juarez"> </author>
<author initials='N.' surname='Vallina-Rodriguez'> </author> <author initials="N." surname="Vallina-Rodriguez"> </author>
<author initials='C.' surname='Troncosol'> </author> <author initials="C." surname="Troncoso"> </author>
<date year='2019'/> <date year="2018"/>
</front> </front>
</reference> <seriesInfo name="Privacy Enhancing Technologies" value="Symposium"/>
<reference anchor='DoH-resolver-policy' </reference>
target='https://wiki.mozilla.org/Security/DOH-resolver-policy'>
<front> <reference anchor="DoH-resolver-policy" target="https://wiki.mozilla.org
<title>Security/DOH-resolver-policy</title> /Security/DOH-resolver-policy">
<author> <front>
<organization>Mozilla</organization> <title>Security/DOH-resolver-policy</title>
</author> <author>
<date year='2019'/> <organization>Mozilla</organization>
</front> </author>
</reference> <date year="2019"/>
<reference anchor='Geolocation-Impact-Assessement' </front>
target='https://support.google.com/analytics/answer/2763052?hl=en'> </reference>
<front>
<title>Anonymize IP Geolocation Accuracy Impact Assessment</title> <reference anchor="Geolocation-Impact-Assessment" target="https://www.co
<author> nversionworks.co.uk/blog/2017/05/19/anonymize-ip-geo-impact-test/">
<organization>Conversion Works</organization> <front>
</author> <title>Anonymize IP Geolocation Accuracy Impact Assessment</title>
<date year='2017'/> <author>
</front> <organization>Conversion Works</organization>
</reference> </author>
<reference anchor='Harvan' <date day="19" month="May" year="2017"/>
target='http://mharvan.net/talks/noms-ip_anon.pdf'> </front>
<front> </reference>
<title>Prefix- and Lexicographical-order-preserving IP Address
<reference anchor="Harvan" target="http://mharvan.net/talks/noms-ip_anon
.pdf">
<front>
<title>Prefix- and Lexicographical-order-preserving IP Address
Anonymization</title> Anonymization</title>
<author initials='M.' surname='Harvan'> </author> <author initials="M." surname="Harvan"> </author>
<date year='2006'/> <date year="2006"/>
</front> </front>
</reference> <refcontent>IEEE/IFIP Network Operations and Management
<?rfc Symposium</refcontent>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.belli <seriesInfo name="DOI" value="10.1109/NOMS.2006.1687580"/>
s-dnsop-xpf.xml"?> </reference>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf- <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
dnsop-dns-tcp-requirements.xml"?> .bellis-dnsop-xpf.xml"/>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf- <!-- [I-D.ietf-dnsop-dns-tcp-requirements] IESG state I-D Exists -->
httpbis-bcp56bis.xml"?>
<reference anchor='IP-Anonymization-in-Analytics' <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
target='https://support.google.com/analytics/answer/2763052?hl=en'> .ietf-dnsop-dns-tcp-requirements.xml"/>
<front>
<title>IP Anonymization in Analytics</title> <!-- [I-D.ietf-httpbis-bcp56bis] IESG state Expired -->
<author>
<organization>Google</organization> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
</author> .ietf-httpbis-bcp56bis.xml"/>
<date year='2019'/>
</front> <reference anchor="IP-Anonymization-in-Analytics" target="https://suppor
</reference> t.google.com/analytics/answer/2763052?hl=en">
<reference anchor='ISC-Knowledge-database-on-cache-snooping' <front>
target='https://kb.isc.org/docs/aa-00482'> <title>IP Anonymization in Analytics</title>
<front> <author>
<title>DNS Cache snooping - should I be concerned?</title> <organization>Google</organization>
<author> </author>
<organization>ISC Knowledge Database</organization> <date year="2019"/>
</author> </front>
<date year='2018'/> </reference>
</front>
</reference> <reference anchor="ISC-Knowledge-database-on-cache-snooping" target="htt
<reference anchor='Internet.nl' target='https://internet.nl'> ps://kb.isc.org/docs/aa-00482">
<front> <front>
<title>Internet.nl Is Your Internet Up To Date?</title> <title>DNS Cache snooping - should I be concerned?</title>
<author> <author initials="S" surname="Goldlust" />
<organization>Internet.nl</organization> <author initials="C" surname="Almond" />
</author> <date year="2018" month="October" day="15"/>
<date year='2019'/> </front>
</front> <seriesInfo name="ISC" value="Knowledge Database"/>
</reference> </reference>
<reference anchor='MAC-address-EDNS'
target='https://lists.dns-oarc.net/pipermail/dns-operations/2016-Janua <reference anchor="Internet.nl" target="https://internet.nl">
ry/014143.html'> <front>
<front> <title>Internet.nl Is Your Internet Up To Date?</title>
<title>Embedding MAC address in DNS requests for selective filtering <author>
IDs</title> <organization>Internet.nl</organization>
<author> </author>
<organization>DNS-OARC mailing list</organization> <date year="2019"/>
</author> </front>
<date year='2016'/> </reference>
</front>
</reference> <reference anchor="DNSCrypt" target="https://www.dnscrypt.org">
<reference anchor='Passive-Observations-of-a-Large-DNS' <front>
target='http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/t <title>DNSCrypt - Official Project Home Page</title>
ma2018_paper30.pdf'> <author/>
<front> <date/>
<title>Passive Observations of a Large DNS Service: 2.5 Years in the </front>
</reference>
<reference anchor="MAC-address-EDNS" target="https://lists.dns-oarc.net/
pipermail/dns-operations/2016-January/014143.html">
<front>
<title>Embedding MAC address in DNS requests for selective filtering
</title>
<author initials="B" surname="Hubert"/>
<date year="2016" month="January" day="25"/>
</front>
<seriesInfo name="DNS-OARC" value="mailing list" />
</reference>
<reference anchor="Passive-Observations-of-a-Large-DNS" target="http://tma.ifip.
org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper30.pdf">
<front>
<title>Passive Observations of a Large DNS Service: 2.5 Years in the
Life of Google</title> Life of Google</title>
<author initials='W. B.' surname='de Vries'> </author> <author initials="W. B." surname="de Vries"> </author>
<author initials='R.' surname='van Rijswijk-Deij'> </author> <author initials="R." surname="van Rijswijk-Deij"> </author>
<author initials='P.' surname='de Boer'> </author> <author initials="P-T" surname="de Boer"> </author>
<author initials='A.' surname='Pras'> </author> <author initials="A." surname="Pras"> </author>
<date year='2018'/> <date year="2018"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.23919/TMA.2018.8506536"/>
<reference anchor='Pitfalls-of-DNS-Encryption' </reference>
target='https://dl.acm.org/citation.cfm?id=2665959'>
<front> <reference anchor="Pitfalls-of-DNS-Encryption" target="https://dl.acm.or
<title>Pretty Bad Privacy: Pitfalls of DNS Encryption</title> g/citation.cfm?id=2665959">
<author initials='H.' surname='Shulman' fullname='Haya Shulman'> <front>
<organization>Fachbereich Informatik, Technische Universität <title>Pretty Bad Privacy: Pitfalls of DNS Encryption</title>
<author initials="H." surname="Shulman" fullname="Haya Shulman">
<organization>Fachbereich Informatik, Technische Universität
Darmstadt</organization> Darmstadt</organization>
</author> </author>
<date year='2014'/> <date year="2014" month="November"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1145/2665943.2665959"/>
<reference anchor='PowerDNS-dnswasher' <refcontent>Proceedings of the 13th Workshop on Privacy in the
target='https://github.com/PowerDNS/pdns/blob/master/pdns/dnswasher.cc Electronic Society, pp. 191-200</refcontent>
'> </reference>
<front>
<title>dnswasher</title> <reference anchor="PowerDNS-dnswasher" target="https://github.com/PowerD
<author> NS/pdns/blob/master/pdns/dnswasher.cc">
<organization>PowerDNS</organization> <front>
</author> <title>dnswasher</title>
<date year='2019'/> <author>
</front> <organization>PowerDNS</organization>
</reference> </author>
<?rfc <date day="24" month="April" year="2020"/>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.x </front>
ml"?> <seriesInfo name="commit" value="050e687" />
<?rfc </reference>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.x
ml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc FC.4034.xml"/>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5077.x <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ml"?> FC.4035.xml"/>
<?rfc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6235.x FC.5077.xml"/>
ml"?> <xi:include
<?rfc href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6147.x
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6265.x ml"/>
ml"?> <xi:include
<?rfc href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6235.x
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7626.x ml"/>
ml"?>
<?rfc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7873.x FC.6265.xml"/>
ml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc FC.7626.xml"/>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8027.x <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ml"?> FC.7873.xml"/>
<?rfc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8094.x FC.8027.xml"/>
ml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc FC.8094.xml"/>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8404.x <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ml"?> FC.8404.xml"/>
<?rfc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.x FC.8446.xml"/>
ml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc FC.8555.xml"/>
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8555.x <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ml"?> FC.8618.xml"/>
<?rfc
include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8618.x <reference anchor="Ramaswamy-and-Wolf" target="http://www.ecs.umass.edu/
ml"?> ece/wolf/pubs/ton2007.pdf">
<reference anchor='Ramaswamy-and-Wolf' <front>
target='http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf'> <title>High-Speed Prefix-Preserving IP Address Anonymization for
<front>
<title>High-Speed Prefix-Preserving IP Address Anonymization for
Passive Measurement Systems</title> Passive Measurement Systems</title>
<author initials='R.' surname='Ramaswamy'> </author> <author initials="R." surname="Ramaswamy"> </author>
<author initials='T.' surname='Wolf'> </author> <author initials="T." surname="Wolf"> </author>
<date year='2007'/> <date year="2007"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1109/TNET.2006.890128"/>
<reference anchor='SSL-Labs' target='https://www.ssllabs.com/ssltest/'> </reference>
<front>
<title>SSL Server Test</title> <reference anchor="SSL-Labs" target="https://www.ssllabs.com/ssltest/">
<author> <front>
<organization>SSL Labs</organization> <title>SSL Server Test</title>
</author> <author>
<date year='2019'/> <organization>SSL Labs</organization>
</front> </author>
</reference> <date year="2019"/>
<reference anchor='SURFnet-policy' </front>
target='https://surf.nl/datasharing'> </reference>
<front>
<title>SURFnet Data Sharing Policy</title> <reference anchor="SURFnet-policy" target="https://surf.nl/datasharing">
<author> <front>
<organization>SURFnet</organization> <title>SURFnet Data Sharing Policy</title>
</author> <author initials ="C" surname="Baartmans" />
<date year='2016'/> <author initials ="A" surname="van Wynsberghe" />
</front> <author initials ="R" surname="van Rijswijk-Deij" />
</reference> <author initials ="F" surname="Jorna" />
<reference anchor='TCPdpriv' <date year="2016" month="June"/>
target='http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html'> </front>
<front> </reference>
<title>TCPdpriv</title>
<author> <reference anchor="tcpdpriv"
<organization>Ipsilon Networks, Inc.</organization> target="http://fly.isti.cnr.it/software/tcpdpriv/">
</author> <front>
<date year='2005'/> <title>TCPDRIV - Program for Eliminating Confidential Information fr
</front> om Traces</title>
</reference> <author>
<reference anchor='Xu-et-al.' <organization>Ipsilon Networks, Inc.</organization>
target='http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-anon </author>
.pdf'> <date year="2004"/>
<front> </front>
<title>Prefix-preserving IP address anonymization: measurement-based </reference>
<reference anchor="Xu-et-al" target="http://an.kaist.ac.kr/~sbmoon/paper
/intl-journal/2004-cn-anon.pdf">
<front>
<title>Prefix-preserving IP address anonymization: measurement-based
security evaluation and a new cryptography-based scheme</title> security evaluation and a new cryptography-based scheme</title>
<author initials='J.' surname='Fan'> </author> <author initials="J." surname="Fan"> </author>
<author initials='J.' surname='Xu'> </author> <author initials="J." surname="Xu"> </author>
<author initials='M. H.' surname='Ammar'> </author> <author initials="M.H." surname="Ammar"> </author>
<author initials='S. B.' surname='Moon'> </author> <author initials="S.B." surname="Moon"> </author>
<date year='2004'/> <date year="2004"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1016/j.comnet.2004.03.033"/>
<reference anchor='dnsdist' target='https://dnsdist.org'> </reference>
<front>
<title>dnsdist Overview</title> <reference anchor="dnsdist" target="https://dnsdist.org">
<author> <front>
<organization>PowerDNS</organization> <title>dnsdist Overview</title>
</author> <author>
<date year='2019'/> <organization>PowerDNS</organization>
</front> </author>
</reference> </front>
<reference anchor='dnstap' target='http://dnstap.info'> </reference>
<front>
<title>DNSTAP</title> <reference anchor="dnstap" target="https://dnstap.info">
<author> <front>
<organization>dnstap.info</organization> <title>dnstap</title>
</author> <author />
<date year='2019'/> </front>
</front> </reference>
</reference>
<reference anchor='dot-ALPN' <reference anchor="dot-ALPN" target="https://www.iana.org/assignments/tl
target='https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiont s-extensiontype-values">
ype-values.xhtml#alpn-protocol-ids'> <front>
<front> <title>Transport Layer Security (TLS) Extensions: TLS Application-La
<title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title> yer Protocol Negotiation (ALPN) Protocol IDs</title>
<author> <author>
<organization>IANA (iana.org)</organization> <organization>IANA</organization>
</author> </author>
<date year='2020'/> </front>
</front> </reference>
</reference>
<reference anchor='haproxy' target='https://www.haproxy.org/'> <reference anchor="haproxy" target="https://www.haproxy.org/">
<front> <front>
<title>HAPROXY</title> <title>HAProxy - The Reliable, High Performance TCP/HTTP Load Balanc
<author> er</title>
<organization>haproxy.org</organization> <author>
</author> <organization/>
<date year='2019'/> </author>
</front> </front>
</reference> </reference>
<reference anchor='ipcipher1'
target='https://medium.com/@bert.hubert/on-ip-address-encryption-secu <reference anchor="ipcipher1" target="https://medium.com/@bert.hubert/on
rity-analysis-with-respect-for-privacy-dabe1201b476'> -ip-address-encryption-security-analysis-with-respect-for-privacy-dabe1201b476">
<front> <front>
<title>On IP address encryption: security analysis with respect for <title>On IP address encryption: security analysis with respect for
privacy</title> privacy</title>
<author initials='B.' surname='Hubert'> </author> <author initials="B." surname="Hubert"> </author>
<date year='2017'/> <date year="2017" month="May" day="7"/>
</front> </front>
</reference> <refcontent>Medium</refcontent>
<reference anchor='ipcipher2' </reference>
target='https://github.com/PowerDNS/ipcipher'>
<front> <reference anchor="ipcipher2" target="https://github.com/PowerDNS/ipciph
<title>ipcipher</title> er">
<author> <front>
<organization>PowerDNS</organization> <title>ipcipher</title>
</author> <author>
<date year='2017'/> <organization>PowerDNS</organization>
</front> </author>
</reference> <date year="2018" month="February" day="13"/>
<reference anchor='ipcrypt' </front>
target='https://github.com/veorq/ipcrypt'> <seriesInfo name="commit" value="fd47abe"/>
<front> </reference>
<title>ipcrypt: IP-format-preserving encryption</title>
<author> <reference anchor="ipcrypt" target="https://github.com/veorq/ipcrypt">
<organization>veorq</organization> <front>
</author> <title>ipcrypt: IP-format-preserving encryption</title>
<date year='2015'/> <author>
</front> <organization>veorq</organization>
</reference> </author>
<reference anchor='ipcrypt-analysis' <date year="2015" month="July" day="6"/>
target='https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.h </front>
tml'> <seriesInfo name="commit" value="8cc12f9" />
<front> </reference>
<title>Analysis of ipcrypt?</title>
<author initials='J.' surname='Aumasson'> </author> <reference anchor="ipcrypt-analysis" target="https://mailarchive.ietf.or
<date year='2018'/> g/arch/msg/cfrg/cFx5WJo48ZEN-a5cj_LlyrdN8-0/">
</front> <front>
</reference> <title>Subject: Re: [Cfrg] Analysis of ipcrypt?</title>
<reference anchor='nginx' target='https://nginx.org/'> <author initials="J-P" surname="Aumasson"> </author>
<front> <date year="2018" month="February" day="22"/>
<title>NGINX</title> </front>
<author> <refcontent>message to the Cfrg mailing list</refcontent>
<organization>nginx.org</organization> </reference>
</author>
<date year='2019'/> <reference anchor="nginx" target="https://nginx.org/">
</front> <front>
</reference> <title>nginx news</title>
<reference anchor='pcap' target='http://www.tcpdump.org/'> <author>
<front> <organization>nginx.org</organization>
<title>PCAP</title> </author>
<author> <date year="2019"/>
<organization>tcpdump.org</organization> </front>
</author> </reference>
<date year='2016'/>
</front> <reference anchor="pcap" target="https://www.tcpdump.org/">
</reference> <front>
<reference anchor='policy-comparison' <title>Tcpdump &amp; Libpcap</title>
target='https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+priva <author>
cy+statements+2019'> <organization>The Tcpdump Group</organization>
<front> </author>
<title>Comparison of policy and privacy statements 2019</title> <date year="2020"/>
<author> </front>
<organization>dnsprivacy.org</organization> </reference>
</author>
<date year='2019'/> <reference anchor="policy-comparison" target="https://dnsprivacy.org/wik
</front> i/display/DP/Comparison+of+policy+and+privacy+statements+2019">
</reference> <front>
<reference anchor='stunnel' <title>Comparison of policy and privacy statements 2019</title>
target='https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html'> <author initials="S" surname="Dickinson" />
<front> <date day="18" month="December" year="2019" />
<title>DNS-over-TLS</title> </front>
<author> <refcontent>DNS Privacy Project</refcontent>
<organization>ISC Knowledge Database</organization> </reference>
</author>
<date year='2018'/> <reference anchor="stunnel" target="https://kb.isc.org/article/AA-01386/
</front> 0/DNS-over-TLS.html">
</reference> <front>
<reference anchor='van-Dijkhuizen-et-al.' <title>DNS over TLS</title>
target='https://doi.org/10.1145/3182660'> <author initials="S" surname="Goldlust" />
<front> <author initials="C" surname="Almond" />
<title>A Survey of Network Traffic Anonymisation Techniques and <author initials="F" surname="Dupont" />
<date year="2018" month="November" day="1"/>
</front>
<refcontent>ISC Knowledge Database"</refcontent>
</reference>
<reference anchor="van-Dijkhuizen-et-al" target="https://doi.org/10.1145
/3182660">
<front>
<title>A Survey of Network Traffic Anonymisation Techniques and
Implementations</title> Implementations</title>
<author initials='N.' surname='Van Dijkhuizen '> </author> <author initials="N." surname="Van Dijkhuizen "> </author>
<author initials='J.' surname='Van Der Ham'> </author> <author initials="J." surname="Van Der Ham"> </author>
<date year='2018'/> <date year="2018" month="May"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1145/3182660"/>
</references> <refcontent>ACM Computing Surveys</refcontent>
</reference>
</references>
</references>
<section anchor="documents" title="Documents"> <section anchor="documents" numbered="true" toc="default">
<t>This section provides an overview of some DNS privacy-related documents, <name>Documents</name>
however, this is neither an exhaustive list nor a definitive statement on the <t>
characteristic of the document.
</t> 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.
<section anchor="potential-increases-in-dns-privacy" title="Potential
increases in DNS privacy">
<t>These documents are limited in scope to communications between stub
clients and recursive resolvers:
</t> </t>
<t> <section anchor="potential-increases-in-dns-privacy" numbered="true" toc="
<list style="symbols"> default">
<t>'Specification for DNS over Transport Layer Security (TLS)' <xref <name>Potential Increases in DNS Privacy</name>
target="RFC7858"/>.</t> <t>These documents are limited in scope to communications between stub
<t>'DNS over Datagram Transport Layer Security (DTLS)' <xref clients and recursive resolvers:
target="RFC8094"/>. Note that this
document has the Category of Experimental.</t>
<t>'DNS Queries over HTTPS (DoH)' <xref target="RFC8484"/>.</t>
<t>'Usage Profiles for DNS over TLS and DNS over DTLS' <xref
target="RFC8310"/>.</t>
<t>'The EDNS(0) Padding Option' <xref target="RFC7830"/> and 'Padding Policy
for EDNS(0)'
<xref target="RFC8467"/>.</t>
</list>
</t> </t>
<t>These documents apply to recursive and authoritative DNS but are relevant <ul spacing="normal">
<li>"Specification for DNS over Transport Layer Security (TLS)" <xref
target="RFC7858" format="default"/>.</li>
<li>"DNS over Datagram Transport Layer Security (DTLS)" <xref target="
RFC8094" format="default"/>. Note that this
document has the category of Experimental.</li>
<li>"DNS Queries over HTTPS (DoH)" <xref target="RFC8484" format="defa
ult"/>.</li>
<li>"Usage Profiles for DNS over TLS and DNS over DTLS" <xref target="
RFC8310" format="default"/>.</li>
<li>"The EDNS(0) Padding Option" <xref target="RFC7830"
format="default"/> and "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))" <xref target="RFC8467" format="default"/>.</li>
</ul>
<t>These documents apply to recursive and authoritative DNS but are rele
vant
when when
considering the operation of a recursive server: considering the operation of a recursive server:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>"DNS Query Name Minimisation to Improve Privacy" <xref target="RFC
<t>'DNS Query Name minimization to Improve Privacy' <xref 7816" format="default"/>.</li>
target="RFC7816"/>.</t> </ul>
</list> </section>
</t> <section anchor="potential-decreases-in-dns-privacy" numbered="true" toc="
</section> default">
<name>Potential Decreases in DNS Privacy</name>
<section anchor="potential-decreases-in-dns-privacy" title="Potential <t>These documents relate to functionality that could provide increased
decreases in DNS privacy">
<t>These documents relate to functionality that could provide increased
tracking of tracking of
user activity as a side effect: user activity as a side effect:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>"Client Subnet in DNS Queries" <xref target="RFC7871"
<t>'Client Subnet in DNS Queries' <xref target="RFC7871"/>.</t> format="default"/>.</li>
<t>'Domain Name System (DNS) Cookies' <xref target="RFC7873"/>).</t> <li>"Domain Name System (DNS) Cookies" <xref target="RFC7873"
<t>'Transport Layer Security (TLS) Session Resumption without Server-Side format="default"/>).</li>
State' <li>"Transport Layer Security (TLS) Session Resumption without Server-
<xref target="RFC5077"/> referred to here as simply TLS session Side
resumption.</t> State" <xref target="RFC5077" format="default"/>, referred to here
<t><xref target="RFC8446"/> Appendix C.4 describes Client Tracking Prevention as simply TLS session resumption.</li>
in TLS 1.3</t> <li>
<t>'A DNS Packet Capture Format' <xref target="RFC8618"/>.</t> <xref target="RFC8446" section="C.4" sectionFormat="comma"/>
<t>Passive DNS <xref target="RFC8499"/>.</t> describes client tracking prevention in TLS 1.3</li>
<t>Section 8 of <xref target="RFC8484"/> outlines the privacy considerations <li>"Compacted-DNS (C-DNS): A Format for DNS Packet Capture" <xref
target="RFC8618" format="default"/>.</li>
<li>Passive DNS <xref target="RFC8499" format="default"/>.</li>
<li><xref target="RFC8484" sectionFormat="of"
section="8"/> outlines the privacy considerations
of DoH. Note that of DoH. Note that
(while that document advises exposing the minimal set of data needed to (while that document advises exposing the minimal set of data needed to
achieve the desired feature set) depending on the specifics of a DoH achieve the desired feature set), depending on the specifics of a DoH
implementation there may be increased identification and tracking compared to implementation, there may be increased identification and tracking compared to
other DNS transports.</t> other DNS transports.</li>
</list> </ul>
</t> </section>
</section> <section anchor="related-operational-documents" numbered="true" toc="defau
lt">
<section anchor="related-operational-documents" title="Related operational <name>Related Operational Documents</name>
documents"> <ul spacing="normal">
<t> <li>"DNS Transport over TCP - Implementation Requirements" <xref targe
<list style="symbols"> t="RFC7766" format="default"/>.</li>
<t>'DNS Transport over TCP - Implementation Requirements' <xref <li>"DNS Transport over TCP - Operational Requirements"
target="RFC7766"/>.</t> <xref target="I-D.ietf-dnsop-dns-tcp-requirements" format="default"/>.</li>
<t>'Operational requirements for DNS over TCP' <li>"The edns-tcp-keepalive EDNS0 Option" <xref target="RFC7828" forma
<xref target="I-D.ietf-dnsop-dns-tcp-requirements"/>.</t> t="default"/>.</li>
<t>'The edns-tcp-keepalive EDNS0 Option' <xref target="RFC7828"/>.</t> <li>"DNS Stateful Operations" <xref target="RFC8490" format="default"/
<t>'DNS Stateful Operations' <xref target="RFC8490"/>.</t> >.</li>
</list> </ul>
</t> </section>
</section> </section>
</section> <section anchor="ip-address-techniques" numbered="true" toc="default">
<name>IP Address Techniques</name>
<section anchor="ip-address-techniques" title="IP address techniques"> <t>The following table presents a high-level comparison of various techniq
<t>The following table presents a high level comparison of various techniques ues
employed or under development in 2019, and classifies them according to employed or under development in 2019 and classifies them according to
categorization of technique and other properties. Both the specific techniques categorization of technique and other properties. Both the specific techniques
and the categorisations are described in more detail in the following and the categorizations are described in more detail in the following
sections. sections.
The list of techniques includes the main techniques in current use, but does The list of techniques includes the main techniques in current use but does
not not
claim to be comprehensive. claim to be comprehensive.
</t> </t>
<texttable title="Table 1: Classification of techniques <table align="center">
"> <name>Classification of Techniques</name>
<ttcol align="left">Categorization/Property</ttcol> <thead>
<ttcol align="center">GA</ttcol> <tr>
<ttcol align="center">d</ttcol> <th align="left">Categorization/Property</th>
<ttcol align="center">TC</ttcol> <th align="center">GA</th>
<ttcol align="center">C</ttcol> <th align="center">d</th>
<ttcol align="center">TS</ttcol> <th align="center">TC</th>
<ttcol align="center">i</ttcol> <th align="center">C</th>
<ttcol align="center">B</ttcol> <th align="center">TS</th>
<th align="center">i</th>
<th align="center">B</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Anonymization</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
</tr>
<tr>
<td align="left">Pseudonymization</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">Format
preserving</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">Prefix preserving</td>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Replacement</td>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Filtering</td>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Generalization</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
</tr>
<tr>
<td align="left">Enumeration</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Reordering/Shuffling</td>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Random substitution</td>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Cryptographic
permutation</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">IPv6 issues</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">CPU intensive</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Memory intensive</td>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">Security concerns</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
</tr>
</tbody>
</table>
<t>Legend of techniques:</t>
<dl spacing="compact" indent="5">
<dt>GA</dt><dd>= Google Analytics</dd>
<dt>d</dt><dd>= dnswasher</dd>
<dt>TC</dt><dd>= TCPdpriv</dd>
<dt>C</dt><dd>= CryptoPAn</dd>
<dt>TS</dt><dd>= TSA</dd>
<dt>i</dt><dd>= ipcipher</dd>
<dt>B</dt><dd>= Bloom filter</dd>
</dl>
<c>Anonymization</c><c>X</c><c>X</c><c>X</c><c></c><c></c><c></c><c>X</c> <t>The choice of which method to use for a particular application will dep
<c>Pseudoanonymization</c><c></c><c></c><c></c><c>X</c><c>X</c><c>X</c><c></c> end
<c>Format
preserving</c><c>X</c><c>X</c><c>X</c><c>X</c><c>X</c><c>X</c><c></c>
<c>Prefix preserving</c><c></c><c></c><c>X</c><c>X</c><c>X</c><c></c><c></c>
<c>Replacement</c><c></c><c></c><c>X</c><c></c><c></c><c></c><c></c>
<c>Filtering</c><c>X</c><c></c><c></c><c></c><c></c><c></c><c></c>
<c>Generalization</c><c></c><c></c><c></c><c></c><c></c><c></c><c>X</c>
<c>Enumeration</c><c></c><c>X</c><c></c><c></c><c></c><c></c><c></c>
<c>Reordering/Shuffling</c><c></c><c></c><c>X</c><c></c><c></c><c></c><c></c>
<c>Random substitution</c><c></c><c></c><c>X</c><c></c><c></c><c></c><c></c>
<c>Cryptographic
permutation</c><c></c><c></c><c></c><c>X</c><c>X</c><c>X</c><c></c>
<c>IPv6 issues</c><c></c><c></c><c></c><c></c><c>X</c><c></c><c></c>
<c>CPU intensive</c><c></c><c></c><c></c><c>X</c><c></c><c></c><c></c>
<c>Memory intensive</c><c></c><c></c><c>X</c><c></c><c></c><c></c><c></c>
<c>Security concerns</c><c></c><c></c><c></c><c></c><c></c><c>X</c><c></c>
</texttable>
<t>Legend of techniques: GA = Google Analytics, d = dnswasher, TC = TCPdpriv,
C = CryptoPAn, TS = TSA, i = ipcipher, B = Bloom filter
</t>
<t>The choice of which method to use for a particular application will depend
on on
the requirements of that application and consideration of the threat analysis the requirements of that application and consideration of the threat analysis
of of
the particular situation. the particular situation.
</t> </t>
<t>For example, a common goal is that distributed packet captures must be in
an
existing data format such as PCAP <xref target="pcap"/> or C-DNS <xref
target="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.,
<xref target="Brenker-and-Arnes"/> have observed that, as the entropy in an
IPv4 address is
limited, if an attacker can
</t>
<t>
<list style="symbols">
<t>ensure packets are captured by the target and</t>
<t>send forged traffic with arbitrary source and destination addresses to that
target and</t>
<t>obtain a de-identified log of said traffic from that target</t>
</list>
</t>
<t>any format-preserving pseudonymization is vulnerable to an attack along the
lines of a cryptographic chosen plaintext attack.
</t>
<section anchor="categorization-of-techniques" title="Categorization of <t>For example, a common goal is that distributed packet captures must be
techniques"> in
<t>Data minimization methods may be categorized by the processing used and the an existing data format, such as PCAP <xref target="pcap"
format="default"/> or Compacted-DNS (C-DNS) <xref target="RFC8618"
format="default"/>, that can be used
as input to existing analysis tools. In that case, use of a format-preserv
ing
technique is essential. This, though, is not cost free; several authors
(e.g., <xref target="Brekne-and-Arnes" format="default"/>) have observed
that, as the entropy in an IPv4 address is limited, if an attacker can
</t>
<ul spacing="normal">
<li>ensure packets are captured by the target and</li>
<li>send forged traffic with arbitrary source and destination addresses
to that
target and</li>
<li>obtain a de-identified log of said traffic from that target,</li>
</ul>
<t>any format-preserving pseudonymization is vulnerable to an attack along
the
lines of a cryptographic chosen-plaintext attack.
</t>
<section anchor="categorization-of-techniques" numbered="true" toc="defaul
t">
<name>Categorization of Techniques</name>
<t>Data minimization methods may be categorized by the processing used a
nd the
properties of their outputs. The following builds on the categorization properties of their outputs. The following builds on the categorization
employed in <xref target="RFC6235"/>: employed in <xref target="RFC6235" format="default"/>:
</t> </t>
<t> <dl spacing="normal">
<list style="symbols"> <dt>Format-preserving.</dt><dd> Normally, when encrypting, the origina
<t>Format-preserving. Normally when encrypting, the original data length and l data length and
patterns in the data should be hidden from an attacker. Some applications of 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-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 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.</t> to be parsed in the same way as the original.</dd>
<t>Prefix preservation. Values such as IP addresses and MAC addresses contain <dt>Prefix preservation.</dt><dd> Values such as IP addresses and MAC
prefix information that can be valuable in analysis, e.g., manufacturer ID in addresses contain
MAC addresses, subnet in IP addresses. Prefix preservation ensures that prefix information that can be valuable in analysis -- e.g., manufacturer ID in
prefixes are de-identified consistently; e.g., if two IP addresses are from MAC addresses, or subnet in IP addresses. Prefix preservation ensures that
prefixes are de-identified consistently; for example, if two IP addresses are fr
om
the the
same subnet, a prefix preserving de-identification will ensure that their same subnet, a prefix preserving de-identification will ensure that their
de-identified counterparts will also share a subnet. Prefix preservation may 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 fixed (i.e., based on a user-selected prefix length identified in advance to
be preserved ) or general.</t> be preserved ) or general.</dd>
<t>Replacement. A one-to-one replacement of a field to a new value of the same <dt>Replacement.</dt><dd> A one-to-one replacement of a field to a new value of
type, for example, using a regular expression.</t> the same
<t>Filtering. Removing or replacing data in a field. Field type -- for example, using a regular expression.</dd>
<dt>Filtering.</dt><dd> Removing or replacing data in a field. Field
data can be overwritten, often with zeros, either partially (truncation or data can be overwritten, often with zeros, either partially (truncation or
reverse truncation) or reverse truncation) or
completely (black-marker anonymization).</t> completely (black-marker anonymization).</dd>
<t>Generalization. Data is replaced by more general data with reduced <dt>Generalization.</dt><dd> Data is replaced by more general data wit
h reduced
specificity. One example would be to replace all TCP/UDP port numbers with one 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 of two fixed values indicating whether the original port was ephemeral
(&gt;=1024) or non-ephemeral (&gt;1024). Another example, precision (&gt;=1024) or nonephemeral (&gt;1024). Another example, precision
degradation, degradation,
reduces the accuracy of e.g., a numeric value or a timestamp.</t> reduces the accuracy of, for example, a numeric value or a timestamp.</dd>
<t>Enumeration. With data from a well-ordered set, replace the first data item
data using a random initial value and then allocate ordered values for <dt>Enumeration.</dt><dd> With data from a well-ordered set, replace
subsequent data items. When used with timestamp data, this preserves ordering the first data item's data using a random initial value and then
but loses precision and distance.</t> allocate ordered values for
<t>Reordering/shuffling. Preserving the original data, but rearranging its subsequent data items. When used with timestamp data, this preserves or
dering
but loses precision and distance.</dd>
<dt>Reordering/shuffling.</dt><dd> Preserving the original data, but r
earranging its
order, order,
often in a random manner.</t> often in a random manner.</dd>
<t>Random substitution. As replacement, but using randomly generated <dt>Random substitution.</dt><dd> As replacement, but using randomly g
enerated
replacement replacement
values.</t> values.</dd>
<t>Cryptographic permutation. Using a permutation function, such as a hash <dt>Cryptographic permutation.</dt><dd> Using a permutation function,
such as a hash
function or cryptographic block cipher, to generate a replacement function or cryptographic block cipher, to generate a replacement
de-identified value.</t> de-identified value.</dd>
</list> </dl>
</t> </section>
</section> <section anchor="specific-techniques" numbered="true" toc="default">
<name>Specific Techniques</name>
<section anchor="specific-techniques" title="Specific techniques"> <section anchor="google-analytics-nonprefix-filtering" numbered="true" t
oc="default">
<section anchor="google-analytics-nonprefix-filtering" title="Google Analytics <name>Google Analytics Non-Prefix Filtering</name>
non-prefix filtering"> <t>Since May 2010, Google Analytics has provided a facility <xref targ
<t>Since May 2010, Google Analytics has provided a facility <xref et="IP-Anonymization-in-Analytics" format="default"/> that allows website
target="IP-Anonymization-in-Analytics"/> that allows website owners to request that all their users' IP addresses are anonymized within
owners to request that all their users IP addresses are anonymized within
Google Analytics processing. This very basic anonymization simply sets to zero Google Analytics processing. This very basic anonymization simply sets to zero
the least significant 8 bits of IPv4 addresses, and the least significant 80 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 bits of IPv6 addresses. The level of anonymization this produces is perhaps
questionable. There are some analysis results <xref questionable. There are some analysis results <xref
target="Geolocation-Impact-Assessement"/> target="Geolocation-Impact-Assessment" format="default"/> that suggest that the
which suggest that the impact of impact of
this on reducing the accuracy of determining the user's location from their IP 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 address is less than might be hoped; the average discrepancy in identification
of the user city for UK users is no more than 17%. of the user city for UK users is no more than 17%.
</t> </t>
<t>Anonymization: Format-preserving, Filtering (trucation). <dl>
</t> <dt>Anonymization:</dt><dd> Format-preserving, Filtering (truncation).
</section> </dd>
</dl>
<section anchor="dnswasher" title="dnswasher"> </section>
<t>Since 2006, PowerDNS have included a de-identification tool dnswasher <section anchor="dnswasher" numbered="true" toc="default">
<xref target="PowerDNS-dnswasher"/> with their PowerDNS product. This is a <name>dnswasher</name>
<t>Since 2006, PowerDNS has included a de-identification tool, dnswash
er
<xref target="PowerDNS-dnswasher" format="default"/>, with their PowerDNS
product. This is a
PCAP filter that PCAP filter that
performs a one-to-one mapping of end user IP addresses with an anonymized 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 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 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 0.0.0.2, and so on. The de-identified address therefore depends on the order
that that
addresses arrive in the input, and running over a large amount of data the addresses arrive in the input, and when running over a large amount of data, the
address translation tables can grow to a significant size. address translation tables can grow to a significant size.
</t> </t>
<t>Anonymization: Format-preserving, Enumeration. <dl>
</t> <dt>Anonymization:</dt><dd> Format-preserving, Enumeration.</dd>
</section> </dl>
</section>
<section anchor="prefixpreserving-map" title="Prefix-preserving map"> <section anchor="prefixpreserving-map" numbered="true" toc="default">
<t>Used in <xref target="TCPdpriv"/>, <name>Prefix-Preserving Map</name>
this algorithm stores a set of original and anonymised IP <t>Used in <xref target="tcpdpriv" format="default"/>,
this algorithm stores a set of original and anonymized IP
address pairs. When a new IP address arrives, it is compared with previous 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 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 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 random value. The use of a random value means that TCPdpriv is not
deterministic; different anonymized values will be generated on each run. The deterministic; different anonymized values will be generated on each run.
need to store previous addresses means that TCPdpriv has significant and
unbounded memory requirements, and because of the need to allocated anonymized
addresses sequentially cannot be used in parallel processing.
</t>
<t>Anonymization: Format-preserving, prefix preservation (general).
</t>
</section>
<section anchor="cryptographic-prefixpreserving-pseudonymization" The need to store previous addresses means that TCPdpriv has significant and
title="Cryptographic Prefix-Preserving Pseudonymization"> unbounded memory requirements. The need to allocate anonymized addresses
<t>Cryptographic prefix-preserving pseudonymization was originally proposed as sequentially means that TCPdpriv cannot be used in parallel processing.
</t>
<dl>
<dt>Anonymization:</dt><dd> Format-preserving, prefix preservation (ge
neral).</dd>
</dl>
</section>
<section anchor="cryptographic-prefixpreserving-pseudonymization" number
ed="true" toc="default">
<name>Cryptographic Prefix-Preserving Pseudonymization</name>
<t>Cryptographic prefix-preserving pseudonymization was originally pro
posed as
an an
improvement to the prefix-preserving map implemented in TCPdpriv, described in improvement to the prefix-preserving map implemented in TCPdpriv, described in
<xref target="Xu-et-al."/> and implemented in the <xref target="Crypto-PAn"/> <xref target="Xu-et-al" format="default"/> and implemented in the <xref target=" Crypto-PAn" format="default"/>
tool. tool.
Crypto-PAn is now frequently Crypto-PAn is now frequently
used as an acronym for the algorithm. Initially it was described for IPv4 used as an acronym for the algorithm. Initially, it was described for IPv4
addresses only; extension for IPv6 addresses was proposed in <xref addresses only; extension for IPv6 addresses was proposed in <xref target="Harva
target="Harvan"/>. This uses a cryptographic algorithm n" format="default"/>. This uses a cryptographic algorithm
rather than a random value, and thus pseudonymity is determined uniquely by rather than a random value, and thus pseudonymity is determined uniquely by
the the
encryption key, and is deterministic. It requires a separate AES encryption encryption key, and is deterministic. It requires a separate AES encryption
for for
each output bit, so has a non-trivial calculation overhead. This can be each output bit and so has a nontrivial calculation overhead. This can be
mitigated to some extent (for IPv4, at least) by pre-calculating results for mitigated to some extent (for IPv4, at least) by precalculating results for
some number of prefix bits. some number of prefix bits.
</t> </t>
<t>Pseudonymization: Format-preserving, prefix preservation (general). <dl>
</t> <dt>Pseudonymization:</dt><dd> Format-preserving, prefix preservation
</section> (general).</dd>
</dl>
<section anchor="tophash-subtreereplicated-anonymization" title="Top-hash </section>
Subtree-replicated Anonymization"> <section anchor="tophash-subtreereplicated-anonymization" numbered="true
<t>Proposed in <xref target="Ramaswamy-and-Wolf"/>, " toc="default">
<name>Top-Hash Subtree-Replicated Anonymization</name>
<t>Proposed in <xref target="Ramaswamy-and-Wolf" format="default"/>,
Top-hash Subtree-replicated Anonymization (TSA) Top-hash Subtree-replicated Anonymization (TSA)
originated in response to the requirement for faster processing than originated in response to the requirement for faster processing than
Crypto-PAn. Crypto-PAn.
It used hashing for the most significant byte of an IPv4 address, and a It used hashing for the most significant byte of an IPv4 address and a
pre-calculated binary tree structure for the remainder of the address. To save precalculated binary-tree structure for the remainder of the address.
To save
memory space, replication is used within the tree structure, reducing the size memory space, replication is used within the tree structure, reducing the size
of the pre-calculated structures to a few Mb for IPv4 addresses. Address of the precalculated structures to a few megabytes for IPv4 addresses. Address
pseudonymization is done via hash and table lookup, and so requires minimal 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 computation. However, due to the much-increased address space for IPv6, TSA is
not memory efficient for IPv6. not memory efficient for IPv6.
</t> </t>
<t>Pseudonymization: Format-preserving, prefix preservation (general). <dl>
</t> <dt>Pseudonymization:</dt><dd> Format-preserving, prefix preservation
</section> (general).</dd>
</dl>
<section anchor="ipcipher" title="ipcipher"> </section>
<t>A recently-released proposal from PowerDNS, ipcipher <section anchor="ipcipher" numbered="true" toc="default">
<xref target="ipcipher1"/> <xref target="ipcipher2"/> is a simple <name>ipcipher</name>
<t>A recently released proposal from PowerDNS, ipcipher
<xref target="ipcipher1" format="default"/> <xref target="ipcipher2"
format="default"/>, is a simple
pseudonymization technique for IPv4 and IPv6 addresses. IPv6 addresses are pseudonymization technique for IPv4 and IPv6 addresses. IPv6 addresses are
encrypted directly with AES-128 using a key (which may be derived from a encrypted directly with AES-128 using a key (which may be derived from a
passphrase). IPv4 addresses are similarly encrypted, but using a recently passphrase). IPv4 addresses are similarly encrypted, but using a recently
proposed encryption <xref target="ipcrypt"/> suitable for 32bit proposed encryption <xref target="ipcrypt" format="default"/> suitable for
block lengths. However, the author of ipcrypt has since indicated <xref 32-bit block lengths. However, the author of ipcrypt has since indicated <xref
target="ipcrypt-analysis"/> that it has target="ipcrypt-analysis" format="default"/> that it has
low security, and further analysis has revealed it is vulnerable to attack. low security, and further analysis has revealed it is vulnerable to attack.
</t> </t>
<t>Pseudonymization: Format-preserving, cryptographic permutation. <dl>
</t> <dt>Pseudonymization:</dt><dd>Format-preserving, cryptographic permuta
</section> tion.</dd>
</dl>
<section anchor="bloom-filters" title="Bloom filters"> </section>
<t>van Rijswijk-Deij et al. <section anchor="bloom-filters" numbered="true" toc="default">
have recently described work using Bloom filters <xref target="Bloom-filter"/> <name>Bloom Filters</name>
<t>van Rijswijk-Deij et al.
have recently described work using Bloom Filters <xref target="Bloom-filter" for
mat="default"/>
to to
categorize query traffic and record the traffic as the state of multiple 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 filters. The goal of this work is to allow operators to identify so-called
Indicators of Compromise (IOCs) originating from specific subnets without Indicators of Compromise (IOCs) originating from specific subnets without
storing information about, or be able to monitor the DNS queries of an 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 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 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 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 from a sufficient number of users in a single filter, it becomes practically
impossible to determine if a particular user performed a particular impossible to determine if a particular user performed a particular
query. Large query. Large
numbers of queries can be tracked in a memory-efficient way. As filter status numbers of queries can be tracked in a memory-efficient way. As filter status
is is
stored, this approach cannot be used to regenerate traffic, and so cannot be stored, this approach cannot be used to regenerate traffic and so cannot be
used with tools used to process live traffic. used with tools used to process live traffic.
</t>
<dl>
<dt>Anonymized:</dt><dd> Generalization.</dd>
</dl>
</section>
</section>
</section>
<section anchor="current-policy-and-privacy-statements" numbered="true" toc=
"default">
<name>Current Policy and Privacy Statements</name>
<t>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 <xref target="policy-comparison" format="default"/>. The
analysis is based on the data available in December 2019.
</t> </t>
<t>Anonymized: Generalization. <t>We note that the existing policies vary widely in style, content, and
</t> detail, and it is not uncommon for the full text for a given operator to
</section> equate to more than 10 pages (A4 size) of text in a moderate-sized font. It is a
</section> nontrivial task today for a user to extract a meaningful overview of the
</section>
<section anchor="current-policy-and-privacy-statements" title="Current policy
and privacy statements">
<t>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 <xref target="policy-comparison"/>. The analysis is based on the
data
available in December 2019.
</t>
<t>We note that the existing set of policies vary widely in style, content and
detail and it is not uncommon for the full text for a given operator to
equate to more than 10 pages of moderate font sized A4 text. It is a
non-trivial task today for a user to extract a meaningful overview of the
different services on offer. different services on offer.
</t> </t>
<t>It is also noted that Mozilla have published a DoH resolver policy <t>It is also noted that Mozilla has published a DoH resolver policy
<xref target="DoH-resolver-policy"/>, which describes the minimum set of <xref target="DoH-resolver-policy" format="default"/> that describes the minimum
set of
policy policy
requirements that a party must satisfy to be considered as a potential requirements that a party must satisfy to be considered as a potential
partner for Mozilla’s Trusted Recursive Resolver (TRR) program. partner for Mozilla's Trusted Recursive Resolver (TRR) program.
</t> </t>
</section> </section>
<section anchor="example-rps" numbered="true" toc="default">
<section anchor="example-rps" title="Example RPS"> <name>Example RPS</name>
<t>The following example RPS is very loosely based on some elements of <t>The following example RPS is very loosely based on some elements of
published privacy statements for some public resolvers, with additional fields published privacy statements for some public resolvers, with additional fields
populated to illustrate the what the full contents of an RPS might populated to illustrate what the full contents of an RPS might
look like. This should not be interpreted as look like. This should not be interpreted as
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>having been reviewed or approved by any operator in any way</li>
<t>having been reviewed or approved by any operator in any way</t> <li>having any legal standing or validity at all</li>
<t>having any legal standing or validity at all</t> <li>being complete or exhaustive</li>
<t>being complete or exhaustive</t> </ul>
</list> <t>This is a purely hypothetical example of an RPS to outline example
</t> contents -- in this case, for a public resolver operator providing a basic DNS
<t>This is a purely hypothetical example of an RPS to outline example Privacy service via one IP address and one DoH URI with security-based
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 filtering. It does aim to meet minimal compliance as specified in
<xref target="recommendations-for-dns-privacy-services"/>. <xref target="recommendations-for-dns-privacy-services" format="default"/>.
</t> </t>
<section anchor="policy-1" title="Policy"> <section anchor="policy-1" numbered="true" toc="default">
<t> <name>Policy</name>
<list style="numbers"> <ol spacing="normal" type="1">
<t>Treatment of IP addresses. Many nations classify IP addresses as personal <li>Treatment of IP addresses. Many nations classify IP addresses as p
ersonal
data, and we take a conservative approach in treating 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.</t> data in all jurisdictions in which our systems reside.</li>
<t>Data collection and sharing. <li>
<list style="numbers"> <t>Data collection and sharing.
<t>IP addresses. Our normal course of data management does </t>
<ol spacing="normal" type="a">
<li>IP addresses. Our normal course of data management does
not have any IP address information or other personal data logged to disk or 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 transmitted out of the location in which the query was received. We may
aggregate certain counters to larger network block levels for statistical aggregate certain counters to larger network block levels for
collection purposes, but those counters do not maintain specific IP address statistical collection purposes, but those counters do not maintain specific
data nor is the format or model of data stored capable of being 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 reverse-engineered to ascertain what specific IP addresses made what
queries.</t> queries.</li>
<t>Data collected in logs. We do keep some generalized location information <li>
(at the city/metropolitan area level) so that we can conduct debugging and <t>Data collected in logs. We do keep some generalized
analyze abuse phenomena. We also use the collected information for the location information
creation and sharing of telemetry (timestamp, geolocation, number of hits, (at the city / metropolitan-area level) so that we can conduct de
first seen, last seen) for contributors, public publishing of general bugging and
statistics of system use (protections, threat types, counts, etc.) analyze abuse phenomena. We also use the collected information fo
When you use our DNS Services, here is the full list of items that are r the
included in our logs: creation and sharing of telemetry (timestamp, geolocation, number
<list style="symbols"> of hits,
<t>Request domain name, e.g., example.net</t> first seen, last seen) for contributors, public publishing of gen
<t>Record type of requested domain, e.g., A, AAAA, NS, MX, TXT, etc.</t> eral
<t>Transport protocol on which the request arrived, i.e. UDP, TCP, DoT, statistics of system use (protections, threat types, counts, etc.
<vspace/> ).
DoH</t> When you use our DNS services, here is the full list of items tha
<t>Origin IP general geolocation information: i.e. geocode, region ID, t are
city ID, and metro code</t> included in our logs:
<t>IP protocol version – IPv4 or IPv6</t> </t>
<t>Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN, etc.</t> <ul spacing="normal">
<t>Absolute arrival time using a precision in ms</t> <li>Requested domain name -- e.g., example.net</li>
<t>Name of the specific instance that processed this request</t> <li>Record type of requested domain -- e.g., A, AAAA, NS,
<t>IP address of the specific instance to which this request was MX, TXT, etc.</li>
addressed (no relation to the requestor’s IP address)</t> <li>
</list> <t>Transport protocol on which the request arrived --
i.e., UDP, TCP, DoT, DoH</t>
</li>
<li>Origin IP general geolocation information -- i.e., geocode
, region ID,
city ID, and metro code</li>
<li>IP protocol version -- IPv4 or IPv6</li>
<li>Response code sent -- e.g., SUCCESS, SERVFAIL, NXDOMAIN, e
tc.</li>
<li>Absolute arrival time using a precision in ms</li>
<li>Name of the specific instance that processed this request<
/li>
<li>IP address of the specific instance to which this request
was
addressed (no relation to the requestor's IP address)</li>
</ul>
<t>
We may keep the following data as summary information, including all the We may keep the following data as summary information, including all the
above EXCEPT for data about the DNS record requested: above EXCEPT for data about the DNS record requested:
<list style="symbols"> </t>
<t>Currently-advertised BGP-summarized IP prefix/netmask of apparent <ul spacing="normal">
client origin</t> <li>Currently advertised BGP-summarized IP prefix/netmask of a
<t>Autonomous system number (BGP ASN) of apparent client origin</t> pparent
</list> client origin</li>
<li>Autonomous system number (BGP ASN) of apparent client orig
in</li>
</ul>
<t>
All the above data may be kept in full or partial form in permanent All the above data may be kept in full or partial form in permanent
archives.</t> archives.</t>
<t>Sharing of data. </li>
<li>Sharing of data.
Except as described in this document, we do not intentionally share, Except as described in this document, we do not intentionally share,
sell, or rent individual personal information associated with the sell, or rent individual personal information associated with the
requestor (i.e. source IP address or any other information that can requestor (i.e., source IP address or any other information that can
positively identify the client using our infrastructure) with anyone positively identify the client using our infrastructure) with anyone
without your consent. without your consent.
We generate and share high level anonymized aggregate statistics We generate and share high-level anonymized aggregate statistics,
including threat metrics on threat type, geolocation, and if available, including threat metrics on threat type, geolocation, and if available,
sector, as well as other vertical metrics including performance metrics sector, as well as other vertical metrics, including performance metrics
on our DNS Services (i.e. number of threats blocked, infrastructure on our DNS Services (i.e., number of threats blocked, infrastructure
uptime) when available with our threat intelligence (TI) partners, uptime) when available with our Threat Intelligence (TI) partners,
academic researchers, or the public. academic researchers, or the public.
Our DNS Services share anonymized data on specific domains queried Our DNS services share anonymized data on specific domains queried
(records such as domain, timestamp, geolocation, number of hits, first (records such as domain, timestamp, geolocation, number of hits, first
seen, last seen) with our threat intelligence partners. Our DNS Services seen, last seen) with our Threat Intelligence partners. Our DNS service
also builds, stores, and may share certain DNS data streams which store also builds, stores, and may share certain DNS data streams which store
high level information about domain resolved, query types, result codes, high level information about domain resolved, query types, result codes,
and timestamp. These streams do not contain IP address information of and timestamp. These streams do not contain the IP address information of
requestor and cannot be correlated to IP address or other personal data. the requestor and cannot be correlated to IP address or other personal data.
We do not and never will share any of its data with marketers, nor will We do not and never will share any of the requestor's data with marketers, nor w
it use this data for demographic analysis.</t> ill
</list></t> we use this data for demographic analysis.</li>
<t>Exceptions. There are exceptions to this storage model: In the event of </ol>
actions or observed behaviors which we deem malicious or anomalous, we may </li>
<li>Exceptions. There are exceptions to this storage model: In the eve
nt 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 utilize more detailed logging to collect more specific IP address data in the
process of normal network defence and mitigation. This collection and process of normal network defense and mitigation. This collection and
transmission off-site will be limited to IP addresses that we determine are transmission off-site will be limited to IP addresses that we determine are
involved in the event.</t> involved in the event.</li>
<t>Associated entities. Details of our Threat Intelligence partners can be <li>Associated entities. Details of our Threat Intelligence partners c
an be
found found
at our website page (insert link).</t> at our website page (insert link).</li>
<t>Correlation of Data. We do not correlate or combine information from our <li>Correlation of Data. We do not correlate or combine information fr
om our
logs logs
with any personal information that you have provided us for other services, or with any personal information that you have provided us for other services, or
with your specific IP address.</t> with your specific IP address.</li>
<t>Result filtering. <li>
<list style="numbers"> <t>Result filtering.
<t>Filtering. We utilise cyber threat intelligence about malicious domains </t>
from a variety of public and private sources and blocks access to those <ol spacing="normal" type="a">
malicious domains when your system attempts to contact them. An NXDOMAIN is <li>
returned for blocked sites. <t>Filtering. We utilize cyber-threat intelligence about
<list style="numbers"> malicious domains
<t>Censorship. We will not provide a censoring component and will limit our 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.
</t>
<ol spacing="normal" type="i">
<li>Censorship. We will not provide a censoring component and
will limit our
actions solely to the blocking of malicious domains around phishing, actions solely to the blocking of malicious domains around phishing,
malware, and exploit kit domains.</t> malware, and exploit-kit domains.</li>
<t>Accidental blocking. We implement allowlisting algorithms to make sure <li>Accidental blocking. We implement allowlisting algorithms
to make sure
legitimate domains are not blocked by accident. However, in the rare case of 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 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 that domain. Please use our support form (insert link) if you believe we are
blocking a domain in error.</t> blocking a domain in error.</li>
</list></t> </ol>
</list></t> </li>
</list> </ol>
</t> </li>
</section> </ol>
</section>
<section anchor="practice-1" title="Practice"> <section anchor="practice-1" numbered="true" toc="default">
<t> <name>Practice</name>
<list style="numbers"> <ol spacing="normal" type="1">
<t>Deviations from Policy. None in place since (insert date).</t> <li>Deviations from Policy. None in place since (insert date).</li>
<t>Client facing capabilities. <li>
<list style="numbers"> <t>Client-facing capabilities.
<t>We offer UDP and TCP DNS on port 53 on (insert IP address)</t> </t>
<t>We offer DNS over TLS as specified in RFC7858 on (insert IP address). It <ol spacing="normal" type="a">
is available on port 853 and port 443. We also implement RFC7766. <li>We offer UDP and TCP DNS on port 53 on (insert IP address)</li
<list style="numbers"> >
<t>The DoT authentication domain name used is (insert domain name).</t> <li>
<t>We do not publish SPKI pin sets.</t> <t>We offer DNS over TLS as specified in RFC 7858 on (insert
</list></t> IP address). It
<t>We offer DNS over HTTPS as specified in RFC8484 on (insert URI is available on port 853 and port 443. We also implement RFC 7766
template).</t> .
<t>Both services offer TLS 1.2 and TLS 1.3.</t> </t>
<t>Both services pad DNS responses according to RFC8467.</t> <ol spacing="normal" type="i">
<t>Both services provide DNSSEC validation. <li>The DoT authentication domain name used is (insert domain
name).</li>
<li>We do not publish SPKI pin sets.</li>
</ol>
</li>
<li>We offer DNS over HTTPS as specified in RFC 8484 on (insert UR
I
template).</li>
<li>Both services offer TLS 1.2 and TLS 1.3.</li>
<li>Both services pad DNS responses according to RFC 8467.</li>
<li>
<t>Both services provide DNSSEC validation.
<vspace/></t> </t>
</list></t> <t/>
<t>Upstream capabilities. </li>
<list style="numbers"> </ol>
<t>Our servers implement QNAME minimization.</t> </li>
<t>Our servers do not send ECS upstream.</t> <li>
</list></t> <t>Upstream capabilities.
<t>Support. Support information for this service is available at (insert </t>
link).</t> <ol spacing="normal" type="a">
<t>Data Processing. We operate as the legal entity (insert entity) registered <li>Our servers implement QNAME minimization.</li>
<li>Our servers do not send ECS upstream.</li>
</ol>
</li>
<li>Support. Support information for this service is available at (ins
ert
link).</li>
<li>Data Processing. We operate as the legal entity (insert entity) re
gistered
in in
(insert country); as such we operate under (insert country/region) law. Our (insert country); as such, we operate under (insert country/region) law. Our
separate statement regarding the specifics of our data processing policy, separate statement regarding the specifics of our data processing policy,
practice, and agreements can be found here (insert link).</t> practice, and agreements can be found here (insert link).</li>
</list> </ol>
</section>
</section>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks to <contact fullname="Amelia Andersdotter"/> for a very
thorough review of the first draft of this document and <contact
fullname="Stephen Farrell"/> for a thorough review at Working Group Last
Call and for
suggesting the inclusion of an example RPS. Thanks to <contact
fullname="John Todd"/> for discussions on this topic, and to <contact
fullname="Stéphane Bortzmeyer"/>, <contact fullname="Puneet Sood"/>, and
<contact fullname="Vittorio Bertola"/> for review. Thanks to <contact
fullname="Daniel Kahn Gillmor"/>, <contact fullname="Barry Green"/>,
<contact fullname="Paul Hoffman"/>, <contact fullname="Dan York"/>,
<contact fullname="Jon Reed"/>, and <contact fullname="Lorenzo
Colitti"/> for comments at the mic. Thanks to <contact
fullname="Loganaden Velvindron"/> for useful updates to the text.
</t> </t>
</section> <t><contact fullname="Sara Dickinson"/> thanks the Open Technology Fund fo
</section> r a grant to support the
work
on this document.
</t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
</back> <t>The below individuals contributed significantly to the document:
</t>
<contact fullname="John Dickinson">
<organization>Sinodun IT</organization>
<address>
<postal>
<street/>
<extaddr>Magdalen Centre</extaddr>
<street>Oxford Science Park</street>
<city>Oxford</city><code>OX4 4GA</code>
<country>United Kingdom</country>
<region/>
</postal>
</address>
</contact>
<contact fullname="Jim Hague">
<organization>Sinodun IT</organization>
<address>
<postal>
<street/>
<extaddr>Magdalen Centre</extaddr>
<street>Oxford Science Park</street>
<city>Oxford</city><code>OX4 4GA</code>
<country>United Kingdom</country>
<region/>
</postal>
</address>
</contact>
</section>
</back>
</rfc> </rfc>
 End of changes. 222 change blocks. 
2038 lines changed or deleted 2319 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/