Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8490

DNS Stateful Operations

Pages: 64
Proposed Standard
Updates:  10357766
Part 2 of 4 – Pages 11 to 28
First   Prev   Next

Top   ToC   RFC8490 - Page 11   prevText

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).
Top   ToC   RFC8490 - Page 12
   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
Top   ToC   RFC8490 - Page 13
   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.
Top   ToC   RFC8490 - Page 14
   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
Top   ToC   RFC8490 - Page 15
   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
Top   ToC   RFC8490 - Page 16
   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 / / / +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Top   ToC   RFC8490 - Page 17

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
Top   ToC   RFC8490 - Page 18
   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
Top   ToC   RFC8490 - Page 19
   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.
Top   ToC   RFC8490 - Page 20

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].
Top   ToC   RFC8490 - Page 21

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.
Top   ToC   RFC8490 - Page 22

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.
Top   ToC   RFC8490 - Page 23

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.
Top   ToC   RFC8490 - Page 24

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.
Top   ToC   RFC8490 - Page 25

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.
Top   ToC   RFC8490 - Page 26

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.
Top   ToC   RFC8490 - Page 27

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.
Top   ToC   RFC8490 - Page 28

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.


(next page on part 3)

Next Section