idnits 2.17.1 draft-ietf-dprive-rfc7626-bis-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 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 (September 27, 2019) is 1665 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1181 -- Looks like a reference, but probably isn't: '2' on line 1184 -- Looks like a reference, but probably isn't: '3' on line 1186 -- Looks like a reference, but probably isn't: '4' on line 1189 -- Looks like a reference, but probably isn't: '5' on line 1191 -- Looks like a reference, but probably isn't: '6' on line 1193 -- Looks like a reference, but probably isn't: '7' on line 1195 ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) == 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-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-06 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: March 30, 2020 September 27, 2019 8 DNS Privacy Considerations 9 draft-ietf-dprive-rfc7626-bis-01 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 March 30, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 7 59 3.4. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4.1. Unencrypted Transports . . . . . . . . . . . . . . . 8 61 3.4.2. Encrypted Transports . . . . . . . . . . . . . . . . 9 62 3.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 10 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 71 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 74 9.2. Informative References . . . . . . . . . . . . . . . . . 20 75 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 78 1. Introduction 80 This document is an analysis of the DNS privacy issues, in the spirit 81 of Section 8 of [RFC6973]. 83 The Domain Name System is specified in [RFC1034], [RFC1035], and many 84 later RFCs, which have never been consolidated. It is one of the 85 most important infrastructure components of the Internet and often 86 ignored or misunderstood by Internet users (and even by many 87 professionals). Almost every activity on the Internet starts with a 88 DNS query (and often several). Its use has many privacy implications 89 and this is an attempt at a comprehensive and accurate list. 91 Let us begin with a simplified reminder of how the DNS works. (See 92 also [RFC8499]) A client, the stub resolver, issues a DNS query to a 93 server, called the recursive resolver (also called caching resolver 94 or full resolver or recursive name server). Let's use the query 95 "What are the AAAA records for www.example.com?" as an example. AAAA 96 is the QTYPE (Query Type), and www.example.com is the QNAME (Query 97 Name). (The description that follows assumes a cold cache, for 98 instance, because the server just started.) The recursive resolver 99 will first query the root name servers. In most cases, the root name 100 servers will send a referral. In this example, the referral will be 101 to the .com name servers. The resolver repeats the query to one of 102 the .com name servers. The .com name servers, in turn, will refer to 103 the example.com name servers. The example.com name server will then 104 return the answer. The root name servers, the name servers of .com, 105 and the name servers of example.com are called authoritative name 106 servers. It is important, when analyzing the privacy issues, to 107 remember that the question asked to all these name servers is always 108 the original question, not a derived question. The question sent to 109 the root name servers is "What are the AAAA records for 110 www.example.com?", not "What are the name servers of .com?". By 111 repeating the full question, instead of just the relevant part of the 112 question to the next in line, the DNS provides more information than 113 necessary to the name server. In this simplified description, 114 recursive resolvers do not implement QNAME minimization as described 115 in [RFC7816], which will only send the relevant part of the question 116 to the upstream name server. 118 Because DNS relies on caching heavily, the algorithm described just 119 above is actually a bit more complicated, and not all questions are 120 sent to the authoritative name servers. If a few seconds later the 121 stub resolver asks the recursive resolver, "What are the SRV records 122 of _xmpp-server._tcp.example.com?", the recursive resolver will 123 remember that it knows the name servers of example.com and will just 124 query them, bypassing the root and .com. Because there is typically 125 no caching in the stub resolver, the recursive resolver, unlike the 126 authoritative servers, sees all the DNS traffic. (Applications, like 127 web browsers, may have some form of caching that does not follow DNS 128 rules, for instance, because it may ignore the TTL. So, the 129 recursive resolver does not see all the name resolution activity.) 131 It should be noted that DNS recursive resolvers sometimes forward 132 requests to other recursive resolvers, typically bigger machines, 133 with a larger and more shared cache (and the query hierarchy can be 134 even deeper, with more than two levels of recursive resolvers). From 135 the point of view of privacy, these forwarders are like resolvers, 136 except that they do not see all of the requests being made (due to 137 caching in the first resolver). 139 At the time of writing, almost all this DNS traffic is currently sent 140 in clear (unencrypted). However there is increasing deployment of 141 DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], 142 particularly in mobile devices, browsers and by providers of anycast 143 recursive DNS resolution services. There are a few cases where there 144 is some alternative channel encryption, for instance, in an IPsec 145 VPN, at least between the stub resolver and the resolver. 147 Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. 148 This has practical consequences when considering encryption of the 149 traffic as a possible privacy technique. Some encryption solutions 150 are only designed for TCP, not UDP and new solutions are still 151 emerging [I-D.ietf-quic-transport]. 153 Another important point to keep in mind when analyzing the privacy 154 issues of DNS is the fact that DNS requests received by a server are 155 triggered by different reasons. Let's assume an eavesdropper wants 156 to know which web page is viewed by a user. For a typical web page, 157 there are three sorts of DNS requests being issued: 159 o Primary request: this is the domain name in the URL that the user 160 typed, selected from a bookmark, or chose by clicking on an 161 hyperlink. Presumably, this is what is of interest for the 162 eavesdropper. 164 o Secondary requests: these are the additional requests performed by 165 the user agent (here, the web browser) without any direct 166 involvement or knowledge of the user. For the Web, they are 167 triggered by embedded content, Cascading Style Sheets (CSS), 168 JavaScript code, embedded images, etc. In some cases, there can 169 be dozens of domain names in different contexts on a single web 170 page. 172 o Tertiary requests: these are the additional requests performed by 173 the DNS system itself. For instance, if the answer to a query is 174 a referral to a set of name servers, and the glue records are not 175 returned, the resolver will have to do additional requests to turn 176 the name servers' names into IP addresses. Similarly, even if 177 glue records are returned, a careful recursive server will do 178 tertiary requests to verify the IP addresses of those records. 180 It can be noted also that, in the case of a typical web browser, more 181 DNS requests than strictly necessary are sent, for instance, to 182 prefetch resources that the user may query later or when 183 autocompleting the URL in the address bar. Both are a big privacy 184 concern since they may leak information even about non-explicit 185 actions. For instance, just reading a local HTML page, even without 186 selecting the hyperlinks, may trigger DNS requests. 188 For privacy-related terms, we will use the terminology from 189 [RFC6973]. 191 2. Scope 193 This document focuses mostly on the study of privacy risks for the 194 end user (the one performing DNS requests). We consider the risks of 195 pervasive surveillance [RFC7258] as well as risks coming from a more 196 focused surveillance. 198 Privacy risks for the holder of a zone (the risk that someone gets 199 the data) are discussed in [RFC5936] and [RFC5155]. 201 Privacy risks for recursive operators such as leakage of private 202 namespaces or blocklists are out of scope for this document. 204 Non-privacy risks (e.g security related concerns such as cache 205 poisoning) are also out of scope. 207 3. Risks 209 3.1. The Alleged Public Nature of DNS Data 211 It has long been claimed that "the data in the DNS is public". While 212 this sentence makes sense for an Internet-wide lookup system, there 213 are multiple facets to the data and metadata involved that deserve a 214 more detailed look. First, access control lists and private 215 namespaces notwithstanding, the DNS operates under the assumption 216 that public-facing authoritative name servers will respond to "usual" 217 DNS queries for any zone they are authoritative for without further 218 authentication or authorization of the client (resolver). Due to the 219 lack of search capabilities, only a given QNAME will reveal the 220 resource records associated with that name (or that name's non- 221 existence). In other words: one needs to know what to ask for, in 222 order to receive a response. The zone transfer QTYPE [RFC5936] is 223 often blocked or restricted to authenticated/authorized access to 224 enforce this difference (and maybe for other reasons). 226 Another differentiation to be considered is between the DNS data 227 itself and a particular transaction (i.e., a DNS name lookup). DNS 228 data and the results of a DNS query are public, within the boundaries 229 described above, and may not have any confidentiality requirements. 230 However, the same is not true of a single transaction or a sequence 231 of transactions; that transaction is not / should not be public. A 232 typical example from outside the DNS world is: the web site of 233 Alcoholics Anonymous is public; the fact that you visit it should not 234 be. 236 3.2. Data in the DNS Request 238 The DNS request includes many fields, but two of them seem 239 particularly relevant for the privacy issues: the QNAME and the 240 source IP address. "source IP address" is used in a loose sense of 241 "source IP address + maybe source port", because the port is also in 242 the request and can be used to differentiate between several users 243 sharing an IP address (behind a Carrier-Grade NAT (CGN), for instance 244 [RFC6269]). 246 The QNAME is the full name sent by the user. It gives information 247 about what the user does ("What are the MX records of example.net?" 248 means he probably wants to send email to someone at example.net, 249 which may be a domain used by only a few persons and is therefore 250 very revealing about communication relationships). Some QNAMEs are 251 more sensitive than others. For instance, querying the A record of a 252 well-known web statistics domain reveals very little (everybody 253 visits web sites that use this analytics service), but querying the A 254 record of www.verybad.example where verybad.example is the domain of 255 an organization that some people find offensive or objectionable may 256 create more problems for the user. Also, sometimes, the QNAME embeds 257 the software one uses, which could be a privacy issue. For instance, 258 _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. 259 There are also some BitTorrent clients that query an SRV record for 260 _bittorrent-tracker._tcp.domain.example. 262 Another important thing about the privacy of the QNAME is the future 263 usages. Today, the lack of privacy is an obstacle to putting 264 potentially sensitive or personally identifiable data in the DNS. At 265 the moment, your DNS traffic might reveal that you are doing email 266 but not with whom. If your Mail User Agent (MUA) starts looking up 267 Pretty Good Privacy (PGP) keys in the DNS [RFC7929], then privacy 268 becomes a lot more important. And email is just an example; there 269 would be other really interesting uses for a more privacy- friendly 270 DNS. 272 For the communication between the stub resolver and the recursive 273 resolver, the source IP address is the address of the user's machine. 274 Therefore, all the issues and warnings about collection of IP 275 addresses apply here. For the communication between the recursive 276 resolver and the authoritative name servers, the source IP address 277 has a different meaning; it does not have the same status as the 278 source address in an HTTP connection. It is now the IP address of 279 the recursive resolver that, in a way, "hides" the real user. 280 However, hiding does not always work. Sometimes EDNS(0) Client 281 subnet [RFC7871] is used (see its privacy analysis in 282 [denis-edns-client-subnet]). Sometimes the end user has a personal 283 recursive resolver on her machine. In both cases, the IP address is 284 as sensitive as it is for HTTP [sidn-entrada]. 286 A note about IP addresses: there is currently no IETF document that 287 describes in detail all the privacy issues around IP addressing. In 288 the meantime, the discussion here is intended to include both IPv4 289 and IPv6 source addresses. For a number of reasons, their assignment 290 and utilization characteristics are different, which may have 291 implications for details of information leakage associated with the 292 collection of source addresses. (For example, a specific IPv6 source 293 address seen on the public Internet is less likely than an IPv4 294 address to originate behind a CGN or other NAT.) However, for both 295 IPv4 and IPv6 addresses, it's important to note that source addresses 296 are propagated with queries and comprise metadata about the host, 297 user, or application that originated them. 299 3.2.1. Data in the DNS payload 301 At the time of writing there are no standardized client identifiers 302 contained in the DNS payload itself (ECS [RFC7871] while widely used 303 is only of Category Informational). 305 DNS Cookies [RFC7873] are a lightweight DNS transaction security 306 mechanism that provides limited protection against a variety of 307 increasingly common denial-of-service and amplification/forgery or 308 cache poisoning attacks by off-path attackers. It is noted, however, 309 that they are designed to just verify IP addresses (and should change 310 once a client's IP address changes), they are not designed to 311 actively track users (like HTTP cookies). 313 There are anecdotal accounts of MAC addresses [1] and even user names 314 being inserted in non-standard EDNS(0) options for stub to resolver 315 communications to support proprietary functionality implemented at 316 the resolver (e.g. parental filtering). 318 3.3. Cache Snooping 320 The content of recursive resolvers' caches can reveal data about the 321 clients using it (the privacy risks depend on the number of clients). 322 This information can sometimes be examined by sending DNS queries 323 with RD=0 to inspect cache content, particularly looking at the DNS 324 TTLs [grangeia.snooping]. Since this also is a reconnaissance 325 technique for subsequent cache poisoning attacks, some counter 326 measures have already been developed and deployed. 328 3.4. On the Wire 330 3.4.1. Unencrypted Transports 332 For unencrypted transports, DNS traffic can be seen by an 333 eavesdropper like any other traffic. (DNSSEC, specified in 334 [RFC4033], explicitly excludes confidentiality from its goals.) So, 335 if an initiator starts an HTTPS communication with a recipient, while 336 the HTTP traffic will be encrypted, the DNS exchange prior to it will 337 not be. When other protocols will become more and more privacy-aware 338 and secured against surveillance (e.g. [RFC8446], 339 [I-D.ietf-quic-transport]), the use of unencrypted transports for DNS 340 may become "the weakest link" in privacy. It is noted that at the 341 time of writing there is on-going work attempting to encrypt the SNI 342 in the TLS handshake [I-D.ietf-tls-sni-encryption]. 344 An important specificity of the DNS traffic is that it may take a 345 different path than the communication between the initiator and the 346 recipient. For instance, an eavesdropper may be unable to tap the 347 wire between the initiator and the recipient but may have access to 348 the wire going to the recursive resolver, or to the authoritative 349 name servers. 351 The best place to tap, from an eavesdropper's point of view, is 352 clearly between the stub resolvers and the recursive resolvers, 353 because traffic is not limited by DNS caching. 355 The attack surface between the stub resolver and the rest of the 356 world can vary widely depending upon how the end user's computer is 357 configured. By order of increasing attack surface: 359 The recursive resolver can be on the end user's computer. In 360 (currently) a small number of cases, individuals may choose to 361 operate their own DNS resolver on their local machine. In this 362 case, the attack surface for the connection between the stub 363 resolver and the caching resolver is limited to that single 364 machine. 366 The recursive resolver may be at the local network edge. For 367 many/most enterprise networks and for some residential users, the 368 caching resolver may exist on a server at the edge of the local 369 network. In this case, the attack surface is the local network. 370 Note that in large enterprise networks, the DNS resolver may not 371 be located at the edge of the local network but rather at the edge 372 of the overall enterprise network. In this case, the enterprise 373 network could be thought of as similar to the Internet Access 374 Provider (IAP) network referenced below. 376 The recursive resolver can be in the IAP premises. For most 377 residential users and potentially other networks, the typical case 378 is for the end user's computer to be configured (typically 379 automatically through DHCP) with the addresses of the DNS 380 recursive resolvers at the IAP. The attack surface for on-the- 381 wire attacks is therefore from the end-user system across the 382 local network and across the IAP network to the IAP's recursive 383 resolvers. 385 The recursive resolver can be a public DNS service. Some machines 386 may be configured to use public DNS resolvers such as those 387 operated today by Google Public DNS or OpenDNS. The end user may 388 have configured their machine to use these DNS recursive resolvers 389 themselves -- or their IAP may have chosen to use the public DNS 390 resolvers rather than operating their own resolvers. In this 391 case, the attack surface is the entire public Internet between the 392 end user's connection and the public DNS service. 394 3.4.2. Encrypted Transports 396 The use of encrypted transports directly mitigates passive 397 surveillance of the DNS payload, however there are still some privacy 398 attacks possible. This section enumerates the residual privacy risks 399 to an end user when an attacker can passively monitor encrypted DNS 400 traffic flows on the wire. 402 These are cases where user identification, fingerprinting or 403 correlations may be possible due to the use of certain transport 404 layers or clear text/observable features. These issues are not 405 specific to DNS, but DNS traffic is susceptible to these attacks when 406 using specific transports. 408 There are some general examples, for example, certain studies have 409 highlighted that IP TTL or TCP Window sizes os-fingerprint [2] values 410 can be used to fingerprint client OS's or that various techniques can 411 be used to de-NAT DNS queries dns-de-nat [3]. 413 The use of clear text transport options to decrease latency may also 414 identify a user e.g. using TCP Fast Open [RFC7413]. 416 More specifically, (since the deployment of encrypted transports is 417 not widespread at the time of writing) users wishing to use encrypted 418 transports for DNS may in practice be limited in the resolver 419 services available. Given this, the choice of a user to configure a 420 single resolver (or a fixed set of resolvers) and an encrypted 421 transport to use in all network environments can actually serve to 422 identify the user as one that desires privacy and can provide an 423 added mechanism to track them as they move across network 424 environments. 426 Users of encrypted transports are also highly likely to re-use 427 sessions for multiple DNS queries to optimize performance (e.g. via 428 DNS pipelining or HTTPS multiplexing). Certain configuration options 429 for encrypted transports could also in principle fingerprint a user 430 or client application. For example: 432 o TLS version or cipher suite selection 434 o session resumption 436 o the maximum number of messages to send or 438 o a maximum connection time before closing a connections and re- 439 opening. 441 Whilst there are known attacks on older versions of TLS the most 442 recent recommendations [RFC7525] and developments [RFC8446] in this 443 area largely mitigate those. 445 Traffic analysis of unpadded encrypted traffic is also possible 446 [pitfalls-of-dns-encrption] because the sizes and timing of encrypted 447 DNS requests and responses can be correlated to unencrypted DNS 448 requests upstream of a recursive resolver. 450 3.5. In the Servers 452 Using the terminology of [RFC6973], the DNS servers (recursive 453 resolvers and authoritative servers) are enablers: they facilitate 454 communication between an initiator and a recipient without being 455 directly in the communications path. As a result, they are often 456 forgotten in risk analysis. But, to quote again [RFC6973], "Although 457 [...] enablers may not generally be considered as attackers, they may 458 all pose privacy threats (depending on the context) because they are 459 able to observe, collect, process, and transfer privacy-relevant 460 data." In [RFC6973] parlance, enablers become observers when they 461 start collecting data. 463 Many programs exist to collect and analyze DNS data at the servers -- 464 from the "query log" of some programs like BIND to tcpdump and more 465 sophisticated programs like PacketQ [packetq] and DNSmezzo 466 [dnsmezzo]. The organization managing the DNS server can use this 467 data itself, or it can be part of a surveillance program like PRISM 468 [prism] and pass data to an outside observer. 470 Sometimes, this data is kept for a long time and/or distributed to 471 third parties for research purposes [ditl] [day-at-root], security 472 analysis, or surveillance tasks. These uses are sometimes under some 473 sort of contract, with various limitations, for instance, on 474 redistribution, given the sensitive nature of the data. Also, there 475 are observation points in the network that gather DNS data and then 476 make it accessible to third parties for research or security purposes 477 ("passive DNS" [passive-dns]). 479 3.5.1. In the Recursive Resolvers 481 Recursive Resolvers see all the traffic since there is typically no 482 caching before them. To summarize: your recursive resolver knows a 483 lot about you. The resolver of a large IAP, or a large public 484 resolver, can collect data from many users. 486 3.5.1.1. Resolver selection 488 Given all the above considerations the choice of recursive resolver 489 has direct privacy considerations for end users. Historically end 490 user devices have used the DHCP provided local network recursive 491 resolver which may have strong, medium or weak privacy policies 492 depending on the network. Privacy policies for these servers may or 493 may not be available and users need to be aware that privacy 494 guarantees will vary with network. 496 More recently some networks and end users have actively chosen to use 497 a large public resolver instead e.g. Google Public DNS, Cloudflare 498 or Quad9 (need refs). There can be many reasons: cost considerations 499 for network operators, better reliability or anti-censorship 500 considerations are just a few. Such services typically do provide a 501 privacy policy and the end user can get an idea of the data collected 502 by such operators by reading one e.g., Google Public DNS - Your 503 Privacy [4]. 505 Even more recently some applications have announced plans to deploy 506 application specific DNS settings which might be enabled by default. 507 For example current proposals by Firefox [firefox] revolve around a 508 default based on geographic region using a pre-configured list of 509 large public resolver services which offer DoH, combined with non- 510 standard probing and signalling mechanism to disable DoH in 511 particular networks. Whereas Chrome [chrome] is experimenting with 512 using DoH to the DHCP provided resolver if it is on a list of DoH- 513 compatible providers. At the time of writing efforts to provide 514 standardized signalling mechanisms for applications to discover the 515 services offered by local resolvers are in progress 516 [I-D.ietf-dnsop-resolver-information]. 518 If applications enable application specific DNS settings without 519 properly informing the user of the change (or do not provide an 520 option for user configuration of the application recursive resolver) 521 there is a potential privacy issue; depending on the network context 522 and the application default the application might use a recursive 523 server that provides less privacy protection than the default network 524 provided server without the users full knowledge. Users that are 525 fully aware of an application specific DNS setting may want to 526 actively override any default in favour of their chosen recursive 527 resolver. 529 There are also concerns that should the trend towards using large 530 public resolvers increase, this will itself provide a privacy concern 531 due to a small number of operators having visibility of the majority 532 of DNS requests globally and the potential for aggregating data 533 across services about a user. Additionally the operating 534 organisation of the resolver may be in a different legal jurisdiction 535 to the user which creates further privacy concerns around legal 536 protections of and access to the data collected by the operator. 538 At the time of writing the deployment models for DNS are evolving, 539 their implications are complex and extend beyond the scope of this 540 document. They are the subject of much other work including 541 [I-D.livingood-doh-implementation-risks-issues], the IETF ADD mailing 542 list [5] and the Encrypted DNS Deployment Initiative [6]. 544 3.5.1.2. Active attacks on resolver configuration 546 The previous paragraphs discussed DNS privacy, assuming that all the 547 traffic was directed to the intended servers (i.e those that would be 548 used in the absence of an active attack) and that the potential 549 attacker was purely passive. But, in reality, we can have active 550 attackers in the network redirecting the traffic, not just to observe 551 it but also potentially change it. 553 For instance, a DHCP server controlled by an attacker can direct you 554 to a recursive resolver also controlled by that attacker. Most of 555 the time, it seems to be done to divert traffic in order to also 556 direct the user to a web server controlled by the attacker. However 557 it could be used just to capture the traffic and gather information 558 about you. 560 Other attacks, besides using DHCP, are possible. The cleartext 561 traffic from a DNS client to a DNS server can be intercepted along 562 its way from originator to intended source, for instance, by 563 transparent attacker controlled DNS proxies in the network that will 564 divert the traffic intended for a legitimate DNS server. This server 565 can masquerade as the intended server and respond with data to the 566 client. (Attacker controlled servers that inject malicious data are 567 possible, but it is a separate problem not relevant to privacy.) A 568 server controlled by an attacker may respond correctly for a long 569 period of time, thereby foregoing detection. 571 Also, malware like DNSchanger [dnschanger] can change the recursive 572 resolver in the machine's configuration, or the routing itself can be 573 subverted (for instance, [ripe-atlas-turkey]). 575 3.5.1.3. Blocking of user selected services 577 User privacy can also be at risk if there is blocking (by local 578 network operators or more general mechanisms) of access to remote 579 recursive servers that offer encrypted transports when the local 580 resolver does not offer encryption and/or has very poor privacy 581 policies. For example active blocking of port 853 for DoT or of 582 specific IP addresses (e.g. 1.1.1.1 or 2606:4700:4700::1111) could 583 restrict the resolvers available to the user. The extent of the risk 584 to end user privacy is highly dependant on the specific network and 585 user context; a user on a network that is known to perform 586 surveillance would be compromised if they could not access such 587 services whereas a user on a trusted network might have no privacy 588 motivation to do so. 590 Similarly attacks on such services e.g. DDoS could force users to 591 switch to other services that do not offer encrypted transports for 592 DNS. 594 3.5.1.4. Authentication of Servers 596 Both DoH and Strict mode for DoT require authentication of the server 597 and therefore as long as the authentication credentials are obtained 598 over a secure channel then using either of these transports defeats 599 the attack of re-directing traffic to rogue servers. Of course 600 attacks on these secure channels are also possible, but out of the 601 scope of this document. 603 3.5.1.5. Encrypted Transports 605 3.5.1.5.1. DoT and DoH 607 Use of encrypted transports does not reduce the data available in the 608 recursive resolver and ironically can actually expose more 609 information about users to operators. As mentioned in Section 3.4 610 use of session based encrypted transports (TCP/TLS) can expose 611 correlation data about users. Such concerns in the TCP/TLS layers 612 apply equally to DoT and DoH which both use TLS as the underlying 613 transport, some examples are: 615 o fingerprinting based on TLS version and/or cipher suite selection 617 o user tracking via session resumption in TLS 1.2 619 3.5.1.5.2. DoH Specific Considerations 621 The proposed specification for DoH [RFC8484] includes a Privacy 622 Considerations section which highlights some of the differences 623 between HTTP and DNS. As a deliberate design choice DoH inherits the 624 privacy properties of the HTTPS stack and as a consequence introduces 625 new privacy concerns when compared with DNS over UDP, TCP or TLS 626 [RFC7858]. The rationale for this decision is that retaining the 627 ability to leverage the full functionality of the HTTP ecosystem is 628 more important than placing specific constraints on this new protocol 629 based on privacy considerations (modulo limiting the use of HTTP 630 cookies). 632 In analyzing the new issues introduced by DoH it is helpful to 633 recognize that there exists a natural tension between 635 o the wide practice in HTTP to use various headers to optimize HTTP 636 connections, functionality and behaviour (which can facilitate 637 user identification and tracking) 639 o and the fact that the DNS payload is currently very tightly 640 encoded and contains no standardized user identifiers. 642 DoT, for example, would normally contain no client identifiers above 643 the TLS layer and a resolver would see only a stream of DNS query 644 payloads originating within one or more connections from a client IP 645 address. Whereas if DoH clients commonly include several headers in 646 a DNS message (e.g. user-agent and accept-language) this could lead 647 to the DoH server being able to identify the source of individual DNS 648 requests not only to a specific end user device but to a specific 649 application. 651 Additionally, depending on the client architecture, isolation of DoH 652 queries from other HTTP traffic may or may not be feasible or 653 desirable. Depending on the use case, isolation of DoH queries from 654 other HTTP traffic may or may not increase privacy. 656 The picture for privacy considerations and user expectations for DoH 657 with respect to what additional data may be available to the DoH 658 server compared to DNS over UDP, TCP or TLS is complex and requires a 659 detailed analysis for each use case. In particular the choice of 660 HTTPS functionality vs privacy is specifically made an implementation 661 choice in DoH and users may well have differing privacy expectations 662 depending on the DoH use case and implementation. 664 At the extremes, there may be implementations that attempt to achieve 665 parity with DoT from a privacy perspective at the cost of using no 666 identifiable headers, there might be others that provide feature rich 667 data flows where the low-level origin of the DNS query is easily 668 identifiable. 670 Privacy focussed users should be aware of the potential for 671 additional client identifiers in DoH compared to DoT and may want to 672 only use DoH client implementations that provide clear guidance on 673 what identifiers they add. 675 3.5.2. In the Authoritative Name Servers 677 Unlike what happens for recursive resolvers, observation capabilities 678 of authoritative name servers are limited by caching; they see only 679 the requests for which the answer was not in the cache. For 680 aggregated statistics ("What is the percentage of LOC queries?"), 681 this is sufficient, but it prevents an observer from seeing 682 everything. Similarly the increasing deployment of QNAME 683 minimisation [ripe-qname-measurements] reduces the data visible at 684 the authoritative name server. Still, the authoritative name servers 685 see a part of the traffic, and this subset may be sufficient to 686 violate some privacy expectations. 688 Also, the end user typically has some legal/contractual link with the 689 recursive resolver (he has chosen the IAP, or he has chosen to use a 690 given public resolver), while having no control and perhaps no 691 awareness of the role of the authoritative name servers and their 692 observation abilities. 694 As noted before, using a local resolver or a resolver close to the 695 machine decreases the attack surface for an on-the-wire eavesdropper. 697 But it may decrease privacy against an observer located on an 698 authoritative name server. This authoritative name server will see 699 the IP address of the end client instead of the address of a big 700 recursive resolver shared by many users. 702 This "protection", when using a large resolver with many clients, is 703 no longer present if ECS [RFC7871] is used because, in this case, the 704 authoritative name server sees the original IP address (or prefix, 705 depending on the setup). 707 As of today, all the instances of one root name server, L-root, 708 receive together around 50,000 queries per second. While most of it 709 is "junk" (errors on the Top-Level Domain (TLD) name), it gives an 710 idea of the amount of big data that pours into name servers. (And 711 even "junk" can leak information; for instance, if there is a typing 712 error in the TLD, the user will send data to a TLD that is not the 713 usual one.) 715 Many domains, including TLDs, are partially hosted by third-party 716 servers, sometimes in a different country. The contracts between the 717 domain manager and these servers may or may not take privacy into 718 account. Whatever the contract, the third-party hoster may be honest 719 or not but, in any case, it will have to follow its local laws. So, 720 requests to a given ccTLD may go to servers managed by organizations 721 outside of the ccTLD's country. End users may not anticipate that, 722 when doing a security analysis. 724 Also, it seems (see the survey described in [aeris-dns]) that there 725 is a strong concentration of authoritative name servers among 726 "popular" domains (such as the Alexa Top N list). For instance, 727 among the Alexa Top 100K, one DNS provider hosts today 10% of the 728 domains. The ten most important DNS providers host together one 729 third of the domains. With the control (or the ability to sniff the 730 traffic) of a few name servers, you can gather a lot of information. 732 3.6. Re-identification and Other Inferences 734 An observer has access not only to the data he/she directly collects 735 but also to the results of various inferences about this data. The 736 term 'observer' here is used very generally, it might be one that is 737 passively observing cleartext DNS traffic, one in the network that is 738 actively attacking the user by re-directing DNS resolution, or it 739 might be a local or remote resolver operator. 741 For instance, a user can be re-identified via DNS queries. If the 742 adversary knows a user's identity and can watch their DNS queries for 743 a period, then that same adversary may be able to re-identify the 744 user solely based on their pattern of DNS queries later on regardless 745 of the location from which the user makes those queries. For 746 example, one study [herrmann-reidentification] found that such re- 747 identification is possible so that "73.1% of all day-to-day links 748 were correctly established, i.e. user u was either re-identified 749 unambiguously (1) or the classifier correctly reported that u was not 750 present on day t+1 any more (2)." While that study related to web 751 browsing behavior, equally characteristic patterns may be produced 752 even in machine-to-machine communications or without a user taking 753 specific actions, e.g., at reboot time if a characteristic set of 754 services are accessed by the device. 756 For instance, one could imagine that an intelligence agency 757 identifies people going to a site by putting in a very long DNS name 758 and looking for queries of a specific length. Such traffic analysis 759 could weaken some privacy solutions. 761 The IAB privacy and security program also have a work in progress 762 [RFC7624] that considers such inference-based attacks in a more 763 general framework. 765 3.7. More Information 767 Useful background information can also be found in [tor-leak] (about 768 the risk of privacy leak through DNS) and in a few academic papers: 769 [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and 770 [federrath-fuchs-herrmann-piosecny]. 772 4. Actual "Attacks" 774 A very quick examination of DNS traffic may lead to the false 775 conclusion that extracting the needle from the haystack is difficult. 776 "Interesting" primary DNS requests are mixed with useless (for the 777 eavesdropper) secondary and tertiary requests (see the terminology in 778 Section 1). But, in this time of "big data" processing, powerful 779 techniques now exist to get from the raw data to what the 780 eavesdropper is actually interested in. 782 Many research papers about malware detection use DNS traffic to 783 detect "abnormal" behavior that can be traced back to the activity of 784 malware on infected machines. Yes, this research was done for the 785 good, but technically it is a privacy attack and it demonstrates the 786 power of the observation of DNS traffic. See [dns-footprint], 787 [dagon-malware], and [darkreading-dns]. 789 Passive DNS systems [passive-dns] allow reconstruction of the data of 790 sometimes an entire zone. They are used for many reasons -- some 791 good, some bad. Well-known passive DNS systems keep only the DNS 792 responses, and not the source IP address of the client, precisely for 793 privacy reasons. Other passive DNS systems may not be so careful. 794 And there is still the potential problems with revealing QNAMEs. 796 The revelations from the Edward Snowden documents, which were leaked 797 from the National Security Agency (NSA) provide evidence of the use 798 of the DNS in mass surveillance operations [morecowbell]. For 799 example the MORECOWBELL surveillance program, which uses a dedicated 800 covert monitoring infrastructure to actively query DNS servers and 801 perform HTTP requests to obtain meta information about services and 802 to check their availability. Also the QUANTUMTHEORY project which 803 includes detecting lookups for certain addresses and injecting bogus 804 replies is another good example showing that the lack of privacy 805 protections in the DNS is actively exploited. 807 5. Legalities 809 To our knowledge, there are no specific privacy laws for DNS data, in 810 any country. Interpreting general privacy laws like 811 [data-protection-directive] or GDPR [7] applicable in the European 812 Union in the context of DNS traffic data is not an easy task, and we 813 do not know a court precedent here. See an interesting analysis in 814 [sidn-entrada]. 816 6. Security Considerations 818 This document is entirely about security, more precisely privacy. It 819 just lays out the problem; it does not try to set requirements (with 820 the choices and compromises they imply), much less define solutions. 821 Possible solutions to the issues described here are discussed in 822 other documents (currently too many to all be mentioned); see, for 823 instance, 'Recommendations for DNS Privacy Operators' 824 [I-D.ietf-dprive-bcp-op]. 826 7. Acknowledgments 828 Thanks to Nathalie Boulvard and to the CENTR members for the original 829 work that led to this document. Thanks to Ondrej Sury for the 830 interesting discussions. Thanks to Mohsen Souissi and John Heidemann 831 for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz, 832 Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for 833 proofreading, providing technical remarks, and making many 834 readability improvements. Thanks to Dan York, Suzanne Woolf, Tony 835 Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis 836 for good written contributions. And thanks to the IESG members for 837 the last remarks. 839 8. Changelog 841 draft-ietf-dprive-rfc7627-bis-01 843 o Re-structure section 3.5 (was 2.5) 845 * Collect considerations for recursive resolvers together 847 * Re-work several sections here to clarify their context (e.g. 848 'Rogue servers' becomes 'Active attacks on resolver 849 configuration') 851 * Add discussion of resolver selection 853 o Update text and old reference on Snowdon revelations. 855 o Add text on and references to QNAME minimisation RFC and 856 deployment measurements 858 o Correct outdated references 860 o Clarify scope by adding a Scope section (was Risks overview) 862 o Clarify what risks are considered in section 3.4.2 864 draft-ietf-dprive-rfc7627-bis-00 866 o Rename after WG adoption 868 o Use DoT acronym throughout 870 o Minor updates to status of deployment and other drafts 872 draft-bortzmeyer-dprive-rfc7626-bis-02 874 o Update various references and fix some nits. 876 draft-bortzmeyer-dprive-rfc7626-bis-01 878 o Update reference for dickinson-bcp-op to draft-dickinson-dprive- 879 bcp-op 881 draft-borztmeyer-dprive-rfc7626-bis-00: 883 Initial commit. Differences to RFC7626: 885 o Update many references 886 o Add discussions of encrypted transports including DoT and DoH 888 o Add section on DNS payload 890 o Add section on authentication of servers 892 o Add section on blocking of services 894 9. References 896 9.1. Normative References 898 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 899 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 900 . 902 [RFC1035] Mockapetris, P., "Domain names - implementation and 903 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 904 November 1987, . 906 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 907 Morris, J., Hansen, M., and R. Smith, "Privacy 908 Considerations for Internet Protocols", RFC 6973, 909 DOI 10.17487/RFC6973, July 2013, . 912 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 913 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 914 2014, . 916 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 917 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 918 . 920 9.2. Informative References 922 [aeris-dns] 923 Vinot, N., "Vie privee: et le DNS alors?", (In French), 924 2015, . 927 [castillo-garcia] 928 Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous 929 Resolution of DNS Queries", 2008, 930 . 932 [chrome] Baheux, , "Experimenting with same-provider DNS-over-HTTPS 933 upgrade", September 2019, 934 . 937 [dagon-malware] 938 Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a 939 Malicious Resolution Authority", ISC/OARC Workshop, 2007, 940 . 943 [darkreading-dns] 944 Lemos, R., "Got Malware? Three Signs Revealed In DNS 945 Traffic", InformationWeek Dark Reading, May 2013, 946 . 950 [data-protection-directive] 951 European Parliament, "Directive 95/46/EC of the European 952 Pariament and of the council on the protection of 953 individuals with regard to the processing of personal data 954 and on the free movement of such data", Official Journal L 955 281, pp. 0031 - 0050, November 1995, . 959 [day-at-root] 960 Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A 961 Day at the Root of the Internet", ACM SIGCOMM Computer 962 Communication Review, Vol. 38, Number 5, 963 DOI 10.1145/1452335.1452341, October 2008, 964 . 967 [denis-edns-client-subnet] 968 Denis, F., "Security and privacy issues of edns-client- 969 subnet", August 2013, . 972 [ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002, 973 . 975 [dns-footprint] 976 Stoner, E., "DNS Footprint of Malware", OARC Workshop, 977 October 2010, . 980 [dnschanger] 981 Wikipedia, "DNSChanger", October 2013, 982 . 985 [dnsmezzo] 986 Bortzmeyer, S., "DNSmezzo", 2009, 987 . 989 [fangming-hori-sakurai] 990 Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of 991 Privacy Disclosure in DNS Query", 2007 International 992 Conference on Multimedia and Ubiquitous Engineering (MUE 993 2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957, 994 DOI 10.1109/MUE.2007.84, April 2007, 995 . 997 [federrath-fuchs-herrmann-piosecny] 998 Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny, 999 "Privacy-Preserving DNS: Analysis of Broadcast, Range 1000 Queries and Mix-based Protection Methods", Computer 1001 Security ESORICS 2011, Springer, page(s) 665-683, 1002 ISBN 978-3-642-23821-5, 2011, . 1006 [firefox] Deckelmann, , "What's next in making Encrypted DNS-over- 1007 HTTPS the Default", September 2019, 1008 . 1011 [grangeia.snooping] 1012 Grangeia, L., "DNS Cache Snooping or Snooping the Cache 1013 for Fun and Profit", 2005, 1014 . 1018 [herrmann-reidentification] 1019 Herrmann, D., Gerber, C., Banse, C., and H. Federrath, 1020 "Analyzing Characteristic Host Access Patterns for Re- 1021 Identification of Web User Sessions", 1022 DOI 10.1007/978-3-642-27937-9_10, 2012, . 1025 [I-D.ietf-dnsop-resolver-information] 1026 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 1027 Information Self-publication", draft-ietf-dnsop-resolver- 1028 information-00 (work in progress), August 2019. 1030 [I-D.ietf-dprive-bcp-op] 1031 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 1032 Mankin, "Recommendations for DNS Privacy Service 1033 Operators", draft-ietf-dprive-bcp-op-03 (work in 1034 progress), July 2019. 1036 [I-D.ietf-quic-transport] 1037 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1038 and Secure Transport", draft-ietf-quic-transport-23 (work 1039 in progress), September 2019. 1041 [I-D.ietf-tls-sni-encryption] 1042 Huitema, C. and E. Rescorla, "Issues and Requirements for 1043 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-06 1044 (work in progress), September 2019. 1046 [I-D.livingood-doh-implementation-risks-issues] 1047 Livingood, J., Antonakakis, M., Sleigh, B., and A. 1048 Winfield, "Centralized DNS over HTTPS (DoH) Implementation 1049 Issues and Risks", draft-livingood-doh-implementation- 1050 risks-issues-04 (work in progress), September 2019. 1052 [morecowbell] 1053 Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, 1054 "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January 1055 2015, . 1058 [packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries 1059 against PCAP-files", 2011, . 1062 [passive-dns] 1063 Weimer, F., "Passive DNS Replication", April 2005, 1064 . 1067 [pitfalls-of-dns-encrption] 1068 Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS 1069 Encryption", . 1071 [prism] Wikipedia, "PRISM (surveillance program)", July 2015, 1072 . 1075 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1076 Rose, "DNS Security Introduction and Requirements", 1077 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1078 . 1080 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1081 Security (DNSSEC) Hashed Authenticated Denial of 1082 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1083 . 1085 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1086 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1087 . 1089 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1090 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1091 DOI 10.17487/RFC6269, June 2011, . 1094 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1095 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1096 . 1098 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1099 "Recommendations for Secure Use of Transport Layer 1100 Security (TLS) and Datagram Transport Layer Security 1101 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1102 2015, . 1104 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1105 Trammell, B., Huitema, C., and D. Borkmann, 1106 "Confidentiality in the Face of Pervasive Surveillance: A 1107 Threat Model and Problem Statement", RFC 7624, 1108 DOI 10.17487/RFC7624, August 2015, . 1111 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1112 and P. Hoffman, "Specification for DNS over Transport 1113 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1114 2016, . 1116 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1117 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1118 DOI 10.17487/RFC7871, May 2016, . 1121 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1122 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1123 . 1125 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 1126 (DANE) Bindings for OpenPGP", RFC 7929, 1127 DOI 10.17487/RFC7929, August 2016, . 1130 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1131 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1132 . 1134 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1135 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1136 . 1138 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1139 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1140 January 2019, . 1142 [ripe-atlas-turkey] 1143 Aben, E., "A RIPE Atlas View of Internet Meddling in 1144 Turkey", March 2014, 1145 . 1148 [ripe-qname-measurements] 1149 University of Twente, "Making the DNS More Private with 1150 QNAME Minimisation", April 2019, 1151 . 1154 [sidn-entrada] 1155 Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. 1156 Simon, "A privacy framework for 'DNS big data' 1157 applications", November 2014, 1158 . 1162 [thomas-ditl-tcp] 1163 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 1164 Root Server DITL Data", DNS-OARC 2014 Fall Workshop, 1165 October 2014, . 1169 [tor-leak] 1170 Tor, "DNS leaks in Tor", 2013, 1171 . 1174 [yanbin-tsudik] 1175 Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks 1176 in the Domain Name System", October 2009, 1177 . 1179 9.3. URIs 1181 [1] https://lists.dns-oarc.net/pipermail/dns- 1182 operations/2016-January/014141.html 1184 [2] http://netres.ec/?b=11B99BD 1186 [3] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS- 1187 based_De-NAT_Scheme 1189 [4] https://developers.google.com/speed/public-dns/privacy 1191 [5] https://mailarchive.ietf.org/arch/browse/static/add 1193 [6] https://www.encrypted-dns.org 1195 [7] https://www.eugdpr.org/the-regulation.html 1197 Authors' Addresses 1199 Stephane Bortzmeyer 1200 AFNIC 1201 1, rue Stephenson 1202 Montigny-le-Bretonneux 1203 France 78180 1205 Email: bortzmeyer+ietf@nic.fr 1206 Sara Dickinson 1207 Sinodun IT 1208 Magdalen Centre 1209 Oxford Science Park 1210 Oxford OX4 4GA 1211 United Kingdom 1213 Email: sara@sinodun.com