< draft-ietf-doh-dns-over-https-09.txt		draft-ietf-doh-dns-over-https-10.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 25, 2018 Mozilla		Expires: December 3, 2018 Mozilla
	May 24, 2018		June 01, 2018
	DNS Queries over HTTPS (DOH)		DNS Queries over HTTPS (DOH)
	draft-ietf-doh-dns-over-https-09		draft-ietf-doh-dns-over-https-10
	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 25, 2018.		This Internet-Draft will expire on December 3, 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 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	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 . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Registration of application/dns-message Media Type . . . 11		8.1. Registration of application/dns-message Media Type . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. Operational Considerations . . . . . . . . . . . . . . . . . 12		10. Operational Considerations . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 16
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Previous Work on DNS over HTTP or in Other Formats . . . . . . . 17		Previous Work on DNS over HTTP or in Other Formats . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	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
			Configuration, discovery, and updating of the URI Template [RFC6570]
			(see Section 5.1) is done out of band from this protocol. Note that
			configuration might be manual (such as a user typing URI Templates in
			a user interface for "options") or automatic (such as URI Templates
			being supplied in responses from DHCP or similar protocols). DNS API
			Servers MAY support more than one URI. This allows the different
			endpoints to have different properties such as different
			authentication requirements or service level guarantees.
	A DNS API client uses configuration to select the URI, and thus the		A DNS API client uses configuration to select the URI, and thus the
	DNS API server, used for resolution. A client MUST NOT use a DNS API		DNS API server, that is to be used for resolution. [RFC2818] defines
	server simply because it was discovered, or because the client was		how HTTPS verifies the DNS API server's identity.
	told to use the DNS API server by an untrusted party. [RFC2818]
	defines how HTTPS verifies the server's identity.
	This specification does not extend DNS resolution privileges to URIs		A DNS API client MUST NOT use a different URI simply because it was
	that are not recognized by the DNS API client as trusted DNS API		discovered outside of the client's configuration, or because a server
	servers. As such, use of untrusted servers is out of scope of this		offers an unsolicited response that appears to be a valid answer to a
	document.		DNS query. This specification does not extend DNS resolution
			privileges to URIs that are not recognized by the DNS API client as
			configured URIs. Such scenarios may create additional operational,
			tracking, and security hazards that require limitations for safe
			usage. A future specification may support this use case.
	5. The HTTP Exchange		5. The HTTP Exchange
	5.1. The HTTP Request		5.1. The HTTP Request
	A DNS API client encodes a single DNS query into an HTTP request		A DNS API client encodes a single DNS query into an HTTP request
	using either the HTTP GET or POST method and the other requirements		using either the HTTP GET or POST method and the other requirements
	of this section. The DNS API server defines the URI used by the		of this section. The DNS API server defines the URI used by the
	request through the use of a URI Template [RFC6570].		request through the use of a URI Template.
	Configuration and discovery of the URI Template is done out of band
	from this protocol. DNS API Servers MAY support more than one URI.
	This allows the different endpoints to have different properties such
	as different authentication requirements or service level guarantees.
	The URI Template defined in this document is processed without any		The URI Template defined in this document is processed without any
	variables when the HTTP method is POST. When the HTTP method is GET		variables when the HTTP method is POST. When the HTTP method is GET
	the single variable "dns" is defined as the content of the DNS		the single variable "dns" is defined as the content of the DNS
	request (as described in Section 7), encoded with base64url		request (as described in Section 7), encoded with base64url
	[RFC4648].		[RFC4648].
	Future specifications for new media types MUST define the variables		Future specifications for new media types MUST define the variables
	used for URI Template processing with this protocol.		used for URI Template processing with this protocol.
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 14 ¶
	When using the POST method, the data payload MUST NOT be encoded and		When using the POST method, the data payload MUST NOT be encoded and
	is used directly as the HTTP message body.		is used directly as the HTTP message body.
	DNS API clients using the DNS wire format MAY have one or more EDNS		DNS API clients using the DNS wire format MAY have one or more EDNS
	options [RFC6891] in the request.		options [RFC6891] in the request.
	The media type is "application/dns-message".		The media type is "application/dns-message".
	8. IANA Considerations		8. IANA Considerations
	8.1. Registration of application/dns-message Media Type
			8.1. Registration of application/dns-message Media Type
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type		Subject: Registration of MIME media type
	application/dns-message		application/dns-message
	MIME media type name: application		MIME media type name: application
	MIME subtype name: dns-message		MIME subtype name: dns-message
	Required parameters: n/a		Required parameters: n/a
	skipping to change at page 12, line 39 ¶		skipping to change at page 13, line 39 ¶
	types will provide more or less information from a DNS response so		types will provide more or less information from a DNS response so
	this choice may be affected by the response media type.		this choice may be affected by the response media type.
	Section 6.1 describes the interaction of this protocol with HTTP		Section 6.1 describes the interaction of this protocol with HTTP
	caching. An adversary that can control the cache used by the client		caching. An adversary that can control the cache used by the client
	can affect that client's view of the DNS. This is no different than		can affect that client's view of the DNS. This is no different than
	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. Section 4 disallows
	use arbitrary DNS API servers. Instead, a client MUST only use DNS		the use of DOH DNS responses that do not originate from configured
	API servers specified using mechanisms such as explicit		servers. This prohibition does not guarantee protection against
	configuration. This does not guarantee protection against invalid		invalid data, but it does reduce the risk.
	data but reduces the risk.
	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.
End of changes. 14 change blocks.
	35 lines changed or deleted		40 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/