<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-ietf-dprive-bcp-op-14" number="8932" obsoletes=""
     updates="" submissionType="IETF" 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"?> consensus="true"
     xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
     version="3">

  <!-- 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"/>

    <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
      <organization>Sinodun IT</organization>
      <address>
        <postal>
<street></street>
<street>Magdalen Centre</street>
	  <extaddr>Magdalen Centre</extaddr>
          <street>Oxford Science Park</street>
          <city>Oxford</city>
          <code>OX4 4GA</code>
          <country>United Kingdom</country>
<region></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>
          <country>Netherlands</country>
          <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>
          <country>Netherlands</country>
          <region/>
        </postal>
<phone></phone>
        <email>roland@nlnetLabs.nl</email>
<uri></uri>
      </address>
    </author>
    <author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization>Salesforce</organization>
      <organization abbrev="Salesforce">Salesforce.com, Inc.</organization>
      <address>
        <postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
          <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>
<phone></phone>
        <email>allison.mankin@gmail.com</email>
<uri></uri>
      </address>
    </author>
    <date year="2020" month="July" day="13"/> month="October"/>
    <area>Internet</area>
    <workgroup>dprive</workgroup>
    <keyword>DNS</keyword>
    <abstract>

      <t>This document presents operational, policy, and security
      considerations for DNS recursive resolver operators who choose to offer
      DNS Privacy privacy services.  With these recommendations, the operator can make
      deliberate decisions regarding which services to provide, and as well as
      understanding how the 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 Statement, analogous to DNS
      Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
      described in RFC6841). RFC 6841.
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Domain Name System (DNS) is at the core of the Internet; almost every
activity on the Internet starts with a DNS query (and often several). However However,
the DNS was not originally designed with strong security or privacy
mechanisms.
A number of developments have taken place in recent years which that aim to
increase
the privacy of the DNS system DNS, and these are now seeing some deployment. This
latest evolution of the DNS presents new challenges to operators operators, and this
document attempts to provide an overview of considerations for privacy focused privacy-focused
DNS services.
</t>
      <t>In recent years years, there has also been an increase in the availability of
&quot;public
resolvers&quot;
"public
resolvers" <xref target="RFC8499"/> target="RFC8499" format="default"/>, which users may prefer
to use instead of the default
network resolver resolver, either because they offer a specific feature (e.g., good
reachability or encrypted transport) or because the network resolver lacks a
specific feature (e.g., strong privacy policy or unfiltered responses). These
public resolvers have tended to be at the forefront of adoption of
privacy-related
enhancements
enhancements, but it is anticipated that operators of other resolver services
will follow.
</t>
      <t>Whilst protocols that encrypt DNS messages on the wire provide protection
against certain attacks, the resolver operator still has (in principle) full
visibility of the query data and transport identifiers for each
user. Therefore,
a trust relationship (whether explicit or implicit) is assumed to exist
between
each user and the operator of the resolver(s) used by that user. The ability
of
the operator to provide a transparent, well documented, well-documented, and secure privacy
service will likely serve as a major differentiating factor for privacy
conscious
privacy-conscious users if they make an active selection of which resolver to
use.
</t>
      <t>It should also be noted that the choice of there are both advantages and
      disadvantages to a user choosing to configure a single resolver
(or a fixed set of resolvers) and an encrypted transport to use in all network
environments has both advantages and disadvantages.
environments. For example, the user has a
clear expectation of which resolvers have visibility of their query data.
However, this resolver/transport selection may provide an added mechanism to
track for
tracking them as they move across network environments. Commitments from
resolver
operators to minimize such tracking as users move between networks are also
likely to play a role in user selection of resolvers.
</t>
      <t>More recently recently, the global legislative landscape with regard to personal data
collection, retention, and pseudonymization has seen significant activity.
Providing detailed practice advice about these areas to the operator is out of
scope, but <xref target="data-sharing"/> target="data-sharing" format="default"/> describes some mitigations of data
sharing data-sharing risk.
</t>
      <t>This document has two main goals:
</t>
<t>
<list style="symbols">
<t>To
      <ul spacing="normal">
        <li>To provide operational and policy guidance related to DNS over encrypted
transports and to outline recommendations for data handling for operators of
DNS privacy services.</t>
<t>To services.</li>
        <li>To introduce the Recursive operator Privacy Statement (RPS) and present a
framework to assist writers of an RPS. An RPS is a
document that an operator should publish which that outlines their operational
practices and commitments with regard to privacy, thereby providing a means
for clients to evaluate both the measurable and claimed privacy properties of
a given DNS privacy service. The framework identifies a set of elements and
specifies an outline order for them. This document does not, however, define a
particular privacy statement, nor does it seek to provide legal advice as to
the contents.</t>
</list>
</t> contents of an RPS.</li>
      </ul>
      <t>A desired operational impact is that all operators (both those providing
resolvers within networks and those operating large public services) can
demonstrate their commitment to user privacy privacy, thereby driving all DNS
resolution
services to a more equitable footing. Choices for users would (in this ideal
world) be driven by other factors, factors -- e.g., differing security policies or minor
difference
differences in operator policy, policy -- rather than gross disparities in privacy
concerns.
</t>

      <t>Community insight [or judgment?] (or judgment?) about operational practices can change
quickly, and experience shows that a Best Current Practice (BCP) document
about
privacy and security is a point-in-time statement. Readers are advised to seek
out any updates that apply to this document.
</t>
    </section>
    <section anchor="scope" title="Scope">
<t>&quot;DNS numbered="true" toc="default">
      <name>Scope</name>
      <t>"DNS Privacy Considerations&quot; Considerations" <xref target="RFC7626"/> target="RFC7626" format="default"/> describes
the general privacy issues
and threats associated with the use of the DNS by Internet users and users; much of
the threat analysis here is lifted from that document and from <xref
target="RFC6973"/>. However
target="RFC6973" format="default"/>. However,
this document is limited in scope to best practice best-practice considerations for the
provision of DNS privacy services by servers (recursive resolvers) to clients
(stub resolvers or forwarders). Choices that are made exclusively by
the end user, or those for operators of authoritative nameservers nameservers, are out
of scope.
</t>
      <t>This document includes (but is not limited to) considerations in the
following
areas:
</t>
<t>
<list style="numbers">
<t>Data &quot;on
      <ol spacing="normal" type="1">
        <li>Data "on the wire&quot; wire" between a client and a server.</t>
<t>Data &quot;at rest&quot; server.</li>
        <li>Data "at rest" on a server (e.g., in logs).</t>
<t>Data &quot;sent onwards&quot; logs).</li>
        <li>Data "sent onwards" from the server (either on the wire or shared
with a
third party).</t>
</list>
</t> party).</li>
      </ol>
      <t>Whilst the issues raised here are targeted at those operators who choose to
offer a DNS privacy service, considerations for areas 2 and 3 could equally
apply to operators who only offer DNS over unencrypted transports but who
would
otherwise like to align with privacy best practice.
</t>
    </section>
    <section anchor="privacyrelated-documents" title="Privacy-related documents"> numbered="true" toc="default">
      <name>Privacy-Related Documents</name>
      <t>There are various documents that describe protocol changes that have the
potential to either increase or decrease the privacy properties of the DNS in
various ways. Note that this does not imply that some documents are good or bad,
better or worse, just that (for example) some features may bring functional
benefits at the price of a reduction in privacy privacy, and conversely some features
increase privacy with an accompanying increase in complexity. A selection of
the
most relevant documents are is listed in <xref target="documents"/> target="documents" format="default"/> for
reference.
</t>
    </section>
    <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;,
&quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;,
&quot;MAY&quot;, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>",
"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and &quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> target="RFC2119" format="default"/>
        <xref target="RFC8174"/> target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>DNS
      <t>
DNS terminology is as described in <xref target="RFC8499"/> target="RFC8499"/>, except with one
modification: we restate
the clause in
regard to the original definition of Privacy-enabling privacy-enabling DNS server in <xref target="RFC8310"/> to include
target="RFC8499" section="6" sectionFormat="of" />. In this document we use
the requirement that full definition of a DNS over (D)TLS privacy-enabling DNS server as given
in <xref target="RFC8310"/>, i.e., that such a server should also offer at
least one of the credentials described in Section 8 of <xref
target="RFC8310"/> target="RFC8310" section="8"
sectionFormat="of"/> and implement the (D)TLS profile described in Section 9 of <xref
target="RFC8310"/>.
target="RFC8310" section="9" sectionFormat="of"/>.
      </t>

      <t>Other Terms:
</t>
<t>
<list style="symbols">
<t>RPS: Recursive
      <dl>
        <dt>RPS:</dt><dd>Recursive operator Privacy Statement, Statement; see
	<xref target="recursive-operator-privacy-statement-rps"/>.</t>
<t>DNS target="recursive-operator-privacy-statement-rps"
      format="default"/>.</dd>
        <dt>DNS privacy service: The 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.</t>
</list>
</t> RPS.</dd>
      </dl>
    </section>
    <section anchor="recommendations-for-dns-privacy-services"
	 title="Recommendations numbered="true" toc="default">
      <name>Recommendations for DNS privacy services"> Privacy Services</name>
      <t>In the following sections sections, we first outline the threats relevant to the
specific topic and then discuss the potential actions that can be taken to
mitigate them.
</t>
      <t>We describe two classes of threats:
</t>
<t>
<list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Threats described in <xref target="RFC6973"/> 'Privacy target="RFC6973" format="default"/>,
	  "Privacy Considerations for Internet Protocols'
<list style="symbols">
<t>Privacy Protocols"
</t>
          <ul spacing="normal">
            <li>Privacy terminology, threats to privacy, and mitigations as
	    described in Sections 3, 5, <xref target="RFC6973" section="3"
	    sectionFormat="bare"/>, <xref target="RFC6973" section="5"
	    sectionFormat="bare"/>, and 6 <xref target="RFC6973" section="6"
	    sectionFormat="bare"/> of <xref target="RFC6973"/>.</t>
</list></t> target="RFC6973"/>.</li>
          </ul>
        </li>
        <li>
          <t>DNS Privacy Threats
<list style="symbols">
<t>These
</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"/>. target="RFC6973"
	    format="default"/>. These may be more
	    operational in
nature
	    nature, such as certificate management certificate-management or service availability issues.</t>
</list></t>
</list>
</t> service-availability issues.</li>
          </ul>
        </li>
      </ul>
      <t>We describe three classes of actions that operators of DNS privacy
services can take:
</t>
<t>
<list style="symbols">
<t>Threat
      <ul spacing="normal">
        <li>Threat mitigation for well understood well-understood and documented privacy threats to the
users of the service and and, in some cases to cases, the operators of the service.</t>
<t>Optimization service.</li>
        <li>Optimization of privacy services from an operational or management
perspective.</t>
<t>Additional
perspective.</li>
        <li>Additional options that could further enhance the privacy and usability of
the
service.</t>
</list>
</t>
service.</li>
      </ul>
      <t>This document does not specify policy - policy, only best practice, however practice. However, for DNS
Privacy
privacy services to be considered compliant with these best practice
guidelines best-practice
guidelines,
they SHOULD <bcp14>SHOULD</bcp14> implement (where appropriate) all:
</t>
<t>
<list style="symbols">
<t>Threat
      <ul spacing="normal">
        <li>Threat mitigations to be minimally compliant.</t>
<t>Optimizations compliant.</li>
        <li>Optimizations to be moderately compliant.</t>
<t>Additional compliant.</li>
        <li>Additional options to be maximally compliant.</t>
</list>
</t> compliant.</li>
      </ul>
      <t>The rest of this document does not use normative language but instead
refers
only to the three differing classes of action which that correspond to the three
named levels of compliance stated above. However, compliance (to the indicated
level) remains a normative requirement.
</t>
      <section anchor="on-the-wire-between-client-and-server" title="On numbered="true" toc="default">
        <name>On the wire Wire between client Client and server"> Server</name>
        <t>In this section section, we consider both data on the wire and the service provided
	to the client.
	</t>

        <section anchor="transport-recommendations" title="Transport recommendations">
<t><xref target="RFC6973"/> Threats:
</t>
<t>
<list style="symbols">
<t>Surveillance:
<list style="symbols">
<t>Passive numbered="true" toc="default">
          <name>Transport Recommendations</name>

          <dl newline="true">
	  <dt>Threats described in <xref target="RFC6973" format="default"/>:</dt>
<dd>
          <dl newline="true">
              <dt>Surveillance:</dt>
              <dd>Passive surveillance of traffic on the wire</t>
</list></t>
</list>
</t>
<t>DNS wire.</dd>
	  </dl>
          </dd>

          <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Active Threats:</dt>

            <dd>Active injection of spurious data or traffic.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>A traffic.</dd>

          <dt>Mitigations:</dt>

          <dd><t>A DNS privacy service can mitigate these threats by providing
	  service over one
	  or more of the following transports
