idnits 2.17.1 draft-ietf-dprive-rfc7626-bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2020) is 1288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1216 -- Looks like a reference, but probably isn't: '2' on line 1219 -- Looks like a reference, but probably isn't: '3' on line 1221 -- Looks like a reference, but probably isn't: '4' on line 1223 -- Looks like a reference, but probably isn't: '5' on line 1225 -- Looks like a reference, but probably isn't: '6' on line 1227 -- Looks like a reference, but probably isn't: '7' on line 1229 -- Looks like a reference, but probably isn't: '8' on line 1231 -- Looks like a reference, but probably isn't: '9' on line 1234 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-31 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive T. Wicinski, Ed. 3 Internet-Draft October 15, 2020 4 Obsoletes: 7626 (if approved) 5 Intended status: Informational 6 Expires: April 18, 2021 8 DNS Privacy Considerations 9 draft-ietf-dprive-rfc7626-bis-08 11 Abstract 13 This document describes the privacy issues associated with the use of 14 the DNS by Internet users. It is intended to be an analysis of the 15 present situation and does not prescribe solutions. This document 16 obsoletes RFC 7626. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 18, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Risks in the DNS Data . . . . . . . . . . . . . . . . . . . . 6 56 4.1. The Public Nature of DNS Data . . . . . . . . . . . . . . 6 57 4.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 6 58 4.2.1. Data in the DNS Payload . . . . . . . . . . . . . . . 8 59 4.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 8 60 5. Risks On the Wire . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Unencrypted Transports . . . . . . . . . . . . . . . . . 8 62 5.2. Encrypted Transports . . . . . . . . . . . . . . . . . . 10 63 6. Risks in the Servers . . . . . . . . . . . . . . . . . . . . 11 64 6.1. In the Recursive Resolvers . . . . . . . . . . . . . . . 12 65 6.1.1. Resolver Selection . . . . . . . . . . . . . . . . . 12 66 6.1.2. Active Attacks on Resolver Configuration . . . . . . 14 67 6.1.3. Blocking of User Selected DNS Resolution Services . . 14 68 6.1.4. Encrypted Transports and Recursive Resolvers . . . . 15 69 6.2. In the Authoritative Name Servers . . . . . . . . . . . . 16 70 7. Other risks . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 7.1. Re-identification and Other Inferences . . . . . . . . . 17 72 7.2. More Information . . . . . . . . . . . . . . . . . . . . 18 73 8. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 18 74 9. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 12. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 19 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 81 14.2. Informative References . . . . . . . . . . . . . . . . . 20 82 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 Appendix A. Updates since RFC7626 . . . . . . . . . . . . . . . 27 84 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 27 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 87 1. Introduction 89 This document is an analysis of the DNS privacy issues, in the spirit 90 of Section 8 of [RFC6973]. 92 The Domain Name System (DNS) is specified in [RFC1034], [RFC1035], 93 and many later RFCs, which have never been consolidated. It is one 94 of the most important infrastructure components of the Internet and 95 often ignored or misunderstood by Internet users (and even by many 96 professionals). Almost every activity on the Internet starts with a 97 DNS query (and often several). Its use has many privacy implications 98 and this document is an attempt at a comprehensive and accurate list. 100 Let us begin with a simplified reminder of how the DNS works (See 101 also [RFC8499]). A client, the stub resolver, issues a DNS query to 102 a server, called the recursive resolver (also called caching resolver 103 or full resolver or recursive name server). Let's use the query 104 "What are the AAAA records for www.example.com?" as an example. AAAA 105 is the QTYPE (Query Type), and www.example.com is the QNAME (Query 106 Name). (The description that follows assumes a cold cache, for 107 instance, because the server just started.) The recursive resolver 108 will first query the root name servers. In most cases, the root name 109 servers will send a referral. In this example, the referral will be 110 to the .com name servers. The resolver repeats the query to one of 111 the .com name servers. The .com name servers, in turn, will refer to 112 the example.com name servers. The example.com name server will then 113 return the answer. The root name servers, the name servers of .com, 114 and the name servers of example.com are called authoritative name 115 servers. It is important, when analyzing the privacy issues, to 116 remember that the question asked to all these name servers is always 117 the original question, not a derived question. The question sent to 118 the root name servers is "What are the AAAA records for 119 www.example.com?", not "What are the name servers of .com?". By 120 repeating the full question, instead of just the relevant part of the 121 question to the next in line, the DNS provides more information than 122 necessary to the name server. In this simplified description, 123 recursive resolvers do not implement QNAME minimization as described 124 in [RFC7816], which will only send the relevant part of the question 125 to the upstream name server. 127 DNS relies heavily on caching, so the algorithm described above is 128 actually a bit more complicated, and not all questions are sent to 129 the authoritative name servers. If a few seconds later the stub 130 resolver asks the recursive resolver, "What are the SRV records of 131 _xmpp-server._tcp.example.com?", the recursive resolver will remember 132 that it knows the name servers of example.com and will just query 133 them, bypassing the root and .com. Because there is typically no 134 caching in the stub resolver, the recursive resolver, unlike the 135 authoritative servers, sees all the DNS traffic. (Applications, like 136 web browsers, may have some form of caching that does not follow DNS 137 rules, for instance, because it may ignore the TTL. So, the 138 recursive resolver does not see all the name resolution activity.) 140 It should be noted that DNS recursive resolvers sometimes forward 141 requests to other recursive resolvers, typically bigger machines, 142 with a larger and more shared cache (and the query hierarchy can be 143 even deeper, with more than two levels of recursive resolvers). From 144 the point of view of privacy, these forwarders are like resolvers, 145 except that they do not see all of the requests being made (due to 146 caching in the first resolver). 148 At the time of writing, almost all this DNS traffic is currently sent 149 unencrypted. However, there is increasing deployment of DNS-over-TLS 150 (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in 151 mobile devices, browsers, and by providers of anycast recursive DNS 152 resolution services. There are a few cases where there is some 153 alternative channel encryption, for instance, in an IPsec VPN tunnel, 154 at least between the stub resolver and the resolver. 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 [I-D.ietf-quic-transport] [I-D.ietf-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 by 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 o Primary request: this is the domain name in the URL that the user 169 typed, selected from a bookmark, or chose by clicking on an 170 hyperlink. Presumably, this is what is of interest for the 171 eavesdropper. 173 o Secondary requests: these are the additional requests performed by 174 the user agent (here, the web browser) without any direct 175 involvement or knowledge of the user. For the Web, they are 176 triggered by embedded content, Cascading Style Sheets (CSS), 177 JavaScript code, embedded images, etc. In some cases, there can 178 be dozens of domain names in different contexts on a single web 179 page. 181 o Tertiary requests: these are the additional requests performed by 182 the DNS system itself. For instance, if the answer to a query is 183 a referral to a set of name servers, and the glue records are not 184 returned, the resolver will have to do additional requests to turn 185 the name servers' names into IP addresses. Similarly, even if 186 glue records are returned, a careful recursive server will do 187 tertiary requests to verify the IP addresses of those records. 189 It can also be noted that, in the case of a typical web browser, more 190 DNS requests than strictly necessary are sent, for instance, to 191 prefetch resources that the user may query later or when 192 autocompleting the URL in the address bar. Both are a significant 193 privacy concern since they may leak information even about non- 194 explicit actions. For instance, just reading a local HTML page, even 195 without selecting the hyperlinks, may trigger DNS requests. 197 For privacy-related terms, the terminology is from [RFC6973]. 199 2. Scope 201 This document focuses mostly on the study of privacy risks for the 202 end user (the one performing DNS requests). The risks of pervasive 203 surveillance [RFC7258] are considered as well as risks coming from a 204 more focused surveillance. 206 This document does not attempt a comparison of specific privacy 207 protections provided by individual networks or organizations, it 208 makes only general observations about typical current practices. 210 Privacy risks for the holder of a zone (the risk that someone gets 211 the data) are discussed in [RFC5936] and [RFC5155]. 213 Privacy risks for recursive operators (including access providers and 214 operators in enterprise networks) such as leakage of private 215 namespaces or blocklists are out of scope for this document. 217 Non-privacy risks (e.g security related considerations such as cache 218 poisoning) are also out of scope. 220 The privacy risks associated with the use of other protocols that 221 make use of DNS information are not considered here. 223 3. Risks 225 The following four sections outline the privacy considerations 226 associated with different aspects of the DNS for the end user. When 227 reading these sections it needs to be kept in mind that many of the 228 considerations (for example, recursive resolver and transport 229 protocol) can be specific to the network context that a device is 230 using at a given point in time. A user may have many devices and 231 each device might utilize many different networks (e.g. home, work, 232 public or cellular) over a period of time or even concurrently. An 233 exhaustive analysis of the privacy considerations for an individual 234 user would need to take into account the set of devices used and the 235 multiple dynamic contexts of each device. This document does not 236 attempt such a complex analysis, but instead it presents an overview 237 of the various considerations that could form the basis of such an 238 analysis. 240 4. Risks in the DNS Data 242 4.1. The Public Nature of DNS Data 244 It has been stated that "the data in the DNS is public". This 245 sentence makes sense for an Internet-wide lookup system, and there 246 are multiple facets to the data and metadata involved that deserve a 247 more detailed look. First, access control lists (ACLs) and private 248 namespaces notwithstanding, the DNS operates under the assumption 249 that public-facing authoritative name servers will respond to "usual" 250 DNS queries for any zone they are authoritative for without further 251 authentication or authorization of the client (resolver). Due to the 252 lack of search capabilities, only a given QNAME will reveal the 253 resource records associated with that name (or that name's non- 254 existence). In other words: one needs to know what to ask for, in 255 order to receive a response. There are many ways in which supposedly 256 "private" resources currently leak. A few examples are DNSSEC NSEC 257 zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The 258 zone transfer QTYPE [RFC5936] is often blocked or restricted to 259 authenticated/authorized access to enforce this difference (and maybe 260 for other reasons). 262 Another differencce between the DNS data and a particular DNS 263 transaction (i.e., a DNS name lookup). DNS data and the results of a 264 DNS query are public, within the boundaries described above, and may 265 not have any confidentiality requirements. However, the same is not 266 true of a single transaction or a sequence of transactions; those 267 transactions are not / should not be public. A single transactions 268 reveals both the originator of the query and the query contents which 269 potentially leaks sensitive information about a specific user. A 270 typical example from outside the DNS world is: the web site of 271 Alcoholics Anonymous is public; the fact that you visit it should not 272 be. Furthermore, the ability to link queries reveals information 273 about individual use patterns. 275 4.2. Data in the DNS Request 277 The DNS request includes many fields, but two of them seem 278 particularly relevant for the privacy issues: the QNAME and the 279 source IP address. "source IP address" is used in a loose sense of 280 "source IP address + maybe source port number", because the port 281 number is also in the request and can be used to differentiate 282 between several users sharing an IP address (behind a Carrier-Grade 283 NAT (CGN), for instance [RFC6269]). 285 The QNAME is the full name sent by the user. It gives information 286 about what the user does ("What are the MX records of example.net?" 287 means he probably wants to send email to someone at example.net, 288 which may be a domain used by only a few persons and is therefore 289 very revealing about communication relationships). Some QNAMEs are 290 more sensitive than others. For instance, querying the A record of a 291 well-known web statistics domain reveals very little (everybody 292 visits web sites that use this analytics service), but querying the A 293 record of www.verybad.example where verybad.example is the domain of 294 an organization that some people find offensive or objectionable may 295 create more problems for the user. Also, sometimes, the QNAME embeds 296 the software one uses, which could be a privacy issue. For instance, 297 _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. 298 There are also some BitTorrent clients that query an SRV record for 299 _bittorrent-tracker._tcp.domain.example. 301 Another important thing about the privacy of the QNAME is the future 302 usages. Today, the lack of privacy is an obstacle to putting 303 potentially sensitive or personally identifiable data in the DNS. At 304 the moment, your DNS traffic might reveal that you are doing email 305 but not with whom. If your Mail User Agent (MUA) starts looking up 306 Pretty Good Privacy (PGP) keys in the DNS [RFC7929], then privacy 307 becomes a lot more important. And email is just an example; there 308 would be other really interesting uses for a more privacy-friendly 309 DNS. 311 For the communication between the stub resolver and the recursive 312 resolver, the source IP address is the address of the user's machine. 313 Therefore, all the issues and warnings about collection of IP 314 addresses apply here. For the communication between the recursive 315 resolver and the authoritative name servers, the source IP address 316 has a different meaning; it does not have the same status as the 317 source address in an HTTP connection. It can be typically the IP 318 address of the recursive resolver that, in a way, "hides" the real 319 user. However, hiding does not always work. Sometimes EDNS(0) 320 Client subnet [RFC7871] is used (see one privacy analysis in 321 [denis-edns-client-subnet]). Sometimes the end user has a personal 322 recursive resolver on her machine. In both cases, the IP address 323 originating queries to the authoritative server is as sensitive as it 324 is for HTTP [sidn-entrada]. 326 A note about IP addresses: there is currently no IETF document that 327 describes in detail all the privacy issues around IP addressing in 328 general, although [RFC7721] does discuss privacy considerations for 329 IPv6 address generation mechanisms. In the meantime, the discussion 330 here is intended to include both IPv4 and IPv6 source addresses. For 331 a number of reasons, their assignment and utilization characteristics 332 are different, which may have implications for details of information 333 leakage associated with the collection of source addresses. (For 334 example, a specific IPv6 source address seen on the public Internet 335 is less likely than an IPv4 address to originate behind an address 336 sharing scheme.) However, for both IPv4 and IPv6 addresses, it is 337 important to note that source addresses are propagated with queries 338 via EDNS(0) Client subnet and comprise metadata about the host, user, 339 or application that originated them. 341 4.2.1. Data in the DNS Payload 343 At the time of writing there are no standardized client identifiers 344 contained in the DNS payload itself (ECS [RFC7871] while widely used 345 is only of Category Informational). 347 DNS Cookies [RFC7873] are a lightweight DNS transaction security 348 mechanism that provides limited protection against a variety of 349 increasingly common denial-of-service and amplification/forgery or 350 cache poisoning attacks by off-path attackers. It is noted, however, 351 that they are designed to just verify IP addresses (and should change 352 once a client's IP address changes), but they are not designed to 353 actively track users (like HTTP cookies). 355 There are anecdotal accounts of MAC addresses [1] and even user names 356 being inserted in non-standard EDNS(0) options [RFC6891] for stub to 357 resolver communications to support proprietary functionality 358 implemented at the resolver (e.g., parental filtering). 360 4.3. Cache Snooping 362 The content of recursive resolvers' caches can reveal data about the 363 clients using it (the privacy risks depend on the number of clients). 364 This information can sometimes be examined by sending DNS queries 365 with RD=0 to inspect cache content, particularly looking at the DNS 366 TTLs [grangeia.snooping]. Since this also is a reconnaissance 367 technique for subsequent cache poisoning attacks, some counter 368 measures have already been developed and deployed 369 [cache-snooping-defence]. 371 5. Risks On the Wire 373 5.1. Unencrypted Transports 375 For unencrypted transports, DNS traffic can be seen by an 376 eavesdropper like any other traffic. (DNSSEC, specified in 377 [RFC4033], explicitly excludes confidentiality from its goals.) So, 378 if an initiator starts an HTTPS communication with a recipient, while 379 the HTTP traffic will be encrypted, the DNS exchange prior to it will 380 not be. When other protocols will become more and more privacy-aware 381 and secured against surveillance (e.g., [RFC8446], 382 [I-D.ietf-quic-transport]), the use of unencrypted transports for DNS 383 may become "the weakest link" in privacy. It is noted that at the 384 time of writing there is on-going work attempting to encrypt the SNI 385 in the TLS handshake [RFC8744], which is one of the last remaining 386 non-DNS cleartext identifiers of a connection target. 388 An important specificity of the DNS traffic is that it may take a 389 different path than the communication between the initiator and the 390 recipient. For instance, an eavesdropper may be unable to tap the 391 wire between the initiator and the recipient but may have access to 392 the wire going to the recursive resolver, or to the authoritative 393 name servers. 395 The best place to tap, from an eavesdropper's point of view, is 396 clearly between the stub resolvers and the recursive resolvers, 397 because traffic is not limited by DNS caching. 399 The attack surface between the stub resolver and the rest of the 400 world can vary widely depending upon how the end user's device is 401 configured. By order of increasing attack surface: 403 o The recursive resolver can be on the end user's device. In 404 (currently) a small number of cases, individuals may choose to 405 operate their own DNS resolver on their local machine. In this 406 case, the attack surface for the connection between the stub 407 resolver and the caching resolver is limited to that single 408 machine. The recursive resolver will expose data to authoritative 409 resolvers as discussed in Section 6.2. 411 o The recursive resolver may be at the local network edge. For 412 many/most enterprise networks and for some residential users, the 413 caching resolver may exist on a server at the edge of the local 414 network. In this case, the attack surface is the local network. 415 Note that in large enterprise networks, the DNS resolver may not 416 be located at the edge of the local network but rather at the edge 417 of the overall enterprise network. In this case, the enterprise 418 network could be thought of as similar to the Internet Access 419 Provider (IAP) network referenced below. 421 o The recursive resolver can be in the IAP network. For most 422 residential users and potentially other networks, the typical case 423 is for the end user's device to be configured (typically 424 automatically through DHCP or RA options) with the addresses of 425 the DNS proxy in the Customer Premise Equipment (CPE), which in 426 turns points to the DNS recursive resolvers at the IAP. The 427 attack surface for on-the-wire attacks is therefore from the end 428 user system across the local network and across the IAP network to 429 the IAP's recursive resolvers. 431 o The recursive resolver can be a public DNS service (or a privately 432 run DNS resolver hosted on the public internet). Some machines 433 may be configured to use public DNS resolvers such as those 434 operated by Google Public DNS or OpenDNS. The end user may have 435 configured their machine to use these DNS recursive resolvers 436 themselves -- or their IAP may have chosen to use the public DNS 437 resolvers rather than operating their own resolvers. In this 438 case, the attack surface is the entire public Internet between the 439 end user's connection and the public DNS service. It can be noted 440 that if the user selects a single resolver with a small client 441 population (even when using an encrypted transport) it can 442 actually serve to aid tracking of that user as they move across 443 network environments. 445 It is also noted that typically a device connected _only_ to a modern 446 cellular network is 448 o directly configured with only the recursive resolvers of the IAP 449 and 451 o afforded some level of protection against some types of 452 eavesdropping for all traffic (including DNS traffic) due to the 453 cellular network link-layer encryption. 455 The attack surface for this specific scenario is not considered here. 457 5.2. Encrypted Transports 459 The use of encrypted transports directly mitigates passive 460 surveillance of the DNS payload, however there are still some privacy 461 attacks possible. This section enumerates the residual privacy risks 462 to an end user when an attacker can passively monitor encrypted DNS 463 traffic flows on the wire. 465 These are cases where user identification, fingerprinting or 466 correlations may be possible due to the use of certain transport 467 layers or clear text/observable features. These issues are not 468 specific to DNS, but DNS traffic is susceptible to these attacks when 469 using specific transports. 471 There are some general examples, for example, certain studies have 472 highlighted that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes os- 473 fingerprint [2] values can be used to fingerprint client OS's or that 474 various techniques can be used to de-NAT DNS queries [dns-de-nat]. 476 Note that even when using encrypted transports, the use of clear text 477 transport options to decrease latency can provide correlation of a 478 users' connections, e.g. using TCP Fast Open [RFC7413]. 480 Implementations that support encrypted transports also commonly re- 481 use connections for multiple DNS queries to optimize performance 482 (e.g. via DNS pipelining or HTTPS multiplexing). Default 483 configuration options for encrypted transports could in principle 484 fingerprint a specific client application. For example: 486 o TLS version or cipher suite selection 488 o session resumption 490 o the maximum number of messages to send or 492 o a maximum connection time before closing a connections and re- 493 opening. 495 If libraries or applications offer user configuration of such options 496 (e.g. [getdns]) then they could in principle help to identify a 497 specific user. Users may want to use only the defaults to avoid this 498 issue. 500 Whilst there are known attacks on older versions of TLS the most 501 recent recommendations [RFC7525] and the development of TLS 1.3 502 [RFC8446] largely mitigate those. 504 Traffic analysis of unpadded encrypted traffic is also possible 505 [pitfalls-of-dns-encryption] because the sizes and timing of 506 encrypted DNS requests and responses can be correlated to unencrypted 507 DNS requests upstream of a recursive resolver. 509 6. Risks in the Servers 511 Using the terminology of [RFC6973], the DNS servers (recursive 512 resolvers and authoritative servers) are enablers: they facilitate 513 communication between an initiator and a recipient without being 514 directly in the communications path. As a result, they are often 515 forgotten in risk analysis. But, to quote again [RFC6973], "Although 516 [...] enablers may not generally be considered as attackers, they may 517 all pose privacy threats (depending on the context) because they are 518 able to observe, collect, process, and transfer privacy-relevant 519 data." In [RFC6973] parlance, enablers become observers when they 520 start collecting data. 522 Many programs exist to collect and analyze DNS data at the servers -- 523 from the "query log" of some programs like BIND to tcpdump and more 524 sophisticated programs like PacketQ [packetq] and DNSmezzo 525 [dnsmezzo]. The organization managing the DNS server can use this 526 data itself, or it can be part of a surveillance program like PRISM 527 [prism] and pass data to an outside observer. 529 Sometimes, this data is kept for a long time and/or distributed to 530 third parties for research purposes [ditl] [day-at-root], security 531 analysis, or surveillance tasks. These uses are sometimes under some 532 sort of contract, with various limitations, for instance, on 533 redistribution, given the sensitive nature of the data. Also, there 534 are observation points in the network that gather DNS data and then 535 make it accessible to third parties for research or security purposes 536 ("passive DNS" [passive-dns]). 538 6.1. In the Recursive Resolvers 540 Recursive Resolvers see all the traffic since there is typically no 541 caching before them. To summarize: your recursive resolver knows a 542 lot about you. The resolver of a large IAP, or a large public 543 resolver, can collect data from many users. 545 6.1.1. Resolver Selection 547 Given all the above considerations, the choice of recursive resolver 548 has direct privacy considerations for end users. Historically, end 549 user devices have used the DHCP-provided local network recursive 550 resolver. The choice by a user to join a particular network (e.g. by 551 physically plugging in a cable or selecting a network in a OS 552 dialogue) typically updates a number of system resources - these can 553 include IP addresses, availability of IPv4/IPv6, DHCP server, and DNS 554 resolver. These individual changes, including the change in DNS 555 resolver, are not normally communicated directly to the user by the 556 OS when the network is joined. The choice of network has 557 historically determined the default system DNS resolver selection; 558 the two are directly coupled in this model. 560 The vast majority of users do not change their default system DNS 561 settings and so implicitly accept the network settings for DNS. The 562 network resolvers have therefore historically been the sole 563 destination for all of the DNS queries from a device. These 564 resolvers may have may have varied privacy policies depending on the 565 network. Privacy policies for these servers may or may not be 566 available and users need to be aware that privacy guarantees will 567 vary with network. 569 All major OS's expose the system DNS settings and allow users to 570 manually override them if desired. 572 More recently, some networks and end users have actively chosen to 573 use a large public resolver, e.g., Google Public DNS [3], Cloudflare 574 [4], or Quad9 [5]. There can be many reasons: cost considerations 575 for network operators, better reliability or anti-censorship 576 considerations are just a few. Such services typically do provide a 577 privacy policy and the end user can get an idea of the data collected 578 by such operators by reading one e.g., Google Public DNS - Your 579 Privacy [6]. 581 In general, as with many other protocols, issues around 582 centralization also arise with DNS. The picture is fluid with 583 several competing factors contributing which can also vary by 584 geographic region. These include: 586 o ISP outsourcing, including to third party and public resolvers 588 o regional market domination by one or only a few ISPs 590 o applications directing DNS traffic by default to a limited subset 591 of resolvers, see Section 6.1.1.2 593 An increased proportion of the global DNS resolution traffic being 594 served by only a few entities means that the privacy considerations 595 for end users are highly dependent on the privacy policies and 596 practices of those entities. Many of the issues around 597 centralization are discussed in 598 [centralisation-and-data-sovereignty]. 600 6.1.1.1. Dynamic Discovery of DoH and Strict DoT 602 Whilst support for opportunistic DoT can be determined by probing a 603 resolver on port 853, there is currently no standardized discovery 604 mechanism for DoH and Strict DoT servers. 606 This means that clients which might want to dynamically discover such 607 encrypted services, and where users are willing to trust such 608 services, are not able to do so. At the time of writing, efforts to 609 provide standardized signaling mechanisms to discover the services 610 offered by local resolvers are in progress 611 [I-D.ietf-dnsop-resolver-information]. Note that an increasing 612 numbers of ISPs are deploying encrypted DNS, for example see the 613 Encrypted DNS Deployment Initiative [EDDI]. 615 6.1.1.2. Application-specific Resolver Selection 617 An increasing number of applications are offering application- 618 specific encrypted DNS resolution settings, rather than defaulting to 619 using only the system resolver. A variety of heuristics and 620 resolvers are available in different applications including hard- 621 coded lists of recognized DoH/DoT servers. 623 Users will only be aware of and have the ability to control such 624 settings if applications provide the following functions: 626 o communicate clearly to users the change when the default 627 application resolver changes away from the system resolver 629 o provide configuration options to change the default 631 o provide configuration options to always use the system resolver 633 Application-specific changes to default destinations for users' DNS 634 queries might increase or decrease user privacy - it is highly 635 dependent on the network context and the application-specific 636 default. This is an area of active debate and the IETF is working on 637 a number of issues related to application-specific DNS settings. 639 6.1.2. Active Attacks on Resolver Configuration 641 The previous section discussed DNS privacy, assuming that all the 642 traffic was directed to the intended servers (i.e those that would be 643 used in the absence of an active attack) and that the potential 644 attacker was purely passive. But, in reality, there can be active 645 attackers in the network. 647 The Internet Threat model, as described in [RFC3552], assumes that 648 the attacker controls the network. Such an attacker can completely 649 control any insecure DNS resolution, both passively monitoring the 650 queries and responses and substituting their own responses. Even if 651 encrypted DNS such as DoH or DoT is used, unless the client has been 652 configured in a secure way with the server identity, an active 653 attacker can impersonate the server. This implies that opportunistic 654 modes of DoH/DoT as well as modes where the client learns of the DoH/ 655 DoT server via in-network mechanisms such as DHCP are vulnerable to 656 attack. In addition, if the client is compromised, the attacker can 657 replace the DNS configuration with one of its own choosing. 659 6.1.3. Blocking of User Selected DNS Resolution Services 661 User privacy can also be at risk if there is blocking of access to 662 remote recursive servers that offer encrypted transports e.g., when 663 the local resolver does not offer encryption and/or has very poor 664 privacy policies. For example, active blocking of port 853 for DoT 665 or of specific IP addresses could restrict the resolvers available to 666 the user. The extent of the risk to end user privacy is highly 667 dependent on the specific network and user context; a user on a 668 network that is known to perform surveillance would be compromised if 669 they could not access such services, whereas a user on a trusted 670 network might have no privacy motivation to do so. 672 As a matter of policy, some recursive resolvers use their position in 673 the query path to selectively block access to certain DNS records. 675 This is a form of Rendezvous-Based Blocking as described in 676 Section 4.3 of [RFC7754]. Such blocklists often include servers 677 known to be used for malware, bots or other security risks. In order 678 to prevent circumvention of their blocking policies, some networks 679 also block access to resolvers with incompatible policies. 681 It is also noted that attacks on remote resolver services, e.g., 682 DDoS, could force users to switch to other services that do not offer 683 encrypted transports for DNS. 685 6.1.4. Encrypted Transports and Recursive Resolvers 687 6.1.4.1. DoT and DoH 689 Use of encrypted transports does not reduce the data available in the 690 recursive resolver and ironically can actually expose more 691 information about users to operators. As described in Section 5.2 692 use of session based encrypted transports (TCP/TLS) can expose 693 correlation data about users. 695 6.1.4.2. DoH Specific Considerations 697 DoH inherits the full privacy properties of the HTTPS stack and as a 698 consequence introduces new privacy considerations when compared with 699 DNS over UDP, TCP or TLS [RFC7858]. Section 8.2 of [RFC8484] 700 describes the privacy consideration in the server of the DoH 701 protocol. 703 A brief summary of some of the issues includes: 705 o HTTPS presents new considerations for correlation, such as 706 explicit HTTP cookies and implicit fingerprinting of the unique 707 set and ordering of HTTP request header fields. 709 o The User-Agent and Accept-Language request header fields often 710 convey specific information about the client version or locale. 712 o Utilizing the full set of HTTP features enables DoH to be more 713 than an HTTP tunnel, but it is at the cost of opening up 714 implementations to the full set of privacy considerations of HTTP. 716 o Implementations are advised to expose the minimal set of data 717 needed to achieve the desired feature set. 719 [RFC8484] specifically makes selection of HTTPS functionality vs 720 privacy an implementation choice. At the extremes, there may be 721 implementations that attempt to achieve parity with DoT from a 722 privacy perspective at the cost of using no identifiable HTTP 723 headers, there might be others that provide feature rich data flows 724 where the low-level origin of the DNS query is easily identifiable. 725 Some implementations have, in fact, chosen to restrict the use of the 726 'User-Agent' header so that resolver operators cannot identify the 727 specific application that is originating the DNS queries. 729 Privacy focused users should be aware of the potential for additional 730 client identifiers in DoH compared to DoT and may want to only use 731 DoH client implementations that provide clear guidance on what 732 identifiers they add. 734 6.2. In the Authoritative Name Servers 736 Unlike what happens for recursive resolvers, observation capabilities 737 of authoritative name servers are limited by caching; they see only 738 the requests for which the answer was not in the cache. For 739 aggregated statistics ("What is the percentage of LOC queries?"), 740 this is sufficient, but it prevents an observer from seeing 741 everything. Similarly the increasing deployment of QNAME 742 minimisation [ripe-qname-measurements] reduces the data visible at 743 the authoritative name server. Still, the authoritative name servers 744 see a part of the traffic, and this subset may be sufficient to 745 violate some privacy expectations. 747 Also, the end user often has some legal/contractual link with the 748 recursive resolver (he has chosen the IAP, or he has chosen to use a 749 given public resolver), while having no control and perhaps no 750 awareness of the role of the authoritative name servers and their 751 observation abilities. 753 As noted before, using a local resolver or a resolver close to the 754 machine decreases the attack surface for an on-the-wire eavesdropper. 755 But it may decrease privacy against an observer located on an 756 authoritative name server. This authoritative name server will see 757 the IP address of the end client instead of the address of a big 758 recursive resolver shared by many users. 760 This "protection", when using a large resolver with many clients, is 761 no longer present if ECS [RFC7871] is used because, in this case, the 762 authoritative name server sees the original IP address (or prefix, 763 depending on the setup). 765 As of today, all the instances of one root name server, L-root, 766 receive together around 50,000 queries per second. While most of it 767 is "junk" (errors on the Top-Level Domain (TLD) name), it gives an 768 idea of the amount of big data that pours into name servers. (And 769 even "junk" can leak information; for instance, if there is a typing 770 error in the TLD, the user will send data to a TLD that is not the 771 usual one.) 773 Many domains, including TLDs, are partially hosted by third-party 774 servers, sometimes in a different country. The contracts between the 775 domain manager and these servers may or may not take privacy into 776 account. Whatever the contract, the third-party hoster may be honest 777 or not but, in any case, it will have to follow its local laws. For 778 example, requests to a given ccTLD may go to servers managed by 779 organizations outside of the ccTLD's country. End users may not 780 anticipate that, when doing a security analysis. 782 Also, it seems (see the survey described in [aeris-dns]) that there 783 is a strong concentration of authoritative name servers among 784 "popular" domains (such as the Alexa Top N list). For instance, 785 among the Alexa Top 100K [7], one DNS provider hosts today 10% of the 786 domains. The ten most important DNS providers host together one 787 third of the domains. With the control (or the ability to sniff the 788 traffic) of a few name servers, you can gather a lot of information. 790 7. Other risks 792 7.1. Re-identification and Other Inferences 794 An observer has access not only to the data he/she directly collects 795 but also to the results of various inferences about this data. The 796 term 'observer' here is used very generally, it might be one that is 797 passively observing cleartext DNS traffic, one in the network that is 798 actively attacking the user by re-directing DNS resolution, or it 799 might be a local or remote resolver operator. 801 For instance, a user can be re-identified via DNS queries. If the 802 adversary knows a user's identity and can watch their DNS queries for 803 a period, then that same adversary may be able to re-identify the 804 user solely based on their pattern of DNS queries later on regardless 805 of the location from which the user makes those queries. For 806 example, one study [herrmann-reidentification] found that such re- 807 identification is possible so that "73.1% of all day-to-day links 808 were correctly established, i.e., user u was either re-identified 809 unambiguously (1) or the classifier correctly reported that u was not 810 present on day t+1 any more (2)." While that study related to web 811 browsing behavior, equally characteristic patterns may be produced 812 even in machine-to-machine communications or without a user taking 813 specific actions, e.g., at reboot time if a characteristic set of 814 services are accessed by the device. 816 For instance, one could imagine that an intelligence agency 817 identifies people going to a site by putting in a very long DNS name 818 and looking for queries of a specific length. Such traffic analysis 819 could weaken some privacy solutions. 821 The IAB privacy and security program also have a document [RFC7624] 822 that considers such inference-based attacks in a more general 823 framework. 825 7.2. More Information 827 Useful background information can also be found in [tor-leak] (about 828 the risk of privacy leak through DNS) and in a few academic papers: 829 [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and 830 [federrath-fuchs-herrmann-piosecny]. 832 8. Actual "Attacks" 834 A very quick examination of DNS traffic may lead to the false 835 conclusion that extracting the needle from the haystack is difficult. 836 "Interesting" primary DNS requests are mixed with useless (for the 837 eavesdropper) secondary and tertiary requests (see the terminology in 838 Section 1). But, in this time of "big data" processing, powerful 839 techniques now exist to get from the raw data to what the 840 eavesdropper is actually interested in. 842 Many research papers about malware detection use DNS traffic to 843 detect "abnormal" behavior that can be traced back to the activity of 844 malware on infected machines. Yes, this research was done for the 845 good, but technically it is a privacy attack and it demonstrates the 846 power of the observation of DNS traffic. See [dns-footprint], 847 [dagon-malware], and [darkreading-dns]. 849 Passive DNS systems [passive-dns] allow reconstruction of the data of 850 sometimes an entire zone. Well-known passive DNS systems keep only 851 the DNS responses, and not the source IP address of the client, 852 precisely for privacy reasons. Other passive DNS systems may not be 853 so careful. And there is still the potential problems with revealing 854 QNAMEs. 856 The revelations from the Edward Snowden documents, which were leaked 857 from the National Security Agency (NSA), provide evidence of the use 858 of the DNS in mass surveillance operations [morecowbell]. For 859 example the MORECOWBELL surveillance program, which uses a dedicated 860 covert monitoring infrastructure to actively query DNS servers and 861 perform HTTP requests to obtain meta information about services and 862 to check their availability. Also the QUANTUMTHEORY [8] project 863 which includes detecting lookups for certain addresses and injecting 864 bogus replies is another good example showing that the lack of 865 privacy protections in the DNS is actively exploited. 867 9. Legalities 869 To our knowledge, there are no specific privacy laws for DNS data, in 870 any country. Interpreting general privacy laws like 871 [data-protection-directive] or GDPR [9] applicable in the European 872 Union in the context of DNS traffic data is not an easy task, and 873 there is no known court precedent. See an interesting analysis in 874 [sidn-entrada]. 876 10. Security Considerations 878 This document is entirely about security, more precisely privacy. It 879 just lays out the problem; it does not try to set requirements (with 880 the choices and compromises they imply), much less define solutions. 881 Possible solutions to the issues described here are discussed in 882 other documents (currently too many to all be mentioned); see, for 883 instance, 'Recommendations for DNS Privacy Operators' 884 [I-D.ietf-dprive-bcp-op]. 886 11. IANA Considerations 888 This document makes no requests of the IANA. 890 12. Contributions 892 Sara Dickinson and Stephane Bortzmeyer were the original authors on 893 the document, and their contribution on the initial version is 894 greatly appreciated. 896 13. Acknowledgments 898 Thanks to Nathalie Boulvard and to the CENTR members for the original 899 work that led to this document. Thanks to Ondrej Sury for the 900 interesting discussions. Thanks to Mohsen Souissi and John Heidemann 901 for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz, 902 Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for 903 proofreading, providing technical remarks, and making many 904 readability improvements. Thanks to Dan York, Suzanne Woolf, Tony 905 Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis 906 for good written contributions. Thanks to Vittorio Bertola and 907 Mohamed Boucadair for a detailed review of the -bis. And thanks to 908 the IESG members for the last remarks. 910 14. References 911 14.1. Normative References 913 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 914 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 915 . 917 [RFC1035] Mockapetris, P., "Domain names - implementation and 918 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 919 November 1987, . 921 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 922 Morris, J., Hansen, M., and R. Smith, "Privacy 923 Considerations for Internet Protocols", RFC 6973, 924 DOI 10.17487/RFC6973, July 2013, 925 . 927 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 928 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 929 2014, . 931 14.2. Informative References 933 [aeris-dns] 934 Vinot, N., "Vie privee: et le DNS alors?", (In French), 935 2015, 936 . 938 [cache-snooping-defence] 939 ISC, "ISC Knowledge Database: DNS Cache snooping - should 940 I be concerned?", 2018, 941 . 943 [castillo-garcia] 944 Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous 945 Resolution of DNS Queries", 2008, 946 . 948 [centralisation-and-data-sovereignty] 949 De Filippi, P. and S. McCarthy, "Cloud Computing: 950 Centralization and Data Sovereignty", October 2012, 951 . 954 [dagon-malware] 955 Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a 956 Malicious Resolution Authority", ISC/OARC Workshop, 2007, 957 . 960 [darkreading-dns] 961 Lemos, R., "Got Malware? Three Signs Revealed In DNS 962 Traffic", InformationWeek Dark Reading, May 2013, 963 . 967 [data-protection-directive] 968 European Parliament, "Directive 95/46/EC of the European 969 Parliament and of the council on the protection of 970 individuals with regard to the processing of personal data 971 and on the free movement of such data", Official Journal L 972 281, pp. 0031 - 0050, November 1995, . 976 [day-at-root] 977 Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A 978 Day at the Root of the Internet", ACM SIGCOMM Computer 979 Communication Review, Vol. 38, Number 5, 980 DOI 10.1145/1452335.1452341, October 2008, 981 . 984 [denis-edns-client-subnet] 985 Denis, F., "Security and privacy issues of edns-client- 986 subnet", August 2013, 987 . 989 [ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002, 990 . 992 [dns-footprint] 993 Stoner, E., "DNS Footprint of Malware", OARC Workshop, 994 October 2010, . 997 [dnsmezzo] 998 Bortzmeyer, S., "DNSmezzo", 2009, 999 . 1001 [EDDI] EDDI, "Encrypted DNS Deployment Initiative", 2020, 1002 . 1004 [fangming-hori-sakurai] 1005 Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of 1006 Privacy Disclosure in DNS Query", 2007 International 1007 Conference on Multimedia and Ubiquitous Engineering (MUE 1008 2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957, 1009 DOI 10.1109/MUE.2007.84, April 2007, 1010 . 1012 [federrath-fuchs-herrmann-piosecny] 1013 Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny, 1014 "Privacy-Preserving DNS: Analysis of Broadcast, Range 1015 Queries and Mix-based Protection Methods", Computer 1016 Security ESORICS 2011, Springer, page(s) 665-683, 1017 ISBN 978-3-642-23821-5, 2011, . 1021 [getdns] getdns, "getdns - A modern asynchronous DNS API", January 1022 2020, . 1024 [grangeia.snooping] 1025 Grangeia, L., "DNS Cache Snooping or Snooping the Cache 1026 for Fun and Profit", 2005, 1027 . 1031 [herrmann-reidentification] 1032 Herrmann, D., Gerber, C., Banse, C., and H. Federrath, 1033 "Analyzing Characteristic Host Access Patterns for Re- 1034 Identification of Web User Sessions", 1035 DOI 10.1007/978-3-642-27937-9_10, 2012, . 1038 [I-D.ietf-dnsop-resolver-information] 1039 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 1040 Information Self-publication", draft-ietf-dnsop-resolver- 1041 information-01 (work in progress), February 2020. 1043 [I-D.ietf-dprive-bcp-op] 1044 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 1045 Mankin, "Recommendations for DNS Privacy Service 1046 Operators", draft-ietf-dprive-bcp-op-14 (work in 1047 progress), July 2020. 1049 [I-D.ietf-dprive-dnsoquic] 1050 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1051 of DNS over Dedicated QUIC Connections", draft-ietf- 1052 dprive-dnsoquic-00 (work in progress), April 2020. 1054 [I-D.ietf-quic-transport] 1055 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1056 and Secure Transport", draft-ietf-quic-transport-31 (work 1057 in progress), September 2020. 1059 [morecowbell] 1060 Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, 1061 "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January 1062 2015, . 1065 [packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries 1066 against PCAP-files", 2011, 1067 . 1069 [passive-dns] 1070 Weimer, F., "Passive DNS Replication", April 2005, 1071 . 1074 [pitfalls-of-dns-encryption] 1075 Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS 1076 Encryption", . 1078 [prism] Wikipedia, "PRISM (surveillance program)", July 2015, 1079 . 1082 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1083 Text on Security Considerations", BCP 72, RFC 3552, 1084 DOI 10.17487/RFC3552, July 2003, 1085 . 1087 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1088 Rose, "DNS Security Introduction and Requirements", 1089 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1090 . 1092 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records 1093 and DNSSEC On-line Signing", RFC 4470, 1094 DOI 10.17487/RFC4470, April 2006, 1095 . 1097 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1098 Security (DNSSEC) Hashed Authenticated Denial of 1099 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1100 . 1102 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1103 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1104 . 1106 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1107 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1108 DOI 10.17487/RFC6269, June 2011, 1109 . 1111 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1112 for DNS (EDNS(0))", STD 75, RFC 6891, 1113 DOI 10.17487/RFC6891, April 2013, 1114 . 1116 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1117 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1118 . 1120 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1121 "Recommendations for Secure Use of Transport Layer 1122 Security (TLS) and Datagram Transport Layer Security 1123 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1124 2015, . 1126 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1127 Trammell, B., Huitema, C., and D. Borkmann, 1128 "Confidentiality in the Face of Pervasive Surveillance: A 1129 Threat Model and Problem Statement", RFC 7624, 1130 DOI 10.17487/RFC7624, August 2015, 1131 . 1133 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1134 Considerations for IPv6 Address Generation Mechanisms", 1135 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1136 . 1138 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1139 Nordmark, "Technical Considerations for Internet Service 1140 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1141 March 2016, . 1143 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1144 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1145 . 1147 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1148 and P. Hoffman, "Specification for DNS over Transport 1149 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1150 2016, . 1152 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1153 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1154 DOI 10.17487/RFC7871, May 2016, 1155 . 1157 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1158 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1159 . 1161 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 1162 (DANE) Bindings for OpenPGP", RFC 7929, 1163 DOI 10.17487/RFC7929, August 2016, 1164 . 1166 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1167 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1168 . 1170 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1171 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1172 . 1174 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1175 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1176 January 2019, . 1178 [RFC8744] Huitema, C., "Issues and Requirements for Server Name 1179 Identification (SNI) Encryption in TLS", RFC 8744, 1180 DOI 10.17487/RFC8744, July 2020, 1181 . 1183 [ripe-qname-measurements] 1184 Vries, W., "Making the DNS More Private with QNAME 1185 Minimisation", April 2019, 1186 . 1189 [sidn-entrada] 1190 Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. 1191 Simon, "A privacy framework for 'DNS big data' 1192 applications", November 2014, 1193 . 1197 [thomas-ditl-tcp] 1198 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 1199 Root Server DITL Data", DNS-OARC 2014 Fall Workshop, 1200 October 2014, . 1204 [tor-leak] 1205 Tor, "DNS leaks in Tor", 2013, 1206 . 1209 [yanbin-tsudik] 1210 Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks 1211 in the Domain Name System", October 2009, 1212 . 1214 14.3. URIs 1216 [1] https://lists.dns-oarc.net/pipermail/dns- 1217 operations/2016-January/014143.html 1219 [2] http://netres.ec/?b=11B99BD 1221 [3] https://developers.google.com/speed/public-dns 1223 [4] https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/ 1225 [5] https://www.quad9.net 1227 [6] https://developers.google.com/speed/public-dns/privacy 1229 [7] https://www.alexa.com/topsites 1231 [8] https://theintercept.com/document/2014/03/12/nsa-gchqs- 1232 quantumtheory-hacking-tactics/ 1234 [9] https://www.eugdpr.org/the-regulation.html 1236 Appendix A. Updates since RFC7626 1238 Update many references; Add discussions of encrypted transports 1239 including DoT and DoH; Added section on DNS payload; Add section on 1240 authentication of servers; Add section on blocking of services. With 1241 the publishing of RFC7816 on QNAME minimisation, text, references, 1242 and initial attempts to measure deployment were added to reflect 1243 this. The text and references on the Snowden revelations were 1244 updated. 1246 The "Risks overview" section was changed to "Scope" to help clarify 1247 the risks being considered. Text was adding on cellular network DNS, 1248 blocking and security. Considerations for recursive resolvers were 1249 collected and placed together. Addded a discussion on resolver 1250 selection. 1252 Appendix B. Changelog 1254 draft-ietf-dprive-rfc7626-bis-05 1256 o Second batch of Editorial updates from IESG last call 1258 draft-ietf-dprive-rfc7626-bis-07 1260 o First batch of Editorial updates from IESG last call 1262 draft-ietf-dprive-rfc7626-bis-06 1264 o Removed Sara and Stephane as editors, made chairs as Editor. 1266 o Replaced the text in 6.1.1.2 with the text from the -04 version. 1268 o Clarified text about resolver selection in 6.1.1. 1270 draft-ietf-dprive-rfc7626-bis-05 1272 o Editorial updates from second IESG last call 1274 o Section renumbering as suggested by Vittorio Bertola 1276 draft-ietf-dprive-rfc7626-bis-04 1278 o Tsvart review: Add reference to DNS-over-QUIC, fix typo. 1280 o Secdir review: Add text in Section 3 on devices using many 1281 networks. Update bullet in 3.4.1 on cellular encryption. 1283 o Section 3.5.1.1 - re-work the section to try to address multiple 1284 comments. 1286 o Section 3.5.1.4 - remove this section as now covered by 3.5.1.1. 1288 o Section 3.5.1.5.2 - Remove several paragraphs and more directly 1289 reference RFC8484 by including bullet points quoting text from 1290 Section 8.2 of RFC8484. Retain the last 2 paragraphs as they are 1291 information for users, not implementors. 1293 o Section 3.4.2 - some minor updates made based on specific 1294 comments. 1296 draft-ietf-dprive-rfc7626-bis-03 1298 o Address 2 minor nits (typo in section 3.4.1 and adding an IANA 1299 section) 1301 o Minor updates from AD review 1303 draft-ietf-dprive-rfc7626-bis-02 1305 o Numerous editorial corrections thanks to Mohamed Boucadair and 1307 * Minor additions to Scope section 1309 * New text on cellular network DNS 1311 o Additional text from Vittorio Bertola on blocking and security 1313 draft-ietf-dprive-rfc7626-bis-01 1315 o Re-structure section 3.5 (was 2.5) 1317 * Collect considerations for recursive resolvers together 1319 * Re-work several sections here to clarify their context (e.g., 1320 'Rogue servers' becomes 'Active attacks on resolver 1321 configuration') 1323 * Add discussion of resolver selection 1325 o Update text and old reference on Snowdon revelations. 1327 o Add text on and references to QNAME minimisation RFC and 1328 deployment measurements 1330 o Correct outdated references 1331 o Clarify scope by adding a Scope section (was Risks overview) 1333 o Clarify what risks are considered in section 3.4.2 1335 draft-ietf-dprive-rfc7626-bis-00 1337 o Rename after WG adoption 1339 o Use DoT acronym throughout 1341 o Minor updates to status of deployment and other drafts 1343 draft-bortzmeyer-dprive-rfc7626-bis-02 1345 o Update various references and fix some nits. 1347 draft-bortzmeyer-dprive-rfc7626-bis-01 1349 o Update reference for dickinson-bcp-op to draft-dickinson-dprive- 1350 bcp-op 1352 draft-borztmeyer-dprive-rfc7626-bis-00: 1354 Initial commit. Differences to RFC7626: 1356 o Update many references 1358 o Add discussions of encrypted transports including DoT and DoH 1360 o Add section on DNS payload 1362 o Add section on authentication of servers 1364 o Add section on blocking of services 1366 Author's Address 1368 Tim Wicinski (editor) 1369 Elkins, WV 26241 1370 USA 1372 Email: tjw.ietf@gmail.com