Network Working Group P. Hoffman
Internet-Draft ICANN
Intended status: Standards Track P. McManus
Expires: November 25, 2018 Mozilla
May 24, 2018
DNS Queries over HTTPS (DOH)
draft-ietf-doh-dns-over-https-09
Abstract
This document describes how to make DNS queries over HTTPS.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hoffman & McManus Expires November 25, 2018 [Page 1]
Internet-Draft DNS Queries over HTTPS (DOH) May 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4
4. Selection of DNS API Server . . . . . . . . . . . . . . . . . 4
5. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4
5.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4
5.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
5.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 6
5.2.1. HTTP Response Example . . . . . . . . . . . . . . . . 7
6. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8
6.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10
7. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Registration of application/dns-message Media Type . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Operational Considerations . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Previous Work on DNS over HTTP or in Other Formats . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This document defines a specific protocol for sending DNS [RFC1035]
queries and getting DNS responses over HTTP [RFC7540] using https
URIs (and therefore TLS [RFC5246] security for integrity and
confidentiality). Each DNS query-response pair is mapped into a HTTP
exchange.
The described approach is more than a tunnel over HTTP. It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases. In addition to this media type negotiation, it aligns
itself with HTTP features such as caching, redirection, proxying,
authentication, and compression.
The integration with HTTP provides a transport suitable for both
existing DNS clients and native web applications seeking access to
the DNS.
Hoffman & McManus Expires November 25, 2018 [Page 2]
Internet-Draft DNS Queries over HTTPS (DOH) May 2018
Two primary uses cases were considered during this protocol's
development. They included preventing on-path devices from
interfering with DNS operations and allowing web applications to
access DNS information via existing browser APIs in a safe way
consistent with Cross Origin Resource Sharing (CORS) [CORS]. No
special effort has been taken to enable or prevent application to
other use cases. This document focuses on communication between DNS
clients (such as operating system stub resolvers) and recursive
resolvers.
2. Terminology
A server that supports this protocol is called a "DNS API server" to
differentiate it from a "DNS server" (one that only provides DNS
service over one or more of the other transport protocols
standardized for DNS). Similarly, a client that supports this
protocol is called a "DNS API client".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol Requirements
[[ RFC Editor: Please remove this entire section before publication.
]]
The protocol described here bases its design on the following
protocol requirements:
o The protocol must use normal HTTP semantics.
o The queries and responses must be able to be flexible enough to
express every DNS query that would normally be sent in DNS over
UDP (including queries and responses that use DNS extensions, but
not those that require multiple responses).
o The protocol must permit the addition of new formats for DNS
queries and responses.
o The protocol must ensure interoperability by specifying a single
format for requests and responses that is mandatory to implement.
That format must be able to support future modifications to the
DNS protocol including the inclusion of one or more EDNS options
(including those not yet defined).
Hoffman & McManus Expires November 25, 2018 [Page 3]
Internet-Draft DNS Queries over HTTPS (DOH) May 2018
o The protocol must use a secure transport that meets the
requirements for HTTPS.
3.1. Non-requirements
o Supporting network-specific DNS64 [RFC6147]
o Supporting other network-specific inferences from plaintext DNS
queries
o Supporting insecure HTTP
4. Selection of DNS API Server
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
server simply because it was discovered, or because the client was
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
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
document.
5. The HTTP Exchange
5.1. The 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
of this section. The DNS API server defines the URI used by the
request through the use of a URI Template [RFC6570].
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
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
request (as described in Section 7), encoded with base64url
[