< draft-ietf-dprive-bcp-op-05.txt		draft-ietf-dprive-bcp-op-06.txt >
	dprive S. Dickinson		dprive S. Dickinson
	Internet-Draft Sinodun IT		Internet-Draft Sinodun IT
	Intended status: Best Current Practice B. Overeinder		Intended status: Best Current Practice B. Overeinder
	Expires: May 3, 2020 R. van Rijswijk-Deij		Expires: May 21, 2020 R. van Rijswijk-Deij
	NLnet Labs		NLnet Labs
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	October 31, 2019		November 18, 2019
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	draft-ietf-dprive-bcp-op-05		draft-ietf-dprive-bcp-op-06
	Abstract		Abstract
	This document presents operational, policy and security		This document presents operational, policy and security
	considerations for DNS recursive resolver operators who choose to		considerations for DNS recursive resolver operators who choose to
	offer DNS Privacy services. With these recommendations, the operator		offer DNS Privacy services. With these recommendations, the operator
	can make deliberate decisions regarding which services to provide,		can make deliberate decisions regarding which services to provide,
	and how the decisions and alternatives impact the privacy of users.		and how the decisions and alternatives impact the privacy of users.
	This document also presents a framework to assist writers of a DNS		This document also presents a framework to assist writers of a DNS
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 May 3, 2020.		This Internet-Draft will expire on May 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	6.2. Current policy and privacy statements . . . . . . . . . . 22		6.2. Current policy and privacy statements . . . . . . . . . . 22
	6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23		6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
	8. Security considerations . . . . . . . . . . . . . . . . . . . 23		8. Security considerations . . . . . . . . . . . . . . . . . . . 23
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12.1. Normative References . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . 26
	12.2. Informative References . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 28
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31		Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31
	A.1. Potential increases in DNS privacy . . . . . . . . . . . 31		A.1. Potential increases in DNS privacy . . . . . . . . . . . 31
	A.2. Potential decreases in DNS privacy . . . . . . . . . . . 31		A.2. Potential decreases in DNS privacy . . . . . . . . . . . 32
	A.3. Related operational documents . . . . . . . . . . . . . . 32		A.3. Related operational documents . . . . . . . . . . . . . . 32
	Appendix B. IP address techniques . . . . . . . . . . . . . . . 32		Appendix B. IP address techniques . . . . . . . . . . . . . . . 32
	B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33		B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33
	B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33		B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 34
	B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34		B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34
	B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34		B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34
	B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34		B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 35
	B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35		B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35
	B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35		B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix C. Example DROP statement . . . . . . . . . . . . . . . 35		Appendix C. Example DROP statement . . . . . . . . . . . . . . . 36
	C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36		C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36
	C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 38		C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is at the core of the Internet; almost		The Domain Name System (DNS) is at the core of the Internet; almost
	every activity on the Internet starts with a DNS query (and often		every activity on the Internet starts with a DNS query (and often
	several). However the DNS was not originally designed with strong		several). However the DNS was not originally designed with strong
	security or privacy mechanisms. A number of developments have taken		security or privacy mechanisms. A number of developments have taken
	place in recent years which aim to increase the privacy of the DNS		place in recent years which aim to increase the privacy of the DNS
	system and these are now seeing some deployment. This latest		system and these are now seeing some deployment. This latest
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	operator policy rather than gross disparities in privacy concerns.		operator policy rather than gross disparities in privacy concerns.
	Community insight [or judgment?] about operational practices can		Community insight [or judgment?] about operational practices can
	change quickly, and experience shows that a Best Current Practice		change quickly, and experience shows that a Best Current Practice
	(BCP) document about privacy and security is a point-in-time		(BCP) document about privacy and security is a point-in-time
	statement. Readers are advised to seek out any errata or updates		statement. Readers are advised to seek out any errata or updates
	that apply to this document.		that apply to this document.
	2. Scope		2. Scope
	"DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis]		"DNS Privacy Considerations" [I-D.ietf-dprive-rfc7626-bis] describes
	describes the general privacy issues and threats associated with the		the general privacy issues and threats associated with the use of the
	use of the DNS by Internet users and much of the threat analysis here		DNS by Internet users and much of the threat analysis here is lifted
	is lifted from that document and from [RFC6973]. However this		from that document and from [RFC6973]. However this document is
	document is limited in scope to best practice considerations for the		limited in scope to best practice considerations for the provision of
	provision of DNS privacy services by servers (recursive resolvers) to		DNS privacy services by servers (recursive resolvers) to clients
	clients (stub resolvers or forwarders). Privacy considerations		(stub resolvers or forwarders). Privacy considerations specifically
	specifically from the perspective of an end user, or those for		from the perspective of an end user, or those for operators of
	operators of authoritative nameservers are out of scope.		authoritative nameservers are out of scope.
	This document includes (but is not limited to) considerations in the		This document includes (but is not limited to) considerations in the
	following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]):		following areas (taken from [I-D.ietf-dprive-rfc7626-bis]):
	1. Data "on the wire" between a client and a server		1. Data "on the wire" between a client and a server
	2. Data "at rest" on a server (e.g. in logs)		2. Data "at rest" on a server (e.g. in logs)
	3. Data "sent onwards" from the server (either on the wire or shared		3. Data "sent onwards" from the server (either on the wire or shared
	with a third party)		with a third party)
	Whilst the issues raised here are targeted at those operators who		Whilst the issues raised here are targeted at those operators who
	choose to offer a DNS privacy service, considerations for areas 2 and		choose to offer a DNS privacy service, considerations for areas 2 and
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	benefits at the price of a reduction in privacy and conversely some		benefits at the price of a reduction in privacy and conversely some
	features increase privacy with an accompanying increase in		features increase privacy with an accompanying increase in
	complexity. A selection of the most relevant documents are listed in		complexity. A selection of the most relevant documents are listed in
	Appendix A for reference.		Appendix A for reference.
	4. Terminology		4. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] and [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	DNS terminology is as described in [RFC8499] with one modification:		DNS terminology is as described in [RFC8499] with one modification:
	we restate the clause in the original definition of Privacy-enabling		we restate the clause in the original definition of Privacy-enabling
	DNS server in [RFC8310] to include the requirement that a DNS over		DNS server in [RFC8310] to include the requirement that a DNS over
	(D)TLS server should also offer at least one of the credentials		(D)TLS server should also offer at least one of the credentials
	described in Section 8 and implement the (D)TLS profile described in		described in Section 8 and implement the (D)TLS profile described in
	Section 9 of [RFC8310].		Section 9 of [RFC8310].
	Other Terms:		Other Terms:
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 33 ¶
	In this section we consider both data on the wire and the service		In this section we consider both data on the wire and the service
	provided to the client.		provided to the client.
	5.1.1. Transport recommendations		5.1.1. Transport recommendations
	[RFC6973] Threats:		[RFC6973] Threats:
	o Surveillance:		o Surveillance:
	* Passive surveillance of traffic on the wire		* Passive surveillance of traffic on the wire
	[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.4.2.		[I-D.ietf-dprive-rfc7626-bis] Section 2.4.2.
	DNS Privacy Threats:		DNS Privacy Threats:
	o Active injection of spurious data or traffic		o Active injection of spurious data or traffic
	Mitigations:		Mitigations:
	A DNS privacy service can mitigate these threats by providing service		A DNS privacy service can mitigate these threats by providing service
	over one or more of the following transports		over one or more of the following transports
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 20 ¶
	Whilst encryption of DNS traffic can protect against active injection		Whilst encryption of DNS traffic can protect against active injection
	this does not diminish the need for DNSSEC, see Section 5.1.4.		this does not diminish the need for DNSSEC, see Section 5.1.4.
	5.1.2. Authentication of DNS privacy services		5.1.2. Authentication of DNS privacy services
	[RFC6973] Threats:		[RFC6973] Threats:
	o Surveillance:		o Surveillance:
	* Active attacks that can redirect traffic to rogue servers		* Active attacks that can redirect traffic to rogue servers
	[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3.		[I-D.ietf-dprive-rfc7626-bis] Section 2.5.3.
	Mitigations:		Mitigations:
	DNS privacy services should ensure clients can authenticate the		DNS privacy services should ensure clients can authenticate the
	server. Note that this, in effect, commits the DNS privacy service		server. Note that this, in effect, commits the DNS privacy service
	to a public identity users will trust.		to a public identity users will trust.
	When using DNS-over-TLS clients that select a 'Strict Privacy' usage		When using DNS-over-TLS clients that select a 'Strict Privacy' usage
	profile [RFC8310] (to mitigate the threat of active attack on the		profile [RFC8310] (to mitigate the threat of active attack on the
	client) require the ability to authenticate the DNS server. To		client) require the ability to authenticate the DNS server. To
	skipping to change at page 11, line 48 ¶		skipping to change at page 11, line 48 ¶
	5.1.5. Availability		5.1.5. Availability
	DNS Privacy Threats:		DNS Privacy Threats:
	o A failed DNS privacy service could force the user to switch		o A failed DNS privacy service could force the user to switch
	providers, fallback to cleartext or accept no DNS service for the		providers, fallback to cleartext or accept no DNS service for the
	outage.		outage.
	Mitigations:		Mitigations:
	A DNS privacy service must be engineered for high availability.		A DNS privacy service should strive to engineer encrypted services to
			the same availability level as any unencrypted services they provide.
	Particular care should to be taken to protect DNS privacy services		Particular care should to be taken to protect DNS privacy services
	against denial-of-service attacks, as experience has shown that		against denial-of-service attacks, as experience has shown that
	unavailability of DNS resolving because of attacks is a significant		unavailability of DNS resolving because of attacks is a significant
	motivation for users to switch services. See, for example		motivation for users to switch services. See, for example
	Section IV-C of Passive Observations of a Large DNS Service: 2.5		Section IV-C of Passive Observations of a Large DNS Service: 2.5
	Years in the Life of Google [2].		Years in the Life of Google [2].
	Techniques such as those described in Section 10 of [RFC7766] can be		Techniques such as those described in Section 10 of [RFC7766] can be
	of use to operators to defend against such attacks.		of use to operators to defend against such attacks.
	skipping to change at page 12, line 48 ¶		skipping to change at page 12, line 49 ¶
	however, legitimate reasons for operators to inspect DNS traffic,		however, legitimate reasons for operators to inspect DNS traffic,
	e.g. to monitor for network security threats. Operators may		e.g. to monitor for network security threats. Operators may
	therefore need to invest in alternative means of monitoring that		therefore need to invest in alternative means of monitoring that
	relies on either the resolver software directly, or exporting DNS		relies on either the resolver software directly, or exporting DNS
	traffic from the resolver using e.g. dnstap [3].		traffic from the resolver using e.g. dnstap [3].
	Optimization:		Optimization:
	When implementing alternative means for traffic monitoring, operators		When implementing alternative means for traffic monitoring, operators
	of a DNS privacy service should consider using privacy conscious		of a DNS privacy service should consider using privacy conscious
	means to do so (see, for example, the discussion on the use of Bloom		means to do so (see section Section 5.2 for more details on data
	Filters in the #documents appendix in this document).		handling and also the discussion on the use of Bloom Filters in
			Appendix A.
	5.1.8. Limitations of using a pure TLS proxy		5.1.8. Limitations of using a pure TLS proxy
	DNS Privacy Threats:		DNS Privacy Threats:
	o Limited ability to manage or monitor incoming connections using		o Limited ability to manage or monitor incoming connections using
	DNS specific techniques		DNS specific techniques
	o Misconfiguration of the target server could lead to data leakage		o Misconfiguration of the target server could lead to data leakage
	if the proxy to target server path is not encrypted.		if the proxy to target server path is not encrypted.
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 18 ¶
	Mitigations:		Mitigations:
	The following are common activities for DNS service operators and in		The following are common activities for DNS service operators and in
	all cases should be minimized or completely avoided if possible for		all cases should be minimized or completely avoided if possible for
	DNS privacy services. If data is retained it should be encrypted and		DNS privacy services. If data is retained it should be encrypted and
	either aggregated, pseudonymized or anonymized whenever possible. In		either aggregated, pseudonymized or anonymized whenever possible. In
	general the principle of data minimization described in [RFC6973]		general the principle of data minimization described in [RFC6973]
	should be applied.		should be applied.
	o Transient data (e.g. that is used for real time monitoring and		o Transient data (e.g. that is used for real time monitoring and
	threat analysis which might be held only memory) should be		threat analysis which might be held only in memory) should be
	retained for the shortest possible period deemed operationally		retained for the shortest possible period deemed operationally
	feasible.		feasible.
	o The retention period of DNS traffic logs should be only those		o The retention period of DNS traffic logs should be only those
	required to sustain operation of the service and, to the extent		required to sustain operation of the service and, to the extent
	that such exists, meet regulatory requirements.		that such exists, meet regulatory requirements.
	o DNS privacy services should not track users except for the		o DNS privacy services should not track users except for the
	particular purpose of detecting and remedying technically		particular purpose of detecting and remedying technically
	malicious (e.g. DoS) or anomalous use of the service.		malicious (e.g. DoS) or anomalous use of the service.
	skipping to change at page 15, line 46 ¶		skipping to change at page 15, line 46 ¶
	pseudonymization schema is known, the process can be reversed, so		pseudonymization schema is known, the process can be reversed, so
	the original identity becomes known again.		the original identity becomes known again.
	In practice there is a fine line between the two; for example, how to		In practice there is a fine line between the two; for example, how to
	categorize a deterministic algorithm for data minimization of IP		categorize a deterministic algorithm for data minimization of IP
	addresses that produces a group of pseudonyms for a single given		addresses that produces a group of pseudonyms for a single given
	address.		address.
	5.2.3. IP address pseudonymization and anonymization methods		5.2.3. IP address pseudonymization and anonymization methods
	As [I-D.bortzmeyer-dprive-rfc7626-bis] makes clear, the big privacy		As [I-D.ietf-dprive-rfc7626-bis] makes clear, the big privacy risk in
	risk in DNS is connecting DNS queries to an individual and the major		DNS is connecting DNS queries to an individual and the major vector
	vector for this in DNS traffic is the client IP address.		for this in DNS traffic is the client IP address.
	There is active discussion in the space of effective pseudonymization		There is active discussion in the space of effective pseudonymization
	of IP addresses in DNS traffic logs, however there seems to be no		of IP addresses in DNS traffic logs, however there seems to be no
	single solution that is widely recognized as suitable for all or most		single solution that is widely recognized as suitable for all or most
	use cases. There are also as yet no standards for this that are		use cases. There are also as yet no standards for this that are
	unencumbered by patents.		unencumbered by patents.
	The following table presents a high level comparison of various		The following table presents a high level comparison of various
	techniques employed or under development today and classifies them		techniques employed or under development today and classifies them
	according to categorization of technique and other properties.		according to categorization of technique and other properties.
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 5 ¶
	Whitelisting has the benefit that not only does the operator know		Whitelisting has the benefit that not only does the operator know
	which upstream servers can use ECS but also allows the operator to		which upstream servers can use ECS but also allows the operator to
	decide which upstream servers apply privacy policies that the		decide which upstream servers apply privacy policies that the
	operator is happy with. However some operators consider whitelisting		operator is happy with. However some operators consider whitelisting
	to incur significant operational overhead compared to dynamic		to incur significant operational overhead compared to dynamic
	detection of ECS on authoritative servers.		detection of ECS on authoritative servers.
	Additional options:		Additional options:
	o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the		o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
			(NXDOMAIN: There Really Is Nothing Underneath) to reduce the
	number of queries to authoritative servers to increase privacy.		number of queries to authoritative servers to increase privacy.
	o Run a copy of the root zone on loopback [RFC7706] to avoid making		o Run a copy of the root zone on loopback [RFC7706] to avoid making
	queries to the root servers that might leak information.		queries to the root servers that might leak information.
	5.3.2. Client query obfuscation		5.3.2. Client query obfuscation
	Additional options:		Additional options:
	Since queries from recursive resolvers to authoritative servers are		Since queries from recursive resolvers to authoritative servers are
	skipping to change at page 24, line 27 ¶		skipping to change at page 24, line 27 ¶
	Sinodun Internet Technologies		Sinodun Internet Technologies
	Magdalen Centre		Magdalen Centre
	Oxford Science Park		Oxford Science Park
	Oxford OX4 4GA		Oxford OX4 4GA
	United Kingdom		United Kingdom
	11. Changelog		11. Changelog
	draft-ietf-dprive-bcp-op-05		draft-ietf-dprive-bcp-op-05
			o Final minor changes from second WGLC.
			draft-ietf-dprive-bcp-op-05
	o Remove some text on consent:		o Remove some text on consent:
	* Paragraph 2 in section 5.3.3		* Paragraph 2 in section 5.3.3
	* Item 6 in the DROP Practice statement (and example)		* Item 6 in the DROP Practice statement (and example)
	o Remove .onion and TLSA options		o Remove .onion and TLSA options
	o Include ACME as a reference for certificate management		o Include ACME as a reference for certificate management
	skipping to change at page 26, line 27 ¶		skipping to change at page 26, line 30 ¶
	draft-ietf-dprive-bcp-op-00		draft-ietf-dprive-bcp-op-00
	o Initial commit of re-named document after adoption to replace		o Initial commit of re-named document after adoption to replace
	draft-dickinson-dprive-bcp-op-01		draft-dickinson-dprive-bcp-op-01
	12. References		12. References
	12.1. Normative References		12.1. Normative References
			[I-D.ietf-dprive-rfc7626-bis]
			Bortzmeyer, S. and S. Dickinson, "DNS Privacy
			Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in
			progress), October 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011, <https://www.rfc-		DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
	editor.org/info/rfc6265>.		editor.org/info/rfc6265>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	skipping to change at page 28, line 11 ¶		skipping to change at page 28, line 24 ¶
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,		(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/info/rfc8484>.		<https://www.rfc-editor.org/info/rfc8484>.
	12.2. Informative References		12.2. Informative References
	[I-D.bellis-dnsop-xpf]		[I-D.bellis-dnsop-xpf]
	Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",		Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",
	draft-bellis-dnsop-xpf-04 (work in progress), March 2018.		draft-bellis-dnsop-xpf-04 (work in progress), March 2018.
	[I-D.bortzmeyer-dprive-rfc7626-bis]
	Bortzmeyer, S. and S. Dickinson, "DNS Privacy
	Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02
	(work in progress), January 2019.
	[I-D.ietf-dnsop-dns-tcp-requirements]		[I-D.ietf-dnsop-dns-tcp-requirements]
	Kristoff, J. and D. Wessels, "DNS Transport over TCP -		Kristoff, J. and D. Wessels, "DNS Transport over TCP -
	Operational Requirements", draft-ietf-dnsop-dns-tcp-		Operational Requirements", draft-ietf-dnsop-dns-tcp-
	requirements-04 (work in progress), June 2019.		requirements-05 (work in progress), November 2019.
	[I-D.ietf-httpbis-bcp56bis]		[I-D.ietf-httpbis-bcp56bis]
	Nottingham, M., "Building Protocols with HTTP", draft-		Nottingham, M., "Building Protocols with HTTP", draft-
	ietf-httpbis-bcp56bis-08 (work in progress), November		ietf-httpbis-bcp56bis-09 (work in progress), November
	2018.		2019.
	[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.		[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.
	[Pitfalls-of-DNS-Encryption]		[Pitfalls-of-DNS-Encryption]
	Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS		Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
	Encryption", 2014, <https://dl.acm.org/		Encryption", 2014, <https://dl.acm.org/
	citation.cfm?id=2665959>.		citation.cfm?id=2665959>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	skipping to change at page 29, line 15 ¶		skipping to change at page 29, line 25 ¶
	[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing		[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
	Known Attacks on Transport Layer Security (TLS) and		Known Attacks on Transport Layer Security (TLS) and
	Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,		Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
	February 2015, <https://www.rfc-editor.org/info/rfc7457>.		February 2015, <https://www.rfc-editor.org/info/rfc7457>.
	[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root		[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
	Servers by Running One on Loopback", RFC 7706,		Servers by Running One on Loopback", RFC 7706,
	DOI 10.17487/RFC7706, November 2015, <https://www.rfc-		DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
	editor.org/info/rfc7706>.		editor.org/info/rfc7706>.
			[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
			Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
			November 2016, <https://www.rfc-editor.org/info/rfc8020>.
	[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram		[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
	Transport Layer Security (DTLS)", RFC 8094,		Transport Layer Security (DTLS)", RFC 8094,
	DOI 10.17487/RFC8094, February 2017, <https://www.rfc-		DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
	editor.org/info/rfc8094>.		editor.org/info/rfc8094>.
	[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of		[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
	DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,		DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
	July 2017, <https://www.rfc-editor.org/info/rfc8198>.		July 2017, <https://www.rfc-editor.org/info/rfc8198>.
	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,		[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
End of changes. 26 change blocks.
	39 lines changed or deleted		50 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/