GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8490

Internet Engineering Task Force (IETF) R. Bellis Request for Comments: 8490 ISC Updates: 1035, 7766 S. Cheshire Category: Standards Track Apple Inc. ISSN: 2070-1721 J. Dickinson

                                                          S. Dickinson
                                                               Sinodun
                                                              T. Lemon
                                                   Nibbhaya Consulting
                                                           T. Pusateri
                                                          Unaffiliated
                                                            March 2019
                      DNS Stateful Operations

Abstract

 This document defines a new DNS OPCODE for DNS Stateful Operations
 (DSO).  DSO messages communicate operations within persistent
 stateful sessions using Type Length Value (TLV) syntax.  Three TLVs
 are defined that manage session timeouts, termination, and encryption
 padding, and a framework is defined for extensions to enable new
 stateful operations.  This document updates RFC 1035 by adding a new
 DNS header OPCODE that has both different message semantics and a new
 result code.  This document updates RFC 7766 by redefining a session,
 providing new guidance on connection reuse, and providing a new
 mechanism for handling session idle timeouts.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8490.

Bellis, et al. Standards Track [Page 1] RFC 8490 DNS Stateful Operations March 2019

Copyright Notice

 Copyright (c) 2019 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (https://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
 2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
 3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
 4.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.1.  Session Management  . . . . . . . . . . . . . . . . .   9
     4.1.2.  Long-Lived Subscriptions  . . . . . . . . . . . . . .   9
   4.2.  Applicable Transports . . . . . . . . . . . . . . . . . .  10
 5.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  11
   5.1.  DSO Session Establishment . . . . . . . . . . . . . . . .  12
     5.1.1.  DSO Session Establishment Failure . . . . . . . . . .  13
     5.1.2.  DSO Session Establishment Success . . . . . . . . . .  14
   5.2.  Operations after DSO Session Establishment  . . . . . . .  14
   5.3.  DSO Session Termination . . . . . . . . . . . . . . . . .  15
     5.3.1.  Handling Protocol Errors  . . . . . . . . . . . . . .  15
   5.4.  Message Format  . . . . . . . . . . . . . . . . . . . . .  16
     5.4.1.  DNS Header Fields in DSO Messages . . . . . . . . . .  17
     5.4.2.  DSO Data  . . . . . . . . . . . . . . . . . . . . . .  18
     5.4.3.  DSO Unidirectional Messages . . . . . . . . . . . . .  20
     5.4.4.  TLV Syntax  . . . . . . . . . . . . . . . . . . . . .  21
     5.4.5.  Unrecognized TLVs . . . . . . . . . . . . . . . . . .  22
     5.4.6.  EDNS(0) and TSIG  . . . . . . . . . . . . . . . . . .  23
   5.5.  Message Handling  . . . . . . . . . . . . . . . . . . . .  24
     5.5.1.  Delayed Acknowledgement Management  . . . . . . . . .  25
     5.5.2.  MESSAGE ID Namespaces . . . . . . . . . . . . . . . .  26
     5.5.3.  Error Responses . . . . . . . . . . . . . . . . . . .  27
   5.6.  Responder-Initiated Operation Cancellation  . . . . . . .  28
 6.  DSO Session Lifecycle and Timers  . . . . . . . . . . . . . .  29
   6.1.  DSO Session Initiation  . . . . . . . . . . . . . . . . .  29
   6.2.  DSO Session Timeouts  . . . . . . . . . . . . . . . . . .  30
   6.3.  Inactive DSO Sessions . . . . . . . . . . . . . . . . . .  31

Bellis, et al. Standards Track [Page 2] RFC 8490 DNS Stateful Operations March 2019

   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

Bellis, et al. Standards Track [Page 3] RFC 8490 DNS Stateful Operations March 2019

1. Introduction

 This document specifies a mechanism for managing stateful DNS
 connections.  DNS most commonly operates over a UDP transport, but it
 can also operate over streaming transports; the original DNS RFC
 specifies DNS-over-TCP [RFC1035], and a profile for DNS-over-TLS
 [RFC7858] has been specified.  These transports can offer persistent
 long-lived sessions and therefore, when using them for transporting
 DNS messages, it is of benefit to have a mechanism that can establish
 parameters associated with those sessions, such as timeouts.  In such
 situations, it is also advantageous to support server-initiated
 messages (such as DNS Push Notifications [Push]).
 The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is
 explicitly defined to only have "per-message" semantics.  While
 EDNS(0) has been used to signal at least one session-related
 parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), the result
 is less than optimal due to the restrictions imposed by the EDNS(0)
 semantics and the lack of server-initiated signaling.  For example, a
 server cannot arbitrarily instruct a client to close a connection
 because the server can only send EDNS(0) options in responses to
 queries that contained EDNS(0) options.
 This document defines a new DNS OPCODE for DNS Stateful Operations
 (DSO) with a value of 6.  DSO messages are used to communicate
 operations within persistent stateful sessions, expressed using Type
 Length Value (TLV) syntax.  This document defines an initial set of
 three TLVs used to manage session timeouts, termination, and
 encryption padding.
 All three TLVs defined here are mandatory for all implementations of
 DSO.  Further TLVs may be defined in additional specifications.
 DSO messages may or may not be acknowledged.  Whether a DSO message
 is to be acknowledged (a DSO request message) or is not to be
 acknowledged (a DSO unidirectional message) is specified in the
 definition of that particular DSO message type.  The MESSAGE ID is
 nonzero for DSO request messages, and zero for DSO unidirectional
 messages.  Messages are pipelined and responses may appear out of
 order when multiple requests are being processed concurrently.
 The format for DSO messages (Section 5.4) differs somewhat from the
 traditional DNS message format used for standard queries and
 responses.  The standard twelve-byte header is used, but the four
 count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero,
 and accordingly their corresponding sections are not present.

Bellis, et al. Standards Track [Page 4] RFC 8490 DNS Stateful Operations March 2019

 The actual data pertaining to DNS Stateful Operations (expressed in
 TLV syntax) is appended to the end of the DNS message header.  Just
 as in traditional DNS-over-TCP [RFC1035] [RFC7766], the stream
 protocol carrying DSO messages (which are just another kind of DNS
 message) frames them by putting a 16-bit message length at the start.
 The length of the DSO message is therefore determined from that
 length rather than from any of the DNS header counts.
 When displayed using packet analyzer tools that have not been updated
 to recognize the DSO format, this will result in the DSO data being
 displayed as unknown extra data after the end of the DNS message.
 This new format has distinct advantages over an RR-based format
 because it is more explicit and more compact.  Each TLV definition is
 specific to its use case and, as a result, contains no redundant or
 overloaded fields.  Importantly, it completely avoids conflating DNS
 Stateful Operations in any way with normal DNS operations or with
 existing EDNS(0)-based functionality.  A goal of this approach is to
 avoid the operational issues that have befallen EDNS(0), particularly
 relating to middlebox behavior (see sections discussing EDNS(0), and
 problems caused by firewalls and load balancers, in the recent work
 describing causes of DNS failures [Fail]).
 With EDNS(0), multiple options may be packed into a single OPT
 pseudo-RR, and there is no generalized mechanism for a client to be
 able to tell whether a server has processed or otherwise acted upon
 each individual option within the combined OPT pseudo-RR.  The
 specifications for each individual option need to define how each
 different option is to be acknowledged, if necessary.
 In contrast to EDNS(0), with DSO there is no compelling motivation to
 pack multiple operations into a single message for efficiency
 reasons, because DSO always operates using a connection-oriented
 transport protocol.  Each DSO operation is communicated in its own
 separate DNS message, and the transport protocol can take care of
 packing several DNS messages into a single IP packet if appropriate.
 For example, TCP can pack multiple small DNS messages into a single
 TCP segment.  This simplification allows for clearer semantics.  Each
 DSO request message communicates just one primary operation, and the
 RCODE in the corresponding response message indicates the success or
 failure of that operation.

Bellis, et al. Standards Track [Page 5] RFC 8490 DNS Stateful Operations March 2019

2. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.

