draft-ietf-dprive-problem-statement-06.txt		rfc7626.txt
	DNS PRIVate Exchange (dprive) Working Group S. Bortzmeyer		Internet Engineering Task Force (IETF) S. Bortzmeyer
	Internet-Draft AFNIC		Request for Comments: 7626 AFNIC
	Intended status: Informational June 15, 2015		Category: Informational August 2015
	Expires: December 17, 2015		ISSN: 2070-1721
	DNS privacy considerations		DNS Privacy Considerations
	draft-ietf-dprive-problem-statement-06
	Abstract		Abstract
	This document describes the privacy issues associated with the use of		This document describes the privacy issues associated with the use of
	the DNS by Internet users. It is intended to be an analysis of the		the DNS by Internet users. It is intended to be an analysis of the
	present situation and does not prescribe solutions.		present situation and does not prescribe solutions.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on December 17, 2015.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7626.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. The alleged public nature of DNS data . . . . . . . . . . 5		2.1. The Alleged Public Nature of DNS Data . . . . . . . . . . 4
	2.2. Data in the DNS request . . . . . . . . . . . . . . . . . 5		2.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 5
	2.3. Cache snooping . . . . . . . . . . . . . . . . . . . . . 6		2.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 6
	2.4. On the wire . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 7
	2.5. In the servers . . . . . . . . . . . . . . . . . . . . . 8		2.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 8
	2.5.1. In the recursive resolvers . . . . . . . . . . . . . 9		2.5.1. In the Recursive Resolvers . . . . . . . . . . . . . 8
	2.5.2. In the authoritative name servers . . . . . . . . . . 9		2.5.2. In the Authoritative Name Servers . . . . . . . . . . 9
	2.5.3. Rogue servers . . . . . . . . . . . . . . . . . . . . 10		2.5.3. Rogue Servers . . . . . . . . . . . . . . . . . . . . 10
	2.6. Re-identification and other inferences . . . . . . . . . 11		2.6. Re-identification and Other Inferences . . . . . . . . . 11
	3. Actual "attacks" . . . . . . . . . . . . . . . . . . . . . . 11		2.7. More Information . . . . . . . . . . . . . . . . . . . . 11
			3. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 11
	4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Security considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12		6.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.2. Informative References . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . 13
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document is an analysis of the DNS privacy issues, in the spirit		This document is an analysis of the DNS privacy issues, in the spirit
	of section 8 of [RFC6973].		of Section 8 of [RFC6973].
	The Domain Name System is specified in [RFC1034] and [RFC1035] and		The Domain Name System is specified in [RFC1034], [RFC1035], and many
	many later RFCs, which have never been consolidated. It is one of		later RFCs, which have never been consolidated. It is one of the
	the most important infrastructure components of the Internet and		most important infrastructure components of the Internet and often
	often ignored or misunderstood by Internet users (and even by many		ignored or misunderstood by Internet users (and even by many
	professionals). Almost every activity on the Internet starts with a		professionals). Almost every activity on the Internet starts with a
	DNS query (and often several). Its use has many privacy implications		DNS query (and often several). Its use has many privacy implications
	and this is an attempt at a comprehensive and accurate list.		and this is an attempt at a comprehensive and accurate list.
	Let us begin with a simplified reminder of how the DNS works. (See		Let us begin with a simplified reminder of how the DNS works. (See
	also [I-D.ietf-dnsop-dns-terminology].) A client, the stub resolver,		also [DNS-TERMS].) A client, the stub resolver, issues a DNS query
	issues a DNS query to a server, called the recursive resolver (also		to a server, called the recursive resolver (also called caching
	called caching resolver or full resolver or recursive name server).		resolver or full resolver or recursive name server). Let's use the
	Let's use the query "What are the AAAA records for www.example.com?"		query "What are the AAAA records for www.example.com?" as an example.
	as an example. AAAA is the QTYPE (Query Type), and www.example.com		AAAA is the QTYPE (Query Type), and www.example.com is the QNAME
	is the QNAME (Query Name). (The description which follows assumes a		(Query Name). (The description that follows assumes a cold cache,
	cold cache, for instance because the server just started.) The		for instance, because the server just started.) The recursive
	recursive resolver will first query the root nameservers. In most		resolver will first query the root name servers. In most cases, the
	cases, the root nameservers will send a referral. In this example,		root name servers will send a referral. In this example, the
	the referral will be to the .com nameservers. The resolver repeats		referral will be to the .com name servers. The resolver repeats the
	the query to one of the .com nameservers. The .com nameservers, in		query to one of the .com name servers. The .com name servers, in
	turn, will refer to the example.com nameservers. The example.com		turn, will refer to the example.com name servers. The example.com
	nameserver will then return the answer. The root name servers, the		name server will then return the answer. The root name servers, the
	name servers of .com and the name servers of example.com are called		name servers of .com, and the name servers of example.com are called
	authoritative name servers. It is important, when analyzing the		authoritative name servers. It is important, when analyzing the
	privacy issues, to remember that the question asked to all these name		privacy issues, to remember that the question asked to all these name
	servers is always the original question, not a derived question. The		servers is always the original question, not a derived question. The
	question sent to the root name servers is "What are the AAAA records		question sent to the root name servers is "What are the AAAA records
	for www.example.com?", not "What are the name servers of .com?". By		for www.example.com?", not "What are the name servers of .com?". By
	repeating the full question, instead of just the relevant part of the		repeating the full question, instead of just the relevant part of the
	question to the next in line, the DNS provides more information than		question to the next in line, the DNS provides more information than
	necessary to the nameserver.		necessary to the name server.
	Because DNS relies on caching heavily, the algorithm described just		Because DNS relies on caching heavily, the algorithm described just
	above is actually a bit more complicated, and not all questions are		above is actually a bit more complicated, and not all questions are
	sent to the authoritative name servers. If a few seconds later the		sent to the authoritative name servers. If a few seconds later the
	stub resolver asks to the recursive resolver, "What are the SRV		stub resolver asks the recursive resolver, "What are the SRV records
	records of _xmpp-server._tcp.example.com?", the recursive resolver		of _xmpp-server._tcp.example.com?", the recursive resolver will
	will remember that it knows the name servers of example.com and will		remember that it knows the name servers of example.com and will just
	just query them, bypassing the root and .com. Because there is		query them, bypassing the root and .com. Because there is typically
	typically no caching in the stub resolver, the recursive resolver,		no caching in the stub resolver, the recursive resolver, unlike the
	unlike the authoritative servers, sees all the DNS traffic.		authoritative servers, sees all the DNS traffic. (Applications, like
	(Applications, like Web browsers, may have some form of caching which		web browsers, may have some form of caching that does not follow DNS
	do not follow DNS rules, for instance because it may ignore the TTL.		rules, for instance, because it may ignore the TTL. So, the
	So, the recursive resolver does not see all the name resolution		recursive resolver does not see all the name resolution activity.)
	activity.)
	It should be noted that DNS recursive resolvers sometimes forward		It should be noted that DNS recursive resolvers sometimes forward
	requests to other recursive resolvers, typically bigger machines,		requests to other recursive resolvers, typically bigger machines,
	with a larger and more shared cache (and the query hierarchy can be		with a larger and more shared cache (and the query hierarchy can be
	even deeper, with more than two levels of recursive resolvers). From		even deeper, with more than two levels of recursive resolvers). From
	the point of view of privacy, these forwarders are like resolvers,		the point of view of privacy, these forwarders are like resolvers,
	except that they do not see all of the requests being made (due to		except that they do not see all of the requests being made (due to
	caching in the first resolver).		caching in the first resolver).
	Almost all this DNS traffic is currently sent in clear (unencrypted).		Almost all this DNS traffic is currently sent in clear (unencrypted).
	There are a few cases where there is some channel encryption, for		There are a few cases where there is some channel encryption, for
	instance in an IPsec VPN, at least between the stub resolver and the		instance, in an IPsec VPN, at least between the stub resolver and the
	resolver.		resolver.
	Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].		Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
	This has practical consequences when considering encryption of the		This has practical consequences when considering encryption of the
	traffic as a possible privacy technique. Some encryption solutions		traffic as a possible privacy technique. Some encryption solutions
	are only designed for TCP, not UDP.		are only designed for TCP, not UDP.
	Another important point to keep in mind when analyzing the privacy		Another important point to keep in mind when analyzing the privacy
	issues of DNS is the fact that DNS requests received by a server were		issues of DNS is the fact that DNS requests received by a server are
	triggered by different reasons. Let's assume an eavesdropper wants		triggered by different reasons. Let's assume an eavesdropper wants
	to know which Web page is viewed by a user. For a typical Web page,		to know which web page is viewed by a user. For a typical web page,
	there are three sorts of DNS requests being issued:		there are three sorts of DNS requests being issued:
	Primary request: this is the domain name in the URL that the user		Primary request: this is the domain name in the URL that the user
	typed, selected from a bookmark or chose by clicking on an		typed, selected from a bookmark, or chose by clicking on an
	hyperlink. Presumably, this is what is of interest for the		hyperlink. Presumably, this is what is of interest for the
	eavesdropper.		eavesdropper.
	Secondary requests: these are the additional requests performed by		Secondary requests: these are the additional requests performed by
	the user agent (here, the Web browser) without any direct		the user agent (here, the web browser) without any direct
	involvement or knowledge of the user. For the Web, they are		involvement or knowledge of the user. For the Web, they are
	triggered by embedded content, CSS sheets, JavaScript code,		triggered by embedded content, Cascading Style Sheets (CSS),
	embedded images, etc. In some cases, there can be dozens of		JavaScript code, embedded images, etc. In some cases, there can
	domain names in different contexts on a single Web page.		be dozens of domain names in different contexts on a single web
			page.
	Tertiary requests: these are the additional requests performed by		Tertiary requests: these are the additional requests performed by
	the DNS system itself. For instance, if the answer to a query is		the DNS system itself. For instance, if the answer to a query is
	a referral to a set of name servers, and the glue records are not		a referral to a set of name servers, and the glue records are not
	returned, the resolver will have to do additional requests to turn		returned, the resolver will have to do additional requests to turn
	name servers' names into IP addresses. Similarly, even if glue		the name servers' names into IP addresses. Similarly, even if
	records are returned, a careful recursive server will do tertiary		glue records are returned, a careful recursive server will do
	requests to verify the IP addresses of those records.		tertiary requests to verify the IP addresses of those records.
	It can be noted also that, in the case of a typical Web browser, more		It can be noted also that, in the case of a typical web browser, more
	DNS requests than stricly necessary are sent, for instance to		DNS requests than strictly necessary are sent, for instance, to
	prefetch resources that the user may query later, or when		prefetch resources that the user may query later or when
	autocompleting the URL in the address bar. Both are a big privacy		autocompleting the URL in the address bar. Both are a big privacy
	concern since they may leak information even about non-explicit		concern since they may leak information even about non-explicit
	actions. For instance, just reading a local HTML page, even without		actions. For instance, just reading a local HTML page, even without
	selecting the hyperlinks, may trigger DNS requests.		selecting the hyperlinks, may trigger DNS requests.
	For privacy-related terms, we will use here the terminology of		For privacy-related terms, we will use the terminology from
	[RFC6973].		[RFC6973].
	2. Risks		2. Risks
	This document focuses mostly on the study of privacy risks for the		This document focuses mostly on the study of privacy risks for the
	end-user (the one performing DNS requests). We consider the risks of		end user (the one performing DNS requests). We consider the risks of
	pervasive surveillance ([RFC7258]) as well as risks coming from a		pervasive surveillance [RFC7258] as well as risks coming from a more
	more focused surveillance. Privacy risks for the holder of a zone		focused surveillance. Privacy risks for the holder of a zone (the
	(the risk that someone gets the data) are discussed in [RFC5936] and		risk that someone gets the data) are discussed in [RFC5936] and
	[RFC5155]. Non-privacy risks (such as cache poisoning) are out of		[RFC5155]. Non-privacy risks (such as cache poisoning) are out of
	scope.		scope.
	2.1. The alleged public nature of DNS data		2.1. The Alleged Public Nature of DNS Data
	It has long been claimed that "the data in the DNS is public". While		It has long been claimed that "the data in the DNS is public". While
	this sentence makes sense for an Internet-wide lookup system, there		this sentence makes sense for an Internet-wide lookup system, there
	are multiple facets to the data and metadata involved that deserve a		are multiple facets to the data and metadata involved that deserve a
	more detailed look. First, access control lists and private		more detailed look. First, access control lists and private
	namespaces nonwithstanding, the DNS operates under the assumption		namespaces notwithstanding, the DNS operates under the assumption
	that public facing authoritative name servers will respond to "usual"		that public-facing authoritative name servers will respond to "usual"
	DNS queries for any zone they are authoritative for without further		DNS queries for any zone they are authoritative for without further
	authentication or authorization of the client (resolver). Due to the		authentication or authorization of the client (resolver). Due to the
	lack of search capabilities, only a given QNAME will reveal the		lack of search capabilities, only a given QNAME will reveal the
	resource records associated with that name (or that name's non-		resource records associated with that name (or that name's non-
	existence). In other words: one needs to know what to ask for, in		existence). In other words: one needs to know what to ask for, in
	order to receive a response. The zone transfer QTYPE [RFC5936] is		order to receive a response. The zone transfer QTYPE [RFC5936] is
	often blocked or restricted to authenticated/authorized access to		often blocked or restricted to authenticated/authorized access to
	enforce this difference (and maybe for other reasons).		enforce this difference (and maybe for other reasons).
	Another differentiation to be considered is between the DNS data		Another differentiation to be considered is between the DNS data
	itself and a particular transaction (i.e., a DNS name lookup). DNS		itself and a particular transaction (i.e., a DNS name lookup). DNS
	data and the results of a DNS query are public, within the boundaries		data and the results of a DNS query are public, within the boundaries
	described above, and may not have any confidentiality requirements.		described above, and may not have any confidentiality requirements.
	However, the same is not true of a single transaction or sequence of		However, the same is not true of a single transaction or a sequence
	transactions; that transaction is not/should not be public. A		of transactions; that transaction is not / should not be public. A
	typical example from outside the DNS world is: the Web site of		typical example from outside the DNS world is: the web site of
	Alcoholics Anonymous is public; the fact that you visit it should not		Alcoholics Anonymous is public; the fact that you visit it should not
	be.		be.
	2.2. Data in the DNS request		2.2. Data in the DNS Request
	The DNS request includes many fields but two of them seem		The DNS request includes many fields, but two of them seem
	particularly relevant for the privacy issues: the QNAME and the		particularly relevant for the privacy issues: the QNAME and the
	source IP address. "source IP address" is used in a loose sense of		source IP address. "source IP address" is used in a loose sense of
	"source IP address + maybe source port", because the port is also in		"source IP address + maybe source port", because the port is also in
	the request and can be used to differentiate between several users		the request and can be used to differentiate between several users
	sharing an IP address (behind a CGN for instance [RFC6269]).		sharing an IP address (behind a Carrier-Grade NAT (CGN), for instance
			[RFC6269]).
	The QNAME is the full name sent by the user. It gives information		The QNAME is the full name sent by the user. It gives information
	about what the user does ("What are the MX records of example.net?"		about what the user does ("What are the MX records of example.net?"
	means he probably wants to send email to someone at example.net,		means he probably wants to send email to someone at example.net,
	which may be a domain used by only a few persons and therefore very		which may be a domain used by only a few persons and is therefore
	revealing about communication relationships). Some QNAMEs are more		very revealing about communication relationships). Some QNAMEs are
	sensitive than others. For instance, querying the A record of a		more sensitive than others. For instance, querying the A record of a
	well-known Web statistics domain reveals very little (everybody		well-known web statistics domain reveals very little (everybody
	visits Web sites which use this analytics service) but querying the A		visits web sites that use this analytics service), but querying the A
	record of www.verybad.example where verybad.example is the domain of		record of www.verybad.example where verybad.example is the domain of
	an organization that some people find offensive or objectionable, may		an organization that some people find offensive or objectionable may
	create more problems for the user. Also, sometimes, the QNAME embeds		create more problems for the user. Also, sometimes, the QNAME embeds
	the software one uses, which could be a privacy issue. For instance,		the software one uses, which could be a privacy issue. For instance,
	_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.		_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
	There are also some BitTorrent clients that query a SRV record for		There are also some BitTorrent clients that query an SRV record for
	_bittorrent-tracker._tcp.domain.example.		_bittorrent-tracker._tcp.domain.example.
	Another important thing about the privacy of the QNAME is the future		Another important thing about the privacy of the QNAME is the future
	usages. Today, the lack of privacy is an obstacle to putting		usages. Today, the lack of privacy is an obstacle to putting
	potentially sensitive or personally identifiable data in the DNS. At		potentially sensitive or personally identifiable data in the DNS. At
	the moment your DNS traffic might reveal that you are doing email but		the moment, your DNS traffic might reveal that you are doing email
	not with whom. If your MUA starts looking up PGP keys in the DNS		but not with whom. If your Mail User Agent (MUA) starts looking up
	[I-D.wouters-dane-openpgp] then privacy becomes a lot more important.		Pretty Good Privacy (PGP) keys in the DNS [DANE-OPENPGPKEY], then
	And email is just an example; there would be other really interesting		privacy becomes a lot more important. And email is just an example;
	uses for a more privacy-friendly DNS.		there would be other really interesting uses for a more privacy-
			friendly DNS.
	For the communication between the stub resolver and the recursive		For the communication between the stub resolver and the recursive
	resolver, the source IP address is the address of the user's machine.		resolver, the source IP address is the address of the user's machine.
	Therefore, all the issues and warnings about collection of IP		Therefore, all the issues and warnings about collection of IP
	addresses apply here. For the communication between the recursive		addresses apply here. For the communication between the recursive
	resolver and the authoritative name servers, the source IP address		resolver and the authoritative name servers, the source IP address
	has a different meaning; it does not have the same status as the		has a different meaning; it does not have the same status as the
	source address in a HTTP connection. It is now the IP address of the		source address in an HTTP connection. It is now the IP address of
	recursive resolver which, in a way "hides" the real user. However,		the recursive resolver that, in a way, "hides" the real user.
	hiding does not always work. Sometimes		However, hiding does not always work. Sometimes [CLIENT-SUBNET] is
	[I-D.ietf-dnsop-edns-client-subnet] is used (see its privacy analysis		used (see its privacy analysis in [denis-edns-client-subnet]).
	in [denis-edns-client-subnet]). Sometimes the end user has a		Sometimes the end user has a personal recursive resolver on her
	personal recursive resolver on her machine. In both cases, the IP		machine. In both cases, the IP address is as sensitive as it is for
	address is as sensitive as it is for HTTP [sidn-entrada].		HTTP [sidn-entrada].
	A note about IP addresses: there is currently no IETF document which		A note about IP addresses: there is currently no IETF document that
	describes in detail all the privacy issues around IP addressing. In		describes in detail all the privacy issues around IP addressing. In
	the meantime, the discussion here is intended to include both IPv4		the meantime, the discussion here is intended to include both IPv4
	and IPv6 source addresses. For a number of reasons their assignment		and IPv6 source addresses. For a number of reasons, their assignment
	and utilization characteristics are different, which may have		and utilization characteristics are different, which may have
	implications for details of information leakage associated with the		implications for details of information leakage associated with the
	collection of source addresses. (For example, a specific IPv6 source		collection of source addresses. (For example, a specific IPv6 source
	address seen on the public Internet is less likely than an IPv4		address seen on the public Internet is less likely than an IPv4
	address to originate behind a CGN or other NAT.) However, for both		address to originate behind a CGN or other NAT.) However, for both
	IPv4 and IPv6 addresses, it's important to note that source addresses		IPv4 and IPv6 addresses, it's important to note that source addresses
	are propagated with queries and comprise metadata about the host,		are propagated with queries and comprise metadata about the host,
	user, or application that originated them.		user, or application that originated them.
	2.3. Cache snooping		2.3. Cache Snooping
	The content of recursive resolvers' caches can reveal data about the		The content of recursive resolvers' caches can reveal data about the
	clients using it (the privacy risks depend on the number of clients).		clients using it (the privacy risks depend on the number of clients).
	This information can sometimes be examined by sending DNS queries		This information can sometimes be examined by sending DNS queries
	with RD=0 to inspect cache content, particularly looking at the DNS		with RD=0 to inspect cache content, particularly looking at the DNS
	TTLs [grangeia.snooping]. Since this also is a reconnaissance		TTLs [grangeia.snooping]. Since this also is a reconnaissance
	technique for subsequent cache poisoning attacks, some counter		technique for subsequent cache poisoning attacks, some counter
	measures have already been developed and deployed.		measures have already been developed and deployed.
	2.4. On the wire		2.4. On the Wire
	DNS traffic can be seen by an eavesdropper like any other traffic.		DNS traffic can be seen by an eavesdropper like any other traffic.
	It is typically not encrypted. (DNSSEC, specified in [RFC4033]		It is typically not encrypted. (DNSSEC, specified in [RFC4033],
	explicitly excludes confidentiality from its goals.) So, if an		explicitly excludes confidentiality from its goals.) So, if an
	initiator starts a HTTPS communication with a recipient, while the		initiator starts an HTTPS communication with a recipient, while the
	HTTP traffic will be encrypted, the DNS exchange prior to it will not		HTTP traffic will be encrypted, the DNS exchange prior to it will not
	be. When other protocols will become more and more privacy-aware and		be. When other protocols will become more and more privacy-aware and
	secured against surveillance, the DNS may become "the weakest link"		secured against surveillance, the DNS may become "the weakest link"
	in privacy.		in privacy.
	An important specificity of the DNS traffic is that it may take a		An important specificity of the DNS traffic is that it may take a
	different path than the communication between the initiator and the		different path than the communication between the initiator and the
	recipient. For instance, an eavesdropper may be unable to tap the		recipient. For instance, an eavesdropper may be unable to tap the
	wire between the initiator and the recipient but may have access to		wire between the initiator and the recipient but may have access to
	the wire going to the recursive resolver, or to the authoritative		the wire going to the recursive resolver, or to the authoritative
	skipping to change at page 7, line 36		skipping to change at page 7, line 34
	clearly between the stub resolvers and the recursive resolvers,		clearly between the stub resolvers and the recursive resolvers,
	because traffic is not limited by DNS caching.		because traffic is not limited by DNS caching.
	The attack surface between the stub resolver and the rest of the		The attack surface between the stub resolver and the rest of the
	world can vary widely depending upon how the end user's computer is		world can vary widely depending upon how the end user's computer is
	configured. By order of increasing attack surface:		configured. By order of increasing attack surface:
	The recursive resolver can be on the end user's computer. In		The recursive resolver can be on the end user's computer. In
	(currently) a small number of cases, individuals may choose to		(currently) a small number of cases, individuals may choose to
	operate their own DNS resolver on their local machine. In this		operate their own DNS resolver on their local machine. In this
	case the attack surface for the connection between the stub		case, the attack surface for the connection between the stub
	resolver and the caching resolver is limited to that single		resolver and the caching resolver is limited to that single
	machine.		machine.
	The recursive resolver may be at the local network edge. For		The recursive resolver may be at the local network edge. For
	many/most enterprise networks and for some residential users the		many/most enterprise networks and for some residential users, the
	caching resolver may exist on a server at the edge of the local		caching resolver may exist on a server at the edge of the local
	network. In this case the attack surface is the local network.		network. In this case, the attack surface is the local network.
	Note that in large enterprise networks the DNS resolver may not be		Note that in large enterprise networks, the DNS resolver may not
	located at the edge of the local network but rather at the edge of		be located at the edge of the local network but rather at the edge
	the overall enterprise network. In this case the enterprise		of the overall enterprise network. In this case, the enterprise
	network could be thought of as similar to the IAP (Internet Access		network could be thought of as similar to the Internet Access
	Provider) network referenced below.		Provider (IAP) network referenced below.
	The recursive resolver can be in the IAP (Internet Access		The recursive resolver can be in the IAP premises. For most
	Provider) premises. For most residential users and potentially		residential users and potentially other networks, the typical case
	other networks the typical case is for the end user's computer to		is for the end user's computer to be configured (typically
	be configured (typically automatically through DHCP) with the		automatically through DHCP) with the addresses of the DNS
	addresses of the DNS recursive resolvers at the IAP. The attack		recursive resolvers at the IAP. The attack surface for on-the-
	surface for on-the-wire attacks is therefore from the end user		wire attacks is therefore from the end-user system across the
	system across the local network and across the IAP network to the		local network and across the IAP network to the IAP's recursive
	IAP's recursive resolvers.		resolvers.
	The recursive resolver can be a public DNS service. Some machines		The recursive resolver can be a public DNS service. Some machines
	may be configured to use public DNS resolvers such as those		may be configured to use public DNS resolvers such as those
	operated today by Google Public DNS or OpenDNS. The end user may		operated today by Google Public DNS or OpenDNS. The end user may
	have configured their machine to use these DNS recursive resolvers		have configured their machine to use these DNS recursive resolvers
	themselves - or their IAP may have chosen to use the public DNS		themselves -- or their IAP may have chosen to use the public DNS
	resolvers rather than operating their own resolvers. In this case		resolvers rather than operating their own resolvers. In this
	the attack surface is the entire public Internet between the end		case, the attack surface is the entire public Internet between the
	user's connection and the public DNS service.		end user's connection and the public DNS service.
	2.5. In the servers		2.5. In the Servers
	Using the terminology of [RFC6973], the DNS servers (recursive		Using the terminology of [RFC6973], the DNS servers (recursive
	resolvers and authoritative servers) are enablers: they facilitate		resolvers and authoritative servers) are enablers: they facilitate
	communication between an initiator and a recipient without being		communication between an initiator and a recipient without being
	directly in the communications path. As a result, they are often		directly in the communications path. As a result, they are often
	forgotten in risk analysis. But, to quote again [RFC6973], "Although		forgotten in risk analysis. But, to quote again [RFC6973], "Although
	[...] enablers may not generally be considered as attackers, they may		[...] enablers may not generally be considered as attackers, they may
	all pose privacy threats (depending on the context) because they are		all pose privacy threats (depending on the context) because they are
	able to observe, collect, process, and transfer privacy-relevant		able to observe, collect, process, and transfer privacy-relevant
	data." In [RFC6973] parlance, enablers become observers when they		data." In [RFC6973] parlance, enablers become observers when they
	start collecting data.		start collecting data.
	Many programs exist to collect and analyze DNS data at the servers.		Many programs exist to collect and analyze DNS data at the servers --
	From the "query log" of some programs like BIND, to tcpdump and more		from the "query log" of some programs like BIND to tcpdump and more
	sophisticated programs like PacketQ [packetq] and DNSmezzo		sophisticated programs like PacketQ [packetq] [packetq-list] and
	[dnsmezzo]. The organization managing the DNS server can use these		DNSmezzo [dnsmezzo]. The organization managing the DNS server can
	data itself or it can be part of a surveillance program like PRISM		use this data itself, or it can be part of a surveillance program
	[prism] and pass data to an outside observer.		like PRISM [prism] and pass data to an outside observer.
	Sometimes, these data are kept for a long time and/or distributed to		Sometimes, this data is kept for a long time and/or distributed to
	third parties, for research purposes [ditl] [day-at-root], for		third parties for research purposes [ditl] [day-at-root], security
	security analysis, or for surveillance tasks. These uses are		analysis, or surveillance tasks. These uses are sometimes under some
	sometimes under some sort of contract, with various limitations, for		sort of contract, with various limitations, for instance, on
	instance on redistribution, giving the sensitive nature of the data.		redistribution, given the sensitive nature of the data. Also, there
	Also, there are observation points in the network which gather DNS		are observation points in the network that gather DNS data and then
	data and then make it accessible to third-parties for research or		make it accessible to third parties for research or security purposes
	security purposes ("passive DNS [passive-dns]").		("passive DNS" [passive-dns]).
	2.5.1. In the recursive resolvers		2.5.1. In the Recursive Resolvers
	Recursive Resolvers see all the traffic since there is typically no		Recursive Resolvers see all the traffic since there is typically no
	caching before them. To summarize: your recursive resolver knows a		caching before them. To summarize: your recursive resolver knows a
	lot about you. The resolver of a large IAP, or a large public		lot about you. The resolver of a large IAP, or a large public
	resolver can collect data from many users. You may get an idea of		resolver, can collect data from many users. You may get an idea of
	the data collected by reading the privacy policy of a big public		the data collected by reading the privacy policy of a big public
	resolver [1].		resolver, e.g., <https://developers.google.com/speed/public-dns/
			privacy>.
	2.5.2. In the authoritative name servers		2.5.2. In the Authoritative Name Servers
	Unlike what happens for recursive resolvers, observation capabilities		Unlike what happens for recursive resolvers, observation capabilities
	of authoritative name servers are limited by caching; they see only		of authoritative name servers are limited by caching; they see only
	the requests for which the answer was not in the cache. For		the requests for which the answer was not in the cache. For
	aggregated statistics ("What is the percentage of LOC queries?"),		aggregated statistics ("What is the percentage of LOC queries?"),
	this is sufficient; but it prevents an observer from seeing		this is sufficient, but it prevents an observer from seeing
	everything. Still, the authoritative name servers see a part of the		everything. Still, the authoritative name servers see a part of the
	traffic, and this subset may be sufficient to violate some privacy		traffic, and this subset may be sufficient to violate some privacy
	expectations.		expectations.
	Also, the end user has typically some legal/contractual link with the		Also, the end user typically has some legal/contractual link with the
	recursive resolver (he has chosen the IAP, or he has chosen to use a		recursive resolver (he has chosen the IAP, or he has chosen to use a
	given public resolver), while having no control and perhaps no		given public resolver), while having no control and perhaps no
	awareness of the role of the authoritative name servers and their		awareness of the role of the authoritative name servers and their
	observation abilities.		observation abilities.
	As noted before, using a local resolver or a resolver close to the		As noted before, using a local resolver or a resolver close to the
	machine decreases the attack surface for an on-the-wire eavesdropper.		machine decreases the attack surface for an on-the-wire eavesdropper.
	But it may decrease privacy against an observer located on an		But it may decrease privacy against an observer located on an
	authoritative name server. This authoritative name server will see		authoritative name server. This authoritative name server will see
	the IP address of the end client, instead of the address of a big		the IP address of the end client instead of the address of a big
	recursive resolver shared by many users.		recursive resolver shared by many users.
	This "protection", when using a large resolver with many clients, is		This "protection", when using a large resolver with many clients, is
	no longer present if [I-D.ietf-dnsop-edns-client-subnet] is used		no longer present if [CLIENT-SUBNET] is used because, in this case,
	because, in this case, the authoritative name server sees the		the authoritative name server sees the original IP address (or
	original IP address (or prefix, depending on the setup).		prefix, depending on the setup).
	As of today, all the instances of one root name server, L-root,		As of today, all the instances of one root name server, L-root,
	receive together around 50,000 queries per second. While most of it		receive together around 50,000 queries per second. While most of it
	is "junk" (errors on the TLD name), it gives an idea of the amount of		is "junk" (errors on the Top-Level Domain (TLD) name), it gives an
	big data which pours into name servers. (And even "junk" can leak		idea of the amount of big data that pours into name servers. (And
	information, for instance if there is a typing error in the TLD, the		even "junk" can leak information; for instance, if there is a typing
	user will send data to a TLD which is not the usual one.)		error in the TLD, the user will send data to a TLD that is not the
			usual one.)
	Many domains, including TLDs, are partially hosted by third-party		Many domains, including TLDs, are partially hosted by third-party
	servers, sometimes in a different country. The contracts between the		servers, sometimes in a different country. The contracts between the
	domain manager and these servers may or may not take privacy into		domain manager and these servers may or may not take privacy into
	account. Whatever the contract, the third-party hoster may be honest		account. Whatever the contract, the third-party hoster may be honest
	or not but, in any case, it will have to follow its local laws. So,		or not but, in any case, it will have to follow its local laws. So,
	requests to a given ccTLD may go to servers managed by organizations		requests to a given ccTLD may go to servers managed by organizations
	outside of the ccTLD's country. End-users may not anticipate that,		outside of the ccTLD's country. End users may not anticipate that,
	when doing a security analysis.		when doing a security analysis.
	Also, it seems [aeris-dns] that there is a strong concentration of		Also, it seems (see the survey described in [aeris-dns]) that there
	authoritative name servers among "popular" domains (such as the Alexa		is a strong concentration of authoritative name servers among
	Top N list). For instance, among the Alexa Top 100k, one DNS		"popular" domains (such as the Alexa Top N list). For instance,
	provider hosts today 10 % of the domains. The ten most important DNS		among the Alexa Top 100K, one DNS provider hosts today 10% of the
	providers host together one third of the domains. With the control		domains. The ten most important DNS providers host together one
	(or the ability to sniff the traffic) of a few name servers, you can		third of the domains. With the control (or the ability to sniff the
	gather a lot of information.		traffic) of a few name servers, you can gather a lot of information.
	2.5.3. Rogue servers		2.5.3. Rogue Servers
	The previous paragraphs discussed DNS privacy, assuming that all the		The previous paragraphs discussed DNS privacy, assuming that all the
	traffic was directed to the intended servers, and that the potential		traffic was directed to the intended servers and that the potential
	attacker was purely passive. But, in reality, we can have active		attacker was purely passive. But, in reality, we can have active
	attackers, redirecting the traffic, not for changing it but just to		attackers redirecting the traffic, not to change it but just to
	observe it.		observe it.
	For instance, a rogue DHCP server, or a trusted DHCP server that has		For instance, a rogue DHCP server, or a trusted DHCP server that has
	had its configuration altered by malicious parties, can direct you to		had its configuration altered by malicious parties, can direct you to
	a rogue recursive resolver. Most of the time, it seems to be done to		a rogue recursive resolver. Most of the time, it seems to be done to
	divert traffic, by providing lies for some domain names. But it		divert traffic by providing lies for some domain names. But it could
	could be used just to capture the traffic and gather information		be used just to capture the traffic and gather information about you.
	about you. Other attacks, besides using DHCP, are possible. The		Other attacks, besides using DHCP, are possible. The traffic from a
	traffic from a DNS client to a DNS server can be intercepted along		DNS client to a DNS server can be intercepted along its way from
	its way from originator to intended source; for instance by		originator to intended source, for instance, by transparent DNS
	transparent DNS proxies in the network that will divert the traffic		proxies in the network that will divert the traffic intended for a
	intended for a legitimate DNS server. This rogue server can		legitimate DNS server. This rogue server can masquerade as the
	masquerade as the intended server and respond with data to the		intended server and respond with data to the client. (Rogue servers
	client. (Rogue servers that inject malicious data are possible, but		that inject malicious data are possible, but it is a separate problem
	is a separate problem not relevant to privacy.) A rogue server may		not relevant to privacy.) A rogue server may respond correctly for a
	respond correctly for a long period of time, thereby foregoing		long period of time, thereby foregoing detection. This may be done
	detection. This may be done for what could be claimed to be good		for what could be claimed to be good reasons, such as optimization or
	reasons, such as optimization or caching, but it leads to a reduction		caching, but it leads to a reduction of privacy compared to if there
	of privacy compared to if there were no attacker present. Also,		was no attacker present. Also, malware like DNSchanger [dnschanger]
	malware like DNSchanger [dnschanger] can change the recursive		can change the recursive resolver in the machine's configuration, or
	resolver in the machine's configuration, or the routing itself can be		the routing itself can be subverted (for instance,
	subverted (for instance [turkey-googledns]).		[ripe-atlas-turkey]).
	A practical consequence of this section is that solutions for DNS		A practical consequence of this section is that solutions for DNS
	privacy may have to address authentication of the server, not just		privacy may have to address authentication of the server, not just
	passive sniffing.		passive sniffing.
	2.6. Re-identification and other inferences		2.6. Re-identification and Other Inferences
	An observer has access not only to the data he/she directly collects		An observer has access not only to the data he/she directly collects
	but also to the results of various inferences about these data.		but also to the results of various inferences about this data.
	For instance, a user can be re-identified via DNS queries. If the		For instance, a user can be re-identified via DNS queries. If the
	adversary knows a user's identity and can watch their DNS queries for		adversary knows a user's identity and can watch their DNS queries for
	a period, then that same adversary may be able to re-identify the		a period, then that same adversary may be able to re-identify the
	user solely based on their pattern of DNS queries later on regardless		user solely based on their pattern of DNS queries later on regardless
	of the location from which the user makes those queries. For		of the location from which the user makes those queries. For
	example, one study [herrmann-reidentification] found that such re-		example, one study [herrmann-reidentification] found that such re-
	identification is possible so that "73.1% of all day-to-day links		identification is possible so that "73.1% of all day-to-day links
	were correctly established, i.e. user u was either re-identified		were correctly established, i.e. user u was either re-identified
	unambiguously (1) or the classifier correctly reported that u was not		unambiguously (1) or the classifier correctly reported that u was not
	present on day t+1 any more (2)". While that study related to web		present on day t+1 any more (2)." While that study related to web
	browsing behaviour, equally characteristic patterns may be produced		browsing behavior, equally characteristic patterns may be produced
	even in machine-to-machine communications or without a user taking		even in machine-to-machine communications or without a user taking
	specific actions, e.g. at reboot time if a characteristic set of		specific actions, e.g., at reboot time if a characteristic set of
	services are accessed by the device.		services are accessed by the device.
	For instance, one could imagine, for an intelligence agency to		For instance, one could imagine that an intelligence agency
	identify people going to a site by putting in a very long DNS name		identifies people going to a site by putting in a very long DNS name
	and looking for queries of a specific length. Such traffic analysis		and looking for queries of a specific length. Such traffic analysis
	could weaken some privacy solutions.		could weaken some privacy solutions.
	The IAB privacy and security programme also have a work in progress		The IAB privacy and security program also have a work in progress
	[I-D.iab-privsec-confidentiality-threat] that considers such		[RFC7624] that considers such inference-based attacks in a more
	inference based attacks in a more general framework.		general framework.
	3. Actual "attacks"		2.7. More Information
			Useful background information can also be found in [tor-leak] (about
			the risk of privacy leak through DNS) and in a few academic papers:
			[yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and
			[federrath-fuchs-herrmann-piosecny].
			3. Actual "Attacks"
	A very quick examination of DNS traffic may lead to the false		A very quick examination of DNS traffic may lead to the false
	conclusion that extracting the needle from the haystack is difficult.		conclusion that extracting the needle from the haystack is difficult.
	"Interesting" primary DNS requests are mixed with useless (for the		"Interesting" primary DNS requests are mixed with useless (for the
	eavesdropper) secondary and tertiary requests (see the terminology in		eavesdropper) secondary and tertiary requests (see the terminology in
	Section 1). But, in this time of "big data" processing, powerful		Section 1). But, in this time of "big data" processing, powerful
	techniques now exist to get from the raw data to what the		techniques now exist to get from the raw data to what the
	eavesdropper is actually interested in.		eavesdropper is actually interested in.
	Many research papers about malware detection use DNS traffic to		Many research papers about malware detection use DNS traffic to
	detect "abnormal" behaviour that can be traced back to the activity		detect "abnormal" behavior that can be traced back to the activity of
	of malware on infected machines. Yes, this research was done for the		malware on infected machines. Yes, this research was done for the
	good; but, technically, it is a privacy attack and it demonstrates		good, but technically it is a privacy attack and it demonstrates the
	the power of the observation of DNS traffic. See [dns-footprint],		power of the observation of DNS traffic. See [dns-footprint],
	[dagon-malware] and [darkreading-dns].		[dagon-malware], and [darkreading-dns].
	Passive DNS systems [passive-dns] allow reconstruction of the data of		Passive DNS systems [passive-dns] allow reconstruction of the data of
	sometimes an entire zone. They are used for many reasons, some good,		sometimes an entire zone. They are used for many reasons -- some
	some bad. Well-known passive DNS systems keep only the DNS		good, some bad. Well-known passive DNS systems keep only the DNS
	responses, and not the source IP address of the client, precisely for		responses, and not the source IP address of the client, precisely for
	privacy reasons. Other passive DNS systems may not be so careful.		privacy reasons. Other passive DNS systems may not be so careful.
	And there is still the potential problems with revealing QNAMEs.		And there is still the potential problems with revealing QNAMEs.
	The revelations (from the Edward Snowden documents, leaked from the		The revelations (from the Edward Snowden documents, which were leaked
	NSA) of the MORECOWBELL surveillance program [morecowbell], which		from the National Security Agency (NSA)) of the MORECOWBELL
	uses the DNS, both passively and actively, to surreptitiously gather		surveillance program [morecowbell], which uses the DNS, both
	information about the users, is another good example showing that the		passively and actively, to surreptitiously gather information about
	lack of privacy protections in the DNS is actively exploited.		the users, is another good example showing that the lack of privacy
			protections in the DNS is actively exploited.
	4. Legalities		4. Legalities
	To our knowledge, there are no specific privacy laws for DNS data, in		To our knowledge, there are no specific privacy laws for DNS data, in
	any country. Interpreting general privacy laws like		any country. Interpreting general privacy laws like
	[data-protection-directive] (European Union) in the context of DNS		[data-protection-directive] (European Union) in the context of DNS
	traffic data is not an easy task and we do not know a court precedent		traffic data is not an easy task, and we do not know a court
	here. An interesting analysis is [sidn-entrada].		precedent here. See an interesting analysis in [sidn-entrada].
	5. Security considerations		5. Security Considerations
	This document is entirely about security, more precisely privacy. It		This document is entirely about security, more precisely privacy. It
	just lays out the problem, it does not try to set requirements (with		just lays out the problem; it does not try to set requirements (with
	the choices and compromises they imply), much less to define		the choices and compromises they imply), much less define solutions.
	solutions. Possible solutions to the issues described here are		Possible solutions to the issues described here are discussed in
	discussed in other documents (currently too many to all be		other documents (currently too many to all be mentioned); see, for
	mentioned), see for instance [I-D.ietf-dnsop-qname-minimisation] for		instance, [QNAME-MINIMIZATION] for the minimization of data or
	the minimisation of data, or [I-D.ietf-dprive-start-tls-for-dns]		[TLS-FOR-DNS] about encryption.
	about encryption.
	6. Acknowledgments
	Thanks to Nathalie Boulvard and to the CENTR members for the original
	work which leaded to this document. Thanks to Ondrej Sury for the
	interesting discussions. Thanks to Mohsen Souissi and John Heidemann
	for proofreading, to Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim
	Wicinski, Francis Dupont, Allison Mankin and Warren Kumari for
	proofreading, technical remarks, and many readability improvements.
	Thanks to Dan York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter
	Koch, Simon Josefsson and Frank Denis for good written contributions.
	And thanks to the IESG members for the last remarks.
	7. IANA considerations
	This document has no actions for IANA.
	8. References		6. References
	8.1. Normative References		6.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
			<http://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
			November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973, July		Considerations for Internet Protocols", RFC 6973,
	2013.		DOI 10.17487/RFC6973, July 2013,
			<http://www.rfc-editor.org/info/rfc6973>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, May 2014.		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
			2014, <http://www.rfc-editor.org/info/rfc7258>.
	8.2. Informative References
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC
	4033, March 2005.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS		6.2. Informative References
	Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, March 2008.
	[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol		[aeris-dns]
	(AXFR)", RFC 5936, June 2010.		Vinot, N., "Vie privee: et le DNS alors?", (In French),
			2015,
			<https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.
	[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.		[castillo-garcia]
	Roberts, "Issues with IP Address Sharing", RFC 6269, June		Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous
	2011.		Resolution of DNS Queries", 2008,
			<http://deic.uab.es/~joaquin/papers/is08.pdf>.
	[I-D.ietf-dnsop-edns-client-subnet]		[CLIENT-SUBNET]
	Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,		Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,
	"Client Subnet in DNS Querys", draft-ietf-dnsop-edns-		"Client Subnet in DNS Queries", Work in Progress,
	client-subnet-01 (work in progress), May 2015.		draft-ietf-dnsop-edns-client-subnet-02, July 2015.
	[I-D.iab-privsec-confidentiality-threat]		[dagon-malware]
	Barnes, R., Schneier, B., Jennings, C., Hardie, T.,		Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a
	Trammell, B., Huitema, C., and D. Borkmann,		Malicious Resolution Authority", ISC/OARC Workshop, 2007,
	"Confidentiality in the Face of Pervasive Surveillance: A		<https://www.dns-oarc.net/files/workshop-2007/
	Threat Model and Problem Statement", draft-iab-privsec-		Dagon-Resolution-corruption.pdf>.
	confidentiality-threat-07 (work in progress), May 2015.
	[I-D.wouters-dane-openpgp]		[DANE-OPENPGPKEY]
	Wouters, P., "Using DANE to Associate OpenPGP public keys		Wouters, P., "Using DANE to Associate OpenPGP public keys
	with email addresses", draft-wouters-dane-openpgp-02 (work		with email addresses", Work in Progress,
	in progress), February 2014.		draft-ietf-dane-openpgpkey-03, April 2015.
	[I-D.ietf-dprive-start-tls-for-dns]		[darkreading-dns]
	Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		Lemos, R., "Got Malware? Three Signs Revealed In DNS
	and P. Hoffman, "TLS for DNS: Initiation and Performance		Traffic", InformationWeek Dark Reading, May 2013,
	Considerations", draft-ietf-dprive-start-tls-for-dns-00		<http://www.darkreading.com/analytics/security-monitoring/
	(work in progress), May 2015.		got-malware-three-signs-revealed-in-dns-traffic/d/
			d-id/1139680>.
	[I-D.ietf-dnsop-qname-minimisation]		[data-protection-directive]
	Bortzmeyer, S., "DNS query name minimisation to improve		European Parliament, "Directive 95/46/EC of the European
	privacy", draft-ietf-dnsop-qname-minimisation-03 (work in		Pariament and of the council on the protection of
	progress), June 2015.		individuals with regard to the processing of personal data
			and on the free movement of such data", Official Journal L
			281, pp. 0031 - 0050, November 1995,
			<http://eur-lex.europa.eu/LexUriServ/
			LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.
	[I-D.ietf-dnsop-dns-terminology]		[day-at-root]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A
	Terminology", draft-ietf-dnsop-dns-terminology-02 (work in		Day at the Root of the Internet", ACM SIGCOMM Computer
	progress), May 2015.		Communication Review, Vol. 38, Number 5, DOI
			10.1145/1452335.1452341, October 2008,
			<http://www.sigcomm.org/sites/default/files/ccr/
			papers/2008/October/1452335-1452341.pdf>.
	[denis-edns-client-subnet]		[denis-edns-client-subnet]
	Denis, F., "Security and privacy issues of edns-client-		Denis, F., "Security and privacy issues of edns-client-
	subnet", August 2013, <https://00f.net/2013/08/07/edns-		subnet", August 2013, <https://00f.net/2013/08/07/
	client-subnet/>.		edns-client-subnet/>.
	[dagon-malware]		[ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002,
	Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a		<http://www.caida.org/projects/ditl/>.
	Malicious Resolution Authority", 2007, <https://www.dns-
	oarc.net/files/workshop-2007/Dagon-Resolution-
	corruption.pdf>.
	[dns-footprint]		[dns-footprint]
	Stoner, E., "DNS footprint of malware", October 2010,		Stoner, E., "DNS Footprint of Malware", OARC Workshop,
	<https://www.dns-oarc.net/files/workshop-201010/OARC-ers-		October 2010, <https://www.dns-oarc.net/files/
	20101012.pdf>.		workshop-201010/OARC-ers-20101012.pdf>.
	[morecowbell]
	Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
	"NSA's MORECOWBELL: Knell for DNS", January 2015,
	<https://gnunet.org/morecowbell>.
	[darkreading-dns]		[DNS-TERMS]
	Lemos, R., "Got Malware? Three Signs Revealed In DNS		Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Traffic", May 2013,		Terminology", Work in Progress,
	<http://www.darkreading.com/monitoring/		draft-ietf-dnsop-dns-terminology-03, June 2015.
	got-malware-three-signs-revealed-in-dns/240154181>.
	[dnschanger]		[dnschanger]
	Wikipedia, , "DNSchanger", November 2011,		Wikipedia, "DNSChanger", October 2013,
	<http://en.wikipedia.org/wiki/DNSChanger>.		<https://en.wikipedia.org/w/
			index.php?title=DNSChanger&oldid=578749672>.
	[packetq] Dot SE, , "PacketQ, a simple tool to make SQL-queries
	against PCAP-files", 2011,
	<https://github.com/dotse/packetq/wiki>.
	[dnsmezzo]		[dnsmezzo] Bortzmeyer, S., "DNSmezzo", 2009,
	Bortzmeyer, S., "DNSmezzo", 2009,
	<http://www.dnsmezzo.net/>.		<http://www.dnsmezzo.net/>.
	[prism] NSA, , "PRISM", 2007, <http://en.wikipedia.org/wiki/		[fangming-hori-sakurai]
	PRISM_%28surveillance_program%29>.		Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of
			Privacy Disclosure in DNS Query", 2007 International
			Conference on Multimedia and Ubiquitous Engineering (MUE
			2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957,
			DOI 10.1109/MUE.2007.84, April 2007,
			<http://dl.acm.org/citation.cfm?id=1262690.1262986>.
			[federrath-fuchs-herrmann-piosecny]
			Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny,
			"Privacy-Preserving DNS: Analysis of Broadcast, Range
			Queries and Mix-based Protection Methods", Computer
			Security ESORICS 2011, Springer, page(s) 665-683, ISBN
			978-3-642-23821-5, 2011,
			<https://svs.informatik.uni-hamburg.de/publications/2011/
			2011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.
	[grangeia.snooping]		[grangeia.snooping]
	Grangeia, L., "DNS Cache Snooping or Snooping the Cache		Grangeia, L., "DNS Cache Snooping or Snooping the Cache
	for Fun and Profit", 2004,		for Fun and Profit", February 2004,
	<http://www.msit2005.mut.ac.th/msit_media/1_2551/nete4630/		<http://www.msit2005.mut.ac.th/msit_media/1_2551/nete4630/
	materials/20080718130017Hc.pdf>.		materials/20080718130017Hc.pdf>.
	[ditl] CAIDA, , "A Day in the Life of the Internet (DITL)", 2002,		[herrmann-reidentification]
	<http://www.caida.org/projects/ditl/>.		Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
			"Analyzing Characteristic Host Access Patterns for
			Re-Identification of Web User Sessions",
			DOI 10.1007/978-3-642-27937-9_10, 2012,
			<http://epub.uni-regensburg.de/21103/1/
			Paper_PUL_nordsec_published.pdf>.
	[day-at-root]		[morecowbell]
	Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A		Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
	Day at the Root of the Internet", 2008,		"NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January
	<http://www.sigcomm.org/sites/default/files/ccr/		2015, <https://gnunet.org/morecowbell>.
	papers/2008/October/1452335-1452341.pdf>.
	[turkey-googledns]		[packetq] Dot SE, "PacketQ, a simple tool to make SQL-queries
	Bortzmeyer, S., "Hijacking of public DNS servers in		against PCAP-files", 2011,
	Turkey, through routing", 2014,		<https://github.com/dotse/packetq/wiki>.
	<http://www.bortzmeyer.org/
	dns-routing-hijack-turkey.html>.
	[data-protection-directive]		[packetq-list]
	Europe, , "European directive 95/46/EC on the protection		PacketQ, "PacketQ Mailing List",
	of individuals with regard to the processing of personal		<http://lists.iis.se/mailman/listinfo/packetq>.
	data and on the free movement of such data", November
	1995, <http://eur-lex.europa.eu/LexUriServ/
	LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.
	[passive-dns]		[passive-dns]
	Weimer, F., "Passive DNS Replication", April 2005,		Weimer, F., "Passive DNS Replication", April 2005,
	<http://www.enyo.de/fw/software/dnslogger/#2>.		<http://www.enyo.de/fw/software/dnslogger/#2>.
	[tor-leak]		[prism] Wikipedia, "PRISM (surveillance program)", July 2015,
	Tor, , "DNS leaks in Tor", 2013,		<https://en.wikipedia.org/w/index.php?title=PRISM_
	<https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#		(surveillance_program)&oldid=673789455>.
	IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleak
	s.ShouldIworry>.
	[yanbin-tsudik]		[QNAME-MINIMIZATION]
	Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks		Bortzmeyer, S., "DNS query name minimisation to improve
	in the Domain Name System", 2009,		privacy", Work in Progress,
	<http://arxiv.org/abs/0910.2472>.		draft-ietf-dnsop-qname-minimisation-04, June 2015.
	[castillo-garcia]		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous		Rose, "DNS Security Introduction and Requirements",
	Resolution of DNS Queries", 2008,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<http://deic.uab.es/~joaquin/papers/is08.pdf>.		<http://www.rfc-editor.org/info/rfc4033>.
	[fangming-hori-sakurai]		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Fangming, , Hori, Y., and K. Sakurai, "Analysis of Privacy		Security (DNSSEC) Hashed Authenticated Denial of
	Disclosure in DNS Query", 2007,		Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
	<http://dl.acm.org/citation.cfm?id=1262690.1262986>.		<http://www.rfc-editor.org/info/rfc5155>.
	[thomas-ditl-tcp]		[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
	Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in		(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
	Root Server DITL Data"", 2014, <https://indico.dns-		<http://www.rfc-editor.org/info/rfc5936>.
	oarc.net/event/20/session/2/contribution/15/material/
	slides/1.pdf>.
	[federrath-fuchs-herrmann-piosecny]		[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
	Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny,		P. Roberts, "Issues with IP Address Sharing", RFC 6269,
	"Privacy-Preserving DNS: Analysis of Broadcast, Range		DOI 10.17487/RFC6269, June 2011,
	Queries and Mix-Based Protection Methods", 2011,		<http://www.rfc-editor.org/info/rfc6269>.
	<https://svs.informatik.uni-hamburg.de/publications/2011/2
	011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.
	[aeris-dns]		[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
	Vinot, N., "[In French] Vie privee : et le DNS alors ?",		Trammell, B., Huitema, C., and D. Borkmann,
	2015, <https://blog.imirhil.fr/vie-privee-et-le-dns-		"Confidentiality in the Face of Pervasive Surveillance: A
	alors.html>.		Threat Model and Problem Statement", RFC 7624,
			DOI 10.17487/RFC7624, August 2015,
			<http://www.rfc-editor.org/info/rfc7624>.
	[herrmann-reidentification]		[ripe-atlas-turkey]
	Herrmann, D., Gerber, C., Banse, C., and H. Federrath,		Aben, E., "A RIPE Atlas View of Internet Meddling in
	"Analyzing characteristic host access patterns for re-		Turkey", March 2014,
	identification of web user sessions", 2012,		<https://labs.ripe.net/Members/emileaben/
	<http://epub.uni-regensburg.de/21103/1/		a-ripe-atlas-view-of-internet-meddling-in-turkey>.
	Paper_PUL_nordsec_published.pdf>.
	[sidn-entrada]		[sidn-entrada]
	Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.		Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.
	Simon, "A privacy framework for 'DNS big data'		Simon, "A privacy framework for 'DNS big data'
	applications", 2014,		applications", November 2014,
	<https://www.sidnlabs.nl/uploads/tx_sidnpublications/		<https://www.sidnlabs.nl/uploads/tx_sidnpublications/
	SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.		SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.
	8.3. URIs		[thomas-ditl-tcp]
			Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in
			Root Server DITL Data", DNS-OARC 2014 Fall Workshop,
			October 2014, <https://indico.dns-oarc.net/event/20/
			session/2/contribution/15/material/slides/1.pdf>.
	[1] https://developers.google.com/speed/public-dns/privacy		[TLS-FOR-DNS]
			Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "TLS for DNS: Initiation and Performance
			Considerations", Work in Progress, draft-ietf-dprive-
			start-tls-for-dns-01, July 2015.
			[tor-leak] Tor, "DNS leaks in Tor", 2013,
			<https://www.torproject.org/docs/
			faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.
			[yanbin-tsudik]
			Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks
			in the Domain Name System", October 2009,
			<http://arxiv.org/abs/0910.2472>.
			Acknowledgments
			Thanks to Nathalie Boulvard and to the CENTR members for the original
			work that led to this document. Thanks to Ondrej Sury for the
			interesting discussions. Thanks to Mohsen Souissi and John Heidemann
			for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,
			Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for
			proofreading, providing technical remarks, and making many
			readability improvements. Thanks to Dan York, Suzanne Woolf, Tony
			Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis
			for good written contributions. And thanks to the IESG members for
			the last remarks.
	Author's Address		Author's Address
	Stephane Bortzmeyer		Stephane Bortzmeyer
	AFNIC		AFNIC
	1, rue Stephenson		1, rue Stephenson
	Montigny-le-Bretonneux 78180		Montigny-le-Bretonneux 78180
	France		France
	Phone: +33 1 39 30 83 46		Phone: +33 1 39 30 83 46
End of changes. 116 change blocks.
	381 lines changed or deleted		404 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/