idnits 2.17.1 draft-ietf-dnsop-session-signal-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1035, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 02, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA1' is mentioned on line 1925, but not defined == Missing Reference: 'TBA2' is mentioned on line 1931, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-dnssd-mdns-relay-00 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-14 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-padding-policy-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group R. Bellis 3 Internet-Draft ISC 4 Updates: 1035, 7766 (if approved) S. Cheshire 5 Intended status: Standards Track Apple Inc. 6 Expires: January 3, 2019 J. Dickinson 7 S. Dickinson 8 Sinodun 9 T. Lemon 10 Barefoot Consulting 11 T. Pusateri 12 Unaffiliated 13 July 02, 2018 15 DNS Stateful Operations 16 draft-ietf-dnsop-session-signal-11 18 Abstract 20 This document defines a new DNS OPCODE for DNS Stateful Operations 21 (DSO). DSO messages communicate operations within persistent 22 stateful sessions, using type-length-value (TLV) syntax. Three TLVs 23 are defined that manage session timeouts, termination, and encryption 24 padding, and a framework is defined for extensions to enable new 25 stateful operations. This document updates RFC 1035 by adding a new 26 DNS header opcode and result code which has different message 27 semantics. This document updates RFC 7766 by redefining a session, 28 providing new guidance on connection re-use, and providing a new 29 mechanism for handling session idle timeouts. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 10 71 5.1.1. Connection Sharing . . . . . . . . . . . . . . . . . 12 72 5.1.2. Zero Round-Trip Operation . . . . . . . . . . . . . . 12 73 5.1.3. Middlebox Considerations . . . . . . . . . . . . . . 13 74 5.2. Message Format . . . . . . . . . . . . . . . . . . . . . 14 75 5.2.1. DNS Header Fields in DSO Messages . . . . . . . . . . 15 76 5.2.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 17 77 5.2.3. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 22 78 5.3. Message Handling . . . . . . . . . . . . . . . . . . . . 23 79 5.3.1. Error Responses . . . . . . . . . . . . . . . . . . . 24 80 5.4. DSO Response Generation . . . . . . . . . . . . . . . . . 25 81 5.5. Responder-Initiated Operation Cancellation . . . . . . . 26 82 6. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 27 83 6.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 27 84 6.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 27 85 6.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 28 86 6.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 29 87 6.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 29 88 6.4.2. Values for the Inactivity Timeout . . . . . . . . . . 30 89 6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 31 90 6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 31 91 6.5.2. Values for the Keepalive Interval . . . . . . . . . . 31 92 6.6. Server-Initiated Session Termination . . . . . . . . . . 33 93 6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 34 94 7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 37 95 7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 37 96 7.1.1. Client handling of received Session Timeout values . 39 97 7.1.2. Relation to EDNS(0) TCP Keepalive Option . . . . . . 41 98 7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 42 99 7.2.1. Retry Delay TLV used as a Primary TLV . . . . . . . . 42 100 7.2.2. Retry Delay TLV used as a Response Additional TLV . . 44 101 7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 44 102 8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 45 103 8.1. QR bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 45 104 8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 46 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 106 9.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . . 48 107 9.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 48 108 9.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 48 109 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 110 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 50 113 12.2. Informative References . . . . . . . . . . . . . . . . . 51 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 116 1. Introduction 118 The use of transports for DNS other than UDP is being increasingly 119 specified, for example, DNS over TCP [RFC1035] [RFC7766] and DNS over 120 TLS [RFC7858]. Such transports can offer persistent, long-lived 121 sessions and therefore when using them for transporting DNS messages 122 it is of benefit to have a mechanism that can establish parameters 123 associated with those sessions, such as timeouts. In such situations 124 it is also advantageous to support server-initiated messages. 126 The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is 127 explicitly defined to only have "per-message" semantics. While 128 EDNS(0) has been used to signal at least one session-related 129 parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is 130 less than optimal due to the restrictions imposed by the EDNS(0) 131 semantics and the lack of server-initiated signalling. For example, 132 a server cannot arbitrarily instruct a client to close a connection 133 because the server can only send EDNS(0) options in responses to 134 queries that contained EDNS(0) options. 136 This document defines a new DNS OPCODE, DSO ([TBA1], tentatively 6), 137 for DNS Stateful Operations. DSO messages are used to communicate 138 operations within persistent stateful sessions, expressed using type- 139 length-value (TLV) syntax. This document defines an initial set of 140 three TLVs, used to manage session timeouts, termination, and 141 encryption padding. 143 The three TLVs defined here are all mandatory for all implementations 144 of DSO. Further TLVs may be defined in additional specifications. 146 The format for DSO messages (Section 5.2) differs somewhat from the 147 traditional DNS message format used for standard queries and 148 responses. The standard twelve-byte 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 pseudo-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 DSO operation is communicated in its own 179 separate DNS message, and the transport protocol can take care of 180 packing several 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. Requirements Language 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 BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 3. Terminology 197 "DSO" is used to mean DNS Stateful Operation. 199 The term "connection" means a bidirectional byte (or message) stream, 200 where the bytes (or messages) are delivered reliably and in-order, 201 such as provided by using DNS over TCP [RFC1035] [RFC7766] or DNS 202 over TLS [RFC7858]. 204 The unqualified term "session" in the context of this document means 205 the exchange of DNS messages over a connection where: 207 o The connection between client and server is persistent and 208 relatively long-lived (i.e., minutes or hours, rather than 209 seconds). 211 o Either end of the connection may initiate messages to the other. 213 In this document the term "session" is used exclusively as described 214 above. The term has no relationship to the "session layer" of the 215 OSI "seven-layer model". 217 A "DSO Session" is established between two endpoints that acknowledge 218 persistent DNS state via the exchange of DSO messages over the 219 connection. This is distinct from a DNS-over-TCP session as 220 described in the previous specification for DNS over TCP [RFC7766]. 222 A "DSO Session" is terminated when the underlying connection is 223 closed. The underlying connection can be closed in two ways: 225 Where this specification says, "close gracefully," that means sending 226 a TLS close_notify (if TLS is in use) followed by a TCP FIN, or the 227 equivalents for other protocols. Where this specification requires a 228 connection to be closed gracefully, the requirement to initiate that 229 graceful close is placed on the client, to place the burden of TCP's 230 TIME-WAIT state on the client rather than the server. 232 Where this specification says, "forcibly abort," that means sending a 233 TCP RST, or the equivalent for other protocols. In the BSD Sockets 234 API this is achieved by setting the SO_LINGER option to zero before 235 closing the socket. 237 The term "server" means the software with a listening socket, 238 awaiting incoming connection requests. 240 The term "client" means the software which initiates a connection to 241 the server's listening socket. 243 The terms "initiator" and "responder" correspond respectively to the 244 initial sender and subsequent receiver of a DSO request message or 245 unacknowledged message, regardless of which was the "client" and 246 "server" in the usual DNS sense. 248 The term "sender" may apply to either an initiator (when sending a 249 DSO request message or unacknowledged message) or a responder (when 250 sending a DSO response message). 252 Likewise, the term "receiver" may apply to either a responder (when 253 receiving a DSO request message or unacknowledged message) or an 254 initiator (when receiving a DSO response message). 256 In protocol implementation there are generally two kinds of errors 257 that software writers have to deal with. The first is situations 258 that arise due to factors in the environment, such as temporary loss 259 of connectivity. While undesirable, these situations do not indicate 260 a flaw in the software, and they are situations that software should 261 generally be able to recover from. The second is situations that 262 should never happen when communicating with a correctly-implemented 263 peer. If they do happen, they indicate a serious flaw in the 264 protocol implementation, beyond what it is reasonable to expect 265 software to recover from. This document describes this latter form 266 of error condition as a "fatal error" and specifies that an 267 implementation encountering a fatal error condition "MUST forcibly 268 abort the connection immediately". Given that these fatal error 269 conditions signify defective software, and given that defective 270 software is likely to remain defective for some time until it is 271 fixed, after forcibly aborting a connection, a client SHOULD refrain 272 from automatically reconnecting to that same service instance for at 273 least one hour. 275 This document uses the term "same service instance" as follows: 277 o In cases where a server is specified or configured using an IP 278 address and TCP port number, two different configurations are 279 referring to the same service instance if they contain the same IP 280 address and TCP port number. 282 o In cases where a server is specified or configured using a 283 hostname and TCP port number, such as in the content of a DNS SRV 284 record [RFC2782], two different configurations (or DNS SRV 285 records) are considered to be referring to the same service 286 instance if they contain the same hostname (subject to the usual 287 case insensitive DNS name matching rules [RFC1034] [RFC1035]) and 288 TCP port number. In these cases, configurations with different 289 hostnames are considered to be referring to different service 290 instances, even if those different hostnames happen to be aliases, 291 or happen to resolve to the same IP address(es). Implementations 292 SHOULD NOT resolve hostnames and then perform matching of IP 293 address(es) in order to evaluate whether two entities should be 294 determined to be the "same service instance". 296 When an anycast service is configured on a particular IP address and 297 port, it must be the case that although there is more than one 298 physical server responding on that IP address, each such server can 299 be treated as equivalent. If a change in network topology causes 300 packets in a particular TCP connection to be sent to an anycast 301 server instance that does not know about the connection, the normal 302 keepalive and TCP connection timeout process will allow for recovery. 303 If after the connection is re-established, the client's assumption 304 that it is connected to the same service is violated in some way, 305 that would be considered to be incorrect behavior in this context. 306 It is however out of the possible scope for this specification to 307 make specific recommendations in this regard; that would be up to 308 follow-on documents that describe specific uses of DNS stateful 309 operations. 311 The term "long-lived operations" refers to operations such as Push 312 Notification subscriptions [I-D.ietf-dnssd-push], Discovery Relay 313 interface subscriptions [I-D.ietf-dnssd-mdns-relay], and other future 314 long-lived DNS operations that choose to use DSO as their basis. 315 These operations establish state that persists beyond the lifetime of 316 a traditional brief request/response transaction. This document, the 317 base specification for DNS Stateful Operations, defines a framework 318 for supporting long-lived operations, but does not itself define any 319 long-lived operations. Nonetheless, to appreciate the design 320 rationale behind DNS Stateful Operations, it is helpful to understand 321 the kind of long-lived operations that it is intended to support. 323 DNS Stateful Operations uses three kinds of message: "DSO request 324 messages", "DSO response messages", and "DSO unacknowledged 325 messages". A DSO request message elicits a DSO response message. 326 DSO unacknowledged messages are unidirectional messages and do not 327 generate any response. 329 Both DSO request messages and DSO unacknowledged messages are 330 formatted as DNS request messages (the header QR bit is set to zero, 331 as described in Section 5.2). One difference is that in DSO request 332 messages the MESSAGE ID field is nonzero; in DSO unacknowledged 333 messages it is zero. 335 The content of DSO messages is expressed using type-length-value 336 (TLV) syntax. 338 In a DSO request message or DSO unacknowledged message the first TLV 339 is referred to as the "Primary TLV" and determines the nature of the 340 operation being performed, including whether it is an acknowledged or 341 unacknowledged operation; any other TLVs in a DSO request message or 342 unacknowledged message are referred to as "Additional TLVs" and serve 343 additional non-primary purposes, which may be related to the primary 344 purpose, or not, as in the case of the encryption padding TLV. 346 A DSO response message may contain no TLVs, or it may contain one or 347 more TLVs as appropriate to the information being communicated. In 348 the context of DSO response messages, one or more TLVs with the same 349 DSO-TYPE as the Primary TLV in the corresponding DSO request message 350 are referred to as "Response Primary TLVs". Any other TLVs with 351 different DSO-TYPEs are referred to as "Response Additional TLVs". 352 The Response Primary TLV(s), if present, MUST occur first in the 353 response message, before any Response Additional TLVs. 355 Two timers (elapsed time since an event) are defined in this 356 document: 358 o an inactivity timer (see Section 6.4 and Section 7.1) 360 o a keepalive timer (see Section 6.5 and Section 7.1) 362 The timeouts associated with these timers are called the inactivity 363 timeout and the keepalive interval, respectively. The term "Session 364 Timeouts" is used to refer to this pair of timeout values. 366 Resetting a timer means resetting the timer value to zero and 367 starting the timer again. Clearing a timer means resetting the timer 368 value to zero but NOT starting the timer again. 370 4. Discussion 372 There are several use cases for DNS Stateful operations that can be 373 described here. 375 Firstly, establishing session parameters such as server-defined 376 timeouts is of great use in the general management of persistent 377 connections. For example, using DSO sessions for stub-to-recursive 378 DNS-over-TLS [RFC7858] is more flexible for both the client and the 379 server than attempting to manage sessions using just the EDNS(0) TCP 380 Keepalive option [RFC7828]. The simple set of TLVs defined in this 381 document is sufficient to greatly enhance connection management for 382 this use case. 384 Secondly, DNS-SD [RFC6763] has evolved into a naturally session-based 385 mechanism where, for example, long-lived subscriptions lend 386 themselves to 'push' mechanisms as opposed to polling. Long-lived 387 stateful connections and server-initiated messages align with this 388 use case [I-D.ietf-dnssd-push]. 390 A general use case is that DNS traffic is often bursty but session 391 establishment can be expensive. One challenge with long-lived 392 connections is to maintain sufficient traffic to maintain NAT and 393 firewall state. To mitigate this issue this document introduces a 394 new concept for the DNS, that is DSO "Keepalive traffic". This 395 traffic carries no DNS data and is not considered 'activity' in the 396 classic DNS sense, but serves to maintain state in middleboxes, and 397 to assure client and server that they still have connectivity to each 398 other. 400 5. Protocol Details 402 5.1. DSO Session Establishment 404 DSO messages MUST be carried in only protocols and in environments 405 where a session may be established according to the definition given 406 above in the Terminology section (Section 3). 408 DNS over plain UDP [RFC0768] is not appropriate since it fails on the 409 requirement for in-order message delivery, and, in the presence of 410 NAT gateways and firewalls with short UDP timeouts, it fails to 411 provide a persistent bi-directional communication channel unless an 412 excessive amount of keepalive traffic is used. 414 At the time of publication, DSO is specified only for DNS over TCP 415 [RFC1035] [RFC7766], and for DNS over TLS over TCP [RFC7858]. Any 416 use of DSO over some other connection technology needs to be 417 specified in an appropriate future document. 419 Determining whether a given connection is using DNS over TCP, or DNS 420 over TLS over TCP, is outside the scope of this specification, and 421 must be determined using some out-of-band configuration information. 422 There is no provision within the DSO specification to turn TLS on or 423 off during the lifetime of a connection. For service types where the 424 service instance is discovered using a DNS SRV record [RFC2782], the 425 specification for that service type SRV name [RFC6335] will state 426 whether the connection uses plain TCP, or TLS over TCP. For example, 427 the specification for the "_dns-push-tls._tcp" service 428 [I-D.ietf-dnssd-push], states that it uses TLS. It is a common 429 convention that protocols specified to run over TLS are given IANA 430 service type names ending in "-tls". 432 In some environments it may be known in advance by external means 433 that both client and server support DSO, and in these cases either 434 client or server may initiate DSO messages at any time. 436 However, in the typical case a server will not know in advance 437 whether a client supports DSO, so in general, unless it is known in 438 advance by other means that a client does support DSO, a server MUST 439 NOT initiate DSO request messages or DSO unacknowledged messages 440 until a DSO Session has been mutually established by at least one 441 successful DSO request/response exchange initiated by the client, as 442 described below. Similarly, unless it is known in advance by other 443 means that a server does support DSO, a client MUST NOT initiate DSO 444 unacknowledged messages until after a DSO Session has been mutually 445 established. 447 A DSO Session is established over a connection by the client sending 448 a DSO request message, such as a DSO Keepalive request message 449 (Section 7.1), and receiving a response, with matching MESSAGE ID, 450 and RCODE set to NOERROR (0), indicating that the DSO request was 451 successful. 453 If the RCODE in the response is set to DSOTYPENI ("DSO-TYPE Not 454 Implemented", [TBA2] tentatively RCODE 11) this indicates that the 455 server does support DSO, but does not implement the DSO-TYPE of the 456 primary TLV in this DSO request message. A server implementing DSO 457 MUST NOT return DSOTYPENI for a DSO Keepalive request message, 458 because the Keepalive TLV is mandatory to implement. But in the 459 future, if a client attempts to establish a DSO Session using a 460 response-requiring DSO request message using some newly-defined DSO- 461 TYPE that the server does not understand, that would result in a 462 DSOTYPENI response. If the server returns DSOTYPENI then a DSO 463 Session is not considered established, but the client is permitted to 464 continue sending DNS messages on the connection, including other DSO 465 messages such as the DSO Keepalive, which may result in a successful 466 NOERROR response, yielding the establishment of a DSO Session. 468 If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI 469 ([TBA2] tentatively 11), then the client MUST assume that the server 470 does not implement DSO at all. In this case the client is permitted 471 to continue sending DNS messages on that connection, but the client 472 SHOULD NOT issue further DSO messages on that connection. 474 When the server receives a DSO request message from a client, and 475 transmits a successful NOERROR response to that request, the server 476 considers the DSO Session established. 478 When the client receives the server's NOERROR response to its DSO 479 request message, the client considers the DSO Session established. 481 Once a DSO Session has been established, either end may unilaterally 482 send appropriate DSO messages at any time, and therefore either 483 client or server may be the initiator of a message. 485 Once a DSO Session has been established, clients and servers should 486 behave as described in this specification with regard to inactivity 487 timeouts and session termination, not as previously prescribed in the 488 earlier specification for DNS over TCP [RFC7766]. 490 Note that for clients that implement only the DSO-TYPEs defined in 491 this base specification, sending a DSO Keepalive TLV is the only DSO 492 request message they have available to initiate a DSO Session. Even 493 for clients that do implement other future DSO-TYPEs, for simplicity 494 they MAY elect to always send an initial DSO Keepalive request 495 message as their way of initiating a DSO Session. A future 496 definition of a new response-requiring DSO-TYPE gives implementers 497 the option of using that new DSO-TYPE if they wish, but does not 498 change the fact that sending a DSO Keepalive TLV remains a valid way 499 of initiating a DSO Session. 501 5.1.1. Connection Sharing 503 As previously specified for DNS over TCP [RFC7766]: 505 To mitigate the risk of unintentional server overload, DNS 506 clients MUST take care to minimize the number of concurrent 507 TCP connections made to any individual server. It is RECOMMENDED 508 that for any given client/server interaction there SHOULD be 509 no more than one connection for regular queries, one for zone 510 transfers, and one for each protocol that is being used on top 511 of TCP (for example, if the resolver was using TLS). However, 512 it is noted that certain primary/secondary configurations 513 with many busy zones might need to use more than one TCP 514 connection for zone transfers for operational reasons (for 515 example, to support concurrent transfers of multiple zones). 517 A single server may support multiple services, including DNS Updates 518 [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other 519 services, for one or more DNS zones. When a client discovers that 520 the target server for several different operations is the same target 521 hostname and port, the client SHOULD use a single shared DSO Session 522 for all those operations. A client SHOULD NOT open multiple 523 connections to the same target host and port just because the names 524 being operated on are different or happen to fall within different 525 zones. This requirement is to reduce unnecessary connection load on 526 the DNS server. 528 However, server implementers and operators should be aware that 529 connection sharing may not be possible in all cases. A single host 530 device may be home to multiple independent client software instances 531 that don't coordinate with each other. Similarly, multiple 532 independent client devices behind the same NAT gateway will also 533 typically appear to the DNS server as different source ports on the 534 same client IP address. Because of these constraints, a DNS server 535 MUST be prepared to accept multiple connections from different source 536 ports on the same client IP address. 538 5.1.2. Zero Round-Trip Operation 540 There is increased awareness today of the performance benefits of 541 eliminating round trips in session establishment. Technologies like 542 TCP Fast Open [RFC7413] and TLS 1.3 [I-D.ietf-tls-tls13] provide 543 mechanisms to reduce or eliminate round trips in session 544 establishment. 546 Similarly, DSO supports zero round-trip operation. 548 Having initiated a connection to a server, possibly using zero round- 549 trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send 550 multiple response-requiring DSO request messages to the server in 551 succession without having to wait for a response to the first request 552 message to confirm successful establishment of a DSO session. 554 However, a client MUST NOT send non-response-requiring DSO request 555 messages until after a DSO Session has been mutually established. 557 Similarly, a server MUST NOT send DSO request messages until it has 558 received a response-requiring DSO request message from a client and 559 transmitted a successful NOERROR response for that request. 561 Caution must be taken to ensure that DSO messages sent before the 562 first round-trip is completed are idempotent, or are otherwise immune 563 to any problems that could be result from the inadvertent replay that 564 can occur with zero round-trip operation. 566 5.1.3. Middlebox Considerations 568 Where an application-layer middlebox (e.g., a DNS proxy, forwarder, 569 or session multiplexer) is in the path, the middlebox MUST NOT 570 blindly forward DSO messages in either direction, and MUST treat the 571 inbound and outbound connections as separate sessions. This does not 572 preclude the use of DSO messages in the presence of an IP-layer 573 middlebox, such as a NAT that rewrites IP-layer and/or transport- 574 layer headers but otherwise preserves the effect of a single session 575 between the client and the server. 577 To illustrate the above, consider a network where a middlebox 578 terminates one or more TCP connections from clients and multiplexes 579 the queries therein over a single TCP connection to an upstream 580 server. The DSO messages and any associated state are specific to 581 the individual TCP connections. A DSO-aware middlebox MAY in some 582 circumstances be able to retain associated state and pass it between 583 the client and server (or vice versa) but this would be highly TLV- 584 specific. For example, the middlebox may be able to maintain a list 585 of which clients have made Push Notification subscriptions 586 [I-D.ietf-dnssd-push] and make its own subscription(s) on their 587 behalf, relaying any subsequent notifications to the client (or 588 clients) that have subscribed to that particular notification. 590 5.2. Message Format 592 A DSO message begins with the standard twelve-byte DNS message header 593 [RFC1035] with the OPCODE field set to the DSO OPCODE ([TBA1] 594 tentatively 6). However, unlike standard DNS messages, the question 595 section, answer section, authority records section and additional 596 records sections are not present. The corresponding count fields 597 (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero on 598 transmission. 600 If a DSO message is received where any of the count fields are not 601 zero, then a FORMERR MUST be returned, unless a future IETF Standard 602 specifies otherwise. 604 1 1 1 1 1 1 605 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 606 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 607 | MESSAGE ID | 608 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 609 |QR | OPCODE | Z | RCODE | 610 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 611 | QDCOUNT (MUST be zero) | 612 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 613 | ANCOUNT (MUST be zero) | 614 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 615 | NSCOUNT (MUST be zero) | 616 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 617 | ARCOUNT (MUST be zero) | 618 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 619 | | 620 / DSO Data / 621 / / 622 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 624 5.2.1. DNS Header Fields in DSO Messages 626 In an unacknowledged message the MESSAGE ID field MUST be set to 627 zero. In an acknowledged request message the MESSAGE ID field MUST 628 be set to a unique nonzero value, that the initiator is not currently 629 using for any other active operation on this connection. For the 630 purposes here, a MESSAGE ID is in use in this DSO Session if the 631 initiator has used it in a request for which it is still awaiting a 632 response, or if the client has used it to set up a long-lived 633 operation that has not yet been cancelled. For example, a long-lived 634 operation could be a Push Notification subscription 635 [I-D.ietf-dnssd-push] or a Discovery Relay interface subscription 636 [I-D.ietf-dnssd-mdns-relay]. 638 Whether a message is acknowledged or unacknowledged is determined 639 only by the specification for the Primary TLV. An acknowledgment 640 cannot be requested by including a nonzero message ID in a message 641 the primary TLV of which is specified to be unacknowledged, nor can 642 an acknowledgment be prevented by sending a message ID of zero in a 643 message with a primary TLV that is specified to be acknowledged. A 644 responder that receives either such malformed message MUST treat it 645 as a fatal error and forcibly abort the connection immediately. 647 In a request or unacknowledged message the DNS Header QR bit MUST be 648 zero (QR=0). If the QR bit is not zero the message is not a request 649 or unacknowledged message. 651 In a response message the DNS Header QR bit MUST be one (QR=1). 652 If the QR bit is not one the message is not a response message. 654 In a response message (QR=1) the MESSAGE ID field MUST contain a copy 655 of the value of the MESSAGE ID field in the request message being 656 responded to. In a response message (QR=1) the MESSAGE ID field MUST 657 NOT be zero. If a response message (QR=1) is received where the 658 MESSAGE ID is zero this is a fatal error and the recipient MUST 659 forcibly abort the connection immediately. 661 The DNS Header OPCODE field holds the DSO OPCODE value ([TBA1] 662 tentatively 6). 664 The Z bits are currently unused in DSO messages, and in both DSO 665 requests and DSO responses the Z bits MUST be set to zero (0) on 666 transmission and MUST be silently ignored on reception, unless a 667 future IETF Standard specifies otherwise. 669 In a DNS request message (QR=0) the RCODE is set according to the 670 definition of the request. For example, in a Retry Delay message 671 (Section 6.6.1) the RCODE indicates the reason for termination. 672 However, in most cases, except where clearly specified otherwise, in 673 a DNS request message (QR=0) the RCODE is set to zero on 674 transmission, and silently ignored on reception. 676 The RCODE value in a response message (QR=1) may be one of the 677 following values: 679 +---------+-----------+---------------------------------------------+ 680 | Code | Mnemonic | Description | 681 +---------+-----------+---------------------------------------------+ 682 | 0 | NOERROR | Operation processed successfully | 683 | | | | 684 | 1 | FORMERR | Format error | 685 | | | | 686 | 2 | SERVFAIL | Server failed to process request due to a | 687 | | | problem with the server | 688 | | | | 689 | 3 | NXDOMAIN | Name Error -- Named entity does not exist | 690 | | | (TLV-dependent) | 691 | | | | 692 | 4 | NOTIMP | DSO not supported | 693 | | | | 694 | 5 | REFUSED | Operation declined for policy reasons | 695 | | | | 696 | 9 | NOTAUTH | Not Authoritative (TLV-dependent) | 697 | | | | 698 | [TBA2] | DSOTYPENI | Primary TLV's DSO-Type is not implemented | 699 | 11 | | | 700 +---------+-----------+---------------------------------------------+ 702 Use of the above RCODEs is likely to be common in DSO but does not 703 preclude the definition and use of other codes in future documents 704 that make use of DSO. 706 If a document defining a new DSO-TYPE makes use of NXDOMAIN (Name 707 Error) or NOTAUTH (Not Authoritative) then that document MUST specify 708 the specific interpretation of these RCODE values in the context of 709 that new DSO TLV. 711 5.2.2. DSO Data 713 The standard twelve-byte DNS message header with its zero-valued 714 count fields is followed by the DSO Data, expressed using TLV syntax, 715 as described below Section 5.2.2.1. 717 A DSO message may be a request message, a response message, or an 718 unacknowledged message. 720 A DSO request message or DSO unacknowledged message MUST contain at 721 least one TLV. The first TLV in a DSO request message or DSO 722 unacknowledged message is referred to as the "Primary TLV" and 723 determines the nature of the operation being performed, including 724 whether it is an acknowledged or unacknowledged operation. In some 725 cases it may be appropriate to include other TLVs in a request 726 message or unacknowledged message, such as the Encryption Padding TLV 727 (Section 7.3), and these extra TLVs are referred to as the 728 "Additional TLVs" and are not limited to what is defined in this 729 document. New "Additional TLVs" may be defined in the future and 730 those definitions will describe when their use is appropriate. 732 A DSO response message may contain no TLVs, or it may be specified to 733 contain one or more TLVs appropriate to the information being 734 communicated. This includes "Primary TLVs" and "Additional TLVs" 735 defined in this document as well as in future TLV definitions. 737 A DSO response message may contain one or more TLVs with DSO-TYPE the 738 same as the Primary TLV from the corresponding DSO request message, 739 in which case those TLV(s) are referred to as "Response Primary 740 TLVs". A DSO response message is not required to carry Response 741 Primary TLVs. The MESSAGE ID field in the DNS message header is 742 sufficient to identify the DSO request message to which this response 743 message relates. 745 A DSO response message may contain one or more TLVs with DSO-TYPEs 746 different from the Primary TLV from the corresponding DSO request 747 message, in which case those TLV(s) are referred to as "Response 748 Additional TLVs". 750 Response Primary TLV(s), if present, MUST occur first in the response 751 message, before any Response Additional TLVs. 753 It is anticipated that most DSO operations will be specified to use 754 request messages, which generate corresponding responses. In some 755 specialized high-traffic use cases, it may be appropriate to specify 756 unacknowledged messages. Unacknowledged messages can be more 757 efficient on the network, because they don't generate a stream of 758 corresponding reply messages. Using unacknowledged messages can also 759 simplify software in some cases, by removing need for an initiator to 760 maintain state while it waits to receive replies it doesn't care 761 about. When the specification for a particular TLV states that, when 762 used as a Primary TLV (i.e., first) in an outgoing DNS request 763 message (i.e., QR=0), that message is to be unacknowledged, the 764 MESSAGE ID field MUST be set to zero and the receiver MUST NOT 765 generate any response message corresponding to this unacknowledged 766 message. 768 The previous point, that the receiver MUST NOT generate responses to 769 unacknowledged messages, applies even in the case of errors. When a 770 DSO message is received where both the QR bit and the MESSAGE ID 771 field are zero, the receiver MUST NOT generate any response. For 772 example, if the DSO-TYPE in the Primary TLV is unrecognized, then a 773 DSOTYPENI error MUST NOT be returned; instead the receiver MUST 774 forcibly abort the connection immediately. 776 Unacknowledged messages MUST NOT be used "speculatively" in cases 777 where the sender doesn't know if the receiver supports the Primary 778 TLV in the message, because there is no way to receive any response 779 to indicate success or failure of the request message (the request 780 message does not contain a unique MESSAGE ID with which to associate 781 a response with its corresponding request). Unacknowledged messages 782 are only appropriate in cases where the sender already knows that the 783 receiver supports, and wishes to receive, these messages. 785 For example, after a client has subscribed for Push Notifications 786 [I-D.ietf-dnssd-push], the subsequent event notifications are then 787 sent as unacknowledged messages, and this is appropriate because the 788 client initiated the message stream by virtue of its Push 789 Notification subscription, thereby indicating its support of Push 790 Notifications, and its desire to receive those notifications. 792 Similarly, after an Discovery Relay client has subscribed to receive 793 inbound mDNS (multicast DNS, [RFC6762]) traffic from an Discovery 794 Relay, the subsequent stream of received packets is then sent using 795 unacknowledged messages, and this is appropriate because the client 796 initiated the message stream by virtue of its Discovery Relay link 797 subscription, thereby indicating its support of Discovery Relay, and 798 its desire to receive inbound mDNS packets over that DSO session 799 [I-D.ietf-dnssd-mdns-relay]. 801 5.2.2.1. TLV Syntax 803 All TLVs, whether used as "Primary", "Additional", "Response 804 Primary", or "Response Additional", use the same encoding syntax. 806 The specification for a TLV states whether that DSO-TYPE may be used 807 in "Primary", "Additional", "Response Primary", or "Response 808 Additional" TLVs. The specification for a TLV also states whether, 809 when used as the Primary (i.e., first) TLV in a DNS request message 810 (i.e., QR=0), that DSO message is to be acknowledged. If the DSO 811 message is to be acknowledged, the specification also states which 812 TLVs, if any, are to be included in the response. The Primary TLV 813 may or may not be contained in the response, depending on what is 814 stated in the specification for that TLV. 816 1 1 1 1 1 1 817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 818 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 819 | DSO-TYPE | 820 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 821 | DSO-LENGTH | 822 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 823 | | 824 / DSO-DATA / 825 / / 826 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 828 DSO-TYPE: A 16-bit unsigned integer, in network (big endian) byte 829 order, giving the DSO-TYPE of the current DSO TLV per the IANA DSO 830 Type Code Registry. 832 DSO-LENGTH: A 16-bit unsigned integer, in network (big endian) byte 833 order, giving the size in bytes of the DSO-DATA. 835 DSO-DATA: Type-code specific format. The generic DSO machinery 836 treats the DSO-DATA as an opaque "blob" without attempting to 837 interpret it. Interpretation of the meaning of the DSO-DATA for a 838 particular DSO-TYPE is the responsibility of the software that 839 implements that DSO-TYPE. 841 5.2.2.2. Request TLVs 843 The first TLV in a DSO request message or unacknowledged message is 844 the "Primary TLV" and indicates the operation to be performed. A DSO 845 request message or unacknowledged message MUST contain at at least 846 one TLV, the Primary TLV. 848 Immediately following the Primary TLV, a DSO request message or 849 unacknowledged message MAY contain one or more "Additional TLVs", 850 which specify additional parameters relating to the operation. 852 5.2.2.3. Response TLVs 854 Depending on the operation, a DSO response message MAY contain no 855 TLVs, because it is simply a response to a previous request message, 856 and the MESSAGE ID in the header is sufficient to identify the 857 request in question. Or it may contain a single response TLV, with 858 the same DSO-TYPE as the Primary TLV in the request message. 859 Alternatively it may contain one or more TLVs of other types, or a 860 combination of the above, as appropriate for the information that 861 needs to be communicated. The specification for each DSO TLV 862 determines what TLVs are required in a response to a request using 863 that TLV. 865 If a DSO response is received for an operation where the 866 specification requires that the response carry a particular TLV or 867 TLVs, and the required TLV(s) are not present, then this is a fatal 868 error and the recipient of the defective response message MUST 869 forcibly abort the connection immediately. 871 5.2.2.4. Unrecognized TLVs 873 If DSO request message is received containing an unrecognized Primary 874 TLV, with a nonzero MESSAGE ID (indicating that a response is 875 expected), then the receiver MUST send an error response with 876 matching MESSAGE ID, and RCODE DSOTYPENI ([TBA2] tentatively 11). 877 The error response MUST NOT contain a copy of the unrecognized 878 Primary TLV. 880 If DSO unacknowledged message is received containing an unrecognized 881 Primary TLV, with a zero MESSAGE ID (indicating that no response is 882 expected), then this is a fatal error and the recipient MUST forcibly 883 abort the connection immediately. 885 If a DSO request message or unacknowledged message is received where 886 the Primary TLV is recognized, containing one or more unrecognized 887 Additional TLVs, the unrecognized Additional TLVs MUST be silently 888 ignored, and the remainder of the message is interpreted and handled 889 as if the unrecognized parts were not present. 891 Similarly, if a DSO response message is received containing one or 892 more unrecognized TLVs, the unrecognized TLVs MUST be silently 893 ignored, and the remainder of the message is interpreted and handled 894 as if the unrecognized parts were not present. 896 5.2.3. EDNS(0) and TSIG 898 Since the ARCOUNT field MUST be zero, a DSO message MUST NOT contain 899 an EDNS(0) option in the additional records section. If 900 functionality provided by current or future EDNS(0) options is 901 desired for DSO messages, one or more new DSO TLVs need to be defined 902 to carry the necessary information. 904 For example, the EDNS(0) Padding Option [RFC7830] used for security 905 purposes is not permitted in a DSO message, so if message padding is 906 desired for DSO messages then the Encryption Padding TLV described in 907 Section 7.3 MUST be used. 909 Similarly, a DSO message MUST NOT contain a TSIG record. A TSIG 910 record in a conventional DNS message is added as the last record in 911 the additional records section, and carries a signature computed over 912 the preceding message content. Since DSO data appears *after* the 913 additional records section, it would not be included in the signature 914 calculation. If use of signatures with DSO messages becomes 915 necessary in the future, a new DSO TLV needs to be defined to perform 916 this function. 918 Note however that, while DSO *messages* cannot include EDNS(0) or 919 TSIG records, a DSO *session* is typically used to carry a whole 920 series of DNS messages of different kinds, including DSO messages, 921 and other DNS message types like Query [RFC1034] [RFC1035] and Update 922 [RFC2136], and those messages can carry EDNS(0) and TSIG records. 924 Although messages may contain other EDNS(0) options as appropriate, 925 this specification explicitly prohibits use of the EDNS(0) TCP 926 Keepalive Option [RFC7828] in *any* messages sent on a DSO Session 927 (because it is obsoleted by the functionality provided by the DSO 928 Keepalive operation). If any message sent on a DSO Session contains 929 an EDNS(0) TCP Keepalive Option this is a fatal error and the 930 recipient of the defective message MUST forcibly abort the connection 931 immediately. 933 5.3. Message Handling 935 The initiator MUST set the value of the QR bit in the DNS header to 936 zero (0), and the responder MUST set it to one (1). 938 As described above in Section 5.2.1 whether an outgoing message with 939 QR=0 is unacknowledged or acknowledged is determined by the 940 specification for the Primary TLV, which in turn determines whether 941 the MESSAGE ID field in that outgoing message will be zero or 942 nonzero. 944 A DSO unacknowledged message has both the QR bit and the MESSAGE ID 945 field set to zero, and MUST NOT elicit a response. 947 Every DSO request message (QR=0) with a nonzero MESSAGE ID field is 948 an acknowledged DSO request, and MUST elicit a corresponding response 949 (QR=1), which MUST have the same MESSAGE ID in the DNS message header 950 as in the corresponding request. 952 Valid DSO request messages sent by the client with a nonzero MESSAGE 953 ID field elicit a response from the server, and Valid DSO request 954 messages sent by the server with a nonzero MESSAGE ID field elicit a 955 response from the client. 957 The namespaces of 16-bit MESSAGE IDs are independent in each 958 direction. This means it is *not* an error for both client and 959 server to send request messages at the same time as each other, using 960 the same MESSAGE ID, in different directions. This simplification is 961 necessary in order for the protocol to be implementable. It would be 962 infeasible to require the client and server to coordinate with each 963 other regarding allocation of new unique MESSAGE IDs. It is also not 964 necessary to require the client and server to coordinate with each 965 other regarding allocation of new unique MESSAGE IDs. The value of 966 the 16-bit MESSAGE ID combined with the identity of the initiator 967 (client or server) is sufficient to unambiguously identify the 968 operation in question. This can be thought of as a 17-bit message 969 identifier space, using message identifiers 0x00001-0x0FFFF for 970 client-to-server DSO request messages, and message identifiers 971 0x10001-0x1FFFF for server-to-client DSO request messages. The 972 least-significant 16 bits are stored explicitly in the MESSAGE ID 973 field of the DSO message, and the most-significant bit is implicit 974 from the direction of the message. 976 As described above in Section 5.2.1, an initiator MUST NOT reuse a 977 MESSAGE ID that it already has in use for an outstanding request 978 (unless specified otherwise by the relevant specification for the 979 DSO-TYPE in question). At the very least, this means that a MESSAGE 980 ID MUST NOT be reused in a particular direction on a particular DSO 981 Session while the initiator is waiting for a response to a previous 982 request using that MESSAGE ID on that DSO Session (unless specified 983 otherwise by the relevant specification for the DSO-TYPE in 984 question), and for a long-lived operation the MESSAGE ID for the 985 operation MUST NOT be reused while that operation remains active. 987 If a client or server receives a response (QR=1) where the MESSAGE ID 988 is zero, or is any other value that does not match the MESSAGE ID of 989 any of its outstanding operations, this is a fatal error and the 990 recipient MUST forcibly abort the connection immediately. 992 5.3.1. Error Responses 994 When a DSO unacknowledged message is unsuccessful for some reason, 995 the responder immediately aborts the connection. 997 When a DSO request message is unsuccessful for some reason, the 998 responder returns an error code to the initiator. 1000 In the case of a server returning an error code to a client in 1001 response to an unsuccessful DSO request message, the server MAY 1002 choose to end the DSO Session, or MAY choose to allow the DSO Session 1003 to remain open. For error conditions that only affect the single 1004 operation in question, the server SHOULD return an error response to 1005 the client and leave the DSO Session open for further operations. 1007 For error conditions that are likely to make all operations 1008 unsuccessful in the immediate future, the server SHOULD return an 1009 error response to the client and then end the DSO Session by sending 1010 a Retry Delay message, as described in Section 6.6.1. 1012 Upon receiving an error response from the server, a client SHOULD NOT 1013 automatically close the DSO Session. An error relating to one 1014 particular operation on a DSO Session does not necessarily imply that 1015 all other operations on that DSO Session have also failed, or that 1016 future operations will fail. The client should assume that the 1017 server will make its own decision about whether or not to end the DSO 1018 Session, based on the server's determination of whether the error 1019 condition pertains to this particular operation, or would also apply 1020 to any subsequent operations. If the server does not end the DSO 1021 Session by sending the client a Retry Delay message (Section 6.6.1) 1022 then the client SHOULD continue to use that DSO Session for 1023 subsequent operations. 1025 5.4. DSO Response Generation 1027 With most TCP implementations, for DSO requests that generate a 1028 response, the TCP data acknowledgement (generated because data has 1029 been received by TCP), the TCP window update (generated because TCP 1030 has delivered that data to the receiving software), and the DSO 1031 response (generated by the receiving application-layer software 1032 itself) are all combined into a single IP packet. Combining these 1033 three elements into a single IP packet can give a significant 1034 improvement in network efficiency. 1036 For DSO requests that do not generate a response, the TCP 1037 implementation generally doesn't have any way to know that no 1038 response will be forthcoming, so it waits fruitlessly for the 1039 application-layer software to generate a response, until the Delayed 1040 ACK timer fires [RFC1122] (typically 200 milliseconds) and only then 1041 does it send the TCP ACK and window update. In conjunction with 1042 Nagle's Algorithm at the sender, this can delay the sender's 1043 transmission of its next (non-full-sized) TCP segment, while the 1044 sender is waiting for its previous (non-full-sized) TCP segment to be 1045 acknowledged, which won't happen until the Delayed ACK timer fires. 1046 Nagle's Algorithm exists to combine multiple small application writes 1047 into more-efficient large TCP segments, to guard against wasteful use 1048 of the network by applications that would otherwise transmit a stream 1049 of small TCP segments, but in this case Nagle's Algorithm (created to 1050 improve network efficiency) can interact badly with TCP's Delayed ACK 1051 feature (also created to improve network efficiency) [NagleDA] with 1052 the result of delaying some messages by up to 200 milliseconds. 1054 Possible mitigations for this problem include: 1056 o Disable Nagle's Algorithm at the sender. This is not great, 1057 because it results in less efficient use of the network. 1059 o Disable Delayed ACK at the receiver. This is not great, 1060 because it results in less efficient use of the network. 1062 o Adding padding data to fill the segment. This is not great, 1063 because it uses additional bandwidth. 1065 o Use a networking API that lets the receiver signal to the TCP 1066 implementation that the receiver has received and processed a 1067 client request for which it will not be generating any immediate 1068 response. This allows the TCP implementation to operate 1069 efficiently in both cases; for requests that generate a response, 1070 the TCP ACK, window update, and DSO response are transmitted 1071 together in a single TCP segment, and for requests that do not 1072 generate a response, the application-layer software informs the 1073 TCP implementation that it should go ahead and send the TCP ACK 1074 and window update immediately, without waiting for the Delayed ACK 1075 timer. Unfortunately it is not known at this time which (if any) 1076 of the widely-available networking APIs currently include this 1077 capability. 1079 5.5. Responder-Initiated Operation Cancellation 1081 This document, the base specification for DNS Stateful Operations, 1082 does not itself define any long-lived operations, but it defines a 1083 framework for supporting long-lived operations, such as Push 1084 Notification subscriptions [I-D.ietf-dnssd-push] and Discovery Relay 1085 interface subscriptions [I-D.ietf-dnssd-mdns-relay]. 1087 Generally speaking, a long-lived operation is initiated by the 1088 initiator, and, if successful, remains active until the initiator 1089 terminates the operation. 1091 However, it is possible that a long-lived operation may be valid at 1092 the time it was initiated, but then a later change of circumstances 1093 may render that previously valid operation invalid. 1095 For example, a long-lived client operation may pertain to a name that 1096 the server is authoritative for, but then the server configuration is 1097 changed such that it is no longer authoritative for that name. 1099 In such cases, instead of terminating the entire session it may be 1100 desirable for the responder to be able to cancel selectively only 1101 those operations that have become invalid. 1103 The responder performs this selective cancellation by sending a new 1104 response message, with the MESSAGE ID field containing the MESSAGE ID 1105 of the long-lived operation that is to be terminated (that it had 1106 previously acknowledged with a NOERROR RCODE), and the RCODE field of 1107 the new response message giving the reason for cancellation. 1109 After a response message with nonzero RCODE has been sent, that 1110 operation has been terminated from the responder's point of view, and 1111 the responder sends no more messages relating to that operation. 1113 After a response message with nonzero RCODE has been received by the 1114 initiator, that operation has been terminated from the initiator's 1115 point of view, and the cancelled operation's MESSAGE ID is now free 1116 for reuse. 1118 6. DSO Session Lifecycle and Timers 1120 6.1. DSO Session Initiation 1122 A DSO Session begins as described in Section 5.1. 1124 The client may perform as many DNS operations as it wishes using the 1125 newly created DSO Session. Operations SHOULD be pipelined (i.e., the 1126 client doesn't need wait for a response before sending the next 1127 message). The server MUST act on messages in the order they are 1128 transmitted, but responses to those messages SHOULD be sent out of 1129 order when appropriate. 1131 6.2. DSO Session Timeouts 1133 Two timeout values are associated with a DSO Session: the inactivity 1134 timeout, and the keepalive interval. Both values are communicated in 1135 the same TLV, the DSO Keepalive TLV (Section 7.1). 1137 The first timeout value, the inactivity timeout, is the maximum time 1138 for which a client may speculatively keep a DSO Session open in the 1139 expectation that it may have future requests to send to that server. 1141 The second timeout value, the keepalive interval, is the maximum 1142 permitted interval between messages if the client wishes to keep the 1143 DSO Session alive. 1145 The two timeout values are independent. The inactivity timeout may 1146 be lower, the same, or higher than the keepalive interval, though in 1147 most cases the inactivity timeout is expected to be shorter than the 1148 keepalive interval. 1150 A shorter inactivity timeout with a longer keepalive interval signals 1151 to the client that it should not speculatively keep an inactive DSO 1152 Session open for very long without reason, but when it does have an 1153 active reason to keep a DSO Session open, it doesn't need to be 1154 sending an aggressive level of keepalive traffic to maintain that 1155 session. 1157 A longer inactivity timeout with a shorter keepalive interval signals 1158 to the client that it may speculatively keep an inactive DSO Session 1159 open for a long time, but to maintain that inactive DSO Session it 1160 should be sending a lot of keepalive traffic. This configuration is 1161 expected to be less common. 1163 In the usual case where the inactivity timeout is shorter than the 1164 keepalive interval, it is only when a client has a very long-lived, 1165 low-traffic, operation that the keepalive interval comes into play, 1166 to ensure that a sufficient residual amount of traffic is generated 1167 to maintain NAT and firewall state and to assure client and server 1168 that they still have connectivity to each other. 1170 On a new DSO Session, if no explicit DSO Keepalive message exchange 1171 has taken place, the default value for both timeouts is 15 seconds. 1173 For both timeouts, lower values of the timeout result in higher 1174 network traffic and higher CPU load on the server. 1176 6.3. Inactive DSO Sessions 1178 At both servers and clients, the generation or reception of any 1179 complete DNS message, including DNS requests, responses, updates, or 1180 DSO messages, resets both timers for that DSO Session, with the 1181 exception that a DSO Keepalive message resets only the keepalive 1182 timer, not the inactivity timeout timer. 1184 In addition, for as long as the client has an outstanding operation 1185 in progress, the inactivity timer remains cleared, and an inactivity 1186 timeout cannot occur. 1188 For short-lived DNS operations like traditional queries and updates, 1189 an operation is considered in progress for the time between request 1190 and response, typically a period of a few hundred milliseconds at 1191 most. At the client, the inactivity timer is cleared upon 1192 transmission of a request and remains cleared until reception of the 1193 corresponding response. At the server, the inactivity timer is 1194 cleared upon reception of a request and remains cleared until 1195 transmission of the corresponding response. 1197 For long-lived DNS Stateful operations (such as a Push Notification 1198 subscription [I-D.ietf-dnssd-push] or a Discovery Relay interface 1199 subscription [I-D.ietf-dnssd-mdns-relay]), an operation is considered 1200 in progress for as long as the operation is active, until it is 1201 cancelled. This means that a DSO Session can exist, with active 1202 operations, with no messages flowing in either direction, for far 1203 longer than the inactivity timeout, and this is not an error. This 1204 is why there are two separate timers: the inactivity timeout, and the 1205 keepalive interval. Just because a DSO Session has no traffic for an 1206 extended period of time does not automatically make that DSO Session 1207 "inactive", if it has an active operation that is awaiting events. 1209 6.4. The Inactivity Timeout 1211 The purpose of the inactivity timeout is for the server to balance 1212 its trade off between the costs of setting up new DSO Sessions and 1213 the costs of maintaining inactive DSO Sessions. A server with 1214 abundant DSO Session capacity can offer a high inactivity timeout, to 1215 permit clients to keep a speculative DSO Session open for a long 1216 time, to save the cost of establishing a new DSO Session for future 1217 communications with that server. A server with scarce memory 1218 resources can offer a low inactivity timeout, to cause clients to 1219 promptly close DSO Sessions whenever they have no outstanding 1220 operations with that server, and then create a new DSO Session later 1221 when needed. 1223 6.4.1. Closing Inactive DSO Sessions 1225 When a connection's inactivity timeout is reached the client MUST 1226 begin closing the idle connection, but a client is not required to 1227 keep an idle connection open until the inactivity timeout is reached. 1228 A client MAY close a DSO Session at any time, at the client's 1229 discretion. If a client determines that it has no current or 1230 reasonably anticipated future need for a currently inactive DSO 1231 Session, then the client SHOULD gracefully close that connection. 1233 If, at any time during the life of the DSO Session, the inactivity 1234 timeout value (i.e., 15 seconds by default) elapses without there 1235 being any operation active on the DSO Session, the client MUST close 1236 the connection gracefully. 1238 If, at any time during the life of the DSO Session, twice the 1239 inactivity timeout value (i.e., 30 seconds by default), or five 1240 seconds, if twice the inactivity timeout value is less than five 1241 seconds, elapses without there being any operation active on the DSO 1242 Session, the server SHOULD consider the client delinquent, and SHOULD 1243 forcibly abort the DSO Session. 1245 In this context, an operation being active on a DSO Session includes 1246 a query waiting for a response, an update waiting for a response, or 1247 an active long-lived operation, but not a DSO Keepalive message 1248 exchange itself. A DSO Keepalive message exchange resets only the 1249 keepalive interval timer, not the inactivity timeout timer. 1251 If the client wishes to keep an inactive DSO Session open for longer 1252 than the default duration then it uses the DSO Keepalive message to 1253 request longer timeout values, as described in Section 7.1. 1255 6.4.2. Values for the Inactivity Timeout 1257 For the inactivity timeout value, lower values result in more 1258 frequent DSO Session teardown and re-establishment. Higher values 1259 result in lower traffic and lower CPU load on the server, but higher 1260 memory burden to maintain state for inactive DSO Sessions. 1262 A server may dictate any value it chooses for the inactivity timeout 1263 (either in a response to a client-initiated request, or in a server- 1264 initiated message) including values under one second, or even zero. 1266 An inactivity timeout of zero informs the client that it should not 1267 speculatively maintain idle connections at all, and as soon as the 1268 client has completed the operation or operations relating to this 1269 server, the client should immediately begin closing this session. 1271 A server will abort an idle client session after twice the inactivity 1272 timeout value, or five seconds, whichever is greater. In the case of 1273 a zero inactivity timeout value, this means that if a client fails to 1274 close an idle client session then the server will forcibly abort the 1275 idle session after five seconds. 1277 An inactivity timeout of 0xFFFFFFFF represents "infinity" and informs 1278 the client that it may keep an idle connection open as long as it 1279 wishes. Note that after granting an unlimited inactivity timeout in 1280 this way, at any point the server may revise that inactivity timeout 1281 by sending a new Keepalive message dictating new Session Timeout 1282 values to the client. 1284 The largest *finite* inactivity timeout supported by the current DSO 1285 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 1286 days). 1288 6.5. The Keepalive Interval 1290 The purpose of the keepalive interval is to manage the generation of 1291 sufficient messages to maintain state in middleboxes (such at NAT 1292 gateways or firewalls) and for the client and server to periodically 1293 verify that they still have connectivity to each other. This allows 1294 them to clean up state when connectivity is lost, and to establish a 1295 new session if appropriate. 1297 6.5.1. Keepalive Interval Expiry 1299 If, at any time during the life of the DSO Session, the keepalive 1300 interval value (i.e., 15 seconds by default) elapses without any DNS 1301 messages being sent or received on a DSO Session, the client MUST 1302 take action to keep the DSO Session alive, by sending a DSO Keepalive 1303 message (Section 7.1). A DSO Keepalive message exchange resets only 1304 the keepalive timer, not the inactivity timer. 1306 If a client disconnects from the network abruptly, without cleanly 1307 closing its DSO Session, perhaps leaving a long-lived operation 1308 uncancelled, the server learns of this after failing to receive the 1309 required keepalive traffic from that client. If, at any time during 1310 the life of the DSO Session, twice the keepalive interval value 1311 (i.e., 30 seconds by default) elapses without any DNS messages being 1312 sent or received on a DSO Session, the server SHOULD consider the 1313 client delinquent, and SHOULD forcibly abort the DSO Session. 1315 6.5.2. Values for the Keepalive Interval 1317 For the keepalive interval value, lower values result in a higher 1318 volume of keepalive traffic. Higher values of the keepalive interval 1319 reduce traffic and CPU load, but have minimal effect on the memory 1320 burden at the server, because clients keep a DSO Session open for the 1321 same length of time (determined by the inactivity timeout) regardless 1322 of the level of keepalive traffic required. 1324 It may be appropriate for clients and servers to select different 1325 keepalive interval values depending on the nature of the network they 1326 are on. 1328 A corporate DNS server that knows it is serving only clients on the 1329 internal network, with no intervening NAT gateways or firewalls, can 1330 impose a higher keepalive interval, because frequent keepalive 1331 traffic is not required. 1333 A public DNS server that is serving primarily residential consumer 1334 clients, where it is likely there will be a NAT gateway on the path, 1335 may impose a lower keepalive interval, to generate more frequent 1336 keepalive traffic. 1338 A smart client may be adaptive to its environment. A client using a 1339 private IPv4 address [RFC1918] to communicate with a DNS server at an 1340 address outside that IPv4 private address block, may conclude that 1341 there is likely to be a NAT gateway on the path, and accordingly 1342 request a lower keepalive interval. 1344 By default it is RECOMMENDED that clients request, and servers grant, 1345 a keepalive interval of 60 minutes. This keepalive interval provides 1346 for reasonably timely detection if a client abruptly disconnects 1347 without cleanly closing the session, and is sufficient to maintain 1348 state in firewalls and NAT gateways that follow the IETF recommended 1349 Best Current Practice that the "established connection idle-timeout" 1350 used by middleboxes be at least 2 hours 4 minutes [RFC5382]. 1352 Note that the lower the keepalive interval value, the higher the load 1353 on client and server. For example, a hypothetical keepalive interval 1354 value of 100ms would result in a continuous stream of at least ten 1355 messages per second, in both directions, to keep the DSO Session 1356 alive. And, in this extreme example, a single packet loss and 1357 retransmission over a long path could introduce a momentary pause in 1358 the stream of messages, long enough to cause the server to 1359 overzealously abort the connection. 1361 Because of this concern, the server MUST NOT send a Keepalive message 1362 (either a response to a client-initiated request, or a server- 1363 initiated message) with a keepalive interval value less than ten 1364 seconds. If a client receives a Keepalive message specifying a 1365 keepalive interval value less than ten seconds this is a fatal error 1366 and the client MUST forcibly abort the connection immediately. 1368 A keepalive interval value of 0xFFFFFFFF represents "infinity" and 1369 informs the client that it should generate no keepalive traffic. 1370 Note that after signaling that the client should generate no 1371 keepalive traffic in this way, at any point the server may revise 1372 that keepalive traffic requirement by sending a new Keepalive message 1373 dictating new Session Timeout values to the client. 1375 The largest *finite* keepalive interval supported by the current DSO 1376 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 1377 days). 1379 6.6. Server-Initiated Session Termination 1381 In addition to cancelling individual long-lived operations 1382 selectively (Section 5.5) there are also occasions where a server may 1383 need to terminate one or more entire sessions. An entire session may 1384 need to be terminated if the client is defective in some way, or 1385 departs from the network without closing its session. Sessions may 1386 also need to be terminated if the server becomes overloaded, or if 1387 the server is reconfigured and lacks the ability to be selective 1388 about which operations need to be cancelled. 1390 This section discusses various reasons a session may be terminated, 1391 and the mechanisms for doing so. 1393 Normally a server MUST NOT close a DSO Session with a client. A 1394 server only causes a DSO Session to be ended in the exceptional 1395 circumstances outlined below. In normal operation, closing a DSO 1396 Session is the client's responsibility. The client makes the 1397 determination of when to close a DSO Session based on an evaluation 1398 of both its own needs, and the inactivity timeout value dictated by 1399 the server. 1401 Some of the exceptional situations in which a server may terminate a 1402 DSO Session include: 1404 o The server application software or underlying operating system is 1405 shutting down or restarting. 1407 o The server application software terminates unexpectedly (perhaps 1408 due to a bug that makes it crash). 1410 o The server is undergoing a reconfiguration or maintenance 1411 procedure, that, due to the way the server software is 1412 implemented, requires clients to be disconnected. For example, 1413 some software is implemented such that it reads a configuration 1414 file at startup, and changing the server's configuration entails 1415 modifying the configuration file and then killing and restarting 1416 the server software, which generally entails a loss of network 1417 connections. 1419 o The client fails to meets its obligation to generate the required 1420 keepalive traffic, or to close an inactive session by the 1421 prescribed time (twice the time interval dictated by the server, 1422 or five seconds, whichever is greater, as described in 1423 Section 6.2). 1425 o The client sends a grossly invalid or malformed request that is 1426 indicative of a seriously defective client implementation. 1428 o The server is over capacity and needs to shed some load. 1430 6.6.1. Server-Initiated Retry Delay Message 1432 In the cases described above where a server elects to terminate a DSO 1433 Session, it could do so simply by forcibly aborting the connection. 1434 However, if it did this the likely behavior of the client might be 1435 simply to to treat this as a network failure and reconnect 1436 immediately, putting more burden on the server. 1438 Therefore, to avoid this reconnection implosion, a server SHOULD 1439 instead choose to shed client load by sending a Retry Delay message, 1440 with an appropriate RCODE value informing the client of the reason 1441 the DSO Session needs to be terminated. The format of the Retry 1442 Delay TLV, and the interpretations of the various RCODE values, are 1443 described in Section 7.2. After sending a Retry Delay message, the 1444 server MUST NOT send any further messages on that DSO Session. 1446 Upon receipt of a Retry Delay message from the server, the client 1447 MUST make note of the reconnect delay for this server, and then 1448 immediately close the connection gracefully. 1450 After sending a Retry Delay message the server SHOULD allow the 1451 client five seconds to close the connection, and if the client has 1452 not closed the connection after five seconds then the server SHOULD 1453 forcibly abort the connection. 1455 A Retry Delay message MUST NOT be initiated by a client. If a server 1456 receives a Retry Delay message this is a fatal error and the server 1457 MUST forcibly abort the connection immediately. 1459 6.6.1.1. Outstanding Operations 1461 At the instant a server chooses to initiate a Retry Delay message 1462 there may be DNS requests already in flight from client to server on 1463 this DSO Session, which will arrive at the server after its Retry 1464 Delay message has been sent. The server MUST silently ignore such 1465 incoming requests, and MUST NOT generate any response messages for 1466 them. When the Retry Delay message from the server arrives at the 1467 client, the client will determine that any DNS requests it previously 1468 sent on this DSO Session, that have not yet received a response, now 1469 will certainly not be receiving any response. Such requests should 1470 be considered failed, and should be retried at a later time, as 1471 appropriate. 1473 In the case where some, but not all, of the existing operations on a 1474 DSO Session have become invalid (perhaps because the server has been 1475 reconfigured and is no longer authoritative for some of the names), 1476 but the server is terminating all affected DSO Sessions en masse by 1477 sending them all a Retry Delay message, the RECONNECT DELAY MAY be 1478 zero, indicating that the clients SHOULD immediately attempt to re- 1479 establish operations. 1481 It is likely that some of the attempts will be successful and some 1482 will not, depending on the nature of the reconfiguration. 1484 In the case where a server is terminating a large number of DSO 1485 Sessions at once (e.g., if the system is restarting) and the server 1486 doesn't want to be inundated with a flood of simultaneous retries, it 1487 SHOULD send different RECONNECT delay values to each client. These 1488 adjustments MAY be selected randomly, pseudorandomly, or 1489 deterministically (e.g., incrementing the time value by one tenth of 1490 a second for each successive client, yielding a post-restart 1491 reconnection rate of ten clients per second). 1493 6.6.1.2. Client Reconnection 1495 After a DSO Session is ended by the server (either by sending the 1496 client a Retry Delay message, or by forcibly aborting the underlying 1497 transport connection) the client SHOULD try to reconnect, to that 1498 service instance, or to another suitable service instance, if more 1499 than one is available. If reconnecting to the same service instance, 1500 the client MUST respect the indicated delay, if available, before 1501 attempting to reconnect. 1503 If the service instance will only be out of service for a short 1504 maintenance period, it should use a value a little longer that the 1505 expected maintenance window. It should not default to a very large 1506 delay value, or clients may not attempt to reconnect after it resumes 1507 service. 1509 If a particular service instance does not want a client to reconnect 1510 ever (perhaps the service instance is being de-commissioned), it 1511 SHOULD set the retry delay to the maximum value 0xFFFFFFFF (2^32-1 1512 milliseconds, approximately 49.7 days). It is not possible to 1513 instruct a client to stay away for longer than 49.7 days. If, after 1514 49.7 days, the DNS or other configuration information still indicates 1515 that this is the valid service instance for a particular service, 1516 then clients MAY attempt to reconnect. In reality, if a client is 1517 rebooted or otherwise lose state, it may well attempt to reconnect 1518 before 49.7 days elapses, for as long as the DNS or other 1519 configuration information continues to indicate that this is the 1520 service instance the client should use. 1522 7. Base TLVs for DNS Stateful Operations 1524 This section describes the three base TLVs for DNS Stateful 1525 Operations: Keepalive, Retry Delay, and Encryption Padding. 1527 7.1. Keepalive TLV 1529 The Keepalive TLV (DSO-TYPE=1) performs two functions: to reset the 1530 keepalive timer for the DSO Session, and to establish the values for 1531 the Session Timeouts. 1533 The DSO-DATA for the the Keepalive TLV is as follows: 1535 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1536 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 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | INACTIVITY TIMEOUT (32 bits) | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | KEEPALIVE INTERVAL (32 bits) | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 INACTIVITY TIMEOUT: The inactivity timeout for the current DSO 1544 Session, specified as a 32-bit unsigned integer, in network (big 1545 endian) byte order, in units of milliseconds. This is the timeout 1546 at which the client MUST begin closing an inactive DSO Session. 1547 The inactivity timeout can be any value of the server's choosing. 1548 If the client does not gracefully close an inactive DSO Session, 1549 then after twice this interval, or five seconds, whichever is 1550 greater, the server will forcibly abort the connection. 1552 KEEPALIVE INTERVAL: The keepalive interval for the current DSO 1553 Session, specified as a 32-bit unsigned integer, in network (big 1554 endian) byte order, in units of milliseconds. This is the 1555 interval at which a client MUST generate keepalive traffic to 1556 maintain connection state. The keepalive interval MUST NOT be 1557 less than ten seconds. If the client does not generate the 1558 mandated keepalive traffic, then after twice this interval the 1559 server will forcibly abort the connection. Since the minimum 1560 allowed keepalive interval is ten seconds, the minimum time at 1561 which a server will forcibly disconnect a client for failing to 1562 generate the mandated keepalive traffic is twenty seconds. 1564 The transmission or reception of DSO Keepalive messages (i.e., 1565 messages where the Keepalive TLV is the first TLV) reset only the 1566 keepalive timer, not the inactivity timer. The reason for this is 1567 that periodic Keepalive messages are sent for the sole purpose of 1568 keeping a DSO Session alive, when that DSO Session has current or 1569 recent non-maintenance activity that warrants keeping that DSO 1570 Session alive. Sending keepalive traffic itself is not considered a 1571 client activity; it is considered a maintenance activity that is 1572 performed in service of other client activities. If keepalive 1573 traffic itself were to reset the inactivity timer, then that would 1574 create a circular livelock where keepalive traffic would be sent 1575 indefinitely to keep a DSO Session alive, where the only activity on 1576 that DSO Session would be the keepalive traffic keeping the DSO 1577 Session alive so that further keepalive traffic can be sent. For a 1578 DSO Session to be considered active, it must be carrying something 1579 more than just keepalive traffic. This is why merely sending or 1580 receiving a Keepalive message does not reset the inactivity timer. 1582 When sent by a client, the Keepalive request message MUST be sent as 1583 an acknowledged request, with a nonzero MESSAGE ID. If a server 1584 receives a Keepalive DSO message with a zero MESSAGE ID then this is 1585 a fatal error and the server MUST forcibly abort the connection 1586 immediately. The Keepalive request message resets a DSO Session's 1587 keepalive timer, and at the same time communicates to the server the 1588 the client's requested Session Timeout values. In a server response 1589 to a client-initiated Keepalive request message, the Session Timeouts 1590 contain the server's chosen values from this point forward in the DSO 1591 Session, which the client MUST respect. This is modeled after the 1592 DHCP protocol, where the client requests a certain lease lifetime 1593 using DHCP option 51 [RFC2132], but the server is the ultimate 1594 authority for deciding what lease lifetime is actually granted. 1596 When a client is sending its second and subsequent Keepalive DSO 1597 requests to the server, the client SHOULD continue to request its 1598 preferred values each time. This allows flexibility, so that if 1599 conditions change during the lifetime of a DSO Session, the server 1600 can adapt its responses to better fit the client's needs. 1602 Once a DSO Session is in progress (Section 5.1) a Keepalive message 1603 MAY be initiated by a server. When sent by a server, the Keepalive 1604 message MUST be sent as an unacknowledged message, with the MESSAGE 1605 ID set to zero. The client MUST NOT generate a response to a server- 1606 initiated DSO Keepalive message. If a client receives a Keepalive 1607 request message with a nonzero MESSAGE ID then this is a fatal error 1608 and the client MUST forcibly abort the connection immediately. The 1609 Keepalive unacknowledged message from the server resets a DSO 1610 Session's keepalive timer, and at the same time unilaterally informs 1611 the client of the new Session Timeout values to use from this point 1612 forward in this DSO Session. No client DSO response message to this 1613 unilateral declaration is required or allowed. 1615 The Keepalive TLV is not used as an Additional TLV. 1617 In Keepalive response messages, the Keepalive TLV is REQUIRED and is 1618 used only as a Response Primary TLV sent as a reply to a Keepalive 1619 request message from the client. A Keepalive TLV MUST NOT be added 1620 as to other responses a Response Additional TLV. If the server 1621 wishes to update a client's Session Timeout values other than in 1622 response to a Keepalive request message from the client, then it does 1623 so by sending an unacknowledged Keepalive message of its own, as 1624 described above. 1626 It is not required that the Keepalive TLV be used in every DSO 1627 Session. While many DNS Stateful operations will be used in 1628 conjunction with a long-lived session state, not all DNS Stateful 1629 operations require long-lived session state, and in some cases the 1630 default 15-second value for both the inactivity timeout and keepalive 1631 interval may be perfectly appropriate. However, note that for 1632 clients that implement only the DSO-TYPEs defined in this document, a 1633 Keepalive request message is the only way for a client to initiate a 1634 DSO Session. 1636 7.1.1. Client handling of received Session Timeout values 1638 When a client receives a response to its client-initiated DSO 1639 Keepalive message, or receives a server-initiated DSO Keepalive 1640 message, the client has then received Session Timeout values dictated 1641 by the server. The two timeout values contained in the DSO Keepalive 1642 TLV from the server may each be higher, lower, or the same as the 1643 respective Session Timeout values the client previously had for this 1644 DSO Session. 1646 In the case of the keepalive timer, the handling of the received 1647 value is straightforward. The act of receiving the message 1648 containing the DSO Keepalive TLV itself resets the keepalive timer 1649 and updates the keepalive interval for the DSO Session. The new 1650 keepalive interval indicates the maximum time that may elapse before 1651 another message must be sent or received on this DSO Session, if the 1652 DSO Session is to remain alive. 1654 In the case of the inactivity timeout, the handling of the received 1655 value is a little more subtle, though the meaning of the inactivity 1656 timeout remains as specified -- it still indicates the maximum 1657 permissible time allowed without useful activity on a DSO Session. 1658 The act of receiving the message containing the DSO Keepalive TLV 1659 does not itself reset the inactivity timer. The time elapsed since 1660 the last useful activity on this DSO Session is unaffected by 1661 exchange of DSO Keepalive messages. The new inactivity timeout value 1662 in the DSO Keepalive TLV in the received message does update the 1663 timeout associated with the running inactivity timer; that becomes 1664 the new maximum permissible time without activity on a DSO Session. 1666 o If the current inactivity timer value is less than the new 1667 inactivity timeout, then the DSO Session may remain open for now. 1668 When the inactivity timer value reaches the new inactivity 1669 timeout, the client MUST then begin closing the DSO Session, as 1670 described above. 1672 o If the current inactivity timer value is equal to the new 1673 inactivity timeout, then this DSO Session has been inactive for 1674 exactly as long as the server will permit, and now the client MUST 1675 immediately begin closing this DSO Session. 1677 o If the current inactivity timer value is already greater than the 1678 new inactivity timeout, then this DSO Session has already been 1679 inactive for longer than the server permits, and the client MUST 1680 immediately begin closing this DSO Session. 1682 o If the current inactivity timer value is already more than twice 1683 the new inactivity timeout, then the client is immediately 1684 considered delinquent (this DSO Session is immediately eligible to 1685 be forcibly terminated by the server) and the client MUST 1686 immediately begin closing this DSO Session. However if a server 1687 abruptly reduces the inactivity timeout in this way, then, to give 1688 the client time to close the connection gracefully before the 1689 server resorts to forcibly aborting it, the server SHOULD give the 1690 client an additional grace period of one quarter of the new 1691 inactivity timeout, or five seconds, whichever is greater. 1693 7.1.2. Relation to EDNS(0) TCP Keepalive Option 1695 The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has 1696 similar intent to the EDNS(0) TCP Keepalive Option [RFC7828]. A 1697 client/server pair that supports DSO MUST NOT use the EDNS(0) TCP 1698 KeepAlive option within any message after a DSO Session has been 1699 established. Once a DSO Session has been established, if either 1700 client or server receives a DNS message over the DSO Session that 1701 contains an EDNS(0) TCP Keepalive option, this is a fatal error and 1702 the receiver of the EDNS(0) TCP Keepalive option MUST forcibly abort 1703 the connection immediately. 1705 7.2. Retry Delay TLV 1707 The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary TLV 1708 (unacknowledged) in a server-to-client message, or as a Response 1709 Additional TLV in either direction. 1711 The DSO-DATA for the the Retry Delay TLV is as follows: 1713 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1714 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 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | RETRY DELAY (32 bits) | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 RETRY DELAY: A time value, specified as a 32-bit unsigned integer, 1720 in network (big endian) byte order, in units of milliseconds, 1721 within which the initiator MUST NOT retry this operation, or retry 1722 connecting to this server. Recommendations for the RETRY DELAY 1723 value are given in Section 6.6.1. 1725 7.2.1. Retry Delay TLV used as a Primary TLV 1727 When sent from server to client, the Retry Delay TLV is used as the 1728 Primary TLV in an unacknowledged message. It is used by a server to 1729 instruct a client to close the DSO Session and underlying connection, 1730 and not to reconnect for the indicated time interval. 1732 In this case it applies to the DSO Session as a whole, and the client 1733 MUST begin closing the DSO Session, as described in Section 6.6.1. 1734 The RCODE in the message header SHOULD indicate the principal reason 1735 for the termination: 1737 o NOERROR indicates a routine shutdown or restart. 1739 o FORMERR indicates that the client requests are too badly malformed 1740 for the session to continue. 1742 o SERVFAIL indicates that the server is overloaded due to resource 1743 exhaustion and needs to shed load. 1745 o REFUSED indicates that the server has been reconfigured, and at 1746 this time it is now unable to perform one or more of the long- 1747 lived client operations that were previously being performed on 1748 this DSO Session. 1750 o NOTAUTH indicates that the server has been reconfigured and at 1751 this time it is now unable to perform one or more of the long- 1752 lived client operations that were previously being performed on 1753 this DSO Session because it does not have authority over the names 1754 in question (for example, a DNS Push Notification server could be 1755 reconfigured such that is is no longer accepting DNS Push 1756 Notification requests for one or more of the currently subscribed 1757 names). 1759 This document specifies only these RCODE values for Retry Delay 1760 message. Servers sending Retry Delay messages SHOULD use one of 1761 these values. However, future circumstances may create situations 1762 where other RCODE values are appropriate in Retry Delay messages, so 1763 clients MUST be prepared to accept Retry Delay messages with any 1764 RCODE value. 1766 In some cases, when a server sends a Retry Delay message to a client, 1767 there may be more than one reason for the server wanting to end the 1768 session. Possibly the configuration could have been changed such 1769 that some long-lived client operations can no longer be continued due 1770 to policy (REFUSED), and other long-lived client operations can no 1771 longer be performed due to the server no longer being authoritative 1772 for those names (NOTAUTH). In such cases the server MAY use any of 1773 the applicable RCODE values, or RCODE=NOERROR (routine shutdown or 1774 restart). 1776 Note that the selection of RCODE value in a Retry Delay message is 1777 not critical, since the RCODE value is generally used only for 1778 information purposes, such as writing to a log file for future human 1779 analysis regarding the nature of the disconnection. Generally 1780 clients do not modify their behavior depending on the RCODE value. 1781 The RETRY DELAY in the message tells the client how long it should 1782 wait before attempting a new connection to this service instance. 1784 For clients that do in some way modify their behavior depending on 1785 the RCODE value, they should treat unknown RCODE values the same as 1786 RCODE=NOERROR (routine shutdown or restart). 1788 A Retry Delay message from server to client is an unacknowledged 1789 message; the MESSAGE ID MUST be set to zero in the outgoing message 1790 and the client MUST NOT send a response. 1792 A client MUST NOT send a Retry Delay DSO request message or DSO 1793 unacknowledged message to a server. If a server receives a DNS 1794 request message (i.e., QR=0) where the Primary TLV is the Retry Delay 1795 TLV, this is a fatal error and the server MUST forcibly abort the 1796 connection immediately. 1798 7.2.2. Retry Delay TLV used as a Response Additional TLV 1800 In the case of a request that returns a nonzero RCODE value, the 1801 responder MAY append a Retry Delay TLV to the response, indicating 1802 the time interval during which the initiator SHOULD NOT attempt this 1803 operation again. 1805 The indicated time interval during which the initiator SHOULD NOT 1806 retry applies only to the failed operation, not to the DSO Session as 1807 a whole. 1809 7.3. Encryption Padding TLV 1811 The Encryption Padding TLV (DSO-TYPE=3) can only be used as an 1812 Additional or Response Additional TLV. It is only applicable when 1813 the DSO Transport layer uses encryption such as TLS. 1815 The DSO-DATA for the the Padding TLV is optional and is a variable 1816 length field containing non-specified values. A DSO-LENGTH of 0 1817 essentially provides for 4 bytes of padding (the minimum amount). 1819 1 1 1 1 1 1 1820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1821 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1822 / / 1823 / VARIABLE NUMBER OF BYTES / 1824 / / 1825 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1827 As specified for the EDNS(0) Padding Option [RFC7830] the PADDING 1828 bytes SHOULD be set to 0x00. Other values MAY be used, for example, 1829 in cases where there is a concern that the padded message could be 1830 subject to compression before encryption. PADDING bytes of any value 1831 MUST be accepted in the messages received. 1833 The Encryption Padding TLV may be included in either a DSO request, 1834 response, or both. As specified for the EDNS(0) Padding Option 1835 [RFC7830] if a request is received with an Encryption Padding TLV, 1836 then the response MUST also include an Encryption Padding TLV. 1838 The length of padding is intentionally not specified in this document 1839 and is a function of current best practices with respect to the type 1840 and length of data in the preceding TLVs 1841 [I-D.ietf-dprive-padding-policy]. 1843 8. Summary Highlights 1845 This section summarizes some noteworthy highlights about various 1846 components of the DSO protocol. 1848 8.1. QR bit and MESSAGE ID 1850 In DSO Request Messages the QR bit is 0 and the MESSAGE ID is 1851 nonzero. 1853 In DSO Response Messages the QR bit is 1 and the MESSAGE ID is 1854 nonzero. 1856 In DSO Unacknowledged Messages the QR bit is 0 and the MESSAGE ID is 1857 zero. 1859 The table below illustrates which combinations are legal and how they 1860 are interpreted: 1862 +--------------------------+------------------------+ 1863 | MESSAGE ID zero | MESSAGE ID nonzero | 1864 +--------+--------------------------+------------------------+ 1865 | QR=0 | Unacknowledged Message | Request Message | 1866 +--------+--------------------------+------------------------+ 1867 | QR=1 | Invalid - Fatal Error | Response Message | 1868 +--------+--------------------------+------------------------+ 1870 8.2. TLV Usage 1872 The table below indicates, for each of the three TLVs defined in this 1873 document, whether they are valid in each of ten different contexts. 1875 The first five contexts are requests or unacknowledged messages from 1876 client to server, and the corresponding responses from server back to 1877 client: 1879 o C-P - Primary TLV, sent in DSO Request message, from client to 1880 server, with nonzero MESSAGE ID indicating that this request MUST 1881 generate response message. 1883 o C-U - Primary TLV, sent in DSO Unacknowledged message, from client 1884 to server, with zero MESSAGE ID indicating that this request MUST 1885 NOT generate response message. 1887 o C-A - Additional TLV, optionally added to request message or 1888 unacknowledged message from client to server. 1890 o CRP - Response Primary TLV, included in response message sent back 1891 to the client (in response to a client "C-P" request with nonzero 1892 MESSAGE ID indicating that a response is required) where the DSO- 1893 TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV 1894 in the request. 1896 o CRA - Response Additional TLV, included in response message sent 1897 back to the client (in response to a client "C-P" request with 1898 nonzero MESSAGE ID indicating that a response is required) where 1899 the DSO-TYPE of the Response TLV does not match the DSO-TYPE of 1900 the Primary TLV in the request. 1902 The second five contexts are their counterparts in the opposite 1903 direction: requests or unacknowledged messages from server to client, 1904 and the corresponding responses from client back to server. 1906 +-------------------------+-------------------------+ 1907 | C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA | 1908 +------------+-------------------------+-------------------------+ 1909 | KeepAlive | X X | X | 1910 +------------+-------------------------+-------------------------+ 1911 | RetryDelay | X | X | 1912 +------------+-------------------------+-------------------------+ 1913 | Padding | X X | X X | 1914 +------------+-------------------------+-------------------------+ 1916 Note that some of the columns in this table are currently empty. The 1917 table provides a template for future TLV definitions to follow. It 1918 is recommended that definitions of future TLVs include a similar 1919 table summarizing the contexts where the new TLV is valid. 1921 9. IANA Considerations 1923 9.1. DSO OPCODE Registration 1925 The IANA is requested to record the value ([TBA1] tentatively) 6 for 1926 the DSO OPCODE in the DNS OPCODE Registry. DSO stands for DNS 1927 Stateful Operations. 1929 9.2. DSO RCODE Registration 1931 The IANA is requested to record the value ([TBA2] tentatively) 11 for 1932 the DSOTYPENI error code in the DNS RCODE Registry. The DSOTYPENI 1933 error code ("DSO-TYPE Not Implemented") indicates that the receiver 1934 does implement DNS Stateful Operations, but does not implement the 1935 specific DSO-TYPE of the primary TLV in the DSO request message. 1937 9.3. DSO Type Code Registry 1939 The IANA is requested to create the 16-bit DSO Type Code Registry, 1940 with initial (hexadecimal) values as shown below: 1942 +-----------+--------------------------------+----------+-----------+ 1943 | Type | Name | Status | Reference | 1944 +-----------+--------------------------------+----------+-----------+ 1945 | 0000 | Reserved | Standard | RFC-TBD | 1946 | | | | | 1947 | 0001 | KeepAlive | Standard | RFC-TBD | 1948 | | | | | 1949 | 0002 | RetryDelay | Standard | RFC-TBD | 1950 | | | | | 1951 | 0003 | EncryptionPadding | Standard | RFC-TBD | 1952 | | | | | 1953 | 0004-003F | Unassigned, reserved for | | | 1954 | | DSO session-management TLVs | | | 1955 | | | | | 1956 | 0040-F7FF | Unassigned | | | 1957 | | | | | 1958 | F800-FBFF | Reserved for | | | 1959 | | experimental/local use | | | 1960 | | | | | 1961 | FC00-FFFF | Reserved for future expansion | | | 1962 +-----------+--------------------------------+----------+-----------+ 1964 DSO Type Code zero is reserved and is not currently intended for 1965 allocation. 1967 Registrations of new DSO Type Codes in the "Reserved for DSO session- 1968 management" range 0004-003F and the "Reserved for future expansion" 1969 range FC00-FFFF require publication of an IETF Standards Action 1970 document [RFC8126]. 1972 Requests to register additional new DSO Type Codes in the 1973 "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert 1974 Review [RFC8126]. At the time of publication of this document, the 1975 Designated Expert for the newly created DSO Type Code registry is 1976 [*TBD*]. 1978 DSO Type Codes in the "experimental/local" range F800-FBFF may be 1979 used as Experimental Use or Private Use values [RFC8126] and may be 1980 used freely for development purposes, or for other purposes within a 1981 single site. No attempt is made to prevent multiple sites from using 1982 the same value in different (and incompatible) ways. There is no 1983 need for IANA to review such assignments (since IANA does not record 1984 them) and assignments are not generally useful for broad 1985 interoperability. It is the responsibility of the sites making use 1986 of "experimental/local" values to ensure that no conflicts occur 1987 within the intended scope of use. 1989 10. Security Considerations 1991 If this mechanism is to be used with DNS over TLS, then these 1992 messages are subject to the same constraints as any other DNS-over- 1993 TLS messages and MUST NOT be sent in the clear before the TLS session 1994 is established. 1996 The data field of the "Encryption Padding" TLV could be used as a 1997 covert channel. 1999 When designing new DSO TLVs, the potential for data in the TLV to be 2000 used as a tracking identifier should be taken into consideration, and 2001 should be avoided when not required. 2003 When used without TLS or similar cryptographic protection, a 2004 malicious entity maybe able to inject a malicious Retry Delay 2005 Unacknowledged Message into the data stream, specifying an 2006 unreasonably large RETRY DELAY, causing a denial-of-service attack 2007 against the client. 2009 11. Acknowledgements 2011 Thanks to Stephane Bortzmeyer, Tim Chown, Ralph Droms, Paul Hoffman, 2012 Jan Komissar, Edward Lewis, Allison Mankin, Rui Paulo, David 2013 Schinazi, Manju Shankar Rao, and Bernie Volz for their helpful 2014 contributions to this document. 2016 12. References 2018 12.1. Normative References 2020 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2021 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2022 . 2024 [RFC1035] Mockapetris, P., "Domain names - implementation and 2025 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2026 November 1987, . 2028 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2029 and E. Lear, "Address Allocation for Private Internets", 2030 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2031 . 2033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2034 Requirement Levels", BCP 14, RFC 2119, 2035 DOI 10.17487/RFC2119, March 1997, 2036 . 2038 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 2039 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 2040 . 2042 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 2043 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 2044 RFC 2136, DOI 10.17487/RFC2136, April 1997, 2045 . 2047 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 2048 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2049 RFC 5382, DOI 10.17487/RFC5382, October 2008, 2050 . 2052 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 2053 for DNS (EDNS(0))", STD 75, RFC 6891, 2054 DOI 10.17487/RFC6891, April 2013, 2055 . 2057 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 2058 D. Wessels, "DNS Transport over TCP - Implementation 2059 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 2060 . 2062 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 2063 edns-tcp-keepalive EDNS0 Option", RFC 7828, 2064 DOI 10.17487/RFC7828, April 2016, 2065 . 2067 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 2068 DOI 10.17487/RFC7830, May 2016, 2069 . 2071 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2072 Writing an IANA Considerations Section in RFCs", BCP 26, 2073 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2074 . 2076 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2077 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2078 May 2017, . 2080 12.2. Informative References 2082 [I-D.ietf-dnssd-mdns-relay] 2083 Lemon, T. and S. Cheshire, "Multicast DNS Discovery 2084 Relay", draft-ietf-dnssd-mdns-relay-00 (work in progress), 2085 May 2018. 2087 [I-D.ietf-dnssd-push] 2088 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 2089 draft-ietf-dnssd-push-14 (work in progress), March 2018. 2091 [I-D.ietf-dprive-padding-policy] 2092 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 2093 dprive-padding-policy-05 (work in progress), April 2018. 2095 [I-D.ietf-tls-tls13] 2096 Rescorla, E., "The Transport Layer Security (TLS) Protocol 2097 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 2098 March 2018. 2100 [NagleDA] Cheshire, S., "TCP Performance problems caused by 2101 interaction between Nagle's Algorithm and Delayed ACK", 2102 May 2005, 2103 . 2105 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2106 DOI 10.17487/RFC0768, August 1980, 2107 . 2109 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2110 Communication Layers", STD 3, RFC 1122, 2111 DOI 10.17487/RFC1122, October 1989, 2112 . 2114 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2115 specifying the location of services (DNS SRV)", RFC 2782, 2116 DOI 10.17487/RFC2782, February 2000, 2117 . 2119 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2120 Cheshire, "Internet Assigned Numbers Authority (IANA) 2121 Procedures for the Management of the Service Name and 2122 Transport Protocol Port Number Registry", BCP 165, 2123 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2124 . 2126 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2127 DOI 10.17487/RFC6762, February 2013, 2128 . 2130 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2131 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2132 . 2134 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2135 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2136 . 2138 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2139 and P. Hoffman, "Specification for DNS over Transport 2140 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2141 2016, . 2143 Authors' Addresses 2145 Ray Bellis 2146 Internet Systems Consortium, Inc. 2147 950 Charter Street 2148 Redwood City CA 94063 2149 USA 2151 Phone: +1 (650) 423-1200 2152 Email: ray@isc.org 2153 Stuart Cheshire 2154 Apple Inc. 2155 One Apple Park Way 2156 Cupertino CA 95014 2157 USA 2159 Phone: +1 (408) 996-1010 2160 Email: cheshire@apple.com 2162 John Dickinson 2163 Sinodun Internet Technologies 2164 Magadalen Centre 2165 Oxford Science Park 2166 Oxford OX4 4GA 2167 United Kingdom 2169 Email: jad@sinodun.com 2171 Sara Dickinson 2172 Sinodun Internet Technologies 2173 Magadalen Centre 2174 Oxford Science Park 2175 Oxford OX4 4GA 2176 United Kingdom 2178 Email: sara@sinodun.com 2180 Ted Lemon 2181 Barefoot Consulting 2182 Brattleboro 2183 VT 05301 2184 USA 2186 Email: mellon@fugue.com 2188 Tom Pusateri 2189 Unaffiliated 2190 Raleigh NC 27608 2191 USA 2193 Phone: +1 (919) 867-1330 2194 Email: pusateri@bangj.com