doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7626.txt b/doc/rfc/rfc7626.txt
new file mode 100644
index 0000000..2c3eddf
--- /dev/null
+++ b/doc/rfc/rfc7626.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     S. Bortzmeyer
+Request for Comments: 7626                                         AFNIC
+Category: Informational                                      August 2015
+ISSN: 2070-1721
+
+
+                       DNS Privacy Considerations
+
+Abstract
+
+   This document describes the privacy issues associated with the use of
+   the DNS by Internet users.  It is intended to be an analysis of the
+   present situation and does not prescribe solutions.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7626.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Bortzmeyer                    Informational                     [Page 1]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     2.1.  The Alleged Public Nature of DNS Data . . . . . . . . . .   4
+     2.2.  Data in the DNS Request . . . . . . . . . . . . . . . . .   5
+     2.3.  Cache Snooping  . . . . . . . . . . . . . . . . . . . . .   6
+     2.4.  On the Wire . . . . . . . . . . . . . . . . . . . . . . .   7
+     2.5.  In the Servers  . . . . . . . . . . . . . . . . . . . . .   8
+       2.5.1.  In the Recursive Resolvers  . . . . . . . . . . . . .   8
+       2.5.2.  In the Authoritative Name Servers . . . . . . . . . .   9
+       2.5.3.  Rogue Servers . . . . . . . . . . . . . . . . . . . .  10
+     2.6.  Re-identification and Other Inferences  . . . . . . . . .  11
+     2.7.  More Information  . . . . . . . . . . . . . . . . . . . .  11
+   3.  Actual "Attacks"  . . . . . . . . . . . . . . . . . . . . . .  11
+   4.  Legalities  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17
+
+1.  Introduction
+
+   This document is an analysis of the DNS privacy issues, in the spirit
+   of Section 8 of [RFC6973].
+
+   The Domain Name System is specified in [RFC1034], [RFC1035], and many
+   later RFCs, which have never been consolidated.  It is one of the
+   most important infrastructure components of the Internet and often
+   ignored or misunderstood by Internet users (and even by many
+   professionals).  Almost every activity on the Internet starts with a
+   DNS query (and often several).  Its use has many privacy implications
+   and this is an attempt at a comprehensive and accurate list.
+
+   Let us begin with a simplified reminder of how the DNS works.  (See
+   also [DNS-TERMS].)  A client, the stub resolver, issues a DNS query
+   to a server, called the recursive resolver (also called caching
+   resolver or full resolver or recursive name server).  Let's use the
+   query "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 description that follows assumes a cold cache,
+   for instance, because the 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 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
+
+
+
+Bortzmeyer                    Informational                     [Page 2]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   turn, will refer to the example.com name servers.  The example.com
+   name server will then return the answer.  The root name servers, the
+   name servers of .com, and the name servers of example.com are called
+   authoritative name servers.  It is important, when analyzing the
+   privacy issues, to remember that the question asked to all these name
+   servers is always the original question, not a derived question.  The
+   question sent to the root name servers is "What are the AAAA records
+   for www.example.com?", not "What are the name servers of .com?".  By
+   repeating the full question, instead of just the relevant part of the
+   question to the next in line, the DNS provides more information than
+   necessary to the name server.
+
+   Because DNS relies on caching heavily, the algorithm described just
+   above is actually a bit more complicated, and not all questions are
+   sent to the authoritative name servers.  If a few seconds later the
+   stub resolver asks the recursive resolver, "What are the 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
+   query them, bypassing the root and .com.  Because there is typically
+   no caching in the stub resolver, the recursive resolver, unlike the
+   authoritative servers, sees all the DNS traffic.  (Applications, like
+   web browsers, may have some form of caching that does not follow DNS
+   rules, for instance, because it may ignore the TTL.  So, the
+   recursive resolver does not see all the name resolution activity.)
+
+   It should be noted that DNS recursive resolvers sometimes forward
+   requests to other recursive resolvers, typically bigger machines,
+   with a larger and more shared cache (and the query hierarchy can be
+   even deeper, with more than two levels of recursive resolvers).  From
+   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
+   caching in the first resolver).
+
+   Almost all this DNS traffic is currently sent in clear (unencrypted).
+   There are a few cases where there is some channel encryption, for
+   instance, in an IPsec VPN, at least between the stub resolver and the
+   resolver.
+
+   Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
+   This has practical consequences when considering encryption of the
+   traffic as a possible privacy technique.  Some encryption solutions
+   are only designed for TCP, not UDP.
+
+   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
+   triggered by different reasons.  Let's assume an eavesdropper wants
+   to know which web page is viewed by a user.  For a typical web page,
+   there are three sorts of DNS requests being issued:
+
+
+
+Bortzmeyer                    Informational                     [Page 3]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+      Primary request: this is the domain name in the URL that the user
+      typed, selected from a bookmark, or chose by clicking on an
+      hyperlink.  Presumably, this is what is of interest for the
+      eavesdropper.
+
+      Secondary requests: these are the additional requests performed by
+      the user agent (here, the web browser) without any direct
+      involvement or knowledge of the user.  For the Web, they are
+      triggered by embedded content, Cascading Style Sheets (CSS),
+      JavaScript code, embedded images, etc.  In some cases, there can
+      be dozens of domain names in different contexts on a single web
+      page.
+
+      Tertiary requests: these are the additional requests performed by
+      the DNS system 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 do additional requests to turn
+      the name servers' names into IP addresses.  Similarly, even if
+      glue records are returned, a careful recursive server will do
+      tertiary requests to verify the IP addresses of those records.
+
+   It can be noted also that, in the case of a typical web browser, more
+   DNS requests than strictly necessary are sent, for instance, to
+   prefetch resources that the user may query later or when
+   autocompleting the URL in the address bar.  Both are a big privacy
+   concern since they may leak information even about non-explicit
+   actions.  For instance, just reading a local HTML page, even without
+   selecting the hyperlinks, may trigger DNS requests.
+
+   For privacy-related terms, we will use the terminology from
+   [RFC6973].
+
+2.  Risks
+
+   This document focuses mostly on the study of privacy risks for the
+   end user (the one performing DNS requests).  We consider the risks of
+   pervasive surveillance [RFC7258] as well as risks coming from a more
+   focused surveillance.  Privacy risks for the holder of a zone (the
+   risk that someone gets the data) are discussed in [RFC5936] and
+   [RFC5155].  Non-privacy risks (such as cache poisoning) are out of
+   scope.
+
+2.1.  The Alleged Public Nature of DNS Data
+
+   It has long been claimed that "the data in the DNS is public".  While
+   this sentence makes sense for an Internet-wide lookup system, there
+   are multiple facets to the data and metadata involved that deserve a
+   more detailed look.  First, access control lists and private
+
+
+
+Bortzmeyer                    Informational                     [Page 4]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   namespaces notwithstanding, the DNS operates under the assumption
+   that public-facing authoritative name servers will respond to "usual"
+   DNS queries for any zone they are authoritative for without further
+   authentication or authorization of the client (resolver).  Due to the
+   lack of search capabilities, only a given QNAME will reveal the
+   resource records associated with that name (or that name's non-
+   existence).  In other words: one needs to know what to ask for, in
+   order to receive a response.  The zone transfer QTYPE [RFC5936] is
+   often blocked or restricted to authenticated/authorized access to
+   enforce this difference (and maybe for other reasons).
+
+   Another differentiation to be considered is between the DNS data
+   itself and a particular transaction (i.e., a DNS name lookup).  DNS
+   data and the results of a DNS query are public, within the boundaries
+   described above, and may not have any confidentiality requirements.
+   However, the same is not true of a single transaction or a sequence
+   of transactions; that transaction is not / should not be public.  A
+   typical example from outside the DNS world is: the web site of
+   Alcoholics Anonymous is public; the fact that you visit it should not
+   be.
+
+2.2.  Data in the DNS Request
+
+   The DNS request includes many fields, but two of them seem
+   particularly relevant for the privacy issues: the QNAME and the
+   source IP address. "source IP address" is used in a loose sense of
+   "source IP address + maybe source port", because the port is also in
+   the request and can be used to differentiate between several users
+   sharing an IP address (behind a Carrier-Grade NAT (CGN), for instance
+   [RFC6269]).
+
+   The QNAME is the full name sent by the user.  It gives information
+   about what the user does ("What are the MX records of example.net?"
+   means he probably wants to send email to someone at example.net,
+   which may be a domain used by only a few persons and is therefore
+   very revealing about communication relationships).  Some QNAMEs are
+   more sensitive than others.  For instance, querying the A record of a
+   well-known web statistics domain reveals very little (everybody
+   visits web sites that use this analytics service), but querying the A
+   record of www.verybad.example where verybad.example is the domain of
+   an organization that some people find offensive or objectionable may
+   create more problems for the user.  Also, sometimes, the QNAME embeds
+   the software one uses, which could be a privacy issue.  For instance,
+   _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
+   There are also some BitTorrent clients that query an SRV record for
+   _bittorrent-tracker._tcp.domain.example.
+
+
+
+
+
+Bortzmeyer                    Informational                     [Page 5]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   Another important thing about the privacy of the QNAME is the future
+   usages.  Today, the lack of privacy is an obstacle to putting
+   potentially sensitive or personally identifiable data in the DNS.  At
+   the moment, your DNS traffic might reveal that you are doing email
+   but not with whom.  If your Mail User Agent (MUA) starts looking up
+   Pretty Good Privacy (PGP) keys in the DNS [DANE-OPENPGPKEY], then
+   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.
+
+   For the communication between the stub resolver and the recursive
+   resolver, 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 communication between the recursive
+   resolver and the authoritative name 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 is now the IP address of
+   the recursive resolver that, in a way, "hides" the real user.
+   However, hiding does not always work.  Sometimes [CLIENT-SUBNET] is
+   used (see its privacy analysis in [denis-edns-client-subnet]).
+   Sometimes the end user has a personal recursive resolver on her
+   machine.  In both cases, the IP address is as sensitive as it is for
+   HTTP [sidn-entrada].
+
+   A note about IP addresses: there is currently no IETF document that
+   describes in detail all the privacy issues around IP addressing.  In
+   the meantime, the discussion here is intended to include both IPv4
+   and IPv6 source addresses.  For a number of reasons, their assignment
+   and utilization characteristics are different, which may have
+   implications for details of information leakage associated with the
+   collection of source addresses.  (For example, a specific IPv6 source
+   address seen on the public Internet is less likely than an IPv4
+   address to originate behind a CGN or other NAT.)  However, for both
+   IPv4 and IPv6 addresses, it's important to note that source addresses
+   are propagated with queries and comprise metadata about the host,
+   user, or application that originated them.
+
+2.3.  Cache Snooping
+
+   The content of recursive resolvers' caches can reveal data about the
+   clients using it (the privacy risks depend on the number of clients).
+   This information can sometimes be examined by sending DNS queries
+   with RD=0 to inspect cache content, particularly looking at the DNS
+   TTLs [grangeia.snooping].  Since this also is a reconnaissance
+   technique for subsequent cache poisoning attacks, some counter
+   measures have already been developed and deployed.
+
+
+
+
+
+Bortzmeyer                    Informational                     [Page 6]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+2.4.  On the Wire
+
+   DNS traffic can be seen by an eavesdropper like any other traffic.
+   It is typically not encrypted.  (DNSSEC, specified in [RFC4033],
+   explicitly excludes confidentiality from its goals.)  So, if an
+   initiator starts an HTTPS communication with a recipient, while the
+   HTTP traffic will be encrypted, the DNS exchange prior to it will not
+   be.  When other protocols will become more and more privacy-aware and
+   secured against surveillance, the DNS may become "the weakest link"
+   in privacy.
+
+   An important specificity of the DNS traffic is that it may take a
+   different path than the communication between the initiator and the
+   recipient.  For instance, an eavesdropper may be unable to tap the
+   wire between the initiator and the recipient but may have access to
+   the wire going to the recursive resolver, or to the authoritative
+   name servers.
+
+   The best place to tap, from an eavesdropper's point of view, is
+   clearly between the stub resolvers and the recursive resolvers,
+   because traffic is not limited by DNS caching.
+
+   The attack surface between the stub resolver and the rest of the
+   world can vary widely depending upon how the end user's computer is
+   configured.  By order of increasing attack surface:
+
+      The recursive resolver can be on the end user's computer.  In
+      (currently) a small number of cases, individuals may choose to
+      operate their own DNS resolver on their local machine.  In this
+      case, the attack surface for the connection between the stub
+      resolver and the caching resolver is limited to that single
+      machine.
+
+      The recursive resolver may be at the local network edge.  For
+      many/most enterprise networks and for some residential users, the
+      caching resolver may exist on a server at the edge of the local
+      network.  In this case, the attack surface is the local network.
+      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
+      of the overall enterprise network.  In this case, the enterprise
+      network could be thought of as similar to the Internet Access
+      Provider (IAP) network referenced below.
+
+      The recursive resolver can be in the IAP premises.  For most
+      residential users and potentially other networks, the typical case
+      is for the end user's computer to be configured (typically
+      automatically through DHCP) with the addresses of the DNS
+      recursive resolvers at the IAP.  The attack surface for on-the-
+
+
+
+Bortzmeyer                    Informational                     [Page 7]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+      wire attacks is therefore from the end-user system across the
+      local network and across the IAP network to the IAP's recursive
+      resolvers.
+
+      The recursive resolver can be a public DNS service.  Some machines
+      may be configured to use public DNS resolvers such as those
+      operated today by Google Public DNS or OpenDNS.  The end user may
+      have configured their machine to use these DNS recursive resolvers
+      themselves -- or their IAP may have chosen to use the public DNS
+      resolvers rather than operating their own resolvers.  In this
+      case, the attack surface is the entire public Internet between the
+      end user's connection and the public DNS service.
+
+2.5.  In the Servers
+
+   Using the terminology of [RFC6973], the DNS servers (recursive
+   resolvers and authoritative servers) are enablers: they facilitate
+   communication between an initiator and a recipient without being
+   directly in the communications path.  As a result, they are often
+   forgotten in risk analysis.  But, to quote again [RFC6973], "Although
+   [...] enablers may not generally be considered as attackers, they may
+   all pose privacy threats (depending on the context) because they are
+   able to observe, collect, process, and transfer privacy-relevant
+   data."  In [RFC6973] parlance, enablers become observers when they
+   start collecting data.
+
+   Many programs exist to collect and analyze DNS data at the servers --
+   from the "query log" of some programs like BIND to tcpdump and more
+   sophisticated programs like PacketQ [packetq] [packetq-list] and
+   DNSmezzo [dnsmezzo].  The organization managing the DNS server can
+   use this data itself, or it can be part of a surveillance program
+   like PRISM [prism] and pass data to an outside observer.
+
+   Sometimes, this data is kept for a long time and/or distributed to
+   third parties for research purposes [ditl] [day-at-root], security
+   analysis, or surveillance tasks.  These uses are sometimes under some
+   sort of contract, with various limitations, for instance, on
+   redistribution, given the sensitive nature of the data.  Also, there
+   are observation points in the network that gather DNS data and then
+   make it accessible to third parties for research or security purposes
+   ("passive DNS" [passive-dns]).
+
+2.5.1.  In the Recursive Resolvers
+
+   Recursive Resolvers see all the traffic since there is typically no
+   caching before them.  To summarize: your recursive resolver knows a
+   lot about you.  The resolver of a large IAP, or a large public
+   resolver, can collect data from many users.  You may get an idea of
+
+
+
+Bortzmeyer                    Informational                     [Page 8]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   the data collected by reading the privacy policy of a big public
+   resolver, e.g., <https://developers.google.com/speed/public-dns/
+   privacy>.
+
+2.5.2.  In the Authoritative Name Servers
+
+   Unlike what happens for recursive resolvers, observation capabilities
+   of authoritative name servers are limited by caching; they see only
+   the requests for which the answer was not in the cache.  For
+   aggregated statistics ("What is the percentage of LOC queries?"),
+   this is sufficient, but it prevents an observer from seeing
+   everything.  Still, the authoritative name servers see a part of the
+   traffic, and this subset may be sufficient to violate some privacy
+   expectations.
+
+   Also, the end user typically has some legal/contractual link with the
+   recursive resolver (he has chosen the IAP, or he has chosen to use a
+   given public resolver), while having no control and perhaps no
+   awareness of the role of the authoritative name servers and their
+   observation abilities.
+
+   As noted before, using a local resolver or a resolver close to the
+   machine decreases the attack surface for an on-the-wire eavesdropper.
+   But it may decrease privacy against an observer located on an
+   authoritative name server.  This authoritative name server will see
+   the IP address of the end client instead of the address of a big
+   recursive resolver shared by many users.
+
+   This "protection", when using a large resolver with many clients, is
+   no longer present if [CLIENT-SUBNET] is used because, in this case,
+   the authoritative name server sees the original IP address (or
+   prefix, depending on the setup).
+
+   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
+   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
+   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
+   usual one.)
+
+   Many domains, including TLDs, are partially hosted by third-party
+   servers, sometimes in a different country.  The contracts between the
+   domain manager and these servers may or may not take privacy into
+   account.  Whatever the contract, the third-party hoster may be honest
+   or not but, in any case, it will have to follow its local laws.  So,
+   requests to a given ccTLD may go to servers managed by organizations
+
+
+
+
+Bortzmeyer                    Informational                     [Page 9]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   outside of the ccTLD's country.  End users may not anticipate that,
+   when doing a security analysis.
+
+   Also, it seems (see the survey described in [aeris-dns]) that there
+   is a strong concentration of authoritative name servers among
+   "popular" domains (such as the Alexa Top N list).  For instance,
+   among the Alexa Top 100K, one DNS provider hosts today 10% of the
+   domains.  The ten most important DNS providers host together one
+   third of the domains.  With the control (or the ability to sniff the
+   traffic) of a few name servers, you can gather a lot of information.
+
+2.5.3.  Rogue Servers
+
+   The previous paragraphs discussed DNS privacy, assuming that all the
+   traffic was directed to the intended servers and that the potential
+   attacker was purely passive.  But, in reality, we can have active
+   attackers redirecting the traffic, not to change it but just to
+   observe it.
+
+   For instance, a rogue DHCP server, or a trusted DHCP server that has
+   had its configuration altered by malicious parties, can direct you to
+   a rogue recursive resolver.  Most of the time, it seems to be done to
+   divert traffic by providing lies for some domain names.  But it could
+   be used just to capture the traffic and gather information about you.
+   Other attacks, besides using DHCP, are possible.  The traffic from a
+   DNS client to a DNS server can be intercepted along its way from
+   originator to intended source, for instance, by transparent DNS
+   proxies in the network that will divert the traffic intended for a
+   legitimate DNS server.  This rogue server can masquerade as the
+   intended server and respond with data to the client.  (Rogue servers
+   that inject malicious data are possible, but it is a separate problem
+   not relevant to privacy.)  A rogue server may respond correctly for a
+   long period of time, thereby foregoing detection.  This may be done
+   for what could be claimed to be good reasons, such as optimization or
+   caching, but it leads to a reduction of privacy compared to if there
+   was no attacker present.  Also, malware like DNSchanger [dnschanger]
+   can change the recursive resolver in the machine's configuration, or
+   the routing itself can be subverted (for instance,
+   [ripe-atlas-turkey]).
+
+   A practical consequence of this section is that solutions for DNS
+   privacy may have to address authentication of the server, not just
+   passive sniffing.
+
+
+
+
+
+
+
+
+Bortzmeyer                    Informational                    [Page 10]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+2.6.  Re-identification and Other Inferences
+
+   An observer has access not only to the data he/she directly collects
+   but also to the results of various inferences about this data.
+
+   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
+   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
+   of the location from which the user makes those queries.  For
+   example, one study [herrmann-reidentification] found that such re-
+   identification is possible so that "73.1% of all day-to-day links
+   were correctly established, i.e. user u was either re-identified
+   unambiguously (1) or the classifier correctly reported that u was not
+   present on day t+1 any more (2)."  While that study related to web
+   browsing behavior, equally characteristic patterns may be produced
+   even in machine-to-machine communications or without a user taking
+   specific actions, e.g., at reboot time if a characteristic set of
+   services are accessed by the device.
+
+   For instance, one could imagine that an intelligence agency
+   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
+   could weaken some privacy solutions.
+
+   The IAB privacy and security program also have a work in progress
+   [RFC7624] that considers such inference-based attacks in a more
+   general framework.
+
+2.7.  More Information
+
+   Useful background information can also be found in [tor-leak] (about
+   the risk of privacy leak through DNS) and in a few academic papers:
+   [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and
+   [federrath-fuchs-herrmann-piosecny].
+
+3.  Actual "Attacks"
+
+   A very quick examination of DNS traffic may lead to the false
+   conclusion that extracting the needle from the haystack is difficult.
+   "Interesting" primary DNS requests are mixed with useless (for the
+   eavesdropper) secondary and tertiary requests (see the terminology in
+   Section 1).  But, in this time of "big data" processing, powerful
+   techniques now exist to get from the raw data to what the
+   eavesdropper is actually interested in.
+
+   Many research papers about malware detection use DNS traffic to
+   detect "abnormal" behavior that can be traced back to the activity of
+
+
+
+Bortzmeyer                    Informational                    [Page 11]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   malware on infected machines.  Yes, this research was done for the
+   good, but technically it is a privacy attack and it demonstrates the
+   power of the observation of DNS traffic.  See [dns-footprint],
+   [dagon-malware], and [darkreading-dns].
+
+   Passive DNS systems [passive-dns] allow reconstruction of the data of
+   sometimes an entire zone.  They are used for many reasons -- some
+   good, some bad.  Well-known passive DNS systems keep only the DNS
+   responses, and not the source IP address of the client, precisely for
+   privacy reasons.  Other passive DNS systems may not be so careful.
+   And there is still the potential problems with revealing QNAMEs.
+
+   The revelations (from the Edward Snowden documents, which were leaked
+   from the National Security Agency (NSA)) of the MORECOWBELL
+   surveillance program [morecowbell], which uses the DNS, both
+   passively and actively, to surreptitiously gather information about
+   the users, is another good example showing that the lack of privacy
+   protections in the DNS is actively exploited.
+
+4.  Legalities
+
+   To our knowledge, there are no specific privacy laws for DNS data, in
+   any country.  Interpreting general privacy laws like
+   [data-protection-directive] (European Union) in the context of DNS
+   traffic data is not an easy task, and we do not know a court
+   precedent here.  See an interesting analysis in [sidn-entrada].
+
+5.  Security Considerations
+
+   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 and compromises they imply), much less define solutions.
+   Possible solutions to the issues described here are discussed in
+   other documents (currently too many to all be mentioned); see, for
+   instance, [QNAME-MINIMIZATION] for the minimization of data or
+   [TLS-FOR-DNS] about encryption.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <http://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+
+
+Bortzmeyer                    Informational                    [Page 12]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+              Morris, J., Hansen, M., and R. Smith, "Privacy
+              Considerations for Internet Protocols", RFC 6973,
+              DOI 10.17487/RFC6973, July 2013,
+              <http://www.rfc-editor.org/info/rfc6973>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <http://www.rfc-editor.org/info/rfc7258>.
+
+6.2.  Informative References
+
+   [aeris-dns]
+              Vinot, N., "Vie privee: et le DNS alors?", (In French),
+              2015,
+              <https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.
+
+   [castillo-garcia]
+              Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous
+              Resolution of DNS Queries", 2008,
+              <http://deic.uab.es/~joaquin/papers/is08.pdf>.
+
+   [CLIENT-SUBNET]
+              Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,
+              "Client Subnet in DNS Queries", Work in Progress,
+              draft-ietf-dnsop-edns-client-subnet-02, July 2015.
+
+   [dagon-malware]
+              Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a
+              Malicious Resolution Authority", ISC/OARC Workshop, 2007,
+              <https://www.dns-oarc.net/files/workshop-2007/
+              Dagon-Resolution-corruption.pdf>.
+
+   [DANE-OPENPGPKEY]
+              Wouters, P., "Using DANE to Associate OpenPGP public keys
+              with email addresses", Work in Progress,
+              draft-ietf-dane-openpgpkey-03, April 2015.
+
+   [darkreading-dns]
+              Lemos, R., "Got Malware? Three Signs Revealed In DNS
+              Traffic", InformationWeek Dark Reading, May 2013,
+              <http://www.darkreading.com/analytics/security-monitoring/
+              got-malware-three-signs-revealed-in-dns-traffic/d/
+              d-id/1139680>.
+
+
+
+
+
+
+
+Bortzmeyer                    Informational                    [Page 13]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   [data-protection-directive]
+              European Parliament, "Directive 95/46/EC of the European
+              Pariament and of the council on the protection of
+              individuals with regard to the processing of personal data
+              and on the free movement of such data", Official Journal L
+              281, pp. 0031 - 0050, November 1995,
+              <http://eur-lex.europa.eu/LexUriServ/
+              LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.
+
+   [day-at-root]
+              Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A
+              Day at the Root of the Internet", ACM SIGCOMM Computer
+              Communication Review, Vol. 38, Number 5, DOI
+              10.1145/1452335.1452341, October 2008,
+              <http://www.sigcomm.org/sites/default/files/ccr/
+              papers/2008/October/1452335-1452341.pdf>.
+
+   [denis-edns-client-subnet]
+              Denis, F., "Security and privacy issues of edns-client-
+              subnet", August 2013, <https://00f.net/2013/08/07/
+              edns-client-subnet/>.
+
+   [ditl]     CAIDA, "A Day in the Life of the Internet (DITL)", 2002,
+              <http://www.caida.org/projects/ditl/>.
+
+   [dns-footprint]
+              Stoner, E., "DNS Footprint of Malware", OARC Workshop,
+              October 2010, <https://www.dns-oarc.net/files/
+              workshop-201010/OARC-ers-20101012.pdf>.
+
+   [DNS-TERMS]
+              Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", Work in Progress,
+              draft-ietf-dnsop-dns-terminology-03, June 2015.
+
+   [dnschanger]
+              Wikipedia, "DNSChanger", October 2013,
+              <https://en.wikipedia.org/w/
+              index.php?title=DNSChanger&oldid=578749672>.
+
+   [dnsmezzo] Bortzmeyer, S., "DNSmezzo", 2009,
+              <http://www.dnsmezzo.net/>.
+
+
+
+
+
+
+
+
+
+Bortzmeyer                    Informational                    [Page 14]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   [fangming-hori-sakurai]
+              Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of
+              Privacy Disclosure in DNS Query", 2007 International
+              Conference on Multimedia and Ubiquitous Engineering (MUE
+              2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957,
+              DOI 10.1109/MUE.2007.84, April 2007,
+              <http://dl.acm.org/citation.cfm?id=1262690.1262986>.
+
+   [federrath-fuchs-herrmann-piosecny]
+              Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny,
+              "Privacy-Preserving DNS: Analysis of Broadcast, Range
+              Queries and Mix-based Protection Methods", Computer
+              Security ESORICS 2011, Springer, page(s) 665-683, ISBN
+              978-3-642-23821-5, 2011,
+              <https://svs.informatik.uni-hamburg.de/publications/2011/
+              2011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.
+
+   [grangeia.snooping]
+              Grangeia, L., "DNS Cache Snooping or Snooping the Cache
+              for Fun and Profit", February 2004,
+              <http://www.msit2005.mut.ac.th/msit_media/1_2551/nete4630/
+              materials/20080718130017Hc.pdf>.
+
+   [herrmann-reidentification]
+              Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
+              "Analyzing Characteristic Host Access Patterns for
+              Re-Identification of Web User Sessions",
+              DOI 10.1007/978-3-642-27937-9_10, 2012,
+              <http://epub.uni-regensburg.de/21103/1/
+              Paper_PUL_nordsec_published.pdf>.
+
+   [morecowbell]
+              Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
+              "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January
+              2015, <https://gnunet.org/morecowbell>.
+
+   [packetq]  Dot SE, "PacketQ, a simple tool to make SQL-queries
+              against PCAP-files", 2011,
+              <https://github.com/dotse/packetq/wiki>.
+
+   [packetq-list]
+              PacketQ, "PacketQ Mailing List",
+              <http://lists.iis.se/mailman/listinfo/packetq>.
+
+   [passive-dns]
+              Weimer, F., "Passive DNS Replication", April 2005,
+              <http://www.enyo.de/fw/software/dnslogger/#2>.
+
+
+
+
+Bortzmeyer                    Informational                    [Page 15]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   [prism]    Wikipedia, "PRISM (surveillance program)", July 2015,
+              <https://en.wikipedia.org/w/index.php?title=PRISM_
+              (surveillance_program)&oldid=673789455>.
+
+   [QNAME-MINIMIZATION]
+              Bortzmeyer, S., "DNS query name minimisation to improve
+              privacy", Work in Progress,
+              draft-ietf-dnsop-qname-minimisation-04, June 2015.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <http://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
+              <http://www.rfc-editor.org/info/rfc5155>.
+
+   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
+              <http://www.rfc-editor.org/info/rfc5936>.
+
+   [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
+              P. Roberts, "Issues with IP Address Sharing", RFC 6269,
+              DOI 10.17487/RFC6269, June 2011,
+              <http://www.rfc-editor.org/info/rfc6269>.
+
+   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
+              Trammell, B., Huitema, C., and D. Borkmann,
+              "Confidentiality in the Face of Pervasive Surveillance: A
+              Threat Model and Problem Statement", RFC 7624,
+              DOI 10.17487/RFC7624, August 2015,
+              <http://www.rfc-editor.org/info/rfc7624>.
+
+   [ripe-atlas-turkey]
+              Aben, E., "A RIPE Atlas View of Internet Meddling in
+              Turkey", March 2014,
+              <https://labs.ripe.net/Members/emileaben/
+              a-ripe-atlas-view-of-internet-meddling-in-turkey>.
+
+   [sidn-entrada]
+              Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.
+              Simon, "A privacy framework for 'DNS big data'
+              applications", November 2014,
+              <https://www.sidnlabs.nl/uploads/tx_sidnpublications/
+              SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.
+
+
+
+
+Bortzmeyer                    Informational                    [Page 16]
+
+RFC 7626                       DNS Privacy                   August 2015
+
+
+   [thomas-ditl-tcp]
+              Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in
+              Root Server DITL Data", DNS-OARC 2014 Fall Workshop,
+              October 2014, <https://indico.dns-oarc.net/event/20/
+              session/2/contribution/15/material/slides/1.pdf>.
+
+   [TLS-FOR-DNS]
+              Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
+              and P. Hoffman, "TLS for DNS: Initiation and Performance
+              Considerations", Work in Progress, draft-ietf-dprive-
+              start-tls-for-dns-01, July 2015.
+
+   [tor-leak] Tor, "DNS leaks in Tor", 2013,
+              <https://www.torproject.org/docs/
+              faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.
+
+   [yanbin-tsudik]
+              Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks
+              in the Domain Name System", October 2009,
+              <http://arxiv.org/abs/0910.2472>.
+
+Acknowledgments
+
+   Thanks to Nathalie Boulvard and to the CENTR members for the original
+   work that led to this document.  Thanks to Ondrej Sury for the
+   interesting discussions.  Thanks to Mohsen Souissi and John Heidemann
+   for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,
+   Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for
+   proofreading, providing technical remarks, and making many
+   readability improvements.  Thanks to Dan York, Suzanne Woolf, Tony
+   Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis
+   for good written contributions.  And thanks to the IESG members for
+   the last remarks.
+
+Author's Address
+
+   Stephane Bortzmeyer
+   AFNIC
+   1, rue Stephenson
+   Montigny-le-Bretonneux  78180
+   France
+
+   Phone: +33 1 39 30 83 46
+   Email: bortzmeyer+ietf@nic.fr
+   URI:   http://www.afnic.fr/
+
+
+
+
+
+
+Bortzmeyer                    Informational                    [Page 17]
+