</t>
<t>
<list style="symbols">
<t>DNS transports:</t>

          <ul spacing="normal">
            <li>DNS over TLS (DoT) <xref target="RFC7858"/> and target="RFC7858" format="default"/>
	    <xref
target="RFC8310"/>.</t>
<t>DNS target="RFC8310" format="default"/>.</li>
            <li>DNS over HTTPS (DoH) <xref target="RFC8484"/>.</t>
</list>
</t> target="RFC8484" format="default"/>.</li>
          </ul>
	  </dd>
	  </dl>

          <t>It is noted that a DNS privacy service can also be provided over DNS over
DTLS
<xref target="RFC8094"/>, however target="RFC8094" format="default"/>; however, this is an Experimental specification
specification, and
there are no known
implementations at the time of writing.
</t>

          <t>It is also noted that DNS privacy service might be
          provided over IPSec,
DNSCrypt, DNSCrypt <xref target="DNSCrypt"/>, IPsec, or VPNs. However, there are
          no specific RFCs that cover the use of these transports for DNS
          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 connection, this
	  does not diminish the need
	  for
DNSSEC, DNSSEC; see <xref target="dnssec"/>. target="dnssec" format="default"/>.
</t>
        </section>
        <section anchor="authentication-of-dns-privacy-services" title="Authentication numbered="true" toc="default">
          <name>Authentication of DNS privacy services">
<t><xref target="RFC6973"/> Threats:
</t>
<t>
<list style="symbols">
<t>Surveillance:
<list style="symbols">
<t>Active Privacy Services</name>

	  <dl newline="true">
	    <dt>Threats described in <xref target="RFC6973" format="default"/>:</dt>
	    <dd>
          <dl newline="true">
              <dt>Surveillance:</dt>
              <dd>Active attacks on client resolver configuration</t>
</list></t>
</list>
</t>
<t>Mitigations:
</t> 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' "Strict Privacy" usage
            profile <xref
target="RFC8310"/> 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
DNS over TLS 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"/> target="RFC5280" format="default"/> or Subject
            Public Key Info (SPKI) pin sets <xref target="RFC8310"/>. target="RFC8310"
            format="default"/>.
	    </t>

	    <t>When offering DoH <xref target="RFC8484"/>, target="RFC8484" format="default"/>,
	    HTTPS requires authentication of the server as part of the protocol.
	    </t>
<t>Server operators should also follow the best practices with regard to
certificate revocation as described in <xref target="RFC7525"/>.
</t>
	  </dd>
	  </dl>

          <section anchor="certificate-management" title="Certificate management"> numbered="true" toc="default">
            <name>Certificate Management</name>
            <t>Anecdotal evidence to date highlights the management of certificates as one
of
the more challenging aspects for operators of traditional DNS resolvers that
choose to additionally provide a DNS privacy service service, as management of such
credentials is new to those DNS operators.
</t>
            <t>It is noted that SPKI pin set management is described in <xref
target="RFC7858"/> target="RFC7858" format="default"/> but that key
pinning key-pinning mechanisms in general have fallen out of favor operationally for
various reasons reasons, such as the logistical overhead of rolling keys.
	    </t>
<t>DNS

	  <dl newline="true">
          <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Invalid Threats:</dt>

          <dd>
	    <ul spacing="normal">
              <li>Invalid certificates, resulting in an unavailable service service, which might force a
	      user to fallback fall back to cleartext.</t>
<t>Mis-identification cleartext.</li>
              <li>Misidentification of a server by a client -- e.g., typos in DoH URL templates
	      <xref target="RFC8484"/> target="RFC8484" format="default"/> or authentication domain names <xref
target="RFC8310"/> which target="RFC8310" format="default"/> that accidentally direct
	      clients to attacker controlled servers.</t>
</list>
</t>
<t>Mitigations:
</t> attacker-controlled servers.</li>
            </ul>
	  </dd>

            <dt>Mitigations:</dt>
            <dd>
	      <t>It is recommended that operators:
</t>
<t>
<list style="symbols">
<t>Follow
            <ul spacing="normal">
              <li>Follow the guidance in Section 6.5 of <xref target="RFC7525"/> target="RFC7525" section="6.5"
	      sectionFormat="of"/> with regards regard to certificate
revocation.</t>
<t>Automate revocation.</li>
              <li>Automate the generation, publication, and renewal of certificates. For
	      example,
ACME Automatic Certificate Management Environment (ACME)
	      <xref target="RFC8555"/> target="RFC8555" format="default"/> provides a
	      mechanism to actively manage certificates through
	      automation and has been implemented by a number of certificate
authorities.</t>
<t>Monitor
	      authorities.</li>
              <li>Monitor certificates to prevent accidental expiration of certificates.</t>
<t>Choose certificates.</li>
              <li>Choose a short, memorable authentication domain name for the service.</t>
</list>
</t> service.</li>
            </ul>
	    </dd>
	  </dl>

          </section>
        </section>
        <section anchor="protocol-recommendations" title="Protocol recommendations"> numbered="true" toc="default">
          <name>Protocol Recommendations</name>
          <section anchor="dot" title="DoT">
<t>DNS numbered="true" toc="default">
            <name>DoT</name>

	    <dl newline="true">

            <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Known Threats:</dt>
<dd>
            <ul spacing="normal">
              <li>Known attacks on TLS TLS, such as those described in <xref
target="RFC7457"/>.</t>
<t>Traffic
	      target="RFC7457" format="default"/>.</li>
              <li>Traffic analysis, for example: <xref
target="Pitfalls-of-DNS-Encryption"/>.</t>
<t>Potential
	      target="Pitfalls-of-DNS-Encryption" format="default"/> (focused
	      on DoT).</li>
              <li>Potential for client tracking via transport identifiers.</t>
<t>Blocking identifiers.</li>
              <li>Blocking of well known well-known ports (e.g., 853 for DoT).</t>
</list>
</t>
<t>Mitigations:
</t> DoT).</li>
            </ul>
</dd>
            <dt>Mitigations:</dt>

           <dd> <t>In the case of DoT, TLS profiles from Section 9 of <xref target="RFC8310"/>
           target="RFC8310" section="9" sectionFormat="of"/> and the
Countermeasures
           "Countermeasures to DNS Traffic Analysis Analysis" from section 11.1 of <xref
target="RFC8310"/>
           target="RFC8310" section="11.1" sectionFormat="of"/>
           provide strong mitigations. This includes but is not
           limited to:
</t>
<t>
<list style="symbols">
<t>Adhering
            <ul spacing="normal">
              <li>Adhering to <xref target="RFC7525"/>.</t>
<t>Implementing target="RFC7525" format="default"/>.</li>
              <li>Implementing only (D)TLS 1.2 or later later, as specified in <xref
target="RFC8310"/>.</t>
<t>Implementing EDNS(0) target="RFC8310" format="default"/>.</li>
              <li>Implementing Extension Mechanisms for DNS (EDNS(0)) Padding
	      <xref target="RFC7830"/> target="RFC7830" format="default"/> using the guidelines
in
<xref target="RFC8467"/> target="RFC8467" format="default"/> or a successor specification.</t>
<t>Servers specification.</li>

              <li>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"/> target="RFC5077" format="default"/> with TLS 1.2, section 2.2 of <xref
target="RFC8446"/>, 1.2
	      (<xref target="RFC8446" section="2.2" sectionFormat="of"/>) or Domain
	      Name System (DNS) Cookies <xref target="RFC7873"/>.</t>
<t>A target="RFC7873" format="default"/>.</li>

              <li>A DoT privacy service on both port 853 and 443. If the
	      operator deploys DoH
	      on the same IP address address, this requires the use of the 'dot' ALPN "dot"
	      Application-Layer Protocol Negotiation (ALPN) value <xref
target="dot-ALPN"/>.</t>
</list>
</t>
<t>Optimizations:
</t>
<t>
<list style="symbols">
<t>Concurrent
target="dot-ALPN" format="default"/>.</li>
            </ul>
	   </dd>

            <dt>Optimizations:</dt>
<dd>
            <ul spacing="normal">
              <li>Concurrent processing of pipelined queries, returning
	      responses as soon as
	      available, potentially out of order order, as specified in <xref
target="RFC7766"/>. target="RFC7766"
	      format="default"/>. This is often
	      called 'OOOR' - "OOOR" -- out-of-order responses (providing processing performance
	      similar to HTTP multiplexing).</t>
<t>Management multiplexing).</li>
              <li>Management of TLS connections to optimize performance for clients using
	      <xref target="RFC7766"/> target="RFC7766" format="default"/> and EDNS(0) Keepalive
	      <xref target="RFC7828"/></t>
</list>
</t>
<t>Additional Options:
</t>
<t>Management target="RFC7828" format="default"/></li>
            </ul>
</dd>
            <dt>Additional Options:</dt>

            <dd>Management of TLS connections to optimize performance for clients using DNS
Stateful Operations <xref target="RFC8490"/>.
</t> target="RFC8490" format="default"/>.
	    </dd>
	    </dl>

          </section>
          <section anchor="doh" title="DoH">
<t>DNS numbered="true" toc="default">
            <name>DoH</name>
            <dl newline="true">

	      <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Known Threats:</dt>
	      <dd>
            <ul spacing="normal">
              <li>Known attacks on TLS TLS, such as those described in <xref
target="RFC7457"/>.</t>
<t>Traffic target="RFC7457" format="default"/>.</li>
              <li>Traffic analysis, for example: <xref
target="DNS-Privacy-not-so-private"/>.</t>
<t>Potential
	      target="DNS-Privacy-not-so-private" format="default"/> (focused
	      on DoH).</li>
              <li>Potential for client tracking via transport identifiers.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>
<list style="symbols">
<t>Clients identifiers.</li>
            </ul>
	      </dd>

              <dt>Mitigations:</dt>

	      <dd>
            <ul spacing="normal">
              <li>Clients must be able to forgo the use of HTTP Cookies cookies <xref
target="RFC6265"/>
	      target="RFC6265" format="default"/> and still
use the service.</t>
<t>Use service.</li>
              <li>Use of HTTP/2 padding and/or EDNS(0) padding padding, as described in Section 9 of
<xref target="RFC8484"/></t>
<t>Clients target="RFC8484" section="9" sectionFormat="of"/>.</li>
              <li>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> target="I-D.ietf-httpbis-bcp56bis" section="6.1" sectionFormat="of"/>.)</li>
            </ul>
	      </dd>
	    </dl>
          </section>
        </section>
        <section anchor="dnssec" title="DNSSEC">
<t>DNS numbered="true" toc="default">
          <name>DNSSEC</name>
	  <dl newline="true">
	    <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Users Threats:</dt>

            <dd>Users may be directed to bogus IP addresses which, that, depending on the
	    application, protocol protocol, and authentication method, might lead users to reveal
	    personal information to attackers. One example is a website that doesn't use
	    TLS or its whose TLS authentication can somehow be subverted.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>
<list style="symbols">
<t>All subverted.</dd>

          <dt>Mitigations:</dt>

          <dd>All DNS privacy services must offer a DNS privacy service that performs

	  Domain Name System Security Extensions (DNSSEC) validation. In addition
	  addition, they must be
	  able to provide the DNSSEC RRs Resource Records (RRs) to the client so that it can perform its own
validation.</t>
</list>
</t>
	  validation.</dd>
	  </dl>

          <t>The addition of encryption to DNS does not remove the need for DNSSEC
<xref target="RFC4033"/> - target="RFC4033" format="default"/>; they are independent and fully compatible
protocols,
each solving different problems. The use of one does not diminish the need nor
the usefulness of the other.
</t>
          <t>While the use of an authenticated and encrypted transport protects origin
	  authentication and data integrity between a client and a DNS privacy service service,
	  it provides no proof (for a non-validating nonvalidating client) that the data provided by the
	  DNS privacy service was actually DNSSEC authenticated. As with cleartext DNS DNS,
	  the user is still solely trusting the AD Authentic Data (AD) bit (if
	  present) set by the resolver.
</t>
          <t>It should also be noted that the use of an encrypted transport for DNS
	  actually solves many of the practical issues encountered by DNS validating clients e.g. -- e.g.,
	  interference by middleboxes with cleartext DNS payloads is completely avoided.
	  In this sense sense, a validating client that uses a DNS privacy service which that
	  supports DNSSEC has a far simpler task in terms of DNSSEC Roadblock roadblock avoidance
	  <xref
target="RFC8027"/>. target="RFC8027" format="default"/>.
</t>
        </section>
        <section anchor="availability" title="Availability">
<t>DNS numbered="true" toc="default">
          <name>Availability</name>
	  <dl newline="true">
	    <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>A failed Threats:</dt>

            <dd>
	      A failing DNS privacy service could force the user to switch
	      providers,
