idnits 2.17.1 draft-ietf-dprive-dnsoquic-02.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 (February 22, 2021) is 1158 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) -- Looks like a reference, but probably isn't: '1' on line 965 -- Looks like a reference, but probably isn't: '2' on line 967 -- Looks like a reference, but probably isn't: '3' on line 969 -- Looks like a reference, but probably isn't: '4' on line 971 -- Looks like a reference, but probably isn't: '5' on line 973 -- Looks like a reference, but probably isn't: '6' on line 975 -- Looks like a reference, but probably isn't: '7' on line 977 -- Looks like a reference, but probably isn't: '8' on line 979 -- Looks like a reference, but probably isn't: '9' on line 981 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dnsop-terminology-ter' == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-08 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-xfr-over-tls-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-33 -- Obsolete informational reference (is this intentional?): RFC 1885 (Obsoleted by RFC 2463) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). 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 A. Mankin 5 Expires: August 26, 2021 Salesforce 6 S. Dickinson 7 Sinodun IT 8 February 22, 2021 10 Specification of DNS over Dedicated QUIC Connections 11 draft-ietf-dprive-dnsoquic-02 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 August 26, 2021. 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Document work via GitHub . . . . . . . . . . . . . . . . . . 4 60 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Scope is Limited to the Stub to Resolver Scenario . . . . 5 62 4.2. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5 63 4.3. Design for Minimum Latency . . . . . . . . . . . . . . . 6 64 4.4. No Specific Middlebox Bypass Mechanism . . . . . . . . . 6 65 4.5. No Server Initiated Transactions . . . . . . . . . . . . 7 66 5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Connection Establishment . . . . . . . . . . . . . . . . 7 68 5.1.1. Draft Version Identification . . . . . . . . . . . . 7 69 5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7 70 5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 8 71 5.2.1. Transaction Errors . . . . . . . . . . . . . . . . . 8 72 5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 8 73 5.4. Connection Management . . . . . . . . . . . . . . . . . . 9 74 5.5. Connection Resume and 0-RTT . . . . . . . . . . . . . . . 10 75 5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Implementation Requirements . . . . . . . . . . . . . . . . . 11 77 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 11 78 6.2. Fall Back to Other Protocols on Connection Failure . . . 11 79 6.3. Address Validation . . . . . . . . . . . . . . . . . . . 11 80 6.4. DNS Message IDs . . . . . . . . . . . . . . . . . . . . . 12 81 6.5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.6. Connection Handling . . . . . . . . . . . . . . . . . . . 12 83 6.6.1. Connection Reuse . . . . . . . . . . . . . . . . . . 12 84 6.6.2. Resource Management and Idle Timeout Values . . . . . 12 85 6.7. Processing Queries in Parallel . . . . . . . . . . . . . 13 86 6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 13 87 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 88 7.1. Performance Measurements . . . . . . . . . . . . . . . . 14 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 91 9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 15 92 9.2. Privacy Issues With Session Resume . . . . . . . . . . . 16 93 9.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 16 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 10.1. Registration of DoQ Identification String . . . . . . . 17 96 10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 17 97 10.2.1. Port number 8853 for experimentations . . . . . . . 17 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 12.2. Informative References . . . . . . . . . . . . . . . . . 19 102 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 Appendix A. Supporting AXFR . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 106 1. Introduction 108 Domain Name System (DNS) concepts are specified in "Domain names - 109 concepts and facilities" [RFC1034]. The transmission of DNS queries 110 and responses over UDP and TCP is specified in "Domain names - 111 implementation and specification" [RFC1035]. This document presents 112 a mapping of the DNS protocol over the QUIC transport 113 [I-D.ietf-quic-transport] [I-D.ietf-quic-tls]. DNS over QUIC is 114 referred here as DoQ, in line with the "Terminology for DNS 115 Transports and Location" [I-D.ietf-dnsop-terminology-ter]. The goals 116 of the DoQ mapping are: 118 1. Provide the same DNS privacy protection as DNS over TLS (DoT) 119 [RFC7858]. This includes an option for the client to 120 authenticate the server by means of an authentication domain name 121 as specified in "Usage Profiles for DNS over TLS and DNS over 122 DTLS" [RFC8310]. 124 2. Provide an improved level of source address validation for DNS 125 servers compared to classic DNS over UDP. 127 3. Provide a transport that is not constrained by path MTU 128 limitations on the size of DNS responses it can send. 130 4. Explore the characteristics of using QUIC as a DNS transport, 131 versus other solutions like DNS over UDP [RFC1035], DoT 132 [RFC7858], or DNS over HTTPS (DoH) [RFC8484]. 134 In order to achieve these goals, the focus of this document is 135 limited to the "stub to recursive resolver" scenario also addressed 136 by DoT [RFC7858]. That is, the protocol described here works for 137 queries and responses between stub clients and recursive servers. 138 The specific non-goals of this document are: 140 1. No attempt is made to support AXFR "DNS Zone Transfer Protocol 141 (AXFR)" [RFC5936] or IXFR "Incremental Zone Transfer in DNS" 142 [RFC1885], as these mechanisms are not relevant to the stub to 143 recursive resolver scenario. (This may change in future versions 144 of this draft. See Appendix A for a discussion of changes 145 required for AXFR support.) 147 2. No attempt is made to evade potential blocking of DNS over QUIC 148 traffic by middleboxes. 150 3. No attempt to support server initiated transactions, are these 151 are not relevant for the "stub to recursive resolver" scenario, 152 see Section 4.5. 154 Users interested in zone transfers should continue using TCP based 155 solutions and will also want to take note of work in progress to 156 support "DNS Zone Transfer-over-TLS" [I-D.ietf-dprive-xfr-over-tls]. 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 (THIS SECTION TO BE REMOVED BEFORE PUBLICATION) The Github repository 179 for this document is at https://github.com/huitema/dnsoquic. 180 Proposed text and editorial changes are very much welcomed there, but 181 any functional changes should always first be discussed on the IETF 182 DPRIVE WG (dns-privacy) mailing list. 184 4. Design Considerations 186 This section and its subsection present the design guidelines that 187 were used for DoQ. This section is informative in nature. 189 4.1. Scope is Limited to the Stub to Resolver Scenario 191 Usage scenarios for the DNS protocol can be broadly classified in 192 three groups: stub to recursive resolver, recursive resolver to 193 authoritative server, and server to server. This design focuses only 194 on the "stub to recursive resolver" scenario following the approach 195 taken in DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS 196 over DTLS" [RFC8310]. 198 QUESTION: Should this document specify any aspects of configuration 199 of discoverability differently to DoT? 201 No attempt is made to address the recursive to authoritative 202 scenarios. Authoritative resolvers are discovered dynamically 203 through NS records. It is noted that at the time of writing work is 204 ongoing in the DPRIVE working group to attempt to address the 205 analogous problem for DoT [I-D.ietf-dprive-phase2-requirements]. In 206 the absence of an agreed way for authoritative to signal support for 207 QUIC transport, recursive resolvers would have to resort to some 208 trial and error process. At this stage of QUIC deployment, this 209 would be mostly errors, and does not seem attractive. This could 210 change in the future. 212 The DNS protocol is also used for zone transfers. In the AXFR zone 213 transfer scenario [RFC5936], the client emits a single AXFR query, 214 and the server responds with a series of AXFR responses. This 215 creates a unique profile, in which a query results in several 216 responses. Supporting that profile would complicate the mapping of 217 DNS queries over QUIC streams. Zone transfers are not used in the 218 stub to recursive scenario that is the focus here, and seem to be 219 currently well served by using DNS over TCP. There is no attempt to 220 support either AXFR or IXFR in this proposed mapping of DNS to QUIC. 222 4.2. Provide DNS Privacy 224 DoT [RFC7858] defines how to mitigate some of the issues described in 225 "DNS Privacy Considerations" [RFC7626] by specifying how to transmit 226 DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS 227 over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles 228 for DoT including how stub resolvers can authenticate recursive 229 resolvers. 231 QUIC connection setup includes the negotiation of security parameters 232 using TLS, as specified in "Using TLS to Secure QUIC" 233 [I-D.ietf-quic-tls], enabling encryption of the QUIC transport. 234 Transmitting DNS messages over QUIC will provide essentially the same 235 privacy protections as DoT [RFC7858] including Strict and 236 Opportunistic Usage Profiles [RFC8310]. Further discussion on this 237 is provided in Section 9. 239 4.3. Design for Minimum Latency 241 QUIC is specifically designed to reduce the delay between HTTP 242 queries and HTTP responses. This is achieved through three main 243 components: 245 1. Support for 0-RTT data during session resumption. 247 2. Support for advanced error recovery procedures as specified in 248 "QUIC Loss Detection and Congestion Control" 249 [I-D.ietf-quic-recovery]. 251 3. Mitigation of head-of-line blocking by allowing parallel delivery 252 of data on multiple streams. 254 This mapping of DNS to QUIC will take advantage of these features in 255 three ways: 257 1. Optional support for sending 0-RTT data during session resumption 258 (the security and privacy implications of this are discussed in 259 later sections). 261 2. Long-lived QUIC connections over which multiple DNS transactions 262 are performed, generating the sustained traffic required to 263 benefit from advanced recovery features. 265 3. Fast resumption of QUIC connections to manage the disconnect-on- 266 idle feature of QUIC without incurring retransmission time-outs. 268 4. Mapping of each DNS Query/Response transaction to a separate 269 stream, to mitigate head-of-line blocking. This enables servers 270 to respond to queries "out of order". It also enables clients to 271 process responses as soon as they arrive, without having to wait 272 for in order delivery of responses previously posted by the 273 server. 275 These considerations will be reflected in the mapping of DNS traffic 276 to QUIC streams in Section 5.2. 278 4.4. No Specific Middlebox Bypass Mechanism 280 The mapping of DNS over QUIC is defined for minimal overhead and 281 maximum performance. This means a different traffic profile than 282 HTTP3 over QUIC. This difference can be noted by firewalls and 283 middleboxes. There may be environments in which HTTP3 over QUIC will 284 be able to pass through, but DoQ will be blocked by these middle 285 boxes. 287 4.5. No Server Initiated Transactions 289 As stated in Section 1, this document does not specify support for 290 server initiated transactions because these are not relevant for the 291 "stub to recursive resolver" scenario. Note that "DNS Stateful 292 Operations" (DSO) [RFC8490] are only applicable for DNS over TCP and 293 DNS over TLS. DSO is not applicable to DNS over HTTP since HTTP has 294 its own mechanism for managing sessions, and this is incompatible 295 with the DSO; the same is true for DNS over QUIC. 297 5. Specifications 299 5.1. Connection Establishment 301 DoQ connections are established as described in the QUIC transport 302 specification [I-D.ietf-quic-transport]. During connection 303 establishment, DoQ support is indicated by selecting the ALPN token 304 "doq" in the crypto handshake. 306 5.1.1. Draft Version Identification 308 *RFC Editor's Note:* Please remove this section prior to publication 309 of a final version of this document. 311 Only implementations of the final, published RFC can identify 312 themselves as "doq". Until such an RFC exists, implementations MUST 313 NOT identify themselves using this string. 315 Implementations of draft versions of the protocol MUST add the string 316 "-" and the corresponding draft number to the identifier. For 317 example, draft-ietf-dprive-dnsoquic-00 is identified using the string 318 "doq-i00". 320 5.1.2. Port Selection 322 By default, a DNS server that supports DoQ MUST listen for and accept 323 QUIC connections on the dedicated UDP port TBD (number to be defined 324 in Section 10), unless it has mutual agreement with its clients to 325 use a port other than TBD for DoQ. In order to use a port other than 326 TBD, both clients and servers would need a configuration option in 327 their software. 329 By default, a DNS client desiring to use DoQ with a particular server 330 MUST establish a QUIC connection to UDP port TBD on the server, 331 unless it has mutual agreement with its server to use a port other 332 than port TBD for DoQ. Such another port MUST NOT be port 53 or port 333 853. This recommendation against use of port 53 for DoQ is to avoid 334 confusion between DoQ and the use of DNS over UDP [RFC1035]. 335 Similarly, using port 853 would cause confusion between DoQ and DNS 336 over DTLS [RFC8094]. 338 5.2. Stream Mapping and Usage 340 The mapping of DNS traffic over QUIC streams takes advantage of the 341 QUIC stream features detailed in Section 2 of the QUIC transport 342 specification [I-D.ietf-quic-transport]. 344 The stub to resolver DNS traffic follows a simple pattern in which 345 the client sends a query, and the server provides a response. This 346 design specifies that for each subsequent query on a QUIC connection 347 the client MUST select the next available client-initiated 348 bidirectional stream, in conformance with the QUIC transport 349 specification [I-D.ietf-quic-transport]. 351 The client MUST send the DNS query over the selected stream, and MUST 352 indicate through the STREAM FIN mechanism that no further data will 353 be sent on that stream. 355 The server MUST send the response on the same stream, and MUST 356 indicate through the STREAM FIN mechanism that no further data will 357 be sent on that stream. 359 Therefore, a single client initiated DNS transaction consumes a 360 single stream. This means that the client's first query occurs on 361 QUIC stream 0, the second on 4, and so on. 363 5.2.1. Transaction Errors 365 Peers normally complete transactions by sending a DNS response on the 366 transaction's stream, including cases where the DNS response 367 indicates a DNS error. For example, a Server Failure (SERVFAIL, 368 [RFC1035]) SHOULD be notified to the initiator of the transaction by 369 sending back a response with the Response Code set to SERVFAIL. 371 If a peer is incapable of sending a DNS response due to an internal 372 error, it may issue a QUIC Stream Reset with error code 373 DOQ_INTERNAL_ERROR. The corresponding transaction MUST be abandoned. 375 5.3. DoQ Error Codes 377 The following error codes are defined for use when abruptly 378 terminating streams, aborting reading of streams, or immediately 379 closing connections: 381 DOQ_NO_ERROR (0x00): No error. This is used when the connection or 382 stream needs to be closed, but there is no error to signal. 384 DOQ_INTERNAL_ERROR (0x01): The DoQ implementation encountered an 385 internal error and is incapable of pursuing the transaction or the 386 connection 388 5.4. Connection Management 390 Section 10 of the QUIC transport specification 391 [I-D.ietf-quic-transport] specifies that connections can be closed in 392 three ways: 394 o idle timeout 396 o immediate close 398 o stateless reset 400 Clients and servers implementing DNS over QUIC SHOULD negotiate use 401 of the idle timeout. Closing on idle timeout is done without any 402 packet exchange, which minimizes protocol overhead. Per section 10.2 403 of the QUIC transport specification, the effective value of the idle 404 timeout is computed as the minimum of the values advertised by the 405 two endpoints. Practical considerations on setting the idle timeout 406 are discussed in Section 6.6.2. 408 Clients SHOULD monitor the idle time incurred on their connection to 409 the server, defined by the time spent since the last packet from the 410 server has been received. When a client prepares to send a new DNS 411 query to the server, it will check whether the idle time is 412 sufficient lower than the idle timer. If it is, the client will send 413 the DNS query over the existing connection. If not, the client will 414 establish a new connection and send the query over that connection. 416 Clients MAY discard their connection to the server before the idle 417 timeout expires. If they do that, they SHOULD close the connection 418 explicitly, using QUIC's CONNECTION_CLOSE mechanisms, and indicating 419 the Application reason "No Error". 421 Clients and servers MAY close the connection for a variety of other 422 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers 423 that send packets over a connection discarded by their peer MAY 424 receive a stateless reset indication. If a connection fails, all 425 queries in progress over the connection MUST be considered failed, 426 and a Server Failure (SERVFAIL, [RFC1035]) SHOULD be notified to the 427 initiator of the transaction. 429 5.5. Connection Resume and 0-RTT 431 A stub resolver MAY take advantage of the connection resume 432 mechanisms supported by QUIC transport [I-D.ietf-quic-transport] and 433 QUIC TLS [I-D.ietf-quic-tls]. Stub resolvers SHOULD consider 434 potential privacy issues associated with session resume before 435 deciding to use this mechanism. These privacy issues are detailed in 436 Section 9.2. 438 When resuming a session, a stub resolver MAY take advantage of the 439 0-RTT mechanism supported by QUIC. The 0-RTT mechanism MUST NOT be 440 used to send data that is not "replayable" transactions. For 441 example, a stub resolver MAY transmit a Query as 0-RTT, but MUST NOT 442 transmit an Update. 444 5.6. Message Sizes 446 DoQ Queries and Responses are sent on QUIC streams, which in theory 447 can carry up to 2^62 bytes. However, DNS messages are restricted in 448 practice to a maximum size of 65535 bytes. This maximum size is 449 enforced by the use of a two-octet message length field in DNS over 450 TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of 451 the "application/dns-message" for DNS over HTTP [RFC8484]. DoQ 452 enforces the same restriction. 454 The flow control mechanism of QUIC control how much data can be sent 455 by QUIC nodes at a given time. The initial values of per stream flow 456 control parameters is defined by two transport parameters: 458 o initial_max_stream_data_bidi_local: when set by the client, 459 specifies the amount of data that servers can send on a "response" 460 stream without waiting for a MAX_STREAM_DATA frame. 462 o initial_max_stream_data_bidi_remote: when set by the server, 463 specifies the amount of data that clients can send on a "query" 464 stream without waiting for a MAX_STREAM_DATA frame. 466 For better performance, it is RECOMMENDED that clients and servers 467 set each of these two parameters to a value of 65535 or greater. 469 The Extension Mechanisms for DNS (EDNS) [RFC6891] allow peers to 470 specify the UDP message size. This parameter is ignored by DoQ. DoQ 471 implementations always assume that the maximum message size is 65535 472 bytes. 474 6. Implementation Requirements 476 6.1. Authentication 478 For the stub to recursive resolver scenario, the authentication 479 requirements are the same as described in DoT [RFC7858] and "Usage 480 Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. There is no 481 need to authenticate the client's identity in either scenario. 483 6.2. Fall Back to Other Protocols on Connection Failure 485 If the establishment of the DoQ connection fails, clients SHOULD 486 attempt to fall back to DoT and then potentially clear text, as 487 specified in DoT [RFC7858] and "Usage Profiles for DNS over TLS and 488 DNS over DTLS" [RFC8310], depending on their privacy profile. 490 DNS clients SHOULD remember server IP addresses that don't support 491 DoQ, including timeouts, connection refusals, and QUIC handshake 492 failures, and not request DoQ from them for a reasonable period (such 493 as one hour per server). DNS clients following an out-of-band key- 494 pinned privacy profile ([RFC7858]) MAY be more aggressive about 495 retrying DoQ connection failures. 497 6.3. Address Validation 499 Section 8 of the QUIC transport specification 500 [I-D.ietf-quic-transport] defines Address Validation procedures to 501 avoid servers being used in address amplification attacks. DoQ 502 implementations MUST conform to this specification, which limits the 503 worst case amplification to a factor 3. 505 DoQ implementations SHOULD consider configuring servers to use the 506 Address Validation using Retry Packets procedure defined in section 507 8.1.2 of the QUIC transport specification [I-D.ietf-quic-transport]). 508 This procedure imposes a 1-RTT delay for verifying the return 509 routability of the source address of a client, similar to the DNS 510 Cookies mechanism [RFC7873]. 512 DoQ implementations that configure Address Validation using Retry 513 Packets SHOULD implement the Address Validation for Future 514 Connections procedure defined in section 8.1.3 of the QUIC transport 515 specification [I-D.ietf-quic-transport]). This defines how servers 516 can send NEW TOKEN frames to clients after the client address is 517 validated, in order to avoid the 1-RTT penalty during subsequent 518 connections by the client from the same address. 520 6.4. DNS Message IDs 522 When sending queries over a QUIC connection, the DNS Message ID MUST 523 be set to zero. 525 6.5. Padding 527 There are mechanisms specified for padding individual DNS messages in 528 "The EDNS(0) Padding Option" [RFC7830] and for padding within QUIC 529 packets (see Section 8.6 of the QUIC transport specification 530 [I-D.ietf-quic-transport]). 532 Implementations SHOULD NOT use DNS options for padding individual DNS 533 messages, because QUIC transport MAY transmit multiple STREAM frames 534 containing separate DNS messages in a single QUIC packet. Instead, 535 implementations SHOULD use QUIC PADDING frames to align the packet 536 length to a small set of fixed sizes, aligned with the 537 recommendations of the "Padding Policies for Extension Mechanisms for 538 DNS (EDNS(0))" [RFC8467]. 540 6.6. Connection Handling 542 "DNS Transport over TCP - Implementation Requirements" [RFC7766] 543 provides updated guidance on DNS over TCP, some of which is 544 applicable to DoQ. This section attempts to specify which and how 545 those considerations apply to DoQ. 547 6.6.1. Connection Reuse 549 Historic implementations of DNS stub resolvers are known to open and 550 close TCP connections for each DNS query. To avoid excess QUIC 551 connections, each with a single query, clients SHOULD reuse a single 552 QUIC connection to the recursive resolver. 554 In order to achieve performance on par with UDP, DNS clients SHOULD 555 send their queries concurrently over the QUIC streams on a QUIC 556 connection. That is, when a DNS client sends multiple queries to a 557 server over a QUIC connection, it SHOULD NOT wait for an outstanding 558 reply before sending the next query. 560 6.6.2. Resource Management and Idle Timeout Values 562 Proper management of established and idle connections is important to 563 the healthy operation of a DNS server. An implementation of DoQ 564 SHOULD follow best practices similar to those specified for DNS over 565 TCP [RFC7766], in particular with regard to: 567 o Concurrent Connections (Section 6.2.2) 568 o Security Considerations (Section 10) 570 Failure to do so may lead to resource exhaustion and denial of 571 service. 573 Clients that want to maintain long duration DoQ connections SHOULD 574 use the idle timeout mechanisms defined in Section 10.2 of the QUIC 575 transport specification [I-D.ietf-quic-transport]. Clients and 576 servers MUST NOT send the edns-tcp-keepalive EDNS(0) Option [RFC7828] 577 in any messages sent on a DoQ connection (because it is specific to 578 the use of TCP/TLS as a transport). If any message sent on a DoQ 579 connection contains an edns-tcp-keepalive EDNS(0) Option, this is a 580 fatal error and the recipient of the defective message MUST forcibly 581 abort the connection immediately. 583 This document does not make specific recommendations for timeout 584 values on idle connections. Clients and servers should reuse and/or 585 close connections depending on the level of available resources. 586 Timeouts may be longer during periods of low activity and shorter 587 during periods of high activity. 589 Clients that are willing to use QUIC's 0-RTT mechanism can 590 reestablish connections and send transactions on the new connection 591 with minimal delay overhead. These clients MAY chose low values of 592 the idle timer. 594 6.7. Processing Queries in Parallel 596 As specified in Section 7 of "DNS Transport over TCP - Implementation 597 Requirements" [RFC7766], resolvers are RECOMMENDED to support the 598 preparing of responses in parallel and sending them out of order. In 599 DoQ, they do that by sending responses on their specific stream as 600 soon as possible, without waiting for availability of responses for 601 previously opened streams. 603 6.8. Flow Control Mechanisms 605 Servers and Clients manage flow control as specified in QUIC. 607 Servers MAY use the "maximum stream ID" option of the QUIC transport 608 to limit the number of streams opened by the client. This mechanism 609 will effectively limit the number of DNS queries that a client can 610 send on a single DoQ connection. 612 7. Implementation Status 614 (THIS SECTION TO BE REMOVED BEFORE PUBLICATION) This section records 615 the status of known implementations of the protocol defined by this 616 specification at the time of posting of this Internet-Draft, and is 617 based on a proposal described in [RFC7942]. 619 1. AdGuard launched a DoQ recursive resolver service in December 620 2020. They have released a suite of open source tools that 621 support DoQ: 623 1. AdGuard C++ DNS libraries [1] A DNS proxy library that 624 supports all existing DNS protocols including DNS-over-TLS, 625 DNS-over-HTTPS, DNSCrypt and DNS-over-QUIC (experimental). 627 2. DNS Proxy [2] A simple DNS proxy server that supports all 628 existing DNS protocols including DNS-over-TLS, DNS-over- 629 HTTPS, DNSCrypt, and DNS-over-QUIC. Moreover, it can work as 630 a DNS-over-HTTPS, DNS-over-TLS or DNS-over-QUIC server. 632 3. CoreDNS fork for AdGuard DNS [3] Includes DNS-over-QUIC 633 server-side support. 635 4. dnslookup [4] Simple command line utility to make DNS 636 lookups. Supports all known DNS protocols: plain DNS, DoH, 637 DoT, DoQ, DNSCrypt. 639 2. Quicdoq [5] Quicdoq is a simple open source implementation of DNS 640 over Quic. It is written in C, based on Picoquic [6]. 642 3. Flamethrower [7] is an open source DNS performance and functional 643 testing utility written in C++ that has an experimental 644 implementation of DoQ. 646 4. aioquic [8] is an implementation of QUIC in Python. It includes 647 example client and server for DNS over QUIC. 649 7.1. Performance Measurements 651 To our knowledge, no benchmarking studies comparing DoT, DoH and DoQ 652 are published yet. However anecdotal evidence from the AdGuard DoQ 653 recursive resolver deployment [9] indicates that it performs well 654 compared to the other encrypted protocols, particularly in mobile 655 environments. Reasons given for this include that DoQ 657 o Uses less bandwidth due to a more efficient handshake (and due to 658 less per message overhead when compared to DoH). 660 o Performs better in mobile environments due to the increased 661 resilience to packet loss 663 o Can maintain connections as users move between mobile networks via 664 its connection management 666 8. Security Considerations 668 The security considerations of DoQ should be comparable to those of 669 DoT [RFC7858]. 671 9. Privacy Considerations 673 DoQ is specifically designed to protect the DNS traffic between stub 674 and resolver from observations by third parties, and thus protect the 675 privacy of queries sent by the stub. However, the recursive resolver 676 has full visibility of the stub's traffic, and could be used as an 677 observation point, as discussed in the revision of "DNS Privacy 678 Considerations" [I-D.ietf-dprive-rfc7626-bis]. These considerations 679 do not differ between DoT and DoQ and are not discussed further here. 681 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this 682 enables QUIC transmission of "0-RTT" data. This can provide 683 interesting latency gains, but it raises two concerns: 685 1. Adversaries could replay the 0-RTT data and infer its content 686 from the behavior of the receiving server. 688 2. The 0-RTT mechanism relies on TLS resume, which can provide 689 linkability between successive client sessions. 691 These issues are developed in Section 9.1 and Section 9.2. 693 9.1. Privacy Issues With 0-RTT data 695 The 0-RTT data can be replayed by adversaries. That data may trigger 696 queries by a recursive resolver to authoritative resolvers. 697 Adversaries may be able to pick a time at which the recursive 698 resolver outgoing traffic is observable, and thus find out what name 699 was queried for in the 0-RTT data. 701 This risk is in fact a subset of the general problem of observing the 702 behavior of the recursive resolver discussed in "DNS Privacy 703 Considerations" [RFC7626]. The attack is partially mitigated by 704 reducing the observability of this traffic. However, the risk is 705 amplified for 0-RTT data, because the attacker might replay it at 706 chosen times, several times. 708 The recommendation for TLS 1.3 [RFC8446] is that the capability to 709 use 0-RTT data should be turned off by default, and only enabled if 710 the user clearly understands the associated risks. 712 QUESTION: Should 0-RTT only be used with Opportunistic profiles (i.e. 713 disabled by default for Strict only)? 715 9.2. Privacy Issues With Session Resume 717 The QUIC session resume mechanism reduces the cost of re-establishing 718 sessions and enables 0-RTT data. There is a linkability issue 719 associated with session resume, if the same resume token is used 720 several times, but this risk is mitigated by the mechanisms 721 incorporated in QUIC and in TLS 1.3. With these mechanisms, clients 722 and servers can cooperate to avoid linkability by third parties. 723 However, the server will always be able to link the resumed session 724 to the initial session. This creates a virtual long duration 725 session. The series of queries in that session can be used by the 726 server to identify the client. 728 Enabling the server to link client sessions through session resume is 729 probably not a large additional risk if the client's connectivity did 730 not change between the sessions, since the two sessions can probably 731 be correlated by comparing the IP addresses. On the other hand, if 732 the addresses did change, the client SHOULD consider whether the 733 linkability risk exceeds the performance benefits. This evaluation 734 will obviously depend on the level of trust between stub and 735 recursive. 737 9.3. Traffic Analysis 739 Even though QUIC packets are encrypted, adversaries can gain 740 information from observing packet lengths, in both queries and 741 responses, as well as packet timing. Many DNS requests are emitted 742 by web browsers. Loading a specific web page may require resolving 743 dozen of DNS names. If an application adopts a simple mapping of one 744 query or response per packet, or "one QUIC STREAM frame per packet", 745 then the succession of packet lengths may provide enough information 746 to identify the requested site. 748 Implementations SHOULD use the mechanisms defined in Section 6.5 to 749 mitigate this attack. 751 10. IANA Considerations 752 10.1. Registration of DoQ Identification String 754 This document creates a new registration for the identification of 755 DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol 756 IDs" registry [RFC7301]. 758 The "doq" string identifies DoQ: 760 Protocol: DoQ 762 Identification Sequence: 0x64 0x6F 0x71 ("doq") 764 Specification: This document 766 10.2. Reservation of Dedicated Port 768 IANA is required to add the following value to the "Service Name and 769 Transport Protocol Port Number Registry" in the System Range. The 770 registry for that range requires IETF Review or IESG Approval 771 [RFC6335], and such a review was requested using the early allocation 772 process [RFC7120] for the well-known UDP port in this document. 773 Since port 853 is reserved for 'DNS query-response protocol run over 774 TLS' consideration is requested for reserving port 8853 for 'DNS 775 query-response 776 protocol run over QUIC'. 778 Service Name dns-over-quic 779 Port Number 8853 780 Transport Protocol(s) UDP 781 Assignee IESG 782 Contact IETF Chair 783 Description DNS query-response protocol run over QUIC 784 Reference This document 786 10.2.1. Port number 8853 for experimentations 788 *RFC Editor's Note:* Please remove this section prior to publication 789 of a final version of this document. 791 Early experiments MAY use port 8853. This port is marked in the IANA 792 registry as unassigned. 794 (Note that prior to version -02 of this draft, experiments were 795 directed to use port 784.) 797 11. Acknowledgements 799 This document liberally borrows text from the HTTP-3 specification 800 [I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT 801 specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, 802 Allison Mankin, Duane Wessels, and Paul Hoffman. 804 The privacy issue with 0-RTT data and session resume were analyzed by 805 Daniel Kahn Gillmor (DKG) in a message to the IETF "DPRIVE" working 806 group [DNS0RTT]. 808 Thanks to Tony Finch for an extensive review of the initial version 809 of this draft. Reviews by Paul Hoffman and interoperability tests 810 conducted by Stephane Bortzmeyer helped improve the definition of the 811 protocol. 813 12. References 815 12.1. Normative References 817 [I-D.ietf-dnsop-terminology-ter] 818 Hoffman, P., "Terminology for DNS Transports and 819 Location", draft-ietf-dnsop-terminology-ter-02 (work in 820 progress), August 2020. 822 [I-D.ietf-quic-tls] 823 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 824 draft-ietf-quic-tls-34 (work in progress), January 2021. 826 [I-D.ietf-quic-transport] 827 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 828 and Secure Transport", draft-ietf-quic-transport-34 (work 829 in progress), January 2021. 831 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 832 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 833 . 835 [RFC1035] Mockapetris, P., "Domain names - implementation and 836 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 837 November 1987, . 839 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 840 for DNS (EDNS(0))", STD 75, RFC 6891, 841 DOI 10.17487/RFC6891, April 2013, 842 . 844 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 845 "Transport Layer Security (TLS) Application-Layer Protocol 846 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 847 July 2014, . 849 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 850 D. Wessels, "DNS Transport over TCP - Implementation 851 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 852 . 854 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 855 and P. Hoffman, "Specification for DNS over Transport 856 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 857 2016, . 859 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 860 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 861 . 863 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 864 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 865 May 2017, . 867 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 868 for DNS over TLS and DNS over DTLS", RFC 8310, 869 DOI 10.17487/RFC8310, March 2018, 870 . 872 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 873 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 874 . 876 12.2. Informative References 878 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG 879 mailing list, April 2016, . 882 [I-D.ietf-dprive-phase2-requirements] 883 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 884 Privacy Requirements for Exchanges between Recursive 885 Resolvers and Authoritative Servers", draft-ietf-dprive- 886 phase2-requirements-02 (work in progress), November 2020. 888 [I-D.ietf-dprive-rfc7626-bis] 889 Wicinski, T., "DNS Privacy Considerations", draft-ietf- 890 dprive-rfc7626-bis-08 (work in progress), October 2020. 892 [I-D.ietf-dprive-xfr-over-tls] 893 Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 894 Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- 895 xfr-over-tls-05 (work in progress), January 2021. 897 [I-D.ietf-quic-http] 898 Bishop, M., "Hypertext Transfer Protocol Version 3 899 (HTTP/3)", draft-ietf-quic-http-33 (work in progress), 900 December 2020. 902 [I-D.ietf-quic-recovery] 903 Iyengar, J. and I. Swett, "QUIC Loss Detection and 904 Congestion Control", draft-ietf-quic-recovery-34 (work in 905 progress), January 2021. 907 [RFC1885] Conta, A. and S. Deering, "Internet Control Message 908 Protocol (ICMPv6) for the Internet Protocol Version 6 909 (IPv6)", RFC 1885, DOI 10.17487/RFC1885, December 1995, 910 . 912 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 913 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 914 . 916 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 917 Cheshire, "Internet Assigned Numbers Authority (IANA) 918 Procedures for the Management of the Service Name and 919 Transport Protocol Port Number Registry", BCP 165, 920 RFC 6335, DOI 10.17487/RFC6335, August 2011, 921 . 923 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 924 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 925 2014, . 927 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 928 DOI 10.17487/RFC7626, August 2015, 929 . 931 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 932 edns-tcp-keepalive EDNS0 Option", RFC 7828, 933 DOI 10.17487/RFC7828, April 2016, 934 . 936 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 937 DOI 10.17487/RFC7830, May 2016, 938 . 940 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 941 Code: The Implementation Status Section", BCP 205, 942 RFC 7942, DOI 10.17487/RFC7942, July 2016, 943 . 945 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 946 Transport Layer Security (DTLS)", RFC 8094, 947 DOI 10.17487/RFC8094, February 2017, 948 . 950 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 951 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 952 . 954 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 955 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 956 October 2018, . 958 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 959 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 960 RFC 8490, DOI 10.17487/RFC8490, March 2019, 961 . 963 12.3. URIs 965 [1] https://github.com/AdguardTeam/DnsLibs 967 [2] https://github.com/AdguardTeam/dnsproxy 969 [3] https://github.com/AdguardTeam/coredns 971 [4] https://github.com/ameshkov/dnslookup 973 [5] https://github.com/private-octopus/quicdoq 975 [6] https://github.com/private-octopus/picoquic 977 [7] https://github.com/DNS-OARC/flamethrower/tree/dns-over-quic 979 [8] https://github.com/aiortc/aioquic 981 [9] https://adguard.com/en/blog/dns-over-quic.html 983 Appendix A. Supporting AXFR 985 This draft version makes no attempt to support AXFR or IXFR queries. 986 As defined in [RFC5936], the server responds to AXFR queries with a 987 series of DNS response messages where 988 "... the first message MUST begin with the SOA resource record of the 989 zone, and the last message MUST conclude with the same SOA resource 990 record." 992 and the QDCOUNT: 994 o MUST be 1 in the first message; 996 o MUST be 0 or 1 in all following messages; 998 o MUST be 1 if RCODE indicates an error 1000 When the DNS protocol is carried over TCP or TLS, these messages are 1001 carried over a single byte stream and each of them is preceded by a 1002 16 bit length field. The encapsulation currently defined in this 1003 draft does not include a length field and assumes exactly one 1004 response message for each query. 1006 Note that since IXFR can fall back to an AXFR-like response if the 1007 server is not able to send an incremental change, this discussion 1008 also applies to those AXFR-like responses returned to an IXFR request 1009 in that scenario. 1011 There are two plausible ways to carry the series of AXFR responses in 1012 QUIC: keep the current format and use a separate QUIC stream for each 1013 response; or, relax the restriction of having just one response per 1014 QUIC stream. This second option is much simpler to engineer. It 1015 will not require complex methods to correlate different streams, and 1016 it will ensure that the responses in the series are delivered in the 1017 intended order. However, it requires parsing the response stream to 1018 extract separate responses. The practical requirement would be that 1019 the content of the QUIC stream be exactly the same as the content of 1020 a TCP connection that would manage exactly one query. The main 1021 difference with the current proposal would be to insert a length 1022 field before each response. So we would get: 1024 o For a query: open a bidirectional stream, send the query encoded 1025 as { 16 bit length, DNS query }, mark this stream direction as 1026 finished. 1028 o For most responses: send the single response message encoded as { 1029 16 bit length, DNS response }, mark this stream direction as 1030 finished. 1032 o For a response to an AXFR query: send a series of response 1033 messages encoded as { 16 bit length, DNS response }, using the 1034 QDCOUNT convention as specified in [RFC5936], mark this stream 1035 direction as finished when the entire series is sent. 1037 This adds a length field that is not in the current draft, which 1038 breaks compatibility with the previous versions. Draft versions are 1039 identified by draft version specific ALPN, which makes this change 1040 manageable. However, the authors would like to get feedback from 1041 developers before making this change. 1043 The change will also add new error conditions: if the stream FIN 1044 happens before the bytes specified in the message length field are 1045 sent; if the client expects a single response message and several are 1046 sent; and, if the client expects AXFR responses but does not receive 1047 the expected pattern of QDCOUNT flagged messages. 1049 Authors' Addresses 1051 Christian Huitema 1052 Private Octopus Inc. 1053 427 Golfcourse Rd 1054 Friday Harbor WA 98250 1055 U.S.A 1057 Email: huitema@huitema.net 1059 Allison Mankin 1060 Salesforce 1062 Email: amankin@salesforce.com 1064 Sara Dickinson 1065 Sinodun IT 1066 Oxford Science Park 1067 Oxford OX4 4GA 1068 U.K. 1070 Email: sara@sinodun.com