rfc9076xml2.original.xml   rfc9076.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc ipr="trust200902" category="info" docName="draft-ietf-dprive-rfc7626-bis-09
" obsoletes="7626">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="DNS Privacy Considerations">DNS Privacy Considerations</title>
<author role="editor" initials="T." surname="Wicinski" fullname="Tim Wicinski">
<organization></organization>
<address>
<postal>
<street></street>
<city>Elkins</city>
<code>26241</code>
<country>USA</country>
<region>WV</region>
</postal>
<phone></phone>
<email>tjw.ietf@gmail.com</email>
<uri></uri>
</address>
</author>
<date year="2021" month="March" day="9"/>
<area>Internet Area</area> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<workgroup>dprive</workgroup> -ietf-dprive-rfc7626-bis-09" number="9076" obsoletes="7626" updates="" submissio
<keyword>DNS</keyword> nType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" sy
mRefs="true" sortRefs="true" version="3">
<abstract> <front>
<t>This document describes the privacy issues associated with the use of the DNS <title abbrev="DNS Privacy Considerations">DNS Privacy Considerations</title
>
<seriesInfo name="RFC" value="9076"/>
<author role="editor" initials="T." surname="Wicinski" fullname="Tim Wicinsk
i">
<organization/>
<address>
<postal>
<street/>
<city>Elkins</city>
<code>26241</code>
<country>United States of America</country>
<region>WV</region>
</postal>
<phone/>
<email>tjw.ietf@gmail.com</email>
<uri/>
</address>
</author>
<date year="2021" month="July"/>
<area>Internet Area</area>
<workgroup>dprive</workgroup>
<keyword>DNS</keyword>
<abstract>
<t>This document describes the privacy issues associated with the use of t
he DNS
by Internet users. It provides general observations about typical current by Internet users. It provides general observations about typical current
privacy practices. It is intended to be an analysis of the present situation privacy practices. It is intended to be an analysis of the present situation
and does not prescribe solutions. This document obsoletes RFC 7626. and does not prescribe solutions. This document obsoletes RFC 7626.
</t> </t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>This document is an analysis of the DNS privacy issues, in the spirit
<section anchor="introduction" title="Introduction"> of <xref target="RFC6973" sectionFormat="of" section="8"/>.
<t>This document is an analysis of the DNS privacy issues, in the spirit
of Section 8 of <xref target="RFC6973"/>.
</t> </t>
<t>The Domain Name System (DNS) is specified in <xref target="RFC1034"/>, <xref target="RFC1035"/>, and <t>The Domain Name System (DNS) is specified in <xref target="RFC1034" for mat="default"/>, <xref target="RFC1035" format="default"/>, and
many later RFCs, which have never been consolidated. It is one of the most many later RFCs, which have never been consolidated. It is one of the most
important infrastructure components of the Internet and often ignored or important infrastructure components of the Internet and is often ignored or
misunderstood by Internet users (and even by many professionals). Almost misunderstood by Internet users (and even by many professionals). Almost
every activity on the Internet starts with a DNS query (and often several). every activity on the Internet starts with a DNS query (and often several).
Its use has many privacy implications and this document is an attempt at a Its use has many privacy implications, and this document is an attempt at a
comprehensive and accurate list. comprehensive and accurate list.
</t> </t>
<t>Let us begin with a simplified reminder of how the DNS works (See also <t>Let us begin with a simplified reminder of how the DNS works (see also
<xref target="RFC8499"/>). A client, the stub resolver, issues a <xref target="RFC8499" format="default"/>). A client, the stub resolver, issu
DNS query to a server, called the recursive resolver (also called caching es a
resolver or full resolver or recursive name server). Let's use the query DNS query to a server called the recursive resolver (also called caching
&quot;What are the AAAA records for www.example.com?&quot; as an example. AAA resolver, full resolver, or recursive name server). Let's use the query
A is the "What are the AAAA records for www.example.com?" as an example. AAAA is the
QTYPE (Query Type), and www.example.com is the QNAME (Query Name). (The QTYPE (Query Type), and www.example.com is the QNAME (Query Name). (The
description that follows assumes a cold cache, for instance, because the description that follows assumes a cold cache, for instance, because the
server just started.) The recursive resolver will first query the root name server just started.) The recursive resolver will first query the root name
servers. In most cases, the root name servers will send a referral. In this servers. In most cases, the root name servers will send a referral. In this
example, the referral will be to the .com name servers. The resolver repeats example, the referral will be to the .com name servers. The resolver repeats
the query to one of the .com name servers. The .com name servers, in turn, the query to one of the .com name servers. The .com name servers, in turn,
will refer to the example.com name servers. The example.com name server will will refer to the example.com name servers. The example.com name servers will
then return the answer. The root name servers, the name servers of .com, and then return the answers. The root name servers, the name servers of .com, and
the name servers of example.com are called authoritative name servers. It is the name servers of example.com are called authoritative name servers. It is
important, when analyzing the privacy issues, to remember that the question important, when analyzing the privacy issues, to remember that the question
asked to all these name servers is always the original question, not a asked to all these name servers is always the original question, not a
derived question. The question sent to the root name servers is &quot;What ar derived question. The question sent to the root name servers is "What are
e the AAAA records for www.example.com?", not "What are the name servers of
the AAAA records for www.example.com?&quot;, not &quot;What are the name serv .com?". By repeating the full question, instead of just the relevant part of
ers of
.com?&quot;. By repeating the full question, instead of just the relevant par
t of
the question to the next in line, the DNS provides more information than the question to the next in line, the DNS provides more information than
necessary to the name server. In this simplified description, recursive necessary to the name server. In this simplified description, recursive
resolvers do not implement QNAME minimization as described in <xref target="R FC7816"/>, resolvers do not implement QNAME minimization as described in <xref target="R FC7816" format="default"/>,
which will only send the relevant part of the question to the upstream name which will only send the relevant part of the question to the upstream name
server. server.
</t> </t>
<t>DNS relies heavily on caching, so the algorithm described <t>DNS relies heavily on caching, so the algorithm described
above is actually a bit more complicated, and not all questions are above is actually a bit more complicated, and not all questions are
sent to the authoritative name servers. If a few seconds later the sent to the authoritative name servers. If the
stub resolver asks the recursive resolver, &quot;What are the SRV records stub resolver asks the recursive resolver a few seconds later, "What are the
of _xmpp-server._tcp.example.com?&quot;, the recursive resolver will SRV records
of _xmpp-server._tcp.example.com?", the recursive resolver will
remember that it knows the name servers of example.com and will just remember that it knows the name servers of example.com and will just
query them, bypassing the root and .com. Because there is typically query them, bypassing the root and .com. Because there is typically
no caching in the stub resolver, the recursive resolver, unlike the no caching in the stub resolver, the recursive resolver, unlike the
authoritative servers, sees all the DNS traffic. (Applications, like authoritative servers, sees all the DNS traffic. (Applications, like
web browsers, may have some form of caching that does not follow DNS web browsers, may have some form of caching that does not follow DNS
rules, for instance, because it may ignore the TTL. So, the rules, for instance, because it may ignore the TTL. So, the
recursive resolver does not see all the name resolution activity.) recursive resolver does not see all the name resolution activity.)
</t> </t>
<t>It should be noted that DNS recursive resolvers sometimes forward <t>It should be noted that DNS recursive resolvers sometimes forward
requests to other recursive resolvers, typically bigger machines, requests to other recursive resolvers, typically bigger machines,
with a larger and more shared cache (and the query hierarchy can be with a larger and more shared cache (and the query hierarchy can be
even deeper, with more than two levels of recursive resolvers). From even deeper, with more than two levels of recursive resolvers). From
the point of view of privacy, these forwarders are like resolvers, the point of view of privacy, these forwarders are like resolvers
except that they do not see all of the requests being made (due to except that they do not see all of the requests being made (due to
caching in the first resolver). caching in the first resolver).
</t> </t>
<t>At the time of writing, almost all this DNS traffic is currently <t>At the time of writing, almost all this DNS traffic is currently
sent unencrypted. However, there is increasing deployment sent unencrypted. However, there is increasing deployment
of DNS-over-TLS (DoT) <xref target="RFC7858"/> and DNS-over-HTTPS (DoH) of DNS over TLS (DoT) <xref target="RFC7858" format="default"/> and DNS over H
<xref target="RFC8484"/>, particularly in mobile devices, browsers, and by TTPS (DoH)
<xref target="RFC8484" format="default"/>, particularly in mobile devices, bro
wsers, and by
providers of anycast recursive DNS resolution services. There are a providers of anycast recursive DNS resolution services. There are a
few cases where there is some alternative channel encryption, for few cases where there is some alternative channel encryption, for
instance, in an IPsec VPN tunnel, at least between the stub resolver and instance, in an IPsec VPN tunnel, at least between the stub resolver and
the resolver. Some recent analysis on service quality of encrypted DNS the resolver. Some recent analysis on the service quality of encrypted DNS
traffic can be found in <xref target="dns-over-encryption"/>. traffic can be found in <xref target="dns-over-encryption" format="default"/>.
</t> </t>
<t>Today, almost all DNS queries are sent over UDP <xref target="thomas-ditl-tcp "/>. This has <t>Today, almost all DNS queries are sent over UDP <xref target="thomas-di tl-tcp" format="default"/>. This has
practical consequences when considering encryption of the traffic as a practical consequences when considering encryption of the traffic as a
possible privacy technique. Some encryption solutions are only designed for possible privacy technique. Some encryption solutions are only designed for
TCP, not UDP, although new solutions are still emerging <xref target="I-D.iet TCP, not UDP, although new solutions are still emerging <xref target="RFC9000
f-quic-transport"/> " format="default"/>
<xref target="I-D.ietf-dprive-dnsoquic"/>. <xref target="I-D.ietf-dprive-dnsoquic" format="default"/>.
</t> </t>
<t>Another important point to keep in mind when analyzing the privacy <t>Another important point to keep in mind when analyzing the privacy
issues of DNS is the fact that DNS requests received by a server are issues of DNS is the fact that DNS requests received by a server are
triggered by different reasons. Let's assume an eavesdropper wants triggered for different reasons. Let's assume an eavesdropper wants
to know which web page is viewed by a user. For a typical web page, to know which web page is viewed by a user. For a typical web page,
there are three sorts of DNS requests being issued: there are three sorts of DNS requests being issued:
</t> </t>
<t> <dl newline="true">
<list style="symbols"> <dt>Primary request:</dt><dd> This is the domain name in the URL that th
<t>Primary request: this is the domain name in the URL that the user e user
typed, selected from a bookmark, or chose by clicking on an typed, selected from a bookmark, or chose by clicking on a
hyperlink. Presumably, this is what is of interest for the hyperlink. Presumably, this is what is of interest for the
eavesdropper.</t> eavesdropper.</dd>
<t>Secondary requests: these are the additional requests performed by <dt>Secondary requests:</dt><dd>These are the additional requests perfor
med by
the user agent (here, the web browser) without any direct the user agent (here, the web browser) without any direct
involvement or knowledge of the user. For the Web, they are involvement or knowledge of the user. For the Web, they are
triggered by embedded content, Cascading Style Sheets (CSS), triggered by embedded content, Cascading Style Sheets (CSS),
JavaScript code, embedded images, etc. In some cases, there can JavaScript code, embedded images, etc. In some cases, there can
be dozens of domain names in different contexts on a single web be dozens of domain names in different contexts on a single web
page.</t> page.</dd>
<t>Tertiary requests: these are the additional requests performed by
the DNS system itself. For instance, if the answer to a query is <dt>Tertiary requests:</dt><dd> These are the additional requests perfor
a referral to a set of name servers, and the glue records are not med by
returned, the resolver will have to do additional requests to turn the DNS service itself. For instance, if the answer to a query is
a referral to a set of name servers and the glue records are not
returned, the resolver will have to send additional requests to turn
the name servers' names into IP addresses. Similarly, even if the name servers' names into IP addresses. Similarly, even if
glue records are returned, a careful recursive server will do glue records are returned, a careful recursive server will send
tertiary requests to verify the IP addresses of those records.</t> tertiary requests to verify the IP addresses of those records.</dd>
</list> </dl>
</t> <t>It can also be noted that, in the case of a typical web browser, more
<t>It can also be noted that, in the case of a typical web browser, more
DNS requests than strictly necessary are sent, for instance, to DNS requests than strictly necessary are sent, for instance, to
prefetch resources that the user may query later or when prefetch resources that the user may query later or when
autocompleting the URL in the address bar. Both are a significant privacy autocompleting the URL in the address bar. Both are a significant privacy
concern since they may leak information even about non-explicit concern since they may leak information even about non-explicit
actions. For instance, just reading a local HTML page, even without actions. For instance, just reading a local HTML page, even without
selecting the hyperlinks, may trigger DNS requests. selecting the hyperlinks, may trigger DNS requests.
</t> </t>
<t>For privacy-related terms, the terminology is from <t>Privacy-related terminology is from
<xref target="RFC6973"/>. <xref target="RFC6973" format="default"/>. This document obsoletes <xref targ
et="RFC7626"/>.
</t> </t>
</section> </section>
<section anchor="scope" numbered="true" toc="default">
<section anchor="scope" title="Scope"> <name>Scope</name>
<t>This document focuses mostly on the study of privacy risks for the <t>This document focuses mostly on the study of privacy risks for the
end user (the one performing DNS requests). The risks of end user (the one performing DNS requests). The risks of
pervasive surveillance <xref target="RFC7258"/> are considered as well as ris pervasive surveillance <xref target="RFC7258" format="default"/> are consider
ks coming from a more ed as well as risks coming from a more
focused surveillance. In this document, the term 'end user' is used focused surveillance. In this document, the term "end user" is used
as defined in <xref target="RFC8890"/>. as defined in <xref target="RFC8890" format="default"/>.
</t> </t>
<t>This document does not attempt a comparison of specific privacy protections <t>This document does not attempt a comparison of specific privacy protect
provided by individual networks or organizations, it makes only general ions
provided by individual networks or organizations; it makes only general
observations about typical current practices. observations about typical current practices.
</t> </t>
<t>Privacy risks for the holder of a zone (the risk that someone gets the data) <t>Privacy risks for the holder of a zone (the risk that someone gets the
are discussed in <xref target="RFC5936"/> and <xref target="RFC5155"/>. data)
are discussed in <xref target="RFC5155" format="default"/> and <xref target="
RFC5936" format="default"/>.
</t> </t>
<t>Privacy risks for recursive operators (including access providers and <t>Privacy risks for recursive operators (including access providers and
operators in enterprise networks) such as leakage of private namespaces or operators in enterprise networks) such as leakage of private namespaces or
blocklists are out of scope for this document. blocklists are out of scope for this document.
</t> </t>
<t>Non-privacy risks (e.g security related considerations such as cache poisonin g) are <t>Non-privacy risks (e.g., security-related considerations such as cache poisoning) are
also out of scope. also out of scope.
</t> </t>
<t>The privacy risks associated with the use of other protocols that make use of <t>The privacy risks associated with the use of other protocols that make use of
DNS information are not considered here. DNS information are not considered here.
</t> </t>
</section> </section>
<section anchor="risks" numbered="true" toc="default">
<section anchor="risks" title="Risks"> <name>Risks</name>
<t>The following four sections outline the privacy considerations associated wit <t>The following four sections outline the privacy considerations associat
h ed with
different aspects of the DNS for the end user. When reading these sections it different aspects of the DNS for the end user. When reading these sections, it
needs to be kept in mind that many of the considerations (for example, recursive needs to be kept in mind that many of the considerations (for example, recursive
resolver and transport protocol) can be specific to the network context that a resolver and transport protocol) can be specific to the network context that a
device is using at a given point in time. A user may have many devices and each device is using at a given point in time. A user may have many devices, and each
device might utilize many different networks (e.g. home, work, public or device might utilize many different networks (e.g., home, work, public, or
cellular) over a period of time or even concurrently. An exhaustive analysis of cellular) over a period of time or even concurrently. An exhaustive analysis of
the privacy considerations for an individual user would need to take into the privacy considerations for an individual user would need to take into
account the set of devices used and the multiple dynamic contexts of each account the set of devices used and the multiple dynamic contexts of each
device. This document does not attempt such a complex analysis, but instead it device. This document does not attempt such a complex analysis; instead, it
presents an overview of the various considerations that could form the basis of presents an overview of the various considerations that could form the basis of
such an analysis. such an analysis.
</t> </t>
</section> </section>
<section anchor="risks-in-the-dns-data" numbered="true" toc="default">
<section anchor="risks-in-the-dns-data" title="Risks in the DNS Data"> <name>Risks in the DNS Data</name>
<section anchor="the-public-nature-of-dns-data" numbered="true" toc="defau
<section anchor="the-public-nature-of-dns-data" title="The Public Nature of DNS lt">
Data"> <name>The Public Nature of DNS Data</name>
<t>It has been stated that &quot;the data in the DNS is public&quot;. This sent <t>It has been stated that "the data in the DNS is public". This senten
ence ce
makes sense for an Internet-wide lookup system, and there makes sense for an Internet-wide lookup system, and there
are multiple facets to the data and metadata involved that deserve a are multiple facets to the data and metadata involved that deserve a
more detailed look. First, access control lists (ACLs) and private more detailed look. First, access control lists (ACLs) and private
namespaces notwithstanding, the DNS operates under the assumption namespaces notwithstanding, the DNS operates under the assumption
that public-facing authoritative name servers will respond to &quot;usual&quo that public-facing authoritative name servers will respond to "usual"
t; DNS queries for any zone they are authoritative for, without further
DNS queries for any zone they are authoritative for without further
authentication or authorization of the client (resolver). Due to the authentication or authorization of the client (resolver). Due to the
lack of search capabilities, only a given QNAME will reveal the lack of search capabilities, only a given QNAME will reveal the
resource records associated with that name (or that name's non- resource records associated with that name (or that name's nonexistence). In
existence). In other words: one needs to know what to ask for, in other words: one needs to know what to ask for in
order to receive a response. There are many ways in which supposedly &quot;pr order to receive a response. There are many ways in which supposedly "private
ivate&quot; "
resources currently leak. A few examples are DNSSEC NSEC zone walking<xref resources currently leak. A few examples are DNSSEC NSEC zone walking <xref t
target="RFC4470"/>; arget="RFC4470" format="default"/>,
passive-DNS services[passive-dns]; etc. The zone transfer QTYPE <xref target= passive DNS services <xref target="passive-dns"/>, etc. The zone transfer QTY
"RFC5936"/> is PE <xref target="RFC5936" format="default"/> is
often blocked or restricted to authenticated/authorized access to often blocked or restricted to authenticated/authorized access to
enforce this difference (and maybe for other reasons). enforce this difference (and maybe for other reasons).
</t> </t>
<t>Another difference between the DNS data and a particular DNS transaction <t>Another difference between the DNS data and a particular DNS
(i.e., a DNS name lookup). DNS transaction (i.e., a DNS name lookup): DNS data and the results of a
data and the results of a DNS query are public, within the boundaries DNS query are public, within the boundaries described above, and may
described above, and may not have any confidentiality requirements. not have any confidentiality requirements. However, the same is not
However, the same is not true of a single transaction or a sequence of true of a single transaction or a sequence of transactions; those
transactions; those transactions are not / should not be public. A single transactions are not / should not be public. A single transaction
transaction reveals both the originator of the query and the query contents reveals both the originator of the query and the query contents; this
which potentially leaks sensitive information about a specific user. A potentially leaks sensitive information about a specific user. A
typical example from outside the DNS world is: the web site of Alcoholics typical example from outside the DNS world is that the website of Alcoholics
Anonymous is public; the fact that you visit it should not be. Furthermore, Anonymous is public but the fact that you visit it should not be. Furthermore,
the ability to link queries reveals information about individual use the ability to link queries reveals information about individual use
patterns. patterns.
</t> </t>
</section> </section>
<section anchor="data-in-the-dns-request" numbered="true" toc="default">
<section anchor="data-in-the-dns-request" title="Data in the DNS Request"> <name>Data in the DNS Request</name>
<t>The DNS request includes many fields, but two of them seem particularly <t>The DNS request includes many fields, but two of them seem particular
ly
relevant for the privacy issues: the QNAME and the source IP address. relevant for the privacy issues: the QNAME and the source IP address.
&quot;source IP address&quot; is used in a loose sense of &quot;source IP add ress + maybe "Source IP address" is used in a loose sense of "source IP address + maybe
source source
port number&quot;, because the port number is also in the request and can be used to port number", because the port number is also in the request and can be used to
differentiate between several users sharing an IP address (behind a differentiate between several users sharing an IP address (behind a
Carrier-Grade NAT (CGN), for instance <xref target="RFC6269"/>). Carrier-Grade NAT (CGN), for instance <xref target="RFC6269" format="default" />).
</t> </t>
<t>The QNAME is the full name sent by the user. It gives information
about what the user does (&quot;What are the MX records of example.net?&quot; <t>The QNAME is the full name sent by the user. It gives information
means he probably wants to send email to someone at example.net, about what the user does ("What are the MX records of example.net?"
means they probably want to send email to someone at example.net,
which may be a domain used by only a few persons and is therefore which may be a domain used by only a few persons and is therefore
very revealing about communication relationships). Some QNAMEs are very revealing about communication relationships). Some QNAMEs are
more sensitive than others. For instance, querying the A record of a more sensitive than others. For instance, querying the A record of a
well-known web statistics domain reveals very little (everybody well-known web statistics domain reveals very little (everybody
visits web sites that use this analytics service), but querying the A visits websites that use this analytics service), but querying the A
record of www.verybad.example where verybad.example is the domain of record of www.verybad.example where verybad.example is the domain of
an organization that some people find offensive or objectionable may an organization that some people find offensive or objectionable may
create more problems for the user. Also, sometimes, the QNAME embeds create more problems for the user. Also, sometimes, the QNAME embeds
the software one uses, which could be a privacy issue. For instance, the software one uses, which could be a privacy issue (for instance,
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
There are also some BitTorrent clients that query an SRV record for There are also some BitTorrent clients that query an SRV record for
_bittorrent-tracker._tcp.domain.example. _bittorrent-tracker._tcp.domain.example.
</t> </t>
<t>Another important thing about the privacy of the QNAME is the future
<t>Another important thing about the privacy of the QNAME is future
usages. Today, the lack of privacy is an obstacle to putting usages. Today, the lack of privacy is an obstacle to putting
potentially sensitive or personally identifiable data in the DNS. At potentially sensitive or personally identifiable data in the DNS. At
the moment, your DNS traffic might reveal that you are doing email the moment, your DNS traffic might reveal that you are exchanging emails but
but not with whom. If your Mail User Agent (MUA) starts looking up not with whom. If your Mail User Agent (MUA) starts looking up
Pretty Good Privacy (PGP) keys in the DNS <xref target="RFC7929"/>, then Pretty Good Privacy (PGP) keys in the DNS <xref target="RFC7929" format="defa
ult"/>, then
privacy becomes a lot more important. And email is just an example; privacy becomes a lot more important. And email is just an example;
there would be other really interesting uses for a more privacy-friendly DNS. there would be other really interesting uses for a more privacy-friendly DNS.
</t> </t>
<t>For the communication between the stub resolver and the recursive resolver,
<t>For the communication between the stub resolver and the recursive res
olver,
the source IP address is the address of the user's machine. Therefore, all the source IP address is the address of the user's machine. Therefore, all
the issues and warnings about collection of IP addresses apply here. For the the issues and warnings about collection of IP addresses apply here. For the
communication between the recursive resolver and the authoritative name communication between the recursive resolver and the authoritative name
servers, the source IP address has a different meaning; it does not have the servers, the source IP address has a different meaning; it does not have the
same status as the source address in an HTTP connection. It can be typically same status as the source address in an HTTP connection. It is typically the
the IP address of the recursive resolver that, in a way, "hides" the real user.
IP address of the recursive resolver that, in a way, &quot;hides&quot; the re
al user. However, hiding does not always work. The edns-client-subnet (ECS) EDNS0 opti
However, hiding does not always work. Sometimes EDNS(0) Client subnet on <xref target="RFC7871" format="default"/> is sometimes used (see one privacy
<xref target="RFC7871"/> is used (see one privacy analysis in <xref target="d analysis in <xref target="denis-edns-client-subnet" format="default"/>).
enis-edns-client-subnet"/>).
Sometimes the end user has a personal recursive resolver on their machine. Sometimes the end user has a personal recursive resolver on their machine.
In both cases, the IP address originating queries to the authoritative server In both cases, the IP address originating queries to the authoritative server
is as sensitive as it is for HTTP <xref target="sidn-entrada"/>. is as sensitive as it is for HTTP <xref target="sidn-entrada" format="default "/>.
</t> </t>
<t>A note about IP addresses: there is currently no IETF document that describes <t>A note about IP addresses: there is currently no IETF document that d escribes
in detail all the privacy issues around IP addressing in general, although in detail all the privacy issues around IP addressing in general, although
<xref target="RFC7721"/> does discuss privacy considerations for IPv6 address generation <xref target="RFC7721" format="default"/> does discuss privacy considerations for IPv6 address generation
mechanisms. In the meantime, the discussion here is intended to include both mechanisms. In the meantime, the discussion here is intended to include both
IPv4 and IPv6 source addresses. For a number of reasons, their assignment and IPv4 and IPv6 source addresses. For a number of reasons, their assignment and
utilization characteristics are different, which may have implications for utilization characteristics are different, which may have implications for
details of information leakage associated with the collection of source details of information leakage associated with the collection of source
addresses. (For example, a specific IPv6 source address seen on the public addresses. (For example, a specific IPv6 source address seen on the public
Internet is less likely than an IPv4 address to originate behind an address Internet is less likely than an IPv4 address to originate behind an address-s
sharing scheme.) However, for both IPv4 and IPv6 addresses, it is important haring scheme.) However, for both IPv4 and IPv6 addresses, it is
to note that source addresses are propagated with queries via EDNS(0) important to note that source addresses are propagated with queries
Client subnet and comprise via the ECS option and comprise metadata about the host, user,
metadata about the host, user, or application that originated them. or application that originated them.
</t> </t>
<section anchor="data-in-the-dns-payload" numbered="true" toc="default">
<section anchor="data-in-the-dns-payload" title="Data in the DNS Payload"> <name>Data in the DNS Payload</name>
<t>At the time of writing there are no standardized client identifiers contained <t>At the time of writing, there are no standardized client identifier
in s contained in
the DNS payload itself (ECS <xref target="RFC7871"/> while widely used is only o the DNS payload itself (ECS, as described in <xref target="RFC7871" format="defa
f Category ult"/>, is widely used; however, <xref target="RFC7871" format="default"/> is on
Informational). ly an Informational RFC).
</t> </t>
<t>DNS Cookies <xref target="RFC7873"/> are a lightweight DNS transaction securi ty mechanism that <t>DNS Cookies <xref target="RFC7873" format="default"/> are a lightwe ight DNS transaction security mechanism that
provides limited protection against a variety of increasingly common provides limited protection against a variety of increasingly common
denial-of-service and amplification/forgery or cache poisoning attacks by denial-of-service and amplification/forgery or cache poisoning attacks by
off-path attackers. It is noted, however, that they are designed to just verify off-path attackers. It is noted, however, that they are designed to just verify
IP addresses (and should change once a client's IP address changes), but they ar e IP addresses (and should change once a client's IP address changes), but they ar e
not designed to actively track users (like HTTP cookies). not designed to actively track users (like HTTP cookies).
</t> </t>
<t>There are anecdotal accounts of <eref target="https://lists.dns-oarc.net/pipe <t>There are anecdotal accounts of <eref target="https://lists.dns-oar
rmail/dns-operations/2016-January/014143.html">MAC c.net/pipermail/dns-operations/2016-January/014143.html">Media Access Control (M
addresses</eref> AC) addresses</eref>
and even user names being inserted in non-standard EDNS(0) options <xref target= and even user names being inserted in nonstandard EDNS(0) options <xref target="
"RFC6891"/> RFC6891" format="default"/>
for stub to resolver communications to support proprietary functionality for stub-to-resolver communications to support proprietary functionality
implemented at the resolver (e.g., parental filtering). implemented at the resolver (e.g., parental filtering).
</t> </t>
</section> </section>
</section> </section>
<section anchor="cache-snooping" numbered="true" toc="default">
<section anchor="cache-snooping" title="Cache Snooping"> <name>Cache Snooping</name>
<t>The content of recursive resolvers' caches can reveal data about the <t>The content of recursive resolvers' caches can reveal data about the
clients using it (the privacy risks depend on the number of clients). clients using it (the privacy risks depend on the number of clients).
This information can sometimes be examined by sending DNS queries This information can sometimes be examined by sending DNS queries
with RD=0 to inspect cache content, particularly looking at the DNS with RD=0 to inspect cache content, particularly looking at the DNS
TTLs <xref target="grangeia.snooping"/>. Since this also is a reconnaissance TTLs <xref target="grangeia.snooping" format="default"/>. Since this also is
technique for subsequent cache poisoning attacks, some counter a reconnaissance
measures have already been developed and deployed <xref target="cache-snoopin technique for subsequent cache poisoning attacks, some countermeasures have a
g-defence"/>. lready been developed and deployed <xref target="cache-snooping-defence" format=
"default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="risks-on-the-wire" numbered="true" toc="default">
<section anchor="risks-on-the-wire" title="Risks On the Wire"> <name>Risks on the Wire</name>
<section anchor="unencrypted-transports" numbered="true" toc="default">
<name>Unencrypted Transports</name>
<section anchor="unencrypted-transports" title="Unencrypted Transports"> <t>For unencrypted transports, DNS traffic can be seen by an eavesdroppe
<t>For unencrypted transports, DNS traffic can be seen by an eavesdropper like r like
any other traffic. (DNSSEC, specified in <xref target="RFC4033"/>, explicitly any other traffic. (DNSSEC, specified in <xref target="RFC4033" format="defau
excludes lt"/>, explicitly excludes
confidentiality from its goals.) So, if an initiator starts an HTTPS confidentiality from its goals.) So, if an initiator starts an HTTPS
communication with a recipient, while the HTTP traffic will be encrypted, the communication with a recipient, the HTTP traffic will be encrypted, but the
DNS exchange prior to it will not be. When other protocols will become more DNS exchange prior to it will not be. When other protocols become more
and more privacy-aware and secured against surveillance (e.g., <xref target=" and more privacy aware and secured against surveillance (e.g., <xref target="
RFC8446"/>, RFC8446" format="default"/>,
<xref target="I-D.ietf-quic-transport"/>), the use of unencrypted transports <xref target="RFC9000" format="default"/>), the use of unencrypted transports
for DNS may for DNS may
become &quot;the weakest link&quot; in privacy. It is noted that at the time become "the weakest link" in privacy. It is noted that, at the time of writin
of writing g,
there is on-going work attempting to encrypt the SNI in the TLS handshake there is ongoing work attempting to encrypt the Server Name Identification (S
<xref target="RFC8744"/>, which is one of the NI) in the TLS handshake
<xref target="RFC8744" format="default"/>, which is one of the
last remaining non-DNS cleartext identifiers of a connection target. last remaining non-DNS cleartext identifiers of a connection target.
</t> </t>
<t>An important specificity of the DNS traffic is that it may take a <t>An important specificity of the DNS traffic is that it may take a
different path than the communication between the initiator and the different path than the communication between the initiator and the
recipient. For instance, an eavesdropper may be unable to tap the recipient. For instance, an eavesdropper may be unable to tap the
wire between the initiator and the recipient but may have access to wire between the initiator and the recipient but may have access to
the wire going to the recursive resolver, or to the authoritative the wire going to the recursive resolver or to the authoritative
name servers. name servers.
</t> </t>
<t>The best place to tap, from an eavesdropper's point of view, is <t>The best place to tap, from an eavesdropper's point of view, is
clearly between the stub resolvers and the recursive resolvers, clearly between the stub resolvers and the recursive resolvers,
because traffic is not limited by DNS caching. because traffic is not limited by DNS caching.
</t> </t>
<t>The attack surface between the stub resolver and the rest of the <t>The attack surface between the stub resolver and the rest of the
world can vary widely depending upon how the end user's device is world can vary widely depending upon how the end user's device is
configured. By order of increasing attack surface: configured. By order of increasing attack surface:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>The recursive resolver can be on the end user's device. In (curre
<t>The recursive resolver can be on the end user's device. In ntly) a small number of cases, individuals may choose to
(currently) a small number of cases, individuals may choose to
operate their own DNS resolver on their local machine. In this operate their own DNS resolver on their local machine. In this
case, the attack surface for the connection between the stub case, the attack surface for the connection between the stub
resolver and the caching resolver is limited to that single resolver and the caching resolver is limited to that single
machine. The recursive resolver will expose data to authoritative machine. The recursive resolver will expose data to authoritative
resolvers as discussed in <xref target="in-the-authoritative-name-servers"/>.</t resolvers as discussed in <xref target="in-the-authoritative-name-servers" forma
> t="default"/>.</li>
<t>The recursive resolver may be at the local network edge. For <li>The recursive resolver may be at the local network edge. For
many/most enterprise networks and for some residential networks, the many/most enterprise networks and for some residential networks, the
caching resolver may exist on a server at the edge of the local caching resolver may exist on a server at the edge of the local
network. In this case, the attack surface is the local network. network. In this case, the attack surface is the local network.
Note that in large enterprise networks, the DNS resolver may not Note that in large enterprise networks, the DNS resolver may not
be located at the edge of the local network but rather at the edge be located at the edge of the local network but rather at the edge
of the overall enterprise network. In this case, the enterprise of the overall enterprise network. In this case, the enterprise
network could be thought of as similar to the Internet Access network could be thought of as similar to the Internet Access
Provider (IAP) network referenced below.</t> Provider (IAP) network referenced below.</li>
<t>The recursive resolver can be in the IAP network. For most residential
<li>The recursive resolver can be in the IAP network. For most residen
tial
networks and potentially other networks, the typical case is for the networks and potentially other networks, the typical case is for the
user's device to be configured (typically automatically through DHCP or user's device to be configured (typically automatically through DHCP or
RA options) with the addresses of the DNS proxy in the Customer relay agent options) with the addresses of the DNS proxy in the Customer
Premise Equipment (CPE), which in turns Premises Equipment (CPE), which in turn
points to the DNS recursive resolvers at the IAP. The attack surface for points to the DNS recursive resolvers at the IAP. The attack surface for
on-the-wire attacks is therefore from the end user system across the on-the-wire attacks is therefore from the end user system across the
local network and across the IAP network to the IAP's recursive resolvers.</t> local network and across the IAP network to the IAP's recursive resolvers.</li>
<t>The recursive resolver can be a public DNS service (or a privately run DNS <li>The recursive resolver can be a public DNS service (or a privately
resolver hosted on the public internet). Some machines run DNS
resolver hosted on the public Internet). Some machines
may be configured to use public DNS resolvers such as those may be configured to use public DNS resolvers such as those
operated by Google Public DNS or OpenDNS. The user may operated by Google Public DNS or OpenDNS. The user may
have configured their machine to use these DNS recursive resolvers have configured their machine to use these DNS recursive resolvers
themselves -- or their IAP may have chosen to use the public DNS themselves -- or their IAP may have chosen to use the public DNS
resolvers rather than operating their own resolvers. In this resolvers rather than operating their own resolvers. In this
case, the attack surface is the entire public Internet between the case, the attack surface is the entire public Internet between the
user's connection and the public DNS service. It can be noted that if the user's connection and the public DNS service. It can be noted that if the
user selects a single resolver with a small client population (even when using user selects a single resolver with a small client population (even when using
an encrypted transport) it can actually serve to aid tracking of that user as an encrypted transport), it can actually serve to aid tracking of that user as
they move across network environments.</t> they move across network environments.</li>
</list> </ul>
</t> <t>It is also noted that, typically, a device connected <em>only</em> to
<t>It is also noted that typically a device connected <spanx style="emph">only</ a modern cellular
spanx> to a modern cellular
network is network is
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>directly configured with only the recursive resolvers of the IAP a
<t>directly configured with only the recursive resolvers of the IAP and</t> nd</li>
<t>afforded some level of protection against some types of eavesdropping <li>
<t>afforded some level of protection against some types of eavesdrop
ping
for all traffic (including DNS traffic) due to the cellular network for all traffic (including DNS traffic) due to the cellular network
link-layer encryption. link-layer encryption.
<vspace/></t>
</list>
</t> </t>
<t>The attack surface for this specific scenario is not considered here.
</t>
</section>
<section anchor="encrypted-transports" title="Encrypted Transports"> </li>
<t>The use of encrypted transports directly mitigates passive surveillance of th </ul>
e <t>The attack surface for this specific scenario is not considered here.
DNS payload, however there are still some privacy attacks possible. This section </t>
</section>
<section anchor="encrypted-transports" numbered="true" toc="default">
<name>Encrypted Transports</name>
<t>The use of encrypted transports directly mitigates passive surveillan
ce of the
DNS payload; however, some privacy attacks are still possible. This section
enumerates the residual privacy risks to an end user when an attacker can enumerates the residual privacy risks to an end user when an attacker can
passively monitor encrypted DNS traffic flows on the wire. passively monitor encrypted DNS traffic flows on the wire.
</t> </t>
<t>These are cases where user identification, fingerprinting or correlations may <t>These are cases where user identification, fingerprinting, or correla
be tions may be
possible due to the use of certain transport layers or clear text/observable possible due to the use of certain transport layers or cleartext/observable
features. These issues are not specific to DNS, but DNS traffic is susceptible features. These issues are not specific to DNS, but DNS traffic is susceptible
to these attacks when using specific transports. to these attacks when using specific transports.
</t> </t>
<t>There are some general examples, for example, certain studies have highlighte
d <t>Some general examples exist; for example, certain studies highlight
that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes that the <eref target="http://netres.ec/?b=11B99BD">OS fingerprint values</eref>
<eref target="http://netres.ec/?b=11B99BD">os-fingerprint</eref> of IPv4 TTL, IPv6 Hop Limit, or TCP Window size can be used to fingerprint clie
values can be used to fingerprint client OS's or that various techniques can be nt OSes or that various techniques can be
used to de-NAT DNS queries used to de-NAT DNS queries <xref target="dns-de-nat"/>.
[dns-de-nat].
</t> </t>
<t>Note that even when using encrypted transports, the use of clear text transpo <t>Note that even when using encrypted transports, the use of cleartext
rt transport
options to decrease latency can provide correlation of a users' connections, options to decrease latency can provide correlation of a user's connections,
e.g. using TCP Fast Open <xref target="RFC7413"/>. e.g., using TCP Fast Open <xref target="RFC7413" format="default"/>.
</t> </t>
<t>Implementations that support encrypted transports also commonly re-use <t>Implementations that support encrypted transports also commonly reuse
connections for multiple DNS queries to optimize performance (e.g. via DNS connections for multiple DNS queries to optimize performance (e.g., via DNS
pipelining or HTTPS multiplexing). Default configuration options for encrypted pipelining or HTTPS multiplexing). Default configuration options for encrypted
transports could in principle fingerprint a specific client application. For transports could, in principle, fingerprint a specific client application.
For
example: example:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>TLS version or cipher suite selection</li>
<t>TLS version or cipher suite selection</t> <li>session resumption</li>
<t>session resumption</t> <li>the maximum number of messages to send and</li>
<t>the maximum number of messages to send or</t> <li>a maximum connection time before closing a connections and reopeni
<t>a maximum connection time before closing a connections and re-opening.</t> ng.</li>
</list> </ul>
</t> <t>If libraries or applications offer user configuration of such options
<t>If libraries or applications offer user configuration of such options (e.g. (e.g.,
<xref target="getdns"/>) then they could in principle help to identify a specifi <xref target="getdns" format="default"/>), then they could, in principle, help t
c user. Users o identify a specific user. Users
may want to use only the defaults to avoid this issue. may want to use only the defaults to avoid this issue.
</t> </t>
<t>Whilst there are known attacks on older versions of TLS, the most recent <t>While there are known attacks on older versions of TLS, the most rece
recommendations <xref target="RFC7525"/> and the development of TLS 1.3 <xref ta nt
rget="RFC8446"/> largely recommendations <xref target="RFC7525" format="default"/> and the development of
TLS 1.3 <xref target="RFC8446" format="default"/> largely
mitigate those. mitigate those.
</t> </t>
<t>Traffic analysis of unpadded encrypted traffic is also possible <t>Traffic analysis of unpadded encrypted traffic is also possible
<xref target="pitfalls-of-dns-encryption"/> because the sizes and timing of encr <xref target="pitfalls-of-dns-encryption" format="default"/> because the sizes a
ypted DNS nd timing of encrypted DNS
requests and responses can be correlated to unencrypted DNS requests upstream requests and responses can be correlated to unencrypted DNS requests upstream
of a recursive resolver. of a recursive resolver.
</t> </t>
</section> </section>
</section> </section>
<section anchor="risks-in-the-servers" numbered="true" toc="default">
<section anchor="risks-in-the-servers" title="Risks in the Servers"> <name>Risks in the Servers</name>
<t>Using the terminology of <xref target="RFC6973"/>, the DNS servers (recursive <t>Using the terminology of <xref target="RFC6973" format="default"/>, the
resolvers and authoritative servers) are enablers: they facilitate DNS servers (recursive
resolvers and authoritative servers) are enablers: "they facilitate
communication between an initiator and a recipient without being communication between an initiator and a recipient without being
directly in the communications path. As a result, they are often directly in the communications path". As a result, they are often
forgotten in risk analysis. But, to quote again <xref target="RFC6973"/>, &q forgotten in risk analysis. But, to quote <xref target="RFC6973" format="def
uot;Although ault"/> again, "Although
[...] enablers may not generally be considered as attackers, they may [...] enablers may not generally be considered as attackers, they may
all pose privacy threats (depending on the context) because they are all pose privacy threats (depending on the context) because they are
able to observe, collect, process, and transfer privacy-relevant able to observe, collect, process, and transfer privacy-relevant
data.&quot; In <xref target="RFC6973"/> parlance, enablers become observers when they data". In <xref target="RFC6973" format="default"/> parlance, enablers becom e observers when they
start collecting data. start collecting data.
</t> </t>
<t>Many programs exist to collect and analyze DNS data at the servers -- from <t>Many programs exist to collect and analyze DNS data at the servers -- f
the &quot;query log&quot; of some programs like BIND to tcpdump and more soph rom
isticated the "query log" of some programs like BIND to tcpdump and more sophisticated
programs like PacketQ <xref target="packetq"/> and DNSmezzo <xref target="dns programs like PacketQ <xref target="packetq" format="default"/> and DNSmezzo
mezzo"/>. The <xref target="dnsmezzo" format="default"/>. The
organization managing the DNS server can use this data itself, or it can be organization managing the DNS server can use this data itself, or it can be
part of a surveillance program like PRISM <xref target="prism"/> and pass dat a to an part of a surveillance program like PRISM <xref target="prism" format="defaul t"/> and pass data to an
outside observer. outside observer.
</t> </t>
<t>Sometimes, this data is kept for a long time and/or distributed to <t>Sometimes this data is kept for a long time and/or distributed to
third parties for research purposes <xref target="ditl"/> <xref target="day-a third parties for research purposes <xref target="ditl" format="default"/> <x
t-root"/>, security ref target="day-at-root" format="default"/>, security
analysis, or surveillance tasks. These uses are sometimes under some analysis, or surveillance tasks. These uses are sometimes under some
sort of contract, with various limitations, for instance, on sort of contract, with various limitations, for instance, on
redistribution, given the sensitive nature of the data. Also, there redistribution, given the sensitive nature of the data. Also, there
are observation points in the network that gather DNS data and then are observation points in the network that gather DNS data and then
make it accessible to third parties for research or security purposes make it accessible to third parties for research or security purposes
(&quot;passive DNS&quot; <xref target="passive-dns"/>). ("passive DNS" <xref target="passive-dns" format="default"/>).
</t> </t>
<section anchor="in-the-recursive-resolvers" numbered="true" toc="default"
<section anchor="in-the-recursive-resolvers" title="In the Recursive Resolvers"> >
<t>Recursive Resolvers see all the traffic since there is typically no <name>In the Recursive Resolvers</name>
<t>Recursive resolvers see all the traffic since there is typically no
caching before them. To summarize: your recursive resolver knows a caching before them. To summarize: your recursive resolver knows a
lot about you. The resolver of a large IAP, or a large public lot about you. The resolver of a large IAP, or a large public
resolver, can collect data from many users. resolver, can collect data from many users.
</t> </t>
<section anchor="resolver-selection" numbered="true" toc="default">
<section anchor="resolver-selection" title="Resolver Selection"> <name>Resolver Selection</name>
<t>Given all the above considerations, the choice of recursive resolver has <t>Given all the above considerations, the choice of recursive resolve
r has
direct privacy considerations for end users. Historically, end user devices direct privacy considerations for end users. Historically, end user devices
have used the DHCP-provided local network recursive resolver. The choice by a have used the DHCP-provided local network recursive resolver. The choice by a
user to join a particular network (e.g. by physically plugging in a cable or user to join a particular network (e.g., by physically plugging in a cable or
selecting a network in a OS dialogue) typically updates a number of system selecting a network in an OS dialogue) typically updates a number of system
resources - these can include IP addresses, availability of IPv4/IPv6, DHCP resources -- these can include IP addresses, the availability of IPv4/IPv6, DH
CP
server, and DNS resolver. These individual changes, including the change in server, and DNS resolver. These individual changes, including the change in
DNS resolver, are not normally communicated directly to the user by the OS DNS resolver, are not normally communicated directly to the user by the OS
when the network is joined. The choice of network has historically determined when the network is joined. The choice of network has historically determined
the default system DNS resolver selection; the two are directly coupled in the default system DNS resolver selection; the two are directly coupled in
this model. this model.
</t> </t>
<t>The vast majority of users do not change their default system DNS settings <t>The vast majority of users do not change their default system DNS s
and so implicitly accept the network settings for DNS. The network resolvers ettings
and so implicitly accept the network settings for the DNS. The network resolve
rs
have therefore historically been the sole destination for all of the DNS have therefore historically been the sole destination for all of the DNS
queries from a device. These resolvers may have varied queries from a device. These resolvers may have varied
privacy policies depending on the network. Privacy policies for these servers privacy policies depending on the network. Privacy policies for these servers
may or may not be available and users need to be aware that privacy may or may not be available, and users need to be aware that privacy
guarantees will vary with the network. guarantees will vary with the network.
</t> </t>
<t>All major OS’s expose the system DNS settings and allow users to manually <t>All major OSes expose the system DNS settings and allow users to ma nually
override them if desired. override them if desired.
</t> </t>
<t>More recently, some networks and users have actively chosen <t>More recently, some networks and users have actively chosen
to use a large public resolver, e.g., <eref target="https://developers.google .com/speed/public-dns">Google Public to use a large public resolver, e.g., <eref target="https://developers.google .com/speed/public-dns">Google Public
DNS</eref>, DNS</eref>,
<eref target="https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/"> Cloudflare</eref>, <eref target="https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/"> Cloudflare</eref>,
or <eref target="https://www.quad9.net">Quad9</eref>. There can be many reaso ns: cost or <eref target="https://www.quad9.net">Quad9</eref>. There can be many reaso ns: cost
considerations for network operators, better reliability or anti-censorship considerations for network operators, better reliability, or anti-censorship
considerations are just a few. Such services typically do provide a privacy considerations are just a few. Such services typically do provide a privacy
policy and the user can get an idea of the data collected by such policy, and the user can get an idea of the data collected by such
operators by reading one e.g., <eref target="https://developers.google.com/sp operators by reading one, e.g., <eref target="https://developers.google.com/s
eed/public-dns/privacy">Google Public DNS - Your peed/public-dns/privacy">Google Public DNS - Your
Privacy</eref>. Privacy</eref>.
</t> </t>
<t>In general, as with many other protocols, issues around centralization also <t>In general, as with many other protocols, issues around centralizat
arise with DNS. The picture is fluid with several competing factors ion also
contributing which can also vary by geographic region. These include: arise with DNS.
</t>
<t> The picture is fluid with several competing factors
<list style="symbols"> contributing, where these factors can also vary by geographic region. These i
<t>ISP outsourcing, including to third party and public resolvers</t> nclude:
<t>regional market domination by one or only a few ISPs</t>
<t>applications directing DNS traffic by default to a limited subset of resolver
s, see <xref target="applicationspecific-resolver-selection"/></t>
</list>
</t> </t>
<t>An increased proportion of the global DNS resolution traffic being served by <ul spacing="normal">
<li>ISP outsourcing, including to third-party and public resolvers</
li>
<li>regional market domination by one or only a few ISPs</li>
<li>applications directing DNS traffic by default to a limited subse
t of resolvers (see <xref target="applicationspecific-resolver-selection" format
="default"/>)</li>
</ul>
<t>An increased proportion of the global DNS resolution traffic being
served by
only a few entities means that the privacy considerations for users are only a few entities means that the privacy considerations for users are
highly dependent on the privacy policies and practices of those highly dependent on the privacy policies and practices of those
entities. Many of the issues around centralization are discussed in entities. Many of the issues around centralization are discussed in
<xref target="centralisation-and-data-sovereignty"/>. <xref target="centralisation-and-data-sovereignty" format="default"/>.
</t> </t>
<section anchor="dynamic-discovery-of-doh-and-strict-dot" numbered="tr
<section anchor="dynamic-discovery-of-doh-and-strict-dot" title="Dynamic Discove ue" toc="default">
ry of DoH and Strict DoT"> <name>Dynamic Discovery of DoH and Strict DoT</name>
<t>Whilst support for opportunistic DoT can be determined by probing a resolver <t>While support for opportunistic DoT can be determined by probing
on a resolver on
port 853, there is currently no standardized discovery mechanism for DoH and port 853, there is currently no standardized discovery mechanism for DoH and
Strict DoT servers. Strict DoT servers.
</t> </t>
<t>This means that clients which might want to dynamically discover such encrypt ed <t>This means that clients that might want to dynamically discover s uch encrypted
services, and where users are willing to trust such services, are not able to do services, and where users are willing to trust such services, are not able to do
so. At the time of writing, efforts to provide standardized signaling mechanisms so. At the time of writing, efforts to provide standardized signaling mechanisms
to discover the services offered by local resolvers are in progress to discover the services offered by local resolvers are in progress
<xref target="I-D.ietf-dnsop-resolver-information"/>. Note that an increasing nu <xref target="I-D.ietf-dnsop-resolver-information" format="default"/>. Note that
mbers of ISPs an increasing number of ISPs
are deploying encrypted DNS, for example see the Encrypted DNS Deployment are deploying encrypted DNS; for example, see the Encrypted DNS Deployment
Initiative <xref target="EDDI"/>. Initiative <xref target="EDDI" format="default"/>.
</t> </t>
</section> </section>
<section anchor="applicationspecific-resolver-selection" numbered="tru
<section anchor="applicationspecific-resolver-selection" title="Application-spec e" toc="default">
ific Resolver Selection"> <name>Application-Specific Resolver Selection</name>
<t>An increasing number of applications are offering application- <t>An increasing number of applications are offering application-spe
specific encrypted DNS resolution settings, rather than defaulting to cific encrypted DNS resolution settings, rather than defaulting to
using only the system resolver. A variety of heuristics and using only the system resolver. A variety of heuristics and
resolvers are available in different applications including hard- resolvers are available in different applications, including hard-coded lists
coded lists of recognized DoH/DoT servers. of recognized DoH/DoT servers.
</t> </t>
<t>Generally, users are not aware of application specific DNS settings, and may <t>Generally, users are not aware of application-specific DNS settin gs and may
not have control over those settings. To address these limitations, users not have control over those settings. To address these limitations, users
will only be aware of and have the ability to control such settings if will only be aware of and have the ability to control such settings if
applications provide the following functions: applications provide the following functions:
</t> </t>
<t>o communicate clearly to users the change when the default application <ul empty="false">
resolver changes away from the system resolver <li>communicate the change clearly to users when the default applica
</t> tion
<t>o provide configuration options to change the default resolver changes away from the system resolver</li>
<li>provide configuration options to change the default
application resolver, including a choice to always use the system resolver application resolver, including a choice to always use the system resolver
</t> </li>
<t>o provide mechanisms for users to locally inspect, selectively forward, <li>provide mechanisms for users to locally inspect, selectively for
ward,
and filter queries (either via the application itself or use of the and filter queries (either via the application itself or use of the
system resolver) system resolver)
</t> </li></ul>
<t>Application-specific changes to default destinations for users' DNS <t>Application-specific changes to default destinations for users' D
queries might increase or decrease user privacy - it is highly NS
queries might increase or decrease user privacy; it is highly
dependent on the network context and the application-specific dependent on the network context and the application-specific
default. This is an area of active debate and the IETF is working on default. This is an area of active debate, and the IETF is working on
a number of issues related to application-specific DNS settings. a number of issues related to application-specific DNS settings.
</t> </t>
</section> </section>
</section> </section>
<section anchor="active-attacks-on-resolver-configuration" numbered="tru
<section anchor="active-attacks-on-resolver-configuration" title="Active Attacks e" toc="default">
on Resolver Configuration"> <name>Active Attacks on Resolver Configuration</name>
<t>The previous section discussed DNS privacy, assuming that all the traffic <t>The previous section discussed DNS privacy, assuming that all the t
was directed to the intended servers (i.e those that would be used in the raffic
was directed to the intended servers (i.e., those that would be used in the
absence of an active attack) and that the potential attacker was purely absence of an active attack) and that the potential attacker was purely
passive. But, in reality, there can be active attackers in the network. passive. But, in reality, there can be active attackers in the network.
</t> </t>
<t>The Internet Threat model, as described in <xref target="RFC3552"/>, assumes that the attacker <t>The Internet Threat model, as described in <xref target="RFC3552" f ormat="default"/>, assumes that the attacker
controls the network. Such an attacker can completely control any insecure DNS controls the network. Such an attacker can completely control any insecure DNS
resolution, both passively monitoring the queries and responses and substituti ng resolution, both passively monitoring the queries and responses and substituti ng
their own responses. Even if encrypted DNS such as DoH or DoT is used, unless their own responses. Even if encrypted DNS such as DoH or DoT is used, unless
the client has been configured in a secure way with the server identity, an the client has been configured in a secure way with the server identity, an ac
active attacker can impersonate the server. This implies that opportunistic tive attacker can impersonate the server. This implies that opportunistic
modes of DoH/DoT as well as modes where the client learns of the DoH/DoT serve r modes of DoH/DoT as well as modes where the client learns of the DoH/DoT serve r
via in-network mechanisms such as DHCP are vulnerable to attack. In addition, if via in-network mechanisms such as DHCP are vulnerable to attack. In addition, if
the client is compromised, the attacker can replace the DNS configuration with the client is compromised, the attacker can replace the DNS configuration with
one of its own choosing. one of its own choosing.
</t> </t>
</section> </section>
<section anchor="blocking-of-dns-resolution-services" numbered="true" to
<section anchor="blocking-of-dns-resolution-services" title="Blocking of DNS Res c="default">
olution Services"> <name>Blocking of DNS Resolution Services</name>
<t>User privacy can also be at risk if there is blocking <t>User privacy can also be at risk if there is blocking
of access to remote recursive servers of access to remote recursive servers
that offer encrypted transports e.g., when the local resolver does not offer that offer encrypted transports, e.g., when the local resolver does not offer
encryption and/or has very poor privacy policies. For example, active blocking encryption and/or has very poor privacy policies. For example, active blocking
of port 853 for DoT or of specific IP addresses could restrict the resolvers of port 853 for DoT or blocking of specific IP addresses could restrict the re solvers
available to the user. The extent of the risk to user privacy is highly available to the user. The extent of the risk to user privacy is highly
dependent on the specific network and user context; a user on a network that dependent on the specific network and user context; a user on a network that
is known to perform surveillance would be compromised if they could not access is known to perform surveillance would be compromised if they could not access
such services, whereas a user on a trusted network might have no privacy such services, whereas a user on a trusted network might have no privacy
motivation to do so. motivation to do so.
</t> </t>
<t>As a matter of policy, some recursive resolvers use their position in the que ry <t>As a matter of policy, some recursive resolvers use their position in the query
path to selectively block access to certain DNS records. This is a form of path to selectively block access to certain DNS records. This is a form of
Rendezvous-Based Blocking as described in Section 4.3 of <xref target="RFC7754 rendezvous-based blocking as described in <xref target="RFC7754" sectionFormat
"/>. Such ="of" section="4.3"/>. Such
blocklists often include servers known to be used for malware, bots or other blocklists often include servers known to be used for malware, bots, or other
security risks. In order to prevent circumvention of their blocking policies, security risks. In order to prevent circumvention of their blocking policies,
some networks also block access to resolvers with incompatible policies. some networks also block access to resolvers with incompatible policies.
</t> </t>
<t>It is also noted that attacks on remote resolver services, e.g., DDoS, could <t>It is also noted that attacks on remote resolver services, e.g., DD oS, could
force users to switch to other services that do not offer encrypted transports force users to switch to other services that do not offer encrypted transports
for DNS. for DNS.
</t> </t>
</section> </section>
<section anchor="encrypted-transports-and-recursive-resolvers" numbered=
<section anchor="encrypted-transports-and-recursive-resolvers" title="Encrypted "true" toc="default">
Transports and Recursive Resolvers"> <name>Encrypted Transports and Recursive Resolvers</name>
<section anchor="dot-and-doh" numbered="true" toc="default">
<section anchor="dot-and-doh" title="DoT and DoH"> <name>DoT and DoH</name>
<t>Use of encrypted transports does not reduce the data available in the recursi <t>Use of encrypted transports does not reduce the data available in
ve the recursive
resolver and ironically can actually expose more information about users to resolver and ironically can actually expose more information about users to
operators. As described in <xref target="encrypted-transports"/> use of session based encrypted operators. As described in <xref target="encrypted-transports" format="default"/ >, use of session-based encrypted
transports (TCP/TLS) can expose correlation data about users. transports (TCP/TLS) can expose correlation data about users.
</t> </t>
</section> </section>
<section anchor="doh-specific-considerations" numbered="true" toc="def
<section anchor="doh-specific-considerations" title="DoH Specific Considerations ault">
"> <name>DoH-Specific Considerations</name>
<t>DoH inherits the full privacy properties of the HTTPS stack and as a conseque <t>DoH inherits the full privacy properties of the HTTPS stack and a
nce s a consequence
introduces new privacy considerations when compared with DNS over UDP, TCP or introduces new privacy considerations when compared with DNS over UDP, TCP, or
TLS <xref target="RFC7858"/>. Section 8.2 of <xref target="RFC8484"/> describes TLS <xref target="RFC7858" format="default"/>. <xref target="RFC8484" sectionFor
the privacy consideration in mat="of" section="8.2"/> describes the privacy considerations in
the server of the DoH protocol. the server of the DoH protocol.
</t> </t>
<t>A brief summary of some of the issues includes: <t>A brief summary of some of the issues includes the following:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>HTTPS presents new considerations for correlation, such as exp
<t>HTTPS presents new considerations for correlation, such as explicit HTTP licit HTTP
cookies and implicit fingerprinting of the unique set and ordering of HTTP cookies and implicit fingerprinting of the unique set and ordering of HTTP
request header fields.</t> request header fields.</li>
<t>The User-Agent and Accept-Language request header fields often convey specifi <li>The User-Agent and Accept-Language request header fields often
c convey specific
information about the client version or locale.</t> information about the client version or locale.</li>
<t>Utilizing the full set of HTTP features enables DoH to be more than an HTTP <li>Utilizing the full set of HTTP features enables DoH to be more
than an HTTP
tunnel, but it is at the cost of opening up implementations to the full set of tunnel, but it is at the cost of opening up implementations to the full set of
privacy considerations of HTTP.</t> privacy considerations of HTTP.</li>
<t>Implementations are advised to expose the minimal set of data needed to <li>Implementations are advised to expose the minimal set of data
achieve the desired feature set.</t> needed to
</list> achieve the desired feature set.</li>
</t> </ul>
<t><xref target="RFC8484"/> specifically makes selection of HTTPS functionality <t><xref target="RFC8484" format="default"/> specifically makes sele
vs privacy an ction of HTTPS functionality vs. privacy an
implementation choice. At the extremes, there may be implementations that implementation choice. At the extremes, there may be implementations that
attempt to achieve parity with DoT from a privacy perspective at the cost of attempt to achieve parity with DoT from a privacy perspective at the cost of
using no identifiable HTTP headers, there might be others that provide feature using no identifiable HTTP headers, and there might be others that provide featu
rich data flows where the low-level origin of the DNS query is easily re-rich data flows where the low-level origin of the DNS query is easily
identifiable. Some implementations have, in fact, chosen to restrict the use of identifiable. Some implementations have, in fact, chosen to restrict the use of
the the User-Agent header so that resolver operators cannot identify the specific
'User-Agent' header so that resolver operators cannot identify the specific
application that is originating the DNS queries. application that is originating the DNS queries.
</t> </t>
<t>Privacy focused users should be aware of the potential for additional client <t>Privacy-focused users should be aware of the potential for additi onal client
identifiers in DoH compared to DoT and may want to only use DoH client identifiers in DoH compared to DoT and may want to only use DoH client
implementations that provide clear guidance on what identifiers they add. implementations that provide clear guidance on what identifiers they add.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="in-the-authoritative-name-servers" numbered="true" toc="d
<section anchor="in-the-authoritative-name-servers" title="In the Authoritative efault">
Name Servers"> <name>In the Authoritative Name Servers</name>
<t>Unlike what happens for recursive resolvers, observation capabilities of <t>Unlike what happens for recursive resolvers, the observation capabili
ties of
authoritative name servers are limited by caching; they see only the requests authoritative name servers are limited by caching; they see only the requests
for which the answer was not in the cache. For aggregated statistics (&quot;W for which the answer was not in the cache. For aggregated statistics ("What
hat is the percentage of LOC queries?"), this is sufficient, but it prevents an
is the percentage of LOC queries?&quot;), this is sufficient, but it prevents observer from seeing everything. Similarly, the increasing deployment of QNAM
an E
observer from seeing everything. Similarly the increasing deployment of QNAME minimization <xref target="ripe-qname-measurements" format="default"/> reduce
minimisation <xref target="ripe-qname-measurements"/> reduces the data visibl s the data visible at the
e at the
authoritative name server. Still, the authoritative name servers see a part authoritative name server. Still, the authoritative name servers see a part
of the traffic, and this subset may be sufficient to violate some privacy of the traffic, and this subset may be sufficient to violate some privacy
expectations. expectations.
</t> </t>
<t>Also, the user often has some legal/contractual link with the <t>Also, the user often has some legal/contractual link with the
recursive resolver (he has chosen the IAP, or he has chosen to use a recursive resolver (they have chosen the IAP, or they have chosen to use a
given public resolver), while having no control and perhaps no given public resolver) while having no control and perhaps no
awareness of the role of the authoritative name servers and their awareness of the role of the authoritative name servers and their
observation abilities. observation abilities.
</t> </t>
<t>As noted before, using a local resolver or a resolver close to the <t>As noted before, using a local resolver or a resolver close to the
machine decreases the attack surface for an on-the-wire eavesdropper. machine decreases the attack surface for an on-the-wire eavesdropper.
But it may decrease privacy against an observer located on an But it may decrease privacy against an observer located on an
authoritative name server. This authoritative name server will see authoritative name server. This authoritative name server will see
the IP address of the end client instead of the address of a big the IP address of the end client instead of the address of a big
recursive resolver shared by many users. recursive resolver shared by many users.
</t> </t>
<t>This &quot;protection&quot;, when using a large resolver with many clients, i <t>This "protection", when using a large resolver with many clients, is
s no longer present if ECS <xref target="RFC7871" format="default"/> is used be
no longer present if ECS <xref target="RFC7871"/> is used because, in this ca cause, in this case,
se,
the authoritative name server sees the original IP address (or the authoritative name server sees the original IP address (or
prefix, depending on the setup). prefix, depending on the setup).
</t> </t>
<t>As of today, all the instances of one root name server, L-root, <t>As of today, all the instances of one root name server, L-root,
receive together around 50,000 queries per second. While most of it receive together around 50,000 queries per second. While most of it
is &quot;junk&quot; (errors on the Top-Level Domain (TLD) name), it gives an is "junk" (errors on the Top-Level Domain (TLD) name), it gives an
idea of the amount of big data that pours into name servers. (And idea of the amount of big data that pours into name servers. (And
even &quot;junk&quot; can leak information; for instance, if there is a typin g even "junk" can leak information; for instance, if there is a typing
error in the TLD, the user will send data to a TLD that is not the error in the TLD, the user will send data to a TLD that is not the
usual one.) usual one.)
</t> </t>
<t>Many domains, including TLDs, are partially hosted by third-party <t>Many domains, including TLDs, are partially hosted by third-party
servers, sometimes in a different country. The contracts between the servers, sometimes in a different country. The contracts between the
domain manager and these servers may or may not take privacy into domain manager and these servers may or may not take privacy into
account. Whatever the contract, the third-party hoster may be honest account. Whatever the contract, the third-party hoster may or may not be hon
or not but, in any case, it will have to follow its local laws. For est; in any case, it will have to follow its local laws. For
example, example,
requests to a given ccTLD may go to servers managed by organizations requests to a given ccTLD may go to servers managed by organizations
outside of the ccTLD's country. Users may not anticipate that, outside of the ccTLD's country. Users may not anticipate that
when doing a security analysis. when doing a security analysis.
</t> </t>
<t>Also, it seems (see the survey described in <xref target="aeris-dns"/>) that <t>Also, it seems (see the survey described in <xref target="aeris-dns"
there is a format="default"/>) that there is a
strong concentration of authoritative name servers among &quot;popular&quot; strong concentration of authoritative name servers among "popular" domains
domains
(such as the Alexa Top N list). For instance, among the <eref target="https:/ /www.alexa.com/topsites">Alexa Top (such as the Alexa Top N list). For instance, among the <eref target="https:/ /www.alexa.com/topsites">Alexa Top
100K</eref>, one DNS provider hosts today 10% of 100K</eref>, one DNS provider hosts 10% of
the domains. The ten most important DNS providers host together one third of the domains today. The ten most important DNS providers together host one-thi
the domains. With the control (or the ability to sniff the traffic) of a few rd of
all domains. With the control (or the ability to sniff the traffic) of a few
name servers, you can gather a lot of information. name servers, you can gather a lot of information.
</t> </t>
</section> </section>
</section> </section>
<section anchor="other-risks" numbered="true" toc="default">
<section anchor="other-risks" title="Other risks"> <name>Other Risks</name>
<section anchor="reidentification-and-other-inferences" numbered="true" to
c="default">
<name>Re-identification and Other Inferences</name>
<section anchor="reidentification-and-other-inferences" title="Re-identification <t>An observer has access not only to the data they directly collect but
and Other Inferences"> also
<t>An observer has access not only to the data he/she directly collects but also to the results of various inferences about this data. The term "observer" her
to the results of various inferences about this data. The term 'observer' e is used very generally; for example, the observer might
here is used very generally, it might be one that is passively observing passively observe cleartext DNS traffic or be in the network
cleartext DNS traffic, one in the network that is actively attacking the user that is actively attacking the user by redirecting DNS resolution, or it migh
by re-directing DNS resolution, or it might be a local or remote resolver t be a
operator. local or remote resolver operator.
</t> </t>
<t>For instance, a user can be re-identified via DNS queries. If the <t>For instance, a user can be re-identified via DNS queries. If the
adversary knows a user's identity and can watch their DNS queries for adversary knows a user's identity and can watch their DNS queries for
a period, then that same adversary may be able to re-identify the a period, then that same adversary may be able to re-identify the
user solely based on their pattern of DNS queries later on regardless user solely based on their pattern of DNS queries later on regardless
of the location from which the user makes those queries. For of the location from which the user makes those queries. For
example, one study <xref target="herrmann-reidentification"/> found that such example, one study <xref target="herrmann-reidentification" format="default"/
re- > found that such re-identification is possible so that "73.1% of all day-to-day
identification is possible so that &quot;73.1% of all day-to-day links links
were correctly established, i.e., user u was either re-identified were correctly established, i.e. user u was either re-identified
unambiguously (1) or the classifier correctly reported that u was not unambiguously (1) or the classifier correctly reported that u was not
present on day t+1 any more (2).&quot; While that study related to web present on day t + 1 any more (2)". While that study related to web
browsing behavior, equally characteristic patterns may be produced browsing behavior, equally characteristic patterns may be produced
even in machine-to-machine communications or without a user taking even in machine-to-machine communications or without a user taking
specific actions, e.g., at reboot time if a characteristic set of specific actions, e.g., at reboot time if a characteristic set of
services are accessed by the device. services are accessed by the device.
</t> </t>
<t>For instance, one could imagine that an intelligence agency <t>For instance, one could imagine that an intelligence agency
identifies people going to a site by putting in a very long DNS name identifies people going to a site by putting in a very long DNS name
and looking for queries of a specific length. Such traffic analysis and looking for queries of a specific length. Such traffic analysis
could weaken some privacy solutions. could weaken some privacy solutions.
</t> </t>
<t>The IAB privacy and security program also have a document <t>The IAB Privacy and Security Program also has a document
<xref target="RFC7624"/> that considers such inference-based attacks in a mor <xref target="RFC7624" format="default"/> that considers such inference-based
e attacks in a more
general framework. general framework.
</t> </t>
</section> </section>
<section anchor="more-information" numbered="true" toc="default">
<section anchor="more-information" title="More Information"> <name>More Information</name>
<t>Useful background information can also be found in <xref target="tor-leak"/> <t>Useful background information can also be found in <xref target="tor-
(about leak" format="default"/> (regarding the risk of privacy leaks through DNS) and i
the risk of privacy leak through DNS) and in a few academic papers: n a few academic papers:
<xref target="yanbin-tsudik"/>, <xref target="castillo-garcia"/>, <xref targe <xref target="yanbin-tsudik" format="default"/>, <xref target="castillo-garci
t="fangming-hori-sakurai"/>, and a" format="default"/>, <xref target="fangming-hori-sakurai" format="default"/>,
<xref target="federrath-fuchs-herrmann-piosecny"/>. and
<xref target="federrath-fuchs-herrmann-piosecny" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="actual-attacks" numbered="true" toc="default">
<section anchor="actual-attacks" title="Actual &quot;Attacks&quot;"> <name>Actual "Attacks"</name>
<t>A very quick examination of DNS traffic may lead to the false conclusion that <t>A very quick examination of DNS traffic may lead to the false conclusio
extracting the needle from the haystack is difficult. &quot;Interesting&quot; n that
primary extracting the needle from the haystack is difficult. "Interesting" primary
DNS requests are mixed with useless (for the eavesdropper) secondary and DNS requests are mixed with useless (for the eavesdropper) secondary and
tertiary requests (see the terminology in <xref target="introduction"/>). But tertiary requests (see the terminology in <xref target="introduction" format=
, in "default"/>). But, in
this time of &quot;big data&quot; processing, powerful techniques now exist t this time of "big data" processing, powerful techniques now exist to get from
o get from
the raw data to what the eavesdropper is actually interested in. the raw data to what the eavesdropper is actually interested in.
</t> </t>
<t>Many research papers about malware detection use DNS traffic to <t>Many research papers about malware detection use DNS traffic to
detect &quot;abnormal&quot; behavior that can be traced back to the activity detect "abnormal" behavior that can be traced back to the activity of
of malware on infected machines.
malware on infected machines. Yes, this research was done for the Yes, this research was done for the greater good, but technically it is a privac
good, but technically it is a privacy attack and it demonstrates the y attack and it demonstrates the
power of the observation of DNS traffic. See <xref target="dns-footprint"/>, power of the observation of DNS traffic. See <xref target="dns-footprint" fo
<xref target="dagon-malware"/>, and <xref target="darkreading-dns"/>. rmat="default"/>,
<xref target="dagon-malware" format="default"/>, and <xref target="darkreadin
g-dns" format="default"/>.
</t> </t>
<t>Passive DNS systems <xref target="passive-dns"/> allow reconstruction of the <t>Passive DNS services <xref target="passive-dns" format="default"/> allo
data of w reconstruction of the data of sometimes an entire zone. Well-known passive DNS
sometimes an entire zone. Well-known passive DNS systems keep only the DNS services keep only the DNS
responses, and not the source IP address of the client, precisely for responses and not the source IP address of the client, precisely for
privacy reasons. Other passive DNS systems may not be so careful. privacy reasons. Other passive DNS services may not be so careful.
And there is still the potential problems with revealing QNAMEs. And there are still potential problems with revealing QNAMEs.
</t> </t>
<t>The revelations from the Edward Snowden documents, which were leaked from the <t>The revelations from the Edward Snowden documents, which were leaked fr om the
National Security Agency (NSA), provide evidence of the use of the DNS in mas s National Security Agency (NSA), provide evidence of the use of the DNS in mas s
surveillance operations <xref target="morecowbell"/>. For example the MORECOW surveillance operations <xref target="morecowbell" format="default"/>. For ex
BELL ample, the MORECOWBELL
surveillance program, which uses a dedicated covert monitoring infrastructure surveillance program uses a dedicated covert monitoring infrastructure
to actively query DNS servers and perform HTTP requests to obtain meta to actively query DNS servers and perform HTTP requests to obtain meta-inform
information about services and to check their availability. Also the ation about services and to check their availability. Also, the
<eref target="https://theintercept.com/document/2014/03/12/nsa-gchqs-quantumt heory-hacking-tactics/">QUANTUMTHEORY</eref> <eref target="https://theintercept.com/document/2014/03/12/nsa-gchqs-quantumt heory-hacking-tactics/">QUANTUMTHEORY</eref>
project which includes detecting lookups for certain addresses and injecting project, which includes detecting lookups for certain addresses and injecting
bogus replies is another good example showing that the lack of privacy bogus replies, is another good example showing that the lack of privacy
protections in the DNS is actively exploited. protections in the DNS is actively exploited.
</t> </t>
</section> </section>
<section anchor="legalities" numbered="true" toc="default">
<section anchor="legalities" title="Legalities"> <name>Legalities</name>
<t>To our knowledge, there are no specific privacy laws for DNS data, in any <t>To our knowledge, there are no specific privacy laws for DNS data in an
country. Interpreting general privacy laws like <xref target="data-protection y
-directive"/> country. Interpreting general privacy laws, like the European Union's <xref t
or <eref target="https://www.eugdpr.org/the-regulation.html">GDPR</eref> appl arget="data-protection-directive" format="default"/>
icable in the or <eref target="https://gdpr.eu/tag/gdpr/">GDPR</eref>, in the context of DN
European Union in the context of DNS traffic data is not an easy task, and S traffic data is not an easy task, and
there is no known court precedent. See an interesting analysis in there is no known court precedent. See an interesting analysis in
<xref target="sidn-entrada"/>. <xref target="sidn-entrada" format="default"/>.
</t> </t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>This document is entirely about security, more precisely privacy. It just <t>This document is entirely about security -- more precisely, privacy. It
just
lays out the problem; it does not try to set requirements (with the choices lays out the problem; it does not try to set requirements (with the choices
and compromises they imply), much less define solutions. Possible solutions and compromises they imply), much less define solutions. Possible solutions
to the issues described here are discussed in other documents (currently too to the issues described here are discussed in other documents (currently too
many to all be mentioned); see, for instance, 'Recommendations for DNS many to all be mentioned); see, for instance, "Recommendations for DNS
Privacy Operators' <xref target="I-D.ietf-dprive-bcp-op"/>. Privacy Operators" <xref target="RFC8932" format="default"/>.
</t> </t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document makes no requests of the IANA. <t>This document has no IANA actions.
</t> </t>
</section> </section>
</middle>
<back>
<section anchor="contributions" title="Contributions"> <displayreference target="I-D.ietf-dnsop-resolver-information" to="DNSOP-RESOLVE
<t>Sara Dickinson and Stephane Bortzmeyer were the original authors on the R"/>
document, and their contribution on the initial version is greatly appreciate <displayreference target="I-D.ietf-dprive-dnsoquic" to="DPRIVE-DNSOQUIC"/>
d.
</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments"> <references>
<t>Thanks to Nathalie Boulvard and to the CENTR members for the original work <name>References</name>
that led to this document. Thanks to Ondrej Sury for the interesting <references>
discussions. Thanks to Mohsen Souissi and John Heidemann for proofreading and <name>Normative References</name>
to Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim Wicinski, Francis Dupont, <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Allison Mankin, and Warren Kumari for proofreading, providing technical FC.1034.xml"/>
remarks, and making many readability improvements. Thanks to Dan York, <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Suzanne Woolf, Tony Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and FC.1035.xml"/>
Frank Denis for good written contributions. Thanks to Vittorio Bertola and <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Mohamed Boucadair for a detailed review of the -bis. And thanks to the IESG FC.6973.xml"/>
members for the last remarks. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</t> FC.7258.xml"/>
</section> </references>
<references>
<name>Informative References</name>
</middle> <reference anchor="dns-de-nat" target= "https://www.researchgate.net/pub
<back> lication/320322146_DNS-DNS_DNS-based_De-NAT_Scheme">
<references title="Normative References"> <front>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.10 <title>DNS-DNS: DNS-based De-NAT Scheme</title>
34.xml"?> <author surname="Orevi" initials="L." fullname="Liran Orevi"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.10 <author surname="Herzberg" initials="A." fullname="Amir Herzberg"/>
35.xml"?> <author surname="Zlatokrilov" initials="H." fullname="Haim Zlatokril
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.69 ov"/>
73.xml"?> <author surname="Sigron" initials="D." fullname="Dolev Sigron"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72 <date month="January" year="2017"/>
58.xml"?> </front>
</references> </reference>
<references title="Informative References">
<reference anchor="EDDI" target="https://www.encrypted-dns.org"> <reference anchor="EDDI" target="https://www.encrypted-dns.org">
<front> <front>
<title>Encrypted DNS Deployment Initiative</title> <title>Encrypted DNS Deployment Initiative</title>
<author><organization>EDDI</organization></author> <author>
<date year="2020"/> <organization>EDDI</organization>
</front> </author>
</reference> <date/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i </front>
etf-dnsop-resolver-information.xml"?> </reference>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-dprive-bcp-op.xml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i .ietf-dnsop-resolver-information.xml"/>
etf-dprive-dnsoquic.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
etf-quic-transport.xml"?> FC.8932.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.35
52.xml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.40 .ietf-dprive-dnsoquic.xml"/>
33.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.44 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
70.xml"?> xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.51
55.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.59 FC.3552.xml"/>
36.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.62 FC.4033.xml"/>
69.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.68 FC.4470.xml"/>
91.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.74 FC.5155.xml"/>
13.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.75 FC.5936.xml"/>
25.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.76 FC.6269.xml"/>
24.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.77 FC.6891.xml"/>
21.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.77 FC.7413.xml"/>
54.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.78 FC.7525.xml"/>
16.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.78 FC.7624.xml"/>
58.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.78 FC.7626.xml"/>
71.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.78 FC.7721.xml"/>
73.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.79 FC.7754.xml"/>
29.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84 FC.7816.xml"/>
46.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84 FC.7858.xml"/>
84.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84 FC.7871.xml"/>
99.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.87 FC.7873.xml"/>
44.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.88 FC.7929.xml"/>
90.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="aeris-dns" target="https://blog.imirhil.fr/vie-privee-et-le-d FC.8446.xml"/>
ns-alors.html"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8484.xml"/>
<title>Vie privee: et le DNS alors?</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="Nicolas Vinot" surname="Vinot" initials="N."/> FC.8499.xml"/>
<date year="2015"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<abstract> FC.8744.xml"/>
<t>A survey of the DNS privacy issues, specifically from the point of <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
view of the concentration in DNS providers. With data drawn from a DNS FC.8890.xml"/>
harvest of Alexa Top N's authoritative name servers. <reference anchor="aeris-dns" target="https://blog.imirhil.fr/vie-privee
</t> -et-le-dns-alors.html">
</abstract> <front>
</front> <title>Vie privée: et le DNS alors? [Privacy: what about DNS?]</titl
<seriesInfo name="(In" value="French)"/> e>
</reference> <author fullname="Nicolas Vinot" surname="Vinot" initials="N."/>
<reference anchor="cache-snooping-defence" target="https://kb.isc.org/docs/aa-00 <date month="February" year="2015"/>
482"> </front>
<front> </reference>
<title>ISC Knowledge Database: DNS Cache snooping - should I be concerned?</titl
e> <reference anchor="cache-snooping-defence" target="https://kb.isc.org/do
<author fullname="ISC" surname="ISC"/> cs/aa-00482">
<date year="2018" /> <front>
</front> <title>DNS Cache snooping - should I be concerned?</title>
</reference> <author><organization>ISC</organization></author>
<reference anchor="castillo-garcia" target="http://deic.uab.es/~joaquin/papers/i <date year="2018" month="October"/>
s08.pdf"> </front>
<front> </reference>
<title>Anonymous Resolution of DNS Queries</title>
<author initials="S." surname="Castillo-Perez" fullname="S. Castillo-Perez"/> <reference anchor="castillo-garcia" target="https://dl.acm.org/doi/10.10
<author initials="J." surname="Garcia-Alfaro" fullname="J.Garcia-Alfaro"/> 07/978-3-540-88873-4_5">
<date year="2008"/>
<abstract> <front>
<t>OTM 2008 Confederated International Conferences, CoopIS, DOA, GADA, IS, and <title>Anonymous Resolution of DNS Queries</title>
ODBASE 2008, Monterrey, Mexico, November 9-14, 2008, Proceedings</t> <author initials="S." surname="Castillo-Perez" fullname="S. Castillo
<t>Focus on ENUM privacy risks. A suggested solution is to add gratuitous -Perez"/>
queries, in order to hide the real ones.</t> <author initials="J." surname="Garcia-Alfaro" fullname="J.Garcia-Alf
</abstract> aro"/>
</front> <date year="2008"/>
</reference> </front>
<reference anchor="centralisation-and-data-sovereignty" target="https://papers.s <seriesInfo name="DOI" value="10.1007/978-3-540-88873-4_5"/>
srn.com/sol3/papers.cfm?abstract_id=2167372"> <refcontent>Lecture Notes in Computer Science, Vol. 5332</refcontent>
<front> </reference>
<title>Cloud Computing: Centralization and Data Sovereignty</title>
<author fullname="Primavera De Filippi" surname="De Filippi" initials="P."/> <reference anchor="centralisation-and-data-sovereignty" target="https://
<author fullname="Smari McCarthy" surname="McCarthy" initials="S."/> papers.ssrn.com/sol3/papers.cfm?abstract_id=2167372">
<date month="October" year="2012"/> <front>
</front> <title>Cloud Computing: Centralization and Data Sovereignty</title>
</reference> <author fullname="Primavera De Filippi" surname="De Filippi" initial
<reference anchor="dagon-malware" target="https://www.dns-oarc.net/files/worksho s="P."/>
p-2007/Dagon-Resolution-corruption.pdf"> <author fullname="Smari McCarthy" surname="McCarthy" initials="S."/>
<front> <date month="October" year="2012"/>
<title>Corrupted DNS Resolution Paths: The Rise of a Malicious </front>
<refcontent>European Journal of Law and Technology, Vol. 3, No. 2</refcontent>
</reference>
<reference anchor="dagon-malware" target="https://www.dns-oarc.net/files
/workshop-2007/Dagon-Resolution-corruption.pdf">
<front>
<title>Corrupted DNS Resolution Paths: The Rise of a Malicious
Resolution Authority</title> Resolution Authority</title>
<author surname="Dagon" initials="D." fullname="David Dagon"/> <author surname="Dagon" initials="D." fullname="David Dagon"/>
<date year="2007"/> <date year="2007"/>
</front> </front>
<seriesInfo name="ISC/OARC" value="Workshop"/> <refcontent>ISC/OARC Workshop</refcontent>
</reference> </reference>
<reference anchor="darkreading-dns" target="http://www.darkreading.com/analytics
/security-monitoring/got-malware-three-signs-revealed-in-dns-traffic/d/d-id/1139 <reference anchor="darkreading-dns" target="https://www.darkreading.com/
680"> analytics/security-monitoring/got-malware-three-signs-revealed-in-dns-traffic/d/
<front> d-id/1139680">
<title>Got Malware? Three Signs Revealed In DNS Traffic</title> <front>
<author fullname="Robert Lemos" surname="Lemos" initials="R."/> <title>Got Malware? Three Signs Revealed In DNS Traffic</title>
<date month="May" year="2013"/> <author fullname="Robert Lemos" surname="Lemos" initials="R."/>
<abstract> <date month="May" year="2013"/>
<t>Monitoring your network's requests for domain lookups can reveal </front>
network problems and potential malware infections.</t> </reference>
</abstract>
</front> <reference anchor="data-protection-directive" target="https://eur-lex.eu
<seriesInfo name="InformationWeek" value="Dark Reading"/> ropa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML">
</reference> <front>
<reference anchor="data-protection-directive" target="http://eur-lex.europa.eu/L <title>Directive 95/46/EC of the European Parliament and of the Coun
exUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML"> cil of 24 October 1995 on the protection of individuals with regard to the proce
<front> ssing of personal data and on the free movement of such data </title>
<title>Directive 95/46/EC of the European Parliament and of the council on the p <author>
rotection of individuals <organization>European Parliament</organization>
with regard to the processing of personal data and on the free </author>
movement of such data</title> <date month="November" year="1995"/>
<author><organization>European Parliament</organization></author> </front>
<date month="November" year="1995"/> <refcontent>Official Journal L 281, pp. 31-50</refcontent>
</front> </reference>
<seriesInfo name='Official Journal L 281,' value='pp. 0031 - 0050' />
</reference> <reference anchor="day-at-root" target="https://www.sigcomm.org/sites/de
<reference anchor="day-at-root" fault/files/ccr/papers/2008/October/1452335-1452341.pdf">
target="http://www.sigcomm.org/sites/default/files/ccr/papers/2008/Octobe <front>
r/1452335-1452341.pdf"> <title>A Day at the Root of the Internet</title>
<front> <author fullname="Sebastian Castro" initials="S." surname="Castro"/>
<title>A Day at the Root of the Internet</title> <author fullname="Duane Wessels" initials="D." surname="Wessels"/>
<author fullname="Sebastian Castro" initials="S." surname="Castro"/> <author fullname="Marina Fomenkov" initials="M." surname="Fomenkov"/
<author fullname="Duane Wessels" initials="D." surname="Wessels"/> >
<author fullname="Marina Fomenkov" initials="M." surname="Fomenkov"/> <author fullname="Kimberly Claffy" initials="K." surname="Claffy"/>
<author fullname="Kimberly Claffy" initials="K." surname="Claffy"/> <date month="October" year="2008"/>
<date month="October" year="2008"/> </front>
</front> <seriesInfo name="DOI" value="10.1145/1452335.1452341"/>
<seriesInfo name='ACM SIGCOMM Computer Communication Review,' value='Vol. 38, Nu <refcontent>ACM SIGCOMM Computer Communication Review, Vol. 38, No. 5<
mber 5'/> /refcontent>
<seriesInfo name="DOI" value="10.1145/1452335.1452341"/> </reference>
</reference>
<reference anchor="denis-edns-client-subnet" target="https://00f.net/2013/08/07/ <reference anchor="denis-edns-client-subnet" target="https://00f.net/201
edns-client-subnet/"> 3/08/07/edns-client-subnet/">
<front> <front>
<title>Security and privacy issues of edns-client-subnet</title> <title>Security and privacy issues of edns-client-subnet</title>
<author fullname="Frank Denis" surname="Denis" initials="F"/> <author fullname="Frank Denis" surname="Denis" initials="F."/>
<date month="August" year="2013"/> <date month="August" year="2013"/>
</front> </front>
</reference> </reference>
<reference anchor="ditl" target="http://www.caida.org/projects/ditl/">
<front> <reference anchor="ditl" target="https://www.caida.org/projects/ditl/">
<title>A Day in the Life of the Internet (DITL)</title> <front>
<author><organization>CAIDA</organization></author> <title>A Day in the Life of the Internet (DITL)</title>
<date year="2002"/> <author>
<abstract> <organization>CAIDA</organization>
<t>CAIDA, ISC, DNS-OARC, and many partnering root nameserver operators </author>
and other organizations to coordinate and conduct large-scale, <date/>
simultaneous traffic data collection events with the goal of capturing </front>
datasets of strategic interest to researchers. Over the last several </reference>
years, we have come to refer to this project and related activities as
"A Day in the Life of the Internet" (DITL).</t> <reference anchor="dns-footprint" target="https://www.dns-oarc.net/files
</abstract> /workshop-201010/OARC-ers-20101012.pdf">
</front> <front>
</reference> <title>DNS Footprint of Malware</title>
<reference anchor="dns-footprint" target="https://www.dns-oarc.net/files/worksho <author fullname="Ed Stoner" surname="Stoner" initials="E."/>
p-201010/OARC-ers-20101012.pdf"> <date month="October" year="2010"/>
<front> </front>
<title>DNS Footprint of Malware</title> <refcontent>OARC Workshop</refcontent>
<author fullname="Ed Stoner" surname="Stoner" initials="E."/> </reference>
<date month="October" year="2010"/>
</front> <reference anchor="dns-over-encryption" target="https://dl.acm.org/citat
<seriesInfo name="OARC" value="Workshop"/> ion.cfm?id=3355369.3355580">
</reference> <front>
<reference anchor="dns-over-encryption" <title>An End-to-End, Large-Scale Measurement of DNS-over-Encryption
target="http://dl.acm.org/citation.cfm?id=3355369.3355580"> : How Far Have We Come?</title>
<front> <author fullname="Chaoyi Lu" surname="Lu" initials="C."/>
<title>An End-to-End, Large-Scale Measurement of DNS-over-Encryption</title> <author fullname="Baojun Liu" surname="Liu" initials="B."/>
<author fullname="Chaoyi Lu" surname="Lu" initials="C."/> <author fullname="Zhou Li" surname="Li" initials="Z."/>
<author fullname="Baojun Liu" surname="Liu" initials="B."/> <author fullname="Shuang Hao" surname="Hao" initials="S."/>
<author fullname="Zhou Li" surname="Li" initials="Z."/> <author fullname="Haixin Duan" surname="Duan" initials="H."/>
<author fullname="Shuang Hao" surname="Hao" initials="S."/> <author fullname="Mingming Zhang" surname="Zhang" initials="M."/>
<author fullname="Haixin Duan" surname="Duan" initials="H."/> <author fullname="Chunying Leng" surname="Leng" initials="C."/>
<author fullname="Mingming Zhang" surname="Zhang" initials="M."/> <author fullname="Ying Liu" surname="Liu" initials="Y."/>
<author fullname="Chunying Leng" surname="Leng" initials="C."/> <author fullname="Zaifeng Zhang" surname="Zhang" initials="Z."/>
<author fullname="Ying Liu" surname="Liu" initials="Y."/> <author fullname="Jianping Wu" surname="Wu" initials="J."/>
<author fullname="Zaifeng Zhang" surname="Zhang" initials="Z."/> <date month="October" year="2019"/>
<author fullname="Jianping Wu" surname="Wu" initials="J."/> </front>
<date month="October" year="2019"/> <seriesInfo name="DOI" value="10.1145/3355369.3355580"/>
</front> <refcontent>IMC '19: Proceedings of the Internet Measurement Conference, pp. 22-
<seriesInfo name="IMC '19" value="Amsterdam, Netherlands"/> 35</refcontent>
<seriesInfo name="DOI" value="10.1145/3355369.3355580"/> </reference>
</reference>
<reference anchor="dnsmezzo" target="http://www.dnsmezzo.net/"> <reference anchor="dnsmezzo" target="http://www.dnsmezzo.net/">
<front> <front>
<title>DNSmezzo</title> <title>DNSmezzo</title>
<author fullname="Stephane Bortzmeyer" surname="Bortzmeyer" initials="S."/> <author fullname="Stephane Bortzmeyer" surname="Bortzmeyer" initials
<date year="2009"/> ="S."/>
<abstract><t>DNSmezzo is a framework for the capture and analysis of DNS packets <date/>
. </front>
It allows the manager of a DNS name server to get information such as the top </reference>
N domains requests, the percentage of IPv6 queries, the most talkative clients,
etc. It is part of the broader program DNSwitness.</t></abstract> <reference anchor="fangming-hori-sakurai" target="https://dl.acm.org/cit
</front> ation.cfm?id=1262690.1262986">
</reference> <front>
<reference anchor="fangming-hori-sakurai" <title>Analysis of Privacy Disclosure in DNS Query</title>
target="http://dl.acm.org/citation.cfm?id=1262690.1262986"> <author fullname="Fangming Zhao" surname="Zhao" initials="F."/>
<front> <author fullname="Yoshiaki Hori" surname="Hori" initials="Y."/>
<title>Analysis of Privacy Disclosure in DNS Query</title> <author fullname="Kouichi Sakurai" surname="Sakurai" initials="K."/>
<author fullname="Fangming Zhao" surname="Fangming" initials="Z."/> <date month="April" year="2007"/>
<author fullname="Yoshiaki Hori" surname="Hori" initials="Y."/> </front>
<author fullname="Kouichi Sakurai" surname="Sakurai" initials="K."/> <refcontent>MUE '07: Proceedings of the 2007 International Conference
<date month="April" year="2007"/> on Multimedia and Ubiquitous Engineering</refcontent>
<abstract> <seriesInfo name="DOI" value="10.1109/MUE.2007.84"/>
<t>Not available online.</t> <seriesInfo name="ISBN" value="0-7695-2777-9"/>
</abstract> <refcontent>pp. 952-957</refcontent>
</front> </reference>
<seriesInfo name="2007 International Conference on Multimedia and Ubiquitous Eng
ineering (MUE 2007)," value="Seoul, Korea"/> <reference anchor="federrath-fuchs-herrmann-piosecny" target="https://sv
<seriesInfo name='ISBN: 0-7695-2777-9,' value='pp. 952-957' /> s.informatik.uni-hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreservingD
<seriesInfo name="DOI" value="10.1109/MUE.2007.84"/> NS_ESORICS2011.pdf">
</reference> <front>
<reference anchor="federrath-fuchs-herrmann-piosecny" target="https://svs.inform <title>Privacy-Preserving DNS: Analysis of Broadcast, Range Queries
atik.uni-hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreservingDNS_ESORI and Mix-based Protection Methods</title>
CS2011.pdf"> <author fullname="Hannes Federrath" surname="Federrath" initials="H.
<front> "/>
<title>Privacy-Preserving DNS: Analysis of Broadcast, Range Queries and Mix-base <author fullname="Karl-Peter Fuchs" surname="Fuchs" initials="K.-P."
d Protection Methods</title> />
<author fullname="Hannes Federrath" surname="Federrath" initials="H."/> <author fullname="Dominik Herrmann" surname="Herrmann" initials="D."
<author fullname="Karl-Peter Fuchs" surname="Fuchs" initials="K.-P."/> />
<author fullname="Dominik Herrmann" surname="Herrmann" initials="D."/> <author fullname="Christopher Piosecny" surname="Piosecny" initials=
<author fullname="Christopher Piosecny" surname="Piosecny" initials="C."/> "C."/>
<date year="2011"/> <date year="2011"/>
<abstract> </front>
<t>Privacy is improved by broadcasting of the most common names plus mixes (a To <seriesInfo name="DOI" value="10.1007/978-3-642-23822-2_36"/>
r-like routing system).</t> <seriesInfo name="ISBN" value="978-3-642-23822-2"/>
</abstract> <refcontent>ESORICS 2011, pp. 665-683</refcontent>
</front> </reference>
<seriesInfo name="Computer Security ESORICS 2011," value="Springer"/>
<seriesInfo name="page(s)" value="665-683"/> <reference anchor="getdns" target="https://getdnsapi.net">
<seriesInfo name="ISBN" value="978-3-642-23821-5"/> <front>
</reference> <title>getdns</title>
<reference anchor="getdns" target="https://getdnsapi.net"> <author/>
<front> <date/>
<title>getdns - A modern asynchronous DNS API</title> </front>
<author><organization>getdns</organization></author> </reference>
<date month="January" year="2020"/>
</front> <reference anchor="grangeia.snooping" target="https://www.semanticschola
</reference> r.org/paper/Cache-Snooping-or-Snooping-the-Cache-for-Fun-and-1-Grangeia/9b22f606
<reference anchor="grangeia.snooping" e10b3609eafbdcbfc9090b63be8778c3">
target="https://www.semanticscholar.org/paper/Cache-Snooping-or-Snooping- <front>
the-Cache-for-Fun-and-1-Grangeia/9b22f606e10b3609eafbdcbfc9090b63be8778c3"> <title>Cache Snooping or Snooping the Cache for Fun and
<front>
<title>DNS Cache Snooping or Snooping the Cache for Fun and
Profit</title> Profit</title>
<author fullname="Luis Grangeia" surname="Grangeia" <author fullname="Luis Grangeia" surname="Grangeia" initials="L."/>
initials="L."/> <date year="2005"/>
<date year="2005"/> </front>
</front> </reference>
</reference>
<reference anchor="herrmann-reidentification" <reference anchor="herrmann-reidentification" target="https://epub.uni-r
target="http://epub.uni-regensburg.de/21103/1/Paper_PUL_nordsec_published egensburg.de/21103/1/Paper_PUL_nordsec_published.pdf">
.pdf"> <front>
<front> <title>Analyzing Characteristic Host Access Patterns for Re-Identifi
<title>Analyzing Characteristic Host Access Patterns for Re-Identification o cation of
f
Web User Sessions</title> Web User Sessions</title>
<author fullname="Dominik Herrmann" surname="Herrmann" initials="D."/> <author fullname="Dominik Herrmann" surname="Herrmann" initials="D."
<author fullname="Christoph Gerber" surname="Gerber" initials="C."/> />
<author fullname="Christian Banse" surname="Banse" initials="C."/> <author fullname="Christoph Gerber" surname="Gerber" initials="C."/>
<author fullname="Hannes Federrath" surname="Federrath" initials="H."/> <author fullname="Christian Banse" surname="Banse" initials="C."/>
<date year="2012"/> <author fullname="Hannes Federrath" surname="Federrath" initials="H.
<abstract> "/>
<t>Abstract. An attacker, who is able to observe a web user over a long <date year="2012"/>
period of time, learns a lot about his interests. It may be difficult to </front>
track users with regularly changing IP addresses, though. We show how <seriesInfo name="DOI" value="10.1007/978-3-642-27937-9_10"/>
patterns mined from web traffic can be used to re-identify a majority <refcontent>Lecture Notes in Computer Science, Vol. 7127</refcontent>
of users, i. e. link multiple sessions of them. </t> </reference>
</abstract>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-642-27937-9_10"/>
</reference>
<reference anchor="morecowbell"
target="https://pdfs.semanticscholar.org/2610/2b99bdd6a258a98740af8217ba8
da8a1e4fa.pdf">
<front>
<title>NSA's MORECOWBELL: Knell for DNS</title>
<author fullname="Christian Grothoff" surname="Grothoff" initials="C."/>
<author fullname="Matthias Wachs" surname="Wachs" initials="M."/>
<author fullname="Monika Ermert" surname="Ermert" initials="M."/>
<author fullname="Jacob Appelbaum" surname="Appelbaum" initials="J."/>
<date month="January" year="2015"/>
<abstract>
<t>Detailed technical analysis of the MORECOWBELL program, followed by
opinions about the future of the DNS and the needs for alternate
systems. Stable GNUnet identifier <eref target="gnunet://fs/chk/RSVKSQXNKSHYAD51
8W1CQ79S2FGRYAR7CM7MMEBFTXJ677DVJQN8HR3TR0K544Y050THXM6KZ0ZV6BP3NM31P90ZDGXYTX21
MNV50W8.1XBPZ4MVFQCDY914S1HB7S8VSYDPCXB0XEY50D6ZK0V30C7N39QFKX2AXW8EW9M8HCCPR6EE
EN89D9G6Y8NS7DJMV1TPQXW22E9QWHR.968272"/></t>
</abstract>
</front>
<seriesInfo name="GNUnet" value="e.V."/>
</reference>
<reference anchor="packetq" target="https://github.com/DNS-OARC/PacketQ">
<front>
<title>PacketQ, a simple tool to make SQL-queries against PCAP-files</title>
<author><organization>DNS-OARC</organization></author>
<date year="2011"/>
<abstract><t>A tool that provides a basic SQL-frontend to
PCAP-files. Outputs JSON, CSV and XML and includes a build-in
webserver with JSON-api and a nice looking AJAX GUI.</t></abstract>
</front>
</reference>
<reference anchor="passive-dns" target="https://www.first.org/conference/2005/pa
pers/florian-weimer-slides-1.pdf">
<front>
<title>Passive DNS Replication</title>
<author fullname="Florian Weimer" initials="F." surname="Weimer"/>
<date month="April" year="2005"/>
<abstract>
<t>FIRST 17</t>
</abstract>
</front>
</reference>
<reference anchor="pitfalls-of-dns-encryption" target="https://dl.acm.org/citati
on.cfm?id=2665959">
<front>
<title>Pretty Bad Privacy:Pitfalls of DNS Encryption</title>
<author fullname="Haya Shulman" surname="Shulman" initials="H"/>
<date/>
</front>
</reference>
<reference anchor="prism" target="https://en.wikipedia.org/w/index.php?title=PRI
SM_(surveillance_program)&amp;oldid=673789455">
<front>
<title>PRISM (surveillance program)</title>
<author><organization>Wikipedia</organization></author>
<date month="July" year="2015"/>
</front>
</reference>
<reference anchor="ripe-qname-measurements" target="https://labs.ripe.net/Member
s/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation">
<front>
<title>Making the DNS More Private with QNAME Minimisation</title>
<author fullname="Wouter de Vries " initials="W. de Vries "><organization>Univer
sity of Twente</organization></author>
<date month="April" year="2019"/>
</front>
</reference>
<reference anchor="sidn-entrada" target="https://www.sidnlabs.nl/downloads/yBW6h
BoaSZe4m6GJc_0b7w/2211058ab6330c7f3788141ea19d3db7/SIDN_Labs_Privacyraamwerk_Pos
ition_Paper_V1.4_ENG.pdf">
<front>
<title>A privacy framework for 'DNS big data' applications</title>
<author fullname="Cristian Hesselman" surname="Hesselman" initials="C."/>
<author fullname="Jelte Jansen" surname="Jansen" initials="J."/>
<author fullname="Maarten Wullink" surname="Wullink" initials="M."/>
<author fullname="Karin Vink" surname="Vink" initials="K."/>
<author fullname="Maarten Simon" surname="Simon" initials="M."/>
<date month="November" year="2014"/>
<abstract><t>A good analysis of DNS privacy, with quantitative
measurements showing that, "for the great majority of resolvers, therefore,
the associated IP address is personal data", and a privacy policy for
big data analysis.</t></abstract>
</front>
</reference>
<reference anchor="thomas-ditl-tcp"
target="https://indico.dns-oarc.net/event/20/session/2/contribution/15/ma
terial/slides/1.pdf">
<front>
<title>An Analysis of TCP Traffic in Root Server DITL Data</title>
<author fullname="Matt Thomas" surname="Thomas" initials="M."/>
<author fullname="Duane Wessels" surname="Wessels" initials="D."/>
<date month="October" year="2014"/>
</front>
<seriesInfo name="DNS-OARC" value="2014 Fall Workshop"/>
</reference>
<reference anchor="tor-leak" target="https://www.torproject.org/docs/faq.html.en
#WarningsAboutSOCKSandDNSInformationLeaks">
<front>
<title>DNS leaks in Tor</title>
<author><organization>Tor</organization></author>
<date year="2013"/>
</front>
</reference>
<reference anchor="yanbin-tsudik" target="http://arxiv.org/abs/0910.2472">
<front>
<title>Towards Plugging Privacy Leaks in the Domain Name System</title>
<author fullname="Yanbin Lu" surname="Yanbin" initials="L."/>
<author fullname="Gene Tsudik" surname="Tsudik" initials="G."/>
<date month="October" year="2009"/>
<abstract>
<t>Peer-to-peer computing (p2p), 2010 IEEE tenth
international conference on, IEEE, Piscataway, NJ, USA, 25 August 2010
(2010-08-25), pages 1-10, XP031752227, ISBN: 978-1-4244-7140-9</t>
<t>Actually, it is not about the DNS but about a complete replacement, using DHT
s for resolution.</t>
</abstract></front>
</reference>
</references>
<section anchor="updates-since-rfc7626" title="Updates since RFC7626"> <reference anchor="morecowbell" target="https://pdfs.semanticscholar.org
<t>Update many references; Added discussions of encrypted transports including /2610/2b99bdd6a258a98740af8217ba8da8a1e4fa.pdf">
DoT and DoH; Added section on DNS payload; Added section on authentication of <front>
servers; Added section on blocking of services. With the publishing of <title>NSA's MORECOWBELL: Knell for DNS</title>
RFC7816 on QNAME minimisation, text, references, and initial attempts to <author fullname="Christian Grothoff" surname="Grothoff" initials="C
."/>
<author fullname="Matthias Wachs" surname="Wachs" initials="M."/>
<author fullname="Monika Ermert" surname="Ermert" initials="M."/>
<author fullname="Jacob Appelbaum" surname="Appelbaum" initials="J."
/>
<date month="January" year="2015"/>
</front>
</reference>
<reference anchor="packetq" target="https://github.com/DNS-OARC/PacketQ"
>
<front>
<title>A tool that provides a basic SQL-frontend to PCAP-files</titl
e>
<author><organization>DNS-OARC</organization></author>
<date year="2020" month="October"/>
</front>
<refcontent>Release 1.4.3</refcontent>
<refcontent>commit 29a8288</refcontent>
</reference>
<reference anchor="passive-dns" target="https://www.first.org/conference
/2005/papers/florian-weimer-slides-1.pdf">
<front>
<title>Passive DNS Replication</title>
<author fullname="Florian Weimer" initials="F." surname="Weimer"/>
<date month="April" year="2005"/>
</front>
<refcontent>17th Annual FIRST Conference</refcontent>
</reference>
<reference anchor="pitfalls-of-dns-encryption" target="https://dl.acm.or
g/citation.cfm?id=2665959">
<front>
<title>Pretty Bad Privacy: Pitfalls of DNS Encryption</title>
<author fullname="Haya Shulman" surname="Shulman" initials="H."/>
<date month="November" year="2014"/>
</front>
<seriesInfo name="DOI" value="10.1145/2665943.2665959"/>
<refcontent>WPES '14: Proceedings of the 13th Workshop on Privacy in the Electro
nic Society, pp. 191-200</refcontent>
</reference>
<reference anchor="prism" target="https://en.wikipedia.org/w/index.php?t
itle=PRISM_(surveillance_program)&amp;oldid=673789455">
<front>
<title>PRISM (surveillance program)</title>
<author>
<organization>Wikipedia</organization>
</author>
<date month="July" year="2015"/>
</front>
</reference>
<reference anchor="ripe-qname-measurements" target="https://labs.ripe.ne
t/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation">
<front>
<title>Making the DNS More Private with QNAME Minimisation</title>
<author fullname="Wouter de Vries" surname="de Vries" initials="W."/
>
<date month="April" year="2019"/>
</front>
</reference>
<reference anchor="sidn-entrada" target="https://www.sidnlabs.nl/downloa
ds/yBW6hBoaSZe4m6GJc_0b7w/2211058ab6330c7f3788141ea19d3db7/SIDN_Labs_Privacyraam
werk_Position_Paper_V1.4_ENG.pdf">
<front>
<title>A privacy framework for 'DNS big data' applications</title>
<author fullname="Cristian Hesselman" surname="Hesselman" initials="
C."/>
<author fullname="Jelte Jansen" surname="Jansen" initials="J."/>
<author fullname="Maarten Wullink" surname="Wullink" initials="M."/>
<author fullname="Karin Vink" surname="Vink" initials="K."/>
<author fullname="Maarten Simon" surname="Simon" initials="M."/>
<date month="November" year="2014"/>
</front>
</reference>
<reference anchor="thomas-ditl-tcp" target="https://indico.dns-oarc.net/
event/20/session/2/contribution/15/material/slides/1.pdf">
<front>
<title>An Analysis of TCP Traffic in Root Server DITL Data</title>
<author fullname="Matt Thomas" surname="Thomas" initials="M."/>
<author fullname="Duane Wessels" surname="Wessels" initials="D."/>
<date month="October" year="2014"/>
</front>
<refcontent>DNS-OARC 2014 Fall Workshop</refcontent>
</reference>
<reference anchor="tor-leak" target="https://www.torproject.org/docs/faq
.html.en#WarningsAboutSOCKSandDNSInformationLeaks">
<front>
<title>Tor FAQs: I keep seeing these warnings about SOCKS and DNS in
formation leaks. Should I worry?</title>
<author>
<organization>Tor</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="yanbin-tsudik" target="https://arxiv.org/abs/0910.247
2">
<front>
<title>Towards Plugging Privacy Leaks in Domain Name System</title>
<author fullname="Yanbin Lu" surname="Yanbin" initials="L."/>
<author fullname="Gene Tsudik" surname="Tsudik" initials="G."/>
<date month="June" year="2010"/>
</front>
</reference>
</references>
</references>
<section anchor="updates-since-rfc7626" numbered="true" toc="default">
<name>Updates since RFC 7626</name>
<t>Many references were updated. Discussions of encrypted transports, incl
uding
DoT and DoH, and sections on DNS payload, authentication of servers, and blockin
g of services were added.
With the publishing of
<xref target="RFC7816"/> on QNAME minimization, text, references, and initial at
tempts to
measure deployment were added to reflect this. The text and references on the measure deployment were added to reflect this. The text and references on the
Snowden revelations were updated. Snowden revelations were updated.
</t> </t>
<t>The &quot;Risks overview&quot; section was changed to &quot;Scope&quot; to he <t>The "Risks Overview" section was changed to "Scope" to help clarify the
lp clarify the risks risks
being considered. Text was adding on cellular network DNS, blocking and being considered. Text on cellular network DNS, blocking, and
security. Considerations for recursive resolvers were collected and placed security was added. Considerations for recursive resolvers were collected and p
together. Addded a discussion on resolver selection. laced
</t> together. A discussion on resolver selection was added.
</section>
<section anchor="changelog" title="Changelog">
<t>draft-ietf-dprive-rfc7626-bis-08
</t>
<t>
<list style="symbols">
<t>Second batch of Editorial updates from IESG last call</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-07
</t>
<t>
<list style="symbols">
<t>First batch of Editorial updates from IESG last call</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-06
</t>
<t>
<list style="symbols">
<t>Removed Sara and Stephane as editors, made chairs as Editor.</t>
<t>Replaced the text in 6.1.1.2 with the text from the -04 version.</t>
<t>Clarified text about resolver selection in 6.1.1.</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-05
</t>
<t>
<list style="symbols">
<t>Editorial updates from second IESG last call</t>
<t>Section renumbering as suggested by Vittorio Bertola</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-04
</t>
<t>
<list style="symbols">
<t>Tsvart review: Add reference to DNS-over-QUIC, fix typo.</t>
<t>Secdir review: Add text in Section 3 on devices using many networks.</t>
<t>Update bullet in 3.4.1 on cellular encryption.</t>
<t>Section 3.5.1.1 - re-work the section to try to address multiple comments.</t
>
<t>Section 3.5.1.4 - remove this section as now covered by 3.5.1.1.</t>
<t>Section 3.5.1.5.2 - Remove several paragraphs and more directly reference
RFC8484 by including bullet points quoting text from Section 8.2 of RFC8484.
Retain the last 2 paragraphs as they are information for users, not
implementors.</t>
<t>Section 3.4.2 - some minor updates made based on specific comments.</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-03
</t>
<t>
<list style="symbols">
<t>Address 2 minor nits (typo in section 3.4.1 and adding an IANA section)</t>
<t>Minor updates from AD review</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-02
</t>
<t>
<list style="symbols">
<t>Numerous editorial corrections thanks to Mohamed Boucadair and
<list style="symbols">
<t>Minor additions to Scope section</t>
<t>New text on cellular network DNS</t>
</list></t>
<t>Additional text from Vittorio Bertola on blocking and security</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-01
</t>
<t>
<list style="symbols">
<t>Re-structure section 3.5 (was 2.5)
<list style="symbols">
<t>Collect considerations for recursive resolvers together</t>
<t>Re-work several sections here to clarify their context (e.g., ‘Rogue servers'
becomes ‘Active attacks on resolver configuration’)</t>
<t>Add discussion of resolver selection</t>
</list></t>
<t>Update text and old reference on Snowdon revelations.</t>
<t>Add text on and references to QNAME minimisation RFC and deployment measureme
nts</t>
<t>Correct outdated references</t>
<t>Clarify scope by adding a Scope section (was Risks overview)</t>
<t>Clarify what risks are considered in section 3.4.2</t>
</list>
</t>
<t>draft-ietf-dprive-rfc7626-bis-00
</t>
<t>
<list style="symbols">
<t>Rename after WG adoption</t>
<t>Use DoT acronym throughout</t>
<t>Minor updates to status of deployment and other drafts</t>
</list>
</t>
<t>draft-bortzmeyer-dprive-rfc7626-bis-02
</t>
<t>
<list style="symbols">
<t>Update various references and fix some nits.</t>
</list>
</t>
<t>draft-bortzmeyer-dprive-rfc7626-bis-01
</t>
<t>
<list style="symbols">
<t>Update reference for dickinson-bcp-op to draft-dickinson-dprive-bcp-op</t>
</list>
</t>
<t>draft-borztmeyer-dprive-rfc7626-bis-00:
</t> </t>
<t>Initial commit. Differences to RFC7626: </section>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to <contact fullname="Nathalie Boulvard"/> and to the CENTR memb
ers for the original work
that led to this document. Thanks to <contact fullname="Ondrej Sury"/> for th
e interesting
discussions. Thanks to <contact fullname="Mohsen Souissi"/> and <contact full
name="John Heidemann"/> for proofreading and
to <contact fullname="Paul Hoffman"/>, <contact fullname="Matthijs Mekking"/>
, <contact fullname="Marcos Sanz"/>, <contact fullname="Francis Dupont"/>,
<contact fullname="Allison Mankin"/>, and <contact fullname="Warren Kumari"/>
for proofreading, providing technical
remarks, and making many readability improvements. Thanks to <contact fullnam
e="Dan York"/>,
<contact fullname="Suzanne Woolf"/>, <contact fullname="Tony Finch"/>, <conta
ct fullname="Stephen Farrell"/>, <contact fullname="Peter Koch"/>, <contact full
name="Simon Josefsson"/>, and
<contact fullname="Frank Denis"/> for good written contributions. Thanks to <
contact fullname="Vittorio Bertola"/> and
<contact fullname="Mohamed Boucadair"/> for a detailed review of the -bis. An
d thanks to the IESG
members for the last remarks.
</t> </t>
<t> </section>
<list style="symbols"> <section anchor="contributions" numbered="false" toc="default">
<t>Update many references</t> <name>Contributions</name>
<t>Add discussions of encrypted transports including DoT and DoH</t> <t><contact fullname="Sara Dickinson"/> and <contact fullname="Stephane Bo
<t>Add section on DNS payload</t> rtzmeyer"/> were the original authors of the
<t>Add section on authentication of servers</t> document, and their contribution to the initial draft of this document is gre
<t>Add section on blocking of services</t> atly appreciated.
</list>
</t> </t>
</section> </section>
</back>
</back>
</rfc> </rfc>
 End of changes. 180 change blocks. 
1140 lines changed or deleted 1087 lines changed or added

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