< draft-ietf-doh-dns-over-https-08.txt		draft-ietf-doh-dns-over-https-09.txt >
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Standards Track P. McManus		Intended status: Standards Track P. McManus
	Expires: November 17, 2018 Mozilla		Expires: November 25, 2018 Mozilla
	May 16, 2018		May 24, 2018
	DNS Queries over HTTPS (DOH)		DNS Queries over HTTPS (DOH)
	draft-ietf-doh-dns-over-https-08		draft-ietf-doh-dns-over-https-09
	Abstract		Abstract
	This document describes how to make DNS queries over HTTPS.		This document describes how to make DNS queries over HTTPS.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 November 17, 2018.		This Internet-Draft will expire on November 25, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 3		3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 3
	3.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4		3.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4
	4. Selection of DNS API Server . . . . . . . . . . . . . . . . . 4		4. Selection of DNS API Server . . . . . . . . . . . . . . . . . 4
	5. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4		5. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4		5.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4
	5.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5		5.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
	5.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 6		5.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 6
	5.2.1. HTTP Response Example . . . . . . . . . . . . . . . . 7		5.2.1. HTTP Response Example . . . . . . . . . . . . . . . . 7
	6. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8		6. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8		6.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8
	6.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10		6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10		6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10
	7. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . . . 10		7. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Registration of application/dns-message Media Type . . . 11		8.1. Registration of application/dns-message Media Type . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. Operational Considerations . . . . . . . . . . . . . . . . . 14		10. Operational Considerations . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 16		11.2. Informative References . . . . . . . . . . . . . . . . . 15
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Previous Work on DNS over HTTP or in Other Formats . . . . . . . 18		Previous Work on DNS over HTTP or in Other Formats . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document defines a specific protocol for sending DNS [RFC1035]		This document defines a specific protocol for sending DNS [RFC1035]
	queries and getting DNS responses over HTTP [RFC7540] using https		queries and getting DNS responses over HTTP [RFC7540] using https
	URIs (and therefore TLS [RFC5246] security for integrity and		URIs (and therefore TLS [RFC5246] security for integrity and
	confidentiality). Each DNS query-response pair is mapped into a HTTP		confidentiality). Each DNS query-response pair is mapped into a HTTP
	exchange.		exchange.
	The described approach is more than a tunnel over HTTP. It		The described approach is more than a tunnel over HTTP. It
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	o Supporting network-specific DNS64 [RFC6147]		o Supporting network-specific DNS64 [RFC6147]
	o Supporting other network-specific inferences from plaintext DNS		o Supporting other network-specific inferences from plaintext DNS
	queries		queries
	o Supporting insecure HTTP		o Supporting insecure HTTP
	4. Selection of DNS API Server		4. Selection of DNS API Server
	Before using a DNS API server for DNS resolution, the client MUST		A DNS API client uses configuration to select the URI, and thus the
	establish that the HTTP request URI is a trusted service for the DOH		DNS API server, used for resolution. A client MUST NOT use a DNS API
	query, in other words, a DNS API client MUST only use a DNS API		server simply because it was discovered, or because the client was
	server that is configured as trustworthy.		told to use the DNS API server by an untrusted party. [RFC2818]
			defines how HTTPS verifies the server's identity.
	A client MUST NOT use a DNS API server simply because it was
	discovered, or because the client was told to use the DNS API server
	by an untrusted party.
	This specification does not extend DNS resolution privileges to URIs		This specification does not extend DNS resolution privileges to URIs
	that are not recognized by the DNS API client as trusted DNS API		that are not recognized by the DNS API client as trusted DNS API
	servers. As such, use of untrusted servers is out of scope of this		servers. As such, use of untrusted servers is out of scope of this
	document.		document.
	5. The HTTP Exchange		5. The HTTP Exchange
	5.1. The HTTP Request		5.1. The HTTP Request
	skipping to change at page 13, line 45 ¶		skipping to change at page 12, line 45 ¶
	the security implications of HTTP caching for other protocols that		the security implications of HTTP caching for other protocols that
	use HTTP.		use HTTP.
	In the absence of DNSSEC information, a DNS API server can give a		In the absence of DNSSEC information, a DNS API server can give a
	client invalid data in response to a DNS query. A client MUST NOT		client invalid data in response to a DNS query. A client MUST NOT
	use arbitrary DNS API servers. Instead, a client MUST only use DNS		use arbitrary DNS API servers. Instead, a client MUST only use DNS
	API servers specified using mechanisms such as explicit		API servers specified using mechanisms such as explicit
	configuration. This does not guarantee protection against invalid		configuration. This does not guarantee protection against invalid
	data but reduces the risk.		data but reduces the risk.
	A client can use DNS over HTTPS as one of multiple mechanisms to
	obtain DNS data. If a client of this protocol encounters an HTTP
	error after sending a DNS query, and then falls back to a different
	DNS retrieval mechanism, doing so can weaken the privacy and
	authenticity expected by the user of the client.
	10. Operational Considerations		10. Operational Considerations
	Local policy considerations and similar factors mean different DNS		Local policy considerations and similar factors mean different DNS
	servers may provide different results to the same query: for instance		servers may provide different results to the same query: for instance
	in split DNS configurations [RFC6950]. It logically follows that the		in split DNS configurations [RFC6950]. It logically follows that the
	server which is queried can influence the end result. Therefore a		server which is queried can influence the end result. Therefore a
	client's choice of DNS server may affect the responses it gets to its		client's choice of DNS server may affect the responses it gets to its
	queries. For example, in the case of DNS64 [RFC6147], the choice		queries. For example, in the case of DNS64 [RFC6147], the choice
	could affect whether IPv6/IPv4 translation will work at all.		could affect whether IPv6/IPv4 translation will work at all.
	skipping to change at page 16, line 38 ¶		skipping to change at page 15, line 33 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	[CORS] "Cross-Origin Resource Sharing", n.d.,		[CORS] "Cross-Origin Resource Sharing", n.d.,
	<https://fetch.spec.whatwg.org/#http-cors-protocol>.		<https://fetch.spec.whatwg.org/#http-cors-protocol>.
			[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
			DOI 10.17487/RFC2818, May 2000,
			<https://www.rfc-editor.org/info/rfc2818>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale		[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
	Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,		Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
	<https://www.rfc-editor.org/info/rfc5861>.		<https://www.rfc-editor.org/info/rfc5861>.
End of changes. 9 change blocks.
	28 lines changed or deleted		23 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/