idnits 2.17.00 (12 Aug 2021) /tmp/idnits46919/draft-ietf-dprive-dnsoquic-07.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (1 December 2021) is 170 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 8094 ** Downref: Normative reference to an Experimental RFC: RFC 8467 Summary: 2 errors (**), 0 flaws (~~), 2 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: 4 June 2022 Sinodun IT 6 A. Mankin 7 Salesforce 8 1 December 2021 10 DNS over Dedicated QUIC Connections 11 draft-ietf-dprive-dnsoquic-07 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. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 4 June 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Document work via GitHub . . . . . . . . . . . . . . . . . . 5 59 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5 61 4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5 62 4.3. Middlebox Considerations . . . . . . . . . . . . . . . . 6 63 4.4. No Server Initiated Transactions . . . . . . . . . . . . 6 64 5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Connection Establishment . . . . . . . . . . . . . . . . 6 66 5.1.1. Draft Version Identification . . . . . . . . . . . . 7 67 5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7 68 5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7 69 5.2.1. DNS Message IDs . . . . . . . . . . . . . . . . . . . 8 70 5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9 71 5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9 72 5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 10 73 5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10 74 5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11 75 5.4. Connection Management . . . . . . . . . . . . . . . . . . 11 76 5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12 77 5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 13 78 6. Implementation Requirements . . . . . . . . . . . . . . . . . 13 79 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13 80 6.2. Fallback to Other Protocols on Connection Failure . . . . 14 81 6.3. Address Validation . . . . . . . . . . . . . . . . . . . 14 82 6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15 84 6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15 85 6.5.2. Resource Management . . . . . . . . . . . . . . . . . 15 86 6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16 87 6.5.4. Controlling Connection Migration For Privacy . . . . 17 88 6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17 89 6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17 90 6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18 91 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 92 7.1. Performance Measurements . . . . . . . . . . . . . . . . 19 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 95 9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 20 96 9.2. Privacy Issues With Session Resumption . . . . . . . . . 21 97 9.3. Privacy Issues With Address Validation Tokens . . . . . . 22 98 9.4. Privacy Issues With Long Duration Sessions . . . . . . . 22 99 9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 10.1. Registration of DoQ Identification String . . . . . . . 23 102 10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 23 103 10.2.1. Port number 784 for experimentations . . . . . . . . 24 104 10.3. Reservation of Extended DNS Error Code Too Early . . . . 24 105 10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 24 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 109 12.2. Informative References . . . . . . . . . . . . . . . . . 29 110 Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 30 111 Appendix B. Notable Changes From Previous Versions . . . . . . . 30 112 B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 31 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 115 1. Introduction 117 Domain Name System (DNS) concepts are specified in "Domain names - 118 concepts and facilities" [RFC1034]. The transmission of DNS queries 119 and responses over UDP and TCP is specified in "Domain names - 120 implementation and specification" [RFC1035]. 122 This document presents a mapping of the DNS protocol over the QUIC 123 transport [RFC9000] [RFC9001]. DNS over QUIC is referred here as 124 DoQ, in line with "DNS Terminology" [I-D.ietf-dnsop-rfc8499bis]. 126 The goals of the DoQ mapping are: 128 1. Provide the same DNS privacy protection as DNS over TLS (DoT) 129 [RFC7858]. This includes an option for the client to 130 authenticate the server by means of an authentication domain name 131 as specified in "Usage Profiles for DNS over TLS and DNS over 132 DTLS" [RFC8310]. 134 2. Provide an improved level of source address validation for DNS 135 servers compared to classic DNS over UDP. 137 3. Provide a transport that is not constrained by path MTU 138 limitations on the size of DNS responses it can send. 140 In order to achieve these goals, and to support ongoing work on 141 encryption of DNS, the scope of this document includes 143 * the "stub to recursive resolver" scenario 144 * the "recursive resolver to authoritative nameserver" scenario and 146 * the "nameserver to nameserver" scenario (mainly used for zone 147 transfers (XFR) [RFC1995], [RFC5936]). 149 In other words, this document is intended to specify QUIC as a 150 general purpose transport for DNS. 152 The specific non-goals of this document are: 154 1. No attempt is made to evade potential blocking of DNS over QUIC 155 traffic by middleboxes. 157 2. No attempt to support server initiated transactions, which are 158 used only in DNS Stateful Operations (DSO) [RFC8490]. 160 Specifying the transmission of an application over QUIC requires 161 specifying how the application's messages are mapped to QUIC streams, 162 and generally how the application will use QUIC. This is done for 163 HTTP in "Hypertext Transfer Protocol Version 3 164 (HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to 165 define the way DNS messages can be transmitted over QUIC. 167 DNS over HTTP [RFC8484] can be used with HTTP/3 to get some of the 168 benefits of QUIC. However, a lightweight direct mapping for DNS over 169 QUIC can be regarded as a more natural fit for both the recursive to 170 authoritative and zone transfer scenarios which rarely involve 171 intermediaries. In these scenarios, the additional overhead of HTTP 172 is not offset by, e.g., benefits of HTTP proxying and caching 173 behavior. 175 In this document, Section 4 presents the reasoning that guided the 176 proposed design. Section 5 specifies the actual mapping of DoQ. 177 Section 6 presents guidelines on the implementation, usage and 178 deployment of DoQ. 180 2. Key Words 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in BCP 14 [RFC8174]. 186 3. Document work via GitHub 188 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The 189 Github repository for this document is at https://github.com/huitema/ 190 dnsoquic. Proposed text and editorial changes are very much welcomed 191 there, but any functional changes should always first be discussed on 192 the IETF DPRIVE WG (dns-privacy) mailing list. 194 4. Design Considerations 196 This section and its subsections present the design guidelines that 197 were used for DoQ. This section is informative in nature. 199 4.1. Provide DNS Privacy 201 DoT [RFC7858] defines how to mitigate some of the issues described in 202 "DNS Privacy Considerations" [RFC9076] by specifying how to transmit 203 DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS 204 over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles 205 for DoT including how stub resolvers can authenticate recursive 206 resolvers. 208 QUIC connection setup includes the negotiation of security parameters 209 using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001], 210 enabling encryption of the QUIC transport. Transmitting DNS messages 211 over QUIC will provide essentially the same privacy protections as 212 DoT [RFC7858] including Strict and Opportunistic Usage Profiles 213 [RFC8310]. Further discussion on this is provided in Section 9. 215 4.2. Design for Minimum Latency 217 QUIC is specifically designed to reduce protocol-induced delays, with 218 features such as: 220 1. Support for 0-RTT data during session resumption. 222 2. Support for advanced packet loss recovery procedures as specified 223 in "QUIC Loss Detection and Congestion Control" [RFC9002]. 225 3. Mitigation of head-of-line blocking by allowing parallel delivery 226 of data on multiple streams. 228 This mapping of DNS to QUIC will take advantage of these features in 229 three ways: 231 1. Optional support for sending 0-RTT data during session resumption 232 (the security and privacy implications of this are discussed in 233 later sections). 235 2. Long-lived QUIC connections over which multiple DNS transactions 236 are performed, generating the sustained traffic required to 237 benefit from advanced recovery features. 239 3. Mapping of each DNS Query/Response transaction to a separate 240 stream, to mitigate head-of-line blocking. This enables servers 241 to respond to queries "out of order". It also enables clients to 242 process responses as soon as they arrive, without having to wait 243 for in order delivery of responses previously posted by the 244 server. 246 These considerations are reflected in the mapping of DNS traffic to 247 QUIC streams in Section 5.2. 249 4.3. Middlebox Considerations 251 Using QUIC might allow a protocol to disguise its purpose from 252 devices on the network path using encryption and traffic analysis 253 resistance techniques like padding. This specification does not 254 include any measures that are designed to avoid such classification. 255 Consequently, firewalls and other middleboxes might be able to 256 distinguish DoQ from other protocols that use QUIC, like HTTP, and 257 apply different treatment. 259 The lack of measures in this specification to avoid protocol 260 classification is not an endorsement of such practices. 262 4.4. No Server Initiated Transactions 264 As stated in Section 1, this document does not specify support for 265 server initiated transactions within established DoQ connections. 266 That is, only the initiator of the DoQ connection may send queries 267 over the connection. 269 DSO does support server-initiated transactions within existing 270 connections. However DoQ as defined here does not meet the criteria 271 for an applicable transport for DSO because it does not guarantee in- 272 order delivery of messages, see Section 4.2 of [RFC8490]. 274 5. Specifications 276 5.1. Connection Establishment 278 DoQ connections are established as described in the QUIC transport 279 specification [RFC9000]. During connection establishment, DoQ 280 support is indicated by selecting the ALPN token "doq" in the crypto 281 handshake. 283 5.1.1. Draft Version Identification 285 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only 286 implementations of the final, published RFC can identify themselves 287 as "doq". Until such an RFC exists, implementations MUST NOT 288 identify themselves using this string. 290 Implementations of draft versions of the protocol MUST add the string 291 "-" and the corresponding draft number to the identifier. For 292 example, draft-ietf-dprive-dnsoquic-00 is identified using the string 293 "doq-i00". 295 5.1.2. Port Selection 297 By default, a DNS server that supports DoQ MUST listen for and accept 298 QUIC connections on the dedicated UDP port TBD (number to be defined 299 in Section 10), unless there is a mutual agreement to use another 300 port. 302 By default, a DNS client desiring to use DoQ with a particular server 303 MUST establish a QUIC connection to UDP port TBD on the server, 304 unless there is a mutual agreement to use another port. 306 In order to use a port other than TBD, both clients and servers would 307 need a configuration option in their software. 309 DoQ connections MUST NOT use UDP port 53. This recommendation 310 against use of port 53 for DoQ is to avoid confusion between DoQ and 311 the use of DNS over UDP [RFC1035]. 313 In the stub to recursive scenario, the use of port 443 as a mutually 314 agreed alternative port can be operationally beneficial, since port 315 443 is less likely to be blocked than other ports. Several 316 mechanisms for stubs to discover recursives offering encrypted 317 transports, including the use of custom ports, are the subject of 318 ongoing work. 320 5.2. Stream Mapping and Usage 322 The mapping of DNS traffic over QUIC streams takes advantage of the 323 QUIC stream features detailed in Section 2 of [RFC9000], the QUIC 324 transport specification. 326 DNS traffic follows a simple pattern in which the client sends a 327 query, and the server provides one or more responses (multiple 328 responses can occur in zone transfers). 330 The mapping specified here requires that the client selects a 331 separate QUIC stream for each query. The server then uses the same 332 stream to provide all the response messages for that query. In order 333 that multiple responses can be parsed, a 2-octet length field is used 334 in exactly the same way as the 2-octet length field defined for DNS 335 over TCP [RFC1035]. The practical result of this is that the content 336 of each QUIC stream is exactly the same as the content of a TCP 337 connection that would manage exactly one query. 339 All DNS messages (queries and responses) sent over DoQ connections 340 MUST be encoded as a 2-octet length field followed by the message 341 content as specified in [RFC1035]. 343 The client MUST select the next available client-initiated 344 bidirectional stream for each subsequent query on a QUIC connection, 345 in conformance with the QUIC transport specification [RFC9000]. 347 The client MUST send the DNS query over the selected stream, and MUST 348 indicate through the STREAM FIN mechanism that no further data will 349 be sent on that stream. 351 The server MUST send the response(s) on the same stream and MUST 352 indicate, after the last response, through the STREAM FIN mechanism 353 that no further data will be sent on that stream. 355 Therefore, a single client initiated DNS transaction consumes a 356 single stream. This means that the client's first query occurs on 357 QUIC stream 0, the second on 4, and so on. 359 Servers MAY defer processing of a query until the STREAM FIN has been 360 indicated on the stream selected by the client. Servers and clients 361 MAY monitor the number of "dangling" streams for which the expected 362 queries or responses have been received but not the STREAM FIN. 363 Implementations MAY impose a limit on the number of such dangling 364 streams. If limits are encountered, implementations MAY close the 365 connection. 367 5.2.1. DNS Message IDs 369 When sending queries over a QUIC connection, the DNS Message ID MUST 370 be set to zero. The stream mapping for DoQ allows for unambiguous 371 correlation of queries and responses and so the Message ID field is 372 not required. 374 This has implications for proxying DoQ message to and from other 375 transports. For example, proxies may have to manage the fact that 376 DoQ can support a larger number of outstanding queries on a single 377 connection than e.g., DNS over TCP because DoQ is not limited by the 378 Message ID space. This issue already exists for DoH, where a Message 379 ID of 0 is recommended. 381 When forwarding a DNS message from DoQ over another transport, a DNS 382 Message ID MUST be generated according to the rules of the protocol 383 that is in use. When forwarding a DNS message from another transport 384 over DoQ, the Message ID MUST be set to zero. 386 5.3. DoQ Error Codes 388 The following error codes are defined for use when abruptly 389 terminating streams, aborting reading of streams, or immediately 390 closing connections: 392 DOQ_NO_ERROR (0x0): No error. This is used when the connection or 393 stream needs to be closed, but there is no error to signal. 395 DOQ_INTERNAL_ERROR (0x1): The DoQ implementation encountered an 396 internal error and is incapable of pursuing the transaction or the 397 connection. 399 DOQ_PROTOCOL_ERROR (0x2): The DoQ implementation encountered an 400 protocol error and is forcibly aborting the connection. 402 DOQ_REQUEST_CANCELLED (0x3): A DoQ client uses this to signal that 403 it wants to cancel an outstanding transaction. 405 DOQ_EXCESSIVE_LOAD (0x4): A DoQ implementation uses this to signal 406 when closing a connection due to excessive load. 408 DOQ_ERROR_RESERVED (0xd098ea5e): Alternative error code used for 409 tests. 411 See Section 10.4 for details on registering new error codes. 413 5.3.1. Transaction Cancellation 415 In QUIC, sending STOP_SENDING requests that a peer cease transmission 416 on a stream. If a DoQ client wishes to cancel an outstanding 417 request, it MUST issue a QUIC Stop Sending with error code 418 DOQ_REQUEST_CANCELLED. This may be sent at any time but will be 419 ignored if the server has already sent the response. The 420 corresponding DNS transaction MUST be abandoned. 422 Servers that receive STOP_SENDING act in accordance with Section 3.5 423 of [RFC9000]. Servers MAY impose implementation limits on the total 424 number or rate of request cancellations. If limits are encountered, 425 servers MAY close the connection. In this case, servers wanting to 426 help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD. 427 There is always a trade-off between helping good faith clients debug 428 issues and allowing denial-of-service attackers to test server 429 defenses, so depending on circumstances servers might very well chose 430 to send different error codes. 432 Note that this mechanism provides a way for secondaries to cancel a 433 single zone transfer occurring on a given stream without having to 434 close the QUIC connection. 436 5.3.2. Transaction Errors 438 Servers normally complete transactions by sending a DNS response (or 439 responses) on the transaction's stream, including cases where the DNS 440 response indicates a DNS error. For example, a Server Failure 441 (SERVFAIL, [RFC1035]) SHOULD be notified to the client by sending 442 back a response with the Response Code set to SERVFAIL. 444 If a server is incapable of sending a DNS response due to an internal 445 error, it SHOULD issue a QUIC Stream Reset. The error code SHOULD be 446 set to DOQ_INTERNAL_ERROR. The corresponding DNS transaction MUST be 447 abandoned. Clients MAY limit the number of unsolicited QUIC Stream 448 Resets received on a connection before choosing to close the 449 connection. 451 Note that this mechanism provides a way for primaries to abort a 452 single zone transfer occurring on a given stream without having to 453 close the QUIC connection. 455 5.3.3. Protocol Errors 457 Other error scenarios can occur due to malformed, incomplete or 458 unexpected messages during a transaction. These include (but are not 459 limited to) 461 * a client or server receives a message with a non-zero Message ID 463 * a client or server receives a STREAM FIN before receiving all the 464 bytes for a message indicated in the 2-octet length field 466 * a client receives a STREAM FIN before receiving all the expected 467 responses 469 * a server receives more than one query on a stream 470 * a client receives a different number of responses on a stream than 471 expected (e.g. multiple responses to a query for an A record) 473 * a client receives a STOP_SENDING request 475 * the client or server does not indicate the expected STREAM FIN 476 after sending requests or responses (see Section 5.2). 478 * an implementation receives a message containing the edns-tcp- 479 keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2) 481 * a client or a server attempts to open an unidirectional QUIC 482 stream 484 * a server attempts to open a server-initiated bidirectional QUIC 485 stream 487 If a peer encounters such an error condition it is considered a fatal 488 error. It SHOULD forcibly abort the connection using QUIC's 489 CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code 490 DOQ_PROTOCOL_ERROR. 492 It is noted that the restrictions on use of the above EDNS(0) options 493 has implications for proxying message from TCP/DoT/DoH over DoQ. 495 5.3.4. Alternative error codes 497 This specification suggests specific error codes Section 5.3.1, 498 Section 5.3.2, and Section 5.3.3. These error codes are meant to 499 facilitate investigation of failures and other incidents. New error 500 codes may be defined in future versions of DoQ, or registered as 501 specified in Section 10.4. 503 Because new error codes can be defined without negotiation, use of an 504 error code in an unexpected context or receipt of an unknown error 505 code MUST be treated as equivalent to DOQ_NO_ERROR. 507 Implementations MAY wish to test the support for the error code 508 extension mechanism by using error codes not listed in this document, 509 or they MAY use DOQ_ERROR_RESERVED. 511 5.4. Connection Management 513 Section 10 of [RFC9000], the QUIC transport specification, specifies 514 that connections can be closed in three ways: 516 * idle timeout 517 * immediate close 519 * stateless reset 521 Clients and servers implementing DoQ SHOULD negotiate use of the idle 522 timeout. Closing on idle timeout is done without any packet 523 exchange, which minimizes protocol overhead. Per Section 10.1 of 524 [RFC9000], the QUIC transport specification, the effective value of 525 the idle timeout is computed as the minimum of the values advertised 526 by the two endpoints. Practical considerations on setting the idle 527 timeout are discussed in Section 6.5.2. 529 Clients SHOULD monitor the idle time incurred on their connection to 530 the server, defined by the time spent since the last packet from the 531 server has been received. When a client prepares to send a new DNS 532 query to the server, it will check whether the idle time is 533 sufficient lower than the idle timer. If it is, the client will send 534 the DNS query over the existing connection. If not, the client will 535 establish a new connection and send the query over that connection. 537 Clients MAY discard their connections to the server before the idle 538 timeout expires. A client that has outstanding queries SHOULD close 539 the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and 540 the DoQ error code DOQ_NO_ERROR. 542 Clients and servers MAY close the connection for a variety of other 543 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers 544 that send packets over a connection discarded by their peer MAY 545 receive a stateless reset indication. If a connection fails, all the 546 in progress transaction on that connection MUST be abandoned. 548 5.5. Session Resumption and 0-RTT 550 A client MAY take advantage of the session resumption mechanisms 551 supported by QUIC transport [RFC9000] and QUIC TLS [RFC9001]. 552 Clients SHOULD consider potential privacy issues associated with 553 session resumption before deciding to use this mechanism. These 554 privacy issues are detailed in Section 9.2 and Section 9.1, and the 555 implementation considerations are discussed in Section 6.5.3. 557 The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are 558 not "replayable" transactions. In this specification, only 559 transactions that have an OPCODE of QUERY or NOTIFY are considered 560 replayable and MAY be sent in 0-RTT data. See Appendix A for a 561 detailed discussion of why NOTIFY is included here. 563 Servers MUST NOT execute non replayable transactions received in 564 0-RTT data. Servers MUST adopt one of the following behaviors: 566 * Queue the offending transaction and only execute it after the QUIC 567 handshake has been completed, as defined in Section 4.1.1 of 568 [RFC9001]. 570 * Reply to the offending transaction with a response code REFUSED 571 and an Extended DNS Error Code (EDE) "Too Early", see 572 Section 10.3. 574 * Close the connection with the error code DOQ_PROTOCOL_ERROR. 576 5.6. Message Sizes 578 DoQ Queries and Responses are sent on QUIC streams, which in theory 579 can carry up to 2^62 bytes. However, DNS messages are restricted in 580 practice to a maximum size of 65535 bytes. This maximum size is 581 enforced by the use of a two-octet message length field in DNS over 582 TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of 583 the "application/dns-message" for DNS over HTTP [RFC8484]. DoQ 584 enforces the same restriction. 586 The Extension Mechanisms for DNS (EDNS) [RFC6891] allow peers to 587 specify the UDP message size. This parameter is ignored by DoQ. DoQ 588 implementations always assume that the maximum message size is 65535 589 bytes. 591 6. Implementation Requirements 593 6.1. Authentication 595 For the stub to recursive resolver scenario, the authentication 596 requirements are the same as described in DoT [RFC7858] and "Usage 597 Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932] 598 states that DNS privacy services SHOULD provide credentials that 599 clients can use to authenticate the server. Given this, and to align 600 with the authentication model for DoH, DoQ stubs SHOULD use a Strict 601 authentication profile. Client authentication for the encrypted stub 602 to recursive scenario is not described in any DNS RFC. 604 For zone transfer, the requirements are the same as described in 605 [RFC9103]. 607 For the recursive resolver to authoritative nameserver scenario, 608 authentication requirements are unspecified at the time of writing 609 and are the subject on ongoing work in the DPRIVE WG. 611 6.2. Fallback to Other Protocols on Connection Failure 613 If the establishment of the DoQ connection fails, clients MAY attempt 614 to fall back to DoT and then potentially clear text, as specified in 615 DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS" 616 [RFC8310], depending on their privacy profile. 618 DNS clients SHOULD remember server IP addresses that don't support 619 DoQ. Timeouts, connection refusals, and QUIC handshake failures are 620 valid indicators that a server does not support DoQ. Clients SHOULD 621 NOT attempt DoQ queries to a server that does not support DoQ for a 622 reasonable period (such as one hour per server). DNS clients 623 following an out-of-band key-pinned privacy profile ([RFC7858]) MAY 624 be more aggressive about retrying DoQ connection failures. 626 6.3. Address Validation 628 Section 8 of [RFC9000], the QUIC transport specification, defines 629 Address Validation procedures to avoid servers being used in address 630 amplification attacks. DoQ implementations MUST conform to this 631 specification, which limits the worst case amplification to a factor 632 3. 634 DoQ implementations SHOULD consider configuring servers to use the 635 Address Validation using Retry Packets procedure defined in 636 Section 8.1.2 of [RFC9000], the QUIC transport specification. This 637 procedure imposes a 1-RTT delay for verifying the return routability 638 of the source address of a client, similar to the DNS Cookies 639 mechanism [RFC7873]. 641 DoQ implementations that configure Address Validation using Retry 642 Packets SHOULD implement the Address Validation for Future 643 Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC 644 transport specification. This defines how servers can send NEW_TOKEN 645 frames to clients after the client address is validated, in order to 646 avoid the 1-RTT penalty during subsequent connections by the client 647 from the same address. 649 6.4. Padding 651 Implementations SHOULD protect against the traffic analysis attacks 652 described in Section 9.5 by the judicious injection of padding. This 653 could be done either by padding individual DNS messages using the 654 EDNS(0) Padding Option [RFC7830] and by padding QUIC packets (see 655 Section 8.6 of [RFC9000], the QUIC transport specification. 657 In theory, padding at the QUIC level could result in better 658 performance for the equivalent protection, because the amount of 659 padding can take into account non-DNS frames such as acknowledgeemnts 660 or flow control updates, and also because QUIC packets can carry 661 multiple DNS messages. However, applications can only control the 662 amount of padding in QUIC packets if the implementation of QUIC 663 exposes adequate APIs. This leads to the following recommendation: 665 * if the implementation of QUIC exposes APIs to set a padding 666 policy, DNS over QUIC SHOULD use that API to align the packet 667 length to a small set of fixed sizes, aligned with the 668 recommendations of the "Padding Policies for Extension Mechanisms 669 for DNS (EDNS(0))" [RFC8467]. 671 * if padding at the QUIC level is not available or not used, DNS 672 over QUIC MUST ensure that all DNS queries and responses are 673 padded to a small set of fixed sizes, using the EDNS padding 674 extension as specified in "Padding Policies for Extension 675 Mechanisms for DNS (EDNS(0))" [RFC8467]. 677 6.5. Connection Handling 679 "DNS Transport over TCP - Implementation Requirements" [RFC7766] 680 provides updated guidance on DNS over TCP, some of which is 681 applicable to DoQ. This section provides similar advice on 682 connection handling for DoQ. 684 6.5.1. Connection Reuse 686 Historic implementations of DNS clients are known to open and close 687 TCP connections for each DNS query. To amortise connection setup 688 costs, both clients and servers SHOULD support connection reuse by 689 sending multiple queries and responses over a single persistent QUIC 690 connection. 692 In order to achieve performance on par with UDP, DNS clients SHOULD 693 send their queries concurrently over the QUIC streams on a QUIC 694 connection. That is, when a DNS client sends multiple queries to a 695 server over a QUIC connection, it SHOULD NOT wait for an outstanding 696 reply before sending the next query. 698 6.5.2. Resource Management 700 Proper management of established and idle connections is important to 701 the healthy operation of a DNS server. 703 An implementation of DoQ SHOULD follow best practices similar to 704 those specified for DNS over TCP [RFC7766], in particular with regard 705 to: 707 * Concurrent Connections (Section 6.2.2 of [RFC7766], updated by 708 Section 6.4 of [RFC9103]) 710 * Security Considerations (Section 10 of [RFC7766]) 712 Failure to do so may lead to resource exhaustion and denial of 713 service. 715 Clients that want to maintain long duration DoQ connections SHOULD 716 use the idle timeout mechanisms defined in Section 10.1 of [RFC9000], 717 the QUIC transport specification. Clients and servers MUST NOT send 718 the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent 719 on a DoQ connection (because it is specific to the use of TCP/TLS as 720 a transport). 722 This document does not make specific recommendations for timeout 723 values on idle connections. Clients and servers should reuse and/or 724 close connections depending on the level of available resources. 725 Timeouts may be longer during periods of low activity and shorter 726 during periods of high activity. 728 6.5.3. Using 0-RTT and Session Resumption 730 Using 0-RTT for DNS over QUIC has many compelling advantages. 731 Clients can establish connections and send queries without incurring 732 a connection delay. Servers can thus negotiate low values of the 733 connection timers, which reduces the total number of connections that 734 they need to manage. They can do that because the clients that use 735 0-RTT will not incur latency penalties if new connections are 736 required for a query. 738 Session resumption and 0-RTT data transmission create privacy risks 739 detailed in detailed in Section 9.2 and Section 9.1. The following 740 recommendations are meant to reduce the privacy risks while enjoying 741 the performance benefits of 0-RTT data, with the restriction 742 specified in Section 5.5. 744 Clients SHOULD use resumption tickets only once, as specified in 745 Appendix C.4 to [RFC8446]. By default, clients SHOULD NOT use 746 session resumption if the client's connectivity has changed. 748 Clients could receive address validation tokens from the server using 749 the NEW_TOKEN mechanism; see Section 8 of [RFC9000]. The associated 750 tracking risks are mentioned in Section 9.3. Clients SHOULD only use 751 the address validation tokens when they are also using session 752 resumption, thus avoiding additional tracking risks. 754 Servers SHOULD issue session resumption tickets with a sufficiently 755 long life time (e.g., 6 hours), so that clients are not tempted to 756 either keep connection alive or frequently poll the server to renew 757 session resumption tickets. Servers SHOULD implement the anti-replay 758 mechanisms specified in Section 8 of [RFC8446]. 760 6.5.4. Controlling Connection Migration For Privacy 762 DoQ implementation might consider using the connection migration 763 features defined in Section 9 of [RFC9000]. These features enable 764 connections to continue operating as the client's connectivity 765 changes. As detailed in Section 9.4, these features trade off 766 privacy for latency. By default, clients SHOULD be configured to 767 prioritise privacy and start new sessions if their connectivity 768 changes. 770 6.6. Processing Queries in Parallel 772 As specified in Section 7 of [RFC7766] "DNS Transport over TCP - 773 Implementation Requirements", resolvers are RECOMMENDED to support 774 the preparing of responses in parallel and sending them out of order. 775 In DoQ, they do that by sending responses on their specific stream as 776 soon as possible, without waiting for availability of responses for 777 previously opened streams. 779 6.7. Zone transfer 781 [RFC9103] specifies zone transfer over TLS (XoT) and includes updates 782 to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766]. Considerations 783 relating to the re-use of XoT connections described there apply 784 analogously to zone transfers performed using DoQ connections. For 785 example: 787 * DoQ servers MUST be able to handle multiple concurrent IXFR 788 requests on a single QUIC connection 790 * DoQ servers MUST be able to handle multiple concurrent AXFR 791 requests on a single QUIC connection 793 * DoQ implementations SHOULD 794 - use the same QUIC connection for both AXFR and IXFR requests to 795 the same primary 797 - pipeline such requests (if they pipeline XFR requests in 798 general) and MAY intermingle them 800 - send the response(s) for each request as soon as they are 801 available i.e. responses MAY be sent intermingled 803 6.8. Flow Control Mechanisms 805 Servers and Clients manage flow control using the mechanisms defined 806 in Section 4 of [RFC9000]. These mechanisms allow clients and 807 servers to specify how many streams can be created, how much data can 808 be sent on a stream, and how much data can be sent on the union of 809 all streams. For DNS over QUIC, controlling how many streams are 810 created allows servers to control how many new requests the client 811 can send on a given connection. 813 Flow control exists to protect endpoint resources. For servers, 814 global and per-stream flow control limits control how much data can 815 be sent by clients. The same mechanisms allow clients to control how 816 much data can be sent by servers. Values that are too small will 817 unnecessarily limit performance. Values that are too large might 818 expose endpoints to overload or memory exhaustion. Implementations 819 or deployments will need to adjust flow control limits to balance 820 these concerns. In particular, zone transfer implementations will 821 need to control these limits carefully to ensure both large and 822 concurrent zone transfers are well managed. 824 Initial values of parameters control how many requests and how much 825 data can be sent by clients and servers at the beginning of the 826 connection. These values are specified in transport parameters 827 exchanged during the connection handshake. The parameter values 828 received in the initial connection also control how many requests and 829 how much data can be sent by clients using 0-RTT data in a resumed 830 connection. Using too small values of these initial parameters would 831 restrict the usefulness of allowing 0-RTT data. 833 7. Implementation Status 835 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) This 836 section records the status of known implementations of the protocol 837 defined by this specification at the time of posting of this 838 Internet-Draft, and is based on a proposal described in [RFC7942]. 840 1. AdGuard launched a DoQ recursive resolver service in December 841 2020. They have released a suite of open source tools that 842 support DoQ: 844 1. AdGuard C++ DNS libraries (https://github.com/AdguardTeam/ 845 DnsLibs) A DNS proxy library that supports all existing DNS 846 protocols including DNS-over-TLS, DNS-over-HTTPS, DNSCrypt 847 and DNS-over-QUIC (experimental). 849 2. DNS Proxy (https://github.com/AdguardTeam/dnsproxy) A simple 850 DNS proxy server that supports all existing DNS protocols 851 including DNS-over-TLS, DNS-over-HTTPS, DNSCrypt, and DNS- 852 over-QUIC. Moreover, it can work as a DNS-over-HTTPS, DNS- 853 over-TLS or DNS-over-QUIC server. 855 3. CoreDNS fork for AdGuard DNS (https://github.com/AdguardTeam/ 856 coredns) Includes DNS-over-QUIC server-side support. 858 4. dnslookup (https://github.com/ameshkov/dnslookup) Simple 859 command line utility to make DNS lookups. Supports all known 860 DNS protocols: plain DNS, DoH, DoT, DoQ, DNSCrypt. 862 2. Quicdoq (https://github.com/private-octopus/quicdoq) Quicdoq is a 863 simple open source implementation of DoQ. It is written in C, 864 based on Picoquic (https://github.com/private-octopus/picoquic). 866 3. Flamethrower (https://github.com/DNS-OARC/flamethrower/tree/dns- 867 over-quic) is an open source DNS performance and functional 868 testing utility written in C++ that has an experimental 869 implementation of DoQ. 871 4. aioquic (https://github.com/aiortc/aioquic) is an implementation 872 of QUIC in Python. It includes example client and server for 873 DoQ. 875 7.1. Performance Measurements 877 To our knowledge, no benchmarking studies comparing DoT, DoH and DoQ 878 are published yet. However anecdotal evidence from the AdGuard DoQ 879 recursive resolver deployment (https://adguard.com/en/blog/dns-over- 880 quic.html) indicates that it performs well compared to the other 881 encrypted protocols, particularly in mobile environments. Reasons 882 given for this include that DoQ 884 * Uses less bandwidth due to a more efficient handshake (and due to 885 less per message overhead when compared to DoH). 887 * Performs better in mobile environments due to the increased 888 resilience to packet loss 890 * Can maintain connections as users move between mobile networks via 891 its connection management 893 8. Security Considerations 895 The security considerations of DoQ should be comparable to those of 896 DoT [RFC7858]. 898 9. Privacy Considerations 900 The general considerations of encrypted transports provided in "DNS 901 Privacy Considerations" [RFC9076] apply to DoQ. The specific 902 considerations provided there do not differ between DoT and DoQ, and 903 are not discussed further here. Similarly, "Recommendations for DNS 904 Privacy Service Operators" [RFC8932] (which covers operational, 905 policy, and security considerations for DNS privacy services) is also 906 applicable to DoQ services. 908 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this 909 enables QUIC transmission of "0-RTT" data. This can provide 910 interesting latency gains, but it raises two concerns: 912 1. Adversaries could replay the 0-RTT data and infer its content 913 from the behavior of the receiving server. 915 2. The 0-RTT mechanism relies on TLS session resumption, which can 916 provide linkability between successive client sessions. 918 These issues are developed in Section 9.1 and Section 9.2. 920 9.1. Privacy Issues With 0-RTT data 922 The 0-RTT data can be replayed by adversaries. That data may trigger 923 queries by a recursive resolver to authoritative resolvers. 924 Adversaries may be able to pick a time at which the recursive 925 resolver outgoing traffic is observable, and thus find out what name 926 was queried for in the 0-RTT data. 928 This risk is in fact a subset of the general problem of observing the 929 behavior of the recursive resolver discussed in "DNS Privacy 930 Considerations" [RFC9076]. The attack is partially mitigated by 931 reducing the observability of this traffic. The mandatory replay 932 protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate 933 the risk of replay. 0-RTT packets can only be replayed within a 934 narrow window, which is only wide enough to account for variations in 935 clock skew and network transmission. 937 The recommendation for TLS 1.3 [RFC8446] is that the capability to 938 use 0-RTT data should be turned off by default, and only enabled if 939 the user clearly understands the associated risks. In our case, 940 allowing 0-RTT data provides significant performance gains, and we 941 are concerned that a recommendation to not use it would simply be 942 ignored. Instead, we provide a set of practical recommendations in 943 Section 5.5 and Section 6.5.3. 945 The prevention on allowing replayable transactions in 0-RTT data 946 expressed in Section 5.5 blocks the most obvious risks of replay 947 attacks, as it only allows for transactions that will not change the 948 long term state of the server. 950 The attacks described above apply to the stub resolver to recursive 951 resolver scenario, but similar attacks might be envisaged in the 952 recursive resolver to authoritative resolver scenario, and the same 953 mitigations apply. 955 9.2. Privacy Issues With Session Resumption 957 The QUIC session resumption mechanism reduces the cost of re- 958 establishing sessions and enables 0-RTT data. There is a linkability 959 issue associated with session resumption, if the same resumption 960 token is used several times. Attackers on path between client and 961 server could observe repeated usage of the token and use that to 962 track the client over time or over multiple locations. 964 The session resumption mechanism allows servers to correlate the 965 resumed sessions with the initial sessions, and thus to track the 966 client. This creates a virtual long duration session. The series of 967 queries in that session can be used by the server to identify the 968 client. Servers can most probably do that already if the client 969 address remains constant, but session resumption tickets also enable 970 tracking after changes of the client's address. 972 The recommendations in Section 6.5.3 are designed to mitigate these 973 risks. Using session tickets only once mitigates the risk of 974 tracking by third parties. Refusing to resume a session if addresses 975 change mitigates the risk of tracking by the server. 977 The privacy trade-offs here may be context specific. Stub resolvers 978 will have a strong motivation to prefer privacy over latency since 979 they often change location. However, recursive resolvers that use a 980 small set of static IP addresses are more likely to prefer the 981 reduced latency provided by session resumption and may consider this 982 a valid reason to use resumption tickets even if the IP address 983 changed between sessions. 985 Encrypted zone transfer (RFC9103) explicitly does not attempt to hide 986 the identity of the parties involved in the transfer, but at the same 987 time such transfers are not particularly latency sensitive. This 988 means that applications supporting zone transfers may decide to apply 989 the same protections as stub to recursive applications. 991 9.3. Privacy Issues With Address Validation Tokens 993 QUIC specifies address validation mechanisms in Section 8 of 994 [RFC9000]. Use of an address validation token allows QUIC servers to 995 avoid an extra RTT for new connections. Address validation tokens 996 are typically tied to an IP address. QUIC clients normally only use 997 these tokens when setting a new connection from a previously used 998 address. However, due to the prevalence of NAT, clients are not 999 always aware that they are using a new address. There is a 1000 linkability risk if clients mistakenly use address validation tokens 1001 after unknowingly moving to a new location. 1003 The recommendations in Section 6.5.3 mitigates this risk by tying the 1004 usage of the NEW_TOKEN to that of session resumption. 1006 9.4. Privacy Issues With Long Duration Sessions 1008 A potential alternative to session resumption is the use of long 1009 duration sessions: if a session remains open for a long time, new 1010 queries can be sent without incurring connection establishment 1011 delays. It is worth pointing out that the two solutions have similar 1012 privacy characteristics. Session resumption may allow servers to 1013 keep track of the IP addresses of clients, but long duration sessions 1014 have the same effect. 1016 In particular, a DoQ implementation might take advantage of the 1017 connection migration features of QUIC to maintain a session even if 1018 the client's connectivity changes, for example if the client migrates 1019 from a Wi-Fi connection to a cellular network connection, and then to 1020 another Wi-Fi connection. The server would be able to track the 1021 client location by monitoring the succession of IP addresses used by 1022 the long duration connection. 1024 The recommendation in Section 6.5.4 mitigates the privacy concerns 1025 related to long duration sessions using multiple client addresses. 1027 9.5. Traffic Analysis 1029 Even though QUIC packets are encrypted, adversaries can gain 1030 information from observing packet lengths, in both queries and 1031 responses, as well as packet timing. Many DNS requests are emitted 1032 by web browsers. Loading a specific web page may require resolving 1033 dozen of DNS names. If an application adopts a simple mapping of one 1034 query or response per packet, or "one QUIC STREAM frame per packet", 1035 then the succession of packet lengths may provide enough information 1036 to identify the requested site. 1038 Implementations SHOULD use the mechanisms defined in Section 6.4 to 1039 mitigate this attack. 1041 10. IANA Considerations 1043 10.1. Registration of DoQ Identification String 1045 This document creates a new registration for the identification of 1046 DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol 1047 IDs" registry [RFC7301]. 1049 The "doq" string identifies DoQ: 1051 Protocol: DoQ 1053 Identification Sequence: 0x64 0x6F 0x71 ("doq") 1055 Specification: This document 1057 10.2. Reservation of Dedicated Port 1059 Port 853 is currently reserved for 'DNS query-response protocol run 1060 over TLS/DTLS' [RFC7858]. However, the specification for DNS over 1061 DTLS (DoD) [RFC8094] is experimental, limited to stub to resolver, 1062 and no implementations or deployments currently exist to our 1063 knowledge (even though several years have passed since the 1064 specification was published). 1066 This specification proposes to additionally reserve the use of port 1067 853 for DoQ. QUIC was designed to be able to co-exist with other 1068 protocols on the same port, including DTLS , see Section 17.2 of 1069 [RFC9000]. 1071 IANA is requested to add the following value to the "Service Name and 1072 Transport Protocol Port Number Registry" in the System Range. The 1073 registry for that range requires IETF Review or IESG Approval 1074 [RFC6335]. 1076 Service Name: dns-over-quic 1078 Port Number: 853 1080 Transport Protocol(s): UDP 1082 Assignee: IESG 1084 Contact: IETF Chair 1086 Description: DNS query-response protocol run over QUIC 1088 Reference: This document 1090 10.2.1. Port number 784 for experimentations 1092 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) 1093 Early experiments MAY use port 784. This port is marked in the IANA 1094 registry as unassigned. 1096 (Note that version in -02 of this draft experiments were directed to 1097 use port 8853.) 1099 10.3. Reservation of Extended DNS Error Code Too Early 1101 IANA is requested to add the following value to the Extended DNS 1102 Error Codes registry [RFC8914]: 1104 INFO-CODE: TBD 1106 Purpose: Too Early 1108 Reference: This document 1110 10.4. DNS over QUIC Error Codes Registry 1112 IANA [SHALL add/has added] a registry for "DNS over QUIC Error Codes" 1113 on the "Domain Name System (DNS) Parameters" web page. 1115 The "DNS over QUIC Error Codes" registry governs a 62-bit space. 1116 This space is split into three regions that are governed by different 1117 policies: 1119 * Permanent registrations for values between 0x00 and 0x3f (in 1120 hexadecimal; inclusive), which are assigned using Standards Action 1121 or IESG Approval as defined in Section 4.9 and Section 4.10 of 1122 [RFC8126] 1124 * Permanent registrations for values larger than 0x3f, which are 1125 assigned using the Specification Required policy ([RFC8126]) 1127 * Provisonal registrations for values larger than 0x3f, which 1128 require Expert Review, as defined in Section 4.5 of [RFC8126]. 1130 Provisional reservations share the range of values larger than 0x3f 1131 with some permanent registrations. This is by design, to enable 1132 conversion of provisional registrations into permanent registrations 1133 without requiring changes in deployed systems. (This design is 1134 aligned with the principles set in Section 22 of [RFC9000].) 1136 Registrations in this registry MUST include the following fields: 1138 Value: The assigned codepoint. 1140 Status: "Permanent" or "Provisional". 1142 Contact: Contact details for the registrant. 1144 Notes: Supplementary notes about the registration. 1146 In addition, permanent registrations MUST include: 1148 Error: A short mnemonic for the parameter. 1150 Specification: A reference to a publicly available specification for 1151 the value (optional for provisional registrations). 1153 Description: A brief description of the error code semantics, which 1154 MAY be a summary if a specification reference is provided. 1156 Provisional registrations of codepoints are intended to allow for 1157 private use and experimentation with extensions to DNS over QUIC. 1158 However, provisional registrations could be reclaimed and reassigned 1159 for another purpose. In addition to the parameters listed above, 1160 provisional registrations MUST include: 1162 Date: The date of last update to the registration. 1164 A request to update the date on any provisional registration can be 1165 made without review from the designated expert(s). 1167 The initial contents of this registry are shown in Table 1. 1169 +==========+=======================+================+===============+ 1170 |Value | Error |Description | Specification | 1171 +==========+=======================+================+===============+ 1172 |0x0 | DOQ_NO_ERROR |No error | Section 5.3 | 1173 +----------+-----------------------+----------------+---------------+ 1174 |0x1 | DOQ_INTERNAL_ERROR |Implementation | Section 5.3 | 1175 | | |error | | 1176 +----------+-----------------------+----------------+---------------+ 1177 |0x2 | DOQ_PROTOCOL_ERROR |Generic protocol| Section 5.3 | 1178 | | |violation | | 1179 +----------+-----------------------+----------------+---------------+ 1180 |0x3 | DOQ_REQUEST_CANCELLED |Request | Section 5.3 | 1181 | | |cancelled by | | 1182 | | |client | | 1183 +----------+-----------------------+----------------+---------------+ 1184 |0x4 | DOQ_EXCESSIVE_LOAD |Closing a | Section 5.3 | 1185 | | |connection for | | 1186 | | |excessive load | | 1187 +----------+-----------------------+----------------+---------------+ 1188 |0xd098ea5e| DOQ_ERROR_RESERVED |Alternative | Section 5.3 | 1189 | | |error code used | | 1190 | | |for tests | | 1191 +----------+-----------------------+----------------+---------------+ 1193 Table 1: Initial DNS over QUIC Error Codes Entries 1195 11. Acknowledgements 1197 This document liberally borrows text from the HTTP-3 specification 1198 [I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT 1199 specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, 1200 Allison Mankin, Duane Wessels, and Paul Hoffman. 1202 The privacy issue with 0-RTT data and session resumption were 1203 analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF 1204 "DPRIVE" working group [DNS0RTT]. 1206 Thanks to Tony Finch for an extensive review of the initial version 1207 of this draft, and to Robert Evans for the discussion of 0-RTT 1208 privacy issues. Reviews by Paul Hoffman and Martin Thomson and 1209 interoperability tests conducted by Stephane Bortzmeyer helped 1210 improve the definition of the protocol. 1212 12. References 1214 12.1. Normative References 1216 [I-D.ietf-dnsop-rfc8499bis] 1217 Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in 1218 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03, 1219 28 September 2021, . 1222 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1223 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1224 . 1226 [RFC1035] Mockapetris, P., "Domain names - implementation and 1227 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1228 November 1987, . 1230 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1231 DOI 10.17487/RFC1995, August 1996, 1232 . 1234 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1235 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1236 . 1238 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1239 for DNS (EDNS(0))", STD 75, RFC 6891, 1240 DOI 10.17487/RFC6891, April 2013, 1241 . 1243 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1244 "Transport Layer Security (TLS) Application-Layer Protocol 1245 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1246 July 2014, . 1248 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1249 D. Wessels, "DNS Transport over TCP - Implementation 1250 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1251 . 1253 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1254 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1255 DOI 10.17487/RFC7828, April 2016, 1256 . 1258 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1259 DOI 10.17487/RFC7830, May 2016, 1260 . 1262 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1263 and P. Hoffman, "Specification for DNS over Transport 1264 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1265 2016, . 1267 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1268 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1269 . 1271 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1272 Transport Layer Security (DTLS)", RFC 8094, 1273 DOI 10.17487/RFC8094, February 2017, 1274 . 1276 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1277 Writing an IANA Considerations Section in RFCs", BCP 26, 1278 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1279 . 1281 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1282 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1283 May 2017, . 1285 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1286 for DNS over TLS and DNS over DTLS", RFC 8310, 1287 DOI 10.17487/RFC8310, March 2018, 1288 . 1290 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1291 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1292 October 2018, . 1294 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1295 Lawrence, "Extended DNS Errors", RFC 8914, 1296 DOI 10.17487/RFC8914, October 2020, 1297 . 1299 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1300 Multiplexed and Secure Transport", RFC 9000, 1301 DOI 10.17487/RFC9000, May 2021, 1302 . 1304 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1305 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1306 . 1308 [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 1309 Mankin, "DNS Zone Transfer over TLS", RFC 9103, 1310 DOI 10.17487/RFC9103, August 2021, 1311 . 1313 12.2. Informative References 1315 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG 1316 mailing list, 6 April 2016, . 1319 [I-D.ietf-quic-http] 1320 Bishop, M., "Hypertext Transfer Protocol Version 3 1321 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1322 quic-http-34, 2 February 2021, 1323 . 1326 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1327 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1328 August 1996, . 1330 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1331 Cheshire, "Internet Assigned Numbers Authority (IANA) 1332 Procedures for the Management of the Service Name and 1333 Transport Protocol Port Number Registry", BCP 165, 1334 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1335 . 1337 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1338 Code: The Implementation Status Section", BCP 205, 1339 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1340 . 1342 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1343 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1344 . 1346 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1347 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1348 . 1350 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1351 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1352 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1353 . 1355 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 1356 A. Mankin, "Recommendations for DNS Privacy Service 1357 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, 1358 October 2020, . 1360 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1361 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 1362 May 2021, . 1364 [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, 1365 DOI 10.17487/RFC9076, July 2021, 1366 . 1368 Appendix A. The NOTIFY Service 1370 This appendix discusses why it is considered acceptable to send 1371 NOTIFY (see [RFC1996]) in 0-RTT data. 1373 Section 5.5 says "The 0-RTT mechanism SHOULD NOT be used to send DNS 1374 requests that are not "replayable" transactions". This specification 1375 supports sending a NOTIFY in 0-RTT data because although a NOTIFY 1376 technically changes the state of the receiving server, the effect of 1377 replaying NOTIFYs has negligible impact in practice. 1379 NOTIFY messages prompt a secondary to either send an SOA query or an 1380 XFR request to the primary on the basis that a newer version of the 1381 zone is available. It has long been recognized that NOTIFYs can be 1382 forged and, in theory, used to cause a secondary to send repeated 1383 unnecessary requests to the primary. For this reason, most 1384 implementations have some form of throttling of the SOA/XFR queries 1385 triggered by the receipt of one or more NOTIFYs. 1387 [RFC9103] describes the privacy risks associated with both NOTIFY and 1388 SOA queries and does not include addressing those risks within the 1389 scope of encrypting zone transfers. Given this, the privacy benefit 1390 of using DoQ for NOTIFY is not clear - but for the same reason, 1391 sending NOTIFY as 0-RTT data has no privacy risk above that of 1392 sending it using cleartext DNS. 1394 Appendix B. Notable Changes From Previous Versions 1396 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) 1398 B.1. Stream Mapping Incompatibility With Draft-02 1400 Versions prior to -02 of this specification proposed a simpler 1401 mapping scheme of queries and responses to QUIc stream, which omitted 1402 the 2 byte length field and supported only a single response on a 1403 given stream. The more complex mapping in Section 5.2 was adopted to 1404 specifically cater for XFR support, however it breaks compatibility 1405 with earlier versions. 1407 Authors' Addresses 1409 Christian Huitema 1410 Private Octopus Inc. 1411 427 Golfcourse Rd 1412 Friday Harbor, WA 98250 1413 United States of America 1415 Email: huitema@huitema.net 1417 Sara Dickinson 1418 Sinodun IT 1419 Oxford Science Park 1420 Oxford 1421 OX4 4GA 1422 United Kingdom 1424 Email: sara@sinodun.com 1426 Allison Mankin 1427 Salesforce 1429 Email: allison.mankin@gmail.com