< draft-bortzmeyer-dprive-rfc7626-bis-01.txt		draft-bortzmeyer-dprive-rfc7626-bis-02.txt >
	dprive S. Bortzmeyer		dprive S. Bortzmeyer
	Internet-Draft AFNIC		Internet-Draft AFNIC
	Obsoletes: 7626 (if approved) S. Dickinson		Obsoletes: 7626 (if approved) S. Dickinson
	Intended status: Informational Sinodun IT		Intended status: Informational Sinodun IT
	Expires: January 17, 2019 July 16, 2018		Expires: July 19, 2019 January 15, 2019
	DNS Privacy Considerations		DNS Privacy Considerations
	draft-bortzmeyer-dprive-rfc7626-bis-01		draft-bortzmeyer-dprive-rfc7626-bis-02
	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. This document
			obsoletes RFC 7626.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 17, 2019.		This Internet-Draft will expire on July 19, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	The Domain Name System is specified in [RFC1034], [RFC1035], and many		The Domain Name System is specified in [RFC1034], [RFC1035], and many
	later RFCs, which have never been consolidated. It is one of the		later RFCs, which have never been consolidated. It is one of the
	most important infrastructure components of the Internet and often		most important infrastructure components of the Internet and 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-terminology-bis]) A client, the stub resolver,		also [RFC8499]) A client, the stub resolver, issues a DNS query to a
	issues a DNS query to a server, called the recursive resolver (also		server, called the recursive resolver (also called caching resolver
	called caching resolver or full resolver or recursive name server).		or full resolver or recursive name server). Let's use the query
	Let's use the query "What are the AAAA records for www.example.com?"		"What are the AAAA records for www.example.com?" as an example. AAAA
	as an example. AAAA is the QTYPE (Query Type), and www.example.com		is the QTYPE (Query Type), and www.example.com is the QNAME (Query
	is the QNAME (Query Name). (The description that follows assumes a		Name). (The description that follows assumes a cold cache, for
	cold cache, for instance, because the server just started.) The		instance, because the server just started.) The recursive resolver
	recursive resolver will first query the root name servers. In most		will first query the root name servers. In most cases, the root name
	cases, the root name servers will send a referral. In this example,		servers will send a referral. In this example, the referral will be
	the referral will be to the .com name servers. The resolver repeats		to the .com name servers. The resolver repeats the query to one of
	the query to one of the .com name servers. The .com name servers, in		the .com name servers. The .com name servers, in turn, will refer to
	turn, will refer to the example.com name servers. The example.com		the example.com name servers. The example.com name server will then
	name server will then return the answer. The root name servers, the		return the answer. The root name servers, the name servers of .com,
	name servers of .com, and the name servers of example.com are called		and the name servers of example.com are called authoritative name
	authoritative name servers. It is important, when analyzing the		servers. It is important, when analyzing the privacy issues, to
	privacy issues, to remember that the question asked to all these name		remember that the question asked to all these name servers is always
	servers is always the original question, not a derived question. The		the original question, not a derived question. The question sent to
	question sent to the root name servers is "What are the AAAA records		the root name servers is "What are the AAAA records for
	for www.example.com?", not "What are the name servers of .com?". By		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 name server.		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 the recursive resolver, "What are the SRV records		stub resolver asks the recursive resolver, "What are the SRV records
	of _xmpp-server._tcp.example.com?", the recursive resolver will		of _xmpp-server._tcp.example.com?", the recursive resolver will
	remember that it knows the name servers of example.com and will just		remember that it knows the name servers of example.com and will just
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	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).
	At the time of writing there is increasing deployment of DNS-over-TLS		At the time of writing there is increasing deployment of DNS-over-TLS
	[RFC7858] and work underway on DoH [I-D.ietf-doh-dns-over-https].		[RFC7858] and work underway on DoH [RFC8484]. There are a few cases
	There are a few cases where there is some alternative channel		where there is some alternative channel encryption, for instance, in
	encryption, for instance, in an IPsec VPN, at least between the stub		an IPsec VPN, at least between the stub resolver and the resolver.
	resolver and the 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 are		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,
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 44 ¶
	2.4. On the Wire		2.4. On the Wire
	2.4.1. Unencrypted Transports		2.4.1. Unencrypted Transports
	For unencrypted transports, DNS traffic can be seen by an		For unencrypted transports, DNS traffic can be seen by an
	eavesdropper like any other traffic. (DNSSEC, specified in		eavesdropper like any other traffic. (DNSSEC, specified in
	[RFC4033], explicitly excludes confidentiality from its goals.) So,		[RFC4033], explicitly excludes confidentiality from its goals.) So,
	if an initiator starts an HTTPS communication with a recipient, while		if an initiator starts an HTTPS communication with a recipient, while
	the HTTP traffic will be encrypted, the DNS exchange prior to it will		the HTTP traffic will be encrypted, the DNS exchange prior to it will
	not be. When other protocols will become more and more privacy-aware		not be. When other protocols will become more and more privacy-aware
	and secured against surveillance (e.g. [I-D.draft-ietf-tls-tls130,		and secured against surveillance (e.g. [RFC8446],
	[I-D.draft-ietf-quic-transport]), the use of unencrypted transports		[I-D.ietf-quic-transport]), the use of unencrypted transports for DNS
	for DNS may become "the weakest link" in privacy. It is noted that		may become "the weakest link" in privacy. It is noted that there is
	there is on-going work attempting to encrypt the SNI in the TLS		on-going work attempting to encrypt the SNI in the TLS handshake but
	handshake but that this is a non-trivial problem [I-D.ietf-tls-sni-		that this is a non-trivial problem [I-D.ietf-tls-sni-encryption].
	encryption].
	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
	name servers.		name servers.
	The best place to tap, from an eavesdropper's point of view, is		The best place to tap, from an eavesdropper's point of view, is
	clearly between the stub resolvers and the recursive resolvers,		clearly between the stub resolvers and the recursive resolvers,
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 44 ¶
	Users of encrypted transports are also highly likely to re-use		Users of encrypted transports are also highly likely to re-use
	sessions for multiple DNS queries to optimize performance (e.g. via		sessions for multiple DNS queries to optimize performance (e.g. via
	DNS pipelining or HTTPS multiplexing). Certain configuration options		DNS pipelining or HTTPS multiplexing). Certain configuration options
	for encrypted transports could also in principle fingerprint a user,		for encrypted transports could also in principle fingerprint a user,
	for example session resumption, the maximum number of messages to		for example session resumption, the maximum number of messages to
	send or a maximum connection time before closing a connections and		send or a maximum connection time before closing a connections and
	re-opening.		re-opening.
	Whilst there are known attacks on older versions of TLS the most		Whilst there are known attacks on older versions of TLS the most
	recent recommendations [RFC7525] and developments [I-D.draft-ietf-		recent recommendations [RFC7525] and developments [RFC8446] in this
	tls-tls13] in this area largely mitigate those.		area largely mitigate those.
	Traffic analysis of unpadded encrypted traffic is also possible		Traffic analysis of unpadded encrypted traffic is also possible
	[pitfalls-of-dns-encrption] because the sizes and timing of encrypted		[pitfalls-of-dns-encrption] because the sizes and timing of encrypted
	DNS requests and responses can be correlated to unencrypted DNS		DNS requests and responses can be correlated to unencrypted DNS
	requests upstream of a recursive resolver.		requests upstream of a recursive resolver.
	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
	skipping to change at page 11, line 7 ¶		skipping to change at page 11, line 7 ¶
	Use of encrypted transports does not reduce the data available in the		Use of encrypted transports does not reduce the data available in the
	recursive resolver and ironically can actually expose more		recursive resolver and ironically can actually expose more
	information about users to operators. As mentioned in Section 2.4		information about users to operators. As mentioned in Section 2.4
	use of session based encrypted transports (TCP/TLS) can expose		use of session based encrypted transports (TCP/TLS) can expose
	correlation data about users. Such concerns in the TCP/TLS layers		correlation data about users. Such concerns in the TCP/TLS layers
	apply equally to DNS-over-TLS and DoH which both use TLS as the		apply equally to DNS-over-TLS and DoH which both use TLS as the
	underlying transport.		underlying transport.
	2.5.1.2. DoH vs DNS-over-TLS		2.5.1.2. DoH vs DNS-over-TLS
	The proposed specification for DoH [I-D.ietf-doh-dns-over-https]		The proposed specification for DoH [RFC8484] includes a Privacy
	includes a Privacy Considerations section which highlights some of		Considerations section which highlights some of the differences
	the differences between HTTP and DNS. As a deliberate design choice		between HTTP and DNS. As a deliberate design choice DoH inherits the
	DoH inherits the privacy properties of the HTTPS stack and as a		privacy properties of the HTTPS stack and as a consequence introduces
	consequence introduces new privacy concerns when compared with DNS		new privacy concerns when compared with DNS over UDP, TCP or TLS
	over UDP, TCP or TLS [RFC7858]. The rationale for this decision is		[RFC7858]. The rationale for this decision is that retaining the
	that retaining the ability to leverage the full functionality of the		ability to leverage the full functionality of the HTTP ecosystem is
	HTTP ecosystem is more important than placing specific constraints on		more important than placing specific constraints on this new protocol
	this new protocol based on privacy considerations (modulo limiting		based on privacy considerations (modulo limiting the use of HTTP
	the use of HTTP cookies).		cookies).
	In analyzing the new issues introduced by DoH it is helpful to		In analyzing the new issues introduced by DoH it is helpful to
	recognize that there exists a natural tension between		recognize that there exists a natural tension between
	o the wide practice in HTTP to use various headers to optimize HTTP		o the wide practice in HTTP to use various headers to optimize HTTP
	connections, functionality and behaviour (which can facilitate		connections, functionality and behaviour (which can facilitate
	user identification and tracking)		user identification and tracking)
	o and the fact that the DNS payload is currently very tightly		o and the fact that the DNS payload is currently very tightly
	encoded and contains no standardized user identifiers.		encoded and contains no standardized user identifiers.
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	transports defeats the attack of re-directing traffic to rogue		transports defeats the attack of re-directing traffic to rogue
	servers. Of course attacks on these secure channels are also		servers. Of course attacks on these secure channels are also
	possible, but out of the scope of this document.		possible, but out of the scope of this document.
	2.5.5. Blocking of services		2.5.5. Blocking of services
	User privacy can also be at risk if there is blocking (by local		User privacy can also be at risk if there is blocking (by local
	network operators or more general mechanisms) of access to recursive		network operators or more general mechanisms) of access to recursive
	servers that offer encrypted transports. For example active blocking		servers that offer encrypted transports. For example active blocking
	of port 853 for DNS-over-TLS or of specific IP addresses (e.g.		of port 853 for DNS-over-TLS or of specific IP addresses (e.g.
	1.1.1.1) could restrict the resolvers available to the client.		1.1.1.1 or 2606:4700:4700::1111) could restrict the resolvers
	Similarly attacks on such services e.g. DDoS could force users to		available to the client. Similarly attacks on such services e.g.
	switch to other services that do not offer encrypted transports for		DDoS could force users to switch to other services that do not offer
	DNS.		encrypted transports for DNS.
	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 this 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
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 13 ¶
	[sidn-entrada].		[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 define solutions.		the choices and compromises they imply), much less define solutions.
	Possible solutions to the issues described here are discussed in		Possible solutions to the issues described here are discussed in
	other documents (currently too many to all be mentioned); see, for		other documents (currently too many to all be mentioned); see, for
	instance, 'Recommendations for DNS Privacy Operators'		instance, 'Recommendations for DNS Privacy Operators'
	[I-D.dickinson-dprive-bcp-op].		[I-D.ietf-dprive-bcp-op].
	6. Acknowledgments		6. Acknowledgments
	Thanks to Nathalie Boulvard and to the CENTR members for the original		Thanks to Nathalie Boulvard and to the CENTR members for the original
	work that led to this document. Thanks to Ondrej Sury for the		work that led to this document. Thanks to Ondrej Sury for the
	interesting discussions. Thanks to Mohsen Souissi and John Heidemann		interesting discussions. Thanks to Mohsen Souissi and John Heidemann
	for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,		for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,
	Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for		Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for
	proofreading, providing technical remarks, and making many		proofreading, providing technical remarks, and making many
	readability improvements. Thanks to Dan York, Suzanne Woolf, Tony		readability improvements. Thanks to Dan York, Suzanne Woolf, Tony
	Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis		Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis
	for good written contributions. And thanks to the IESG members for		for good written contributions. And thanks to the IESG members for
	the last remarks.		the last remarks.
	7. Changelog		7. Changelog
			draft-bortzmeyer-dprive-rfc7626-bis-02
			o Update various references and fix some nits.
	draft-bortzmeyer-dprive-rfc7626-bis-01		draft-bortzmeyer-dprive-rfc7626-bis-01
	o Update reference for dickinson-bcp-op to draft-dickinson-dprive-		o Update reference for dickinson-bcp-op to draft-dickinson-dprive-
	bcp-op		bcp-op
	draft-borztmeyer-dprive-rfc7626-bis-00:		draft-borztmeyer-dprive-rfc7626-bis-00:
	Initial commit. Differences to RFC7626:		Initial commit. Differences to RFC7626:
	o Update many references		o Update many references
	skipping to change at page 19, line 27 ¶		skipping to change at page 19, line 27 ¶
	<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>.
	[herrmann-reidentification]		[herrmann-reidentification]
	Herrmann, D., Gerber, C., Banse, C., and H. Federrath,		Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
	"Analyzing Characteristic Host Access Patterns for Re-		"Analyzing Characteristic Host Access Patterns for Re-
	Identification of Web User Sessions",		Identification of Web User Sessions",
	DOI 10.1007/978-3-642-27937-9_10, 2012, <http://epub.uni-		DOI 10.1007/978-3-642-27937-9_10, 2012, <http://epub.uni-
	regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.		regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.
	[I-D.dickinson-dprive-bcp-op]		[I-D.ietf-dprive-bcp-op]
	Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A.		Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A.
	Mankin, "Recommendations for DNS Privacy Service		Mankin, "Recommendations for DNS Privacy Service
	Operators", draft-dickinson-dprive-bcp-op-00 (work in		Operators", draft-ietf-dprive-bcp-op-01 (work in
	progress), July 2018.		progress), December 2018.
	[I-D.ietf-dnsop-terminology-bis]		[I-D.ietf-quic-transport]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	Terminology", draft-ietf-dnsop-terminology-bis-11 (work in		and Secure Transport", draft-ietf-quic-transport-17 (work
	progress), July 2018.		in progress), December 2018.
	[I-D.ietf-doh-dns-over-https]		[I-D.ietf-tls-sni-encryption]
	Hoffman, P. and P. McManus, "DNS Queries over HTTPS		Huitema, C. and E. Rescorla, "Issues and Requirements for
	(DoH)", draft-ietf-doh-dns-over-https-12 (work in		SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04
	progress), June 2018.		(work in progress), November 2018.
	[morecowbell]		[morecowbell]
	Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,		Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
	"NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January		"NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January
	2015, <https://gnunet.org/morecowbell>.		2015, <https://gnunet.org/morecowbell>.
	[packetq] Dot SE, "PacketQ, a simple tool to make SQL-queries		[packetq] Dot SE, "PacketQ, a simple tool to make SQL-queries
	against PCAP-files", 2011,		against PCAP-files", 2011,
	<https://github.com/dotse/packetq/wiki>.		<https://github.com/dotse/packetq/wiki>.
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 31 ¶
	[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)		[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
	Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,		Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
	<https://www.rfc-editor.org/info/rfc7873>.		<https://www.rfc-editor.org/info/rfc7873>.
	[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities		[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
	(DANE) Bindings for OpenPGP", RFC 7929,		(DANE) Bindings for OpenPGP", RFC 7929,
	DOI 10.17487/RFC7929, August 2016, <https://www.rfc-		DOI 10.17487/RFC7929, August 2016, <https://www.rfc-
	editor.org/info/rfc7929>.		editor.org/info/rfc7929>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
			(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
			<https://www.rfc-editor.org/info/rfc8484>.
			[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
			Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
			January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	[ripe-atlas-turkey]		[ripe-atlas-turkey]
	Aben, E., "A RIPE Atlas View of Internet Meddling in		Aben, E., "A RIPE Atlas View of Internet Meddling in
	Turkey", March 2014,		Turkey", March 2014,
	<https://labs.ripe.net/Members/emileaben/a-ripe-atlas-		<https://labs.ripe.net/Members/emileaben/a-ripe-atlas-
	view-of-internet-meddling-in-turkey>.		view-of-internet-meddling-in-turkey>.
	[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", November 2014,		applications", November 2014,
End of changes. 18 change blocks.
	62 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/