3. Terminology

 DSO:  DNS Stateful Operations.
 connection:  a bidirectional byte (or message) stream, where the
    bytes (or messages) are delivered reliably and in order, such as
    provided by using DNS-over-TCP [RFC1035] [RFC7766] or DNS-over-TLS
    [RFC7858].
 session:  the unqualified term "session" in the context of this
    document refers to a persistent network connection between two
    endpoints that allows for the exchange of DNS messages over a
    connection where either end of the connection can send messages to
    the other end.  (The term has no relationship to the "session
    layer" of the OSI "seven-layer model".)
 DSO Session:  a session established between two endpoints that
    acknowledge persistent DNS state via the exchange of DSO messages
    over the connection.  This is distinct from a DNS-over-TCP session
    as described in the previous specification for DNS-over-TCP
    [RFC7766].
 close gracefully:  a normal session shutdown where the client closes
    the TCP connection to the server using a graceful close such that
    no data is lost (e.g., using TCP FIN; see Section 5.3).
 forcibly abort:  a session shutdown as a result of a fatal error
    where the TCP connection is unilaterally aborted without regard
    for data loss (e.g., using TCP RST; see Section 5.3).
 server:  the software with a listening socket, awaiting incoming
    connection requests, in the usual DNS sense.
 client:  the software that initiates a connection to the server's
    listening socket, in the usual DNS sense.
 initiator:  the software that sends a DSO request message or a DSO
    unidirectional message during a DSO Session.  Either a client or
    server can be an initiator.

Bellis, et al. Standards Track [Page 6] RFC 8490 DNS Stateful Operations March 2019

 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.

Bellis, et al. Standards Track [Page 7] RFC 8490 DNS Stateful Operations March 2019

 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.

Bellis, et al. Standards Track [Page 8] RFC 8490 DNS Stateful Operations March 2019

4. Applicability

 DNS Stateful Operations are applicable to several known use cases and
 are only applicable on transports that are capable of supporting a
 DSO Session.

4.1. Use Cases

 Several use cases for DNS Stateful Operations are described below.

4.1.1. Session Management

 In one use case, establishing session parameters such as server-
 defined timeouts is of great use in the general management of
 persistent connections.  For example, using DSO Sessions for stub-to-
 recursive DNS-over-TLS [RFC7858] is more flexible for both the client
 and the server than attempting to manage sessions using just the
 edns-tcp-keepalive EDNS(0) Option [RFC7828].  The simple set of TLVs
 defined in this document is sufficient to greatly enhance connection
 management for this use case.

4.1.2. Long-Lived Subscriptions

 In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763]
 has evolved into a naturally session-based mechanism where, for
 example, long-lived subscriptions lend themselves to 'push'
 mechanisms as opposed to polling.  Long-lived stateful connections
 and server-initiated messages align with this use case [Push].
 A general use case is that DNS traffic is often bursty, but session
 establishment can be expensive.  One challenge with long-lived
 connections is sustaining sufficient traffic to maintain NAT and
 firewall state.  To mitigate this issue, this document introduces a
 new concept for the DNS -- DSO "keepalive traffic".  This traffic
 carries no DNS data and is not considered 'activity' in the classic
 DNS sense, but it serves to maintain state in middleboxes and to
 assure the client and server that they still have connectivity to
 each other.

Bellis, et al. Standards Track [Page 9] RFC 8490 DNS Stateful Operations March 2019

4.2. Applicable Transports

 DNS Stateful Operations are applicable in cases where it is useful to
 maintain an open session between a DNS client and server, where the
 transport allows such a session to be maintained, and where the
 transport guarantees in-order delivery of messages on which DSO
 depends.  Two specific transports that meet the requirements to
 support DNS Stateful Operations are DNS-over-TCP [RFC1035] [RFC7766]
 and DNS-over-TLS [RFC7858].
 Note that in the case of DNS-over-TLS, there is no mechanism for
 upgrading from DNS-over-TCP to DNS-over-TLS mid-connection (see
 Section 7 of the DNS-over-TLS specification [RFC7858]).  A connection
 is either DNS-over-TCP from the start, or DNS-over-TLS from the
 start.
 DNS Stateful Operations are not applicable for transports that cannot
 support clean session semantics or that do not guarantee in-order
 delivery.  While in principle such a transport could be constructed
 over UDP, the current specification of DNS-over-UDP [RFC1035] does
 not provide in-order delivery or session semantics and hence cannot
 be used.  Similarly, DNS-over-HTTP [RFC8484] cannot be used because
 HTTP has its own mechanism for managing sessions, which is
 incompatible with the mechanism specified here.
 Only DNS-over-TCP and DNS-over-TLS are currently defined for use with
 DNS Stateful Operations.  Other transports may be added in the future
 if they meet the requirements set out in the first paragraph of this
 section.

Bellis, et al. Standards Track [Page 10] RFC 8490 DNS Stateful Operations March 2019

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 that 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 that 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).

Bellis, et al. Standards Track [Page 11] RFC 8490 DNS Stateful Operations March 2019

 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 else 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 must first 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, and in these cases either
 client or server may initiate DSO messages at any time.  In this
 case, the session is established as soon as the connection is
 established; this is referred to as implicit DSO Session
 establishment.
 However, in the typical case a server will not know in advance
 whether a client supports DSO, so in general, unless it is 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

Bellis, et al. Standards Track [Page 12] RFC 8490 DNS Stateful Operations March 2019

 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.

Bellis, et al. Standards Track [Page 13] RFC 8490 DNS Stateful Operations March 2019

 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.

5.2. Operations after DSO Session Establishment

 Once a DSO Session has been established, clients and servers should
 behave as described in this specification with regard to inactivity
 timeouts and session termination, not as previously prescribed in the
 earlier specification for DNS-over-TCP [RFC7766].
 Because a server that supports DNS Stateful Operations MUST return an
 RCODE of "NOERROR" when it receives a Keepalive TLV DSO request
 message, the Keepalive TLV is an ideal candidate for use in
 establishing a DSO Session.  Any other option that can only succeed

Bellis, et al. Standards Track [Page 14] RFC 8490 DNS Stateful Operations March 2019

 when sent to a server of the desired kind is also a good candidate
 for use in establishing a DSO Session.  For clients that implement
 only the DSO-TYPEs defined in this base specification, sending a
 Keepalive TLV is the only DSO request message they have available to
 initiate a DSO Session.  Even for clients that do implement other
 future DSO-TYPEs, for simplicity they MAY elect to always send an
 initial DSO Keepalive request message as their way of initiating a
 DSO Session.  A future definition of a new response-requiring DSO-
 TYPE gives implementers the option of using that new DSO-TYPE if they
 wish, but does not change the fact that sending a Keepalive TLV
 remains a valid way of initiating a DSO Session.

5.3. DSO Session Termination

 A DSO Session is terminated when the underlying connection is closed.
 DSO Sessions are "closed gracefully" as a result of the server
 closing a DSO Session because it is overloaded, because of the client
 closing the DSO Session because it is done, or because of the client
 closing the DSO Session because it is inactive.  DSO Sessions are
 "forcibly aborted" when either the client or server closes the
 connection because of a protocol error.
 o  Where this specification 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 specification
    requires a connection to be closed gracefully, the requirement to
    initiate that graceful close is placed on the client in order to
    place the burden of TCP's TIME-WAIT state on the client rather
    than the server.
 o  Where this specification says "forcibly abort", it means sending a
    TCP RST or the equivalent for other protocols.  In the BSD Sockets
    API, this is achieved by setting the SO_LINGER option to zero
    before closing the socket.

5.3.1. Handling Protocol Errors

 In protocol implementation, there are generally two kinds of errors
 that software writers have to deal with.  The first is situations
 that arise due to factors in the environment, such as temporary loss
 of connectivity.  While undesirable, these situations do not indicate
 a flaw in the software and are situations that software should
 generally be able to recover from.
 The second is situations that should never happen when communicating
 with a compliant DSO implementation.  If they do happen, they
 indicate a serious flaw in the protocol implementation beyond what is
 reasonable to expect software to recover from.  This document

Bellis, et al. Standards Track [Page 15] RFC 8490 DNS Stateful Operations March 2019

 describes this latter form of error condition as a "fatal error" and
 specifies that an implementation encountering a fatal error condition
 "MUST forcibly abort the connection immediately".

5.4. Message Format

 A DSO message begins with the standard twelve-byte DNS message header
 [RFC1035] with the OPCODE field set to the DSO OPCODE (6).  However,
 unlike standard DNS messages, the question section, answer section,
 authority records section, and additional records sections are not
 present.  The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
 ARCOUNT) MUST be set to zero on transmission.
 If a DSO message is received where 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                            /
    /                                                               /
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Bellis, et al. Standards Track [Page 16] RFC 8490 DNS Stateful Operations March 2019

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 is not currently using for
 any other active operation on this connection.  For the purposes
 here, a MESSAGE ID is in use in this DSO Session if the initiator has
 used it in a DSO request message for which it is still awaiting a
 response, or if the client has used it to set up a long-lived
 operation that has not yet been canceled.  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 determined only by the specification for the Primary TLV.
 An acknowledgment cannot be requested by including a nonzero MESSAGE
 ID in a message that is required according to its Primary TLV to be
 unidirectional.  Nor can an acknowledgment be prevented by sending a
 MESSAGE ID of zero in a message that is required to be a DSO request
 message according to its Primary TLV.  A responder that receives
 either such malformed message 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 is
 not zero, the message is not 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 is not one, the message is not a DSO response message.
 In a DSO response message (QR=1), the MESSAGE ID field MUST NOT be
 zero, and MUST contain a copy of the value of the (nonzero) MESSAGE
 ID field in the DSO request message being responded to.  If a DSO
 response message (QR=1) is received where the MESSAGE ID is zero,
 this is 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 are currently unused in DSO messages; 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 the
 definition of the request.  For example, in a Retry Delay message
 (Section 6.6.1), the RCODE indicates the reason for termination.
 However, in most DSO request messages (QR=0), except where clearly