fallback fall back to cleartext cleartext, or accept no DNS service for
	      the outage.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>A duration of the outage.
	    </dd>

          <dt>Mitigations:</dt>

          <dd><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
	  (DoS) attacks, as experience has shown that unavailability of DNS resolving because
	  of attacks is a significant motivation for users to switch services. See, for
example
	  example, Section IV-C of <xref target="Passive-Observations-of-a-Large-DNS"/>.
</t>
	  target="Passive-Observations-of-a-Large-DNS" format="default"/>.</t>

          <t>Techniques such as those described in Section 10 of <xref
target="RFC7766"/> target="RFC7766" section="10" sectionFormat="of"/> can be of use to operators to defend against such attacks.
	  </t>
	  </dd>
	  </dl>
        </section>
        <section anchor="service-options" title="Service options">
<t>DNS numbered="true" toc="default">
          <name>Service Options</name>
	  <dl newline="true">

          <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Unfairly Threats:</dt>

          <dd>Unfairly disadvantaging users of the privacy service with respect to the
	  services available. This could force the user to switch providers, fallback
	  fall back to
cleartext
	  cleartext, or accept no DNS service for the outage.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>A duration of the outage.</dd>

          <dt>Mitigations:</dt>

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

        </section>
        <section anchor="impact-of-encryption-on-monitoring-by-dns-privacy-service-operators"
    title="Impact numbered="true" toc="default">
          <name>Impact of Encryption on Monitoring by DNS Privacy Service
	   Operators">
<t>DNS Operators</name>
	  <dl newline="true">

          <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Increased Threats:</dt>

          <dd>Increased use of encryption can impact a DNS privacy service operator operator's ability
	  to monitor traffic and therefore manage their DNS servers <xref
target="RFC8404"/>.</t>
</list>
</t>
	  target="RFC8404" format="default"/>.</dd>
          </dl>

          <t>Many monitoring solutions for DNS traffic rely on the plain text plaintext nature of
	  this
	  traffic and work by intercepting traffic on the wire, either using a separate
	  view on the connection between clients and the resolver, or as a separate
	  process on the resolver system that inspects network traffic. Such solutions
	  will no longer function when traffic between clients and resolvers is
	  encrypted.
	  Many DNS privacy service operators still have need to inspect DNS traffic, 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 e.g., using, for
	  example, <xref
target="dnstap"/>. target="dnstap" format="default"/>.
	  </t>
<t>Optimization:
</t>
<t>When
	  <dl newline="true">

          <dt>Optimization:</dt>

          <dd>When implementing alternative means for traffic monitoring, operators of a
DNS
privacy service should consider using privacy conscious privacy-conscious means to do so (see
section so. See
<xref target="data-at-rest-on-the-server"/> target="data-at-rest-on-the-server" format="default"/> for more details on data
handling and also the discussion on the use of Bloom Filters in <xref
target="ip-address-techniques"/>.
</t>
target="ip-address-techniques" format="default"/>.
	  </dd>
	  </dl>
        </section>
        <section anchor="limitations-of-fronting-a-dns-privacy-service-with-a-pure-tls-proxy"
    title="Limitations numbered="true" toc="default">
          <name>Limitations of fronting Fronting a DNS privacy service Privacy Service with a pure Pure TLS
	   proxy">
<t>DNS Proxy</name>
	  <dl newline="true">

          <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Limited Threats:</dt>
<dd>
          <ul spacing="normal">
            <li>Limited ability to manage or monitor incoming connections using DNS
specific
techniques.</t>
<t>Misconfiguration DNS-specific
	    techniques.</li>
            <li>Misconfiguration (e.g., of the target server target-server address in the
	    proxy configuration) could lead to data leakage if the proxy to target server
	    proxy-to-target-server path
	    is not encrypted.</t>
</list>
</t>
<t>Optimization:
</t>
<t>Some encrypted.</li>
          </ul>
</dd>
          <dt>Optimization:</dt>

          <dd><t>Some operators may choose to implement DoT using a TLS proxy (e.g. (e.g.,
<xref target="nginx"/>, target="nginx" format="default"/>, <xref target="haproxy"/>, target="haproxy" format="default"/>, or
<xref target="stunnel"/>) target="stunnel" format="default"/>) in front of
a DNS nameserver because of proven robustness and capacity when handling large
numbers of client connections, load balancing capabilities load-balancing capabilities, and good tooling.
Currently, however, because such proxies typically have no specific handling
of DNS as a protocol over TLS or DTLS DTLS, using them can restrict traffic management
at the proxy layer and at the DNS server. For example, all traffic received by a
nameserver behind such a proxy will appear to originate from the proxy proxy, and DNS
techniques such as ACLs, RRL, Access Control Lists (ACLs), Response Rate Limiting (RRL),
or DNS64 <xref target="RFC6147"/> will be hard or impossible to implement
in
the nameserver.
</t>
          <t>Operators may choose to use a DNS aware proxy DNS-aware proxy, such as
<xref target="dnsdist"/> which target="dnsdist" format="default"/>, that offers custom options (similar to that those
proposed in <xref target="I-D.bellis-dnsop-xpf"/>) target="I-D.bellis-dnsop-xpf" format="default"/>) to add source information
to packets
to address this shortcoming. It should be noted that such options potentially
significantly increase the leaked information in the event of a
misconfiguration.
	  </t>
	</dd>
      </dl>
        </section>
      </section>
      <section anchor="data-at-rest-on-the-server" title="Data numbered="true" toc="default">
        <name>Data at rest Rest on the
						    server"> Server</name>
        <section anchor="data-handling" title="Data handling">
<t><xref target="RFC6973"/> Threats:
</t>
<t>
<list style="symbols">
<t>Surveillance.</t>
<t>Stored data compromise.</t>
<t>Correlation.</t>
<t>Identification.</t>
<t>Secondary use.</t>
<t>Disclosure.</t>
</list>
</t>
<t>Other Threats
</t>
<t>
<list style="symbols">
<t>Contravention numbered="true" toc="default">
          <name>Data Handling</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>Other Threats</dt>
<dd>
          <ul spacing="normal">
            <li>Contravention of legal requirements not to process user data.</t>
</list>
</t>
<t>Mitigations:
</t>
<t>The data.</li>
          </ul>
</dd>
          <dt>Mitigations:</dt>

          <dd><t>The following are recommendations relating to common activities for DNS
	  service
operators and operators; in all cases cases, data retention should be minimized or completely
	  avoided if possible for DNS privacy services. If data is retained retained, it should be
	  encrypted and either aggregated, pseudonymized, or anonymized whenever
	  possible.
	  In general general, the principle of data minimization described in <xref
target="RFC6973"/>
	  target="RFC6973" format="default"/> should be
applied.
</t>
<t>
<list style="symbols">
<t>Transient applied.</t>

          <ul spacing="normal">
            <li>Transient data (e.g., that is data used for real time real-time monitoring and threat
analysis
	    analysis, which might be held only in memory) should be retained for the shortest
	    possible period deemed operationally feasible.</t>
<t>The feasible.</li>
            <li>The retention period of DNS traffic logs should be only those as
	    long as is required to sustain operation of the service and, and meet
	    regulatory requirements, to the extent that such exists, meet
regulatory requirements.</t>
<t>DNS they exist.</li>
            <li>DNS privacy services should not track users except for the particular
purpose
of detecting and remedying technically malicious (e.g., DoS) or anomalous use
of the service.</t>
<t>Data service.</li>
            <li>Data access should be minimized to only those personnel who require access
to
perform operational duties. It should also be limited to anonymized or
pseudonymized data where operationally feasible, with access to full logs (if
any are held) only permitted when necessary.</t>
</list>
</t>
<t>Optimizations:
</t>
<t>
<list style="symbols">
<t>Consider necessary.</li>
          </ul>
	  </dd>

          <dt>Optimizations:</dt>
<dd>
          <ul spacing="normal">
            <li>Consider use of full disk full-disk encryption for logs and data capture storage.</t>
</list>
</t> data-capture storage.</li>
          </ul>
</dd>
	  </dl>
        </section>
        <section anchor="data-minimization-of-network-traffic" title="Data
  minimization numbered="true" toc="default">
          <name>Data Minimization of network traffic"> Network Traffic</name>
          <t>Data minimization refers to collecting, using, disclosing, and storing the
minimal data necessary to perform a task, and this can be achieved by
removing or obfuscating privacy-sensitive information in network traffic logs.
This is typically personal data, data or data that can be used to link a record to
an individual, but it may also include revealing other confidential information, information -- for
example
example, on the structure of an internal corporate network.
</t>
          <t>The problem of effectively ensuring that DNS traffic logs contain no or
minimal
privacy-sensitive information is not one that currently has a generally agreed
solution or any standards to inform this discussion. This section presents an
overview of current techniques to simply provide reference on the current
status of this work.
</t>
          <t>Research into data minimization techniques (and particularly IP address
pseudonymization/anonymization) was sparked in the late 1990s/early 1990s / early 2000s,
partly driven by the desire to share significant corpuses of traffic captures
for research purposes. Several techniques reflecting different requirements in
this area and different performance/resource tradeoffs trade-offs emerged over the course
of the decade. Developments over the last decade have been both a blessing and
a
curse; the large increase in size between an IPv4 and an IPv6 address, for
example, renders some techniques impractical, but also makes available a much
larger amount of input entropy, the better to resist brute force brute-force
re-identification attacks that have grown in practicality over the period.
</t>
          <t>Techniques employed may be broadly categorized as either anonymization or
pseudonymization. The following discussion uses the definitions from <xref
target="RFC6973"/>
Section 3,
target="RFC6973" section="3" sectionFormat="comma"/>, with additional
observations from <xref
target="van-Dijkhuizen-et-al."/> target="van-Dijkhuizen-et-al" format="default"/>.
          </t>
<t>
<list style="symbols">
<t>Anonymization.
          <ul spacing="normal">
            <li>Anonymization. To enable anonymity of an individual, there must exist a set
of
individuals that appear to have the same attribute(s) as the individual. To
the attacker or the observer, these individuals must appear indistinguishable
from each other.</t>
<t>Pseudonymization. other.</li>
            <li>Pseudonymization. The true identity is deterministically replaced with an
alternate identity (a pseudonym). When the pseudonymization schema is known,
the process can be reversed, so the original identity becomes known again.</t>
</list>
</t> again.</li>
          </ul>
          <t>In practice practice, there is a fine line between the two; for example, how
	  it is difficult to categorize a deterministic algorithm for data
	  minimization of IP addresses that produces a group of pseudonyms for
	  a single given address.
</t>
        </section>
        <section anchor="ip-address-pseudonymization-and-anonymization-methods"
	 title="IP address pseudonymization numbered="true" toc="default">
          <name>IP Address Pseudonymization and anonymization methods"> Anonymization Methods</name>
          <t>A major privacy risk in DNS is connecting DNS queries to an individual individual, and
	  the major vector for this in DNS traffic is the client IP address.
</t>
          <t>There is active discussion in the space of effective pseudonymization of IP
	  addresses in DNS traffic logs, however logs; however, there seems to be no single solution
	  that is widely recognized as suitable for all or most use cases. There are also as
	  yet no standards for this that are unencumbered by patents.
</t>
          <t><xref target="ip-address-techniques"/> target="ip-address-techniques" format="default"/> provides a more detailed survey of
various techniques
employed or under development in 2019. 2020.
</t>
        </section>
        <section anchor="pseudonymization-anonymization-or-discarding-of-other-correlation-data"
    title="Pseudonymization, anonymization, or discarding of other correlation
	   data">
<t>DNS numbered="true" toc="default">
          <name>Pseudonymization, Anonymization, or Discarding of Other Correlation Data</name>
          <dl newline="true">
	      <dt>DNS Privacy Threats:
</t>
<t>
<list style="symbols">
<t>Fingerprinting Threats:</dt>
<dd>
          <ul spacing="normal">
            <li>Fingerprinting of the client OS via various means means, including: IP
	    TTL/Hoplimit,
	    TCP parameters (e.g., window size, ECN Explicit Congestion
	    Notification (ECN) support, SACK), OS specific selective acknowledgment (SACK)),
	    OS-specific DNS query
	    patterns (e.g., for network connectivity, captive portal detection, or OS
specific updates).</t>
<t>Fingerprinting
	    OS-specific updates).</li>
            <li>Fingerprinting of the client application or TLS library by, e.g.,
	    for example, HTTP headers (e.g., User-Agent, Accept,
	    Accept-Encoding), TLS version/Cipher suite version/Cipher-suite
	    combinations, or other connection parameters.</t>
<t>Correlation parameters.</li>
            <li>Correlation of queries on multiple TCP sessions originating from the same
	    IP
address.</t>
<t>Correlating address.</li>
            <li>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> session-resumption mechanisms.</li>

            <li>Resolvers <em>might</em> receive client identifiers, identifiers -- e.g., MAC
	    Media Access Control (MAC) addresses in EDNS(0)
options - some Customer-premises
	    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 target="MAC-address-EDNS" format="default"/>.</li>
          </ul>
</dd>
          <dt>Mitigations:</dt>
<dd>
          <ul spacing="normal">
            <li>Data minimization or discarding of such correlation data.</t>
</list>
</t> data.</li>
          </ul>
</dd>
</dl>
        </section>

        <section anchor="cache-snooping" title="Cache snooping">
<t><xref target="RFC6973"/> Threats:
</t>
<t>
<list style="symbols">
<t>Surveillance:
<list style="symbols">
<t>Profiling numbered="true" toc="default">
	  <name>Cache Snooping</name>

<dl newline="true">

  <dt>Threats described in <xref target="RFC6973" format="default"/>:</dt>
  <dd>

	    <dl newline="true">

	      <dt>Surveillance:</dt>
              <dd>Profiling of client queries by malicious third parties.</t>
</list></t>
</list>
</t>
<t>Mitigations:
</t>
<t>
<list style="symbols">
<t>See parties.</dd>
	    </dl>
  </dd>

          <dt>Mitigations:</dt>

            <dd>See <xref target="ISC-Knowledge-database-on-cache-snooping"/> target="ISC-Knowledge-database-on-cache-snooping" format="default"/> for an
example discussion on
defending against cache snooping. Options proposed include limiting access to
a server and limiting non-recursive queries.</t>
</list>
</t> nonrecursive queries.</dd>
          </dl>

        </section>
      </section>
      <section anchor="data-sent-onwards-from-the-server" title="Data sent onwards numbered="true" toc="default">
        <name>Data Sent Onwards from the server"> Server</name>
        <t>In this section section, we consider both data sent on the wire in upstream queries
and
data shared with third parties.
</t>
        <section anchor="protocol-recommendations-1" title="Protocol recommendations">
<t><xref target="RFC6973"/> Threats:
</t>
<t>
<list style="symbols">
<t>Surveillance:
<list style="symbols">
<t>Transmission numbered="true" toc="default">
          <name>Protocol Recommendations</name>
	  <dl newline="true">

          <dt>Threats described in <xref target="RFC6973" format="default"/>:</dt>
	  <dd>
	    <dl newline="true">

              <dt>Surveillance:</dt>

              <dd>Transmission of identifying data upstream.</t>
</list></t>
</list>
</t>
<t>Mitigations:
</t>
<t>As specified in <xref target="RFC8310"/> for DoT but applicable to any DNS
Privacy
services the upstream.</dd>
	    </dl>
	    </dd>
          <dt>Mitigations:</dt>

          <dd><t>The server should:
</t>
<t>
<list style="symbols">
<t>Implement should:</t>

          <ul spacing="normal">

            <li>implement QNAME minimization <xref target="RFC7816"/>.</t>
<t>Honor target="RFC7816"
	    format="default"/>.</li>
            <li>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).</t>
</list>
</t>
<t>Optimizations:
</t>
<t>
<list style="symbols">
<t>As target="RFC7871" section="7.1.2"
sectionFormat="comma"/>).  This is as specified in <xref target="RFC8310"/> for DoT but
	    applicable to any DNS
        privacy service.</li>
          </ul>
	  </dd>

          <dt>Optimizations:</dt>

              <dd><t>As per Section 2 of <xref target="RFC7871"/> target="RFC7871" section="2"
	      sectionFormat="of"/>, the server should either:
<list style="symbols">
<t>not either:</t>
              <ul spacing="normal">
                <li>not use the ECS option in upstream queries at all, or</t>
<t>offer or</li>
                <li>offer alternative services, one that sends ECS and one that does not.</t>
</list></t>
</list>
</t> not.</li>
              </ul>
            </dd>

</dl>

          <t>If operators do offer a service that sends the ECS options upstream upstream, they
should
use the shortest prefix that is operationally feasible and ideally
use a policy of allowlisting upstream servers to which to send ECS to in order to
reduce data leakage. Operators should make clear in any policy statement what
prefix length they actually send and the specific policy used.
</t>
          <t>Allowlisting has the benefit that not only does the operator know which
	  upstream
	  servers can use ECS ECS, but also allows the operator to can decide which upstream
	  servers apply privacy policies that the operator is happy with. However However, some
	  operators consider allowlisting to incur significant operational overhead
	  compared to dynamic detection of ECS support on authoritative servers.
</t>
          <t>Additional options:
</t>
<t>
<list style="symbols">
<t>Aggressive
          <ul spacing="normal">
            <li>"Aggressive Use of DNSSEC-Validated Cache Cache" <xref target="RFC8198"/>
	    target="RFC8198" format="default"/> and <xref
target="RFC8020"/>
(NXDOMAIN: "NXDOMAIN: There Really Is
	    Nothing Underneath) Underneath" <xref target="RFC8020"
	    format="default"/> to reduce the number of queries
to authoritative servers to increase privacy.</t>
<t>Run privacy.</li>
            <li>Run a local copy of the root zone on loopback <xref target="RFC8806"/> target="RFC8806"
            format="default"/> to avoid making queries to the root servers
            that might leak information.</t>
</list>
</t> information.</li>
          </ul>
        </section>
        <section anchor="client-query-obfuscation" title="Client query obfuscation"> numbered="true" toc="default">
          <name>Client Query Obfuscation</name>
          <t>Additional options:
</t>
          <t>Since queries from recursive resolvers to authoritative servers are
performed
using cleartext (at the time of writing), resolver services need to consider
the
extent to which they may be directly leaking information about their client
community via these upstream queries and what they can do to mitigate this
further. Note, that Note that, even when all the relevant techniques described above are
employed
employed, there may still be attacks possible, e.g. possible -- e.g.,
<xref target="Pitfalls-of-DNS-Encryption"/>. target="Pitfalls-of-DNS-Encryption" format="default"/>. For example, a resolver with a
very small
community of users risks exposing data in this way and ought to obfuscate this
traffic by mixing it with 'generated' "generated" traffic to make client characterization
harder. The resolver could also employ aggressive pre-fetch prefetch techniques as a
further measure to counter traffic analysis.
</t>
          <t>At the time of writing writing, there are no standardized or widely recognized
techniques
to perform such obfuscation or bulk pre-fetches. prefetches.
</t>
          <t>Another technique that particularly small operators may consider is
forwarding
local traffic to a larger resolver (with a privacy policy that aligns with
their
own practices) over an encrypted protocol protocol, so that the upstream queries are
obfuscated among those of the large resolver.
</t>
        </section>
        <section anchor="data-sharing" title="Data sharing">
<t><xref target="RFC6973"/> Threats:
</t>
<t>
<list style="symbols">
<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 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:
</t>
<t>
<list style="symbols">
<t>Contravention Threats:</dt>

          <dd>Contravention of legal requirements not to process user data.</t>
</list>
</t>
<t>Mitigations:
</t> data.</dd>

          <dt>Mitigations:</dt>

         <dd> <t>Operators should not share identifiable data with third-parties. third parties.
</t>
          <t>If operators choose to share identifiable data with third-parties third parties in
	  specific
circumstance circumstances, they should publish the terms under which data is shared.
</t>
          <t>Operators should consider including specific guidelines for the collection
of
aggregated and/or anonymized data for research purposes, within or outside of
their own organization. This can benefit not only the operator (through
inclusion in novel research) but also the wider Internet community. See the
policy published by SURFnet <xref target="SURFnet-policy"/> target="SURFnet-policy" format="default"/> on data sharing
for research as
an example.
	  </t>
	 </dd>
	  </dl>
        </section>
      </section>
    </section>
    <section anchor="recursive-operator-privacy-statement-rps" title="Recursive
  operator numbered="true" toc="default">
      <name>Recursive Operator Privacy Statement (RPS)"> (RPS)</name>
      <t>To be compliant with this Best Common Practices Current Practice document, a DNS recursive
operator SHOULD <bcp14>SHOULD</bcp14> publish a Recursive operator Privacy Statement (RPS). Adopting
the
outline, and including the headings in the order provided, is a benefit to
persons comparing RPSs from multiple operators.
</t>
      <t><xref target="current-policy-and-privacy-statements"/> target="current-policy-and-privacy-statements" format="default"/> provides a
comparison of some existing
policy and privacy statements.
</t>
      <section anchor="outline-of-an-rps" title="Outline numbered="true" toc="default">
        <name>Outline of an RPS"> RPS</name>
        <t>The contents of Sections <xref target="policy"/> target="policy" format="counter"/> and <xref target="practice"/>
	target="practice" format="counter"/> are
non-normative, other than the
order of the headings. Material under each topic is present to assist the
operator developing their own RPS and: RPS. This material:
</t>
<t>
<list style="symbols">
<t>Relates <spanx style="emph">only</spanx>
        <ul spacing="normal">
          <li>Relates <em>only</em> to matters around to the technical
operation of DNS privacy services, and not on any no other matters.</t>
<t>Does matters.</li>
          <li>Does not attempt to offer an exhaustive list for the contents of an
RPS.</t>
<t>Is
RPS.</li>
          <li>Is not intended to form the basis of any legal/compliance
documentation.</t>
</list>
</t>
documentation.</li>
        </ul>
        <t><xref target="example-rps"/> target="example-rps" format="default"/> provides an example (also non-normative) of an
RPS
statement for a specific operator scenario.
</t>
        <section anchor="policy" title="Policy">
<t>
<list style="numbers">
<t>Treatment numbered="true" toc="default">
          <name>Policy</name>
          <ol spacing="normal" type="1">
            <li>Treatment of IP addresses. Make an explicit statement that IP addresses are
treated as personal data.</t> data.</li>
            <li>
              <t>Data collection and sharing. Specify clearly what data (including IP
	      addresses) is:
<list style="symbols">
<t>Collected
</t>
              <ul spacing="normal">
                <li>Collected and retained by the operator, and for what period it is
retained.</t>
<t>Shared
retained.</li>
                <li>Shared with partners.</t> partners.</li>
                <li>
                  <t>Shared, sold, or rented to third-parties.

<vspace/></t>
</list>
and in third parties.
		  </t>
                  <t/>
                </li>
              </ul>
              <t>
		In each case case, specify whether it data is aggregated, pseudonymized, or anonymized and
		the conditions of data transfer. Where possible provide details of the
	      techniques used for the above data minimizations.</t>
<t>Exceptions.
            </li>
            <li>Exceptions. Specify any exceptions to the above, above -- for example, technically
malicious or anomalous behavior.</t>
<t>Associated behavior.</li>
            <li>Associated entities. Declare and explicitly enumerate any partners,
third-party affiliations, or sources of funding.</t>
<t>Correlation. funding.</li>
            <li>Correlation. Whether user DNS data is correlated or combined with any other
personal information held by the operator.</t> operator.</li>
            <li>
              <t>Result filtering. This section should explain whether the operator filters,
edits
edits, or alters in any way the replies that it receives from the authoritative
servers for each DNS zone, zone before forwarding them to the clients. For each
category listed below, the operator should also specify how the filtering
lists
are created and managed, whether it employs any third-party sources for such
lists, and which ones.
<list style="symbols">
<t>Specify
</t>
              <ul spacing="normal">
                <li>Specify if any replies are being filtered out or altered for network network- and
computer security
		computer-security reasons (e.g., preventing connections to
		malware-spreading websites or botnet control servers).</t>
<t>Specify 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
and other public authorities.</t>
<t>Specify authorities.</li>
                <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
reducing potential legal risks.</t>
<t>Specify risks.</li>
                <li>Specify if any replies are being filtered out or altered for any other
reason, including commercial ones.</t>
</list></t>
</list>
</t> ones.</li>
              </ul>
            </li>
          </ol>
        </section>
        <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> numbered="true" toc="default">
          <name>Practice</name>

<t>Communicate the current operational practices of the service.
</t>
<t>
<list style="numbers">
<t>Deviations.

<ol spacing="normal">
  <li>Deviations. Specify any temporary or permanent deviations from the policy
  for operational reasons.</t>
<t>Client facing reasons.</li>
            <li>
              <t>Client-facing capabilities. With reference to each subsection of
	      <xref target="on-the-wire-between-client-and-server"/> target="on-the-wire-between-client-and-server" format="default"/>, provide specific
	      details of which
	      capabilities (transport, DNSSEC, padding, etc.) are provided on
	      which client
facing client-facing addresses/port combination or DoH URI
	      template. For
	      <xref target="authentication-of-dns-privacy-services"/>, target="authentication-of-dns-privacy-services"
		    format="default"/>, clearly specify which specific
	      authentication mechanisms are supported for each endpoint that offers DoT:
