idnits 2.17.1 draft-ietf-dnsop-session-signal-05.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7766, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. (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 (January 26, 2018) is 2281 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-13 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-padding-policy-03 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-04) exists of draft-sctl-dnssd-mdns-relay-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 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: RFC 7766, RFC 1035 (if S. Cheshire 5 approved) Apple Inc. 6 Intended status: Standards Track J. Dickinson 7 Expires: July 30, 2018 S. Dickinson 8 Sinodun 9 A. Mankin 10 Salesforce 11 T. Pusateri 12 Unaffiliated 13 January 26, 2018 15 DNS Stateful Operations 16 draft-ietf-dnsop-session-signal-05 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. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 30, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. DSO Session Establishment . . . . . . . . . . . . . . . . 9 66 4.1.1. Connection Sharing . . . . . . . . . . . . . . . . . 11 67 4.1.2. Zero Round-Trip Operation . . . . . . . . . . . . . . 12 68 4.1.3. Middlebox Considerations . . . . . . . . . . . . . . 12 69 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 13 70 4.2.1. DNS Header Fields in DSO Messages . . . . . . . . . . 14 71 4.2.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 16 72 4.2.3. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 21 73 4.3. Message Handling . . . . . . . . . . . . . . . . . . . . 22 74 4.4. DSO Response Generation . . . . . . . . . . . . . . . . . 23 75 4.5. Responder-Initiated Operation Cancellation . . . . . . . 24 76 5. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 25 77 5.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 25 78 5.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 25 79 5.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 26 80 5.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 26 81 5.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 27 82 5.4.2. Values for the Inactivity Timeout . . . . . . . . . . 27 83 5.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 29 84 5.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 29 85 5.5.2. Values for the Keepalive Interval . . . . . . . . . . 29 86 5.6. Server-Initiated Session Termination . . . . . . . . . . 31 87 5.6.1. Server-Initiated Session Termination on Error . . . . 31 88 5.6.2. Server-Initiated Session Termination on Overload . . 32 89 5.6.3. Server-Initiated Retry Delay Request Message . . . . 33 90 6. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 35 91 6.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 35 92 6.1.1. Client handling of received Session Timeout values . 37 93 6.1.2. Relation to EDNS(0) TCP Keepalive Option . . . . . . 38 94 6.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 39 95 6.2.1. Retry Delay TLV used as a Primary TLV . . . . . . . . 39 96 6.2.2. Retry Delay TLV used as a Response Additional TLV . . 40 97 6.2.3. Retry Delay TLV is used by server only . . . . . . . 40 98 6.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 41 99 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 100 7.1. MESSAGE ID . . . . . . . . . . . . . . . . . . . . . . . 42 101 7.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 43 102 7.3. Inactivity Timeout . . . . . . . . . . . . . . . . . . . 44 103 7.4. Keepalive Interval . . . . . . . . . . . . . . . . . . . 44 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 105 8.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . . 45 106 8.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 45 107 8.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 45 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 47 112 11.2. Informative References . . . . . . . . . . . . . . . . . 48 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 115 1. Introduction 117 The use of transports for DNS other than UDP is being increasingly 118 specified, for example, DNS over TCP [RFC1035][RFC7766] and DNS over 119 TLS [RFC7858]. Such transports can offer persistent, long-lived 120 sessions and therefore when using them for transporting DNS messages 121 it is of benefit to have a mechanism that can establish parameters 122 associated with those sessions, such as timeouts. In such situations 123 it is also advantageous to support server initiated messages. 125 The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is 126 explicitly defined to only have "per-message" semantics. Whilst 127 EDNS(0) has been used to signal at least one session-related 128 parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is 129 less than optimal due to the restrictions imposed by the EDNS(0) 130 semantics and the lack of server-initiated signalling. For example, 131 a server cannot arbitrarily instruct a client to close a connection 132 because the server can only send EDNS(0) options in responses to 133 queries that contained EDNS(0) options. 135 This document defines a new DNS OPCODE, DSO (tentatively 6), for DNS 136 Stateful Operations. DSO messages are used to communicate operations 137 within persistent stateful sessions, expressed using type-length- 138 value (TLV) syntax. This document defines an initial set of three 139 TLVs, used to manage session timeouts, termination, and encryption 140 padding. 142 All three of the TLVs defined here are mandatory for all 143 implementations of DSO. Further TLVs may be defined in additional 144 specifications. 146 The format for DSO messages (see Section 4.2) differs somewhat from 147 the traditional DNS message format used for standard queries and 148 responses. The standard twelve-octet header is used, but the four 149 count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero and 150 accordingly their corresponding sections are not present. The actual 151 data pertaining to DNS Stateful Operations (expressed in TLV syntax) 152 is appended to the end of the DNS message header. When displayed 153 using packet analyzer tools that have not been updated to recognize 154 the DSO format, this will result in the DSO data being displayed as 155 unknown additional data after the end of the DNS message. It is 156 likely that future updates to these tools will add the ability to 157 recognize, decode, and display the DSO data. 159 This new format has distinct advantages over an RR-based format 160 because it is more explicit and more compact. Each TLV definition is 161 specific to its use case, and as a result contains no redundant or 162 overloaded fields. Importantly, it completely avoids conflating DNS 163 Stateful Operations in any way with normal DNS operations or with 164 existing EDNS(0)-based functionality. A goal of this approach is to 165 avoid the operational issues that have befallen EDNS(0), particularly 166 relating to middlebox behaviour. 168 With EDNS(0), multiple options may be packed into a single OPT 169 pseudo-RR, and there is no generalized mechanism for a client to be 170 able to tell whether a server has processed or otherwise acted upon 171 each individual option within the combined OPT RR. The 172 specifications for each individual option need to define how each 173 different option is to be acknowledged, if necessary. 175 In contrast to EDNS(0), with DSO there is no compelling motivation to 176 pack multiple operations into a single message for efficiency 177 reasons, because DSO always operates using a connection-oriented 178 transport protocol. Each Stateful operation is communicated in its 179 own separate DNS message, and the transport protocol can take care of 180 packing separate DNS messages into a single IP packet if appropriate. 181 For example, TCP can pack multiple small DNS messages into a single 182 TCP segment. This simplification allows for clearer semantics. Each 183 DSO request message communicates just one primary operation, and the 184 RCODE in the corresponding response message indicates the success or 185 failure of that operation. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 194 "DSO" is used to mean DNS Stateful Operation. 196 The term "connection" means a bidirectional byte stream of reliable, 197 in-order messages, such as provided by using DNS over TCP 198 [RFC1035][RFC7766] or DNS over TLS [RFC7858]. 200 The unqualified term "session" in the context of this document means 201 the exchange of DNS messages over a connection where: 203 o The connection between client and server is persistent and 204 relatively long-lived (i.e., minutes or hours, rather than 205 seconds). 207 o Either end of the connection may initiate messages to the other. 209 A "DSO Session" is established between two endpoints that acknowledge 210 persistent DNS state via the exchange of DSO messages over the 211 connection. This is distinct from a DNS-over-TCP session as 212 described in the previous specification for DNS over TCP [RFC7766]. 214 A "DSO Session" is terminated when the underlying connection is 215 closed. The underlying connection can be closed in two ways. 217 Where this specification says, "close gracefully," that means sending 218 a TLS close_notify followed by a TCP FIN, or the equivalents for 219 other protocols. Where this specification requires a connection to 220 be closed gracefully, the requirement to initiate that graceful close 221 is placed on the client, to place the burden of TCP's TIME-WAIT state 222 on the client rather than the server. 224 Where this specification says, "forcibly abort," that means sending a 225 TCP RST, or the equivalent for other protocols. In the BSD Sockets 226 API this is achieved by setting the SO_LINGER option to zero before 227 closing the socket. 229 The term "server" means the software with a listening socket, 230 awaiting incoming connection requests. 232 The term "client" means the software which initiates a connection to 233 the server's listening socket. 235 The terms "initiator" and "responder" correspond respectively to the 236 initial sender and subsequent receiver of a DSO request message, 237 regardless of which was the "client" and "server" in the usual DNS 238 sense. 240 The term "sender" may apply to either an initiator (when sending a 241 DSO request message) or a responder (when sending a DSO response 242 message). 244 Likewise, the term "receiver" may apply to either a responder (when 245 receiving a DSO request message) or an initiator (when receiving a 246 DSO response message). 248 The term "long-lived operations" refers to operations such as Push 249 Notification subscriptions [I-D.ietf-dnssd-push], Discovery Relay 250 interface subscriptions [I-D.sctl-dnssd-mdns-relay], and other future 251 long-lived DNS operations that choose to use DSO as their basis, that 252 establish state that persists beyond the lifetime of a traditional 253 brief request/response transaction. This document, the base 254 specification for DNS Stateful Operations, defines a framework for 255 supporting long-lived operations, but does not itself define any 256 long-lived operations. Nonetheless, to appreciate the design 257 rationale behind DNS Stateful Operations, it is helpful to understand 258 the long-lived operations that it is intended to support. 260 DNS Stateful Operations uses "DSO request messages" and "DSO response 261 messages". DSO request messages are further subdivided into two 262 variants, "acknowledged request messages" (which generate a 263 corresponding response message) and "unacknowledged request messages" 264 (which do not generate any corresponding response message). 266 The content of DSO messages is expressed using type-length-value 267 (TLV) syntax. 269 In a DSO request message the first TLV is referred to as the "Primary 270 TLV" and determines the nature of the operation being performed, 271 including whether it is an acknowledged or unacknowledged operation; 272 any other TLVs in a DSO request message are referred to as 273 "Additional TLVs" and serve additional non-primary purposes, which 274 may be related to the primary purpose, or not, as in the case of the 275 encryption padding TLV. 277 A DSO response message may contain no TLVs, or it may contain one or 278 more TLVs as appropriate to the information being communicated. In 279 the context of DSO response messages, one or more TLVs with the same 280 DSO-TYPE as the Primary TLV in the corresponding DSO request message 281 are referred to as "Response Primary TLVs". Any other TLVs with 282 different DSO-TYPEs are referred to as "Response Additional TLVs". 284 The Response Primary TLV(s), if present, MUST occur first in the 285 response message, before any Response Additional TLVs. 287 Two timers (elapsed time since an event) are defined in this 288 document: 290 o an inactivity timer (see Section 6.1 and Section 5.3) 292 o a keepalive timer (see Section 6.1 and Section 5.5) 294 The timeouts associated with these timers are called the inactivity 295 timeout and the keepalive interval, respectively. The term "Session 296 Timeouts" is used to refer to this pair of timeout values. 298 Resetting a timer means resetting the timer value to zero and 299 starting the timer again. Clearing a timer means resetting the timer 300 value to zero but NOT starting the timer again. 302 3. Discussion 304 There are several use cases for DNS Stateful operations that can be 305 described here. 307 Firstly, establishing session parameters such as server-defined 308 timeouts is of great use in the general management of persistent 309 connections. For example, using DSO sessions for stub to recursive 310 DNS-over-TLS [RFC7858] is more flexible for both the client and the 311 server than attempting to manage sessions using just the EDNS(0) TCP 312 Keepalive option [RFC7828]. The simple set of TLVs defined in this 313 document is sufficient to greatly enhance connection management for 314 this use case. 316 Secondly, DNS-SD [RFC6763] has evolved into a naturally session based 317 mechanism where, for example, long-lived subscriptions lend 318 themselves to 'push' mechanisms as opposed to polling. Long-lived 319 stateful connections and server initiated messages align with this 320 use case [I-D.ietf-dnssd-push]. 322 A general use case is that DNS traffic is often bursty but session 323 establishment can be expensive. One challenge with long-lived 324 connections is to maintain sufficient traffic to maintain NAT and 325 firewall state. To mitigate this issue this document introduces a 326 new concept for the DNS, that is DSO "Keepalive traffic". This 327 traffic carries no DNS data and is not considered 'activity' in the 328 classic DNS sense, but serves to maintain state in middleboxes, and 329 to assure client and server that they still have connectivity to each 330 other. 332 There are a myriad of other potential use cases for DSO given the 333 versatility and extensibility of this specification. 335 Section 4 of this document describes the protocol details of DNS 336 Stateful Operations including definitions of three TLVs for session 337 management and encryption padding. Section 5 presents a detailed 338 discussion of the DSO Session lifecycle including an in-depth 339 discussion of keepalive traffic and session termination. 341 4. Protocol Details 343 4.1. DSO Session Establishment 345 DSO messages MUST only be carried in protocols and in environments 346 where a session may be established according to the definition above. 347 Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] 348 are suitable protocols. 350 DNS over plain UDP [RFC0768] is not appropriate since it fails on the 351 requirement for in-order message delivery, and, in the presence of 352 NAT gateways and firewalls with short UDP timeouts, it fails to 353 provide a persistent bi-directional communication channel unless an 354 excessive amount of keepalive traffic is used. 356 In some environments it may be known in advance by external means 357 that both client and server support DSO, and in these cases either 358 client or server may initiate DSO messages at any time. 360 However, in the typical case a server will not know in advance 361 whether a client supports DSO, so in general, unless it is known in 362 advance by other means that a client does support DSO, a server MUST 363 NOT initiate DSO request messages until a DSO Session has been 364 mutually established, as described below. Similarly, unless it is 365 known in advance by other means that a server does support DSO, a 366 client MUST NOT initiate non-response-requiring DSO request messages 367 until after a DSO Session has been mutually established. 369 Whether or not a given DSO request message elicits a response is 370 determined by whether or not the first DSO TLV (see Section 4.2.2.1) 371 in the message (the Primary TLV) is one that is specified to generate 372 a response. Whether a Primary TLV will be specified to elicit a 373 response will depend on the intended use pattern for that particular 374 TLV. 376 A DSO Session is established over a connection by the client sending 377 a DSO request message of a kind that requires a response, such as the 378 DSO Keepalive TLV (see Section 6.1), and receiving a response, with 379 matching MESSAGE ID, and RCODE set to NOERROR (0), indicating that 380 the DSO request was successful. 382 If the RCODE is set to DSONOTIMP (tentatively 11) this indicates that 383 the server does support DSO, but does not support the particular 384 operation the client requested. A server MUST NOT return DSONOTIMP 385 for the DSO Keepalive TLV, but a DSONOTIMP response could happen in 386 the future, if a client attempts to establish a DSO Session using a 387 future response-requiring DSO TLV that the server does not 388 understand. If the server returns DSONOTIMP then a DSO Session is 389 not considered established, but the client is permitted to continue 390 sending DNS messages on the connection, including other response- 391 requiring DSO messages such as the DSO Keepalive, which may result in 392 a successful NOERROR response, yielding the establishment of a DSO 393 Session. 395 If the RCODE is set to any value other than NOERROR (0) or DSONOTIMP 396 (tentatively 11), then the client should assume that the server does 397 not support DSO. In this case the client is permitted to continue 398 sending DNS messages on that connection, but the client SHOULD NOT 399 issue further DSO messages on that connection. 401 When the server receives a response-requiring DSO request message 402 from a client, and transmits a successful NOERROR response to that 403 request, the server considers the DSO Session established. 405 When the client receives the server's NOERROR response to its DSO 406 request message, the client considers the DSO Session established. 408 Once a DSO Session has been established, either end may unilaterally 409 send DSO messages at any time, and therefore either client or server 410 may be the initiator of a message. 412 Once a DSO Session has been established, clients and servers should 413 behave as described in this specification with regard to inactivity 414 timeouts and session termination, not as previously prescribed in the 415 earlier specification for DNS over TCP [RFC7766]. 417 4.1.1. Connection Sharing 419 As previously specified for DNS over TCP [RFC7766], to mitigate the 420 risk of unintentional server overload, DNS clients MUST take care to 421 minimize the number of concurrent TCP connections made to any 422 individual server. It is RECOMMENDED that for any given client/ 423 server interaction there SHOULD be no more than one connection for 424 regular queries, one for zone transfers, and one for each protocol 425 that is being used on top of TCP (for example, if the resolver was 426 using TLS). However, it is noted that certain primary/secondary 427 configurations with many busy zones might need to use more than one 428 TCP connection for zone transfers for operational reasons (for 429 example, to support concurrent transfers of multiple zones). 431 A single server may support multiple services, including DNS Updates 432 [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other 433 services, for one or more DNS zones. When a client discovers that 434 the target server for several different operations is the same target 435 hostname and port, the client SHOULD use a single shared DSO Session 436 for all those operations. A client SHOULD NOT open multiple 437 connections to the same target host and port just because the names 438 being operated on are different or happen to fall within different 439 zones. This is to reduce unnecessary connection load on the DNS 440 server. 442 However, server implementers and operators should be aware that 443 connection sharing may not be possible in all cases. A single host 444 device may be home to multiple independent client software instances 445 that don't coordinate with each other. Similarly, multiple 446 independent client devices behind the same NAT gateway will also 447 typically appear to the DNS server as different source ports on the 448 same client IP address. Because of these constraints, a DNS server 449 MUST be prepared to accept multiple connections from different source 450 ports on the same client IP address. 452 4.1.2. Zero Round-Trip Operation 454 There is increased awareness today of the performance benefits of 455 eliminating round trips in session establishment. Technologies like 456 TCP Fast Open [RFC7413] and TLS 1.3 [I-D.ietf-tls-tls13] provide 457 mechanisms to reduce or eliminate round trips in session 458 establishment. 460 Similarly, DSO supports zero round-trip operation. 462 Having initiated a connection to a server, possibly using zero round- 463 trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send 464 multiple response-requiring DSO request messages to the server in 465 succession without having to wait for a response to the first request 466 message to confirm successful establishment of a DSO session. 468 However, a client MUST NOT send non-response-requiring DSO request 469 messages until after a DSO Session has been mutually established. 471 Similarly, a server MUST NOT send DSO request messages until it has 472 received a response-requiring DSO request message from a client and 473 transmitted a successful NOERROR response for that request. 475 4.1.3. Middlebox Considerations 477 Where an application-layer middlebox (e.g., a DNS proxy, forwarder, 478 or session multiplexer) is in the path the middlebox MUST NOT blindly 479 forward DSO messages in either direction, and MUST treat the inbound 480 and outbound connections as separate sessions. This does not 481 preclude the use of DSO messages in the presence of an IP-layer 482 middlebox, such as a NAT that rewrites IP-layer and/or transport- 483 layer headers but otherwise preserves the effect of a single session 484 between the client and the server. 486 To illustrate the above, consider a network where a middlebox 487 terminates one or more TCP connections from clients and multiplexes 488 the queries therein over a single TCP connection to an upstream 489 server. The DSO messages and any associated state are specific to 490 the individual TCP connections. A DSO-aware middlebox MAY in some 491 circumstances be able to retain associated state and pass it between 492 the client and server (or vice versa) but this would be highly TLV- 493 specific. For example, the middlebox may be able to maintain a list 494 of which clients have made Push Notification subscriptions 495 [I-D.ietf-dnssd-push] and make its own subscription(s) on their 496 behalf, relaying any subsequent notifications to the client (or 497 clients) that have subscribed to that particular notification. 499 4.2. Message Format 501 A DSO message begins with the standard twelve-octet DNS message 502 header [RFC1035] with the OPCODE field set to the DSO OPCODE 503 (tentatively 6). However, unlike standard DNS messages, the question 504 section, answer section, authority records section and additional 505 records sections are not present. The corresponding count fields 506 (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero on 507 transmission. 509 If a DSO message is received where any of the count fields are not 510 zero, then a FORMERR MUST be returned, unless a future IETF Standard 511 specifies otherwise. 513 1 1 1 1 1 1 514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 515 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 516 | MESSAGE ID | 517 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 518 |QR | OPCODE | Z | RCODE | 519 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 520 | QDCOUNT (MUST be zero) | 521 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 522 | ANCOUNT (MUST be zero) | 523 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 524 | NSCOUNT (MUST be zero) | 525 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 526 | ARCOUNT (MUST be zero) | 527 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 528 | | 529 / DSO Data / 530 / / 531 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 533 4.2.1. DNS Header Fields in DSO Messages 535 In an unacknowledged request message the MESSAGE ID field MUST be set 536 to zero. In an acknowledged request message the MESSAGE ID field 537 MUST be set to a unique nonzero value, that the initiator is not 538 currently using for any other active operation on this connection. 539 For the purposes here, a MESSAGE ID is in use in this DSO Session if 540 the initiator has used it in a request for which it is still awaiting 541 a response, or if the client has used it to setup a long-lived 542 operation that has not yet been cancelled. For example, a long-lived 543 operation could be a Push Notification subscription 544 [I-D.ietf-dnssd-push] or a Discovery Relay interface subscription 545 [I-D.sctl-dnssd-mdns-relay]. 547 Whether a message is acknowledged or unacknowledged is determined 548 only by the specification for the Primary TLV. An acknowledgment 549 cannot be requested by including a nonzero message ID in a message 550 the primary TLV of which is specified to be unacknowledged, nor can 551 an acknowledgment be prevented by sending a message ID of zero in a 552 message with a primary TLV that is specified to be acknowledged. A 553 responder that receives either such malformed message MUST treat it 554 as a programming error and terminate the connection. 556 In a request message the DNS Header QR bit MUST be zero (QR=0). 557 If the QR bit is not zero the message is not a request message. 559 In a response message the DNS Header QR bit MUST be one (QR=1). 560 If the QR bit is not one the message is not a response message. 562 In a response message (QR=1) the MESSAGE ID field MUST contain a copy 563 of the value of the MESSAGE ID field in the acknowledged request 564 message being responded to. In a response message (QR=1) the MESSAGE 565 ID field MUST NOT be zero. If a response message (QR=1) is received 566 where the MESSAGE ID is zero this is a fatal error and the receiver 567 MUST forcibly abort the connection immediately. 569 The DNS Header OPCODE field holds the DSO OPCODE value (tentatively 570 6). 572 The Z bits are currently unused in DSO messages, and in both DSO 573 requests and DSO responses the Z bits MUST be set to zero (0) on 574 transmission and MUST be silently ignored on reception, unless a 575 future IETF Standard specifies otherwise. 577 In a request message (QR=0) the RCODE is generally set to zero on 578 transmission, and silently ignored on reception, except where 579 specified otherwise (for example, the Retry Delay request message 580 (see Section 5.6.3), where the RCODE indicates the reason for 581 termination). 583 The RCODE value in a response message (QR=1) may be one of the 584 following values: 586 +------+-----------+------------------------------------------------+ 587 | Code | Mnemonic | Description | 588 +------+-----------+------------------------------------------------+ 589 | 0 | NOERROR | Operation processed successfully | 590 | | | | 591 | 1 | FORMERR | Format error | 592 | | | | 593 | 2 | SERVFAIL | Server failed to process request due to a | 594 | | | problem with the server | 595 | | | | 596 | 3 | NXDOMAIN | Name Error -- Named entity does not exist | 597 | | | (TLV-dependent) | 598 | | | | 599 | 4 | NOTIMP | DSO not supported | 600 | | | | 601 | 5 | REFUSED | Operation declined for policy reasons | 602 | | | | 603 | 9 | NOTAUTH | Not Authoritative (TLV-dependent) | 604 | | | | 605 | 11 | DSONOTIMP | DSO type code not supported | 606 +------+-----------+------------------------------------------------+ 608 Use of the above RCODEs is likely to be common in DSO but does not 609 preclude the definition and use of other codes in future documents 610 that make use of DSO. 612 If a document defining a new DSO TLV makes use of NXDOMAIN (Name 613 Error) or NOTAUTH (Not Authoritative) then that document MUST specify 614 the specific interpretation of these RCODE values in the context of 615 that new DSO TLV. 617 4.2.2. DSO Data 619 The standard twelve-octet DNS message header with its zero-valued 620 count fields is followed by the DSO Data, expressed using TLV syntax, 621 as described below Section 4.2.2.1. 623 A DSO message may be either a request message or a response message, 624 as indicated by the QR bit in the DNS message header. DSO request 625 messages are further subdivided into two variants, acknowledged 626 request messages (which generate a corresponding response message) 627 and unacknowledged request messages (which do not generate any 628 corresponding response message). 630 A DSO request message MUST contain at least one TLV. The first TLV 631 in a DSO request message is referred to as the "Primary TLV" and 632 determines the nature of the operation being performed, including 633 whether it is an acknowledged or unacknowledged operation. In some 634 cases it may be appropriate to include other TLVs in a request 635 message, such as the Encryption Padding TLV (Section 6.3), and these 636 extra TLVs are referred to as the "Additional TLVs". 638 A DSO response message may contain no TLVs, or it may be specified to 639 contain one or more TLVs appropriate to the information being 640 communicated. 642 A DSO response message may contain one or more TLVs with DSO-TYPE the 643 same as the Primary TLV from the corresponding DSO request message, 644 in which case those TLV(s) are referred to as "Response Primary 645 TLVs". A DSO response message is not required to carry Response 646 Primary TLVs. The MESSAGE ID field in the DNS message header is 647 sufficient to identify to which DSO request message this response 648 message relates. 650 A DSO response message may contain one or more TLVs with DSO-TYPEs 651 different from the Primary TLV from the corresponding DSO request 652 message, in which case those TLV(s) are referred to as "Response 653 Additional TLVs". 655 Response Primary TLV(s), if present, MUST occur first in the response 656 message, before any Response Additional TLVs. 658 It is anticipated that by default most DSO request messages will be 659 specified to be acknowledged request messages, which generate 660 corresponding responses. In some specialized high-traffic use cases, 661 it may be appropriate to specify unacknowledged request messages. 662 Unacknowledged request messages can be more efficient on the network, 663 because they don't generate a stream of corresponding reply messages. 664 Using unacknowledged request messages can also simplify software in 665 some cases, by removing need for an initiator to maintain state while 666 it waits to receive replies it doesn't care about. When the 667 specification for a particular TLV states that, when used as a 668 Primary TLV (i.e., first) in a request message, that request message 669 is to be unacknowledged, the MESSAGE ID field MUST be set to zero and 670 the receiver MUST NOT generate any response message corresponding to 671 this unacknowledged request message. 673 The previous point, that the receiver MUST NOT generate responses to 674 unacknowledged request messages, applies even in the case of errors. 675 When a DSO request message is received with the MESSAGE ID field set 676 to zero, the receiver MUST NOT generate any response. For example, 677 if the DSO-TYPE in the Primary TLV is unrecognized, then a DSONOTIMP 678 error MUST NOT be returned; instead the receiver MUST forcibly abort 679 the connection immediately. 681 Unacknowledged request messages MUST NOT be used "speculatively" in 682 cases where the sender doesn't know if the receiver supports the 683 Primary TLV in the message, because there is no way to receive any 684 response to indicate success or failure of the request message (the 685 request message does not contain a unique MESSAGE ID with which to 686 associate a response with its corresponding request). Unacknowledged 687 request messages are only appropriate in cases where the sender 688 already knows that the receiver supports and wishes to receive these 689 messages. 691 For example, after a client has subscribed for Push Notifications 692 [I-D.ietf-dnssd-push], the subsequent event notifications are then 693 sent as unacknowledged messages, and this is appropriate because the 694 client initiated the message stream by virtue of its Push 695 Notification subscription, thereby indicating its support of Push 696 Notifications, and its desire to receive those notifications. 698 Similarly, after an mDNS Relay client has subscribed to receive 699 inbound mDNS traffic from an mDNS Relay, the subsequent stream of 700 received packets is then sent using unacknowledged messages, and this 701 is appropriate because the client initiated the message stream by 702 virtue of its mDNS Relay link subscription, thereby indicating its 703 support of mDNS Relay, and its desire to receive inbound mDNS packets 704 over that DSO session [I-D.sctl-dnssd-mdns-relay]. 706 4.2.2.1. TLV Syntax 708 All TLVs, whether used as "Primary", "Additional", "Response 709 Primary", or "Response Additional", use the same encoding syntax. 711 The specification for a TLV determines whether, when used as the 712 Primary (i.e., first) TLV in a request message, that request message 713 is to be acknowledged. If the request message is to be acknowledged, 714 the specification also states which TLVs, if any, are to be included 715 in the response. The Primary TLV may or may not be contained in the 716 response, depending on what is stated in the specification for that 717 TLV. 719 1 1 1 1 1 1 720 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 721 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 722 | DSO-TYPE | 723 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 724 | DSO DATA LENGTH | 725 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 726 | | 727 / TYPE-DEPENDENT DATA / 728 / / 729 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 731 DSO-TYPE: A 16-bit unsigned integer in network (big endian) byte 732 order giving the type of the current DSO TLV per the IANA DSO Type 733 Code Registry. 735 DSO DATA LENGTH: A 16-bit unsigned integer in network (big endian) 736 byte order giving the size in octets of the TYPE-DEPENDENT DATA. 738 TYPE-DEPENDENT DATA: Type-code specific format. 740 Where domain names appear within TYPE-DEPENDENT DATA, they MAY 741 be compressed using standard DNS name compression [RFC1035]. 742 However, the compression offsets MUST be relative to the start of the 743 TYPE-DEPENDENT DATA and MUST NOT extend beyond the end of the TYPE- 744 DEPENDENT DATA. 746 4.2.2.2. Request TLVs 748 The first TLV in a DSO request message is the "Primary TLV" and 749 indicates the operation to be performed. A DSO request message MUST 750 contain at at least one TLV, the Primary TLV. 752 Immediately following the Primary TLV, a DSO request message MAY 753 contain one or more "Additional TLVs", which specify additional 754 parameters relating to the operation. 756 4.2.2.3. Response TLVs 758 Depending on the operation, a DSO response message MAY contain no 759 TLVs, because it is simply a response to a previous request message, 760 and the MESSAGE ID in the header is sufficient to identify the 761 request in question. Or it may contain a single response TLV, with 762 the same DSO-TYPE as the Primary TLV in the request message. 763 Alternatively it may contain one or more TLVs of other types, or a 764 combination of the above, as appropriate for the information that 765 needs to be communicated. The specification for each DSO TLV 766 determines what TLVs are required in a response to a request using 767 that TLV. 769 If a DSO response is received for an operation where the 770 specification requires that the response carry a particular TLV or 771 TLVs, and the required TLV(s) are not present, then this is a fatal 772 error and the recipient of the defective response message MUST 773 forcibly abort the connection immediately. 775 4.2.2.4. Unrecognized TLVs 777 If DSO request is received containing an unrecognized Primary TLV, 778 with a nonzero MESSAGE ID (indicating that a response is expected), 779 then the receiver MUST send a response with matching MESSAGE ID, and 780 RCODE DSONOTIMP (tentatively 11). The response MUST NOT contain a 781 copy of the unrecognized Primary TLV. 783 If DSO request is received containing an unrecognized Primary TLV, 784 with a zero MESSAGE ID (indicating that no response is expected), the 785 receiver MUST silently ignore the message. A response MUST NOT be 786 sent. 788 If a DSO request message is received where the Primary TLV is 789 recognized, containing one or more unrecognized Additional TLVs, the 790 unrecognized Additional TLVs MUST be silently ignored, and the 791 remainder of the message is interpreted and handled as if the 792 unrecognized parts were not present. 794 Similarly, if a DSO response message is received containing one or 795 more unrecognized TLVs, the unrecognized TLVs MUST be silently 796 ignored, and the remainder of the message is interpreted and handled 797 as if the unrecognized parts were not present. 799 4.2.3. EDNS(0) and TSIG 801 Since the ARCOUNT field MUST be zero, a DSO message MUST NOT contain 802 an EDNS(0) option in the additional records section. If 803 functionality provided by current or future EDNS(0) options is 804 desired for DSO messages, one or more new DSO TLVs need to be defined 805 to carry the necessary information. 807 For example, the EDNS(0) Padding Option [RFC7830] used for security 808 purposes is not permitted in a DSO message, so if message padding is 809 desired for DSO messages then the Encryption Padding TLV described in 810 Section 6.3 MUST be used. 812 Similarly, a DSO message MUST NOT contain a TSIG record. A TSIG 813 record in a conventional DNS message is added as the last record in 814 the additional records section, and carries a signature computed over 815 the preceding message content. Since DSO data appears after the 816 additional records section, it would not be included in the signature 817 calculation. If use of signatures with DSO messages becomes 818 necessary in the future, a new DSO TLV needs to be defined to perform 819 this function. 821 Note however that, while DSO *messages* cannot include EDNS(0) or 822 TSIG records, a DSO *session* is typically used to carry a whole 823 series of DNS messages of different kinds, including DSO messages, 824 and other DNS message types like Query [RFC1034] [RFC1035] and Update 825 [RFC2136], and those messages can carry EDNS(0) and TSIG records. 827 This specification explicitly prohibits use of the EDNS(0) TCP 828 Keepalive Option [RFC7828] in *any* messages sent on a DSO Session 829 (because it is obsoleted by the functionality provided by the DSO 830 Keepalive operation), but messages may contain other EDNS(0) options 831 as appropriate. 833 4.3. Message Handling 835 The initiator MUST set the value of the QR bit in the DNS header to 836 zero (0), and the responder MUST set it to one (1). Every DSO 837 request message (QR=0) with a nonzero MESSAGE ID field MUST elicit a 838 corresponding response (QR=1), which MUST have the same MESSAGE ID in 839 the DNS message header as in the corresponding request. DSO request 840 messages sent by the client with a nonzero MESSAGE ID field elicit a 841 response from the server, and DSO request messages sent by the server 842 with a nonzero MESSAGE ID field elicit a response from the client. 844 A DSO request message (QR=0) with a zero MESSAGE ID field MUST NOT 845 elicit a response. 847 The namespaces of 16-bit MESSAGE IDs are disjoint in each direction. 848 For example, it is *not* an error for both client and server to send 849 a request message with the same ID. In effect, the 16-bit MESSAGE ID 850 combined with the identity of the initiator (client or server) serves 851 as a 17-bit unique identifier for a particular operation on a DSO 852 Session. 854 As described in Section 4.2.1 An initiator MUST NOT reuse a MESSAGE 855 ID that is already in use for an outstanding request, unless 856 specified otherwise by the relevant specification for the DSO in 857 question. At the very least, this means that a MESSAGE ID MUST NOT 858 be reused in a particular direction on a particular DSO Session while 859 the initiator is waiting for a response to a previous request using 860 that MESSAGE ID on that DSO Session, unless specified otherwise by 861 the relevant specification for the DSO in question. (For a long- 862 lived operation the MESSAGE ID for the operation MUST NOT be reused 863 whilst that operation remains active.) 865 If a client or server receives a response (QR=1) where the MESSAGE ID 866 is zero, or any other value that does not match the MESSAGE ID of any 867 of its outstanding operations, this is a fatal error and the 868 recipient MUST forcibly abort the connection immediately. 870 4.4. DSO Response Generation 872 With most TCP implementations, for DSO requests that generate a 873 response, the TCP data acknowledgement (generated because data has 874 been received by TCP), the TCP window update (generated because TCP 875 has delivered that data to the receiving software), and the DSO 876 response (generated by the receiving application-layer software 877 itself) are all combined into a single IP packet. Combining these 878 three elements into a single IP packet gives a potentially 879 significant improvement in network efficiency. 881 For DSO requests that do not generate a response, the TCP 882 implementation generally doesn't have any way to know that no 883 response will be forthcoming, so it waits fruitlessly for the 884 application-layer software to generate a response, until the Delayed 885 ACK timer fires [RFC1122] (typically 200 milliseconds) and only then 886 does it send the TCP ack and window update. In conjunction with 887 Nagle's Algorithm at the sender, this can delay the sender's 888 transmission of its next (non-full-sized) TCP segment, while the 889 sender is waiting for its previous (non-full-sized) TCP segment to be 890 acknowledged, which won't happen until the Delayed ACK timer fires. 891 Nagle's Algorithm exists to combine multiple small application writes 892 into more efficient large TCP segments, to guard against wasteful use 893 of the network by applications that would otherwise transmit a stream 894 of small TCP segments, but in this case Nagle's Algorithm (created to 895 improve network efficiency) can interact badly with TCP's Delayed ACK 896 feature (also created to improve network efficiency) [NagleDA] with 897 the result of delaying some messages by up to 200 milliseconds. 899 Possible mitigations for this problem include: 901 o Disabling Nagle's Algorithm at the sender. 902 This is not great, because it results 903 in less efficient use of the network. 905 o Disabling Delayed ACK at the receiver. 906 This is not great, because it results 907 in less efficient use of the network. 909 o Using a networking API that lets the receiver signal to the TCP 910 implementation that the receiver has received and processed a 911 client request for which it will not be generating any immediate 912 response. This allows the TCP implementation to operate 913 efficiently in both cases; for requests that generate a response, 914 the TCP ack, window update, and DSO response are transmitted 915 together in a single TCP segment, and for requests that do not 916 generate a response, the application-layer software informs the 917 TCP implementation that it should go ahead and send the TCP ack 918 and window update immediately, without waiting for the Delayed ACK 919 timer. Unfortunately it is not known at this time which (if any) 920 of the widely-available networking APIs currently include this 921 capability. 923 4.5. Responder-Initiated Operation Cancellation 925 This document, the base specification for DNS Stateful Operations, 926 does not itself define any long-lived operations, but it defines a 927 framework for supporting long-lived operations such as Push 928 Notification subscriptions [I-D.ietf-dnssd-push] and Discovery Relay 929 interface subscriptions [I-D.sctl-dnssd-mdns-relay]. 931 Generally speaking, a long-lived operation is initiated by the 932 initiator, and, if successful, remains active until the initiator 933 terminates the operation. 935 However, it is possible that a long-lived operation may be valid at 936 the time it was initiated, but then a later change of circumstances 937 may render that previously valid operation invalid. 939 For example, a long-lived client operation may pertain to a name that 940 the server is authoritative for, but then the server configuration is 941 changed such that it is no longer authoritative for that name. 943 In such cases, instead of terminating the entire session it may be 944 desirable for the responder to be able to cancel selectively only 945 those operations that have become invalid. 947 The responder performs this selective cancellation by sending a new 948 response message, with the MESSAGE ID field containing the MESSAGE ID 949 of the long-lived operation that is to be terminated (that it had 950 previously acknowledged with a NOERROR RCODE), and the RCODE field of 951 the new response message giving the reason for cancellation. 953 After a response message with nonzero RCODE has been sent, that 954 operation has been terminated from the responder's point of view, and 955 the responder sends no more messages relating to that operation. 957 After a response message with nonzero RCODE has been received by the 958 initiator, that operation has been terminated from the initiator's 959 point of view, and its MESSAGE ID is now free for reuse. 961 5. DSO Session Lifecycle and Timers 963 5.1. DSO Session Initiation 965 A DSO Session begins as described in Section 4.1. 967 The client may perform as many DNS operations as it wishes using the 968 newly created DSO Session. Operations SHOULD be pipelined (i.e., the 969 client doesn't need wait for a response before sending the next 970 message). The server MUST act on messages in the order they are 971 transmitted, but responses to those messages SHOULD be sent out of 972 order when appropriate. 974 5.2. DSO Session Timeouts 976 Two timeout values are associated with a DSO Session: the inactivity 977 timeout, and the keepalive interval. 979 The first timeout value, the inactivity timeout, is the maximum time 980 for which a client may speculatively keep a DSO Session open in the 981 expectation that it may have future requests to send to that server. 983 The second timeout value, the keepalive interval, is the maximum 984 permitted interval between client messages to the server if the 985 client wishes to keep the DSO Session alive. 987 The two timeout values are independent. The inactivity timeout may 988 be lower, the same, or higher than the keepalive interval, though in 989 most cases the inactivity timeout is expected to be shorter than the 990 keepalive interval. 992 Only when the client has a very long-lived low-traffic operation does 993 the keepalive interval come into play, to ensure that a sufficient 994 residual amount of traffic is generated to maintain NAT and firewall 995 state and to assure client and server that they still have 996 connectivity to each other. 998 On a new DSO Session, if no explicit DSO Keepalive message exchange 999 has taken place, the default value for both timeouts is 15 seconds. 1000 For both timeouts, lower values of the timeout result in higher 1001 network traffic and higher CPU load on the server. 1003 5.3. Inactive DSO Sessions 1005 At both servers and clients, the generation or reception of any 1006 complete DNS message, including DNS requests, responses, updates, or 1007 DSO messages, resets both timers for that DSO Session, with the 1008 exception that a DSO Keepalive message resets only the keepalive 1009 timer, not the inactivity timeout timer. 1011 In addition, for as long as the client has an outstanding operation 1012 in progress, the inactivity timer remains cleared, and an inactivity 1013 timeout cannot occur. 1015 For short-lived DNS operations like traditional queries and updates, 1016 an operation is considered in progress for the time between request 1017 and response, typically a period of a few hundred milliseconds at 1018 most. At the client, the inactivity timer is cleared upon 1019 transmission of a request and remains cleared until reception of the 1020 corresponding response. At the server, the inactivity timer is 1021 cleared upon reception of a request and remains cleared until 1022 transmission of the corresponding response. 1024 For long-lived DNS Stateful operations (such as a Push Notification 1025 subscription [I-D.ietf-dnssd-push] or a Discovery Relay interface 1026 subscription [I-D.sctl-dnssd-mdns-relay]), an operation is considered 1027 in progress for as long as the operation is active, until it is 1028 cancelled. This means that a DSO Session can exist, with active 1029 operations, with no messages flowing in either direction, for far 1030 longer than the inactivity timeout, and this is not an error. This 1031 is why there are two separate timers: the inactivity timeout, and the 1032 keepalive interval. Just because a DSO Session has no traffic for an 1033 extended period of time does not automatically make that DSO Session 1034 "inactive", if it has an active operation that is awaiting events. 1036 5.4. The Inactivity Timeout 1038 The purpose of the inactivity timeout is for the server to balance 1039 its trade off between the costs of setting up new DSO Sessions and 1040 the costs of maintaining inactive DSO Sessions. A server with 1041 abundant DSO Session capacity can offer a high inactivity timeout, to 1042 permit clients to keep a speculative DSO Session open for a long 1043 time, to save the cost of establishing a new DSO Session for future 1044 communications with that server. A server with scarce memory 1045 resources can offer a low inactivity timeout, to cause clients to 1046 promptly close DSO Sessions whenever they have no outstanding 1047 operations with that server, and then create a new DSO Session later 1048 when needed. 1050 5.4.1. Closing Inactive DSO Sessions 1052 A client is NOT required to wait until the inactivity timeout expires 1053 before closing a DSO Session. A client MAY close a DSO Session at 1054 any time, at the client's discretion. If a client determines that it 1055 has no current or reasonably anticipated future need for an inactive 1056 DSO Session, then the client SHOULD close that connection. 1058 If, at any time during the life of the DSO Session, the inactivity 1059 timeout value (i.e., 15 seconds by default) elapses without there 1060 being any operation active on the DSO Session, the client MUST close 1061 the connection gracefully. 1063 If, at any time during the life of the DSO Session, twice the 1064 inactivity timeout value (i.e., 30 seconds by default), or five 1065 seconds, if twice the inactivity timeout value is less than five 1066 seconds, elapses without there being any operation active on the DSO 1067 Session, the server SHOULD consider the client delinquent, and SHOULD 1068 forcibly abort the DSO Session. 1070 In this context, an operation being active on a DSO Session includes 1071 a query waiting for a response, an update waiting for a response, or 1072 an active long-lived operation, but not a DSO Keepalive message 1073 exchange itself. A DSO Keepalive message exchange resets only the 1074 keepalive interval timer, not the inactivity timeout timer. 1076 If the client wishes to keep an inactive DSO Session open for longer 1077 than the default duration without having to send traffic every 15 1078 seconds, then it uses the DSO Keepalive message to request longer 1079 timeout values, as described in Section 6.1. 1081 5.4.2. Values for the Inactivity Timeout 1083 For the inactivity timeout value, lower values result in more 1084 frequent DSO Session teardown and re-establishment. Higher values 1085 result in lower traffic and lower CPU load on the server, but higher 1086 memory burden to maintain state for inactive DSO Sessions. 1088 A server may dictate (in a server-initiated Keepalive message, or in 1089 a response to a client-initiated Keepalive request message) any value 1090 it chooses for the inactivity timeout. When a connection's 1091 inactivity timeout is reached the client MUST begin closing the idle 1092 connection, but a client is NOT REQUIRED to keep an idle connection 1093 open until the inactivity timeout is reached -- a client SHOULD begin 1094 closing the connection sooner if it has no reason to expect future 1095 operations with that server before the inactivity timeout is reached. 1097 A shorter inactivity timeout with a longer keepalive interval signals 1098 to the client that it should not speculatively keep an inactive DSO 1099 Session open for very long without reason, but when it does have an 1100 active reason to keep a DSO Session open, it doesn't need to be 1101 sending an aggressive level of keepalive traffic to maintain that 1102 session. 1104 A longer inactivity timeout with a shorter keepalive interval signals 1105 to the client that it may speculatively keep an inactive DSO Session 1106 open for a long time, but to maintain that inactive DSO Session it 1107 should be sending a lot of keepalive traffic. This configuration is 1108 expected to be less common. 1110 A server may dictate any value it chooses for the inactivity timeout 1111 (either in a response to a client-initiated request, or in a server- 1112 initiated message) including values under one second, or even zero. 1114 An inactivity timeout of zero informs the client that it should not 1115 speculatively maintain idle connections at all, and as soon as the 1116 client has completed the operation or operations relating to this 1117 server, the client should immediately begin closing this session. 1119 An inactivity timeout of 0xFFFFFFFF (2^32-1 milliseconds, 1120 approximately 49.7 days) informs the client that it may keep an idle 1121 connection open as long as it wishes. Note that after granting an 1122 unlimited inactivity timeout in this way, at any point the server may 1123 revise that inactivity timeout by sending a new Keepalive TLV 1124 dictating new Session Timeout values to the client. 1126 A server will abort an idle client session after twice the inactivity 1127 timeout value, or five seconds, whichever is greater. In the case of 1128 a zero inactivity timeout value, this means that if a client fails to 1129 close an idle client session then the server will forcibly abort the 1130 idle session after five seconds. 1132 5.5. The Keepalive Interval 1134 The purpose of the keepalive interval is to manage the generation of 1135 sufficient messages to maintain state in middleboxes (such at NAT 1136 gateways or firewalls) and for the client and server to periodically 1137 verify that they still have connectivity to each other. This allows 1138 them to clean up state when connectivity is lost, and attempt re- 1139 connection if appropriate. 1141 5.5.1. Keepalive Interval Expiry 1143 If, at any time during the life of the DSO Session, the keepalive 1144 interval value (i.e., 15 seconds by default) elapses without any DNS 1145 messages being sent or received on a DSO Session, the client MUST 1146 take action to keep the DSO Session alive, by sending a DSO Keepalive 1147 message (see Section 6.1). A DSO Keepalive message exchange resets 1148 only the keepalive timer, not the inactivity timer. 1150 If a client disconnects from the network abruptly, without cleanly 1151 closing its DSO Session, leaving a long-lived operation uncanceled, 1152 the server learns of this after failing to receive the required 1153 keepalive traffic from that client. If, at any time during the life 1154 of the DSO Session, twice the keepalive interval value (i.e., 30 1155 seconds by default) elapses without any DNS messages being sent or 1156 received on a DSO Session, the server SHOULD consider the client 1157 delinquent, and SHOULD forcibly abort the DSO Session. 1159 5.5.2. Values for the Keepalive Interval 1161 For the keepalive interval value, lower values result in a higher 1162 volume of keepalive traffic. Higher values of the keepalive interval 1163 reduce traffic and CPU load, but have minimal effect on the memory 1164 burden at the server, because clients keep a DSO Session open for the 1165 same length of time (determined by the inactivity timeout) regardless 1166 of the level of keepalive traffic required. 1168 It may be appropriate for clients and servers to select different 1169 keepalive interval values depending on the nature of the network they 1170 are on. 1172 A corporate DNS server that knows it is serving only clients on the 1173 internal network, with no intervening NAT gateways or firewalls, can 1174 impose a higher keepalive interval, because frequent keepalive 1175 traffic is not required. 1177 A public DNS server that is serving primarily residential consumer 1178 clients, where it is likely there will be a NAT gateway on the path, 1179 may impose a lower keepalive interval, to generate more frequent 1180 keepalive traffic. 1182 A smart client may be adaptive to its environment. A client using a 1183 private IPv4 address [RFC1918] to communicate with a DNS server at an 1184 address outside that IPv4 private address block, may conclude that 1185 there is likely to be a NAT gateway on the path, and accordingly 1186 request a lower keepalive interval. 1188 By default it is RECOMMENDED that clients request, and servers grant, 1189 a keepalive interval of 60 minutes. This keepalive interval provides 1190 for reasonably timely detection if a client abruptly disconnects 1191 without cleanly closing the session, and is sufficient to maintain 1192 state in firewalls and NAT gateways that follow the IETF recommended 1193 Best Current Practice that the "established connection idle-timeout" 1194 used by middleboxes be at least 2 hours 4 minutes [RFC5382]. 1196 Note that the lower the keepalive interval value, the higher the load 1197 on client and server. For example, a hypothetical keepalive interval 1198 value of 100ms would result in a continuous stream of at least ten 1199 messages per second, in both directions, to keep the DSO Session 1200 alive. And, in this extreme example, a single packet loss and 1201 retransmission over a long path could introduce a momentary pause in 1202 the stream of messages, long enough to cause the server to 1203 overzealously abort the connection. 1205 Because of this concern, the server MUST NOT send a Keepalive message 1206 (either a response to a client-initiated request, or a server- 1207 initiated message) with a keepalive interval value less than ten 1208 seconds. If a client receives a Keepalive message specifying a 1209 keepalive interval value less than ten seconds this is an error and 1210 the client MUST forcibly abort the connection immediately. 1212 A keepalive interval value of 0xFFFFFFFF (2^32-1 milliseconds, 1213 approximately 49.7 days) informs the client that it should generate 1214 no keepalive traffic. Note that after signaling that the client 1215 should generate no keepalive traffic in this way, at any point the 1216 server may revise that keepalive traffic requirement by sending a new 1217 Keepalive TLV dictating new Session Timeout values to the client. 1219 5.6. Server-Initiated Session Termination 1221 In addition to cancelling individual operations selectively (see 1222 Section 4.5) there are also occasions where a server may need to 1223 terminate one or more entire sessions wholesale. An entire session 1224 may need to be terminated if the client is defective in some way, or 1225 departs from the network without closing its session. Sessions may 1226 also need to be terminated if the server becomes overloaded, or if 1227 the server is reconfigured and lacks the ability to be selective 1228 about which operations need to be cancelled. 1230 This section discusses various reasons a session may be terminated, 1231 and the mechanisms for doing so. 1233 5.6.1. Server-Initiated Session Termination on Error 1235 After sending an error response to a client, the server MAY end the 1236 DSO Session, or may allow the DSO Session to remain open. For error 1237 conditions that only affect the single operation in question, the 1238 server SHOULD return an error response to the client and leave the 1239 DSO Session open for further operations. For error conditions that 1240 are likely to make all operations unsuccessful in the immediate 1241 future, the server SHOULD return an error response to the client and 1242 then end the DSO Session by sending a Retry Delay request message, as 1243 described in Section 5.6.3. 1245 Upon receiving an error response from the server, a client SHOULD NOT 1246 automatically close the DSO Session. An error relating to one 1247 particular operation on a DSO Session does not necessarily imply that 1248 all other operations on that DSO Session have also failed, or that 1249 future operations will fail. The client should assume that the 1250 server will make its own decision about whether or not to end the DSO 1251 Session, based on the server's determination of whether the error 1252 condition pertains to this particular operation, or would also apply 1253 to any subsequent operations. If the server does not end the DSO 1254 Session by sending the client a Retry Delay message (see 1255 Section 5.6.3) then the client SHOULD continue to use that DSO 1256 Session for subsequent operations. 1258 5.6.2. Server-Initiated Session Termination on Overload 1260 A server MUST NOT close a DSO Session with a client, except in 1261 certain exceptional circumstances, as outlined below. In normal 1262 operation, closing a DSO Session is the client's responsibility. The 1263 client makes the determination of when to close a DSO Session based 1264 on an evaluation of both its own needs, and the inactivity timeout 1265 value dictated by the server. 1267 Some exceptional situations where a server may terminate a DSO 1268 Session include: 1270 o The server application software or underlying operating system is 1271 shutting down or restarting. 1273 o The server application software terminates unexpectedly (perhaps 1274 due to a bug that makes it crash). 1276 o The server is undergoing a reconfiguration or maintenance 1277 procedure, that, due to the way the server software is 1278 implemented, requires clients to be disconnected. For example, 1279 some software is implemented such that it reads a configuration 1280 file at startup, and changing the server's configuration entails 1281 modifying the configuration file and then killing and restarting 1282 the server software, which generally entails a loss of network 1283 connections. 1285 o The client fails to meets its obligation to generate keepalive 1286 traffic or close an inactive session by the prescribed time (twice 1287 the time interval dictated by the server, or five seconds, 1288 whichever is greater, as described in Section 5.2). 1290 o The client sends a grossly invalid or malformed request that is 1291 indicative of a seriously defective client implementation (see 1292 Section 5.6.1). 1294 o The server is over capacity and needs to shed some load (see 1295 Section 5.6.3). 1297 When a server has to close a DSO Session with a client (because of 1298 exceptional circumstances such as those outlined above) the server 1299 SHOULD, whenever possible, send a Retry Delay request message (see 1300 below) informing the client of the reason for the DSO Session being 1301 closed, and allow the client five seconds to receive it before the 1302 server resorts to forcibly aborting the connection. 1304 5.6.3. Server-Initiated Retry Delay Request Message 1306 There may be rare cases where a server is overloaded and wishes to 1307 shed load. If a server is low on resources it MAY simply terminate a 1308 client connection by forcibly aborting it. However, the likely 1309 behavior of the client may be simply to to treat this as a network 1310 failure and reconnect immediately, putting more burden on the server. 1312 Therefore to avoid this reconnection implosion, a server SHOULD 1313 instead choose to shed client load by sending a Retry Delay request 1314 message, with an RCODE of SERVFAIL, to inform the client of the 1315 overload situation. The format of the Retry Delay TLV is described 1316 in Section 6.2. After sending a Retry Delay request message, the 1317 server MUST NOT send any further messages on that DSO Session. 1319 Upon receipt of a Retry Delay request from the server, the client 1320 MUST make note of the reconnect delay for this server, and then 1321 immediately close the connection gracefully. 1323 After sending a Retry Delay request message the server SHOULD allow 1324 the client five seconds to close the connection, and if the client 1325 has not closed the connection after five seconds then the server 1326 SHOULD forcibly abort the connection. 1328 A Retry Delay request message MUST NOT be initiated by a client. If 1329 a server receives a Retry Delay request message this is an error and 1330 the server MUST forcibly abort the connection immediately. 1332 5.6.3.1. Outstanding Operations 1334 At the moment a server chooses to initiate a Retry Delay request 1335 message there may be DNS requests already in flight from client to 1336 server on this DSO Session, which will arrive at the server after its 1337 Retry Delay request message has been sent. The server MUST silently 1338 ignore such incoming requests, and MUST NOT generate any response 1339 messages for them. When the Retry Delay request message from the 1340 server arrives at the client, the client will determine that any DNS 1341 requests it previously sent on this DSO Session, that have not yet 1342 received a response, now will certainly not be receiving any 1343 response. Such requests should be considered failed, and should be 1344 retried at a later time, as appropriate. 1346 In the case where some, but not all, of the existing operations on a 1347 DSO Session have become invalid (perhaps because the server has been 1348 reconfigured and is no longer authoritative for some of the names), 1349 but the server is terminating all DSO Sessions en masse with a 1350 REFUSED (5) RCODE, the RECONNECT DELAY MAY be zero, indicating that 1351 the clients SHOULD immediately attempt to re-establish operations. 1353 It is likely that some of the attempts will be successful and some 1354 will not, depending on the nature of the reconfiguration. 1356 In the case where a server is terminating a large number of DSO 1357 Sessions at once (e.g., if the system is restarting) and the server 1358 doesn't want to be inundated with a flood of simultaneous retries, it 1359 SHOULD send different RECONNECT delay values to each client. These 1360 adjustments MAY be selected randomly, pseudorandomly, or 1361 deterministically (e.g., incrementing the time value by one tenth of 1362 a second for each successive client, yielding a post-restart 1363 reconnection rate of ten clients per second). 1365 5.6.3.2. Client Reconnection 1367 After a DSO Session is closed by the server, the client SHOULD try to 1368 reconnect, to that server, or to another suitable server, if more 1369 than one is available. If reconnecting to the same server, the 1370 client MUST respect the indicated delay before attempting to 1371 reconnect. 1373 If a particular server does not want a client to reconnect (the 1374 server is being de-commissioned), it SHOULD set the retry delay to 1375 the maximum value (which is approximately 49.7 days). If the server 1376 will only be out of service for a maintenance period, it should use a 1377 value closer to the expected maintenance window and not default to a 1378 very large delay value or clients may not attempt to reconnect after 1379 it resumes service. 1381 6. Base TLVs for DNS Stateful Operations 1383 This section describes the three base TLVs for DNS Stateful 1384 Operations: Keepalive, Retry Delay, and Encryption Padding. 1386 6.1. Keepalive TLV 1388 The Keepalive TLV (DSO-TYPE=1) performs two functions: to reset the 1389 keepalive timer for the DSO Session, and to establish the values for 1390 the Session Timeouts. 1392 The TYPE-DEPENDENT DATA for the the Keepalive TLV is as follows: 1394 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1395 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 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | INACTIVITY TIMEOUT (32 bits) | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | KEEPALIVE INTERVAL (32 bits) | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 INACTIVITY TIMEOUT: The inactivity timeout for the current DSO 1403 Session, specified as a 32-bit unsigned integer in network (big 1404 endian) byte order in units of milliseconds. This is the timeout 1405 at which the client MUST begin closing an inactive DSO Session. 1406 The inactivity timeout can be any value of the server's choosing. 1407 If the client does not gracefully close an inactive DSO Session, 1408 then after twice this interval, or five seconds, whichever is 1409 greater, the server will forcibly abort the connection. 1411 KEEPALIVE INTERVAL: The keepalive interval for the current DSO 1412 Session, specified as a 32-bit unsigned integer in network (big 1413 endian) byte order in units of milliseconds. This is the interval 1414 at which a client MUST generate keepalive traffic to maintain 1415 connection state. The keepalive interval MUST NOT be less than 1416 ten seconds. If the client does not generate the mandated 1417 keepalive traffic, then after twice this interval the server will 1418 forcibly abort the connection. Since the minimum allowed 1419 keepalive interval is ten seconds, the minimum time at which a 1420 server will forcibly disconnect a client for failing to generate 1421 the mandated keepalive traffic is twenty seconds. 1423 The transmission or reception of DSO Keepalive messages (i.e., 1424 messages where the Keepalive TLV is the first TLV) reset only the 1425 keepalive timer, not the inactivity timer. The reason for this is 1426 that periodic Keepalive messages are sent for the sole purpose of 1427 keeping a DSO Session alive, when that DSO Session has current or 1428 recent non-maintenance activity that warrants keeping that DSO 1429 Session alive. Sending keepalive traffic itself is not considered a 1430 client activity; it is considered a maintenance activity that is 1431 performed in service of other client activities. If keepalive 1432 traffic itself were to reset the inactivity timer, then that would 1433 create a circular livelock where keepalive traffic would be sent 1434 indefinitely to keep a DSO Session alive, where the only activity on 1435 that DSO Session would be the keepalive traffic keeping the DSO 1436 Session alive so that further keepalive traffic can be sent. For a 1437 DSO Session to be considered active, it must be carrying something 1438 more than just keepalive traffic. This is why merely sending or 1439 receiving a Keepalive message does not reset the inactivity timer. 1441 When sent by a client, the Keepalive request message MUST be sent as 1442 an acknowledged request, with a nonzero MESSAGE ID. If a server 1443 receives a Keepalive request message with a zero MESSAGE ID then this 1444 is a fatal error and the server MUST forcibly abort the connection 1445 immediately. The Keepalive request message resets a DSO Session's 1446 keepalive timer, and at the same time communicates to the server the 1447 the client's requested Session Timeout values. In a server response 1448 to a client-initiated Keepalive request message, the Session Timeouts 1449 contain the server's chosen values from this point forward in the DSO 1450 Session, which the client MUST respect. This is modeled after the 1451 DHCP protocol, where the client requests a certain lease lifetime 1452 using DHCP option 51 [RFC2132], but the server is the ultimate 1453 authority for deciding what lease lifetime is actually granted. 1455 When a client is sending its second and subsequent Keepalive DSO 1456 requests to the server, the client SHOULD continue to request its 1457 preferred values each time. This allows flexibility, so that if 1458 conditions change during the lifetime of a DSO Session, the server 1459 can adapt its responses to better fit the client's needs. 1461 Once a DSO Session is in progress (see Section 4) a Keepalive request 1462 message MAY be initiated by a server. When sent by a server, the 1463 Keepalive request message MUST be sent as an unacknowledged request, 1464 with the MESSAGE ID set to zero. The client MUST NOT generate a 1465 response to a server-initiated DSO Keepalive message. If a client 1466 receives a Keepalive request message with a nonzero MESSAGE ID then 1467 this is a fatal error and the client MUST forcibly abort the 1468 connection immediately. The Keepalive request message from the 1469 server resets a DSO Session's keepalive timer, and at the same time 1470 unilaterally informs the client of the new Session Timeout values to 1471 use from this point forward in this DSO Session. No client DSO 1472 response message to this unilateral declaration is required or 1473 allowed. 1475 The Keepalive TLV is not used as a request message Additional TLV. 1477 In response messages the Keepalive TLV is used only as a Response 1478 Primary TLV, replying to a Keepalive request message from the client. 1479 A Keepalive TLV MUST NOT be added as to other responses a Response 1480 Additional TLV. If the server wishes to update a client's Session 1481 Timeout values other than in response to a Keepalive request message 1482 from the client, then it does so by sending an unacknowledged 1483 Keepalive request message of its own, as described above. 1485 It is not required that the Keepalive TLV be used in every DSO 1486 Session. While many DNS Stateful operations will be used in 1487 conjunction with a long-lived session state, not all DNS Stateful 1488 operations require long-lived session state, and in some cases the 1489 default 15-second value for both the inactivity timeout and keepalive 1490 interval may be perfectly appropriate. However, note that for 1491 clients that implement only the TLVs defined in this document it is 1492 the only way for a client to initiate a DSO Session. 1494 6.1.1. Client handling of received Session Timeout values 1496 When a client receives a response to its client-initiated DSO 1497 Keepalive message, or receives a server-initiated DSO Keepalive 1498 message, the client has then received Session Timeout values dictated 1499 by the server. The two timeout values contained in the DSO Keepalive 1500 TLV from the server may each be higher, lower, or the same as the 1501 respective Session Timeout values the client previously had for this 1502 DSO Session. 1504 In the case of the keepalive timer, the handling of the received 1505 value is straightforward. The act of receiving the message 1506 containing the DSO Keepalive TLV itself resets the keepalive timer 1507 and updates the keepalive interval for the DSO Session. The new 1508 keepalive interval indicates the maximum time that may elapse before 1509 another message must be sent or received on this DSO Session, if the 1510 DSO Session is to remain alive. 1512 In the case of the inactivity timeout, the handling of the received 1513 value is a little more subtle, though the meaning of the inactivity 1514 timeout is unchanged -- it still indicates the maximum permissible 1515 time allowed without useful activity on a DSO Session. The act of 1516 receiving the message containing the DSO Keepalive TLV does not 1517 itself reset the inactivity timer. The time elapsed since the last 1518 useful activity on this DSO Session is unaffected by exchange of DSO 1519 Keepalive messages. The new inactivity timeout value in the DSO 1520 Keepalive TLV in the received message does update the timeout 1521 associated with the running inactivity timer; that becomes the new 1522 maximum permissible time without activity on a DSO Session. 1524 o If the current inactivity timer value is not greater than the new 1525 inactivity timeout, then the DSO Session may remain open for now. 1526 When the inactivity timer value exceeds the new inactivity 1527 timeout, the client MUST then begin closing the DSO Session, as 1528 described above. 1530 o If the current inactivity timer value is already greater than the 1531 new inactivity timeout, then this DSO Session has already been 1532 inactive for longer than the server permits, and the client MUST 1533 immediately begin closing this DSO Session. 1535 o If the current inactivity timer value is already more than twice 1536 the new inactivity timeout, then the client is immediately 1537 considered delinquent (this DSO Session is immediately eligible to 1538 be forcibly terminated by the server) and the client MUST 1539 immediately begin closing this DSO Session. However if a server 1540 abruptly reduces the inactivity timeout in this way, then, to give 1541 the client time to close the connection gracefully before the 1542 server resorts to forcibly aborting it, the server SHOULD give the 1543 client an additional grace period of one quarter of the new 1544 inactivity timeout, or five seconds, whichever is greater. 1546 6.1.2. Relation to EDNS(0) TCP Keepalive Option 1548 The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has 1549 similar intent to the EDNS(0) TCP Keepalive Option [RFC7828]. A 1550 client/server pair that supports DSO MUST NOT use the EDNS(0) TCP 1551 KeepAlive option within any message after a DSO Session has been 1552 established. Once a DSO Session has been established, if either 1553 client or server receives a DNS message over the DSO Session that 1554 contains an EDNS(0) TCP Keepalive option, this is an error and the 1555 receiver of the EDNS(0) TCP Keepalive option MUST forcibly abort the 1556 connection immediately. 1558 6.2. Retry Delay TLV 1560 The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary TLV 1561 (unacknowledged) in a server-to-client message, or as a Response 1562 Additional TLV in a server-to-client response to a client-to-server 1563 request message. 1565 The TYPE-DEPENDENT DATA for the the Retry Delay TLV is as follows: 1567 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1568 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 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | RETRY DELAY (32 bits) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 RETRY DELAY: A time value, specified as a 32-bit unsigned integer in 1574 network (big endian) byte order in units of milliseconds, within 1575 which the client MUST NOT retry this operation, or retry 1576 connecting to this server. 1578 The RECOMMENDED value is 10 seconds. 1580 6.2.1. Retry Delay TLV used as a Primary TLV 1582 When sent in a DSO request message, from server to client, the Retry 1583 Delay TLV (0) is used as a Primary TLV. It is used by a server to 1584 instruct a client to close the DSO Session and underlying connection, 1585 and not to reconnect for the indicated time interval. 1587 In this case it applies to the DSO Session as a whole, and the client 1588 MUST begin closing the DSO Session, as described in Section 5.6.3. 1589 The RCODE in the message header MUST indicate the reason for the 1590 termination: 1592 o NOERROR indicates a routine shutdown. 1594 o SERVFAIL indicates that the server is overloaded due to resource 1595 exhaustion. 1597 o REFUSED indicates that the server has been reconfigured and is no 1598 longer able to perform one or more of the functions currently 1599 being performed on this DSO Session (for example, a DNS Push 1600 Notification server could be reconfigured such that is is no 1601 longer accepting DNS Push Notification requests for one or more of 1602 the currently subscribed names). 1604 This document specifies only these three RCODE values for Retry Delay 1605 request. Servers sending Retry Delay requests SHOULD use one of 1606 these three values. However, future circumstances may create 1607 situations where other RCODE values are appropriate in Retry Delay 1608 requests, so clients MUST be prepared to accept Retry Delay requests 1609 with any RCODE value. 1611 A Retry Delay request is an unacknowledged request message; the 1612 MESSAGE ID MUST be set to zero in the request and the client MUST NOT 1613 send a response. 1615 6.2.2. Retry Delay TLV used as a Response Additional TLV 1617 In the case of a client request that returns a nonzero RCODE value, 1618 the server MAY append a Retry Delay TLV (0) to the response, 1619 indicating the time interval during which the client SHOULD NOT 1620 attempt this operation again. 1622 The indicated time interval during which the client SHOULD NOT retry 1623 applies only to the failed operation, not to the DSO Session as a 1624 whole. 1626 6.2.3. Retry Delay TLV is used by server only 1628 A client MUST NOT send a Retry Delay TLV to a server, either in a DSO 1629 request message, or in a DSO response message. If a server receives 1630 a DSO message containing a Retry Delay TLV, this is a fatal error and 1631 the server MUST forcibly abort the connection immediately. 1633 6.3. Encryption Padding TLV 1635 The Encryption Padding TLV (DSO-TYPE=3) can only be used as an 1636 Additional or Response Additional TLV. It is only applicable when 1637 the DSO Transport layer uses encryption such as TLS. 1639 The TYPE-DEPENDENT DATA for the the Padding TLV is optional and is a 1640 variable length field containing non-specified values. A DATA LENGTH 1641 of 0 essentially provides for 4 octets of padding (the minimum 1642 amount). 1644 1 1 1 1 1 1 1645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1646 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1647 / / 1648 / VARIABLE NUMBER OF OCTETS / 1649 / / 1650 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1652 As specified for the EDNS(0) Padding Option [RFC7830] the PADDING 1653 octets SHOULD be set to 0x00. Other values MAY be used, for example, 1654 in cases where there is a concern that the padded message could be 1655 subject to compression before encryption. PADDING octets of any 1656 value MUST be accepted in the messages received. 1658 The Encryption Padding TLV may be included in either a DSO request, 1659 response, or both. As specified for the EDNS(0) Padding Option 1660 [RFC7830] if a request is received with an Encryption Padding TLV, 1661 then the response MUST also include an Encryption Padding TLV. 1663 The length of padding is intentionally not specified in this document 1664 and is a function of current best practices with respect to the type 1665 and length of data in the preceding TLVs 1666 [I-D.ietf-dprive-padding-policy]. 1668 7. Summary 1670 This section summarizes some noteworthy highlights about various 1671 components of the DSO protocol. 1673 7.1. MESSAGE ID 1675 In DSO Request Messages the MESSAGE ID may be either nonzero 1676 (signaling that the responder MUST generate a response) or zero 1677 (signaling that the responder MUST NOT generate a response). 1679 In DSO Response Messages the MESSAGE ID MUST NOT be zero (since this 1680 would be a response to a request that had indicated that a response 1681 is not allowed). 1683 The table below illustrates the legal combinations: 1685 +--------------------+-------------------+ 1686 | Nonzero MESSAGE ID | Zero MESSAGE ID | 1687 +----------------------+--------------------+-------------------+ 1688 | DSO Request Message | X | X | 1689 +----------------------+--------------------+-------------------+ 1690 | DSO Response Message | X | | 1691 +----------------------+--------------------+-------------------+ 1693 7.2. TLV Usage 1695 The table below indicates, for each of the three TLVs defined in this 1696 document, whether they are valid in each of ten different contexts. 1698 The first five contexts are requests from client to server, and the 1699 corresponding responses from server back to client: 1701 o C-P - Primary TLV, sent in DSO Request message, from client to 1702 server, with nonzero MESSAGE ID indicating that this request MUST 1703 generate response message. 1705 o C-U - Primary TLV (unacknowledged), sent in DSO Request message, 1706 from client to server, with zero MESSAGE ID indicating that this 1707 request MUST NOT generate response message. 1709 o C-A - Additional TLV, optionally added to request message from 1710 client to server. 1712 o CRP - Response Primary TLV, included in response message sent to 1713 back the client (in response to a client "C-P" request with 1714 nonzero MESSAGE ID indicating that a response is required) where 1715 the DSO-TYPE of the Response TLV matches the DSO-TYPE of the 1716 Primary TLV in the request. 1718 o CRA - Response Additional TLV, included in response message sent 1719 to back the client (in response to a client "C-P" request with 1720 nonzero MESSAGE ID indicating that a response is required) where 1721 the DSO-TYPE of the Response TLV does not match the DSO-TYPE of 1722 the Primary TLV in the request. 1724 The second five contexts are the reverse: requests from server to 1725 client, and the corresponding responses from client back to server. 1727 +-------------------------+-------------------------+ 1728 | C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA | 1729 +------------+-------------------------+-------------------------+ 1730 | KeepAlive | X X | X | 1731 +------------+-------------------------+-------------------------+ 1732 | RetryDelay | X | X | 1733 +------------+-------------------------+-------------------------+ 1734 | Padding | X X | X X | 1735 +------------+-------------------------+-------------------------+ 1737 It is recommended that definitions of future TLVs include a similar 1738 table summarizing the contexts where the new TLV is valid. 1740 7.3. Inactivity Timeout 1742 The Inactivity Timeout may have any 32-bit unsigned integer value. 1744 The value zero informs the client that it should not speculatively 1745 maintain idle connections at all, and as soon as the client has 1746 completed the operation or operations relating to this server, the 1747 client should immediately begin closing this session. 1749 The maximum possible value, 0xFFFFFFFF (2^32-1 milliseconds, 1750 approximately 49.7 days), informs the client that it may keep an idle 1751 connection open as long as it wishes. 1753 The Inactivity timer is reset by any message *except* the Keepalive 1754 TLV, and remains cleared any time that an operation is outstanding. 1756 7.4. Keepalive Interval 1758 The Keepalive Interval is a 32-bit unsigned integer value, with a 1759 minimum value of 10,000 milliseconds (10 seconds). 1761 The maximum possible value, 0xFFFFFFFF (2^32-1 milliseconds, 1762 approximately 49.7 days), informs the client that it should generate 1763 no keepalive traffic. 1765 Any message exchange (including the Keepalive TLV) resets the 1766 Keepalive timer. 1768 8. IANA Considerations 1770 8.1. DSO OPCODE Registration 1772 The IANA is directed to record the value (tentatively) 6 for the 1773 DSO OPCODE in the DNS OPCODE Registry. 1775 8.2. DSO RCODE Registration 1777 The IANA is directed to record the value (tentatively) 11 for the 1778 DSONOTIMP error code in the DNS RCODE Registry. 1780 8.3. DSO Type Code Registry 1782 The IANA is directed to create the 16-bit DSO Type Code Registry, 1783 with initial (hexadecimal) values as shown below: 1785 +-----------+--------------------------------+----------+-----------+ 1786 | Type | Name | Status | Reference | 1787 +-----------+--------------------------------+----------+-----------+ 1788 | 0000 | Reserved | Standard | RFC-TBD | 1789 | | | | | 1790 | 0001 | KeepAlive | Standard | RFC-TBD | 1791 | | | | | 1792 | 0002 | RetryDelay | Standard | RFC-TBD | 1793 | | | | | 1794 | 0003 | EncryptionPadding | Standard | RFC-TBD | 1795 | | | | | 1796 | 0004-003F | Unassigned, reserved for | | | 1797 | | DSO session-management TLVs | | | 1798 | | | | | 1799 | 0040-F7FF | Unassigned | | | 1800 | | | | | 1801 | F800-FBFF | Reserved for | | | 1802 | | experimental/local use | | | 1803 | | | | | 1804 | FC00-FFFF | Reserved for future expansion | | | 1805 +-----------+--------------------------------+----------+-----------+ 1807 DSO Type Code zero is reserved and is not currently intended for 1808 allocation. 1810 Registrations of new DSO Type Codes in the "Reserved for DSO session- 1811 management" range 0004-003F and the "Reserved for future expansion" 1812 range FC00-FFFF require publication of an IETF Standards Action 1813 document [RFC5226]. 1815 Requests to register additional new DSO Type Codes in the 1816 "Unassigned" range 0040-F7FF are to be recorded by IANA after 1817 consultation with the registry's Designated Expert [RFC5226] at that 1818 time. At the time of publication of this document, the Designated 1819 Expert for the newly created DSO Type Code registry is [*TBD*]. 1821 DSO Type Codes in the "experimental/local" range F800-FBFF may be 1822 used as Experimental Use or Private Use values [RFC5226] and may be 1823 used freely for development purposes, or for other purposes within a 1824 single site. No attempt is made to prevent multiple sites from using 1825 the same value in different (and incompatible) ways. There is no 1826 need for IANA to review such assignments (since IANA does not record 1827 them) and assignments are not generally useful for broad 1828 interoperability. It is the responsibility of the sites making use 1829 of "experimental/local" values to ensure that no conflicts occur 1830 within the intended scope of use. 1832 9. Security Considerations 1834 If this mechanism is to be used with DNS over TLS, then these 1835 messages are subject to the same constraints as any other DNS-over- 1836 TLS messages and MUST NOT be sent in the clear before the TLS session 1837 is established. 1839 The data field of the "Encryption Padding" TLV could be used as a 1840 covert channel. 1842 10. Acknowledgements 1844 Thanks to Tim Chown, Ralph Droms, Jan Komissar, Manju Shankar Rao, 1845 and Ted Lemon for their helpful contributions to this document. 1847 11. References 1849 11.1. Normative References 1851 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1852 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1853 . 1855 [RFC1035] Mockapetris, P., "Domain names - implementation and 1856 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1857 November 1987, . 1859 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1860 and E. Lear, "Address Allocation for Private Internets", 1861 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1862 . 1864 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1865 Requirement Levels", BCP 14, RFC 2119, 1866 DOI 10.17487/RFC2119, March 1997, 1867 . 1869 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1870 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1871 . 1873 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1874 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1875 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1876 . 1878 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1879 IANA Considerations Section in RFCs", RFC 5226, 1880 DOI 10.17487/RFC5226, May 2008, 1881 . 1883 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1884 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1885 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1886 . 1888 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1889 for DNS (EDNS(0))", STD 75, RFC 6891, 1890 DOI 10.17487/RFC6891, April 2013, 1891 . 1893 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1894 D. Wessels, "DNS Transport over TCP - Implementation 1895 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1896 . 1898 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1899 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1900 DOI 10.17487/RFC7828, April 2016, 1901 . 1903 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1904 DOI 10.17487/RFC7830, May 2016, 1905 . 1907 11.2. Informative References 1909 [I-D.ietf-dnssd-push] 1910 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1911 draft-ietf-dnssd-push-13 (work in progress), October 2017. 1913 [I-D.ietf-dprive-padding-policy] 1914 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 1915 dprive-padding-policy-03 (work in progress), January 2018. 1917 [I-D.ietf-tls-tls13] 1918 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1919 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 1920 January 2018. 1922 [I-D.sctl-dnssd-mdns-relay] 1923 Cheshire, S. and T. Lemon, "Multicast DNS Discovery 1924 Relay", draft-sctl-dnssd-mdns-relay-02 (work in progress), 1925 November 2017. 1927 [NagleDA] Cheshire, S., "TCP Performance problems caused by 1928 interaction between Nagle's Algorithm and Delayed ACK", 1929 May 2005, 1930 . 1932 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1933 DOI 10.17487/RFC0768, August 1980, 1934 . 1936 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1937 Communication Layers", STD 3, RFC 1122, 1938 DOI 10.17487/RFC1122, October 1989, 1939 . 1941 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1942 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1943 . 1945 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1946 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1947 . 1949 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1950 and P. Hoffman, "Specification for DNS over Transport 1951 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1952 2016, . 1954 Authors' Addresses 1956 Ray Bellis 1957 Internet Systems Consortium, Inc. 1958 950 Charter Street 1959 Redwood City CA 94063 1960 USA 1962 Phone: +1 650 423 1200 1963 Email: ray@isc.org 1965 Stuart Cheshire 1966 Apple Inc. 1967 1 Infinite Loop 1968 Cupertino CA 95014 1969 USA 1971 Phone: +1 408 974 3207 1972 Email: cheshire@apple.com 1974 John Dickinson 1975 Sinodun Internet Technologies 1976 Magadalen Centre 1977 Oxford Science Park 1978 Oxford OX4 4GA 1979 United Kingdom 1981 Email: jad@sinodun.com 1982 Sara Dickinson 1983 Sinodun Internet Technologies 1984 Magadalen Centre 1985 Oxford Science Park 1986 Oxford OX4 4GA 1987 United Kingdom 1989 Email: sara@sinodun.com 1991 Allison Mankin 1992 Salesforce 1994 Email: allison.mankin@gmail.com 1996 Tom Pusateri 1997 Unaffiliated 1998 Raleigh NC 27608 1999 USA 2001 Phone: +1 919 867 1330 2002 Email: pusateri@bangj.com