Bellis, et al. Standards Track [Page 17] RFC 8490 DNS Stateful Operations March 2019

 specified otherwise, the RCODE is set to zero on transmission, and
 silently ignored on reception.
 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      |
 +------+-----------+------------------------------------------------+
 Use of the above RCODEs is likely to be common in DSO but does not
 preclude the definition and use of other codes in future documents
 that make use of DSO.
 If a document defining a new DSO-TYPE makes use of response codes not
 defined here, then that document MUST specify the specific
 interpretation of those RCODE values in the context of that new DSO
 TLV.
 The RCODE field is followed by the four zero-valued count fields,
 followed by the DSO Data.

5.4.2. DSO Data

 The standard twelve-byte DNS message header with its zero-valued
 count fields is followed by the DSO Data, expressed using TLV syntax,
 as described in Section 5.4.4.
 A DSO request message or DSO unidirectional message MUST contain at
 least one TLV.  The first TLV in a DSO request message or DSO
 unidirectional message is referred to as the "Primary TLV" and
 determines the nature of the operation being performed, including
 whether it is a DSO request or a DSO unidirectional operation.  In
 some cases, it may be appropriate to include other TLVs in a DSO
 request message or DSO unidirectional message, such as the DSO

Bellis, et al. Standards Track [Page 18] RFC 8490 DNS Stateful Operations March 2019

 Encryption Padding TLV (Section 7.3).  Additional TLVs follow the
 Primary TLV.  Additional TLVs are not limited to what is defined in
 this document.  New Additional TLVs may be defined in the future.
 Their definitions will describe when their use is appropriate.
 An unrecognized Primary TLV results in 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 may contain one or
 more TLVs, appropriate to the information being communicated.
 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
 may contain multiple Response Primary TLVs, or a single Response
 Primary TLV, or in some cases, no Response Primary TLV.  A Response
 Primary TLV is not required; for most DSO operations the MESSAGE ID
 field in the DNS message header is sufficient to identify the DSO
 request message to which a particular response message relates.
 Any other TLVs in a DSO response message are Response Additional
 TLVs, such as the DSO Encryption Padding TLV (Section 7.3).  Response
 Additional TLVs follow the Response Primary TLV(s), if present.
 Response Additional TLVs are not limited to what is defined in this
 document.  New Response Additional TLVs may be defined in the future.
 Their definitions will describe when their use is appropriate.
 Unrecognized Response Additional TLVs are silently ignored, as
 described in Sections 5.4.5 and 8.2.
 The specification for each DSO TLV determines what TLVs are required
 in a response to a DSO request message using that TLV.  If a DSO
 response is received for an operation where the specification
 requires that the response carry a particular TLV or TLVs, and the
 required TLV(s) are not present, then this is a fatal error and the
 recipient of the defective response message MUST forcibly abort the
 connection immediately.  Similarly, if more than the specified number
 of instances of a given TLV are present, this is a fatal error and
 the recipient of the defective response message MUST forcibly abort
 the connection immediately.

Bellis, et al. Standards Track [Page 19] RFC 8490 DNS Stateful Operations March 2019

5.4.3. DSO Unidirectional Messages

 It is anticipated that most DSO operations will be specified to use
 DSO request messages, which generate corresponding DSO responses.  In
 some specialized high-traffic use cases, it may be appropriate to
 specify DSO unidirectional messages.  DSO unidirectional messages can
 be more efficient on the network because they don't generate a stream
 of corresponding reply messages.  Using DSO unidirectional messages
 can also simplify software in some cases by removing the need for an
 initiator to maintain state while it waits to receive replies it
 doesn't care about.  When the specification for a particular TLV used
 as a Primary TLV (i.e., first) in an outgoing DSO request message
 (i.e., QR=0) states that a message is to be 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, applies even in the case of errors.
 When a DSO message is received 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 is unrecognized, 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" in cases
 where the sender doesn't know if the receiver supports the Primary
 TLV in the message because there is no way to receive any response to
 indicate success or failure.  DSO unidirectional messages are only
 appropriate in cases where the sender already knows that the receiver
 supports and wishes to receive these messages.
 For example, after a client has subscribed for Push Notifications
 [Push], the subsequent event notifications are then sent as DSO
 unidirectional messages.  This is appropriate because the client
 initiated the message stream by virtue of its Push Notification
 subscription, thereby indicating its support of Push Notifications
 and its desire to receive those notifications.
 Similarly, after a Discovery Relay client has subscribed to receive
 inbound multicast DNS (mDNS) [RFC6762] traffic from a Discovery
 Relay, the subsequent stream of received packets is then sent using
 DSO unidirectional messages.  This is appropriate because the client
 initiated the message stream by virtue of its Discovery Relay link
 subscription, thereby indicating its support of Discovery Relay and
 its desire to receive inbound mDNS packets over that DSO Session
 [Relay].

Bellis, et al. Standards Track [Page 20] RFC 8490 DNS Stateful Operations March 2019

5.4.4. TLV Syntax

 All TLVs, whether used as "Primary", "Additional", "Response
 Primary", or "Response Additional", use the same encoding syntax.
 A specification that defines a new TLV must specify whether the DSO-
 TYPE can be used as a Primary TLV, and whether the DSO-TYPE can be
 used as an Additional TLV.  Some DSO-TYPEs are dual-purpose and can
 be used as Primary TLVs in some messages, and in other messages as
 Additional TLVs.  The specification for a DSO-TYPE must also state
 whether, when 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 specification must
 also state which TLVs, if any, are to be included in the response and
 how many instances of each of the TLVs are allowed.  The Primary TLV
 may or may not be contained in the response depending on what is
 specified for that TLV.  If multiple instances of the Primary TLV are
 allowed the specification 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, giving 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, giving 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" without attempting to
    interpret it.  Interpretation of the meaning of the DSO-DATA for a
    particular DSO-TYPE is the responsibility of the software that
    implements that DSO-TYPE.

Bellis, et al. Standards Track [Page 21] RFC 8490 DNS Stateful Operations March 2019

5.4.5. Unrecognized TLVs

 If a DSO request message is received containing an unrecognized
 Primary TLV, with a nonzero MESSAGE ID (indicating that a response is
 expected), then 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 is received containing both an
 unrecognized Primary TLV and a zero MESSAGE ID (indicating that no
 response is expected), then this is a fatal error and the recipient
 MUST forcibly abort the connection immediately.
 If a DSO request message or DSO unidirectional message is received
 where the Primary TLV is recognized, containing one or more
 unrecognized Additional TLVs, the unrecognized Additional TLVs MUST
 be silently ignored, and the remainder of the message is interpreted
 and handled as if the unrecognized parts were not present.
 Similarly, if a DSO response message is received containing one or
 more unrecognized TLVs, the unrecognized TLVs MUST be silently
 ignored and the remainder of the message is interpreted and handled
 as if the unrecognized parts are not present.

Bellis, et al. Standards Track [Page 22] RFC 8490 DNS Stateful Operations March 2019

5.4.6. EDNS(0) and TSIG

 Since the ARCOUNT field MUST be zero, a DSO message cannot contain a
 valid EDNS(0) option in the additional records section.  If
 functionality provided by current or future EDNS(0) options is
 desired for DSO messages, one or more new DSO TLVs need to be defined
 to carry the necessary information.
 For example, the EDNS(0) Padding Option [RFC7830] used for security
 purposes is not permitted in a DSO message, so if message padding is
 desired for DSO messages, then 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, which would mean
 that ARCOUNT would be greater than zero.  DSO messages are required
 to have an ARCOUNT of zero.  Therefore, if use of signatures with DSO
 messages becomes necessary in the future, a new DSO TLV would have to
 be defined to perform this function.
 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, including 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
 (because it is obsoleted by the functionality provided by the DSO
 Keepalive operation).  If any message sent on a DSO Session contains
 an edns-tcp-keepalive EDNS(0) Option, this is a fatal error and the
 recipient of the defective message MUST forcibly abort the connection
 immediately.

Bellis, et al. Standards Track [Page 23] RFC 8490 DNS Stateful Operations March 2019

5.5. Message Handling

 As described in Section 5.4.1, whether an outgoing DSO message with
 the QR bit in the DNS header set to zero is a DSO request or a DSO
 unidirectional message is determined by the specification for the
 Primary TLV, which in turn determines whether the MESSAGE ID field in
 that outgoing message will be zero or nonzero.
 Every DSO message with the QR bit in the DNS header set to zero and a
 nonzero MESSAGE ID field is a DSO request message, and MUST elicit a
 corresponding response, with the QR bit in the DNS header set to one
 and the MESSAGE ID field set to the value given in the corresponding
 DSO request message.
 Valid DSO request messages sent by the client with a nonzero MESSAGE
 ID field elicit a response from the server, and valid DSO request
 messages sent by the server with a nonzero MESSAGE ID field elicit a
 response from the client.
 Every DSO message with both the QR bit in the DNS header and the
 MESSAGE ID field set to zero is a DSO unidirectional message and MUST
 NOT elicit a response.

