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