<list style="numbers">
<t>The
</t>
              <ol spacing="normal" type="a">
                <li>The authentication domain name to be used (if any).</t> any).</li>
                <li>
                  <t>The SPKI pin sets to be used (if any) and policy for rolling keys.

<vspace/></t>
</list></t>
<t>Upstream
		  </t>
                  <t/>
                </li>
              </ol>
            </li>
            <li>Upstream capabilities. With reference to section
	    <xref target="data-sent-onwards-from-the-server"/> target="data-sent-onwards-from-the-server"
		  format="default"/>, provide specific details of
	    which capabilities are provided upstream for data sent to authoritative servers.</t>
<t>Support. servers.</li>
            <li>Support. Provide contact/support information for the service.</t>
<t>Data service.</li>
            <li>Data Processing. This section can optionally communicate links to to, and the
high level
	    high-level contents of of, any separate statements the operator has published
which
	    that cover applicable data processing data-processing legislation or agreements with regard to the
	    location(s) of service provision.</t>
</list>
</t> provision.</li>
          </ol>
        </section>
      </section>
      <section anchor="enforcementaccountability"
	 title="Enforcement/accountability"> numbered="true" toc="default">
        <name>Enforcement/Accountability</name>
        <t>Transparency reports may help with building user trust that operators
adhere to
their policies and practices.
</t>
<t>Independent
        <t>Where possible, independent monitoring or analysis could be performed where possible of:
</t>
<t>
<list style="symbols">
<t>ECS,
        <ul spacing="normal">
          <li>ECS, QNAME minimization, EDNS(0) padding, etc.</t>
<t>Filtering.</t>
<t>Uptime.</t>
</list>
</t> etc.</li>
          <li>Filtering.</li>
          <li>Uptime.</li>
        </ul>
        <t>This is by analogy with several TLS or website analysis website-analysis tools that are
currently available -- e.g., <xref target="SSL-Labs"/> target="SSL-Labs" format="default"/> or
<xref target="Internet.nl"/>. target="Internet.nl" format="default"/>.
</t>
<t>Additionally
        <t>Additionally, operators could choose to engage the services of a third party third-party
auditor to verify their compliance with their published RPS.
</t>
      </section>
    </section>
    <section anchor="iana-considerations" title="IANA considerations">
<t>None
</t> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="security-considerations" title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security considerations for DNS over TCP are given in <xref
target="RFC7766"/>, target="RFC7766" format="default"/>, many of which
are generally applicable to session based session-based DNS. Guidance on operational
requirements for DNS over TCP are also available in
[I-D.dnsop-dns-tcp-requirements]. <xref
target="I-D.ietf-dnsop-dns-tcp-requirements"/>. Security considerations for
DoT are given in
[RFC7858] <xref target="RFC7858" /> and <xref target="RFC8310"/>, target="RFC8310"
format="default"/>, and those for DoH in [RFC8484]. <xref target="RFC8484"/>.
</t>
      <t>Security considerations for DNSSEC are given in <xref target="RFC4033"/>, target="RFC4033" format="default"/>,
<xref target="RFC4034"/> target="RFC4034" format="default"/>, and <xref target="RFC4035"/>.
</t>
</section>

<section anchor="acknowledgements" title="Acknowledgements">
<t>Many thanks to Amelia Andersdotter for a very thorough review of the first
draft
of this document and Stephen Farrell for a thorough review at WGLC and for
suggesting the inclusion of an example RPS. Thanks to John Todd for
discussions on this topic, and to Stephane Bortzmeyer, Puneet Sood and
Vittorio
Bertola for review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman,
Dan York, Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to
Loganaden Velvindron for useful updates to the text.
</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">
<t>The below individuals contributed significantly to the document:
</t>
<t>John Dickinson
<vspace/>
Sinodun Internet Technologies
<vspace/>
Magdalen Centre
<vspace/>
Oxford Science Park
<vspace/>
Oxford OX4 4GA
<vspace/>
United Kingdom
</t>
<t>Jim Hague
<vspace/>
Sinodun Internet Technologies
<vspace/>
Magdalen Centre
<vspace/>
Oxford Science Park
<vspace/>
Oxford OX4 4GA
<vspace/>
United Kingdom
</t>
</section>

<section anchor="changelog" title="Changelog">
<t>draft-ietf-dprive-bcp-op-13
</t>
<t>
<list style="symbols">
<t>Minor edits</t>
</list>
</t>
<t>draft-ietf-dprive-bcp-op-12
</t>
<t>
<list style="symbols">
<t>Change DROP to RPS throughout</t>
</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> target="RFC4035" format="default"/>.
</t>
    </section>
  </middle>
  <back>
<references title="Normative References">
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7457.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7816.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7828.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7830.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8467.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"?>

<displayreference target="I-D.bellis-dnsop-xpf" to="DNS-XPF"/>
<displayreference target="I-D.ietf-dnsop-dns-tcp-requirements" to="DNS-OVER-TCP"/>
<displayreference target="I-D.ietf-httpbis-bcp56bis" to="BUILD-W-HTTP"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7457.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7816.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7828.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7830.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8467.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/>
      </references>
<references title="Informative References">
      <references>
        <name>Informative References</name>

        <reference anchor='Bloom-filter'
           target='http://dl.ifip.org/db/conf/im/im2019/189282.pdf'> 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'> initials="R." surname="van Rijswijk-Deij"> </author>
            <author initials='G.' surname='Rijnders'> initials="G." surname="Rijnders"> </author>
            <author initials='M.' surname='Bomhoff'> initials="M." surname="Bomhoff"> </author>
            <author initials='L.' surname='Allodi'> initials="L." surname="Allodi"> </author>
            <date year='2019'/> year="2019"/>
          </front>
	  <refcontent>IFIP/IEEE International Symposium on Integrated Network
	  Management (IM2019)</refcontent>
        </reference>

        <reference anchor='Brenker-and-Arnes'
           target='https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda164fb2138a44.pdf'> anchor="Brekne-and-Arnes"
		   target="https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda164fb2138a44.pdf">
          <front>
        <title>CIRCUMVENTING IP-ADDRESS PSEUDONYMIZATION</title>
            <title>Circumventing IP-address pseudonymization</title>
            <author initials='T.' surname='Brekne'> initials="T." surname="Brekne"> </author>
            <author initials='A.' surname='Arnes'> initials="A." surname="Årnes"> </author>
            <date year='2005'/> year="2005"/>
          </front>
	  <seriesInfo name="Communications and" value="Computer Networks" />
        </reference>

        <reference anchor='Crypto-PAn'
	   target='https://github.com/CESNET/ipfixcol/tree/master/base/src/intermediate/anonymization/Crypto-PAn'> anchor="Crypto-PAn"
		   target="https://github.com/CESNET/ipfixcol/tree/master/base/src/intermediate/anonymization/Crypto-PAn">
          <front>
            <title>Crypto-PAn</title>
            <author>
              <organization>CESNET</organization>
            </author>
            <date year='2015'/> year="2015" month="March"/>
          </front>
	  <seriesInfo name="commit" value="636b237"/>
        </reference>

        <reference anchor='DNS-Privacy-not-so-private'
 target='https://petsymposium.org/2018/files/hotpets/4-siby.pdf'> 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>
            <author initials='S.' surname='Silby'> initials="S." surname="Silby"> </author>
            <author initials='M.' surname='Juarez'> initials="M." surname="Juarez"> </author>
            <author initials='N.' surname='Vallina-Rodriguez'> initials="N." surname="Vallina-Rodriguez"> </author>
            <author initials='C.' surname='Troncosol'> initials="C." surname="Troncoso"> </author>
            <date year='2019'/> year="2018"/>
          </front>
	  <seriesInfo name="Privacy Enhancing Technologies" value="Symposium"/>
        </reference>

        <reference anchor='DoH-resolver-policy'
   target='https://wiki.mozilla.org/Security/DOH-resolver-policy'> anchor="DoH-resolver-policy" target="https://wiki.mozilla.org/Security/DOH-resolver-policy">
          <front>
            <title>Security/DOH-resolver-policy</title>
            <author>
              <organization>Mozilla</organization>
            </author>
            <date year='2019'/> year="2019"/>
          </front>
        </reference>

        <reference anchor='Geolocation-Impact-Assessement'
          target='https://support.google.com/analytics/answer/2763052?hl=en'> anchor="Geolocation-Impact-Assessment" target="https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-geo-impact-test/">
          <front>
            <title>Anonymize IP Geolocation Accuracy Impact Assessment</title>
            <author>
              <organization>Conversion Works</organization>
            </author>
            <date year='2017'/> day="19" month="May" year="2017"/>
          </front>
        </reference>

        <reference anchor='Harvan'
           target='http://mharvan.net/talks/noms-ip_anon.pdf'> anchor="Harvan" target="http://mharvan.net/talks/noms-ip_anon.pdf">
          <front>
            <title>Prefix- and Lexicographical-order-preserving IP Address
	Anonymization</title>
            <author initials='M.' surname='Harvan'> initials="M." surname="Harvan"> </author>
            <date year='2006'/> year="2006"/>
          </front>
	  <refcontent>IEEE/IFIP Network Operations and Management
	  Symposium</refcontent>
	  <seriesInfo name="DOI" value="10.1109/NOMS.2006.1687580"/>
        </reference>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.bellis-dnsop-xpf.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-dns-tcp-requirements.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-bcp56bis.xml"?>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.bellis-dnsop-xpf.xml"/>

<!-- [I-D.ietf-dnsop-dns-tcp-requirements] IESG state I-D Exists -->

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dnsop-dns-tcp-requirements.xml"/>

<!-- [I-D.ietf-httpbis-bcp56bis] IESG state Expired -->

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-httpbis-bcp56bis.xml"/>

        <reference anchor='IP-Anonymization-in-Analytics'
	   target='https://support.google.com/analytics/answer/2763052?hl=en'> anchor="IP-Anonymization-in-Analytics" target="https://support.google.com/analytics/answer/2763052?hl=en">
          <front>
            <title>IP Anonymization in Analytics</title>
            <author>
              <organization>Google</organization>
            </author>
            <date year='2019'/> year="2019"/>
          </front>
        </reference>

        <reference anchor='ISC-Knowledge-database-on-cache-snooping'
   target='https://kb.isc.org/docs/aa-00482'> anchor="ISC-Knowledge-database-on-cache-snooping" target="https://kb.isc.org/docs/aa-00482">
          <front>
            <title>DNS Cache snooping - should I be concerned?</title>
        <author>
            <organization>ISC Knowledge Database</organization>
        </author>
            <author initials="S" surname="Goldlust" />
            <author initials="C" surname="Almond" />
            <date year='2018'/> year="2018" month="October" day="15"/>
          </front>
	<seriesInfo name="ISC" value="Knowledge Database"/>
        </reference>

        <reference anchor='Internet.nl' target='https://internet.nl'> anchor="Internet.nl" target="https://internet.nl">
          <front>
            <title>Internet.nl Is Your Internet Up To Date?</title>
            <author>
              <organization>Internet.nl</organization>
            </author>
            <date year='2019'/> year="2019"/>
          </front>
        </reference>

        <reference anchor='MAC-address-EDNS'
	   target='https://lists.dns-oarc.net/pipermail/dns-operations/2016-January/014143.html'> anchor="DNSCrypt" target="https://www.dnscrypt.org">
          <front>
            <title>DNSCrypt - Official Project Home Page</title>
            <author/>
            <date/>
          </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
	IDs</title>
        <author>
           <organization>DNS-OARC mailing list</organization>
        </author> filtering</title>
            <author initials="B" surname="Hubert"/>
            <date year='2016'/> 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'> 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>
            <author initials='W. B.' surname='de Vries'> initials="W. B." surname="de Vries"> </author>
            <author initials='R.' surname='van Rijswijk-Deij'> initials="R." surname="van Rijswijk-Deij"> </author>
            <author initials='P.' surname='de Boer'> initials="P-T" surname="de Boer"> </author>
            <author initials='A.' surname='Pras'> initials="A." surname="Pras"> </author>
            <date year='2018'/> year="2018"/>
          </front>
	    <seriesInfo name="DOI" value="10.23919/TMA.2018.8506536"/>
        </reference>

        <reference anchor='Pitfalls-of-DNS-Encryption'
 target='https://dl.acm.org/citation.cfm?id=2665959'> anchor="Pitfalls-of-DNS-Encryption" target="https://dl.acm.org/citation.cfm?id=2665959">
          <front>
            <title>Pretty Bad Privacy: Pitfalls of DNS Encryption</title>
            <author initials='H.' surname='Shulman' fullname='Haya Shulman'> initials="H." surname="Shulman" fullname="Haya Shulman">
              <organization>Fachbereich Informatik, Technische Universität
	    Darmstadt</organization>
            </author>
            <date year='2014'/> year="2014" month="November"/>
          </front>
	  <seriesInfo name="DOI" value="10.1145/2665943.2665959"/>
	  <refcontent>Proceedings of the 13th Workshop on Privacy in the
	    Electronic Society, pp. 191-200</refcontent>
        </reference>

        <reference anchor='PowerDNS-dnswasher'
	   target='https://github.com/PowerDNS/pdns/blob/master/pdns/dnswasher.cc'> anchor="PowerDNS-dnswasher" target="https://github.com/PowerDNS/pdns/blob/master/pdns/dnswasher.cc">
          <front>
            <title>dnswasher</title>
            <author>
              <organization>PowerDNS</organization>
            </author>
            <date year='2019'/> day="24" month="April" year="2020"/>
          </front>
	  <seriesInfo name="commit" value="050e687" />
        </reference>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6235.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7626.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8027.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8404.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"?>
