idnits 2.17.1 draft-ietf-doh-dns-over-https-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 18, 2017) is 2381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-dns-wireformat-http-01 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track P. McManus 5 Expires: April 21, 2018 Mozilla 6 October 18, 2017 8 DNS Queries over HTTPS 9 draft-ietf-doh-dns-over-https-00 11 Abstract 13 DNS queries sometimes experience problems with end to end 14 connectivity at times and places where HTTPS flows freely. 16 HTTPS provides the most practical mechanism for reliable end to end 17 communication. Its use of TLS provides integrity and confidentiality 18 guarantees and its use of HTTP allows it to interoperate with 19 proxies, firewalls, and authentication systems where required for 20 transit. 22 This document describes how to run DNS service over HTTP using 23 https:// URIs. 25 [[ There is a repository for this draft at 26 https://github.com/paulehoffman/draft-ietf-doh-dns-over-https ]]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 21, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4 67 5. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4 68 5.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 5 69 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Registration of Well-Known URI . . . . . . . . . . . . . 8 75 8.2. Registration of application/dns-udpwireformat Media Type 8 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 11.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 The Internet does not always provide end to end reachability for 87 native DNS. On-path network devices may spoof DNS responses, block 88 DNS requests, or just redirect DNS queries to different DNS servers 89 that give less-than-honest answers. 91 Over time, there have been many proposals for using HTTP and HTTPS as 92 a substrate for DNS queries and responses. To date, none of those 93 proposals have made it beyond early discussion, partially due to 94 disagreement about what the appropriate formatting should be and 95 partially because they did not follow HTTP best practices. 97 This document defines a specific protocol for sending DNS [RFC1035] 98 queries and getting DNS responses over modern versions of HTTP 99 [RFC7540] using https:// (and therefore TLS [RFC5246] security for 100 integrity and confidentiality). 102 The described approach is more than a tunnel over HTTP. It 103 establishes default media formatting types for requests and responses 104 but uses normal HTTP content negotiation mechanisms for selecting 105 alternatives that endpoints may prefer in anticipation of serving new 106 use cases. In addition to this media type negotiation, it aligns 107 itself with HTTP features such as caching, proxying, and compression. 109 The integration with HTTP provides a transport suitable for both 110 traditional DNS clients and native web applications seeking access to 111 the DNS. 113 2. Terminology 115 A server that supports this protocol is called a "DNS API server" to 116 differentiate it from a "DNS server" (one that uses the regular DNS 117 protocol). Similarly, a client that supports this protocol is called 118 a "DNS API client". 120 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 121 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 122 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 123 [RFC2119]. 125 3. Use Cases 127 There are two primary use cases for this protocol. 129 The primary one is to prevent on-path network devices from 130 interfering with native DNS operations. This interference includes, 131 but is not limited to, spoofing DNS responses, blocking DNS requests, 132 and tracking. HTTP authentication and proxy friendliness are 133 expected to make this protocol function in some environments where 134 DNS directly on TLS ([RFC7858]) would not. 136 A secondary use case is web applications that want to access DNS 137 information. Standardizing an HTTPS mechanism allows this to be done 138 in a way consistent with the cross-origin resource sharing [CORS] 139 security model of the web and also integrate the caching mechanisms 140 of DNS with those of HTTP. These applications may be interested in 141 using a different media type than traditional clients. 143 [ This paragraph is to be removed when this document is published as 144 an RFC ] Note that these use cases are different than those in a 145 similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http]. 146 The use case for that protocol is proxying DNS queries over HTTP 147 instead of over DNS itself. The use cases in this document all 148 involve query origination instead of proxying. 150 4. Protocol Requirements 152 The protocol described here bases its design on the following 153 protocol requirements: 155 o The protocol must use normal HTTP semantics. 157 o The queries and responses must be able to be flexible enough to 158 express every normal DNS query. 160 o The protocol must allow implementations to use HTTP's content 161 negotiation mechanism. 163 o The protocol must ensure interoperable media formats through a 164 mandatory to implement format wherein a query must be able to 165 contain one or more EDNS extensions, including those not yet 166 defined. 168 o The protocol must use a secure transport that meets the 169 requirements for modern https://. 171 4.1. Non-requirements 173 o Supporting network-specific DNS64 [RFC6147] 175 o Supporting other network-specific inferences from plaintext DNS 176 queries 178 o Supporting insecure HTTP 180 o Supporting legacy HTTP versions 182 5. The HTTP Request 184 The URI scheme MUST be https. 186 The path SHOULD be "/.well-known/dns-query" but a different path can 187 be used if the DNS API Client has prior knowledge about a DNS API 188 service on a different path at the origin being used. (See Section 8 189 for the registration of this in the well-known URI registry.) Using 190 the well-known path allows automated discovery of a DNS API Service, 191 and also helps contextualize DNS Query requests pushed over an active 192 HTTP/2 connection. 194 A DNS API Client encodes the DNS query into the HTTP request using 195 either the HTTP GET or POST methods. 197 When using the POST method, the DNS query is included as the message 198 body of the HTTP request and the Content-Type request header 199 indicates the media type of the message. POST-ed requests are 200 smaller than their GET equivalents. 202 When using the GET method, the URI path MUST contain a query 203 parameter of the form content-type=TTT and another of the form 204 body=BBBB, where "TTT" is the media type of the format used for the 205 body parameter, and "BBB" is the content of the body encoded with 206 base64url [RFC4648]. Using the GET method is friendlier to many HTTP 207 cache implementations. 209 The DNS API Client SHOULD include an HTTP "Accept:" request header to 210 say what type of content can be understood in response. The client 211 MUST be prepared to process "application/dns-udpwireformat" 212 {{dnswire} responses but MAY process any other type it receives. 214 In order to maximize cache friendliness, DNS API clients using media 215 formats that include DNS ID, such as application/dns-udpwireformat, 216 should use a DNS ID of 0 in every DNS request. HTTP semantics 217 correlate the request and response, thus eliminating the need for the 218 ID in a media type such as application/dns-udpwireformat. 220 DNS API clients can use HTTP/2 padding and compression in the same 221 way that other HTTP/2 clients use (or don't use) them. 223 5.1. DNS Wire Format 225 The media type is "application/dns-udpwireformat". The body is the 226 DNS on-the-wire format is defined in [RFC1035]. The body MUST be 227 encoded with base64url [RFC4648]. Padding characters for base64url 228 MUST NOT be included. 230 DNS API clients using the DNS wire format MAY have one or more 231 EDNS(0) extensions [RFC6891] in the request. 233 5.2. Examples 235 For example, assume a DNS API server is following this specification 236 on origin https://dnsserver.example.net/ and the well-known path. 237 The DNS API client chooses to send its requests in appliation/dns- 238 udpwirefomat but indicates it can parse replies in that format or as 239 a JSON-based content type. 241 The examples uses HTTP/2 formatting from [RFC7540]. 243 A query for the IN A records for "www.example.com" with recursion 244 turned on using the GET method and a wireformat request would be: 246 :method = GET 247 :scheme = https 248 :authority = dnsserver.example.net 249 :path = /.well-known/dns-query? (no CR) 250 content-type=application/dns-udpwireformat& (no CR) 251 body=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB 252 accept = application/dns-udpwireformat, application/simpledns+json 254 The same DNS query, using the POST method would be: 256 :method = POST 257 :scheme = https 258 :authority = dnsserver.example.net 259 :path = /.well-known/dns-query 260 accept = application/dns-udpwireformat, application/simpledns+json 261 content-type = application/dns-udpwireformat 262 content-length = 33 264 <33 bytes represented by the following hex encoding> 265 abcd 0100 0001 0000 0000 0000 0377 7777 266 0765 7861 6d70 6c65 0363 6f6d 0000 0100 267 01 269 6. The HTTP Response 271 Different response media types will provide more or less information 272 from a DNS response. For example, one response type might include 273 the information from the DNS header bytes while another might omit 274 it. The amount and type of information that a media type gives is 275 solely up to the format, and not defined in this protocol. 277 At the time this is published, the response types are works in 278 progress. The only known response type is "application/dns- 279 udpwireformat", but it is likely that at least one JSON-based 280 response format will be defined in the future. 282 The DNS response for "application/dns-udpwireformat" in Section 5.1 283 MAY have one or more EDNS(0) extensions, depending on the extension 284 definition of the extensions given in the DNS request. 286 Native HTTP methods are used to correlate requests and responses. 287 Responses may be returned in a different temporal order than requests 288 were made using the protocols native multi-streaming functionality. 290 In the HTTP responses, the HTTP cache headers SHOULD be set to expire 291 at the same time as the shortest DNS TTL in the response. Because 292 DNS provides only caching but not revalidation semantics, DNS over 293 HTTP responses should not carry revalidation response headers (such 294 as Last-Modified: or Etag:) or return 304 responses. 296 A DNS API Server MUST be able to process application/dns- 297 udpwireformat request messages. 299 A DNS API Server SHOULD respond with HTTP status code 415 upon 300 receiving a media type it is unable to process. 302 This document does not change the definition of any HTTP response 303 codes or otherwise proscribe their use. 305 6.1. Example 307 This is an example response for a query for the IN A records for 308 "www.example.com" with recursion turned on. The response bears one 309 record with an address of 93.184.216.34 and a TTL of 128 seconds. 311 :status = 200 312 content-type = application/dns-udpwireformat 313 content-length = 64 314 cache-control = max-age=128 316 <64 bytes represented by the following hex encoding> 317 abcd 8180 0001 0001 0000 0000 0377 7777 318 0765 7861 6d70 6c65 0363 6f6d 0000 0100 320 0103 7777 7707 6578 616d 706c 6503 636f 321 6d00 0001 0001 0000 0080 0004 5db8 d822 323 7. HTTP Integration 325 In order to satisfy the security requirements of DNS over HTTPS, this 326 protocol MUST use HTTP/2 [RFC7540] or its successors. HTTP/2 327 enforces a modern TLS profile necessary for achieving the security 328 requirements of this protocol. 330 This protocol MUST be used with https scheme URI [RFC7230]. 332 The messages in classic UDP based DNS [RFC1035] are inherently 333 unordered and have low overhead. A competitive HTTP transport needs 334 to support reordering, priority, parallelism, and header compression. 335 For this additional reason, this protocol MUST use HTTP/2 [RFC7540] 336 or its successors. 338 8. IANA Considerations 340 8.1. Registration of Well-Known URI 342 This specification registers a Well-Known URI [RFC5785]: 344 o URI Suffix: dns-query 346 o Change Controller: IETF 348 o Specification Document(s): [this specification] 350 8.2. Registration of application/dns-udpwireformat Media Type 351 To: ietf-types@iana.org 352 Subject: Registration of MIME media type 353 pplication/dns-udpwireformat 355 MIME media type name: application 357 MIME subtype name: dns-udpwireformat 359 Required parameters: n/a 361 Optional parameters: n/a 363 Encoding considerations: This is a binary format. The contents are a 364 DNS message as defined in RFC 1035. The format used here is for DNS 365 over UDP, which is the format defined in the diagrams in RFC 1035. 367 Security considerations: The security considerations for carrying 368 this data are the same for carrying DNS without encryption. 370 Interoperability considerations: None. 372 Published specification: This document. 374 Applications that use this media type: 375 Systems that want to exchange full DNS messages. 377 Additional information: 379 Magic number(s): n/a 381 File extension(s): n/a 383 Macintosh file type code(s): n/a 385 Person & email address to contact for further information: 386 Paul Hoffman, paul.hoffman@icann.org 388 Intended usage: COMMON 390 Restrictions on usage: n/a 392 Author: Paul Hoffman, paul.hoffman@icann.org 394 Change controller: IESG 396 9. Security Considerations 398 Running DNS over https:// relies on the security of the underlying 399 HTTP connection. By requiring at least [RFC7540] levels of support 400 for TLS this protocol expects to use current best practices for 401 secure transport. 403 Session level encryption has well known weaknesses with respect to 404 traffic analysis which might be particularly acute when dealing with 405 DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of 406 [RFC7540] provide some further advice on mitigations within an HTTP/2 407 context. 409 A server that is acting both as a normal web server and a DNS API 410 server is in a position to choose which DNS names it forces a client 411 to resolve (through its web service) and also be the one to answer 412 those queries (through its DNS API service). An untrusted DNS API 413 server can thus easily cause damage by poisoning a client's cache 414 with names that the DNS API server chooses to poison. A client MUST 415 NOT trust a DNS API server simply because it was discovered, or 416 because the client was told to trust the DNS API server by an 417 untrusted party. Instead, a client MUST only trust DNS API server 418 that is configured as trustworthy. 420 10. Acknowledgments 422 Joe Hildebrand contributed lots of material for a different iteration 423 of this document. Helpful early comments were given by Ben Schwartz 424 and Mark Nottingham. 426 11. References 428 11.1. Normative References 430 [RFC1035] Mockapetris, P., "Domain names - implementation and 431 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 432 November 1987, . 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, 436 DOI 10.17487/RFC2119, March 1997, . 439 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 440 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 441 . 443 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 444 (TLS) Protocol Version 1.2", RFC 5246, 445 DOI 10.17487/RFC5246, August 2008, . 448 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 449 Uniform Resource Identifiers (URIs)", RFC 5785, 450 DOI 10.17487/RFC5785, April 2010, . 453 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 454 Protocol (HTTP/1.1): Message Syntax and Routing", 455 RFC 7230, DOI 10.17487/RFC7230, June 2014, 456 . 458 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 459 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 460 DOI 10.17487/RFC7540, May 2015, . 463 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 464 and P. Hoffman, "Specification for DNS over Transport 465 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 466 2016, . 468 11.2. Informative References 470 [CORS] W3C, "Cross-Origin Resource Sharing", 2014, 471 . 473 [I-D.ietf-dnsop-dns-wireformat-http] 474 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 475 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 476 (work in progress), March 2017. 478 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 479 Beijnum, "DNS64: DNS Extensions for Network Address 480 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 481 DOI 10.17487/RFC6147, April 2011, . 484 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 485 for DNS (EDNS(0))", STD 75, RFC 6891, 486 DOI 10.17487/RFC6891, April 2013, . 489 Appendix A. Previous Work on DNS over HTTP or in Other Formats 491 The following is an incomplete list of earlier work that related to 492 DNS over HTTP/1 or representing DNS data in other formats. 494 The list includes links to the tools.ietf.org site (because these 495 documents are all expired) and web sites of software. 497 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 499 o https://tools.ietf.org/html/draft-daley-dnsxml 501 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 503 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 505 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 507 Authors' Addresses 509 Paul Hoffman 510 ICANN 512 Email: paul.hoffman@icann.org 514 Patrick McManus 515 Mozilla 517 Email: pmcmanus@mozilla.com