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/