Network Working Group P. Hoffman
Internet-Draft ICANN
Intended status: Standards Track P. McManus
Expires: September 22, 2018 Mozilla
March 21, 2018
DNS Queries over HTTPS
draft-ietf-doh-dns-over-https-04
Abstract
This document describes how to run DNS service over HTTP using
https:// URIs.
[[ There is a repository for this draft at https://github.com/dohwg/
draft-ietf-doh-dns-over-https [1] ]].
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 September 22, 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
Hoffman & McManus Expires September 22, 2018 [Page 1]
Internet-Draft DNS Queries over HTTPS March 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4
4. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4
4.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 5
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
5. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8
6.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Registration of application/dns-udpwireformat Media Type 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Operational Considerations . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Previous Work on DNS over HTTP or in Other Formats . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The Internet does not always provide end to end reachability for
native DNS. On-path network devices may spoof DNS responses, block
DNS requests, or just redirect DNS queries to different DNS servers
that give less-than-honest answers. These are also sometimes
delivered with poor performance or reduced feature sets.
Over time, there have been many proposals for using HTTP and HTTPS as
a substrate for DNS queries and responses. To date, none of those
proposals have made it beyond early discussion, partially due to
disagreement about what the appropriate formatting should be and
partially because they did not follow HTTP best practices.
This document defines a specific protocol for sending DNS [RFC1035]
queries and getting DNS responses over HTTP [RFC7540] using https://
(and therefore TLS [RFC5246] security for integrity and
Hoffman & McManus Expires September 22, 2018 [Page 2]
Internet-Draft DNS Queries over HTTPS March 2018
confidentiality). Each DNS query-response pair is mapped into a HTTP
request-response pair.
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
traditional DNS clients and native web applications seeking access to
the DNS.
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]. There
are certainly other uses for this work.
2. Terminology
A server that supports this protocol is called a "DNS API server" to
differentiate it from a "DNS server" (one that uses the regular DNS
protocol). 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, RFC8174 [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol Requirements
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 normal DNS query.
o The protocol must allow implementations to use HTTP's content
negotiation mechanism.
Hoffman & McManus Expires September 22, 2018 [Page 3]
Internet-Draft DNS Queries over HTTPS March 2018
o The protocol must ensure interoperable media formats through a
mandatory to implement format wherein a query must be able to
contain future modifications to the DNS protocol including the
inclusion of one or more EDNS extensions (including those not yet
defined).
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
o Supporting legacy HTTP versions
4. The HTTP Request
To make a DNS API query 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. Configuration and discovery of the URI is
done out of band from this protocol.
When using the POST method the DNS query is included as the message
body of the HTTP request and the Content-Type request header
indicates the media type of the message. POST-ed requests are
smaller than their GET equivalents.
When using the GET method the URI path MUST contain a query parameter
name-value pair [QUERYPARAMETER] with the name of "ct" and a value
indicating the media-format used for the dns parameter. The value
may either be an explicit media type (e.g. ct=application/dns-
udpwireformat&dns=...) or it may be empty. An empty value indicates
the default application/dns-udpwireformat type (e.g. ct&dns=...).
When using the GET method the URI path MUST contain a query parameter
with the name of "dns". The value of the parameter is the content of
the request potentially encoded with base64url [