Bellis, et al. Standards Track [Page 24] RFC 8490 DNS Stateful Operations March 2019

5.5.1. Delayed Acknowledgement Management

 Generally, most good TCP implementations employ a delayed
 acknowledgement timer to provide more efficient use of the network
 and better performance.
 With a bidirectional exchange over TCP, such as with a DSO request
 message, the operating system TCP implementation waits for the
 application-layer client software to generate the corresponding DSO
 response message.  The TCP implementation can then send a single
 combined packet containing the TCP acknowledgement, the TCP window
 update, and the application-generated DSO response message.  This is
 more efficient than sending three separate packets, as would occur if
 the TCP packet containing the DSO request were acknowledged
 immediately.
 With a DSO unidirectional message or DSO response message, there is
 no corresponding application-generated DSO response message, and
 consequently, no hint to the transport protocol about when it should
 send its acknowledgement and window update.
 Some networking APIs provide a mechanism that allows the application-
 layer client software to signal to the transport protocol that no
 response will be forthcoming (in effect it can be thought of as a
 zero-length "empty" write).  Where available in the networking API
 being used, the recipient of a DSO unidirectional message or DSO
 response message, having parsed and interpreted the message, SHOULD
 then use this mechanism provided by the networking API to signal that
 no response for this message will be forthcoming.  The TCP
 implementation can then go ahead and send its acknowledgement and
 window update without further delay.  See Section 9.5 for further
 discussion of why this is important.

Bellis, et al. Standards Track [Page 25] RFC 8490 DNS Stateful Operations March 2019

5.5.2. MESSAGE ID Namespaces

 The namespaces of 16-bit MESSAGE IDs are independent in each
 direction.  This means it is *not* an error for both client and
 server to send DSO request messages at the same time as each other,
 using the same MESSAGE ID, in different directions.  This
 simplification is necessary in order for the protocol to be
 implementable.  It would be infeasible to require the client and
 server to coordinate with each other regarding allocation of new
 unique MESSAGE IDs.  It is also not necessary to require the client
 and server to coordinate with each other regarding allocation of new
 unique MESSAGE IDs.  The value of the 16-bit MESSAGE ID combined with
 the identity of the initiator (client or server) is sufficient to
 unambiguously identify the operation in question.  This can be
 thought of as a 17-bit message identifier space using message
 identifiers 0x00001-0x0FFFF for client-to-server DSO request
 messages, and 0x10001-0x1FFFF for server-to-client DSO request
 messages.  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 specified otherwise by the relevant specification for the
 DSO-TYPE in question).  At the very least, this means that 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
 specified otherwise by the relevant specification for the DSO-TYPE in
 question), and for a long-lived operation, the MESSAGE ID for the
 operation can't be reused while that 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 does not match the MESSAGE ID of
 any of its outstanding operations, this is a fatal error and 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, the responder tracks request MESSAGE IDs, and
 the MESSAGE ID matches the MESSAGE ID of a DSO request message it
 received for which a response has not yet been sent, 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 does not track
 MESSAGE IDs in this way, no such risk exists.  Therefore, tracking
 MESSAGE IDs just to implement this sanity check is not required.

Bellis, et al. Standards Track [Page 26] RFC 8490 DNS Stateful Operations March 2019

5.5.3. Error Responses

 When a DSO request message is unsuccessful for some reason, the
 responder returns an error code to the initiator.
 In the case of a server returning 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 allow the DSO Session
 to remain open.  For error conditions that only affect the single
 operation in question, 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.
 Upon receiving an error response from the server, a client SHOULD NOT
 automatically close the DSO Session.  An error relating to one
 particular operation on a DSO Session does not necessarily imply that
 all other operations on that DSO Session have also failed or that
 future operations will fail.  The client should assume that the
 server will make its own decision about whether or not to end the DSO
 Session based on the server's determination of whether the error
 condition pertains to this particular operation or to any subsequent
 operations.  If the server does not 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 (MESSAGE ID field
 is zero), the receiver should already be expecting this DSO message
 type.  Section 5.4.5 describes the handling of 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
 processing the DSO unidirectional message is implementation dependent
 according to the severity of the error.

Bellis, et al. Standards Track [Page 27] RFC 8490 DNS Stateful Operations March 2019

5.6. Responder-Initiated Operation Cancellation

 This document, the base specification for DNS Stateful Operations,
 does not itself define any long-lived operations, but it defines a
 framework for supporting long-lived operations such as Push
 Notification subscriptions [Push] and Discovery Relay interface
 subscriptions [Relay].
 Long-lived operations, if successful, will remain active until the
 initiator terminates the operation.
 However, it is possible that a long-lived operation may be valid at
 the time it was initiated, but then a later change of circumstances
 may render that operation invalid.  For example, a long-lived client
 operation may pertain to a name that the server is authoritative for,
 but then the server configuration is changed such that it is no
 longer authoritative for that name.
 In such cases, instead of terminating the entire session, it may be
 desirable for the responder to be able to cancel selectively only
 those operations that have become invalid.
 The responder performs this selective cancellation by sending a new
 DSO response message with the MESSAGE ID field containing the MESSAGE
 ID of the long-lived operation that is to be terminated (that it had
 previously acknowledged with a NOERROR RCODE) and the RCODE field of
 the new DSO response message giving the reason for cancellation.
 After a DSO response message with nonzero RCODE has been sent, that
 operation has been terminated from the responder's point of view, and
 the responder sends no more messages relating to that operation.
 After a DSO response message with nonzero RCODE has been received by
 the initiator, that operation has been terminated from the
 initiator's point of view, and the canceled operation's MESSAGE ID is
 now free for reuse.

Bellis, et al. Standards Track [Page 28] RFC 8490 DNS Stateful Operations March 2019

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, client or server may initiate as
 many DNS operations as they wish using the 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 for the purpose of
 delivering responses in the same order that the corresponding
 requests were received.
 Section 6.2.1.1 of the DNS-over-TCP specification [RFC7766] specifies
 this in more detail.

Bellis, et al. Standards Track [Page 29] RFC 8490 DNS Stateful Operations March 2019

6.2. DSO Session Timeouts

 Two timeout values are associated with a DSO Session: the inactivity
 timeout and the keepalive interval.  Both values are communicated in
 the same TLV, the Keepalive TLV (Section 7.1).
 The first timeout value, the inactivity timeout, is the maximum time
 for which a client may speculatively keep an inactive DSO Session
 open in the expectation that it may have future requests to send to
 that server.
 The second timeout value, the keepalive interval, is the maximum
 permitted interval between messages if the client wishes to keep the
 DSO Session alive.
 The two timeout values are independent.  The inactivity timeout may
 be shorter, the same, or longer than the keepalive interval, though
 in most cases the inactivity timeout is expected to be shorter than
 the keepalive interval.
 A shorter inactivity timeout with a longer keepalive interval signals
 to the client that it should not speculatively keep an inactive DSO
 Session open for very long without reason, but when it does have an
 active reason to keep a DSO Session open, it doesn't need to be
 sending an aggressive level of DSO keepalive traffic to maintain that
 session.  An example of this would be a client that has subscribed to
 DNS Push notifications.  In this case, the client is not sending any
 traffic to the server, but the session is not inactive because there
 is an active request to the server to receive push notifications.
 A longer inactivity timeout with a shorter keepalive interval signals
 to the client that it may speculatively keep an inactive DSO Session
 open for a long time, but to maintain that inactive DSO Session it
 should be sending a lot of DSO keepalive traffic.  This configuration
 is expected to be less common.
 In the usual case where the inactivity timeout is shorter than the
 keepalive interval, it is only when a client has a long-lived, low-
 traffic operation that the keepalive interval comes into play in
 order to ensure that a sufficient residual amount of traffic is
 generated to maintain NAT and firewall state, and to assure the
 client and server that they still have connectivity to each other.
 On a new DSO Session, if no explicit DSO Keepalive message exchange
 has taken place, the default value for both timeouts is 15 seconds.
 For both timeouts, lower values of the timeout result in higher
 network traffic and a higher CPU load on the server.

Bellis, et al. Standards Track [Page 30] RFC 8490 DNS Stateful Operations March 2019

