idnits 2.17.1 draft-ietf-dnsop-session-signal-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1035, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 06, 2018) is 1966 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA1' is mentioned on line 2301, but not defined == Missing Reference: 'TBA2' is mentioned on line 2307, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-dnsop-no-response-issue-12 == Outdated reference: A later version (-04) exists of draft-ietf-dnssd-mdns-relay-01 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-16 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group R. Bellis 3 Internet-Draft ISC 4 Updates: 1035, 7766 (if approved) S. Cheshire 5 Intended status: Standards Track Apple Inc. 6 Expires: June 9, 2019 J. Dickinson 7 S. Dickinson 8 Sinodun 9 T. Lemon 10 Nibbhaya Consulting 11 T. Pusateri 12 Unaffiliated 13 December 06, 2018 15 DNS Stateful Operations 16 draft-ietf-dnsop-session-signal-20 18 Abstract 20 This document defines a new DNS OPCODE for DNS Stateful Operations 21 (DSO). DSO messages communicate operations within persistent 22 stateful sessions, using type-length-value (TLV) syntax. Three TLVs 23 are defined that manage session timeouts, termination, and encryption 24 padding, and a framework is defined for extensions to enable new 25 stateful operations. This document updates RFC 1035 by adding a new 26 DNS header opcode which has different message semantics, and a new 27 result code. This document updates RFC 7766 by redefining a session, 28 providing new guidance on connection re-use, and providing a new 29 mechanism for handling session idle timeouts. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 9, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. Session Management . . . . . . . . . . . . . . . . . 9 71 4.1.2. Long-lived Subscriptions . . . . . . . . . . . . . . 9 72 4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10 73 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12 75 5.1.1. Session Establishment Failure . . . . . . . . . . . . 13 76 5.1.2. Session Establishment Success . . . . . . . . . . . . 14 77 5.2. Operations After Session Establishment . . . . . . . . . 14 78 5.3. Session Termination . . . . . . . . . . . . . . . . . . . 15 79 5.3.1. Handling Protocol Errors . . . . . . . . . . . . . . 15 80 5.4. Message Format . . . . . . . . . . . . . . . . . . . . . 16 81 5.4.1. DNS Header Fields in DSO Messages . . . . . . . . . . 17 82 5.4.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 19 83 5.4.3. TLV Syntax . . . . . . . . . . . . . . . . . . . . . 21 84 5.4.4. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 24 85 5.5. Message Handling . . . . . . . . . . . . . . . . . . . . 25 86 5.5.1. Delayed Acknowledgement Management . . . . . . . . . 26 87 5.5.2. MESSAGE ID Namespaces . . . . . . . . . . . . . . . . 27 88 5.5.3. Error Responses . . . . . . . . . . . . . . . . . . . 28 89 5.6. Responder-Initiated Operation Cancellation . . . . . . . 29 90 6. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 30 91 6.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 30 92 6.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 31 93 6.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 32 94 6.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 33 95 6.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 33 96 6.4.2. Values for the Inactivity Timeout . . . . . . . . . . 34 97 6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 35 98 6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 35 99 6.5.2. Values for the Keepalive Interval . . . . . . . . . . 35 100 6.6. Server-Initiated Session Termination . . . . . . . . . . 37 101 6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 38 102 6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 39 103 6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 39 104 7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 41 105 7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 41 106 7.1.1. Client handling of received Session Timeout values . 43 107 7.1.2. Relationship to edns-tcp-keepalive EDNS0 Option . . . 44 108 7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 45 109 7.2.1. Retry Delay TLV used as a Primary TLV . . . . . . . . 45 110 7.2.2. Retry Delay TLV used as a Response Additional TLV . . 47 111 7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 48 112 8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 49 113 8.1. QR bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 49 114 8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 50 115 9. Additional Considerations . . . . . . . . . . . . . . . . . . 52 116 9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 52 117 9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 53 118 9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 54 119 9.4. Operational Considerations for Middlebox . . . . . . . . 55 120 9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 56 121 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 122 10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 59 123 10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 59 124 10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 59 125 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 126 11.1. TLS 0-RTT Considerations . . . . . . . . . . . . . . . . 61 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 129 13.1. Normative References . . . . . . . . . . . . . . . . . . 62 130 13.2. Informative References . . . . . . . . . . . . . . . . . 63 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 133 1. Introduction 135 This document specifies a mechanism for managing stateful DNS 136 connections. DNS most commonly operates over a UDP transport, but 137 can also operate over streaming transports; the original DNS RFC 138 specifies DNS over TCP [RFC1035] and a profile for DNS over TLS 139 [RFC7858] has been specified. These transports can offer persistent, 140 long-lived sessions and therefore when using them for transporting 141 DNS messages it is of benefit to have a mechanism that can establish 142 parameters associated with those sessions, such as timeouts. In such 143 situations it is also advantageous to support server-initiated 144 messages (such as DNS Push Notifications [I-D.ietf-dnssd-push]). 146 The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is 147 explicitly defined to only have "per-message" semantics. While 148 EDNS(0) has been used to signal at least one session-related 149 parameter (edns-tcp-keepalive EDNS0 Option [RFC7828]) the result is 150 less than optimal due to the restrictions imposed by the EDNS(0) 151 semantics and the lack of server-initiated signalling. For example, 152 a server cannot arbitrarily instruct a client to close a connection 153 because the server can only send EDNS(0) options in responses to 154 queries that contained EDNS(0) options. 156 This document defines a new DNS OPCODE, DSO ([TBA1], tentatively 6), 157 for DNS Stateful Operations. DSO messages are used to communicate 158 operations within persistent stateful sessions, expressed using type- 159 length-value (TLV) syntax. This document defines an initial set of 160 three TLVs, used to manage session timeouts, termination, and 161 encryption padding. 163 All three TLVs defined here are mandatory for all implementations of 164 DSO. Further TLVs may be defined in additional specifications. 166 DSO messages may or may not be acknowledged; this is signalled by 167 providing a non-zero message ID for messages that must be 168 acknowledged (DSO request messages) and a zero message ID for 169 messages that are not to be acknowledged (DSO unidirectional 170 messages), and is also specified in the definition of a particular 171 DSO message type. Messages are pipelined; answers may appear out of 172 order when more than one answer is pending. 174 The format for DSO messages (Section 5.4) differs somewhat from the 175 traditional DNS message format used for standard queries and 176 responses. The standard twelve-byte header is used, but the four 177 count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero and 178 accordingly their corresponding sections are not present. 180 The actual data pertaining to DNS Stateful Operations (expressed in 181 TLV syntax) is appended to the end of the DNS message header. Just 182 as in traditional DNS over TCP [RFC1035] [RFC7766] the stream 183 protocol carrying DSO messages (which are just another kind of DNS 184 message) frames them by putting a 16-bit message length at the start, 185 so the length of the DSO message is determined from that length, 186 rather than from any of the DNS header counts. 188 When displayed using packet analyzer tools that have not been updated 189 to recognize the DSO format, this will result in the DSO data being 190 displayed as unknown additional data after the end of the DNS 191 message. 193 This new format has distinct advantages over an RR-based format 194 because it is more explicit and more compact. Each TLV definition is 195 specific to its use case, and as a result contains no redundant or 196 overloaded fields. Importantly, it completely avoids conflating DNS 197 Stateful Operations in any way with normal DNS operations or with 198 existing EDNS(0)-based functionality. A goal of this approach is to 199 avoid the operational issues that have befallen EDNS(0), particularly 200 relating to middlebox behaviour (see for example 201 [I-D.ietf-dnsop-no-response-issue] sections 3.2 and 4). 203 With EDNS(0), multiple options may be packed into a single OPT 204 pseudo-RR, and there is no generalized mechanism for a client to be 205 able to tell whether a server has processed or otherwise acted upon 206 each individual option within the combined OPT pseudo-RR. The 207 specifications for each individual option need to define how each 208 different option is to be acknowledged, if necessary. 210 In contrast to EDNS(0), with DSO there is no compelling motivation to 211 pack multiple operations into a single message for efficiency 212 reasons, because DSO always operates using a connection-oriented 213 transport protocol. Each DSO operation is communicated in its own 214 separate DNS message, and the transport protocol can take care of 215 packing several DNS messages into a single IP packet if appropriate. 216 For example, TCP can pack multiple small DNS messages into a single 217 TCP segment. This simplification allows for clearer semantics. Each 218 DSO request message communicates just one primary operation, and the 219 RCODE in the corresponding response message indicates the success or 220 failure of that operation. 222 2. Requirements Language 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 226 "OPTIONAL" in this document are to be interpreted as described in BCP 227 14 [RFC2119] [RFC8174] when, and only when, they appear in all 228 capitals, as shown here. 230 3. Terminology 232 DSO: DNS Stateful Operations. 234 connection: a bidirectional byte (or message) stream, where the 235 bytes (or messages) are delivered reliably and in-order, such as 236 provided by using DNS over TCP [RFC1035] [RFC7766] or DNS over TLS 237 [RFC7858]. 239 session: The unqualified term "session" in the context of this 240 document refers to a persistent network connection between two 241 endpoints which allows for the exchange of DNS messages over a 242 connection where either end of the connection can send messages to 243 the other end. (The term has no relationship to the "session 244 layer" of the OSI "seven-layer model".) 246 DSO Session: a session established between two endpoints that 247 acknowledge persistent DNS state via the exchange of DSO messages 248 over the connection. This is distinct from a DNS-over-TCP session 249 as described in the previous specification for DNS over TCP 250 [RFC7766]. 252 close gracefully: a normal session shutdown, where the client closes 253 the TCP connection to the server using a graceful close, such that 254 no data is lost (e.g., using TCP FIN, see Section 5.3). 256 forcibly abort: a session shutdown as a result of a fatal error, 257 where the TCP connection is unilaterally aborted without regard 258 for data loss (e.g., using TCP RST, see Section 5.3). 260 server: the software with a listening socket, awaiting incoming 261 connection requests, in the usual DNS sense. 263 client: the software which initiates a connection to the server's 264 listening socket, in the usual DNS sense. 266 initiator: the software which sends a DSO request message or a DSO 267 unidirectional message during a DSO session. Either a client or 268 server can be an initiator 270 responder: the software which receives a DSO request message or a 271 DSO unidirectional message during a DSO 273 session. Either a client or server can be a responder. 275 sender: the software which is sending a DNS message, a DSO message, 276 a DNS response, or a DSO response. 278 receiver: the software which is receiving a DNS message, a DSO 279 message, a DNS response, or a DSO response. 281 service instance: a specific instance of server software running on 282 a specific host (Section 9.1). 284 long-lived operation: a long-lived operation is an outstanding 285 operation on a DSO session where either the client or server, 286 acting as initiator, has requested that the responder send new 287 information regarding the request, as it becomes available. 289 Early Data: A TLS 1.3 handshake containing early data that begins a 290 DSO session ([RFC8446] section 2.3). TCP Fast Open is only permitted 291 when using TLS. 293 DNS message: any DNS message, including DNS queries, response, 294 updates, DSO messages, etc. 296 DNS request message: any DNS message where the QR bit is 0. 298 DNS response message: any DNS message where the QR bit is 1. 300 DSO message: a DSO request message, DSO unidirectional message, or a 301 DSO response to a DSO request message. If the QR bit is 1 in a 302 DSO message, it is a DSO response message. If the QR bit is 0 in 303 a DSO message, it is a DSO request message or DSO unidirectional 304 message, as determined by the specification of its primary TLV. 306 DSO response message: a response to a DSO request message. 308 DSO request message: a DSO message that requires a response. 310 DSO unidirectional message: a DSO message that does not require and 311 cannot induce a response. 313 Primary TLV: The first TLV in a DSO message or DSO response; in the 314 DSO message this determines the nature of the operation being 315 performed. 317 Additional TLV: Any TLVs in a DSO message response that follow the 318 primary TLV. 320 Response Primary TLV: The (optional) first TLV in a DSO response. 322 Response Additional TLV: Any TLVs in a DSO response that follow the 323 (optional) Response Primary TLV. 325 inactivity timer: the time since the most recent non-keepalive DNS 326 message was sent or received. (see Section 6.4) 328 keepalive timer: the time since the most recent DNS message was sent 329 or received. (see Section 6.5) 331 session timeouts: the inactivity timer and the keepalive timer. 333 inactivity timeout: the maximum value that the inactivity timer can 334 have before the connection is gracefully closed. 336 keepalive interval: the maximum value that the keepalive timer can 337 have before the client is required to send a keepalive. (see 338 Section 7.1) 340 resetting a timer: setting the timer value to zero and restarting 341 the timer. 343 clearing a timer: setting the timer value to zero but not restarting 344 the timer. 346 4. Applicability 348 DNS Stateful Operations are applicable to several known use cases and 349 are only applicable on transports that are capable of supporting a 350 DSO Session. 352 4.1. Use Cases 354 There are several use cases for DNS Stateful operations that can be 355 described here. 357 4.1.1. Session Management 359 Firstly, establishing session parameters such as server-defined 360 timeouts is of great use in the general management of persistent 361 connections. For example, using DSO sessions for stub-to-recursive 362 DNS-over-TLS [RFC7858] is more flexible for both the client and the 363 server than attempting to manage sessions using just the edns-tcp- 364 keepalive EDNS0 Option [RFC7828]. The simple set of TLVs defined in 365 this document is sufficient to greatly enhance connection management 366 for this use case. 368 4.1.2. Long-lived Subscriptions 370 Secondly, DNS-SD [RFC6763] has evolved into a naturally session-based 371 mechanism where, for example, long-lived subscriptions lend 372 themselves to 'push' mechanisms as opposed to polling. Long-lived 373 stateful connections and server-initiated messages align with this 374 use case [I-D.ietf-dnssd-push]. 376 A general use case is that DNS traffic is often bursty but session 377 establishment can be expensive. One challenge with long-lived 378 connections is to maintain sufficient traffic to maintain NAT and 379 firewall state. To mitigate this issue this document introduces a 380 new concept for the DNS, that is DSO "Keepalive traffic". This 381 traffic carries no DNS data and is not considered 'activity' in the 382 classic DNS sense, but serves to maintain state in middleboxes, and 383 to assure client and server that they still have connectivity to each 384 other. 386 4.2. Applicable Transports 388 DNS Stateful Operations are applicable in cases where it is useful to 389 maintain an open session between a DNS client and server, where the 390 transport allows such a session to be maintained, and where the 391 transport guarantees in-order delivery of messages, on which DSO 392 depends. Examples of transports that can support DNS Stateful 393 Operations are DNS-over-TCP [RFC1035] [RFC7766] and DNS-over-TLS 394 [RFC7858]. 396 Note that in the case of DNS over TLS, there is no mechanism for 397 upgrading from DNS-over-TCP to DNS-over-TLS mid-connection (see 398 [RFC7858] section 7). A connection is either DNS-over-TCP from the 399 start, or DNS-over-TLS from the start. 401 DNS Stateful Operations are not applicable for transports that cannot 402 support clean session semantics, or that do not guarantee in-order 403 delivery. While in principle such a transport could be constructed 404 over UDP, the current DNS specification over UDP transport [RFC1035] 405 does not provide in-order delivery or session semantics, and hence 406 cannot be used. Similarly, DNS-over-HTTP 407 [I-D.ietf-doh-dns-over-https] cannot be used because HTTP has its own 408 mechanism for managing sessions, and this is incompatible with the 409 mechanism specified here. 411 No other transports are currently defined for use with DNS Stateful 412 Operations. Such transports can be added in the future, if they meet 413 the requirements set out in the first paragraph of this section. 415 5. Protocol Details 417 The overall flow of DNS Stateful Operations goes through a series of 418 phases: 420 Connection Establishment: A client establishes a connection to a 421 server. (Section 4.2) 423 Connected but sessionless: A connection exists, but a DSO session 424 has not been established. DNS messages can be sent from the 425 client to server, and DNS responses can be sent from servers to 426 clients. In this state a client that wishes to use DSO can 427 attempt to establish a DSO session (Section 5.1). Standard DNS- 428 over-TCP inactivity timeout handling is in effect [RFC7766] (see 429 Section 7.1.2). 431 DSO Session Establishment in Progress: A client has sent a DSO 432 request, but has not yet received a DSO response. In this phase, 433 the client may send more DSO requests and more DNS requests, but 434 MUST NOT send DSO unidirectional messages (Section 5.1). 436 DSO Session Establishment Failed: The attempt to establish the DSO 437 session did not succeed. At this point, the client is permitted 438 to continue operating without a DSO session (Connected but 439 Sessionless) but does not send further DSO messages (Section 5.1). 441 DSO Session Established: Both client and server may send DSO 442 messages and DNS messages; both may send replies in response to 443 messages they receive (Section 5.2). The inactivity timer 444 (Section 6.4) is active; the keepalive timer (Section 6.5) is 445 active. Standard DNS-over-TCP inactivity timeout handling is no 446 longer in effect [RFC7766] (see Section 7.1.2). 448 Server Shutdown: The server has decided to gracefully terminate the 449 session, and has sent the client a Retry Delay message 450 (Section 6.6.1). There may still be unprocessed messages from the 451 client; the server will ignore these. The server will not send 452 any further messages to the client (Section 6.6.1.1). 454 Client Shutdown: The client has decided to disconnect, either 455 because it no longer needs service, the connection is inactive 456 (Section 6.4.1), or because the server sent it a Retry Delay 457 message (Section 6.6.1). The client closes the connection 458 gracefully Section 5.3. 460 Reconnect: The client disconnected as a result of a server shutdown. 461 The client either waits for the server-specified Retry Delay to 462 expire (Section 6.6.3), or else contacts a different server 463 instance. If the client no longer needs service, it does not 464 reconnect. 466 Forcibly Abort: The client or server detected a protocol error, and 467 further communication would have undefined behavior. The client 468 or server forcibly aborts the connection (Section 5.3). 470 Abort Reconnect Wait: The client has forcibly aborted the 471 connection, but still needs service. Or, the server forcibly 472 aborted the connection, but the client still needs service. The 473 client either connects to a different service instance 474 (Section 9.1) or waits to reconnect (Section 6.6.3.1). 476 5.1. DSO Session Establishment 478 In order for a session to be established between a client and a 479 server, the client must first establish a connection to the server, 480 using an applicable transport (see Section 4). 482 In some environments it may be known in advance by external means 483 that both client and server support DSO, and in these cases either 484 client or server may initiate DSO messages at any time. In this 485 case, the session is established as soon as the connection is 486 established; this is referred to as implicit session establishment. 488 However, in the typical case a server will not know in advance 489 whether a client supports DSO, so in general, unless it is known in 490 advance by other means that a client does support DSO, a server MUST 491 NOT initiate DSO request messages or DSO unidirectional messages 492 until a DSO Session has been mutually established by at least one 493 successful DSO request/response exchange initiated by the client, as 494 described below. This is referred to as explicit session 495 establishment. 497 Until a DSO session has been implicitly or explicitly established, a 498 client MUST NOT initiate DSO unidirectional messages. 500 A DSO Session is established over a connection by the client sending 501 a DSO request message, such as a DSO Keepalive request message 502 (Section 7.1), and receiving a response, with matching MESSAGE ID, 503 and RCODE set to NOERROR (0), indicating that the DSO request was 504 successful. 506 Some DSO messages are permitted as early data (Section 11.1). Others 507 are not. Unidirectional messages are never permitted as early data 508 unless an implicit session exists. 510 If a server receives a DSO message in early data whose primary TLV is 511 not permitted to appear in early data, the server MUST forcibly abort 512 the connection. If a client receives a DSO message in early data, 513 and there is no implicit DSO session, the client MUST forcibly abort 514 the connection. This can only be enforced on TLS connections; 515 therefore, servers MUST NOT enable TFO when listening for a 516 connection that does not require TLS. 518 5.1.1. Session Establishment Failure 520 If the response RCODE is set to NOTIMP (4), or in practise any value 521 other than NOERROR (0) or DSOTYPENI (defined below), then the client 522 MUST assume that the server does not implement DSO at all. In this 523 case the client is permitted to continue sending DNS messages on that 524 connection, but the client MUST NOT issue further DSO messages on 525 that connection. 527 If the RCODE in the response is set to DSOTYPENI ("DSO-TYPE Not 528 Implemented", [TBA2] tentatively RCODE 11) this indicates that the 529 server does support DSO, but does not implement the DSO-TYPE of the 530 primary TLV in this DSO request message. A server implementing DSO 531 MUST NOT return DSOTYPENI for a DSO Keepalive request message, 532 because the Keepalive TLV is mandatory to implement. But in the 533 future, if a client attempts to establish a DSO Session using a 534 response-requiring DSO request message using some newly-defined DSO- 535 TYPE that the server does not understand, that would result in a 536 DSOTYPENI response. If the server returns DSOTYPENI then a DSO 537 Session is not considered established, but the client is permitted to 538 continue sending DNS messages on the connection, including other DSO 539 messages such as the DSO Keepalive, which may result in a successful 540 NOERROR response, yielding the establishment of a DSO Session. 542 Two other possibilities exist: the server might drop the connection, 543 or the server might send no response to the DSO message. 545 In the first case, the client SHOULD mark that service instance as 546 not supporting DSO, and not attempt a DSO connection for some period 547 of time (at least an hour) after the failed attempt. The client MAY 548 reconnect but not use DSO, if appropriate (Section 6.6.3.2). 550 In the second case, the client SHOULD wait 30 seconds, after which 551 time the server will be assumed not to support DSO. If the server 552 doesn't respond within 30 seconds, the client MUST forcibly abort the 553 connection to the server, since the server's behavior is out of spec, 554 and hence its state is undefined. The client MAY reconnect, but not 555 use DSO, if appropriate (Section 6.6.3.1). 557 5.1.2. Session Establishment Success 559 When the server receives a DSO request message from a client, and 560 transmits a successful NOERROR response to that request, the server 561 considers the DSO Session established. 563 When the client receives the server's NOERROR response to its DSO 564 request message, the client considers the DSO Session established. 566 Once a DSO Session has been established, either end may unilaterally 567 send appropriate DSO messages at any time, and therefore either 568 client or server may be the initiator of a message. 570 5.2. Operations After Session Establishment 572 Once a DSO Session has been established, clients and servers should 573 behave as described in this specification with regard to inactivity 574 timeouts and session termination, not as previously prescribed in the 575 earlier specification for DNS over TCP [RFC7766]. 577 Because a server that supports DNS Stateful Operations MUST return an 578 RCODE of NOERROR when it receives a Keepalive TLV DSO request 579 message, the Keepalive TLV is an ideal candidate for use in 580 establishing a DSO session. Any other option that can only succeed 581 when sent to a server of the desired kind is also a good candidate 582 for use in establishing a DSO session. For clients that implement 583 only the DSO-TYPEs defined in this base specification, sending a 584 Keepalive TLV is the only DSO request message they have available to 585 initiate a DSO Session. Even for clients that do implement other 586 future DSO-TYPEs, for simplicity they MAY elect to always send an 587 initial DSO Keepalive request message as their way of initiating a 588 DSO Session. A future definition of a new response-requiring DSO- 589 TYPE gives implementers the option of using that new DSO-TYPE if they 590 wish, but does not change the fact that sending a Keepalive TLV 591 remains a valid way of initiating a DSO Session. 593 5.3. Session Termination 595 A "DSO Session" is terminated when the underlying connection is 596 closed. Sessions are "closed gracefully" as a result of the server 597 closing a session because it is overloaded, the client closing the 598 session because it is done, or the client closing the session because 599 it is inactive. Sessions are "forcibly aborted" when either the 600 client or server closes the connection because of a protocol error. 602 o Where this specification says, "close gracefully," that means 603 sending a TLS close_notify (if TLS is in use) followed by a TCP 604 FIN, or the equivalents for other protocols. Where this 605 specification requires a connection to be closed gracefully, the 606 requirement to initiate that graceful close is placed on the 607 client, to place the burden of TCP's TIME-WAIT state on the client 608 rather than the server. 610 o Where this specification says, "forcibly abort," that means 611 sending a TCP RST, or the equivalent for other protocols. In the 612 BSD Sockets API this is achieved by setting the SO_LINGER option 613 to zero before closing the socket. 615 5.3.1. Handling Protocol Errors 617 In protocol implementation there are generally two kinds of errors 618 that software writers have to deal with. The first is situations 619 that arise due to factors in the environment, such as temporary loss 620 of connectivity. While undesirable, these situations do not indicate 621 a flaw in the software, and they are situations that software should 622 generally be able to recover from. 624 The second is situations that should never happen when communicating 625 with a compliant DSO implementation. If they do happen, they 626 indicate a serious flaw in the protocol implementation, beyond what 627 it is reasonable to expect software to recover from. This document 628 describes this latter form of error condition as a "fatal error" and 629 specifies that an implementation encountering a fatal error condition 630 "MUST forcibly abort the connection immediately". 632 5.4. Message Format 634 A DSO message begins with the standard twelve-byte DNS message header 635 [RFC1035] with the OPCODE field set to the DSO OPCODE. However, 636 unlike standard DNS messages, the question section, answer section, 637 authority records section and additional records sections are not 638 present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, 639 ARCOUNT) MUST be set to zero on transmission. 641 If a DSO message is received where any of the count fields are not 642 zero, then a FORMERR MUST be returned. 644 1 1 1 1 1 1 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 646 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 647 | MESSAGE ID | 648 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 649 |QR | OPCODE | Z | RCODE | 650 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 651 | QDCOUNT (MUST be zero) | 652 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 653 | ANCOUNT (MUST be zero) | 654 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 655 | NSCOUNT (MUST be zero) | 656 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 657 | ARCOUNT (MUST be zero) | 658 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 659 | | 660 / DSO Data / 661 / / 662 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 664 5.4.1. DNS Header Fields in DSO Messages 666 In a DSO unidirectional message the MESSAGE ID field MUST be set to 667 zero. In a DSO request message the MESSAGE ID field MUST be set to a 668 unique nonzero value, that the initiator is not currently using for 669 any other active operation on this connection. For the purposes 670 here, a MESSAGE ID is in use in this DSO Session if the initiator has 671 used it in a DSO request message for which it is still awaiting a 672 response, or if the client has used it to set up a long-lived 673 operation that has not yet been cancelled. For example, a long-lived 674 operation could be a Push Notification subscription 675 [I-D.ietf-dnssd-push] or a Discovery Relay interface subscription 676 [I-D.ietf-dnssd-mdns-relay]. 678 Whether a message is a DSO request message or a DSO unidirectional 679 message is determined only by the specification for the Primary TLV. 680 An acknowledgment cannot be requested by including a nonzero message 681 ID in a message that is required according to its primary TLV to be 682 unidirectional. Nor can an acknowledgment be prevented by sending a 683 message ID of zero in a message that is required to be a DSO request 684 message according to its primary TLV. A responder that receives 685 either such malformed message MUST treat it as a fatal error and 686 forcibly abort the connection immediately. 688 In a DSO request message or DSO unidirectional message the DNS Header 689 QR bit MUST be zero (QR=0). If the QR bit is not zero the message is 690 not a DSO request or DSO unidirectional message. 692 In a DSO response message the DNS Header QR bit MUST be one (QR=1). 693 If the QR bit is not one, the message is not a response message. 695 In a DSO response message (QR=1) the MESSAGE ID field MUST contain a 696 copy of the value of the MESSAGE ID field in the DSO request message 697 being responded to. In a DSO response message (QR=1) the MESSAGE ID 698 field MUST NOT be zero. If a DSO response message (QR=1) is received 699 where the MESSAGE ID is zero this is a fatal error and the recipient 700 MUST forcibly abort the connection immediately. 702 The DNS Header OPCODE field holds the DSO OPCODE value. 704 The Z bits are currently unused in DSO messages, and in both DSO 705 request messages and DSO responses the Z bits MUST be set to zero (0) 706 on transmission and MUST be ignored on reception. 708 In a DSO request message (QR=0) the RCODE is set according to the 709 definition of the request. For example, in a Retry Delay message 710 (Section 6.6.1) the RCODE indicates the reason for termination. 711 However, in most cases, except where clearly specified otherwise, in 712 a DSO request message (QR=0) the RCODE is set to zero on 713 transmission, and silently ignored on reception. 715 The RCODE value in a response message (QR=1) may be one of the 716 following values: 718 +--------+-----------+----------------------------------------------+ 719 | Code | Mnemonic | Description | 720 +--------+-----------+----------------------------------------------+ 721 | 0 | NOERROR | Operation processed successfully | 722 | | | | 723 | 1 | FORMERR | Format error | 724 | | | | 725 | 2 | SERVFAIL | Server failed to process DSO request message | 726 | | | due to a problem with the server | 727 | | | | 728 | 4 | NOTIMP | DSO not supported | 729 | | | | 730 | 5 | REFUSED | Operation declined for policy reasons | 731 | | | | 732 | [TBA2] | DSOTYPENI | Primary TLV's DSO-Type is not implemented | 733 | 11 | | | 734 +--------+-----------+----------------------------------------------+ 736 Use of the above RCODEs is likely to be common in DSO but does not 737 preclude the definition and use of other codes in future documents 738 that make use of DSO. 740 If a document defining a new DSO-TYPE makes use of response codes not 741 defined here, then that document MUST specify the specific 742 interpretation of those RCODE values in the context of that new DSO 743 TLV. 745 5.4.2. DSO Data 747 The standard twelve-byte DNS message header with its zero-valued 748 count fields is followed by the DSO Data, expressed using TLV syntax, 749 as described below in Section 5.4.3. 751 A DSO request message or DSO unidirectional message MUST contain at 752 least one TLV. The first TLV in a DSO request message or DSO 753 unidirectional message is referred to as the "Primary TLV" and 754 determines the nature of the operation being performed, including 755 whether it is a DSO request or a DSO unidirectional operation. In 756 some cases it may be appropriate to include other TLVs in a DSO 757 request message or DSO unidirectional message, such as the Encryption 758 Padding TLV (Section 7.3), and these extra TLVs are referred to as 759 the "Additional TLVs" and are not limited to what is defined in this 760 document. New "Additional TLVs" may be defined in the future and 761 those definitions will describe when their use is appropriate. 763 A DSO response message may contain no TLVs, or it may be specified to 764 contain one or more TLVs appropriate to the information being 765 communicated. This includes "Primary TLVs" and "Additional TLVs" 766 defined in this document as well as in future TLV definitions. It 767 may be permissible for an additional TLV to appear in a response to a 768 primary TLV even though the specification of that primary TLV does 769 not specify it explicitly. See Section 8.2 for more information. 771 A DSO response message may contain one or more TLVs with the Primary 772 TLV DSO-TYPE the same as the Primary TLV from the corresponding DSO 773 request message or it may contain zero or more Additional TLVs only. 774 The MESSAGE ID field in the DNS message header is sufficient to 775 identify the DSO request message to which this response message 776 relates. 778 A DSO response message may contain one or more TLVs with DSO-TYPEs 779 different from the Primary TLV from the corresponding DSO request 780 message, in which case those TLV(s) are referred to as "Response 781 Additional TLVs". 783 Response Primary TLV(s), if present, MUST occur first in the response 784 message, before any Response Additional TLVs. 786 It is anticipated that most DSO operations will be specified to use 787 DSO request messages, which generate corresponding DSO responses. In 788 some specialized high-traffic use cases, it may be appropriate to 789 specify DSO unidirectional messages. DSO unidirectional messages can 790 be more efficient on the network, because they don't generate a 791 stream of corresponding reply messages. Using DSO unidirectional 792 messages can also simplify software in some cases, by removing need 793 for an initiator to maintain state while it waits to receive replies 794 it doesn't care about. When the specification for a particular TLV 795 states that, when used as a Primary TLV (i.e., first) in an outgoing 796 DSO request message (i.e., QR=0), that message is to be 797 unidirectional, the MESSAGE ID field MUST be set to zero and the 798 receiver MUST NOT generate any response message corresponding to this 799 DSO unidirectional message. 801 The previous point, that the receiver MUST NOT generate responses to 802 DSO unidirectional messages, applies even in the case of errors. 804 When a DSO message is received where both the QR bit and the MESSAGE 805 ID field are zero, the receiver MUST NOT generate any response. For 806 example, if the DSO-TYPE in the Primary TLV is unrecognized, then a 807 DSOTYPENI error MUST NOT be returned; instead the receiver MUST 808 forcibly abort the connection immediately. 810 DSO unidirectional messages MUST NOT be used "speculatively" in cases 811 where the sender doesn't know if the receiver supports the Primary 812 TLV in the message, because there is no way to receive any response 813 to indicate success or failure. DSO unidirectional messages are only 814 appropriate in cases where the sender already knows that the receiver 815 supports, and wishes to receive, these messages. 817 For example, after a client has subscribed for Push Notifications 818 [I-D.ietf-dnssd-push], the subsequent event notifications are then 819 sent as DSO unidirectional messages, and this is appropriate because 820 the client initiated the message stream by virtue of its Push 821 Notification subscription, thereby indicating its support of Push 822 Notifications, and its desire to receive those notifications. 824 Similarly, after a Discovery Relay client has subscribed to receive 825 inbound mDNS (multicast DNS, [RFC6762]) traffic from a Discovery 826 Relay, the subsequent stream of received packets is then sent using 827 DSO unidirectional messages, and this is appropriate because the 828 client initiated the message stream by virtue of its Discovery Relay 829 link subscription, thereby indicating its support of Discovery Relay, 830 and its desire to receive inbound mDNS packets over that DSO session 831 [I-D.ietf-dnssd-mdns-relay]. 833 5.4.3. TLV Syntax 835 All TLVs, whether used as "Primary", "Additional", "Response 836 Primary", or "Response Additional", use the same encoding syntax. 838 Specifications that define new TLVs must specify whether the DSO-TYPE 839 can be used as the Primary TLV, used as an Additional TLV, or used in 840 either context, both in the case of requests and of responses. The 841 specification for a TLV must also state whether, when used as the 842 Primary (i.e., first) TLV in a DSO message (i.e., QR=0), that DSO 843 message is unidirectional or is a request message which requires a 844 response. If the DSO message requires a response, the specification 845 must also state which TLVs, if any, are to be included in the 846 response. The Primary TLV may or may not be contained in the 847 response, depending on what is specified for that TLV. 849 1 1 1 1 1 1 850 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 851 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 852 | DSO-TYPE | 853 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 854 | DSO-LENGTH | 855 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 856 | | 857 / DSO-DATA / 858 / / 859 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 861 DSO-TYPE: A 16-bit unsigned integer, in network (big endian) byte 862 order, giving the DSO-TYPE of the current DSO TLV per the IANA DSO 863 Type Code Registry. 865 DSO-LENGTH: A 16-bit unsigned integer, in network (big endian) byte 866 order, giving the size in bytes of the DSO-DATA. 868 DSO-DATA: Type-code specific format. The generic DSO machinery 869 treats the DSO-DATA as an opaque "blob" without attempting to 870 interpret it. Interpretation of the meaning of the DSO-DATA for a 871 particular DSO-TYPE is the responsibility of the software that 872 implements that DSO-TYPE. 874 5.4.3.1. Request TLVs 876 The first TLV in a DSO request message or DSO unidirectional message 877 is the "Primary TLV" and indicates the operation to be performed. A 878 DSO request message or DSO unidirectional message MUST contain at at 879 least one TLV-the Primary TLV. 881 Immediately following the Primary TLV, a DSO request message or DSO 882 unidirectional message MAY contain one or more "Additional TLVs", 883 which specify additional parameters relating to the operation. 885 5.4.3.2. Response TLVs 887 Depending on the operation, a DSO response message MAY contain no 888 TLVs, because it is simply a response to a previous DSO request 889 message, and the MESSAGE ID in the header is sufficient to identify 890 the DSO request in question. Or it may contain a single response 891 TLV, with the same DSO-TYPE as the Primary TLV in the request 892 message. Alternatively it may contain one or more TLVs of other 893 types, or a combination of the above, as appropriate for the 894 information that needs to be communicated. The specification for 895 each DSO TLV determines what TLVs are required in a response to a DSO 896 request message using that TLV. 898 If a DSO response is received for an operation where the 899 specification requires that the response carry a particular TLV or 900 TLVs, and the required TLV(s) are not present, then this is a fatal 901 error and the recipient of the defective response message MUST 902 forcibly abort the connection immediately. 904 5.4.3.3. Unrecognized TLVs 906 If DSO request message is received containing an unrecognized Primary 907 TLV, with a nonzero MESSAGE ID (indicating that a response is 908 expected), then the receiver MUST send an error response with 909 matching MESSAGE ID, and RCODE DSOTYPENI. The error response MUST 910 NOT contain a copy of the unrecognized Primary TLV. 912 If DSO unidirectional message is received containing an unrecognized 913 Primary TLV, with a zero MESSAGE ID (indicating that no response is 914 expected), then this is a fatal error and the recipient MUST forcibly 915 abort the connection immediately. 917 If a DSO request message or DSO unidirectional message is received 918 where the Primary TLV is recognized, containing one or more 919 unrecognized Additional TLVs, the unrecognized Additional TLVs MUST 920 be silently ignored, and the remainder of the message is interpreted 921 and handled as if the unrecognized parts were not present. 923 Similarly, if a DSO response message is received containing one or 924 more unrecognized TLVs, the unrecognized TLVs MUST be silently 925 ignored, and the remainder of the message is interpreted and handled 926 as if the unrecognized parts were not present. 928 5.4.4. EDNS(0) and TSIG 930 Since the ARCOUNT field MUST be zero, a DSO message cannot contain a 931 valid EDNS(0) option in the additional records section. If 932 functionality provided by current or future EDNS(0) options is 933 desired for DSO messages, one or more new DSO TLVs need to be defined 934 to carry the necessary information. 936 For example, the EDNS(0) Padding Option [RFC7830] used for security 937 purposes is not permitted in a DSO message, so if message padding is 938 desired for DSO messages then the Encryption Padding TLV described in 939 Section 7.3 MUST be used. 941 A DSO message can't contain a TSIG record, because a TSIG record is 942 included in the additional section of the message, which would mean 943 that ARCOUNT would be greater than zero. DSO messages are required 944 to have an ARCOUNT of zero. Therefore, if use of signatures with DSO 945 messages becomes necessary in the future, a new DSO TLV would have to 946 be defined to perform this function. 948 Note however that, while DSO *messages* cannot include EDNS(0) or 949 TSIG records, a DSO *session* is typically used to carry a whole 950 series of DNS messages of different kinds, including DSO messages, 951 and other DNS message types like Query [RFC1034] [RFC1035] and Update 952 [RFC2136], and those messages can carry EDNS(0) and TSIG records. 954 Although messages may contain other EDNS(0) options as appropriate, 955 this specification explicitly prohibits use of the edns-tcp-keepalive 956 EDNS0 Option [RFC7828] in *any* messages sent on a DSO Session 957 (because it is obsoleted by the functionality provided by the DSO 958 Keepalive operation). If any message sent on a DSO Session contains 959 an edns-tcp-keepalive EDNS0 Option this is a fatal error and the 960 recipient of the defective message MUST forcibly abort the connection 961 immediately. 963 5.5. Message Handling 965 As described above in Section 5.4.1, whether an outgoing DSO message 966 with the QR bit in the DNS header set to zero is a DSO request or DSO 967 unidirectional message is determined by the specification for the 968 Primary TLV, which in turn determines whether the MESSAGE ID field in 969 that outgoing message will be zero or nonzero. 971 Every DSO message with the QR bit in the DNS header set to zero and a 972 nonzero MESSAGE ID field is a DSO request message, and MUST elicit a 973 corresponding response, with the QR bit in the DNS header set to one 974 and the MESSAGE ID field set to the value given in the corresponding 975 DSO request message. 977 Valid DSO request messages sent by the client with a nonzero MESSAGE 978 ID field elicit a response from the server, and valid DSO request 979 messages sent by the server with a nonzero MESSAGE ID field elicit a 980 response from the client. 982 Every DSO message with both the QR bit in the DNS header and the 983 MESSAGE ID field set to zero is a DSO unidirectional message, and 984 MUST NOT elicit a response. 986 5.5.1. Delayed Acknowledgement Management 988 Generally, most good TCP implementations employ a delayed 989 acknowledgement timer to provide more efficient use of the network 990 and better performance. 992 With a bidirectional exchange over TCP, as for example with a DSO 993 request message, the operating system TCP implementation waits for 994 the application-layer client software to generate the corresponding 995 DSO response message. It can then send a single combined packet 996 containing the TCP acknowledgement, the TCP window update, and the 997 application-generated DSO response message. This is more efficient 998 than sending three separate packets, as would occur if the TCP packet 999 containing the DSO request were acknowledged immediately. 1001 With a DSO unidirectional message or DSO response message, there is 1002 no corresponding application-generated DSO response message, and 1003 consequently, no hint to the transport protocol about when it should 1004 send its acknowledgement and window update. 1006 Some networking APIs provide a mechanism that allows the application- 1007 layer client software to signal to the transport protocol that no 1008 response will be forthcoming (in effect it can be thought of as a 1009 zero-length "empty" write). Where available in the networking API 1010 being used, the recipient of a DSO unidirectional message or DSO 1011 response message, having parsed and interpreted the message, SHOULD 1012 then use this mechanism provided by the networking API to signal that 1013 no response for this message will be forthcoming, so that the TCP 1014 implementation can go ahead and send its acknowledgement and window 1015 update without further delay. See Section 9.5 for further discussion 1016 of why this is important. 1018 5.5.2. MESSAGE ID Namespaces 1020 The namespaces of 16-bit MESSAGE IDs are independent in each 1021 direction. This means it is *not* an error for both client and 1022 server to send DSO request messages at the same time as each other, 1023 using the same MESSAGE ID, in different directions. This 1024 simplification is necessary in order for the protocol to be 1025 implementable. It would be infeasible to require the client and 1026 server to coordinate with each other regarding allocation of new 1027 unique MESSAGE IDs. It is also not necessary to require the client 1028 and server to coordinate with each other regarding allocation of new 1029 unique MESSAGE IDs. The value of the 16-bit MESSAGE ID combined with 1030 the identity of the initiator (client or server) is sufficient to 1031 unambiguously identify the operation in question. This can be 1032 thought of as a 17-bit message identifier space, using message 1033 identifiers 0x00001-0x0FFFF for client-to-server DSO request 1034 messages, and message identifiers 0x10001-0x1FFFF for server-to- 1035 client DSO request messages. The least-significant 16 bits are 1036 stored explicitly in the MESSAGE ID field of the DSO message, and the 1037 most-significant bit is implicit from the direction of the message. 1039 As described above in Section 5.4.1, an initiator MUST NOT reuse a 1040 MESSAGE ID that it already has in use for an outstanding DSO request 1041 message (unless specified otherwise by the relevant specification for 1042 the DSO-TYPE in question). At the very least, this means that a 1043 MESSAGE ID can't be reused in a particular direction on a particular 1044 DSO Session while the initiator is waiting for a response to a 1045 previous DSO request message using that MESSAGE ID on that DSO 1046 Session (unless specified otherwise by the relevant specification for 1047 the DSO-TYPE in question), and for a long-lived operation the MESSAGE 1048 ID for the operation can't be reused while that operation remains 1049 active. 1051 If a client or server receives a response (QR=1) where the MESSAGE ID 1052 is zero, or is any other value that does not match the MESSAGE ID of 1053 any of its outstanding operations, this is a fatal error and the 1054 recipient MUST forcibly abort the connection immediately. 1056 If a responder receives a DSO request message (QR=0) where the 1057 MESSAGE ID is not zero, and the responder tracks request MESSAGE IDs, 1058 and the MESSAGE ID matches the MESSAGE ID of a DSO request message it 1059 received for which a response has not yet been sent, it MUST forcibly 1060 abort the connection immediately. This behavior is required to 1061 prevent a hypothetical attack that takes advantage of undefined 1062 behavior in this case. However, if the responder does not track 1063 MESSAGE IDs in this way, no such risk exists, so tracking MESSAGE IDs 1064 just to implement this sanity check is not required. 1066 5.5.3. Error Responses 1068 When a DSO unidirectional message type is received (MESSAGE ID field 1069 is zero), the receiver should already be expecting this DSO message 1070 type. Section 5.4.3.3 describes the handling of unknown DSO message 1071 types. Parsing errors MUST also result in the receiver forcibly 1072 aborting the connection. When a DSO unidirectional message of an 1073 unexpected type is received, the receiver SHOULD forcibly abort the 1074 connection. Whether the connection should be forcibly aborted for 1075 other internal errors processing the DSO unidirectional message is 1076 implementation dependent, according to the severity of the error. 1078 When a DSO request message is unsuccessful for some reason, the 1079 responder returns an error code to the initiator. 1081 In the case of a server returning an error code to a client in 1082 response to an unsuccessful DSO request message, the server MAY 1083 choose to end the DSO Session, or MAY choose to allow the DSO Session 1084 to remain open. For error conditions that only affect the single 1085 operation in question, the server SHOULD return an error response to 1086 the client and leave the DSO Session open for further operations. 1088 For error conditions that are likely to make all operations 1089 unsuccessful in the immediate future, the server SHOULD return an 1090 error response to the client and then end the DSO Session by sending 1091 a Retry Delay message, as described in Section 6.6.1. 1093 Upon receiving an error response from the server, a client SHOULD NOT 1094 automatically close the DSO Session. An error relating to one 1095 particular operation on a DSO Session does not necessarily imply that 1096 all other operations on that DSO Session have also failed, or that 1097 future operations will fail. The client should assume that the 1098 server will make its own decision about whether or not to end the DSO 1099 Session, based on the server's determination of whether the error 1100 condition pertains to this particular operation, or would also apply 1101 to any subsequent operations. If the server does not end the DSO 1102 Session by sending the client a Retry Delay message (Section 6.6.1) 1103 then the client SHOULD continue to use that DSO Session for 1104 subsequent operations. 1106 5.6. Responder-Initiated Operation Cancellation 1108 This document, the base specification for DNS Stateful Operations, 1109 does not itself define any long-lived operations, but it defines a 1110 framework for supporting long-lived operations, such as Push 1111 Notification subscriptions [I-D.ietf-dnssd-push] and Discovery Relay 1112 interface subscriptions [I-D.ietf-dnssd-mdns-relay]. 1114 Long-lived operations, if successful, will remain active until the 1115 initiator terminates the operation. 1117 However, it is possible that a long-lived operation may be valid at 1118 the time it was initiated, but then a later change of circumstances 1119 may render that operation invalid. For example, a long-lived client 1120 operation may pertain to a name that the server is authoritative for, 1121 but then the server configuration is changed such that it is no 1122 longer authoritative for that name. 1124 In such cases, instead of terminating the entire session it may be 1125 desirable for the responder to be able to cancel selectively only 1126 those operations that have become invalid. 1128 The responder performs this selective cancellation by sending a new 1129 response message, with the MESSAGE ID field containing the MESSAGE ID 1130 of the long-lived operation that is to be terminated (that it had 1131 previously acknowledged with a NOERROR RCODE), and the RCODE field of 1132 the new response message giving the reason for cancellation. 1134 After a response message with nonzero RCODE has been sent, that 1135 operation has been terminated from the responder's point of view, and 1136 the responder sends no more messages relating to that operation. 1138 After a response message with nonzero RCODE has been received by the 1139 initiator, that operation has been terminated from the initiator's 1140 point of view, and the cancelled operation's MESSAGE ID is now free 1141 for reuse. 1143 6. DSO Session Lifecycle and Timers 1145 6.1. DSO Session Initiation 1147 A DSO Session begins as described in Section 5.1. 1149 The client may perform as many DNS operations as it wishes using the 1150 newly created DSO Session. When the client has multiple messages to 1151 send, it SHOULD NOT wait for each response before sending the next 1152 message. 1154 The server MUST act on messages in the order they are received, but 1155 SHOULD NOT delay sending responses to those messages as they become 1156 available in order to return them in the order the requests were 1157 received. 1159 Section 6.2.1.1 of the DNS-over-TCP specification [RFC7766] specifies 1160 this in more detail. 1162 6.2. DSO Session Timeouts 1164 Two timeout values are associated with a DSO Session: the inactivity 1165 timeout, and the keepalive interval. Both values are communicated in 1166 the same TLV, the Keepalive TLV (Section 7.1). 1168 The first timeout value, the inactivity timeout, is the maximum time 1169 for which a client may speculatively keep an inactive DSO Session 1170 open in the expectation that it may have future requests to send to 1171 that server. 1173 The second timeout value, the keepalive interval, is the maximum 1174 permitted interval between messages if the client wishes to keep the 1175 DSO Session alive. 1177 The two timeout values are independent. The inactivity timeout may 1178 be lower, the same, or higher than the keepalive interval, though in 1179 most cases the inactivity timeout is expected to be shorter than the 1180 keepalive interval. 1182 A shorter inactivity timeout with a longer keepalive interval signals 1183 to the client that it should not speculatively keep an inactive DSO 1184 Session open for very long without reason, but when it does have an 1185 active reason to keep a DSO Session open, it doesn't need to be 1186 sending an aggressive level of DSO keepalive traffic to maintain that 1187 session. An example of this would be a client that has subscribed to 1188 DNS Push notifications: in this case, the client is not sending any 1189 traffic to the server, but the session is not inactive, because there 1190 is a active request to the server to receive push notifications. 1192 A longer inactivity timeout with a shorter keepalive interval signals 1193 to the client that it may speculatively keep an inactive DSO Session 1194 open for a long time, but to maintain that inactive DSO Session it 1195 should be sending a lot of DSO keepalive traffic. This configuration 1196 is expected to be less common. 1198 In the usual case where the inactivity timeout is shorter than the 1199 keepalive interval, it is only when a client has a long-lived, low- 1200 traffic, operation that the keepalive interval comes into play, to 1201 ensure that a sufficient residual amount of traffic is generated to 1202 maintain NAT and firewall state and to assure client and server that 1203 they still have connectivity to each other. 1205 On a new DSO Session, if no explicit DSO Keepalive message exchange 1206 has taken place, the default value for both timeouts is 15 seconds. 1208 For both timeouts, lower values of the timeout result in higher 1209 network traffic, and higher CPU load on the server. 1211 6.3. Inactive DSO Sessions 1213 At both servers and clients, the generation or reception of any 1214 complete DNS message (including DNS requests, responses, updates, DSO 1215 messages, etc.) resets both timers for that DSO Session, with the one 1216 exception that a DSO Keepalive message resets only the keepalive 1217 timer, not the inactivity timeout timer. 1219 In addition, for as long as the client has an outstanding operation 1220 in progress, the inactivity timer remains cleared, and an inactivity 1221 timeout cannot occur. 1223 For short-lived DNS operations like traditional queries and updates, 1224 an operation is considered in progress for the time between request 1225 and response, typically a period of a few hundred milliseconds at 1226 most. At the client, the inactivity timer is cleared upon 1227 transmission of a request and remains cleared until reception of the 1228 corresponding response. At the server, the inactivity timer is 1229 cleared upon reception of a request and remains cleared until 1230 transmission of the corresponding response. 1232 For long-lived DNS Stateful operations (such as a Push Notification 1233 subscription [I-D.ietf-dnssd-push] or a Discovery Relay interface 1234 subscription [I-D.ietf-dnssd-mdns-relay]), an operation is considered 1235 in progress for as long as the operation is active, i.e. until it is 1236 cancelled. This means that a DSO Session can exist, with active 1237 operations, with no messages flowing in either direction, for far 1238 longer than the inactivity timeout, and this is not an error. This 1239 is why there are two separate timers: the inactivity timeout, and the 1240 keepalive interval. Just because a DSO Session has no traffic for an 1241 extended period of time does not automatically make that DSO Session 1242 "inactive", if it has an active operation that is awaiting events. 1244 6.4. The Inactivity Timeout 1246 The purpose of the inactivity timeout is for the server to balance 1247 the trade off between the costs of setting up new DSO Sessions and 1248 the costs of maintaining inactive DSO Sessions. A server with 1249 abundant DSO Session capacity can offer a high inactivity timeout, to 1250 permit clients to keep a speculative DSO Session open for a long 1251 time, to save the cost of establishing a new DSO Session for future 1252 communications with that server. A server with scarce memory 1253 resources can offer a low inactivity timeout, to cause clients to 1254 promptly close DSO Sessions whenever they have no outstanding 1255 operations with that server, and then create a new DSO Session later 1256 when needed. 1258 6.4.1. Closing Inactive DSO Sessions 1260 When a connection's inactivity timeout is reached the client MUST 1261 begin closing the idle connection, but a client is not required to 1262 keep an idle connection open until the inactivity timeout is reached. 1263 A client MAY close a DSO Session at any time, at the client's 1264 discretion. If a client determines that it has no current or 1265 reasonably anticipated future need for a currently inactive DSO 1266 Session, then the client SHOULD gracefully close that connection. 1268 If, at any time during the life of the DSO Session, the inactivity 1269 timeout value (i.e., 15 seconds by default) elapses without there 1270 being any operation active on the DSO Session, the client MUST close 1271 the connection gracefully. 1273 If, at any time during the life of the DSO Session, twice the 1274 inactivity timeout value (i.e., 30 seconds by default), or five 1275 seconds, if twice the inactivity timeout value is less than five 1276 seconds, elapses without there being any operation active on the DSO 1277 Session, the server MUST consider the client delinquent, and MUST 1278 forcibly abort the DSO Session. 1280 In this context, an operation being active on a DSO Session includes 1281 a query waiting for a response, an update waiting for a response, or 1282 an active long-lived operation, but not a DSO Keepalive message 1283 exchange itself. A DSO Keepalive message exchange resets only the 1284 keepalive interval timer, not the inactivity timeout timer. 1286 If the client wishes to keep an inactive DSO Session open for longer 1287 than the default duration then it uses the DSO Keepalive message to 1288 request longer timeout values, as described in Section 7.1. 1290 6.4.2. Values for the Inactivity Timeout 1292 For the inactivity timeout value, lower values result in more 1293 frequent DSO Session teardown and re-establishment. Higher values 1294 result in lower traffic and lower CPU load on the server, but higher 1295 memory burden to maintain state for inactive DSO Sessions. 1297 A server may dictate any value it chooses for the inactivity timeout 1298 (either in a response to a client-initiated request, or in a server- 1299 initiated message) including values under one second, or even zero. 1301 An inactivity timeout of zero informs the client that it should not 1302 speculatively maintain idle connections at all, and as soon as the 1303 client has completed the operation or operations relating to this 1304 server, the client should immediately begin closing this session. 1306 A server will forcibly abort an idle client session after twice the 1307 inactivity timeout value, or five seconds, whichever is greater. In 1308 the case of a zero inactivity timeout value, this means that if a 1309 client fails to close an idle client session then the server will 1310 forcibly abort the idle session after five seconds. 1312 An inactivity timeout of 0xFFFFFFFF represents "infinity" and informs 1313 the client that it may keep an idle connection open as long as it 1314 wishes. Note that after granting an unlimited inactivity timeout in 1315 this way, at any point the server may revise that inactivity timeout 1316 by sending a new DSO Keepalive message dictating new Session Timeout 1317 values to the client. 1319 The largest *finite* inactivity timeout supported by the current 1320 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 1321 days). 1323 6.5. The Keepalive Interval 1325 The purpose of the keepalive interval is to manage the generation of 1326 sufficient messages to maintain state in middleboxes (such at NAT 1327 gateways or firewalls) and for the client and server to periodically 1328 verify that they still have connectivity to each other. This allows 1329 them to clean up state when connectivity is lost, and to establish a 1330 new session if appropriate. 1332 6.5.1. Keepalive Interval Expiry 1334 If, at any time during the life of the DSO Session, the keepalive 1335 interval value (i.e., 15 seconds by default) elapses without any DNS 1336 messages being sent or received on a DSO Session, the client MUST 1337 take action to keep the DSO Session alive, by sending a DSO Keepalive 1338 message (Section 7.1). A DSO Keepalive message exchange resets only 1339 the keepalive timer, not the inactivity timer. 1341 If a client disconnects from the network abruptly, without cleanly 1342 closing its DSO Session, perhaps leaving a long-lived operation 1343 uncancelled, the server learns of this after failing to receive the 1344 required DSO keepalive traffic from that client. If, at any time 1345 during the life of the DSO Session, twice the keepalive interval 1346 value (i.e., 30 seconds by default) elapses without any DNS messages 1347 being sent or received on a DSO Session, the server SHOULD consider 1348 the client delinquent, and SHOULD forcibly abort the DSO Session. 1350 6.5.2. Values for the Keepalive Interval 1352 For the keepalive interval value, lower values result in a higher 1353 volume of DSO keepalive traffic. Higher values of the keepalive 1354 interval reduce traffic and CPU load, but have minimal effect on the 1355 memory burden at the server, because clients keep a DSO Session open 1356 for the same length of time (determined by the inactivity timeout) 1357 regardless of the level of DSO keepalive traffic required. 1359 It may be appropriate for clients and servers to select different 1360 keepalive interval values depending on the nature of the network they 1361 are on. 1363 A corporate DNS server that knows it is serving only clients on the 1364 internal network, with no intervening NAT gateways or firewalls, can 1365 impose a higher keepalive interval, because frequent DSO keepalive 1366 traffic is not required. 1368 A public DNS server that is serving primarily residential consumer 1369 clients, where it is likely there will be a NAT gateway on the path, 1370 may impose a lower keepalive interval, to generate more frequent DSO 1371 keepalive traffic. 1373 A smart client may be adaptive to its environment. A client using a 1374 private IPv4 address [RFC1918] to communicate with a DNS server at an 1375 address outside that IPv4 private address block, may conclude that 1376 there is likely to be a NAT gateway on the path, and accordingly 1377 request a lower keepalive interval. 1379 By default it is RECOMMENDED that clients request, and servers grant, 1380 a keepalive interval of 60 minutes. This keepalive interval provides 1381 for reasonably timely detection if a client abruptly disconnects 1382 without cleanly closing the session, and is sufficient to maintain 1383 state in firewalls and NAT gateways that follow the IETF recommended 1384 Best Current Practice that the "established connection idle-timeout" 1385 used by middleboxes be at least 2 hours 4 minutes [RFC5382] 1386 [RFC7857]. 1388 Note that the lower the keepalive interval value, the higher the load 1389 on client and server. Moreover for a keep-alive value that is 1390 smaller than the time needed for the transport to retransmit, a 1391 single packet loss would cause a server to overzealously abort the 1392 connect. For example, a (hypothetical and unrealistic) keepalive 1393 interval value of 100 ms would result in a continuous stream of ten 1394 messages per second or more (if allowed by the current congestion 1395 control window), in both directions, to keep the DSO Session alive. 1396 And, in this extreme example, a single retransmission over a path 1397 with, e.g., 100ms RTT would introduce a momentary pause in the stream 1398 of messages, long enough to cause the server to abort the connection. 1400 Because of this concern, the server MUST NOT send a DSO Keepalive 1401 message (either a response to a client-initiated request, or a 1402 server-initiated message) with a keepalive interval value less than 1403 ten seconds. If a client receives a DSO Keepalive message specifying 1404 a keepalive interval value less than ten seconds this is a fatal 1405 error and the client MUST forcibly abort the connection immediately. 1407 A keepalive interval value of 0xFFFFFFFF represents "infinity" and 1408 informs the client that it should generate no DSO keepalive traffic. 1409 Note that after signaling that the client should generate no DSO 1410 keepalive traffic in this way, at any point the server may revise 1411 that DSO keepalive traffic requirement by sending a new DSO Keepalive 1412 message dictating new Session Timeout values to the client. 1414 The largest *finite* keepalive interval supported by the current 1415 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 1416 days). 1418 6.6. Server-Initiated Session Termination 1420 In addition to cancelling individual long-lived operations 1421 selectively (Section 5.6) there are also occasions where a server may 1422 need to terminate one or more entire sessions. An entire session may 1423 need to be terminated if the client is defective in some way, or 1424 departs from the network without closing its session. Sessions may 1425 also need to be terminated if the server becomes overloaded, or if 1426 the server is reconfigured and lacks the ability to be selective 1427 about which operations need to be cancelled. 1429 This section discusses various reasons a session may be terminated, 1430 and the mechanisms for doing so. 1432 In normal operation, closing a DSO Session is the client's 1433 responsibility. The client makes the determination of when to close 1434 a DSO Session based on an evaluation of both its own needs, and the 1435 inactivity timeout value dictated by the server. A server only 1436 causes a DSO Session to be ended in the exceptional circumstances 1437 outlined below. Some of the exceptional situations in which a server 1438 may terminate a DSO Session include: 1440 o The server application software or underlying operating system is 1441 shutting down or restarting. 1443 o The server application software terminates unexpectedly (perhaps 1444 due to a bug that makes it crash, causing the underlying operating 1445 system to send a TCP RST). 1447 o The server is undergoing a reconfiguration or maintenance 1448 procedure, that, due to the way the server software is 1449 implemented, requires clients to be disconnected. For example, 1450 some software is implemented such that it reads a configuration 1451 file at startup, and changing the server's configuration entails 1452 modifying the configuration file and then killing and restarting 1453 the server software, which generally entails a loss of network 1454 connections. 1456 o The client fails to meets its obligation to generate the required 1457 DSO keepalive traffic, or to close an inactive session by the 1458 prescribed time (twice the time interval dictated by the server, 1459 or five seconds, whichever is greater, as described in 1460 Section 6.2). 1462 o The client sends a grossly invalid or malformed request that is 1463 indicative of a seriously defective client implementation. 1465 o The server is over capacity and needs to shed some load. 1467 6.6.1. Server-Initiated Retry Delay Message 1469 In the cases described above where a server elects to terminate a DSO 1470 Session, it could do so simply by forcibly aborting the connection. 1471 However, if it did this the likely behavior of the client might be 1472 simply to to treat this as a network failure and reconnect 1473 immediately, putting more burden on the server. 1475 Therefore, to avoid this reconnection implosion, a server SHOULD 1476 instead choose to shed client load by sending a Retry Delay message, 1477 with an appropriate RCODE value informing the client of the reason 1478 the DSO Session needs to be terminated. The format of the Retry 1479 Delay TLV, and the interpretations of the various RCODE values, are 1480 described in Section 7.2. After sending a Retry Delay message, the 1481 server MUST NOT send any further messages on that DSO Session. 1483 The server MAY randomize retry delays in situations where many retry 1484 delays are sent in quick succession, so as to avoid all the clients 1485 attempting to reconnect at once. In general, implementations should 1486 avoid using the Retry Delay message in a way that would result in 1487 many clients reconnecting at the same time, if every client attempts 1488 to reconnect at the exact time specified. 1490 Upon receipt of a Retry Delay message from the server, the client 1491 MUST make note of the reconnect delay for this server, and then 1492 immediately close the connection gracefully. 1494 After sending a Retry Delay message the server SHOULD allow the 1495 client five seconds to close the connection, and if the client has 1496 not closed the connection after five seconds then the server SHOULD 1497 forcibly abort the connection. 1499 A Retry Delay message MUST NOT be initiated by a client. If a server 1500 receives a Retry Delay message this is a fatal error and the server 1501 MUST forcibly abort the connection immediately. 1503 6.6.1.1. Outstanding Operations 1505 At the instant a server chooses to initiate a Retry Delay message 1506 there may be DNS requests already in flight from client to server on 1507 this DSO Session, which will arrive at the server after its Retry 1508 Delay message has been sent. The server MUST silently ignore such 1509 incoming requests, and MUST NOT generate any response messages for 1510 them. When the Retry Delay message from the server arrives at the 1511 client, the client will determine that any DNS requests it previously 1512 sent on this DSO Session, that have not yet received a response, now 1513 will certainly not be receiving any response. Such requests should 1514 be considered failed, and should be retried at a later time, as 1515 appropriate. 1517 In the case where some, but not all, of the existing operations on a 1518 DSO Session have become invalid (perhaps because the server has been 1519 reconfigured and is no longer authoritative for some of the names), 1520 but the server is terminating all affected DSO Sessions en masse by 1521 sending them all a Retry Delay message, the reconnect delay MAY be 1522 zero, indicating that the clients SHOULD immediately attempt to re- 1523 establish operations. 1525 It is likely that some of the attempts will be successful and some 1526 will not, depending on the nature of the reconfiguration. 1528 In the case where a server is terminating a large number of DSO 1529 Sessions at once (e.g., if the system is restarting) and the server 1530 doesn't want to be inundated with a flood of simultaneous retries, it 1531 SHOULD send different reconnect delay values to each client. These 1532 adjustments MAY be selected randomly, pseudorandomly, or 1533 deterministically (e.g., incrementing the time value by one tenth of 1534 a second for each successive client, yielding a post-restart 1535 reconnection rate of ten clients per second). 1537 6.6.2. Misbehaving Clients 1539 A server may determine that a client is not following the protocol 1540 correctly. There may be no way for the server to recover the 1541 session, in which case the server forcibly terminates the connection. 1542 Since the client doesn't know why the connection dropped, it may 1543 reconnect immediately. If the server has determined that a client is 1544 not following the protocol correctly, it may terminate the DSO 1545 session as soon as it is established, specifying a long retry-delay 1546 to prevent the client from immediately reconnecting. 1548 6.6.3. Client Reconnection 1550 After a DSO Session is ended by the server (either by sending the 1551 client a Retry Delay message, or by forcibly aborting the underlying 1552 transport connection) the client SHOULD try to reconnect, to that 1553 service instance, or to another suitable service instance, if more 1554 than one is available. If reconnecting to the same service instance, 1555 the client MUST respect the indicated delay, if available, before 1556 attempting to reconnect. Clients should not attempt to randomize the 1557 delay; the server will randomly jitter the retry delay values it 1558 sends to each client if this behavior is desired. 1560 If the service instance will only be out of service for a short 1561 maintenance period, it should use a value a little longer that the 1562 expected maintenance window. It should not default to a very large 1563 delay value, or clients may not attempt to reconnect after it resumes 1564 service. 1566 If a particular service instance does not want a client to reconnect 1567 ever (perhaps the service instance is being de-commissioned), it 1568 SHOULD set the retry delay to the maximum value 0xFFFFFFFF (2^32-1 1569 milliseconds, approximately 49.7 days). It is not possible to 1570 instruct a client to stay away for longer than 49.7 days. If, after 1571 49.7 days, the DNS or other configuration information still indicates 1572 that this is the valid service instance for a particular service, 1573 then clients MAY attempt to reconnect. In reality, if a client is 1574 rebooted or otherwise lose state, it may well attempt to reconnect 1575 before 49.7 days elapses, for as long as the DNS or other 1576 configuration information continues to indicate that this is the 1577 service instance the client should use. 1579 6.6.3.1. Reconnecting After a Forcible Abort 1581 If a connection was forcibly aborted by the client, the client SHOULD 1582 mark that service instance as not supporting DSO. The client MAY 1583 reconnect but not attempt to use DSO, or may connect to a different 1584 service instance, if applicable. 1586 6.6.3.2. Reconnecting After an Unexplained Connection Drop 1588 It is also possible for a server to forcibly terminate the 1589 connection; in this case the client doesn't know whether the 1590 termination was the result of a protocol error or a network outage. 1591 When the client notices that the connection has been dropped, it can 1592 attempt to reconnect immediately. However, if the connection is 1593 dropped again without the client being able to successfully do 1594 whatever it is trying to do, it should mark the server as not 1595 supporting DSO. 1597 6.6.3.3. Probing for Working DSO Support 1599 Once a server has been marked by the client as not supporting DSO, 1600 the client SHOULD NOT attempt DSO operations on that server until 1601 some time has elapsed. A reasonable minimum would be an hour. Since 1602 forcibly aborted connections are the result of a software failure, 1603 it's not likely that the problem will be solved in the first hour 1604 after it's first encountered. However, by restricting the retry 1605 interval to an hour, the client will be able to notice when the 1606 problem has been fixed without placing an undue burden on the server. 1608 7. Base TLVs for DNS Stateful Operations 1610 This section describes the three base TLVs for DNS Stateful 1611 Operations: Keepalive, Retry Delay, and Encryption Padding. 1613 7.1. Keepalive TLV 1615 The Keepalive TLV (DSO-TYPE=1) performs two functions. Primarily it 1616 establishes the values for the Session Timeouts. Incidentally, it 1617 also resets the keepalive timer for the DSO Session, meaning that it 1618 can be used as a kind of "no-op" message for the purpose of keeping a 1619 session alive. The client will request the desired session timeout 1620 values and the server will acknowledge with the response values that 1621 it requires the client to use. 1623 DSO messages with the Keepalive TLV as the primary TLV may appear in 1624 early data. 1626 The DSO-DATA for the Keepalive TLV is as follows: 1628 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1629 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 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | INACTIVITY TIMEOUT (32 bits) | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | KEEPALIVE INTERVAL (32 bits) | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 INACTIVITY TIMEOUT: The inactivity timeout for the current DSO 1637 Session, specified as a 32-bit unsigned integer, in network (big 1638 endian) byte order, in units of milliseconds. This is the timeout 1639 at which the client MUST begin closing an inactive DSO Session. 1640 The inactivity timeout can be any value of the server's choosing. 1641 If the client does not gracefully close an inactive DSO Session, 1642 then after twice this interval, or five seconds, whichever is 1643 greater, the server will forcibly abort the connection. 1645 KEEPALIVE INTERVAL: The keepalive interval for the current DSO 1646 Session, specified as a 32-bit unsigned integer, in network (big 1647 endian) byte order, in units of milliseconds. This is the 1648 interval at which a client MUST generate DSO keepalive traffic to 1649 maintain connection state. The keepalive interval MUST NOT be 1650 less than ten seconds. If the client does not generate the 1651 mandated DSO keepalive traffic, then after twice this interval the 1652 server will forcibly abort the connection. Since the minimum 1653 allowed keepalive interval is ten seconds, the minimum time at 1654 which a server will forcibly disconnect a client for failing to 1655 generate the mandated DSO keepalive traffic is twenty seconds. 1657 The transmission or reception of DSO Keepalive messages (i.e., 1658 messages where the Keepalive TLV is the first TLV) reset only the 1659 keepalive timer, not the inactivity timer. The reason for this is 1660 that periodic DSO Keepalive messages are sent for the sole purpose of 1661 keeping a DSO Session alive, when that DSO Session has current or 1662 recent non-maintenance activity that warrants keeping that DSO 1663 Session alive. Sending DSO keepalive traffic itself is not 1664 considered a client activity; it is considered a maintenance activity 1665 that is performed in service of other client activities. If DSO 1666 keepalive traffic itself were to reset the inactivity timer, then 1667 that would create a circular livelock where keepalive traffic would 1668 be sent indefinitely to keep a DSO Session alive, where the only 1669 activity on that DSO Session would be the keepalive traffic keeping 1670 the DSO Session alive so that further keepalive traffic can be sent. 1671 For a DSO Session to be considered active, it must be carrying 1672 something more than just keepalive traffic. This is why merely 1673 sending or receiving a DSO Keepalive message does not reset the 1674 inactivity timer. 1676 When sent by a client, the DSO Keepalive request message MUST be sent 1677 as an DSO request message, with a nonzero MESSAGE ID. If a server 1678 receives a DSO Keepalive message with a zero MESSAGE ID then this is 1679 a fatal error and the server MUST forcibly abort the connection 1680 immediately. The DSO Keepalive request message resets a DSO 1681 Session's keepalive timer, and at the same time communicates to the 1682 server the client's requested Session Timeout values. In a server 1683 response to a client-initiated DSO Keepalive request message, the 1684 Session Timeouts contain the server's chosen values from this point 1685 forward in the DSO Session, which the client MUST respect. This is 1686 modeled after the DHCP protocol, where the client requests a certain 1687 lease lifetime using DHCP option 51 [RFC2132], but the server is the 1688 ultimate authority for deciding what lease lifetime is actually 1689 granted. 1691 When a client is sending its second and subsequent DSO Keepalive 1692 request messages to the server, the client SHOULD continue to request 1693 its preferred values each time. This allows flexibility, so that if 1694 conditions change during the lifetime of a DSO Session, the server 1695 can adapt its responses to better fit the client's needs. 1697 Once a DSO Session is in progress (Section 5.1) a DSO Keepalive 1698 message MAY be initiated by a server. When sent by a server, the DSO 1699 Keepalive message MUST be sent as a DSO unidirectional message, with 1700 the MESSAGE ID set to zero. The client MUST NOT generate a response 1701 to a server-initiated DSO Keepalive message. If a client receives a 1702 DSO Keepalive request message with a nonzero MESSAGE ID then this is 1703 a fatal error and the client MUST forcibly abort the connection 1704 immediately. The DSO Keepalive unidirectional message from the 1705 server resets a DSO Session's keepalive timer, and at the same time 1706 unilaterally informs the client of the new Session Timeout values to 1707 use from this point forward in this DSO Session. No client DSO 1708 response to this unilateral declaration is required or allowed. 1710 In DSO Keepalive response messages, the Keepalive TLV is REQUIRED and 1711 is used only as a Response Primary TLV sent as a reply to a DSO 1712 Keepalive request message from the client. A Keepalive TLV MUST NOT 1713 be added to other responses as a Response Additional TLV. If the 1714 server wishes to update a client's Session Timeout values other than 1715 in response to a DSO Keepalive request message from the client, then 1716 it does so by sending an DSO Keepalive unidirectional message of its 1717 own, as described above. 1719 It is not required that the Keepalive TLV be used in every DSO 1720 Session. While many DNS Stateful operations will be used in 1721 conjunction with a long-lived session state, not all DNS Stateful 1722 operations require long-lived session state, and in some cases the 1723 default 15-second value for both the inactivity timeout and keepalive 1724 interval may be perfectly appropriate. However, note that for 1725 clients that implement only the DSO-TYPEs defined in this document, a 1726 DSO Keepalive request message is the only way for a client to 1727 initiate a DSO Session. 1729 7.1.1. Client handling of received Session Timeout values 1731 When a client receives a response to its client-initiated DSO 1732 Keepalive message, or receives a server-initiated DSO Keepalive 1733 message, the client has then received Session Timeout values dictated 1734 by the server. The two timeout values contained in the Keepalive TLV 1735 from the server may each be higher, lower, or the same as the 1736 respective Session Timeout values the client previously had for this 1737 DSO Session. 1739 In the case of the keepalive timer, the handling of the received 1740 value is straightforward. The act of receiving the message 1741 containing the DSO Keepalive TLV itself resets the keepalive timer, 1742 and updates the keepalive interval for the DSO Session. The new 1743 keepalive interval indicates the maximum time that may elapse before 1744 another message must be sent or received on this DSO Session, if the 1745 DSO Session is to remain alive. 1747 In the case of the inactivity timeout, the handling of the received 1748 value is a little more subtle, though the meaning of the inactivity 1749 timeout remains as specified -- it still indicates the maximum 1750 permissible time allowed without useful activity on a DSO Session. 1751 The act of receiving the message containing the Keepalive TLV does 1752 not itself reset the inactivity timer. The time elapsed since the 1753 last useful activity on this DSO Session is unaffected by exchange of 1754 DSO Keepalive messages. The new inactivity timeout value in the 1755 Keepalive TLV in the received message does update the timeout 1756 associated with the running inactivity timer; that becomes the new 1757 maximum permissible time without activity on a DSO Session. 1759 o If the current inactivity timer value is less than the new 1760 inactivity timeout, then the DSO Session may remain open for now. 1761 When the inactivity timer value reaches the new inactivity 1762 timeout, the client MUST then begin closing the DSO Session, as 1763 described above. 1765 o If the current inactivity timer value is equal to the new 1766 inactivity timeout, then this DSO Session has been inactive for 1767 exactly as long as the server will permit, and now the client MUST 1768 immediately begin closing this DSO Session. 1770 o If the current inactivity timer value is already greater than the 1771 new inactivity timeout, then this DSO Session has already been 1772 inactive for longer than the server permits, and the client MUST 1773 immediately begin closing this DSO Session. 1775 o If the current inactivity timer value is already more than twice 1776 the new inactivity timeout, then the client is immediately 1777 considered delinquent (this DSO Session is immediately eligible to 1778 be forcibly terminated by the server) and the client MUST 1779 immediately begin closing this DSO Session. However if a server 1780 abruptly reduces the inactivity timeout in this way, then, to give 1781 the client time to close the connection gracefully before the 1782 server resorts to forcibly aborting it, the server SHOULD give the 1783 client an additional grace period of one quarter of the new 1784 inactivity timeout, or five seconds, whichever is greater. 1786 7.1.2. Relationship to edns-tcp-keepalive EDNS0 Option 1788 The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has 1789 similar intent to the edns-tcp-keepalive EDNS0 Option [RFC7828]. A 1790 client/server pair that supports DSO MUST NOT use the edns-tcp- 1791 keepalive EDNS0 Option within any message after a DSO Session has 1792 been established. A client that has sent a DSO message to establish 1793 a session MUST NOT send an edns-tcp-keepalive EDNS0 Option from this 1794 point on. Once a DSO Session has been established, if either client 1795 or server receives a DNS message over the DSO Session that contains 1796 an edns-tcp-keepalive EDNS0 Option, this is a fatal error and the 1797 receiver of the edns-tcp-keepalive EDNS0 Option MUST forcibly abort 1798 the connection immediately. 1800 7.2. Retry Delay TLV 1802 The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary TLV 1803 (unidirectional) in a server-to-client message, or as a Response 1804 Additional TLV in either direction. DSO messages with a Relay Delay 1805 TLV as their primary TLV are not permitted in early data. 1807 The DSO-DATA for the Retry Delay TLV is as follows: 1809 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1810 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 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | RETRY DELAY (32 bits) | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 RETRY DELAY: A time value, specified as a 32-bit unsigned integer, 1816 in network (big endian) byte order, in units of milliseconds, 1817 within which the initiator MUST NOT retry this operation, or retry 1818 connecting to this server. Recommendations for the RETRY DELAY 1819 value are given in Section 6.6.1. 1821 7.2.1. Retry Delay TLV used as a Primary TLV 1823 When sent from server to client, the Retry Delay TLV is used as the 1824 Primary TLV in a DSO unidirectional message. It is used by a server 1825 to instruct a client to close the DSO Session and underlying 1826 connection, and not to reconnect for the indicated time interval. 1828 In this case it applies to the DSO Session as a whole, and the client 1829 MUST begin closing the DSO Session, as described in Section 6.6.1. 1830 The RCODE in the message header SHOULD indicate the principal reason 1831 for the termination: 1833 o NOERROR indicates a routine shutdown or restart. 1835 o FORMERR indicates that a client request was too badly malformed 1836 for the session to continue. 1838 o SERVFAIL indicates that the server is overloaded due to resource 1839 exhaustion and needs to shed load. 1841 o REFUSED indicates that the server has been reconfigured, and at 1842 this time it is now unable to perform one or more of the long- 1843 lived client operations that were previously being performed on 1844 this DSO Session. 1846 o NOTAUTH indicates that the server has been reconfigured and at 1847 this time it is now unable to perform one or more of the long- 1848 lived client operations that were previously being performed on 1849 this DSO Session because it does not have authority over the names 1850 in question (for example, a DNS Push Notification server could be 1851 reconfigured such that is is no longer accepting DNS Push 1852 Notification requests for one or more of the currently subscribed 1853 names). 1855 This document specifies only these RCODE values for the Retry Delay 1856 message. Servers sending Retry Delay messages SHOULD use one of 1857 these values. However, future circumstances may create situations 1858 where other RCODE values are appropriate in Retry Delay messages, so 1859 clients MUST be prepared to accept Retry Delay messages with any 1860 RCODE value. 1862 In some cases, when a server sends a Retry Delay message to a client, 1863 there may be more than one reason for the server wanting to end the 1864 session. Possibly the configuration could have been changed such 1865 that some long-lived client operations can no longer be continued due 1866 to policy (REFUSED), and other long-lived client operations can no 1867 longer be performed due to the server no longer being authoritative 1868 for those names (NOTAUTH). In such cases the server MAY use any of 1869 the applicable RCODE values, or RCODE=NOERROR (routine shutdown or 1870 restart). 1872 Note that the selection of RCODE value in a Retry Delay message is 1873 not critical, since the RCODE value is generally used only for 1874 information purposes, such as writing to a log file for future human 1875 analysis regarding the nature of the disconnection. Generally 1876 clients do not modify their behavior depending on the RCODE value. 1877 The RETRY DELAY in the message tells the client how long it should 1878 wait before attempting a new connection to this service instance. 1880 For clients that do in some way modify their behavior depending on 1881 the RCODE value, they should treat unknown RCODE values the same as 1882 RCODE=NOERROR (routine shutdown or restart). 1884 A Retry Delay message from server to client is a DSO unidirectional 1885 message; the MESSAGE ID MUST be set to zero in the outgoing message 1886 and the client MUST NOT send a response. 1888 A client MUST NOT send a Retry Delay DSO message to a server. If a 1889 server receives a DSO message where the Primary TLV is the Retry 1890 Delay TLV, this is a fatal error and the server MUST forcibly abort 1891 the connection immediately. 1893 7.2.2. Retry Delay TLV used as a Response Additional TLV 1895 In the case of a DSO request message that results in a nonzero RCODE 1896 value, the responder MAY append a Retry Delay TLV to the response, 1897 indicating the time interval during which the initiator SHOULD NOT 1898 attempt this operation again. 1900 The indicated time interval during which the initiator SHOULD NOT 1901 retry applies only to the failed operation, not to the DSO Session as 1902 a whole. 1904 7.3. Encryption Padding TLV 1906 The Encryption Padding TLV (DSO-TYPE=3) can only be used as an 1907 Additional or Response Additional TLV. It is only applicable when 1908 the DSO Transport layer uses encryption such as TLS. 1910 The DSO-DATA for the Padding TLV is optional and is a variable length 1911 field containing non-specified values. A DSO-LENGTH of 0 essentially 1912 provides for 4 bytes of padding (the minimum amount). 1914 1 1 1 1 1 1 1915 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1916 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1917 / / 1918 / PADDING -- VARIABLE NUMBER OF BYTES / 1919 / / 1920 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1922 As specified for the EDNS(0) Padding Option [RFC7830] the PADDING 1923 bytes SHOULD be set to 0x00. Other values MAY be used, for example, 1924 in cases where there is a concern that the padded message could be 1925 subject to compression before encryption. PADDING bytes of any value 1926 MUST be accepted in the messages received. 1928 The Encryption Padding TLV may be included in either a DSO request 1929 message, response, or both. As specified for the EDNS(0) Padding 1930 Option [RFC7830] if a DSO request message is received with an 1931 Encryption Padding TLV, then the DSO response MUST also include an 1932 Encryption Padding TLV. 1934 The length of padding is intentionally not specified in this document 1935 and is a function of current best practices with respect to the type 1936 and length of data in the preceding TLVs 1937 [I-D.ietf-dprive-padding-policy]. 1939 8. Summary Highlights 1941 This section summarizes some noteworthy highlights about various 1942 aspects of the DSO protocol. 1944 8.1. QR bit and MESSAGE ID 1946 In DSO Request Messages the QR bit is 0 and the MESSAGE ID is 1947 nonzero. 1949 In DSO Response Messages the QR bit is 1 and the MESSAGE ID is 1950 nonzero. 1952 In DSO Unidirectional Messages the QR bit is 0 and the MESSAGE ID is 1953 zero. 1955 The table below illustrates which combinations are legal and how they 1956 are interpreted: 1958 +------------------------------+------------------------+ 1959 | MESSAGE ID zero | MESSAGE ID nonzero | 1960 +--------+------------------------------+------------------------+ 1961 | QR=0 | DSO unidirectional Message | DSO Request Message | 1962 +--------+------------------------------+------------------------+ 1963 | QR=1 | Invalid - Fatal Error | DSO Response Message | 1964 +--------+------------------------------+------------------------+ 1966 8.2. TLV Usage 1968 The table below indicates, for each of the three TLVs defined in this 1969 document, whether they are valid in each of ten different contexts. 1971 The first five contexts are DSO requests or DSO unidirectional 1972 messages from client to server, and the corresponding responses from 1973 server back to client: 1975 o C-P - Primary TLV, sent in DSO Request message, from client to 1976 server, with nonzero MESSAGE ID indicating that this request MUST 1977 generate response message. 1979 o C-U - Primary TLV, sent in DSO Unidirectional message, from client 1980 to server, with zero MESSAGE ID indicating that this request MUST 1981 NOT generate response message. 1983 o C-A - Additional TLV, optionally added to a DSO request message or 1984 DSO unidirectional message from client to server. 1986 o CRP - Response Primary TLV, included in response message sent back 1987 to the client (in response to a client "C-P" request with nonzero 1988 MESSAGE ID indicating that a response is required) where the DSO- 1989 TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV 1990 in the request. 1992 o CRA - Response Additional TLV, included in response message sent 1993 back to the client (in response to a client "C-P" request with 1994 nonzero MESSAGE ID indicating that a response is required) where 1995 the DSO-TYPE of the Response TLV does not match the DSO-TYPE of 1996 the Primary TLV in the request. 1998 The second five contexts are their counterparts in the opposite 1999 direction: DSO requests or DSO unidirectional messages from server to 2000 client, and the corresponding responses from client back to server. 2002 o S-P - Primary TLV, sent in DSO Request message, from server to 2003 client, with nonzero MESSAGE ID indicating that this request MUST 2004 generate response message. 2006 o S-U - Primary TLV, sent in DSO Unidirectional message, from server 2007 to client, with zero MESSAGE ID indicating that this request MUST 2008 NOT generate response message. 2010 o S-A - Additional TLV, optionally added to a DSO request message or 2011 DSO unidirectional message from server to client. 2013 o SRP - Response Primary TLV, included in response message sent back 2014 to the server (in response to a server "S-P" request with nonzero 2015 MESSAGE ID indicating that a response is required) where the DSO- 2016 TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV 2017 in the request. 2019 o SRA - Response Additional TLV, included in response message sent 2020 back to the server (in response to a server "S-P" request with 2021 nonzero MESSAGE ID indicating that a response is required) where 2022 the DSO-TYPE of the Response TLV does not match the DSO-TYPE of 2023 the Primary TLV in the request. 2025 +-------------------------+-------------------------+ 2026 | C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA | 2027 +------------+-------------------------+-------------------------+ 2028 | KeepAlive | X X | X | 2029 +------------+-------------------------+-------------------------+ 2030 | RetryDelay | X | X X | 2031 +------------+-------------------------+-------------------------+ 2032 | Padding | X X | X X | 2033 +------------+-------------------------+-------------------------+ 2035 Note that some of the columns in this table are currently empty. The 2036 table provides a template for future TLV definitions to follow. It 2037 is recommended that definitions of future TLVs include a similar 2038 table summarizing the contexts where the new TLV is valid. 2040 9. Additional Considerations 2042 9.1. Service Instances 2044 We use the term service instance to refer to software running on a 2045 host which can receive connections on some set of IP address and port 2046 tuples. What makes the software an instance is that regardless of 2047 which of these tuples the client uses to connect to it, the client is 2048 connected to the same software, running on the same node (but see 2049 Section 9.2), and will receive the same answers and the same keying 2050 information. 2052 Service instances are identified from the perspective of the client. 2053 If the client is configured with IP addresses and port number tuples, 2054 it has no way to tell if the service offered at one tuple is the same 2055 server that is listening on a different tuple. So in this case, the 2056 client treats each such tuple as if it references a separate service 2057 instance. 2059 In some cases a client is configured with a hostname and a port 2060 number (either implicitly, where the port number is omitted and 2061 assumed, or explicitly, as in the case of DNS SRV records). In these 2062 cases, the (hostname, port) tuple uniquely identifies the service 2063 instance (hostname comparisons are case-insensitive [RFC1034]. 2065 It is possible that two hostnames might point to some common IP 2066 addresses; this is a configuration error which the client is not 2067 obliged to detect. The effect of this could be that after being told 2068 to disconnect, the client might reconnect to the same server because 2069 it is represented as a different service instance. 2071 Implementations SHOULD NOT resolve hostnames and then perform 2072 matching of IP address(es) in order to evaluate whether two entities 2073 should be determined to be the "same service instance". 2075 9.2. Anycast Considerations 2077 When an anycast service is configured on a particular IP address and 2078 port, it must be the case that although there is more than one 2079 physical server responding on that IP address, each such server can 2080 be treated as equivalent. What we mean by "equivalent" here is that 2081 both servers can provide the same service and, where appropriate, the 2082 same authentication information, such as PKI certificates, when 2083 establishing connections. 2085 If a change in network topology causes packets in a particular TCP 2086 connection to be sent to an anycast server instance that does not 2087 know about the connection, the new server will automatically 2088 terminate the connection with a TCP reset, since it will have no 2089 record of the connection, and then the client can reconnect or stop 2090 using the connection, as appropriate. 2092 If after the connection is re-established, the client's assumption 2093 that it is connected to the same service is violated in some way, 2094 that would be considered to be incorrect behavior in this context. 2095 It is however out of the possible scope for this specification to 2096 make specific recommendations in this regard; that would be up to 2097 follow-on documents that describe specific uses of DNS stateful 2098 operations. 2100 9.3. Connection Sharing 2102 As previously specified for DNS over TCP [RFC7766]: 2104 To mitigate the risk of unintentional server overload, DNS 2105 clients MUST take care to minimize the number of concurrent 2106 TCP connections made to any individual server. It is RECOMMENDED 2107 that for any given client/server interaction there SHOULD be 2108 no more than one connection for regular queries, one for zone 2109 transfers, and one for each protocol that is being used on top 2110 of TCP (for example, if the resolver was using TLS). However, 2111 it is noted that certain primary/secondary configurations 2112 with many busy zones might need to use more than one TCP 2113 connection for zone transfers for operational reasons (for 2114 example, to support concurrent transfers of multiple zones). 2116 A single server may support multiple services, including DNS Updates 2117 [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other 2118 services, for one or more DNS zones. When a client discovers that 2119 the target server for several different operations is the same 2120 service instance (see Section 9.1), the client SHOULD use a single 2121 shared DSO Session for all those operations. 2123 This requirement has two benefits. First, it reduces unnecessary 2124 connection load on the DNS server. Second, it avoids paying the TCP 2125 slow start penalty when making subsequent connections to the same 2126 server. 2128 However, server implementers and operators should be aware that 2129 connection sharing may not be possible in all cases. A single host 2130 device may be home to multiple independent client software instances 2131 that don't coordinate with each other. Similarly, multiple 2132 independent client devices behind the same NAT gateway will also 2133 typically appear to the DNS server as different source ports on the 2134 same client IP address. Because of these constraints, a DNS server 2135 MUST be prepared to accept multiple connections from different source 2136 ports on the same client IP address. 2138 9.4. Operational Considerations for Middlebox 2140 Where an application-layer middlebox (e.g., a DNS proxy, forwarder, 2141 or session multiplexer) is in the path, care must be taken to avoid a 2142 configuration in which DSO traffic is mis-handled. The simplest way 2143 to avoid such problems is to avoid using middleboxes. When this is 2144 not possible, middleboxes should be evaluated to make sure that they 2145 behave correctly. 2147 Correct behavior for middleboxes consists of one of: 2149 o The middlebox does not forward DSO messages, and responds to DSO 2150 messages with a response code other than NOERROR or DSOTYPENI. 2152 o The middlebox acts as a DSO server and follows this specification 2153 in establishing connections. 2155 o There is a 1:1 correspondence between incoming and outgoing 2156 connections, such that when a connection is established to the 2157 middlebox, it is guaranteed that exactly one corresponding 2158 connection will be established from the middlebox to some DNS 2159 resolver, and all incoming messages will be forwarded without 2160 modification or reordering. An example of this would be a NAT 2161 forwarder or TCP connection optimizer (e.g. for a high-latency 2162 connection such as a geosynchronous satellite link). 2164 Middleboxes that do not meet one of the above criteria are very 2165 likely to fail in unexpected and difficult-to-diagnose ways. For 2166 example, a DNS load balancer might unbundle DNS messages from the 2167 incoming TCP stream and forward each message from the stream to a 2168 different DNS server. If such a load balancer is in use, and the DNS 2169 servers it points implement DSO and are configured to enable DSO, DSO 2170 session establishment will succeed, but no coherent session will 2171 exist between the client and the server. If such a load balancer is 2172 pointed at a DNS server that does not implement DSO or is configured 2173 not to allow DSO, no such problem will exist, but such a 2174 configuration risks unexpected failure if new server software is 2175 installed which does implement DSO. 2177 It is of course possible to implement a middlebox that properly 2178 supports DSO. It is even possible to implement one that implements 2179 DSO with long-lived operations. This can be done either by 2180 maintaining a 1:1 correspondence between incoming and outgoing 2181 connections, as mentioned above, or by terminating incoming sessions 2182 at the middlebox, but maintaining state in the middlebox about any 2183 long-lived that are requested. Specifying this in detail is beyond 2184 the scope of this document. 2186 9.5. TCP Delayed Acknowledgement Considerations 2188 Most modern implementations of the Transmission Control Protocol 2189 (TCP) include a feature called "Delayed Acknowledgement" [RFC1122]. 2191 Without this feature, TCP can be very wasteful on the network. For 2192 illustration, consider a simple example like remote login, using a 2193 very simple TCP implementation that lacks delayed acks. When the 2194 user types a keystroke, a data packet is sent. When the data packet 2195 arrives at the server, the simple TCP implementation sends an 2196 immediate acknowledgement. Mere milliseconds later, the server 2197 process reads the one byte of keystroke data, and consequently the 2198 simple TCP implementation sends an immediate window update. Mere 2199 milliseconds later, the server process generates the character echo, 2200 and sends this data back in reply. The simple TCP implementation 2201 then sends this data packet immediately too. In this case, this 2202 simple TCP implementation sends a burst of three packets almost 2203 instantaneously (ack, window update, data). 2205 Clearly it would be more efficient if the TCP implementation were to 2206 combine the three separate packets into one, and this is what the 2207 delayed ack feature enables. 2209 With delayed ack, the TCP implementation waits after receiving a data 2210 packet, typically for 200 ms, and then send its ack if (a) more data 2211 packet(s) arrive (b) the receiving process generates some reply data, 2212 or (c) 200 ms elapses without either of the above occurring. 2214 With delayed ack, remote login becomes much more efficient, 2215 generating just one packet instead of three for each character echo. 2217 The logic of delayed ack is that the 200 ms delay cannot do any 2218 significant harm. If something at the other end were waiting for 2219 something, then the receiving process should generate the reply that 2220 the thing at the end is waiting for, and TCP will then immediately 2221 send that reply (and the ack and window update). And if the 2222 receiving process does not in fact generate any reply for this 2223 particular message, then by definition the thing at the other end 2224 cannot be waiting for anything, so the 200 ms delay is harmless. 2226 This assumption may be true, unless the sender is using Nagle's 2227 algorithm, a similar efficiency feature, created to protect the 2228 network from poorly written client software that performs many rapid 2229 small writes in succession. Nagle's algorithm allows these small 2230 writes to be combined into larger, less wasteful packets. 2232 Unfortunately, Nagle's algorithm and delayed ack, two valuable 2233 efficiency features, can interact badly with each other when used 2234 together [NagleDA]. 2236 DSO request messages elicit responses; DSO unidirectional messages 2237 and DSO response messages do not. 2239 For DSO request messages, which do elicit responses, Nagle's 2240 algorithm and delayed ack work as intended. 2242 For DSO messages that do not elicit responses, the delayed ack 2243 mechanism causes the ack to be delayed by 200 ms. The 200 ms delay 2244 on the ack can in turn cause Nagle's algorithm to prevent the sender 2245 from sending any more data for 200 ms until the awaited ack arrives. 2246 On an enterprise GigE backbone with sub-millisecond round-trip times, 2247 a 200 ms delay is enormous in comparison. 2249 When this issues is raised, there are two solutions that are often 2250 offered, neither of them ideal: 2252 1. Disable delayed ack. For DSO messages that elicit no response, 2253 removing delayed ack avoids the needless 200 ms delay, and sends 2254 back an immediate ack, which tells Nagle's algorithm that it 2255 should immediately grant the sender permission to send its next 2256 packet. Unfortunately, for DSO messages that *do* elicit a 2257 response, removing delayed ack removes the efficiency gains of 2258 combining acks with data, and the responder will now send two or 2259 three packets instead of one. 2261 2. Disable Nagle's algorithm. When acks are delayed by the delayed 2262 ack algorithm, removing Nagle's algorithm prevents the sender 2263 from being blocked from sending its next small packet 2264 immediately. Unfortunately, on a network with a higher round- 2265 trip time, removing Nagle's algorithm removes the efficiency 2266 gains of combining multiple small packets into fewer larger ones, 2267 with the goal of limiting the number of small packets in flight 2268 at any one time. 2270 For DSO messages that elicit a response, delayed ack and Nagle's 2271 algorithm do the right thing. 2273 The problem here is that with DSO messages that elicit no response, 2274 the TCP implementation is stuck waiting, unsure if a response is 2275 about to be generated, or whether the TCP implementation should go 2276 ahead and send an ack and window update. 2278 The solution is networking APIs that allow the receiver to inform the 2279 TCP implementation that a received message has been read, processed, 2280 and no response for this message will be generated. TCP can then 2281 stop waiting for a response that will never come, and immediately go 2282 ahead and send an ack and window update. 2284 For implementations of DSO, disabling delayed ack is NOT RECOMMENDED, 2285 because of the harm this can do to the network. 2287 For implementations of DSO, disabling Nagle's algorithm is NOT 2288 RECOMMENDED, because of the harm this can do to the network. 2290 At the time that this document is being prepared for publication, it 2291 is known that at least one TCP implementation provides the ability 2292 for the recipient of a TCP message to signal that it is not going to 2293 send a response, and hence the delayed ack mechanism can stop 2294 waiting. Implementations on operating systems where this feature is 2295 available SHOULD make use of it. 2297 10. IANA Considerations 2299 10.1. DSO OPCODE Registration 2301 The IANA is requested to record the value [TBA1] (tentatively 6) for 2302 the DSO OPCODE in the DNS OPCODE Registry. DSO stands for DNS 2303 Stateful Operations. 2305 10.2. DSO RCODE Registration 2307 The IANA is requested to record the value [TBA2] (tentatively 11) for 2308 the DSOTYPENI error code in the DNS RCODE Registry. The DSOTYPENI 2309 error code ("DSO-TYPE Not Implemented") indicates that the receiver 2310 does implement DNS Stateful Operations, but does not implement the 2311 specific DSO-TYPE of the primary TLV in the DSO request message. 2313 10.3. DSO Type Code Registry 2315 The IANA is requested to create the 16-bit DSO Type Code Registry, 2316 with initial (hexadecimal) values as shown below: 2318 +-----------+------------------------+-------+----------+-----------+ 2319 | Type | Name | Early | Status | Reference | 2320 | | | Data | | | 2321 +-----------+------------------------+-------+----------+-----------+ 2322 | 0000 | Reserved | NO | Standard | RFC-TBD | 2323 | | | | | | 2324 | 0001 | KeepAlive | OK | Standard | RFC-TBD | 2325 | | | | | | 2326 | 0002 | RetryDelay | NO | Standard | RFC-TBD | 2327 | | | | | | 2328 | 0003 | EncryptionPadding | NA | Standard | RFC-TBD | 2329 | | | | | | 2330 | 0004-003F | Unassigned, reserved | NO | | | 2331 | | for DSO session- | | | | 2332 | | management TLVs | | | | 2333 | | | | | | 2334 | 0040-F7FF | Unassigned | NO | | | 2335 | | | | | | 2336 | F800-FBFF | Experimental/local use | NO | | | 2337 | | | | | | 2338 | FC00-FFFF | Reserved for future | NO | | | 2339 | | expansion | | | | 2340 +-----------+------------------------+-------+----------+-----------+ 2342 The meanings of the fields are as follows: 2344 Type: the 16-bit DSO type code 2345 Name: the human-readable name of the TLV 2347 Early Data: If OK, this TLV may be sent as early data in a TLS 0-RTT 2348 ([RFC8446] Section 2.3) initial handshake. If NA, the TLV may 2349 appear as a secondary TLV in a DSO message that is send as early 2350 data. 2352 Status: IETF Document status (or "External" if not documented in an 2353 IETF document. 2355 Reference: A stable reference to the document in which this TLV is 2356 defined. 2358 DSO Type Code zero is reserved and is not currently intended for 2359 allocation. 2361 Registrations of new DSO Type Codes in the "Reserved for DSO session- 2362 management" range 0004-003F and the "Reserved for future expansion" 2363 range FC00-FFFF require publication of an IETF Standards Action 2364 document [RFC8126]. 2366 Any document defining a new TLV which lists a value of "OK" in the 2367 0-RTT column must include a threat analysis for the use of the TLV in 2368 the case of TLS 0-RTT. See Section 11.1 for details. 2370 Requests to register additional new DSO Type Codes in the 2371 "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert 2372 Review [RFC8126]. The expert review should validate that the 2373 requested type code is specified in a way that conforms to this 2374 specification, and that the intended use for the code would not be 2375 addressed with an experimental/local assignment. 2377 DSO Type Codes in the "experimental/local" range F800-FBFF may be 2378 used as Experimental Use or Private Use values [RFC8126] and may be 2379 used freely for development purposes, or for other purposes within a 2380 single site. No attempt is made to prevent multiple sites from using 2381 the same value in different (and incompatible) ways. There is no 2382 need for IANA to review such assignments (since IANA does not record 2383 them) and assignments are not generally useful for broad 2384 interoperability. It is the responsibility of the sites making use 2385 of "experimental/local" values to ensure that no conflicts occur 2386 within the intended scope of use. 2388 11. Security Considerations 2390 If this mechanism is to be used with DNS over TLS, then these 2391 messages are subject to the same constraints as any other DNS-over- 2392 TLS messages and MUST NOT be sent in the clear before the TLS session 2393 is established. 2395 The data field of the "Encryption Padding" TLV could be used as a 2396 covert channel. 2398 When designing new DSO TLVs, the potential for data in the TLV to be 2399 used as a tracking identifier should be taken into consideration, and 2400 should be avoided when not required. 2402 When used without TLS or similar cryptographic protection, a 2403 malicious entity maybe able to inject a malicious unidirectional DSO 2404 Retry Delay Message into the data stream, specifying an unreasonably 2405 large RETRY DELAY, causing a denial-of-service attack against the 2406 client. 2408 The establishment of DSO sessions has an impact on the number of open 2409 TCP connections on a DNS server. Additional resources may be used on 2410 the server as a result. However, because the server can limit the 2411 number of DSO sessions established and can also close existing DSO 2412 sessions as needed, denial of service or resource exhaustion should 2413 not be a concern. 2415 11.1. TLS 0-RTT Considerations 2417 DSO permits zero round-trip operation using TCP Fast Open [RFC7413] 2418 with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in 2419 session establishment. TCP Fast Open is only permitted in 2420 combination with TLS 0-RTT. In the rest of this section we refer to 2421 TLS 1.3 early data in a TLS 0-RTT initial handshake message, whether 2422 or not it is included in a TCP SYN packet with early data using the 2423 TCP Fast Open option, as "early data." 2425 A DSO message may or may not be permitted to be sent as early data. 2426 The definition for each TLV that can be used as a primary TLV is 2427 required to state whether or not that TLV is permitted as early data. 2428 Only response-requiring messages are ever permitted as early data, 2429 and only clients are permitted to send any DSO message as early data, 2430 unless there is an implicit session (see Section 5.1). 2432 For DSO messages that are permitted as early data, a client MAY 2433 include one or more such messages as early data without having to 2434 wait for a DSO response to the first DSO request message to confirm 2435 successful establishment of a DSO session. 2437 However, unless there is an implicit session, a client MUST NOT send 2438 DSO unidirectional messages until after a DSO Session has been 2439 mutually established. 2441 Similarly, unless there is an implicit session, a server MUST NOT 2442 send DSO request messages until it has received a response-requiring 2443 DSO request message from a client and transmitted a successful 2444 NOERROR response for that request. 2446 Caution must be taken to ensure that DSO messages sent as early data 2447 are idempotent, or are otherwise immune to any problems that could be 2448 result from the inadvertent replay that can occur with zero round- 2449 trip operation. 2451 It would be possible to add a TLV that requires the server to do some 2452 significant work, and send that to the server as initial data in a 2453 TCP SYN packet. A flood of such packets could be used as a DoS 2454 attack on the server. None of the TLVs defined here have this 2455 property. 2457 If a new TLV is specified that does have this property, that TLV must 2458 be specified as not permitted in 0-RTT messages. This prevents work 2459 from being done until a round-trip has occurred from the server to 2460 the client to verify that the source address of the packet is 2461 reachable. 2463 Documents that define new TLVs must state whether each new TLV may be 2464 sent as early data. Such documents must include a threat analysis in 2465 the security considerations section for each TLV defined in the 2466 document that may be sent as early data. This threat analysis should 2467 be done based on the advice given in [RFC8446] Section 2.3, 8 and 2468 Appendix E.5. 2470 12. Acknowledgements 2472 Thanks to Stephane Bortzmeyer, Tim Chown, Ralph Droms, Paul Hoffman, 2473 Jan Komissar, Edward Lewis, Allison Mankin, Rui Paulo, David 2474 Schinazi, Manju Shankar Rao, Bernie Volz and Bob Harold for their 2475 helpful contributions to this document. 2477 13. References 2479 13.1. Normative References 2481 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2482 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2483 . 2485 [RFC1035] Mockapetris, P., "Domain names - implementation and 2486 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2487 November 1987, . 2489 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2490 and E. Lear, "Address Allocation for Private Internets", 2491 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2492 . 2494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2495 Requirement Levels", BCP 14, RFC 2119, 2496 DOI 10.17487/RFC2119, March 1997, 2497 . 2499 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 2500 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 2501 RFC 2136, DOI 10.17487/RFC2136, April 1997, 2502 . 2504 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 2505 for DNS (EDNS(0))", STD 75, RFC 6891, 2506 DOI 10.17487/RFC6891, April 2013, 2507 . 2509 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 2510 D. Wessels, "DNS Transport over TCP - Implementation 2511 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 2512 . 2514 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 2515 DOI 10.17487/RFC7830, May 2016, 2516 . 2518 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2519 Writing an IANA Considerations Section in RFCs", BCP 26, 2520 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2521 . 2523 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2524 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2525 May 2017, . 2527 13.2. Informative References 2529 [I-D.ietf-dnsop-no-response-issue] 2530 Andrews, M. and R. Bellis, "A Common Operational Problem 2531 in DNS Servers - Failure To Respond.", draft-ietf-dnsop- 2532 no-response-issue-12 (work in progress), November 2018. 2534 [I-D.ietf-dnssd-mdns-relay] 2535 Lemon, T. and S. Cheshire, "Multicast DNS Discovery 2536 Relay", draft-ietf-dnssd-mdns-relay-01 (work in progress), 2537 July 2018. 2539 [I-D.ietf-dnssd-push] 2540 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 2541 draft-ietf-dnssd-push-16 (work in progress), November 2542 2018. 2544 [I-D.ietf-doh-dns-over-https] 2545 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 2546 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 2547 progress), August 2018. 2549 [I-D.ietf-dprive-padding-policy] 2550 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 2551 dprive-padding-policy-06 (work in progress), July 2018. 2553 [NagleDA] Cheshire, S., "TCP Performance problems caused by 2554 interaction between Nagle's Algorithm and Delayed ACK", 2555 May 2005, 2556 . 2558 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2559 Communication Layers", STD 3, RFC 1122, 2560 DOI 10.17487/RFC1122, October 1989, 2561 . 2563 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 2564 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 2565 . 2567 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 2568 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2569 RFC 5382, DOI 10.17487/RFC5382, October 2008, 2570 . 2572 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2573 DOI 10.17487/RFC6762, February 2013, 2574 . 2576 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2577 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2578 . 2580 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2581 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2582 . 2584 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 2585 edns-tcp-keepalive EDNS0 Option", RFC 7828, 2586 DOI 10.17487/RFC7828, April 2016, 2587 . 2589 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 2590 S., and K. Naito, "Updates to Network Address Translation 2591 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 2592 DOI 10.17487/RFC7857, April 2016, 2593 . 2595 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2596 and P. Hoffman, "Specification for DNS over Transport 2597 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2598 2016, . 2600 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2601 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2602 . 2604 Authors' Addresses 2606 Ray Bellis 2607 Internet Systems Consortium, Inc. 2608 950 Charter Street 2609 Redwood City CA 94063 2610 USA 2612 Phone: +1 (650) 423-1200 2613 Email: ray@isc.org 2615 Stuart Cheshire 2616 Apple Inc. 2617 One Apple Park Way 2618 Cupertino CA 95014 2619 USA 2621 Phone: +1 (408) 996-1010 2622 Email: cheshire@apple.com 2623 John Dickinson 2624 Sinodun Internet Technologies 2625 Magadalen Centre 2626 Oxford Science Park 2627 Oxford OX4 4GA 2628 United Kingdom 2630 Email: jad@sinodun.com 2632 Sara Dickinson 2633 Sinodun Internet Technologies 2634 Magadalen Centre 2635 Oxford Science Park 2636 Oxford OX4 4GA 2637 United Kingdom 2639 Email: sara@sinodun.com 2641 Ted Lemon 2642 Nibbhaya Consulting 2643 P.O. Box 958 2644 Brattleboro VT 05302-0958 2645 USA 2647 Email: mellon@fugue.com 2649 Tom Pusateri 2650 Unaffiliated 2651 Raleigh NC 27608 2652 USA 2654 Phone: +1 (919) 867-1330 2655 Email: pusateri@bangj.com