idnits 2.17.1 draft-ietf-doh-dns-over-https-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (February 02, 2018) is 2246 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) -- Looks like a reference, but probably isn't: '1' on line 686 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-dns-wireformat-http-01 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: August 6, 2018 Mozilla 6 February 02, 2018 8 DNS Queries over HTTPS 9 draft-ietf-doh-dns-over-https-03 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 https://github.com/dohwg/ 26 draft-ietf-doh-dns-over-https [1] ]]. 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 https://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 August 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . 5 67 5. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 6 69 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 9 74 7.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Registration of application/dns-udpwireformat Media Type 10 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 10. Operational Considerations . . . . . . . . . . . . . . . . . 13 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 12.2. Informative References . . . . . . . . . . . . . . . . . 15 84 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 The Internet does not always provide end to end reachability for 91 native DNS. On-path network devices may spoof DNS responses, block 92 DNS requests, or just redirect DNS queries to different DNS servers 93 that give less-than-honest answers. 95 Over time, there have been many proposals for using HTTP and HTTPS as 96 a substrate for DNS queries and responses. To date, none of those 97 proposals have made it beyond early discussion, partially due to 98 disagreement about what the appropriate formatting should be and 99 partially because they did not follow HTTP best practices. 101 This document defines a specific protocol for sending DNS [RFC1035] 102 queries and getting DNS responses over HTTP [RFC7540] using https:// 103 (and therefore TLS [RFC5246] security for integrity and 104 confidentiality). Each DNS query-response pair is mapped into a HTTP 105 request-response pair. 107 The described approach is more than a tunnel over HTTP. It 108 establishes default media formatting types for requests and responses 109 but uses normal HTTP content negotiation mechanisms for selecting 110 alternatives that endpoints may prefer in anticipation of serving new 111 use cases. In addition to this media type negotiation, it aligns 112 itself with HTTP features such as caching, proxying, and compression. 114 The integration with HTTP provides a transport suitable for both 115 traditional DNS clients and native web applications seeking access to 116 the DNS. 118 2. Terminology 120 A server that supports this protocol is called a "DNS API server" to 121 differentiate it from a "DNS server" (one that uses the regular DNS 122 protocol). Similarly, a client that supports this protocol is called 123 a "DNS API client". 125 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 126 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 127 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 128 [RFC2119]. 130 3. Use Cases 132 There are two initial use cases for this protocol. 134 The primary use case is to prevent on-path network devices from 135 interfering with DNS operations. This interference includes, but is 136 not limited to, spoofing DNS responses, blocking DNS requests, and 137 tracking. 139 In this use, clients - whether operating systems or individual 140 applications - will be explicitly configured to use a DOH server as a 141 recursive resolver by its user (or administrator). They might use 142 the DOH server for all queries, or only for a subset of them. The 143 specific configuration mechanism is out of scope for this document. 145 A secondary use case is allowing web applications to access DNS 146 information, by using existing APIs in browsers to access it over 147 HTTP in a safe way consistent with Cross Origin Resource Sharing 148 (CORS) [CORS]. 150 This is technically already possible (since the server controls both 151 the HTTP resources it exposes and the use of browser APIs by its 152 content), but standardization might make this easier to accomplish. 154 Note that in this second use, the browser does not consult the DOH 155 server or use its responses for any DNS lookups outside the scope of 156 the application using them; i.e., there is (currently) no API that 157 allows a Web site to poison DNS for others. 159 [[ This paragraph is to be removed when this document is published as 160 an RFC ]] Note that these use cases are different than those in a 161 similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http]. 162 The use case for that protocol is proxying DNS queries over HTTP 163 instead of over DNS itself. The use cases in this document all 164 involve query origination instead of proxying. 166 4. Protocol Requirements 168 The protocol described here bases its design on the following 169 protocol requirements: 171 o The protocol must use normal HTTP semantics. 173 o The queries and responses must be able to be flexible enough to 174 express every normal DNS query. 176 o The protocol must allow implementations to use HTTP's content 177 negotiation mechanism. 179 o The protocol must ensure interoperable media formats through a 180 mandatory to implement format wherein a query must be able to 181 contain future modifications to the DNS protocol including the 182 inclusion of one or more EDNS extensions (including those not yet 183 defined). 185 o The protocol must use a secure transport that meets the 186 requirements for HTTPS. 188 4.1. Non-requirements 190 o Supporting network-specific DNS64 [RFC6147] 192 o Supporting other network-specific inferences from plaintext DNS 193 queries 195 o Supporting insecure HTTP 197 o Supporting legacy HTTP versions 199 5. The HTTP Request 201 To make a DNS API query a DNS API client encodes a single DNS query 202 into an HTTP request using either the HTTP GET or POST method and the 203 other requirements of this section. The DNS API server defines the 204 URI used by the request. Configuration and discovery of the URI is 205 done out of band from this protocol. 207 When using the POST method the DNS query is included as the message 208 body of the HTTP request and the Content-Type request header 209 indicates the media type of the message. POST-ed requests are 210 smaller than their GET equivalents. 212 When using the GET method the URI path MUST contain a query parameter 213 with the name of "ct" and a value indicating the media-format used 214 for the dns parameter. The value may either be an explicit media 215 type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be 216 empty. An empty value indicates the default application/dns- 217 udpwireformat type (e.g. ct&dns=...). 219 When using the GET method the URI path MUST contain a query parameter 220 with the name of "dns". The value of the parameter is the content of 221 the request potentially encoded with base64url [RFC4648]. 222 Specifications that define media types for use with DOH, such as DNS 223 Wire Format Section 5.1 of this document, MUST indicate if the body 224 parameter uses base64url encoding. 226 Using the GET method is friendlier to many HTTP cache 227 implementations. 229 The DNS API Client SHOULD include an HTTP "Accept:" request header to 230 say what type of content can be understood in response. The client 231 MUST be prepared to process "application/dns-udpwireformat" 232 Section 5.1 responses but MAY process any other type it receives. 234 In order to maximize cache friendliness, DNS API clients using media 235 formats that include DNS ID, such as application/dns-udpwireformat, 236 SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates 237 request and response, thus eliminating the need for the ID in a media 238 type such as application/dns-udpwireformat and the use of a varying 239 DNS ID can cause semantically equivalent DNS queries to be cached 240 separately. 242 DNS API clients can use HTTP/2 padding and compression in the same 243 way that other HTTP/2 clients use (or don't use) them. 245 5.1. DNS Wire Format 247 The media type is "application/dns-udpwireformat". 249 The body is the DNS on-the-wire format defined in [RFC1035]. 251 When using the GET method, the body MUST be encoded with base64url 252 [RFC4648] and then placed as a name value pair in the query portion 253 of the URI with name "dns". Padding characters for base64url MUST 254 NOT be included. 256 When using the POST method, the body MUST NOT be encoded. 258 DNS API clients using the DNS wire format MAY have one or more 259 EDNS(0) extensions [RFC6891] in the request. 261 5.2. Examples 263 These examples use HTTP/2 style formatting from [RFC7540]. 265 These examples use a DNS API service located at 266 https://dnsserver.example.net/dns-query to resolve the IN A records. 268 The requests are represented as application/dns-udpwirefomat typed 269 bodies, but the client indicates it can parse responses in either 270 that format or as a hypothetical JSON-based content type. The 271 application/simpledns+json type used by this example is currently 272 fictitious. 274 The first example request uses GET to request www.example.com 276 :method = GET 277 :scheme = https 278 :authority = dnsserver.example.net 279 :path = /dns-query?ct& (no space or CR) 280 dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB 281 accept = application/dns-udpwireformat, application/simpledns+json 282 The same DNS query for www.example.com, using the POST method would 283 be: 285 :method = POST 286 :scheme = https 287 :authority = dnsserver.example.net 288 :path = /dns-query 289 accept = application/dns-udpwireformat, application/simpledns+json 290 content-type = application/dns-udpwireformat 291 content-length = 33 293 <33 bytes represented by the following hex encoding> 294 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 295 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 296 01 298 Finally, a GET based query for a.62characterlabel-makes-base64url- 299 distinct-from-standard-base64.example.com is shown as an example to 300 emphasize that the encoding alphabet of base64url is different than 301 regular base64 and that padding is omitted. 303 The DNS query is 94 bytes represented by the following hex encoding 305 00 00 01 00 00 01 00 00 00 00 00 00 01 61 3e 36 306 32 63 68 61 72 61 63 74 65 72 6c 61 62 65 6c 2d 307 6d 61 6b 65 73 2d 62 61 73 65 36 34 75 72 6c 2d 308 64 69 73 74 69 6e 63 74 2d 66 72 6f 6d 2d 73 74 309 61 6e 64 61 72 64 2d 62 61 73 65 36 34 07 65 78 310 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 312 :method = GET 313 :scheme = https 314 :authority = dnsserver.example.net 315 :path = /dns-query?ct& (no space or CR) 316 dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR) 317 bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR) 318 dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ 319 accept = application/dns-udpwireformat, application/simpledns+json 321 6. The HTTP Response 323 Different response media types will provide more or less information 324 from a DNS response. For example, one response type might include 325 the information from the DNS header bytes while another might omit 326 it. The amount and type of information that a media type gives is 327 solely up to the format, and not defined in this protocol. 329 At the time this is published, the response types are works in 330 progress. The only response type defined in this document is 331 "application/dns-udpwireformat", but it is possible that at least one 332 JSON-based response format will be defined in the future. 334 The DNS response for "application/dns-udpwireformat" in Section 5.1 335 MAY have one or more EDNS(0) extensions, depending on the extension 336 definition of the extensions given in the DNS request. 338 Each DNS request-response pair is matched to one HTTP request- 339 response pair. The responses may be processed and transported in any 340 order using HTTP's multi-streaming functionality ([RFC7540] 341 Section 5}). 343 The Answer section of a DNS response contains one or more RRsets. 344 (RRsets are defined in [RFC7719].) According to [RFC2181], each 345 resource record in an RRset is supposed to have the Time To Live 346 (TTL) freshness information. Different RRsets in the Answer section 347 can have different TTLs, though it is only possible for the HTTP 348 response to have a single freshness lifetime. The HTTP response 349 freshness lifetime ([RFC7234] Section 4.2) should be coordinated with 350 the Resource Record bearing the smallest TTL in the Answer section of 351 the response. Specifically, the HTTP freshness lifetime SHOULD be 352 set to expire at the same time any of the DNS Records reach a 0 TTL. 353 The response freshness lifetime MUST NOT be greater than that 354 indicated by the DNS Record with the smallest TTL in the response. 356 A DNS API Client that receives a response without an explicit 357 freshness lifetime MUST NOT assign that response a heuristic 358 freshness ([RFC7234] Section 4.2.2.) greater than that indicated by 359 the DNS Record with the smallest TTL in the response. 361 A DNS API Server MUST be able to process application/dns- 362 udpwireformat request messages. 364 A DNS API Server SHOULD respond with HTTP status code 415 365 (Unsupported Media Type) upon receiving a media type it is unable to 366 process. 368 This document does not change the definition of any HTTP response 369 codes or otherwise proscribe their use. 371 6.1. Example 373 This is an example response for a query for the IN A records for 374 "www.example.com" with recursion turned on. The response bears one 375 record with an address of 192.0.2.1 and a TTL of 128 seconds. 377 :status = 200 378 content-type = application/dns-udpwireformat 379 content-length = 64 380 cache-control = max-age=128 382 <64 bytes represented by the following hex encoding> 383 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 384 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 385 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 386 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 388 7. HTTP Integration 390 This protocol MUST be used with the https scheme URI [RFC7230]. 392 7.1. Cache Interaction 394 A DOH API Client may utilize a hierarchy of caches that include both 395 HTTP and DNS specific caches. HTTP cache entries may be bypassed 396 with HTTP mechanisms such as the Cache-Control no-cache directive 397 however DNS caches do not have a similar mechanism. 399 A DOH response that was previously stored in an HTTP cache will 400 contain the [RFC7234] Age response header indicating the elapsed time 401 between when the entry was placed in the HTTP cache and the current 402 DOH response. DNS API clients should subtract this time from the DNS 403 TTL if they are re-sharing the information in a non HTTP context 404 (e.g. their own DNS cache) to determine the remaining time to live of 405 the DNS record. 407 HTTP revalidation (e.g. via If-None-Match request headers) of cached 408 DNS information may be of limited value to DOH as revalidation 409 provides only a bandwidth benefit and DNS transactions are normally 410 latency bound. Furthermore, the HTTP response headers that enable 411 revalidation (such as "Last-Modified" and "Etag") are often fairly 412 large when compared to the overall DNS response size, and have a 413 variable nature that creates constant pressure on the HTTP/2 414 compression dictionary [RFC7541]. Other types of DNS data, such as 415 zone transfers, may be larger and benefit more from revalidation. 416 DNS API servers may wish to consider whether providing these 417 validation enabling response headers is worthwhile. 419 The stale-while-revalidate and stale-if-error cache control 420 directives may be well suited to a DOH implementation when allowed by 421 server policy. Those mechanisms allow a client, at the server's 422 discretion, to reuse a cache entry that is no longer fresh under some 423 extenuating circumstances defined in [RFC5861]. 425 All HTTP servers, including DNS API servers, need to consider cache 426 interaction when they generate responses that are not globally valid. 427 For instance, if a DNS API server customized a response based on the 428 client's identity then it would not want to globally allow reuse of 429 that response. This could be accomplished through a variety of HTTP 430 techniques such as a Cache-Control max-age of 0, or perhaps by the 431 Vary response header. 433 7.2. HTTP/2 435 The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]. 437 The messages in classic UDP based DNS [RFC1035] are inherently 438 unordered and have low overhead. A competitive HTTP transport needs 439 to support reordering, parallelism, priority, and header compression 440 to achieve similar performance. Those features were introduced to 441 HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of 442 conveying the semantic requirements of DOH but may result in very 443 poor performance for many uses cases. 445 7.3. Server Push 447 Before using DOH response data for DNS resolution, the client MUST 448 establish that the HTTP request URI is a trusted service for the DOH 449 query. For HTTP requests initiated by the DNS API client this trust 450 is implicit in the selection of URI. For HTTP server push ([RFC7540] 451 Section 8.2) extra care must be taken to ensure that the pushed URI 452 is one that the client would have directed the same query to if the 453 client had initiated the request. This specification does not extend 454 DNS resolution privileges to URIs that are not recognized by the 455 client as trusted DNS API servers. 457 8. IANA Considerations 459 8.1. Registration of application/dns-udpwireformat Media Type 460 To: ietf-types@iana.org 461 Subject: Registration of MIME media type 462 application/dns-udpwireformat 464 MIME media type name: application 466 MIME subtype name: dns-udpwireformat 468 Required parameters: n/a 470 Optional parameters: n/a 472 Encoding considerations: This is a binary format. The contents are a 473 DNS message as defined in RFC 1035. The format used here is for DNS 474 over UDP, which is the format defined in the diagrams in RFC 1035. 476 Security considerations: The security considerations for carrying 477 this data are the same for carrying DNS without encryption. 479 Interoperability considerations: None. 481 Published specification: This document. 483 Applications that use this media type: 484 Systems that want to exchange full DNS messages. 486 Additional information: 488 Magic number(s): n/a 490 File extension(s): n/a 492 Macintosh file type code(s): n/a 494 Person & email address to contact for further information: 495 Paul Hoffman, paul.hoffman@icann.org 497 Intended usage: COMMON 499 Restrictions on usage: n/a 501 Author: Paul Hoffman, paul.hoffman@icann.org 503 Change controller: IESG 505 9. Security Considerations 507 Running DNS over HTTPS relies on the security of the underlying HTTP 508 transport. Implementations utilizing HTTP/2 benefit from the TLS 509 profile defined in [RFC7540] Section 9.2. 511 Session level encryption has well known weaknesses with respect to 512 traffic analysis which might be particularly acute when dealing with 513 DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of 514 [RFC7540] provide some further advice on mitigations within an HTTP/2 515 context. 517 The HTTPS connection provides transport security for the interaction 518 between the DNS API server and client, but does not inherently ensure 519 the authenticity of DNS data. A DNS API client may also perform full 520 DNSSEC validation of answers received from a DNS API server or it may 521 choose to trust answers from a particular DNS API server, much as a 522 DNS client might choose to trust answers from its recursive DNS 523 resolver. 525 [[ From the WG charter: 527 The working group will analyze the security and privacy issues that 528 could arise from accessing DNS over HTTPS. In particular, the 529 working group will consider the interaction of DNS and HTTP caching. 531 ]] 533 A server that is acting both as a normal web server and a DNS API 534 server is in a position to choose which DNS names it forces a client 535 to resolve (through its web service) and also be the one to answer 536 those queries (through its DNS API service). An untrusted DNS API 537 server can thus easily cause damage by poisoning a client's cache 538 with names that the DNS API server chooses to poison. A client MUST 539 NOT trust a DNS API server simply because it was discovered, or 540 because the client was told to trust the DNS API server by an 541 untrusted party. Instead, a client MUST only trust DNS API server 542 that is configured as trustworthy. 544 [[ From the WG charter: 546 The working group may define mechanisms for discovery of DOH servers 547 similar to existing mechanisms for discovering other DNS servers if 548 the chairs determine that there is both sufficient interest and 549 working group consensus. 551 ]] 553 10. Operational Considerations 555 Local policy considerations and similar factors mean different DNS 556 servers may provide different results to the same query: for instance 557 in split DNS configurations [RFC6950]. It logically follows that the 558 server which is queried can influence the end result. Therefore a 559 client's choice of DNS server may affect the responses it gets to its 560 queries. 562 The HTTPS channel used by this specification establishes secure two 563 party communication between the DNS API Client and the DNS API 564 Server. Filtering or inspection systems that rely on unsecured 565 transport of DNS will not function in a DNS over HTTPS environment. 567 Many HTTPS implementations perform real time third party checks of 568 the revocation status of the certificates being used by TLS. If this 569 check is done as part of the DNS API server connection procedure and 570 the check itself requires DNS resolution to connect to the third 571 party a deadlock can occur. The use of an OCSP [RFC6960] server is 572 one example of how this can happen. DNS API servers SHOULD utilize 573 OCSP Stapling [RFC6961] to provide the client with certificate 574 revocation information that does not require contacting a third 575 party. 577 A DNS API client may face a similar bootstrapping problem when the 578 HTTP request needs to resolve the hostname portion of the DNS URI. 579 Just as the address of a traditional DNS nameserver cannot be 580 originally determined from that same server, a DOH client cannot use 581 its DOH server to initially resolve the server's host name into an 582 address. Alternative strategies a client might employ include making 583 the initial resolution part of the configuration, IP based URIs and 584 corresponding IP based certificates for HTTPS, or resolving the DNS 585 API Server's hostname via traditional DNS or another DOH server while 586 still authenticating the resulting connection via HTTPS. 588 11. Acknowledgments 590 Joe Hildebrand contributed lots of material for a different iteration 591 of this document. Helpful early comments were given by Ben Schwartz 592 and Mark Nottingham. 594 12. References 596 12.1. Normative References 598 [RFC1035] Mockapetris, P., "Domain names - implementation and 599 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 600 November 1987, . 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, 604 DOI 10.17487/RFC2119, March 1997, 605 . 607 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 608 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 609 . 611 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 612 (TLS) Protocol Version 1.2", RFC 5246, 613 DOI 10.17487/RFC5246, August 2008, 614 . 616 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 617 Galperin, S., and C. Adams, "X.509 Internet Public Key 618 Infrastructure Online Certificate Status Protocol - OCSP", 619 RFC 6960, DOI 10.17487/RFC6960, June 2013, 620 . 622 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 623 Multiple Certificate Status Request Extension", RFC 6961, 624 DOI 10.17487/RFC6961, June 2013, 625 . 627 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 628 Protocol (HTTP/1.1): Message Syntax and Routing", 629 RFC 7230, DOI 10.17487/RFC7230, June 2014, 630 . 632 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 633 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 634 RFC 7234, DOI 10.17487/RFC7234, June 2014, 635 . 637 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 638 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 639 DOI 10.17487/RFC7540, May 2015, 640 . 642 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 643 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 644 . 646 12.2. Informative References 648 [CORS] "Cross-Origin Resource Sharing", n.d., 649 . 651 [I-D.ietf-dnsop-dns-wireformat-http] 652 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 653 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 654 (work in progress), March 2017. 656 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 657 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 658 . 660 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 661 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, 662 . 664 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 665 Beijnum, "DNS64: DNS Extensions for Network Address 666 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 667 DOI 10.17487/RFC6147, April 2011, 668 . 670 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 671 for DNS (EDNS(0))", STD 75, RFC 6891, 672 DOI 10.17487/RFC6891, April 2013, 673 . 675 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 676 "Architectural Considerations on Application Features in 677 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 678 . 680 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 681 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 682 2015, . 684 12.3. URIs 686 [1] https://github.com/dohwg/draft-ietf-doh-dns-over-https 688 Appendix A. Previous Work on DNS over HTTP or in Other Formats 690 The following is an incomplete list of earlier work that related to 691 DNS over HTTP/1 or representing DNS data in other formats. 693 The list includes links to the tools.ietf.org site (because these 694 documents are all expired) and web sites of software. 696 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 698 o https://tools.ietf.org/html/draft-daley-dnsxml 700 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 702 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 704 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 706 Authors' Addresses 708 Paul Hoffman 709 ICANN 711 Email: paul.hoffman@icann.org 713 Patrick McManus 714 Mozilla 716 Email: pmcmanus@mozilla.com