1 Internet Engineering Task Force (IETF) T. Wicinski, Ed.
2 Request for Comments: 9076 July 2021
3 Obsoletes: 7626
4 Category: Informational
5 ISSN: 2070-1721
6
7
8 DNS Privacy Considerations
9
10 Abstract
11
12 This document describes the privacy issues associated with the use of
13 the DNS by Internet users. It provides general observations about
14 typical current privacy practices. It is intended to be an analysis
15 of the present situation and does not prescribe solutions. This
16 document obsoletes RFC 7626.
17
18 Status of This Memo
19
20 This document is not an Internet Standards Track specification; it is
21 published for informational purposes.
22
23 This document is a product of the Internet Engineering Task Force
24 (IETF). It represents the consensus of the IETF community. It has
25 received public review and has been approved for publication by the
26 Internet Engineering Steering Group (IESG). Not all documents
27 approved by the IESG are candidates for any level of Internet
28 Standard; see Section 2 of RFC 7841.
29
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 https://www.rfc-editor.org/info/rfc9076.
33
34 Copyright Notice
35
36 Copyright (c) 2021 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
38
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (https://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
48
49 Table of Contents
50
51 1. Introduction
52 2. Scope
53 3. Risks
54 4. Risks in the DNS Data
55 4.1. The Public Nature of DNS Data
56 4.2. Data in the DNS Request
57 4.2.1. Data in the DNS Payload
58 4.3. Cache Snooping
59 5. Risks on the Wire
60 5.1. Unencrypted Transports
61 5.2. Encrypted Transports
62 6. Risks in the Servers
63 6.1. In the Recursive Resolvers
64 6.1.1. Resolver Selection
65 6.1.2. Active Attacks on Resolver Configuration
66 6.1.3. Blocking of DNS Resolution Services
67 6.1.4. Encrypted Transports and Recursive Resolvers
68 6.2. In the Authoritative Name Servers
69 7. Other Risks
70 7.1. Re-identification and Other Inferences
71 7.2. More Information
72 8. Actual "Attacks"
73 9. Legalities
74 10. Security Considerations
75 11. IANA Considerations
76 12. References
77 12.1. Normative References
78 12.2. Informative References
79 Appendix A. Updates since RFC 7626
80 Acknowledgments
81 Contributions
82 Author's Address
83
84 1. Introduction
85
86 This document is an analysis of the DNS privacy issues, in the spirit
87 of Section 8 of [RFC6973].
88
89 The Domain Name System (DNS) is specified in [RFC1034], [RFC1035],
90 and many later RFCs, which have never been consolidated. It is one
91 of the most important infrastructure components of the Internet and
92 is often ignored or misunderstood by Internet users (and even by many
93 professionals). Almost every activity on the Internet starts with a
94 DNS query (and often several). Its use has many privacy
95 implications, and this document is an attempt at a comprehensive and
96 accurate list.
97
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 full resolver, or recursive name server). Let's use the query "What
102 are the AAAA records for www.example.com?" as an example. AAAA is
103 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 servers will then
111 return the answers. 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.
124
125 DNS relies heavily on caching, 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 the stub resolver asks the
128 recursive resolver a few seconds later, "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.)
137
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).
145
146 At the time of writing, almost all this DNS traffic is currently sent
147 unencrypted. However, there is increasing deployment of DNS over TLS
148 (DoT) [RFC7858] and DNS over HTTPS (DoH) [RFC8484], particularly in
149 mobile devices, browsers, and by providers of anycast recursive DNS
150 resolution services. There are a few cases where there is some
151 alternative channel encryption, for instance, in an IPsec VPN tunnel,
152 at least between the stub resolver and the resolver. Some recent
153 analysis on the service quality of encrypted DNS traffic can be found
154 in [dns-over-encryption].
155
156 Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
157 This has practical consequences when considering encryption of the
158 traffic as a possible privacy technique. Some encryption solutions
159 are only designed for TCP, not UDP, although new solutions are still
160 emerging [RFC9000] [DPRIVE-DNSOQUIC].
161
162 Another important point to keep in mind when analyzing the privacy
163 issues of DNS is the fact that DNS requests received by a server are
164 triggered for different reasons. Let's assume an eavesdropper wants
165 to know which web page is viewed by a user. For a typical web page,
166 there are three sorts of DNS requests being issued:
167
168 Primary request:
169 This is the domain name in the URL that the user typed, selected
170 from a bookmark, or chose by clicking on a hyperlink. Presumably,
171 this is what is of interest for the eavesdropper.
172
173 Secondary requests:
174 These are the additional requests performed by the user agent
175 (here, the web browser) without any direct involvement or
176 knowledge of the user. For the Web, they are triggered by
177 embedded content, Cascading Style Sheets (CSS), JavaScript code,
178 embedded images, etc. In some cases, there can be dozens of
179 domain names in different contexts on a single web page.
180
181 Tertiary requests:
182 These are the additional requests performed by the DNS service
183 itself. For instance, if the answer to a query is a referral to a
184 set of name servers and the glue records are not returned, the
185 resolver will have to send additional requests to turn the name
186 servers' names into IP addresses. Similarly, even if glue records
187 are returned, a careful recursive server will send tertiary
188 requests to verify the IP addresses of those records.
189
190 It can also be noted that, in the case of a typical web browser, more
191 DNS requests than strictly necessary are sent, for instance, to
192 prefetch resources that the user may query later or when
193 autocompleting the URL in the address bar. Both are a significant
194 privacy concern since they may leak information even about non-
195 explicit actions. For instance, just reading a local HTML page, even
196 without selecting the hyperlinks, may trigger DNS requests.
197
198 Privacy-related terminology is from [RFC6973]. This document
199 obsoletes [RFC7626].
200
201 2. Scope
202
203 This document focuses mostly on the study of privacy risks for the
204 end user (the one performing DNS requests). The risks of pervasive
205 surveillance [RFC7258] are considered as well as risks coming from a
206 more focused surveillance. In this document, the term "end user" is
207 used as defined in [RFC8890].
208
209 This document does not attempt a comparison of specific privacy
210 protections provided by individual networks or organizations; it
211 makes only general observations about typical current practices.
212
213 Privacy risks for the holder of a zone (the risk that someone gets
214 the data) are discussed in [RFC5155] and [RFC5936].
215
216 Privacy risks for recursive operators (including access providers and
217 operators in enterprise networks) such as leakage of private
218 namespaces or blocklists are out of scope for this document.
219
220 Non-privacy risks (e.g., security-related considerations such as
221 cache poisoning) are also out of scope.
222
223 The privacy risks associated with the use of other protocols that
224 make use of DNS information are not considered here.
225
226 3. Risks
227
228 The following four sections outline the privacy considerations
229 associated with different aspects of the DNS for the end user. When
230 reading these sections, it needs to be kept in mind that many of the
231 considerations (for example, recursive resolver and transport
232 protocol) can be specific to the network context that a device is
233 using at a given point in time. A user may have many devices, and
234 each device might utilize many different networks (e.g., home, work,
235 public, or cellular) over a period of time or even concurrently. An
236 exhaustive analysis of the privacy considerations for an individual
237 user would need to take into account the set of devices used and the
238 multiple dynamic contexts of each device. This document does not
239 attempt such a complex analysis; instead, it presents an overview of
240 the various considerations that could form the basis of such an
241 analysis.
242
243 4. Risks in the DNS Data
244
245 4.1. The Public Nature of DNS Data
246
247 It has been stated that "the data in the DNS is public". This
248 sentence makes sense for an Internet-wide lookup system, and there
249 are multiple facets to the data and metadata involved that deserve a
250 more detailed look. First, access control lists (ACLs) and private
251 namespaces notwithstanding, the DNS operates under the assumption
252 that public-facing authoritative name servers will respond to "usual"
253 DNS queries for any zone they are authoritative for, without further
254 authentication or authorization of the client (resolver). Due to the
255 lack of search capabilities, only a given QNAME will reveal the
256 resource records associated with that name (or that name's
257 nonexistence). In other words: one needs to know what to ask for in
258 order to receive a response. There are many ways in which supposedly
259 "private" resources currently leak. A few examples are DNSSEC NSEC
260 zone walking [RFC4470], passive DNS services [passive-dns], etc. The
261 zone transfer QTYPE [RFC5936] is often blocked or restricted to
262 authenticated/authorized access to enforce this difference (and maybe
263 for other reasons).
264
265 Another difference between the DNS data and a particular DNS
266 transaction (i.e., a DNS name lookup): DNS data and the results of a
267 DNS query are public, within the boundaries described above, and may
268 not have any confidentiality requirements. However, the same is not
269 true of a single transaction or a sequence of transactions; those
270 transactions are not / should not be public. A single transaction
271 reveals both the originator of the query and the query contents; this
272 potentially leaks sensitive information about a specific user. A
273 typical example from outside the DNS world is that the website of
274 Alcoholics Anonymous is public but the fact that you visit it should
275 not be. Furthermore, the ability to link queries reveals information
276 about individual use patterns.
277
278 4.2. Data in the DNS Request
279
280 The DNS request includes many fields, but two of them seem
281 particularly relevant for the privacy issues: the QNAME and the
282 source IP address. "Source IP address" is used in a loose sense of
283 "source IP address + maybe source port number", because the port
284 number is also in the request and can be used to differentiate
285 between several users sharing an IP address (behind a Carrier-Grade
286 NAT (CGN), for instance [RFC6269]).
287
288 The QNAME is the full name sent by the user. It gives information
289 about what the user does ("What are the MX records of example.net?"
290 means they probably want to send email to someone at example.net,
291 which may be a domain used by only a few persons and is therefore
292 very revealing about communication relationships). Some QNAMEs are
293 more sensitive than others. For instance, querying the A record of a
294 well-known web statistics domain reveals very little (everybody
295 visits websites that use this analytics service), but querying the A
296 record of www.verybad.example where verybad.example is the domain of
297 an organization that some people find offensive or objectionable may
298 create more problems for the user. Also, sometimes, the QNAME embeds
299 the software one uses, which could be a privacy issue (for instance,
300 _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
301 There are also some BitTorrent clients that query an SRV record for
302 _bittorrent-tracker._tcp.domain.example.
303
304 Another important thing about the privacy of the QNAME is future
305 usages. Today, the lack of privacy is an obstacle to putting
306 potentially sensitive or personally identifiable data in the DNS. At
307 the moment, your DNS traffic might reveal that you are exchanging
308 emails but not with whom. If your Mail User Agent (MUA) starts
309 looking up Pretty Good Privacy (PGP) keys in the DNS [RFC7929], then
310 privacy becomes a lot more important. And email is just an example;
311 there would be other really interesting uses for a more privacy-
312 friendly DNS.
313
314 For the communication between the stub resolver and the recursive
315 resolver, the source IP address is the address of the user's machine.
316 Therefore, all the issues and warnings about collection of IP
317 addresses apply here. For the communication between the recursive
318 resolver and the authoritative name servers, the source IP address
319 has a different meaning; it does not have the same status as the
320 source address in an HTTP connection. It is typically the IP address
321 of the recursive resolver that, in a way, "hides" the real user.
322 However, hiding does not always work. The edns-client-subnet (ECS)
323 EDNS0 option [RFC7871] is sometimes used (see one privacy analysis in
324 [denis-edns-client-subnet]). Sometimes the end user has a personal
325 recursive resolver on their machine. In both cases, the IP address
326 originating queries to the authoritative server is as sensitive as it
327 is for HTTP [sidn-entrada].
328
329 A note about IP addresses: there is currently no IETF document that
330 describes in detail all the privacy issues around IP addressing in
331 general, although [RFC7721] does discuss privacy considerations for
332 IPv6 address generation mechanisms. In the meantime, the discussion
333 here is intended to include both IPv4 and IPv6 source addresses. For
334 a number of reasons, their assignment and utilization characteristics
335 are different, which may have implications for details of information
336 leakage associated with the collection of source addresses. (For
337 example, a specific IPv6 source address seen on the public Internet
338 is less likely than an IPv4 address to originate behind an address-
339 sharing scheme.) However, for both IPv4 and IPv6 addresses, it is
340 important to note that source addresses are propagated with queries
341 via the ECS option and comprise metadata about the host, user, or
342 application that originated them.
343
344 4.2.1. Data in the DNS Payload
345
346 At the time of writing, there are no standardized client identifiers
347 contained in the DNS payload itself (ECS, as described in [RFC7871],
348 is widely used; however, [RFC7871] is only an Informational RFC).
349
350 DNS Cookies [RFC7873] are a lightweight DNS transaction security
351 mechanism that provides limited protection against a variety of
352 increasingly common denial-of-service and amplification/forgery or
353 cache poisoning attacks by off-path attackers. It is noted, however,
354 that they are designed to just verify IP addresses (and should change
355 once a client's IP address changes), but they are not designed to
356 actively track users (like HTTP cookies).
357
358 There are anecdotal accounts of Media Access Control (MAC) addresses
359 (https://lists.dns-oarc.net/pipermail/dns-
360 operations/2016-January/014143.html) and even user names being
361 inserted in nonstandard EDNS(0) options [RFC6891] for stub-to-
362 resolver communications to support proprietary functionality
363 implemented at the resolver (e.g., parental filtering).
364
365 4.3. Cache Snooping
366
367 The content of recursive resolvers' caches can reveal data about the
368 clients using it (the privacy risks depend on the number of clients).
369 This information can sometimes be examined by sending DNS queries
370 with RD=0 to inspect cache content, particularly looking at the DNS
371 TTLs [grangeia.snooping]. Since this also is a reconnaissance
372 technique for subsequent cache poisoning attacks, some
373 countermeasures have already been developed and deployed
374 [cache-snooping-defence].
375
376 5. Risks on the Wire
377
378 5.1. Unencrypted Transports
379
380 For unencrypted transports, DNS traffic can be seen by an
381 eavesdropper like any other traffic. (DNSSEC, specified in
382 [RFC4033], explicitly excludes confidentiality from its goals.) So,
383 if an initiator starts an HTTPS communication with a recipient, the
384 HTTP traffic will be encrypted, but the DNS exchange prior to it will
385 not be. When other protocols become more and more privacy aware and
386 secured against surveillance (e.g., [RFC8446], [RFC9000]), the use of
387 unencrypted transports for DNS may become "the weakest link" in
388 privacy. It is noted that, at the time of writing, there is ongoing
389 work attempting to encrypt the Server Name Identification (SNI) in
390 the TLS handshake [RFC8744], which is one of the last remaining non-
391 DNS cleartext identifiers of a connection target.
392
393 An important specificity of the DNS traffic is that it may take a
394 different path than the communication between the initiator and the
395 recipient. For instance, an eavesdropper may be unable to tap the
396 wire between the initiator and the recipient but may have access to
397 the wire going to the recursive resolver or to the authoritative name
398 servers.
399
400 The best place to tap, from an eavesdropper's point of view, is
401 clearly between the stub resolvers and the recursive resolvers,
402 because traffic is not limited by DNS caching.
403
404 The attack surface between the stub resolver and the rest of the
405 world can vary widely depending upon how the end user's device is
406 configured. By order of increasing attack surface:
407
408 * The recursive resolver can be on the end user's device. In
409 (currently) a small number of cases, individuals may choose to
410 operate their own DNS resolver on their local machine. In this
411 case, the attack surface for the connection between the stub
412 resolver and the caching resolver is limited to that single
413 machine. The recursive resolver will expose data to authoritative
414 resolvers as discussed in Section 6.2.
415
416 * The recursive resolver may be at the local network edge. For
417 many/most enterprise networks and for some residential networks,
418 the caching resolver may exist on a server at the edge of the
419 local network. In this case, the attack surface is the local
420 network. Note that in large enterprise networks, the DNS resolver
421 may not be located at the edge of the local network but rather at
422 the edge of the overall enterprise network. In this case, the
423 enterprise network could be thought of as similar to the Internet
424 Access Provider (IAP) network referenced below.
425
426 * The recursive resolver can be in the IAP network. For most
427 residential networks and potentially other networks, the typical
428 case is for the user's device to be configured (typically
429 automatically through DHCP or relay agent options) with the
430 addresses of the DNS proxy in the Customer Premises Equipment
431 (CPE), which in turn points to the DNS recursive resolvers at the
432 IAP. The attack surface for on-the-wire attacks is therefore from
433 the end user system across the local network and across the IAP
434 network to the IAP's recursive resolvers.
435
436 * The recursive resolver can be a public DNS service (or a privately
437 run DNS resolver hosted on the public Internet). Some machines
438 may be configured to use public DNS resolvers such as those
439 operated by Google Public DNS or OpenDNS. The user may have
440 configured their machine to use these DNS recursive resolvers
441 themselves -- or their IAP may have chosen to use the public DNS
442 resolvers rather than operating their own resolvers. In this
443 case, the attack surface is the entire public Internet between the
444 user's connection and the public DNS service. It can be noted
445 that if the user selects a single resolver with a small client
446 population (even when using an encrypted transport), it can
447 actually serve to aid tracking of that user as they move across
448 network environments.
449
450 It is also noted that, typically, a device connected _only_ to a
451 modern cellular network is
452
453 * directly configured with only the recursive resolvers of the IAP
454 and
455
456 * afforded some level of protection against some types of
457 eavesdropping for all traffic (including DNS traffic) due to the
458 cellular network link-layer encryption.
459
460 The attack surface for this specific scenario is not considered here.
461
462 5.2. Encrypted Transports
463
464 The use of encrypted transports directly mitigates passive
465 surveillance of the DNS payload; however, some privacy attacks are
466 still possible. This section enumerates the residual privacy risks
467 to an end user when an attacker can passively monitor encrypted DNS
468 traffic flows on the wire.
469
470 These are cases where user identification, fingerprinting, or
471 correlations may be possible due to the use of certain transport
472 layers or cleartext/observable features. These issues are not
473 specific to DNS, but DNS traffic is susceptible to these attacks when
474 using specific transports.
475
476 Some general examples exist; for example, certain studies highlight
477 that the OS fingerprint values (http://netres.ec/?b=11B99BD) of IPv4
478 TTL, IPv6 Hop Limit, or TCP Window size can be used to fingerprint
479 client OSes or that various techniques can be used to de-NAT DNS
480 queries [dns-de-nat].
481
482 Note that even when using encrypted transports, the use of cleartext
483 transport options to decrease latency can provide correlation of a
484 user's connections, e.g., using TCP Fast Open [RFC7413].
485
486 Implementations that support encrypted transports also commonly reuse
487 connections for multiple DNS queries to optimize performance (e.g.,
488 via DNS pipelining or HTTPS multiplexing). Default configuration
489 options for encrypted transports could, in principle, fingerprint a
490 specific client application. For example:
491
492 * TLS version or cipher suite selection
493
494 * session resumption
495
496 * the maximum number of messages to send and
497
498 * a maximum connection time before closing a connections and
499 reopening.
500
501 If libraries or applications offer user configuration of such options
502 (e.g., [getdns]), then they could, in principle, help to identify a
503 specific user. Users may want to use only the defaults to avoid this
504 issue.
505
506 While there are known attacks on older versions of TLS, the most
507 recent recommendations [RFC7525] and the development of TLS 1.3
508 [RFC8446] largely mitigate those.
509
510 Traffic analysis of unpadded encrypted traffic is also possible
511 [pitfalls-of-dns-encryption] because the sizes and timing of
512 encrypted DNS requests and responses can be correlated to unencrypted
513 DNS requests upstream of a recursive resolver.
514
515 6. Risks in the Servers
516
517 Using the terminology of [RFC6973], the DNS servers (recursive
518 resolvers and authoritative servers) are enablers: "they facilitate
519 communication between an initiator and a recipient without being
520 directly in the communications path". As a result, they are often
521 forgotten in risk analysis. But, to quote [RFC6973] again, "Although
522 [...] enablers may not generally be considered as attackers, they may
523 all pose privacy threats (depending on the context) because they are
524 able to observe, collect, process, and transfer privacy-relevant
525 data". In [RFC6973] parlance, enablers become observers when they
526 start collecting data.
527
528 Many programs exist to collect and analyze DNS data at the servers --
529 from the "query log" of some programs like BIND to tcpdump and more
530 sophisticated programs like PacketQ [packetq] and DNSmezzo
531 [dnsmezzo]. The organization managing the DNS server can use this
532 data itself, or it can be part of a surveillance program like PRISM
533 [prism] and pass data to an outside observer.
534
535 Sometimes this data is kept for a long time and/or distributed to
536 third parties for research purposes [ditl] [day-at-root], security
537 analysis, or surveillance tasks. These uses are sometimes under some
538 sort of contract, with various limitations, for instance, on
539 redistribution, given the sensitive nature of the data. Also, there
540 are observation points in the network that gather DNS data and then
541 make it accessible to third parties for research or security purposes
542 ("passive DNS" [passive-dns]).
543
544 6.1. In the Recursive Resolvers
545
546 Recursive resolvers see all the traffic since there is typically no
547 caching before them. To summarize: your recursive resolver knows a
548 lot about you. The resolver of a large IAP, or a large public
549 resolver, can collect data from many users.
550
551 6.1.1. Resolver Selection
552
553 Given all the above considerations, the choice of recursive resolver
554 has direct privacy considerations for end users. Historically, end
555 user devices have used the DHCP-provided local network recursive
556 resolver. The choice by a user to join a particular network (e.g.,
557 by physically plugging in a cable or selecting a network in an OS
558 dialogue) typically updates a number of system resources -- these can
559 include IP addresses, the availability of IPv4/IPv6, DHCP server, and
560 DNS resolver. These individual changes, including the change in DNS
561 resolver, are not normally communicated directly to the user by the
562 OS when the network is joined. The choice of network has
563 historically determined the default system DNS resolver selection;
564 the two are directly coupled in this model.
565
566 The vast majority of users do not change their default system DNS
567 settings and so implicitly accept the network settings for the DNS.
568 The network resolvers have therefore historically been the sole
569 destination for all of the DNS queries from a device. These
570 resolvers may have varied privacy policies depending on the network.
571 Privacy policies for these servers may or may not be available, and
572 users need to be aware that privacy guarantees will vary with the
573 network.
574
575 All major OSes expose the system DNS settings and allow users to
576 manually override them if desired.
577
578 More recently, some networks and users have actively chosen to use a
579 large public resolver, e.g., Google Public DNS
580 (https://developers.google.com/speed/public-dns), Cloudflare
581 (https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/), or
582 Quad9 (https://www.quad9.net). There can be many reasons: cost
583 considerations for network operators, better reliability, or anti-
584 censorship considerations are just a few. Such services typically do
585 provide a privacy policy, and the user can get an idea of the data
586 collected by such operators by reading one, e.g., Google Public DNS -
587 Your Privacy (https://developers.google.com/speed/public-dns/
588 privacy).
589
590 In general, as with many other protocols, issues around
591 centralization also arise with DNS. The picture is fluid with
592 several competing factors contributing, where these factors can also
593 vary by geographic region. These include:
594
595 * ISP outsourcing, including to third-party and public resolvers
596
597 * regional market domination by one or only a few ISPs
598
599 * applications directing DNS traffic by default to a limited subset
600 of resolvers (see Section 6.1.1.2)
601
602 An increased proportion of the global DNS resolution traffic being
603 served by only a few entities means that the privacy considerations
604 for users are highly dependent on the privacy policies and practices
605 of those entities. Many of the issues around centralization are
606 discussed in [centralisation-and-data-sovereignty].
607
608 6.1.1.1. Dynamic Discovery of DoH and Strict DoT
609
610 While support for opportunistic DoT can be determined by probing a
611 resolver on port 853, there is currently no standardized discovery
612 mechanism for DoH and Strict DoT servers.
613
614 This means that clients that might want to dynamically discover such
615 encrypted services, and where users are willing to trust such
616 services, are not able to do so. At the time of writing, efforts to
617 provide standardized signaling mechanisms to discover the services
618 offered by local resolvers are in progress [DNSOP-RESOLVER]. Note
619 that an increasing number of ISPs are deploying encrypted DNS; for
620 example, see the Encrypted DNS Deployment Initiative [EDDI].
621
622 6.1.1.2. Application-Specific Resolver Selection
623
624 An increasing number of applications are offering application-
625 specific encrypted DNS resolution settings, rather than defaulting to
626 using only the system resolver. A variety of heuristics and
627 resolvers are available in different applications, including hard-
628 coded lists of recognized DoH/DoT servers.
629
630 Generally, users are not aware of application-specific DNS settings
631 and may not have control over those settings. To address these
632 limitations, users will only be aware of and have the ability to
633 control such settings if applications provide the following
634 functions:
635
636 * communicate the change clearly to users when the default
637 application resolver changes away from the system resolver
638
639 * provide configuration options to change the default application
640 resolver, including a choice to always use the system resolver
641
642 * provide mechanisms for users to locally inspect, selectively
643 forward, and filter queries (either via the application itself or
644 use of the system resolver)
645
646 Application-specific changes to default destinations for users' DNS
647 queries might increase or decrease user privacy; it is highly
648 dependent on the network context and the application-specific
649 default. This is an area of active debate, and the IETF is working
650 on a number of issues related to application-specific DNS settings.
651
652 6.1.2. Active Attacks on Resolver Configuration
653
654 The previous section discussed DNS privacy, assuming that all the
655 traffic was directed to the intended servers (i.e., those that would
656 be used in the absence of an active attack) and that the potential
657 attacker was purely passive. But, in reality, there can be active
658 attackers in the network.
659
660 The Internet Threat model, as described in [RFC3552], assumes that
661 the attacker controls the network. Such an attacker can completely
662 control any insecure DNS resolution, both passively monitoring the
663 queries and responses and substituting their own responses. Even if
664 encrypted DNS such as DoH or DoT is used, unless the client has been
665 configured in a secure way with the server identity, an active
666 attacker can impersonate the server. This implies that opportunistic
667 modes of DoH/DoT as well as modes where the client learns of the DoH/
668 DoT server via in-network mechanisms such as DHCP are vulnerable to
669 attack. In addition, if the client is compromised, the attacker can
670 replace the DNS configuration with one of its own choosing.
671
672 6.1.3. Blocking of DNS Resolution Services
673
674 User privacy can also be at risk if there is blocking of access to
675 remote recursive servers that offer encrypted transports, e.g., when
676 the local resolver does not offer encryption and/or has very poor
677 privacy policies. For example, active blocking of port 853 for DoT
678 or blocking of specific IP addresses could restrict the resolvers
679 available to the user. The extent of the risk to user privacy is
680 highly dependent on the specific network and user context; a user on
681 a network that is known to perform surveillance would be compromised
682 if they could not access such services, whereas a user on a trusted
683 network might have no privacy motivation to do so.
684
685 As a matter of policy, some recursive resolvers use their position in
686 the query path to selectively block access to certain DNS records.
687 This is a form of rendezvous-based blocking as described in
688 Section 4.3 of [RFC7754]. Such blocklists often include servers
689 known to be used for malware, bots, or other security risks. In
690 order to prevent circumvention of their blocking policies, some
691 networks also block access to resolvers with incompatible policies.
692
693 It is also noted that attacks on remote resolver services, e.g.,
694 DDoS, could force users to switch to other services that do not offer
695 encrypted transports for DNS.
696
697 6.1.4. Encrypted Transports and Recursive Resolvers
698
699 6.1.4.1. DoT and DoH
700
701 Use of encrypted transports does not reduce the data available in the
702 recursive resolver and ironically can actually expose more
703 information about users to operators. As described in Section 5.2,
704 use of session-based encrypted transports (TCP/TLS) can expose
705 correlation data about users.
706
707 6.1.4.2. DoH-Specific Considerations
708
709 DoH inherits the full privacy properties of the HTTPS stack and as a
710 consequence introduces new privacy considerations when compared with
711 DNS over UDP, TCP, or TLS [RFC7858]. Section 8.2 of [RFC8484]
712 describes the privacy considerations in the server of the DoH
713 protocol.
714
715 A brief summary of some of the issues includes the following:
716
717 * HTTPS presents new considerations for correlation, such as
718 explicit HTTP cookies and implicit fingerprinting of the unique
719 set and ordering of HTTP request header fields.
720
721 * The User-Agent and Accept-Language request header fields often
722 convey specific information about the client version or locale.
723
724 * Utilizing the full set of HTTP features enables DoH to be more
725 than an HTTP tunnel, but it is at the cost of opening up
726 implementations to the full set of privacy considerations of HTTP.
727
728 * Implementations are advised to expose the minimal set of data
729 needed to achieve the desired feature set.
730
731 [RFC8484] specifically makes selection of HTTPS functionality vs.
732 privacy an implementation choice. At the extremes, there may be
733 implementations that attempt to achieve parity with DoT from a
734 privacy perspective at the cost of using no identifiable HTTP
735 headers, and there might be others that provide feature-rich data
736 flows where the low-level origin of the DNS query is easily
737 identifiable. Some implementations have, in fact, chosen to restrict
738 the use of the User-Agent header so that resolver operators cannot
739 identify the specific application that is originating the DNS
740 queries.
741
742 Privacy-focused users should be aware of the potential for additional
743 client identifiers in DoH compared to DoT and may want to only use
744 DoH client implementations that provide clear guidance on what
745 identifiers they add.
746
747 6.2. In the Authoritative Name Servers
748
749 Unlike what happens for recursive resolvers, the observation
750 capabilities of authoritative name servers are limited by caching;
751 they see only the requests for which the answer was not in the cache.
752 For aggregated statistics ("What is the percentage of LOC queries?"),
753 this is sufficient, but it prevents an observer from seeing
754 everything. Similarly, the increasing deployment of QNAME
755 minimization [ripe-qname-measurements] reduces the data visible at
756 the authoritative name server. Still, the authoritative name servers
757 see a part of the traffic, and this subset may be sufficient to
758 violate some privacy expectations.
759
760 Also, the user often has some legal/contractual link with the
761 recursive resolver (they have chosen the IAP, or they have chosen to
762 use a given public resolver) while having no control and perhaps no
763 awareness of the role of the authoritative name servers and their
764 observation abilities.
765
766 As noted before, using a local resolver or a resolver close to the
767 machine decreases the attack surface for an on-the-wire eavesdropper.
768 But it may decrease privacy against an observer located on an
769 authoritative name server. This authoritative name server will see
770 the IP address of the end client instead of the address of a big
771 recursive resolver shared by many users.
772
773 This "protection", when using a large resolver with many clients, is
774 no longer present if ECS [RFC7871] is used because, in this case, the
775 authoritative name server sees the original IP address (or prefix,
776 depending on the setup).
777
778 As of today, all the instances of one root name server, L-root,
779 receive together around 50,000 queries per second. While most of it
780 is "junk" (errors on the Top-Level Domain (TLD) name), it gives an
781 idea of the amount of big data that pours into name servers. (And
782 even "junk" can leak information; for instance, if there is a typing
783 error in the TLD, the user will send data to a TLD that is not the
784 usual one.)
785
786 Many domains, including TLDs, are partially hosted by third-party
787 servers, sometimes in a different country. The contracts between the
788 domain manager and these servers may or may not take privacy into
789 account. Whatever the contract, the third-party hoster may or may
790 not be honest; in any case, it will have to follow its local laws.
791 For example, requests to a given ccTLD may go to servers managed by
792 organizations outside of the ccTLD's country. Users may not
793 anticipate that when doing a security analysis.
794
795 Also, it seems (see the survey described in [aeris-dns]) that there
796 is a strong concentration of authoritative name servers among
797 "popular" domains (such as the Alexa Top N list). For instance,
798 among the Alexa Top 100K (https://www.alexa.com/topsites), one DNS
799 provider hosts 10% of the domains today. The ten most important DNS
800 providers together host one-third of all domains. With the control
801 (or the ability to sniff the traffic) of a few name servers, you can
802 gather a lot of information.
803
804 7. Other Risks
805
806 7.1. Re-identification and Other Inferences
807
808 An observer has access not only to the data they directly collect but
809 also to the results of various inferences about this data. The term
810 "observer" here is used very generally; for example, the observer
811 might passively observe cleartext DNS traffic or be in the network
812 that is actively attacking the user by redirecting DNS resolution, or
813 it might be a local or remote resolver operator.
814
815 For instance, a user can be re-identified via DNS queries. If the
816 adversary knows a user's identity and can watch their DNS queries for
817 a period, then that same adversary may be able to re-identify the
818 user solely based on their pattern of DNS queries later on regardless
819 of the location from which the user makes those queries. For
820 example, one study [herrmann-reidentification] found that such re-
821 identification is possible so that "73.1% of all day-to-day links
822 were correctly established, i.e. user u was either re-identified
823 unambiguously (1) or the classifier correctly reported that u was not
824 present on day t + 1 any more (2)". While that study related to web
825 browsing behavior, equally characteristic patterns may be produced
826 even in machine-to-machine communications or without a user taking
827 specific actions, e.g., at reboot time if a characteristic set of
828 services are accessed by the device.
829
830 For instance, one could imagine that an intelligence agency
831 identifies people going to a site by putting in a very long DNS name
832 and looking for queries of a specific length. Such traffic analysis
833 could weaken some privacy solutions.
834
835 The IAB Privacy and Security Program also has a document [RFC7624]
836 that considers such inference-based attacks in a more general
837 framework.
838
839 7.2. More Information
840
841 Useful background information can also be found in [tor-leak]
842 (regarding the risk of privacy leaks through DNS) and in a few
843 academic papers: [yanbin-tsudik], [castillo-garcia],
844 [fangming-hori-sakurai], and [federrath-fuchs-herrmann-piosecny].
845
846 8. Actual "Attacks"
847
848 A very quick examination of DNS traffic may lead to the false
849 conclusion that extracting the needle from the haystack is difficult.
850 "Interesting" primary DNS requests are mixed with useless (for the
851 eavesdropper) secondary and tertiary requests (see the terminology in
852 Section 1). But, in this time of "big data" processing, powerful
853 techniques now exist to get from the raw data to what the
854 eavesdropper is actually interested in.
855
856 Many research papers about malware detection use DNS traffic to
857 detect "abnormal" behavior that can be traced back to the activity of
858 malware on infected machines. Yes, this research was done for the
859 greater good, but technically it is a privacy attack and it
860 demonstrates the power of the observation of DNS traffic. See
861 [dns-footprint], [dagon-malware], and [darkreading-dns].
862
863 Passive DNS services [passive-dns] allow reconstruction of the data
864 of sometimes an entire zone. Well-known passive DNS services keep
865 only the DNS responses and not the source IP address of the client,
866 precisely for privacy reasons. Other passive DNS services may not be
867 so careful. And there are still potential problems with revealing
868 QNAMEs.
869
870 The revelations from the Edward Snowden documents, which were leaked
871 from the National Security Agency (NSA), provide evidence of the use
872 of the DNS in mass surveillance operations [morecowbell]. For
873 example, the MORECOWBELL surveillance program uses a dedicated covert
874 monitoring infrastructure to actively query DNS servers and perform
875 HTTP requests to obtain meta-information about services and to check
876 their availability. Also, the QUANTUMTHEORY
877 (https://theintercept.com/document/2014/03/12/nsa-gchqs-
878 quantumtheory-hacking-tactics/) project, which includes detecting
879 lookups for certain addresses and injecting bogus replies, is another
880 good example showing that the lack of privacy protections in the DNS
881 is actively exploited.
882
883 9. Legalities
884
885 To our knowledge, there are no specific privacy laws for DNS data in
886 any country. Interpreting general privacy laws, like the European
887 Union's [data-protection-directive] or GDPR (https://gdpr.eu/tag/
888 gdpr/), in the context of DNS traffic data is not an easy task, and
889 there is no known court precedent. See an interesting analysis in
890 [sidn-entrada].
891
892 10. Security Considerations
893
894 This document is entirely about security -- more precisely, privacy.
895 It just lays out the problem; it does not try to set requirements
896 (with the choices and compromises they imply), much less define
897 solutions. Possible solutions to the issues described here are
898 discussed in other documents (currently too many to all be
899 mentioned); see, for instance, "Recommendations for DNS Privacy
900 Operators" [RFC8932].
901
902 11. IANA Considerations
903
904 This document has no IANA actions.
905
906 12. References
907
908 12.1. Normative References
909
910 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
911 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
912 <https://www.rfc-editor.org/info/rfc1034>.
913
914 [RFC1035] Mockapetris, P., "Domain names - implementation and
915 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
916 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
917
918 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
919 Morris, J., Hansen, M., and R. Smith, "Privacy
920 Considerations for Internet Protocols", RFC 6973,
921 DOI 10.17487/RFC6973, July 2013,
922 <https://www.rfc-editor.org/info/rfc6973>.
923
924 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
925 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
926 2014, <https://www.rfc-editor.org/info/rfc7258>.
927
928 12.2. Informative References
929
930 [aeris-dns]
931 Vinot, N., "Vie privée: et le DNS alors? [Privacy: what
932 about DNS?]", February 2015,
933 <https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.
934
935 [cache-snooping-defence]
936 ISC, "DNS Cache snooping - should I be concerned?",
937 October 2018, <https://kb.isc.org/docs/aa-00482>.
938
939 [castillo-garcia]
940 Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous
941 Resolution of DNS Queries", Lecture Notes in Computer
942 Science, Vol. 5332, DOI 10.1007/978-3-540-88873-4_5, 2008,
943 <https://dl.acm.org/doi/10.1007/978-3-540-88873-4_5>.
944
945 [centralisation-and-data-sovereignty]
946 De Filippi, P. and S. McCarthy, "Cloud Computing:
947 Centralization and Data Sovereignty", European Journal of
948 Law and Technology, Vol. 3, No. 2, October 2012,
949 <https://papers.ssrn.com/sol3/
950 papers.cfm?abstract_id=2167372>.
951
952 [dagon-malware]
953 Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a
954 Malicious Resolution Authority", ISC/OARC Workshop, 2007,
955 <https://www.dns-oarc.net/files/workshop-2007/Dagon-
956 Resolution-corruption.pdf>.
957
958 [darkreading-dns]
959 Lemos, R., "Got Malware? Three Signs Revealed In DNS
960 Traffic", May 2013,
961 <https://www.darkreading.com/analytics/security-
962 monitoring/got-malware-three-signs-revealed-in-dns-
963 traffic/d/d-id/1139680>.
964
965 [data-protection-directive]
966 European Parliament, "Directive 95/46/EC of the European
967 Parliament and of the Council of 24 October 1995 on the
968 protection of individuals with regard to the processing of
969 personal data and on the free movement of such data",
970 Official Journal L 281, pp. 31-50, November 1995,
971 <https://eur-lex.europa.eu/LexUriServ/
972 LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.
973
974 [day-at-root]
975 Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A
976 Day at the Root of the Internet", ACM SIGCOMM Computer
977 Communication Review, Vol. 38, No. 5,
978 DOI 10.1145/1452335.1452341, October 2008,
979 <https://www.sigcomm.org/sites/default/files/ccr/
980 papers/2008/October/1452335-1452341.pdf>.
981
982 [denis-edns-client-subnet]
983 Denis, F., "Security and privacy issues of edns-client-
984 subnet", August 2013,
985 <https://00f.net/2013/08/07/edns-client-subnet/>.
986
987 [ditl] CAIDA, "A Day in the Life of the Internet (DITL)",
988 <https://www.caida.org/projects/ditl/>.
989
990 [dns-de-nat]
991 Orevi, L., Herzberg, A., Zlatokrilov, H., and D. Sigron,
992 "DNS-DNS: DNS-based De-NAT Scheme", January 2017,
993 <https://www.researchgate.net/publication/320322146_DNS-
994 DNS_DNS-based_De-NAT_Scheme>.
995
996 [dns-footprint]
997 Stoner, E., "DNS Footprint of Malware", OARC Workshop,
998 October 2010, <https://www.dns-oarc.net/files/workshop-
999 201010/OARC-ers-20101012.pdf>.
1000
1001 [dns-over-encryption]
1002 Lu, C., Liu, B., Li, Z., Hao, S., Duan, H., Zhang, M.,
1003 Leng, C., Liu, Y., Zhang, Z., and J. Wu, "An End-to-End,
1004 Large-Scale Measurement of DNS-over-Encryption: How Far
1005 Have We Come?", IMC '19: Proceedings of the Internet
1006 Measurement Conference, pp. 22-35,
1007 DOI 10.1145/3355369.3355580, October 2019,
1008 <https://dl.acm.org/citation.cfm?id=3355369.3355580>.
1009
1010 [dnsmezzo] Bortzmeyer, S., "DNSmezzo", <http://www.dnsmezzo.net/>.
1011
1012 [DNSOP-RESOLVER]
1013 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver
1014 Information Self-publication", Work in Progress, Internet-
1015 Draft, draft-ietf-dnsop-resolver-information-01, 11
1016 February 2020, <https://datatracker.ietf.org/doc/html/
1017 draft-ietf-dnsop-resolver-information-01>.
1018
1019 [DPRIVE-DNSOQUIC]
1020 Huitema, C., Dickinson, S., and A. Mankin, "Specification
1021 of DNS over Dedicated QUIC Connections", Work in Progress,
1022 Internet-Draft, draft-ietf-dprive-dnsoquic-03, 12 July
1023 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
1024 dprive-dnsoquic-03>.
1025
1026 [EDDI] EDDI, "Encrypted DNS Deployment Initiative",
1027 <https://www.encrypted-dns.org>.
1028
1029 [fangming-hori-sakurai]
1030 Zhao, F., Hori, Y., and K. Sakurai, "Analysis of Privacy
1031 Disclosure in DNS Query", MUE '07: Proceedings of the 2007
1032 International Conference on Multimedia and Ubiquitous
1033 Engineering, pp. 952-957, DOI 10.1109/MUE.2007.84,
1034 ISBN 0-7695-2777-9, April 2007,
1035 <https://dl.acm.org/citation.cfm?id=1262690.1262986>.
1036
1037 [federrath-fuchs-herrmann-piosecny]
1038 Federrath, H., Fuchs, K.-P., Herrmann, D., and C.
1039 Piosecny, "Privacy-Preserving DNS: Analysis of Broadcast,
1040 Range Queries and Mix-based Protection Methods", ESORICS
1041 2011, pp. 665-683, DOI 10.1007/978-3-642-23822-2_36,
1042 ISBN 978-3-642-23822-2, 2011, <https://svs.informatik.uni-
1043 hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreser
1044 vingDNS_ESORICS2011.pdf>.
1045
1046 [getdns] "getdns", <https://getdnsapi.net>.
1047
1048 [grangeia.snooping]
1049 Grangeia, L., "Cache Snooping or Snooping the Cache for
1050 Fun and Profit", 2005,
1051 <https://www.semanticscholar.org/paper/Cache-Snooping-or-
1052 Snooping-the-Cache-for-Fun-and-
1053 1-Grangeia/9b22f606e10b3609eafbdcbfc9090b63be8778c3>.
1054
1055 [herrmann-reidentification]
1056 Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
1057 "Analyzing Characteristic Host Access Patterns for Re-
1058 Identification of Web User Sessions", Lecture Notes in
1059 Computer Science, Vol. 7127,
1060 DOI 10.1007/978-3-642-27937-9_10, 2012, <https://epub.uni-
1061 regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.
1062
1063 [morecowbell]
1064 Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
1065 "NSA's MORECOWBELL: Knell for DNS", January 2015, <https:/
1066 /pdfs.semanticscholar.org/2610/2b99bdd6a258a98740af8217ba8
1067 da8a1e4fa.pdf>.
1068
1069 [packetq] DNS-OARC, "A tool that provides a basic SQL-frontend to
1070 PCAP-files", Release 1.4.3, commit 29a8288, October 2020,
1071 <https://github.com/DNS-OARC/PacketQ>.
1072
1073 [passive-dns]
1074 Weimer, F., "Passive DNS Replication", 17th Annual FIRST
1075 Conference, April 2005,
1076 <https://www.first.org/conference/2005/papers/florian-
1077 weimer-slides-1.pdf>.
1078
1079 [pitfalls-of-dns-encryption]
1080 Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
1081 Encryption", WPES '14: Proceedings of the 13th Workshop on
1082 Privacy in the Electronic Society, pp. 191-200,
1083 DOI 10.1145/2665943.2665959, November 2014,
1084 <https://dl.acm.org/citation.cfm?id=2665959>.
1085
1086 [prism] Wikipedia, "PRISM (surveillance program)", July 2015,
1087 <https://en.wikipedia.org/w/index.php?title=PRISM_(surveil
1088 lance_program)&oldid=673789455>.
1089
1090 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1091 Text on Security Considerations", BCP 72, RFC 3552,
1092 DOI 10.17487/RFC3552, July 2003,
1093 <https://www.rfc-editor.org/info/rfc3552>.
1094
1095 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1096 Rose, "DNS Security Introduction and Requirements",
1097 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1098 <https://www.rfc-editor.org/info/rfc4033>.
1099
1100 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
1101 and DNSSEC On-line Signing", RFC 4470,
1102 DOI 10.17487/RFC4470, April 2006,
1103 <https://www.rfc-editor.org/info/rfc4470>.
1104
1105 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
1106 Security (DNSSEC) Hashed Authenticated Denial of
1107 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
1108 <https://www.rfc-editor.org/info/rfc5155>.
1109
1110 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
1111 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
1112 <https://www.rfc-editor.org/info/rfc5936>.
1113
1114 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
1115 P. Roberts, "Issues with IP Address Sharing", RFC 6269,
1116 DOI 10.17487/RFC6269, June 2011,
1117 <https://www.rfc-editor.org/info/rfc6269>.
1118
1119 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
1120 for DNS (EDNS(0))", STD 75, RFC 6891,
1121 DOI 10.17487/RFC6891, April 2013,
1122 <https://www.rfc-editor.org/info/rfc6891>.
1123
1124 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
1125 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
1126 <https://www.rfc-editor.org/info/rfc7413>.
1127
1128 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
1129 "Recommendations for Secure Use of Transport Layer
1130 Security (TLS) and Datagram Transport Layer Security
1131 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
1132 2015, <https://www.rfc-editor.org/info/rfc7525>.
1133
1134 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
1135 Trammell, B., Huitema, C., and D. Borkmann,
1136 "Confidentiality in the Face of Pervasive Surveillance: A
1137 Threat Model and Problem Statement", RFC 7624,
1138 DOI 10.17487/RFC7624, August 2015,
1139 <https://www.rfc-editor.org/info/rfc7624>.
1140
1141 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
1142 DOI 10.17487/RFC7626, August 2015,
1143 <https://www.rfc-editor.org/info/rfc7626>.
1144
1145 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
1146 Considerations for IPv6 Address Generation Mechanisms",
1147 RFC 7721, DOI 10.17487/RFC7721, March 2016,
1148 <https://www.rfc-editor.org/info/rfc7721>.
1149
1150 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
1151 Nordmark, "Technical Considerations for Internet Service
1152 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
1153 March 2016, <https://www.rfc-editor.org/info/rfc7754>.
1154
1155 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
1156 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
1157 <https://www.rfc-editor.org/info/rfc7816>.
1158
1159 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1160 and P. Hoffman, "Specification for DNS over Transport
1161 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1162 2016, <https://www.rfc-editor.org/info/rfc7858>.
1163
1164 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
1165 Kumari, "Client Subnet in DNS Queries", RFC 7871,
1166 DOI 10.17487/RFC7871, May 2016,
1167 <https://www.rfc-editor.org/info/rfc7871>.
1168
1169 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
1170 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
1171 <https://www.rfc-editor.org/info/rfc7873>.
1172
1173 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
1174 (DANE) Bindings for OpenPGP", RFC 7929,
1175 DOI 10.17487/RFC7929, August 2016,
1176 <https://www.rfc-editor.org/info/rfc7929>.
1177
1178 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1179 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1180 <https://www.rfc-editor.org/info/rfc8446>.
1181
1182 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1183 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1184 <https://www.rfc-editor.org/info/rfc8484>.
1185
1186 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1187 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
1188 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
1189
1190 [RFC8744] Huitema, C., "Issues and Requirements for Server Name
1191 Identification (SNI) Encryption in TLS", RFC 8744,
1192 DOI 10.17487/RFC8744, July 2020,
1193 <https://www.rfc-editor.org/info/rfc8744>.
1194
1195 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
1196 DOI 10.17487/RFC8890, August 2020,
1197 <https://www.rfc-editor.org/info/rfc8890>.
1198
1199 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
1200 A. Mankin, "Recommendations for DNS Privacy Service
1201 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
1202 October 2020, <https://www.rfc-editor.org/info/rfc8932>.
1203
1204 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
1205 Multiplexed and Secure Transport", RFC 9000,
1206 DOI 10.17487/RFC9000, May 2021,
1207 <https://www.rfc-editor.org/info/rfc9000>.
1208
1209 [ripe-qname-measurements]
1210 de Vries, W., "Making the DNS More Private with QNAME
1211 Minimisation", April 2019,
1212 <https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-
1213 bit-more-private-with-qname-minimisation>.
1214
1215 [sidn-entrada]
1216 Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.
1217 Simon, "A privacy framework for 'DNS big data'
1218 applications", November 2014,
1219 <https://www.sidnlabs.nl/downloads/
1220 yBW6hBoaSZe4m6GJc_0b7w/2211058ab6330c7f3788141ea19d3db7/
1221 SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.
1222
1223 [thomas-ditl-tcp]
1224 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in
1225 Root Server DITL Data", DNS-OARC 2014 Fall Workshop,
1226 October 2014, <https://indico.dns-
1227 oarc.net/event/20/session/2/contribution/15/material/
1228 slides/1.pdf>.
1229
1230 [tor-leak] Tor, "Tor FAQs: I keep seeing these warnings about SOCKS
1231 and DNS information leaks. Should I worry?",
1232 <https://www.torproject.org/docs/
1233 faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.
1234
1235 [yanbin-tsudik]
1236 Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks
1237 in Domain Name System", June 2010,
1238 <https://arxiv.org/abs/0910.2472>.
1239
1240 Appendix A. Updates since RFC 7626
1241
1242 Many references were updated. Discussions of encrypted transports,
1243 including DoT and DoH, and sections on DNS payload, authentication of
1244 servers, and blocking of services were added. With the publishing of
1245 [RFC7816] on QNAME minimization, text, references, and initial
1246 attempts to measure deployment were added to reflect this. The text
1247 and references on the Snowden revelations were updated.
1248
1249 The "Risks Overview" section was changed to "Scope" to help clarify
1250 the risks being considered. Text on cellular network DNS, blocking,
1251 and security was added. Considerations for recursive resolvers were
1252 collected and placed together. A discussion on resolver selection
1253 was added.
1254
1255 Acknowledgments
1256
1257 Thanks to Nathalie Boulvard and to the CENTR members for the original
1258 work that led to this document. Thanks to Ondrej Sury for the
1259 interesting discussions. Thanks to Mohsen Souissi and John Heidemann
1260 for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,
1261 Francis Dupont, Allison Mankin, and Warren Kumari for proofreading,
1262 providing technical remarks, and making many readability
1263 improvements. Thanks to Dan York, Suzanne Woolf, Tony Finch, Stephen
1264 Farrell, Peter Koch, Simon Josefsson, and Frank Denis for good
1265 written contributions. Thanks to Vittorio Bertola and Mohamed
1266 Boucadair for a detailed review of the -bis. And thanks to the IESG
1267 members for the last remarks.
1268
1269 Contributions
1270
1271 Sara Dickinson and Stephane Bortzmeyer were the original authors of
1272 the document, and their contribution to the initial draft of this
1273 document is greatly appreciated.
1274
1275 Author's Address
1276
1277 Tim Wicinski (editor)
1278 Elkins, WV 26241
1279 United States of America
1280
1281 Email: tjw.ietf@gmail.com
1282
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.