RFC 8490
DNS Stateful Operations
Internet Engineering Task Force (IETF) R. Bellis Request for Comments: 8490 ISC Updates: 1035, 7766 S. Cheshire Category: Standards Track Apple Inc. ISSN: 2070-1721 J. Dickinson S. Dickinson Sinodun T. Lemon Nibbhaya Consulting T. Pusateri Unaffiliated March 2019 DNS Stateful OperationsAbstract
This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts. 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/rfc8490.
Copyright Notice Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Session Management . . . . . . . . . . . . . . . . . 9 4.1.2. Long-Lived Subscriptions . . . . . . . . . . . . . . 9 4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12 5.1.1. DSO Session Establishment Failure . . . . . . . . . . 13 5.1.2. DSO Session Establishment Success . . . . . . . . . . 14 5.2. Operations after DSO Session Establishment . . . . . . . 14 5.3. DSO Session Termination . . . . . . . . . . . . . . . . . 15 5.3.1. Handling Protocol Errors . . . . . . . . . . . . . . 15 5.4. Message Format . . . . . . . . . . . . . . . . . . . . . 16 5.4.1. DNS Header Fields in DSO Messages . . . . . . . . . . 17 5.4.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 18 5.4.3. DSO Unidirectional Messages . . . . . . . . . . . . . 20 5.4.4. TLV Syntax . . . . . . . . . . . . . . . . . . . . . 21 5.4.5. Unrecognized TLVs . . . . . . . . . . . . . . . . . . 22 5.4.6. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 23 5.5. Message Handling . . . . . . . . . . . . . . . . . . . . 24 5.5.1. Delayed Acknowledgement Management . . . . . . . . . 25 5.5.2. MESSAGE ID Namespaces . . . . . . . . . . . . . . . . 26 5.5.3. Error Responses . . . . . . . . . . . . . . . . . . . 27 5.6. Responder-Initiated Operation Cancellation . . . . . . . 28 6. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 29 6.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 29 6.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 30 6.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 31
6.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 32
6.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 32
6.4.2. Values for the Inactivity Timeout . . . . . . . . . . 33
6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 34
6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 34
6.5.2. Values for the Keepalive Interval . . . . . . . . . . 34
6.6. Server-Initiated DSO Session Termination . . . . . . . . 36
6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 37
6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 38
6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 38
7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 40
7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 40
7.1.1. Client Handling of Received Session Timeout Values . 42
7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option . . 43
7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Retry Delay TLV Used as a Primary TLV . . . . . . . . 44
7.2.2. Retry Delay TLV Used as a Response Additional TLV . . 46
7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 46
8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 47
8.1. QR Bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 47
8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Additional Considerations . . . . . . . . . . . . . . . . . . 50
9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 50
9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 51
9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 52
9.4. Operational Considerations for Middleboxes . . . . . . . 53
9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 57
10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 57
10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 57
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
11.1. TLS Zero Round-Trip Considerations . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction
This document specifies a mechanism for managing stateful DNS connections. DNS most commonly operates over a UDP transport, but it can also operate over streaming transports; the original DNS RFC specifies DNS-over-TCP [RFC1035], and a profile for DNS-over-TLS [RFC7858] has been specified. These transports can offer persistent long-lived sessions and therefore, when using them for transporting DNS messages, it is of benefit to have a mechanism that can establish parameters associated with those sessions, such as timeouts. In such situations, it is also advantageous to support server-initiated messages (such as DNS Push Notifications [Push]). The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is explicitly defined to only have "per-message" semantics. While EDNS(0) has been used to signal at least one session-related parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), the result is less than optimal due to the restrictions imposed by the EDNS(0) semantics and the lack of server-initiated signaling. For example, a server cannot arbitrarily instruct a client to close a connection because the server can only send EDNS(0) options in responses to queries that contained EDNS(0) options. This document defines a new DNS OPCODE for DNS Stateful Operations (DSO) with a value of 6. DSO messages are used to communicate operations within persistent stateful sessions, expressed using Type Length Value (TLV) syntax. This document defines an initial set of three TLVs used to manage session timeouts, termination, and encryption padding. All three TLVs defined here are mandatory for all implementations of DSO. Further TLVs may be defined in additional specifications. DSO messages may or may not be acknowledged. Whether a DSO message is to be acknowledged (a DSO request message) or is not to be acknowledged (a DSO unidirectional message) is specified in the definition of that particular DSO message type. The MESSAGE ID is nonzero for DSO request messages, and zero for DSO unidirectional messages. Messages are pipelined and responses may appear out of order when multiple requests are being processed concurrently. The format for DSO messages (Section 5.4) differs somewhat from the traditional DNS message format used for standard queries and responses. The standard twelve-byte header is used, but the four count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero, and accordingly their corresponding sections are not present.
The actual data pertaining to DNS Stateful Operations (expressed in TLV syntax) is appended to the end of the DNS message header. Just as in traditional DNS-over-TCP [RFC1035] [RFC7766], the stream protocol carrying DSO messages (which are just another kind of DNS message) frames them by putting a 16-bit message length at the start. The length of the DSO message is therefore determined from that length rather than from any of the DNS header counts. When displayed using packet analyzer tools that have not been updated to recognize the DSO format, this will result in the DSO data being displayed as unknown extra data after the end of the DNS message. This new format has distinct advantages over an RR-based format because it is more explicit and more compact. Each TLV definition is specific to its use case and, as a result, contains no redundant or overloaded fields. Importantly, it completely avoids conflating DNS Stateful Operations in any way with normal DNS operations or with existing EDNS(0)-based functionality. A goal of this approach is to avoid the operational issues that have befallen EDNS(0), particularly relating to middlebox behavior (see sections discussing EDNS(0), and problems caused by firewalls and load balancers, in the recent work describing causes of DNS failures [Fail]). With EDNS(0), multiple options may be packed into a single OPT pseudo-RR, and there is no generalized mechanism for a client to be able to tell whether a server has processed or otherwise acted upon each individual option within the combined OPT pseudo-RR. The specifications for each individual option need to define how each different option is to be acknowledged, if necessary. In contrast to EDNS(0), with DSO there is no compelling motivation to pack multiple operations into a single message for efficiency reasons, because DSO always operates using a connection-oriented transport protocol. Each DSO operation is communicated in its own separate DNS message, and the transport protocol can take care of packing several DNS messages into a single IP packet if appropriate. For example, TCP can pack multiple small DNS messages into a single TCP segment. This simplification allows for clearer semantics. Each DSO request message communicates just one primary operation, and the RCODE in the corresponding response message indicates the success or failure of that operation.
2. Requirements Language
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. Terminology
DSO: DNS Stateful Operations. connection: a bidirectional byte (or message) stream, where the bytes (or messages) are delivered reliably and in order, such as provided by using DNS-over-TCP [RFC1035] [RFC7766] or DNS-over-TLS [RFC7858]. session: the unqualified term "session" in the context of this document refers to a persistent network connection between two endpoints that allows for the exchange of DNS messages over a connection where either end of the connection can send messages to the other end. (The term has no relationship to the "session layer" of the OSI "seven-layer model".) DSO Session: a session established between two endpoints that acknowledge persistent DNS state via the exchange of DSO messages over the connection. This is distinct from a DNS-over-TCP session as described in the previous specification for DNS-over-TCP [RFC7766]. close gracefully: a normal session shutdown where the client closes the TCP connection to the server using a graceful close such that no data is lost (e.g., using TCP FIN; see Section 5.3). forcibly abort: a session shutdown as a result of a fatal error where the TCP connection is unilaterally aborted without regard for data loss (e.g., using TCP RST; see Section 5.3). server: the software with a listening socket, awaiting incoming connection requests, in the usual DNS sense. client: the software that initiates a connection to the server's listening socket, in the usual DNS sense. initiator: the software that sends a DSO request message or a DSO unidirectional message during a DSO Session. Either a client or server can be an initiator.
responder: the software that receives a DSO request message or a DSO
unidirectional message during a DSO Session. Either a client or a
server can be a responder.
sender: the software that is sending a DNS message, a DSO message, a
DNS response, or a DSO response.
receiver: the software that is receiving a DNS message, a DSO
message, a DNS response, or a DSO response.
service instance: a specific instance of server software running on
a specific host (Section 9.1).
long-lived operation: an outstanding operation on a DSO Session
where either the client or server, acting as initiator, has
requested that the responder send new information regarding the
request, as it becomes available.
early data: a TLS 1.3 handshake containing data on the first flight
that begins a DSO Session (Section 2.3 of the TLS 1.3
specification [RFC8446]). TCP Fast Open [RFC7413] is only
permitted when using TLS.
DNS message: any DNS message, including DNS queries, responses,
updates, DSO messages, etc.
DNS request message: any DNS message where the QR bit is 0.
DNS response message: any DNS message where the QR bit is 1.
DSO message: a DSO request message, DSO unidirectional message, or
DSO response to a DSO request message. If the QR bit is 1 in a
DSO message, it is a DSO response message. If the QR bit is 0 in
a DSO message, it is a DSO request message or DSO unidirectional
message, as determined by the specification of its Primary TLV.
DSO response message: a response to a DSO request message.
DSO request message: a DSO message that requires a response.
DSO unidirectional message: a DSO message that does not require and
cannot induce a response.
Primary TLV: the first TLV in a DSO request message or DSO
unidirectional message; this determines the nature of the
operation being performed.
Additional TLV: any TLVs that follow the Primary TLV in a DSO
request message or DSO unidirectional message.
Response Primary TLV: in a DSO response, any TLVs with the same DSO-
TYPE as the Primary TLV from the corresponding DSO request
message. If present, any Response Primary TLV(s) MUST appear
first in the DSO response message, before any Response Additional
TLVs.
Response Additional TLV: any TLVs in a DSO response that follow the
(optional) Response Primary TLV(s).
inactivity timer: the time since the most recent non-keepalive DNS
message was sent or received (see Section 6.4).
keepalive timer: the time since the most recent DNS message was sent
or received (see Section 6.5).
session timeouts: the inactivity timer and the keepalive timer.
inactivity timeout: the maximum value that the inactivity timer can
have before the connection is gracefully closed.
keepalive interval: the maximum value that the keepalive timer can
have before the client is required to send a keepalive (see
Section 7.1).
resetting a timer: setting the timer value to zero and restarting
the timer.
clearing a timer: setting the timer value to zero but not restarting
the timer.
4. Applicability
DNS Stateful Operations are applicable to several known use cases and are only applicable on transports that are capable of supporting a DSO Session.4.1. Use Cases
Several use cases for DNS Stateful Operations are described below.4.1.1. Session Management
In one use case, establishing session parameters such as server- defined timeouts is of great use in the general management of persistent connections. For example, using DSO Sessions for stub-to- recursive DNS-over-TLS [RFC7858] is more flexible for both the client and the server than attempting to manage sessions using just the edns-tcp-keepalive EDNS(0) Option [RFC7828]. The simple set of TLVs defined in this document is sufficient to greatly enhance connection management for this use case.4.1.2. Long-Lived Subscriptions
In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763] has evolved into a naturally session-based mechanism where, for example, long-lived subscriptions lend themselves to 'push' mechanisms as opposed to polling. Long-lived stateful connections and server-initiated messages align with this use case [Push]. A general use case is that DNS traffic is often bursty, but session establishment can be expensive. One challenge with long-lived connections is sustaining sufficient traffic to maintain NAT and firewall state. To mitigate this issue, this document introduces a new concept for the DNS -- DSO "keepalive traffic". This traffic carries no DNS data and is not considered 'activity' in the classic DNS sense, but it serves to maintain state in middleboxes and to assure the client and server that they still have connectivity to each other.
4.2. Applicable Transports
DNS Stateful Operations are applicable in cases where it is useful to maintain an open session between a DNS client and server, where the transport allows such a session to be maintained, and where the transport guarantees in-order delivery of messages on which DSO depends. Two specific transports that meet the requirements to support DNS Stateful Operations are DNS-over-TCP [RFC1035] [RFC7766] and DNS-over-TLS [RFC7858]. Note that in the case of DNS-over-TLS, there is no mechanism for upgrading from DNS-over-TCP to DNS-over-TLS mid-connection (see Section 7 of the DNS-over-TLS specification [RFC7858]). A connection is either DNS-over-TCP from the start, or DNS-over-TLS from the start. DNS Stateful Operations are not applicable for transports that cannot support clean session semantics or that do not guarantee in-order delivery. While in principle such a transport could be constructed over UDP, the current specification of DNS-over-UDP [RFC1035] does not provide in-order delivery or session semantics and hence cannot be used. Similarly, DNS-over-HTTP [RFC8484] cannot be used because HTTP has its own mechanism for managing sessions, which is incompatible with the mechanism specified here. Only DNS-over-TCP and DNS-over-TLS are currently defined for use with DNS Stateful Operations. Other transports may be added in the future if they meet the requirements set out in the first paragraph of this section.
(next page on part 2)
