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