idnits 2.17.1 draft-ietf-dprive-rfc7626-bis-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 16, 2020) is 1560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1251 -- Looks like a reference, but probably isn't: '2' on line 1254 -- Looks like a reference, but probably isn't: '3' on line 1256 -- Looks like a reference, but probably isn't: '4' on line 1259 -- Looks like a reference, but probably isn't: '5' on line 1261 -- Looks like a reference, but probably isn't: '6' on line 1263 -- Looks like a reference, but probably isn't: '7' on line 1265 -- Looks like a reference, but probably isn't: '8' on line 1267 -- Looks like a reference, but probably isn't: '9' on line 1269 -- Looks like a reference, but probably isn't: '10' on line 1272 == Outdated reference: A later version (-01) exists of draft-ietf-dnsop-resolver-information-00 == Outdated reference: A later version (-14) exists of draft-ietf-dprive-bcp-op-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 -- 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 (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Bortzmeyer 3 Internet-Draft AFNIC 4 Obsoletes: 7626 (if approved) S. Dickinson 5 Intended status: Informational Sinodun IT 6 Expires: July 19, 2020 January 16, 2020 8 DNS Privacy Considerations 9 draft-ietf-dprive-rfc7626-bis-04 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 http://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 July 19, 2020. 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 (http://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 3.1. The Alleged Public Nature of DNS Data . . . . . . . . . . 5 56 3.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 6 57 3.2.1. Data in the DNS payload . . . . . . . . . . . . . . . 7 58 3.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 8 59 3.4. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4.1. Unencrypted Transports . . . . . . . . . . . . . . . 8 61 3.4.2. Encrypted Transports . . . . . . . . . . . . . . . . 10 62 3.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 11 63 3.5.1. In the Recursive Resolvers . . . . . . . . . . . . . 11 64 3.5.2. In the Authoritative Name Servers . . . . . . . . . . 15 65 3.6. Re-identification and Other Inferences . . . . . . . . . 16 66 3.7. More Information . . . . . . . . . . . . . . . . . . . . 17 67 4. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 17 68 5. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 72 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 75 10.2. Informative References . . . . . . . . . . . . . . . . . 21 76 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 79 1. Introduction 81 This document is an analysis of the DNS privacy issues, in the spirit 82 of Section 8 of [RFC6973]. 84 The Domain Name System (DNS) is specified in [RFC1034], [RFC1035], 85 and many later RFCs, which have never been consolidated. It is one 86 of the most important infrastructure components of the Internet and 87 often ignored or misunderstood by Internet users (and even by many 88 professionals). Almost every activity on the Internet starts with a 89 DNS query (and often several). Its use has many privacy implications 90 and this document is an attempt at a comprehensive and accurate list. 92 Let us begin with a simplified reminder of how the DNS works (See 93 also [RFC8499]). A client, the stub resolver, issues a DNS query to 94 a server, called the recursive resolver (also called caching resolver 95 or full resolver or recursive name server). Let's use the query 96 "What are the AAAA records for www.example.com?" as an example. AAAA 97 is the QTYPE (Query Type), and www.example.com is the QNAME (Query 98 Name). (The description that follows assumes a cold cache, for 99 instance, because the server just started.) The recursive resolver 100 will first query the root name servers. In most cases, the root name 101 servers will send a referral. In this example, the referral will be 102 to the .com name servers. The resolver repeats the query to one of 103 the .com name servers. The .com name servers, in turn, will refer to 104 the example.com name servers. The example.com name server will then 105 return the answer. The root name servers, the name servers of .com, 106 and the name servers of example.com are called authoritative name 107 servers. It is important, when analyzing the privacy issues, to 108 remember that the question asked to all these name servers is always 109 the original question, not a derived question. The question sent to 110 the root name servers is "What are the AAAA records for 111 www.example.com?", not "What are the name servers of .com?". By 112 repeating the full question, instead of just the relevant part of the 113 question to the next in line, the DNS provides more information than 114 necessary to the name server. In this simplified description, 115 recursive resolvers do not implement QNAME minimization as described 116 in [RFC7816], which will only send the relevant part of the question 117 to the upstream name server. 119 Because DNS relies on caching heavily, the algorithm described above 120 is actually a bit more complicated, and not all questions are sent to 121 the authoritative name servers. If a few seconds later the stub 122 resolver asks the recursive resolver, "What are the SRV records of 123 _xmpp-server._tcp.example.com?", the recursive resolver will remember 124 that it knows the name servers of example.com and will just query 125 them, bypassing the root and .com. Because there is typically no 126 caching in the stub resolver, the recursive resolver, unlike the 127 authoritative servers, sees all the DNS traffic. (Applications, like 128 web browsers, may have some form of caching that does not follow DNS 129 rules, for instance, because it may ignore the TTL. So, the 130 recursive resolver does not see all the name resolution activity.) 132 It should be noted that DNS recursive resolvers sometimes forward 133 requests to other recursive resolvers, typically bigger machines, 134 with a larger and more shared cache (and the query hierarchy can be 135 even deeper, with more than two levels of recursive resolvers). From 136 the point of view of privacy, these forwarders are like resolvers, 137 except that they do not see all of the requests being made (due to 138 caching in the first resolver). 140 At the time of writing, almost all this DNS traffic is currently sent 141 in clear (i.e., unencrypted). However there is increasing deployment 142 of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], 143 particularly in mobile devices, browsers, and by providers of anycast 144 recursive DNS resolution services. There are a few cases where there 145 is some alternative channel encryption, for instance, in an IPsec VPN 146 tunnel, at least between the stub resolver and the resolver. 148 Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. 149 This has practical consequences when considering encryption of the 150 traffic as a possible privacy technique. Some encryption solutions 151 are only designed for TCP, not UDP and new solutions are still 152 emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic]. 154 Another important point to keep in mind when analyzing the privacy 155 issues of DNS is the fact that DNS requests received by a server are 156 triggered by different reasons. Let's assume an eavesdropper wants 157 to know which web page is viewed by a user. For a typical web page, 158 there are three sorts of DNS requests being issued: 160 o Primary request: this is the domain name in the URL that the user 161 typed, selected from a bookmark, or chose by clicking on an 162 hyperlink. Presumably, this is what is of interest for the 163 eavesdropper. 165 o Secondary requests: these are the additional requests performed by 166 the user agent (here, the web browser) without any direct 167 involvement or knowledge of the user. For the Web, they are 168 triggered by embedded content, Cascading Style Sheets (CSS), 169 JavaScript code, embedded images, etc. In some cases, there can 170 be dozens of domain names in different contexts on a single web 171 page. 173 o Tertiary requests: these are the additional requests performed by 174 the DNS system itself. For instance, if the answer to a query is 175 a referral to a set of name servers, and the glue records are not 176 returned, the resolver will have to do additional requests to turn 177 the name servers' names into IP addresses. Similarly, even if 178 glue records are returned, a careful recursive server will do 179 tertiary requests to verify the IP addresses of those records. 181 It can be noted also that, in the case of a typical web browser, more 182 DNS requests than strictly necessary are sent, for instance, to 183 prefetch resources that the user may query later or when 184 autocompleting the URL in the address bar. Both are a big privacy 185 concern since they may leak information even about non-explicit 186 actions. For instance, just reading a local HTML page, even without 187 selecting the hyperlinks, may trigger DNS requests. 189 For privacy-related terms, we will use the terminology from 190 [RFC6973]. 192 2. Scope 194 This document focuses mostly on the study of privacy risks for the 195 end user (the one performing DNS requests). We consider the risks of 196 pervasive surveillance [RFC7258] as well as risks coming from a more 197 focused surveillance. 199 This document does not attempt a comparison of specific privacy 200 protections provided by individual networks or organizations, it 201 makes only general observations about typical current practices. 203 Privacy risks for the holder of a zone (the risk that someone gets 204 the data) are discussed in [RFC5936] and [RFC5155]. 206 Privacy risks for recursive operators (including access providers and 207 operators in enterprise networks) such as leakage of private 208 namespaces or blocklists are out of scope for this document. 210 Non-privacy risks (e.g security related considerations such as cache 211 poisoning) are also out of scope. 213 The privacy risks associated with the use of other protocols that 214 make use of DNS information are not considered here. 216 3. Risks 218 This section outlines the privacy considerations associated with 219 different aspects of the DNS for the end user. When reading this 220 section it needs to be kept in mind that many of the considerations 221 (for example, recursive resolver and transport protocol) can be 222 specific to the network context that a device is using at a given 223 point in time. A user may have many devices and each device might 224 utilize many different networks (e.g. home, work, public or cellular) 225 over a period of time or even concurrently. An exhaustive analysis 226 of the privacy considerations for an individual user would need to 227 take into account the set of devices used and the multiple dynamic 228 contexts of each device. This document does not attempt such a 229 complex analysis, instead it presents an overview of the various 230 considerations that could form the basis of such an analysis. 232 3.1. The Alleged Public Nature of DNS Data 234 It has long been claimed that "the data in the DNS is public". While 235 this sentence makes sense for an Internet-wide lookup system, there 236 are multiple facets to the data and metadata involved that deserve a 237 more detailed look. First, access control lists (ACLs) and private 238 namespaces notwithstanding, the DNS operates under the assumption 239 that public-facing authoritative name servers will respond to "usual" 240 DNS queries for any zone they are authoritative for without further 241 authentication or authorization of the client (resolver). Due to the 242 lack of search capabilities, only a given QNAME will reveal the 243 resource records associated with that name (or that name's non- 244 existence). In other words: one needs to know what to ask for, in 245 order to receive a response. The zone transfer QTYPE [RFC5936] is 246 often blocked or restricted to authenticated/authorized access to 247 enforce this difference (and maybe for other reasons). 249 Another differentiation to be considered is between the DNS data 250 itself and a particular transaction (i.e., a DNS name lookup). DNS 251 data and the results of a DNS query are public, within the boundaries 252 described above, and may not have any confidentiality requirements. 253 However, the same is not true of a single transaction or a sequence 254 of transactions; that transaction is not / should not be public. A 255 typical example from outside the DNS world is: the web site of 256 Alcoholics Anonymous is public; the fact that you visit it should not 257 be. 259 3.2. Data in the DNS Request 261 The DNS request includes many fields, but two of them seem 262 particularly relevant for the privacy issues: the QNAME and the 263 source IP address. "source IP address" is used in a loose sense of 264 "source IP address + maybe source port number", because the port 265 number is also in the request and can be used to differentiate 266 between several users sharing an IP address (behind a Carrier-Grade 267 NAT (CGN), for instance [RFC6269]). 269 The QNAME is the full name sent by the user. It gives information 270 about what the user does ("What are the MX records of example.net?" 271 means he probably wants to send email to someone at example.net, 272 which may be a domain used by only a few persons and is therefore 273 very revealing about communication relationships). Some QNAMEs are 274 more sensitive than others. For instance, querying the A record of a 275 well-known web statistics domain reveals very little (everybody 276 visits web sites that use this analytics service), but querying the A 277 record of www.verybad.example where verybad.example is the domain of 278 an organization that some people find offensive or objectionable may 279 create more problems for the user. Also, sometimes, the QNAME embeds 280 the software one uses, which could be a privacy issue. For instance, 281 _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. 282 There are also some BitTorrent clients that query an SRV record for 283 _bittorrent-tracker._tcp.domain.example. 285 Another important thing about the privacy of the QNAME is the future 286 usages. Today, the lack of privacy is an obstacle to putting 287 potentially sensitive or personally identifiable data in the DNS. At 288 the moment, your DNS traffic might reveal that you are doing email 289 but not with whom. If your Mail User Agent (MUA) starts looking up 290 Pretty Good Privacy (PGP) keys in the DNS [RFC7929], then privacy 291 becomes a lot more important. And email is just an example; there 292 would be other really interesting uses for a more privacy-friendly 293 DNS. 295 For the communication between the stub resolver and the recursive 296 resolver, the source IP address is the address of the user's machine. 297 Therefore, all the issues and warnings about collection of IP 298 addresses apply here. For the communication between the recursive 299 resolver and the authoritative name servers, the source IP address 300 has a different meaning; it does not have the same status as the 301 source address in an HTTP connection. It is typically the IP address 302 of the recursive resolver that, in a way, "hides" the real user. 303 However, hiding does not always work. Sometimes EDNS(0) Client 304 subnet [RFC7871] is used (see its privacy analysis in 305 [denis-edns-client-subnet]). Sometimes the end user has a personal 306 recursive resolver on her machine. In both cases, the IP address is 307 as sensitive as it is for HTTP [sidn-entrada]. 309 A note about IP addresses: there is currently no IETF document that 310 describes in detail all the privacy issues around IP addressing in 311 general, although [RFC7721] does discuss privacy considerations for 312 IPv6 address generation mechanisms. In the meantime, the discussion 313 here is intended to include both IPv4 and IPv6 source addresses. For 314 a number of reasons, their assignment and utilization characteristics 315 are different, which may have implications for details of information 316 leakage associated with the collection of source addresses. (For 317 example, a specific IPv6 source address seen on the public Internet 318 is less likely than an IPv4 address to originate behind an address 319 sharing scheme.) However, for both IPv4 and IPv6 addresses, it is 320 important to note that source addresses are propagated with queries 321 and comprise metadata about the host, user, or application that 322 originated them. 324 3.2.1. Data in the DNS payload 326 At the time of writing there are no standardized client identifiers 327 contained in the DNS payload itself (ECS [RFC7871] while widely used 328 is only of Category Informational). 330 DNS Cookies [RFC7873] are a lightweight DNS transaction security 331 mechanism that provides limited protection against a variety of 332 increasingly common denial-of-service and amplification/forgery or 333 cache poisoning attacks by off-path attackers. It is noted, however, 334 that they are designed to just verify IP addresses (and should change 335 once a client's IP address changes), they are not designed to 336 actively track users (like HTTP cookies). 338 There are anecdotal accounts of MAC addresses [1] and even user names 339 being inserted in non-standard EDNS(0) options for stub to resolver 340 communications to support proprietary functionality implemented at 341 the resolver (e.g., parental filtering). 343 3.3. Cache Snooping 345 The content of recursive resolvers' caches can reveal data about the 346 clients using it (the privacy risks depend on the number of clients). 347 This information can sometimes be examined by sending DNS queries 348 with RD=0 to inspect cache content, particularly looking at the DNS 349 TTLs [grangeia.snooping]. Since this also is a reconnaissance 350 technique for subsequent cache poisoning attacks, some counter 351 measures have already been developed and deployed. 353 3.4. On the Wire 355 3.4.1. Unencrypted Transports 357 For unencrypted transports, DNS traffic can be seen by an 358 eavesdropper like any other traffic. (DNSSEC, specified in 359 [RFC4033], explicitly excludes confidentiality from its goals.) So, 360 if an initiator starts an HTTPS communication with a recipient, while 361 the HTTP traffic will be encrypted, the DNS exchange prior to it will 362 not be. When other protocols will become more and more privacy-aware 363 and secured against surveillance (e.g., [RFC8446], 364 [I-D.ietf-quic-transport]), the use of unencrypted transports for DNS 365 may become "the weakest link" in privacy. It is noted that at the 366 time of writing there is on-going work attempting to encrypt the SNI 367 in the TLS handshake [I-D.ietf-tls-sni-encryption]. 369 An important specificity of the DNS traffic is that it may take a 370 different path than the communication between the initiator and the 371 recipient. For instance, an eavesdropper may be unable to tap the 372 wire between the initiator and the recipient but may have access to 373 the wire going to the recursive resolver, or to the authoritative 374 name servers. 376 The best place to tap, from an eavesdropper's point of view, is 377 clearly between the stub resolvers and the recursive resolvers, 378 because traffic is not limited by DNS caching. 380 The attack surface between the stub resolver and the rest of the 381 world can vary widely depending upon how the end user's device is 382 configured. By order of increasing attack surface: 384 o The recursive resolver can be on the end user's device. In 385 (currently) a small number of cases, individuals may choose to 386 operate their own DNS resolver on their local machine. In this 387 case, the attack surface for the connection between the stub 388 resolver and the caching resolver is limited to that single 389 machine. 391 o The recursive resolver may be at the local network edge. For 392 many/most enterprise networks and for some residential users, the 393 caching resolver may exist on a server at the edge of the local 394 network. In this case, the attack surface is the local network. 395 Note that in large enterprise networks, the DNS resolver may not 396 be located at the edge of the local network but rather at the edge 397 of the overall enterprise network. In this case, the enterprise 398 network could be thought of as similar to the Internet Access 399 Provider (IAP) network referenced below. 401 o The recursive resolver can be in the IAP network. For most 402 residential users and potentially other networks, the typical case 403 is for the end user's device to be configured (typically 404 automatically through DHCP or RA options) with the addresses of 405 the DNS proxy in the CPE, which in turns points to the DNS 406 recursive resolvers at the IAP. The attack surface for on-the- 407 wire attacks is therefore from the end user system across the 408 local network and across the IAP network to the IAP's recursive 409 resolvers. 411 o The recursive resolver can be a public DNS service. Some machines 412 may be configured to use public DNS resolvers such as those 413 operated by Google Public DNS or OpenDNS. The end user may have 414 configured their machine to use these DNS recursive resolvers 415 themselves -- or their IAP may have chosen to use the public DNS 416 resolvers rather than operating their own resolvers. In this 417 case, the attack surface is the entire public Internet between the 418 end user's connection and the public DNS service. 420 It is also noted that typically a device connected _only_ to a modern 421 cellular network is 423 o directly configured with only the recursive resolvers of the IAP 424 and 426 o afforded some level of protection against some types of 427 eavesdropping for all traffic (including DNS traffic) due to the 428 cellular network link-layer encryption. 430 The attack surface for this specific scenario is not considered here. 432 3.4.2. Encrypted Transports 434 The use of encrypted transports directly mitigates passive 435 surveillance of the DNS payload, however there are still some privacy 436 attacks possible. This section enumerates the residual privacy risks 437 to an end user when an attacker can passively monitor encrypted DNS 438 traffic flows on the wire. 440 These are cases where user identification, fingerprinting or 441 correlations may be possible due to the use of certain transport 442 layers or clear text/observable features. These issues are not 443 specific to DNS, but DNS traffic is susceptible to these attacks when 444 using specific transports. 446 There are some general examples, for example, certain studies have 447 highlighted that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes os- 448 fingerprint [2] values can be used to fingerprint client OS's or that 449 various techniques can be used to de-NAT DNS queries dns-de-nat [3]. 451 Note that even when using encrypted transports the use of clear text 452 transport options to decrease latency can provide correlation of a 453 users' connections e.g. using TCP Fast Open [RFC7413] with TLS 1.2. 455 More specifically, (since the deployment of encrypted transports is 456 not widespread at the time of writing) users wishing to use encrypted 457 transports for DNS may in practice be limited in the resolver 458 services available. Given this, the choice of a user to configure a 459 single resolver (or a fixed set of resolvers) and an encrypted 460 transport to use in all network environments can actually serve to 461 identify the user as one that desires privacy and can provide an 462 added mechanism to track them as they move across network 463 environments. 465 Implementations that support encrypted transports also commonly re- 466 use sessions for multiple DNS queries to optimize performance (e.g. 467 via DNS pipelining or HTTPS multiplexing). Default configuration 468 options for encrypted transports could in principle fingerprint a 469 specific client application. For example: 471 o TLS version or cipher suite selection 473 o session resumption 475 o the maximum number of messages to send or 477 o a maximum connection time before closing a connections and re- 478 opening. 480 If libraries or applications offer user configuration of such options 481 (e.g. [getdns]) then they could in principle help to identify a 482 specific user. Users may want to use only the defaults to avoid this 483 issue. 485 Whilst there are known attacks on older versions of TLS the most 486 recent recommendations [RFC7525] and the development of TLS 1.3 487 [RFC8446] largely mitigate those. 489 Traffic analysis of unpadded encrypted traffic is also possible 490 [pitfalls-of-dns-encryption] because the sizes and timing of 491 encrypted DNS requests and responses can be correlated to unencrypted 492 DNS requests upstream of a recursive resolver. 494 3.5. In the Servers 496 Using the terminology of [RFC6973], the DNS servers (recursive 497 resolvers and authoritative servers) are enablers: they facilitate 498 communication between an initiator and a recipient without being 499 directly in the communications path. As a result, they are often 500 forgotten in risk analysis. But, to quote again [RFC6973], "Although 501 [...] enablers may not generally be considered as attackers, they may 502 all pose privacy threats (depending on the context) because they are 503 able to observe, collect, process, and transfer privacy-relevant 504 data." In [RFC6973] parlance, enablers become observers when they 505 start collecting data. 507 Many programs exist to collect and analyze DNS data at the servers -- 508 from the "query log" of some programs like BIND to tcpdump and more 509 sophisticated programs like PacketQ [packetq] and DNSmezzo 510 [dnsmezzo]. The organization managing the DNS server can use this 511 data itself, or it can be part of a surveillance program like PRISM 512 [prism] and pass data to an outside observer. 514 Sometimes, this data is kept for a long time and/or distributed to 515 third parties for research purposes [ditl] [day-at-root], security 516 analysis, or surveillance tasks. These uses are sometimes under some 517 sort of contract, with various limitations, for instance, on 518 redistribution, given the sensitive nature of the data. Also, there 519 are observation points in the network that gather DNS data and then 520 make it accessible to third parties for research or security purposes 521 ("passive DNS" [passive-dns]). 523 3.5.1. In the Recursive Resolvers 525 Recursive Resolvers see all the traffic since there is typically no 526 caching before them. To summarize: your recursive resolver knows a 527 lot about you. The resolver of a large IAP, or a large public 528 resolver, can collect data from many users. 530 3.5.1.1. Resolver Selection 532 Given all the above considerations, the choice of recursive resolver 533 has direct privacy considerations for end users. Historically, end 534 user devices have used the DHCP-provided local network recursive 535 resolver, which may have strong, medium, or weak privacy policies 536 depending on the network. Privacy policies for these servers may or 537 may not be available and users need to be aware that privacy 538 guarantees will vary with network. 540 More recently, some networks and end users have actively chosen to 541 use a large public resolver, e.g., Google Public DNS [4], Cloudflare 542 [5], or Quad9 [6]. There can be many reasons: cost considerations 543 for network operators, better reliability or anti-censorship 544 considerations are just a few. Such services typically do provide a 545 privacy policy and the end user can get an idea of the data collected 546 by such operators by reading one e.g., Google Public DNS - Your 547 Privacy [7]. 549 In general, as with many other protocols, issues around 550 centralization also arise with DNS. The picture is fluid with 551 several competing factors contributing which can also vary by 552 geographic region. These include: 554 o ISP outsourcing, including to third party and public resolvers 556 o regional market domination by one or only a few ISPs 558 An increased proportion of the global DNS resolution traffic being 559 served by only a few entities means that the privacy considerations 560 for end users are highly dependent on the privacy policies and 561 practices of those entities. Many of the issues around 562 centralization are discussed in 563 [centralisation-and-data-sovereignty]. 565 3.5.1.1.1. Dynamic Discovery of DoH and Strict DoT 567 Whilst support for opportunistic DoT can be determined by probing a 568 resolver on port 853, there is currently no standardized discovery 569 mechanism for DoH and Strict DoT servers. 571 This means that clients which might want to dynamically discover such 572 encrypted services, and where users are willing to trust such 573 services, are not able to do so. At the time of writing, efforts to 574 provide standardized signaling mechanisms to discover the services 575 offered by local resolvers are in progress 576 [I-D.ietf-dnsop-resolver-information]. Note that an increasing 577 numbers of ISPs are deploying encrypted DNS and publishing DNS 578 privacy polices, for example see the Encrypted DNS Deployment 579 Initiative [EDDI]. 581 3.5.1.1.2. Application-specific Resolver Selection 583 An increasing number of applications are offering application- 584 specific encrypted DNS resolution settings, rather than defaulting to 585 using only the system resolver. A variety of heuristics and 586 resolvers are available in different applications including hard- 587 coded lists of recognized DoH/DoT servers. 589 Users will only be aware of and have the ability to control such 590 settings if applications provide the following functions: 592 o communicate clearly the change in default to users 594 o provide configuration options to change the default 596 o provide configuration options to always use the system resolver 598 Application-specific changes to default destinations for users' DNS 599 queries might increase or decrease user privacy - it is highly 600 dependent on the network context and the application-specific 601 default. This is an area of active debate and the IETF is working on 602 a number of issues related to application-specific DNS settings. 604 3.5.1.2. Active Attacks on Resolver Configuration 606 The previous section discussed DNS privacy, assuming that all the 607 traffic was directed to the intended servers (i.e those that would be 608 used in the absence of an active attack) and that the potential 609 attacker was purely passive. But, in reality, we can have active 610 attackers in the network. 612 The Internet Threat model, as described in [RFC3552], assumes that 613 the attacker controls the network. Such an attacker can completely 614 control any insecure DNS resolution, both passively monitoring the 615 queries and responses and substituting their own responses. Even if 616 encrypted DNS such as DoH or DoT is used, unless the client has been 617 configured in a secure way with the server identity, an active 618 attacker can impersonate the server. This implies that opportunistic 619 modes of DoH/DoT as well as modes where the client learns of the DoH/ 620 DoT server via in-network mechanisms such as DHCP are vulnerable to 621 attack. In addition, if the client is compromised, the attacker can 622 replace the DNS configuration with one of its own choosing. 624 3.5.1.3. Blocking of User Selected DNS Resolution Services 626 User privacy can also be at risk if there is blocking (by local 627 network operators or more general mechanisms) of access to remote 628 recursive servers that offer encrypted transports when the local 629 resolver does not offer encryption and/or has very poor privacy 630 policies. For example, active blocking of port 853 for DoT or of 631 specific IP addresses could restrict the resolvers available to the 632 user. The extent of the risk to end user privacy is highly dependent 633 on the specific network and user context; a user on a network that is 634 known to perform surveillance would be compromised if they could not 635 access such services, whereas a user on a trusted network might have 636 no privacy motivation to do so. 638 As a matter of policy, some recursive resolvers use their position in 639 the query path to selectively block access to certain DNS records. 640 This is a form of Rendezvous-Based Blocking as described in 641 Section 4.3 of [RFC7754]. Such blocklists often include servers know 642 to be used for malware, bots or other security risks. In order to 643 prevent circumvention of their blocking policies, some networks also 644 block access to resolvers with incompatible policies. 646 It is also noted that attacks on remote resolver services, e.g., DDoS 647 could force users to switch to other services that do not offer 648 encrypted transports for DNS. 650 3.5.1.4. Encrypted Transports and Recursive Resolvers 652 3.5.1.4.1. DoT and DoH 654 Use of encrypted transports does not reduce the data available in the 655 recursive resolver and ironically can actually expose more 656 information about users to operators. As described in Section 3.4.2 657 use of session based encrypted transports (TCP/TLS) can expose 658 correlation data about users. 660 3.5.1.4.2. DoH Specific Considerations 662 DoH inherits the full privacy properties of the HTTPS stack and as a 663 consequence introduces new privacy considerations when compared with 664 DNS over UDP, TCP or TLS [RFC7858]. Section 8.2 of [RFC8484] 665 describes the privacy consideration in the server of the DoH 666 protocol. 668 A brief summary of some of the issues includes: 670 o HTTPS presents new considerations for correlation, such as 671 explicit HTTP cookies and implicit fingerprinting of the unique 672 set and ordering of HTTP request header fields. 674 o The User-Agent and Accept-Language request header fields often 675 convey specific information about the client version or locale. 677 o Utilizing the full set of HTTP features enables DoH to be more 678 than an HTTP tunnel, but it is at the cost of opening up 679 implementations to the full set of privacy considerations of HTTP. 681 o Implementations are advised to expose the minimal set of data 682 needed to achieve the desired feature set. 684 [RFC8484] specifically makes selection of HTTPS functionality vs 685 privacy an implementation choice. At the extremes, there may be 686 implementations that attempt to achieve parity with DoT from a 687 privacy perspective at the cost of using no identifiable HTTP 688 headers, there might be others that provide feature rich data flows 689 where the low-level origin of the DNS query is easily identifiable. 690 Some implementations have, in fact, chosen restrict the use of the 691 'User-Agent' header so that resolver operators cannot identify the 692 specific application that is originating the DNS queries. 694 Privacy focused users should be aware of the potential for additional 695 client identifiers in DoH compared to DoT and may want to only use 696 DoH client implementations that provide clear guidance on what 697 identifiers they add. 699 3.5.2. In the Authoritative Name Servers 701 Unlike what happens for recursive resolvers, observation capabilities 702 of authoritative name servers are limited by caching; they see only 703 the requests for which the answer was not in the cache. For 704 aggregated statistics ("What is the percentage of LOC queries?"), 705 this is sufficient, but it prevents an observer from seeing 706 everything. Similarly the increasing deployment of QNAME 707 minimisation [ripe-qname-measurements] reduces the data visible at 708 the authoritative name server. Still, the authoritative name servers 709 see a part of the traffic, and this subset may be sufficient to 710 violate some privacy expectations. 712 Also, the end user typically has some legal/contractual link with the 713 recursive resolver (he has chosen the IAP, or he has chosen to use a 714 given public resolver), while having no control and perhaps no 715 awareness of the role of the authoritative name servers and their 716 observation abilities. 718 As noted before, using a local resolver or a resolver close to the 719 machine decreases the attack surface for an on-the-wire eavesdropper. 720 But it may decrease privacy against an observer located on an 721 authoritative name server. This authoritative name server will see 722 the IP address of the end client instead of the address of a big 723 recursive resolver shared by many users. 725 This "protection", when using a large resolver with many clients, is 726 no longer present if ECS [RFC7871] is used because, in this case, the 727 authoritative name server sees the original IP address (or prefix, 728 depending on the setup). 730 As of today, all the instances of one root name server, L-root, 731 receive together around 50,000 queries per second. While most of it 732 is "junk" (errors on the Top-Level Domain (TLD) name), it gives an 733 idea of the amount of big data that pours into name servers. (And 734 even "junk" can leak information; for instance, if there is a typing 735 error in the TLD, the user will send data to a TLD that is not the 736 usual one.) 738 Many domains, including TLDs, are partially hosted by third-party 739 servers, sometimes in a different country. The contracts between the 740 domain manager and these servers may or may not take privacy into 741 account. Whatever the contract, the third-party hoster may be honest 742 or not but, in any case, it will have to follow its local laws. So, 743 requests to a given ccTLD may go to servers managed by organizations 744 outside of the ccTLD's country. End users may not anticipate that, 745 when doing a security analysis. 747 Also, it seems (see the survey described in [aeris-dns]) that there 748 is a strong concentration of authoritative name servers among 749 "popular" domains (such as the Alexa Top N list). For instance, 750 among the Alexa Top 100K [8], one DNS provider hosts today 10% of the 751 domains. The ten most important DNS providers host together one 752 third of the domains. With the control (or the ability to sniff the 753 traffic) of a few name servers, you can gather a lot of information. 755 3.6. Re-identification and Other Inferences 757 An observer has access not only to the data he/she directly collects 758 but also to the results of various inferences about this data. The 759 term 'observer' here is used very generally, it might be one that is 760 passively observing cleartext DNS traffic, one in the network that is 761 actively attacking the user by re-directing DNS resolution, or it 762 might be a local or remote resolver operator. 764 For instance, a user can be re-identified via DNS queries. If the 765 adversary knows a user's identity and can watch their DNS queries for 766 a period, then that same adversary may be able to re-identify the 767 user solely based on their pattern of DNS queries later on regardless 768 of the location from which the user makes those queries. For 769 example, one study [herrmann-reidentification] found that such re- 770 identification is possible so that "73.1% of all day-to-day links 771 were correctly established, i.e., user u was either re-identified 772 unambiguously (1) or the classifier correctly reported that u was not 773 present on day t+1 any more (2)." While that study related to web 774 browsing behavior, equally characteristic patterns may be produced 775 even in machine-to-machine communications or without a user taking 776 specific actions, e.g., at reboot time if a characteristic set of 777 services are accessed by the device. 779 For instance, one could imagine that an intelligence agency 780 identifies people going to a site by putting in a very long DNS name 781 and looking for queries of a specific length. Such traffic analysis 782 could weaken some privacy solutions. 784 The IAB privacy and security program also have a work in progress 785 [RFC7624] that considers such inference-based attacks in a more 786 general framework. 788 3.7. More Information 790 Useful background information can also be found in [tor-leak] (about 791 the risk of privacy leak through DNS) and in a few academic papers: 792 [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and 793 [federrath-fuchs-herrmann-piosecny]. 795 4. Actual "Attacks" 797 A very quick examination of DNS traffic may lead to the false 798 conclusion that extracting the needle from the haystack is difficult. 799 "Interesting" primary DNS requests are mixed with useless (for the 800 eavesdropper) secondary and tertiary requests (see the terminology in 801 Section 1). But, in this time of "big data" processing, powerful 802 techniques now exist to get from the raw data to what the 803 eavesdropper is actually interested in. 805 Many research papers about malware detection use DNS traffic to 806 detect "abnormal" behavior that can be traced back to the activity of 807 malware on infected machines. Yes, this research was done for the 808 good, but technically it is a privacy attack and it demonstrates the 809 power of the observation of DNS traffic. See [dns-footprint], 810 [dagon-malware], and [darkreading-dns]. 812 Passive DNS systems [passive-dns] allow reconstruction of the data of 813 sometimes an entire zone. They are used for many reasons -- some 814 good, some bad. Well-known passive DNS systems keep only the DNS 815 responses, and not the source IP address of the client, precisely for 816 privacy reasons. Other passive DNS systems may not be so careful. 817 And there is still the potential problems with revealing QNAMEs. 819 The revelations from the Edward Snowden documents, which were leaked 820 from the National Security Agency (NSA) provide evidence of the use 821 of the DNS in mass surveillance operations [morecowbell]. For 822 example the MORECOWBELL surveillance program, which uses a dedicated 823 covert monitoring infrastructure to actively query DNS servers and 824 perform HTTP requests to obtain meta information about services and 825 to check their availability. Also the QUANTUMTHEORY [9] project 826 which includes detecting lookups for certain addresses and injecting 827 bogus replies is another good example showing that the lack of 828 privacy protections in the DNS is actively exploited. 830 5. Legalities 832 To our knowledge, there are no specific privacy laws for DNS data, in 833 any country. Interpreting general privacy laws like 834 [data-protection-directive] or GDPR [10] applicable in the European 835 Union in the context of DNS traffic data is not an easy task, and we 836 do not know a court precedent here. See an interesting analysis in 837 [sidn-entrada]. 839 6. Security Considerations 841 This document is entirely about security, more precisely privacy. It 842 just lays out the problem; it does not try to set requirements (with 843 the choices and compromises they imply), much less define solutions. 844 Possible solutions to the issues described here are discussed in 845 other documents (currently too many to all be mentioned); see, for 846 instance, 'Recommendations for DNS Privacy Operators' 847 [I-D.ietf-dprive-bcp-op]. 849 7. IANA Considerations 851 This document makes no requests of the IANA. 853 8. Acknowledgments 855 Thanks to Nathalie Boulvard and to the CENTR members for the original 856 work that led to this document. Thanks to Ondrej Sury for the 857 interesting discussions. Thanks to Mohsen Souissi and John Heidemann 858 for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz, 859 Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for 860 proofreading, providing technical remarks, and making many 861 readability improvements. Thanks to Dan York, Suzanne Woolf, Tony 862 Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis 863 for good written contributions. Thanks to Vittorio Bertola and 864 Mohamed Boucadair for a detailed review of the -bis. And thanks to 865 the IESG members for the last remarks. 867 9. Changelog 869 draft-ietf-dprive-rfc7626-bis-04 871 o Tsvart review: Add reference to DNS-over-QUIC, fix typo. 873 o Secdir review: Add text in Section 3 on devices using many 874 networks. Update bullet in 3.4.1 on cellular encryption. 876 o Section 3.5.1.1 - re-work the section to try to address multiple 877 comments. 879 o Section 3.5.1.4 - remove this section as now covered by 3.5.1.1. 881 o Section 3.5.1.5.2 - Remove several paragraphs and more directly 882 reference RFC8484 by including bullet points quoting text from 883 Section 8.2 of RFC8484. Retain the last 2 paragraphs as they are 884 information for users, not implementors. 886 o Section 3.4.2 - some minor updates made based on specific 887 comments. 889 draft-ietf-dprive-rfc7626-bis-03 891 o Address 2 minor nits (typo in section 3.4.1 and adding an IANA 892 section) 894 o Minor updates from AD review 896 draft-ietf-dprive-rfc7626-bis-02 898 o Numerous editorial corrections thanks to Mohamed Boucadair and 900 * Minor additions to Scope section 902 * New text on cellular network DNS 904 o Additional text from Vittorio Bertola on blocking and security 906 draft-ietf-dprive-rfc7626-bis-01 908 o Re-structure section 3.5 (was 2.5) 909 * Collect considerations for recursive resolvers together 911 * Re-work several sections here to clarify their context (e.g., 912 'Rogue servers' becomes 'Active attacks on resolver 913 configuration') 915 * Add discussion of resolver selection 917 o Update text and old reference on Snowdon revelations. 919 o Add text on and references to QNAME minimisation RFC and 920 deployment measurements 922 o Correct outdated references 924 o Clarify scope by adding a Scope section (was Risks overview) 926 o Clarify what risks are considered in section 3.4.2 928 draft-ietf-dprive-rfc7626-bis-00 930 o Rename after WG adoption 932 o Use DoT acronym throughout 934 o Minor updates to status of deployment and other drafts 936 draft-bortzmeyer-dprive-rfc7626-bis-02 938 o Update various references and fix some nits. 940 draft-bortzmeyer-dprive-rfc7626-bis-01 942 o Update reference for dickinson-bcp-op to draft-dickinson-dprive- 943 bcp-op 945 draft-borztmeyer-dprive-rfc7626-bis-00: 947 Initial commit. Differences to RFC7626: 949 o Update many references 951 o Add discussions of encrypted transports including DoT and DoH 953 o Add section on DNS payload 955 o Add section on authentication of servers 956 o Add section on blocking of services 958 10. References 960 10.1. Normative References 962 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 963 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 964 . 966 [RFC1035] Mockapetris, P., "Domain names - implementation and 967 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 968 November 1987, . 970 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 971 Morris, J., Hansen, M., and R. Smith, "Privacy 972 Considerations for Internet Protocols", RFC 6973, 973 DOI 10.17487/RFC6973, July 2013, . 976 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 977 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 978 2014, . 980 10.2. Informative References 982 [aeris-dns] 983 Vinot, N., "Vie privee: et le DNS alors?", (In French), 984 2015, . 987 [castillo-garcia] 988 Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous 989 Resolution of DNS Queries", 2008, 990 . 992 [centralisation-and-data-sovereignty] 993 De Filippi, P. and S. McCarthy, "Cloud Computing: 994 Centralization and Data Sovereignty", October 2012, 995 . 998 [dagon-malware] 999 Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a 1000 Malicious Resolution Authority", ISC/OARC Workshop, 2007, 1001 . 1004 [darkreading-dns] 1005 Lemos, R., "Got Malware? Three Signs Revealed In DNS 1006 Traffic", InformationWeek Dark Reading, May 2013, 1007 . 1011 [data-protection-directive] 1012 European Parliament, "Directive 95/46/EC of the European 1013 Parliament and of the council on the protection of 1014 individuals with regard to the processing of personal data 1015 and on the free movement of such data", Official Journal L 1016 281, pp. 0031 - 0050, November 1995, . 1020 [day-at-root] 1021 Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A 1022 Day at the Root of the Internet", ACM SIGCOMM Computer 1023 Communication Review, Vol. 38, Number 5, 1024 DOI 10.1145/1452335.1452341, October 2008, 1025 . 1028 [denis-edns-client-subnet] 1029 Denis, F., "Security and privacy issues of edns-client- 1030 subnet", August 2013, . 1033 [ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002, 1034 . 1036 [dns-footprint] 1037 Stoner, E., "DNS Footprint of Malware", OARC Workshop, 1038 October 2010, . 1041 [dnsmezzo] 1042 Bortzmeyer, S., "DNSmezzo", 2009, 1043 . 1045 [EDDI] EDDI, "Encrypted DNS Deployment Initiative", 2020, 1046 . 1048 [fangming-hori-sakurai] 1049 Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of 1050 Privacy Disclosure in DNS Query", 2007 International 1051 Conference on Multimedia and Ubiquitous Engineering (MUE 1052 2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957, 1053 DOI 10.1109/MUE.2007.84, April 2007, 1054 . 1056 [federrath-fuchs-herrmann-piosecny] 1057 Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny, 1058 "Privacy-Preserving DNS: Analysis of Broadcast, Range 1059 Queries and Mix-based Protection Methods", Computer 1060 Security ESORICS 2011, Springer, page(s) 665-683, 1061 ISBN 978-3-642-23821-5, 2011, . 1065 [getdns] getdns, "getdns - A modern asynchronous DNS API", January 1066 2020, . 1068 [grangeia.snooping] 1069 Grangeia, L., "DNS Cache Snooping or Snooping the Cache 1070 for Fun and Profit", 2005, 1071 . 1075 [herrmann-reidentification] 1076 Herrmann, D., Gerber, C., Banse, C., and H. Federrath, 1077 "Analyzing Characteristic Host Access Patterns for Re- 1078 Identification of Web User Sessions", 1079 DOI 10.1007/978-3-642-27937-9_10, 2012, . 1082 [I-D.huitema-quic-dnsoquic] 1083 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 1084 Iyengar, "Specification of DNS over Dedicated QUIC 1085 Connections", draft-huitema-quic-dnsoquic-07 (work in 1086 progress), September 2019. 1088 [I-D.ietf-dnsop-resolver-information] 1089 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 1090 Information Self-publication", draft-ietf-dnsop-resolver- 1091 information-00 (work in progress), August 2019. 1093 [I-D.ietf-dprive-bcp-op] 1094 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 1095 Mankin, "Recommendations for DNS Privacy Service 1096 Operators", draft-ietf-dprive-bcp-op-07 (work in 1097 progress), December 2019. 1099 [I-D.ietf-quic-transport] 1100 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1101 and Secure Transport", draft-ietf-quic-transport-24 (work 1102 in progress), November 2019. 1104 [I-D.ietf-tls-sni-encryption] 1105 Huitema, C. and E. Rescorla, "Issues and Requirements for 1106 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09 1107 (work in progress), October 2019. 1109 [morecowbell] 1110 Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, 1111 "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January 1112 2015, . 1115 [packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries 1116 against PCAP-files", 2011, . 1119 [passive-dns] 1120 Weimer, F., "Passive DNS Replication", April 2005, 1121 . 1124 [pitfalls-of-dns-encryption] 1125 Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS 1126 Encryption", . 1128 [prism] Wikipedia, "PRISM (surveillance program)", July 2015, 1129 . 1132 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1133 Text on Security Considerations", BCP 72, RFC 3552, 1134 DOI 10.17487/RFC3552, July 2003, . 1137 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1138 Rose, "DNS Security Introduction and Requirements", 1139 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1140 . 1142 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1143 Security (DNSSEC) Hashed Authenticated Denial of 1144 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1145 . 1147 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1148 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1149 . 1151 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1152 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1153 DOI 10.17487/RFC6269, June 2011, . 1156 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1157 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1158 . 1160 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1161 "Recommendations for Secure Use of Transport Layer 1162 Security (TLS) and Datagram Transport Layer Security 1163 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1164 2015, . 1166 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1167 Trammell, B., Huitema, C., and D. Borkmann, 1168 "Confidentiality in the Face of Pervasive Surveillance: A 1169 Threat Model and Problem Statement", RFC 7624, 1170 DOI 10.17487/RFC7624, August 2015, . 1173 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1174 Considerations for IPv6 Address Generation Mechanisms", 1175 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1176 . 1178 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1179 Nordmark, "Technical Considerations for Internet Service 1180 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1181 March 2016, . 1183 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1184 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1185 . 1187 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1188 and P. Hoffman, "Specification for DNS over Transport 1189 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1190 2016, . 1192 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1193 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1194 DOI 10.17487/RFC7871, May 2016, . 1197 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1198 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1199 . 1201 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 1202 (DANE) Bindings for OpenPGP", RFC 7929, 1203 DOI 10.17487/RFC7929, August 2016, . 1206 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1207 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1208 . 1210 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1211 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1212 . 1214 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1215 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1216 January 2019, . 1218 [ripe-qname-measurements] 1219 University of Twente, "Making the DNS More Private with 1220 QNAME Minimisation", April 2019, 1221 . 1224 [sidn-entrada] 1225 Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. 1226 Simon, "A privacy framework for 'DNS big data' 1227 applications", November 2014, 1228 . 1232 [thomas-ditl-tcp] 1233 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 1234 Root Server DITL Data", DNS-OARC 2014 Fall Workshop, 1235 October 2014, . 1239 [tor-leak] 1240 Tor, "DNS leaks in Tor", 2013, 1241 . 1244 [yanbin-tsudik] 1245 Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks 1246 in the Domain Name System", October 2009, 1247 . 1249 10.3. URIs 1251 [1] https://lists.dns-oarc.net/pipermail/dns- 1252 operations/2016-January/014141.html 1254 [2] http://netres.ec/?b=11B99BD 1256 [3] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS- 1257 based_De-NAT_Scheme 1259 [4] https://developers.google.com/speed/public-dns 1261 [5] https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/ 1263 [6] https://www.quad9.net 1265 [7] https://developers.google.com/speed/public-dns/privacy 1267 [8] https://www.alexa.com/topsites 1269 [9] https://theintercept.com/document/2014/03/12/nsa-gchqs- 1270 quantumtheory-hacking-tactics/ 1272 [10] https://www.eugdpr.org/the-regulation.html 1274 Authors' Addresses 1275 Stephane Bortzmeyer 1276 AFNIC 1277 1, rue Stephenson 1278 Montigny-le-Bretonneux 1279 France 78180 1281 Email: bortzmeyer+ietf@nic.fr 1283 Sara Dickinson 1284 Sinodun IT 1285 Magdalen Centre 1286 Oxford Science Park 1287 Oxford OX4 4GA 1288 United Kingdom 1290 Email: sara@sinodun.com