6.3. Inactive DSO Sessions

 At both servers and clients, the generation or reception of any
 complete DNS message (including DNS requests, responses, updates, DSO
 messages, etc.) resets both timers for that DSO Session, with the one
 exception being that a DSO Keepalive message resets only the
 keepalive timer, not the inactivity timeout timer.
 In addition, for as long as the client has an outstanding operation
 in progress, the inactivity timer remains cleared and an inactivity
 timeout cannot occur.
 For short-lived DNS operations like traditional queries and updates,
 an operation is considered "in progress" for the time between request
 and response, typically a period of a few hundred milliseconds at
 most.  At the client, the inactivity timer is cleared upon
 transmission of a request and remains cleared until reception of the
 corresponding response.  At the server, the inactivity timer is
 cleared upon reception of a request and remains cleared until
 transmission of the corresponding response.
 For long-lived DNS Stateful Operations (such as a Push Notification
 subscription [Push] or a Discovery Relay interface subscription
 [Relay]), an operation is considered "in progress" for as long as the
 operation is active, i.e., until it is canceled.  This means that a
 DSO Session can exist with active operations, with no messages
 flowing in either direction, for far longer than the inactivity
 timeout.  This is not an error.  This is why there are two separate
 timers: the inactivity timeout and the keepalive interval.  Just
 because a DSO Session has no traffic for an extended period of time,
 it does not automatically make that DSO Session "inactive", if it has
 an active operation that is awaiting events.

Bellis, et al. Standards Track [Page 31] RFC 8490 DNS Stateful Operations March 2019

6.4. The Inactivity Timeout

 The purpose of the inactivity timeout is for the server to balance
 the trade-off between the costs of setting up new DSO Sessions and
 the costs of maintaining inactive DSO Sessions.  A server with
 abundant DSO Session capacity can offer a high inactivity timeout to
 permit clients to keep a speculative DSO Session open for a long time
 and to save the cost of establishing a new DSO Session for future
 communications with that server.  A server with scarce memory
 resources can offer a low inactivity timeout to cause clients to
 promptly close DSO Sessions whenever they have no outstanding
 operations with that server and then create a new DSO Session later
 when needed.

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 is not required to
 keep an idle connection open until the inactivity timeout is reached.
 A client MAY close a DSO Session at any time, at the client's
 discretion.  If a client determines that it has no current or
 reasonably anticipated future need for a currently inactive DSO
 Session, then the client SHOULD gracefully close that connection.
 If, at any time during the life of the DSO Session, the inactivity
 timeout value (i.e., 15 seconds by default) elapses without there
 being any operation active on the DSO Session, the client MUST close
 the connection gracefully.
 If, at any time during the life of the DSO Session, too much time
 elapses without there being any operation active on the DSO Session,
 then the server MUST consider the client delinquent and MUST forcibly
 abort the DSO Session.  What is considered "too much time" in this
 context is five seconds or twice the current inactivity timeout
 value, whichever is greater.  If the inactivity timeout has its
 default value of 15 seconds, this means that a client will be
 considered delinquent and disconnected if it has not closed its
 connection after 30 seconds of inactivity.
 In 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, but not a DSO Keepalive message
 exchange itself.  A DSO Keepalive message exchange resets only the
 keepalive interval timer, not the inactivity timeout timer.
 If the client wishes to keep an inactive DSO Session open for longer
 than the default duration, then it uses the DSO Keepalive message to
 request longer timeout values as described in Section 7.1.

Bellis, et al. Standards Track [Page 32] RFC 8490 DNS Stateful Operations March 2019

6.4.2. Values for the Inactivity Timeout

 For the inactivity timeout value, lower values result in more
 frequent DSO Session teardowns and re-establishments.  Higher values
 result in lower traffic and a lower CPU load on the server, but a
 higher memory burden to maintain state for inactive DSO Sessions.
 A server may dictate any value it chooses for the inactivity timeout
 (either in a response to a client-initiated request or in a server-
 initiated message) including values under one second, or even zero.
 An inactivity timeout of zero informs the client that it should not
 speculatively maintain idle connections at all, and as soon as the
 client has completed the operation or operations relating to this
 server, the client should immediately begin closing this session.
 A server will forcibly abort an idle client session after five
 seconds or twice the inactivity timeout value, whichever is greater.
 In the case of a zero inactivity timeout value, this means that if a
 client fails to close an idle client session, then the server will
 forcibly abort the idle session after five seconds.
 An inactivity timeout of 0xFFFFFFFF represents "infinity" and informs
 the client that it may keep an idle connection open as long as it
 wishes.  Note that after granting an unlimited inactivity timeout in
 this way, at any point the server may revise that inactivity timeout
 by sending a new DSO Keepalive message dictating new Session Timeout
 values to the client.
 The largest *finite* inactivity timeout supported by the current
 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7
 days).

Bellis, et al. Standards Track [Page 33] RFC 8490 DNS Stateful Operations March 2019

6.5. The Keepalive Interval

 The purpose of the keepalive interval is to manage the generation of
 sufficient messages to maintain state in middleboxes (such at NAT
 gateways or firewalls) and for the client and server to periodically
 verify that they still have connectivity to each other.  This allows
 them to clean up state when connectivity is lost and to establish a
 new session if appropriate.

6.5.1. Keepalive Interval Expiry

 If, at any time during the life of the DSO Session, the keepalive
 interval value (i.e., 15 seconds by default) elapses without any DNS
 messages being sent or received on a 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.
 If a client disconnects from the network abruptly, without cleanly
 closing its DSO Session, perhaps leaving a long-lived operation
 uncanceled, the server learns of this after failing to receive the
 required DSO keepalive traffic from that client.  If, at any time
 during the life of the DSO Session, twice the keepalive interval
 value (i.e., 30 seconds by default) elapses without any DNS messages
 being sent or received on a DSO Session, the server SHOULD consider
 the client delinquent and SHOULD forcibly abort the DSO Session.

6.5.2. Values for the Keepalive Interval

 For the keepalive interval value, lower values result in a higher
 volume of DSO keepalive traffic.  Higher values of the keepalive
 interval reduce traffic and the CPU load, but have minimal effect on
 the memory burden at the server because clients keep a DSO Session
 open for the same length of time (determined by the inactivity
 timeout) regardless of the level of DSO keepalive traffic required.
 It may be appropriate for clients and servers to select different
 keepalive intervals depending on the type of network they are on.
 A corporate DNS server that knows it is serving only clients on the
 internal network, with no intervening NAT gateways or firewalls, can
 impose a longer keepalive interval because frequent DSO keepalive
 traffic is not required.
 A public DNS server that is serving primarily residential consumer
 clients, where it is likely there will be a NAT gateway on the path,
 may impose a shorter keepalive interval to generate more frequent DSO
 keepalive traffic.

Bellis, et al. Standards Track [Page 34] RFC 8490 DNS Stateful Operations March 2019

 A smart client may be adaptive to its environment.  A client using a
 private IPv4 address [RFC1918] to communicate with a DNS server at an
 address outside that IPv4 private address block may conclude that
 there is likely to be a NAT gateway on the path, and accordingly
 request a shorter keepalive interval.
 By default, it is RECOMMENDED that clients request, and servers
 grant, a keepalive interval of 60 minutes.  This keepalive interval
 provides for reasonably timely detection if a client abruptly
 disconnects without cleanly closing the session.  Also, it is
 sufficient to maintain state in firewalls and NAT gateways that
 follow the IETF recommended Best Current Practice that the
 "established connection idle-timeout" used by middleboxes be at least
 2 hours and 4 minutes [RFC5382] [RFC7857].
 Note that the shorter the keepalive interval value, the higher the
 load on client and server.  Moreover, for a keepalive value that is
 shorter than the time needed for the transport to retransmit, the
 loss of a single packet would cause a server to overzealously abort
 the connection.  For example, a (hypothetical and unrealistic)
 keepalive interval value of 100 ms would result in a continuous
 stream of ten messages per second or more (if allowed by the current
 congestion control window) in both directions to keep the DSO Session
 alive.  And, in this extreme example, a single retransmission over a
 path with, as an example, 100 ms RTT would introduce a momentary
 pause in the stream of messages long enough to cause 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.  If a client receives a DSO Keepalive message
 specifying a keepalive interval value less than ten seconds, this is
 a fatal error and the client MUST forcibly abort the connection
 immediately.
 A keepalive interval value of 0xFFFFFFFF represents "infinity" and
 informs the client that it should generate no DSO keepalive traffic.
 Note that after signaling that the client should generate no DSO
 keepalive traffic in this way, the server may at any point revise
 that DSO keepalive traffic 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).

Bellis, et al. Standards Track [Page 35] RFC 8490 DNS Stateful Operations March 2019

