< draft-ietf-doh-dns-over-https-06.txt   draft-ietf-doh-dns-over-https-07.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: October 11, 2018 Mozilla Expires: October 13, 2018 Mozilla
April 09, 2018 April 11, 2018
DNS Queries over HTTPS DNS Queries over HTTPS
draft-ietf-doh-dns-over-https-06 draft-ietf-doh-dns-over-https-07
Abstract Abstract
This document describes how to run DNS service over HTTP (DOH) using This document describes how to run DNS service over HTTP (DOH) using
https:// URIs. https:// URIs.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 October 11, 2018. This Internet-Draft will expire on October 13, 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 23 skipping to change at page 2, line 23
4.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5 4.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
4.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 6 4.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 6
4.2.1. HTTP Response Example . . . . . . . . . . . . . . . . 7 4.2.1. HTTP Response Example . . . . . . . . . . . . . . . . 7
5. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7 5. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 7 5.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 7
5.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 9 5.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 9
6. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . . . 9 6. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Registration of message/dns Media Type . . . . . . . . . 10 7.1. Registration of application/dns-message Media Type . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Operational Considerations . . . . . . . . . . . . . . . . . 13 9. Operational Considerations . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Previous Work on DNS over HTTP or in Other Formats . 16 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
skipping to change at page 4, line 47 skipping to change at page 4, line 47
body of the HTTP request and the Content-Type request header body of the HTTP request and the Content-Type request header
indicates the media type of the message. POST-ed requests are indicates the media type of the message. POST-ed requests are
smaller than their GET equivalents. smaller than their GET equivalents.
Using the GET method is friendlier to many HTTP cache Using the GET method is friendlier to many HTTP cache
implementations. implementations.
The DNS API client SHOULD include an HTTP "Accept" request header to The DNS API client SHOULD include an HTTP "Accept" request header to
indicate what type of content can be understood in response. indicate what type of content can be understood in response.
Irrespective of the value of the Accept request header, the client Irrespective of the value of the Accept request header, the client
MUST be prepared to process "message/dns" (as described in Section 6) MUST be prepared to process "application/dns-message" (as described
responses but MAY also process any other type it receives. in Section 6) responses but MAY also process any other type it
receives.
In order to maximize cache friendliness, DNS API clients using media In order to maximize cache friendliness, DNS API clients using media
formats that include DNS ID, such as message/dns, SHOULD use a DNS ID formats that include DNS ID, such as application/dns-message, SHOULD
of 0 in every DNS request. HTTP correlates the request and response, use a DNS ID of 0 in every DNS request. HTTP correlates the request
thus eliminating the need for the ID in a media type such as message/ and response, thus eliminating the need for the ID in a media type
dns. The use of a varying DNS ID can cause semantically equivalent such as application/dns-message. The use of a varying DNS ID can
DNS queries to be cached separately. cause semantically equivalent DNS queries to be cached separately.
DNS API clients can use HTTP/2 padding and compression in the same DNS API clients can use HTTP/2 padding and compression in the same
way that other HTTP/2 clients use (or don't use) them. way that other HTTP/2 clients use (or don't use) them.
4.1.1. HTTP Request Examples 4.1.1. HTTP Request Examples
These examples use HTTP/2 style formatting from [RFC7540]. These examples use HTTP/2 style formatting from [RFC7540].
These examples use a DNS API service with a URI Template of These examples use a DNS API service with a URI Template of
"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A
records. records.
The requests are represented as message/dns typed bodies. The requests are represented as application/dns-message typed bodies.
The first example request uses GET to request www.example.com The first example request uses GET to request www.example.com
:method = GET :method = GET
:scheme = https :scheme = https
:authority = dnsserver.example.net :authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB :path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = message/dns accept = application/dns-message
The same DNS query for www.example.com, using the POST method would The same DNS query for www.example.com, using the POST method would
be: be:
:method = POST :method = POST
:scheme = https :scheme = https
:authority = dnsserver.example.net :authority = dnsserver.example.net
:path = /dns-query :path = /dns-query
accept = message/dns accept = application/dns-message
content-type = message/dns content-type = application/dns-message
content-length = 33 content-length = 33
<33 bytes represented by the following hex encoding> <33 bytes represented by the following hex encoding>
00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01 01
Finally, a GET based query for a.62characterlabel-makes-base64url- Finally, a GET based query for a.62characterlabel-makes-base64url-
distinct-from-standard-base64.example.com is shown as an example to distinct-from-standard-base64.example.com is shown as an example to
emphasize that the encoding alphabet of base64url is different than emphasize that the encoding alphabet of base64url is different than
skipping to change at page 6, line 18 skipping to change at page 6, line 18
61 6e 64 61 72 64 2d 62 61 73 65 36 34 07 65 78 61 6e 64 61 72 64 2d 62 61 73 65 36 34 07 65 78
61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01
:method = GET :method = GET
:scheme = https :scheme = https
:authority = dnsserver.example.net :authority = dnsserver.example.net
:path = /dns-query? (no space or CR) :path = /dns-query? (no space or CR)
dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR) dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR)
bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR) bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR)
dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ
accept = message/dns accept = application/dns-message
4.2. The HTTP Response 4.2. The HTTP Response
An HTTP response with a 2xx status code ([RFC7231] Section 6.3) An HTTP response with a 2xx status code ([RFC7231] Section 6.3)
indicates a valid DNS response to the query made in the HTTP request. indicates a valid DNS response to the query made in the HTTP request.
A valid DNS response includes both success and failure responses. A valid DNS response includes both success and failure responses.
For example, a DNS failure response such as SERVFAIL or NXDOMAIN will For example, a DNS failure response such as SERVFAIL or NXDOMAIN will
be the message in a successful 2xx HTTP response even though there be the message in a successful 2xx HTTP response even though there
was a failure at the DNS layer. Responses with non-successful HTTP was a failure at the DNS layer. Responses with non-successful HTTP
status codes do not contain DNS answers to the question in the status codes do not contain DNS answers to the question in the
skipping to change at page 6, line 41 skipping to change at page 6, line 41
make new requests to satisfy the original question. make new requests to satisfy the original question.
Different response media types will provide more or less information Different response media types will provide more or less information
from a DNS response. For example, one response type might include from a DNS response. For example, one response type might include
the information from the DNS header bytes while another might omit the information from the DNS header bytes while another might omit
it. The amount and type of information that a media type gives is it. The amount and type of information that a media type gives is
solely up to the format, and not defined in this protocol. solely up to the format, and not defined in this protocol.
At the time this is published, the response types are works in At the time this is published, the response types are works in
progress. The only response type defined in this document is progress. The only response type defined in this document is
"message/dns", but it is possible that other response formats will be "application/dns-message", but it is possible that other response
defined in the future. formats will be defined in the future.
The DNS response for "message/dns" in Section 6 MAY have one or more The DNS response for "application/dns-message" in Section 6 MAY have
EDNS options, depending on the extension definition of the extensions one or more EDNS options, depending on the extension definition of
given in the DNS request. the extensions given in the DNS request.
Each DNS request-response pair is matched to one HTTP exchange. The Each DNS request-response pair is matched to one HTTP exchange. The
responses may be processed and transported in any order using HTTP's responses may be processed and transported in any order using HTTP's
multi-streaming functionality ([RFC7540] Section 5). multi-streaming functionality ([RFC7540] Section 5).
Section 5.1 discusses the relationship between DNS and HTTP response Section 5.1 discusses the relationship between DNS and HTTP response
caching. caching.
A DNS API server MUST be able to process message/dns request A DNS API server MUST be able to process application/dns-message
messages. request messages.
A DNS API server SHOULD respond with HTTP status code 415 A DNS API server SHOULD respond with HTTP status code 415
(Unsupported Media Type) upon receiving a media type it is unable to (Unsupported Media Type) upon receiving a media type it is unable to
process. process.
4.2.1. HTTP Response Example 4.2.1. HTTP Response Example
This is an example response for a query for the IN A records for This is an example response for a query for the IN A records for
"www.example.com" with recursion turned on. The response bears one "www.example.com" with recursion turned on. The response bears one
record with an address of 192.0.2.1 and a TTL of 128 seconds. record with an address of 192.0.2.1 and a TTL of 128 seconds.
:status = 200 :status = 200
content-type = message/dns content-type = application/dns-message
content-length = 64 content-length = 64
cache-control = max-age=128 cache-control = max-age=128
<64 bytes represented by the following hex encoding> <64 bytes represented by the following hex encoding>
00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f
6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01
5. HTTP Integration 5. HTTP Integration
skipping to change at page 9, line 34 skipping to change at page 9, line 34
is implicit in the selection of URI. For HTTP server push ([RFC7540] is implicit in the selection of URI. For HTTP server push ([RFC7540]
Section 8.2) extra care must be taken to ensure that the pushed URI Section 8.2) extra care must be taken to ensure that the pushed URI
is one that the client would have directed the same query to if the is one that the client would have directed the same query to if the
client had initiated the request. This specification does not extend client had initiated the request. This specification does not extend
DNS resolution privileges to URIs that are not recognized by the DNS resolution privileges to URIs that are not recognized by the
client as trusted DNS API servers. client as trusted DNS API servers.
5.4. Content Negotiation 5.4. Content Negotiation
In order to maximize interoperability, DNS API clients and DNS API In order to maximize interoperability, DNS API clients and DNS API
servers MUST support the "message/dns" media type. Other media types servers MUST support the "application/dns-message" media type. Other
MAY be used as defined by HTTP Content Negotiation ([RFC7231] media types MAY be used as defined by HTTP Content Negotiation
Section 3.4). ([RFC7231] Section 3.4).
6. DNS Wire Format 6. DNS Wire Format
The data payload is the DNS on-the-wire format defined in [RFC1035]. The data payload is the DNS on-the-wire format defined in [RFC1035].
The format is for DNS over UDP. Note that this is different than the The format is for DNS over UDP. Note that this is different than the
wire format used in [RFC7858]. Also note that while [RFC1035] says wire format used in [RFC7858]. Also note that while [RFC1035] says
"Messages carried by UDP are restricted to 512 bytes", that was later "Messages carried by UDP are restricted to 512 bytes", that was later
updated by [RFC6891], and this protocol allows DNS on-the-wire format updated by [RFC6891], and this protocol allows DNS on-the-wire format
payloads of any size. payloads of any size.
skipping to change at page 10, line 11 skipping to change at page 10, line 11
base64url [RFC4648] and then provided as a variable named "dns" to base64url [RFC4648] and then provided as a variable named "dns" to
the URI Template expansion. Padding characters for base64url MUST the URI Template expansion. Padding characters for base64url MUST
NOT be included. NOT be included.
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 "message/dns". The media type is "application/dns-message".
7. IANA Considerations 7. IANA Considerations
7.1. Registration of message/dns Media Type 7.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
message/dns application/dns-message
MIME media type name: message MIME media type name: application
MIME subtype name: dns MIME subtype name: dns-message
Required parameters: n/a Required parameters: n/a
Optional parameters: n/a Optional parameters: n/a
Encoding considerations: This is a binary format. The contents are a Encoding considerations: This is a binary format. The contents are a
DNS message as defined in RFC 1035. The format used here is for DNS DNS message as defined in RFC 1035. The format used here is for DNS
over UDP, which is the format defined in the diagrams in RFC 1035. over UDP, which is the format defined in the diagrams in RFC 1035.
Security considerations: The security considerations for carrying Security considerations: The security considerations for carrying
 End of changes. 20 change blocks. 
33 lines changed or deleted 34 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/