<?rfc
  include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8618.xml"?>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6235.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7626.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8027.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8404.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8618.xml"/>

        <reference anchor='Ramaswamy-and-Wolf'
           target='http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf'> anchor="Ramaswamy-and-Wolf" target="http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf">
          <front>
            <title>High-Speed Prefix-Preserving IP Address Anonymization for
	Passive Measurement Systems</title>
            <author initials='R.' surname='Ramaswamy'> initials="R." surname="Ramaswamy"> </author>
            <author initials='T.' surname='Wolf'> initials="T." surname="Wolf"> </author>
            <date year='2007'/> year="2007"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/TNET.2006.890128"/>
        </reference>

        <reference anchor='SSL-Labs' target='https://www.ssllabs.com/ssltest/'> anchor="SSL-Labs" target="https://www.ssllabs.com/ssltest/">
          <front>
            <title>SSL Server Test</title>
            <author>
              <organization>SSL Labs</organization>
            </author>
            <date year='2019'/> year="2019"/>
          </front>
        </reference>

        <reference anchor='SURFnet-policy'
   target='https://surf.nl/datasharing'> anchor="SURFnet-policy" target="https://surf.nl/datasharing">
          <front>
            <title>SURFnet Data Sharing Policy</title>
        <author>
            <organization>SURFnet</organization>
        </author>
            <author initials ="C" surname="Baartmans" />
            <author initials ="A" surname="van Wynsberghe" />
            <author initials ="R" surname="van Rijswijk-Deij" />
            <author initials ="F" surname="Jorna" />
            <date year='2016'/> year="2016" month="June"/>
          </front>
        </reference>

        <reference anchor='TCPdpriv'
	   target='http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html'> anchor="tcpdpriv"
		   target="http://fly.isti.cnr.it/software/tcpdpriv/">
          <front>
        <title>TCPdpriv</title>
            <title>TCPDRIV - Program for Eliminating Confidential Information from Traces</title>
            <author>
              <organization>Ipsilon Networks, Inc.</organization>
            </author>
            <date year='2005'/> year="2004"/>
          </front>
        </reference>

        <reference anchor='Xu-et-al.'
           target='http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-anon.pdf'> 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>
            <author initials='J.' surname='Fan'> initials="J." surname="Fan"> </author>
            <author initials='J.' surname='Xu'> initials="J." surname="Xu"> </author>
            <author initials='M. H.' surname='Ammar'> initials="M.H." surname="Ammar"> </author>
            <author initials='S. B.' surname='Moon'> initials="S.B." surname="Moon"> </author>
            <date year='2004'/> year="2004"/>
          </front>
	  <seriesInfo name="DOI" value="10.1016/j.comnet.2004.03.033"/>
        </reference>

        <reference anchor='dnsdist' target='https://dnsdist.org'> anchor="dnsdist" target="https://dnsdist.org">
          <front>
            <title>dnsdist Overview</title>
            <author>
              <organization>PowerDNS</organization>
            </author>
        <date year='2019'/>
          </front>
        </reference>

        <reference anchor='dnstap' target='http://dnstap.info'> anchor="dnstap" target="https://dnstap.info">
          <front>
        <title>DNSTAP</title>
        <author>
            <organization>dnstap.info</organization>
        </author>
        <date year='2019'/>
            <title>dnstap</title>
            <author />
          </front>
        </reference>

        <reference anchor='dot-ALPN'
target='https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids'> anchor="dot-ALPN" target="https://www.iana.org/assignments/tls-extensiontype-values">
          <front>
<title>TLS
            <title>Transport Layer Security (TLS) Extensions: TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title>
            <author>
 <organization>IANA (iana.org)</organization>
              <organization>IANA</organization>
            </author>
<date year='2020'/>
          </front>
        </reference>

        <reference anchor='haproxy' target='https://www.haproxy.org/'> anchor="haproxy" target="https://www.haproxy.org/">
          <front>
        <title>HAPROXY</title>
            <title>HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer</title>
            <author>
            <organization>haproxy.org</organization>
              <organization/>
            </author>
        <date year='2019'/>
          </front>
        </reference>

        <reference anchor='ipcipher1'
           target='https://medium.com/@bert.hubert/on-ip-address-encryption-security-analysis-with-respect-for-privacy-dabe1201b476'> anchor="ipcipher1" target="https://medium.com/@bert.hubert/on-ip-address-encryption-security-analysis-with-respect-for-privacy-dabe1201b476">
          <front>
            <title>On IP address encryption: security analysis with respect for
	privacy</title>
            <author initials='B.' surname='Hubert'> initials="B." surname="Hubert"> </author>
            <date year='2017'/> year="2017" month="May" day="7"/>
          </front>
	  <refcontent>Medium</refcontent>
        </reference>

        <reference anchor='ipcipher2'
           target='https://github.com/PowerDNS/ipcipher'> anchor="ipcipher2" target="https://github.com/PowerDNS/ipcipher">
          <front>
            <title>ipcipher</title>
            <author>
              <organization>PowerDNS</organization>
            </author>
            <date year='2017'/> year="2018" month="February" day="13"/>
          </front>
	  <seriesInfo name="commit" value="fd47abe"/>
        </reference>

        <reference anchor='ipcrypt'
           target='https://github.com/veorq/ipcrypt'> anchor="ipcrypt" target="https://github.com/veorq/ipcrypt">
          <front>
            <title>ipcrypt: IP-format-preserving encryption</title>
            <author>
              <organization>veorq</organization>
            </author>
            <date year='2015'/> year="2015" month="July" day="6"/>
          </front>
	  <seriesInfo name="commit" value="8cc12f9" />
        </reference>

        <reference anchor='ipcrypt-analysis'
           target='https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html'> anchor="ipcrypt-analysis" target="https://mailarchive.ietf.org/arch/msg/cfrg/cFx5WJo48ZEN-a5cj_LlyrdN8-0/">
          <front>
        <title>Analysis
            <title>Subject: Re: [Cfrg] Analysis of ipcrypt?</title>
            <author initials='J.' surname='Aumasson'> initials="J-P" surname="Aumasson"> </author>
            <date year='2018'/> year="2018" month="February" day="22"/>
          </front>
	  <refcontent>message to the Cfrg mailing list</refcontent>
        </reference>

        <reference anchor='nginx' target='https://nginx.org/'> anchor="nginx" target="https://nginx.org/">
          <front>
        <title>NGINX</title>
            <title>nginx news</title>
            <author>
              <organization>nginx.org</organization>
            </author>
            <date year='2019'/> year="2019"/>
          </front>
        </reference>

        <reference anchor='pcap' target='http://www.tcpdump.org/'> anchor="pcap" target="https://www.tcpdump.org/">
          <front>
        <title>PCAP</title>
            <title>Tcpdump &amp; Libpcap</title>
            <author>
            <organization>tcpdump.org</organization>
              <organization>The Tcpdump Group</organization>
            </author>
            <date year='2016'/> year="2020"/>
          </front>
        </reference>

        <reference anchor='policy-comparison'
   target='https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements+2019'> anchor="policy-comparison" target="https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements+2019">
          <front>
            <title>Comparison of policy and privacy statements 2019</title>
        <author>
            <organization>dnsprivacy.org</organization>
        </author>
            <author initials="S" surname="Dickinson" />
            <date year='2019'/> day="18" month="December" year="2019" />
          </front>
	  <refcontent>DNS Privacy Project</refcontent>
        </reference>

        <reference anchor='stunnel'
	   target='https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html'> anchor="stunnel" target="https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html">
          <front>
        <title>DNS-over-TLS</title>
        <author>
            <organization>ISC Knowledge Database</organization>
        </author>
            <title>DNS over TLS</title>
            <author initials="S" surname="Goldlust" />
            <author initials="C" surname="Almond" />
            <author initials="F" surname="Dupont" />
            <date year='2018'/> 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'> anchor="van-Dijkhuizen-et-al" target="https://doi.org/10.1145/3182660">
          <front>
            <title>A Survey of Network Traffic Anonymisation Techniques and
	Implementations</title>
            <author initials='N.' surname='Van initials="N." surname="Van Dijkhuizen '> "> </author>
            <author initials='J.' surname='Van initials="J." surname="Van Der Ham'> Ham"> </author>
            <date year='2018'/> year="2018" month="May"/>
          </front>
	  <seriesInfo name="DOI" value="10.1145/3182660"/>
	  <refcontent>ACM Computing Surveys</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="documents" title="Documents">
<t>This numbered="true" toc="default">
      <name>Documents</name>
      <t>

This section provides an overview of some DNS privacy-related documents,
however,
documents. However, this is neither an exhaustive list nor a
definitive statement on the
characteristic characteristics of the document. any document with
regard to potential increases or decreases in DNS privacy.

</t>
      <section anchor="potential-increases-in-dns-privacy" title="Potential
  increases numbered="true" toc="default">
        <name>Potential Increases in DNS privacy"> Privacy</name>
        <t>These documents are limited in scope to communications between stub
clients and recursive resolvers:
</t>
<t>
<list style="symbols">
<t>'Specification
        <ul spacing="normal">
          <li>"Specification for DNS over Transport Layer Security (TLS)' (TLS)" <xref
target="RFC7858"/>.</t>
<t>'DNS target="RFC7858" format="default"/>.</li>
          <li>"DNS over Datagram Transport Layer Security (DTLS)' (DTLS)" <xref
target="RFC8094"/>. target="RFC8094" format="default"/>. Note that this
document has the Category category of Experimental.</t>
<t>'DNS Experimental.</li>
          <li>"DNS Queries over HTTPS (DoH)' (DoH)" <xref target="RFC8484"/>.</t>
<t>'Usage target="RFC8484" format="default"/>.</li>
          <li>"Usage Profiles for DNS over TLS and DNS over DTLS' DTLS" <xref
target="RFC8310"/>.</t>
<t>'The target="RFC8310" format="default"/>.</li>
          <li>"The EDNS(0) Padding Option' Option" <xref target="RFC7830"/> target="RFC7830"
	  format="default"/> and 'Padding Policy "Padding Policies for Extension Mechanisms
	  for EDNS(0)' DNS (EDNS(0))" <xref target="RFC8467"/>.</t>
</list>
</t> target="RFC8467" format="default"/>.</li>
        </ul>
        <t>These documents apply to recursive and authoritative DNS but are relevant
when
considering the operation of a recursive server:
</t>
<t>
<list style="symbols">
<t>'DNS
        <ul spacing="normal">
          <li>"DNS Query Name minimization Minimisation to Improve Privacy' Privacy" <xref
target="RFC7816"/>.</t>
</list>
</t> target="RFC7816" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="potential-decreases-in-dns-privacy" title="Potential
  decreases numbered="true" toc="default">
        <name>Potential Decreases in DNS privacy"> Privacy</name>
        <t>These documents relate to functionality that could provide increased
tracking of
user activity as a side effect:
</t>
<t>
<list style="symbols">
<t>'Client
        <ul spacing="normal">
          <li>"Client Subnet in DNS Queries' Queries" <xref target="RFC7871"/>.</t>
<t>'Domain target="RFC7871"
	  format="default"/>.</li>
          <li>"Domain Name System (DNS) Cookies' Cookies" <xref target="RFC7873"/>).</t>
<t>'Transport target="RFC7873"
	  format="default"/>).</li>
          <li>"Transport Layer Security (TLS) Session Resumption without Server-Side
State'
	  State" <xref target="RFC5077"/> target="RFC5077" format="default"/>, referred to here
	  as simply TLS session
resumption.</t>
<t><xref target="RFC8446"/> Appendix C.4 resumption.</li>
          <li>
            <xref target="RFC8446" section="C.4" sectionFormat="comma"/>
	    describes Client Tracking Prevention client tracking prevention in TLS 1.3</t>
<t>'A 1.3</li>
          <li>"Compacted-DNS (C-DNS): A Format for DNS Packet Capture Format' Capture" <xref target="RFC8618"/>.</t>
