1 Internet Engineering Task Force (IETF) P. Hoffman
2 Request for Comments: 8484 ICANN
3 Category: Standards Track P. McManus
4 ISSN: 2070-1721 Mozilla
5 October 2018
6
7
8 DNS Queries over HTTPS (DoH)
9
10 Abstract
11
12 This document defines a protocol for sending DNS queries and getting
13 DNS responses over HTTPS. Each DNS query-response pair is mapped
14 into an HTTP exchange.
15
16 Status of This Memo
17
18 This is an Internet Standards Track document.
19
20 This document is a product of the Internet Engineering Task Force
21 (IETF). It represents the consensus of the IETF community. It has
22 received public review and has been approved for publication by the
23 Internet Engineering Steering Group (IESG). Further information on
24 Internet Standards is available in Section 2 of RFC 7841.
25
26 Information about the current status of this document, any errata,
27 and how to provide feedback on it may be obtained at
28 https://www.rfc-editor.org/info/rfc8484.
29
30 Copyright Notice
31
32 Copyright (c) 2018 IETF Trust and the persons identified as the
33 document authors. All rights reserved.
34
35 This document is subject to BCP 78 and the IETF Trust's Legal
36 Provisions Relating to IETF Documents
37 (https://trustee.ietf.org/license-info) in effect on the date of
38 publication of this document. Please review these documents
39 carefully, as they describe your rights and restrictions with respect
40 to this document. Code Components extracted from this document must
41 include Simplified BSD License text as described in Section 4.e of
42 the Trust Legal Provisions and are provided without warranty as
43 described in the Simplified BSD License.
44
45
46
47
48
49
50
51
52 Hoffman & McManus Standards Track [Page 1]
53 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Selection of DoH Server . . . . . . . . . . . . . . . . . . . 4
61 4. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4
62 4.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4
63 4.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
64 4.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 7
65 4.2.1. Handling DNS and HTTP Errors . . . . . . . . . . . . 7
66 4.2.2. HTTP Response Example . . . . . . . . . . . . . . . . 8
67 5. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
68 5.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8
69 5.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 10
70 5.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10
71 5.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10
72 6. Definition of the "application/dns-message" Media Type . . . 10
73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
74 7.1. Registration of the "application/dns-message" Media Type 11
75 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
76 8.1. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 12
77 8.2. In the Server . . . . . . . . . . . . . . . . . . . . . . 12
78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
79 10. Operational Considerations . . . . . . . . . . . . . . . . . 15
80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
81 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
82 11.2. Informative References . . . . . . . . . . . . . . . . . 18
83 Appendix A. Protocol Development . . . . . . . . . . . . . . . . 20
84 Appendix B. Previous Work on DNS over HTTP or in Other Formats . 20
85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Hoffman & McManus Standards Track [Page 2]
108 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
109
110
111 1. Introduction
112
113 This document defines a specific protocol, DNS over HTTPS (DoH), for
114 sending DNS [RFC1035] queries and getting DNS responses over HTTP
115 [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446]
116 security for integrity and confidentiality). Each DNS query-response
117 pair is mapped into an HTTP exchange.
118
119 The described approach is more than a tunnel over HTTP. It
120 establishes default media formatting types for requests and responses
121 but uses normal HTTP content negotiation mechanisms for selecting
122 alternatives that endpoints may prefer in anticipation of serving new
123 use cases. In addition to this media type negotiation, it aligns
124 itself with HTTP features such as caching, redirection, proxying,
125 authentication, and compression.
126
127 The integration with HTTP provides a transport suitable for both
128 existing DNS clients and native web applications seeking access to
129 the DNS.
130
131 Two primary use cases were considered during this protocol's
132 development. These use cases are preventing on-path devices from
133 interfering with DNS operations, and also allowing web applications
134 to access DNS information via existing browser APIs in a safe way
135 consistent with Cross Origin Resource Sharing (CORS) [FETCH]. No
136 special effort has been taken to enable or prevent application to
137 other use cases. This document focuses on communication between DNS
138 clients (such as operating system stub resolvers) and recursive
139 resolvers.
140
141 2. Terminology
142
143 A server that supports this protocol is called a "DoH server" to
144 differentiate it from a "DNS server" (one that only provides DNS
145 service over one or more of the other transport protocols
146 standardized for DNS). Similarly, a client that supports this
147 protocol is called a "DoH client".
148
149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
151 "OPTIONAL" in this document are to be interpreted as described in
152 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
153 capitals, as shown here.
154
155
156
157
158
159
160
161
162 Hoffman & McManus Standards Track [Page 3]
163 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
164
165
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions) with the exception of forwarding. Forwarding DNS queries over encrypted transports is not supported in BIND yet.
166 3. Selection of DoH Server
167
168 The DoH client is configured with a URI Template [RFC6570], which
169 describes how to construct the URL to use for resolution.
170 Configuration, discovery, and updating of the URI Template is done
171 out of band from this protocol. Note that configuration might be
172 manual (such as a user typing URI Templates in a user interface for
173 "options") or automatic (such as URI Templates being supplied in
174 responses from DHCP or similar protocols). DoH servers MAY support
175 more than one URI Template. This allows the different endpoints to
176 have different properties, such as different authentication
177 requirements or service-level guarantees.
178
179 A DoH client uses configuration to select the URI, and thus the DoH
180 server, that is to be used for resolution. [RFC2818] defines how
181 HTTPS verifies the DoH server's identity.
182
183 A DoH client MUST NOT use a different URI simply because it was
184 discovered outside of the client's configuration (such as through
185 HTTP/2 server push) or because a server offers an unsolicited
186 response that appears to be a valid answer to a DNS query. This
187 specification does not extend DNS resolution privileges to URIs that
188 are not recognized by the DoH client as configured URIs. Such
189 scenarios may create additional operational, tracking, and security
190 hazards that require limitations for safe usage. A future
191 specification may support this use case.
192
193 4. The HTTP Exchange
194
A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration (such as through HTTP/2 server push) or because a server offers an unsolicited response that appears to be a valid answer to a DNS query.
A DoH client MUST NOT use a different URI that was discovered outside of the client's configuration (except via HTTP redirection discussed in Section 6.4 of [RFC7231]). Also, the DoH client MUST ignore an unsolicited response (such as through HTTP/2 server push) that appears to be a valid answer to a DNS query unless that response comes from a configured URI (as described in Section 5.3).
(1) The intent of this text is confusing. (2) I checked the mailing list and found that the text was updated late in the publication process to address this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB-KRsLZhttx9tGt75cps/. (3) The example provided in the thread (server push) is related to the second part of the OLD text. It is mistakenly attached to the first part. (4) The push example may be interpreted as if server push is disallowed. This is conflicting with Section 5.3. Hence, this change: Also, the DoH client MUST ignore an unsolicited response (such as through HTTP/2 server push) that appears to be a valid answer to a DNS query ** unless that response comes from a configured URI (as described in Section 5.3) **. (5) An intuitive way to discover the URI outside the configuration is redirection. RFC8484 indicates clearly the following: The described approach is more than a tunnel over HTTP. It establishes default media formatting types for requests and responses but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases. In addition to this media type negotiation, it ** aligns itself with HTTP features ** such as caching, **redirection**, proxying, authentication, and compression. Forbidding discovery of URI outside the configuration contradicts the above excerpt. The text is as such incorrect. (6) Also, I suggest to remove "simply" from the text. Not sure what message is supposed to convey.
195 4.1. The HTTP Request
196
197 A DoH client encodes a single DNS query into an HTTP request using
198 either the HTTP GET or POST method and the other requirements of this
199 section. The DoH server defines the URI used by the request through
200 the use of a URI Template.
201
202 The URI Template defined in this document is processed without any
203 variables when the HTTP method is POST. When the HTTP method is GET,
204 the single variable "dns" is defined as the content of the DNS
205 request (as described in Section 6), encoded with base64url
206 [RFC4648].
207
208 Future specifications for new media types for DoH MUST define the
209 variables used for URI Template processing with this protocol.
210
211 DoH servers MUST implement both the POST and GET methods.
212
213
214
215
216
217 Hoffman & McManus Standards Track [Page 4]
218 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
219
220
221 When using the POST method, the DNS query is included as the message
222 body of the HTTP request, and the Content-Type request header field
223 indicates the media type of the message. POSTed requests are
224 generally smaller than their GET equivalents.
225
226 Using the GET method is friendlier to many HTTP cache
227 implementations.
228
229 The DoH client SHOULD include an HTTP Accept request header field to
230 indicate what type of content can be understood in response.
231 Irrespective of the value of the Accept request header field, the
232 client MUST be prepared to process "application/dns-message" (as
233 described in Section 6) responses but MAY also process other DNS-
234 related media types it receives.
235
236 In order to maximize HTTP cache friendliness, DoH clients using media
237 formats that include the ID field from the DNS message header, such
238 as "application/dns-message", SHOULD use a DNS ID of 0 in every DNS
239 request. HTTP correlates the request and response, thus eliminating
240 the need for the ID in a media type such as "application/dns-
241 message". The use of a varying DNS ID can cause semantically
242 equivalent DNS queries to be cached separately.
243
244 DoH clients can use HTTP/2 padding and compression [RFC7540] in the
245 same way that other HTTP/2 clients use (or don't use) them.
246
247 4.1.1. HTTP Request Examples
248
249 These examples use HTTP/2-style formatting from [RFC7540].
250
251 These examples use a DoH service with a URI Template of
252 "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A
253 records.
254
255 The requests are represented as bodies with media type "application/
256 dns-message".
257
258 The first example request uses GET to request "www.example.com".
259
260 :method = GET
261 :scheme = https
262 :authority = dnsserver.example.net
263 :path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
264 accept = application/dns-message
265
266
267
268
269
270
271
272 Hoffman & McManus Standards Track [Page 5]
273 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
274
275
276 The same DNS query for "www.example.com", using the POST method would
277 be:
278
279 :method = POST
280 :scheme = https
281 :authority = dnsserver.example.net
282 :path = /dns-query
283 accept = application/dns-message
284 content-type = application/dns-message
285 content-length = 33
286
287 <33 bytes represented by the following hex encoding>
288 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77
289 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
290 01
291
292 In this example, the 33 bytes are the DNS message in DNS wire format
293 [RFC1035], starting with the DNS header.
294
295 Finally, a GET-based query for "a.62characterlabel-makes-base64url-
296 distinct-from-standard-base64.example.com" is shown as an example to
297 emphasize that the encoding alphabet of base64url is different than
298 regular base64 and that padding is omitted.
299
300 The DNS query, expressed in DNS wire format, is 94 bytes represented
301 by the following:
302
303 00 00 01 00 00 01 00 00 00 00 00 00 01 61 3e 36
304 32 63 68 61 72 61 63 74 65 72 6c 61 62 65 6c 2d
305 6d 61 6b 65 73 2d 62 61 73 65 36 34 75 72 6c 2d
306 64 69 73 74 69 6e 63 74 2d 66 72 6f 6d 2d 73 74
307 61 6e 64 61 72 64 2d 62 61 73 65 36 34 07 65 78
308 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01
309
310 :method = GET
311 :scheme = https
312 :authority = dnsserver.example.net
313 :path = /dns-query? (no space or Carriage Return (CR))
314 dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR)
315 bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR)
316 dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ
317 accept = application/dns-message
318
319
320
321
322
323
324
325
326
327 Hoffman & McManus Standards Track [Page 6]
328 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
329
330
331 4.2. The HTTP Response
332
333 The only response type defined in this document is "application/dns-
334 message", but it is possible that other response formats will be
335 defined in the future. A DoH server MUST be able to process
336 "application/dns-message" request messages.
337
338 Different response media types will provide more or less information
339 from a DNS response. For example, one response type might include
340 information from the DNS header bytes while another might omit it.
341 The amount and type of information that a media type gives are solely
342 up to the format, which is not defined in this protocol.
343
344 Each DNS request-response pair is mapped to one HTTP exchange. The
345 responses may be processed and transported in any order using HTTP's
346 multi-streaming functionality (see Section 5 of [RFC7540]).
347
348 Section 5.1 discusses the relationship between DNS and HTTP response
349 caching.
350
351 4.2.1. Handling DNS and HTTP Errors
352
353 DNS response codes indicate either success or failure for the DNS
354 query. A successful HTTP response with a 2xx status code (see
355 Section 6.3 of [RFC7231]) is used for any valid DNS response,
356 regardless of the DNS response code. For example, a successful 2xx
357 HTTP status code is used even with a DNS message whose DNS response
358 code indicates failure, such as SERVFAIL or NXDOMAIN.
359
360 HTTP responses with non-successful HTTP status codes do not contain
361 replies to the original DNS question in the HTTP request. DoH
362 clients need to use the same semantic processing of non-successful
363 HTTP status codes as other HTTP clients. This might mean that the
364 DoH client retries the query with the same DoH server, such as if
365 there are authorization failures (HTTP status code 401; see
366 Section 3.1 of [RFC7235]). It could also mean that the DoH client
367 retries with a different DoH server, such as for unsupported media
368 types (HTTP status code 415; see Section 6.5.13 of [RFC7231]), or
369 where the server cannot generate a representation suitable for the
370 client (HTTP status code 406; see Section 6.5.6 of [RFC7231]), and so
371 on.
372
373
374
375
376
377
378
379
380
381
382 Hoffman & McManus Standards Track [Page 7]
383 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
384
385
386 4.2.2. HTTP Response Example
387
388 This is an example response for a query for the IN AAAA records for
389 "www.example.com" with recursion turned on. The response bears one
390 answer record with an address of 2001:db8:abcd:12:1:2:3:4 and a TTL
391 of 3709 seconds.
392
393 :status = 200
394 content-type = application/dns-message
395 content-length = 61
396 cache-control = max-age=3709
397
398 <61 bytes represented by the following hex encoding>
399 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77
400 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 1c 00
401 01 c0 0c 00 1c 00 01 00 00 0e 7d 00 10 20 01 0d
402 b8 ab cd 00 12 00 01 00 02 00 03 00 04
403
404 5. HTTP Integration
405
406 This protocol MUST be used with the https URI scheme [RFC7230].
407
408 Sections 8 and 9 discuss additional considerations for the
409 integration with HTTP.
410
411 5.1. Cache Interaction
412
413 A DoH exchange can pass through a hierarchy of caches that include
414 both HTTP- and DNS-specific caches. These caches may exist between
415 the DoH server and client, or they may exist on the DoH client
416 itself. HTTP caches are generic by design; that is, they do not
417 understand this protocol. Even if a DoH client has modified its
418 cache implementation to be aware of DoH semantics, it does not follow
419 that all upstream caches (for example, inline proxies, server-side
420 gateways, and content delivery networks) will be.
421
422 As a result, DoH servers need to carefully consider the HTTP caching
423 metadata they send in response to GET requests (responses to POST
424 requests are not cacheable unless specific response header fields are
425 sent; this is not widely implemented and is not advised for DoH).
426
427 In particular, DoH servers SHOULD assign an explicit HTTP freshness
428 lifetime (see Section 4.2 of [RFC7234]) so that the DoH client is
429 more likely to use fresh DNS data. This requirement is due to HTTP
430 caches being able to assign their own heuristic freshness (such as
431 that described in Section 4.2.2 of [RFC7234]), which would take
432 control of the cache contents out of the hands of the DoH server.
433
434
435
436
437 Hoffman & McManus Standards Track [Page 8]
438 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
439
440
441 The assigned freshness lifetime of a DoH HTTP response MUST be less
442 than or equal to the smallest TTL in the Answer section of the DNS
443 response. A freshness lifetime equal to the smallest TTL in the
444 Answer section is RECOMMENDED. For example, if a HTTP response
445 carries three RRsets with TTLs of 30, 600, and 300, the HTTP
446 freshness lifetime should be 30 seconds (which could be specified as
447 "Cache-Control: max-age=30"). This requirement helps prevent expired
448 RRsets in messages in an HTTP cache from unintentionally being
449 served.
450
451 If the DNS response has no records in the Answer section, and the DNS
452 response has an SOA record in the Authority section, the response
453 freshness lifetime MUST NOT be greater than the MINIMUM field from
454 that SOA record (see [RFC2308]).
455
456 The stale-while-revalidate and stale-if-error Cache-Control
457 directives [RFC5861] could be well suited to a DoH implementation
458 when allowed by server policy. Those mechanisms allow a client, at
459 the server's discretion, to reuse an HTTP cache entry that is no
460 longer fresh. In such a case, the client reuses either all of a
461 cached entry or none of it.
462
463 DoH servers also need to consider HTTP caching when generating
464 responses that are not globally valid. For instance, if a DoH server
465 customizes a response based on the client's identity, it would not
466 want to allow global reuse of that response. This could be
467 accomplished through a variety of HTTP techniques, such as a Cache-
468 Control max-age of 0, or by using the Vary response header field (see
469 Section 7.1.4 of [RFC7231]) to establish a secondary cache key (see
470 Section 4.1 of [RFC7234]).
471
472 DoH clients MUST account for the Age response header field's value
473 [RFC7234] when calculating the DNS TTL of a response. For example,
474 if an RRset is received with a DNS TTL of 600, but the Age header
475 field indicates that the response has been cached for 250 seconds,
476 the remaining lifetime of the RRset is 350 seconds. This requirement
477 applies to both DoH client HTTP caches and DoH client DNS caches.
478
479 DoH clients can request an uncached copy of a HTTP response by using
480 the "no-cache" request Cache-Control directive (see Section 5.2.1.4
481 of [RFC7234]) and similar controls. Note that some caches might not
482 honor these directives, either due to configuration or interaction
483 with traditional DNS caches that do not have such a mechanism.
484
485 HTTP conditional requests [RFC7232] may be of limited value to DoH,
486 as revalidation provides only a bandwidth benefit and DNS
487 transactions are normally latency bound. Furthermore, the HTTP
488 response header fields that enable revalidation (such as "Last-
489
490
491
492 Hoffman & McManus Standards Track [Page 9]
493 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
494
495
496 Modified" and "Etag") are often fairly large when compared to the
497 overall DNS response size and have a variable nature that creates
498 constant pressure on the HTTP/2 compression dictionary [RFC7541].
499 Other types of DNS data, such as zone transfers, may be larger and
500 benefit more from revalidation.
501
502 5.2. HTTP/2
503
504 HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
505 with DoH.
506
507 The messages in classic UDP-based DNS [RFC1035] are inherently
508 unordered and have low overhead. A competitive HTTP transport needs
509 to support reordering, parallelism, priority, and header compression
510 to achieve similar performance. Those features were introduced to
511 HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of
512 conveying the semantic requirements of DoH but may result in very
513 poor performance.
514
515 5.3. Server Push
516
517 Before using DoH response data for DNS resolution, the client MUST
518 establish that the HTTP request URI can be used for the DoH query.
519 For HTTP requests initiated by the DoH client, this is implicit in
520 the selection of URI. For HTTP server push (see Section 8.2 of
521 [RFC7540]), extra care must be taken to ensure that the pushed URI is
522 one that the client would have directed the same query to if the
523 client had initiated the request (in addition to the other security
524 checks normally needed for server push).
525
526 5.4. Content Negotiation
527
528 In order to maximize interoperability, DoH clients and DoH servers
529 MUST support the "application/dns-message" media type. Other media
530 types MAY be used as defined by HTTP Content Negotiation (see
531 Section 3.4 of [RFC7231]). Those media types MUST be flexible enough
532 to express every DNS query that would normally be sent in DNS over
533 UDP (including queries and responses that use DNS extensions, but not
534 those that require multiple responses).
535
536 6. Definition of the "application/dns-message" Media Type
537
538 The data payload for the "application/dns-message" media type is a
539 single message of the DNS on-the-wire format defined in Section 4.2.1
540 of [RFC1035], which in turn refers to the full wire format defined in
541 Section 4.1 of that RFC.
542
543
544
545
546
547 Hoffman & McManus Standards Track [Page 10]
548 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
549
550
551 Although [RFC1035] says "Messages carried by UDP are restricted to
552 512 bytes", that was later updated by [RFC6891]. This media type
553 restricts the maximum size of the DNS message to 65535 bytes.
554
555 Note that the wire format used in this media type is different than
556 the wire format used in [RFC7858] (which uses the format defined in
557 Section 4.2.2 of [RFC1035] that includes two length bytes).
558
559 DoH clients using this media type MAY have one or more Extension
560 Mechanisms for DNS (EDNS) options [RFC6891] in the request. DoH
561 servers using this media type MUST ignore the value given for the
562 EDNS UDP payload size in DNS requests.
563
564 When using the GET method, the data payload for this media type MUST
565 be encoded with base64url [RFC4648] and then provided as a variable
566 named "dns" to the URI Template expansion. Padding characters for
567 base64url MUST NOT be included.
568
569 When using the POST method, the data payload for this media type MUST
570 NOT be encoded and is used directly as the HTTP message body.
571
572 7. IANA Considerations
573
574 7.1. Registration of the "application/dns-message" Media Type
575
576 Type name: application
577
578 Subtype name: dns-message
579
580 Required parameters: N/A
581
582 Optional parameters: N/A
583
584 Encoding considerations: This is a binary format. The contents are a
585 DNS message as defined in RFC 1035. The format used here is for
586 DNS over UDP, which is the format defined in the diagrams in
587 RFC 1035.
588
589 Security considerations: See RFC 8484. The content is a DNS message
590 and thus not executable code.
591
592 Interoperability considerations: None.
593
594 Published specification: RFC 8484.
595
596 Applications that use this media type:
597 Systems that want to exchange full DNS messages.
598
599
600
601
602 Hoffman & McManus Standards Track [Page 11]
603 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
604
605
606 Additional information:
607
608 Deprecated alias names for this type: N/A
609 Magic number(s): N/A
610 File extension(s): N/A
611 Macintosh file type code(s): N/A
612
613 Person & email address to contact for further information:
614 Paul Hoffman <paul.hoffman@icann.org>
615
616 Intended usage: COMMON
617
618 Restrictions on usage: N/A
619
620 Author: Paul Hoffman <paul.hoffman@icann.org>
621
622 Change controller: IESG
623
624 8. Privacy Considerations
625
626 [RFC7626] discusses DNS privacy considerations in both "on the wire"
627 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of
628 [RFC7626]) contexts. This is also a useful framing for DoH's privacy
629 considerations.
630
631 8.1. On the Wire
632
633 DoH encrypts DNS traffic and requires authentication of the server.
634 This mitigates both passive surveillance [RFC7258] and active attacks
635 that attempt to divert DNS traffic to rogue servers (see
636 Section 2.5.1 of [RFC7626]). DNS over TLS [RFC7858] provides similar
637 protections, while direct UDP- and TCP-based transports are
638 vulnerable to this class of attack. An experimental effort to offer
639 guidance on choosing the padding length can be found in [RFC8467].
640
641 Additionally, the use of the HTTPS default port 443 and the ability
642 to mix DoH traffic with other HTTPS traffic on the same connection
643 can deter unprivileged on-path devices from interfering with DNS
644 operations and make DNS traffic analysis more difficult.
645
646 8.2. In the Server
647
648 The DNS wire format [RFC1035] contains no client identifiers;
649 however, various transports of DNS queries and responses do provide
650 data that can be used to correlate requests. HTTPS presents new
651 considerations for correlation, such as explicit HTTP cookies and
652 implicit fingerprinting of the unique set and ordering of HTTP
653 request header fields.
654
655
656
657 Hoffman & McManus Standards Track [Page 12]
658 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
659
660
661 A DoH implementation is built on IP, TCP, TLS, and HTTP. Each layer
662 contains one or more common features that can be used to correlate
663 queries to the same identity. DNS transports will generally carry
664 the same privacy properties of the layers used to implement them.
665 For example, the properties of IP, TCP, and TLS apply to
666 implementations of DNS over TLS.
667
668 The privacy considerations of using the HTTPS layer in DoH are
669 incremental to those of DNS over TLS. DoH is not known to introduce
670 new concerns beyond those associated with HTTPS.
671
672 At the IP level, the client address provides obvious correlation
673 information. This can be mitigated by use of a NAT, proxy, VPN, or
674 simple address rotation over time. It may be aggravated by use of a
675 DNS server that can correlate real-time addressing information with
676 other personal identifiers, such as when a DNS server and DHCP server
677 are operated by the same entity.
678
679 DNS implementations that use one TCP connection for multiple DNS
680 requests directly group those requests. Long-lived connections have
681 better performance behaviors than short-lived connections; however,
682 they group more requests, which can expose more information to
683 correlation and consolidation. TCP-based solutions may also seek
684 performance through the use of TCP Fast Open [RFC7413]. The cookies
685 used in TCP Fast Open allow servers to correlate TCP sessions.
686
687 TLS-based implementations often achieve better handshake performance
688 through the use of some form of session resumption mechanism, such as
689 Section 2.2 of [RFC8446]. Session resumption creates trivial
690 mechanisms for a server to correlate TLS connections together.
691
692 HTTP's feature set can also be used for identification and tracking
693 in a number of different ways. For example, Authentication request
694 header fields explicitly identify profiles in use, and HTTP cookies
695 are designed as an explicit state-tracking mechanism between the
696 client and serving site and often are used as an authentication
697 mechanism.
698
699 Additionally, the User-Agent and Accept-Language request header
700 fields often convey specific information about the client version or
701 locale. This facilitates content negotiation and operational work-
702 arounds for implementation bugs. Request header fields that control
703 caching can expose state information about a subset of the client's
704 history. Mixing DoH requests with other HTTP requests on the same
705 connection also provides an opportunity for richer data correlation.
706
707
708
709
710
711
712 Hoffman & McManus Standards Track [Page 13]
713 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
714
715
716 The DoH protocol design allows applications to fully leverage the
717 HTTP ecosystem, including features that are not enumerated here.
718 Utilizing the full set of HTTP features enables DoH to be more than
719 an HTTP tunnel, but it is at the cost of opening up implementations
720 to the full set of privacy considerations of HTTP.
721
722 Implementations of DoH clients and servers need to consider the
723 benefit and privacy impact of these features, and their deployment
724 context, when deciding whether or not to enable them.
725 Implementations are advised to expose the minimal set of data needed
726 to achieve the desired feature set.
727
728 Determining whether or not a DoH implementation requires HTTP cookie
729 [RFC6265] support is particularly important because HTTP cookies are
730 the primary state tracking mechanism in HTTP. HTTP cookies SHOULD
731 NOT be accepted by DOH clients unless they are explicitly required by
732 a use case.
733
734 9. Security Considerations
735
736 Running DNS over HTTPS relies on the security of the underlying HTTP
737 transport. This mitigates classic amplification attacks for UDP-
738 based DNS. Implementations utilizing HTTP/2 benefit from the TLS
739 profile defined in Section 9.2 of [RFC7540].
740
741 Session-level encryption has well-known weaknesses with respect to
742 traffic analysis, which might be particularly acute when dealing with
743 DNS queries. HTTP/2 provides further advice about the use of
744 compression (see Section 10.6 of [RFC7540]) and padding (see
745 Section 10.7 of [RFC7540]). DoH servers can also add DNS padding
746 [RFC7830] if the DoH client requests it in the DNS query. An
747 experimental effort to offer guidance on choosing the padding length
748 can be found in [RFC8467].
749
750 The HTTPS connection provides transport security for the interaction
751 between the DoH server and client, but it does not provide the
752 response integrity of DNS data provided by DNSSEC. DNSSEC and DoH
753 are independent and fully compatible protocols, each solving
754 different problems. The use of one does not diminish the need nor
755 the usefulness of the other. It is the choice of a client to either
756 perform full DNSSEC validation of answers or to trust the DoH server
757 to do DNSSEC validation and inspect the AD (Authentic Data) bit in
758 the returned message to determine whether an answer was authentic or
759 not. As noted in Section 4.2, different response media types will
760 provide more or less information from a DNS response, so this choice
761 may be affected by the response media type.
762
763
764
765
766
767 Hoffman & McManus Standards Track [Page 14]
768 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
769
770
771 Section 5.1 describes the interaction of this protocol with HTTP
772 caching. An adversary that can control the cache used by the client
773 can affect that client's view of the DNS. This is no different than
774 the security implications of HTTP caching for other protocols that
775 use HTTP.
776
777 In the absence of DNSSEC information, a DoH server can give a client
778 invalid data in response to a DNS query. Section 3 disallows the use
779 of DoH DNS responses that do not originate from configured servers.
780 This prohibition does not guarantee protection against invalid data,
781 but it does reduce the risk.
782
The URI Template defined in this document is processed without any variables when the HTTP method is POST. When the HTTP method is GET, the single variable "dns" is defined as the content of the DNS request (as described in Section 6), encoded with base64url [RFC4648].
The URI Template defined in this document is processed without any variables when the HTTP method is POST. When the HTTP method is GET, the single variable "dns" is defined as the content of the DNS request (as described in Section 6), encoded with base64url [RFC4648]. Padding characters for base64url MUST NOT be included.
Note that Section 6 does say the same thing for a different usage of base64url, and note that the examples in 4.1.1 even explicitly state this, but the text that states the usual deviation from the default of RFC 4648 should be in the defining part as well. (This is almost, but not quite, an editorial erratum.)
783 10. Operational Considerations
784
785 Local policy considerations and similar factors mean different DNS
786 servers may provide different results to the same query, for
787 instance, in split DNS configurations [RFC6950]. It logically
788 follows that the server that is queried can influence the end result.
789 Therefore, a client's choice of DNS server may affect the responses
790 it gets to its queries. For example, in the case of DNS64 [RFC6147],
791 the choice could affect whether IPv6/IPv4 translation will work at
792 all.
793
794 The HTTPS channel used by this specification establishes secure two-
795 party communication between the DoH client and the DoH server.
796 Filtering or inspection systems that rely on unsecured transport of
797 DNS will not function in a DNS over HTTPS environment due to the
798 confidentiality and integrity protection provided by TLS.
799
800 Some HTTPS client implementations perform real time third-party
801 checks of the revocation status of the certificates being used by
802 TLS. If this check is done as part of the DoH server connection
803 procedure and the check itself requires DNS resolution to connect to
804 the third party, a deadlock can occur. The use of Online Certificate
805 Status Protocol (OCSP) [RFC6960] servers or Authority Information
806 Access (AIA) for Certificate Revocation List (CRL) fetching (see
807 Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can
808 happen. To mitigate the possibility of deadlock, the authentication
809 given DoH servers SHOULD NOT rely on DNS-based references to external
810 resources in the TLS handshake. For OCSP, the server can bundle the
811 certificate status as part of the handshake using a mechanism
812 appropriate to the version of TLS, such as using Section 4.4.2.1 of
813 [RFC8446] for TLS version 1.3. AIA deadlocks can be avoided by
814 providing intermediate certificates that might otherwise be obtained
815 through additional requests. Note that these deadlocks also need to
816 be considered for servers that a DoH server might redirect to.
817
818
819
820
821
822 Hoffman & McManus Standards Track [Page 15]
823 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
824
825
826 A DoH client may face a similar bootstrapping problem when the HTTP
827 request needs to resolve the hostname portion of the DNS URI. Just
828 as the address of a traditional DNS nameserver cannot be originally
829 determined from that same server, a DoH client cannot use its DoH
830 server to initially resolve the server's host name into an address.
831 Alternative strategies a client might employ include 1) making the
832 initial resolution part of the configuration, 2) IP-based URIs and
833 corresponding IP-based certificates for HTTPS, or 3) resolving the
834 DNS API server's hostname via traditional DNS or another DoH server
835 while still authenticating the resulting connection via HTTPS.
836
837 HTTP [RFC7230] is a stateless application-level protocol, and
838 therefore DoH implementations do not provide stateful ordering
839 guarantees between different requests. DoH cannot be used as a
840 transport for other protocols that require strict ordering.
841
842 A DoH server is allowed to answer queries with any valid DNS
843 response. For example, a valid DNS response might have the TC
844 (truncation) bit set in the DNS header to indicate that the server
845 was not able to retrieve a full answer for the query but is providing
846 the best answer it could get. A DoH server can reply to queries with
847 an HTTP error for queries that it cannot fulfill. In this same
848 example, a DoH server could use an HTTP error instead of a non-error
849 response that has the TC bit set.
850
851 Many extensions to DNS, using [RFC6891], have been defined over the
852 years. Extensions that are specific to the choice of transport, such
853 as [RFC7828], are not applicable to DoH.
854
855 11. References
856
857 11.1. Normative References
858
859 [RFC1035] Mockapetris, P., "Domain names - implementation and
860 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
861 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
862
863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
864 Requirement Levels", BCP 14, RFC 2119,
865 DOI 10.17487/RFC2119, March 1997,
866 <https://www.rfc-editor.org/info/rfc2119>.
867
868 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
869 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
870 <https://www.rfc-editor.org/info/rfc2308>.
871
872
873
874
875
876
877 Hoffman & McManus Standards Track [Page 16]
878 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
879
880
881 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
882 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
883 <https://www.rfc-editor.org/info/rfc4648>.
884
885 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
886 DOI 10.17487/RFC6265, April 2011,
887 <https://www.rfc-editor.org/info/rfc6265>.
888
889 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
890 and D. Orchard, "URI Template", RFC 6570,
891 DOI 10.17487/RFC6570, March 2012,
892 <https://www.rfc-editor.org/info/rfc6570>.
893
894 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
895 Protocol (HTTP/1.1): Message Syntax and Routing",
896 RFC 7230, DOI 10.17487/RFC7230, June 2014,
897 <https://www.rfc-editor.org/info/rfc7230>.
898
899 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
900 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
901 DOI 10.17487/RFC7231, June 2014,
902 <https://www.rfc-editor.org/info/rfc7231>.
903
904 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
905 Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
906 DOI 10.17487/RFC7232, June 2014,
907 <https://www.rfc-editor.org/info/rfc7232>.
908
909 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
910 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
911 RFC 7234, DOI 10.17487/RFC7234, June 2014,
912 <https://www.rfc-editor.org/info/rfc7234>.
913
914 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
915 Protocol (HTTP/1.1): Authentication", RFC 7235,
916 DOI 10.17487/RFC7235, June 2014,
917 <https://www.rfc-editor.org/info/rfc7235>.
918
919 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
920 Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
921 DOI 10.17487/RFC7540, May 2015,
922 <https://www.rfc-editor.org/info/rfc7540>.
923
924 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
925 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
926 <https://www.rfc-editor.org/info/rfc7541>.
927
928
929
930
931
932 Hoffman & McManus Standards Track [Page 17]
933 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
934
935
936 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
937 DOI 10.17487/RFC7626, August 2015,
938 <https://www.rfc-editor.org/info/rfc7626>.
939
940 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
941 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
942 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
943
944 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
945 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
946 <https://www.rfc-editor.org/info/rfc8446>.
947
948 11.2. Informative References
949
950 [FETCH] "Fetch Living Standard", August 2018,
951 <https://fetch.spec.whatwg.org/>.
952
953 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
954 DOI 10.17487/RFC2818, May 2000,
955 <https://www.rfc-editor.org/info/rfc2818>.
956
957 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
958 Housley, R., and W. Polk, "Internet X.509 Public Key
959 Infrastructure Certificate and Certificate Revocation List
960 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
961 <https://www.rfc-editor.org/info/rfc5280>.
962
963 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
964 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
965 <https://www.rfc-editor.org/info/rfc5861>.
966
967 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
968 Beijnum, "DNS64: DNS Extensions for Network Address
969 Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
970 DOI 10.17487/RFC6147, April 2011,
971 <https://www.rfc-editor.org/info/rfc6147>.
972
973 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
974 for DNS (EDNS(0))", STD 75, RFC 6891,
975 DOI 10.17487/RFC6891, April 2013,
976 <https://www.rfc-editor.org/info/rfc6891>.
977
978 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
979 "Architectural Considerations on Application Features in
980 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
981 <https://www.rfc-editor.org/info/rfc6950>.
982
983
984
985
986
987 Hoffman & McManus Standards Track [Page 18]
988 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
989
990
991 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
992 Galperin, S., and C. Adams, "X.509 Internet Public Key
993 Infrastructure Online Certificate Status Protocol - OCSP",
994 RFC 6960, DOI 10.17487/RFC6960, June 2013,
995 <https://www.rfc-editor.org/info/rfc6960>.
996
997 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
998 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
999 2014, <https://www.rfc-editor.org/info/rfc7258>.
1000
1001 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
1002 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
1003 <https://www.rfc-editor.org/info/rfc7413>.
1004
1005 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
1006 edns-tcp-keepalive EDNS0 Option", RFC 7828,
1007 DOI 10.17487/RFC7828, April 2016,
1008 <https://www.rfc-editor.org/info/rfc7828>.
1009
1010 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
1011 DOI 10.17487/RFC7830, May 2016,
1012 <https://www.rfc-editor.org/info/rfc7830>.
1013
1014 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1015 and P. Hoffman, "Specification for DNS over Transport
1016 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1017 2016, <https://www.rfc-editor.org/info/rfc7858>.
1018
1019 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
1020 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
1021 October 2018, <https://www.rfc-editor.org/info/rfc8467>.
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Hoffman & McManus Standards Track [Page 19]
1043 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
1044
1045
1046 Appendix A. Protocol Development
1047
1048 This appendix describes the requirements used to design DoH. These
1049 requirements are listed here to help readers understand the current
1050 protocol, not to limit how the protocol might be developed in the
1051 future. This appendix is non-normative.
1052
1053 The protocol described in this document based its design on the
1054 following protocol requirements:
1055
1056 o The protocol must use normal HTTP semantics.
1057
1058 o The queries and responses must be able to be flexible enough to
1059 express every DNS query that would normally be sent in DNS over
1060 UDP (including queries and responses that use DNS extensions, but
1061 not those that require multiple responses).
1062
1063 o The protocol must permit the addition of new formats for DNS
1064 queries and responses.
1065
1066 o The protocol must ensure interoperability by specifying a single
1067 format for requests and responses that is mandatory to implement.
1068 That format must be able to support future modifications to the
1069 DNS protocol including the inclusion of one or more EDNS options
1070 (including those not yet defined).
1071
1072 o The protocol must use a secure transport that meets the
1073 requirements for HTTPS.
1074
1075 The following were considered non-requirements:
1076
1077 o Supporting network-specific DNS64 [RFC6147]
1078
1079 o Supporting other network-specific inferences from plaintext DNS
1080 queries
1081
1082 o Supporting insecure HTTP
1083
1084 Appendix B. Previous Work on DNS over HTTP or in Other Formats
1085
1086 The following is an incomplete list of earlier work that related to
1087 DNS over HTTP/1 or representing DNS data in other formats.
1088
1089 The list includes links to the tools.ietf.org site (because these
1090 documents are all expired) and web sites of software.
1091
1092 o <https://tools.ietf.org/html/draft-mohan-dns-query-xml>
1093
1094
1095
1096
1097 Hoffman & McManus Standards Track [Page 20]
1098 RFC 8484 DNS Queries over HTTPS (DoH) October 2018
1099
1100
1101 o <https://tools.ietf.org/html/draft-daley-dnsxml>
1102
1103 o <https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof>
1104
1105 o <https://tools.ietf.org/html/draft-bortzmeyer-dns-json>
1106
1107 o <https://www.nlnetlabs.nl/projects/dnssec-trigger/>
1108
1109 Acknowledgments
1110
1111 This work required a high level of cooperation between experts in
1112 different technologies. Thank you Ray Bellis, Stephane Bortzmeyer,
1113 Manu Bretelle, Sara Dickinson, Massimiliano Fantuzzi, Tony Finch,
1114 Daniel Kahn Gilmor, Olafur Gudmundsson, Wes Hardaker, Rory Hewitt,
1115 Joe Hildebrand, David Lawrence, Eliot Lear, John Mattsson, Alex
1116 Mayrhofer, Mark Nottingham, Jim Reid, Adam Roach, Ben Schwartz, Davey
1117 Song, Daniel Stenberg, Andrew Sullivan, Martin Thomson, and Sam
1118 Weiler.
1119
1120 Authors' Addresses
1121
1122 Paul Hoffman
1123 ICANN
1124
1125 Email: paul.hoffman@icann.org
1126
1127
1128 Patrick McManus
1129 Mozilla
1130
1131 Email: mcmanus@ducksong.com
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152 Hoffman & McManus Standards Track [Page 21]
1153
The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers or Authority Information Access (AIA) for Certificate Revocation List (CRL) fetching (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen.
The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers, Certificate Revocation List (CRL) distribution points (see Section 4.2.1.13 of [RFC5280]), or Authority Information Access (AIA) to retrieve issuer certificates (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen.
The OCSP part is fine, but the AIA piece is wrong. For context, there are three different ways (to my knowledge) that a client might make outbound connections in order to validate or build a certification path. 1. CRL - clients fetch CRLs from the designated location. This rarely happens any more as it is grossly inefficient, but it does still happen in some usages. 2. OCSP - clients query OCSP for the status of a certificate. 3. AIA chasing - this is where the TLS handshake doesn't include the full set of certificates required to validate the end-entity certificate, but the certificate includes a URL for that certificate. AIA itself is a multi-purpose field. It can include multiple elements, one of which is the identity of an OCSP responder (the same one used in (2) above) and the other being the one used in (3). It does not include CRL distribution points, as the text implies.