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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/