rfc8490v6.txt   rfc8490.txt 
skipping to change at page 2, line 17 skipping to change at page 2, line 22
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Session Management . . . . . . . . . . . . . . . . . 9 4.1.1. Session Management . . . . . . . . . . . . . . . . . 9
4.1.2. Long-Lived Subscriptions . . . . . . . . . . . . . . 9 4.1.2. Long-Lived Subscriptions . . . . . . . . . . . . . . 9
4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10 4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11
5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12 5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12
5.1.1. DSO Session Establishment Failure . . . . . . . . . . 13 5.1.1. DSO Session Establishment Failure . . . . . . . . . . 13
5.1.2. DSO Session Establishment Success . . . . . . . . . . 14 5.1.2. DSO Session Establishment Success . . . . . . . . . . 14
skipping to change at page 3, line 12 skipping to change at page 3, line 17
6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 34 6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 34
6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 34 6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 34
6.5.2. Values for the Keepalive Interval . . . . . . . . . . 34 6.5.2. Values for the Keepalive Interval . . . . . . . . . . 34
6.6. Server-Initiated DSO Session Termination . . . . . . . . 36 6.6. Server-Initiated DSO Session Termination . . . . . . . . 36
6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 37 6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 37
6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 38 6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 38
6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 38 6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 38
7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 40 7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 40
7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 40 7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 40
7.1.1. Client Handling of Received Session Timeout Values . 42 7.1.1. Client Handling of Received Session Timeout Values . 42
7.1.2. Relationship to edns-tcp-keepalive EDNS0 Option . . . 43 7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option . . 43
7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 44 7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Retry Delay TLV Used as a Primary 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.2.2. Retry Delay TLV Used as a Response Additional TLV . . 46
7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 47 7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 46
8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 47 8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 47
8.1. QR Bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 47 8.1. QR Bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 47
8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 49 8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Additional Considerations . . . . . . . . . . . . . . . . . . 51 9. Additional Considerations . . . . . . . . . . . . . . . . . . 50
9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 51 9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 50
9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 52 9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 51
9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 53 9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 52
9.4. Operational Considerations for Middleboxes . . . . . . . 54 9.4. Operational Considerations for Middleboxes . . . . . . . 53
9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 55 9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 58 10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 57
10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 58 10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 57
10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 58 10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 57
11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
11.1. TLS Zero Round-Trip Considerations . . . . . . . . . . . 60 11.1. TLS Zero Round-Trip Considerations . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 61 12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 62 12.2. Informative References . . . . . . . . . . . . . . . . . 61
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
This document specifies a mechanism for managing stateful DNS This document specifies a mechanism for managing stateful DNS
connections. DNS most commonly operates over a UDP transport, but it connections. DNS most commonly operates over a UDP transport, but it
can also operate over streaming transports; the original DNS RFC can also operate over streaming transports; the original DNS RFC
specifies DNS-over-TCP [RFC1035], and a profile for DNS-over-TLS specifies DNS-over-TCP [RFC1035], and a profile for DNS-over-TLS
[RFC7858] has been specified. These transports can offer persistent [RFC7858] has been specified. These transports can offer persistent
long-lived sessions and therefore, when using them for transporting long-lived sessions and therefore, when using them for transporting
DNS messages, it is of benefit to have a mechanism that can establish DNS messages, it is of benefit to have a mechanism that can establish
parameters associated with those sessions, such as timeouts. In such parameters associated with those sessions, such as timeouts. In such
situations, it is also advantageous to support server-initiated situations, it is also advantageous to support server-initiated
messages (such as DNS Push Notifications [Push]). messages (such as DNS Push Notifications [Push]).
The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is
explicitly defined to only have "per-message" semantics. While explicitly defined to only have "per-message" semantics. While
EDNS(0) has been used to signal at least one session-related EDNS(0) has been used to signal at least one session-related
parameter (edns-tcp-keepalive EDNS0 Option [RFC7828]), the result is parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), the result
less than optimal due to the restrictions imposed by the EDNS(0) is less than optimal due to the restrictions imposed by the EDNS(0)
semantics and the lack of server-initiated signaling. For example, a semantics and the lack of server-initiated signaling. For example, a
server cannot arbitrarily instruct a client to close a connection server cannot arbitrarily instruct a client to close a connection
because the server can only send EDNS(0) options in responses to because the server can only send EDNS(0) options in responses to
queries that contained EDNS(0) options. queries that contained EDNS(0) options.
This document defines a new DNS OPCODE for DNS Stateful Operations This document defines a new DNS OPCODE for DNS Stateful Operations
(DSO) with a value of 6. DSO messages are used to communicate (DSO) with a value of 6. DSO messages are used to communicate
operations within persistent stateful sessions, expressed using Type operations within persistent stateful sessions, expressed using Type
Length Value (TLV) syntax. This document defines an initial set of Length Value (TLV) syntax. This document defines an initial set of
three TLVs used to manage session timeouts, termination, and three TLVs used to manage session timeouts, termination, and
skipping to change at page 9, line 22 skipping to change at page 9, line 22
Several use cases for DNS Stateful Operations are described below. Several use cases for DNS Stateful Operations are described below.
4.1.1. Session Management 4.1.1. Session Management
In one use case, establishing session parameters such as server- In one use case, establishing session parameters such as server-
defined timeouts is of great use in the general management of defined timeouts is of great use in the general management of
persistent connections. For example, using DSO Sessions for stub-to- persistent connections. For example, using DSO Sessions for stub-to-
recursive DNS-over-TLS [RFC7858] is more flexible for both the client recursive DNS-over-TLS [RFC7858] is more flexible for both the client
and the server than attempting to manage sessions using just the and the server than attempting to manage sessions using just the
edns-tcp-keepalive EDNS0 Option [RFC7828]. The simple set of TLVs edns-tcp-keepalive EDNS(0) Option [RFC7828]. The simple set of TLVs
defined in this document is sufficient to greatly enhance connection defined in this document is sufficient to greatly enhance connection
management for this use case. management for this use case.
4.1.2. Long-Lived Subscriptions 4.1.2. Long-Lived Subscriptions
In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763] In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763]
has evolved into a naturally session-based mechanism where, for has evolved into a naturally session-based mechanism where, for
example, long-lived subscriptions lend themselves to 'push' example, long-lived subscriptions lend themselves to 'push'
mechanisms as opposed to polling. Long-lived stateful connections mechanisms as opposed to polling. Long-lived stateful connections
and server-initiated messages align with this use case [Push]. and server-initiated messages align with this use case [Push].
skipping to change at page 23, line 33 skipping to change at page 23, line 33
be defined to perform this function. be defined to perform this function.
Note, however, that while DSO *messages* cannot include EDNS(0) or Note, however, that while DSO *messages* cannot include EDNS(0) or
TSIG records, a DSO *session* is typically used to carry a whole TSIG records, a DSO *session* is typically used to carry a whole
series of DNS messages of different kinds, including DSO messages and series of DNS messages of different kinds, including DSO messages and
other DNS message types like Query [RFC1034] [RFC1035] and Update other DNS message types like Query [RFC1034] [RFC1035] and Update
[RFC2136]. These messages can carry EDNS(0) and TSIG records. [RFC2136]. These messages can carry EDNS(0) and TSIG records.
Although messages may contain other EDNS(0) options as appropriate, Although messages may contain other EDNS(0) options as appropriate,
this specification explicitly prohibits use of the edns-tcp-keepalive this specification explicitly prohibits use of the edns-tcp-keepalive
EDNS0 Option [RFC7828] in *any* messages sent on a DSO Session EDNS(0) Option [RFC7828] in *any* messages sent on a DSO Session
(because it is obsoleted by the functionality provided by the DSO (because it is obsoleted by the functionality provided by the DSO
Keepalive operation). If any message sent on a DSO Session contains Keepalive operation). If any message sent on a DSO Session contains
an edns-tcp-keepalive EDNS0 option, this is a fatal error and the an edns-tcp-keepalive EDNS(0) Option, this is a fatal error and the
recipient of the defective message MUST forcibly abort the connection recipient of the defective message MUST forcibly abort the connection
immediately. immediately.
5.5. Message Handling 5.5. Message Handling
As described in Section 5.4.1, whether an outgoing DSO message with 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 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 unidirectional message is determined by the specification for the
Primary TLV, which in turn determines whether the MESSAGE ID field in Primary TLV, which in turn determines whether the MESSAGE ID field in
that outgoing message will be zero or nonzero. that outgoing message will be zero or nonzero.
skipping to change at page 39, line 17 skipping to change at page 39, line 20
If a service instance does not want a client to reconnect ever If a service instance does not want a client to reconnect ever
(perhaps the service instance is being decommissioned), it SHOULD set (perhaps the service instance is being decommissioned), it SHOULD set
the retry delay to the maximum value 0xFFFFFFFF (2^32-1 milliseconds, 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 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 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 other configuration information still indicates that this is the
valid service instance for a particular service, then clients MAY valid service instance for a particular service, then clients MAY
attempt to reconnect. In reality, if a client is rebooted or attempt to reconnect. In reality, if a client is rebooted or
otherwise loses state, it may well attempt to reconnect before 49.7 otherwise loses state, it may well attempt to reconnect before 49.7
days elapse for as long as the DNS or other configuration information days elapse, for as long as the DNS or other configuration
continues to indicate that this is the service instance the client information continues to indicate that this is the service instance
should use. the client should use.
6.6.3.1. Reconnecting after a Forcible Abort 6.6.3.1. Reconnecting after a Forcible Abort
If a connection was forcibly aborted by the client due to If a connection was forcibly aborted by the client due to
noncompliant behavior by the server, the client SHOULD mark that noncompliant behavior by the server, the client SHOULD mark that
service instance as not supporting DSO. The client MAY reconnect but service instance as not supporting DSO. The client MAY reconnect but
not attempt to use DSO, or it may connect to a different service not attempt to use DSO, or it may connect to a different service
instance if applicable. instance if applicable.
6.6.3.2. Reconnecting after an Unexplained Connection Drop 6.6.3.2. Reconnecting after an Unexplained Connection Drop
skipping to change at page 43, line 36 skipping to change at page 43, line 36
the new inactivity timeout, then the client is immediately the new inactivity timeout, then the client is immediately
considered delinquent (this DSO Session is immediately eligible to considered delinquent (this DSO Session is immediately eligible to
be forcibly terminated by the server) and the client MUST be forcibly terminated by the server) and the client MUST
immediately begin closing this DSO Session. However, if a server immediately begin closing this DSO Session. However, if a server
abruptly reduces the inactivity timeout in this way, then, to give abruptly reduces the inactivity timeout in this way, then, to give
the client time to close the connection gracefully before the the client time to close the connection gracefully before the
server resorts to forcibly aborting it, the server SHOULD give the server resorts to forcibly aborting it, the server SHOULD give the
client an additional grace period of either five seconds or one client an additional grace period of either five seconds or one
quarter of the new inactivity timeout, whichever is greater. quarter of the new inactivity timeout, whichever is greater.
7.1.2. Relationship to edns-tcp-keepalive EDNS0 Option 7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option
The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has
similar intent to the edns-tcp-keepalive EDNS0 Option [RFC7828]. A similar intent to the edns-tcp-keepalive EDNS(0) Option [RFC7828]. A
client/server pair that supports DSO MUST NOT use the edns-tcp- client/server pair that supports DSO MUST NOT use the edns-tcp-
keepalive EDNS0 Option within any message after a DSO Session has keepalive EDNS(0) Option within any message after a DSO Session has
been established. A client that has sent a DSO message to establish been established. A client that has sent a DSO message to establish
a session MUST NOT send an edns-tcp-keepalive EDNS0 Option from this a session MUST NOT send an edns-tcp-keepalive EDNS(0) Option from
point on. Once a DSO Session has been established, if either client this point on. Once a DSO Session has been established, if either
or server receives a DNS message over the DSO Session that contains client or server receives a DNS message over the DSO Session that
an edns-tcp-keepalive EDNS0 Option, this is a fatal error and the contains an edns-tcp-keepalive EDNS(0) Option, this is a fatal error
receiver of the edns-tcp-keepalive EDNS0 Option MUST forcibly abort and the receiver of the edns-tcp-keepalive EDNS(0) Option MUST
the connection immediately. forcibly abort the connection immediately.
7.2. Retry Delay TLV 7.2. Retry Delay TLV
The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary 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 (unidirectional) in a server-to-client message, or as a Response
Additional TLV in either direction. DSO messages with a Relay Delay Additional TLV in either direction. DSO messages with a Relay Delay
TLV as their Primary TLV are not permitted in early data. TLV as their Primary TLV are not permitted in early data.
The DSO-DATA for the Retry Delay TLV is as follows: The DSO-DATA for the Retry Delay TLV is as follows:
 End of changes. 13 change blocks. 
39 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/