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