idnits 2.17.1 draft-hoffman-dispatch-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 (June 17, 2017) is 2504 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: December 19, 2017 Mozilla 6 June 17, 2017 8 DNS Queries over HTTPS 9 draft-hoffman-dispatch-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 [ This paragraph is to be removed when this document is published as 26 an RFC ] Comments on this draft can be sent to the DNS over HTTP 27 mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 19, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 4 68 5. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4 69 5.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 5 70 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 72 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Registration of Well-Known URI . . . . . . . . . . . . . 8 76 8.2. Registration of application/dns-udpwireformat Media Type 8 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 11.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The Internet does not always provide end to end reachability for 88 native DNS. On-path network devices may spoof DNS responses, block 89 DNS requests, or just redirect DNS queries to different DNS servers 90 that give less-than-honest answers. 92 Over time, there have been many proposals for using HTTP and HTTPS as 93 a substrate for DNS queries and responses. To date, none of those 94 proposals have made it beyond early discussion, partially due to 95 disagreement about what the appropriate formatting should be and 96 partially because they did not follow HTTP best practices. 98 This document defines a specific protocol for sending DNS [RFC1035] 99 queries and getting DNS responses over modern versions of HTTP 100 [RFC7540] using https:// (and therefore TLS [RFC5246] security for 101 integrity and confidentiality). 103 The described approach is more than a tunnel over HTTP. It 104 establishes default media formatting types for requests and responses 105 but uses normal HTTP content negotiation mechanisms for selecting 106 alternatives that endpoints may prefer in anticipation of serving new 107 use cases. In addition to this media type negotiation, it aligns 108 itself with HTTP features such as caching, proxying, and compression. 110 The integration with HTTP provides a transport suitable for both 111 traditional DNS clients and native web applications seeking access to 112 the DNS. 114 2. Terminology 116 A server that supports this protocol is called a "DNS API server" to 117 differentiate it from a "DNS server" (one that uses the regular DNS 118 protocol). Similarly, a client that supports this protocol is called 119 a "DNS API client". 121 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 123 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 124 [RFC2119]. 126 3. Use Cases 128 There are two primary use cases for this protocol. 130 The primary one is to prevent on-path network devices from 131 interfering with native DNS operations. This interference includes, 132 but is not limited to, spoofing DNS responses, blocking DNS requests, 133 and tracking. HTTP authentication and proxy friendliness are 134 expected to make this protocol function in some environments where 135 DNS directly on TLS ([RFC7858]) would not. 137 A secondary use case is web applications that want to access DNS 138 information. Standardizing an HTTPS mechanism allows this to be done 139 in a way consistent with the cross-origin resource sharing [CORS] 140 security model of the web and also integrate the caching mechanisms 141 of DNS with those of HTTP. These applications may be interested in 142 using a different media type than traditional clients. 144 [ This paragraph is to be removed when this document is published as 145 an RFC ] Note that these use cases are different than those in a 146 similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http]. 147 The use case for that protocol is proxying DNS queries over HTTP 148 instead of over DNS itself. The use cases in this document all 149 involve query origination instead of proxying. 151 4. Protocol Requirements 153 The protocol described here bases its design on the following 154 protocol requirements: 156 o The protocol must use normal HTTP semantics. 158 o The queries and responses must be able to be flexible enough to 159 express every normal DNS query. 161 o The protocol must allow implementations to use HTTP's content 162 negotiation mechanism. 164 o The protocol must ensure interoperable media formats through a 165 mandatory to implement format wherein a query must be able to 166 contain one or more EDNS extensions, including those not yet 167 defined. 169 o The protocol must use a secure transport that meets the 170 requirements for modern https://. 172 4.1. Non-requirements 174 o Supporting network-specific DNS64 [RFC6147] 176 o Supporting other network-specific inferences from plaintext DNS 177 queries 179 o Supporting insecure HTTP 181 o Supporting legacy HTTP versions 183 5. The HTTP Request 185 The URI scheme MUST be https. 187 The path SHOULD be "/.well-known/dns-query" but a different path can 188 be used if the DNS API Client has prior knowledge about a DNS API 189 service on a different path at the origin being used. (See Section 8 190 for the registration of this in the well-known URI registry.) Using 191 the well-known path allows automated discovery of a DNS API Service, 192 and also helps contextualize DNS Query requests pushed over an active 193 HTTP/2 connection. 195 A DNS API Client encodes the DNS query into the HTTP request using 196 either the HTTP GET or POST methods. 198 When using the POST method, the DNS query is included as the message 199 body of the HTTP request and the Content-Type request header 200 indicates the media type of the message. POST-ed requests are 201 smaller than their GET equivalents. 203 When using the GET method, the URI path MUST contain a query 204 parameter of the form content-type=TTT and another of the form 205 body=BBBB, where "TTT" is the media type of the format used for the 206 body parameter, and "BBB" is the content of the body encoded with 207 base64url [RFC4648]. Using the GET method is friendlier to many HTTP 208 cache implementations. 210 The DNS API Client SHOULD include an HTTP "Accept:" request header to 211 say what type of content can be understood in response. The client 212 MUST be prepared to process "application/dns-udpwireformat" 213 {{dnswire} responses but MAY process any other type it receives. 215 In order to maximize cache friendliness, DNS API clients using media 216 formats that include DNS ID, such as application/dns-udpwireformat, 217 should use a DNS ID of 0 in every DNS request. HTTP semantics 218 correlate the request and response, thus eliminating the need for the 219 ID in a media type such as application/dns-udpwireformat. 221 DNS API clients can use HTTP/2 padding and compression in the same 222 way that other HTTP/2 clients use (or don't use) them. 224 5.1. DNS Wire Format 226 The media type is "application/dns-udpwireformat". The body is the 227 DNS on-the-wire format is defined in [RFC1035]. The body MUST be 228 encoded with base64url [RFC4648]. Padding characters for base64url 229 MUST NOT be included. 231 DNS API clients using the DNS wire format MAY have one or more 232 EDNS(0) extensions [RFC6891] in the request. 234 5.2. Examples 236 For example, assume a DNS API server is following this specification 237 on origin https://dnsserver.example.net/ and the well-known path. 238 The DNS API client chooses to send its requests in appliation/dns- 239 udpwirefomat but indicates it can parse replies in that format or as 240 a JSON-based content type. 242 The examples uses HTTP/2 formatting from [RFC7540]. 244 A query for the IN A records for "www.example.com" with recursion 245 turned on using the GET method and a wireformat request would be: 247 :method = GET 248 :scheme = https 249 :authority = dnsserver.example.net 250 :path = /.well-known/dns-query? (no CR) 251 content-type=application/dns-udpwireformat& (no CR) 252 body=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB 253 accept = application/dns-udpwireformat, application/simpledns+json 255 The same DNS query, using the POST method would be: 257 :method = POST 258 :scheme = https 259 :authority = dnsserver.example.net 260 :path = /.well-known/dns-query 261 accept = application/dns-udpwireformat, application/simpledns+json 262 content-type = application/dns-udpwireformat 263 content-length = 33 265 <33 bytes represented by the following hex encoding> 266 abcd 0100 0001 0000 0000 0000 0377 7777 267 0765 7861 6d70 6c65 0363 6f6d 0000 0100 268 01 270 6. The HTTP Response 272 Different response media types will provide more or less information 273 from a DNS response. For example, one response type might include 274 the information from the DNS header bytes while another might omit 275 it. The amount and type of information that a media type gives is 276 solely up to the format, and not defined in this protocol. 278 At the time this is published, the response types are works in 279 progress. The only known response type is "application/dns- 280 udpwireformat", but it is likely that at least one JSON-based 281 response format will be defined in the future. 283 The DNS response for "application/dns-udpwireformat" in Section 5.1 284 MAY have one or more EDNS(0) extensions, depending on the extension 285 definition of the extensions given in the DNS request. 287 Native HTTP methods are used to correlate requests and responses. 288 Responses may be returned in a different temporal order than requests 289 were made using the protocols native multi-streaming functionality. 291 In the HTTP responses, the HTTP cache headers SHOULD be set to expire 292 at the same time as the shortest DNS TTL in the response. Because 293 DNS provides only caching but not revalidation semantics, DNS over 294 HTTP responses should not carry revalidation response headers (such 295 as Last-Modified: or Etag:) or return 304 responses. 297 A DNS API Server MUST be able to process application/dns- 298 udpwireformat request messages. 300 A DNS API Server SHOULD respond with HTTP status code 415 upon 301 receiving a media type it is unable to process. 303 This document does not change the definition of any HTTP response 304 codes or otherwise proscribe their use. 306 6.1. Example 308 This is an example response for a query for the IN A records for 309 "www.example.com" with recursion turned on. The response bears one 310 record with an address of 93.184.216.34 and a TTL of 128 seconds. 312 :status = 200 313 content-type = application/dns-udpwireformat 314 content-length = 64 315 cache-control = max-age=128 317 <64 bytes represented by the following hex encoding> 318 abcd 8180 0001 0001 0000 0000 0377 7777 319 0765 7861 6d70 6c65 0363 6f6d 0000 0100 321 0103 7777 7707 6578 616d 706c 6503 636f 322 6d00 0001 0001 0000 0080 0004 5db8 d822 324 7. HTTP Integration 326 In order to satisfy the security requirements of DNS over HTTPS, this 327 protocol MUST use HTTP/2 [RFC7540] or its successors. HTTP/2 328 enforces a modern TLS profile necessary for achieving the security 329 requirements of this protocol. 331 This protocol MUST be used with https scheme URI [RFC7230]. 333 The messages in classic UDP based DNS [RFC1035] are inherently 334 unordered and have low overhead. A competitive HTTP transport needs 335 to support reordering, priority, parallelism, and header compression. 336 For this additional reason, this protocol MUST use HTTP/2 [RFC7540] 337 or its successors. 339 8. IANA Considerations 341 8.1. Registration of Well-Known URI 343 This specification registers a Well-Known URI [RFC5785]: 345 o URI Suffix: dns-query 347 o Change Controller: IETF 349 o Specification Document(s): [this specification] 351 8.2. Registration of application/dns-udpwireformat Media Type 352 To: ietf-types@iana.org 353 Subject: Registration of MIME media type 354 pplication/dns-udpwireformat 356 MIME media type name: application 358 MIME subtype name: dns-udpwireformat 360 Required parameters: n/a 362 Optional parameters: n/a 364 Encoding considerations: This is a binary format. The contents are a 365 DNS message as defined in RFC 1035. The format used here is for DNS 366 over UDP, which is the format defined in the diagrams in RFC 1035. 368 Security considerations: The security considerations for carrying 369 this data are the same for carrying DNS without encryption. 371 Interoperability considerations: None. 373 Published specification: This document. 375 Applications that use this media type: 376 Systems that want to exchange full DNS messages. 378 Additional information: 380 Magic number(s): n/a 382 File extension(s): n/a 384 Macintosh file type code(s): n/a 386 Person & email address to contact for further information: 387 Paul Hoffman, paul.hoffman@icann.org 389 Intended usage: COMMON 391 Restrictions on usage: n/a 393 Author: Paul Hoffman, paul.hoffman@icann.org 395 Change controller: IESG 397 9. Security Considerations 399 Running DNS over https:// relies on the security of the underlying 400 HTTP connection. By requiring at least [RFC7540] levels of support 401 for TLS this protocol expects to use current best practices for 402 secure transport. 404 Session level encryption has well known weaknesses with respect to 405 traffic analysis which might be particularly acute when dealing with 406 DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of 407 [RFC7540] provide some further advice on mitigations within an HTTP/2 408 context. 410 A server that is acting both as a normal web server and a DNS API 411 server is in a position to choose which DNS names it forces a client 412 to resolve (through its web service) and also be the one to answer 413 those queries (through its DNS API service). An untrusted DNS API 414 server can thus easily cause damage by poisoning a client's cache 415 with names that the DNS API server chooses to poison. A client MUST 416 NOT trust a DNS API server simply because it was discovered, or 417 because the client was told to trust the DNS API server by an 418 untrusted party. Instead, a client MUST only trust DNS API server 419 that is configured as trustworthy. 421 10. Acknowledgments 423 Joe Hildebrand contributed lots of material for a different iteration 424 of this document. Helpful early comments were given by Ben Schwartz 425 and Mark Nottingham. 427 11. References 429 11.1. Normative References 431 [RFC1035] Mockapetris, P., "Domain names - implementation and 432 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 433 November 1987, . 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 441 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 442 . 444 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 445 (TLS) Protocol Version 1.2", RFC 5246, 446 DOI 10.17487/RFC5246, August 2008, 447 . 449 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 450 Uniform Resource Identifiers (URIs)", RFC 5785, 451 DOI 10.17487/RFC5785, April 2010, 452 . 454 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 455 Protocol (HTTP/1.1): Message Syntax and Routing", 456 RFC 7230, DOI 10.17487/RFC7230, June 2014, 457 . 459 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 460 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 461 DOI 10.17487/RFC7540, May 2015, 462 . 464 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 465 and P. Hoffman, "Specification for DNS over Transport 466 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 467 2016, . 469 11.2. Informative References 471 [CORS] W3C, "Cross-Origin Resource Sharing", 2014, 472 . 474 [I-D.ietf-dnsop-dns-wireformat-http] 475 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 476 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 477 (work in progress), March 2017. 479 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 480 Beijnum, "DNS64: DNS Extensions for Network Address 481 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 482 DOI 10.17487/RFC6147, April 2011, 483 . 485 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 486 for DNS (EDNS(0))", STD 75, RFC 6891, 487 DOI 10.17487/RFC6891, April 2013, 488 . 490 Appendix A. Previous Work on DNS over HTTP or in Other Formats 492 The following is an incomplete list of earlier work that related to 493 DNS over HTTP/1 or representing DNS data in other formats. 495 The list includes links to the tools.ietf.org site (because these 496 documents are all expired) and web sites of software. 498 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 500 o https://tools.ietf.org/html/draft-daley-dnsxml 502 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 504 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 506 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 508 Authors' Addresses 510 Paul Hoffman 511 ICANN 513 Email: paul.hoffman@icann.org 515 Patrick McManus 516 Mozilla 518 Email: pmcmanus@mozilla.com