6.6. Server-Initiated DSO Session Termination

 In addition to canceling individual long-lived operations selectively
 (Section 5.6), there are also occasions where a server may need to
 terminate one or more entire DSO sessions.  An entire DSO session may
 need to be terminated if the client is defective in some way or
 departs from the network without closing its DSO session.  DSO
 Sessions may also need to be terminated if the server becomes
 overloaded or is reconfigured and lacks the ability to be selective
 about which operations need to be canceled.
 This section discusses 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 makes the determination of when to close
 a DSO Session based on an evaluation of both its own needs and the
 inactivity timeout value dictated by the server.  A server only
 causes a DSO Session to be ended in the exceptional circumstances
 outlined below.  Some of the exceptional situations in which a server
 may terminate a DSO Session include:
 o  The server application software or underlying operating system is
    shutting down or restarting.
 o  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).
 o  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
    is implemented such that it reads a configuration file at startup,
    and changing the server's configuration entails modifying the
    configuration file and then killing and restarting the server
    software, which generally entails a loss of network connections.
 o  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).
 o  The client sends a grossly invalid or malformed request that is
    indicative of a seriously defective client implementation.
 o  The server is over capacity and needs to shed some load.

Bellis, et al. Standards Track [Page 36] RFC 8490 DNS Stateful Operations March 2019

6.6.1. Server-Initiated Retry Delay Message

 In the cases described above where a server elects to terminate a DSO
 Session, it could do so simply by forcibly aborting the connection.
 However, if it did this, the likely behavior of the client might be
 simply to treat this as a network failure and reconnect immediately,
 putting more burden on the server.
 Therefore, 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 in situations where many retry
 delays are sent in quick succession so as to avoid all the clients
 attempting 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 has
 not closed the connection after five seconds, then 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, this is 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 from the server
 arrives at the client, the client will determine that any DNS
 requests it previously sent on this DSO Session that have not yet
 received a response will now certainly not be receiving any response.

Bellis, et al. Standards Track [Page 37] RFC 8490 DNS Stateful Operations March 2019

 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, indicating that the clients SHOULD immediately attempt to
 re-establish operations.
 It is likely that some of the attempts will be successful and some
 will not, 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 the server
 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

 After a DSO Session is ended by the server (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 service instance if
 more than one is available.  If reconnecting to the same service
 instance, the client MUST respect the indicated delay, if available,
 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 this behavior is desired.

Bellis, et al. Standards Track [Page 38] RFC 8490 DNS Stateful Operations March 2019

 If a particular service instance will only be out of service for a
 short maintenance period, it should indicate a retry delay value that
 is a little longer than the expected maintenance window.  It should
 not default to a very large delay value, or clients may not attempt
 to reconnect promptly after it resumes service.
 If a service instance does not want a client to reconnect ever
 (perhaps the service instance is being decommissioned), it SHOULD set
 the retry delay to the maximum value 0xFFFFFFFF (2^32-1 milliseconds,
 approximately 49.7 days).  It is not possible to instruct a client to
 stay away for longer than 49.7 days.  If, after 49.7 days, the DNS or
 other configuration information still indicates that this is the
 valid service instance for a particular service, then clients MAY
 attempt to reconnect.  In reality, if a client is rebooted or
 otherwise loses state, it may well attempt to reconnect before 49.7
 days elapse, for as long as the DNS or other configuration
 information continues to indicate that this is the service instance
 the client should use.

6.6.3.1. Reconnecting after a Forcible Abort

 If a connection was forcibly aborted by the client due to
 noncompliant behavior by the server, the client SHOULD mark that
 service instance as not supporting DSO.  The client MAY reconnect but
 not attempt to use DSO, or it may connect to a different service
 instance if applicable.

6.6.3.2. Reconnecting after an Unexplained Connection Drop

 It is also possible for a server to forcibly terminate the
 connection; in this case, the client doesn't know whether the
 termination was the result of a protocol error or a network outage.
 When the client notices that the connection has been dropped, it can
 attempt to reconnect immediately.  However, if the connection is
 dropped again without the client being able to successfully do
 whatever it is trying to do, it should mark the server as not
 supporting DSO.

6.6.3.3. Probing for Working DSO Support

 Once a server has been marked by the client 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,
 it's not likely that the problem will be solved in the first hour
 after it's first encountered.  However, by restricting the retry
 interval to an hour, the client will be able to notice when the
 problem has been fixed without placing an undue burden on the server.

Bellis, et al. Standards Track [Page 39] RFC 8490 DNS Stateful Operations March 2019

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) performs two functions.  Primarily, it
 establishes the values for the Session Timeouts.  Incidentally, it
 also resets the keepalive timer for the DSO Session, meaning that it
 can be used as a kind of "no-op" message for the purpose of keeping a
 session alive.  The client will request the desired Session Timeout
 values and the server will acknowledge with the response values that
 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:  The inactivity timeout for the current DSO
    Session, specified as a 32-bit unsigned integer, in network (big
    endian) byte order in units of milliseconds.  This is the timeout
    at which the client MUST begin closing an inactive DSO Session.
    The inactivity timeout can be any value of the server's choosing.
    If the client does not 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:  The keepalive interval for the current DSO
    Session, specified as a 32-bit unsigned integer, in network (big
    endian) byte order in units of milliseconds.  This is the interval
    at which a client MUST generate DSO keepalive traffic to maintain
    connection state.  The keepalive interval MUST NOT be less than
    ten seconds.  If the client does not 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 minimum time at which a
    server will forcibly disconnect a client for failing to generate
    the mandated DSO keepalive traffic is twenty seconds.

Bellis, et al. Standards Track [Page 40] RFC 8490 DNS Stateful Operations March 2019

 The transmission or reception of DSO Keepalive messages (i.e.,
 messages where the Keepalive TLV is the first TLV) reset only the
 keepalive timer, not the inactivity timer.  The reason for this is
 that periodic DSO Keepalive messages are sent for the sole purpose of
 keeping a DSO Session alive when that DSO Session has current or
 recent non-maintenance activity that warrants keeping that DSO
 Session alive.  Sending DSO keepalive traffic itself is not
 considered a client activity; it is considered a maintenance activity
 that is performed in service of other client activities.  If DSO
 keepalive traffic itself were to reset the inactivity timer, then
 that would create a circular livelock where keepalive traffic would
 be sent indefinitely to keep a DSO Session alive.  In this scenario,
 the only activity on that DSO Session would be the keepalive traffic
 keeping the DSO Session alive so that further keepalive traffic can
 be sent.  For a DSO Session to be considered active, it must be
 carrying something more than just keepalive traffic.  This is why
 merely sending or receiving a DSO Keepalive message does not reset
 the inactivity timer.
 When sent by a client, the DSO Keepalive request message 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, then this is
 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, communicates to the
 server the client's requested Session Timeout values.  In a server
 response to a client-initiated DSO Keepalive request message, the
 Session Timeouts contain the server's chosen values from this point
 forward in the DSO Session, which the client MUST respect.  This is
 modeled after the DHCP protocol, where the client requests a certain
 lease lifetime using DHCP option 51 [RFC2132], but the server is the
 ultimate authority for deciding what lease lifetime is actually
 granted.
 When a client is sending its second and subsequent DSO Keepalive
 request messages to the server, the client SHOULD continue to request
 its preferred values each time.  This allows flexibility so that if
 conditions change during the lifetime of a DSO Session, the server
 can adapt its responses to better fit the client's needs.
 Once a DSO Session is in progress (Section 5.1), a DSO Keepalive
 message MAY be initiated by a server.  When sent by a server, the DSO
 Keepalive message 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, then this is
 a fatal error and the client MUST forcibly abort the connection
 immediately.  The DSO Keepalive unidirectional message from the

Bellis, et al. Standards Track [Page 41] RFC 8490 DNS Stateful Operations March 2019

 server resets a DSO Session's keepalive timer and, at the same time,
 unilaterally informs the client of the new Session Timeout values to
 use from this 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 is used only 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 wishes to update a client's
 Session Timeout values other than in response to a DSO Keepalive
 request message from the client, then it does so by sending a DSO
 Keepalive unidirectional message of its own, as described above.
 It is not required that the Keepalive TLV be used in every DSO
 Session.  While many DSO operations will be used in conjunction with
 a long-lived session state, not all DSO operations require a long-
 lived session state, 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

 When a client receives a response to its client-initiated DSO
 Keepalive request message, or receives a server-initiated DSO
 Keepalive unidirectional message, the client has then received
 Session Timeout values dictated by the server.  The two timeout
 values contained in the Keepalive TLV from the server may each be
 higher, lower, or the same as the respective Session Timeout values
 the client previously had for this DSO Session.
 In the case of the keepalive timer, the handling of the received
 value is straightforward.  The act of receiving the message
 containing the DSO Keepalive TLV itself resets the keepalive timer
 and updates the keepalive interval for the DSO Session.  The new
 keepalive interval indicates the maximum time that may elapse before
 another message must be sent or received on this DSO Session, if the
 DSO Session is to remain alive.
 In the case of the inactivity timeout, the handling of the received
 value is a little more subtle, though the meaning of the inactivity
 timeout remains as specified; it still indicates the maximum
 permissible time allowed without useful activity on a DSO Session.
 The act of receiving the message containing the Keepalive TLV does
 not itself reset the inactivity timer.  The time elapsed since the
 last useful activity on this DSO Session is unaffected by exchange of