<t>Passive
	  target="RFC8618" format="default"/>.</li>
          <li>Passive DNS <xref target="RFC8499"/>.</t>
<t>Section 8 of <xref target="RFC8484"/> target="RFC8499" format="default"/>.</li>
          <li><xref target="RFC8484" sectionFormat="of"
	  section="8"/> outlines the privacy considerations
of DoH. Note that
(while that document advises exposing the minimal set of data needed to
achieve the desired feature set) set), depending on the specifics of a DoH
implementation
implementation, there may be increased identification and tracking compared to
other DNS transports.</t>
</list>
</t> transports.</li>
        </ul>
      </section>
      <section anchor="related-operational-documents" title="Related operational
						       documents">
<t>
<list style="symbols">
<t>'DNS numbered="true" toc="default">
        <name>Related Operational Documents</name>
        <ul spacing="normal">
          <li>"DNS Transport over TCP - Implementation Requirements' Requirements" <xref
target="RFC7766"/>.</t>
<t>'Operational requirements for DNS target="RFC7766" format="default"/>.</li>
          <li>"DNS Transport over TCP' TCP - Operational Requirements"
<xref target="I-D.ietf-dnsop-dns-tcp-requirements"/>.</t>
<t>'The target="I-D.ietf-dnsop-dns-tcp-requirements" format="default"/>.</li>
          <li>"The edns-tcp-keepalive EDNS0 Option' Option" <xref target="RFC7828"/>.</t>
<t>'DNS target="RFC7828" format="default"/>.</li>
          <li>"DNS Stateful Operations' Operations" <xref target="RFC8490"/>.</t>
</list>
</t> target="RFC8490" format="default"/>.</li>
        </ul>
      </section>
    </section>
    <section anchor="ip-address-techniques" title="IP address techniques"> numbered="true" toc="default">
      <name>IP Address Techniques</name>
      <t>The following table presents a high level high-level comparison of various techniques
employed or under development in 2019, 2019 and classifies them according to
categorization of technique and other properties. Both the specific techniques
and the categorisations categorizations are described in more detail in the following
sections.
The list of techniques includes the main techniques in current use, use but does
not
claim to be comprehensive.
</t>
<texttable title="Table 1: Classification of techniques
">
<ttcol align="left">Categorization/Property</ttcol>
<ttcol align="center">GA</ttcol>
<ttcol align="center">d</ttcol>
<ttcol align="center">TC</ttcol>
<ttcol align="center">C</ttcol>
<ttcol align="center">TS</ttcol>
<ttcol align="center">i</ttcol>
<ttcol align="center">B</ttcol>

<c>Anonymization</c><c>X</c><c>X</c><c>X</c><c></c><c></c><c></c><c>X</c>
<c>Pseudoanonymization</c><c></c><c></c><c></c><c>X</c><c>X</c><c>X</c><c></c>
<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>
      <table align="center">
        <name>Classification of Techniques</name>
        <thead>
          <tr>
            <th align="left">Categorization/Property</th>
            <th align="center">GA</th>
            <th align="center">d</th>
            <th align="center">TC</th>
            <th align="center">C</th>
            <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: GA = techniques:</t>
      <dl spacing="compact" indent="5">
	<dt>GA</dt><dd>= Google Analytics, d = dnswasher, TC = TCPdpriv,
C = CryptoPAn, TS = TSA, i = ipcipher, B = 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
</t> filter</dd>
</dl>

      <t>The choice of which method to use for a particular application will depend
on
the requirements of that application and consideration of the threat analysis
of
the particular situation.
</t>

      <t>For example, a common goal is that distributed packet captures must be in
      an existing data format format, such as PCAP <xref target="pcap"/> target="pcap"
      format="default"/> or C-DNS Compacted-DNS (C-DNS) <xref
target="RFC8618"/> target="RFC8618"
      format="default"/>, 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 - cost free; several authors
      (e.g., <xref target="Brenker-and-Arnes"/> target="Brekne-and-Arnes" format="default"/>) have observed
      that, as the entropy in an IPv4 address is limited, if an attacker can
      </t>
<t>
<list style="symbols">
<t>ensure
      <ul spacing="normal">
        <li>ensure packets are captured by the target and</t>
<t>send and</li>
        <li>send forged traffic with arbitrary source and destination addresses to that
target and</t>
<t>obtain and</li>
        <li>obtain a de-identified log of said traffic from that target</t>
</list>
</t> target,</li>
      </ul>
      <t>any format-preserving pseudonymization is vulnerable to an attack along the
lines of a cryptographic chosen plaintext chosen-plaintext attack.
</t>
      <section anchor="categorization-of-techniques" title="Categorization numbered="true" toc="default">
        <name>Categorization of
						      techniques"> Techniques</name>
        <t>Data minimization methods may be categorized by the processing used and the
properties of their outputs. The following builds on the categorization
employed in <xref target="RFC6235"/>: target="RFC6235" format="default"/>:
</t>
<t>
<list style="symbols">
<t>Format-preserving. Normally
        <dl spacing="normal">
          <dt>Format-preserving.</dt><dd> Normally, when encrypting, the original data length and
patterns in the data should be hidden from an attacker. Some applications of
de-identification, such as network capture de-identification, require that the
de-identified data is of the same form as the original data, to allow the data
to be parsed in the same way as the original.</t>
<t>Prefix preservation. original.</dd>
          <dt>Prefix preservation.</dt><dd> Values such as IP addresses and MAC addresses contain
prefix information that can be valuable in analysis, analysis -- e.g., manufacturer ID in
MAC addresses, or subnet in IP addresses. Prefix preservation ensures that
prefixes are de-identified consistently; e.g., for example, if two IP addresses are from
the
same subnet, a prefix preserving de-identification will ensure that their
de-identified counterparts will also share a subnet. Prefix preservation may
be fixed (i.e. (i.e., based on a user selected user-selected prefix length identified in advance to
be preserved ) or general.</t>
<t>Replacement. general.</dd>
<dt>Replacement.</dt><dd> A one-to-one replacement of a field to a new value of the same
type,
type -- for example, using a regular expression.</t>
<t>Filtering. 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
reverse truncation) or
completely (black-marker anonymization).</t>
<t>Generalization. anonymization).</dd>
          <dt>Generalization.</dt><dd> Data is replaced by more general data with reduced
specificity. One example would be to replace all TCP/UDP port numbers with one
of two fixed values indicating whether the original port was ephemeral
(&gt;=1024) or non-ephemeral nonephemeral (&gt;1024). Another example, precision
degradation,
reduces the accuracy of e.g., of, for example, a numeric value or a timestamp.</t>
<t>Enumeration. timestamp.</dd>

          <dt>Enumeration.</dt><dd> With data from a well-ordered set, replace
	  the first data item item's data using a random initial value and then
	  allocate ordered values for
	  subsequent data items. When used with timestamp data, this preserves ordering
	  but loses precision and distance.</t>
<t>Reordering/shuffling. distance.</dd>
          <dt>Reordering/shuffling.</dt><dd> Preserving the original data, but rearranging its
order,
often in a random manner.</t>
<t>Random substitution. manner.</dd>
          <dt>Random substitution.</dt><dd> As replacement, but using randomly generated
replacement
values.</t>
<t>Cryptographic permutation.
values.</dd>
          <dt>Cryptographic permutation.</dt><dd> Using a permutation function, such as a hash
function or cryptographic block cipher, to generate a replacement
de-identified value.</t>
</list>
</t> value.</dd>
        </dl>
      </section>
      <section anchor="specific-techniques" title="Specific techniques"> numbered="true" toc="default">
        <name>Specific Techniques</name>
        <section anchor="google-analytics-nonprefix-filtering" title="Google numbered="true" toc="default">
          <name>Google Analytics
  non-prefix filtering"> Non-Prefix Filtering</name>
          <t>Since May 2010, Google Analytics has provided a facility <xref
target="IP-Anonymization-in-Analytics"/> target="IP-Anonymization-in-Analytics" format="default"/> that allows website
owners to request that all their users users' IP addresses are anonymized within
Google Analytics processing. This very basic anonymization simply sets to zero
the least significant 8 bits of IPv4 addresses, and the least significant 80
bits of IPv6 addresses. The level of anonymization this produces is perhaps
questionable. There are some analysis results <xref
target="Geolocation-Impact-Assessement"/>
which
target="Geolocation-Impact-Assessment" format="default"/> that suggest that the impact of
this on reducing the accuracy of determining the user's location from their IP
address is less than might be hoped; the average discrepancy in identification
of the user city for UK users is no more than 17%.
	  </t>
<t>Anonymization:
	  <dl>
          <dt>Anonymization:</dt><dd> Format-preserving, Filtering (trucation).
</t> (truncation).</dd>
</dl>
        </section>
        <section anchor="dnswasher" title="dnswasher"> numbered="true" toc="default">
          <name>dnswasher</name>
          <t>Since 2006, PowerDNS have has included a de-identification tool tool, dnswasher
<xref target="PowerDNS-dnswasher"/> target="PowerDNS-dnswasher" format="default"/>, with their PowerDNS
product. This is a
PCAP filter that
performs a one-to-one mapping of end user end-user IP addresses with an anonymized
address. A table of user IP addresses and their de-identified counterparts is
kept; the first IPv4 user addresses is translated to 0.0.0.1, the second to
0.0.0.2
0.0.0.2, and so on. The de-identified address therefore depends on the order
that
addresses arrive in the input, and when running over a large amount of data data, the
address translation tables can grow to a significant size.
	  </t>
<t>Anonymization:
	  <dl>
          <dt>Anonymization:</dt><dd> Format-preserving, Enumeration.
</t> Enumeration.</dd>
</dl>
        </section>
        <section anchor="prefixpreserving-map" title="Prefix-preserving map"> numbered="true" toc="default">
          <name>Prefix-Preserving Map</name>
          <t>Used in <xref target="TCPdpriv"/>, target="tcpdpriv" format="default"/>,
this algorithm stores a set of original and anonymised anonymized IP
address pairs. When a new IP address arrives, it is compared with previous
addresses to determine the longest prefix match. The new address is anonymized
by using the same prefix, with the remainder of the address anonymized with a
random value. The use of a random value means that TCPdpriv is not
deterministic; different anonymized values will be generated on each run.

The need to store previous addresses means that TCPdpriv has significant and
unbounded memory requirements, and because of the requirements. The need to allocated allocate anonymized addresses
sequentially means that TCPdpriv cannot be used in parallel processing.

	  </t>
<t>Anonymization:
	  <dl>
          <dt>Anonymization:</dt><dd> Format-preserving, prefix preservation (general).
</t> (general).</dd>
</dl>
        </section>
        <section anchor="cryptographic-prefixpreserving-pseudonymization"
	 title="Cryptographic numbered="true" toc="default">
          <name>Cryptographic Prefix-Preserving Pseudonymization"> Pseudonymization</name>
          <t>Cryptographic prefix-preserving pseudonymization was originally proposed as
an
improvement to the prefix-preserving map implemented in TCPdpriv, described in
<xref target="Xu-et-al."/> target="Xu-et-al" format="default"/> and implemented in the <xref target="Crypto-PAn"/> target="Crypto-PAn" format="default"/>
tool.
Crypto-PAn is now frequently
used as an acronym for the algorithm. Initially Initially, it was described for IPv4
addresses only; extension for IPv6 addresses was proposed in <xref
target="Harvan"/>. target="Harvan" format="default"/>. This uses a cryptographic algorithm
rather than a random value, and thus pseudonymity is determined uniquely by
the
encryption key, and is deterministic. It requires a separate AES encryption
for
each output bit, bit and so has a non-trivial nontrivial calculation overhead. This can be
mitigated to some extent (for IPv4, at least) by pre-calculating precalculating results for
some number of prefix bits.
	  </t>
<t>Pseudonymization:
	  <dl>
          <dt>Pseudonymization:</dt><dd> Format-preserving, prefix preservation (general).
</t> (general).</dd>
</dl>
        </section>
        <section anchor="tophash-subtreereplicated-anonymization" title="Top-hash
  Subtree-replicated Anonymization"> numbered="true" toc="default">
          <name>Top-Hash Subtree-Replicated Anonymization</name>
          <t>Proposed in <xref target="Ramaswamy-and-Wolf"/>, target="Ramaswamy-and-Wolf" format="default"/>,
Top-hash Subtree-replicated Anonymization (TSA)
originated in response to the requirement for faster processing than
Crypto-PAn.
It used hashing for the most significant byte of an IPv4 address, address and a
pre-calculated binary tree
precalculated binary-tree structure for the remainder of the address.

To save
memory space, replication is used within the tree structure, reducing the size
of the pre-calculated precalculated structures to a few Mb megabytes for IPv4 addresses. Address
pseudonymization is done via hash and table lookup, lookup and so requires minimal
computation. However, due to the much increased much-increased address space for IPv6, TSA is
not memory efficient for IPv6.
	  </t>
