idnits 2.17.00 (12 Aug 2021) /tmp/idnits47756/draft-ietf-dprive-dnsoquic-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (8 February 2022) is 101 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 8467 == Outdated reference: A later version (-03) exists of draft-ietf-quic-bit-grease-02 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Standards Track S. Dickinson 5 Expires: 12 August 2022 Sinodun IT 6 A. Mankin 7 Salesforce 8 8 February 2022 10 DNS over Dedicated QUIC Connections 11 draft-ietf-dprive-dnsoquic-09 13 Abstract 15 This document describes the use of QUIC to provide transport privacy 16 for DNS. The encryption provided by QUIC has similar properties to 17 that provided by TLS, while QUIC transport eliminates the head-of- 18 line blocking issues inherent with TCP and provides more efficient 19 packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy 20 properties similar to DNS over TLS (DoT) specified in RFC7858, and 21 latency characteristics similar to classic DNS over UDP. This 22 specification describes the use of DNS over QUIC as a general-purpose 23 transport for DNS and includes the use of DNS over QUIC for stub to 24 recursive, recursive to authoritative, and zone transfer scenarios. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 12 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Document work via GitHub . . . . . . . . . . . . . . . . . . 5 62 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5 64 4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5 65 4.3. Middlebox Considerations . . . . . . . . . . . . . . . . 6 66 4.4. No Server-Initiated Transactions . . . . . . . . . . . . 6 67 5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Connection Establishment . . . . . . . . . . . . . . . . 7 69 5.1.1. Draft Version Identification . . . . . . . . . . . . 7 70 5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7 71 5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7 72 5.2.1. DNS Message IDs . . . . . . . . . . . . . . . . . . . 8 73 5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9 74 5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9 75 5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 10 76 5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10 77 5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11 78 5.4. Connection Management . . . . . . . . . . . . . . . . . . 11 79 5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12 80 5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 13 81 6. Implementation Requirements . . . . . . . . . . . . . . . . . 13 82 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13 83 6.2. Fallback to Other Protocols on Connection Failure . . . . 14 84 6.3. Address Validation . . . . . . . . . . . . . . . . . . . 14 85 6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15 87 6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15 88 6.5.2. Resource Management . . . . . . . . . . . . . . . . . 16 89 6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16 90 6.5.4. Controlling Connection Migration For Privacy . . . . 17 91 6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17 92 6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17 93 6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18 94 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 95 7.1. Performance Measurements . . . . . . . . . . . . . . . . 19 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 98 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 99 9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 21 100 9.2. Privacy Issues With Session Resumption . . . . . . . . . 21 101 9.3. Privacy Issues With Address Validation Tokens . . . . . . 22 102 9.4. Privacy Issues With Long Duration Sessions . . . . . . . 23 103 9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 105 10.1. Registration of DoQ Identification String . . . . . . . 23 106 10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 24 107 10.3. Reservation of Extended DNS Error Code Too Early . . . . 25 108 10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 25 109 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 112 12.2. Informative References . . . . . . . . . . . . . . . . . 30 113 Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 31 114 Appendix B. Notable Changes From Previous Versions . . . . . . . 32 115 B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 32 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 118 1. Introduction 120 Domain Name System (DNS) concepts are specified in "Domain names - 121 concepts and facilities" [RFC1034]. The transmission of DNS queries 122 and responses over UDP and TCP is specified in "Domain names - 123 implementation and specification" [RFC1035]. 125 This document presents a mapping of the DNS protocol over the QUIC 126 transport [RFC9000] [RFC9001]. DNS over QUIC is referred here as 127 DoQ, in line with "DNS Terminology" [I-D.ietf-dnsop-rfc8499bis]. 129 The goals of the DoQ mapping are: 131 1. Provide the same DNS privacy protection as DNS over TLS (DoT) 132 [RFC7858]. This includes an option for the client to 133 authenticate the server by means of an authentication domain name 134 as specified in "Usage Profiles for DNS over TLS and DNS over 135 DTLS" [RFC8310]. 137 2. Provide an improved level of source address validation for DNS 138 servers compared to classic DNS over UDP. 140 3. Provide a transport that is not constrained by path MTU 141 limitations on the size of DNS responses it can send. 143 In order to achieve these goals, and to support ongoing work on 144 encryption of DNS, the scope of this document includes 145 * the "stub to recursive resolver" scenario 147 * the "recursive resolver to authoritative nameserver" scenario and 149 * the "nameserver to nameserver" scenario (mainly used for zone 150 transfers (XFR) [RFC1995], [RFC5936]). 152 In other words, this document specifies QUIC as a general-purpose 153 transport for DNS. 155 The specific non-goals of this document are: 157 1. No attempt is made to evade potential blocking of DNS over QUIC 158 traffic by middleboxes. 160 2. No attempt to support server-initiated transactions, which are 161 used only in DNS Stateful Operations (DSO) [RFC8490]. 163 Specifying the transmission of an application over QUIC requires 164 specifying how the application's messages are mapped to QUIC streams, 165 and generally how the application will use QUIC. This is done for 166 HTTP in "Hypertext Transfer Protocol Version 3 167 (HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to 168 define the way DNS messages can be transmitted over QUIC. 170 DNS over HTTP [RFC8484] can be used with HTTP/3 to get some of the 171 benefits of QUIC. However, a lightweight direct mapping for DNS over 172 QUIC can be regarded as a more natural fit for both the recursive to 173 authoritative and zone transfer scenarios which rarely involve 174 intermediaries. In these scenarios, the additional overhead of HTTP 175 is not offset by, e.g., benefits of HTTP proxying and caching 176 behavior. 178 In this document, Section 4 presents the reasoning that guided the 179 proposed design. Section 5 specifies the actual mapping of DoQ. 180 Section 6 presents guidelines on the implementation, usage and 181 deployment of DoQ. 183 2. Key Words 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119] [RFC8174] when, and only when, they appear in all 189 capitals, as shown here. 191 3. Document work via GitHub 193 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The 194 Github repository for this document is at https://github.com/huitema/ 195 dnsoquic. Proposed text and editorial changes are very much welcomed 196 there, but any functional changes should always first be discussed on 197 the IETF DPRIVE WG (dns-privacy) mailing list. 199 4. Design Considerations 201 This section and its subsections present the design guidelines that 202 were used for DoQ. Whilst all other sections in this document are 203 normative, this section is informative in nature. 205 4.1. Provide DNS Privacy 207 DoT [RFC7858] defines how to mitigate some of the issues described in 208 "DNS Privacy Considerations" [RFC9076] by specifying how to transmit 209 DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS 210 over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles 211 for DoT including how stub resolvers can authenticate recursive 212 resolvers. 214 QUIC connection setup includes the negotiation of security parameters 215 using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001], 216 enabling encryption of the QUIC transport. Transmitting DNS messages 217 over QUIC will provide essentially the same privacy protections as 218 DoT [RFC7858] including Strict and Opportunistic Usage Profiles 219 [RFC8310]. Further discussion on this is provided in Section 9. 221 4.2. Design for Minimum Latency 223 QUIC is specifically designed to reduce protocol-induced delays, with 224 features such as: 226 1. Support for 0-RTT data during session resumption. 228 2. Support for advanced packet loss recovery procedures as specified 229 in "QUIC Loss Detection and Congestion Control" [RFC9002]. 231 3. Mitigation of head-of-line blocking by allowing parallel delivery 232 of data on multiple streams. 234 This mapping of DNS to QUIC will take advantage of these features in 235 three ways: 237 1. Optional support for sending 0-RTT data during session resumption 238 (the security and privacy implications of this are discussed in 239 later sections). 241 2. Long-lived QUIC connections over which multiple DNS transactions 242 are performed, generating the sustained traffic required to 243 benefit from advanced recovery features. 245 3. Mapping of each DNS Query/Response transaction to a separate 246 stream, to mitigate head-of-line blocking. This enables servers 247 to respond to queries "out of order". It also enables clients to 248 process responses as soon as they arrive, without having to wait 249 for in order delivery of responses previously posted by the 250 server. 252 These considerations are reflected in the mapping of DNS traffic to 253 QUIC streams in Section 5.2. 255 4.3. Middlebox Considerations 257 Using QUIC might allow a protocol to disguise its purpose from 258 devices on the network path using encryption and traffic analysis 259 resistance techniques like padding. This specification does not 260 include any measures that are designed to avoid such classification. 261 Consequently, firewalls and other middleboxes might be able to 262 distinguish DoQ from other protocols that use QUIC, like HTTP, and 263 apply different treatment. 265 The lack of measures in this specification to avoid protocol 266 classification is not an endorsement of such practices. 268 4.4. No Server-Initiated Transactions 270 As stated in Section 1, this document does not specify support for 271 server-initiated transactions within established DoQ connections. 272 That is, only the initiator of the DoQ connection may send queries 273 over the connection. 275 DSO does support server-initiated transactions within existing 276 connections. However, DoQ as defined here does not meet the criteria 277 for an applicable transport for DSO because it does not guarantee in- 278 order delivery of messages, see Section 4.2 of [RFC8490]. 280 5. Specifications 281 5.1. Connection Establishment 283 DoQ connections are established as described in the QUIC transport 284 specification [RFC9000]. During connection establishment, DoQ 285 support is indicated by selecting the ALPN token "doq" in the crypto 286 handshake. 288 5.1.1. Draft Version Identification 290 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only 291 implementations of the final, published RFC can identify themselves 292 as "doq". Until such an RFC exists, implementations MUST NOT 293 identify themselves using this string. 295 Implementations of draft versions of the protocol MUST add the string 296 "-" and the corresponding draft number to the identifier. For 297 example, draft-ietf-dprive-dnsoquic-00 is identified using the string 298 "doq-i00". 300 5.1.2. Port Selection 302 By default, a DNS server that supports DoQ MUST listen for and accept 303 QUIC connections on the dedicated UDP port TBD (number to be defined 304 in Section 10), unless there is a mutual agreement to use another 305 port. 307 By default, a DNS client desiring to use DoQ with a particular server 308 MUST establish a QUIC connection to UDP port TBD on the server, 309 unless there is a mutual agreement to use another port. 311 DoQ connections MUST NOT use UDP port 53. This recommendation 312 against use of port 53 for DoQ is to avoid confusion between DoQ and 313 the use of DNS over UDP [RFC1035]. 315 In the stub to recursive scenario, the use of port 443 as a mutually 316 agreed alternative port can be operationally beneficial, since port 317 443 is less likely to be blocked than other ports. Several 318 mechanisms for stubs to discover recursives offering encrypted 319 transports, including the use of custom ports, are the subject of 320 ongoing work. 322 5.2. Stream Mapping and Usage 324 The mapping of DNS traffic over QUIC streams takes advantage of the 325 QUIC stream features detailed in Section 2 of [RFC9000], the QUIC 326 transport specification. 328 DNS traffic follows a simple pattern in which the client sends a 329 query, and the server provides one or more responses (multiple 330 responses can occur in zone transfers). 332 The mapping specified here requires that the client selects a 333 separate QUIC stream for each query. The server then uses the same 334 stream to provide all the response messages for that query. In order 335 that multiple responses can be parsed, a 2-octet length field is used 336 in exactly the same way as the 2-octet length field defined for DNS 337 over TCP [RFC1035]. The practical result of this is that the content 338 of each QUIC stream is exactly the same as the content of a TCP 339 connection that would manage exactly one query. 341 All DNS messages (queries and responses) sent over DoQ connections 342 MUST be encoded as a 2-octet length field followed by the message 343 content as specified in [RFC1035]. 345 The client MUST select the next available client-initiated 346 bidirectional stream for each subsequent query on a QUIC connection, 347 in conformance with the QUIC transport specification [RFC9000]. 349 The client MUST send the DNS query over the selected stream, and MUST 350 indicate through the STREAM FIN mechanism that no further data will 351 be sent on that stream. 353 The server MUST send the response(s) on the same stream and MUST 354 indicate, after the last response, through the STREAM FIN mechanism 355 that no further data will be sent on that stream. 357 Therefore, a single DNS transaction consumes a single bidirectional 358 client-initiated stream. This means that the client's first query 359 occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1 360 of [RFC9000]. 362 Servers MAY defer processing of a query until the STREAM FIN has been 363 indicated on the stream selected by the client. Servers and clients 364 MAY monitor the number of "dangling" streams for which the expected 365 queries or responses have been received but not the STREAM FIN. 366 Implementations MAY impose a limit on the number of such dangling 367 streams. If limits are encountered, implementations MAY close the 368 connection. 370 5.2.1. DNS Message IDs 372 When sending queries over a QUIC connection, the DNS Message ID MUST 373 be set to zero. The stream mapping for DoQ allows for unambiguous 374 correlation of queries and responses and so the Message ID field is 375 not required. 377 This has implications for proxying DoQ message to and from other 378 transports. For example, proxies may have to manage the fact that 379 DoQ can support a larger number of outstanding queries on a single 380 connection than e.g., DNS over TCP because DoQ is not limited by the 381 Message ID space. This issue already exists for DoH, where a Message 382 ID of 0 is recommended. 384 When forwarding a DNS message from DoQ over another transport, a DNS 385 Message ID MUST be generated according to the rules of the protocol 386 that is in use. When forwarding a DNS message from another transport 387 over DoQ, the Message ID MUST be set to zero. 389 5.3. DoQ Error Codes 391 The following error codes are defined for use when abruptly 392 terminating streams, aborting reading of streams, or immediately 393 closing connections: 395 DOQ_NO_ERROR (0x0): No error. This is used when the connection or 396 stream needs to be closed, but there is no error to signal. 398 DOQ_INTERNAL_ERROR (0x1): The DoQ implementation encountered an 399 internal error and is incapable of pursuing the transaction or the 400 connection. 402 DOQ_PROTOCOL_ERROR (0x2): The DoQ implementation encountered an 403 protocol error and is forcibly aborting the connection. 405 DOQ_REQUEST_CANCELLED (0x3): A DoQ client uses this to signal that 406 it wants to cancel an outstanding transaction. 408 DOQ_EXCESSIVE_LOAD (0x4): A DoQ implementation uses this to signal 409 when closing a connection due to excessive load. 411 DOQ_ERROR_RESERVED (0xd098ea5e): Alternative error code used for 412 tests. 414 See Section 10.4 for details on registering new error codes. 416 5.3.1. Transaction Cancellation 418 In QUIC, sending STOP_SENDING requests that a peer cease transmission 419 on a stream. If a DoQ client wishes to cancel an outstanding 420 request, it MUST issue a QUIC STOP_SENDING with error code 421 DOQ_REQUEST_CANCELLED. This may be sent at any time but will be 422 ignored if the server response has already been acknowledged. The 423 corresponding DNS transaction MUST be abandoned. 425 Servers that receive STOP_SENDING act in accordance with Section 3.5 426 of [RFC9000]. Servers MAY impose implementation limits on the total 427 number or rate of request cancellations. If limits are encountered, 428 servers MAY close the connection. In this case, servers wanting to 429 help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD. 430 There is always a trade-off between helping good faith clients debug 431 issues and allowing denial-of-service attackers to test server 432 defenses, so depending on circumstances servers might very well chose 433 to send different error codes. 435 Note that this mechanism provides a way for secondaries to cancel a 436 single zone transfer occurring on a given stream without having to 437 close the QUIC connection. 439 5.3.2. Transaction Errors 441 Servers normally complete transactions by sending a DNS response (or 442 responses) on the transaction's stream, including cases where the DNS 443 response indicates a DNS error. For example, a Server Failure 444 (SERVFAIL, [RFC1035]) SHOULD be notified to the client by sending 445 back a response with the Response Code set to SERVFAIL. 447 If a server is incapable of sending a DNS response due to an internal 448 error, it SHOULD issue a QUIC Stream Reset. The error code SHOULD be 449 set to DOQ_INTERNAL_ERROR. The corresponding DNS transaction MUST be 450 abandoned. Clients MAY limit the number of unsolicited QUIC Stream 451 Resets received on a connection before choosing to close the 452 connection. 454 Note that this mechanism provides a way for primaries to abort a 455 single zone transfer occurring on a given stream without having to 456 close the QUIC connection. 458 5.3.3. Protocol Errors 460 Other error scenarios can occur due to malformed, incomplete or 461 unexpected messages during a transaction. These include (but are not 462 limited to) 464 * a client or server receives a message with a non-zero Message ID 466 * a client or server receives a STREAM FIN before receiving all the 467 bytes for a message indicated in the 2-octet length field 469 * a client receives a STREAM FIN before receiving all the expected 470 responses 472 * a server receives more than one query on a stream 473 * a client receives a different number of responses on a stream than 474 expected (e.g. multiple responses to a query for an A record) 476 * a client receives a STOP_SENDING request 478 * the client or server does not indicate the expected STREAM FIN 479 after sending requests or responses (see Section 5.2). 481 * an implementation receives a message containing the edns-tcp- 482 keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2) 484 * a client or a server attempts to open a unidirectional QUIC stream 486 * a server attempts to open a server-initiated bidirectional QUIC 487 stream 489 If a peer encounters such an error condition it is considered a fatal 490 error. It SHOULD forcibly abort the connection using QUIC's 491 CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code 492 DOQ_PROTOCOL_ERROR. 494 It is noted that the restrictions on use of the above EDNS(0) options 495 has implications for proxying message from TCP/DoT/DoH over DoQ. 497 5.3.4. Alternative error codes 499 This specification suggests specific error codes in Section 5.3.1, 500 Section 5.3.2, and Section 5.3.3. These error codes are meant to 501 facilitate investigation of failures and other incidents. New error 502 codes may be defined in future versions of DoQ, or registered as 503 specified in Section 10.4. 505 Because new error codes can be defined without negotiation, use of an 506 error code in an unexpected context or receipt of an unknown error 507 code MUST be treated as equivalent to DOQ_NO_ERROR. 509 Implementations MAY wish to test the support for the error code 510 extension mechanism by using error codes not listed in this document, 511 or they MAY use DOQ_ERROR_RESERVED. 513 5.4. Connection Management 515 Section 10 of [RFC9000], the QUIC transport specification, specifies 516 that connections can be closed in three ways: 518 * idle timeout 520 * immediate close 521 * stateless reset 523 Clients and servers implementing DoQ SHOULD negotiate use of the idle 524 timeout. Closing on idle timeout is done without any packet 525 exchange, which minimizes protocol overhead. Per Section 10.1 of 526 [RFC9000], the QUIC transport specification, the effective value of 527 the idle timeout is computed as the minimum of the values advertised 528 by the two endpoints. Practical considerations on setting the idle 529 timeout are discussed in Section 6.5.2. 531 Clients SHOULD monitor the idle time incurred on their connection to 532 the server, defined by the time spent since the last packet from the 533 server has been received. When a client prepares to send a new DNS 534 query to the server, it will check whether the idle time is 535 sufficiently lower than the idle timer. If it is, the client will 536 send the DNS query over the existing connection. If not, the client 537 will establish a new connection and send the query over that 538 connection. 540 Clients MAY discard their connections to the server before the idle 541 timeout expires. A client that has outstanding queries SHOULD close 542 the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and 543 the DoQ error code DOQ_NO_ERROR. 545 Clients and servers MAY close the connection for a variety of other 546 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers 547 that send packets over a connection discarded by their peer MAY 548 receive a stateless reset indication. If a connection fails, all the 549 in progress transaction on that connection MUST be abandoned. 551 5.5. Session Resumption and 0-RTT 553 A client MAY take advantage of the session resumption mechanisms 554 supported by QUIC transport [RFC9000] and QUIC TLS [RFC9001]. 555 Clients SHOULD consider potential privacy issues associated with 556 session resumption before deciding to use this mechanism. These 557 privacy issues are detailed in Section 9.1 and Section 9.2, and the 558 implementation considerations are discussed in Section 6.5.3. 560 The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are 561 not "replayable" transactions. In this specification, only 562 transactions that have an OPCODE of QUERY or NOTIFY are considered 563 replayable and MAY be sent in 0-RTT data. See Appendix A for a 564 detailed discussion of why NOTIFY is included here. 566 Servers MUST NOT execute non replayable transactions received in 567 0-RTT data. Servers MUST adopt one of the following behaviors: 569 * Queue the offending transaction and only execute it after the QUIC 570 handshake has been completed, as defined in Section 4.1.1 of 571 [RFC9001]. 573 * Reply to the offending transaction with a response code REFUSED 574 and an Extended DNS Error Code (EDE) "Too Early", see 575 Section 10.3. 577 * Close the connection with the error code DOQ_PROTOCOL_ERROR. 579 5.6. Message Sizes 581 DoQ Queries and Responses are sent on QUIC streams, which in theory 582 can carry up to 2^62 bytes. However, DNS messages are restricted in 583 practice to a maximum size of 65535 bytes. This maximum size is 584 enforced by the use of a two-octet message length field in DNS over 585 TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of 586 the "application/dns-message" for DNS over HTTP [RFC8484]. DoQ 587 enforces the same restriction. 589 The Extension Mechanisms for DNS (EDNS) [RFC6891] allow peers to 590 specify the UDP message size. This parameter is ignored by DoQ. DoQ 591 implementations always assume that the maximum message size is 65535 592 bytes. 594 6. Implementation Requirements 596 6.1. Authentication 598 For the stub to recursive resolver scenario, the authentication 599 requirements are the same as described in DoT [RFC7858] and "Usage 600 Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932] 601 states that DNS privacy services SHOULD provide credentials that 602 clients can use to authenticate the server. Given this, and to align 603 with the authentication model for DoH, DoQ stubs SHOULD use a Strict 604 authentication profile. Client authentication for the encrypted stub 605 to recursive scenario is not described in any DNS RFC. 607 For zone transfer, the requirements are the same as described in 608 [RFC9103]. 610 For the recursive resolver to authoritative nameserver scenario, 611 authentication requirements are unspecified at the time of writing 612 and are the subject on ongoing work in the DPRIVE WG. 614 6.2. Fallback to Other Protocols on Connection Failure 616 If the establishment of the DoQ connection fails, clients MAY attempt 617 to fall back to DoT and then potentially clear text, as specified in 618 DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS" 619 [RFC8310], depending on their privacy profile. 621 DNS clients SHOULD remember server IP addresses that don't support 622 DoQ. Timeouts, connection refusals, and QUIC handshake failures are 623 valid indicators that a server does not support DoQ. Clients SHOULD 624 NOT attempt DoQ queries to a server that does not support DoQ for a 625 reasonable period (such as one hour per server). DNS clients 626 following an out-of-band key-pinned privacy profile ([RFC7858]) MAY 627 be more aggressive about retrying DoQ connection failures. 629 6.3. Address Validation 631 Section 8 of [RFC9000], the QUIC transport specification, defines 632 Address Validation procedures to avoid servers being used in address 633 amplification attacks. DoQ implementations MUST conform to this 634 specification, which limits the worst case amplification to a factor 635 3. 637 DoQ implementations SHOULD consider configuring servers to use the 638 Address Validation using Retry Packets procedure defined in 639 Section 8.1.2 of [RFC9000], the QUIC transport specification. This 640 procedure imposes a 1-RTT delay for verifying the return routability 641 of the source address of a client, similar to the DNS Cookies 642 mechanism [RFC7873]. 644 DoQ implementations that configure Address Validation using Retry 645 Packets SHOULD implement the Address Validation for Future 646 Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC 647 transport specification. This defines how servers can send NEW_TOKEN 648 frames to clients after the client address is validated, in order to 649 avoid the 1-RTT penalty during subsequent connections by the client 650 from the same address. 652 6.4. Padding 654 Implementations MUST protect against the traffic analysis attacks 655 described in Section 9.5 by the judicious injection of padding. This 656 could be done either by padding individual DNS messages using the 657 EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see 658 Section 8.6 of [RFC9000], the QUIC transport specification. 660 In theory, padding at the QUIC level could result in better 661 performance for the equivalent protection, because the amount of 662 padding can take into account non-DNS frames such as acknowledgements 663 or flow control updates, and also because QUIC packets can carry 664 multiple DNS messages. However, applications can only control the 665 amount of padding in QUIC packets if the implementation of QUIC 666 exposes adequate APIs. This leads to the following recommendation: 668 * if the implementation of QUIC exposes APIs to set a padding 669 policy, DNS over QUIC SHOULD use that API to align the packet 670 length to a small set of fixed sizes. 672 * if padding at the QUIC level is not available or not used, DNS 673 over QUIC MUST ensure that all DNS queries and responses are 674 padded to a small set of fixed sizes, using the EDNS(0) padding 675 extension as specified in [RFC7830]. 677 Implementation might choose not to use a QUIC API for padding if it 678 is significantly simpler to re-use existing DNS message padding logic 679 which is applied to other encrypted transports. 681 In the absence of a standard policy for padding sizes, 682 implementations SHOULD follow the recommendations of the Experimental 683 status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))" 684 [RFC8467]. While Experimental, these recommendations are referenced 685 because they are implemented and deployed for DoT, and provide a way 686 for implementations to be fully compliant with this specification. 688 6.5. Connection Handling 690 "DNS Transport over TCP - Implementation Requirements" [RFC7766] 691 provides updated guidance on DNS over TCP, some of which is 692 applicable to DoQ. This section provides similar advice on 693 connection handling for DoQ. 695 6.5.1. Connection Reuse 697 Historic implementations of DNS clients are known to open and close 698 TCP connections for each DNS query. To amortize connection setup 699 costs, both clients and servers SHOULD support connection reuse by 700 sending multiple queries and responses over a single persistent QUIC 701 connection. 703 In order to achieve performance on par with UDP, DNS clients SHOULD 704 send their queries concurrently over the QUIC streams on a QUIC 705 connection. That is, when a DNS client sends multiple queries to a 706 server over a QUIC connection, it SHOULD NOT wait for an outstanding 707 reply before sending the next query. 709 6.5.2. Resource Management 711 Proper management of established and idle connections is important to 712 the healthy operation of a DNS server. 714 An implementation of DoQ SHOULD follow best practices similar to 715 those specified for DNS over TCP [RFC7766], in particular with regard 716 to: 718 * Concurrent Connections (Section 6.2.2 of [RFC7766], updated by 719 Section 6.4 of [RFC9103]) 721 * Security Considerations (Section 10 of [RFC7766]) 723 Failure to do so may lead to resource exhaustion and denial of 724 service. 726 Clients that want to maintain long duration DoQ connections SHOULD 727 use the idle timeout mechanisms defined in Section 10.1 of [RFC9000], 728 the QUIC transport specification. Clients and servers MUST NOT send 729 the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent 730 on a DoQ connection (because it is specific to the use of TCP/TLS as 731 a transport). 733 This document does not make specific recommendations for timeout 734 values on idle connections. Clients and servers should reuse and/or 735 close connections depending on the level of available resources. 736 Timeouts may be longer during periods of low activity and shorter 737 during periods of high activity. 739 6.5.3. Using 0-RTT and Session Resumption 741 Using 0-RTT for DNS over QUIC has many compelling advantages. 742 Clients can establish connections and send queries without incurring 743 a connection delay. Servers can thus negotiate low values of the 744 connection timers, which reduces the total number of connections that 745 they need to manage. They can do that because the clients that use 746 0-RTT will not incur latency penalties if new connections are 747 required for a query. 749 Session resumption and 0-RTT data transmission create privacy risks 750 detailed in detailed in Section 9.2 and Section 9.1. The following 751 recommendations are meant to reduce the privacy risks while enjoying 752 the performance benefits of 0-RTT data, with the restriction 753 specified in Section 5.5. 755 Clients SHOULD use resumption tickets only once, as specified in 756 Appendix C.4 to [RFC8446]. By default, clients SHOULD NOT use 757 session resumption if the client's connectivity has changed. 759 Clients could receive address validation tokens from the server using 760 the NEW_TOKEN mechanism; see Section 8 of [RFC9000]. The associated 761 tracking risks are mentioned in Section 9.3. Clients SHOULD only use 762 the address validation tokens when they are also using session 763 resumption, thus avoiding additional tracking risks. 765 Servers SHOULD issue session resumption tickets with a sufficiently 766 long life time (e.g., 6 hours), so that clients are not tempted to 767 either keep connection alive or frequently poll the server to renew 768 session resumption tickets. Servers SHOULD implement the anti-replay 769 mechanisms specified in Section 8 of [RFC8446]. 771 6.5.4. Controlling Connection Migration For Privacy 773 DoQ implementation might consider using the connection migration 774 features defined in Section 9 of [RFC9000]. These features enable 775 connections to continue operating as the client's connectivity 776 changes. As detailed in Section 9.4, these features trade off 777 privacy for latency. By default, clients SHOULD be configured to 778 prioritize privacy and start new sessions if their connectivity 779 changes. 781 6.6. Processing Queries in Parallel 783 As specified in Section 7 of [RFC7766] "DNS Transport over TCP - 784 Implementation Requirements", resolvers are RECOMMENDED to support 785 the preparing of responses in parallel and sending them out of order. 786 In DoQ, they do that by sending responses on their specific stream as 787 soon as possible, without waiting for availability of responses for 788 previously opened streams. 790 6.7. Zone transfer 792 [RFC9103] specifies zone transfer over TLS (XoT) and includes updates 793 to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766]. Considerations 794 relating to the re-use of XoT connections described there apply 795 analogously to zone transfers performed using DoQ connections. For 796 example: 798 * DoQ servers MUST be able to handle multiple concurrent IXFR 799 requests on a single QUIC connection 801 * DoQ servers MUST be able to handle multiple concurrent AXFR 802 requests on a single QUIC connection 804 * DoQ implementations SHOULD 806 - use the same QUIC connection for both AXFR and IXFR requests to 807 the same primary 809 - pipeline such requests (if they pipeline XFR requests in 810 general) and MAY intermingle them 812 - send the response(s) for each request as soon as they are 813 available i.e. responses MAY be sent intermingled 815 6.8. Flow Control Mechanisms 817 Servers and Clients manage flow control using the mechanisms defined 818 in Section 4 of [RFC9000]. These mechanisms allow clients and 819 servers to specify how many streams can be created, how much data can 820 be sent on a stream, and how much data can be sent on the union of 821 all streams. For DNS over QUIC, controlling how many streams are 822 created allows servers to control how many new requests the client 823 can send on a given connection. 825 Flow control exists to protect endpoint resources. For servers, 826 global and per-stream flow control limits control how much data can 827 be sent by clients. The same mechanisms allow clients to control how 828 much data can be sent by servers. Values that are too small will 829 unnecessarily limit performance. Values that are too large might 830 expose endpoints to overload or memory exhaustion. Implementations 831 or deployments will need to adjust flow control limits to balance 832 these concerns. In particular, zone transfer implementations will 833 need to control these limits carefully to ensure both large and 834 concurrent zone transfers are well managed. 836 Initial values of parameters control how many requests and how much 837 data can be sent by clients and servers at the beginning of the 838 connection. These values are specified in transport parameters 839 exchanged during the connection handshake. The parameter values 840 received in the initial connection also control how many requests and 841 how much data can be sent by clients using 0-RTT data in a resumed 842 connection. Using too small values of these initial parameters would 843 restrict the usefulness of allowing 0-RTT data. 845 7. Implementation Status 847 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) This 848 section records the status of known implementations of the protocol 849 defined by this specification at the time of posting of this 850 Internet-Draft, and is based on a proposal described in [RFC7942]. 852 1. AdGuard launched a DoQ recursive resolver service in December 853 2020. They have released a suite of open source tools that 854 support DoQ: 856 1. AdGuard C++ DNS libraries (https://github.com/AdguardTeam/ 857 DnsLibs) A DNS proxy library that supports all existing DNS 858 protocols including DNS-over-TLS, DNS-over-HTTPS, DNSCrypt 859 and DNS-over-QUIC (experimental). 861 2. DNS Proxy (https://github.com/AdguardTeam/dnsproxy) A simple 862 DNS proxy server that supports all existing DNS protocols 863 including DNS-over-TLS, DNS-over-HTTPS, DNSCrypt, and DNS- 864 over-QUIC. Moreover, it can work as a DNS-over-HTTPS, DNS- 865 over-TLS or DNS-over-QUIC server. 867 3. CoreDNS fork for AdGuard DNS (https://github.com/AdguardTeam/ 868 coredns) Includes DNS-over-QUIC server-side support. 870 4. dnslookup (https://github.com/ameshkov/dnslookup) Simple 871 command line utility to make DNS lookups. Supports all known 872 DNS protocols: plain DNS, DoH, DoT, DoQ, DNSCrypt. 874 2. Quicdoq (https://github.com/private-octopus/quicdoq) Quicdoq is a 875 simple open source implementation of DoQ. It is written in C, 876 based on Picoquic (https://github.com/private-octopus/picoquic). 878 3. Flamethrower (https://github.com/DNS-OARC/flamethrower/tree/dns- 879 over-quic) is an open source DNS performance and functional 880 testing utility written in C++ that has an experimental 881 implementation of DoQ. 883 4. aioquic (https://github.com/aiortc/aioquic) is an implementation 884 of QUIC in Python. It includes example client and server for 885 DoQ. 887 7.1. Performance Measurements 889 To the authors' knowledge, no benchmarking studies comparing DoT, DoH 890 and DoQ are published yet. However, anecdotal evidence from the 891 AdGuard DoQ recursive resolver deployment 892 (https://adguard.com/en/blog/dns-over-quic.html) indicates that it 893 performs similarly (and possibly better) compared to the other 894 encrypted protocols, particularly in mobile environments. Reasons 895 given for this include that DoQ 897 * Uses less bandwidth due to a more efficient handshake (and due to 898 less per message overhead when compared to DoH). 900 * Performs better in mobile environments due to the increased 901 resilience to packet loss 903 * Can maintain connections as users move between mobile networks via 904 its connection management 906 8. Security Considerations 908 A general Threat Analysis of the Domain Name System is found in 909 [RFC3833]. This analysis was written before the development of DoT, 910 DoH and DoQ, and probably needs to be updated. 912 The security considerations of DoQ should be comparable to those of 913 DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub 914 to recursive resolver scenario, but the considerations about person- 915 in-the-middle attacks, middleboxes and caching of data from clear 916 text connections also apply for DoQ to the resolver to authoritative 917 server scenario. As stated in Section 6.1 the authentication 918 requirements for securing zone transfer using DoQ are the same as 919 those for zone transfer over DoT, therefore the general security 920 considerations are entirely analogous to those described in 921 [RFC9103]. 923 DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports 924 by default the protections against downgrade attacks described in 925 [BCP195]. QUIC specific issues and their mitigations are described 926 in Section 21 of [RFC9000]. 928 9. Privacy Considerations 930 The general considerations of encrypted transports provided in "DNS 931 Privacy Considerations" [RFC9076] apply to DoQ. The specific 932 considerations provided there do not differ between DoT and DoQ, and 933 are not discussed further here. Similarly, "Recommendations for DNS 934 Privacy Service Operators" [RFC8932] (which covers operational, 935 policy, and security considerations for DNS privacy services) is also 936 applicable to DoQ services. 938 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this 939 enables QUIC transmission of "0-RTT" data. This can provide 940 interesting latency gains, but it raises two concerns: 942 1. Adversaries could replay the 0-RTT data and infer its content 943 from the behavior of the receiving server. 945 2. The 0-RTT mechanism relies on TLS session resumption, which can 946 provide linkability between successive client sessions. 948 These issues are developed in Section 9.1 and Section 9.2. 950 9.1. Privacy Issues With 0-RTT data 952 The 0-RTT data can be replayed by adversaries. That data may trigger 953 queries by a recursive resolver to authoritative resolvers. 954 Adversaries may be able to pick a time at which the recursive 955 resolver outgoing traffic is observable, and thus find out what name 956 was queried for in the 0-RTT data. 958 This risk is in fact a subset of the general problem of observing the 959 behavior of the recursive resolver discussed in "DNS Privacy 960 Considerations" [RFC9076]. The attack is partially mitigated by 961 reducing the observability of this traffic. The mandatory replay 962 protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate 963 the risk of replay. 0-RTT packets can only be replayed within a 964 narrow window, which is only wide enough to account for variations in 965 clock skew and network transmission. 967 The recommendation for TLS 1.3 [RFC8446] is that the capability to 968 use 0-RTT data should be turned off by default, and only enabled if 969 the user clearly understands the associated risks. In the case of 970 DoQ, allowing 0-RTT data provides significant performance gains, and 971 there is a concern that a recommendation to not use it would simply 972 be ignored. Instead, a set of practical recommendations is provided 973 in Section 5.5 and Section 6.5.3. 975 The prevention on allowing replayable transactions in 0-RTT data 976 expressed in Section 5.5 blocks the most obvious risks of replay 977 attacks, as it only allows for transactions that will not change the 978 long-term state of the server. 980 The attacks described above apply to the stub resolver to recursive 981 resolver scenario, but similar attacks might be envisaged in the 982 recursive resolver to authoritative resolver scenario, and the same 983 mitigations apply. 985 9.2. Privacy Issues With Session Resumption 987 The QUIC session resumption mechanism reduces the cost of re- 988 establishing sessions and enables 0-RTT data. There is a linkability 989 issue associated with session resumption, if the same resumption 990 token is used several times. Attackers on path between client and 991 server could observe repeated usage of the token and use that to 992 track the client over time or over multiple locations. 994 The session resumption mechanism allows servers to correlate the 995 resumed sessions with the initial sessions, and thus to track the 996 client. This creates a virtual long duration session. The series of 997 queries in that session can be used by the server to identify the 998 client. Servers can most probably do that already if the client 999 address remains constant, but session resumption tickets also enable 1000 tracking after changes of the client's address. 1002 The recommendations in Section 6.5.3 are designed to mitigate these 1003 risks. Using session tickets only once mitigates the risk of 1004 tracking by third parties. Refusing to resume a session if addresses 1005 change mitigates the risk of tracking by the server. 1007 The privacy trade-offs here may be context specific. Stub resolvers 1008 will have a strong motivation to prefer privacy over latency since 1009 they often change location. However, recursive resolvers that use a 1010 small set of static IP addresses are more likely to prefer the 1011 reduced latency provided by session resumption and may consider this 1012 a valid reason to use resumption tickets even if the IP address 1013 changed between sessions. 1015 Encrypted zone transfer (RFC9103) explicitly does not attempt to hide 1016 the identity of the parties involved in the transfer, but at the same 1017 time such transfers are not particularly latency sensitive. This 1018 means that applications supporting zone transfers may decide to apply 1019 the same protections as stub to recursive applications. 1021 9.3. Privacy Issues With Address Validation Tokens 1023 QUIC specifies address validation mechanisms in Section 8 of 1024 [RFC9000]. Use of an address validation token allows QUIC servers to 1025 avoid an extra RTT for new connections. Address validation tokens 1026 are typically tied to an IP address. QUIC clients normally only use 1027 these tokens when setting up a new connection from a previously used 1028 address. However, clients are not always aware that they are using a 1029 new address. This could be due to NAT, or because the client does 1030 not have an API available to check if the IP address has changed 1031 (which can be quite often for IPv6). There is a linkability risk if 1032 clients mistakenly use address validation tokens after unknowingly 1033 moving to a new location. 1035 The recommendations in Section 6.5.3 mitigates this risk by tying the 1036 usage of the NEW_TOKEN to that of session resumption. 1038 9.4. Privacy Issues With Long Duration Sessions 1040 A potential alternative to session resumption is the use of long 1041 duration sessions: if a session remains open for a long time, new 1042 queries can be sent without incurring connection establishment 1043 delays. It is worth pointing out that the two solutions have similar 1044 privacy characteristics. Session resumption may allow servers to 1045 keep track of the IP addresses of clients, but long duration sessions 1046 have the same effect. 1048 In particular, a DoQ implementation might take advantage of the 1049 connection migration features of QUIC to maintain a session even if 1050 the client's connectivity changes, for example if the client migrates 1051 from a Wi-Fi connection to a cellular network connection, and then to 1052 another Wi-Fi connection. The server would be able to track the 1053 client location by monitoring the succession of IP addresses used by 1054 the long duration connection. 1056 The recommendation in Section 6.5.4 mitigates the privacy concerns 1057 related to long duration sessions using multiple client addresses. 1059 9.5. Traffic Analysis 1061 Even though QUIC packets are encrypted, adversaries can gain 1062 information from observing packet lengths, in both queries and 1063 responses, as well as packet timing. Many DNS requests are emitted 1064 by web browsers. Loading a specific web page may require resolving 1065 dozen of DNS names. If an application adopts a simple mapping of one 1066 query or response per packet, or "one QUIC STREAM frame per packet", 1067 then the succession of packet lengths may provide enough information 1068 to identify the requested site. 1070 Implementations SHOULD use the mechanisms defined in Section 6.4 to 1071 mitigate this attack. 1073 10. IANA Considerations 1075 10.1. Registration of DoQ Identification String 1077 This document creates a new registration for the identification of 1078 DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol 1079 IDs" registry [RFC7301]. 1081 The "doq" string identifies DoQ: 1083 Protocol: DoQ 1085 Identification Sequence: 0x64 0x6F 0x71 ("doq") 1086 Specification: This document 1088 10.2. Reservation of Dedicated Port 1090 For both TCP and UDP port 853 is currently reserved for 'DNS query- 1091 response protocol run over TLS/DTLS' [RFC7858]. 1093 However, the specification for DNS over DTLS (DoD) [RFC8094] is 1094 experimental, limited to stub to resolver, and no implementations or 1095 deployments currently exist to the authors' knowledge (even though 1096 several years have passed since the specification was published). 1098 This specification proposes to additionally reserve the use of UDP 1099 port 853 for DoQ. QUIC version 1 was designed to be able to co-exist 1100 with other protocols on the same port, including DTLS , see 1101 Section 17.2 of [RFC9000]. This means that deployments that serve 1102 DNS over DTLS and DNS over QUIC (QUIC version 1) on the same port 1103 will be able to demultiplex the two due to the second most 1104 significant bit in each UDP payload. Such deployments ought to check 1105 the signatures of future versions or extensions (e.g. 1106 [I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to 1107 serve DNS on the same port. 1109 IANA is requested to update the following value in the "Service Name 1110 and Transport Protocol Port Number Registry" in the System Range. 1111 The registry for that range requires IETF Review or IESG Approval 1112 [RFC6335]. 1114 Service Name: domain-s 1116 Port Number: 853 1118 Transport Protocol(s): UDP 1120 Assignee: IETF DPRIVE Chairs 1122 Contact: Brian Haberman 1124 Description: DNS query-response protocol run over DTLS or QUIC 1126 Reference: [RFC7858][RFC8094] This document 1128 Additionally, IANA is requested to update the Description field for 1129 the corresponding TCP port 853 allocation to be 'DNS query-response 1130 protocol run over TLS' for consistency and clarity. 1132 (UPDATE ON IANA REQUEST: THIS SENTENCE TO BE REMOVED BEFORE 1133 PUBLICATION) Review by the port experts on 13th December 2021 1134 determined that the proposed updates to the existing port allocation 1135 were acceptable and will be made when this document is approved for 1136 publication. 1138 10.3. Reservation of Extended DNS Error Code Too Early 1140 IANA is requested to add the following value to the Extended DNS 1141 Error Codes registry [RFC8914]: 1143 INFO-CODE: TBD 1145 Purpose: Too Early 1147 Reference: This document 1149 10.4. DNS over QUIC Error Codes Registry 1151 IANA [SHALL add/has added] a registry for "DNS over QUIC Error Codes" 1152 on the "Domain Name System (DNS) Parameters" web page. 1154 The "DNS over QUIC Error Codes" registry governs a 62-bit space. 1155 This space is split into three regions that are governed by different 1156 policies: 1158 * Permanent registrations for values between 0x00 and 0x3f (in 1159 hexadecimal; inclusive), which are assigned using Standards Action 1160 or IESG Approval as defined in Section 4.9 and Section 4.10 of 1161 [RFC8126] 1163 * Permanent registrations for values larger than 0x3f, which are 1164 assigned using the Specification Required policy ([RFC8126]) 1166 * Provisional registrations for values larger than 0x3f, which 1167 require Expert Review, as defined in Section 4.5 of [RFC8126]. 1169 Provisional reservations share the range of values larger than 0x3f 1170 with some permanent registrations. This is by design, to enable 1171 conversion of provisional registrations into permanent registrations 1172 without requiring changes in deployed systems. (This design is 1173 aligned with the principles set in Section 22 of [RFC9000].) 1175 Registrations in this registry MUST include the following fields: 1177 Value: The assigned codepoint. 1179 Status: "Permanent" or "Provisional". 1181 Contact: Contact details for the registrant. 1183 Notes: Supplementary notes about the registration. 1185 In addition, permanent registrations MUST include: 1187 Error: A short mnemonic for the parameter. 1189 Specification: A reference to a publicly available specification for 1190 the value (optional for provisional registrations). 1192 Description: A brief description of the error code semantics, which 1193 MAY be a summary if a specification reference is provided. 1195 Provisional registrations of codepoints are intended to allow for 1196 private use and experimentation with extensions to DNS over QUIC. 1197 However, provisional registrations could be reclaimed and reassigned 1198 for another purpose. In addition to the parameters listed above, 1199 provisional registrations MUST include: 1201 Date: The date of last update to the registration. 1203 A request to update the date on any provisional registration can be 1204 made without review from the designated expert(s). 1206 The initial contents of this registry are shown in Table 1. 1208 +==========+=======================+================+===============+ 1209 |Value | Error |Description | Specification | 1210 +==========+=======================+================+===============+ 1211 |0x0 | DOQ_NO_ERROR |No error | Section 5.3 | 1212 +----------+-----------------------+----------------+---------------+ 1213 |0x1 | DOQ_INTERNAL_ERROR |Implementation | Section 5.3 | 1214 | | |error | | 1215 +----------+-----------------------+----------------+---------------+ 1216 |0x2 | DOQ_PROTOCOL_ERROR |Generic protocol| Section 5.3 | 1217 | | |violation | | 1218 +----------+-----------------------+----------------+---------------+ 1219 |0x3 | DOQ_REQUEST_CANCELLED |Request | Section 5.3 | 1220 | | |cancelled by | | 1221 | | |client | | 1222 +----------+-----------------------+----------------+---------------+ 1223 |0x4 | DOQ_EXCESSIVE_LOAD |Closing a | Section 5.3 | 1224 | | |connection for | | 1225 | | |excessive load | | 1226 +----------+-----------------------+----------------+---------------+ 1227 |0xd098ea5e| DOQ_ERROR_RESERVED |Alternative | Section 5.3 | 1228 | | |error code used | | 1229 | | |for tests | | 1230 +----------+-----------------------+----------------+---------------+ 1232 Table 1: Initial DNS over QUIC Error Codes Entries 1234 11. Acknowledgements 1236 This document liberally borrows text from the HTTP-3 specification 1237 [I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT 1238 specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, 1239 Allison Mankin, Duane Wessels, and Paul Hoffman. 1241 The privacy issue with 0-RTT data and session resumption were 1242 analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF 1243 "DPRIVE" working group [DNS0RTT]. 1245 Thanks to Tony Finch for an extensive review of the initial version 1246 of this draft, and to Robert Evans for the discussion of 0-RTT 1247 privacy issues. Early reviews by Paul Hoffman and Martin Thomson and 1248 interoperability tests conducted by Stephane Bortzmeyer helped 1249 improve the definition of the protocol. 1251 Thanks also to Martin Thomson and Martin Duke for their later reviews 1252 focussing on the low level QUIC details which helped clarify several 1253 aspects of DoQ. Thanks to Andrey Meshkov, Loganaden Velvindron, 1254 Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell and Phillip 1255 Hallam-Baker for their reviews and contributions. 1257 12. References 1259 12.1. Normative References 1261 [I-D.ietf-dnsop-rfc8499bis] 1262 Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in 1263 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03, 1264 28 September 2021, . 1267 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1268 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1269 . 1271 [RFC1035] Mockapetris, P., "Domain names - implementation and 1272 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1273 November 1987, . 1275 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1276 DOI 10.17487/RFC1995, August 1996, 1277 . 1279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", BCP 14, RFC 2119, 1281 DOI 10.17487/RFC2119, March 1997, 1282 . 1284 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1285 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1286 . 1288 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1289 for DNS (EDNS(0))", STD 75, RFC 6891, 1290 DOI 10.17487/RFC6891, April 2013, 1291 . 1293 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1294 "Transport Layer Security (TLS) Application-Layer Protocol 1295 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1296 July 2014, . 1298 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1299 D. Wessels, "DNS Transport over TCP - Implementation 1300 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1301 . 1303 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1304 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1305 DOI 10.17487/RFC7828, April 2016, 1306 . 1308 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1309 DOI 10.17487/RFC7830, May 2016, 1310 . 1312 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1313 and P. Hoffman, "Specification for DNS over Transport 1314 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1315 2016, . 1317 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1318 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1319 . 1321 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1322 Writing an IANA Considerations Section in RFCs", BCP 26, 1323 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1324 . 1326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1328 May 2017, . 1330 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1331 for DNS over TLS and DNS over DTLS", RFC 8310, 1332 DOI 10.17487/RFC8310, March 2018, 1333 . 1335 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1336 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1337 October 2018, . 1339 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1340 Lawrence, "Extended DNS Errors", RFC 8914, 1341 DOI 10.17487/RFC8914, October 2020, 1342 . 1344 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1345 Multiplexed and Secure Transport", RFC 9000, 1346 DOI 10.17487/RFC9000, May 2021, 1347 . 1349 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1350 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1351 . 1353 [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 1354 Mankin, "DNS Zone Transfer over TLS", RFC 9103, 1355 DOI 10.17487/RFC9103, August 2021, 1356 . 1358 12.2. Informative References 1360 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 1361 "Recommendations for Secure Use of Transport Layer 1362 Security (TLS) and Datagram Transport Layer Security 1363 (DTLS)", BCP 195, RFC 7525, May 2015. 1365 Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1366 1.1", BCP 195, RFC 8996, March 2021. 1368 1370 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG 1371 mailing list, 6 April 2016, . 1374 [I-D.ietf-quic-bit-grease] 1375 Thomson, M., "Greasing the QUIC Bit", Work in Progress, 1376 Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November 1377 2021, . 1380 [I-D.ietf-quic-http] 1381 Bishop, M., "Hypertext Transfer Protocol Version 3 1382 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1383 quic-http-34, 2 February 2021, 1384 . 1387 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1388 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1389 August 1996, . 1391 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1392 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 1393 2004, . 1395 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1396 Cheshire, "Internet Assigned Numbers Authority (IANA) 1397 Procedures for the Management of the Service Name and 1398 Transport Protocol Port Number Registry", BCP 165, 1399 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1400 . 1402 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1403 Code: The Implementation Status Section", BCP 205, 1404 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1405 . 1407 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1408 Transport Layer Security (DTLS)", RFC 8094, 1409 DOI 10.17487/RFC8094, February 2017, 1410 . 1412 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1413 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1414 . 1416 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1417 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1418 . 1420 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1421 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1422 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1423 . 1425 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 1426 A. Mankin, "Recommendations for DNS Privacy Service 1427 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, 1428 October 2020, . 1430 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1431 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 1432 May 2021, . 1434 [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, 1435 DOI 10.17487/RFC9076, July 2021, 1436 . 1438 Appendix A. The NOTIFY Service 1440 This appendix discusses why it is considered acceptable to send 1441 NOTIFY (see [RFC1996]) in 0-RTT data. 1443 Section 5.5 says "The 0-RTT mechanism SHOULD NOT be used to send DNS 1444 requests that are not "replayable" transactions". This specification 1445 supports sending a NOTIFY in 0-RTT data because although a NOTIFY 1446 technically changes the state of the receiving server, the effect of 1447 replaying NOTIFYs has negligible impact in practice. 1449 NOTIFY messages prompt a secondary to either send an SOA query or an 1450 XFR request to the primary on the basis that a newer version of the 1451 zone is available. It has long been recognized that NOTIFYs can be 1452 forged and, in theory, used to cause a secondary to send repeated 1453 unnecessary requests to the primary. For this reason, most 1454 implementations have some form of throttling of the SOA/XFR queries 1455 triggered by the receipt of one or more NOTIFYs. 1457 [RFC9103] describes the privacy risks associated with both NOTIFY and 1458 SOA queries and does not include addressing those risks within the 1459 scope of encrypting zone transfers. Given this, the privacy benefit 1460 of using DoQ for NOTIFY is not clear - but for the same reason, 1461 sending NOTIFY as 0-RTT data has no privacy risk above that of 1462 sending it using cleartext DNS. 1464 Appendix B. Notable Changes From Previous Versions 1466 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) 1468 B.1. Stream Mapping Incompatibility With Draft-02 1470 Versions prior to -02 of this specification proposed a simpler 1471 mapping scheme of queries and responses to QUIc stream, which omitted 1472 the 2 byte length field and supported only a single response on a 1473 given stream. The more complex mapping in Section 5.2 was adopted to 1474 specifically cater for XFR support, however, it breaks compatibility 1475 with earlier versions. 1477 Authors' Addresses 1479 Christian Huitema 1480 Private Octopus Inc. 1481 427 Golfcourse Rd 1482 Friday Harbor, WA 98250 1483 United States of America 1485 Email: huitema@huitema.net 1487 Sara Dickinson 1488 Sinodun IT 1489 Oxford Science Park 1490 Oxford 1491 OX4 4GA 1492 United Kingdom 1494 Email: sara@sinodun.com 1496 Allison Mankin 1497 Salesforce 1499 Email: allison.mankin@gmail.com