Bellis, et al. Standards Track [Page 42] RFC 8490 DNS Stateful Operations March 2019

 DSO Keepalive messages.  The new inactivity timeout value in the
 Keepalive TLV in the received message does update the timeout
 associated with the running inactivity timer; that becomes the new
 maximum permissible time without activity on a DSO Session.
 o  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.
 o  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 now the client MUST
    immediately begin closing this DSO Session.
 o  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.
 o  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, this is a fatal error
 and the receiver of the edns-tcp-keepalive EDNS(0) Option MUST
 forcibly abort the connection immediately.

Bellis, et al. Standards Track [Page 43] RFC 8490 DNS Stateful Operations March 2019

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 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     RETRY DELAY (32 bits)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 RETRY DELAY:  A time value, specified as a 32-bit unsigned integer in
    network (big endian) byte order, in units of milliseconds, within
    which 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 used as the Primary TLV in a DSO unidirectional message, the
 Retry Delay TLV is sent from server to client.  It is used by a
 server to instruct 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, and 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:
 o  NOERROR indicates a routine shutdown or restart.
 o  FORMERR indicates that a client DSO request was too badly
    malformed for the session to continue.
 o  SERVFAIL indicates that the server is overloaded due to resource
    exhaustion and needs to shed load.
 o  REFUSED indicates 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.

Bellis, et al. Standards Track [Page 44] RFC 8490 DNS Stateful Operations March 2019

 o  NOTAUTH indicates 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.
 In some cases, 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.  Possibly, 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 such cases,
 the server MAY use any of the applicable RCODE values, or
 RCODE=NOERROR (routine shutdown or restart).
 Note that the selection of RCODE value in a DSO Retry Delay message
 is not critical since the RCODE value is generally used only for
 information purposes such as writing to a log file for future human
 analysis regarding the nature of the disconnection.  Generally,
 clients do not modify their behavior depending on the RCODE value.
 The RETRY DELAY in the message tells the client how long it should
 wait before attempting a new connection to this service instance.
 For clients that do in some way modify their behavior depending on
 the RCODE value, they should treat unknown RCODE values the same as
 RCODE=NOERROR (routine shutdown or restart).
 A DSO Retry Delay message (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, this is a fatal error and the server MUST forcibly abort
 the connection immediately.

Bellis, et al. Standards Track [Page 45] RFC 8490 DNS Stateful Operations March 2019

7.2.2. Retry Delay TLV Used as a Response Additional TLV

 In the case of a DSO request message that results in a nonzero RCODE
 value, the responder MAY append a Retry Delay TLV to the response,
 indicating the time interval during which the initiator 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.
 Either a client or a server, whichever is acting in the role of 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 is 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
 and is a function of current best practices with respect to the type
 and length of data in the preceding TLVs [RFC8467].

Bellis, et al. Standards Track [Page 46] RFC 8490 DNS Stateful Operations March 2019

8. Summary Highlights

 This section summarizes some noteworthy highlights about various
 aspects of the DSO protocol.

8.1. QR Bit and MESSAGE ID

 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.
 The table below illustrates which combinations are legal and how they
 are interpreted:
             +------------------------------+------------------------+
             |       MESSAGE ID zero        |   MESSAGE ID nonzero   |
    +--------+------------------------------+------------------------+
    |  QR=0  |  DSO unidirectional message  |  DSO request message   |
    +--------+------------------------------+------------------------+
    |  QR=1  |    Invalid - Fatal Error     |  DSO response message  |
    +--------+------------------------------+------------------------+

Bellis, et al. Standards Track [Page 47] RFC 8490 DNS Stateful Operations March 2019

8.2. TLV Usage

 The table below indicates, for each of the three TLVs defined in this
 document, whether they are valid in each of ten different contexts.
 The first five contexts are DSO requests or DSO unidirectional
 messages from client to server, and the corresponding responses from
 server back 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 their counterparts in the opposite
 direction: DSO requests or DSO unidirectional messages from server to
 client, and the corresponding 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.

Bellis, et al. Standards Track [Page 48] RFC 8490 DNS Stateful Operations March 2019

 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.
              +-------------------------+-------------------------+
              | 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  |
 +------------+-------------------------+-------------------------+
 Note that some of the columns in this table are currently empty.  The
 table provides 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.

Bellis, et al. Standards Track [Page 49] RFC 8490 DNS Stateful Operations March 2019

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 the software an instance is that regardless of
 which of these tuples the client uses to connect to it, the client is
 connected to the same software, running on the same logical node (see
 Section 9.2), and will receive the same answers and the same keying
 information.
 Service instances are identified from the perspective of the client.
 If the client is configured with { IP address, port } tuples, it has
 no way to tell if the service offered at one tuple is the same server
 that is listening on a different tuple.  So in this case, the client
 treats each different tuple as if it references a different service
 instance.
 In some cases, a client is configured with a hostname and a port
 number.  The port number may be given explicitly, along with the
 hostname.  The port number may be omitted, and assumed to have some
 default value.  The hostname and a port number may be learned from
 the network, as in the case of 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 is possible that two hostnames might point to some common IP
 addresses; this is a configuration anomaly that the client is not
 obliged to detect.  The effect of this could be that after being told
 to disconnect, the client might reconnect to the same server because
 it is represented as a different service instance.
 Implementations SHOULD NOT resolve hostnames and then perform the
 process of matching IP address(es) in order to evaluate whether two
 entities should be determined to be the "same service instance".

Bellis, et al. Standards Track [Page 50] RFC 8490 DNS Stateful Operations March 2019

9.2. Anycast Considerations

 When an anycast service is configured on a particular IP address and
 port, it must be the case that although there is more than one
 physical server responding on that IP address, each such server can
 be treated as equivalent.  What we mean by "equivalent" here is that
 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 causes packets in a particular TCP
 connection to be sent to an anycast server instance that does not
 know about the connection, the new server will automatically
 terminate the connection with a TCP reset, since it will have no
 record of the connection, and then the client can reconnect or stop
 using the connection as appropriate.
 If, after the connection is re-established, the client's assumption
 that it is connected to the same instance is violated in some way,
 that would be considered an incorrect behavior in this context.  It
 is, however, out of the possible scope for this specification to make
 specific recommendations in this regard; that would be up to follow-
 on documents that describe specific uses of DNS Stateful Operations.

Bellis, et al. Standards Track [Page 51] RFC 8490 DNS Stateful Operations March 2019

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.

Bellis, et al. Standards Track [Page 52] RFC 8490 DNS Stateful Operations March 2019

9.4. Operational Considerations for Middleboxes

 Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
 or session multiplexer) is in the path, care must be taken to avoid a
 configuration in which DSO traffic is mishandled.  The simplest way
 to avoid such problems is to avoid using middleboxes.  When this is
 not possible, middleboxes should be evaluated to make sure that they
 behave correctly.
 Correct behavior for middleboxes consists of one of the following:
 o  The middlebox does not forward DSO messages and responds to DSO
    messages with a response code other than NOERROR or DSOTYPENI.
 o  The middlebox acts as a DSO server and follows this specification
    in establishing connections.
 o  There is a 1:1 correspondence between incoming and outgoing
    connections such that when a connection is established to the
    middlebox, it is guaranteed that exactly one corresponding
    connection will be established from the middlebox to some DNS
    resolver, and all incoming messages will be forwarded without
    modification or reordering.  An example of this would be a NAT
    forwarder or TCP connection optimizer (e.g., for a high-latency
    connection such as a geosynchronous satellite link).
 Middleboxes that do not meet one of the above criteria are very
 likely to fail in unexpected and difficult-to-diagnose ways.  For
 example, a DNS load balancer might unbundle DNS messages from the
 incoming TCP stream and forward each message from the stream to a
 different DNS server.  If such a load balancer is in use, and the DNS
 servers it points to implement DSO and are configured to enable DSO,
 DSO Session establishment will succeed, but no coherent session will
 exist between the client and the server.  If such a load balancer is
 pointed at a DNS server that does not implement DSO or is configured
 not to allow DSO, no such problem will exist, but such a
 configuration risks unexpected failure if new server software is
 installed that does implement DSO.
 It is of course possible to implement a middlebox that properly
 supports DSO.  It is even possible to implement one that implements
 DSO with long-lived operations.  This can be done either by
 maintaining a 1:1 correspondence between incoming and outgoing
 connections, as mentioned above, or by terminating incoming sessions
 at the middlebox but maintaining state in the middlebox about any
 long-lived operations that are requested.  Specifying this in detail
 is beyond the scope of this document.

