idnits 2.17.1 draft-ietf-doh-dns-over-https-01.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 30, 2017) is 2369 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) -- Duplicate reference: RFC1035, mentioned in 'DNS', was also mentioned in 'RFC1035'. == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-dns-wireformat-http-01 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: May 3, 2018 Mozilla 6 October 30, 2017 8 DNS Queries over HTTPS 9 draft-ietf-doh-dns-over-https-01 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 May 3, 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 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 use case 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 unsecured DNS ([DNS]) or 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 security 139 model of the web [CORS] and also integrate the caching mechanisms of 140 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 To make a DNS API query, a DNS API client sends an HTTP request to 185 the URI of the DNS API. 187 The URI scheme MUST be https. 189 A client can be configured with a DNS API URI, or it can discover the 190 URI. This document defines a well-known URI path of "/.well-known/ 191 dns-query" so that a discovery process that produces a domain name or 192 domain name and port can be used to construct the DNS API URI. (See 193 Section 8 for the registration of this in the well-known URI 194 registry.) DNS API servers SHOULD use this well-known path to help 195 contextualize DNS Query requests that use server push [RFC7540]. 197 A DNS API Client encodes the DNS query into the HTTP request using 198 either the HTTP GET or POST methods. 200 When using the POST method, the DNS query is included as the message 201 body of the HTTP request and the Content-Type request header 202 indicates the media type of the message. POST-ed requests are 203 smaller than their GET equivalents. 205 When using the GET method, the URI path MUST contain a query 206 parameter of the form content-type=TTT and another of the form 207 body=BBBB, where "TTT" is the media type of the format used for the 208 body parameter, and "BBB" is the content of the body encoded with 209 base64url [RFC4648]. Using the GET method is friendlier to many HTTP 210 cache implementations. 212 The DNS API Client SHOULD include an HTTP "Accept:" request header to 213 say what type of content can be understood in response. The client 214 MUST be prepared to process "application/dns-udpwireformat" 215 Section 5.1 responses but MAY process any other type it receives. 217 In order to maximize cache friendliness, DNS API clients using media 218 formats that include DNS ID, such as application/dns-udpwireformat, 219 should use a DNS ID of 0 in every DNS request. HTTP semantics 220 correlate the request and response, thus eliminating the need for the 221 ID in a media type such as application/dns-udpwireformat. 223 DNS API clients can use HTTP/2 padding and compression in the same 224 way that other HTTP/2 clients use (or don't use) them. 226 5.1. DNS Wire Format 228 The media type is "application/dns-udpwireformat". The body is the 229 DNS on-the-wire format is defined in [RFC1035]. 231 When using the GET method, the body MUST be encoded with base64url 232 [RFC4648]. Padding characters for base64url MUST NOT be included. 234 When using the POST method, the body is not encoded. 236 DNS API clients using the DNS wire format MAY have one or more 237 EDNS(0) extensions [RFC6891] in the request. 239 5.2. Examples 241 For example, assume a DNS API server is following this specification 242 on origin https://dnsserver.example.net/ and the well-known path. 243 The DNS API client chooses to send its requests in appliation/dns- 244 udpwirefomat but indicates it can parse replies in that format or as 245 a JSON-based content type. 247 The examples uses HTTP/2 formatting from [RFC7540]. 249 A query for the IN A records for "www.example.com" with recursion 250 turned on using the GET method and a wireformat request would be: 252 :method = GET 253 :scheme = https 254 :authority = dnsserver.example.net 255 :path = /.well-known/dns-query? (no CR) 256 content-type=application/dns-udpwireformat& (no CR) 257 body=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB 258 accept = application/dns-udpwireformat, application/simpledns+json 260 The same DNS query, using the POST method would be: 262 :method = POST 263 :scheme = https 264 :authority = dnsserver.example.net 265 :path = /.well-known/dns-query 266 accept = application/dns-udpwireformat, application/simpledns+json 267 content-type = application/dns-udpwireformat 268 content-length = 33 270 <33 bytes represented by the following hex encoding> 271 abcd 0100 0001 0000 0000 0000 0377 7777 272 0765 7861 6d70 6c65 0363 6f6d 0000 0100 273 01 275 6. The HTTP Response 277 Different response media types will provide more or less information 278 from a DNS response. For example, one response type might include 279 the information from the DNS header bytes while another might omit 280 it. The amount and type of information that a media type gives is 281 solely up to the format, and not defined in this protocol. 283 At the time this is published, the response types are works in 284 progress. The only known response type is "application/dns- 285 udpwireformat", but it is possible that at least one JSON-based 286 response format will be defined in the future. 288 The DNS response for "application/dns-udpwireformat" in Section 5.1 289 MAY have one or more EDNS(0) extensions, depending on the extension 290 definition of the extensions given in the DNS request. 292 Native HTTP methods are used to correlate requests and responses. 293 Responses may be returned in a different temporal order than requests 294 were made using the protocols native multi-streaming functionality. 296 In the HTTP responses, the HTTP cache headers SHOULD be set to expire 297 at the same time as the shortest DNS TTL in the response. Because 298 DNS provides only caching but not revalidation semantics, DNS over 299 HTTP responses should not carry revalidation response headers (such 300 as Last-Modified: or Etag:) or return 304 responses. 302 A DNS API Server MUST be able to process application/dns- 303 udpwireformat request messages. 305 A DNS API Server SHOULD respond with HTTP status code 415 upon 306 receiving a media type it is unable to process. 308 This document does not change the definition of any HTTP response 309 codes or otherwise proscribe their use. 311 6.1. Example 313 This is an example response for a query for the IN A records for 314 "www.example.com" with recursion turned on. The response bears one 315 record with an address of 93.184.216.34 and a TTL of 128 seconds. 317 :status = 200 318 content-type = application/dns-udpwireformat 319 content-length = 64 320 cache-control = max-age=128 322 <64 bytes represented by the following hex encoding> 323 abcd 8180 0001 0001 0000 0000 0377 7777 324 0765 7861 6d70 6c65 0363 6f6d 0000 0100 326 0103 7777 7707 6578 616d 706c 6503 636f 327 6d00 0001 0001 0000 0080 0004 5db8 d822 329 7. HTTP Integration 331 This protocol MUST be used with https scheme URI [RFC7230]. 333 This protocol MUST use HTTP/2 [RFC7540] or its successors in order to 334 satisfy the security requirements of DNS over HTTPS. Further, the 335 messages in classic UDP based DNS [RFC1035] are inherently unordered 336 and have low overhead. A competitive HTTP transport needs to support 337 reordering, priority, parallelism, and header compression, all of 338 which are supported by HTTP/2 [RFC7540] or its successors. 340 8. IANA Considerations 342 8.1. Registration of Well-Known URI 344 This specification registers a Well-Known URI [RFC5785]: 346 o URI Suffix: dns-query 348 o Change Controller: IETF 350 o Specification Document(s): [this specification] 352 8.2. Registration of application/dns-udpwireformat Media Type 353 To: ietf-types@iana.org 354 Subject: Registration of MIME media type 355 pplication/dns-udpwireformat 357 MIME media type name: application 359 MIME subtype name: dns-udpwireformat 361 Required parameters: n/a 363 Optional parameters: n/a 365 Encoding considerations: This is a binary format. The contents are a 366 DNS message as defined in RFC 1035. The format used here is for DNS 367 over UDP, which is the format defined in the diagrams in RFC 1035. 369 Security considerations: The security considerations for carrying 370 this data are the same for carrying DNS without encryption. 372 Interoperability considerations: None. 374 Published specification: This document. 376 Applications that use this media type: 377 Systems that want to exchange full DNS messages. 379 Additional information: 381 Magic number(s): n/a 383 File extension(s): n/a 385 Macintosh file type code(s): n/a 387 Person & email address to contact for further information: 388 Paul Hoffman, paul.hoffman@icann.org 390 Intended usage: COMMON 392 Restrictions on usage: n/a 394 Author: Paul Hoffman, paul.hoffman@icann.org 396 Change controller: IESG 398 9. Security Considerations 400 Running DNS over HTTPS relies on the security of the underlying HTTP 401 connection. By requiring at least [RFC7540] levels of support for 402 TLS, this protocol expects to use current best practices for secure 403 transport. 405 Session level encryption has well known weaknesses with respect to 406 traffic analysis which might be particularly acute when dealing with 407 DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of 408 [RFC7540] provide some further advice on mitigations within an HTTP/2 409 context. 411 [[ From the WG charter: 413 The working group will analyze the security and privacy issues that 414 could arise from accessing DNS over HTTPS. In particular, the 415 working group will consider the interaction of DNS and HTTP caching. 417 ]] 419 A server that is acting both as a normal web server and a DNS API 420 server is in a position to choose which DNS names it forces a client 421 to resolve (through its web service) and also be the one to answer 422 those queries (through its DNS API service). An untrusted DNS API 423 server can thus easily cause damage by poisoning a client's cache 424 with names that the DNS API server chooses to poison. A client MUST 425 NOT trust a DNS API server simply because it was discovered, or 426 because the client was told to trust the DNS API server by an 427 untrusted party. Instead, a client MUST only trust DNS API server 428 that is configured as trustworthy. 430 [[ From the WG charter: 432 The working group may define mechanisms for discovery of DOH servers 433 similar to existing mechanisms for discovering other DNS servers if 434 the chairs determine that there is both sufficient interest and 435 working group consensus. 437 ]] 439 10. Acknowledgments 441 Joe Hildebrand contributed lots of material for a different iteration 442 of this document. Helpful early comments were given by Ben Schwartz 443 and Mark Nottingham. 445 11. References 447 11.1. Normative References 449 [RFC1035] Mockapetris, P., "Domain names - implementation and 450 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 451 November 1987, . 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, . 458 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 459 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 460 . 462 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 463 (TLS) Protocol Version 1.2", RFC 5246, 464 DOI 10.17487/RFC5246, August 2008, . 467 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 468 Uniform Resource Identifiers (URIs)", RFC 5785, 469 DOI 10.17487/RFC5785, April 2010, . 472 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 473 Protocol (HTTP/1.1): Message Syntax and Routing", 474 RFC 7230, DOI 10.17487/RFC7230, June 2014, 475 . 477 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 478 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 479 DOI 10.17487/RFC7540, May 2015, . 482 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 483 and P. Hoffman, "Specification for DNS over Transport 484 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 485 2016, . 487 11.2. Informative References 489 [CORS] W3C, "Cross-Origin Resource Sharing", 2014, 490 . 492 [DNS] Mockapetris, P., "Domain names - implementation and 493 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 494 November 1987, . 496 [I-D.ietf-dnsop-dns-wireformat-http] 497 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 498 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 499 (work in progress), March 2017. 501 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 502 Beijnum, "DNS64: DNS Extensions for Network Address 503 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 504 DOI 10.17487/RFC6147, April 2011, . 507 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 508 for DNS (EDNS(0))", STD 75, RFC 6891, 509 DOI 10.17487/RFC6891, April 2013, . 512 Appendix A. Previous Work on DNS over HTTP or in Other Formats 514 The following is an incomplete list of earlier work that related to 515 DNS over HTTP/1 or representing DNS data in other formats. 517 The list includes links to the tools.ietf.org site (because these 518 documents are all expired) and web sites of software. 520 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 522 o https://tools.ietf.org/html/draft-daley-dnsxml 524 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 526 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 528 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 530 Authors' Addresses 532 Paul Hoffman 533 ICANN 535 Email: paul.hoffman@icann.org 536 Patrick McManus 537 Mozilla 539 Email: pmcmanus@mozilla.com