idnits 2.17.00 (12 Aug 2021) /tmp/idnits29690/draft-hoffman-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 (May 03, 2017) is 1844 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) == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-dns-wireformat-http-01 Summary: 2 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: November 4, 2017 Mozilla 6 May 03, 2017 8 DNS Queries over HTTPS 9 draft-hoffman-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 November 4, 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. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 7 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 11.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 The Internet does not always provide end to end reachability for 85 native DNS. On-path network devices may spoof DNS responses, block 86 DNS requests, or just redirect DNS queries to different DNS servers 87 that give less-than-honest answers. 89 Over time, there have been many proposals for using HTTP and HTTPS as 90 a substrate for DNS queries and responses. To date, none of those 91 proposals have made it beyond early discussion, partially due to 92 disagreement about what the appropriate formatting should be and 93 partially because they did not follow HTTP best practices. 95 This document defines a specific protocol for sending DNS [RFC1035] 96 queries and getting DNS responses over modern versions of HTTP 97 [RFC7540] using https:// (and therefore TLS [RFC5246] security for 98 integrity and confidentiality). 100 The described approach is more than a tunnel over HTTP. It 101 establishes default media formatting types for requests and responses 102 but uses normal HTTP content negotiation mechanisms for selecting 103 alternatives that endpoints may prefer in anticipation of serving new 104 use cases. In addition to this media type negotiation, it aligns 105 itself with HTTP features such as caching, proxying, and compression. 107 The integration with HTTP provides a transport suitable for both 108 traditional DNS clients and native web applications seeking access to 109 the DNS. 111 A server that supports this protocol is called a "DNS API server" to 112 differentiate it from a "DNS server" (one that uses the regular DNS 113 protocol). Similarly, a client that supports this protocol is called 114 a "DNS API client". 116 2. Terminology 118 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 119 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 120 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 121 [RFC2119]. 123 3. Use Cases 125 There are two primary use cases for this protocol. 127 The primary one is to prevent on-path network devices from 128 interfering with native DNS operations. This interference includes, 129 but is not limited to, spoofing DNS responses, blocking DNS requests, 130 and tracking. HTTP authentication and proxy friendliness are 131 expected to make this protocol function in some environments where 132 DNS directly on TLS ([RFC7858]) would not. 134 A secondary use case is web applications that want to access DNS 135 information. Standardizing an HTTPS mechanism allows this to be done 136 in a way consistent with the cross-origin resource sharing [CORS] 137 security model of the web and also integrate the caching mechanisms 138 of DNS with those of HTTP. These applications may be interested in 139 using a different media type than traditional clients. 141 [ This paragraph is to be removed when this document is published as 142 an RFC ] Note that these use cases are different than those in a 143 similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http]. 144 The use case for that protocol is proxying DNS queries over HTTP 145 instead of over DNS itself. The use cases in this document all 146 involve query origination instead of proxying. 148 4. Protocol Requirements 150 The protocol described here bases its design on the following 151 protocol requirements: 153 o The protocol must use normal HTTP semantics. 155 o The query format must be able to be flexible enough to express 156 every normal DNS query. 158 o The protocol must allow implementations to use HTTP's content 159 negotiation mechanism. 161 o The protocol must ensure interoperable media formats through a 162 mandatory to implement format wherein a query must be able to 163 contain one or more EDNS extensions, including those not yet 164 defined. 166 o The protocol must use a secure transport that meets the 167 requirements for modern https://. 169 4.1. Non-requirements 171 o Supporting network-specific DNS64 [RFC6147] 173 o Supporting other network-specific inferences from plaintext DNS 174 queries 176 o Supporting insecure HTTP 178 o Supporitng legacy HTTP versions 180 5. The HTTP Request 182 The URI scheme MUST be https. 184 The path SHOULD be "/.well-known/dns-query" but a different path can 185 be used if the DNS API Client has prior knowledge about a DNS API 186 service on a different path at the origin being used. (See Section 8 187 for the registration of this in the well-known URI registry.) Using 188 the well-known path allows automated discovery of a DNS API Service, 189 and also helps contextualize DNS Query requests pushed over an active 190 HTTP/2 connection. 192 Some forms of the request may also include a HTTP query as defined by 193 [RFC3986]. 195 A DNS API Client encodes the DNS query into the HTTP request in one 196 of two different methods: 198 GET: Using the on-the-wire representation of a DNS message defined 199 in [RFC1035] as the query string portion of the URI, encoded as 200 necessary with [RFC3986], using the GET HTTP method. This is the 201 preferred approach because it is friendlier to HTTP caches. 203 POST: Including the DNS query as the message body of the HTTP 204 request, with the request using the POST method. The body MUST 205 use a media type selected by the DNS API Client, and that media 206 type MUST be indicated by the request's Content-Type header. 208 The DNS request MAY have one or more EDNS(0) extensions [RFC6891]. 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" responses 213 but MAY process any other type it receives. 215 In order to maximize cache friendliness, DNS API Clients SHOULD use 216 the same ID (the first two bytes of the header) for every DNS 217 request. The exact mechanism for doing so is dependent on the media 218 type in use. HTTP semantics correlate the request and response which 219 eliminates the need for the ID in a media type such as application/ 220 dns-udpwireformat. Using a constant value greatly increases the 221 opportunity for successful caching. 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. Example 228 For example, assume a DNS API server is following this specification 229 on origin https://dnsserver.example.net/ and the well-known path. 230 The example uses HTTP/2 formatting from [RFC7540]. 232 A query for the IN A records for "www.example.com" with recursion 233 turned on using the GET approach would be: 235 :method = GET 236 :scheme = https 237 :authority = dnsserver.example.net 238 :path = /.well-known/dns-query?%ab%cd%01%00%00%01%00%00%00%00 (no CR) 239 %00%00%03www%07example%03com%00%00%01%00%01 240 accept = application/dns-udpwireformat, application/dns-futureJsonDns 242 The same DNS query, using the second method of HTTP encoding would 243 be: 245 :method = POST 246 :scheme = https 247 :authority = dnsserver.example.net 248 :path = /.well-known/dns-query 249 accept = application/dns-udpwireformat, application/dns-futureJsonDns 250 content-type = application/dns-udpwireformat 251 content-length = 33 253 <33 bytes represented by the following hex encoding> 254 abcd 0100 0001 0000 0000 0000 0377 7777 255 0765 7861 6d70 6c65 0363 6f6d 0000 0100 256 01 258 6. The HTTP Response 260 Different response media types will provide more or less information 261 from a DNS response. For example, one response type might include 262 the information from the DNS header bytes while another might omit 263 it. The amount and type of information that a media type gives is 264 solely up to the format, and not defined in this protocol. 266 At the time this is published, the response types are works in 267 progress. The only known response type is "application/dns- 268 udpwireformat", but it is likely that at least one JSON-based 269 response format might be defined in the future. 271 The DNS response MAY have one or more EDNS(0) extensions, depending 272 on the extension definition of the extensions given in the DNS 273 request. 275 Native HTTP methods are used to correlate requests and responses. 276 Responses may be returned in a different temporal order than requests 277 were made using the protocols native multistreaming functionality. 279 In the HTTP responses, the HTTP cache headers SHOULD be set to expire 280 at the same time as the shortest DNS TTL in the response. Because 281 DNS provides only caching but not revalidation semantics, DNS over 282 HTTP responses should not carry revalidation response headers (such 283 as Last-Modified: or Etag:) or return 304 responses. 285 A DNS API Server MUST be able to process application/dns- 286 udpwireformat request messages. 288 A DNS API Server SHOULD respond with HTTP status code 415 upon 289 receiving a media type it is unable to process. 291 This document does not change the definition of any HTTP response 292 codes or otherwise proscribe their use. 294 6.1. Example 296 This is an example response for a query for the IN A records for 297 "www.example.com" with recursion turned on. The response bears one 298 record with an address of 93.184.216.34 and a TTL of 128 seconds. 300 :status = 200 301 content-type = application/dns-udpwireformat 302 content-length = 64 303 cache-control = max-age=128 305 <64 bytes represented by the following hex encoding> 306 abcd 8180 0001 0001 0000 0000 0377 7777 307 0765 7861 6d70 6c65 0363 6f6d 0000 0100 309 0103 7777 7707 6578 616d 706c 6503 636f 310 6d00 0001 0001 0000 0080 0004 5Db8 d822 312 7. HTTP Integration 314 In order to satisfy the security requirements of DNS over HTTPS, this 315 protocol MUST use HTTP/2 [RFC7540] or its successors. HTTP/2 316 enforces a modern TLS profile necessary for achieving the security 317 requirements of this protocol. 319 This protocol MUST be used with https scheme URI [RFC7230]. 321 The messages in classic UDP based DNS [RFC1035] are inherently 322 unordered and have low overhead. A competitive HTTP transport needs 323 to support reordering, priority, parallelism, and header compression. 324 For this additional reason, this protocol MUST use HTTP/2 [RFC7540] 325 or its successors. 327 8. IANA Considerations 329 This specification registers a Well-Known URI [RFC5785]: 331 o URI Suffix: dns-query 333 o Change Controller: IETF 335 o Specification Document(s): [this specification] 337 (Note for the -00 draft: a request for the media type application/ 338 dns-udpwireformat has already been submitted separately from this 339 draft because it may be useful for other documents as well. That 340 application is pending approval.) 342 9. Security Considerations 344 Running DNS over https:// relies on the security of the underlying 345 HTTP connection. By requiring at least [RFC7540] levels of support 346 for TLS this protocol expects to use current best practices for 347 secure transport. 349 Session level encryption has well known weaknesses with respect to 350 traffic analysis which might be particularly acute when dealing with 351 DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of 352 [RFC7540] provide some further advice on mitigations within an HTTP/2 353 context. 355 10. Acknowledgments 357 Joe Hildebrand contributed lots of material for a different iteration 358 of this document. Helpful early comments were given by Ben Schwartz 359 and Mark Nottingham. 361 11. References 363 11.1. Normative References 365 [RFC1035] Mockapetris, P., "Domain names - implementation and 366 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 367 November 1987, . 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 375 Resource Identifier (URI): Generic Syntax", STD 66, 376 RFC 3986, DOI 10.17487/RFC3986, January 2005, 377 . 379 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 380 (TLS) Protocol Version 1.2", RFC 5246, 381 DOI 10.17487/RFC5246, August 2008, 382 . 384 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 385 Uniform Resource Identifiers (URIs)", RFC 5785, 386 DOI 10.17487/RFC5785, April 2010, 387 . 389 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 390 Protocol (HTTP/1.1): Message Syntax and Routing", 391 RFC 7230, DOI 10.17487/RFC7230, June 2014, 392 . 394 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 395 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 396 DOI 10.17487/RFC7540, May 2015, 397 . 399 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 400 and P. Hoffman, "Specification for DNS over Transport 401 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 402 2016, . 404 11.2. Informative References 406 [CORS] W3C, "Cross-Origin Resource Sharing", 2014, 407 . 409 [I-D.ietf-dnsop-dns-wireformat-http] 410 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 411 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 412 (work in progress), March 2017. 414 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 415 Beijnum, "DNS64: DNS Extensions for Network Address 416 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 417 DOI 10.17487/RFC6147, April 2011, 418 . 420 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 421 for DNS (EDNS(0))", STD 75, RFC 6891, 422 DOI 10.17487/RFC6891, April 2013, 423 . 425 Appendix A. Previous Work on DNS over HTTP or in Other Formats 427 The following is an incomplete list of earlier work that related to 428 DNS over HTTP/1 or representing DNS data in other formats. 430 The list includes links to the tools.ietf.org site (because these 431 documents are all expired) and web sites of software. 433 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 435 o https://tools.ietf.org/html/draft-daley-dnsxml 437 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 439 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 441 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 443 Authors' Addresses 445 Paul Hoffman 446 ICANN 448 Email: paul.hoffman@icann.org 450 Patrick McManus 451 Mozilla 453 Email: pmcmanus@mozilla.com