diff options
Diffstat (limited to 'doc/rfc/rfc9250.txt')
| -rw-r--r-- | doc/rfc/rfc9250.txt | 1450 |
1 files changed, 1450 insertions, 0 deletions
diff --git a/doc/rfc/rfc9250.txt b/doc/rfc/rfc9250.txt new file mode 100644 index 0000000..1aed862 --- /dev/null +++ b/doc/rfc/rfc9250.txt @@ -0,0 +1,1450 @@ + + + + +Internet Engineering Task Force (IETF) C. Huitema +Request for Comments: 9250 Private Octopus Inc. +Category: Standards Track S. Dickinson +ISSN: 2070-1721 Sinodun IT + A. Mankin + Salesforce + May 2022 + + + DNS over Dedicated QUIC Connections + +Abstract + + This document describes the use of QUIC to provide transport + confidentiality for DNS. The encryption provided by QUIC has similar + properties to those provided by TLS, while QUIC transport eliminates + the head-of-line blocking issues inherent with TCP and provides more + efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has + privacy properties similar to DNS over TLS (DoT) specified in RFC + 7858, and latency characteristics similar to classic DNS over UDP. + This specification describes the use of DoQ as a general-purpose + transport for DNS and includes the use of DoQ for stub to recursive, + recursive to authoritative, and zone transfer scenarios. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9250. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Key Words + 3. Design Considerations + 3.1. Provide DNS Privacy + 3.2. Design for Minimum Latency + 3.3. Middlebox Considerations + 3.4. No Server-Initiated Transactions + 4. Specifications + 4.1. Connection Establishment + 4.1.1. Port Selection + 4.2. Stream Mapping and Usage + 4.2.1. DNS Message IDs + 4.3. DoQ Error Codes + 4.3.1. Transaction Cancellation + 4.3.2. Transaction Errors + 4.3.3. Protocol Errors + 4.3.4. Alternative Error Codes + 4.4. Connection Management + 4.5. Session Resumption and 0-RTT + 4.6. Message Sizes + 5. Implementation Requirements + 5.1. Authentication + 5.2. Fallback to Other Protocols on Connection Failure + 5.3. Address Validation + 5.4. Padding + 5.5. Connection Handling + 5.5.1. Connection Reuse + 5.5.2. Resource Management + 5.5.3. Using 0-RTT and Session Resumption + 5.5.4. Controlling Connection Migration for Privacy + 5.6. Processing Queries in Parallel + 5.7. Zone Transfer + 5.8. Flow Control Mechanisms + 6. Security Considerations + 7. Privacy Considerations + 7.1. Privacy Issues with 0-RTT data + 7.2. Privacy Issues with Session Resumption + 7.3. Privacy Issues with Address Validation Tokens + 7.4. Privacy Issues with Long Duration Sessions + 7.5. Traffic Analysis + 8. IANA Considerations + 8.1. Registration of a DoQ Identification String + 8.2. Reservation of a Dedicated Port + 8.3. Reservation of an Extended DNS Error Code: Too Early + 8.4. DNS-over-QUIC Error Codes Registry + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. The NOTIFY Service + Acknowledgements + Authors' Addresses + +1. Introduction + + Domain Name System (DNS) concepts are specified in "Domain names - + concepts and facilities" [RFC1034]. The transmission of DNS queries + and responses over UDP and TCP is specified in "Domain names - + implementation and specification" [RFC1035]. + + This document presents a mapping of the DNS protocol over the QUIC + transport [RFC9000] [RFC9001]. DNS over QUIC is referred to here as + DoQ, in line with "DNS Terminology" [DNS-TERMS]. + + The goals of the DoQ mapping are: + + 1. Provide the same DNS privacy protection as DoT [RFC7858]. This + includes an option for the client to authenticate the server by + means of an authentication domain name as specified in "Usage + Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. + + 2. Provide an improved level of source address validation for DNS + servers compared to classic DNS over UDP. + + 3. Provide a transport that does not impose path MTU limitations on + the size of DNS responses it can send. + + In order to achieve these goals, and to support ongoing work on + encryption of DNS, the scope of this document includes: + + * the "stub to recursive resolver" scenario (also called the "stub + to recursive" scenario in this document) + + * the "recursive resolver to authoritative nameserver" scenario + (also called the "recursive to authoritative" scenario in this + document), and + + * the "nameserver to nameserver" scenario (mainly used for zone + transfers (XFR) [RFC1995] [RFC5936]). + + In other words, this document specifies QUIC as a general-purpose + transport for DNS. + + The specific non-goals of this document are: + + 1. No attempt is made to evade potential blocking of DoQ traffic by + middleboxes. + + 2. No attempt to support server-initiated transactions, which are + used only in DNS Stateful Operations (DSO) [RFC8490]. + + Specifying the transmission of an application over QUIC requires + specifying how the application's messages are mapped to QUIC streams, + and generally how the application will use QUIC. This is done for + HTTP in "Hypertext Transfer Protocol Version 3 (HTTP/3)" [HTTP/3]. + The purpose of this document is to define the way DNS messages can be + transmitted over QUIC. + + DNS over HTTPS (DoH) [RFC8484] can be used with HTTP/3 to get some of + the benefits of QUIC. However, a lightweight direct mapping for DoQ + can be regarded as a more natural fit for both the recursive to + authoritative and zone transfer scenarios, which rarely involve + intermediaries. In these scenarios, the additional overhead of HTTP + is not offset by, for example, benefits of HTTP proxying and caching + behavior. + + In this document, Section 3 presents the reasoning that guided the + proposed design. Section 4 specifies the actual mapping of DoQ. + Section 5 presents guidelines on the implementation, usage, and + deployment of DoQ. + +2. Key Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Design Considerations + + This section and its subsections present the design guidelines that + were used for DoQ. While all other sections in this document are + normative, this section is informative in nature. + +3.1. Provide DNS Privacy + + DoT [RFC7858] defines how to mitigate some of the issues described in + "DNS Privacy Considerations" [RFC9076] by specifying how to transmit + DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS + over DTLS" [RFC8310] specify Strict and Opportunistic usage profiles + for DoT including how stub resolvers can authenticate recursive + resolvers. + + QUIC connection setup includes the negotiation of security parameters + using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001], + enabling encryption of the QUIC transport. Transmitting DNS messages + over QUIC will provide essentially the same privacy protections as + DoT [RFC7858] including Strict and Opportunistic usage profiles + [RFC8310]. Further discussion on this is provided in Section 7. + +3.2. Design for Minimum Latency + + QUIC is specifically designed to reduce protocol-induced delays, with + features such as: + + 1. Support for 0-RTT data during session resumption. + + 2. Support for advanced packet-loss recovery procedures as specified + in "QUIC Loss Detection and Congestion Control" [RFC9002]. + + 3. Mitigation of head-of-line blocking by allowing parallel delivery + of data on multiple streams. + + This mapping of DNS to QUIC will take advantage of these features in + three ways: + + 1. Optional support for sending 0-RTT data during session resumption + (the security and privacy implications of this are discussed in + later sections). + + 2. Long-lived QUIC connections over which multiple DNS transactions + are performed, generating the sustained traffic required to + benefit from advanced recovery features. + + 3. Mapping of each DNS Query/Response transaction to a separate + stream, to mitigate head-of-line blocking. This enables servers + to respond to queries "out of order". It also enables clients to + process responses as soon as they arrive, without having to wait + for in-order delivery of responses previously posted by the + server. + + These considerations are reflected in the mapping of DNS traffic to + QUIC streams in Section 4.2. + +3.3. Middlebox Considerations + + Using QUIC might allow a protocol to disguise its purpose from + devices on the network path using encryption and traffic analysis + resistance techniques like padding, traffic pacing, and traffic + shaping. This specification does not include any measures that are + designed to avoid such classification; the padding mechanisms defined + in Section 5.4 are intended to obfuscate the specific records + contained in DNS queries and responses, but not the fact that this is + DNS traffic. Consequently, firewalls and other middleboxes might be + able to distinguish DoQ from other protocols that use QUIC, like + HTTP, and apply different treatment. + + The lack of measures in this specification to avoid protocol + classification is not an endorsement of such practices. + +3.4. No Server-Initiated Transactions + + As stated in Section 1, this document does not specify support for + server-initiated transactions within established DoQ connections. + That is, only the initiator of the DoQ connection may send queries + over the connection. + + DSO does support server-initiated transactions within existing + connections. However, DoQ as defined here does not meet the criteria + for an applicable transport for DSO because it does not guarantee in- + order delivery of messages; see Section 4.2 of [RFC8490]. + +4. Specifications + +4.1. Connection Establishment + + DoQ connections are established as described in the QUIC transport + specification [RFC9000]. During connection establishment, DoQ + support is indicated by selecting the Application-Layer Protocol + Negotiation (ALPN) token "doq" in the crypto handshake. + +4.1.1. Port Selection + + By default, a DNS server that supports DoQ MUST listen for and accept + QUIC connections on the dedicated UDP port 853 (Section 8), unless + there is a mutual agreement to use another port. + + By default, a DNS client desiring to use DoQ with a particular server + MUST establish a QUIC connection to UDP port 853 on the server, + unless there is a mutual agreement to use another port. + + DoQ connections MUST NOT use UDP port 53. This recommendation + against use of port 53 for DoQ is to avoid confusion between DoQ and + the use of DNS over UDP [RFC1035]. The risk of confusion exists even + if two parties agreed on port 53, as other parties without knowledge + of that agreement might still try to use that port. + + In the stub to recursive scenario, the use of port 443 as a mutually + agreed alternative port can be operationally beneficial, since port + 443 is used by many services using QUIC and HTTP-3 and is thus less + likely to be blocked than other ports. Several mechanisms for stubs + to discover recursives offering encrypted transports, including the + use of custom ports, are the subject of ongoing work. + +4.2. Stream Mapping and Usage + + The mapping of DNS traffic over QUIC streams takes advantage of the + QUIC stream features detailed in Section 2 of [RFC9000], the QUIC + transport specification. + + DNS query/response traffic [RFC1034] [RFC1035] follows a simple + pattern in which the client sends a query, and the server provides + one or more responses (multiple responses can occur in zone + transfers). + + The mapping specified here requires that the client select a separate + QUIC stream for each query. The server then uses the same stream to + provide all the response messages for that query. In order for + multiple responses to be parsed, a 2-octet length field is used in + exactly the same way as the 2-octet length field defined for DNS over + TCP [RFC1035]. The practical result of this is that the content of + each QUIC stream is exactly the same as the content of a TCP + connection that would manage exactly one query. + + All DNS messages (queries and responses) sent over DoQ connections + MUST be encoded as a 2-octet length field followed by the message + content as specified in [RFC1035]. + + The client MUST select the next available client-initiated + bidirectional stream for each subsequent query on a QUIC connection, + in conformance with the QUIC transport specification [RFC9000]. + Packet losses and other network events might cause queries to arrive + in a different order. Servers SHOULD process queries as they arrive, + as not doing so would cause unnecessary delays. + + The client MUST send the DNS query over the selected stream and MUST + indicate through the STREAM FIN mechanism that no further data will + be sent on that stream. + + The server MUST send the response(s) on the same stream and MUST + indicate, after the last response, through the STREAM FIN mechanism + that no further data will be sent on that stream. + + Therefore, a single DNS transaction consumes a single bidirectional + client-initiated stream. This means that the client's first query + occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1 + of [RFC9000]). + + Servers MAY defer processing of a query until the STREAM FIN has been + indicated on the stream selected by the client. + + Servers and clients MAY monitor the number of "dangling" streams. + These are open streams where the following events have not occurred + after implementation-defined timeouts: + + * the expected queries or responses have not been received or, + + * the expected queries or responses have been received but not the + STREAM FIN + + Implementations MAY impose a limit on the number of such dangling + streams. If limits are encountered, implementations MAY close the + connection. + +4.2.1. DNS Message IDs + + When sending queries over a QUIC connection, the DNS Message ID MUST + be set to 0. The stream mapping for DoQ allows for unambiguous + correlation of queries and responses, so the Message ID field is not + required. + + This has implications for proxying DoQ messages to and from other + transports. For example, proxies may have to manage the fact that + DoQ can support a larger number of outstanding queries on a single + connection than, for example, DNS over TCP, because DoQ is not + limited by the Message ID space. This issue already exists for DoH, + where a Message ID of 0 is recommended. + + When forwarding a DNS message from DoQ over another transport, a DNS + Message ID MUST be generated according to the rules of the protocol + that is in use. When forwarding a DNS message from another transport + over DoQ, the Message ID MUST be set to 0. + +4.3. DoQ Error Codes + + The following error codes are defined for use when abruptly + terminating streams, for use as application protocol error codes when + aborting reading of streams, or for immediately closing connections: + + DOQ_NO_ERROR (0x0): No error. This is used when the connection or + stream needs to be closed, but there is no error to signal. + + DOQ_INTERNAL_ERROR (0x1): The DoQ implementation encountered an + internal error and is incapable of pursuing the transaction or the + connection. + + DOQ_PROTOCOL_ERROR (0x2): The DoQ implementation encountered a + protocol error and is forcibly aborting the connection. + + DOQ_REQUEST_CANCELLED (0x3): A DoQ client uses this to signal that + it wants to cancel an outstanding transaction. + + DOQ_EXCESSIVE_LOAD (0x4): A DoQ implementation uses this to signal + when closing a connection due to excessive load. + + DOQ_UNSPECIFIED_ERROR (0x5): A DoQ implementation uses this in the + absence of a more specific error code. + + DOQ_ERROR_RESERVED (0xd098ea5e): An alternative error code used for + tests. + + See Section 8.4 for details on registering new error codes. + +4.3.1. Transaction Cancellation + + In QUIC, sending STOP_SENDING requests that a peer cease transmission + on a stream. If a DoQ client wishes to cancel an outstanding + request, it MUST issue a QUIC STOP_SENDING, and it SHOULD use the + error code DOQ_REQUEST_CANCELLED. It MAY use a more specific error + code registered according to Section 8.4. The STOP_SENDING request + may be sent at any time but will have no effect if the server + response has already been sent, in which case the client will simply + discard the incoming response. The corresponding DNS transaction + MUST be abandoned. + + Servers that receive STOP_SENDING act in accordance with Section 3.5 + of [RFC9000]. Servers SHOULD NOT continue processing a DNS + transaction if they receive a STOP_SENDING. + + Servers MAY impose implementation limits on the total number or rate + of cancellation requests. If limits are encountered, servers MAY + close the connection. In this case, servers wanting to help client + debugging MAY use the error code DOQ_EXCESSIVE_LOAD. There is always + a trade-off between helping good faith clients debug issues and + allowing denial-of-service attackers to test server defenses; + depending on circumstances servers might very well choose to send + different error codes. + + Note that this mechanism provides a way for secondaries to cancel a + single zone transfer occurring on a given stream without having to + close the QUIC connection. + + Servers MUST NOT continue processing a DNS transaction if they + receive a RESET_STREAM request from the client before the client + indicates the STREAM FIN. The server MUST issue a RESET_STREAM to + indicate that the transaction is abandoned unless: + + * it has already done so for another reason or + + * it has already both sent the response and indicated the STREAM + FIN. + +4.3.2. Transaction Errors + + Servers normally complete transactions by sending a DNS response (or + responses) on the transaction's stream, including cases where the DNS + response indicates a DNS error. For example, a client SHOULD be + notified of a Server Failure (SERVFAIL, [RFC1035]) through a response + with the Response Code set to SERVFAIL. + + If a server is incapable of sending a DNS response due to an internal + error, it SHOULD issue a QUIC RESET_STREAM frame. The error code + SHOULD be set to DOQ_INTERNAL_ERROR. The corresponding DNS + transaction MUST be abandoned. Clients MAY limit the number of + unsolicited QUIC RESET_STREAM frames received on a connection before + choosing to close the connection. + + Note that this mechanism provides a way for primaries to abort a + single zone transfer occurring on a given stream without having to + close the QUIC connection. + +4.3.3. Protocol Errors + + Other error scenarios can occur due to malformed, incomplete, or + unexpected messages during a transaction. These include (but are not + limited to): + + * a client or server receives a message with a non-zero Message ID + + * a client or server receives a STREAM FIN before receiving all the + bytes for a message indicated in the 2-octet length field + + * a client receives a STREAM FIN before receiving all the expected + responses + + * a server receives more than one query on a stream + + * a client receives a different number of responses on a stream than + expected (e.g., multiple responses to a query for an A record) + + * a client receives a STOP_SENDING request + + * the client or server does not indicate the expected STREAM FIN + after sending requests or responses (see Section 4.2) + + * an implementation receives a message containing the edns-tcp- + keepalive EDNS(0) Option [RFC7828] (see Section 5.5.2) + + * a client or a server attempts to open a unidirectional QUIC stream + + * a server attempts to open a server-initiated bidirectional QUIC + stream + + * a server receives a "replayable" transaction in 0-RTT data (for + servers not willing to handle this case, see Section 4.5) + + If a peer encounters such an error condition, it is considered a + fatal error. It SHOULD forcibly abort the connection using QUIC's + CONNECTION_CLOSE mechanism and SHOULD use the DoQ error code + DOQ_PROTOCOL_ERROR. In some cases, it MAY instead silently abandon + the connection, which uses fewer of the local resources but makes + debugging at the offending node more difficult. + + It is noted that the restrictions on use of the above EDNS(0) option + has implications for proxying messages from TCP/DoT/DoH over DoQ. + +4.3.4. Alternative Error Codes + + This specification describes specific error codes in Sections 4.3.1, + 4.3.2, and 4.3.3. These error codes are meant to facilitate + investigation of failures and other incidents. New error codes may + be defined in future versions of DoQ or registered as specified in + Section 8.4. + + Because new error codes can be defined without negotiation, use of an + error code in an unexpected context or receipt of an unknown error + code MUST be treated as equivalent to DOQ_UNSPECIFIED_ERROR. + + Implementations MAY wish to test the support for the error code + extension mechanism by using error codes not listed in this document, + or they MAY use DOQ_ERROR_RESERVED. + +4.4. Connection Management + + Section 10 of [RFC9000], the QUIC transport specification, specifies + that connections can be closed in three ways: + + * idle timeout + + * immediate close + + * stateless reset + + Clients and servers implementing DoQ SHOULD negotiate use of the idle + timeout. Closing on idle timeout is done without any packet + exchange, which minimizes protocol overhead. Per Section 10.1 of + [RFC9000], the QUIC transport specification, the effective value of + the idle timeout is computed as the minimum of the values advertised + by the two endpoints. Practical considerations on setting the idle + timeout are discussed in Section 5.5.2. + + Clients SHOULD monitor the idle time incurred on their connection to + the server, defined by the time spent since the last packet from the + server has been received. When a client prepares to send a new DNS + query to the server, it SHOULD check whether the idle time is + sufficiently lower than the idle timer. If it is, the client SHOULD + send the DNS query over the existing connection. If not, the client + SHOULD establish a new connection and send the query over that + connection. + + Clients MAY discard their connections to the server before the idle + timeout expires. A client that has outstanding queries SHOULD close + the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and + the DoQ error code DOQ_NO_ERROR. + + Clients and servers MAY close the connection for a variety of other + reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers + that send packets over a connection discarded by their peer might + receive a stateless reset indication. If a connection fails, all the + in-progress transactions on that connection MUST be abandoned. + +4.5. Session Resumption and 0-RTT + + A client MAY take advantage of the session resumption and 0-RTT + mechanisms supported by QUIC transport [RFC9000] and QUIC TLS + [RFC9001] if the server supports them. Clients SHOULD consider + potential privacy issues associated with session resumption before + deciding to use this mechanism and specifically evaluate the trade- + offs presented in the various sections of this document. The privacy + issues are detailed in Sections 7.1 and 7.2, and the implementation + considerations are discussed in Section 5.5.3. + + The 0-RTT mechanism MUST NOT be used to send DNS requests that are + not "replayable" transactions. In this specification, only + transactions that have an OPCODE of QUERY or NOTIFY are considered + replayable; therefore, other OPCODES MUST NOT be sent in 0-RTT data. + See Appendix A for a detailed discussion of why NOTIFY is included + here. + + Servers MAY support session resumption, and MAY do that with or + without supporting 0-RTT, using the mechanisms described in + Section 4.6.1 of [RFC9001]. Servers supporting 0-RTT MUST NOT + immediately process non-replayable transactions received in 0-RTT + data but instead MUST adopt one of the following behaviors: + + * Queue the offending transaction and only process it after the QUIC + handshake has been completed, as defined in Section 4.1.1 of + [RFC9001]. + + * Reply to the offending transaction with a response code REFUSED + and an Extended DNS Error Code (EDE) "Too Early" using the + extended RCODE mechanisms defined in [RFC6891] and the extended + DNS errors defined in [RFC8914]; see Section 8.3. + + * Close the connection with the error code DOQ_PROTOCOL_ERROR. + +4.6. Message Sizes + + DoQ queries and responses are sent on QUIC streams, which in theory + can carry up to 2^62 bytes. However, DNS messages are restricted in + practice to a maximum size of 65535 bytes. This maximum size is + enforced by the use of a 2-octet message length field in DNS over TCP + [RFC1035] and DoT [RFC7858], and by the definition of the + "application/dns-message" for DoH [RFC8484]. DoQ enforces the same + restriction. + + The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] allow peers to + specify the UDP message size. This parameter is ignored by DoQ. DoQ + implementations always assume that the maximum message size is 65535 + bytes. + +5. Implementation Requirements + +5.1. Authentication + + For the stub to recursive scenario, the authentication requirements + are the same as described in DoT [RFC7858] and "Usage Profiles for + DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932] states that DNS + privacy services SHOULD provide credentials that clients can use to + authenticate the server. Given this, and to align with the + authentication model for DoH, DoQ stubs SHOULD use a Strict usage + profile. Client authentication for the encrypted stub to recursive + scenario is not described in any DNS RFC. + + For zone transfer, the authentication requirements are the same as + described in [RFC9103]. + + For the recursive to authoritative scenario, authentication + requirements are unspecified at the time of writing and are the + subject of ongoing work in the DPRIVE WG. + +5.2. Fallback to Other Protocols on Connection Failure + + If the establishment of the DoQ connection fails, clients MAY attempt + to fall back to DoT and then potentially cleartext, as specified in + DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS" + [RFC8310], depending on their usage profile. + + DNS clients SHOULD remember server IP addresses that don't support + DoQ. Mobile clients might also remember the lack of DoQ support by + given IP addresses on a per-context basis (e.g., per network or + provisioning domain). + + Timeouts, connection refusals, and QUIC handshake failures are + indicators that a server does not support DoQ. Clients SHOULD NOT + attempt DoQ queries to a server that does not support DoQ for a + reasonable period (such as one hour per server). DNS clients + following an out-of-band key-pinned usage profile [RFC7858] MAY be + more aggressive about retrying after DoQ connection failures. + +5.3. Address Validation + + Section 8 of [RFC9000], the QUIC transport specification, defines + Address Validation procedures to avoid servers being used in address + amplification attacks. DoQ implementations MUST conform to this + specification, which limits the worst-case amplification to a factor + 3. + + DoQ implementations SHOULD consider configuring servers to use the + Address Validation using Retry Packets procedure defined in + Section 8.1.2 of [RFC9000], the QUIC transport specification. This + procedure imposes a 1-RTT delay for verifying the return routability + of the source address of a client, similar to the DNS Cookies + mechanism [RFC7873]. + + DoQ implementations that configure Address Validation using Retry + Packets SHOULD implement the Address Validation for Future + Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC + transport specification. This defines how servers can send NEW_TOKEN + frames to clients after the client address is validated in order to + avoid the 1-RTT penalty during subsequent connections by the client + from the same address. + +5.4. Padding + + Implementations MUST protect against the traffic analysis attacks + described in Section 7.5 by the judicious injection of padding. This + could be done either by padding individual DNS messages using the + EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see + Section 19.1 of [RFC9000]). + + In theory, padding at the QUIC packet level could result in better + performance for the equivalent protection, because the amount of + padding can take into account non-DNS frames such as acknowledgements + or flow control updates, and also because QUIC packets can carry + multiple DNS messages. However, applications can only control the + amount of padding in QUIC packets if the implementation of QUIC + exposes adequate APIs. This leads to the following recommendations: + + * If the implementation of QUIC exposes APIs to set a padding + policy, DoQ SHOULD use that API to align the packet length to a + small set of fixed sizes. + + * If padding at the QUIC packet level is not available or not used, + DoQ MUST ensure that all DNS queries and responses are padded to a + small set of fixed sizes, using the EDNS(0) padding extension as + specified in [RFC7830]. + + Implementations might choose not to use a QUIC API for padding if it + is significantly simpler to reuse existing DNS message padding logic + that is applied to other encrypted transports. + + In the absence of a standard policy for padding sizes, + implementations SHOULD follow the recommendations of the Experimental + status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))" + [RFC8467]. While Experimental, these recommendations are referenced + because they are implemented and deployed for DoT and provide a way + for implementations to be fully compliant with this specification. + +5.5. Connection Handling + + "DNS Transport over TCP - Implementation Requirements" [RFC7766] + provides updated guidance on DNS over TCP, some of which is + applicable to DoQ. This section provides similar advice on + connection handling for DoQ. + +5.5.1. Connection Reuse + + Historic implementations of DNS clients are known to open and close + TCP connections for each DNS query. To amortize connection setup + costs, both clients and servers SHOULD support connection reuse by + sending multiple queries and responses over a single persistent QUIC + connection. + + In order to achieve performance on par with UDP, DNS clients SHOULD + send their queries concurrently over the QUIC streams on a QUIC + connection. That is, when a DNS client sends multiple queries to a + server over a QUIC connection, it SHOULD NOT wait for an outstanding + reply before sending the next query. + +5.5.2. Resource Management + + Proper management of established and idle connections is important to + the healthy operation of a DNS server. + + An implementation of DoQ SHOULD follow best practices similar to + those specified for DNS over TCP [RFC7766], in particular with regard + to: + + * Concurrent Connections (Section 6.2.2 of [RFC7766], updated by + Section 6.4 of [RFC9103]) + + * Security Considerations (Section 10 of [RFC7766]) + + Failure to do so may lead to resource exhaustion and denial of + service. + + Clients that want to maintain long duration DoQ connections SHOULD + use the idle timeout mechanisms defined in Section 10.1 of [RFC9000], + the QUIC transport specification. Clients and servers MUST NOT send + the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent + on a DoQ connection (because it is specific to the use of TCP/TLS as + a transport). + + This document does not make specific recommendations for timeout + values on idle connections. Clients and servers should reuse and/or + close connections depending on the level of available resources. + Timeouts may be longer during periods of low activity and shorter + during periods of high activity. + +5.5.3. Using 0-RTT and Session Resumption + + Using 0-RTT for DoQ has many compelling advantages. Clients can + establish connections and send queries without incurring a connection + delay. Servers can thus negotiate low values of the connection + timers, which reduces the total number of connections that they need + to manage. They can do that because the clients that use 0-RTT will + not incur latency penalties if new connections are required for a + query. + + Session resumption and 0-RTT data transmission create privacy risks + detailed in Sections 7.1 and 7.2. The following recommendations are + meant to reduce the privacy risks while enjoying the performance + benefits of 0-RTT data, subject to the restrictions specified in + Section 4.5. + + Clients SHOULD use resumption tickets only once, as specified in + Appendix C.4 of [RFC8446]. By default, clients SHOULD NOT use + session resumption if the client's connectivity has changed. + + Clients could receive address validation tokens from the server using + the NEW_TOKEN mechanism; see Section 8 of [RFC9000]. The associated + tracking risks are mentioned in Section 7.3. Clients SHOULD only use + the address validation tokens when they are also using session + resumption thus avoiding additional tracking risks. + + Servers SHOULD issue session resumption tickets with a sufficiently + long lifetime (e.g., 6 hours), so that clients are not tempted to + either keep the connection alive or frequently poll the server to + renew session resumption tickets. Servers SHOULD implement the anti- + replay mechanisms specified in Section 8 of [RFC8446]. + +5.5.4. Controlling Connection Migration for Privacy + + DoQ implementations might consider using the connection migration + features defined in Section 9 of [RFC9000]. These features enable + connections to continue operating as the client's connectivity + changes. As detailed in Section 7.4, these features trade off + privacy for latency. By default, clients SHOULD be configured to + prioritize privacy and start new sessions if their connectivity + changes. + +5.6. Processing Queries in Parallel + + As specified in Section 7 of [RFC7766] "DNS Transport over TCP - + Implementation Requirements", resolvers are RECOMMENDED to support + the preparing of responses in parallel and sending them out of order. + In DoQ, they do that by sending responses on their specific stream as + soon as possible, without waiting for availability of responses for + previously opened streams. + +5.7. Zone Transfer + + [RFC9103] specifies zone transfer over TLS (XoT) and includes updates + to [RFC1995] (IXFR), [RFC5936] (AXFR), and [RFC7766]. Considerations + relating to the reuse of XoT connections described there apply + analogously to zone transfers performed using DoQ connections. One + reason for reiterating such specific guidance is the lack of + effective connection reuse in existing TCP/TLS zone transfer + implementations today. The following recommendations apply: + + * DoQ servers MUST be able to handle multiple concurrent IXFR + requests on a single QUIC connection. + + * DoQ servers MUST be able to handle multiple concurrent AXFR + requests on a single QUIC connection. + + * DoQ implementations SHOULD + + - use the same QUIC connection for both AXFR and IXFR requests to + the same primary + + - send those requests in parallel as soon as they are queued, + i.e., do not wait for a response before sending the next query + on the connection (this is analogous to pipelining requests on + a TCP/TLS connection) + + - send the response(s) for each request as soon as they are + available, i.e., response streams MAY be sent intermingled + +5.8. Flow Control Mechanisms + + Servers and clients manage flow control using the mechanisms defined + in Section 4 of [RFC9000]. These mechanisms allow clients and + servers to specify how many streams can be created, how much data can + be sent on a stream, and how much data can be sent on the union of + all streams. For DoQ, controlling how many streams are created + allows servers to control how many new requests the client can send + on a given connection. + + Flow control exists to protect endpoint resources. For servers, + global and per-stream flow control limits control how much data can + be sent by clients. The same mechanisms allow clients to control how + much data can be sent by servers. Values that are too small will + unnecessarily limit performance. Values that are too large might + expose endpoints to overload or memory exhaustion. Implementations + or deployments will need to adjust flow control limits to balance + these concerns. In particular, zone transfer implementations will + need to control these limits carefully to ensure both large and + concurrent zone transfers are well managed. + + Initial values of parameters control how many requests and how much + data can be sent by clients and servers at the beginning of the + connection. These values are specified in transport parameters + exchanged during the connection handshake. The parameter values + received in the initial connection also control how many requests and + how much data can be sent by clients using 0-RTT data in a resumed + connection. Using too small values of these initial parameters would + restrict the usefulness of allowing 0-RTT data. + +6. Security Considerations + + A Threat Analysis of the Domain Name System is found in [RFC3833]. + This analysis was written before the development of DoT, DoH, and + DoQ, and probably needs to be updated. + + The security considerations of DoQ should be comparable to those of + DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub + to recursive scenario, but the considerations about person-in-the- + middle attacks, middleboxes, and caching of data from cleartext + connections also apply for DoQ to the resolver to authoritative + server scenario. As stated in Section 5.1, the authentication + requirements for securing zone transfer using DoQ are the same as + those for zone transfer over DoT; therefore, the general security + considerations are entirely analogous to those described in + [RFC9103]. + + DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports + by default the protections against downgrade attacks described in + [BCP195]. QUIC-specific issues and their mitigations are described + in Section 21 of [RFC9000]. + +7. Privacy Considerations + + The general considerations of encrypted transports provided in "DNS + Privacy Considerations" [RFC9076] apply to DoQ. The specific + considerations provided there do not differ between DoT and DoQ, and + they are not discussed further here. Similarly, "Recommendations for + DNS Privacy Service Operators" [RFC8932] (which covers operational, + policy, and security considerations for DNS privacy services) is also + applicable to DoQ services. + + QUIC incorporates the mechanisms of TLS 1.3 [RFC8446], and this + enables QUIC transmission of "0-RTT" data. This can provide + interesting latency gains, but it raises two concerns: + + 1. Adversaries could replay the 0-RTT data and infer its content + from the behavior of the receiving server. + + 2. The 0-RTT mechanism relies on TLS session resumption, which can + provide linkability between successive client sessions. + + These issues are developed in Sections 7.1 and 7.2. + +7.1. Privacy Issues with 0-RTT data + + The 0-RTT data can be replayed by adversaries. That data may trigger + queries by a recursive resolver to authoritative resolvers. + Adversaries may be able to pick a time at which the recursive + resolver outgoing traffic is observable and thus find out what name + was queried for in the 0-RTT data. + + This risk is in fact a subset of the general problem of observing the + behavior of the recursive resolver discussed in "DNS Privacy + Considerations" [RFC9076]. The attack is partially mitigated by + reducing the observability of this traffic. The mandatory replay + protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate + the risk of replay. 0-RTT packets can only be replayed within a + narrow window, which is only wide enough to account for variations in + clock skew and network transmission. + + The recommendation for TLS 1.3 [RFC8446] is that the capability to + use 0-RTT data should be turned off by default and only enabled if + the user clearly understands the associated risks. In the case of + DoQ, allowing 0-RTT data provides significant performance gains, and + there is a concern that a recommendation to not use it would simply + be ignored. Instead, a set of practical recommendations is provided + in Sections 4.5 and 5.5.3. + + The specifications in Section 4.5 block the most obvious risks of + replay attacks, as they only allow for transactions that will not + change the long-term state of the server. + + The attacks described above apply to the stub resolver to recursive + resolver scenario, but similar attacks might be envisaged in the + recursive resolver to authoritative resolver scenario, and the same + mitigations apply. + +7.2. Privacy Issues with Session Resumption + + The QUIC session resumption mechanism reduces the cost of re- + establishing sessions and enables 0-RTT data. There is a linkability + issue associated with session resumption, if the same resumption + token is used several times. Attackers on path between client and + server could observe repeated usage of the token and use that to + track the client over time or over multiple locations. + + The session resumption mechanism allows servers to correlate the + resumed sessions with the initial sessions and thus to track the + client. This creates a virtual long duration session. The series of + queries in that session can be used by the server to identify the + client. Servers can most probably do that already if the client + address remains constant, but session resumption tickets also enable + tracking after changes of the client's address. + + The recommendations in Section 5.5.3 are designed to mitigate these + risks. Using session tickets only once mitigates the risk of + tracking by third parties. Refusing to resume a session if addresses + change mitigates the incremental risk of tracking by the server (but + the risk of tracking by IP address remains). + + The privacy trade-offs here may be context specific. Stub resolvers + will have a strong motivation to prefer privacy over latency since + they often change location. However, recursive resolvers that use a + small set of static IP addresses are more likely to prefer the + reduced latency provided by session resumption and may consider this + a valid reason to use resumption tickets even if the IP address + changed between sessions. + + Encrypted zone transfer ([RFC9103]) explicitly does not attempt to + hide the identity of the parties involved in the transfer; at the + same time, such transfers are not particularly latency sensitive. + This means that applications supporting zone transfers may decide to + apply the same protections as stub to recursive applications. + +7.3. Privacy Issues with Address Validation Tokens + + QUIC specifies address validation mechanisms in Section 8 of + [RFC9000]. Use of an address validation token allows QUIC servers to + avoid an extra RTT for new connections. Address validation tokens + are typically tied to an IP address. QUIC clients normally only use + these tokens when setting up a new connection from a previously used + address. However, clients are not always aware that they are using a + new address. This could be due to NAT, or because the client does + not have an API available to check if the IP address has changed + (which can be quite often for IPv6). There is a linkability risk if + clients mistakenly use address validation tokens after unknowingly + moving to a new location. + + The recommendations in Section 5.5.3 mitigates this risk by tying the + usage of the NEW_TOKEN to that of session resumption, though this + recommendation does not cover the case where the client is unaware of + the address change. + +7.4. Privacy Issues with Long Duration Sessions + + A potential alternative to session resumption is the use of long + duration sessions: if a session remains open for a long time, new + queries can be sent without incurring connection establishment + delays. It is worth pointing out that the two solutions have similar + privacy characteristics. Session resumption may allow servers to + keep track of the IP addresses of clients, but long duration sessions + have the same effect. + + In particular, a DoQ implementation might take advantage of the + connection migration features of QUIC to maintain a session even if + the client's connectivity changes, for example, if the client + migrates from a Wi-Fi connection to a cellular network connection and + then to another Wi-Fi connection. The server would be able to track + the client location by monitoring the succession of IP addresses used + by the long duration connection. + + The recommendation in Section 5.5.4 mitigates the privacy concerns + related to long duration sessions using multiple client addresses. + +7.5. Traffic Analysis + + Even though QUIC packets are encrypted, adversaries can gain + information from observing packet lengths, in both queries and + responses, as well as packet timing. Many DNS requests are emitted + by web browsers. Loading a specific web page may require resolving + dozens of DNS names. If an application adopts a simple mapping of + one query or response per packet, or "one QUIC STREAM frame per + packet", then the succession of packet lengths may provide enough + information to identify the requested site. + + Implementations SHOULD use the mechanisms defined in Section 5.4 to + mitigate this attack. + +8. IANA Considerations + +8.1. Registration of a DoQ Identification String + + This document creates a new registration for the identification of + DoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) + Protocol IDs" registry [RFC7301]. + + The "doq" string identifies DoQ: + + Protocol: DoQ + + Identification Sequence: 0x64 0x6F 0x71 ("doq") + + Specification: This document + +8.2. Reservation of a Dedicated Port + + For both TCP and UDP, port 853 is currently reserved for "DNS query- + response protocol run over TLS/DTLS" [RFC7858]. + + However, the specification for DNS over DTLS (DoD) [RFC8094] is + experimental, limited to stub to resolver, and no implementations or + deployments currently exist to the authors' knowledge (even though + several years have passed since the specification was published). + + This specification additionally reserves the use of UDP port 853 for + DoQ. QUIC version 1 was designed to be able to coexist with other + protocols on the same port, including DTLS; see Section 17.2 of + [RFC9000]. This means that deployments that serve DoD and DoQ (QUIC + version 1) on the same port will be able to demultiplex the two due + to the second most significant bit in each UDP payload. Such + deployments ought to check the signatures of future versions or + extensions (e.g., [GREASING-QUIC]) of QUIC and DTLS before deploying + them to serve DNS on the same port. + + IANA has updated the following value in the "Service Name and + Transport Protocol Port Number Registry" in the System range. The + registry for that range requires IETF Review or IESG Approval + [RFC6335]. + + Service Name: domain-s + + Port Number: 853 + + Transport Protocol(s): UDP + + Assignee: IESG + + Contact: IETF Chair + + Description: DNS query-response protocol run over DTLS or QUIC + + Reference: [RFC7858][RFC8094] This document + + Additionally, IANA has updated the Description field for the + corresponding TCP port 853 allocation to be "DNS query-response + protocol run over TLS" and removed [RFC8094] from the TCP + allocation's Reference field for consistency and clarity. + +8.3. Reservation of an Extended DNS Error Code: Too Early + + IANA has registered the following value in the "Extended DNS Error + Codes" registry [RFC8914]: + + INFO-CODE: 26 + + Purpose: Too Early + + Reference: This document + +8.4. DNS-over-QUIC Error Codes Registry + + IANA has added a registry for "DNS-over-QUIC Error Codes" on the + "Domain Name System (DNS) Parameters" web page. + + The "DNS-over-QUIC Error Codes" registry governs a 62-bit space. + This space is split into three regions that are governed by different + policies: + + * Permanent registrations for values between 0x00 and 0x3f (in + hexadecimal; inclusive), which are assigned using Standards Action + or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126] + + * Permanent registrations for values larger than 0x3f, which are + assigned using the Specification Required policy ([RFC8126]) + + * Provisional registrations for values larger than 0x3f, which + require Expert Review, as defined in Section 4.5 of [RFC8126]. + + Provisional reservations share the range of values larger than 0x3f + with some permanent registrations. This is by design to enable + conversion of provisional registrations into permanent registrations + without requiring changes in deployed systems. (This design is + aligned with the principles set in Section 22 of [RFC9000].) + + Registrations in this registry MUST include the following fields: + + Value: The assigned codepoint + + Status: "Permanent" or "Provisional" + + Contact: Contact details for the registrant + + In addition, permanent registrations MUST include: + + Error: A short mnemonic for the parameter + + Specification: A reference to a publicly available specification for + the value (optional for provisional registrations) + + Description: A brief description of the error code semantics, which + MAY be a summary if a specification reference is provided + + Provisional registrations of codepoints are intended to allow for + private use and experimentation with extensions to DoQ. However, + provisional registrations could be reclaimed and reassigned for other + purposes. In addition to the parameters listed above, provisional + registrations MUST include: + + Date: The date of last update to the registration + + A request to update the date on any provisional registration can be + made without review from the designated expert(s). + + The initial content of this registry is shown in Table 1 and all + entries share the following fields: + + Status: Permanent + + Contact: DPRIVE WG + + Specification: Section 4.3 + + +============+=======================+=============================+ + | Value | Error | Description | + +============+=======================+=============================+ + | 0x0 | DOQ_NO_ERROR | No error | + +------------+-----------------------+-----------------------------+ + | 0x1 | DOQ_INTERNAL_ERROR | Implementation error | + +------------+-----------------------+-----------------------------+ + | 0x2 | DOQ_PROTOCOL_ERROR | Generic protocol violation | + +------------+-----------------------+-----------------------------+ + | 0x3 | DOQ_REQUEST_CANCELLED | Request cancelled by client | + +------------+-----------------------+-----------------------------+ + | 0x4 | DOQ_EXCESSIVE_LOAD | Closing a connection for | + | | | excessive load | + +------------+-----------------------+-----------------------------+ + | 0x5 | DOQ_UNSPECIFIED_ERROR | No error reason specified | + +------------+-----------------------+-----------------------------+ + | 0xd098ea5e | DOQ_ERROR_RESERVED | Alternative error code used | + | | | for tests | + +------------+-----------------------+-----------------------------+ + + Table 1: Initial DNS-over-QUIC Error Codes Entries + +9. References + +9.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + <https://www.rfc-editor.org/info/rfc1034>. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + DOI 10.17487/RFC1995, August 1996, + <https://www.rfc-editor.org/info/rfc1995>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol + (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, + <https://www.rfc-editor.org/info/rfc5936>. + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, + <https://www.rfc-editor.org/info/rfc6891>. + + [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, + "Transport Layer Security (TLS) Application-Layer Protocol + Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, + July 2014, <https://www.rfc-editor.org/info/rfc7301>. + + [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and + D. Wessels, "DNS Transport over TCP - Implementation + Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, + <https://www.rfc-editor.org/info/rfc7766>. + + [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, + DOI 10.17487/RFC7830, May 2016, + <https://www.rfc-editor.org/info/rfc7830>. + + [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., + and P. Hoffman, "Specification for DNS over Transport + Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May + 2016, <https://www.rfc-editor.org/info/rfc7858>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles + for DNS over TLS and DNS over DTLS", RFC 8310, + DOI 10.17487/RFC8310, March 2018, + <https://www.rfc-editor.org/info/rfc8310>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms + for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, + October 2018, <https://www.rfc-editor.org/info/rfc8467>. + + [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. + Lawrence, "Extended DNS Errors", RFC 8914, + DOI 10.17487/RFC8914, October 2020, + <https://www.rfc-editor.org/info/rfc8914>. + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + <https://www.rfc-editor.org/info/rfc9000>. + + [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure + QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, + <https://www.rfc-editor.org/info/rfc9001>. + + [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. + Mankin, "DNS Zone Transfer over TLS", RFC 9103, + DOI 10.17487/RFC9103, August 2021, + <https://www.rfc-editor.org/info/rfc9103>. + +9.2. Informative References + + [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, May 2015. + + Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS + 1.1", BCP 195, RFC 8996, March 2021. + + <https://www.rfc-editor.org/info/bcp195> + + [DNS-TERMS] + Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in + Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03, + 28 September 2021, <https://datatracker.ietf.org/doc/html/ + draft-ietf-dnsop-rfc8499bis-03>. + + [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG + mailing list, 6 April 2016, <https://www.ietf.org/mail- + archive/web/dns-privacy/current/msg01276.html>. + + [GREASING-QUIC] + Thomson, M., "Greasing the QUIC Bit", Work in Progress, + Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November + 2021, <https://datatracker.ietf.org/doc/html/draft-ietf- + quic-bit-grease-02>. + + [HTTP/3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 + (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- + quic-http-34, 2 February 2021, + <https://datatracker.ietf.org/doc/html/draft-ietf-quic- + http-34>. + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, + August 1996, <https://www.rfc-editor.org/info/rfc1996>. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August + 2004, <https://www.rfc-editor.org/info/rfc3833>. + + [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. + Cheshire, "Internet Assigned Numbers Authority (IANA) + Procedures for the Management of the Service Name and + Transport Protocol Port Number Registry", BCP 165, + RFC 6335, DOI 10.17487/RFC6335, August 2011, + <https://www.rfc-editor.org/info/rfc6335>. + + [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The + edns-tcp-keepalive EDNS0 Option", RFC 7828, + DOI 10.17487/RFC7828, April 2016, + <https://www.rfc-editor.org/info/rfc7828>. + + [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) + Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, + <https://www.rfc-editor.org/info/rfc7873>. + + [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram + Transport Layer Security (DTLS)", RFC 8094, + DOI 10.17487/RFC8094, February 2017, + <https://www.rfc-editor.org/info/rfc8094>. + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + <https://www.rfc-editor.org/info/rfc8484>. + + [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., + Lemon, T., and T. Pusateri, "DNS Stateful Operations", + RFC 8490, DOI 10.17487/RFC8490, March 2019, + <https://www.rfc-editor.org/info/rfc8490>. + + [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and + A. Mankin, "Recommendations for DNS Privacy Service + Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, + October 2020, <https://www.rfc-editor.org/info/rfc8932>. + + [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection + and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, + May 2021, <https://www.rfc-editor.org/info/rfc9002>. + + [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, + DOI 10.17487/RFC9076, July 2021, + <https://www.rfc-editor.org/info/rfc9076>. + +Appendix A. The NOTIFY Service + + This appendix discusses why it is considered acceptable to send + NOTIFY (see [RFC1996]) in 0-RTT data. + + Section 4.5 says "The 0-RTT mechanism MUST NOT be used to send DNS + requests that are not "replayable" transactions". This specification + supports sending a NOTIFY in 0-RTT data because although a NOTIFY + technically changes the state of the receiving server, the effect of + replaying NOTIFYs has negligible impact in practice. + + NOTIFY messages prompt a secondary to either send an SOA query or an + XFR request to the primary on the basis that a newer version of the + zone is available. It has long been recognized that NOTIFYs can be + forged and, in theory, used to cause a secondary to send repeated + unnecessary requests to the primary. For this reason, most + implementations have some form of throttling of the SOA/XFR queries + triggered by the receipt of one or more NOTIFYs. + + [RFC9103] describes the privacy risks associated with both NOTIFY and + SOA queries and does not include addressing those risks within the + scope of encrypting zone transfers. Given this, the privacy benefit + of using DoQ for NOTIFY is not clear, but for the same reason, + sending NOTIFY as 0-RTT data has no privacy risk above that of + sending it using cleartext DNS. + +Acknowledgements + + This document liberally borrows text from the HTTP/3 specification + [HTTP/3] edited by Mike Bishop and from the DoT specification + [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, Allison + Mankin, Duane Wessels, and Paul Hoffman. + + The privacy issue with 0-RTT data and session resumption was analyzed + by Daniel Kahn Gillmor (DKG) in a message to the IETF DPRIVE Working + Group [DNS0RTT]. + + Thanks to Tony Finch for an extensive review of the initial draft + version of this document, and to Robert Evans for the discussion of + 0-RTT privacy issues. Early reviews by Paul Hoffman and Martin + Thomson and interoperability tests conducted by Stephane Bortzmeyer + helped improve the definition of the protocol. + + Thanks also to Martin Thomson and Martin Duke for their later reviews + focusing on the low-level QUIC details, which helped clarify several + aspects of DoQ. Thanks to Andrey Meshkov, Loganaden Velvindron, + Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell, and + Phillip Hallam-Baker for their reviews and contributions. + +Authors' Addresses + + Christian Huitema + Private Octopus Inc. + 427 Golfcourse Rd + Friday Harbor, WA 98250 + United States of America + Email: huitema@huitema.net + + + Sara Dickinson + Sinodun IT + Oxford Science Park + Oxford + OX4 4GA + United Kingdom + Email: sara@sinodun.com + + + Allison Mankin + Salesforce + Email: allison.mankin@gmail.com |