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