<t>Pseudonymization:
	  <dl>
          <dt>Pseudonymization:</dt><dd> Format-preserving, prefix preservation (general).
</t> (general).</dd>
</dl>
        </section>
        <section anchor="ipcipher" title="ipcipher"> numbered="true" toc="default">
          <name>ipcipher</name>
          <t>A recently-released recently released proposal from PowerDNS, ipcipher
<xref target="ipcipher1"/> target="ipcipher1" format="default"/> <xref target="ipcipher2"/> target="ipcipher2"
format="default"/>, is a simple
pseudonymization technique for IPv4 and IPv6 addresses. IPv6 addresses are
encrypted directly with AES-128 using a key (which may be derived from a
passphrase). IPv4 addresses are similarly encrypted, but using a recently
proposed encryption <xref target="ipcrypt"/> target="ipcrypt" format="default"/> suitable for 32bit
32-bit block lengths. However, the author of ipcrypt has since indicated <xref
target="ipcrypt-analysis"/>
target="ipcrypt-analysis" format="default"/> that it has
low security, and further analysis has revealed it is vulnerable to attack.
	  </t>
<t>Pseudonymization: Format-preserving,
	  <dl>
          <dt>Pseudonymization:</dt><dd>Format-preserving, cryptographic permutation.
</t> permutation.</dd>
</dl>
        </section>
        <section anchor="bloom-filters" title="Bloom filters"> numbered="true" toc="default">
          <name>Bloom Filters</name>
          <t>van Rijswijk-Deij et al.
have recently described work using Bloom filters Filters <xref target="Bloom-filter"/> target="Bloom-filter" format="default"/>
to
categorize query traffic and record the traffic as the state of multiple
filters. The goal of this work is to allow operators to identify so-called
Indicators of Compromise (IOCs) originating from specific subnets without
storing information about, or be being able to monitor monitor, the DNS queries of an
individual user. By using a Bloom filter, Filter, it is possible to determine with a
high probability if, for example, a particular query was made, but the set of
queries made cannot be recovered from the filter. Similarly, by mixing queries
from a sufficient number of users in a single filter, it becomes practically
impossible to determine if a particular user performed a particular
query. Large
numbers of queries can be tracked in a memory-efficient way. As filter status
is
stored, this approach cannot be used to regenerate traffic, traffic and so cannot be
used with tools used to process live traffic.
	  </t>
<t>Anonymized: Generalization.
</t>
	  <dl>
          <dt>Anonymized:</dt><dd> Generalization.</dd>
</dl>
        </section>
      </section>
    </section>
    <section anchor="current-policy-and-privacy-statements" title="Current policy numbered="true" toc="default">
      <name>Current Policy and privacy statements"> Privacy Statements</name>
      <t>A tabular comparison of policy and privacy statements from various DNS
Privacy
      privacy service operators based loosely on the proposed RPS structure can
      be found at <xref target="policy-comparison"/>. target="policy-comparison" format="default"/>. 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 content, and
detail
detail, and it is not uncommon for the full text for a given operator to
equate to more than 10 pages (A4 size) of moderate font sized A4 text. text in a moderate-sized font. It is a
non-trivial
nontrivial task today for a user to extract a meaningful overview of the
different services on offer.
</t>
      <t>It is also noted that Mozilla have has published a DoH resolver policy
<xref target="DoH-resolver-policy"/>, which target="DoH-resolver-policy" format="default"/> that describes the minimum set of
policy
requirements that a party must satisfy to be considered as a potential
partner for Mozilla’s Mozilla's Trusted Recursive Resolver (TRR) program.
</t>
    </section>
    <section anchor="example-rps" title="Example RPS"> numbered="true" toc="default">
      <name>Example RPS</name>
      <t>The following example RPS is very loosely based on some elements of
published privacy statements for some public resolvers, with additional fields
populated to illustrate the what the full contents of an RPS might
look like. This should not be interpreted as
</t>
<t>
<list style="symbols">
<t>having
      <ul spacing="normal">
        <li>having been reviewed or approved by any operator in any way</t>
<t>having way</li>
        <li>having any legal standing or validity at all</t>
<t>being all</li>
        <li>being complete or exhaustive</t>
</list>
</t> exhaustive</li>
      </ul>
      <t>This is a purely hypothetical example of an RPS to outline example
contents - -- in this case case, for a public resolver operator providing a basic DNS
Privacy service via one IP address and one DoH URI with security based security-based
filtering. It does aim to meet minimal compliance as specified in
<xref target="recommendations-for-dns-privacy-services"/>. target="recommendations-for-dns-privacy-services" format="default"/>.
</t>

      <section anchor="policy-1" title="Policy">
<t>
<list style="numbers">
<t>Treatment numbered="true" toc="default">
        <name>Policy</name>
        <ol spacing="normal" type="1">
          <li>Treatment of IP addresses. Many nations classify IP addresses as personal
data, and we take a conservative approach in treating IP addresses as personal
data in all jurisdictions in which our systems reside.</t> reside.</li>
          <li>
            <t>Data collection and sharing.
<list style="numbers">
<t>IP
</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
transmitted out of the location in which the query was received. We may
aggregate certain counters to larger network block levels for
statistical collection purposes, but those counters do not maintain specific
IP address
data data, nor is the format or model of data stored capable of being
reverse-engineered to ascertain what specific IP addresses made what
queries.</t>
queries.</li>
              <li>
                <t>Data collected in logs. We do keep some generalized
		location information
		(at the city/metropolitan area city / metropolitan-area level) so that we can conduct debugging and
		analyze abuse phenomena. We also use the collected information for the
		creation and sharing of telemetry (timestamp, geolocation, number of hits,
		first seen, last seen) for contributors, public publishing of general
		statistics of system use (protections, threat types, counts, etc.) etc.).
		When you use our DNS Services, services, here is the full list of items that are
		included in our logs:
<list style="symbols">
<t>Request
</t>
                <ul spacing="normal">
                  <li>Requested domain name, name -- e.g., example.net</t>
<t>Record example.net</li>
                  <li>Record type of requested domain, domain -- e.g., A, AAAA, NS,
		  MX, TXT, etc.</t> etc.</li>
                  <li>
                    <t>Transport protocol on which the request arrived, i.e. arrived --
		    i.e., UDP, TCP, DoT,
<vspace/> DoH</t>
<t>Origin
                  </li>
                  <li>Origin IP general geolocation information: i.e. information -- i.e., geocode, region ID,
		  city ID, and metro code</t>
<t>IP code</li>
                  <li>IP protocol version – -- IPv4 or IPv6</t>
<t>Response IPv6</li>
                  <li>Response code sent, sent -- e.g., SUCCESS, SERVFAIL, NXDOMAIN, etc.</t>
<t>Absolute etc.</li>
                  <li>Absolute arrival time using a precision in ms</t>
<t>Name ms</li>
                  <li>Name of the specific instance that processed this request</t>
<t>IP request</li>
                  <li>IP address of the specific instance to which this request was
addressed (no relation to the requestor’s requestor's IP address)</t>
</list> address)</li>
                </ul>
                <t>
We may keep the following data as summary information, including all the
above EXCEPT for data about the DNS record requested:
<list style="symbols">
<t>Currently-advertised
</t>
                <ul spacing="normal">
                  <li>Currently advertised BGP-summarized IP prefix/netmask of apparent
client origin</t>
<t>Autonomous origin</li>
                  <li>Autonomous system number (BGP ASN) of apparent client origin</t>
</list> origin</li>
                </ul>
                <t>
All the above data may be kept in full or partial form in permanent
archives.</t>
<t>Sharing
              </li>
              <li>Sharing of data.
Except as described in this document, we do not intentionally share,
sell, or rent individual personal information associated with the
requestor (i.e. (i.e., source IP address or any other information that can
positively identify the client using our infrastructure) with anyone
without your consent.
We generate and share high level high-level anonymized aggregate statistics statistics,
including threat metrics on threat type, geolocation, and if available,
sector, as well as other vertical metrics metrics, including performance metrics
on our DNS Services (i.e. (i.e., number of threats blocked, infrastructure
uptime) when available with our threat intelligence Threat Intelligence (TI) partners,
academic researchers, or the public.
Our DNS Services services share anonymized data on specific domains queried
(records such as domain, timestamp, geolocation, number of hits, first
seen, last seen) with our threat intelligence Threat Intelligence partners. Our DNS Services service
also builds, stores, and may share certain DNS data streams which store
high level information about domain resolved, query types, result codes,
and timestamp. These streams do not contain the IP address information of
the requestor and cannot be correlated to IP address or other personal data.
We do not and never will share any of its the requestor's data with marketers, nor will
it
we use this data for demographic analysis.</t>
</list></t>
<t>Exceptions. analysis.</li>
            </ol>
          </li>
          <li>Exceptions. There are exceptions to this storage model: In the event of
actions or observed behaviors which that we deem malicious or anomalous, we may
utilize more detailed logging to collect more specific IP address data in the
process of normal network defence defense and mitigation. This collection and
transmission off-site will be limited to IP addresses that we determine are
involved in the event.</t>
<t>Associated event.</li>
          <li>Associated entities. Details of our Threat Intelligence partners can be
found
at our website page (insert link).</t>
<t>Correlation link).</li>
          <li>Correlation of Data. We do not correlate or combine information from our
logs
with any personal information that you have provided us for other services, or
with your specific IP address.</t> address.</li>
          <li>
            <t>Result filtering.
<list style="numbers">
</t>
            <ol spacing="normal" type="a">
              <li>
                <t>Filtering. We utilise cyber threat utilize cyber-threat intelligence about
		malicious domains
		from a variety of public and private sources and blocks block access to those
		malicious domains when your system attempts to contact
		them. An NXDOMAIN is
		returned for blocked sites.
<list style="numbers">
<t>Censorship.
</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,
malware, and exploit kit domains.</t>
<t>Accidental exploit-kit domains.</li>
                  <li>Accidental blocking. We implement allowlisting algorithms to make sure
legitimate domains are not blocked by accident. However, in the rare case of
blocking a legitimate domain, we work with the users to quickly allowlist
that domain. Please use our support form (insert link) if you believe we are
blocking a domain in error.</t>
</list></t>
</list></t>
</list>
</t> error.</li>
                </ol>
              </li>
            </ol>
          </li>
        </ol>
      </section>

      <section anchor="practice-1" title="Practice">
<t>
<list style="numbers">
<t>Deviations numbered="true" toc="default">
        <name>Practice</name>
        <ol spacing="normal" type="1">
          <li>Deviations from Policy. None in place since (insert date).</t>
<t>Client facing date).</li>
          <li>
            <t>Client-facing capabilities.
<list style="numbers">
<t>We
</t>
            <ol spacing="normal" type="a">
              <li>We offer UDP and TCP DNS on port 53 on (insert IP address)</t> address)</li>
              <li>
                <t>We offer DNS over TLS as specified in RFC7858 RFC 7858 on (insert
		IP address). It
		is available on port 853 and port 443. We also implement RFC7766.
<list style="numbers">
<t>The RFC 7766.
</t>
                <ol spacing="normal" type="i">
                  <li>The DoT authentication domain name used is (insert domain name).</t>
<t>We name).</li>
                  <li>We do not publish SPKI pin sets.</t>
</list></t>
<t>We sets.</li>
                </ol>
              </li>
              <li>We offer DNS over HTTPS as specified in RFC8484 RFC 8484 on (insert URI
template).</t>
<t>Both
template).</li>
              <li>Both services offer TLS 1.2 and TLS 1.3.</t>
<t>Both 1.3.</li>
              <li>Both services pad DNS responses according to RFC8467.</t> RFC 8467.</li>
              <li>
                <t>Both services provide DNSSEC validation.

<vspace/></t>
</list></t>

</t>
                <t/>
              </li>
            </ol>
          </li>
          <li>
            <t>Upstream capabilities.
<list style="numbers">
<t>Our
</t>
            <ol spacing="normal" type="a">
              <li>Our servers implement QNAME minimization.</t>
<t>Our minimization.</li>
              <li>Our servers do not send ECS upstream.</t>
</list></t>
<t>Support. upstream.</li>
            </ol>
          </li>
          <li>Support. Support information for this service is available at (insert
link).</t>
<t>Data
link).</li>
          <li>Data Processing. We operate as the legal entity (insert entity) registered
in
(insert country); as such such, we operate under (insert country/region) law. Our
separate statement regarding the specifics of our data processing policy,
practice, and agreements can be found here (insert link).</t>
</list> link).</li>
        </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><contact fullname="Sara Dickinson"/> thanks the Open Technology Fund for a grant to support the
work
on this document.
</t>
    </section>
    <section anchor="contributors" numbered="false" toc="default">
      <name>Contributors</name>

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