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/