idnits 2.17.1 draft-ietf-dnsop-session-signal-04.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 (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 (September 13, 2017) is 2410 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-12 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-padding-policy-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 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: March 17, 2018 S. Dickinson 8 Sinodun 9 A. Mankin 10 Salesforce 11 T. Pusateri 12 Unaffiliated 13 September 13, 2017 15 DNS Stateful Operations 16 draft-ietf-dnsop-session-signal-04 18 Abstract 20 This document defines a new DNS Stateful Operation OPCODE used to 21 communicate operations within persistent stateful sessions, expressed 22 using type-length-value (TLV) syntax, and defines an initial set of 23 TLVs used to manage session timeouts and termination. This mechanism 24 is intended to reduce the overhead of existing "per-packet" signaling 25 mechanisms with "per-message" semantics as well as defining new 26 stateful operations not defined in EDNS(0). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 17, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. DSO Session Establishment . . . . . . . . . . . . . . . . 7 67 4.1.1. Middle-box Considerations . . . . . . . . . . . . . . 8 68 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2.3. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 12 72 4.3. Message Handling . . . . . . . . . . . . . . . . . . . . 13 73 5. Keepalive Operation TLV . . . . . . . . . . . . . . . . . . . 14 74 5.1. Client handling of received Session Timeout values . . . 16 75 5.2. Relation to EDNS(0) TCP Keepalive Option . . . . . . . . 17 76 6. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . . . 17 77 6.1. Use as an Operation TLV . . . . . . . . . . . . . . . . . 18 78 6.2. Use as a Modifier TLV . . . . . . . . . . . . . . . . . . 19 79 7. Encryption Padding TLV . . . . . . . . . . . . . . . . . . . 19 80 8. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 20 81 8.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 20 82 8.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 20 83 8.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 20 84 8.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 21 85 8.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 21 86 8.4.2. Values for the Inactivity Timeout . . . . . . . . . . 22 87 8.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 23 88 8.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 23 89 8.5.2. Values for the Keepalive Interval . . . . . . . . . . 23 90 8.6. Server-Initiated Termination on Error . . . . . . . . . . 24 91 8.7. Client Behaviour in Receiving an Error . . . . . . . . . 25 92 8.8. Server-Initiated Termination on Overload . . . . . . . . 25 93 8.9. Retry Delay Operation TLV . . . . . . . . . . . . . . . . 26 94 8.9.1. Outstanding Operations . . . . . . . . . . . . . . . 26 95 8.9.2. Client Reconnection . . . . . . . . . . . . . . . . . 27 96 9. Connection Sharing . . . . . . . . . . . . . . . . . . . . . 27 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 98 10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 28 99 10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 28 100 10.3. DSO Type Codes Registry . . . . . . . . . . . . . . . . 28 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 105 13.2. Informative References . . . . . . . . . . . . . . . . . 31 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 108 1. Introduction 110 The use of transports for DNS other than UDP is being increasingly 111 specified, for example, DNS over TCP [RFC1035][RFC7766] and DNS over 112 TLS [RFC7858]. Such transports can offer persistent, long-lived 113 sessions and therefore when using them for transporting DNS messages 114 it is of benefit to have a mechanism that can establish parameters 115 associated with those sessions, such as timeouts. In such situations 116 it is also advantageous to support server initiated messages. 118 The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is 119 explicitly defined to only have "per-message" semantics. Whilst 120 EDNS(0) has been used to signal at least one session related 121 parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is 122 less than optimal due to the restrictions imposed by the EDNS(0) 123 semantics and the lack of server-initiated signalling. For example, 124 a server cannot arbitrarily instruct a client to close a connection 125 because the server can only send EDNS(0) options in responses to 126 queries that contained EDNS(0) options. 128 This document defines a new DNS Stateful Operation OPCODE used to 129 carry operations within persistent stateful connections, expressed 130 using type-length-value (TLV) syntax, and defines an initial set of 131 TLVs including ones used to manage session timeouts and termination. 133 This new format has distinct advantages over an RR based format 134 because it is more explicit and more compact. Each TLV definition is 135 specific to the use case, and as a result contains no redundant or 136 overloaded fields. Importantly, it completely avoids conflating DNS 137 Stateful Operations in anyway with normal DNS operations or with 138 existing EDNS(0) based functionality. A goal of this approach is to 139 avoid the operational issues that have befallen EDNS(0), particularly 140 relating to middle-box behaviour. 142 With EDNS(0), multiple options may be packed into a single OPT 143 pseudo-RR, and there is no generalized mechanism for a client to be 144 able to tell whether a server has processed or otherwise acted upon 145 each individual option within the combined OPT RR. The 146 specifications for each individual option need to define how each 147 different option is to be acknowledged, if necessary. 149 With DNS Stateful Operations, in contrast, there is no compelling 150 motivation to pack multiple operations into a single message for 151 efficiency reasons. Each Stateful operation is communicated in its 152 own separate DNS message, and the transport protocol can take care of 153 packing separate DNS messages into a single IP packet if appropriate. 154 For example, TCP can pack multiple small DNS messages into a single 155 TCP segment. The RCODE in each response message indicates the 156 success or failure of the operation in question. 158 It should be noted that the message format for DNS Stateful 159 Operations (see Section 4.2) differs from the traditional DNS packet 160 format used for standard queries and responses. The standard twelve- 161 octet header is used, but the four count fields (QDCOUNT, ANCOUNT, 162 NSCOUNT, ARCOUNT) are set to zero and their corresponding sections 163 are not present. The actual data pertaining to DNS Stateful 164 Operations is appended to the end of the DNS message header. When 165 displayed using today's packet analyzer tools that have not been 166 updated to recognize the DNS Stateful Operations format, this will 167 result in the Stateful Operations data being displayed as unknown 168 additional data after the end of the DNS message. It is likely that 169 future updates to these tools will add the ability to recognize, 170 decode, and display the Stateful Operations data. 172 2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in 177 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 179 "DSO" is used to mean DNS Stateful Operation. 181 The term "connection" means a bidirectional byte stream of reliable, 182 in-order messages, such as provided by using DNS over TCP 183 [RFC1035][RFC7766] or DNS over TLS [RFC7858]. 185 The unqualified term "session" in the context of this document means 186 the exchange of DNS messages over a connection where: 188 o The connection between client and server is persistent and 189 relatively long-lived (i.e., minutes or hours, rather than 190 seconds). 192 o Either end of the connection may initiate messages to the other. 194 A "DSO session" is established between two endpoints that acknowledge 195 persistent DNS state via the exchange of DSO messages over the 196 connection. This is distinct from, for example a DNS-over-TCP 197 session as described in RC7766. 199 A "DSO session" is terminated when the underlying connection is 200 closed. 202 The term "server" means the software with a listening socket, 203 awaiting incoming connection requests. 205 The term "client" means the software which initiates a connection to 206 the server's listening socket. 208 The terms "initiator" and "responder" correspond respectively to the 209 initial sender and subsequent receiver of a DSO request message, 210 regardless of which was the "client" and "server" in the usual DNS 211 sense. 213 The term "sender" may apply to either an initiator (when sending a 214 DNS Stateful Operation request message) or a responder (when sending 215 a DNS Stateful Operation response message). 217 Likewise, the term "receiver" may apply to either a responder (when 218 receiving a DNS Stateful Operation request message) or an initiator 219 (when receiving a DNS Stateful Operation response message). 221 DNS Stateful Operations are expressed using type-length-value (TLV) 222 syntax. 224 Two timers (elapsed time since an event) are defined in this 225 document: 227 o an inactivity timer (see Section 5 and Section 8.3) 229 o a keepalive timer (see Section 5 and Section 8.5) 231 The timeouts associated with these timers are called the inactivity 232 timeout and the keepalive interval respectively. The term "Session 233 Timeouts" is used to refer to this pair of timeout values. 235 Reseting a timer means resetting the timer value to zero and starting 236 the timer again. Clearing a timer means resetting the timer value to 237 zero but NOT starting the time again. 239 3. Discussion 241 There are several use cases for DNS Stateful operations that can be 242 described here. 244 Firstly, establishing session parameters such as server defined 245 timeouts is of great use in the general management of persistent 246 connections. For example, using DSO sessions for stub to recursive 247 DNS-over-TLS [RFC7858] is more flexible for both the client and the 248 server than attempting to manage sessions using just the EDNS(0) TCP 249 Keepalive option [RFC7828]. The simple set of TLVs defined in this 250 document is sufficient to greatly enhance connection management for 251 this use case. 253 Secondly, DNS-SD has evolved into a naturally session based mechanism 254 where, for example, long-lived subscriptions lend themselves to 255 'push' mechanisms as opposed to polling. Long-lived stateful 256 connections and server initiated messages align with this use case as 257 described in [I-D.ietf-dnssd-push]. 259 A general use case is that DNS traffic is often bursty but session 260 establishment can be expensive. One challenge with long-lived 261 connections is to maintain sufficient traffic to maintain NAT and 262 firewall state. To mitigate this issue this document introduces a 263 new concept for the DNS, that is DSO "Keepalive traffic". This 264 traffic carries no DNS data and is not considered 'activity' in the 265 classic DNS sense but serves to reset a keepalive timer in order to 266 avoid re-cycling a DSO session. 268 There are a myriad of other potential use cases for DSO given the 269 versatility and extensibility of this specification. 271 Section 4 of this document first describes the protocol details of 272 DNS Stateful Operations including definitions of three TLVs for 273 session management and encryption padding. Section 8 then presents a 274 detailed discussion of the DSO Session lifecycle including an in- 275 depth discussion of keepalive traffic and session termination. 277 4. Protocol Details 278 4.1. DSO Session Establishment 280 DSO messages MUST only be carried in protocols and in environments 281 where a session may be established according to the definition above. 282 Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] 283 are suitable protocols. 285 DNS over plain UDP [RFC0768] is not appropriate since it fails on the 286 requirement for in-order message delivery, and, in the presence of 287 NAT gateways and firewalls with short UDP timeouts, it fails to 288 provide a persistent bi-directional communication channel unless an 289 excessive amount of keepalive traffic is used. 291 DSO messages relate only to the specific "DSO session" in which they 292 are being carried. A "DSO session" is established over a connection 293 when either side of the connection sends the first DSO TLV and it is 294 acknowledged by the other side. The DSO message format Section 4.2.2 295 includes an option to specify that a DSO request does not require a 296 response acknowledgement. Session establishment can only be 297 performed using a DSO message that requires a response 298 acknowledgement. 300 While this specification defines an initial set of three TLVs, 301 additional TLVs may be defined in additional specifications. All 302 three of the TLVs defined here are mandatory to implement. 304 A client MAY attempt to initiate DSO messages at any time on a 305 connection; receiving a NOTIMP response in reply indicates that the 306 server does not implement DSO, and the client SHOULD NOT issue 307 further DSO messages on that connection. 309 A server SHOULD NOT initiate DSO messages until a client-initiated 310 DSO message is received first, unless in an environment where it is 311 known in advance by other means that the client supports DSO. This 312 requirement is to ensure that the clients that do not support DSO do 313 not receive unsolicited inbound DSO messages that they would not know 314 how to handle. 316 On a session between a client and server that support DSO, once the 317 client has sent at least one DSO message (or it is known in advance 318 by other means that the client supports DSO) either end may 319 unilaterally send DSO messages at any time, and therefore either 320 client or server may be the initiator of a message. 322 From this point on it is considered that a "DSO session" is in 323 progress. Clients and servers should behave as described in this 324 specification with regard to inactivity timeouts and connection 325 close, not as prescribed in [RFC7766]. 327 4.1.1. Middle-box Considerations 329 Where an application-layer middle box (e.g., a DNS proxy, forwarder, 330 or session multiplexer) is in the path the middle box MUST NOT 331 blindly forward DSO messages in either direction, and MUST treat the 332 inbound and outbound connections as separate sessions. This does not 333 preclude the use of DSO messages in the presence of an IP-layer 334 middle box such as a NAT that rewrites IP-layer and/or transport- 335 layer headers, but otherwise preserves the effect of a single session 336 between the client and the server. 338 To illustrate the above, consider a network where a middle box 339 terminates one or more TCP connections from clients and multiplexes 340 the queries therein over a single TCP connection to an upstream 341 server. The DSO messages and any associated state are specific to 342 the individual TCP connections. A DSO-aware middle box MAY in some 343 circumstances be able to retain associated state and pass it between 344 the client and server (or vice versa) but this would be highly TLV- 345 specific. For example, the middle box may be able to maintain a list 346 of which clients have made Push Notification subscriptions 347 [I-D.ietf-dnssd-push] and make its own subscription(s) on their 348 behalf, relaying any subsequent notifications to the client (or 349 clients) that have subscribed to that particular notification. 351 4.2. Message Format 353 A DSO message begins with the standard twelve-octet DNS message 354 header [RFC1035] with the OPCODE field set to the DSO OPCODE 355 (tentatively 6). However, unlike standard DNS messages, the question 356 section, answer section, authority records section and additional 357 records sections are not present. The corresponding count fields 358 (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero on 359 transmission. 361 If a DSO message is received where any of the count fields are not 362 zero, then a FORMERR MUST be returned. 364 1 1 1 1 1 1 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 366 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 367 | MESSAGE ID | 368 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 369 |QR | OPCODE | Z | RCODE | 370 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 371 | QDCOUNT (MUST be zero) | 372 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 373 | ANCOUNT (MUST be zero) | 374 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 375 | NSCOUNT (MUST be zero) | 376 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 377 | ARCOUNT (MUST be zero) | 378 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 379 | | 380 / DSO Data / 381 / / 382 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 384 4.2.1. Header 386 In a request the MESSAGE ID field MUST be set to a unique value, that 387 the initiator is not currently using for any other active operation 388 on this connection. For the purposes here, a MESSAGE ID is in use in 389 this DSO session if the initiator has used it in a request for which 390 it has not yet received a response, or if the client has used it to 391 setup state that it has not yet ready to delete. For example, state 392 could be a subscription as defined in [I-D.ietf-dnssd-push]. 394 In a response the MESSAGE ID field MUST contain a copy of the value 395 of the MESSAGE ID field in the request being responded to. 397 In a request the DNS Header QR bit MUST be zero (QR=0). If the QR 398 bit is not zero the message is not a request. 400 In a response the DNS Header QR bit MUST be one (QR=1). If the QR 401 bit is not one the message is not a response. 403 The DNS Header OPCODE field holds the DSO OPCODE value (tentatively 404 6). 406 The Z bits are currently unused, and in both requests and responses 407 the Z bits MUST be set to zero (0) on transmission and MUST be 408 silently ignored on reception, unless a future document specifies 409 otherwise. 411 In a request message (QR=0) the RCODE is generally set to zero on 412 transmission, and silently ignored on reception, except where 413 specified otherwise (for example, the Retry Delay operation (see 414 Section 6), where the RCODE indicates the reason for termination). 416 The RCODE value in a response may be one of the following values: 418 +------+-----------+------------------------------------------------+ 419 | Code | Mnemonic | Description | 420 +------+-----------+------------------------------------------------+ 421 | 0 | NOERROR | Operation processed successfully | 422 | | | | 423 | 1 | FORMERR | Format error | 424 | | | | 425 | 2 | SERVFAIL | Server failed to process request due to a | 426 | | | problem with the server | 427 | | | | 428 | 3 | NXDOMAIN | TLV dependent | 429 | | | | 430 | 4 | NOTIMP | DSO not supported | 431 | | | | 432 | 5 | REFUSED | Operation declined for policy reasons | 433 | | | | 434 | 9 | NOTAUTH | Not Authoritative (TLV dependent) | 435 | | | | 436 | 11 | DSONOTIMP | DSO type code not supported | 437 +------+-----------+------------------------------------------------+ 439 Use of the above RCODE's is likely to be common in DSO but does not 440 preclude the definition and use of other codes in future documents 441 that make use of DSO. 443 If a document describing a DSO makes use of either NXDOMAIN or 444 NOTAUTH then that document MUST explain the meaning. 446 4.2.2. DSO Data 448 The standard twelve-octet DNS message header is followed by the DSO 449 Data. 451 The first TLV in a DSO request message is called the Operation TLV. 452 Any subsequent TLVs after this initial Operation TLV are called 453 Modifier TLVs. 455 Depending on the operation a DSO response can contain: 457 o No TLVs 458 o Only an Operation TLV 460 o An Operation TLV followed by one or more Modifier TLVs 462 o Only Modifier TLVs 464 4.2.2.1. TLV Format 466 Operation and modifier TLVs both use the same encoding format. 468 Operation TLVs SHOULD normally require a response and, therefore, set 469 the TLV Acknowledgement bit in a request. However, for some 470 Operation TLVs, this may be undesirable and the TLV Acknowledgement 471 bit MAY be cleared in the request. Each Operation TLV definition 472 should stipulate whether an acknowledgement is REQUIRED. If the TLV 473 Acknowledgement bit is cleared in a request, a response MUST NOT be 474 sent. Modifier TLVs MUST NEVER set the Acknowledgement bit. The 475 Acknowledgement bit is NEVER set in the response to an Operation TLV. 477 1 1 1 1 1 1 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 479 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 480 | A | DSO-TYPE | 481 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 482 | DSO DATA LENGTH | 483 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 484 | | 485 / TYPE-DEPENDENT DATA / 486 / / 487 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 489 A: A 1 bit TLV Response flag indicating whether or not an Operation 490 TLV requires a response Acknowledgement. DSO-TYPE: 492 A 15 bit field in network order giving the type of the current DSO 493 TLV per the IANA DSO Type Codes Registry. 495 DSO DATA LENGTH: A 16 bit field in network order giving the size in 496 octets of the TYPE-DEPENDENT DATA. 498 TYPE-DEPENDENT DATA: Type-code specific format. 500 Where domain names appear within TYPE-DEPENDENT DATA, they MAY be 501 compressed using standard DNS name compression. However, the 502 compression MUST NOT point outside of the TYPE-DEPENDENT DATA section 503 and offsets MUST be from the start of the TYPE-DEPENDENT DATA. 505 4.2.2.2. Operation TLVs 507 An "Operation TLV" specifies the operation to be performed. 509 A DSO message MUST contain at most one Operation TLV. 511 In all cases a DSO request message MUST contain exactly one Operation 512 TLV, indicating the operation to be performed. 514 Depending on the operation, a DSO response message MAY contain no 515 Operation TLV, because it is simply a response to a previous request 516 message, and the MESSAGE ID in the header is sufficient to identify 517 the request in question. Or it may contain a single corresponding 518 response Operation TLV, with the same DSO-TYPE as in the request 519 message. The specification for each DSO type determines whether a 520 response for that operation type is required to carry the Operation 521 TLV. 523 If a DSO response is received for an operation which requires that 524 the response carry an Operation TLV, and the required Operation TLV 525 is not the first DSO TLV in the response message, then this is a 526 fatal error and the recipient of the defective response message MUST 527 immediately terminate the connection with a TCP RST (or equivalent 528 for other protocols). 530 4.2.2.3. Modifier TLVs 532 A "Modifier TLV" specifies additional parameters relating to the 533 operation. Immediately following the Operation TLV, if present, a 534 DSO message MAY contain one or more Modifier TLVs. 536 4.2.2.4. Unrecognized TLVs 538 If a DSO request is received containing an unrecognized Operation 539 TLV, the receiver MUST send a response with matching MESSAGE ID, and 540 RCODE DSONOTIMP (tentatively 11). The response MUST NOT contain an 541 Operation TLV. 543 If a DSO message (request or response) is received containing one or 544 more unrecognized Modifier TLVs, the unrecognized Modifier TLVs MUST 545 be silently ignored, and the remainder of the message is interpreted 546 and handled as if the unrecognized parts were not present. 548 4.2.3. EDNS(0) and TSIG 550 Since the ARCOUNT field MUST be zero, a DSO message MUST NOT contain 551 an EDNS(0) option in the additional records section. If 552 functionality provided by current or future EDNS(0) options is 553 desired for DSO messages, an Operation TLV or Modifier TLV needs to 554 be defined to carry the necessary information. 556 For example, the EDNS(0) Padding Option [RFC7830] used for security 557 purposes is not permitted in a DSO message, so if message padding is 558 desired for DSO messages then the Encryption Padding TLV described in 559 Section 7 MUST be used. 561 Similarly, a DSO message MUST NOT contain a TSIG record. A TSIG 562 record in a conventional DNS message is added as the last record in 563 the additional records section, and carries a signature computed over 564 the preceding message content. Since DSO data appears after the 565 additional records section, it would not be included in the signature 566 calculation. If use of signatures with DSO messages becomes 567 necessary in the future, an explicit Modifier TLV needs to be defined 568 to perform this function. 570 Note however that, while DSO _messages_ cannot include EDNS(0) or 571 TSIG records, a DSO _session_ is typically used to carry a whole 572 series of DNS messages of different kinds, including DSO messages, 573 and other DNS message types like Query [RFC1034] [RFC1035] and Update 574 [RFC2136], and those messages can carry EDNS(0) and TSIG records. 576 This specification explicitly prohibits use of the EDNS(0) TCP 577 Keepalive Option [RFC7828] in _any_ messages sent on a DSO session 578 (because it duplicates the functionality provided by the DSO 579 Keepalive operation), but messages may contain other EDNS(0) options 580 as appropriate. 582 4.3. Message Handling 584 The initiator MUST set the value of the QR bit in the DNS header to 585 zero (0), and the responder MUST set it to one (1). Every DSO 586 request message (QR=0) MUST elicit a response (QR=1), which MUST have 587 the same MESSAGE ID in the DNS message header as in the corresponding 588 request. DSO request messages sent by the client elicit a response 589 from the server, and DSO request messages sent the server elicit a 590 response from the client. 592 With most TCP implementations, the TCP data acknowledgement 593 (generated because data has been received by TCP), the TCP window 594 update (generated because TCP has delivered that data to the 595 receiving software) and the DSO response (generated by the receiving 596 software itself) are all combined into a single packet, so in 597 practice the requirement that every DSO request message MUST elicit a 598 DSO response incurs minimal extra cost on the network. Requiring 599 that every request elicit a corresponding response also avoids 600 performance problems caused by interaction between Nagle's Algorithm 601 and Delayed Ack [NagleDA]. 603 The namespaces of 16-bit MESSAGE IDs are disjoint in each direction. 604 For example, it is _not_ an error for both client and server to send 605 a request message with the same ID. In effect, the 16-bit MESSAGE ID 606 combined with the identity of the initiator (client or server) serves 607 as a 17-bit unique identifier for a particular operation on a DSO 608 session. 610 As described in Section 4.2.1 An initiator MUST NOT reuse a MESSAGE 611 ID that is already in use for an outstanding request, unless 612 specified otherwise by the relevant specification for the DSO in 613 question. At the very least, this means that a MESSAGE ID MUST NOT 614 be reused in a particular direction on a particular DSO session while 615 the initiator is waiting for a response to a previous request on that 616 DSO session, unless specified otherwise by the relevant specification 617 for the DSO in question. (For a long-lived state the MESSAGE ID for 618 the operation MUST NOT be reused whilst that state remains active.) 620 If a client or server receives a response (QR=1) where the MESSAGE ID 621 does not match any of its outstanding operations, this is a fatal 622 error and it MUST immediately terminate the connection with a TCP RST 623 (or equivalent for other protocols). 625 5. Keepalive Operation TLV 627 The Keepalive Operation TLV (DSO-TYPE=1) performs two functions: to 628 reset the keepalive timer for the DSO session and to establish the 629 values for the Session Timeouts. 631 The Keepalive Operation TLV resets only the keepalive timer, not the 632 inactivity timer. The reason for this is that periodic Keepalive 633 Operation TLVs are sent for the sole purpose of keeping a DSO session 634 alive because that DSO session has current or recent activity that 635 warrants keeping the DSO session alive. If sending keepalive traffic 636 itself were to reset the inactivity timer, then that would create a 637 circular livelock where keepalive traffic would be sent indefinitely 638 to keep a DSO session alive, where the only activity on that DSO 639 session would be keepalive traffic keeping the DSO session alive so 640 that further keepalive traffic can be sent. 642 Sending keepalive traffic is considered a maintenance activity that 643 is performed in service of other client activities. Sending 644 keepalive traffic itself is not considered a client activity. For a 645 DSO session to be considered active, it must be carrying something 646 more than just keepalive traffic. This is why merely sending a 647 Keepalive Operation TLV does not reset the inactivity timer. 649 When sent by a client, the Keepalive Operation TLV resets a DSO 650 session's keepalive timer, and at the same time requests what the 651 Session Timeout values should be from this point forward in the DSO 652 session. 654 An acknowledgement is always required for a Keepalive Operation TLV 655 and the TLV Acknowledgement bit MUST be set in the request when 656 originated by either the client or the server. 658 Once a DSO session is in progress (see Section 4) the Keepalive TLV 659 also MAY be initiated by a server. When sent by a server, it resets 660 a DSO session's keepalive timer, and unilaterally informs the client 661 of the new Session Timeout values to use from this point forward in 662 this DSO session. 664 It is not required that the Keepalive TLV be used in every DSO 665 session. While many DNS Stateful operations will be used in 666 conjunction with a long-lived session state, not all DNS Stateful 667 operations require long-lived session state, and in some cases the 668 default 15-second value for both the inactivity timeout and keepalive 669 interval may be perfectly appropriate. However, it can be noted that 670 for clients that implement only the TLVs defined in this document it 671 is the only way for a client to initiate a DSO session. 673 The TYPE-DEPENDENT DATA for the the Keepalive TLV is as follows: 675 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | INACTIVITY TIMEOUT (32 bits) | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | KEEPALIVE INTERVAL (32 bits) | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 INACTIVITY TIMEOUT: the inactivity timeout for the current DSO 684 session, specified as a 32 bit word in network (big endian) order 685 in units of milliseconds. This is the timeout at which the client 686 MUST close an inactive DSO session. If the client does not 687 gracefully close an inactive DSO session then after twice this 688 interval the server will forcibly terminate the connection with a 689 TCP RST (or equivalent for other protocols). 691 KEEPALIVE INTERVAL: the keepalive interval for the current DSO 692 session, specified as a 32-bit word, in network (big endian) 693 order, in units of milliseconds. This is the interval at which a 694 client MUST generate keepalive traffic to maintain connection 695 state. If the client does not generate the necessary keepalive 696 traffic then after twice this interval the server will forcibly 697 terminate the connection with a TCP RST (or equivalent for other 698 protocols). 700 In a client-initiated DSO Keepalive message, the Session Timeouts 701 contain the client's requested values. In a server response to a 702 client-initiated message, the Session Timeouts contain the server's 703 chosen values, which the client MUST respect. This is modeled after 704 the DHCP protocol, where the client requests a certain lease lifetime 705 using DHCP option 51 [RFC2132], but the server is the ultimate 706 authority for deciding what lease lifetime is actually granted. 708 In a server-initiated DSO Keepalive message, the Session Timeouts 709 unilaterally inform the client of the new values from this point 710 forward in this DSO session. The client MUST generate a response to 711 the server-initiated DSO Keepalive message. The MESSAGE ID in the 712 response message MUST match the ID from the server-initiated DSO 713 Keepalive message, and the response message MUST NOT contain any 714 Operation TLV. 716 When a client is sending its second and subsequent Keepalive DSO 717 requests to the server, the client SHOULD continue to request its 718 preferred values each time. This allows flexibility, so that if 719 conditions change during the lifetime of a DSO session, the server 720 can adapt its responses to better fit the client's needs. 722 5.1. Client handling of received Session Timeout values 724 When a client receives a response to its client-initiated DSO 725 Keepalive message, or receives a server-initiated DSO Keepalive 726 message, the client has then received Session Timeout values dictated 727 by the server. The two timeout values contained in the DSO Keepalive 728 TLV from the server may each be higher, lower, or the same as the 729 respective Session Timeout values the client previously had for this 730 DSO session. 732 In the case of the keepalive timer, the handling of the received 733 value is straightforward. The act of receiving the message 734 containing the DSO Keepalive TLV itself resets the keepalive timer 735 and updates the keepalive interval for the DSO session. The new 736 keepalive interval indicates the maximum time that may elapse before 737 another message must be sent or received on this DSO session, if the 738 DSO session is to remain alive. 740 In the case of the inactivity timeout, the handling of the received 741 value superficially appears a little more subtle, though the meaning 742 of the inactivity timeout is unchanged - it still indicates the 743 maximum permissible time allowed without activity on a DSO session. 744 The act of receiving the message containing the DSO Keepalive TLV 745 does not itself reset the inactivity timer. The time elapsed since 746 the last useful activity on this DSO session is unaffected by 747 exchange of DSO Keepalive messages. The act of receiving the message 748 containing the DSO Keepalive TLV does update the timeout associated 749 with the running inactivity timer; that becomes the new maximum 750 permissible time without activity on a DSO session. 752 o If the inactivity timer value is not greater than the new 753 inactivity timeout, then the DSO session may remain open for now. 754 When the inactivity timer value exceeds the new inactivity 755 timeout, the client MUST then close the DSO session, as described 756 above. 758 o If the inactivity timer value is already greater than the new 759 inactivity timeout, then this DSO session has already been 760 inactive for longer than the server permits, and the client MUST 761 immediately close this DSO session. 763 o If the inactivity timer value is more than twice the new 764 inactivity timeout, then this DSO session is eligible to be 765 forcibly terminated by the server and and the client MUST 766 immediately close this DSO session. However if a server abruptly 767 reduces the inactivity timeout in this way the server SHOULD give 768 the client a grace period of one quarter of the new inactivity 769 timeout, to give the client time to close the connection 770 gracefully before the server resorts to terminating it forcibly. 772 5.2. Relation to EDNS(0) TCP Keepalive Option 774 The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has 775 similar intent to the EDNS(0) TCP Keepalive Option [RFC7828]. A 776 client/server pair that supports DSO MUST NOT use the EDNS(0) TCP 777 KeepAlive option within any message after a DSO session has been 778 established. Once a DSO session has been established, if either 779 client or server receives a DNS message over the DSO session that 780 contains an EDNS(0) TCP Keepalive option, this is an error and the 781 receiver of the EDNS(0) TCP Keepalive option MUST immediately 782 terminate the connection with a TCP RST (or equivalent for other 783 protocols). 785 6. Retry Delay TLV 787 The Retry Delay TLV (DSO-TYPE=0) can be used as an Operation TLV or 788 as a Modifier TLV. 790 The TYPE-DEPENDENT DATA for the the Retry Delay TLV is as follows: 792 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | RETRY DELAY (32 bits) | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 RETRY DELAY: a time value, specified as a 32 bit word in network 799 order in units of milliseconds, within which the client MUST NOT 800 retry this operation, or retry connecting to this server. 802 The RECOMMENDED value is 10 seconds. 804 6.1. Use as an Operation TLV 806 When sent in a DSO request message, from server to client, the Retry 807 Delay TLV (0) is considered an Operation TLV. It is used by a server 808 to request that a client close the DSO session and underlying 809 connection, and not to reconnect for the indicated time interval. 811 In this case it applies to the DSO session as a whole, and the client 812 MUST close the DSO session, as described in section Section 8.9. The 813 RCODE in the message header MUST indicate the reason for the 814 termination: 816 o NOERROR indicates a routine shutdown. 818 o SERVFAIL indicates that the server is overloaded due to resource 819 exhaustion. 821 o REFUSED indicates that the server has been reconfigured and is no 822 longer able to perform one or more of the functions currently 823 being performed on this DSO session (for example, a DNS Push 824 Notification server could be reconfigured such that is is no 825 longer accepting DNS Push Notification requests for one or more of 826 the currently subscribed names). 828 This document specifies only these three RCODE values for Retry Delay 829 request. Servers sending Retry Delay requests SHOULD use one of 830 these three values. However, future circumstances may create 831 situations where other RCODE values are appropriate in Retry Delay 832 requests, so clients MUST be prepared to accept Retry Delay requests 833 with any RCODE value. 835 An acknowledgement is not desired for a Retry Delay Operation TLV and 836 the TLV Acknowledgement bit MUST be cleared in the request. 838 6.2. Use as a Modifier TLV 840 When appended to a DSO response message for some client request, the 841 Retry Delay TLV (0) is considered a Modifier TLV. The indicated time 842 interval during which the client SHOULD NOT retry applies only to the 843 failed operation, not to the DSO session as a whole. 845 In the case of a client request that returns a nonzero RCODE value, 846 the server MAY append a Retry Delay TLV (0) to the response, 847 indicating the time interval during which the client SHOULD NOT 848 attempt this operation again. 850 7. Encryption Padding TLV 852 The Encryption Padding TLV (DSO-TYPE=2) can only be used as a 853 Modifier TLV. It is only applicable when the DSO Transport layer 854 uses encryption such as TLS. 856 The TYPE-DEPENDENT DATA for the the Padding TLV is optional and is a 857 variable length field containing non-specified values. A DATA LENGTH 858 of 0 essentially provides for 4 octets of padding (the minimum 859 amount). 861 1 1 1 1 1 1 862 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 863 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 864 / / 865 / VARIABLE NUMBER OF OCTETS / 866 / / 867 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 869 As in [RFC7830] the PADDING octets SHOULD be set to 0x00. Other 870 values MAY be used, for example, in cases where there is a concern 871 that the padded message could be subject to compression before 872 encryption. PADDING octets of any value MUST be accepted in the 873 messages received. 875 The Encryption Padding TLV may be included in either a DSO request, 876 response, or both. As in [RFC7830] if a request is received with a 877 Encryption Padding TLV, then the response MUST also include an 878 Encryption Padding TLV. 880 The length of padding is intentionally not specified in this document 881 and is a function of current best practices with respect to the type 882 and length of data in the preceding TLVs. See 883 [I-D.ietf-dprive-padding-policy] 885 8. DSO Session Lifecycle and Timers 887 8.1. DSO Session Initiation 889 A session begins when a client makes a new connection to a server. 891 A DSO session begin as described in Section 4.1. 893 The client may perform as many DNS operations as it wishes using the 894 newly created DSO session. Operations SHOULD be pipelined (i.e., the 895 client doesn't need wait for a response before sending the next 896 message). The server MUST act on messages in the order they are 897 transmitted, but responses to those messages MAY be sent out of 898 order, if appropriate. 900 8.2. DSO Session Timeouts 902 Two timeout values are associated with a DSO session: the inactivity 903 timeout, and the keepalive interval. 905 The first timeout value, the inactivity timeout, is the maximum time 906 for which a client may speculatively keep a DSO session open in the 907 expectation that it may have future requests to send to that server. 909 The second timeout value, the keepalive interval, is the maximum 910 permitted interval between client messages to the server if the 911 client wishes to keep the DSO session alive. 913 The two timeout values are independent. The inactivity timeout may 914 be lower, the same, or higher than the keepalive interval, though in 915 most cases the inactivity timeout is expected to be shorter than the 916 keepalive interval. 918 Only when the client has a very long-lived low-traffic state does the 919 keepalive interval come into play, to ensure that a sufficient 920 residual amount of traffic is generated to maintain NAT and firewall 921 state. 923 On a new DSO session, if no explicit DSO Keepalive message exchange 924 has taken place, the default value for both timeouts is 15 seconds. 925 For both timeouts, lower values of the timeout result in higher 926 network traffic and higher CPU load on the server. 928 8.3. Inactive DSO Sessions 930 At both servers and clients, the generation or reception of any 931 complete DNS message, including DNS requests, responses, updates, or 932 DSO messages, resets both timers for that DSO session, with the 933 exception that a DSO Keepalive message resets only the keepalive 934 timer, not the inactivity timeout timer. 936 In addition, for as long as the client has an outstanding operation 937 in progress, the inactivity timer remains cleared, and an inactivity 938 timeout cannot occur. 940 For short-lived DNS operations like traditional queries and updates, 941 an operation is considered in progress for the time between request 942 and response, typically a period of a few hundred milliseconds at 943 most. At the client, the inactivity timer is cleared upon 944 transmission of a request and remains cleared until reception of the 945 corresponding response. At the server, the inactivity timer is 946 cleared upon reception of a request and remains cleared until 947 transmission of the corresponding response. 949 For long-lived DNS Stateful operations, an operation is considered in 950 progress for as long as the state is active, until it is cancelled. 951 This means that a DSO session can exist, with a state active, with no 952 messages flowing in either direction, for far longer than the 953 inactivity timeout, and this is not an error. This is why there are 954 two separate timers: the inactivity timeout, and the keepalive 955 interval. Just because a DSO session has no traffic for an extended 956 period of time does not automatically make that DSO session 957 "inactive", if it has an active state that is awaiting for events. 959 8.4. The Inactivity Timeout 961 The purpose of the inactivity timeout is for the server to balance 962 its trade off between the costs of setting up new DSO sessions and 963 the costs of maintaining inactive DSO sessions. A server with 964 abundant DSO session capacity can offer a high inactivity timeout, to 965 permit clients to keep a speculative DSO session open for a long 966 time, to save the cost of establishing a new DSO session for future 967 communications with that server. A server with scarce memory 968 resources can offer a low inactivity timeout, to cause clients to 969 promptly close DSO sessions whenever they have no outstanding 970 operations with that server, and then create a new DSO session later 971 when needed. 973 8.4.1. Closing Inactive DSO Sessions 975 A client is NOT required to wait until the inactivity timeout expires 976 before closing a DSO session. A client MAY close a DSO session at 977 any time, at the client's discretion. If a client determines that it 978 has no current or reasonably anticipated future need for an inactive 979 DSO session, then the client SHOULD close that connection. 981 If, at any time during the life of the DSO session, the inactivity 982 timeout value (i.e., 15 seconds by default) elapses without there 983 being any operation active on the DSO session, the client MUST 984 gracefully close the connection with a TCP FIN (or equivalent for 985 other protocols). 987 If, at any time during the life of the DSO session, twice the 988 inactivity timeout value (i.e., 30 seconds by default) elapses 989 without there being any operation active on the DSO session, the 990 server SHOULD consider the client delinquent, and forcibly abort the 991 DSO session. For DSO sessions over TCP (or over TLS over TCP), to 992 avoid the burden of having a connection in TIME-WAIT state, instead 993 of closing the connection gracefully with a TCP FIN the server SHOULD 994 abort the connection with a TCP RST (or equivalent for other 995 protocols). (In the BSD Sockets API this is achieved by setting the 996 SO_LINGER option to zero before closing the socket.) 998 In this context, an operation being active on a DSO session includes 999 a query waiting for a response, an update waiting for a response, or 1000 active state, but not a DSO Keepalive message exchange itself. A DSO 1001 Keepalive message exchange resets only the keepalive interval timer, 1002 not the inactivity timeout timer. 1004 If the client wishes to keep an inactive DSO session open for longer 1005 than the default duration without having to send traffic every 15 1006 seconds, then it uses the DSO Keepalive message to request longer 1007 timeout values, as described in Section 5. 1009 8.4.2. Values for the Inactivity Timeout 1011 For the inactivity timeout value, lower values result in more 1012 frequent DSO session teardown and re-establishment. Higher values 1013 result in lower traffic and CPU load on the server, but a larger 1014 memory burden to maintain state for inactive DSO sessions. 1016 A shorter inactivity timeout with a longer keepalive interval signals 1017 to the client that it should not speculatively keep inactive DSO 1018 sessions open for very long for no reason, but when it does have an 1019 active reason to keep a DSO session open, it doesn't need to be 1020 sending an aggressive level of keepalive traffic. 1022 A longer inactivity timeout with a shorter keepalive interval signals 1023 to the client that it may speculatively keep inactive DSO sessions 1024 open for a long time, but it should be sending a lot of keepalive 1025 traffic on those inactive DSO sessions. This configuration is 1026 expected to be less common. 1028 To avoid excessive traffic the server MUST NOT send a Keepalive 1029 message (either a response to a client-initiated request, or a 1030 server-initiated message) with an inactivity timeout value less than 1031 ten seconds. If a client receives a Keepalive message specifying an 1032 inactivity timeout value less than ten seconds this is an error and 1033 the client MUST immediately terminate the connection with a TCP RST 1034 (or equivalent for other protocols). 1036 8.5. The Keepalive Interval 1038 The purpose of the keepalive interval is to manage the generation of 1039 sufficient messages to maintain state in middle-boxes (such at NAT 1040 gateways or firewalls) and for the client and server to periodically 1041 verify that they still have connectivity to each other. This allows 1042 them to clean up state when connectivity is lost, and attempt re- 1043 connection if appropriate. 1045 8.5.1. Keepalive Interval Expiry 1047 If, at any time during the life of the DSO session, the keepalive 1048 interval value (i.e., 15 seconds by default) elapses without any DNS 1049 messages being sent or received on a DSO session, the client MUST 1050 take action to keep the DSO session alive. To keep the DSO session 1051 alive the client MUST send a DSO Keepalive message (see Section 5). 1052 A DSO Keepalive message exchange resets only the keepalive timer, not 1053 the inactivity timer. 1055 If a client disconnects from the network abruptly, without cleanly 1056 closing its DSO session, leaving long-lived state uncanceled, the 1057 server learns of this after failing to receive the required keepalive 1058 traffic from that client. If, at any time during the life of the DSO 1059 session, twice the keepalive interval value (i.e., 30 seconds by 1060 default) elapses without any DNS messages being sent or received on a 1061 DSO session, the server SHOULD consider the client delinquent, and 1062 forcibly abort the connection with a TCP RST (or equivalent for other 1063 protocols). 1065 8.5.2. Values for the Keepalive Interval 1067 For the keepalive interval value, lower values result in higher 1068 volume keepalive traffic. Higher values of the keepalive interval 1069 reduce traffic and CPU load, but have minimal effect on the memory 1070 burden at the server, because clients keep a DSO session open for the 1071 same length of time (determined by the inactivity timeout) regardless 1072 of the level of keepalive traffic required. 1074 It may be appropriate for clients and servers to select different 1075 keepalive interval values depending on the nature of the network they 1076 are on. 1078 A corporate DNS server that knows it is serving only clients on the 1079 internal network, with no intervening NAT gateways or firewalls, can 1080 impose a higher keepalive interval, because frequent keepalive 1081 traffic is not required. 1083 A public DNS server that is serving primarily residential consumer 1084 clients, where it is likely there will be a NAT gateway on the path, 1085 may impose a lower keepalive interval, to generate more frequent 1086 keepalive traffic. 1088 A smart client may be adaptive to its environment. A client using a 1089 private IPv4 address [RFC1918] to communicate with a DNS server at an 1090 address that is not in the same IPv4 private address block, may 1091 conclude that there is likely to be a NAT gateway on the path, and 1092 accordingly request a lower keepalive interval. 1094 For environments where there is a NAT gateway or firewalls on the 1095 path, it is RECOMMENDED that clients request, and servers grant, a 1096 keepalive interval of 15 minutes. In other environments it is 1097 RECOMMENDED that clients request, and servers grant, a keepalive 1098 interval of 60 minutes. 1100 Note that the lower the keepalive interval value, the higher the load 1101 on client and server. For example, an keepalive interval value of 1102 100ms would result in a continuous stream of at least ten messages 1103 per second, in both directions, to keep the DSO session alive. And, 1104 in this extreme example, a single packet loss and retransmission over 1105 a long path could introduce a momentary pause in the stream of 1106 messages, long enough to cause the server to overzealously abort the 1107 connection. 1109 Because of this concern, the server MUST NOT send a Keepalive message 1110 (either a response to a client-initiated request, or a server- 1111 initiated message) with an keepalive interval value less than ten 1112 seconds. If a client receives an Keepalive message specifying an 1113 keepalive interval value less than ten seconds this is an error and 1114 the client MUST immediately terminate the connection with a TCP RST 1115 (or equivalent for other protocols). 1117 8.6. Server-Initiated Termination on Error 1119 After sending an error response to a client, the server MAY close the 1120 DSO session, or may allow the DSO session to remain open. For error 1121 conditions that only affect the single operation in question, the 1122 server SHOULD return an error response to the client and leave the 1123 DSO session open for further operations. For error conditions that 1124 are likely to make all operations unsuccessful in the immediate 1125 future, the server SHOULD return an error response to the client and 1126 then close the DSO session by sending a Retry Delay request message, 1127 as described in Section 6. 1129 8.7. Client Behaviour in Receiving an Error 1131 Upon receiving an error response from the server, a client SHOULD NOT 1132 automatically close the DSO session. An error relating to one 1133 particular operation on a DSO session does not necessarily imply that 1134 all other operations on that DSO session have also failed, or that 1135 future operations will fail. The client should assume that the 1136 server will make its own decision about whether or not to close the 1137 DSO session, based on the server's determination of whether the error 1138 condition pertains to this particular operation, or would also apply 1139 to any subsequent operations. If the server does not close the DSO 1140 session then the client SHOULD continue to use that DSO session for 1141 subsequent operations. 1143 8.8. Server-Initiated Termination on Overload 1145 Apart from the cases where: 1147 o Session Timeouts expire (see Section 8.2) 1149 o On error (see {Section Section 8.7) 1151 o When under load (see below) 1153 a server MUST NOT close a DSO session with a client, except in 1154 extraordinary error conditions. Closing the DSO session is the 1155 client's responsibility, to be done at the client's discretion, when 1156 it so chooses. A server only closes a DSO session under exceptional 1157 circumstances, such as when the server application software or 1158 underlying operating system is restarting, the server application 1159 terminated unexpectedly (perhaps due to a bug that makes it crash), 1160 or the server is undergoing maintenance procedures. When possible, a 1161 server SHOULD send a Retry Delay message informing the client of the 1162 reason for the DSO session being closed, and allow the client five 1163 seconds to receive it before the server resorts to forcibly aborting 1164 the connection. 1166 8.9. Retry Delay Operation TLV 1168 There may be rare cases where a server is overloaded and wishes to 1169 shed load. If a server is low on resources it MAY simply terminate a 1170 client connection with a TCP RST (or equivalent for other protocols). 1171 However, the likely behavior of the client may be simply to to treat 1172 this as a network failure and connect immediately, putting more 1173 burden on the server. 1175 Therefore to avoid this reconnection implosion, a server SHOULD 1176 instead choose to shed client load by sending a Retry Delay request 1177 message, with an RCODE of SERVFAIL, to inform the client of the 1178 overload situation. After sending a Retry Delay request message, the 1179 server MUST NOT send any further messages on that DSO session. 1181 After sending the Retry Delay request the server SHOULD allow the 1182 client five seconds to close the connection, and if the client has 1183 not closed the connection after five seconds then the server SHOULD 1184 abort the connection with a TCP RST (or equivalent for other 1185 protocols). 1187 Upon receipt of a Retry Delay request from the server, the client 1188 MUST make note of the reconnect delay for this server, and then 1189 immediately close the connection. This is to place the burden of 1190 TCP's TIME-WAIT state on the client. 1192 A Retry Delay request message MUST NOT be initiated by a client. If 1193 a server receives a Retry Delay request message this is an error and 1194 the server MUST immediately terminate the connection with a TCP RST 1195 (or equivalent for other protocols). 1197 8.9.1. Outstanding Operations 1199 At the moment a server chooses to initiate a Retry Delay request 1200 message there may be DNS requests already in flight from client to 1201 server on this DSO session, which will arrive at the server after its 1202 Retry Delay request message has been sent. The server MUST silently 1203 ignore such incoming requests, and MUST NOT generate any response 1204 messages for them. When the Retry Delay request message from the 1205 server arrives at the client, the client will determine that any DNS 1206 requests it previously sent on this DSO session, that have not yet 1207 received a response, now will certainly not be receiving any 1208 response. Such requests should be considered failed, and should be 1209 retried at a later time, as appropriate. 1211 In the case where some, but not all, of the existing operations on a 1212 DSO session have become invalid (perhaps because the server has been 1213 reconfigured and is no longer authoritative for some of the names), 1214 but the server is terminating all DSO sessions en masse with a 1215 REFUSED (5) RCODE, the RECONNECT DELAY MAY be zero, indicating that 1216 the clients SHOULD immediately attempt to re-establish operations. 1217 It is likely that some of the attempts will be successful and some 1218 will not. 1220 In the case where a server is terminating a large number of DSO 1221 sessions at once (e.g., if the system is restarting) and the server 1222 doesn't want to be inundated with a flood of simultaneous retries, it 1223 SHOULD send different RECONNECT delay values to each client. These 1224 adjustments MAY be selected randomly, pseudorandomly, or 1225 deterministically (e.g., incrementing the time value by one tenth of 1226 a second for each successive client, yielding a post-restart 1227 reconnection rate of ten clients per second). 1229 8.9.2. Client Reconnection 1231 After a DSO session is closed by the server, the client SHOULD try to 1232 reconnect, to that server, or to another suitable server, if more 1233 than one is available. If reconnecting to the same server, the 1234 client MUST respect the indicated delay before attempting to 1235 reconnect. 1237 If a particular server does not want a client to reconnect (it is 1238 being de-commissioned), it SHOULD set the retry delay to the maximum 1239 value (which is approximately 497 days). If the server will only be 1240 out of service for a maintenance period, it should use a value closer 1241 to the expected maintenance window and not default to a very large 1242 delay value or clients may not attempt to reconnect after it resumes 1243 service. 1245 9. Connection Sharing 1247 As in [RFC7766], to mitigate the risk of unintentional server 1248 overload, DNS clients MUST take care to minimize the number of 1249 concurrent TCP connections made to any individual server. It is 1250 RECOMMENDED that for any given client/server interaction there SHOULD 1251 be no more than one connection for regular queries, one for zone 1252 transfers, and one for each protocol that is being used on top of TCP 1253 (for example, if the resolver was using TLS). However, it is noted 1254 that certain primary/ secondary configurations with many busy zones 1255 might need to use more than one TCP connection for zone transfers for 1256 operational reasons (for example, to support concurrent transfers of 1257 multiple zones). 1259 A single server may support multiple services, including DNS Updates 1260 [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other 1261 services, for one or more DNS zones. When a client discovers that 1262 the target server for several different operations is the same target 1263 hostname and port, the client SHOULD use a single shared DSO session 1264 for all those operations. A client SHOULD NOT open multiple 1265 connections to the same target host and port just because the names 1266 being operated on are different or happen to fall within different 1267 zones. This is to reduce unnecessary connection load on the DNS 1268 server. 1270 However, server implementers and operators should be aware that 1271 connection sharing may not be possible in all cases. A single client 1272 device may be home to multiple independent client software instances 1273 that don't coordinate with each other. Similarly, multiple 1274 independent client devices behind the same NAT gateway will also 1275 typically appear to the DNS server as different source ports on the 1276 same client IP address. Because of these constraints, a DNS server 1277 MUST be prepared to accept multiple connections from different source 1278 ports on the same client IP address. 1280 10. IANA Considerations 1282 10.1. DSO OPCODE Registration 1284 IANA are directed to assign a value (tentatively 6) in the DNS 1285 OPCODEs Registry for the DSO OPCODE. 1287 10.2. DSO RCODE Registration 1289 IANA are directed to assign a value (tentatively 11) in the DNS RCODE 1290 Registry for the DSONOTIMP error code. 1292 10.3. DSO Type Codes Registry 1294 IANA are directed to create the DSO Type Codes Registry, with initial 1295 values as follows: 1297 +-----------+--------------------------------+----------+-----------+ 1298 | Type | Name | Status | Reference | 1299 +-----------+--------------------------------+----------+-----------+ 1300 | 0x0000 | RetryDelay | Standard | RFC-TBD | 1301 | | | | | 1302 | 0x0001 | KeepAlive | Standard | RFC-TBD | 1303 | | | | | 1304 | 0x0002 | Encryption Padding | Standard | RFC-TBD | 1305 | | | | | 1306 | 0x0003 - | Unassigned, reserved for DSO | | | 1307 | 0x003F | session management TLVs | | | 1308 | | | | | 1309 | 0x0040 - | Unassigned | | | 1310 | 0xF7FF | | | | 1311 | | | | | 1312 | 0xF800 - | Reserved for local / | | | 1313 | 0xFBFF | experimental use | | | 1314 | | | | | 1315 | 0xFC00 - | Reserved for future expansion | | | 1316 | 0xFFFF | | | | 1317 +-----------+--------------------------------+----------+-----------+ 1319 Registration of additional DSO Type Codes requires publication of an 1320 appropriate IETF "Standards Action" or "IESG Approval" document 1321 [RFC5226]. 1323 11. Security Considerations 1325 If this mechanism is to be used with DNS over TLS, then these 1326 messages are subject to the same constraints as any other DNS over 1327 TLS messages and MUST NOT be sent in the clear before the TLS session 1328 is established. 1330 The data field of the "Encryption Padding" TLV could be used as a 1331 covert channel. 1333 12. Acknowledgements 1335 Thanks to Tim Chown, Ralph Droms, Jan Komissar, and Manju Shankar Rao 1336 for their helpful contributions to this document. 1338 13. References 1340 13.1. Normative References 1342 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1343 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1344 . 1346 [RFC1035] Mockapetris, P., "Domain names - implementation and 1347 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1348 November 1987, . 1350 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1351 and E. Lear, "Address Allocation for Private Internets", 1352 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1353 . 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, 1357 DOI 10.17487/RFC2119, March 1997, . 1360 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1361 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1362 . 1364 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1365 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1366 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1367 . 1369 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1370 IANA Considerations Section in RFCs", RFC 5226, 1371 DOI 10.17487/RFC5226, May 2008, . 1374 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1375 for DNS (EDNS(0))", STD 75, RFC 6891, 1376 DOI 10.17487/RFC6891, April 2013, . 1379 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1380 D. Wessels, "DNS Transport over TCP - Implementation 1381 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1382 . 1384 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1385 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1386 DOI 10.17487/RFC7828, April 2016, . 1389 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1390 DOI 10.17487/RFC7830, May 2016, . 1393 13.2. Informative References 1395 [I-D.ietf-dnssd-push] 1396 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1397 draft-ietf-dnssd-push-12 (work in progress), July 2017. 1399 [I-D.ietf-dprive-padding-policy] 1400 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 1401 dprive-padding-policy-01 (work in progress), July 2017. 1403 [NagleDA] Cheshire, S., "TCP Performance problems caused by 1404 interaction between Nagle's Algorithm and Delayed ACK", 1405 May 2005, 1406 . 1408 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1409 DOI 10.17487/RFC0768, August 1980, . 1412 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1413 and P. Hoffman, "Specification for DNS over Transport 1414 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1415 2016, . 1417 Authors' Addresses 1419 Ray Bellis 1420 Internet Systems Consortium, Inc. 1421 950 Charter Street 1422 Redwood City CA 94063 1423 USA 1425 Phone: +1 650 423 1200 1426 Email: ray@isc.org 1428 Stuart Cheshire 1429 Apple Inc. 1430 1 Infinite Loop 1431 Cupertino CA 95014 1432 USA 1434 Phone: +1 408 974 3207 1435 Email: cheshire@apple.com 1436 John Dickinson 1437 Sinodun Internet Technologies 1438 Magadalen Centre 1439 Oxford Science Park 1440 Oxford OX4 4GA 1441 United Kingdom 1443 Email: jad@sinodun.com 1445 Sara Dickinson 1446 Sinodun Internet Technologies 1447 Magadalen Centre 1448 Oxford Science Park 1449 Oxford OX4 4GA 1450 United Kingdom 1452 Email: sara@sinodun.com 1454 Allison Mankin 1455 Salesforce 1457 Email: allison.mankin@gmail.com 1459 Tom Pusateri 1460 Unaffiliated 1462 Phone: +1 919 867 1330 1463 Email: pusateri@bangj.com