Bellis, et al. Standards Track [Page 53] RFC 8490 DNS Stateful Operations March 2019

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 very wasteful on the network.  For
 illustration, consider a simple example like remote login using a
 very simple TCP implementation that lacks delayed acks.  When the
 user types a keystroke, a data packet is sent.  When the data packet
 arrives at the server, the simple TCP implementation sends an
 immediate acknowledgement.  Mere milliseconds later, the server
 process reads the one byte of keystroke data, and consequently the
 simple TCP implementation sends an immediate window update.  Mere
 milliseconds later, the server process generates the character echo
 and sends this data back in reply.  The simple TCP implementation
 then sends this data packet immediately too.  In this case, this
 simple TCP implementation sends a burst of three packets almost
 instantaneously (ack, window update, data).
 Clearly it would be more efficient if the TCP implementation were to
 combine the three separate packets into one, and this is what the
 delayed ack feature enables.
 With delayed ack, the TCP implementation waits after receiving a data
 packet, typically for 200 ms, and then sends its ack if (a) more data
 packet(s) arrive, (b) the receiving process generates some reply
 data, or (c) 200 ms elapse without either of the above occurring.
 With delayed ack, remote login becomes much more efficient,
 generating just one packet instead of three for each character echo.
 The logic of delayed ack is that the 200 ms delay cannot do any
 significant harm.  If something at the other end were waiting for
 something, then the receiving process should generate the reply that
 the thing at 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 does not in fact generate any
 reply for this particular message, then by definition the thing at
 the other end cannot be waiting for anything.  Therefore, the 200 ms
 delay is harmless.
 This assumption may be true unless the sender is using Nagle's
 algorithm, a similar efficiency feature, created to protect the
 network from poorly written client software that performs many rapid
 small writes in succession.  Nagle's algorithm allows these small
 writes to be coalesced into larger, less wasteful packets.

Bellis, et al. Standards Track [Page 54] RFC 8490 DNS Stateful Operations March 2019

 Unfortunately, Nagle's algorithm and delayed ack, two valuable
 efficiency features, can interact badly with each other when 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 do not elicit responses, the delayed ack
 mechanism causes the ack to be delayed by 200 ms.  The 200 ms delay
 on the ack can in turn cause Nagle's algorithm to prevent 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, a 200 ms delay is enormous in
 comparison.
 When this issues is raised, there are two solutions that are often
 offered, neither of them ideal:
 1.  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 grant 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, and the responder will now send two or three
     packets instead of one.
 2.  Disable Nagle's algorithm.  When acks are delayed by the delayed
     ack algorithm, removing Nagle's algorithm prevents the sender
     from being blocked from sending its next small packet
     immediately.  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,
     with the goal of limiting the number of small packets in flight
     at any one time.
 The problem here is that with DSO messages that elicit no response,
 the TCP implementation is stuck waiting, unsure if a response is
 about to be generated or whether the TCP implementation should go
 ahead and send an ack and window update.
 The solution is networking APIs that allow the receiver to inform the
 TCP implementation that a received message has been read, processed,
 and no response for this message will be generated.  TCP can then

Bellis, et al. Standards Track [Page 55] RFC 8490 DNS Stateful Operations March 2019

 stop waiting for a response that will never come, and immediately go
 ahead and 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.
 At the time that this document is being prepared for publication, it
 is known that at least one TCP implementation provides the ability
 for the recipient of a TCP message to signal that it is not going to
 send a response, and hence the delayed ack mechanism can stop
 waiting.  Implementations on operating systems where this feature is
 available SHOULD make use of it.

Bellis, et al. Standards Track [Page 56] RFC 8490 DNS Stateful Operations March 2019

10. IANA Considerations

10.1. DSO OPCODE Registration

 The 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") indicates that the receiver does implement DNS Stateful
 Operations, but does not implement the specific DSO-TYPE of the
 Primary TLV in the DSO request message.

10.3. DSO Type Code Registry

 The IANA has created the 16-bit "DSO Type Codes" registry, with
 initial (hexadecimal) values as shown below:
 +-----------+-----------------------+-------+-----------+-----------+
 | 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             |       |           |           |
 +-----------+-----------------------+-------+-----------+-----------+

Bellis, et al. Standards Track [Page 57] RFC 8490 DNS Stateful Operations March 2019

 The meanings of the fields are as follows:
 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.
 Registrations of new DSO Type Codes in the "Reserved for DSO session-
 management" range 0004-003F and the "Reserved for future expansion"
 range FC00-FFFF require publication of an IETF Standards Action
 document [RFC8126].
 Requests to register additional new DSO Type Codes in the
 "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert
 Review [RFC8126].  The expert review should validate that the
 requested type code is specified in a way that conforms to this
 specification, and that the intended use for the code would not be
 addressed with an experimental/local assignment.
 DSO Type Codes in the "experimental/local" range F800-FBFF may be
 used as Experimental Use or Private Use values [RFC8126] and may be
 used freely for development purposes or for other purposes within a
 single site.  No attempt is made to prevent multiple sites from using
 the same value in different (and incompatible) ways.  There is no
 need for IANA to review such assignments (since IANA does not record
 them) and assignments are not generally useful for broad
 interoperability.  It is the responsibility of the sites making use
 of "experimental/local" values to ensure that no conflicts occur
 within the intended scope of use.
 Any document defining a new TLV that lists a value of "OK" in the
 Early Data column must include a threat analysis for the use of the
 TLV in the case of TLS zero round-trip.  See Section 11.1 for
 details.

Bellis, et al. Standards Track [Page 58] RFC 8490 DNS Stateful Operations March 2019

11. Security Considerations

 If this mechanism is to be used with DNS-over-TLS, then these
 messages are subject to the same constraints as any other DNS-over-
 TLS messages and 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, the potential for data in the TLV to be
 used as a tracking identifier should be taken into consideration and
 should be avoided when not required.
 When 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, specifying an unreasonably
 large RETRY DELAY, causing a denial-of-service attack against the
 client.
 The establishment of DSO Sessions has an impact on the number of open
 TCP connections on a DNS server.  Additional resources may be used on
 the server as a result.  However, because the server can limit the
 number of DSO Sessions established and can also close existing DSO
 Sessions as needed, denial of service or resource exhaustion should
 not be a concern.

11.1. TLS Zero Round-Trip Considerations

 DSO permits zero round-trip operation using TCP Fast Open with
 TLS 1.3 [RFC8446] early data to reduce or eliminate round trips in
 session establishment.  TCP Fast Open is only permitted in
 combination with TLS 1.3 early data.  In the rest of this section, we
 refer to TLS 1.3 early data in a TLS zero round-trip initial
 handshake message, regardless of whether or not it is included in a
 TCP SYN packet with early data using the TCP Fast Open option, as
 "early data."
 A DSO message may or may not be permitted to be sent as early data.
 The definition for 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).

Bellis, et al. Standards Track [Page 59] RFC 8490 DNS Stateful Operations March 2019

 For DSO messages that are permitted as early data, a client MAY
 include one or more such messages as early data without having to
 wait for a DSO response to the first DSO request message to confirm
 successful establishment of a DSO Session.
 However, unless there is an implicit DSO session, a client MUST NOT
 send DSO unidirectional messages until after a DSO Session has been
 mutually established.
 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 ensure that DSO messages sent as early data
 are idempotent or are otherwise immune to any problems that could
 result from the inadvertent replay that can occur with zero round-
 trip operation.
 It would be possible to add a TLV that requires the server to do some
 significant work and send that 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 done based on the advice given 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>.

Bellis, et al. Standards Track [Page 60] RFC 8490 DNS Stateful Operations March 2019

 [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

 [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.

Bellis, et al. Standards Track [Page 61] RFC 8490 DNS Stateful Operations March 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>.

Bellis, et al. Standards Track [Page 62] RFC 8490 DNS Stateful Operations March 2019

 [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

 Thanks to 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 for their
 helpful contributions to this document.

Authors' Addresses

 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.org
 Stuart Cheshire
 Apple Inc.
 One Apple Park Way
 Cupertino, CA  95014
 United States of America
 Phone: +1 (408) 996-1010
 Email: cheshire@apple.com

Bellis, et al. Standards Track [Page 63] RFC 8490 DNS Stateful Operations March 2019

 John Dickinson
 Sinodun Internet Technologies
 Magadalen Centre
 Oxford Science Park
 Oxford  OX4 4GA
 United Kingdom
 Email: jad@sinodun.com
 Sara Dickinson
 Sinodun Internet Technologies
 Magadalen Centre
 Oxford Science Park
 Oxford  OX4 4GA
 United Kingdom
 Email: sara@sinodun.com
 Ted Lemon
 Nibbhaya Consulting
 P.O. Box 958
 Brattleboro, VT  05302-0958
 United States of America
 Email: mellon@fugue.com
 Tom Pusateri
 Unaffiliated
 Raleigh, NC  27608
 United States of America
 Phone: +1 (919) 867-1330
 Email: pusateri@bangj.com

Bellis, et al. Standards Track [Page 64]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8490.txt · Last modified: 2019/03/15 22:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki