idnits 2.17.00 (12 Aug 2021) /tmp/idnits40162/draft-ietf-dprive-dnsoquic-05.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 (11 October 2021) is 221 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: 14 April 2022 Sinodun IT 6 A. Mankin 7 Salesforce 8 11 October 2021 10 DNS over Dedicated QUIC Connections 11 draft-ietf-dprive-dnsoquic-05 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 error corrections 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 14 April 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 Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Document work via GitHub . . . . . . . . . . . . . . . . . . 4 59 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5 61 4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5 62 4.3. No Specific Middlebox Bypass Mechanism . . . . . . . . . 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 8 71 5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9 72 5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 9 73 5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10 74 5.4. Connection Management . . . . . . . . . . . . . . . . . . 10 75 5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 11 76 5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 12 77 6. Implementation Requirements . . . . . . . . . . . . . . . . . 12 78 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 12 79 6.2. Fall Back to Other Protocols on Connection Failure . . . 13 80 6.3. Address Validation . . . . . . . . . . . . . . . . . . . 13 81 6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 14 83 6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 14 84 6.5.2. Resource Management and Idle Timeout Values . . . . . 14 85 6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 15 86 6.6. Processing Queries in Parallel . . . . . . . . . . . . . 16 87 6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 16 88 6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 16 89 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 90 7.1. Performance Measurements . . . . . . . . . . . . . . . . 18 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 93 9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 19 94 9.2. Privacy Issues With Session Resumption . . . . . . . . . 20 95 9.3. Privacy Issues With New Tokens . . . . . . . . . . . . . 20 96 9.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 21 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 10.1. Registration of DoQ Identification String . . . . . . . 21 100 10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 21 101 10.2.1. Port number 784 for experimentations . . . . . . . . 22 102 10.3. Reservation of Extended DNS Error Code Too Early . . . . 22 103 10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 22 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 107 12.2. Informative References . . . . . . . . . . . . . . . . . 26 108 Appendix A. The NOTIFY service . . . . . . . . . . . . . . . . . 28 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 111 1. Introduction 113 Domain Name System (DNS) concepts are specified in "Domain names - 114 concepts and facilities" [RFC1034]. The transmission of DNS queries 115 and responses over UDP and TCP is specified in "Domain names - 116 implementation and specification" [RFC1035]. This document presents 117 a mapping of the DNS protocol over the QUIC transport [RFC9000] 118 [RFC9001]. DNS over QUIC is referred here as DoQ, in line with "DNS 119 Terminology" [I-D.ietf-dnsop-rfc8499bis]. The goals of the DoQ 120 mapping are: 122 1. Provide the same DNS privacy protection as DNS over TLS (DoT) 123 [RFC7858]. This includes an option for the client to 124 authenticate the server by means of an authentication domain name 125 as specified in "Usage Profiles for DNS over TLS and DNS over 126 DTLS" [RFC8310]. 128 2. Provide an improved level of source address validation for DNS 129 servers compared to classic DNS over UDP. 131 3. Provide a transport that is not constrained by path MTU 132 limitations on the size of DNS responses it can send. 134 4. Explore the characteristics of using QUIC as a DNS transport, 135 versus other solutions like DNS over UDP [RFC1035], DNS over TLS 136 (DoT) [RFC7858], or DNS over HTTPS (DoH) [RFC8484]. 138 In order to achieve these goals, and to support ongoing work on 139 encryption of DNS, the scope of this document includes 141 * the "stub to recursive resolver" scenario 143 * the "recursive resolver to authoritative nameserver" scenario and 144 * the "nameserver to nameserver" scenario (mainly used for zone 145 transfers (XFR) [RFC1995], [RFC5936]). 147 In other words, this document is intended to specify QUIC as a 148 general purpose transport for DNS. 150 The specific non-goals of this document are: 152 1. No attempt is made to evade potential blocking of DNS over QUIC 153 traffic by middleboxes. 155 2. No attempt to support server initiated transactions, which are 156 used only in DNS Stateful Operations (DSO) [RFC8490]. 158 Specifying the transmission of an application over QUIC requires 159 specifying how the application's messages are mapped to QUIC streams, 160 and generally how the application will use QUIC. This is done for 161 HTTP in "Hypertext Transfer Protocol Version 3 162 (HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to 163 define the way DNS messages can be transmitted over QUIC. 165 In this document, Section 4 presents the reasoning that guided the 166 proposed design. Section 5 specifies the actual mapping of DoQ. 167 Section 6 presents guidelines on the implementation, usage and 168 deployment of DoQ. 170 2. Key Words 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in BCP 14 [RFC8174]. 176 3. Document work via GitHub 178 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The 179 Github repository for this document is at https://github.com/huitema/ 180 dnsoquic. Proposed text and editorial changes are very much welcomed 181 there, but any functional changes should always first be discussed on 182 the IETF DPRIVE WG (dns-privacy) mailing list. 184 4. Design Considerations 186 This section and its subsections present the design guidelines that 187 were used for DoQ. This section is informative in nature. 189 4.1. Provide DNS Privacy 191 DoT [RFC7858] defines how to mitigate some of the issues described in 192 "DNS Privacy Considerations" [RFC9076] by specifying how to transmit 193 DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS 194 over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles 195 for DoT including how stub resolvers can authenticate recursive 196 resolvers. 198 QUIC connection setup includes the negotiation of security parameters 199 using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001], 200 enabling encryption of the QUIC transport. Transmitting DNS messages 201 over QUIC will provide essentially the same privacy protections as 202 DoT [RFC7858] including Strict and Opportunistic Usage Profiles 203 [RFC8310]. Further discussion on this is provided in Section 9. 205 4.2. Design for Minimum Latency 207 QUIC is specifically designed to reduce the delay between HTTP 208 queries and HTTP responses. This is achieved through three main 209 components: 211 1. Support for 0-RTT data during session resumption. 213 2. Support for advanced error recovery procedures as specified in 214 "QUIC Loss Detection and Congestion Control" [RFC9002]. 216 3. Mitigation of head-of-line blocking by allowing parallel delivery 217 of data on multiple streams. 219 This mapping of DNS to QUIC will take advantage of these features in 220 three ways: 222 1. Optional support for sending 0-RTT data during session resumption 223 (the security and privacy implications of this are discussed in 224 later sections). 226 2. Long-lived QUIC connections over which multiple DNS transactions 227 are performed, generating the sustained traffic required to 228 benefit from advanced recovery features. 230 3. Fast resumption of QUIC connections to manage the disconnect-on- 231 idle feature of QUIC without incurring retransmission time-outs. 233 4. Mapping of each DNS Query/Response transaction to a separate 234 stream, to mitigate head-of-line blocking. This enables servers 235 to respond to queries "out of order". It also enables clients to 236 process responses as soon as they arrive, without having to wait 237 for in order delivery of responses previously posted by the 238 server. 240 These considerations will be reflected in the mapping of DNS traffic 241 to QUIC streams in Section 5.2. 243 4.3. No Specific Middlebox Bypass Mechanism 245 The mapping of DoQ is defined for minimal overhead and maximum 246 performance. This means a different traffic profile than HTTP3 over 247 QUIC. This difference can be noted by firewalls and middleboxes. 248 There may be environments in which HTTP3 over QUIC will be able to 249 pass through, but DoQ will be blocked by these middle boxes. 251 4.4. No Server Initiated Transactions 253 As stated in Section 1, this document does not specify support for 254 server initiated transactions within established DoQ connections. 255 That is, only the initiator of the DoQ connection may send queries 256 over the connection. 258 DSO supports server-initiated transactions within existing 259 connections, however DSO is not applicable to DNS over HTTP since 260 HTTP has its own mechanism for managing sessions, and this is 261 incompatible with the DSO; the same is true for DoQ. 263 5. Specifications 265 5.1. Connection Establishment 267 DoQ connections are established as described in the QUIC transport 268 specification [RFC9000]. During connection establishment, DoQ 269 support is indicated by selecting the ALPN token "doq" in the crypto 270 handshake. 272 5.1.1. Draft Version Identification 274 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only 275 implementations of the final, published RFC can identify themselves 276 as "doq". Until such an RFC exists, implementations MUST NOT 277 identify themselves using this string. 279 Implementations of draft versions of the protocol MUST add the string 280 "-" and the corresponding draft number to the identifier. For 281 example, draft-ietf-dprive-dnsoquic-00 is identified using the string 282 "doq-i00". 284 5.1.2. Port Selection 286 By default, a DNS server that supports DoQ MUST listen for and accept 287 QUIC connections on the dedicated UDP port TBD (number to be defined 288 in Section 10), unless it has mutual agreement with its clients to 289 use a port other than TBD for DoQ. In order to use a port other than 290 TBD, both clients and servers would need a configuration option in 291 their software. 293 By default, a DNS client desiring to use DoQ with a particular server 294 MUST establish a QUIC connection to UDP port TBD on the server, 295 unless it has mutual agreement with its server to use a port other 296 than port TBD for DoQ. Such another port MUST NOT be port 53. This 297 recommendation against use of port 53 for DoQ is to avoid confusion 298 between DoQ and the use of DNS over UDP [RFC1035]. 300 In the stub to recursive scenario, the use of port 443 as a mutually 301 agreed alternative port can be operationally beneficial, since port 302 443 is less likely to be blocked than other ports. Several 303 mechanisms for stubs to discover recursives offering encrypted 304 transports, including the use of custom ports, are the subject of 305 work in the ADD working group. 307 5.2. Stream Mapping and Usage 309 The mapping of DNS traffic over QUIC streams takes advantage of the 310 QUIC stream features detailed in Section 2 of the QUIC transport 311 specification [RFC9000]. 313 DNS traffic follows a simple pattern in which the client sends a 314 query, and the server provides one or more responses (multiple can 315 responses occur in zone transfers). 317 The mapping specified here requires that the client selects a 318 separate QUIC stream for each query. The server then uses the same 319 stream to provide all the response messages for that query. In order 320 that multiple responses can be parsed, a 2-octet length field is used 321 in exactly the same way as the 2-octet length field defined for DNS 322 over TCP [RFC1035]. The practical result of this is that the content 323 of each QUIC stream is exactly the same as the content of a TCP 324 connection that would manage exactly one query. 326 All DNS messages (queries and responses) sent over DoQ connections 327 MUST be encoded as a 2-octet length field followed by the message 328 content as specified in [RFC1035]. 330 The client MUST select the next available client-initiated 331 bidirectional stream for each subsequent query on a QUIC connection, 332 in conformance with the QUIC transport specification [RFC9000]. 334 The client MUST send the DNS query over the selected stream, and MUST 335 indicate through the STREAM FIN mechanism that no further data will 336 be sent on that stream. 338 The server MUST send the response(s) on the same stream and MUST 339 indicate, after the last response, through the STREAM FIN mechanism 340 that no further data will be sent on that stream. 342 Therefore, a single client initiated DNS transaction consumes a 343 single stream. This means that the client's first query occurs on 344 QUIC stream 0, the second on 4, and so on. 346 For completeness it is noted that versions prior to -02 of this 347 specification proposed a simpler mapping scheme which omitted the 2 348 byte length field and supported only a single response on a given 349 stream. The more complex mapping above was adopted to specifically 350 cater for XFR support, however it breaks compatibility with earlier 351 versions. 353 5.2.1. DNS Message IDs 355 When sending queries over a QUIC connection, the DNS Message ID MUST 356 be set to zero. 358 It is noted that this has implications for proxying DoQ message to 359 other transports in that a mapping of some form must be performed 360 (e.g., from DoQ connection/stream to unique Message ID). 362 5.3. DoQ Error Codes 364 The following error codes are defined for use when abruptly 365 terminating streams, aborting reading of streams, or immediately 366 closing connections: 368 DOQ_NO_ERROR (0x00): No error. This is used when the connection or 369 stream needs to be closed, but there is no error to signal. 371 DOQ_INTERNAL_ERROR (0x01): The DoQ implementation encountered an 372 internal error and is incapable of pursuing the transaction or the 373 connection. 375 DOQ_PROTOCOL_ERROR (0x02): The DoQ implementation encountered an 376 protocol error and is forcibly aborting the connection. 378 DOQ_REQUEST_CANCELLED (0x03): A DoQ client uses this to signal that 379 it wants to cancel an outstanding transaction. 381 See Section 10.4 for details on registering new error codes. 383 5.3.1. Transaction Cancellation 385 In QUIC, sending STOP_SENDING requests that a peer cease transmission 386 on a stream. If a DoQ client wishes to cancel an outstanding 387 request, it MUST issue a QUIC Stop Sending with error code 388 DOQ_REQUEST_CANCELLED. This may be sent at any time but will be 389 ignored if the server has already sent the response. The 390 corresponding DNS transaction MUST be abandoned. 392 A server that receives STOP_SENDING MUST issue a RESET_STREAM with 393 error code DOQ_REQUEST_CANCELLED, unless it has already sent a 394 complete response in which case it MAY ignore the STOP_SENDING 395 request. Servers MAY limit the number of DOQ_REQUEST_CANCELLED 396 errors received on a connection before choosing to close the 397 connection. 399 Note that this mechanism provides a way for secondaries to cancel a 400 single zone transfer occurring on a given stream without having to 401 close the QUIC connection. 403 5.3.2. Transaction Errors 405 Servers normally complete transactions by sending a DNS response (or 406 responses) on the transaction's stream, including cases where the DNS 407 response indicates a DNS error. For example, a Server Failure 408 (SERVFAIL, [RFC1035]) SHOULD be notified to the client by sending 409 back a response with the Response Code set to SERVFAIL. 411 If a server is incapable of sending a DNS response due to an internal 412 error, it SHOULD issue a QUIC Stream Reset with error code 413 DOQ_INTERNAL_ERROR. The corresponding DNS transaction MUST be 414 abandoned. Clients MAY limit the number of unsolicited QUIC Stream 415 Resets received on a connection before choosing to close the 416 connection. 418 Note that this mechanism provides a way for primaries to abort a 419 single zone transfer occurring on a given stream without having to 420 close the QUIC connection. 422 5.3.3. Protocol Errors 424 Other error scenarios can occur due to malformed, incomplete or 425 unexpected messages during a transaction. These include (but are not 426 limited to) 428 * a client or server receives a message with a non-zero Message ID 430 * a client or server receives a STREAM FIN before receiving all the 431 bytes for a message indicated in the 2-octet length field 433 * a client receives a STREAM FIN before receiving all the expected 434 responses 436 * a server receives more than one query on a stream 438 * a client receives a different number of responses on a stream than 439 expected (e.g. multiple responses to a query for an A record) 441 * a client receives a STOP_SENDING request 443 * an implementation receives a message containing the edns-tcp- 444 keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2) 446 If a peer encounters such an error condition it is considered a fatal 447 error. It SHOULD forcibly abort the connection using QUIC's 448 CONNECTION_CLOSE mechanism, and use the DoQ error code 449 DOQ_PROTCOL_ERROR. 451 It is noted that the restrictions on use of the above EDNS(0) options 452 has implications for proxying message from TCP/DoT/DoH over DoQ. 454 5.4. Connection Management 456 Section 10 of the QUIC transport specification [RFC9000] specifies 457 that connections can be closed in three ways: 459 * idle timeout 461 * immediate close 463 * stateless reset 464 Clients and servers implementing DoQ SHOULD negotiate use of the idle 465 timeout. Closing on idle timeout is done without any packet 466 exchange, which minimizes protocol overhead. Per section 10.1 of the 467 QUIC transport specification, the effective value of the idle timeout 468 is computed as the minimum of the values advertised by the two 469 endpoints. Practical considerations on setting the idle timeout are 470 discussed in Section 6.5.2. 472 Clients SHOULD monitor the idle time incurred on their connection to 473 the server, defined by the time spent since the last packet from the 474 server has been received. When a client prepares to send a new DNS 475 query to the server, it will check whether the idle time is 476 sufficient lower than the idle timer. If it is, the client will send 477 the DNS query over the existing connection. If not, the client will 478 establish a new connection and send the query over that connection. 480 Clients MAY discard their connection to the server before the idle 481 timeout expires. If they do that, they SHOULD close the connection 482 explicitly, using QUIC's CONNECTION_CLOSE mechanism, and use the DoQ 483 error code DOQ_NO_ERROR. 485 Clients and servers MAY close the connection for a variety of other 486 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers 487 that send packets over a connection discarded by their peer MAY 488 receive a stateless reset indication. If a connection fails, all 489 queries in progress over the connection MUST be considered failed, 490 and a Server Failure (SERVFAIL, [RFC1035]) SHOULD be notified to the 491 initiator of the transaction. 493 5.5. Session Resumption and 0-RTT 495 A client MAY take advantage of the session resumption mechanisms 496 supported by QUIC transport [RFC9000] and QUIC TLS [RFC9001]. 497 Clients SHOULD consider potential privacy issues associated with 498 session resumption before deciding to use this mechanism. These 499 privacy issues are detailed in Section 9.2 and Section 9.1, and the 500 implementation considerations are discussed in Section 6.5.3. 502 The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are 503 not "replayable" transactions. Our analysis so far shows that such 504 replayable transactions can only be QUERY requests, although we may 505 need to also consider NOTIFY requests once the analysis of NOTIFY 506 services is complete, see Appendix A. 508 Servers MUST NOT execute non replayable transactions received in 509 0-RTT data. Servers MUST adopt one of the following behaviors: 511 * Queue the offending transaction and only execute it after the QUIC 512 handshake has been completed, as defined in section 4.1.1 of 513 [RFC9001]. 515 * Reply to the offending transaction with a response code REFUSED 516 and an Extended DNS Error Code (EDE) "Too Early", see 517 Section 10.3. 519 * Close the connection with the error code DOQ_PROTOCOL_ERROR. 521 For the zone transfer scenario, it would be possible to replay an XFR 522 QUERY that had been sent in 0-RTT data. However the authentication 523 mechanisms described in RFC9103 ("Zone transfer over TLS") will 524 ensure that the response is not sent by the primary until the 525 identity of the secondary has been verified i.e. the first behavior 526 listed above. 528 5.6. Message Sizes 530 DoQ Queries and Responses are sent on QUIC streams, which in theory 531 can carry up to 2^62 bytes. However, DNS messages are restricted in 532 practice to a maximum size of 65535 bytes. This maximum size is 533 enforced by the use of a two-octet message length field in DNS over 534 TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of 535 the "application/dns-message" for DNS over HTTP [RFC8484]. DoQ 536 enforces the same restriction. 538 The Extension Mechanisms for DNS (EDNS) [RFC6891] allow peers to 539 specify the UDP message size. This parameter is ignored by DoQ. DoQ 540 implementations always assume that the maximum message size is 65535 541 bytes. 543 6. Implementation Requirements 545 6.1. Authentication 547 For the stub to recursive resolver scenario, the authentication 548 requirements are the same as described in DoT [RFC7858] and "Usage 549 Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932] 550 states that DNS privacy services SHOULD provide credentials that 551 clients can use to authenticate the server. Given this, and to align 552 with the authentication model for DoH, DoQ stubs SHOULD use a Strict 553 authentication profile. Client authentication for the encrypted stub 554 to recursive scenario is not described in any DNS RFC. 556 For zone transfer, the requirements are the same as described in 557 [RFC9103]. 559 For the recursive resolver to authoritative nameserver scenario, 560 authentication requirements are unspecified at the time of writing 561 and are the subject on ongoing work in the DPRIVE WG. 563 6.2. Fall Back to Other Protocols on Connection Failure 565 If the establishment of the DoQ connection fails, clients MAY attempt 566 to fall back to DoT and then potentially clear text, as specified in 567 DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS" 568 [RFC8310], depending on their privacy profile. 570 DNS clients SHOULD remember server IP addresses that don't support 571 DoQ, including timeouts, connection refusals, and QUIC handshake 572 failures, and not request DoQ from them for a reasonable period (such 573 as one hour per server). DNS clients following an out-of-band key- 574 pinned privacy profile ([RFC7858]) MAY be more aggressive about 575 retrying DoQ connection failures. 577 6.3. Address Validation 579 Section 8 of the QUIC transport specification [RFC9000] defines 580 Address Validation procedures to avoid servers being used in address 581 amplification attacks. DoQ implementations MUST conform to this 582 specification, which limits the worst case amplification to a factor 583 3. 585 DoQ implementations SHOULD consider configuring servers to use the 586 Address Validation using Retry Packets procedure defined in section 587 8.1.2 of the QUIC transport specification [RFC9000]). This procedure 588 imposes a 1-RTT delay for verifying the return routability of the 589 source address of a client, similar to the DNS Cookies mechanism 590 [RFC7873]. 592 DoQ implementations that configure Address Validation using Retry 593 Packets SHOULD implement the Address Validation for Future 594 Connections procedure defined in section 8.1.3 of the QUIC transport 595 specification [RFC9000]). This defines how servers can send NEW 596 TOKEN frames to clients after the client address is validated, in 597 order to avoid the 1-RTT penalty during subsequent connections by the 598 client from the same address. 600 6.4. Padding 602 Implementations SHOULD protect against the traffic analysis attacks 603 described in Section 9.4 by the judicious injection of padding. This 604 could be done either by padding individual DNS messages using the 605 EDNS(0) Padding Option [RFC7830] and by padding QUIC packets (see 606 Section 8.6 of the QUIC transport specification [RFC9000]). 608 In theory, padding at the QUIC level could result in better 609 performance for the equivalent protection, because the amount of 610 padding can take into account non-DNS frames such as acknowledgeemnts 611 or flow control updates, and also because QUIC packets can carry 612 multiple DNS messages. However, applications can only control the 613 amount of padding in QUIC packets if the implementation of QUIC 614 exposes adequate APIs. This leads to the following recommendation: 616 * if the implementation of QUIC exposes APIs to set a padding 617 policy, DNS over QUIC SHOULD use that API to align the packet 618 length to a small set of fixed sizes, aligned with the 619 recommendations of the "Padding Policies for Extension Mechanisms 620 for DNS (EDNS(0))" [RFC8467]. 622 * if padding at the QUIC level is not available or not used, DNS 623 over QUIC MUST ensure that all DNS queries and responses are 624 padded to a small set of fixed sizes, using the EDNS padding 625 extension as specified in "Padding Policies for Extension 626 Mechanisms for DNS (EDNS(0))" [RFC8467]. 628 6.5. Connection Handling 630 "DNS Transport over TCP - Implementation Requirements" [RFC7766] 631 provides updated guidance on DNS over TCP, some of which is 632 applicable to DoQ. This section attempts to specify which and how 633 those considerations apply to DoQ. 635 6.5.1. Connection Reuse 637 Historic implementations of DNS clients are known to open and close 638 TCP connections for each DNS query. To avoid excess QUIC 639 connections, each with a single query, clients SHOULD reuse a single 640 QUIC connection to the recursive resolver. 642 In order to achieve performance on par with UDP, DNS clients SHOULD 643 send their queries concurrently over the QUIC streams on a QUIC 644 connection. That is, when a DNS client sends multiple queries to a 645 server over a QUIC connection, it SHOULD NOT wait for an outstanding 646 reply before sending the next query. 648 6.5.2. Resource Management and Idle Timeout Values 650 Proper management of established and idle connections is important to 651 the healthy operation of a DNS server. An implementation of DoQ 652 SHOULD follow best practices similar to those specified for DNS over 653 TCP [RFC7766], in particular with regard to: 655 * Concurrent Connections (Section 6.2.2) 656 * Security Considerations (Section 10) 658 Failure to do so may lead to resource exhaustion and denial of 659 service. 661 Clients that want to maintain long duration DoQ connections SHOULD 662 use the idle timeout mechanisms defined in Section 10.1 of the QUIC 663 transport specification [RFC9000]. Clients and servers MUST NOT send 664 the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent 665 on a DoQ connection (because it is specific to the use of TCP/TLS as 666 a transport). 668 This document does not make specific recommendations for timeout 669 values on idle connections. Clients and servers should reuse and/or 670 close connections depending on the level of available resources. 671 Timeouts may be longer during periods of low activity and shorter 672 during periods of high activity. 674 6.5.3. Using 0-RTT and Session Resumption 676 Using 0-RTT for DNS over QUIC has many compelling advantages. 677 Clients can establish connections and send queries without incurring 678 a connection delay. Servers can thus negotiate low values of the 679 connection timers, which reduces the total number of connections that 680 they need to manage. They can do that because the clients that use 681 0-RTT will not incur latency penalties if new connections are 682 required for a query. 684 Session resumption and 0-RTT data transmission create privacy risks 685 detailed in detailed in Section 9.2 and Section 9.1. The following 686 recommendations are meant to reduce the privacy risks while enjoying 687 the performance benefits of 0-RTT data, with the restriction 688 specified in Section 5.5. 690 Clients SHOULD use resumption tickets only once, as specified in 691 Appendix C.4 to [RFC8446]. Clients could receive address validation 692 tokens from the server using the NEW TOKEN mechanism; see section 8 693 of [RFC9000]. The associated tracking risks are mentioned in 694 Section 9.3. Clients SHOULD only use the address validation tokens 695 when they are also using session resumption, thus avoiding additional 696 tracking risks. 698 Servers SHOULD issue session resumption tickets with a sufficiently 699 long life time (e.g., 6 hours), so that clients are not tempted to 700 either keep connection alive or frequently poll the server to renew 701 session resumption tickets. Servers SHOULD implement the anti-replay 702 mechanisms specified in section 8 of [RFC8446]. 704 6.6. Processing Queries in Parallel 706 As specified in Section 7 of "DNS Transport over TCP - Implementation 707 Requirements" [RFC7766], resolvers are RECOMMENDED to support the 708 preparing of responses in parallel and sending them out of order. In 709 DoQ, they do that by sending responses on their specific stream as 710 soon as possible, without waiting for availability of responses for 711 previously opened streams. 713 6.7. Zone transfer 715 [RFC9103] specifies zone transfer over TLS (XoT) and includes updates 716 to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766]. Considerations 717 relating to the re-use of XoT connections described there apply 718 analogously to zone transfers performed using DoQ connections. For 719 example: 721 * DoQ servers MUST be able to handle multiple concurrent IXFR 722 requests on a single QUIC connection 724 * DoQ servers MUST be able to handle multiple concurrent AXFR 725 requests on a single QUIC connection 727 * DoQ implementations SHOULD 729 - use the same QUIC connection for both AXFR and IXFR requests to 730 the same primary 732 - pipeline such requests (if they pipeline XFR requests in 733 general) and MAY intermingle them 735 - send the response(s) for each request as soon as they are 736 available i.e. responses MAY be sent intermingled 738 6.8. Flow Control Mechanisms 740 Servers and Clients manage flow control using the mechanisms defined 741 in section 4 of [RFC9000]. These mechanisms allow clients and 742 servers to specify how many streams can be created, how much data can 743 be sent on a stream, and how much data can be sent on the union of 744 all streams. For DNS over QUIC, controlling how many streams are 745 created allows servers to control how many new requests the client 746 can send on a given connection. 748 Flow control exists to protect endpoint resources. For servers, 749 global and per-stream flow control limits control how much data can 750 be sent by clients. The same mechanisms allow clients to control how 751 much data can be sent by servers. Values that are too small will 752 unnecessarily limit performance. Values that are too large might 753 expose endpoints to overload or memory exhaustion. Implementations 754 or deployments will need to adjust flow control limits to balance 755 these concerns. In particular, zone transfer implementations will 756 need to control these limits carefully to ensure both large and 757 concurrent zone transfers are well managed. 759 Initial values of parameters control how many requests and how much 760 data can be sent by clients and servers at the beginning of the 761 connection. These values are specified in transport parameters 762 exchanged during the connection handshake. The parameter values 763 received in the initial connection also control how many requests and 764 how much data can be sent by clients using 0-RTT data in a resumed 765 connection. Using too small values of these initial parameters would 766 restrict the usefulness of allowing 0-RTT data. 768 7. Implementation Status 770 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) This 771 section records the status of known implementations of the protocol 772 defined by this specification at the time of posting of this 773 Internet-Draft, and is based on a proposal described in [RFC7942]. 775 1. AdGuard launched a DoQ recursive resolver service in December 776 2020. They have released a suite of open source tools that 777 support DoQ: 779 1. AdGuard C++ DNS libraries (https://github.com/AdguardTeam/ 780 DnsLibs) A DNS proxy library that supports all existing DNS 781 protocols including DNS-over-TLS, DNS-over-HTTPS, DNSCrypt 782 and DNS-over-QUIC (experimental). 784 2. DNS Proxy (https://github.com/AdguardTeam/dnsproxy) A simple 785 DNS proxy server that supports all existing DNS protocols 786 including DNS-over-TLS, DNS-over-HTTPS, DNSCrypt, and DNS- 787 over-QUIC. Moreover, it can work as a DNS-over-HTTPS, DNS- 788 over-TLS or DNS-over-QUIC server. 790 3. CoreDNS fork for AdGuard DNS (https://github.com/AdguardTeam/ 791 coredns) Includes DNS-over-QUIC server-side support. 793 4. dnslookup (https://github.com/ameshkov/dnslookup) Simple 794 command line utility to make DNS lookups. Supports all known 795 DNS protocols: plain DNS, DoH, DoT, DoQ, DNSCrypt. 797 2. Quicdoq (https://github.com/private-octopus/quicdoq) Quicdoq is a 798 simple open source implementation of DoQ. It is written in C, 799 based on Picoquic (https://github.com/private-octopus/picoquic). 801 3. Flamethrower (https://github.com/DNS-OARC/flamethrower/tree/dns- 802 over-quic) is an open source DNS performance and functional 803 testing utility written in C++ that has an experimental 804 implementation of DoQ. 806 4. aioquic (https://github.com/aiortc/aioquic) is an implementation 807 of QUIC in Python. It includes example client and server for 808 DoQ. 810 7.1. Performance Measurements 812 To our knowledge, no benchmarking studies comparing DoT, DoH and DoQ 813 are published yet. However anecdotal evidence from the AdGuard DoQ 814 recursive resolver deployment (https://adguard.com/en/blog/dns-over- 815 quic.html) indicates that it performs well compared to the other 816 encrypted protocols, particularly in mobile environments. Reasons 817 given for this include that DoQ 819 * Uses less bandwidth due to a more efficient handshake (and due to 820 less per message overhead when compared to DoH). 822 * Performs better in mobile environments due to the increased 823 resilience to packet loss 825 * Can maintain connections as users move between mobile networks via 826 its connection management 828 8. Security Considerations 830 The security considerations of DoQ should be comparable to those of 831 DoT [RFC7858]. 833 9. Privacy Considerations 835 The general considerations of encrypted transports provided in "DNS 836 Privacy Considerations" [RFC9076] apply to DoQ. The specific 837 considerations provided there do not differ between DoT and DoQ, and 838 are not discussed further here. Similarly, "Recommendations for DNS 839 Privacy Service Operators" [RFC8932] (which covers operational, 840 policy, and security considerations for DNS privacy services) is also 841 applicable to DoQ services. 843 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this 844 enables QUIC transmission of "0-RTT" data. This can provide 845 interesting latency gains, but it raises two concerns: 847 1. Adversaries could replay the 0-RTT data and infer its content 848 from the behavior of the receiving server. 850 2. The 0-RTT mechanism relies on TLS session resumption, which can 851 provide linkability between successive client sessions. 853 These issues are developed in Section 9.1 and Section 9.2. 855 9.1. Privacy Issues With 0-RTT data 857 The 0-RTT data can be replayed by adversaries. That data may trigger 858 queries by a recursive resolver to authoritative resolvers. 859 Adversaries may be able to pick a time at which the recursive 860 resolver outgoing traffic is observable, and thus find out what name 861 was queried for in the 0-RTT data. 863 This risk is in fact a subset of the general problem of observing the 864 behavior of the recursive resolver discussed in "DNS Privacy 865 Considerations" [RFC9076]. The attack is partially mitigated by 866 reducing the observability of this traffic. However, the risk is 867 amplified for 0-RTT data, because the attacker might replay it at 868 chosen times, several times. 870 The recommendation for TLS 1.3 [RFC8446] is that the capability to 871 use 0-RTT data should be turned off by default, and only enabled if 872 the user clearly understands the associated risks. In our case, 873 allowing 0-RTT data provides significant performance gains, and we 874 are concerned that a recommendation to not use it would simply be 875 ignored. Instead, we provide a set of practical recommendations in 876 Section 5.5 and Section 6.5.3. 878 The prevention on allowing replayable transactions in 0-RTT data 879 expressed in Section 5.5 blocks the most obvious risks of replay 880 attacks, as it only allows for transactions that will not change the 881 long term state of the server. 883 Attacks trying to assess the state of the cache are more powerful if 884 the attacker can choose the time at which the 0-RTT data will be 885 replayed. Such attacks are blocked if the server enforces single-use 886 tickets, or if the server implements a combination of Client Hello 887 recording and freshness checks, as specified in section 8 of 888 [RFC8446]. 890 The attacks described above apply to the stub resolver to recursive 891 resolver scenario, but similar attacks might be envisaged in the 892 recursive resolver to authoritative resolver scenario, and the same 893 mitigations apply. 895 9.2. Privacy Issues With Session Resumption 897 The QUIC session resumption mechanism reduces the cost of re- 898 establishing sessions and enables 0-RTT data. There is a linkability 899 issue associated with session resumption, if the same resumption 900 token is used several times. Attackers on path between client and 901 server could observe repeated usage of the token and use that to 902 track the client over time or over multiple locations. 904 The session resumption mechanism allows servers to correlate the 905 resumed sessions with the initial sessions, and thus to track the 906 client. This creates a virtual long duration session. The series of 907 queries in that session can be used by the server to identify the 908 client. Servers can most probably do that already if the client 909 address remains constant, but session resumption tickets also enable 910 tracking after changes of the client's address. 912 The recommendations in Section 6.5.3 are designed to mitigate these 913 risks. Using session tickets only once mitigates the risk of 914 tracking by third parties. Refusing to resume a session if addresses 915 change mitigates the risk of tracking by the server. 917 The privacy trade-offs here may be context specific. Stub resolvers 918 will have a strong motivation to prefer privacy over latency since 919 they often change location. However, recursive resolvers that use a 920 small set of static IP addresses are more likely to prefer the 921 reduced latency provided by session resumption and may consider this 922 a valid reason to use resumption tickets even if the IP address 923 changed between sessions. 925 Encrypted zone transfer (RFC9103) explicitly does not attempt to hide 926 the identity of the parties involved in the transfer, but at the same 927 time such transfers are not particularly latency sensitive. This 928 means that applications supporting zone transfers may decide to apply 929 the same protections as stub to recursive applications. 931 9.3. Privacy Issues With New Tokens 933 QUIC specifies address validation mechanisms in section 8 of 934 [RFC9000]. Use of an address validation token allows QUIC servers to 935 avoid an extra RTT for new connections. Address validation tokens 936 are typically tied to an IP address. QUIC clients normally only use 937 these tokens when setting a new connection from a previously used 938 address. However, due to the prevalence of NAT, clients are not 939 always aware that they are using a new address. There is a 940 linkability risk if clients mistakenly use address validation tokens 941 after unknowingly moving to a new location. 943 The recommendations in Section 6.5.3 mitigates this risk by tying the 944 usage of the NEW TOKEN to that of session resumption. 946 9.4. Traffic Analysis 948 Even though QUIC packets are encrypted, adversaries can gain 949 information from observing packet lengths, in both queries and 950 responses, as well as packet timing. Many DNS requests are emitted 951 by web browsers. Loading a specific web page may require resolving 952 dozen of DNS names. If an application adopts a simple mapping of one 953 query or response per packet, or "one QUIC STREAM frame per packet", 954 then the succession of packet lengths may provide enough information 955 to identify the requested site. 957 Implementations SHOULD use the mechanisms defined in Section 6.4 to 958 mitigate this attack. 960 10. IANA Considerations 962 10.1. Registration of DoQ Identification String 964 This document creates a new registration for the identification of 965 DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol 966 IDs" registry [RFC7301]. 968 The "doq" string identifies DoQ: 970 Protocol: DoQ 971 Identification Sequence: 0x64 0x6F 0x71 ("doq") 972 Specification: This document 974 10.2. Reservation of Dedicated Port 976 Port 853 is currently reserved for 'DNS query-response protocol run 977 over TLS/DTLS' [RFC7858]. However, the specification for DNS over 978 DTLS (DoD) [RFC8094] is experimental, limited to stub to resolver, 979 and no implementations or deployments currently exist to our 980 knowledge (even though several years have passed since the 981 specification was published). 983 This specification proposes to additionally reserve the use of port 984 853 for DoQ. QUIC was designed to be able to co-exist with other 985 protocols on the same port, including DTLS , see Section 17.2 in 986 [RFC9000]. 988 IANA is requested to add the following value to the "Service Name and 989 Transport Protocol Port Number Registry" in the System Range. The 990 registry for that range requires IETF Review or IESG Approval 991 [RFC6335]. 993 Service Name dns-over-quic 994 Port Number 853 995 Transport Protocol(s) UDP 996 Assignee IESG 997 Contact IETF Chair 998 Description DNS query-response protocol run over QUIC 999 Reference This document 1001 10.2.1. Port number 784 for experimentations 1003 (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) 1004 Early experiments MAY use port 784. This port is marked in the IANA 1005 registry as unassigned. 1007 (Note that version in -02 of this draft experiments were directed to 1008 use port 8853.) 1010 10.3. Reservation of Extended DNS Error Code Too Early 1012 IANA is requested to add the following value to the Extended DNS 1013 Error Codes registry [RFC8914]: 1015 INFO-CODE TBD 1016 Purpose Too Early 1017 Reference This document 1019 10.4. DNS over QUIC Error Codes Registry 1021 IANA [SHALL add/has added] a registry for "DNS over QUIC Error Codes" 1022 on the "Domain Name System (DNS) Parameters" web page. 1024 The "DNS over QUIC Error Codes" registry governs a 62-bit space. 1025 This space is split into three regions that are governed by different 1026 policies: 1028 * Permanent registrations for values between 0x00 and 0x3f (in 1029 hexadecimal; inclusive), which are assigned using Standards Action 1030 or IESG Approval as defined in Section 4.9 and 4.10 of [RFC8126] 1032 * Permanent registrations for values larger than 0x3f, which are 1033 assigned using the Specification Required policy ([RFC8126]) 1035 * Provisonal registrations for values larger than 0x3f, which 1036 require Expert Review, as defined in Section 4.5 of [RFC8126]. 1038 Provisional reservations share the range of values larger than 0x3f 1039 with some permanent registrations. This is by design, to enable 1040 conversion of provisional registrations into permanent registrations 1041 without requiring changes in deployed systems. (This design is 1042 aligned with the principles set in section 22 of [RFC9000].) 1044 Registrations in this registry MUST include the following fields: 1046 Value: The assigned codepoint. 1048 Status: "Permanent" or "Provisional". 1050 Contact: Contact details for the registrant. 1052 Notes: Supplementary notes about the registration. 1054 In addition, permanent registrations MUST include: 1056 Error: A short mnemonic for the parameter. 1058 Specification: A reference to a publicly available specification for 1059 the value (optional for provisional registrations). 1061 Description: A brief description of the error code semantics, which 1062 MAY be a summary if a specification reference is provided. 1064 Provisional registrations of codepoints are intended to allow for 1065 private use and experimentation with extensions to DNS over QUIC. 1066 However, provisional registrations could be reclaimed and reassigned 1067 for another purpose. In addition to the parameters listed above, 1068 provisional registrations MUST include: 1070 Date: The date of last update to the registration. 1072 A request to update the date on any provisional registration can be 1073 made without review from the designated expert(s). 1075 The initial contents of this registry are shown in Table 1. 1077 +=======+=======================+===================+===============+ 1078 | Value | Error | Description | Specification | 1079 +=======+=======================+===================+===============+ 1080 | 0x0 | DOQ_NO_ERROR | No error | Section 5.3 | 1081 +-------+-----------------------+-------------------+---------------+ 1082 | 0x1 | DOQ_INTERNAL_ERROR | Implementation | Section 5.3 | 1083 | | | error | | 1084 +-------+-----------------------+-------------------+---------------+ 1085 | 0x2 | DOQ_PROTOCOL_ERROR | Generic protocol | Section 5.3 | 1086 | | | violation | | 1087 +-------+-----------------------+-------------------+---------------+ 1088 | 0x3 | DOQ_REQUEST_CANCELLED | Request | Section 5.3 | 1089 | | | cancelled by | | 1090 | | | client | | 1091 +-------+-----------------------+-------------------+---------------+ 1093 Table 1: Initial DNS over QUIC Error Codes Entries 1095 11. Acknowledgements 1097 This document liberally borrows text from the HTTP-3 specification 1098 [I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT 1099 specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, 1100 Allison Mankin, Duane Wessels, and Paul Hoffman. 1102 The privacy issue with 0-RTT data and session resumption were 1103 analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF 1104 "DPRIVE" working group [DNS0RTT]. 1106 Thanks to Tony Finch for an extensive review of the initial version 1107 of this draft, and to Robert Evans for the discussion of 0-RTT 1108 privacy issues. Reviews by Paul Hoffman and Martin Thomson and 1109 interoperability tests conducted by Stephane Bortzmeyer helped 1110 improve the definition of the protocol. 1112 12. References 1114 12.1. Normative References 1116 [I-D.ietf-dnsop-rfc8499bis] 1117 Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in 1118 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03, 1119 28 September 2021, . 1122 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1123 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1124 . 1126 [RFC1035] Mockapetris, P., "Domain names - implementation and 1127 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1128 November 1987, . 1130 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1131 DOI 10.17487/RFC1995, August 1996, 1132 . 1134 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1135 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1136 . 1138 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1139 for DNS (EDNS(0))", STD 75, RFC 6891, 1140 DOI 10.17487/RFC6891, April 2013, 1141 . 1143 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1144 "Transport Layer Security (TLS) Application-Layer Protocol 1145 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1146 July 2014, . 1148 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1149 D. Wessels, "DNS Transport over TCP - Implementation 1150 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1151 . 1153 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1154 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1155 DOI 10.17487/RFC7828, April 2016, 1156 . 1158 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1159 DOI 10.17487/RFC7830, May 2016, 1160 . 1162 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1163 and P. Hoffman, "Specification for DNS over Transport 1164 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1165 2016, . 1167 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1168 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1169 . 1171 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1172 Transport Layer Security (DTLS)", RFC 8094, 1173 DOI 10.17487/RFC8094, February 2017, 1174 . 1176 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1177 Writing an IANA Considerations Section in RFCs", BCP 26, 1178 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1179 . 1181 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1182 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1183 May 2017, . 1185 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1186 for DNS over TLS and DNS over DTLS", RFC 8310, 1187 DOI 10.17487/RFC8310, March 2018, 1188 . 1190 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1191 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1192 October 2018, . 1194 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1195 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1196 . 1198 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1199 Lawrence, "Extended DNS Errors", RFC 8914, 1200 DOI 10.17487/RFC8914, October 2020, 1201 . 1203 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1204 Multiplexed and Secure Transport", RFC 9000, 1205 DOI 10.17487/RFC9000, May 2021, 1206 . 1208 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1209 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1210 . 1212 [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 1213 Mankin, "DNS Zone Transfer over TLS", RFC 9103, 1214 DOI 10.17487/RFC9103, August 2021, 1215 . 1217 12.2. Informative References 1219 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG 1220 mailing list, 6 April 2016, . 1223 [I-D.ietf-quic-http] 1224 Bishop, M., "Hypertext Transfer Protocol Version 3 1225 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1226 quic-http-34, 2 February 2021, 1227 . 1230 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1231 Cheshire, "Internet Assigned Numbers Authority (IANA) 1232 Procedures for the Management of the Service Name and 1233 Transport Protocol Port Number Registry", BCP 165, 1234 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1235 . 1237 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1238 Code: The Implementation Status Section", BCP 205, 1239 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1240 . 1242 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1243 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1244 . 1246 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1247 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1248 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1249 . 1251 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 1252 A. Mankin, "Recommendations for DNS Privacy Service 1253 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, 1254 October 2020, . 1256 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1257 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 1258 May 2021, . 1260 [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, 1261 DOI 10.17487/RFC9076, July 2021, 1262 . 1264 Appendix A. The NOTIFY service 1266 This appendix discusses the issue of allowing NOTIFY to be sent in 1267 0-RTT data. 1269 Section Section 5.5 says "The 0-RTT mechanism SHOULD NOT be used to 1270 send DNS requests that are not "replayable" transactions", and 1271 suggests this is limited to OPCODE QUERY. It might also be viable to 1272 propose that NOTIFY should be permitted in 0-RTT data because 1273 although it technically changes the state of the receiving server, 1274 the effect of replaying NOTIFYs has negligible impact in practice. 1276 NOTIFY messages prompt a secondary to either send an SOA query or an 1277 XFR request to the primary on the basis that a newer version of the 1278 zone is available. It has long been recognized that NOTIFYs can be 1279 forged and, in theory, used to cause a secondary to send repeated 1280 unnecessary requests to the primary. For this reason, most 1281 implementations have some form of throttling of the SOA/XFR queries 1282 triggered by the receipt of one or more NOTIFYs. 1284 RFC9103 describes the privacy risks associated with both NOTIFY and 1285 SOA queries and does not include addressing those risks within the 1286 scope of encrypting zone transfers. Given this, the privacy benefit 1287 of using DoQ for NOTIFY is not clear - but for the same reason, 1288 sending NOTIFY as 0-RTT data has no privacy risk above that of 1289 sending it using cleartext DNS. 1291 Authors' Addresses 1293 Christian Huitema 1294 Private Octopus Inc. 1295 427 Golfcourse Rd 1296 Friday Harbor, WA 98250 1297 United States of America 1299 Email: huitema@huitema.net 1301 Sara Dickinson 1302 Sinodun IT 1303 Oxford Science Park 1304 Oxford 1305 OX4 4GA 1306 United Kingdom 1308 Email: sara@sinodun.com 1309 Allison Mankin 1310 Salesforce 1312 Email: allison.mankin@gmail.com