1 Internet Engineering Task Force (IETF)                  T. Wicinski, Ed.   
    2 Request for Comments: 9076                                     July 2021   
    3 Obsoletes: 7626                                                            
    4 Category: Informational                                                    
    5 ISSN: 2070-1721                                                            
    8                        DNS Privacy Considerations                          
   10 Abstract                                                                   
   12    This document describes the privacy issues associated with the use of   
   13    the DNS by Internet users.  It provides general observations about      
   14    typical current privacy practices.  It is intended to be an analysis    
   15    of the present situation and does not prescribe solutions.  This        
   16    document obsoletes RFC 7626.                                            
   18 Status of This Memo                                                        
   20    This document is not an Internet Standards Track specification; it is   
   21    published for informational purposes.                                   
   23    This document is a product of the Internet Engineering Task Force       
   24    (IETF).  It represents the consensus of the IETF community.  It has     
   25    received public review and has been approved for publication by the     
   26    Internet Engineering Steering Group (IESG).  Not all documents          
   27    approved by the IESG are candidates for any level of Internet           
   28    Standard; see Section 2 of RFC 7841.                                    
   30    Information about the current status of this document, any errata,      
   31    and how to provide feedback on it may be obtained at                    
   32    https://www.rfc-editor.org/info/rfc9076.                                
   34 Copyright Notice                                                           
   36    Copyright (c) 2021 IETF Trust and the persons identified as the         
   37    document authors.  All rights reserved.                                 
   39    This document is subject to BCP 78 and the IETF Trust's Legal           
   40    Provisions Relating to IETF Documents                                   
   41    (https://trustee.ietf.org/license-info) in effect on the date of        
   42    publication of this document.  Please review these documents            
   43    carefully, as they describe your rights and restrictions with respect   
   44    to this document.  Code Components extracted from this document must    
   45    include Simplified BSD License text as described in Section 4.e of      
   46    the Trust Legal Provisions and are provided without warranty as         
   47    described in the Simplified BSD License.                                
   49 Table of Contents                                                          
   51    1.  Introduction                                                        
   52    2.  Scope                                                               
   53    3.  Risks                                                               
   54    4.  Risks in the DNS Data                                               
   55      4.1.  The Public Nature of DNS Data                                   
   56      4.2.  Data in the DNS Request                                         
   57        4.2.1.  Data in the DNS Payload                                     
   58      4.3.  Cache Snooping                                                  
   59    5.  Risks on the Wire                                                   
   60      5.1.  Unencrypted Transports                                          
   61      5.2.  Encrypted Transports                                            
   62    6.  Risks in the Servers                                                
   63      6.1.  In the Recursive Resolvers                                      
   64        6.1.1.  Resolver Selection                                          
   65        6.1.2.  Active Attacks on Resolver Configuration                    
   66        6.1.3.  Blocking of DNS Resolution Services                         
   67        6.1.4.  Encrypted Transports and Recursive Resolvers                
   68      6.2.  In the Authoritative Name Servers                               
   69    7.  Other Risks                                                         
   70      7.1.  Re-identification and Other Inferences                          
   71      7.2.  More Information                                                
   72    8.  Actual "Attacks"                                                    
   73    9.  Legalities                                                          
   74    10. Security Considerations                                             
   75    11. IANA Considerations                                                 
   76    12. References                                                          
   77      12.1.  Normative References                                           
   78      12.2.  Informative References                                         
   79    Appendix A.  Updates since RFC 7626                                     
   80    Acknowledgments                                                         
   81    Contributions                                                           
   82    Author's Address                                                        
   84 1.  Introduction                                                           
   86    This document is an analysis of the DNS privacy issues, in the spirit   
   87    of Section 8 of [RFC6973].                                              
   89    The Domain Name System (DNS) is specified in [RFC1034], [RFC1035],      
   90    and many later RFCs, which have never been consolidated.  It is one     
   91    of the most important infrastructure components of the Internet and     
   92    is often ignored or misunderstood by Internet users (and even by many   
   93    professionals).  Almost every activity on the Internet starts with a    
   94    DNS query (and often several).  Its use has many privacy                
   95    implications, and this document is an attempt at a comprehensive and    
   96    accurate list.                                                          
   98    Let us begin with a simplified reminder of how the DNS works (see       
   99    also [RFC8499]).  A client, the stub resolver, issues a DNS query to    
  100    a server called the recursive resolver (also called caching resolver,   
  101    full resolver, or recursive name server).  Let's use the query "What    
  102    are the AAAA records for www.example.com?" as an example.  AAAA is      
  103    the QTYPE (Query Type), and www.example.com is the QNAME (Query         
  104    Name).  (The description that follows assumes a cold cache, for         
  105    instance, because the server just started.)  The recursive resolver     
  106    will first query the root name servers.  In most cases, the root name   
  107    servers will send a referral.  In this example, the referral will be    
  108    to the .com name servers.  The resolver repeats the query to one of     
  109    the .com name servers.  The .com name servers, in turn, will refer to   
  110    the example.com name servers.  The example.com name servers will then   
  111    return the answers.  The root name servers, the name servers of .com,   
  112    and the name servers of example.com are called authoritative name       
  113    servers.  It is important, when analyzing the privacy issues, to        
  114    remember that the question asked to all these name servers is always    
  115    the original question, not a derived question.  The question sent to    
  116    the root name servers is "What are the AAAA records for                 
  117    www.example.com?", not "What are the name servers of .com?".  By        
  118    repeating the full question, instead of just the relevant part of the   
  119    question to the next in line, the DNS provides more information than    
  120    necessary to the name server.  In this simplified description,          
  121    recursive resolvers do not implement QNAME minimization as described    
  122    in [RFC7816], which will only send the relevant part of the question    
  123    to the upstream name server.                                            
  125    DNS relies heavily on caching, so the algorithm described above is      
  126    actually a bit more complicated, and not all questions are sent to      
  127    the authoritative name servers.  If the stub resolver asks the          
  128    recursive resolver a few seconds later, "What are the SRV records of    
  129    _xmpp-server._tcp.example.com?", the recursive resolver will remember   
  130    that it knows the name servers of example.com and will just query       
  131    them, bypassing the root and .com.  Because there is typically no       
  132    caching in the stub resolver, the recursive resolver, unlike the        
  133    authoritative servers, sees all the DNS traffic.  (Applications, like   
  134    web browsers, may have some form of caching that does not follow DNS    
  135    rules, for instance, because it may ignore the TTL.  So, the            
  136    recursive resolver does not see all the name resolution activity.)      
  138    It should be noted that DNS recursive resolvers sometimes forward       
  139    requests to other recursive resolvers, typically bigger machines,       
  140    with a larger and more shared cache (and the query hierarchy can be     
  141    even deeper, with more than two levels of recursive resolvers).  From   
  142    the point of view of privacy, these forwarders are like resolvers       
  143    except that they do not see all of the requests being made (due to      
  144    caching in the first resolver).                                         
  146    At the time of writing, almost all this DNS traffic is currently sent   
  147    unencrypted.  However, there is increasing deployment of DNS over TLS   
  148    (DoT) [RFC7858] and DNS over HTTPS (DoH) [RFC8484], particularly in     
  149    mobile devices, browsers, and by providers of anycast recursive DNS     
  150    resolution services.  There are a few cases where there is some         
  151    alternative channel encryption, for instance, in an IPsec VPN tunnel,   
  152    at least between the stub resolver and the resolver.  Some recent       
  153    analysis on the service quality of encrypted DNS traffic can be found   
  154    in [dns-over-encryption].                                               
  156    Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].      
  157    This has practical consequences when considering encryption of the      
  158    traffic as a possible privacy technique.  Some encryption solutions     
  159    are only designed for TCP, not UDP, although new solutions are still    
  160    emerging [RFC9000] [DPRIVE-DNSOQUIC].                                   
  162    Another important point to keep in mind when analyzing the privacy      
  163    issues of DNS is the fact that DNS requests received by a server are    
  164    triggered for different reasons.  Let's assume an eavesdropper wants    
  165    to know which web page is viewed by a user.  For a typical web page,    
  166    there are three sorts of DNS requests being issued:                     
  168    Primary request:                                                        
  169       This is the domain name in the URL that the user typed, selected     
  170       from a bookmark, or chose by clicking on a hyperlink.  Presumably,   
  171       this is what is of interest for the eavesdropper.                    
  173    Secondary requests:                                                     
  174       These are the additional requests performed by the user agent        
  175       (here, the web browser) without any direct involvement or            
  176       knowledge of the user.  For the Web, they are triggered by           
  177       embedded content, Cascading Style Sheets (CSS), JavaScript code,     
  178       embedded images, etc.  In some cases, there can be dozens of         
  179       domain names in different contexts on a single web page.             
  181    Tertiary requests:                                                      
  182       These are the additional requests performed by the DNS service       
  183       itself.  For instance, if the answer to a query is a referral to a   
  184       set of name servers and the glue records are not returned, the       
  185       resolver will have to send additional requests to turn the name      
  186       servers' names into IP addresses.  Similarly, even if glue records   
  187       are returned, a careful recursive server will send tertiary          
  188       requests to verify the IP addresses of those records.                
  190    It can also be noted that, in the case of a typical web browser, more   
  191    DNS requests than strictly necessary are sent, for instance, to         
  192    prefetch resources that the user may query later or when                
  193    autocompleting the URL in the address bar.  Both are a significant      
  194    privacy concern since they may leak information even about non-         
  195    explicit actions.  For instance, just reading a local HTML page, even   
  196    without selecting the hyperlinks, may trigger DNS requests.             
  198    Privacy-related terminology is from [RFC6973].  This document           
  199    obsoletes [RFC7626].                                                    
  201 2.  Scope                                                                  
  203    This document focuses mostly on the study of privacy risks for the      
  204    end user (the one performing DNS requests).  The risks of pervasive     
  205    surveillance [RFC7258] are considered as well as risks coming from a    
  206    more focused surveillance.  In this document, the term "end user" is    
  207    used as defined in [RFC8890].                                           
  209    This document does not attempt a comparison of specific privacy         
  210    protections provided by individual networks or organizations; it        
  211    makes only general observations about typical current practices.        
  213    Privacy risks for the holder of a zone (the risk that someone gets      
  214    the data) are discussed in [RFC5155] and [RFC5936].                     
  216    Privacy risks for recursive operators (including access providers and   
  217    operators in enterprise networks) such as leakage of private            
  218    namespaces or blocklists are out of scope for this document.            
  220    Non-privacy risks (e.g., security-related considerations such as        
  221    cache poisoning) are also out of scope.                                 
  223    The privacy risks associated with the use of other protocols that       
  224    make use of DNS information are not considered here.                    
  226 3.  Risks                                                                  
  228    The following four sections outline the privacy considerations          
  229    associated with different aspects of the DNS for the end user.  When    
  230    reading these sections, it needs to be kept in mind that many of the    
  231    considerations (for example, recursive resolver and transport           
  232    protocol) can be specific to the network context that a device is       
  233    using at a given point in time.  A user may have many devices, and      
  234    each device might utilize many different networks (e.g., home, work,    
  235    public, or cellular) over a period of time or even concurrently.  An    
  236    exhaustive analysis of the privacy considerations for an individual     
  237    user would need to take into account the set of devices used and the    
  238    multiple dynamic contexts of each device.  This document does not       
  239    attempt such a complex analysis; instead, it presents an overview of    
  240    the various considerations that could form the basis of such an         
  241    analysis.                                                               
  243 4.  Risks in the DNS Data                                                  
  245 4.1.  The Public Nature of DNS Data                                        
  247    It has been stated that "the data in the DNS is public".  This          
  248    sentence makes sense for an Internet-wide lookup system, and there      
  249    are multiple facets to the data and metadata involved that deserve a    
  250    more detailed look.  First, access control lists (ACLs) and private     
  251    namespaces notwithstanding, the DNS operates under the assumption       
  252    that public-facing authoritative name servers will respond to "usual"   
  253    DNS queries for any zone they are authoritative for, without further    
  254    authentication or authorization of the client (resolver).  Due to the   
  255    lack of search capabilities, only a given QNAME will reveal the         
  256    resource records associated with that name (or that name's              
  257    nonexistence).  In other words: one needs to know what to ask for in    
  258    order to receive a response.  There are many ways in which supposedly   
  259    "private" resources currently leak.  A few examples are DNSSEC NSEC     
  260    zone walking [RFC4470], passive DNS services [passive-dns], etc.  The   
  261    zone transfer QTYPE [RFC5936] is often blocked or restricted to         
  262    authenticated/authorized access to enforce this difference (and maybe   
  263    for other reasons).                                                     
  265    Another difference between the DNS data and a particular DNS            
  266    transaction (i.e., a DNS name lookup): DNS data and the results of a    
  267    DNS query are public, within the boundaries described above, and may    
  268    not have any confidentiality requirements.  However, the same is not    
  269    true of a single transaction or a sequence of transactions; those       
  270    transactions are not / should not be public.  A single transaction      
  271    reveals both the originator of the query and the query contents; this   
  272    potentially leaks sensitive information about a specific user.  A       
  273    typical example from outside the DNS world is that the website of       
  274    Alcoholics Anonymous is public but the fact that you visit it should    
  275    not be.  Furthermore, the ability to link queries reveals information   
  276    about individual use patterns.                                          
  278 4.2.  Data in the DNS Request                                              
  280    The DNS request includes many fields, but two of them seem              
  281    particularly relevant for the privacy issues: the QNAME and the         
  282    source IP address.  "Source IP address" is used in a loose sense of     
  283    "source IP address + maybe source port number", because the port        
  284    number is also in the request and can be used to differentiate          
  285    between several users sharing an IP address (behind a Carrier-Grade     
  286    NAT (CGN), for instance [RFC6269]).                                     
  288    The QNAME is the full name sent by the user.  It gives information      
  289    about what the user does ("What are the MX records of example.net?"     
  290    means they probably want to send email to someone at example.net,       
  291    which may be a domain used by only a few persons and is therefore       
  292    very revealing about communication relationships).  Some QNAMEs are     
  293    more sensitive than others.  For instance, querying the A record of a   
  294    well-known web statistics domain reveals very little (everybody         
  295    visits websites that use this analytics service), but querying the A    
  296    record of www.verybad.example where verybad.example is the domain of    
  297    an organization that some people find offensive or objectionable may    
  298    create more problems for the user.  Also, sometimes, the QNAME embeds   
  299    the software one uses, which could be a privacy issue (for instance,    
  300    _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.        
  301    There are also some BitTorrent clients that query an SRV record for     
  302    _bittorrent-tracker._tcp.domain.example.                                
  304    Another important thing about the privacy of the QNAME is future        
  305    usages.  Today, the lack of privacy is an obstacle to putting           
  306    potentially sensitive or personally identifiable data in the DNS.  At   
  307    the moment, your DNS traffic might reveal that you are exchanging       
  308    emails but not with whom.  If your Mail User Agent (MUA) starts         
  309    looking up Pretty Good Privacy (PGP) keys in the DNS [RFC7929], then    
  310    privacy becomes a lot more important.  And email is just an example;    
  311    there would be other really interesting uses for a more privacy-        
  312    friendly DNS.                                                           
  314    For the communication between the stub resolver and the recursive       
  315    resolver, the source IP address is the address of the user's machine.   
  316    Therefore, all the issues and warnings about collection of IP           
  317    addresses apply here.  For the communication between the recursive      
  318    resolver and the authoritative name servers, the source IP address      
  319    has a different meaning; it does not have the same status as the        
  320    source address in an HTTP connection.  It is typically the IP address   
  321    of the recursive resolver that, in a way, "hides" the real user.        
  322    However, hiding does not always work.  The edns-client-subnet (ECS)     
  323    EDNS0 option [RFC7871] is sometimes used (see one privacy analysis in   
  324    [denis-edns-client-subnet]).  Sometimes the end user has a personal     
  325    recursive resolver on their machine.  In both cases, the IP address     
  326    originating queries to the authoritative server is as sensitive as it   
  327    is for HTTP [sidn-entrada].                                             
  329    A note about IP addresses: there is currently no IETF document that     
  330    describes in detail all the privacy issues around IP addressing in      
  331    general, although [RFC7721] does discuss privacy considerations for     
  332    IPv6 address generation mechanisms.  In the meantime, the discussion    
  333    here is intended to include both IPv4 and IPv6 source addresses.  For   
  334    a number of reasons, their assignment and utilization characteristics   
  335    are different, which may have implications for details of information   
  336    leakage associated with the collection of source addresses.  (For       
  337    example, a specific IPv6 source address seen on the public Internet     
  338    is less likely than an IPv4 address to originate behind an address-     
  339    sharing scheme.)  However, for both IPv4 and IPv6 addresses, it is      
  340    important to note that source addresses are propagated with queries     
  341    via the ECS option and comprise metadata about the host, user, or       
  342    application that originated them.                                       
  344 4.2.1.  Data in the DNS Payload                                            
  346    At the time of writing, there are no standardized client identifiers    
  347    contained in the DNS payload itself (ECS, as described in [RFC7871],    
  348    is widely used; however, [RFC7871] is only an Informational RFC).       
  350    DNS Cookies [RFC7873] are a lightweight DNS transaction security        
  351    mechanism that provides limited protection against a variety of         
  352    increasingly common denial-of-service and amplification/forgery or      
  353    cache poisoning attacks by off-path attackers.  It is noted, however,   
  354    that they are designed to just verify IP addresses (and should change   
  355    once a client's IP address changes), but they are not designed to       
  356    actively track users (like HTTP cookies).                               
  358    There are anecdotal accounts of Media Access Control (MAC) addresses    
  359    (https://lists.dns-oarc.net/pipermail/dns-                              
  360    operations/2016-January/014143.html) and even user names being          
  361    inserted in nonstandard EDNS(0) options [RFC6891] for stub-to-          
  362    resolver communications to support proprietary functionality            
  363    implemented at the resolver (e.g., parental filtering).                 
  365 4.3.  Cache Snooping                                                       
  367    The content of recursive resolvers' caches can reveal data about the    
  368    clients using it (the privacy risks depend on the number of clients).   
  369    This information can sometimes be examined by sending DNS queries       
  370    with RD=0 to inspect cache content, particularly looking at the DNS     
  371    TTLs [grangeia.snooping].  Since this also is a reconnaissance          
  372    technique for subsequent cache poisoning attacks, some                  
  373    countermeasures have already been developed and deployed                
  374    [cache-snooping-defence].                                               
  376 5.  Risks on the Wire                                                      
  378 5.1.  Unencrypted Transports                                               
  380    For unencrypted transports, DNS traffic can be seen by an               
  381    eavesdropper like any other traffic.  (DNSSEC, specified in             
  382    [RFC4033], explicitly excludes confidentiality from its goals.)  So,    
  383    if an initiator starts an HTTPS communication with a recipient, the     
  384    HTTP traffic will be encrypted, but the DNS exchange prior to it will   
  385    not be.  When other protocols become more and more privacy aware and    
  386    secured against surveillance (e.g., [RFC8446], [RFC9000]), the use of   
  387    unencrypted transports for DNS may become "the weakest link" in         
  388    privacy.  It is noted that, at the time of writing, there is ongoing    
  389    work attempting to encrypt the Server Name Identification (SNI) in      
  390    the TLS handshake [RFC8744], which is one of the last remaining non-    
  391    DNS cleartext identifiers of a connection target.                       
  393    An important specificity of the DNS traffic is that it may take a       
  394    different path than the communication between the initiator and the     
  395    recipient.  For instance, an eavesdropper may be unable to tap the      
  396    wire between the initiator and the recipient but may have access to     
  397    the wire going to the recursive resolver or to the authoritative name   
  398    servers.                                                                
  400    The best place to tap, from an eavesdropper's point of view, is         
  401    clearly between the stub resolvers and the recursive resolvers,         
  402    because traffic is not limited by DNS caching.                          
  404    The attack surface between the stub resolver and the rest of the        
  405    world can vary widely depending upon how the end user's device is       
  406    configured.  By order of increasing attack surface:                     
  408    *  The recursive resolver can be on the end user's device.  In          
  409       (currently) a small number of cases, individuals may choose to       
  410       operate their own DNS resolver on their local machine.  In this      
  411       case, the attack surface for the connection between the stub         
  412       resolver and the caching resolver is limited to that single          
  413       machine.  The recursive resolver will expose data to authoritative   
  414       resolvers as discussed in Section 6.2.                               
  416    *  The recursive resolver may be at the local network edge.  For        
  417       many/most enterprise networks and for some residential networks,     
  418       the caching resolver may exist on a server at the edge of the        
  419       local network.  In this case, the attack surface is the local        
  420       network.  Note that in large enterprise networks, the DNS resolver   
  421       may not be located at the edge of the local network but rather at    
  422       the edge of the overall enterprise network.  In this case, the       
  423       enterprise network could be thought of as similar to the Internet    
  424       Access Provider (IAP) network referenced below.                      
  426    *  The recursive resolver can be in the IAP network.  For most          
  427       residential networks and potentially other networks, the typical     
  428       case is for the user's device to be configured (typically            
  429       automatically through DHCP or relay agent options) with the          
  430       addresses of the DNS proxy in the Customer Premises Equipment        
  431       (CPE), which in turn points to the DNS recursive resolvers at the    
  432       IAP.  The attack surface for on-the-wire attacks is therefore from   
  433       the end user system across the local network and across the IAP      
  434       network to the IAP's recursive resolvers.                            
  436    *  The recursive resolver can be a public DNS service (or a privately   
  437       run DNS resolver hosted on the public Internet).  Some machines      
  438       may be configured to use public DNS resolvers such as those          
  439       operated by Google Public DNS or OpenDNS.  The user may have         
  440       configured their machine to use these DNS recursive resolvers        
  441       themselves -- or their IAP may have chosen to use the public DNS     
  442       resolvers rather than operating their own resolvers.  In this        
  443       case, the attack surface is the entire public Internet between the   
  444       user's connection and the public DNS service.  It can be noted       
  445       that if the user selects a single resolver with a small client       
  446       population (even when using an encrypted transport), it can          
  447       actually serve to aid tracking of that user as they move across      
  448       network environments.                                                
  450    It is also noted that, typically, a device connected _only_ to a        
  451    modern cellular network is                                              
  453    *  directly configured with only the recursive resolvers of the IAP     
  454       and                                                                  
  456    *  afforded some level of protection against some types of              
  457       eavesdropping for all traffic (including DNS traffic) due to the     
  458       cellular network link-layer encryption.                              
  460    The attack surface for this specific scenario is not considered here.   
  462 5.2.  Encrypted Transports                                                 
  464    The use of encrypted transports directly mitigates passive              
  465    surveillance of the DNS payload; however, some privacy attacks are      
  466    still possible.  This section enumerates the residual privacy risks     
  467    to an end user when an attacker can passively monitor encrypted DNS     
  468    traffic flows on the wire.                                              
  470    These are cases where user identification, fingerprinting, or           
  471    correlations may be possible due to the use of certain transport        
  472    layers or cleartext/observable features.  These issues are not          
  473    specific to DNS, but DNS traffic is susceptible to these attacks when   
  474    using specific transports.                                              
  476    Some general examples exist; for example, certain studies highlight     
  477    that the OS fingerprint values (http://netres.ec/?b=11B99BD) of IPv4    
  478    TTL, IPv6 Hop Limit, or TCP Window size can be used to fingerprint      
  479    client OSes or that various techniques can be used to de-NAT DNS        
  480    queries [dns-de-nat].                                                   
  482    Note that even when using encrypted transports, the use of cleartext    
  483    transport options to decrease latency can provide correlation of a      
  484    user's connections, e.g., using TCP Fast Open [RFC7413].                
  486    Implementations that support encrypted transports also commonly reuse   
  487    connections for multiple DNS queries to optimize performance (e.g.,     
  488    via DNS pipelining or HTTPS multiplexing).  Default configuration       
  489    options for encrypted transports could, in principle, fingerprint a     
  490    specific client application.  For example:                              
  492    *  TLS version or cipher suite selection                                
  494    *  session resumption                                                   
  496    *  the maximum number of messages to send and                           
  498    *  a maximum connection time before closing a connections and           
  499       reopening.                                                           
  501    If libraries or applications offer user configuration of such options   
  502    (e.g., [getdns]), then they could, in principle, help to identify a     
  503    specific user.  Users may want to use only the defaults to avoid this   
  504    issue.                                                                  
  506    While there are known attacks on older versions of TLS, the most        
  507    recent recommendations [RFC7525] and the development of TLS 1.3         
  508    [RFC8446] largely mitigate those.                                       
  510    Traffic analysis of unpadded encrypted traffic is also possible         
  511    [pitfalls-of-dns-encryption] because the sizes and timing of            
  512    encrypted DNS requests and responses can be correlated to unencrypted   
  513    DNS requests upstream of a recursive resolver.                          
  515 6.  Risks in the Servers                                                   
  517    Using the terminology of [RFC6973], the DNS servers (recursive          
  518    resolvers and authoritative servers) are enablers: "they facilitate     
  519    communication between an initiator and a recipient without being        
  520    directly in the communications path".  As a result, they are often      
  521    forgotten in risk analysis.  But, to quote [RFC6973] again, "Although   
  522    [...] enablers may not generally be considered as attackers, they may   
  523    all pose privacy threats (depending on the context) because they are    
  524    able to observe, collect, process, and transfer privacy-relevant        
  525    data".  In [RFC6973] parlance, enablers become observers when they      
  526    start collecting data.                                                  
  528    Many programs exist to collect and analyze DNS data at the servers --   
  529    from the "query log" of some programs like BIND to tcpdump and more     
  530    sophisticated programs like PacketQ [packetq] and DNSmezzo              
  531    [dnsmezzo].  The organization managing the DNS server can use this      
  532    data itself, or it can be part of a surveillance program like PRISM     
  533    [prism] and pass data to an outside observer.                           
  535    Sometimes this data is kept for a long time and/or distributed to       
  536    third parties for research purposes [ditl] [day-at-root], security      
  537    analysis, or surveillance tasks.  These uses are sometimes under some   
  538    sort of contract, with various limitations, for instance, on            
  539    redistribution, given the sensitive nature of the data.  Also, there    
  540    are observation points in the network that gather DNS data and then     
  541    make it accessible to third parties for research or security purposes   
  542    ("passive DNS" [passive-dns]).                                          
  544 6.1.  In the Recursive Resolvers                                           
  546    Recursive resolvers see all the traffic since there is typically no     
  547    caching before them.  To summarize: your recursive resolver knows a     
  548    lot about you.  The resolver of a large IAP, or a large public          
  549    resolver, can collect data from many users.                             
  551 6.1.1.  Resolver Selection                                                 
  553    Given all the above considerations, the choice of recursive resolver    
  554    has direct privacy considerations for end users.  Historically, end     
  555    user devices have used the DHCP-provided local network recursive        
  556    resolver.  The choice by a user to join a particular network (e.g.,     
  557    by physically plugging in a cable or selecting a network in an OS       
  558    dialogue) typically updates a number of system resources -- these can   
  559    include IP addresses, the availability of IPv4/IPv6, DHCP server, and   
  560    DNS resolver.  These individual changes, including the change in DNS    
  561    resolver, are not normally communicated directly to the user by the     
  562    OS when the network is joined.  The choice of network has               
  563    historically determined the default system DNS resolver selection;      
  564    the two are directly coupled in this model.                             
  566    The vast majority of users do not change their default system DNS       
  567    settings and so implicitly accept the network settings for the DNS.     
  568    The network resolvers have therefore historically been the sole         
  569    destination for all of the DNS queries from a device.  These            
  570    resolvers may have varied privacy policies depending on the network.    
  571    Privacy policies for these servers may or may not be available, and     
  572    users need to be aware that privacy guarantees will vary with the       
  573    network.                                                                
  575    All major OSes expose the system DNS settings and allow users to        
  576    manually override them if desired.                                      
  578    More recently, some networks and users have actively chosen to use a    
  579    large public resolver, e.g., Google Public DNS                          
  580    (https://developers.google.com/speed/public-dns), Cloudflare            
  581    (https://developers.cloudflare.com/, or     
  582    Quad9 (https://www.quad9.net).  There can be many reasons: cost         
  583    considerations for network operators, better reliability, or anti-      
  584    censorship considerations are just a few.  Such services typically do   
  585    provide a privacy policy, and the user can get an idea of the data      
  586    collected by such operators by reading one, e.g., Google Public DNS -   
  587    Your Privacy (https://developers.google.com/speed/public-dns/           
  588    privacy).                                                               
  590    In general, as with many other protocols, issues around                 
  591    centralization also arise with DNS.  The picture is fluid with          
  592    several competing factors contributing, where these factors can also    
  593    vary by geographic region.  These include:                              
  595    *  ISP outsourcing, including to third-party and public resolvers       
  597    *  regional market domination by one or only a few ISPs                 
  599    *  applications directing DNS traffic by default to a limited subset    
  600       of resolvers (see Section                                   
  602    An increased proportion of the global DNS resolution traffic being      
  603    served by only a few entities means that the privacy considerations     
  604    for users are highly dependent on the privacy policies and practices    
  605    of those entities.  Many of the issues around centralization are        
  606    discussed in [centralisation-and-data-sovereignty].                     
  608  Dynamic Discovery of DoH and Strict DoT                          
  610    While support for opportunistic DoT can be determined by probing a      
  611    resolver on port 853, there is currently no standardized discovery      
  612    mechanism for DoH and Strict DoT servers.                               
  614    This means that clients that might want to dynamically discover such    
  615    encrypted services, and where users are willing to trust such           
  616    services, are not able to do so.  At the time of writing, efforts to    
  617    provide standardized signaling mechanisms to discover the services      
  618    offered by local resolvers are in progress [DNSOP-RESOLVER].  Note      
  619    that an increasing number of ISPs are deploying encrypted DNS; for      
  620    example, see the Encrypted DNS Deployment Initiative [EDDI].            
  622  Application-Specific Resolver Selection                          
  624    An increasing number of applications are offering application-          
  625    specific encrypted DNS resolution settings, rather than defaulting to   
  626    using only the system resolver.  A variety of heuristics and            
  627    resolvers are available in different applications, including hard-      
  628    coded lists of recognized DoH/DoT servers.                              
  630    Generally, users are not aware of application-specific DNS settings     
  631    and may not have control over those settings.  To address these         
  632    limitations, users will only be aware of and have the ability to        
  633    control such settings if applications provide the following             
  634    functions:                                                              
  636    *  communicate the change clearly to users when the default             
  637       application resolver changes away from the system resolver           
  639    *  provide configuration options to change the default application      
  640       resolver, including a choice to always use the system resolver       
  642    *  provide mechanisms for users to locally inspect, selectively         
  643       forward, and filter queries (either via the application itself or    
  644       use of the system resolver)                                          
  646    Application-specific changes to default destinations for users' DNS     
  647    queries might increase or decrease user privacy; it is highly           
  648    dependent on the network context and the application-specific           
  649    default.  This is an area of active debate, and the IETF is working     
  650    on a number of issues related to application-specific DNS settings.     
  652 6.1.2.  Active Attacks on Resolver Configuration                           
  654    The previous section discussed DNS privacy, assuming that all the       
  655    traffic was directed to the intended servers (i.e., those that would    
  656    be used in the absence of an active attack) and that the potential      
  657    attacker was purely passive.  But, in reality, there can be active      
  658    attackers in the network.                                               
  660    The Internet Threat model, as described in [RFC3552], assumes that      
  661    the attacker controls the network.  Such an attacker can completely     
  662    control any insecure DNS resolution, both passively monitoring the      
  663    queries and responses and substituting their own responses.  Even if    
  664    encrypted DNS such as DoH or DoT is used, unless the client has been    
  665    configured in a secure way with the server identity, an active          
  666    attacker can impersonate the server.  This implies that opportunistic   
  667    modes of DoH/DoT as well as modes where the client learns of the DoH/   
  668    DoT server via in-network mechanisms such as DHCP are vulnerable to     
  669    attack.  In addition, if the client is compromised, the attacker can    
  670    replace the DNS configuration with one of its own choosing.             
  672 6.1.3.  Blocking of DNS Resolution Services                                
  674    User privacy can also be at risk if there is blocking of access to      
  675    remote recursive servers that offer encrypted transports, e.g., when    
  676    the local resolver does not offer encryption and/or has very poor       
  677    privacy policies.  For example, active blocking of port 853 for DoT     
  678    or blocking of specific IP addresses could restrict the resolvers       
  679    available to the user.  The extent of the risk to user privacy is       
  680    highly dependent on the specific network and user context; a user on    
  681    a network that is known to perform surveillance would be compromised    
  682    if they could not access such services, whereas a user on a trusted     
  683    network might have no privacy motivation to do so.                      
  685    As a matter of policy, some recursive resolvers use their position in   
  686    the query path to selectively block access to certain DNS records.      
  687    This is a form of rendezvous-based blocking as described in             
  688    Section 4.3 of [RFC7754].  Such blocklists often include servers        
  689    known to be used for malware, bots, or other security risks.  In        
  690    order to prevent circumvention of their blocking policies, some         
  691    networks also block access to resolvers with incompatible policies.     
  693    It is also noted that attacks on remote resolver services, e.g.,        
  694    DDoS, could force users to switch to other services that do not offer   
  695    encrypted transports for DNS.                                           
  697 6.1.4.  Encrypted Transports and Recursive Resolvers                       
  699  DoT and DoH                                                      
  701    Use of encrypted transports does not reduce the data available in the   
  702    recursive resolver and ironically can actually expose more              
  703    information about users to operators.  As described in Section 5.2,     
  704    use of session-based encrypted transports (TCP/TLS) can expose          
  705    correlation data about users.                                           
  707  DoH-Specific Considerations                                      
  709    DoH inherits the full privacy properties of the HTTPS stack and as a    
  710    consequence introduces new privacy considerations when compared with    
  711    DNS over UDP, TCP, or TLS [RFC7858].  Section 8.2 of [RFC8484]          
  712    describes the privacy considerations in the server of the DoH           
  713    protocol.                                                               
  715    A brief summary of some of the issues includes the following:           
  717    *  HTTPS presents new considerations for correlation, such as           
  718       explicit HTTP cookies and implicit fingerprinting of the unique      
  719       set and ordering of HTTP request header fields.                      
  721    *  The User-Agent and Accept-Language request header fields often       
  722       convey specific information about the client version or locale.      
  724    *  Utilizing the full set of HTTP features enables DoH to be more       
  725       than an HTTP tunnel, but it is at the cost of opening up             
  726       implementations to the full set of privacy considerations of HTTP.   
  728    *  Implementations are advised to expose the minimal set of data        
  729       needed to achieve the desired feature set.                           
  731    [RFC8484] specifically makes selection of HTTPS functionality vs.       
  732    privacy an implementation choice.  At the extremes, there may be        
  733    implementations that attempt to achieve parity with DoT from a          
  734    privacy perspective at the cost of using no identifiable HTTP           
  735    headers, and there might be others that provide feature-rich data       
  736    flows where the low-level origin of the DNS query is easily             
  737    identifiable.  Some implementations have, in fact, chosen to restrict   
  738    the use of the User-Agent header so that resolver operators cannot      
  739    identify the specific application that is originating the DNS           
  740    queries.                                                                
  742    Privacy-focused users should be aware of the potential for additional   
  743    client identifiers in DoH compared to DoT and may want to only use      
  744    DoH client implementations that provide clear guidance on what          
  745    identifiers they add.                                                   
  747 6.2.  In the Authoritative Name Servers                                    
  749    Unlike what happens for recursive resolvers, the observation            
  750    capabilities of authoritative name servers are limited by caching;      
  751    they see only the requests for which the answer was not in the cache.   
  752    For aggregated statistics ("What is the percentage of LOC queries?"),   
  753    this is sufficient, but it prevents an observer from seeing             
  754    everything.  Similarly, the increasing deployment of QNAME              
  755    minimization [ripe-qname-measurements] reduces the data visible at      
  756    the authoritative name server.  Still, the authoritative name servers   
  757    see a part of the traffic, and this subset may be sufficient to         
  758    violate some privacy expectations.                                      
  760    Also, the user often has some legal/contractual link with the           
  761    recursive resolver (they have chosen the IAP, or they have chosen to    
  762    use a given public resolver) while having no control and perhaps no     
  763    awareness of the role of the authoritative name servers and their       
  764    observation abilities.                                                  
  766    As noted before, using a local resolver or a resolver close to the      
  767    machine decreases the attack surface for an on-the-wire eavesdropper.   
  768    But it may decrease privacy against an observer located on an           
  769    authoritative name server.  This authoritative name server will see     
  770    the IP address of the end client instead of the address of a big        
  771    recursive resolver shared by many users.                                
  773    This "protection", when using a large resolver with many clients, is    
  774    no longer present if ECS [RFC7871] is used because, in this case, the   
  775    authoritative name server sees the original IP address (or prefix,      
  776    depending on the setup).                                                
  778    As of today, all the instances of one root name server, L-root,         
  779    receive together around 50,000 queries per second.  While most of it    
  780    is "junk" (errors on the Top-Level Domain (TLD) name), it gives an      
  781    idea of the amount of big data that pours into name servers.  (And      
  782    even "junk" can leak information; for instance, if there is a typing    
  783    error in the TLD, the user will send data to a TLD that is not the      
  784    usual one.)                                                             
  786    Many domains, including TLDs, are partially hosted by third-party       
  787    servers, sometimes in a different country.  The contracts between the   
  788    domain manager and these servers may or may not take privacy into       
  789    account.  Whatever the contract, the third-party hoster may or may      
  790    not be honest; in any case, it will have to follow its local laws.      
  791    For example, requests to a given ccTLD may go to servers managed by     
  792    organizations outside of the ccTLD's country.  Users may not            
  793    anticipate that when doing a security analysis.                         
  795    Also, it seems (see the survey described in [aeris-dns]) that there     
  796    is a strong concentration of authoritative name servers among           
  797    "popular" domains (such as the Alexa Top N list).  For instance,        
  798    among the Alexa Top 100K (https://www.alexa.com/topsites), one DNS      
  799    provider hosts 10% of the domains today.  The ten most important DNS    
  800    providers together host one-third of all domains.  With the control     
  801    (or the ability to sniff the traffic) of a few name servers, you can    
  802    gather a lot of information.                                            
  804 7.  Other Risks                                                            
  806 7.1.  Re-identification and Other Inferences                               
  808    An observer has access not only to the data they directly collect but   
  809    also to the results of various inferences about this data.  The term    
  810    "observer" here is used very generally; for example, the observer       
  811    might passively observe cleartext DNS traffic or be in the network      
  812    that is actively attacking the user by redirecting DNS resolution, or   
  813    it might be a local or remote resolver operator.                        
  815    For instance, a user can be re-identified via DNS queries.  If the      
  816    adversary knows a user's identity and can watch their DNS queries for   
  817    a period, then that same adversary may be able to re-identify the       
  818    user solely based on their pattern of DNS queries later on regardless   
  819    of the location from which the user makes those queries.  For           
  820    example, one study [herrmann-reidentification] found that such re-      
  821    identification is possible so that "73.1% of all day-to-day links       
  822    were correctly established, i.e. user u was either re-identified        
  823    unambiguously (1) or the classifier correctly reported that u was not   
  824    present on day t + 1 any more (2)".  While that study related to web    
  825    browsing behavior, equally characteristic patterns may be produced      
  826    even in machine-to-machine communications or without a user taking      
  827    specific actions, e.g., at reboot time if a characteristic set of       
  828    services are accessed by the device.                                    
  830    For instance, one could imagine that an intelligence agency             
  831    identifies people going to a site by putting in a very long DNS name    
  832    and looking for queries of a specific length.  Such traffic analysis    
  833    could weaken some privacy solutions.                                    
  835    The IAB Privacy and Security Program also has a document [RFC7624]      
  836    that considers such inference-based attacks in a more general           
  837    framework.                                                              
  839 7.2.  More Information                                                     
  841    Useful background information can also be found in [tor-leak]           
  842    (regarding the risk of privacy leaks through DNS) and in a few          
  843    academic papers: [yanbin-tsudik], [castillo-garcia],                    
  844    [fangming-hori-sakurai], and [federrath-fuchs-herrmann-piosecny].       
  846 8.  Actual "Attacks"                                                       
  848    A very quick examination of DNS traffic may lead to the false           
  849    conclusion that extracting the needle from the haystack is difficult.   
  850    "Interesting" primary DNS requests are mixed with useless (for the      
  851    eavesdropper) secondary and tertiary requests (see the terminology in   
  852    Section 1).  But, in this time of "big data" processing, powerful       
  853    techniques now exist to get from the raw data to what the               
  854    eavesdropper is actually interested in.                                 
  856    Many research papers about malware detection use DNS traffic to         
  857    detect "abnormal" behavior that can be traced back to the activity of   
  858    malware on infected machines.  Yes, this research was done for the      
  859    greater good, but technically it is a privacy attack and it             
  860    demonstrates the power of the observation of DNS traffic.  See          
  861    [dns-footprint], [dagon-malware], and [darkreading-dns].                
  863    Passive DNS services [passive-dns] allow reconstruction of the data     
  864    of sometimes an entire zone.  Well-known passive DNS services keep      
  865    only the DNS responses and not the source IP address of the client,     
  866    precisely for privacy reasons.  Other passive DNS services may not be   
  867    so careful.  And there are still potential problems with revealing      
  868    QNAMEs.                                                                 
  870    The revelations from the Edward Snowden documents, which were leaked    
  871    from the National Security Agency (NSA), provide evidence of the use    
  872    of the DNS in mass surveillance operations [morecowbell].  For          
  873    example, the MORECOWBELL surveillance program uses a dedicated covert   
  874    monitoring infrastructure to actively query DNS servers and perform     
  875    HTTP requests to obtain meta-information about services and to check    
  876    their availability.  Also, the QUANTUMTHEORY                            
  877    (https://theintercept.com/document/2014/03/12/nsa-gchqs-                
  878    quantumtheory-hacking-tactics/) project, which includes detecting       
  879    lookups for certain addresses and injecting bogus replies, is another   
  880    good example showing that the lack of privacy protections in the DNS    
  881    is actively exploited.                                                  
  883 9.  Legalities                                                             
  885    To our knowledge, there are no specific privacy laws for DNS data in    
  886    any country.  Interpreting general privacy laws, like the European      
  887    Union's [data-protection-directive] or GDPR (https://gdpr.eu/tag/       
  888    gdpr/), in the context of DNS traffic data is not an easy task, and     
  889    there is no known court precedent.  See an interesting analysis in      
  890    [sidn-entrada].                                                         
  892 10.  Security Considerations                                               
  894    This document is entirely about security -- more precisely, privacy.    
  895    It just lays out the problem; it does not try to set requirements       
  896    (with the choices and compromises they imply), much less define         
  897    solutions.  Possible solutions to the issues described here are         
  898    discussed in other documents (currently too many to all be              
  899    mentioned); see, for instance, "Recommendations for DNS Privacy         
  900    Operators" [RFC8932].                                                   
  902 11.  IANA Considerations                                                   
  904    This document has no IANA actions.                                      
  906 12.  References                                                            
  908 12.1.  Normative References                                                
  910    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  911               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
  912               <https://www.rfc-editor.org/info/rfc1034>.                   
  914    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  915               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  916               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
  918    [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,         
  919               Morris, J., Hansen, M., and R. Smith, "Privacy               
  920               Considerations for Internet Protocols", RFC 6973,            
  921               DOI 10.17487/RFC6973, July 2013,                             
  922               <https://www.rfc-editor.org/info/rfc6973>.                   
  924    [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an   
  925               Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May        
  926               2014, <https://www.rfc-editor.org/info/rfc7258>.             
  928 12.2.  Informative References                                              
  930    [aeris-dns]                                                             
  931               Vinot, N., "Vie privée: et le DNS alors? [Privacy: what      
  932               about DNS?]", February 2015,                                 
  933               <https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.   
  935    [cache-snooping-defence]                                                
  936               ISC, "DNS Cache snooping - should I be concerned?",          
  937               October 2018, <https://kb.isc.org/docs/aa-00482>.            
  939    [castillo-garcia]                                                       
  940               Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous          
  941               Resolution of DNS Queries", Lecture Notes in Computer        
  942               Science, Vol. 5332, DOI 10.1007/978-3-540-88873-4_5, 2008,   
  943               <https://dl.acm.org/doi/10.1007/978-3-540-88873-4_5>.        
  945    [centralisation-and-data-sovereignty]                                   
  946               De Filippi, P. and S. McCarthy, "Cloud Computing:            
  947               Centralization and Data Sovereignty", European Journal of    
  948               Law and Technology, Vol. 3, No. 2, October 2012,             
  949               <https://papers.ssrn.com/sol3/                               
  950               papers.cfm?abstract_id=2167372>.                             
  952    [dagon-malware]                                                         
  953               Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a    
  954               Malicious Resolution Authority", ISC/OARC Workshop, 2007,    
  955               <https://www.dns-oarc.net/files/workshop-2007/Dagon-         
  956               Resolution-corruption.pdf>.                                  
  958    [darkreading-dns]                                                       
  959               Lemos, R., "Got Malware? Three Signs Revealed In DNS         
  960               Traffic", May 2013,                                          
  961               <https://www.darkreading.com/analytics/security-             
  962               monitoring/got-malware-three-signs-revealed-in-dns-          
  963               traffic/d/d-id/1139680>.                                     
  965    [data-protection-directive]                                             
  966               European Parliament, "Directive 95/46/EC of the European     
  967               Parliament and of the Council of 24 October 1995 on the      
  968               protection of individuals with regard to the processing of   
  969               personal data and on the free movement of such data",        
  970               Official Journal L 281, pp. 31-50, November 1995,            
  971               <https://eur-lex.europa.eu/LexUriServ/                       
  972               LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.                 
  974    [day-at-root]                                                           
  975               Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A     
  976               Day at the Root of the Internet", ACM SIGCOMM Computer       
  977               Communication Review, Vol. 38, No. 5,                        
  978               DOI 10.1145/1452335.1452341, October 2008,                   
  979               <https://www.sigcomm.org/sites/default/files/ccr/            
  980               papers/2008/October/1452335-1452341.pdf>.                    
  982    [denis-edns-client-subnet]                                              
  983               Denis, F., "Security and privacy issues of edns-client-      
  984               subnet", August 2013,                                        
  985               <https://00f.net/2013/08/07/edns-client-subnet/>.            
  987    [ditl]     CAIDA, "A Day in the Life of the Internet (DITL)",           
  988               <https://www.caida.org/projects/ditl/>.                      
  990    [dns-de-nat]                                                            
  991               Orevi, L., Herzberg, A., Zlatokrilov, H., and D. Sigron,     
  992               "DNS-DNS: DNS-based De-NAT Scheme", January 2017,            
  993               <https://www.researchgate.net/publication/320322146_DNS-     
  994               DNS_DNS-based_De-NAT_Scheme>.                                
  996    [dns-footprint]                                                         
  997               Stoner, E., "DNS Footprint of Malware", OARC Workshop,       
  998               October 2010, <https://www.dns-oarc.net/files/workshop-      
  999               201010/OARC-ers-20101012.pdf>.                               
 1001    [dns-over-encryption]                                                   
 1002               Lu, C., Liu, B., Li, Z., Hao, S., Duan, H., Zhang, M.,       
 1003               Leng, C., Liu, Y., Zhang, Z., and J. Wu, "An End-to-End,     
 1004               Large-Scale Measurement of DNS-over-Encryption: How Far      
 1005               Have We Come?", IMC '19: Proceedings of the Internet         
 1006               Measurement Conference, pp. 22-35,                           
 1007               DOI 10.1145/3355369.3355580, October 2019,                   
 1008               <https://dl.acm.org/citation.cfm?id=3355369.3355580>.        
 1010    [dnsmezzo] Bortzmeyer, S., "DNSmezzo", <http://www.dnsmezzo.net/>.      
 1012    [DNSOP-RESOLVER]                                                        
 1013               Sood, P., Arends, R., and P. Hoffman, "DNS Resolver          
 1014               Information Self-publication", Work in Progress, Internet-   
 1015               Draft, draft-ietf-dnsop-resolver-information-01, 11          
 1016               February 2020, <https://datatracker.ietf.org/doc/html/       
 1017               draft-ietf-dnsop-resolver-information-01>.                   
 1019    [DPRIVE-DNSOQUIC]                                                       
 1020               Huitema, C., Dickinson, S., and A. Mankin, "Specification    
 1021               of DNS over Dedicated QUIC Connections", Work in Progress,   
 1022               Internet-Draft, draft-ietf-dprive-dnsoquic-03, 12 July       
 1023               2021, <https://datatracker.ietf.org/doc/html/draft-ietf-     
 1024               dprive-dnsoquic-03>.                                         
 1026    [EDDI]     EDDI, "Encrypted DNS Deployment Initiative",                 
 1027               <https://www.encrypted-dns.org>.                             
 1029    [fangming-hori-sakurai]                                                 
 1030               Zhao, F., Hori, Y., and K. Sakurai, "Analysis of Privacy     
 1031               Disclosure in DNS Query", MUE '07: Proceedings of the 2007   
 1032               International Conference on Multimedia and Ubiquitous        
 1033               Engineering, pp. 952-957, DOI 10.1109/MUE.2007.84,           
 1034               ISBN 0-7695-2777-9, April 2007,                              
 1035               <https://dl.acm.org/citation.cfm?id=1262690.1262986>.        
 1037    [federrath-fuchs-herrmann-piosecny]                                     
 1038               Federrath, H., Fuchs, K.-P., Herrmann, D., and C.            
 1039               Piosecny, "Privacy-Preserving DNS: Analysis of Broadcast,    
 1040               Range Queries and Mix-based Protection Methods", ESORICS     
 1041               2011, pp. 665-683, DOI 10.1007/978-3-642-23822-2_36,         
 1042               ISBN 978-3-642-23822-2, 2011, <https://svs.informatik.uni-   
 1043               hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreser   
 1044               vingDNS_ESORICS2011.pdf>.                                    
 1046    [getdns]   "getdns", <https://getdnsapi.net>.                           
 1048    [grangeia.snooping]                                                     
 1049               Grangeia, L., "Cache Snooping or Snooping the Cache for      
 1050               Fun and Profit", 2005,                                       
 1051               <https://www.semanticscholar.org/paper/Cache-Snooping-or-    
 1052               Snooping-the-Cache-for-Fun-and-                              
 1053               1-Grangeia/9b22f606e10b3609eafbdcbfc9090b63be8778c3>.        
 1055    [herrmann-reidentification]                                             
 1056               Herrmann, D., Gerber, C., Banse, C., and H. Federrath,       
 1057               "Analyzing Characteristic Host Access Patterns for Re-       
 1058               Identification of Web User Sessions", Lecture Notes in       
 1059               Computer Science, Vol. 7127,                                 
 1060               DOI 10.1007/978-3-642-27937-9_10, 2012, <https://epub.uni-   
 1061               regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.      
 1063    [morecowbell]                                                           
 1064               Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,       
 1065               "NSA's MORECOWBELL: Knell for DNS", January 2015, <https:/   
 1066               /pdfs.semanticscholar.org/2610/2b99bdd6a258a98740af8217ba8   
 1067               da8a1e4fa.pdf>.                                              
 1069    [packetq]  DNS-OARC, "A tool that provides a basic SQL-frontend to      
 1070               PCAP-files", Release 1.4.3, commit 29a8288, October 2020,    
 1071               <https://github.com/DNS-OARC/PacketQ>.                       
 1073    [passive-dns]                                                           
 1074               Weimer, F., "Passive DNS Replication", 17th Annual FIRST     
 1075               Conference, April 2005,                                      
 1076               <https://www.first.org/conference/2005/papers/florian-       
 1077               weimer-slides-1.pdf>.                                        
 1079    [pitfalls-of-dns-encryption]                                            
 1080               Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS            
 1081               Encryption", WPES '14: Proceedings of the 13th Workshop on   
 1082               Privacy in the Electronic Society, pp. 191-200,              
 1083               DOI 10.1145/2665943.2665959, November 2014,                  
 1084               <https://dl.acm.org/citation.cfm?id=2665959>.                
 1086    [prism]    Wikipedia, "PRISM (surveillance program)", July 2015,        
 1087               <https://en.wikipedia.org/w/index.php?title=PRISM_(surveil   
 1088               lance_program)&oldid=673789455>.                             
 1090    [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC      
 1091               Text on Security Considerations", BCP 72, RFC 3552,          
 1092               DOI 10.17487/RFC3552, July 2003,                             
 1093               <https://www.rfc-editor.org/info/rfc3552>.                   
 1095    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1096               Rose, "DNS Security Introduction and Requirements",          
 1097               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
 1098               <https://www.rfc-editor.org/info/rfc4033>.                   
 1100    [RFC4470]  Weiler, S. and J. Ihren, "Minimally Covering NSEC Records    
 1101               and DNSSEC On-line Signing", RFC 4470,                       
 1102               DOI 10.17487/RFC4470, April 2006,                            
 1103               <https://www.rfc-editor.org/info/rfc4470>.                   
 1105    [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS      
 1106               Security (DNSSEC) Hashed Authenticated Denial of             
 1107               Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,      
 1108               <https://www.rfc-editor.org/info/rfc5155>.                   
 1110    [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol    
 1111               (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,          
 1112               <https://www.rfc-editor.org/info/rfc5936>.                   
 1114    [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and     
 1115               P. Roberts, "Issues with IP Address Sharing", RFC 6269,      
 1116               DOI 10.17487/RFC6269, June 2011,                             
 1117               <https://www.rfc-editor.org/info/rfc6269>.                   
 1119    [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms    
 1120               for DNS (EDNS(0))", STD 75, RFC 6891,                        
 1121               DOI 10.17487/RFC6891, April 2013,                            
 1122               <https://www.rfc-editor.org/info/rfc6891>.                   
 1124    [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP     
 1125               Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,   
 1126               <https://www.rfc-editor.org/info/rfc7413>.                   
 1128    [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,                   
 1129               "Recommendations for Secure Use of Transport Layer           
 1130               Security (TLS) and Datagram Transport Layer Security         
 1131               (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May        
 1132               2015, <https://www.rfc-editor.org/info/rfc7525>.             
 1134    [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,          
 1135               Trammell, B., Huitema, C., and D. Borkmann,                  
 1136               "Confidentiality in the Face of Pervasive Surveillance: A    
 1137               Threat Model and Problem Statement", RFC 7624,               
 1138               DOI 10.17487/RFC7624, August 2015,                           
 1139               <https://www.rfc-editor.org/info/rfc7624>.                   
 1141    [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,      
 1142               DOI 10.17487/RFC7626, August 2015,                           
 1143               <https://www.rfc-editor.org/info/rfc7626>.                   
 1145    [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy   
 1146               Considerations for IPv6 Address Generation Mechanisms",      
 1147               RFC 7721, DOI 10.17487/RFC7721, March 2016,                  
 1148               <https://www.rfc-editor.org/info/rfc7721>.                   
 1150    [RFC7754]  Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.      
 1151               Nordmark, "Technical Considerations for Internet Service     
 1152               Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,     
 1153               March 2016, <https://www.rfc-editor.org/info/rfc7754>.       
 1155    [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve      
 1156               Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,        
 1157               <https://www.rfc-editor.org/info/rfc7816>.                   
 1159    [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,     
 1160               and P. Hoffman, "Specification for DNS over Transport        
 1161               Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May   
 1162               2016, <https://www.rfc-editor.org/info/rfc7858>.             
 1164    [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.      
 1165               Kumari, "Client Subnet in DNS Queries", RFC 7871,            
 1166               DOI 10.17487/RFC7871, May 2016,                              
 1167               <https://www.rfc-editor.org/info/rfc7871>.                   
 1169    [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)   
 1170               Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,          
 1171               <https://www.rfc-editor.org/info/rfc7873>.                   
 1173    [RFC7929]  Wouters, P., "DNS-Based Authentication of Named Entities     
 1174               (DANE) Bindings for OpenPGP", RFC 7929,                      
 1175               DOI 10.17487/RFC7929, August 2016,                           
 1176               <https://www.rfc-editor.org/info/rfc7929>.                   
 1178    [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol   
 1179               Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,   
 1180               <https://www.rfc-editor.org/info/rfc8446>.                   
 1182    [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS          
 1183               (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,        
 1184               <https://www.rfc-editor.org/info/rfc8484>.                   
 1186    [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
 1187               Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,       
 1188               January 2019, <https://www.rfc-editor.org/info/rfc8499>.     
 1190    [RFC8744]  Huitema, C., "Issues and Requirements for Server Name        
 1191               Identification (SNI) Encryption in TLS", RFC 8744,           
 1192               DOI 10.17487/RFC8744, July 2020,                             
 1193               <https://www.rfc-editor.org/info/rfc8744>.                   
 1195    [RFC8890]  Nottingham, M., "The Internet is for End Users", RFC 8890,   
 1196               DOI 10.17487/RFC8890, August 2020,                           
 1197               <https://www.rfc-editor.org/info/rfc8890>.                   
 1199    [RFC8932]  Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and    
 1200               A. Mankin, "Recommendations for DNS Privacy Service          
 1201               Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,         
 1202               October 2020, <https://www.rfc-editor.org/info/rfc8932>.     
 1204    [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based     
 1205               Multiplexed and Secure Transport", RFC 9000,                 
 1206               DOI 10.17487/RFC9000, May 2021,                              
 1207               <https://www.rfc-editor.org/info/rfc9000>.                   
 1209    [ripe-qname-measurements]                                               
 1210               de Vries, W., "Making the DNS More Private with QNAME        
 1211               Minimisation", April 2019,                                   
 1212               <https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-   
 1213               bit-more-private-with-qname-minimisation>.                   
 1215    [sidn-entrada]                                                          
 1216               Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.     
 1217               Simon, "A privacy framework for 'DNS big data'               
 1218               applications", November 2014,                                
 1219               <https://www.sidnlabs.nl/downloads/                          
 1220               yBW6hBoaSZe4m6GJc_0b7w/2211058ab6330c7f3788141ea19d3db7/     
 1221               SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.      
 1223    [thomas-ditl-tcp]                                                       
 1224               Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in    
 1225               Root Server DITL Data", DNS-OARC 2014 Fall Workshop,         
 1226               October 2014, <https://indico.dns-                           
 1227               oarc.net/event/20/session/2/contribution/15/material/        
 1228               slides/1.pdf>.                                               
 1230    [tor-leak] Tor, "Tor FAQs: I keep seeing these warnings about SOCKS     
 1231               and DNS information leaks. Should I worry?",                 
 1232               <https://www.torproject.org/docs/                            
 1233               faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.       
 1235    [yanbin-tsudik]                                                         
 1236               Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks    
 1237               in Domain Name System", June 2010,                           
 1238               <https://arxiv.org/abs/0910.2472>.                           
 1240 Appendix A.  Updates since RFC 7626                                        
 1242    Many references were updated.  Discussions of encrypted transports,     
 1243    including DoT and DoH, and sections on DNS payload, authentication of   
 1244    servers, and blocking of services were added.  With the publishing of   
 1245    [RFC7816] on QNAME minimization, text, references, and initial          
 1246    attempts to measure deployment were added to reflect this.  The text    
 1247    and references on the Snowden revelations were updated.                 
 1249    The "Risks Overview" section was changed to "Scope" to help clarify     
 1250    the risks being considered.  Text on cellular network DNS, blocking,    
 1251    and security was added.  Considerations for recursive resolvers were    
 1252    collected and placed together.  A discussion on resolver selection      
 1253    was added.                                                              
 1255 Acknowledgments                                                            
 1257    Thanks to Nathalie Boulvard and to the CENTR members for the original   
 1258    work that led to this document.  Thanks to Ondrej Sury for the          
 1259    interesting discussions.  Thanks to Mohsen Souissi and John Heidemann   
 1260    for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,    
 1261    Francis Dupont, Allison Mankin, and Warren Kumari for proofreading,     
 1262    providing technical remarks, and making many readability                
 1263    improvements.  Thanks to Dan York, Suzanne Woolf, Tony Finch, Stephen   
 1264    Farrell, Peter Koch, Simon Josefsson, and Frank Denis for good          
 1265    written contributions.  Thanks to Vittorio Bertola and Mohamed          
 1266    Boucadair for a detailed review of the -bis.  And thanks to the IESG    
 1267    members for the last remarks.                                           
 1269 Contributions                                                              
 1271    Sara Dickinson and Stephane Bortzmeyer were the original authors of     
 1272    the document, and their contribution to the initial draft of this       
 1273    document is greatly appreciated.                                        
 1275 Author's Address                                                           
 1277    Tim Wicinski (editor)                                                   
 1278    Elkins, WV 26241                                                        
 1279    United States of America                                                
 1281    Email: tjw.ietf@gmail.com                                               

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.