Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8490

DNS Stateful Operations

Pages: 64
Proposed Standard
Updates:  10357766
Part 1 of 4 – Pages 1 to 10
None   None   Next

Top   ToC   RFC8490 - Page 1
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.
Top   ToC   RFC8490 - Page 2
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
Top   ToC   RFC8490 - Page 3
     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
Top   ToC   RFC8490 - Page 4

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

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

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

4.2. Applicable Transports

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


(next page on part 2)

Next Section