1 Internet Engineering Task Force (IETF) C. Huitema
2 Request for Comments: 9250 Private Octopus Inc.
3 Category: Standards Track S. Dickinson
4 ISSN: 2070-1721 Sinodun IT
5 A. Mankin
6 Salesforce
7 May 2022
8
9
10 DNS over Dedicated QUIC Connections
11
12 Abstract
13
14 This document describes the use of QUIC to provide transport
15 confidentiality for DNS. The encryption provided by QUIC has similar
16 properties to those provided by TLS, while QUIC transport eliminates
17 the head-of-line blocking issues inherent with TCP and provides more
18 efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has
19 privacy properties similar to DNS over TLS (DoT) specified in RFC
20 7858, and latency characteristics similar to classic DNS over UDP.
21 This specification describes the use of DoQ as a general-purpose
22 transport for DNS and includes the use of DoQ for stub to recursive,
23 recursive to authoritative, and zone transfer scenarios.
24
25 Status of This Memo
26
27 This is an Internet Standards Track document.
28
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 7841.
34
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 https://www.rfc-editor.org/info/rfc9250.
38
39 Copyright Notice
40
41 Copyright (c) 2022 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
43
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Revised BSD License text as described in Section 4.e of the
51 Trust Legal Provisions and are provided without warranty as described
52 in the Revised BSD License.
53
54 Table of Contents
55
56 1. Introduction
57 2. Key Words
58 3. Design Considerations
59 3.1. Provide DNS Privacy
60 3.2. Design for Minimum Latency
61 3.3. Middlebox Considerations
62 3.4. No Server-Initiated Transactions
63 4. Specifications
64 4.1. Connection Establishment
65 4.1.1. Port Selection
66 4.2. Stream Mapping and Usage
67 4.2.1. DNS Message IDs
68 4.3. DoQ Error Codes
69 4.3.1. Transaction Cancellation
70 4.3.2. Transaction Errors
71 4.3.3. Protocol Errors
72 4.3.4. Alternative Error Codes
73 4.4. Connection Management
74 4.5. Session Resumption and 0-RTT
75 4.6. Message Sizes
76 5. Implementation Requirements
77 5.1. Authentication
78 5.2. Fallback to Other Protocols on Connection Failure
79 5.3. Address Validation
80 5.4. Padding
81 5.5. Connection Handling
82 5.5.1. Connection Reuse
83 5.5.2. Resource Management
84 5.5.3. Using 0-RTT and Session Resumption
85 5.5.4. Controlling Connection Migration for Privacy
86 5.6. Processing Queries in Parallel
87 5.7. Zone Transfer
88 5.8. Flow Control Mechanisms
89 6. Security Considerations
90 7. Privacy Considerations
91 7.1. Privacy Issues with 0-RTT data
92 7.2. Privacy Issues with Session Resumption
93 7.3. Privacy Issues with Address Validation Tokens
94 7.4. Privacy Issues with Long Duration Sessions
95 7.5. Traffic Analysis
96 8. IANA Considerations
97 8.1. Registration of a DoQ Identification String
98 8.2. Reservation of a Dedicated Port
99 8.3. Reservation of an Extended DNS Error Code: Too Early
100 8.4. DNS-over-QUIC Error Codes Registry
101 9. References
102 9.1. Normative References
103 9.2. Informative References
104 Appendix A. The NOTIFY Service
105 Acknowledgements
106 Authors' Addresses
107
108 1. Introduction
109
110 Domain Name System (DNS) concepts are specified in "Domain names -
111 concepts and facilities" [RFC1034]. The transmission of DNS queries
112 and responses over UDP and TCP is specified in "Domain names -
113 implementation and specification" [RFC1035].
114
115 This document presents a mapping of the DNS protocol over the QUIC
116 transport [RFC9000] [RFC9001]. DNS over QUIC is referred to here as
117 DoQ, in line with "DNS Terminology" [DNS-TERMS].
118
119 The goals of the DoQ mapping are:
120
121 1. Provide the same DNS privacy protection as DoT [RFC7858]. This
122 includes an option for the client to authenticate the server by
123 means of an authentication domain name as specified in "Usage
124 Profiles for DNS over TLS and DNS over DTLS" [RFC8310].
125
126 2. Provide an improved level of source address validation for DNS
127 servers compared to classic DNS over UDP.
128
129 3. Provide a transport that does not impose path MTU limitations on
130 the size of DNS responses it can send.
131
132 In order to achieve these goals, and to support ongoing work on
133 encryption of DNS, the scope of this document includes:
134
135 * the "stub to recursive resolver" scenario (also called the "stub
136 to recursive" scenario in this document)
137
138 * the "recursive resolver to authoritative nameserver" scenario
139 (also called the "recursive to authoritative" scenario in this
140 document), and
141
142 * the "nameserver to nameserver" scenario (mainly used for zone
143 transfers (XFR) [RFC1995] [RFC5936]).
144
145 In other words, this document specifies QUIC as a general-purpose
146 transport for DNS.
147
148 The specific non-goals of this document are:
149
150 1. No attempt is made to evade potential blocking of DoQ traffic by
151 middleboxes.
152
153 2. No attempt to support server-initiated transactions, which are
154 used only in DNS Stateful Operations (DSO) [RFC8490].
155
156 Specifying the transmission of an application over QUIC requires
157 specifying how the application's messages are mapped to QUIC streams,
158 and generally how the application will use QUIC. This is done for
159 HTTP in "Hypertext Transfer Protocol Version 3 (HTTP/3)" [HTTP/3].
160 The purpose of this document is to define the way DNS messages can be
161 transmitted over QUIC.
162
163 DNS over HTTPS (DoH) [RFC8484] can be used with HTTP/3 to get some of
164 the benefits of QUIC. However, a lightweight direct mapping for DoQ
165 can be regarded as a more natural fit for both the recursive to
166 authoritative and zone transfer scenarios, which rarely involve
167 intermediaries. In these scenarios, the additional overhead of HTTP
168 is not offset by, for example, benefits of HTTP proxying and caching
169 behavior.
170
171 In this document, Section 3 presents the reasoning that guided the
172 proposed design. Section 4 specifies the actual mapping of DoQ.
173 Section 5 presents guidelines on the implementation, usage, and
174 deployment of DoQ.
175
176 2. Key Words
177
178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
180 "OPTIONAL" in this document are to be interpreted as described in
181 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
182 capitals, as shown here.
183
184 3. Design Considerations
185
186 This section and its subsections present the design guidelines that
187 were used for DoQ. While all other sections in this document are
188 normative, this section is informative in nature.
189
190 3.1. Provide DNS Privacy
191
192 DoT [RFC7858] defines how to mitigate some of the issues described in
193 "DNS Privacy Considerations" [RFC9076] by specifying how to transmit
194 DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS
195 over DTLS" [RFC8310] specify Strict and Opportunistic usage profiles
196 for DoT including how stub resolvers can authenticate recursive
197 resolvers.
198
199 QUIC connection setup includes the negotiation of security parameters
200 using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001],
201 enabling encryption of the QUIC transport. Transmitting DNS messages
202 over QUIC will provide essentially the same privacy protections as
203 DoT [RFC7858] including Strict and Opportunistic usage profiles
204 [RFC8310]. Further discussion on this is provided in Section 7.
205
206 3.2. Design for Minimum Latency
207
208 QUIC is specifically designed to reduce protocol-induced delays, with
209 features such as:
210
211 1. Support for 0-RTT data during session resumption.
212
213 2. Support for advanced packet-loss recovery procedures as specified
214 in "QUIC Loss Detection and Congestion Control" [RFC9002].
215
216 3. Mitigation of head-of-line blocking by allowing parallel delivery
217 of data on multiple streams.
218
219 This mapping of DNS to QUIC will take advantage of these features in
220 three ways:
221
222 1. Optional support for sending 0-RTT data during session resumption
223 (the security and privacy implications of this are discussed in
224 later sections).
225
226 2. Long-lived QUIC connections over which multiple DNS transactions
227 are performed, generating the sustained traffic required to
228 benefit from advanced recovery features.
229
230 3. Mapping of each DNS Query/Response transaction to a separate
231 stream, to mitigate head-of-line blocking. This enables servers
232 to respond to queries "out of order". It also enables clients to
233 process responses as soon as they arrive, without having to wait
234 for in-order delivery of responses previously posted by the
235 server.
236
237 These considerations are reflected in the mapping of DNS traffic to
238 QUIC streams in Section 4.2.
239
240 3.3. Middlebox Considerations
241
242 Using QUIC might allow a protocol to disguise its purpose from
243 devices on the network path using encryption and traffic analysis
244 resistance techniques like padding, traffic pacing, and traffic
245 shaping. This specification does not include any measures that are
246 designed to avoid such classification; the padding mechanisms defined
247 in Section 5.4 are intended to obfuscate the specific records
248 contained in DNS queries and responses, but not the fact that this is
249 DNS traffic. Consequently, firewalls and other middleboxes might be
250 able to distinguish DoQ from other protocols that use QUIC, like
251 HTTP, and apply different treatment.
252
253 The lack of measures in this specification to avoid protocol
254 classification is not an endorsement of such practices.
255
256 3.4. No Server-Initiated Transactions
257
258 As stated in Section 1, this document does not specify support for
259 server-initiated transactions within established DoQ connections.
260 That is, only the initiator of the DoQ connection may send queries
261 over the connection.
262
263 DSO does support server-initiated transactions within existing
264 connections. However, DoQ as defined here does not meet the criteria
265 for an applicable transport for DSO because it does not guarantee in-
266 order delivery of messages; see Section 4.2 of [RFC8490].
267
268 4. Specifications
269
270 4.1. Connection Establishment
271
272 DoQ connections are established as described in the QUIC transport
273 specification [RFC9000]. During connection establishment, DoQ
274 support is indicated by selecting the Application-Layer Protocol
275 Negotiation (ALPN) token "doq" in the crypto handshake.
276
277 4.1.1. Port Selection
278
279 By default, a DNS server that supports DoQ MUST listen for and accept
280 QUIC connections on the dedicated UDP port 853 (Section 8), unless
281 there is a mutual agreement to use another port.
282
283 By default, a DNS client desiring to use DoQ with a particular server
284 MUST establish a QUIC connection to UDP port 853 on the server,
285 unless there is a mutual agreement to use another port.
286
287 DoQ connections MUST NOT use UDP port 53. This recommendation
288 against use of port 53 for DoQ is to avoid confusion between DoQ and
289 the use of DNS over UDP [RFC1035]. The risk of confusion exists even
290 if two parties agreed on port 53, as other parties without knowledge
291 of that agreement might still try to use that port.
292
293 In the stub to recursive scenario, the use of port 443 as a mutually
294 agreed alternative port can be operationally beneficial, since port
295 443 is used by many services using QUIC and HTTP-3 and is thus less
296 likely to be blocked than other ports. Several mechanisms for stubs
297 to discover recursives offering encrypted transports, including the
298 use of custom ports, are the subject of ongoing work.
299
300 4.2. Stream Mapping and Usage
301
302 The mapping of DNS traffic over QUIC streams takes advantage of the
303 QUIC stream features detailed in Section 2 of [RFC9000], the QUIC
304 transport specification.
305
306 DNS query/response traffic [RFC1034] [RFC1035] follows a simple
307 pattern in which the client sends a query, and the server provides
308 one or more responses (multiple responses can occur in zone
309 transfers).
310
311 The mapping specified here requires that the client select a separate
312 QUIC stream for each query. The server then uses the same stream to
313 provide all the response messages for that query. In order for
314 multiple responses to be parsed, a 2-octet length field is used in
315 exactly the same way as the 2-octet length field defined for DNS over
316 TCP [RFC1035]. The practical result of this is that the content of
317 each QUIC stream is exactly the same as the content of a TCP
318 connection that would manage exactly one query.
319
320 All DNS messages (queries and responses) sent over DoQ connections
321 MUST be encoded as a 2-octet length field followed by the message
322 content as specified in [RFC1035].
323
324 The client MUST select the next available client-initiated
325 bidirectional stream for each subsequent query on a QUIC connection,
326 in conformance with the QUIC transport specification [RFC9000].
327 Packet losses and other network events might cause queries to arrive
328 in a different order. Servers SHOULD process queries as they arrive,
329 as not doing so would cause unnecessary delays.
330
331 The client MUST send the DNS query over the selected stream and MUST
332 indicate through the STREAM FIN mechanism that no further data will
333 be sent on that stream.
334
335 The server MUST send the response(s) on the same stream and MUST
336 indicate, after the last response, through the STREAM FIN mechanism
337 that no further data will be sent on that stream.
338
339 Therefore, a single DNS transaction consumes a single bidirectional
340 client-initiated stream. This means that the client's first query
341 occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1
342 of [RFC9000]).
343
344 Servers MAY defer processing of a query until the STREAM FIN has been
345 indicated on the stream selected by the client.
346
347 Servers and clients MAY monitor the number of "dangling" streams.
348 These are open streams where the following events have not occurred
349 after implementation-defined timeouts:
350
351 * the expected queries or responses have not been received or,
352
353 * the expected queries or responses have been received but not the
354 STREAM FIN
355
356 Implementations MAY impose a limit on the number of such dangling
357 streams. If limits are encountered, implementations MAY close the
358 connection.
359
360 4.2.1. DNS Message IDs
361
362 When sending queries over a QUIC connection, the DNS Message ID MUST
363 be set to 0. The stream mapping for DoQ allows for unambiguous
364 correlation of queries and responses, so the Message ID field is not
365 required.
366
367 This has implications for proxying DoQ messages to and from other
368 transports. For example, proxies may have to manage the fact that
369 DoQ can support a larger number of outstanding queries on a single
370 connection than, for example, DNS over TCP, because DoQ is not
371 limited by the Message ID space. This issue already exists for DoH,
372 where a Message ID of 0 is recommended.
373
374 When forwarding a DNS message from DoQ over another transport, a DNS
375 Message ID MUST be generated according to the rules of the protocol
376 that is in use. When forwarding a DNS message from another transport
377 over DoQ, the Message ID MUST be set to 0.
378
379 4.3. DoQ Error Codes
380
381 The following error codes are defined for use when abruptly
382 terminating streams, for use as application protocol error codes when
383 aborting reading of streams, or for immediately closing connections:
384
385 DOQ_NO_ERROR (0x0): No error. This is used when the connection or
386 stream needs to be closed, but there is no error to signal.
387
388 DOQ_INTERNAL_ERROR (0x1): The DoQ implementation encountered an
389 internal error and is incapable of pursuing the transaction or the
390 connection.
391
392 DOQ_PROTOCOL_ERROR (0x2): The DoQ implementation encountered a
393 protocol error and is forcibly aborting the connection.
394
395 DOQ_REQUEST_CANCELLED (0x3): A DoQ client uses this to signal that
396 it wants to cancel an outstanding transaction.
397
398 DOQ_EXCESSIVE_LOAD (0x4): A DoQ implementation uses this to signal
399 when closing a connection due to excessive load.
400
401 DOQ_UNSPECIFIED_ERROR (0x5): A DoQ implementation uses this in the
402 absence of a more specific error code.
403
404 DOQ_ERROR_RESERVED (0xd098ea5e): An alternative error code used for
405 tests.
406
407 See Section 8.4 for details on registering new error codes.
408
409 4.3.1. Transaction Cancellation
410
411 In QUIC, sending STOP_SENDING requests that a peer cease transmission
412 on a stream. If a DoQ client wishes to cancel an outstanding
413 request, it MUST issue a QUIC STOP_SENDING, and it SHOULD use the
414 error code DOQ_REQUEST_CANCELLED. It MAY use a more specific error
415 code registered according to Section 8.4. The STOP_SENDING request
416 may be sent at any time but will have no effect if the server
417 response has already been sent, in which case the client will simply
418 discard the incoming response. The corresponding DNS transaction
419 MUST be abandoned.
420
421 Servers that receive STOP_SENDING act in accordance with Section 3.5
422 of [RFC9000]. Servers SHOULD NOT continue processing a DNS
423 transaction if they receive a STOP_SENDING.
424
425 Servers MAY impose implementation limits on the total number or rate
426 of cancellation requests. If limits are encountered, servers MAY
427 close the connection. In this case, servers wanting to help client
428 debugging MAY use the error code DOQ_EXCESSIVE_LOAD. There is always
429 a trade-off between helping good faith clients debug issues and
430 allowing denial-of-service attackers to test server defenses;
431 depending on circumstances servers might very well choose to send
432 different error codes.
433
434 Note that this mechanism provides a way for secondaries to cancel a
435 single zone transfer occurring on a given stream without having to
436 close the QUIC connection.
437
438 Servers MUST NOT continue processing a DNS transaction if they
439 receive a RESET_STREAM request from the client before the client
440 indicates the STREAM FIN. The server MUST issue a RESET_STREAM to
441 indicate that the transaction is abandoned unless:
442
443 * it has already done so for another reason or
444
445 * it has already both sent the response and indicated the STREAM
446 FIN.
447
448 4.3.2. Transaction Errors
449
450 Servers normally complete transactions by sending a DNS response (or
451 responses) on the transaction's stream, including cases where the DNS
452 response indicates a DNS error. For example, a client SHOULD be
453 notified of a Server Failure (SERVFAIL, [RFC1035]) through a response
454 with the Response Code set to SERVFAIL.
455
456 If a server is incapable of sending a DNS response due to an internal
457 error, it SHOULD issue a QUIC RESET_STREAM frame. The error code
458 SHOULD be set to DOQ_INTERNAL_ERROR. The corresponding DNS
459 transaction MUST be abandoned. Clients MAY limit the number of
460 unsolicited QUIC RESET_STREAM frames received on a connection before
461 choosing to close the connection.
462
463 Note that this mechanism provides a way for primaries to abort a
464 single zone transfer occurring on a given stream without having to
465 close the QUIC connection.
466
467 4.3.3. Protocol Errors
468
469 Other error scenarios can occur due to malformed, incomplete, or
470 unexpected messages during a transaction. These include (but are not
471 limited to):
472
473 * a client or server receives a message with a non-zero Message ID
474
475 * a client or server receives a STREAM FIN before receiving all the
476 bytes for a message indicated in the 2-octet length field
477
478 * a client receives a STREAM FIN before receiving all the expected
479 responses
480
481 * a server receives more than one query on a stream
482
483 * a client receives a different number of responses on a stream than
484 expected (e.g., multiple responses to a query for an A record)
485
486 * a client receives a STOP_SENDING request
487
488 * the client or server does not indicate the expected STREAM FIN
489 after sending requests or responses (see Section 4.2)
490
491 * an implementation receives a message containing the edns-tcp-
492 keepalive EDNS(0) Option [RFC7828] (see Section 5.5.2)
493
494 * a client or a server attempts to open a unidirectional QUIC stream
495
496 * a server attempts to open a server-initiated bidirectional QUIC
497 stream
498
499 * a server receives a "replayable" transaction in 0-RTT data (for
500 servers not willing to handle this case, see Section 4.5)
501
502 If a peer encounters such an error condition, it is considered a
503 fatal error. It SHOULD forcibly abort the connection using QUIC's
504 CONNECTION_CLOSE mechanism and SHOULD use the DoQ error code
505 DOQ_PROTOCOL_ERROR. In some cases, it MAY instead silently abandon
506 the connection, which uses fewer of the local resources but makes
507 debugging at the offending node more difficult.
508
509 It is noted that the restrictions on use of the above EDNS(0) option
510 has implications for proxying messages from TCP/DoT/DoH over DoQ.
511
512 4.3.4. Alternative Error Codes
513
514 This specification describes specific error codes in Sections 4.3.1,
515 4.3.2, and 4.3.3. These error codes are meant to facilitate
516 investigation of failures and other incidents. New error codes may
517 be defined in future versions of DoQ or registered as specified in
518 Section 8.4.
519
520 Because new error codes can be defined without negotiation, use of an
521 error code in an unexpected context or receipt of an unknown error
522 code MUST be treated as equivalent to DOQ_UNSPECIFIED_ERROR.
523
524 Implementations MAY wish to test the support for the error code
525 extension mechanism by using error codes not listed in this document,
526 or they MAY use DOQ_ERROR_RESERVED.
527
528 4.4. Connection Management
529
530 Section 10 of [RFC9000], the QUIC transport specification, specifies
531 that connections can be closed in three ways:
532
533 * idle timeout
534
535 * immediate close
536
537 * stateless reset
538
539 Clients and servers implementing DoQ SHOULD negotiate use of the idle
540 timeout. Closing on idle timeout is done without any packet
541 exchange, which minimizes protocol overhead. Per Section 10.1 of
542 [RFC9000], the QUIC transport specification, the effective value of
543 the idle timeout is computed as the minimum of the values advertised
544 by the two endpoints. Practical considerations on setting the idle
545 timeout are discussed in Section 5.5.2.
546
547 Clients SHOULD monitor the idle time incurred on their connection to
548 the server, defined by the time spent since the last packet from the
549 server has been received. When a client prepares to send a new DNS
550 query to the server, it SHOULD check whether the idle time is
551 sufficiently lower than the idle timer. If it is, the client SHOULD
552 send the DNS query over the existing connection. If not, the client
553 SHOULD establish a new connection and send the query over that
554 connection.
555
556 Clients MAY discard their connections to the server before the idle
557 timeout expires. A client that has outstanding queries SHOULD close
558 the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and
559 the DoQ error code DOQ_NO_ERROR.
560
561 Clients and servers MAY close the connection for a variety of other
562 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers
563 that send packets over a connection discarded by their peer might
564 receive a stateless reset indication. If a connection fails, all the
565 in-progress transactions on that connection MUST be abandoned.
566
567 4.5. Session Resumption and 0-RTT
568
569 A client MAY take advantage of the session resumption and 0-RTT
570 mechanisms supported by QUIC transport [RFC9000] and QUIC TLS
571 [RFC9001] if the server supports them. Clients SHOULD consider
572 potential privacy issues associated with session resumption before
573 deciding to use this mechanism and specifically evaluate the trade-
574 offs presented in the various sections of this document. The privacy
575 issues are detailed in Sections 7.1 and 7.2, and the implementation
576 considerations are discussed in Section 5.5.3.
577
578 The 0-RTT mechanism MUST NOT be used to send DNS requests that are
579 not "replayable" transactions. In this specification, only
580 transactions that have an OPCODE of QUERY or NOTIFY are considered
581 replayable; therefore, other OPCODES MUST NOT be sent in 0-RTT data.
582 See Appendix A for a detailed discussion of why NOTIFY is included
583 here.
584
585 Servers MAY support session resumption, and MAY do that with or
586 without supporting 0-RTT, using the mechanisms described in
587 Section 4.6.1 of [RFC9001]. Servers supporting 0-RTT MUST NOT
588 immediately process non-replayable transactions received in 0-RTT
589 data but instead MUST adopt one of the following behaviors:
590
591 * Queue the offending transaction and only process it after the QUIC
592 handshake has been completed, as defined in Section 4.1.1 of
593 [RFC9001].
594
595 * Reply to the offending transaction with a response code REFUSED
596 and an Extended DNS Error Code (EDE) "Too Early" using the
597 extended RCODE mechanisms defined in [RFC6891] and the extended
598 DNS errors defined in [RFC8914]; see Section 8.3.
599
600 * Close the connection with the error code DOQ_PROTOCOL_ERROR.
601
602 4.6. Message Sizes
603
604 DoQ queries and responses are sent on QUIC streams, which in theory
605 can carry up to 2^62 bytes. However, DNS messages are restricted in
606 practice to a maximum size of 65535 bytes. This maximum size is
607 enforced by the use of a 2-octet message length field in DNS over TCP
608 [RFC1035] and DoT [RFC7858], and by the definition of the
609 "application/dns-message" for DoH [RFC8484]. DoQ enforces the same
610 restriction.
611
612 The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] allow peers to
613 specify the UDP message size. This parameter is ignored by DoQ. DoQ
614 implementations always assume that the maximum message size is 65535
615 bytes.
616
617 5. Implementation Requirements
618
619 5.1. Authentication
620
621 For the stub to recursive scenario, the authentication requirements
622 are the same as described in DoT [RFC7858] and "Usage Profiles for
623 DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932] states that DNS
624 privacy services SHOULD provide credentials that clients can use to
625 authenticate the server. Given this, and to align with the
626 authentication model for DoH, DoQ stubs SHOULD use a Strict usage
627 profile. Client authentication for the encrypted stub to recursive
628 scenario is not described in any DNS RFC.
629
630 For zone transfer, the authentication requirements are the same as
631 described in [RFC9103].
632
633 For the recursive to authoritative scenario, authentication
634 requirements are unspecified at the time of writing and are the
635 subject of ongoing work in the DPRIVE WG.
636
637 5.2. Fallback to Other Protocols on Connection Failure
638
639 If the establishment of the DoQ connection fails, clients MAY attempt
640 to fall back to DoT and then potentially cleartext, as specified in
641 DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS"
642 [RFC8310], depending on their usage profile.
643
644 DNS clients SHOULD remember server IP addresses that don't support
645 DoQ. Mobile clients might also remember the lack of DoQ support by
646 given IP addresses on a per-context basis (e.g., per network or
647 provisioning domain).
648
649 Timeouts, connection refusals, and QUIC handshake failures are
650 indicators that a server does not support DoQ. Clients SHOULD NOT
651 attempt DoQ queries to a server that does not support DoQ for a
652 reasonable period (such as one hour per server). DNS clients
653 following an out-of-band key-pinned usage profile [RFC7858] MAY be
654 more aggressive about retrying after DoQ connection failures.
655
656 5.3. Address Validation
657
658 Section 8 of [RFC9000], the QUIC transport specification, defines
659 Address Validation procedures to avoid servers being used in address
660 amplification attacks. DoQ implementations MUST conform to this
661 specification, which limits the worst-case amplification to a factor
662 3.
663
664 DoQ implementations SHOULD consider configuring servers to use the
665 Address Validation using Retry Packets procedure defined in
666 Section 8.1.2 of [RFC9000], the QUIC transport specification. This
667 procedure imposes a 1-RTT delay for verifying the return routability
668 of the source address of a client, similar to the DNS Cookies
669 mechanism [RFC7873].
670
671 DoQ implementations that configure Address Validation using Retry
672 Packets SHOULD implement the Address Validation for Future
673 Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC
674 transport specification. This defines how servers can send NEW_TOKEN
675 frames to clients after the client address is validated in order to
676 avoid the 1-RTT penalty during subsequent connections by the client
677 from the same address.
678
679 5.4. Padding
680
681 Implementations MUST protect against the traffic analysis attacks
682 described in Section 7.5 by the judicious injection of padding. This
683 could be done either by padding individual DNS messages using the
684 EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see
685 Section 19.1 of [RFC9000]).
686
687 In theory, padding at the QUIC packet level could result in better
688 performance for the equivalent protection, because the amount of
689 padding can take into account non-DNS frames such as acknowledgements
690 or flow control updates, and also because QUIC packets can carry
691 multiple DNS messages. However, applications can only control the
692 amount of padding in QUIC packets if the implementation of QUIC
693 exposes adequate APIs. This leads to the following recommendations:
694
695 * If the implementation of QUIC exposes APIs to set a padding
696 policy, DoQ SHOULD use that API to align the packet length to a
697 small set of fixed sizes.
698
699 * If padding at the QUIC packet level is not available or not used,
700 DoQ MUST ensure that all DNS queries and responses are padded to a
701 small set of fixed sizes, using the EDNS(0) padding extension as
702 specified in [RFC7830].
703
704 Implementations might choose not to use a QUIC API for padding if it
705 is significantly simpler to reuse existing DNS message padding logic
706 that is applied to other encrypted transports.
707
708 In the absence of a standard policy for padding sizes,
709 implementations SHOULD follow the recommendations of the Experimental
710 status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))"
711 [RFC8467]. While Experimental, these recommendations are referenced
712 because they are implemented and deployed for DoT and provide a way
713 for implementations to be fully compliant with this specification.
714
715 5.5. Connection Handling
716
717 "DNS Transport over TCP - Implementation Requirements" [RFC7766]
718 provides updated guidance on DNS over TCP, some of which is
719 applicable to DoQ. This section provides similar advice on
720 connection handling for DoQ.
721
722 5.5.1. Connection Reuse
723
724 Historic implementations of DNS clients are known to open and close
725 TCP connections for each DNS query. To amortize connection setup
726 costs, both clients and servers SHOULD support connection reuse by
727 sending multiple queries and responses over a single persistent QUIC
728 connection.
729
730 In order to achieve performance on par with UDP, DNS clients SHOULD
731 send their queries concurrently over the QUIC streams on a QUIC
732 connection. That is, when a DNS client sends multiple queries to a
733 server over a QUIC connection, it SHOULD NOT wait for an outstanding
734 reply before sending the next query.
735
736 5.5.2. Resource Management
737
738 Proper management of established and idle connections is important to
739 the healthy operation of a DNS server.
740
741 An implementation of DoQ SHOULD follow best practices similar to
742 those specified for DNS over TCP [RFC7766], in particular with regard
743 to:
744
745 * Concurrent Connections (Section 6.2.2 of [RFC7766], updated by
746 Section 6.4 of [RFC9103])
747
748 * Security Considerations (Section 10 of [RFC7766])
749
750 Failure to do so may lead to resource exhaustion and denial of
751 service.
752
753 Clients that want to maintain long duration DoQ connections SHOULD
754 use the idle timeout mechanisms defined in Section 10.1 of [RFC9000],
755 the QUIC transport specification. Clients and servers MUST NOT send
756 the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent
757 on a DoQ connection (because it is specific to the use of TCP/TLS as
758 a transport).
759
760 This document does not make specific recommendations for timeout
761 values on idle connections. Clients and servers should reuse and/or
762 close connections depending on the level of available resources.
763 Timeouts may be longer during periods of low activity and shorter
764 during periods of high activity.
765
766 5.5.3. Using 0-RTT and Session Resumption
767
768 Using 0-RTT for DoQ has many compelling advantages. Clients can
769 establish connections and send queries without incurring a connection
770 delay. Servers can thus negotiate low values of the connection
771 timers, which reduces the total number of connections that they need
772 to manage. They can do that because the clients that use 0-RTT will
773 not incur latency penalties if new connections are required for a
774 query.
775
776 Session resumption and 0-RTT data transmission create privacy risks
777 detailed in Sections 7.1 and 7.2. The following recommendations are
778 meant to reduce the privacy risks while enjoying the performance
779 benefits of 0-RTT data, subject to the restrictions specified in
780 Section 4.5.
781
782 Clients SHOULD use resumption tickets only once, as specified in
783 Appendix C.4 of [RFC8446]. By default, clients SHOULD NOT use
784 session resumption if the client's connectivity has changed.
785
786 Clients could receive address validation tokens from the server using
787 the NEW_TOKEN mechanism; see Section 8 of [RFC9000]. The associated
788 tracking risks are mentioned in Section 7.3. Clients SHOULD only use
789 the address validation tokens when they are also using session
790 resumption thus avoiding additional tracking risks.
791
792 Servers SHOULD issue session resumption tickets with a sufficiently
793 long lifetime (e.g., 6 hours), so that clients are not tempted to
794 either keep the connection alive or frequently poll the server to
795 renew session resumption tickets. Servers SHOULD implement the anti-
796 replay mechanisms specified in Section 8 of [RFC8446].
797
798 5.5.4. Controlling Connection Migration for Privacy
799
800 DoQ implementations might consider using the connection migration
801 features defined in Section 9 of [RFC9000]. These features enable
802 connections to continue operating as the client's connectivity
803 changes. As detailed in Section 7.4, these features trade off
804 privacy for latency. By default, clients SHOULD be configured to
805 prioritize privacy and start new sessions if their connectivity
806 changes.
807
808 5.6. Processing Queries in Parallel
809
810 As specified in Section 7 of [RFC7766] "DNS Transport over TCP -
811 Implementation Requirements", resolvers are RECOMMENDED to support
812 the preparing of responses in parallel and sending them out of order.
813 In DoQ, they do that by sending responses on their specific stream as
814 soon as possible, without waiting for availability of responses for
815 previously opened streams.
816
817 5.7. Zone Transfer
818
819 [RFC9103] specifies zone transfer over TLS (XoT) and includes updates
820 to [RFC1995] (IXFR), [RFC5936] (AXFR), and [RFC7766]. Considerations
821 relating to the reuse of XoT connections described there apply
822 analogously to zone transfers performed using DoQ connections. One
823 reason for reiterating such specific guidance is the lack of
824 effective connection reuse in existing TCP/TLS zone transfer
825 implementations today. The following recommendations apply:
826
827 * DoQ servers MUST be able to handle multiple concurrent IXFR
828 requests on a single QUIC connection.
829
830 * DoQ servers MUST be able to handle multiple concurrent AXFR
831 requests on a single QUIC connection.
832
833 * DoQ implementations SHOULD
834
835 - use the same QUIC connection for both AXFR and IXFR requests to
836 the same primary
837
838 - send those requests in parallel as soon as they are queued,
839 i.e., do not wait for a response before sending the next query
840 on the connection (this is analogous to pipelining requests on
841 a TCP/TLS connection)
842
843 - send the response(s) for each request as soon as they are
844 available, i.e., response streams MAY be sent intermingled
845
846 5.8. Flow Control Mechanisms
847
848 Servers and clients manage flow control using the mechanisms defined
849 in Section 4 of [RFC9000]. These mechanisms allow clients and
850 servers to specify how many streams can be created, how much data can
851 be sent on a stream, and how much data can be sent on the union of
852 all streams. For DoQ, controlling how many streams are created
853 allows servers to control how many new requests the client can send
854 on a given connection.
855
856 Flow control exists to protect endpoint resources. For servers,
857 global and per-stream flow control limits control how much data can
858 be sent by clients. The same mechanisms allow clients to control how
859 much data can be sent by servers. Values that are too small will
860 unnecessarily limit performance. Values that are too large might
861 expose endpoints to overload or memory exhaustion. Implementations
862 or deployments will need to adjust flow control limits to balance
863 these concerns. In particular, zone transfer implementations will
864 need to control these limits carefully to ensure both large and
865 concurrent zone transfers are well managed.
866
867 Initial values of parameters control how many requests and how much
868 data can be sent by clients and servers at the beginning of the
869 connection. These values are specified in transport parameters
870 exchanged during the connection handshake. The parameter values
871 received in the initial connection also control how many requests and
872 how much data can be sent by clients using 0-RTT data in a resumed
873 connection. Using too small values of these initial parameters would
874 restrict the usefulness of allowing 0-RTT data.
875
876 6. Security Considerations
877
878 A Threat Analysis of the Domain Name System is found in [RFC3833].
879 This analysis was written before the development of DoT, DoH, and
880 DoQ, and probably needs to be updated.
881
882 The security considerations of DoQ should be comparable to those of
883 DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub
884 to recursive scenario, but the considerations about person-in-the-
885 middle attacks, middleboxes, and caching of data from cleartext
886 connections also apply for DoQ to the resolver to authoritative
887 server scenario. As stated in Section 5.1, the authentication
888 requirements for securing zone transfer using DoQ are the same as
889 those for zone transfer over DoT; therefore, the general security
890 considerations are entirely analogous to those described in
891 [RFC9103].
892
893 DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports
894 by default the protections against downgrade attacks described in
895 [BCP195]. QUIC-specific issues and their mitigations are described
896 in Section 21 of [RFC9000].
897
898 7. Privacy Considerations
899
900 The general considerations of encrypted transports provided in "DNS
901 Privacy Considerations" [RFC9076] apply to DoQ. The specific
902 considerations provided there do not differ between DoT and DoQ, and
903 they are not discussed further here. Similarly, "Recommendations for
904 DNS Privacy Service Operators" [RFC8932] (which covers operational,
905 policy, and security considerations for DNS privacy services) is also
906 applicable to DoQ services.
907
908 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446], and this
909 enables QUIC transmission of "0-RTT" data. This can provide
910 interesting latency gains, but it raises two concerns:
911
912 1. Adversaries could replay the 0-RTT data and infer its content
913 from the behavior of the receiving server.
914
915 2. The 0-RTT mechanism relies on TLS session resumption, which can
916 provide linkability between successive client sessions.
917
918 These issues are developed in Sections 7.1 and 7.2.
919
920 7.1. Privacy Issues with 0-RTT data
921
922 The 0-RTT data can be replayed by adversaries. That data may trigger
923 queries by a recursive resolver to authoritative resolvers.
924 Adversaries may be able to pick a time at which the recursive
925 resolver outgoing traffic is observable and thus find out what name
926 was queried for in the 0-RTT data.
927
928 This risk is in fact a subset of the general problem of observing the
929 behavior of the recursive resolver discussed in "DNS Privacy
930 Considerations" [RFC9076]. The attack is partially mitigated by
931 reducing the observability of this traffic. The mandatory replay
932 protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate
933 the risk of replay. 0-RTT packets can only be replayed within a
934 narrow window, which is only wide enough to account for variations in
935 clock skew and network transmission.
936
937 The recommendation for TLS 1.3 [RFC8446] is that the capability to
938 use 0-RTT data should be turned off by default and only enabled if
939 the user clearly understands the associated risks. In the case of
940 DoQ, allowing 0-RTT data provides significant performance gains, and
941 there is a concern that a recommendation to not use it would simply
942 be ignored. Instead, a set of practical recommendations is provided
943 in Sections 4.5 and 5.5.3.
944
945 The specifications in Section 4.5 block the most obvious risks of
946 replay attacks, as they only allow for transactions that will not
947 change the long-term state of the server.
948
949 The attacks described above apply to the stub resolver to recursive
950 resolver scenario, but similar attacks might be envisaged in the
951 recursive resolver to authoritative resolver scenario, and the same
952 mitigations apply.
953
954 7.2. Privacy Issues with Session Resumption
955
956 The QUIC session resumption mechanism reduces the cost of re-
957 establishing sessions and enables 0-RTT data. There is a linkability
958 issue associated with session resumption, if the same resumption
959 token is used several times. Attackers on path between client and
960 server could observe repeated usage of the token and use that to
961 track the client over time or over multiple locations.
962
963 The session resumption mechanism allows servers to correlate the
964 resumed sessions with the initial sessions and thus to track the
965 client. This creates a virtual long duration session. The series of
966 queries in that session can be used by the server to identify the
967 client. Servers can most probably do that already if the client
968 address remains constant, but session resumption tickets also enable
969 tracking after changes of the client's address.
970
971 The recommendations in Section 5.5.3 are designed to mitigate these
972 risks. Using session tickets only once mitigates the risk of
973 tracking by third parties. Refusing to resume a session if addresses
974 change mitigates the incremental risk of tracking by the server (but
975 the risk of tracking by IP address remains).
976
977 The privacy trade-offs here may be context specific. Stub resolvers
978 will have a strong motivation to prefer privacy over latency since
979 they often change location. However, recursive resolvers that use a
980 small set of static IP addresses are more likely to prefer the
981 reduced latency provided by session resumption and may consider this
982 a valid reason to use resumption tickets even if the IP address
983 changed between sessions.
984
985 Encrypted zone transfer ([RFC9103]) explicitly does not attempt to
986 hide the identity of the parties involved in the transfer; at the
987 same time, such transfers are not particularly latency sensitive.
988 This means that applications supporting zone transfers may decide to
989 apply the same protections as stub to recursive applications.
990
991 7.3. Privacy Issues with Address Validation Tokens
992
993 QUIC specifies address validation mechanisms in Section 8 of
994 [RFC9000]. Use of an address validation token allows QUIC servers to
995 avoid an extra RTT for new connections. Address validation tokens
996 are typically tied to an IP address. QUIC clients normally only use
997 these tokens when setting up a new connection from a previously used
998 address. However, clients are not always aware that they are using a
999 new address. This could be due to NAT, or because the client does
1000 not have an API available to check if the IP address has changed
1001 (which can be quite often for IPv6). There is a linkability risk if
1002 clients mistakenly use address validation tokens after unknowingly
1003 moving to a new location.
1004
1005 The recommendations in Section 5.5.3 mitigates this risk by tying the
1006 usage of the NEW_TOKEN to that of session resumption, though this
1007 recommendation does not cover the case where the client is unaware of
1008 the address change.
1009
1010 7.4. Privacy Issues with Long Duration Sessions
1011
1012 A potential alternative to session resumption is the use of long
1013 duration sessions: if a session remains open for a long time, new
1014 queries can be sent without incurring connection establishment
1015 delays. It is worth pointing out that the two solutions have similar
1016 privacy characteristics. Session resumption may allow servers to
1017 keep track of the IP addresses of clients, but long duration sessions
1018 have the same effect.
1019
1020 In particular, a DoQ implementation might take advantage of the
1021 connection migration features of QUIC to maintain a session even if
1022 the client's connectivity changes, for example, if the client
1023 migrates from a Wi-Fi connection to a cellular network connection and
1024 then to another Wi-Fi connection. The server would be able to track
1025 the client location by monitoring the succession of IP addresses used
1026 by the long duration connection.
1027
1028 The recommendation in Section 5.5.4 mitigates the privacy concerns
1029 related to long duration sessions using multiple client addresses.
1030
1031 7.5. Traffic Analysis
1032
1033 Even though QUIC packets are encrypted, adversaries can gain
1034 information from observing packet lengths, in both queries and
1035 responses, as well as packet timing. Many DNS requests are emitted
1036 by web browsers. Loading a specific web page may require resolving
1037 dozens of DNS names. If an application adopts a simple mapping of
1038 one query or response per packet, or "one QUIC STREAM frame per
1039 packet", then the succession of packet lengths may provide enough
1040 information to identify the requested site.
1041
1042 Implementations SHOULD use the mechanisms defined in Section 5.4 to
1043 mitigate this attack.
1044
1045 8. IANA Considerations
1046
1047 8.1. Registration of a DoQ Identification String
1048
1049 This document creates a new registration for the identification of
1050 DoQ in the "TLS Application-Layer Protocol Negotiation (ALPN)
1051 Protocol IDs" registry [RFC7301].
1052
1053 The "doq" string identifies DoQ:
1054
1055 Protocol: DoQ
1056
1057 Identification Sequence: 0x64 0x6F 0x71 ("doq")
1058
1059 Specification: This document
1060
1061 8.2. Reservation of a Dedicated Port
1062
1063 For both TCP and UDP, port 853 is currently reserved for "DNS query-
1064 response protocol run over TLS/DTLS" [RFC7858].
1065
1066 However, the specification for DNS over DTLS (DoD) [RFC8094] is
1067 experimental, limited to stub to resolver, and no implementations or
1068 deployments currently exist to the authors' knowledge (even though
1069 several years have passed since the specification was published).
1070
1071 This specification additionally reserves the use of UDP port 853 for
1072 DoQ. QUIC version 1 was designed to be able to coexist with other
1073 protocols on the same port, including DTLS; see Section 17.2 of
1074 [RFC9000]. This means that deployments that serve DoD and DoQ (QUIC
1075 version 1) on the same port will be able to demultiplex the two due
1076 to the second most significant bit in each UDP payload. Such
1077 deployments ought to check the signatures of future versions or
1078 extensions (e.g., [GREASING-QUIC]) of QUIC and DTLS before deploying
1079 them to serve DNS on the same port.
1080
1081 IANA has updated the following value in the "Service Name and
1082 Transport Protocol Port Number Registry" in the System range. The
1083 registry for that range requires IETF Review or IESG Approval
1084 [RFC6335].
1085
1086 Service Name: domain-s
1087
1088 Port Number: 853
1089
1090 Transport Protocol(s): UDP
1091
1092 Assignee: IESG
1093
1094 Contact: IETF Chair
1095
1096 Description: DNS query-response protocol run over DTLS or QUIC
1097
1098 Reference: [RFC7858][RFC8094] This document
1099
1100 Additionally, IANA has updated the Description field for the
1101 corresponding TCP port 853 allocation to be "DNS query-response
1102 protocol run over TLS" and removed [RFC8094] from the TCP
1103 allocation's Reference field for consistency and clarity.
1104
1105 8.3. Reservation of an Extended DNS Error Code: Too Early
1106
1107 IANA has registered the following value in the "Extended DNS Error
1108 Codes" registry [RFC8914]:
1109
1110 INFO-CODE: 26
1111
1112 Purpose: Too Early
1113
1114 Reference: This document
1115
1116 8.4. DNS-over-QUIC Error Codes Registry
1117
1118 IANA has added a registry for "DNS-over-QUIC Error Codes" on the
1119 "Domain Name System (DNS) Parameters" web page.
1120
1121 The "DNS-over-QUIC Error Codes" registry governs a 62-bit space.
1122 This space is split into three regions that are governed by different
1123 policies:
1124
1125 * Permanent registrations for values between 0x00 and 0x3f (in
1126 hexadecimal; inclusive), which are assigned using Standards Action
1127 or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126]
1128
1129 * Permanent registrations for values larger than 0x3f, which are
1130 assigned using the Specification Required policy ([RFC8126])
1131
1132 * Provisional registrations for values larger than 0x3f, which
1133 require Expert Review, as defined in Section 4.5 of [RFC8126].
1134
1135 Provisional reservations share the range of values larger than 0x3f
1136 with some permanent registrations. This is by design to enable
1137 conversion of provisional registrations into permanent registrations
1138 without requiring changes in deployed systems. (This design is
1139 aligned with the principles set in Section 22 of [RFC9000].)
1140
1141 Registrations in this registry MUST include the following fields:
1142
1143 Value: The assigned codepoint
1144
1145 Status: "Permanent" or "Provisional"
1146
1147 Contact: Contact details for the registrant
1148
1149 In addition, permanent registrations MUST include:
1150
1151 Error: A short mnemonic for the parameter
1152
1153 Specification: A reference to a publicly available specification for
1154 the value (optional for provisional registrations)
1155
1156 Description: A brief description of the error code semantics, which
1157 MAY be a summary if a specification reference is provided
1158
1159 Provisional registrations of codepoints are intended to allow for
1160 private use and experimentation with extensions to DoQ. However,
1161 provisional registrations could be reclaimed and reassigned for other
1162 purposes. In addition to the parameters listed above, provisional
1163 registrations MUST include:
1164
1165 Date: The date of last update to the registration
1166
1167 A request to update the date on any provisional registration can be
1168 made without review from the designated expert(s).
1169
1170 The initial content of this registry is shown in Table 1 and all
1171 entries share the following fields:
1172
1173 Status: Permanent
1174
1175 Contact: DPRIVE WG
1176
1177 Specification: Section 4.3
1178
1179 +============+=======================+=============================+
1180 | Value | Error | Description |
1181 +============+=======================+=============================+
1182 | 0x0 | DOQ_NO_ERROR | No error |
1183 +------------+-----------------------+-----------------------------+
1184 | 0x1 | DOQ_INTERNAL_ERROR | Implementation error |
1185 +------------+-----------------------+-----------------------------+
1186 | 0x2 | DOQ_PROTOCOL_ERROR | Generic protocol violation |
1187 +------------+-----------------------+-----------------------------+
1188 | 0x3 | DOQ_REQUEST_CANCELLED | Request cancelled by client |
1189 +------------+-----------------------+-----------------------------+
1190 | 0x4 | DOQ_EXCESSIVE_LOAD | Closing a connection for |
1191 | | | excessive load |
1192 +------------+-----------------------+-----------------------------+
1193 | 0x5 | DOQ_UNSPECIFIED_ERROR | No error reason specified |
1194 +------------+-----------------------+-----------------------------+
1195 | 0xd098ea5e | DOQ_ERROR_RESERVED | Alternative error code used |
1196 | | | for tests |
1197 +------------+-----------------------+-----------------------------+
1198
1199 Table 1: Initial DNS-over-QUIC Error Codes Entries
1200
1201 9. References
1202
1203 9.1. Normative References
1204
1205 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1206 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1207 <https://www.rfc-editor.org/info/rfc1034>.
1208
1209 [RFC1035] Mockapetris, P., "Domain names - implementation and
1210 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1211 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
1212
1213 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1214 DOI 10.17487/RFC1995, August 1996,
1215 <https://www.rfc-editor.org/info/rfc1995>.
1216
1217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1218 Requirement Levels", BCP 14, RFC 2119,
1219 DOI 10.17487/RFC2119, March 1997,
1220 <https://www.rfc-editor.org/info/rfc2119>.
1221
1222 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
1223 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
1224 <https://www.rfc-editor.org/info/rfc5936>.
1225
1226 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
1227 for DNS (EDNS(0))", STD 75, RFC 6891,
1228 DOI 10.17487/RFC6891, April 2013,
1229 <https://www.rfc-editor.org/info/rfc6891>.
1230
1231 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
1232 "Transport Layer Security (TLS) Application-Layer Protocol
1233 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
1234 July 2014, <https://www.rfc-editor.org/info/rfc7301>.
1235
1236 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
1237 D. Wessels, "DNS Transport over TCP - Implementation
1238 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
1239 <https://www.rfc-editor.org/info/rfc7766>.
1240
1241 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
1242 DOI 10.17487/RFC7830, May 2016,
1243 <https://www.rfc-editor.org/info/rfc7830>.
1244
1245 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1246 and P. Hoffman, "Specification for DNS over Transport
1247 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1248 2016, <https://www.rfc-editor.org/info/rfc7858>.
1249
1250 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1251 Writing an IANA Considerations Section in RFCs", BCP 26,
1252 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1253 <https://www.rfc-editor.org/info/rfc8126>.
1254
1255 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1256 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1257 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1258
1259 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
1260 for DNS over TLS and DNS over DTLS", RFC 8310,
1261 DOI 10.17487/RFC8310, March 2018,
1262 <https://www.rfc-editor.org/info/rfc8310>.
1263
1264 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1265 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1266 <https://www.rfc-editor.org/info/rfc8446>.
1267
1268 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
1269 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
1270 October 2018, <https://www.rfc-editor.org/info/rfc8467>.
1271
1272 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
1273 Lawrence, "Extended DNS Errors", RFC 8914,
1274 DOI 10.17487/RFC8914, October 2020,
1275 <https://www.rfc-editor.org/info/rfc8914>.
1276
1277 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
1278 Multiplexed and Secure Transport", RFC 9000,
1279 DOI 10.17487/RFC9000, May 2021,
1280 <https://www.rfc-editor.org/info/rfc9000>.
1281
1282 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
1283 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
1284 <https://www.rfc-editor.org/info/rfc9001>.
1285
1286 [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
1287 Mankin, "DNS Zone Transfer over TLS", RFC 9103,
1288 DOI 10.17487/RFC9103, August 2021,
1289 <https://www.rfc-editor.org/info/rfc9103>.
1290
1291 9.2. Informative References
1292
1293 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
1294 "Recommendations for Secure Use of Transport Layer
1295 Security (TLS) and Datagram Transport Layer Security
1296 (DTLS)", BCP 195, RFC 7525, May 2015.
1297
1298 Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1299 1.1", BCP 195, RFC 8996, March 2021.
1300
1301 <https://www.rfc-editor.org/info/bcp195>
1302
1303 [DNS-TERMS]
1304 Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
1305 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,
1306 28 September 2021, <https://datatracker.ietf.org/doc/html/
1307 draft-ietf-dnsop-rfc8499bis-03>.
1308
1309 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG
1310 mailing list, 6 April 2016, <https://www.ietf.org/mail-
1311 archive/web/dns-privacy/current/msg01276.html>.
1312
1313 [GREASING-QUIC]
1314 Thomson, M., "Greasing the QUIC Bit", Work in Progress,
1315 Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November
1316 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
1317 quic-bit-grease-02>.
1318
1319 [HTTP/3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
1320 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
1321 quic-http-34, 2 February 2021,
1322 <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
1323 http-34>.
1324
1325 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
1326 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
1327 August 1996, <https://www.rfc-editor.org/info/rfc1996>.
1328
1329 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
1330 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
1331 2004, <https://www.rfc-editor.org/info/rfc3833>.
1332
1333 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
1334 Cheshire, "Internet Assigned Numbers Authority (IANA)
1335 Procedures for the Management of the Service Name and
1336 Transport Protocol Port Number Registry", BCP 165,
1337 RFC 6335, DOI 10.17487/RFC6335, August 2011,
1338 <https://www.rfc-editor.org/info/rfc6335>.
1339
1340 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
1341 edns-tcp-keepalive EDNS0 Option", RFC 7828,
1342 DOI 10.17487/RFC7828, April 2016,
1343 <https://www.rfc-editor.org/info/rfc7828>.
1344
1345 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
1346 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
1347 <https://www.rfc-editor.org/info/rfc7873>.
1348
1349 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
1350 Transport Layer Security (DTLS)", RFC 8094,
1351 DOI 10.17487/RFC8094, February 2017,
1352 <https://www.rfc-editor.org/info/rfc8094>.
1353
1354 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1355 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1356 <https://www.rfc-editor.org/info/rfc8484>.
1357
1358 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
1359 Lemon, T., and T. Pusateri, "DNS Stateful Operations",
1360 RFC 8490, DOI 10.17487/RFC8490, March 2019,
1361 <https://www.rfc-editor.org/info/rfc8490>.
1362
1363 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
1364 A. Mankin, "Recommendations for DNS Privacy Service
1365 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
1366 October 2020, <https://www.rfc-editor.org/info/rfc8932>.
1367
1368 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
1369 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
1370 May 2021, <https://www.rfc-editor.org/info/rfc9002>.
1371
1372 [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
1373 DOI 10.17487/RFC9076, July 2021,
1374 <https://www.rfc-editor.org/info/rfc9076>.
1375
1376 Appendix A. The NOTIFY Service
1377
1378 This appendix discusses why it is considered acceptable to send
1379 NOTIFY (see [RFC1996]) in 0-RTT data.
1380
1381 Section 4.5 says "The 0-RTT mechanism MUST NOT be used to send DNS
1382 requests that are not "replayable" transactions". This specification
1383 supports sending a NOTIFY in 0-RTT data because although a NOTIFY
1384 technically changes the state of the receiving server, the effect of
1385 replaying NOTIFYs has negligible impact in practice.
1386
1387 NOTIFY messages prompt a secondary to either send an SOA query or an
1388 XFR request to the primary on the basis that a newer version of the
1389 zone is available. It has long been recognized that NOTIFYs can be
1390 forged and, in theory, used to cause a secondary to send repeated
1391 unnecessary requests to the primary. For this reason, most
1392 implementations have some form of throttling of the SOA/XFR queries
1393 triggered by the receipt of one or more NOTIFYs.
1394
1395 [RFC9103] describes the privacy risks associated with both NOTIFY and
1396 SOA queries and does not include addressing those risks within the
1397 scope of encrypting zone transfers. Given this, the privacy benefit
1398 of using DoQ for NOTIFY is not clear, but for the same reason,
1399 sending NOTIFY as 0-RTT data has no privacy risk above that of
1400 sending it using cleartext DNS.
1401
1402 Acknowledgements
1403
1404 This document liberally borrows text from the HTTP/3 specification
1405 [HTTP/3] edited by Mike Bishop and from the DoT specification
1406 [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, Allison
1407 Mankin, Duane Wessels, and Paul Hoffman.
1408
1409 The privacy issue with 0-RTT data and session resumption was analyzed
1410 by Daniel Kahn Gillmor (DKG) in a message to the IETF DPRIVE Working
1411 Group [DNS0RTT].
1412
1413 Thanks to Tony Finch for an extensive review of the initial draft
1414 version of this document, and to Robert Evans for the discussion of
1415 0-RTT privacy issues. Early reviews by Paul Hoffman and Martin
1416 Thomson and interoperability tests conducted by Stephane Bortzmeyer
1417 helped improve the definition of the protocol.
1418
1419 Thanks also to Martin Thomson and Martin Duke for their later reviews
1420 focusing on the low-level QUIC details, which helped clarify several
1421 aspects of DoQ. Thanks to Andrey Meshkov, Loganaden Velvindron,
1422 Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell, and
1423 Phillip Hallam-Baker for their reviews and contributions.
1424
1425 Authors' Addresses
1426
1427 Christian Huitema
1428 Private Octopus Inc.
1429 427 Golfcourse Rd
1430 Friday Harbor, WA 98250
1431 United States of America
1432 Email: huitema@huitema.net
1433
1434
1435 Sara Dickinson
1436 Sinodun IT
1437 Oxford Science Park
1438 Oxford
1439 OX4 4GA
1440 United Kingdom
1441 Email: sara@sinodun.com
1442
1443
1444 Allison Mankin
1445 Salesforce
1446 Email: allison.mankin@gmail.com
1447
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.