RFC 8490
DNS Stateful Operations
Hey bestie, welcome to RFC 8490 🎀
This one is DNS Stateful Operations, published in March 2019 with ISSN 2070-1721 📚. It's a Standards Track doc, so it's the real deal and not a suggestion 💅
The authors are a whole squad: R. Bellis (ISC), S. Cheshire (Apple Inc.), J. Dickinson and S. Dickinson (Sinodun), T. Lemon (Nibbhaya Consulting), and T. Pusateri (Unaffiliated) 🫶
It updates RFC 1035 and RFC 7766 ✨. So it's building on what already exists, not replacing it.
Abstract 🎀
Okay so this doc creates a brand new DNS OPCODE called DNS Stateful Operations (DSO) 🦋 DSO messages talk about operations inside long-lived stateful sessions, and they use Type Length Value (TLV) syntax. There are three TLVs that handle session timeouts, session termination, and encryption padding, plus a framework so new stateful operations can be added later 🧚
It updates RFC 1035 by adding a new DNS header OPCODE with different message semantics and a new result code 🔥. It also updates RFC 7766 by redefining what a session is, giving new guidance on connection reuse, and adding 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 got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. For more on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to give feedback, go to 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) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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- Introduction ✨
okay bestie, so this doc is about managing stateful DNS connections 💖 DNS usually runs over UDP, but it can also run over streaming transports. The original DNS spec covers DNS-over-TCP [RFC1035], and there's a profile for DNS-over-TLS [RFC7858] too. These transports can keep long-lived sessions going, so when you're using them for DNS messages it's super useful to have a way to set up session parameters, like timeouts 🕰️. In those situations it's also really handy to let the server start messages on its own (like DNS Push Notifications [Push]) 🔔
The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is explicitly defined to only have "per-message" semantics 🙃. EDNS(0) has been used to signal at least one session-related parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), but it's giving "not quite": the EDNS(0) semantics are restrictive and there's no 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 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]). We are NOT doing that messy vibe again, periodt 💀
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 👑.
- 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 📚.
- 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). Yikes 😱
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.
- 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. literally the glow-up we needed ✨
4.1.2. Long-Lived Subscriptions 🔔
Okay so DNS-based Service Discovery (DNS-SD) [RFC6763] has totally glowed up into a naturally session-based mechanism 💅. Long-lived subscriptions are perfect for 'push' mechanisms instead of polling, and long-lived stateful connections with server-initiated messages match this use case [Push]. ✨
Here's the general vibe: DNS traffic is often bursty, but session establishment can be expensive 😭. A big struggle with long-lived connections is keeping enough traffic going to maintain NAT and firewall state. So to fix that, this document introduces a brand new concept for DNS: DSO "keepalive traffic" 🫶. This traffic carries no DNS data and isn't 'activity' in the classic DNS sense, but it keeps state alive in middleboxes and reassures the client and server that they still have connectivity to each other 🦋.
4.2. Applicable Transports
DNS Stateful Operations are applicable when it's useful to keep an open session between a DNS client and server, when the transport lets that session be maintained, and when the transport guarantees in-order delivery of messages (which DSO depends on). Two specific transports meet the requirements to support DNS Stateful Operations: DNS-over-TCP [RFC1035] [RFC7766] and DNS-over-TLS [RFC7858]. 🌸
Heads up, bestie: with DNS-over-TLS, there's 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 can't support clean session semantics or don't guarantee in-order delivery. In principle, a transport like that could be built over UDP, but the current specification of DNS-over-UDP [RFC1035] doesn't provide in-order delivery or session semantics, so it can't be used. Similarly, DNS-over-HTTP [RFC8484] can't 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. 🧚
5. Protocol Details 🌈
The overall flow of DNS Stateful Operations goes through a series of phases:
- Connection Establishment: A client establishes a connection to a server (Section 4.2).
- Connected but Sessionless: A connection exists, but a DSO Session has not been established. DNS messages can be sent from the client to server, and DNS responses can be sent from the server to the client. In this state, a client that wishes to use DSO can attempt to establish a DSO Session (Section 5.1). Standard DNS-over-TCP inactivity timeout handling is in effect [RFC7766] (see Section 7.1.2 of this document).
- DSO Session Establishment in Progress: A client has sent a DSO request within the last 30 seconds, but has not yet received a DSO response for that request. In this phase, the client may send more DSO requests and more DNS requests, but MUST NOT send DSO unidirectional messages (Section 5.1).
- DSO Session Establishment Timeout: A client has sent a DSO request, and after 30 seconds has still received no DSO response for that request. This means the server is now in an indeterminate state. The client forcibly aborts the connection. The client MAY reconnect without using DSO, if appropriate.
- DSO Session Establishment Failed: A client has sent a DSO request, and received a corresponding DSO response with a nonzero RCODE. This means the attempt to establish the DSO Session did not succeed. At this point, the client is permitted to continue operating without a DSO Session (Connected but Sessionless) but does not send further DSO messages (Section 5.1). 😤
- DSO Session Established: A client has sent a DSO request, and received a corresponding DSO response with RCODE set to NOERROR (0). A DSO Session has now been successfully established. Both client and server may send DSO messages and DNS messages; both may send replies in response to messages they receive (Section 5.2). The inactivity timer (Section 6.4) is active; the keepalive timer (Section 6.5) is active. Standard DNS-over-TCP inactivity timeout handling is no longer in effect [RFC7766] (see Section 7.1.2 of this document). ✨👑
- Server Shutdown: The server has decided to gracefully terminate the session and has sent the client a Retry Delay message (Section 6.6.1). There may still be unprocessed messages from the client; the server will ignore these. The server will not send any further messages to the client (Section 6.6.1.1).
- Client Shutdown: The client has decided to disconnect, either because it no longer needs service, the connection is inactive (Section 6.4.1), or because the server sent it a Retry Delay message (Section 6.6.1). The client closes the connection gracefully (Section 5.3). 👋
- Reconnect: The client disconnected as a result of a server shutdown. The client either waits for the server-specified Retry Delay to expire (Section 6.6.3) or contacts a different server instance. If the client no longer needs service, it does not reconnect.
- Forcibly Abort: The client or server detected a protocol error, and further communication would have undefined behavior. The client or server forcibly aborts the connection (Section 5.3). 🚨
- Abort Reconnect Wait: The client has forcibly aborted the connection but still needs service. Or, the server forcibly aborted the connection, but the client still needs service. The client either connects to a different service instance (Section 9.1) or waits to reconnect (Section 6.6.3.1). 🥺
5.1. DSO Session Establishment
In order for a session to be established between a client and a server, the client first has to establish a connection to the server using an applicable transport (see Section 4.2). 🔗
In some environments, it may be known in advance, by external means, that both client and server support DSO. In those cases, either client or server may initiate DSO messages at any time. The session is established as soon as the connection is established; this is referred to as implicit DSO Session establishment. 🌟
In the typical case, though, a server won't know in advance whether a client supports DSO. So in general, unless it's known in advance by other means that a client does support DSO, a server MUST NOT initiate DSO request messages or DSO unidirectional messages until a DSO Session has been mutually established by at least one successful DSO request/response exchange initiated by the client, as described below. This is referred to as explicit DSO Session establishment. 🫣
Until a DSO Session has been implicitly or explicitly established, a client MUST NOT initiate DSO unidirectional messages. 🚫
A DSO Session is established over a connection by the client sending a DSO request message, such as a DSO Keepalive request message (Section 7.1), and receiving a response with a matching MESSAGE ID, and RCODE set to NOERROR (0), indicating that the DSO request was successful. 🎀
Some DSO messages are permitted as early data (Section 11.1). Others are not. Unidirectional messages are never permitted as early data, unless an implicit DSO Session exists. 🍓
If a server receives a DSO message in early data whose Primary TLV is not permitted to appear in early data, the server MUST forcibly abort the connection. If a client receives a DSO message in early data, and there is no implicit DSO Session, the client MUST forcibly abort the connection. This can only be enforced on TLS connections; therefore, servers MUST NOT enable TCP Fast Open (TFO) when listening for a connection that does not require TLS. 🛑
5.1.1. DSO Session Establishment Failure
If the response RCODE is set to NOTIMP (4), or in practice any value other than NOERROR (0) or DSOTYPENI (defined below), then the client MUST assume that the server does not implement DSO at all. In this case, the client is permitted to continue sending DNS messages on that connection but MUST NOT issue further DSO messages on that connection. 🙃
If the RCODE in the response is set to DSOTYPENI ("DSO-TYPE Not Implemented"; RCODE 11), this indicates that the server does support DSO but does not implement the DSO-TYPE of the Primary TLV in this DSO request message. A server implementing DSO MUST NOT return DSOTYPENI for a DSO Keepalive request message because the Keepalive TLV is mandatory to implement. But in the future, if a client attempts to establish a DSO Session using a response-requiring DSO request message using some newly-defined DSO-TYPE that the server does not understand, that would result in a DSOTYPENI response. If the server returns DSOTYPENI, then a DSO Session is not considered established. The client is, however, permitted to continue sending DNS messages on the connection, including other DSO messages such as the DSO Keepalive, which may result in a successful NOERROR response, yielding the establishment of a DSO Session. 🧩
When a DSO message is received by an existing DNS server that doesn't recognize the DSO OPCODE, two other possible outcomes exist: the server might send no response to the DSO message, or the server might drop the connection. 🤔
If the server sends no response to the DSO message, the client SHOULD wait 30 seconds, after which time the server will be assumed not to support DSO. If the server doesn't respond within 30 seconds, it can be assumed that it is not going to respond. This leaves it in an unspecified state: there is no specification requiring that a response be sent to an unknown message, but there is also no specification stating what state the server is in if no response is sent. Therefore, the client MUST forcibly abort the connection to the server. The client MAY reconnect, but not use DSO, if appropriate (Section 6.6.3.1). By disconnecting and reconnecting, the client ensures that the server is in a known state before sending any subsequent requests. 😵💫
If the server drops the connection, the client SHOULD mark that service instance as not supporting DSO, and not attempt a DSO connection for some period of time (at least an hour) after the failed attempt. The client MAY reconnect but not use DSO, if appropriate (Section 6.6.3.2). 🕐
5.1.2. DSO Session Establishment Success
When the server receives a DSO request message from a client, and transmits a successful NOERROR response to that request, the server considers the DSO Session established. 🥳
When the client receives the server's NOERROR response to its DSO request message, the client considers the DSO Session established. 🎉
Once a DSO Session has been established, either end may unilaterally send appropriate DSO messages at any time, and therefore either client or server may be the initiator of a message. That's the whole vibe, babe. 💜
5.2. Operations after DSO Session Establishment ✨
Okay so once a DSO Session is up and running, clients and servers should behave the way this spec describes for inactivity timeouts and session termination 💅, not the way the older DNS-over-TCP spec [RFC7766] said. Main character update, bestie 🎀
Here's the iconic part 👑 A server that supports DNS Stateful Operations MUST return an RCODE of "NOERROR" when it gets a Keepalive TLV DSO request message, so the Keepalive TLV is an ideal candidate for starting a DSO Session 🦋 Any other option that can only succeed when it's sent to the right kind of server is also a good candidate. Clients that only implement the DSO-TYPEs from this base spec have just one option: a Keepalive TLV is the only DSO request they can use to start a session 🫶 Even clients that DO implement other future DSO-TYPEs MAY just always send an initial DSO Keepalive request message to start a session, because it's simpler 💖 A future spec for a new response-requiring DSO-TYPE gives implementers the choice to use it if they want, but it doesn't change the fact that sending a Keepalive TLV is still a valid way to start a DSO Session ✨
5.3. DSO Session Termination 🌸
A DSO Session ends when the underlying connection gets closed 🥀 There are two flavours of ending. A session is "closed gracefully" when the server closes it because it's overloaded, when the client closes it because it's done, or when the client closes it because it's inactive. A session is "forcibly aborted" when either the client or the server closes the connection because of a protocol error 😭
- Where this spec says "close gracefully", it means sending a TLS close_notify (if TLS is in use) followed by a TCP FIN, or the equivalent for other protocols. Where this spec requires a connection to be closed gracefully, the requirement to start that graceful close is placed on the client, so that the burden of TCP's TIME-WAIT state lands on the client instead of the server 🧚
- Where this spec says "forcibly abort", it means sending a TCP RST or the equivalent for other protocols. In the BSD Sockets API, this is done by setting the SO_LINGER option to zero before closing the socket 💀
5.3.1. Handling Protocol Errors 🙈
When you're building protocol software, there are generally two kinds of errors you have to deal with. The first kind comes from the environment, like a temporary loss of connectivity. Ngl, it's annoying, but it doesn't mean the software is broken, and software should usually be able to bounce back from these 💜
The second kind is stuff that should NEVER happen when you're talking to a compliant DSO implementation. If it does happen, it's a serious flaw in the protocol implementation, way beyond what's reasonable to expect software to recover from 😱 This document calls this kind of error a "fatal error", and it says that an implementation that runs into a fatal error condition "MUST forcibly abort the connection immediately" 🔥
5.4. Message Format 🍓
A DSO message starts with the standard twelve-byte DNS message header [RFC1035], with the OPCODE field set to the DSO OPCODE (6) 🧁 But unlike regular DNS messages, the question section, answer section, authority records section, and additional records section are NOT there. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero when they're sent 💅
If a DSO message comes in and any of the count fields are not zero, then a FORMERR MUST be returned 🙅♀️
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OPCODE (6) | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| QDCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ANCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| NSCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ARCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO Data /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+5.4.1. DNS Header Fields in DSO Messages 🎀
In a DSO unidirectional message, the MESSAGE ID field MUST be set to zero 🦋 In a DSO request message, the MESSAGE ID field MUST be set to a unique nonzero value that the initiator isn't using for any other active operation on this connection. Here, a MESSAGE ID counts as "in use" in this DSO Session if the initiator sent it in a DSO request message it's still waiting on a response for, or if the client used it to set up a long-lived operation that hasn't been canceled yet. For example, a long-lived operation could be a Push Notification subscription [Push] or a Discovery Relay interface subscription [Relay] ✨
Whether a message is a DSO request message or a DSO unidirectional message is decided ONLY by the spec for the Primary TLV 👑 You can't ask for an acknowledgment by putting a nonzero MESSAGE ID in a message that the Primary TLV says has to be unidirectional. And you can't stop an acknowledgment by sending a MESSAGE ID of zero in a message that has to be a DSO request message according to its Primary TLV. A responder that gets either of these malformed messages MUST treat it as a fatal error and forcibly abort the connection immediately 🚨
In a DSO request message or DSO unidirectional message, the DNS Header Query/Response (QR) bit MUST be zero (QR=0). If the QR bit isn't zero, the message isn't a DSO request or DSO unidirectional message 🙈
In a DSO response message, the DNS Header QR bit MUST be one (QR=1). If the QR bit isn't one, the message isn't a DSO response message 💖
In a DSO response message (QR=1), the MESSAGE ID field MUST NOT be zero, and it MUST contain a copy of the (nonzero) MESSAGE ID value from the DSO request message being responded to. If a DSO response message (QR=1) shows up with a MESSAGE ID of zero, that's a fatal error, and the recipient MUST forcibly abort the connection immediately 😭
The DNS Header OPCODE field holds the DSO OPCODE value (6) 🧚
The Z bits aren't used in DSO messages yet 🌈 In both DSO request messages and DSO responses, the Z bits MUST be set to zero (0) on transmission and MUST be ignored on reception 🫶
In a DSO request message (QR=0), the RCODE is set according to how that request is defined. For example, in a Retry Delay message (Section 6.6.1), the RCODE tells you the reason for termination. But in most DSO request messages (QR=0), unless it's clearly specified otherwise, the RCODE is set to zero when sent and quietly ignored when received 🙃
The RCODE value in a response message (QR=1) may be one of the following values:
+------+-----------+------------------------------------------------+
| Code | Mnemonic | Description |
+------+-----------+------------------------------------------------+
| 0 | NOERROR | Operation processed successfully |
| | | |
| 1 | FORMERR | Format error |
| | | |
| 2 | SERVFAIL | Server failed to process DSO request message |
| | | due to a problem with the server |
| | | |
| 4 | NOTIMP | DSO not supported |
| | | |
| 5 | REFUSED | Operation declined for policy reasons |
| | | |
| 11 | DSOTYPENI | Primary TLV's DSO-Type is not implemented |
+------+-----------+------------------------------------------------+Using the RCODEs above is probably going to be super common in DSO 💅 but it doesn't stop future documents that use DSO from defining and using other codes 🌸
If a document that defines a new DSO-TYPE uses response codes that aren't defined here, then that document MUST specify exactly what those RCODE values mean in the context of that new DSO TLV 🍓
The RCODE field is followed by the four zero-valued count fields, and then the DSO Data 🫶
5.4.2. DSO Data 🎀
okay so the DSO Data sits right after the usual twelve-byte DNS header 💅, and all of that header's count fields are zero. The DSO Data is written in TLV syntax, which we'll get into in Section 5.4.4 🦋
A DSO request message or DSO unidirectional message MUST contain at least one TLV. The very first TLV in one of those is called the "Primary TLV" and it's the boss 👑. It decides what the whole operation is about, including whether it's a DSO request or a DSO unidirectional operation. Sometimes it makes sense to pack in other TLVs too, like the DSO Encryption Padding TLV (Section 7.3) ✨. Additional TLVs go after the Primary TLV. They aren't limited to what this document defines, and new Additional TLVs may be defined in the future. Their definitions will say when using them is appropriate 🌸
An unrecognized Primary TLV gets a DSOTYPENI error response 💀. Unrecognized Additional TLVs are silently ignored, as described in Sections 5.4.5 and 8.2 🙈
A DSO response message may contain no TLVs, or one or more TLVs, depending on what info it's sharing 💖
Any TLVs with the same DSO-TYPE as the Primary TLV from the corresponding DSO request message are Response Primary TLV(s) and MUST appear first in a DSO response message. A DSO response message can have several Response Primary TLVs, just one, or in some cases none at all. A Response Primary TLV isn't required. For most DSO operations, the MESSAGE ID field in the DNS message header is enough to match a response to its request 🧚
Any other TLVs in a DSO response message are Response Additional TLVs, like the DSO Encryption Padding TLV (Section 7.3). They follow the Response Primary TLV(s), if present. Response Additional TLVs aren't limited to this document either, and new ones may be defined later. Their definitions will describe when they're appropriate. Unrecognized Response Additional TLVs are silently ignored, as described in Sections 5.4.5 and 8.2 🫶
The spec for each DSO TLV decides which TLVs have to show up in a response to a request that uses that TLV. If a DSO response arrives for an operation where a particular TLV or TLVs should be there, and they're missing, that's a fatal error. The recipient of the defective response message MUST forcibly abort the connection immediately. Same drama if more instances of a given TLV show up than the spec allows: fatal error, and the recipient of the defective response message MUST forcibly abort the connection immediately 😭
5.4.3. DSO Unidirectional Messages ✨
Most DSO operations are expected to use DSO request messages, which get matching DSO responses 💅. In some specialised high-traffic use cases, though, DSO unidirectional messages might be a good fit 🔥. They can be more efficient on the network because they don't create a stream of matching replies. They can also simplify software in some cases, since the initiator doesn't have to keep track of state while it waits for replies it doesn't care about 🧚
When the spec for a particular TLV used as a Primary TLV (aka first) in an outgoing DSO request message (aka QR=0) says the message is unidirectional, the MESSAGE ID field MUST be set to zero and the receiver MUST NOT generate any response message corresponding to that DSO unidirectional message 🛑
The previous point, that the receiver MUST NOT generate responses to DSO unidirectional messages, still applies even in the case of errors 🥺
When a DSO message arrives where both the QR bit and the MESSAGE ID field are zero, the receiver MUST NOT generate any response. For example, if the DSO-TYPE in the Primary TLV isn't recognized, then a DSOTYPENI error MUST NOT be returned. Instead, the receiver MUST forcibly abort the connection immediately 💀
DSO unidirectional messages MUST NOT be used "speculatively" when the sender doesn't know whether the receiver supports the Primary TLV in the message. There's no way to get a response to say whether it worked or not. DSO unidirectional messages are only appropriate when the sender already knows the receiver supports them and wants to receive them 🌈
For example, after a client has subscribed for Push Notifications [Push], the event notifications that follow are sent as DSO unidirectional messages. That's valid because the client started the message stream by subscribing. That shows it supports Push Notifications and wants to get them 💜
Similarly, after a Discovery Relay client subscribes to receive inbound multicast DNS (mDNS) [RFC6762] traffic from a Discovery Relay, the stream of packets it receives afterwards is sent as DSO unidirectional messages. That makes sense because the client started it through its Discovery Relay link subscription. That shows it supports Discovery Relay and wants inbound mDNS packets over that DSO Session [Relay] 🦋
5.4.4. TLV Syntax 🌸
All TLVs, whether used as "Primary", "Additional", "Response Primary", or "Response Additional", use the same encoding syntax 💖
A spec that defines a new TLV must specify whether the DSO-TYPE can be used as a Primary TLV, and whether it can be used as an Additional TLV. Some DSO-TYPEs are dual-purpose, so they're Primary TLVs in some messages and Additional TLVs in others 🪄. The spec for a DSO-TYPE must also state whether, when it's used as the Primary (i.e., first) TLV in a DSO message (i.e., QR=0), that DSO message is unidirectional or is a DSO request message that requires a response.
If a DSO request message requires a response, the spec must also state which TLVs, if any, are to be included in the response and how many instances of each TLV are allowed. The Primary TLV may or may not be in the response, depending on what the spec says for it. If multiple instances of the Primary TLV are allowed, the spec should clearly describe how they should be processed 📝
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+DSO-TYPE: a 16-bit unsigned integer in network (big endian) byte order. It gives the DSO-TYPE of the current DSO TLV, per the IANA "DSO Type Codes" registry 🎯
DSO-LENGTH: a 16-bit unsigned integer in network (big endian) byte order. It gives the size in bytes of the DSO-DATA 📏
DSO-DATA: type-code specific format. The generic DSO machinery treats the DSO-DATA as an opaque "blob" and doesn't try to interpret it. Figuring out what the DSO-DATA means for a particular DSO-TYPE is the job of the software that implements that DSO-TYPE 🫧
5.4.5. Unrecognized TLVs ✨
If a DSO request message arrives with an unrecognized Primary TLV and a nonzero MESSAGE ID (meaning a response is expected), the receiver MUST send an error response with a matching MESSAGE ID and RCODE DSOTYPENI. The error response MUST NOT contain a copy of the unrecognized Primary TLV 🙅♀️
If a DSO unidirectional message arrives with both an unrecognized Primary TLV and a zero MESSAGE ID (meaning no response is expected), that's a fatal error. The recipient MUST forcibly abort the connection immediately 😱
If a DSO request message or DSO unidirectional message arrives where the Primary TLV is recognized, containing one or more unrecognized Additional TLVs, the unrecognized Additional TLVs MUST be silently ignored. The rest of the message is interpreted and handled as if the unrecognized parts weren't there 🙈
Similarly, if a DSO response message arrives with one or more unrecognized TLVs, the unrecognized TLVs MUST be silently ignored, and the rest of the message is interpreted and handled as if the unrecognized parts are not present 🫶
5.4.6. EDNS(0) and TSIG 🎀
Since the ARCOUNT field MUST be zero, a DSO message can't have a valid EDNS(0) option in the additional records section. If you want functionality from current or future EDNS(0) options for DSO messages, one or more new DSO TLVs need to be defined to carry the necessary info 🧠
For example, the EDNS(0) Padding Option [RFC7830] used for security purposes is not permitted in a DSO message. So if you want message padding for DSO messages, the DSO Encryption Padding TLV described in Section 7.3 MUST be used 🔐
A DSO message can't contain a TSIG record, because a TSIG record is included in the additional section of the message. That would make ARCOUNT greater than zero. DSO messages are required to have an ARCOUNT of zero. So if signatures with DSO messages become necessary in the future, a new DSO TLV would have to be defined to do that job 🚫
Note, however, that while DSO messages cannot include EDNS(0) or TSIG records, a DSO session is typically used to carry a whole series of DNS messages of different kinds. That includes DSO messages and other DNS message types like Query [RFC1034] [RFC1035] and Update [RFC2136]. These messages can carry EDNS(0) and TSIG records 🌈
Although messages may contain other EDNS(0) options as appropriate, this specification explicitly prohibits use of the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent on a DSO Session. That's because it's obsoleted by the functionality the DSO Keepalive operation provides. If any message sent on a DSO Session contains an edns-tcp-keepalive EDNS(0) Option, that's a fatal error. The recipient of the defective message MUST forcibly abort the connection immediately 😭
5.5. Message Handling ✨
Okay bestie, so as we covered in Section 5.4.1, whether an outgoing DSO message with the QR bit set to zero is a DSO request or a DSO unidirectional message is decided by the spec for the Primary TLV 💅. That spec also decides whether the MESSAGE ID field in that outgoing message is zero or nonzero. It's giving "the Primary TLV is the boss" 👑
Every DSO message with QR set to zero and a nonzero MESSAGE ID field is a DSO request message 🎀. It MUST elicit a corresponding response, with QR set to one and the MESSAGE ID field set to the same value as in the DSO request message it's answering 🫶
Valid DSO request messages sent by the client with a nonzero MESSAGE ID field get a response from the server 🦋. Valid DSO request messages sent by the server with a nonzero MESSAGE ID field get a response from the client 🌸
Every DSO message with both QR and the MESSAGE ID field set to zero is a DSO unidirectional message 🧚. It MUST NOT elicit a response, so nobody's replying to these, periodt 🤐
5.5.1. Delayed Acknowledgement Management ✨
Generally, most good TCP implementations use a delayed acknowledgement timer 🌈. It's a whole vibe because it means more efficient use of the network and better performance ⭐
With a bidirectional exchange over TCP, like a DSO request message, the operating system's TCP implementation waits for the application-layer client software to generate the matching DSO response message 💜. Then the TCP implementation can send one combined packet holding the TCP acknowledgement, the TCP window update, and the application-generated DSO response message ✨. That's so much more efficient than sending three separate packets, which is what would happen if the TCP packet carrying the DSO request got acknowledged right away 😭
With a DSO unidirectional message or a DSO response message, there is no application-generated DSO response coming back 🙈. So the transport protocol gets no hint about when it should send its acknowledgement and window update, and that's kind of awkward 💀
Some networking APIs have a mechanism that lets the application-layer client software tell the transport protocol that no response is coming (basically a zero-length "empty" write) 🍓. Where that's available in the networking API being used, the recipient of a DSO unidirectional message or DSO response message SHOULD, after parsing and interpreting the message, use that mechanism to signal that no response for this message is forthcoming 🔥. Then the TCP implementation can send its acknowledgement and window update without any extra delay 🎀. Check Section 9.5 for more on why this matters, it's a must-read 📖
5.5.2. MESSAGE ID Namespaces ✨
The namespaces of 16-bit MESSAGE IDs are independent in each direction 🦋. So it is not an error for both client and server to send DSO request messages at the same time, using the same MESSAGE ID, in different directions 🙌 This simplification is necessary for the protocol to be implementable, bestie 🫶
It would be infeasible to require the client and server to coordinate on allocating new unique MESSAGE IDs 😵. It is also not necessary to require the client and server to coordinate on that either 🤷♀️ The 16-bit MESSAGE ID plus the identity of the initiator (client or server) is enough to unambiguously identify the operation in question 🎯
You can think of this as a 17-bit message identifier space 🌈. Client-to-server DSO request messages use 0x00001-0x0FFFF, and server-to-client DSO request messages use 0x10001-0x1FFFF 💖. The least-significant 16 bits are stored explicitly in the MESSAGE ID field of the DSO message, and the most-significant bit is implicit from the direction of the message 🧚
As described in Section 5.4.1, an initiator MUST NOT reuse a MESSAGE ID that it already has in use for an outstanding DSO request message (unless the relevant specification for the DSO-TYPE in question says otherwise) 🚫 At the very least, that means a MESSAGE ID can't be reused in a particular direction on a particular DSO Session while the initiator is waiting for a response to a previous DSO request message using that MESSAGE ID on that DSO Session (unless the relevant specification for the DSO-TYPE in question says otherwise) 🙅♀️ And for a long-lived operation, the MESSAGE ID for that operation can't be reused while the operation remains active 👑
If a client or server receives a response (QR=1) where the MESSAGE ID is zero, or is any other value that doesn't match the MESSAGE ID of any of its outstanding operations, that's a fatal error 💀 The recipient MUST forcibly abort the connection immediately 🚨
If a responder receives a DSO request message (QR=0) where the MESSAGE ID is not zero, and the responder tracks request MESSAGE IDs, and the MESSAGE ID matches one from a DSO request message it received that hasn't had a response sent yet, it MUST forcibly abort the connection immediately 😱 This behavior is required to prevent a hypothetical attack that takes advantage of undefined behavior in this case 🔐 However, if the responder doesn't track MESSAGE IDs this way, no such risk exists 🥳 So tracking MESSAGE IDs just to implement this sanity check is not required 🫠
5.5.3. Error Responses ✨
When a DSO request message is unsuccessful for some reason, the responder sends an error code back to the initiator 💌
If a server returns an error code to a client in response to an unsuccessful DSO request message, the server MAY choose to end the DSO Session, or MAY choose to let the DSO Session stay open 🤔 For error conditions that only affect that single operation, the server SHOULD return an error response to the client and leave the DSO Session open for further operations 🌸
For error conditions that are likely to make all operations unsuccessful in the immediate future, the server SHOULD return an error response to the client and then end the DSO Session by sending a Retry Delay message, as described in Section 6.6.1 🛑
When a client gets an error response from the server, it SHOULD NOT automatically close the DSO Session 🙅♀️ One operation failing doesn't necessarily mean every other operation on that DSO Session has failed, or that future operations will fail 💅 The client should assume the server will make its own decision about whether to end the DSO Session, based on whether the server thinks the error pertains to this particular operation or to any subsequent ones 🧐 If the server doesn't end the DSO Session by sending the client a Retry Delay message (Section 6.6.1), then the client SHOULD continue to use that DSO Session for subsequent operations 🔁
When a DSO unidirectional message type is received (the MESSAGE ID field is zero), the receiver should already be expecting this DSO message type 👀 Section 5.4.5 describes how to handle unknown DSO message types 📚 When a DSO unidirectional message of an unexpected type is received, the receiver SHOULD forcibly abort the connection 😬 Whether the connection should be forcibly aborted for other internal errors while processing the DSO unidirectional message depends on the implementation and how severe the error is 🎭
5.6. Responder-Initiated Operation Cancellation ✨
This document, the base specification for DNS Stateful Operations, doesn't define any long-lived operations itself 🙃 But it does define a framework for supporting long-lived operations, like Push Notification subscriptions [Push] and Discovery Relay interface subscriptions [Relay] 🌟
Long-lived operations, if successful, stay active until the initiator terminates them 💖
However, an operation that was valid when it was started might become invalid later because circumstances changed 😳 For example, a long-lived client operation might pertain to a name that the server is authoritative for, but then the server configuration changes so it's no longer authoritative for that name 🫣
In cases like this, it may be desirable for the responder to be able to cancel only the operations that have become invalid, instead of terminating the entire session 🦋
The responder does this selective cancellation by sending a new DSO response message. The MESSAGE ID field holds the MESSAGE ID of the long-lived operation being terminated (the one it had previously acknowledged with a NOERROR RCODE), and the RCODE field of the new DSO response message gives the reason for the cancellation 🎀
Once a DSO response message with a nonzero RCODE has been sent, that operation is terminated from the responder's point of view, and the responder sends no more messages about it 🛑
Once a DSO response message with a nonzero RCODE has been received by the initiator, that operation is terminated from the initiator's point of view, and the canceled operation's MESSAGE ID is now free for reuse 🔓✨
6. DSO Session Lifecycle and Timers ✨
6.1. DSO Session Initiation 🚀
A DSO Session begins as described in Section 5.1 🌱
Once a DSO Session has been created, the client or server can start as many DNS operations as they want using that DSO Session 💅
When an initiator has multiple messages to send, it SHOULD NOT wait for each response before sending the next message 🏃♀️💨
A responder MUST act on messages in the order they are received, and SHOULD return responses to request messages as they become available ⏱️ A responder SHOULD NOT delay sending responses just to deliver them in the same order the corresponding requests came in 🙅♀️
Section 6.2.1.1 of the DNS-over-TCP specification [RFC7766] covers this in more detail 📖🫶
6.2. DSO Session Timeouts ✨
okay so a DSO Session has two timeout values, and they're both sent in the same TLV: the Keepalive TLV (Section 7.1) 🎀
The first one is the inactivity timeout. It's the max amount of time a client can keep an idle DSO Session open on spec, just in case it has more requests to send that server later 🧚
The second one is the keepalive interval. That's the longest gap allowed between messages if the client wants to keep the DSO Session alive 💖
These two are totally independent of each other. The inactivity timeout can be shorter than, the same as, or longer than the keepalive interval 🦋 Though honestly, most of the time the inactivity timeout is expected to be shorter than the keepalive interval, so that's the main vibe.
A shorter inactivity timeout with a longer keepalive interval basically tells the client "don't hoard idle sessions for ages for no reason" 💅 But when it does have a real reason to keep one open, it doesn't have to spam aggressive keepalive traffic to hold it together. Like, a client that's subscribed to DNS Push notifications is the perfect example 🔔 It's not sending anything to the server, but the session isn't inactive, because there's an active request to the server to receive push notifications. No cap, that's giving main character energy 👑
Now the opposite: a longer inactivity timeout with a shorter keepalive interval tells the client it can speculatively keep an idle session open for a long time, BUT it should be sending a whole lot of DSO keepalive traffic to keep that idle session alive 🫶 This setup is expected to be less common, lowkey.
In the usual case where the inactivity timeout is shorter than the keepalive interval, the keepalive interval only really matters for a client that has a long-lived, low-traffic operation going 🌸 The point is to make sure there's enough leftover traffic to keep NAT and firewall state alive, and to help the client and server keep confirming that they still have connectivity to each other.
On a brand new DSO Session where no explicit DSO Keepalive message exchange has happened yet, both timeouts default to 15 seconds ⏱️
And for both timeouts, the lower the value, the more network traffic you get and the higher the CPU load on the server 🔥 So yeah, be nice to your server, bestie 🥺
6.3. Inactive DSO Sessions 🌈
Okay this part is so important. At both servers and clients, generating or receiving any complete DNS message resets both timers for that DSO Session 💜 That includes DNS requests, responses, updates, DSO messages, and so on.
The one exception is a DSO Keepalive message. It resets only the keepalive timer, NOT the inactivity timeout timer 🙈
Also, as long as the client has an outstanding operation in progress, the inactivity timer stays cleared, and an inactivity timeout can't happen while that's the case 🛡️
For short-lived DNS operations like traditional queries and updates, an operation counts as "in progress" from the request until the response comes back. We're talking a few hundred milliseconds at most, usually ⚡ On the client side, the inactivity timer gets cleared when a request is sent and stays cleared until the matching response shows up. On the server side, it's cleared when a request comes in and stays cleared until the matching response goes out.
Long-lived DNS Stateful Operations are a whole different energy 🦋 Think a Push Notification subscription [Push] or a Discovery Relay interface subscription [Relay]. These count as "in progress" for as long as they're active, meaning until they get canceled. So a DSO Session can have active operations and zero messages flying back and forth for way longer than the inactivity timeout, and that's totally fine, not an error ✨ That's literally why there are two separate timers: the inactivity timeout and the keepalive interval 🎀
So just because a DSO Session has no traffic for a long stretch, it doesn't automatically become "inactive" if it still has an active operation waiting on events 💅
6.4. The Inactivity Timeout 🧚
The whole purpose of the inactivity timeout is for the server to balance two costs: setting up new DSO Sessions versus keeping inactive ones alive 💭 A server with loads of DSO Session capacity can offer a high inactivity timeout, so clients can keep a speculative session open for ages and skip the cost of setting up a new one later 🌷 A server with scarce memory can offer a low inactivity timeout instead, so clients quickly close sessions whenever they have nothing going on with that server, and then open a fresh one when they actually need it 🍓
6.4.1. Closing Inactive DSO Sessions 🚪
When a connection's inactivity timeout is reached, the client MUST begin closing the idle connection. BUT a client isn't required to keep an idle connection open until the inactivity timeout is actually reached 🫠 A client MAY close a DSO Session at any time, whenever it wants to. And if a client decides it has no current or reasonably expected future need for a currently inactive DSO Session, it SHOULD gracefully close that connection 💖
If, at any point during the life of the DSO Session, the inactivity timeout value (so 15 seconds by default) passes with no operation active on the DSO Session, the client MUST close the connection gracefully 🌸
If, at any point during the life of the DSO Session, way too much time goes by with no operation active on it, then the server MUST consider the client delinquent and MUST forcibly abort the DSO Session 🚨 "Way too much time" here means five seconds or twice the current inactivity timeout value, whichever is greater. So if the inactivity timeout is at its default of 15 seconds, a client gets labeled delinquent and disconnected if it hasn't closed its connection after 30 seconds of inactivity 💀
For this context, an operation being active on a DSO Session includes a query waiting for a response, an update waiting for a response, or an active long-lived operation. It does NOT include a DSO Keepalive message exchange itself 🙅♀️ A DSO Keepalive message exchange only resets the keepalive interval timer, not the inactivity timeout timer.
And if the client wants to keep an inactive DSO Session open for longer than the default duration, it uses the DSO Keepalive message to request longer timeout values, as described in Section 7.1 🎀
6.4.2. Values for the Inactivity Timeout 🔢
For the inactivity timeout, lower values mean more frequent DSO Session teardowns and re-establishments 🔁 Higher values mean less traffic and lower CPU load on the server, but a heavier memory burden for keeping the state of inactive DSO Sessions around 🧠
A server may dictate any value it likes for the inactivity timeout 🌈 That can be in a response to a client-initiated request or in a server-initiated message. And yes, that includes values under one second, or even zero 😳
An inactivity timeout of zero tells the client it should NOT speculatively keep idle connections at all. As soon as the client has finished the operation or operations for this server, it should immediately begin closing the session 🏃♀️
A server will forcibly abort an idle client session after five seconds or twice the inactivity timeout value, whichever is greater. If the inactivity timeout is zero, that means if a client fails to close an idle session, the server will forcibly abort it after five seconds ⏰
An inactivity timeout of 0xFFFFFFFF represents "infinity" ♾️ It tells the client it can keep an idle connection open for as long as it wants. Just a heads up though: even after granting an unlimited inactivity timeout like this, the server can change its mind at any point by sending a new DSO Keepalive message with new Session Timeout values for the client 🫢
The largest finite inactivity timeout the current Keepalive TLV supports is 0xFFFFFFFE, which is 2^32-2 milliseconds, roughly 49.7 days 📅
6.5. The Keepalive Interval 💓
The keepalive interval exists to make sure enough messages get generated to keep state alive in middleboxes (like NAT gateways or firewalls) 🧱 It also lets the client and server periodically check that they still have connectivity to each other 🤝 That way they can clean up state when connectivity drops, and set up a new session if that makes sense 🌟
6.5.1. Keepalive Interval Expiry ⌛
If, at any point during the life of the DSO Session, the keepalive interval value (15 seconds by default) passes with no DNS messages sent or received on the DSO Session, the client MUST take action to keep the DSO Session alive by sending a DSO Keepalive message (Section 7.1) 🫶 A DSO Keepalive message exchange resets only the keepalive timer, not the inactivity timer.
Now, if a client drops off the network abruptly without cleanly closing its DSO Session, maybe leaving a long-lived operation uncanceled, the server finds out after it stops getting the required DSO keepalive traffic from that client 👻 If, at any point during the life of the DSO Session, twice the keepalive interval value (30 seconds by default) passes with no DNS messages sent or received on the DSO Session, the server SHOULD consider the client delinquent and SHOULD forcibly abort the DSO Session 🧹
6.5.2. Values for the Keepalive Interval ✨
okay so the keepalive interval is basically the knob for how chatty the DSO keepalive traffic is 💖 lower values mean MORE keepalive traffic, and higher values mean less traffic and less CPU load 🫶 but the memory burden on the server barely changes, because clients keep a DSO Session open for the same length of time (set by the inactivity timeout) no matter how much keepalive traffic they're sending 🧚
it may be appropriate for clients and servers to pick different keepalive intervals depending on what kind of network they're on 🌸
a corporate DNS server that knows it only serves clients on the internal network, with no NAT gateways or firewalls in the way, can impose a longer keepalive interval 🎀 frequent keepalive traffic just isn't needed there, bestie 💅
a public DNS server mostly serving residential consumer clients is a different story 🏠 there's likely to be a NAT gateway on the path, so it may impose a shorter keepalive interval to generate more frequent keepalive traffic 🦋
a smart client can be adaptive to its environment ✨ a client using a private IPv4 address [RFC1918] to talk to a DNS server at an address outside that private block may conclude there's likely a NAT gateway on the path, and then request a shorter keepalive interval 🙈 that's giving "read the room" energy 👑
by default, it is RECOMMENDED that clients request, and servers grant, a keepalive interval of 60 minutes 💜 this is reasonably timely detection if a client abruptly disconnects without cleanly closing the session 🔥 it's also enough to keep state alive in firewalls and NAT gateways that follow the IETF recommended Best Current Practice, where the "established connection idle-timeout" used by middleboxes is at least 2 hours and 4 minutes [RFC5382] [RFC7857] 🌈
⚠️ the shorter the keepalive interval, the higher the load on the client and the server 😭 and if the keepalive interval is shorter than the time the transport needs to retransmit, losing a single packet can make a server overzealously abort the connection 💀
for a (hypothetical and unrealistic) keepalive interval of 100 ms, you'd get a continuous stream of ten messages per second or more (if the current congestion control window allows it) in both directions just to keep the DSO Session alive 🍓 and in that extreme example, a single retransmission over a path with, as an example, 100 ms RTT would cause a momentary pause in the stream long enough for the server to abort the connection 😱
because of this concern, the server MUST NOT send a DSO Keepalive message (either a DSO response to a client-initiated DSO request or a server-initiated DSO message) with a keepalive interval value less than ten seconds 🛑 and if a client receives a DSO Keepalive message specifying a keepalive interval value less than ten seconds, that's a fatal error and the client MUST forcibly abort the connection immediately 🚨
a keepalive interval value of 0xFFFFFFFF represents "infinity" ♾️ and tells the client it should generate no DSO keepalive traffic 🧚 after signaling that in this way, the server may at any point revise that requirement by sending a new DSO Keepalive message dictating new Session Timeout values to the client 🔄
the largest finite keepalive interval supported by the current Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 days) 📅✨
6.6. Server-Initiated DSO Session Termination 💅
okay so beyond canceling individual long-lived operations selectively (Section 5.6), there are also times when a server may need to terminate one or more entire DSO sessions 😭 an entire DSO session may need to go if the client is defective in some way or leaves the network without closing its DSO session 🙈 DSO Sessions may also need to be terminated if the server gets overloaded or is reconfigured and can't be selective about which operations to cancel 💀
this section covers the various reasons a DSO session may be terminated and the mechanisms for doing so 🎀
in normal operation, closing a DSO Session is the client's responsibility 🫶 the client decides when to close a DSO Session based on its own needs and the inactivity timeout value the server dictated 🧠 a server only causes a DSO Session to end in the exceptional circumstances outlined below, so some of the situations where a server may terminate a DSO Session include:
- 🌸 The server application software or underlying operating system is shutting down or restarting.
- 💥 The server application software terminates unexpectedly (perhaps due to a bug that makes it crash, causing the underlying operating system to send a TCP RST).
- 🔧 The server is undergoing a reconfiguration or maintenance procedure that, due to the way the server software is implemented, requires clients to be disconnected. For example, some software reads a configuration file at startup, and changing the server's configuration means modifying that file and then killing and restarting the server software, which generally entails a loss of network connections.
- ⏰ The client fails to meet its obligation to generate the required DSO keepalive traffic or to close an inactive session by the prescribed time (five seconds or twice the time interval dictated by the server, whichever is greater, as described in Section 6.2).
- 🤡 The client sends a grossly invalid or malformed request that is indicative of a seriously defective client implementation.
- 📦 The server is over capacity and needs to shed some load.
6.6.1. Server-Initiated Retry Delay Message 🦋
in the cases described above where a server elects to terminate a DSO Session, it could just forcibly abort the connection 😬 however, the likely behavior of the client might then be to treat this as a network failure and reconnect immediately, which puts more burden on the server 😩
so, to avoid this reconnection implosion 💥, a server SHOULD instead choose to shed client load by sending a Retry Delay message with an appropriate RCODE value, informing the client of the reason the DSO Session needs to be terminated 🎁 the format of the DSO Retry Delay TLV and the interpretations of the various RCODE values are described in Section 7.2 📖 after sending a DSO Retry Delay message, the server MUST NOT send any further messages on that DSO Session 🛑
the server MAY randomize retry delays when lots of them are sent in quick succession, so that not all the clients try to reconnect at once 🎲 in general, implementations should avoid using the DSO Retry Delay message in a way that would result in many clients reconnecting at the same time if every client attempts to reconnect at the exact time specified 🙅♀️
upon receipt of a DSO Retry Delay message from the server, the client MUST make note of the reconnect delay for this server and then immediately close the connection gracefully 🫡
after sending a DSO Retry Delay message, the server SHOULD allow the client five seconds to close the connection 🕔 and if the client still hasn't closed it after five seconds, the server SHOULD forcibly abort the connection 🔪
a DSO Retry Delay message MUST NOT be initiated by a client 🚫 if a server receives a DSO Retry Delay message, that's a fatal error and the server MUST forcibly abort the connection immediately 🚨
6.6.1.1. Outstanding Operations 🧳
at the instant a server chooses to initiate a DSO Retry Delay message, there may be DNS requests already in flight from client to server on this DSO Session, which will arrive at the server after its DSO Retry Delay message has been sent 🛫 the server MUST silently ignore such incoming requests and MUST NOT generate any response messages for them 🤫 when the DSO Retry Delay message arrives at the client, the client will determine that any DNS requests it previously sent on this DSO Session that haven't received a response will now certainly not get one 💔
such requests should be considered failed and should be retried at a later time, as appropriate 🔁
in the case where some, but not all, of the existing operations on a DSO Session have become invalid (perhaps because the server has been reconfigured and is no longer authoritative for some of the names), but the server is terminating all affected DSO Sessions en masse by sending them all a DSO Retry Delay message, the reconnect delay MAY be zero 0️⃣ which indicates that the clients SHOULD immediately attempt to re-establish operations ⚡
it's likely some of the attempts will succeed and some won't, depending on the nature of the reconfiguration 🎲
in the case where a server is terminating a large number of DSO Sessions at once (e.g., if the system is restarting) and doesn't want to be inundated with a flood of simultaneous retries, it SHOULD send different reconnect delay values to each client 🌊 these adjustments MAY be selected randomly, pseudorandomly, or deterministically (e.g., incrementing the time value by one tenth of a second for each successive client, yielding a post-restart reconnection rate of ten clients per second) 📈✨
6.6.2. Misbehaving Clients 🙅♀️
a server may determine that a client is not following the protocol correctly 🕵️♀️ there may be no way for the server to recover the DSO session, in which case the server forcibly terminates the connection 🔪 since the client doesn't know why the connection dropped, it may reconnect immediately 😵💫 if the server has determined that a client is not following the protocol correctly, it MAY terminate the DSO Session as soon as it is established, specifying a long retry-delay to prevent the client from immediately reconnecting 🧱✨
6.6.3. Client Reconnection 🔁✨
okay so after the server ends a DSO Session (either by sending the client a DSO Retry Delay message or by forcibly aborting the underlying transport connection), the client SHOULD try to reconnect to that service instance, or to another suitable one if more than one is available 💖. If it's reconnecting to the same service instance, the client MUST respect the indicated delay, if there is one, before attempting to reconnect. Clients SHOULD NOT attempt to randomize the delay 🙅♀️. The server will randomly jitter the retry delay values it sends to each client if that behavior is wanted, so that part is handled on the server's side ✨.
If a service instance is only going to be out for a short maintenance period, it should pick a retry delay that's a little longer than the expected window 🧁. It shouldn't default to a super huge delay value, or clients might not reconnect promptly once it's back up 😭.
If a service instance never wants a client to reconnect (maybe it's being decommissioned 🪦), it SHOULD set the retry delay to the maximum value 0xFFFFFFFF (2^32-1 milliseconds, approximately 49.7 days). It's not possible to tell a client to stay away for longer than 49.7 days, sorry bestie 💀. If, after 49.7 days, the DNS or other configuration information still says this is the valid service instance for a particular service, then clients MAY attempt to reconnect. Realistically, if a client gets rebooted or otherwise loses state, it may try to reconnect before 49.7 days even pass, for as long as the DNS or other configuration information keeps pointing to this instance as the one it should use 🙈.
6.6.3.1. Reconnecting after a Forcible Abort 🚫
If the client forcibly aborted a connection because the server was behaving noncompliantly 😤, the client SHOULD mark that service instance as not supporting DSO. The client MAY reconnect but not try to use DSO, or it may connect to a different service instance if that's an option 🦋.
6.6.3.2. Reconnecting after an Unexplained Connection Drop 👻
It's also possible for a server to forcibly terminate the connection. In that case, the client doesn't know whether the termination was caused by a protocol error or a network outage 🤷♀️. When the client notices the connection has been dropped, it can attempt to reconnect immediately. But if the connection gets dropped again before the client can successfully do whatever it was trying to do, it should mark the server as not supporting DSO 😬.
6.6.3.3. Probing for Working DSO Support 🔍
Once the client has marked a server as not supporting DSO, the client SHOULD NOT attempt DSO operations on that server until some time has elapsed. A reasonable minimum would be an hour ⏰. Since forcibly aborted connections are the result of a software failure, the problem probably won't get solved in the first hour after it's first hit 🛠️. But by keeping the retry interval to an hour, the client can notice when the problem's been fixed without putting an undue burden on the server 💜.
7. Base TLVs for DNS Stateful Operations 🎀
This section describes the three base TLVs for DNS Stateful Operations: Keepalive, Retry Delay, and Encryption Padding 🧚.
7.1. Keepalive TLV 💜
The Keepalive TLV (DSO-TYPE=1) has two jobs 👑. Its main one is setting up the values for the Session Timeouts. Its secondary one is that it also resets the keepalive timer for the DSO Session, which means it can be used as a kind of "no-op" message to keep a session alive 🌸. The client requests the Session Timeout values it wants, and the server replies with the values it requires the client to use 💅.
DSO messages with the Keepalive TLV as the Primary TLV may appear in early data 🫶.
The DSO-DATA for the Keepalive TLV is as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INACTIVITY TIMEOUT (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEEPALIVE INTERVAL (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+INACTIVITY TIMEOUT: this is the inactivity timeout for the current DSO Session, a 32-bit unsigned integer in network (big endian) byte order, measured in milliseconds 🕰️. It's the timeout at which the client MUST begin closing an inactive DSO Session. The server can pick any value it likes here 🎯. If the client doesn't gracefully close an inactive DSO Session, then after five seconds or twice this interval (whichever is greater), the server will forcibly abort the connection 💀.
KEEPALIVE INTERVAL: this is the keepalive interval for the current DSO Session, also a 32-bit unsigned integer in network (big endian) byte order, in milliseconds 💓. It's how often a client MUST generate DSO keepalive traffic to keep the connection state alive. The keepalive interval MUST NOT be less than ten seconds 🙅♀️. If the client doesn't generate the mandated DSO keepalive traffic, then after twice this interval the server will forcibly abort the connection. Since the minimum allowed keepalive interval is ten seconds, the earliest a server will forcibly disconnect a client for skipping that keepalive traffic is twenty seconds ⚡.
Here's the tea 🫖: sending or receiving DSO Keepalive messages (aka messages where the Keepalive TLV is the first TLV) only resets the keepalive timer, not the inactivity timer. The reason is that periodic DSO Keepalive messages are only there to keep a DSO Session alive when that session has current or recent non-maintenance activity worth keeping alive 🧠. Sending keepalive traffic isn't counted as client activity. It's a maintenance activity that happens in service of the other client activities 🔧. If keepalive traffic reset the inactivity timer, you'd get a circular livelock, with keepalive traffic being sent forever just to keep the session alive so more keepalive traffic could be sent 🌀. In that scenario, the only thing happening on the session would be keepalive traffic keeping the session alive so that further keepalive traffic could be sent. For a DSO Session to count as active, it must be carrying something more than just keepalive traffic. That's exactly why merely sending or receiving a DSO Keepalive message doesn't reset the inactivity timer 🙃.
When a client sends the DSO Keepalive request message, it MUST be sent as a DSO request message with a nonzero MESSAGE ID 📬. If a server receives a DSO Keepalive message with a zero MESSAGE ID, that's a fatal error, and the server MUST forcibly abort the connection immediately 🚨. The DSO Keepalive request message resets a DSO Session's keepalive timer and, at the same time, tells the server which Session Timeout values the client is requesting 🗣️. In a server response to a client-initiated DSO Keepalive request message, the Session Timeouts contain the server's chosen values from that point forward in the DSO Session, and the client MUST respect them 👑. This is modeled after DHCP, where the client requests a certain lease lifetime using DHCP option 51 [RFC2132], but the server is the ultimate authority on what lease lifetime actually gets granted 🎀.
When a client is sending its second and subsequent DSO Keepalive request messages to the server, it SHOULD keep requesting its preferred values each time 🔁. This leaves room for flexibility: if conditions change during the lifetime of a DSO Session, the server can adjust its responses to better fit what the client needs 🦋.
Once a DSO Session is in progress (Section 5.1), a server MAY initiate a DSO Keepalive message 🌤️. When a server sends one, it MUST be sent as a DSO unidirectional message with the MESSAGE ID set to zero. The client MUST NOT generate a response to a server-initiated DSO Keepalive message 🤐. If a client receives a DSO Keepalive request message with a nonzero MESSAGE ID, that's a fatal error, and the client MUST forcibly abort the connection immediately 🚨. The DSO Keepalive unidirectional message from the server resets a DSO Session's keepalive timer and, at the same time, unilaterally tells the client the new Session Timeout values to use from that point forward in this DSO Session 📣. No client DSO response to this unilateral declaration is required or allowed 🙊.
In DSO Keepalive response messages, exactly one instance of the Keepalive TLV MUST be present, and it's only used as a Response Primary TLV, sent as a reply to a DSO Keepalive request message from the client 💌. A Keepalive TLV MUST NOT be added to other responses as a Response Additional TLV 🚫. If the server wants to update a client's Session Timeout values at some other time (not in response to a DSO Keepalive request message from the client), it does that by sending its own DSO Keepalive unidirectional message, as described above 🧚.
It's not required that the Keepalive TLV be used in every DSO Session 🌈. Lots of DSO operations go hand in hand with long-lived session state, but not all of them need it, and in some cases the default 15-second value for both the inactivity timeout and keepalive interval may be perfectly appropriate 🍓. However, note that for clients that implement only the DSO-TYPEs defined in this document, a DSO Keepalive request message is the only way for a client to initiate a DSO Session 🔑.
7.1.1. Client Handling of Received Session Timeout Values ⏰
okay so this is where the client gets its timeout numbers from the server 🫶 whenever it gets a reply to its own client-initiated DSO Keepalive request, or a server-initiated DSO Keepalive unidirectional message, it has now received Session Timeout values dictated by the server. The two timeout values in the Keepalive TLV from the server can each be higher, lower, or the same as the respective Session Timeout values the client already had for this DSO Session 💅
For the keepalive timer it's honestly pretty simple 💖 receiving the message with the DSO Keepalive TLV resets the keepalive timer and updates the keepalive interval for the DSO Session. That new keepalive interval is the maximum time that can pass before another message has to be sent or received on this DSO Session, if the DSO Session is going to stay alive ✨
The inactivity timeout is where it gets a little more dramatic 🙈 it still means the same thing it always did: the maximum permissible time allowed without useful activity on a DSO Session. But receiving the Keepalive TLV does not reset the inactivity timer, so the time since the last useful activity on this DSO Session is totally unaffected by DSO Keepalive messages 😭 What the new value does do is update the timeout attached to the timer that's already running, and that becomes the new maximum permissible time without activity on a DSO Session 🎀
- 🌸 If the current inactivity timer value is less than the new inactivity timeout, then the DSO Session may remain open for now. When the inactivity timer value reaches the new inactivity timeout, the client MUST then begin closing the DSO Session as described above.
- 🦋 If the current inactivity timer value is equal to the new inactivity timeout, then this DSO Session has been inactive for exactly as long as the server will permit, and the client MUST immediately begin closing this DSO Session.
- 💀 If the current inactivity timer value is already greater than the new inactivity timeout, then this DSO Session has already been inactive for longer than the server permits, and the client MUST immediately begin closing this DSO Session.
- 🚨 If the current inactivity timer value is already more than twice the new inactivity timeout, then the client is immediately considered delinquent (this DSO Session is immediately eligible to be forcibly terminated by the server), and the client MUST immediately begin closing this DSO Session. However, if a server abruptly reduces the inactivity timeout in this way, then, to give the client time to close the connection gracefully before the server resorts to forcibly aborting it, the server SHOULD give the client an additional grace period of either five seconds or one quarter of the new inactivity timeout, whichever is greater. 🫠
7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option 🔗
The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has similar intent to the edns-tcp-keepalive EDNS(0) Option [RFC7828]. A client/server pair that supports DSO MUST NOT use the edns-tcp-keepalive EDNS(0) Option within any message after a DSO Session has been established. A client that has sent a DSO message to establish a session MUST NOT send an edns-tcp-keepalive EDNS(0) Option from this point on.
Once a DSO Session has been established, if either client or server receives a DNS message over the DSO Session that contains an edns-tcp-keepalive EDNS(0) Option, that is a fatal error 🚫 and the receiver of the edns-tcp-keepalive EDNS(0) Option MUST forcibly abort the connection immediately. Not a vibe 💀
7.2. Retry Delay TLV ⏳
The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary TLV (unidirectional) in a server-to-client message, or as a Response Additional TLV in either direction. DSO messages with a Relay Delay TLV as their Primary TLV are not permitted in early data 🙅♀️
The DSO-DATA for the Retry Delay TLV looks like this 👀
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETRY DELAY (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RETRY DELAY is a time value, specified as a 32-bit unsigned integer in network (big endian) byte order, in units of milliseconds. Within that time, the initiator MUST NOT retry this operation or retry connecting to this server. Recommendations for the RETRY DELAY value are given in Section 6.6.1. 🧚
7.2.1. Retry Delay TLV Used as a Primary TLV 📣
When the Retry Delay TLV is used as the Primary TLV in a DSO unidirectional message, it gets sent from server to client. The server uses it to tell a client to close the DSO Session and underlying connection, and not to reconnect for the indicated time interval 👋
In this case it applies to the DSO Session as a whole, so the client MUST begin closing the DSO Session as described in Section 6.6.1. The RCODE in the message header SHOULD indicate the principal reason for the termination:
- 🌈
NOERRORindicates a routine shutdown or restart. - 🤯
FORMERRindicates that a client DSO request was too badly malformed for the session to continue. - 🔥
SERVFAILindicates that the server is overloaded due to resource exhaustion and needs to shed load. - 🙅
REFUSEDindicates that the server has been reconfigured, and at this time it is now unable to perform one or more of the long-lived client operations that were previously being performed on this DSO Session. - 🫥
NOTAUTHindicates that the server has been reconfigured and at this time it is now unable to perform one or more of the long-lived client operations that were previously being performed on this DSO Session, because it does not have authority over the names in question (for example, a DNS Push Notification server could be reconfigured such that it is no longer accepting DNS Push Notification requests for one or more of the currently subscribed names).
This document specifies only these RCODE values for the DSO Retry Delay message. Servers sending DSO Retry Delay messages SHOULD use one of these values. However, future circumstances may create situations where other RCODE values are appropriate in DSO Retry Delay messages, so clients MUST be prepared to accept DSO Retry Delay messages with any RCODE value 🌸
Sometimes, when a server sends a DSO Retry Delay unidirectional message to a client, there may be more than one reason for the server wanting to end the session. The configuration could have been changed such that some long-lived client operations can no longer be continued due to policy (REFUSED), and other long-lived client operations can no longer be performed due to the server no longer being authoritative for those names (NOTAUTH). In situations like that, the server MAY use any of the applicable RCODE values, or RCODE=NOERROR (routine shutdown or restart) 🧠
Note that picking the RCODE value in a DSO Retry Delay message is not critical 🤷♀️ the RCODE is generally used only for information purposes, like writing to a log file for future human analysis of why the disconnection happened. Generally, clients don't change their behavior based on the RCODE value. The RETRY DELAY in the message is what tells the client how long to wait before attempting a new connection to this service instance ⏳
For clients that do modify their behavior depending on the RCODE value in some way, they should treat unknown RCODE values the same as RCODE=NOERROR (routine shutdown or restart) 🧐
A DSO Retry Delay message (a DSO message where the Primary TLV is Retry Delay) from server to client is a DSO unidirectional message. The MESSAGE ID MUST be set to zero in the outgoing message, and the client MUST NOT send a response 🙃
A client MUST NOT send a DSO Retry Delay message to a server. If a server receives a DSO message where the Primary TLV is the Retry Delay TLV, that is a fatal error, and the server MUST forcibly abort the connection immediately. ☠️
7.2.2. Retry Delay TLV Used as a Response Additional TLV 💌
If a DSO request message results in a nonzero RCODE value, the responder MAY append a Retry Delay TLV to the response. That tells the initiator the time interval during which it SHOULD NOT attempt this operation again ⏱️
The indicated time interval during which the initiator SHOULD NOT retry applies only to the failed operation, not to the DSO Session as a whole. So the rest of the session is still good to go 🙌
Either a client or a server, whichever is acting as the responder for a particular DSO request message, MAY append a Retry Delay TLV to an error response that it sends 💖
7.3. Encryption Padding TLV 🔐
The Encryption Padding TLV (DSO-TYPE=3) can only be used as an Additional or Response Additional TLV. It's only applicable when the DSO Transport layer uses encryption such as TLS 🛡️
The DSO-DATA for the Padding TLV is optional and is a variable length field containing non-specified values. A DSO-LENGTH of 0 essentially provides for 4 bytes of padding (the minimum amount) 🫧
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ /
/ PADDING -- VARIABLE NUMBER OF BYTES /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+As specified for the EDNS(0) Padding Option [RFC7830], the PADDING bytes SHOULD be set to 0x00. Other values MAY be used, for example, in cases where there is a concern that the padded message could be subject to compression before encryption. PADDING bytes of any value MUST be accepted in the messages received 🧦
The Encryption Padding TLV may be included in either a DSO request message, response, or both. As specified for the EDNS(0) Padding Option [RFC7830], if a DSO request message is received with an Encryption Padding TLV, then the DSO response MUST also include an Encryption Padding TLV 🎁
The length of padding is intentionally not specified in this document. It's a function of current best practices with respect to the type and length of data in the preceding TLVs [RFC8467] 📚
8. Summary Highlights 🌟
okay so this section is basically the highlight reel ✨ it sums up some of the noteworthy bits about various aspects of the DSO protocol 🎀
8.1. QR Bit and MESSAGE ID
Okay so the QR bit and the MESSAGE ID are literally how you tell a request from a response from a unidirectional message, and they have to agree with each other 💅✨
In DSO request messages, the QR bit is 0 and the MESSAGE ID is nonzero. 🦋
In DSO response messages, the QR bit is 1 and the MESSAGE ID is nonzero. 💖
In DSO unidirectional messages, the QR bit is 0 and the MESSAGE ID is zero. 🌸
Here's the cute little chart that shows which combos are allowed and what they mean 🎀
+------------------------------+------------------------+
| MESSAGE ID zero | MESSAGE ID nonzero |
+--------+------------------------------+------------------------+
| QR=0 | DSO unidirectional message | DSO request message |
+--------+------------------------------+------------------------+
| QR=1 | Invalid - Fatal Error | DSO response message |
+--------+------------------------------+------------------------+8.2. TLV Usage
Ooh this one is my favourite 😭 It tells you, for each of the three TLVs in this doc, whether they're allowed in each of ten different contexts. Main character energy 👑
The first five contexts are DSO requests or DSO unidirectional messages going from client to server, plus the responses coming back from server to client 🧚
o C-P - Primary TLV, sent in DSO request message, from client to server, with nonzero MESSAGE ID indicating that this request MUST generate response message. 💅
o C-U - Primary TLV, sent in DSO unidirectional message, from client to server, with zero MESSAGE ID indicating that this request MUST NOT generate response message. 🙈
o C-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from client to server. 🍓
o CRP - Response Primary TLV, included in response message sent back to the client (in response to a client "C-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV in the request. 🫶
o CRA - Response Additional TLV, included in response message sent back to the client (in response to a client "C-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV does not match the DSO-TYPE of the Primary TLV in the request. 🔥
The second five contexts are the mirror images, going the other way: DSO requests or DSO unidirectional messages from server to client, and the matching responses from client back to server 🌈
o S-P - Primary TLV, sent in DSO request message, from server to client, with nonzero MESSAGE ID indicating that this request MUST generate response message. 💜
o S-U - Primary TLV, sent in DSO unidirectional message, from server to client, with zero MESSAGE ID indicating that this request MUST NOT generate response message. ⭐
o S-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from server to client. 🎀
o SRP - Response Primary TLV, included in response message sent back to the server (in response to a server "S-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV in the request. 🦋
o SRA - Response Additional TLV, included in response message sent back to the server (in response to a server "S-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV does not match the DSO-TYPE of the Primary TLV in the request. 🌸
Here's the table, so you can see which TLVs are valid in which context 🧚
+-------------------------+-------------------------+
| C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA |
+-----------+-------------------------+-------------------------+
| KeepAlive | X X | X |
+-----------+-------------------------+-------------------------+
| RetryDelay| X | X X |
+-----------+-------------------------+-------------------------+
| Padding | X X | X X |
+-----------+-------------------------+-------------------------+Some of the columns in this table are empty right now, and that's on purpose. It's a template for future TLV definitions to follow. It is recommended that definitions of future TLVs include a similar table summarizing the contexts where the new TLV is valid 💖
9. Additional Considerations ✨
9.1. Service Instances 🎀
We use the term "service instance" to refer to software running on a host that can receive connections on some set of { IP address, port } tuples. 🦋 What makes it an instance is that no matter which of those tuples the client uses to connect, the client is connected to the same software, running on the same logical node (see Section 9.2), and gets the same answers and the same keying information. Iconic 💅
Service instances are identified from the client's point of view. If the client is configured with { IP address, port } tuples, it has no way to tell whether the service at one tuple is the same server listening on a different tuple. So in this case, the client treats each different tuple as a different service instance 🙈
Sometimes a client is configured with a hostname and a port number. The port number can be given explicitly, or it can be left out and assumed to have some default value. The hostname and port can also be learned from the network, like with DNS SRV records 🌈 In these cases, the { hostname, port } tuple uniquely identifies the service instance, subject to the usual case-insensitive DNS comparison of names [RFC1034]. 💜
It's possible that two hostnames point to some of the same IP addresses. This is a configuration anomaly that the client is not obliged to detect 🤷♀️ The result could be that after being told to disconnect, the client reconnects to the same server, because it's represented as a different service instance. Not me getting confused 💀
Implementations SHOULD NOT resolve hostnames and then match up IP address(es) to decide whether two entities should be treated as the "same service instance". 🫶
9.2. Anycast Considerations 🌸
When an anycast service is configured on a particular IP address and port, there is more than one physical server answering on that IP address. Each of those servers can be treated as equivalent 🧚 "Equivalent" here means both servers can provide the same service and, where appropriate, the same authentication information, such as PKI certificates, when establishing connections. 🔐
If a change in network topology sends packets for a particular TCP connection to an anycast server instance that doesn't know about the connection, the new server will automatically terminate the connection with a TCP reset. It has no record of the connection, so the client can then reconnect or stop using the connection, as appropriate 😭
If, after the connection is re-established, the client's assumption that it's connected to the same instance gets violated in some way, that counts as incorrect behavior in this context. It is, however, out of scope for this specification to make specific recommendations here. That's up to follow-on documents that describe specific uses of DNS Stateful Operations 📚
9.3. Connection Sharing 🍓
As previously specified for DNS-over-TCP [RFC7766]:
To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top of TCP (for example, if the resolver was using TLS). However, it is noted that certain primary/secondary configurations with many busy zones might need to use more than one TCP connection for zone transfers for operational reasons (for example, to support concurrent transfers of multiple zones).
A single server may support multiple services, including DNS Updates [RFC2136], DNS Push Notifications [Push], and other services, for one or more DNS zones. When a client discovers that the target server for several different operations is the same service instance (see Section 9.1), the client SHOULD use a single shared DSO Session for all those operations. ✨
This requirement has two benefits. First, it reduces unnecessary connection load on the DNS server. Second, it avoids the connection startup time that would be spent establishing each new additional connection to the same DNS server. 🎀
However, server implementers and operators should be aware that connection sharing may not be possible in all cases. A single host device may be home to multiple independent client software instances that don't coordinate with each other. Similarly, multiple independent client devices behind the same NAT gateway will also typically appear to the DNS server as different source ports on the same client IP address. Because of these constraints, a DNS server MUST be prepared to accept multiple connections from different source ports on the same client IP address. 🌈
9.4. Operational Considerations for Middleboxes 🎀
okay bestie, if an application-layer middlebox is in the path (like a DNS proxy, forwarder, or session multiplexer), you have to be careful that DSO traffic doesn't get mangled 😭 The easiest fix is to just not use middleboxes 💅 If that's not possible, you need to actually check that they behave correctly.
Correct middlebox behavior looks like one of these:
- The middlebox does not forward DSO messages and responds to DSO messages with a response code other than
NOERRORorDSOTYPENI. 🙅♀️ - The middlebox acts as a DSO server and follows this specification in establishing connections. 👑
- There is a 1:1 correspondence between incoming and outgoing connections. So when a connection is made to the middlebox, exactly one matching connection is made from the middlebox to some DNS resolver, and every incoming message gets forwarded without being modified or reordered. A NAT forwarder or a TCP connection optimizer (for example, one used on a high-latency connection like a geosynchronous satellite link) is an example of this. 🛰️
Middleboxes that don't meet one of those criteria are very likely to fail in weird, hard-to-debug ways 💀 For example, a DNS load balancer might unbundle DNS messages from the incoming TCP stream and send each message to a different DNS server. If you're using a load balancer like that, and the DNS servers behind it implement DSO and are configured to enable it, DSO Session establishment will succeed, but there won't be a coherent session between the client and the server. 😭 If the load balancer points at a DNS server that doesn't implement DSO or is configured not to allow it, there's no problem yet, but that setup is risky because it can fail unexpectedly if someone installs new server software that does implement DSO. 🫠
It is of course possible to build a middlebox that properly supports DSO. It's even possible to build one that handles DSO with long-lived operations. You can do that either by keeping the 1:1 correspondence between incoming and outgoing connections (like above), or by terminating incoming sessions at the middlebox while keeping state in the middlebox about any long-lived operations that get requested. Specifying this in detail is beyond the scope of this document 🧚
9.5. TCP Delayed Acknowledgement Considerations 🦋
Most modern implementations of the Transmission Control Protocol (TCP) include a feature called "Delayed Acknowledgement" [RFC1122].
Without this feature, TCP can be super wasteful on the network 😩 Let's look at remote login using a very simple TCP implementation that doesn't have delayed acks. When the user types a keystroke, a data packet gets sent. When that packet arrives at the server, the simple TCP implementation sends an immediate acknowledgement. Milliseconds later, the server process reads the one byte of keystroke data, so the simple TCP implementation sends an immediate window update. Milliseconds after that, the server process generates the character echo and sends that data back in reply. The simple TCP implementation then sends this data packet immediately too. So for one keystroke, this simple implementation sends a burst of three packets almost instantly (ack, window update, data). Chaotic 💀
Clearly it would be more efficient to combine those three separate packets into one, and that's exactly what the delayed ack feature enables ✨
With delayed ack, the TCP implementation waits after receiving a data packet, typically for 200 ms. Then it sends its ack if (a) more data packet(s) arrive, (b) the receiving process generates some reply data, or (c) 200 ms pass without either of the above happening.
With delayed ack, remote login becomes way more efficient, generating just one packet instead of three for each character echo 🙌
The logic behind delayed ack is that the 200 ms delay can't do any significant harm. If something on the other end is waiting for something, the receiving process should generate the reply that the other end is waiting for, and TCP will then immediately send that reply (combined with the ack and window update). And if the receiving process doesn't generate any reply for this particular message, then by definition the thing on the other end can't be waiting for anything. So the 200 ms delay is harmless 🫶
This assumption may be true unless the sender is using Nagle's algorithm, a similar efficiency feature. Nagle's algorithm was created to protect the network from poorly written client software that does lots of rapid small writes in a row. It lets those small writes get coalesced into larger, less wasteful packets 📦
Unfortunately, Nagle's algorithm and delayed ack, two valuable efficiency features, can interact badly with each other when they're used together [NagleDA]. 😤
DSO request messages elicit responses. DSO unidirectional messages and DSO response messages do not.
For DSO request messages, which do elicit responses, Nagle's algorithm and delayed ack work as intended ✅
For DSO messages that don't elicit responses, the delayed ack mechanism causes the ack to be delayed by 200 ms. That 200 ms delay on the ack can then cause Nagle's algorithm to stop the sender from sending any more data for 200 ms, until the awaited ack arrives. On an enterprise Gigabit Ethernet (GigE) backbone with sub-millisecond round-trip times, 200 ms is enormous in comparison 😱
When this issue comes up, there are two solutions that people often suggest. Neither is ideal:
- Disable delayed ack. For DSO messages that elicit no response, removing delayed ack avoids the needless 200 ms delay and sends back an immediate ack. That tells Nagle's algorithm that it should immediately give the sender permission to send its next packet. Unfortunately, for DSO messages that do elicit a response, removing delayed ack removes the efficiency gains of combining acks with data, so the responder will now send two or three packets instead of one 🥲
- Disable Nagle's algorithm. When acks are delayed by the delayed ack algorithm, removing Nagle's algorithm stops the sender from being blocked from immediately sending its next small packet. Unfortunately, on a network with a higher round-trip time, removing Nagle's algorithm removes the efficiency gains of combining multiple small packets into fewer, larger ones. The goal there is to limit how many small packets are in flight at any one time 🧐
The real problem is that with DSO messages that elicit no response, the TCP implementation is stuck waiting. It's unsure whether a response is about to be generated, or whether it should just go ahead and send an ack and window update 🫠
The solution is networking APIs that let the receiver tell the TCP implementation that a received message has been read and processed, and that no response for this message will be generated. TCP can then stop waiting for a response that's never coming, and immediately send an ack and window update 🙌
For implementations of DSO, disabling delayed ack is NOT RECOMMENDED because of the harm this can do to the network. 🚫
For implementations of DSO, disabling Nagle's algorithm is NOT RECOMMENDED because of the harm this can do to the network. 🚫
When this document was being prepared for publication, it was known that at least one TCP implementation lets the recipient of a TCP message signal that it's not going to send a response, so the delayed ack mechanism can stop waiting. Implementations on operating systems where this feature is available SHOULD make use of it. 🔥
10. IANA Considerations 🌈
10.1. DSO OPCODE Registration 💖
IANA has assigned the value 6 for DNS Stateful Operations (DSO) in the "DNS OpCodes" registry. ✨
10.2. DSO RCODE Registration 🍓
IANA has assigned the value 11 for the DSOTYPENI error code in the "DNS RCODEs" registry. The DSOTYPENI error code ("DSO-TYPE Not Implemented") means the receiver does implement DNS Stateful Operations, but doesn't implement the specific DSO-TYPE of the Primary TLV in the DSO request message. It's giving "I speak DSO, just not that flavor" 💜
10.3. DSO Type Code Registry
Okay so IANA made a 16-bit "DSO Type Codes" registry 💅 and it comes pre-loaded with these hex values, bestie:
+-----------+-----------------------+-------+-----------+-----------+
| Type | Name | Early | Status | Reference |
| | | Data | | |
+-----------+-----------------------+-------+-----------+-----------+
| 0000 | Reserved | NO | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0001 | KeepAlive | OK | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0002 | RetryDelay | NO | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0003 | EncryptionPadding | NA | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0004-003F | Unassigned, reserved | NO | | |
| | for DSO session- | | | |
| | management TLVs | | | |
| | | | | |
| 0040-F7FF | Unassigned | NO | | |
| | | | | |
| F800-FBFF | Experimental/local | NO | | |
| | use | | | |
| | | | | |
| FC00-FFFF | Reserved for future | NO | | |
| | expansion | | | |
+-----------+-----------------------+-------+-----------+-----------+Here's what each field means 🎀
Type: The 16-bit DSO type code.Name: The human-readable name of the TLV.Early Data: If OK, this TLV may be sent as early data in a TLS zero round-trip (Section 2.3 of the TLS 1.3 specification [RFC8446]) initial handshake. If NA, the TLV may appear as an Additional TLV in a DSO message that is sent as early data.Status: RFC status (e.g., "Standards Track") or "External" if not documented in an RFC.Reference: A stable reference to the document in which this TLV is defined.
Note: DSO Type Code zero is reserved and is not currently intended for allocation. Hands off zero, it's not for you 🙈
Registering new codes in the "Reserved for DSO session-management" range 0004-003F or the "Reserved for future expansion" range FC00-FFFF needs an IETF Standards Action document [RFC8126]. Serious stuff, so it gets a serious process 👑
Requests for new codes in the "Unassigned" range 0040-F7FF get recorded by IANA after Expert Review [RFC8126] ✨ The expert should check that the requested type code is specified in a way that conforms to this specification, and that the intended use wouldn't be better served by an experimental/local assignment.
DSO Type Codes in the "experimental/local" range F800-FBFF can be used as Experimental Use or Private Use values [RFC8126]. Go wild for development or for use within a single site 🧚 Nobody is checking whether multiple sites reuse the same value in different (and incompatible) ways. IANA doesn't need to review these, since it doesn't record them, and they aren't generally useful for broad interoperability. Sites using "experimental/local" values are responsible for making sure no conflicts happen within their intended scope.
Any document that defines a new TLV listing "OK" in the Early Data column must include a threat analysis for using that TLV in a TLS zero round-trip. See Section 11.1 for details 🔥
11. Security Considerations 🔐
Okay, this part is seriously important, so pay attention 🙈
If this mechanism is used with DNS-over-TLS, these messages are subject to the same constraints as any other DNS-over-TLS messages, and they MUST NOT be sent in the clear before the TLS session is established.
The data field of the "Encryption Padding" TLV could be used as a covert channel 👀
When designing new DSO TLVs, you should think about whether data in the TLV could be used as a tracking identifier, and avoid that when it isn't required.
When DSO is used without TLS or similar cryptographic protection, a malicious entity may be able to inject a malicious unidirectional DSO Retry Delay message into the data stream. If it specifies an unreasonably large RETRY DELAY, that causes a denial-of-service attack against the client 💀
Establishing DSO Sessions affects the number of open TCP connections on a DNS server, so the server may need additional resources. However, the server can limit how many DSO Sessions it establishes and can close existing ones as needed, so denial of service or resource exhaustion should not be a concern 💖
11.1. TLS Zero Round-Trip Considerations
DSO allows zero round-trip operation using TCP Fast Open with TLS 1.3 [RFC8446] early data to reduce or eliminate round trips during session establishment ⚡ TCP Fast Open is only permitted in combination with TLS 1.3 early data. In the rest of this section, "early data" means TLS 1.3 early data in a TLS zero round-trip initial handshake message, whether or not it's included in a TCP SYN packet with early data using the TCP Fast Open option.
A DSO message may or may not be permitted to be sent as early data. Each TLV that can be used as a Primary TLV is required to state whether or not that TLV is permitted as early data. Only response-requiring messages are ever permitted as early data, and only clients are permitted to send a DSO message as early data unless there is an implicit DSO session (see Section 5.1) 🫶
For DSO messages that are permitted as early data, a client MAY include one or more such messages as early data without waiting for a DSO response to the first DSO request message. That response is what confirms the DSO Session was successfully established.
Unless there is an implicit DSO session, a client MUST NOT send DSO unidirectional messages until a DSO Session has been mutually established. No skipping ahead, bestie 🙅♀️
Similarly, unless there is an implicit DSO session, a server MUST NOT send DSO request messages until it has received a response-requiring DSO request message from a client and transmitted a successful NOERROR response for that request.
Caution must be taken to make sure DSO messages sent as early data are idempotent, or are otherwise immune to any problems caused by the inadvertent replay that can happen with zero round-trip operation 🔁
It would be possible to add a TLV that requires the server to do significant work and send it to the server as initial data in a TCP SYN packet. A flood of such packets could be used as a DoS attack on the server. None of the TLVs defined here have this property 🛡️
If a new TLV is specified that does have this property, that TLV must be specified as not permitted in zero round-trip messages. This prevents work from being done until a round-trip has occurred from the server to the client to verify that the source address of the packet is reachable.
Documents that define new TLVs must state whether each new TLV may be sent as early data. Such documents must include a threat analysis in the security considerations section for each TLV defined in the document that may be sent as early data. This threat analysis should be based on the advice in Sections 2.3, 8, and Appendix E.5 of the TLS 1.3 specification [RFC8446] 🧠
12. References 📚
12.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>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[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>.
[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>.
[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>.
12.2. Informative References ✨
Okay bestie, now we're in the "further reading" zone 📚. These are the informative references, the docs this RFC points to for extra context. Here they are, every single one, labels and all 🎀
[Fail] Andrews, M. and R. Bellis, "A Common Operational Problem in DNS Servers - Failure To Communicate", Work in Progress, draft-ietf-dnsop-no-response-issue-13, February 2019.
[NagleDA] Cheshire, S., "TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK", May 2005, <http://www.stuartcheshire.org/papers/nagledelayedack/>.
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", Work in Progress, draft-ietf-dnssd-push-18, March 2019.
[Relay] Lemon, T. and S. Cheshire, "Multicast DNS Discovery Relay", Work in Progress, draft-ietf-dnssd-mdns-relay-02, March 2019.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[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>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[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>.
[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>.
[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>.
Acknowledgements 💖
Huge thank-yous to the squad who helped make this document happen 🫶 Stephane Bortzmeyer, Tim Chown, Ralph Droms, Paul Hoffman, Jan Komissar, Edward Lewis, Allison Mankin, Rui Paulo, David Schinazi, Manju Shankar Rao, Bernie Volz, and Bob Harold all brought their contributions, and we are so grateful 🌸✨
Authors' Addresses 🎀
Meet the people behind the spec! 💅 Here are the authors and their contact details, copied exactly as they appear 🦋
Ray Bellis 🌈
Ray Bellis
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
United States of America
Phone: +1 (650) 423-1200
Email: ray@isc.orgStuart Cheshire 🍓
Stuart Cheshire
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Phone: +1 (408) 996-1010
Email: cheshire@apple.comJohn Dickinson 🧚
John Dickinson
Sinodun Internet Technologies
Magadalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: jad@sinodun.comSara Dickinson 💜
Sara Dickinson
Sinodun Internet Technologies
Magadalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: sara@sinodun.comTed Lemon 👑
Ted Lemon
Nibbhaya Consulting
P.O. Box 958
Brattleboro, VT 05302-0958
United States of America
Email: mellon@fugue.comTom Pusateri ⭐
Tom Pusateri
Unaffiliated
Raleigh, NC 27608
United States of America
Phone: +1 (919) 867-1330
Email: pusateri@bangj.comAnd that's a wrap on RFC 8490, bestie! 🌈💖 Every reference, name, and address is intact, so you're all set to dive in 🦋✨
📦 where this page comes from
- ietf: rfc8490 2019-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms