idnits 2.17.1
draft-ietf-dprive-problem-statement-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 23, 2015) is 3293 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 715
== Outdated reference: A later version (-08) exists of
draft-ietf-dnsop-edns-client-subnet-00
== Outdated reference: A later version (-07) exists of
draft-iab-privsec-confidentiality-threat-04
== Outdated reference: A later version (-09) exists of
draft-ietf-dnsop-qname-minimisation-02
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DNS PRIVate Exchange (dprive) Working Group S. Bortzmeyer
3 Internet-Draft AFNIC
4 Intended status: Informational March 23, 2015
5 Expires: September 24, 2015
7 DNS privacy considerations
8 draft-ietf-dprive-problem-statement-04
10 Abstract
12 This document describes the privacy issues associated with the use of
13 the DNS by Internet users. It is intended to be an analysis of the
14 present situation and does not prescribe solutions.
16 Status of This Memo
18 This Internet-Draft is submitted in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF). Note that other groups may also distribute
23 working documents as Internet-Drafts. The list of current Internet-
24 Drafts is at http://datatracker.ietf.org/drafts/current/.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 This Internet-Draft will expire on September 24, 2015.
33 Copyright Notice
35 Copyright (c) 2015 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
51 2. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
52 2.1. The alleged public nature of DNS data . . . . . . . . . . 4
53 2.2. Data in the DNS request . . . . . . . . . . . . . . . . . 5
54 2.3. Cache snooping . . . . . . . . . . . . . . . . . . . . . 6
55 2.4. On the wire . . . . . . . . . . . . . . . . . . . . . . . 6
56 2.5. In the servers . . . . . . . . . . . . . . . . . . . . . 8
57 2.5.1. In the recursive resolvers . . . . . . . . . . . . . 8
58 2.5.2. In the authoritative name servers . . . . . . . . . . 8
59 2.5.3. Rogue servers . . . . . . . . . . . . . . . . . . . . 9
60 2.6. Re-identification and other inferences . . . . . . . . . 10
61 3. Actual "attacks" . . . . . . . . . . . . . . . . . . . . . . 10
62 4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 11
63 5. Security considerations . . . . . . . . . . . . . . . . . . . 11
64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
65 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
67 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
68 8.2. Informative References . . . . . . . . . . . . . . . . . 12
69 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
72 1. Introduction
74 This document is an analysis of the DNS privacy issues, in the spirit
75 of section 8 of [RFC6973].
77 The Domain Name System is specified in [RFC1034] and [RFC1035]. It
78 is one of the most important infrastructure components of the
79 Internet and often ignored or misunderstood. Almost every activity
80 on the Internet starts with a DNS query (and often several). Its use
81 has many privacy implications and this is an attempt at a
82 comprehensive and accurate list.
84 Let us begin with a simplified reminder of how the DNS works. (See
85 also [I-D.hoffman-dns-terminology].) A client, the stub resolver,
86 issues a DNS query to a server, called the recursive resolver (also
87 called caching resolver or full resolver or recursive name server).
88 Let's use the query "What are the AAAA records for www.example.com?"
89 as an example. AAAA is the qtype (Query Type), and www.example.com
90 is the qname (Query Name). (The description which follows assume a
91 cold cache, for instance because the server just started.) The
92 recursive resolver will first query the root nameservers. In most
93 cases, the root nameservers will send a referral. In this example,
94 the referral will be to the .com nameservers. The resolver repeats
95 the query to one of the .com nameservers. The .com nameservers, in
96 turn, will refer to the example.com nameservers. The example.com
97 nameserver will then return the answer. The root name servers, the
98 name servers of .com and the name servers of example.com are called
99 authoritative name servers. It is important, when analyzing the
100 privacy issues, to remember that the question asked to all these name
101 servers is always the original question, not a derived question. The
102 question sent to the root name servers is "What are the AAAA records
103 for www.example.com?", not "What are the name servers of .com?". By
104 repeating the full question, instead of just the relevant part of the
105 question to the next in line, the DNS provides more information than
106 necessary to the nameserver.
108 Because DNS relies on caching heavily, the algorithm described just
109 above is actually a bit more complicated, and not all questions are
110 sent to the authoritative name servers. If a few seconds later the
111 stub resolver asks to the recursive resolver, "What are the SRV
112 records of _xmpp-server._tcp.example.com?", the recursive resolver
113 will remember that it knows the name servers of example.com and will
114 just query them, bypassing the root and .com. Because there is
115 typically no caching in the stub resolver, the recursive resolver,
116 unlike the authoritative servers, sees all the DNS traffic.
117 (Applications, like Web browsers, may have some form of caching which
118 do not follow DNS rules, for instance because it may ignore the TTL.
119 So, the recursive resolver does not see all the name resolution
120 activity.)
122 It should be noted that DNS recursive resolvers sometimes forward
123 requests to other recursive resolvers, typically bigger machines,
124 with a larger and more shared cache (and the query hierarchy can be
125 even deeper, with more than two levels of recursive resolvers). From
126 the point of view of privacy, these forwarders are like resolvers,
127 except that they do not see all of the requests being made (due to
128 caching in the first resolver).
130 All this DNS traffic is currently sent in clear (unencrypted), except
131 a few cases when the IP traffic is protected, for instance in an
132 IPsec VPN.
134 Today, almost all DNS queries are sent over UDP. This has practical
135 consequences when considering encryption of the traffic as a possible
136 privacy technique. Some encryption solutions are only designed for
137 TCP, not UDP.
139 Another important point to keep in mind when analyzing the privacy
140 issues of DNS is the mix of many sort of DNS requests received by a
141 server. Let's assume an eavesdropper wants to know which Web page is
142 viewed by an user. For a typical Web page, there are three sorts of
143 DNS requests being issued:
145 Primary request: this is the domain name in the URL that the user
146 typed, selected from a bookmark or chose by clicking on an
147 hyperlink. Presumably, this is what is of interest for the
148 eavesdropper.
150 Secondary requests: these are the additional requests performed by
151 the user agent (here, the Web browser) without any direct
152 involvement or knowledge of the user. For the Web, they are
153 triggered by embedded content, CSS sheets, JavaScript code,
154 embedded images, etc. In some cases, there can be dozens of
155 domain names in different contexts on a single Web page.
157 Tertiary requests: these are the additional requests performed by
158 the DNS system itself. For instance, if the answer to a query is
159 a referral to a set of name servers, and the glue records are not
160 returned, the resolver will have to do additional requests to turn
161 name servers' names into IP addresses. Similarly, even if glue
162 records are returned, a careful recursive server will do tertiary
163 requests to verify the IP addresses of those records.
165 It can be noted also that, in the case of a typical Web browser, more
166 DNS requests are sent, for instance to prefetch resources that the
167 user may query later, or when autocompleting the URL in the address
168 bar (which obviously is a big privacy concern).
170 For privacy-related terms, we will use here the terminology of
171 [RFC6973].
173 2. Risks
175 This document focuses mostly on the study of privacy risks for the
176 end-user (the one performing DNS requests). We consider the risks of
177 pervasive surveillance ([RFC7258]) as well as risks coming from a
178 more focused surveillance. Privacy risks for the holder of a zone
179 (the risk that someone gets the data) are discussed in [RFC5936] and
180 [RFC5155]. Non-privacy risks (such as cache poisoning) are out of
181 scope.
183 2.1. The alleged public nature of DNS data
185 It has long been claimed that "the data in the DNS is public". While
186 this sentence makes sense for an Internet-wide lookup system, there
187 are multiple facets to the data and metadata involved that deserve a
188 more detailed look. First, access control lists and private
189 namespaces nonwithstanding, the DNS operates under the assumption
190 that public facing authoritative name servers will respond to "usual"
191 DNS queries for any zone they are authoritative for without further
192 authentication or authorization of the client (resolver). Due to the
193 lack of search capabilities, only a given qname will reveal the
194 resource records associated with that name (or that name's non-
195 existence). In other words: one needs to know what to ask for, in
196 order to receive a response. The zone transfer qtype [RFC5936] is
197 often blocked or restricted to authenticated/authorized access to
198 enforce this difference (and maybe for other, more dubious reasons).
200 Another differentiation to be considered is between the DNS data
201 itself and a particular transaction (i.e., a DNS name lookup). DNS
202 data and the results of a DNS query are public, within the boundaries
203 described above, and may not have any confidentiality requirements.
204 However, the same is not true of a single transaction or sequence of
205 transactions; that transaction is not/should not be public. A
206 typical example from outside the DNS world is: the Web site of
207 Alcoholics Anonymous is public; the fact that you visit it should not
208 be.
210 2.2. Data in the DNS request
212 The DNS request includes many fields but two of them seem
213 particularly relevant for the privacy issues: the qname and the
214 source IP address. "source IP address" is used in a loose sense of
215 "source IP address + maybe source port", because the port is also in
216 the request and can be used to sort out several users sharing an IP
217 address (behind a CGN for instance [RFC6269]).
219 The qname is the full name sent by the user. It gives information
220 about what the user does ("What are the MX records of example.net?"
221 means he probably wants to send email to someone at example.net,
222 which may be a domain used by only a few persons and therefore very
223 revealing about communication relationships). Some qnames are more
224 sensitive than others. For instance, querying the A record of
225 google-analytics.com reveals very little (everybody visits Web sites
226 which use Google Analytics) but querying the A record of
227 www.verybad.example where verybad.example is the domain of an
228 organization that some people find offensive or objectionable, may
229 create more problems for the user. Also, sometimes, the qname embeds
230 the software one uses, which could be a privacy issue. For instance,
231 _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
232 There are also some BitTorrent clients that query a SRV record for
233 _bittorrent-tracker._tcp.domain.example.
235 Another important thing about the privacy of the qname is the future
236 usages. Today, the lack of privacy is an obstacle to putting
237 potentially sensitive or personally identifiable data in the DNS. At
238 the moment your DNS traffic might reveal that you are doing email but
239 not with whom. If your MUA starts looking up PGP keys in the DNS
240 [I-D.wouters-dane-openpgp] then privacy becomes a lot more important.
242 And email is just an example; there would be other really interesting
243 uses for a more privacy-friendly DNS.
245 For the communication between the stub resolver and the recursive
246 resolver, the source IP address is the address of the user's machine.
247 Therefore, all the issues and warnings about collection of IP
248 addresses apply here. For the communication between the recursive
249 resolver and the authoritative name servers, the source IP address
250 has a different meaning; it does not have the same status as the
251 source address in a HTTP connection. It is now the IP address of the
252 recursive resolver which, in a way "hides" the real user. However,
253 hiding does not always work. Sometimes
254 [I-D.ietf-dnsop-edns-client-subnet] is used (see its privacy analysis
255 in [denis-edns-client-subnet]). Sometimes the end user has a
256 personal recursive resolver on her machine. In both cases, the IP
257 address is as sensitive as it is for HTTP.
259 A note about IP addresses: there is currently no IETF document which
260 describes in detail all the privacy issues around IP addressing. In
261 the meantime, the discussion here is intended to include both IPv4
262 and IPv6 source addresses. For a number of reasons their assignment
263 and utilization characteristics are different, which may have
264 implications for details of information leakage associated with the
265 collection of source addresses. (For example, a specific IPv6 source
266 address seen on the public Internet is less likely than an IPv4
267 address to originate behind a CGN or other NAT.) However, for both
268 IPv4 and IPv6 addresses, it's important to note that source addresses
269 are propagated with queries and comprise metadata about the host,
270 user, or application that originated them.
272 2.3. Cache snooping
274 The content of recursive resolvers' caches can reveal data about the
275 clients using it (the privacy risks depend on the number of clients).
276 This information can sometimes be examined by sending DNS queries
277 with RD=0 to inspect cache content, particularly looking at the DNS
278 TTLs. Since this also is a reconnaissance technique for subsequent
279 cache poisoning attacks, some counter measures have already been
280 developed and deployed.
282 2.4. On the wire
284 DNS traffic can be seen by an eavesdropper like any other traffic.
285 It is typically not encrypted. (DNSSEC, specified in [RFC4033]
286 explicitly excludes confidentiality from its goals.) So, if an
287 initiator starts a HTTPS communication with a recipient, while the
288 HTTP traffic will be encrypted, the DNS exchange prior to it will not
289 be. When other protocols will become more and more privacy-aware and
290 secured against surveillance, the DNS risks to become "the weakest
291 link" in privacy.
293 An important specificity of the DNS traffic is that it may take a
294 different path than the communication between the initiator and the
295 recipient. For instance, an eavesdropper may be unable to tap the
296 wire between the initiator and the recipient but may have access to
297 the wire going to the recursive resolver, or to the authoritative
298 name servers.
300 The best place to tap, from an eavesdropper's point of view, is
301 clearly between the stub resolvers and the recursive resolvers,
302 because traffic is not limited by DNS caching.
304 The attack surface between the stub resolver and the rest of the
305 world can vary widely depending upon how the end user's computer is
306 configured. By order of increasing attack surface:
308 The recursive resolver can be on the end user's computer. In
309 (currently) a small number of cases, individuals may choose to
310 operate their own DNS resolver on their local machine. In this case
311 the attack surface for the connection between the stub resolver and
312 the caching resolver is limited to that single machine.
314 The recursive resolver may be at the local network edge. For many/
315 most enterprise networks and for some residential users the caching
316 resolver may exist on a server at the edge of the local network. In
317 this case the attack surface is the local network. Note that in
318 large enterprise networks the DNS resolver may not be located at the
319 edge of the local network but rather at the edge of the overall
320 enterprise network. In this case the enterprise network could be
321 thought of as similar to the IAP network referenced below.
323 The recursive resolver can be in the IAP (Internet Access Provider)
324 premises. For most residential users and potentially other networks
325 the typical case is for the end user's computer to be configured
326 (typically automatically through DHCP) with the addresses of the DNS
327 recursive resolvers at the IAP. The attack surface for on-the-wire
328 attacks is therefore from the end user system across the local
329 network and across the IAP network to the IAP's recursive resolvers.
331 The recursive resolver can be a public DNS service. Some machines
332 may be configured to use public DNS resolvers such as those operated
333 by Google Public DNS or OpenDNS. The end user may have configured
334 their machine to use these DNS recursive resolvers themselves - or
335 their IAP may have chosen to use the public DNS resolvers rather than
336 operating their own resolvers. In this case the attack surface is
337 the entire public Internet between the end user's connection and the
338 public DNS service.
340 2.5. In the servers
342 Using the terminology of [RFC6973], the DNS servers (recursive
343 resolvers and authoritative servers) are enablers: they facilitate
344 communication between an initiator and a recipient without being
345 directly in the communications path. As a result, they are often
346 forgotten in risk analysis. But, to quote again [RFC6973], "Although
347 [...] enablers may not generally be considered as attackers, they may
348 all pose privacy threats (depending on the context) because they are
349 able to observe, collect, process, and transfer privacy-relevant
350 data." In [RFC6973] parlance, enablers become observers when they
351 start collecting data.
353 Many programs exist to collect and analyze DNS data at the servers.
354 From the "query log" of some programs like BIND, to tcpdump and more
355 sophisticated programs like PacketQ [packetq] and DNSmezzo
356 [dnsmezzo]. The organization managing the DNS server can use these
357 data itself or it can be part of a surveillance program like PRISM
358 [prism] and pass data to an outside observer.
360 Sometimes, these data are kept for a long time and/or distributed to
361 third parties, for research purposes [ditl] [day-at-root], for
362 security analysis, or for surveillance tasks. These uses are
363 sometimes under some sort of contract, with various limitations, for
364 instance on redistribution, giving the sensitive nature of the data.
365 Also, there are observation points in the network which gather DNS
366 data and then make it accessible to third-parties for research or
367 security purposes ("passive DNS [passive-dns]").
369 2.5.1. In the recursive resolvers
371 Recursive Resolvers see all the traffic since there is typically no
372 caching before them. To summarize: your recursive resolver knows a
373 lot about you. The resolver of a large IAP, or a large public
374 resolver can collect data from many users. You may get an idea of
375 the data collected by reading the privacy policy of a big public
376 resolver [1].
378 2.5.2. In the authoritative name servers
380 Unlike what happens for recursive resolvers, observation capabilities
381 of authoritative name servers are limited by caching; they see only
382 the requests for which the answer was not in the cache. For
383 aggregated statistics ("What is the percentage of LOC queries?"),
384 this is sufficient; but it prevents an observer from seeing
385 everything. Still, the authoritative name servers see a part of the
386 traffic, and this subset may be sufficient to violate some privacy
387 expectations.
389 Also, the end user has typically some legal/contractual link with the
390 recursive resolver (he has chosen the IAP, or he has chosen to use a
391 given public resolver), while having no control and perhaps no
392 awareness of the role of the authoritative name servers and their
393 observation abilities.
395 As noted before, using a local resolver or a resolver close to the
396 machine decreases the attack surface for an on-the-wire eavesdropper.
397 But it may decrease privacy against an observer located on an
398 authoritative name server. This authoritative name server will see
399 the IP address of the end client, instead of the address of a big
400 recursive resolver shared by many users.
402 This "protection", when using a large resolver with many clients, is
403 no longer present if [I-D.ietf-dnsop-edns-client-subnet] is used
404 because, in this case, the authoritative name server sees the
405 original IP address (or prefix, depending on the setup).
407 As of today, all the instances of one root name server, L-root,
408 receive together around 20,000 queries per second. While most of it
409 is junk (errors on the TLD name), it gives an idea of the amount of
410 big data which pours into name servers.
412 Many domains, including TLDs, are partially hosted by third-party
413 servers, sometimes in a different country. The contracts between the
414 domain manager and these servers may or may not take privacy into
415 account. Whatever the contract, the third-party hoster may be honest
416 or not but, in any case, it will have to follow its local laws. It
417 may be surprising for an end-user that requests to a given ccTLD may
418 go to servers managed by organisations outside of the country.
420 Also, it seems [aeris-dns] that there is a strong concentration of
421 authoritative name servers among "popular" domains (such as the Alexa
422 Top N list). For instance, among the Alexa Top 100k, one DNS
423 provider hosts today 10 % of the domains. The ten most important DNS
424 providers host together one third of the domains. With the control
425 (or the ability to sniff the traffic) of a few name servers, you can
426 gather a lot of information.
428 2.5.3. Rogue servers
430 A rogue DHCP server, or a trusted DHCP server that has had its
431 configuration altered by malicious parties, can direct you to a rogue
432 recursive resolver. Most of the time, it seems to be done to divert
433 traffic, by providing lies for some domain names. But it could be
434 used just to capture the traffic and gather information about you.
435 Same thing for malware like DNSchanger [dnschanger] which changes the
436 recursive resolver in the machine's configuration, or with
437 transparent DNS proxies in the network that will divert the traffic
438 intended for a legitimate DNS server (for instance
439 [turkey-googledns]).
441 2.6. Re-identification and other inferences
443 An observer has access not only to the data he/she directly collects
444 but also to the results of various inferences about these data.
446 For instance, an user can be re-identified via DNS queries. If the
447 adversary knows a user's identity and can watch their DNS queries for
448 a period, then that same adversary may be able to re-identify the
449 user solely based on their pattern of DNS queries later on regardless
450 of the location from which the user makes those queries. For
451 example, one study [herrmann-reidentification] found that such re-
452 identification is possible so that "73.1% of all day-to-day links
453 were correctly established, i.e. user u was either re-identified
454 unambiguously (1) or the classifier correctly reported that u was not
455 present on day t+1 any more (2)". While that study related to web
456 browsing behaviour, equally characteristic patterns may be produced
457 even in machine-to-machine communications or without a user taking
458 specific actions, e.g. at reboot time if a characteristic set of
459 services are accessed by the device.
461 The IAB privacy and security programme also have a work in progress
462 [I-D.iab-privsec-confidentiality-threat] that considers such
463 inference based attacks in a more general framework.
465 3. Actual "attacks"
467 A very quick examination of DNS traffic may lead to the false
468 conclusion that extracting the needle from the haystack is difficult.
469 "Interesting" primary DNS requests are mixed with useless (for the
470 eavesdropper) secondary and tertiary requests (see the terminology in
471 Section 1). But, in this time of "big data" processing, powerful
472 techniques now exist to get from the raw data to what the
473 eavesdropper is actually interested in.
475 Many research papers about malware detection use DNS traffic to
476 detect "abnormal" behaviour that can be traced back to the activity
477 of malware on infected machines. Yes, this research was done for the
478 good; but, technically, it is a privacy attack and it demonstrates
479 the power of the observation of DNS traffic. See [dns-footprint],
480 [dagon-malware] and [darkreading-dns].
482 Passive DNS systems [passive-dns] allow reconstruction of the data of
483 sometimes an entire zone. They are used for many reasons, some good,
484 some bad. Well-known passive DNS systems keep only the DNS
485 responses, and not the source IP address of the client, precisely for
486 privacy reasons. Other passive DNS systems may not be so careful.
487 And there is still the potential problems with revealing qnames.
489 The revelations (from the Edward Snowden documents, leaked from the
490 NSA) of the MORECOWBELL surveillance program [morecowbell], which
491 uses the DNS, both passively and actively, to gather surreptitiously
492 information about the users, is another good example that the lack of
493 privacy protections in the DNS is actively exploited.
495 4. Legalities
497 To our knowledge, there are no specific privacy laws for DNS data, in
498 any country. Interpreting general privacy laws like
499 [data-protection-directive] (European Union) in the context of DNS
500 traffic data is not an easy task and it seems there is no court
501 precedent here.
503 5. Security considerations
505 This document is entirely about security, more precisely privacy. It
506 just lays out the problem, it does not try to set requirements (with
507 the choices and compromises they imply), much less to define
508 solutions. A possible document on requirments for DNS privacy is
509 [I-D.hallambaker-dnse]. Possible solutions to the issues described
510 here are discussed in other documents (currently too many to all be
511 mentioned), see for instance [I-D.ietf-dnsop-qname-minimisation] for
512 the minimisation of data, or [I-D.hzhwm-start-tls-for-dns] about
513 encryption.
515 6. Acknowledgments
517 Thanks to Nathalie Boulvard and to the CENTR members for the original
518 work which leaded to this document. Thanks to Ondrej Sury for the
519 interesting discussions. Thanks to Mohsen Souissi and John Heidemann
520 for proofreading, to Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim
521 Wicinski, Francis Dupont, Allison Mankin and Warren Kumari for
522 proofreading, technical remarks, and many readability improvements.
523 Thanks to Dan York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter
524 Koch and Frank Denis for good written contributions.
526 7. IANA considerations
528 This document has no actions for IANA.
530 8. References
532 8.1. Normative References
534 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
535 STD 13, RFC 1034, November 1987.
537 [RFC1035] Mockapetris, P., "Domain names - implementation and
538 specification", STD 13, RFC 1035, November 1987.
540 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
541 Morris, J., Hansen, M., and R. Smith, "Privacy
542 Considerations for Internet Protocols", RFC 6973, July
543 2013.
545 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
546 Attack", BCP 188, RFC 7258, May 2014.
548 8.2. Informative References
550 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
551 Rose, "DNS Security Introduction and Requirements", RFC
552 4033, March 2005.
554 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
555 Security (DNSSEC) Hashed Authenticated Denial of
556 Existence", RFC 5155, March 2008.
558 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
559 (AXFR)", RFC 5936, June 2010.
561 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
562 Roberts, "Issues with IP Address Sharing", RFC 6269, June
563 2011.
565 [I-D.ietf-dnsop-edns-client-subnet]
566 Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,
567 "Client Subnet in DNS Requests", draft-ietf-dnsop-edns-
568 client-subnet-00 (work in progress), November 2014.
570 [I-D.iab-privsec-confidentiality-threat]
571 Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
572 Trammell, B., Huitema, C., and D. Borkmann,
573 "Confidentiality in the Face of Pervasive Surveillance: A
574 Threat Model and Problem Statement", draft-iab-privsec-
575 confidentiality-threat-04 (work in progress), March 2015.
577 [I-D.hallambaker-dnse]
578 Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases
579 and Requirements.", draft-hallambaker-dnse-02 (work in
580 progress), November 2014.
582 [I-D.wouters-dane-openpgp]
583 Wouters, P., "Using DANE to Associate OpenPGP public keys
584 with email addresses", draft-wouters-dane-openpgp-02 (work
585 in progress), February 2014.
587 [I-D.hzhwm-start-tls-for-dns]
588 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D.
589 Wessels, "Starting TLS over DNS", draft-hzhwm-start-tls-
590 for-dns-01 (work in progress), July 2014.
592 [I-D.ietf-dnsop-qname-minimisation]
593 Bortzmeyer, S., "DNS query name minimisation to improve
594 privacy", draft-ietf-dnsop-qname-minimisation-02 (work in
595 progress), March 2015.
597 [I-D.hoffman-dns-terminology]
598 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
599 Terminology", draft-hoffman-dns-terminology-02 (work in
600 progress), March 2015.
602 [dprive] IETF, DPRIVE., "The DPRIVE working group", March 2014,
603 .
605 [denis-edns-client-subnet]
606 Denis, F., "Security and privacy issues of edns-client-
607 subnet", August 2013, .
610 [dagon-malware]
611 Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a
612 Malicious Resolution Authority", 2007, .
616 [dns-footprint]
617 Stoner, E., "DNS footprint of malware", October 2010,
618 .
621 [morecowbell]
622 Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
623 "NSA's MORECOWBELL: Knell for DNS", January 2015,
624 .
626 [darkreading-dns]
627 Lemos, R., "Got Malware? Three Signs Revealed In DNS
628 Traffic", May 2013,
629 .
632 [dnschanger]
633 Wikipedia, , "DNSchanger", November 2011,
634 .
636 [packetq] Dot SE, , "PacketQ, a simple tool to make SQL-queries
637 against PCAP-files", 2011,
638 .
640 [dnsmezzo]
641 Bortzmeyer, S., "DNSmezzo", 2009,
642 .
644 [prism] NSA, , "PRISM", 2007, .
647 [ditl] CAIDA, , "A Day in the Life of the Internet (DITL)", 2002,
648 .
650 [day-at-root]
651 Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A
652 Day at the Root of the Internet", 2008,
653 .
656 [turkey-googledns]
657 Bortzmeyer, S., "Hijacking of public DNS servers in
658 Turkey, through routing", 2014,
659 .
662 [data-protection-directive]
663 Europe, , "European directive 95/46/EC on the protection
664 of individuals with regard to the processing of personal
665 data and on the free movement of such data", November
666 1995, .
669 [passive-dns]
670 Weimer, F., "Passive DNS Replication", April 2005,
671 .
673 [tor-leak]
674 Tor, , "DNS leaks in Tor", 2013,
675 .
679 [yanbin-tsudik]
680 Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks
681 in the Domain Name System", 2009,
682 .
684 [castillo-garcia]
685 Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous
686 Resolution of DNS Queries", 2008,
687 .
689 [fangming-hori-sakurai]
690 Fangming, , Hori, Y., and K. Sakurai, "Analysis of Privacy
691 Disclosure in DNS Query", 2007,
692 .
694 [federrath-fuchs-herrmann-piosecny]
695 Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny,
696 "Privacy-Preserving DNS: Analysis of Broadcast, Range
697 Queries and Mix-Based Protection Methods", 2011,
698 .
701 [aeris-dns]
702 Vinot, N., "[In French] Vie privee : et le DNS alors ?",
703 2015, .
706 [herrmann-reidentification]
707 Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
708 "Analyzing characteristic host access patterns for re-
709 identification of web user sessions", 2012,
710 .
713 8.3. URIs
715 [1] https://developers.google.com/speed/public-dns/privacy
717 Author's Address
719 Stephane Bortzmeyer
720 AFNIC
721 1, rue Stephenson
722 Montigny-le-Bretonneux 78180
723 France
725 Phone: +33 1 39 30 83 46
726 Email: bortzmeyer+ietf@nic.fr
727 URI: http://www.afnic.fr/