1 Internet Engineering Task Force (IETF) R. Bellis
2 Request for Comments: 8490 ISC
3 Updates: 1035, 7766 S. Cheshire
4 Category: Standards Track Apple Inc.
5 ISSN: 2070-1721 J. Dickinson
6 S. Dickinson
7 Sinodun
8 T. Lemon
9 Nibbhaya Consulting
10 T. Pusateri
11 Unaffiliated
12 March 2019
13
14
15 DNS Stateful Operations
16
17 Abstract
18
19 This document defines a new DNS OPCODE for DNS Stateful Operations
20 (DSO). DSO messages communicate operations within persistent
21 stateful sessions using Type Length Value (TLV) syntax. Three TLVs
22 are defined that manage session timeouts, termination, and encryption
23 padding, and a framework is defined for extensions to enable new
24 stateful operations. This document updates RFC 1035 by adding a new
25 DNS header OPCODE that has both different message semantics and a new
26 result code. This document updates RFC 7766 by redefining a session,
27 providing new guidance on connection reuse, and providing a new
28 mechanism for handling session idle timeouts.
29
30 Status of This Memo
31
32 This is an Internet Standards Track document.
33
34 This document is a product of the Internet Engineering Task Force
35 (IETF). It represents the consensus of the IETF community. It has
36 received public review and has been approved for publication by the
37 Internet Engineering Steering Group (IESG). Further information on
38 Internet Standards is available in Section 2 of RFC 7841.
39
40 Information about the current status of this document, any errata,
41 and how to provide feedback on it may be obtained at
42 https://www.rfc-editor.org/info/rfc8490.
43
44
45
46
47
48
49
50
51
52 Bellis, et al. Standards Track [Page 1]
53 RFC 8490 DNS Stateful Operations March 2019
54
55
56 Copyright Notice
57
58 Copyright (c) 2019 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
76 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
77 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9
78 4.1.1. Session Management . . . . . . . . . . . . . . . . . 9
79 4.1.2. Long-Lived Subscriptions . . . . . . . . . . . . . . 9
80 4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10
81 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11
82 5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12
83 5.1.1. DSO Session Establishment Failure . . . . . . . . . . 13
84 5.1.2. DSO Session Establishment Success . . . . . . . . . . 14
85 5.2. Operations after DSO Session Establishment . . . . . . . 14
86 5.3. DSO Session Termination . . . . . . . . . . . . . . . . . 15
87 5.3.1. Handling Protocol Errors . . . . . . . . . . . . . . 15
88 5.4. Message Format . . . . . . . . . . . . . . . . . . . . . 16
89 5.4.1. DNS Header Fields in DSO Messages . . . . . . . . . . 17
90 5.4.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 18
91 5.4.3. DSO Unidirectional Messages . . . . . . . . . . . . . 20
92 5.4.4. TLV Syntax . . . . . . . . . . . . . . . . . . . . . 21
93 5.4.5. Unrecognized TLVs . . . . . . . . . . . . . . . . . . 22
94 5.4.6. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 23
95 5.5. Message Handling . . . . . . . . . . . . . . . . . . . . 24
96 5.5.1. Delayed Acknowledgement Management . . . . . . . . . 25
97 5.5.2. MESSAGE ID Namespaces . . . . . . . . . . . . . . . . 26
98 5.5.3. Error Responses . . . . . . . . . . . . . . . . . . . 27
99 5.6. Responder-Initiated Operation Cancellation . . . . . . . 28
100 6. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 29
101 6.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 29
102 6.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 30
103 6.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 31
104
105
106
107 Bellis, et al. Standards Track [Page 2]
108 RFC 8490 DNS Stateful Operations March 2019
109
110
111 6.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 32
112 6.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 32
113 6.4.2. Values for the Inactivity Timeout . . . . . . . . . . 33
114 6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 34
115 6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 34
116 6.5.2. Values for the Keepalive Interval . . . . . . . . . . 34
117 6.6. Server-Initiated DSO Session Termination . . . . . . . . 36
118 6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 37
119 6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 38
120 6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 38
121 7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 40
122 7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 40
123 7.1.1. Client Handling of Received Session Timeout Values . 42
124 7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option . . 43
125 7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 44
126 7.2.1. Retry Delay TLV Used as a Primary TLV . . . . . . . . 44
127 7.2.2. Retry Delay TLV Used as a Response Additional TLV . . 46
128 7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 46
129 8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 47
130 8.1. QR Bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 47
131 8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 48
132 9. Additional Considerations . . . . . . . . . . . . . . . . . . 50
133 9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 50
134 9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 51
135 9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 52
136 9.4. Operational Considerations for Middleboxes . . . . . . . 53
137 9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 54
138 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
139 10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 57
140 10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 57
141 10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 57
142 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
143 11.1. TLS Zero Round-Trip Considerations . . . . . . . . . . . 59
144 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
145 12.1. Normative References . . . . . . . . . . . . . . . . . . 60
146 12.2. Informative References . . . . . . . . . . . . . . . . . 61
147 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63
148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Bellis, et al. Standards Track [Page 3]
163 RFC 8490 DNS Stateful Operations March 2019
164
165
166 1. Introduction
167
168 This document specifies a mechanism for managing stateful DNS
169 connections. DNS most commonly operates over a UDP transport, but it
170 can also operate over streaming transports; the original DNS RFC
171 specifies DNS-over-TCP [RFC1035], and a profile for DNS-over-TLS
172 [RFC7858] has been specified. These transports can offer persistent
173 long-lived sessions and therefore, when using them for transporting
174 DNS messages, it is of benefit to have a mechanism that can establish
175 parameters associated with those sessions, such as timeouts. In such
176 situations, it is also advantageous to support server-initiated
177 messages (such as DNS Push Notifications [Push]).
178
179 The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is
180 explicitly defined to only have "per-message" semantics. While
181 EDNS(0) has been used to signal at least one session-related
182 parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), the result
183 is less than optimal due to the restrictions imposed by the EDNS(0)
184 semantics and the lack of server-initiated signaling. For example, a
185 server cannot arbitrarily instruct a client to close a connection
186 because the server can only send EDNS(0) options in responses to
187 queries that contained EDNS(0) options.
188
189 This document defines a new DNS OPCODE for DNS Stateful Operations
190 (DSO) with a value of 6. DSO messages are used to communicate
191 operations within persistent stateful sessions, expressed using Type
192 Length Value (TLV) syntax. This document defines an initial set of
193 three TLVs used to manage session timeouts, termination, and
194 encryption padding.
195
196 All three TLVs defined here are mandatory for all implementations of
197 DSO. Further TLVs may be defined in additional specifications.
198
199 DSO messages may or may not be acknowledged. Whether a DSO message
200 is to be acknowledged (a DSO request message) or is not to be
201 acknowledged (a DSO unidirectional message) is specified in the
202 definition of that particular DSO message type. The MESSAGE ID is
203 nonzero for DSO request messages, and zero for DSO unidirectional
204 messages. Messages are pipelined and responses may appear out of
205 order when multiple requests are being processed concurrently.
206
207 The format for DSO messages (Section 5.4) differs somewhat from the
208 traditional DNS message format used for standard queries and
209 responses. The standard twelve-byte header is used, but the four
210 count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero,
211 and accordingly their corresponding sections are not present.
212
213
214
215
216
217 Bellis, et al. Standards Track [Page 4]
218 RFC 8490 DNS Stateful Operations March 2019
219
220
221 The actual data pertaining to DNS Stateful Operations (expressed in
222 TLV syntax) is appended to the end of the DNS message header. Just
223 as in traditional DNS-over-TCP [RFC1035] [RFC7766], the stream
224 protocol carrying DSO messages (which are just another kind of DNS
225 message) frames them by putting a 16-bit message length at the start.
226 The length of the DSO message is therefore determined from that
227 length rather than from any of the DNS header counts.
228
229 When displayed using packet analyzer tools that have not been updated
230 to recognize the DSO format, this will result in the DSO data being
231 displayed as unknown extra data after the end of the DNS message.
232
233 This new format has distinct advantages over an RR-based format
234 because it is more explicit and more compact. Each TLV definition is
235 specific to its use case and, as a result, contains no redundant or
236 overloaded fields. Importantly, it completely avoids conflating DNS
237 Stateful Operations in any way with normal DNS operations or with
238 existing EDNS(0)-based functionality. A goal of this approach is to
239 avoid the operational issues that have befallen EDNS(0), particularly
240 relating to middlebox behavior (see sections discussing EDNS(0), and
241 problems caused by firewalls and load balancers, in the recent work
242 describing causes of DNS failures [Fail]).
243
244 With EDNS(0), multiple options may be packed into a single OPT
245 pseudo-RR, and there is no generalized mechanism for a client to be
246 able to tell whether a server has processed or otherwise acted upon
247 each individual option within the combined OPT pseudo-RR. The
248 specifications for each individual option need to define how each
249 different option is to be acknowledged, if necessary.
250
251 In contrast to EDNS(0), with DSO there is no compelling motivation to
252 pack multiple operations into a single message for efficiency
253 reasons, because DSO always operates using a connection-oriented
254 transport protocol. Each DSO operation is communicated in its own
255 separate DNS message, and the transport protocol can take care of
256 packing several DNS messages into a single IP packet if appropriate.
257 For example, TCP can pack multiple small DNS messages into a single
258 TCP segment. This simplification allows for clearer semantics. Each
259 DSO request message communicates just one primary operation, and the
260 RCODE in the corresponding response message indicates the success or
261 failure of that operation.
262
263
264
265
266
267
268
269
270
271
272 Bellis, et al. Standards Track [Page 5]
273 RFC 8490 DNS Stateful Operations March 2019
274
275
276 2. Requirements Language
277
278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
280 "OPTIONAL" in this document are to be interpreted as described in
281 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
282 capitals, as shown here.
283
284 3. Terminology
285
286 DSO: DNS Stateful Operations.
287
288 connection: a bidirectional byte (or message) stream, where the
289 bytes (or messages) are delivered reliably and in order, such as
290 provided by using DNS-over-TCP [RFC1035] [RFC7766] or DNS-over-TLS
291 [RFC7858].
292
293 session: the unqualified term "session" in the context of this
294 document refers to a persistent network connection between two
295 endpoints that allows for the exchange of DNS messages over a
296 connection where either end of the connection can send messages to
297 the other end. (The term has no relationship to the "session
298 layer" of the OSI "seven-layer model".)
299
300 DSO Session: a session established between two endpoints that
301 acknowledge persistent DNS state via the exchange of DSO messages
302 over the connection. This is distinct from a DNS-over-TCP session
303 as described in the previous specification for DNS-over-TCP
304 [RFC7766].
305
306 close gracefully: a normal session shutdown where the client closes
307 the TCP connection to the server using a graceful close such that
308 no data is lost (e.g., using TCP FIN; see Section 5.3).
309
310 forcibly abort: a session shutdown as a result of a fatal error
311 where the TCP connection is unilaterally aborted without regard
312 for data loss (e.g., using TCP RST; see Section 5.3).
313
314 server: the software with a listening socket, awaiting incoming
315 connection requests, in the usual DNS sense.
316
317 client: the software that initiates a connection to the server's
318 listening socket, in the usual DNS sense.
319
320 initiator: the software that sends a DSO request message or a DSO
321 unidirectional message during a DSO Session. Either a client or
322 server can be an initiator.
323
324
325
326
327 Bellis, et al. Standards Track [Page 6]
328 RFC 8490 DNS Stateful Operations March 2019
329
330
331 responder: the software that receives a DSO request message or a DSO
332 unidirectional message during a DSO Session. Either a client or a
333 server can be a responder.
334
335 sender: the software that is sending a DNS message, a DSO message, a
336 DNS response, or a DSO response.
337
338 receiver: the software that is receiving a DNS message, a DSO
339 message, a DNS response, or a DSO response.
340
341 service instance: a specific instance of server software running on
342 a specific host (Section 9.1).
343
344 long-lived operation: an outstanding operation on a DSO Session
345 where either the client or server, acting as initiator, has
346 requested that the responder send new information regarding the
347 request, as it becomes available.
348
349 early data: a TLS 1.3 handshake containing data on the first flight
350 that begins a DSO Session (Section 2.3 of the TLS 1.3
351 specification [RFC8446]). TCP Fast Open [RFC7413] is only
352 permitted when using TLS.
353
354 DNS message: any DNS message, including DNS queries, responses,
355 updates, DSO messages, etc.
356
357 DNS request message: any DNS message where the QR bit is 0.
358
359 DNS response message: any DNS message where the QR bit is 1.
360
361 DSO message: a DSO request message, DSO unidirectional message, or
362 DSO response to a DSO request message. If the QR bit is 1 in a
363 DSO message, it is a DSO response message. If the QR bit is 0 in
364 a DSO message, it is a DSO request message or DSO unidirectional
365 message, as determined by the specification of its Primary TLV.
366
367 DSO response message: a response to a DSO request message.
368
369 DSO request message: a DSO message that requires a response.
370
371 DSO unidirectional message: a DSO message that does not require and
372 cannot induce a response.
373
374 Primary TLV: the first TLV in a DSO request message or DSO
375 unidirectional message; this determines the nature of the
376 operation being performed.
377
378
379
380
381
382 Bellis, et al. Standards Track [Page 7]
383 RFC 8490 DNS Stateful Operations March 2019
384
385
386 Additional TLV: any TLVs that follow the Primary TLV in a DSO
387 request message or DSO unidirectional message.
388
389 Response Primary TLV: in a DSO response, any TLVs with the same DSO-
390 TYPE as the Primary TLV from the corresponding DSO request
391 message. If present, any Response Primary TLV(s) MUST appear
392 first in the DSO response message, before any Response Additional
393 TLVs.
394
395 Response Additional TLV: any TLVs in a DSO response that follow the
396 (optional) Response Primary TLV(s).
397
398 inactivity timer: the time since the most recent non-keepalive DNS
399 message was sent or received (see Section 6.4).
400
401 keepalive timer: the time since the most recent DNS message was sent
402 or received (see Section 6.5).
403
404 session timeouts: the inactivity timer and the keepalive timer.
405
406 inactivity timeout: the maximum value that the inactivity timer can
407 have before the connection is gracefully closed.
408
409 keepalive interval: the maximum value that the keepalive timer can
410 have before the client is required to send a keepalive (see
411 Section 7.1).
412
413 resetting a timer: setting the timer value to zero and restarting
414 the timer.
415
416 clearing a timer: setting the timer value to zero but not restarting
417 the timer.
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Bellis, et al. Standards Track [Page 8]
438 RFC 8490 DNS Stateful Operations March 2019
439
440
441 4. Applicability
442
443 DNS Stateful Operations are applicable to several known use cases and
444 are only applicable on transports that are capable of supporting a
445 DSO Session.
446
447 4.1. Use Cases
448
449 Several use cases for DNS Stateful Operations are described below.
450
451 4.1.1. Session Management
452
453 In one use case, establishing session parameters such as server-
454 defined timeouts is of great use in the general management of
455 persistent connections. For example, using DSO Sessions for stub-to-
456 recursive DNS-over-TLS [RFC7858] is more flexible for both the client
457 and the server than attempting to manage sessions using just the
458 edns-tcp-keepalive EDNS(0) Option [RFC7828]. The simple set of TLVs
459 defined in this document is sufficient to greatly enhance connection
460 management for this use case.
461
462 4.1.2. Long-Lived Subscriptions
463
464 In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763]
465 has evolved into a naturally session-based mechanism where, for
466 example, long-lived subscriptions lend themselves to 'push'
467 mechanisms as opposed to polling. Long-lived stateful connections
468 and server-initiated messages align with this use case [Push].
469
470 A general use case is that DNS traffic is often bursty, but session
471 establishment can be expensive. One challenge with long-lived
472 connections is sustaining sufficient traffic to maintain NAT and
473 firewall state. To mitigate this issue, this document introduces a
474 new concept for the DNS -- DSO "keepalive traffic". This traffic
475 carries no DNS data and is not considered 'activity' in the classic
476 DNS sense, but it serves to maintain state in middleboxes and to
477 assure the client and server that they still have connectivity to
478 each other.
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Bellis, et al. Standards Track [Page 9]
493 RFC 8490 DNS Stateful Operations March 2019
494
495
496 4.2. Applicable Transports
497
498 DNS Stateful Operations are applicable in cases where it is useful to
499 maintain an open session between a DNS client and server, where the
500 transport allows such a session to be maintained, and where the
501 transport guarantees in-order delivery of messages on which DSO
502 depends. Two specific transports that meet the requirements to
503 support DNS Stateful Operations are DNS-over-TCP [RFC1035] [RFC7766]
504 and DNS-over-TLS [RFC7858].
505
506 Note that in the case of DNS-over-TLS, there is no mechanism for
507 upgrading from DNS-over-TCP to DNS-over-TLS mid-connection (see
508 Section 7 of the DNS-over-TLS specification [RFC7858]). A connection
509 is either DNS-over-TCP from the start, or DNS-over-TLS from the
510 start.
511
512 DNS Stateful Operations are not applicable for transports that cannot
513 support clean session semantics or that do not guarantee in-order
514 delivery. While in principle such a transport could be constructed
515 over UDP, the current specification of DNS-over-UDP [RFC1035] does
516 not provide in-order delivery or session semantics and hence cannot
517 be used. Similarly, DNS-over-HTTP [RFC8484] cannot be used because
518 HTTP has its own mechanism for managing sessions, which is
519 incompatible with the mechanism specified here.
520
521 Only DNS-over-TCP and DNS-over-TLS are currently defined for use with
522 DNS Stateful Operations. Other transports may be added in the future
523 if they meet the requirements set out in the first paragraph of this
524 section.
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Bellis, et al. Standards Track [Page 10]
548 RFC 8490 DNS Stateful Operations March 2019
549
550
551 5. Protocol Details
552
553 The overall flow of DNS Stateful Operations goes through a series of
554 phases:
555
556 Connection Establishment: A client establishes a connection to a
557 server (Section 4.2).
558
559 Connected but Sessionless: A connection exists, but a DSO Session
560 has not been established. DNS messages can be sent from the
561 client to server, and DNS responses can be sent from the server to
562 the client. In this state, a client that wishes to use DSO can
563 attempt to establish a DSO Session (Section 5.1). Standard DNS-
564 over-TCP inactivity timeout handling is in effect [RFC7766] (see
565 Section 7.1.2 of this document).
566
567 DSO Session Establishment in Progress: A client has sent a DSO
568 request within the last 30 seconds, but has not yet received a DSO
569 response for that request. In this phase, the client may send
570 more DSO requests and more DNS requests, but MUST NOT send DSO
571 unidirectional messages (Section 5.1).
572
573 DSO Session Establishment Timeout: A client has sent a DSO request,
574 and after 30 seconds has still received no DSO response for that
575 request. This means that the server is now in an indeterminate
576 state. The client forcibly aborts the connection. The client MAY
577 reconnect without using DSO, if appropriate.
578
579 DSO Session Establishment Failed: A client has sent a DSO request,
580 and received a corresponding DSO response with a nonzero RCODE.
581 This means that the attempt to establish the DSO Session did not
582 succeed. At this point, the client is permitted to continue
583 operating without a DSO Session (Connected but Sessionless) but
584 does not send further DSO messages (Section 5.1).
585
586 DSO Session Established: A client has sent a DSO request, and
587 received a corresponding DSO response with RCODE set to NOERROR
588 (0). A DSO Session has now been successfully established. Both
589 client and server may send DSO messages and DNS messages; both may
590 send replies in response to messages they receive (Section 5.2).
591 The inactivity timer (Section 6.4) is active; the keepalive timer
592 (Section 6.5) is active. Standard DNS-over-TCP inactivity timeout
593 handling is no longer in effect [RFC7766] (see Section 7.1.2 of
594 this document).
595
596
597
598
599
600
601
602 Bellis, et al. Standards Track [Page 11]
603 RFC 8490 DNS Stateful Operations March 2019
604
605
606 Server Shutdown: The server has decided to gracefully terminate the
607 session and has sent the client a Retry Delay message
608 (Section 6.6.1). There may still be unprocessed messages from the
609 client; the server will ignore these. The server will not send
610 any further messages to the client (Section 6.6.1.1).
611
612 Client Shutdown: The client has decided to disconnect, either
613 because it no longer needs service, the connection is inactive
614 (Section 6.4.1), or because the server sent it a Retry Delay
615 message (Section 6.6.1). The client closes the connection
616 gracefully (Section 5.3).
617
618 Reconnect: The client disconnected as a result of a server shutdown.
619 The client either waits for the server-specified Retry Delay to
620 expire (Section 6.6.3) or else contacts a different server
621 instance. If the client no longer needs service, it does not
622 reconnect.
623
624 Forcibly Abort: The client or server detected a protocol error, and
625 further communication would have undefined behavior. The client
626 or server forcibly aborts the connection (Section 5.3).
627
628 Abort Reconnect Wait: The client has forcibly aborted the connection
629 but still needs service. Or, the server forcibly aborted the
630 connection, but the client still needs service. The client either
631 connects to a different service instance (Section 9.1) or waits to
632 reconnect (Section 6.6.3.1).
633
634 5.1. DSO Session Establishment
635
636 In order for a session to be established between a client and a
637 server, the client must first establish a connection to the server
638 using an applicable transport (see Section 4.2).
639
640 In some environments, it may be known in advance by external means
641 that both client and server support DSO, and in these cases either
642 client or server may initiate DSO messages at any time. In this
643 case, the session is established as soon as the connection is
644 established; this is referred to as implicit DSO Session
645 establishment.
646
647 However, in the typical case a server will not know in advance
648 whether a client supports DSO, so in general, unless it is known in
649 advance by other means that a client does support DSO, a server MUST
650 NOT initiate DSO request messages or DSO unidirectional messages
651 until a DSO Session has been mutually established by at least one
652 successful DSO request/response exchange initiated by the client, as
653
654
655
656
657 Bellis, et al. Standards Track [Page 12]
658 RFC 8490 DNS Stateful Operations March 2019
659
660
661 described below. This is referred to as explicit DSO Session
662 establishment.
663
664 Until a DSO Session has been implicitly or explicitly established, a
665 client MUST NOT initiate DSO unidirectional messages.
666
667 A DSO Session is established over a connection by the client sending
668 a DSO request message, such as a DSO Keepalive request message
669 (Section 7.1), and receiving a response with a matching MESSAGE ID,
670 and RCODE set to NOERROR (0), indicating that the DSO request was
671 successful.
672
673 Some DSO messages are permitted as early data (Section 11.1). Others
674 are not. Unidirectional messages are never permitted as early data,
675 unless an implicit DSO Session exists.
676
677 If a server receives a DSO message in early data whose Primary TLV is
678 not permitted to appear in early data, the server MUST forcibly abort
679 the connection. If a client receives a DSO message in early data,
680 and there is no implicit DSO Session, the client MUST forcibly abort
681 the connection. This can only be enforced on TLS connections;
682 therefore, servers MUST NOT enable TCP Fast Open (TFO) when listening
683 for a connection that does not require TLS.
684
685 5.1.1. DSO Session Establishment Failure
686
687 If the response RCODE is set to NOTIMP (4), or in practice any value
688 other than NOERROR (0) or DSOTYPENI (defined below), then the client
689 MUST assume that the server does not implement DSO at all. In this
690 case, the client is permitted to continue sending DNS messages on
691 that connection but MUST NOT issue further DSO messages on that
692 connection.
693
694 If the RCODE in the response is set to DSOTYPENI ("DSO-TYPE Not
695 Implemented"; RCODE 11), this indicates that the server does support
696 DSO but does not implement the DSO-TYPE of the Primary TLV in this
697 DSO request message. A server implementing DSO MUST NOT return
698 DSOTYPENI for a DSO Keepalive request message because the Keepalive
699 TLV is mandatory to implement. But in the future, if a client
700 attempts to establish a DSO Session using a response-requiring DSO
701 request message using some newly-defined DSO-TYPE that the server
702 does not understand, that would result in a DSOTYPENI response. If
703 the server returns DSOTYPENI, then a DSO Session is not considered
704 established. The client is, however, permitted to continue sending
705 DNS messages on the connection, including other DSO messages such as
706 the DSO Keepalive, which may result in a successful NOERROR response,
707 yielding the establishment of a DSO Session.
708
709
710
711
712 Bellis, et al. Standards Track [Page 13]
713 RFC 8490 DNS Stateful Operations March 2019
714
715
716 When a DSO message is received by an existing DNS server that doesn't
717 recognize the DSO OPCODE, two other possible outcomes exist: the
718 server might send no response to the DSO message, or the server might
719 drop the connection.
720
721 If the server sends no response to the DSO message, the client SHOULD
722 wait 30 seconds, after which time the server will be assumed not to
723 support DSO. If the server doesn't respond within 30 seconds, it can
724 be assumed that it is not going to respond; this leaves it in an
725 unspecified state: there is no specification requiring that a
726 response be sent to an unknown message, but there is also no
727 specification stating what state the server is in if no response is
728 sent. Therefore the client MUST forcibly abort the connection to the
729 server. The client MAY reconnect, but not use DSO, if appropriate
730 (Section 6.6.3.1). By disconnecting and reconnecting, the client
731 ensures that the server is in a known state before sending any
732 subsequent requests.
733
734 If the server drops the connection the client SHOULD mark that
735 service instance as not supporting DSO, and not attempt a DSO
736 connection for some period of time (at least an hour) after the
737 failed attempt. The client MAY reconnect but not use DSO, if
738 appropriate (Section 6.6.3.2).
739
740 5.1.2. DSO Session Establishment Success
741
742 When the server receives a DSO request message from a client, and
743 transmits a successful NOERROR response to that request, the server
744 considers the DSO Session established.
745
746 When the client receives the server's NOERROR response to its DSO
747 request message, the client considers the DSO Session established.
748
749 Once a DSO Session has been established, either end may unilaterally
750 send appropriate DSO messages at any time, and therefore either
751 client or server may be the initiator of a message.
752
753 5.2. Operations after DSO Session Establishment
754
755 Once a DSO Session has been established, clients and servers should
756 behave as described in this specification with regard to inactivity
757 timeouts and session termination, not as previously prescribed in the
758 earlier specification for DNS-over-TCP [RFC7766].
759
760 Because a server that supports DNS Stateful Operations MUST return an
761 RCODE of "NOERROR" when it receives a Keepalive TLV DSO request
762 message, the Keepalive TLV is an ideal candidate for use in
763 establishing a DSO Session. Any other option that can only succeed
764
765
766
767 Bellis, et al. Standards Track [Page 14]
768 RFC 8490 DNS Stateful Operations March 2019
769
770
771 when sent to a server of the desired kind is also a good candidate
772 for use in establishing a DSO Session. For clients that implement
773 only the DSO-TYPEs defined in this base specification, sending a
774 Keepalive TLV is the only DSO request message they have available to
775 initiate a DSO Session. Even for clients that do implement other
776 future DSO-TYPEs, for simplicity they MAY elect to always send an
777 initial DSO Keepalive request message as their way of initiating a
778 DSO Session. A future definition of a new response-requiring DSO-
779 TYPE gives implementers the option of using that new DSO-TYPE if they
780 wish, but does not change the fact that sending a Keepalive TLV
781 remains a valid way of initiating a DSO Session.
782
783 5.3. DSO Session Termination
784
785 A DSO Session is terminated when the underlying connection is closed.
786 DSO Sessions are "closed gracefully" as a result of the server
787 closing a DSO Session because it is overloaded, because of the client
788 closing the DSO Session because it is done, or because of the client
789 closing the DSO Session because it is inactive. DSO Sessions are
790 "forcibly aborted" when either the client or server closes the
791 connection because of a protocol error.
792
793 o Where this specification says "close gracefully", it means sending
794 a TLS close_notify (if TLS is in use) followed by a TCP FIN, or
795 the equivalent for other protocols. Where this specification
796 requires a connection to be closed gracefully, the requirement to
797 initiate that graceful close is placed on the client in order to
798 place the burden of TCP's TIME-WAIT state on the client rather
799 than the server.
800
801 o Where this specification says "forcibly abort", it means sending a
802 TCP RST or the equivalent for other protocols. In the BSD Sockets
803 API, this is achieved by setting the SO_LINGER option to zero
804 before closing the socket.
805
806 5.3.1. Handling Protocol Errors
807
808 In protocol implementation, there are generally two kinds of errors
809 that software writers have to deal with. The first is situations
810 that arise due to factors in the environment, such as temporary loss
811 of connectivity. While undesirable, these situations do not indicate
812 a flaw in the software and are situations that software should
813 generally be able to recover from.
814
815 The second is situations that should never happen when communicating
816 with a compliant DSO implementation. If they do happen, they
817 indicate a serious flaw in the protocol implementation beyond what is
818 reasonable to expect software to recover from. This document
819
820
821
822 Bellis, et al. Standards Track [Page 15]
823 RFC 8490 DNS Stateful Operations March 2019
824
825
826 describes this latter form of error condition as a "fatal error" and
827 specifies that an implementation encountering a fatal error condition
828 "MUST forcibly abort the connection immediately".
829
830 5.4. Message Format
831
832 A DSO message begins with the standard twelve-byte DNS message header
833 [RFC1035] with the OPCODE field set to the DSO OPCODE (6). However,
834 unlike standard DNS messages, the question section, answer section,
835 authority records section, and additional records sections are not
836 present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
837 ARCOUNT) MUST be set to zero on transmission.
838
839 If a DSO message is received where any of the count fields are not
840 zero, then a FORMERR MUST be returned.
841
842 1 1 1 1 1 1
843 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
844 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
845 | MESSAGE ID |
846 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
847 |QR | OPCODE (6) | Z | RCODE |
848 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
849 | QDCOUNT (MUST be zero) |
850 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
851 | ANCOUNT (MUST be zero) |
852 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
853 | NSCOUNT (MUST be zero) |
854 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
855 | ARCOUNT (MUST be zero) |
856 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
857 | |
858 / DSO Data /
859 / /
860 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877 Bellis, et al. Standards Track [Page 16]
878 RFC 8490 DNS Stateful Operations March 2019
879
880
881 5.4.1. DNS Header Fields in DSO Messages
882
883 In a DSO unidirectional message, the MESSAGE ID field MUST be set to
884 zero. In a DSO request message, the MESSAGE ID field MUST be set to
885 a unique nonzero value that the initiator is not currently using for
886 any other active operation on this connection. For the purposes
887 here, a MESSAGE ID is in use in this DSO Session if the initiator has
888 used it in a DSO request message for which it is still awaiting a
889 response, or if the client has used it to set up a long-lived
890 operation that has not yet been canceled. For example, a long-lived
891 operation could be a Push Notification subscription [Push] or a
892 Discovery Relay interface subscription [Relay].
893
894 Whether a message is a DSO request message or a DSO unidirectional
895 message is determined only by the specification for the Primary TLV.
896 An acknowledgment cannot be requested by including a nonzero MESSAGE
897 ID in a message that is required according to its Primary TLV to be
898 unidirectional. Nor can an acknowledgment be prevented by sending a
899 MESSAGE ID of zero in a message that is required to be a DSO request
900 message according to its Primary TLV. A responder that receives
901 either such malformed message MUST treat it as a fatal error and
902 forcibly abort the connection immediately.
903
904 In a DSO request message or DSO unidirectional message, the DNS
905 Header Query/Response (QR) bit MUST be zero (QR=0). If the QR bit is
906 not zero, the message is not a DSO request or DSO unidirectional
907 message.
908
909 In a DSO response message, the DNS Header QR bit MUST be one (QR=1).
910 If the QR bit is not one, the message is not a DSO response message.
911
912 In a DSO response message (QR=1), the MESSAGE ID field MUST NOT be
913 zero, and MUST contain a copy of the value of the (nonzero) MESSAGE
914 ID field in the DSO request message being responded to. If a DSO
915 response message (QR=1) is received where the MESSAGE ID is zero,
916 this is a fatal error and the recipient MUST forcibly abort the
917 connection immediately.
918
919 The DNS Header OPCODE field holds the DSO OPCODE value (6).
920
921 The Z bits are currently unused in DSO messages; in both DSO request
922 messages and DSO responses, the Z bits MUST be set to zero (0) on
923 transmission and MUST be ignored on reception.
924
925 In a DSO request message (QR=0), the RCODE is set according to the
926 definition of the request. For example, in a Retry Delay message
927 (Section 6.6.1), the RCODE indicates the reason for termination.
928 However, in most DSO request messages (QR=0), except where clearly
929
930
931
932 Bellis, et al. Standards Track [Page 17]
933 RFC 8490 DNS Stateful Operations March 2019
934
935
936 specified otherwise, the RCODE is set to zero on transmission, and
937 silently ignored on reception.
938
939 The RCODE value in a response message (QR=1) may be one of the
940 following values:
941
942 +------+-----------+------------------------------------------------+
943 | Code | Mnemonic | Description |
944 +------+-----------+------------------------------------------------+
945 | 0 | NOERROR | Operation processed successfully |
946 | | | |
947 | 1 | FORMERR | Format error |
948 | | | |
949 | 2 | SERVFAIL | Server failed to process DSO request message |
950 | | | due to a problem with the server |
951 | | | |
952 | 4 | NOTIMP | DSO not supported |
953 | | | |
954 | 5 | REFUSED | Operation declined for policy reasons |
955 | | | |
956 | 11 | DSOTYPENI | Primary TLV's DSO-Type is not implemented |
957 +------+-----------+------------------------------------------------+
958
959 Use of the above RCODEs is likely to be common in DSO but does not
960 preclude the definition and use of other codes in future documents
961 that make use of DSO.
962
963 If a document defining a new DSO-TYPE makes use of response codes not
964 defined here, then that document MUST specify the specific
965 interpretation of those RCODE values in the context of that new DSO
966 TLV.
967
968 The RCODE field is followed by the four zero-valued count fields,
969 followed by the DSO Data.
970
971 5.4.2. DSO Data
972
973 The standard twelve-byte DNS message header with its zero-valued
974 count fields is followed by the DSO Data, expressed using TLV syntax,
975 as described in Section 5.4.4.
976
977 A DSO request message or DSO unidirectional message MUST contain at
978 least one TLV. The first TLV in a DSO request message or DSO
979 unidirectional message is referred to as the "Primary TLV" and
980 determines the nature of the operation being performed, including
981 whether it is a DSO request or a DSO unidirectional operation. In
982 some cases, it may be appropriate to include other TLVs in a DSO
983 request message or DSO unidirectional message, such as the DSO
984
985
986
987 Bellis, et al. Standards Track [Page 18]
988 RFC 8490 DNS Stateful Operations March 2019
989
990
991 Encryption Padding TLV (Section 7.3). Additional TLVs follow the
992 Primary TLV. Additional TLVs are not limited to what is defined in
993 this document. New Additional TLVs may be defined in the future.
994 Their definitions will describe when their use is appropriate.
995
996 An unrecognized Primary TLV results in a DSOTYPENI error response.
997 Unrecognized Additional TLVs are silently ignored, as described in
998 Sections 5.4.5 and 8.2.
999
1000 A DSO response message may contain no TLVs, or may contain one or
1001 more TLVs, appropriate to the information being communicated.
1002
1003 Any TLVs with the same DSO-TYPE as the Primary TLV from the
1004 corresponding DSO request message are Response Primary TLV(s) and
1005 MUST appear first in a DSO response message. A DSO response message
1006 may contain multiple Response Primary TLVs, or a single Response
1007 Primary TLV, or in some cases, no Response Primary TLV. A Response
1008 Primary TLV is not required; for most DSO operations the MESSAGE ID
1009 field in the DNS message header is sufficient to identify the DSO
1010 request message to which a particular response message relates.
1011
1012 Any other TLVs in a DSO response message are Response Additional
1013 TLVs, such as the DSO Encryption Padding TLV (Section 7.3). Response
1014 Additional TLVs follow the Response Primary TLV(s), if present.
1015 Response Additional TLVs are not limited to what is defined in this
1016 document. New Response Additional TLVs may be defined in the future.
1017 Their definitions will describe when their use is appropriate.
1018 Unrecognized Response Additional TLVs are silently ignored, as
1019 described in Sections 5.4.5 and 8.2.
1020
1021 The specification for each DSO TLV determines what TLVs are required
1022 in a response to a DSO request message using that TLV. If a DSO
1023 response is received for an operation where the specification
1024 requires that the response carry a particular TLV or TLVs, and the
1025 required TLV(s) are not present, then this is a fatal error and the
1026 recipient of the defective response message MUST forcibly abort the
1027 connection immediately. Similarly, if more than the specified number
1028 of instances of a given TLV are present, this is a fatal error and
1029 the recipient of the defective response message MUST forcibly abort
1030 the connection immediately.
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Bellis, et al. Standards Track [Page 19]
1043 RFC 8490 DNS Stateful Operations March 2019
1044
1045
1046 5.4.3. DSO Unidirectional Messages
1047
1048 It is anticipated that most DSO operations will be specified to use
1049 DSO request messages, which generate corresponding DSO responses. In
1050 some specialized high-traffic use cases, it may be appropriate to
1051 specify DSO unidirectional messages. DSO unidirectional messages can
1052 be more efficient on the network because they don't generate a stream
1053 of corresponding reply messages. Using DSO unidirectional messages
1054 can also simplify software in some cases by removing the need for an
1055 initiator to maintain state while it waits to receive replies it
1056 doesn't care about. When the specification for a particular TLV used
1057 as a Primary TLV (i.e., first) in an outgoing DSO request message
1058 (i.e., QR=0) states that a message is to be unidirectional, the
1059 MESSAGE ID field MUST be set to zero and the receiver MUST NOT
1060 generate any response message corresponding to that DSO
1061 unidirectional message.
1062
1063 The previous point, that the receiver MUST NOT generate responses to
1064 DSO unidirectional messages, applies even in the case of errors.
1065
1066 When a DSO message is received where both the QR bit and the MESSAGE
1067 ID field are zero, the receiver MUST NOT generate any response. For
1068 example, if the DSO-TYPE in the Primary TLV is unrecognized, then a
1069 DSOTYPENI error MUST NOT be returned; instead, the receiver MUST
1070 forcibly abort the connection immediately.
1071
1072 DSO unidirectional messages MUST NOT be used "speculatively" in cases
1073 where the sender doesn't know if the receiver supports the Primary
1074 TLV in the message because there is no way to receive any response to
1075 indicate success or failure. DSO unidirectional messages are only
1076 appropriate in cases where the sender already knows that the receiver
1077 supports and wishes to receive these messages.
1078
1079 For example, after a client has subscribed for Push Notifications
1080 [Push], the subsequent event notifications are then sent as DSO
1081 unidirectional messages. This is appropriate because the client
1082 initiated the message stream by virtue of its Push Notification
1083 subscription, thereby indicating its support of Push Notifications
1084 and its desire to receive those notifications.
1085
1086 Similarly, after a Discovery Relay client has subscribed to receive
1087 inbound multicast DNS (mDNS) [RFC6762] traffic from a Discovery
1088 Relay, the subsequent stream of received packets is then sent using
1089 DSO unidirectional messages. This is appropriate because the client
1090 initiated the message stream by virtue of its Discovery Relay link
1091 subscription, thereby indicating its support of Discovery Relay and
1092 its desire to receive inbound mDNS packets over that DSO Session
1093 [Relay].
1094
1095
1096
1097 Bellis, et al. Standards Track [Page 20]
1098 RFC 8490 DNS Stateful Operations March 2019
1099
1100
1101 5.4.4. TLV Syntax
1102
1103 All TLVs, whether used as "Primary", "Additional", "Response
1104 Primary", or "Response Additional", use the same encoding syntax.
1105
1106 A specification that defines a new TLV must specify whether the DSO-
1107 TYPE can be used as a Primary TLV, and whether the DSO-TYPE can be
1108 used as an Additional TLV. Some DSO-TYPEs are dual-purpose and can
1109 be used as Primary TLVs in some messages, and in other messages as
1110 Additional TLVs. The specification for a DSO-TYPE must also state
1111 whether, when used as the Primary (i.e., first) TLV in a DSO message
1112 (i.e., QR=0), that DSO message is unidirectional, or is a DSO request
1113 message that requires a response.
1114
1115 If a DSO request message requires a response, the specification must
1116 also state which TLVs, if any, are to be included in the response and
1117 how many instances of each of the TLVs are allowed. The Primary TLV
1118 may or may not be contained in the response depending on what is
1119 specified for that TLV. If multiple instances of the Primary TLV are
1120 allowed the specification should clearly describe how they should be
1121 processed.
1122
1123 1 1 1 1 1 1
1124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1125 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1126 | DSO-TYPE |
1127 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1128 | DSO-LENGTH |
1129 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1130 | |
1131 / DSO-DATA /
1132 / /
1133 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1134
1135 DSO-TYPE: A 16-bit unsigned integer, in network (big endian) byte
1136 order, giving the DSO-TYPE of the current DSO TLV per the IANA
1137 "DSO Type Codes" registry.
1138
1139 DSO-LENGTH: A 16-bit unsigned integer, in network (big endian) byte
1140 order, giving the size in bytes of the DSO-DATA.
1141
1142 DSO-DATA: Type-code specific format. The generic DSO machinery
1143 treats the DSO-DATA as an opaque "blob" without attempting to
1144 interpret it. Interpretation of the meaning of the DSO-DATA for a
1145 particular DSO-TYPE is the responsibility of the software that
1146 implements that DSO-TYPE.
1147
1148
1149
1150
1151
1152 Bellis, et al. Standards Track [Page 21]
1153 RFC 8490 DNS Stateful Operations March 2019
1154
1155
1156 5.4.5. Unrecognized TLVs
1157
1158 If a DSO request message is received containing an unrecognized
1159 Primary TLV, with a nonzero MESSAGE ID (indicating that a response is
1160 expected), then the receiver MUST send an error response with a
1161 matching MESSAGE ID, and RCODE DSOTYPENI. The error response MUST
1162 NOT contain a copy of the unrecognized Primary TLV.
1163
1164 If a DSO unidirectional message is received containing both an
1165 unrecognized Primary TLV and a zero MESSAGE ID (indicating that no
1166 response is expected), then this is a fatal error and the recipient
1167 MUST forcibly abort the connection immediately.
1168
1169 If a DSO request message or DSO unidirectional message is received
1170 where the Primary TLV is recognized, containing one or more
1171 unrecognized Additional TLVs, the unrecognized Additional TLVs MUST
1172 be silently ignored, and the remainder of the message is interpreted
1173 and handled as if the unrecognized parts were not present.
1174
1175 Similarly, if a DSO response message is received containing one or
1176 more unrecognized TLVs, the unrecognized TLVs MUST be silently
1177 ignored and the remainder of the message is interpreted and handled
1178 as if the unrecognized parts are not present.
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207 Bellis, et al. Standards Track [Page 22]
1208 RFC 8490 DNS Stateful Operations March 2019
1209
1210
1211 5.4.6. EDNS(0) and TSIG
1212
1213 Since the ARCOUNT field MUST be zero, a DSO message cannot contain a
1214 valid EDNS(0) option in the additional records section. If
1215 functionality provided by current or future EDNS(0) options is
1216 desired for DSO messages, one or more new DSO TLVs need to be defined
1217 to carry the necessary information.
1218
1219 For example, the EDNS(0) Padding Option [RFC7830] used for security
1220 purposes is not permitted in a DSO message, so if message padding is
1221 desired for DSO messages, then the DSO Encryption Padding TLV
1222 described in Section 7.3 MUST be used.
1223
1224 A DSO message can't contain a TSIG record because a TSIG record is
1225 included in the additional section of the message, which would mean
1226 that ARCOUNT would be greater than zero. DSO messages are required
1227 to have an ARCOUNT of zero. Therefore, if use of signatures with DSO
1228 messages becomes necessary in the future, a new DSO TLV would have to
1229 be defined to perform this function.
1230
1231 Note, however, that while DSO *messages* cannot include EDNS(0) or
1232 TSIG records, a DSO *session* is typically used to carry a whole
1233 series of DNS messages of different kinds, including DSO messages and
1234 other DNS message types like Query [RFC1034] [RFC1035] and Update
1235 [RFC2136]. These messages can carry EDNS(0) and TSIG records.
1236
1237 Although messages may contain other EDNS(0) options as appropriate,
1238 this specification explicitly prohibits use of the edns-tcp-keepalive
1239 EDNS(0) Option [RFC7828] in *any* messages sent on a DSO Session
1240 (because it is obsoleted by the functionality provided by the DSO
1241 Keepalive operation). If any message sent on a DSO Session contains
1242 an edns-tcp-keepalive EDNS(0) Option, this is a fatal error and the
1243 recipient of the defective message MUST forcibly abort the connection
1244 immediately.
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262 Bellis, et al. Standards Track [Page 23]
1263 RFC 8490 DNS Stateful Operations March 2019
1264
1265
1266 5.5. Message Handling
1267
1268 As described in Section 5.4.1, whether an outgoing DSO message with
1269 the QR bit in the DNS header set to zero is a DSO request or a DSO
1270 unidirectional message is determined by the specification for the
1271 Primary TLV, which in turn determines whether the MESSAGE ID field in
1272 that outgoing message will be zero or nonzero.
1273
1274 Every DSO message with the QR bit in the DNS header set to zero and a
1275 nonzero MESSAGE ID field is a DSO request message, and MUST elicit a
1276 corresponding response, with the QR bit in the DNS header set to one
1277 and the MESSAGE ID field set to the value given in the corresponding
1278 DSO request message.
1279
1280 Valid DSO request messages sent by the client with a nonzero MESSAGE
1281 ID field elicit a response from the server, and valid DSO request
1282 messages sent by the server with a nonzero MESSAGE ID field elicit a
1283 response from the client.
1284
1285 Every DSO message with both the QR bit in the DNS header and the
1286 MESSAGE ID field set to zero is a DSO unidirectional message and MUST
1287 NOT elicit a response.
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317 Bellis, et al. Standards Track [Page 24]
1318 RFC 8490 DNS Stateful Operations March 2019
1319
1320
1321 5.5.1. Delayed Acknowledgement Management
1322
1323 Generally, most good TCP implementations employ a delayed
1324 acknowledgement timer to provide more efficient use of the network
1325 and better performance.
1326
1327 With a bidirectional exchange over TCP, such as with a DSO request
1328 message, the operating system TCP implementation waits for the
1329 application-layer client software to generate the corresponding DSO
1330 response message. The TCP implementation can then send a single
1331 combined packet containing the TCP acknowledgement, the TCP window
1332 update, and the application-generated DSO response message. This is
1333 more efficient than sending three separate packets, as would occur if
1334 the TCP packet containing the DSO request were acknowledged
1335 immediately.
1336
1337 With a DSO unidirectional message or DSO response message, there is
1338 no corresponding application-generated DSO response message, and
1339 consequently, no hint to the transport protocol about when it should
1340 send its acknowledgement and window update.
1341
1342 Some networking APIs provide a mechanism that allows the application-
1343 layer client software to signal to the transport protocol that no
1344 response will be forthcoming (in effect it can be thought of as a
1345 zero-length "empty" write). Where available in the networking API
1346 being used, the recipient of a DSO unidirectional message or DSO
1347 response message, having parsed and interpreted the message, SHOULD
1348 then use this mechanism provided by the networking API to signal that
1349 no response for this message will be forthcoming. The TCP
1350 implementation can then go ahead and send its acknowledgement and
1351 window update without further delay. See Section 9.5 for further
1352 discussion of why this is important.
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372 Bellis, et al. Standards Track [Page 25]
1373 RFC 8490 DNS Stateful Operations March 2019
1374
1375
1376 5.5.2. MESSAGE ID Namespaces
1377
1378 The namespaces of 16-bit MESSAGE IDs are independent in each
1379 direction. This means it is *not* an error for both client and
1380 server to send DSO request messages at the same time as each other,
1381 using the same MESSAGE ID, in different directions. This
1382 simplification is necessary in order for the protocol to be
1383 implementable. It would be infeasible to require the client and
1384 server to coordinate with each other regarding allocation of new
1385 unique MESSAGE IDs. It is also not necessary to require the client
1386 and server to coordinate with each other regarding allocation of new
1387 unique MESSAGE IDs. The value of the 16-bit MESSAGE ID combined with
1388 the identity of the initiator (client or server) is sufficient to
1389 unambiguously identify the operation in question. This can be
1390 thought of as a 17-bit message identifier space using message
1391 identifiers 0x00001-0x0FFFF for client-to-server DSO request
1392 messages, and 0x10001-0x1FFFF for server-to-client DSO request
1393 messages. The least-significant 16 bits are stored explicitly in the
1394 MESSAGE ID field of the DSO message, and the most-significant bit is
1395 implicit from the direction of the message.
1396
1397 As described in Section 5.4.1, an initiator MUST NOT reuse a MESSAGE
1398 ID that it already has in use for an outstanding DSO request message
1399 (unless specified otherwise by the relevant specification for the
1400 DSO-TYPE in question). At the very least, this means that a MESSAGE
1401 ID can't be reused in a particular direction on a particular DSO
1402 Session while the initiator is waiting for a response to a previous
1403 DSO request message using that MESSAGE ID on that DSO Session (unless
1404 specified otherwise by the relevant specification for the DSO-TYPE in
1405 question), and for a long-lived operation, the MESSAGE ID for the
1406 operation can't be reused while that operation remains active.
1407
1408 If a client or server receives a response (QR=1) where the MESSAGE ID
1409 is zero, or is any other value that does not match the MESSAGE ID of
1410 any of its outstanding operations, this is a fatal error and the
1411 recipient MUST forcibly abort the connection immediately.
1412
1413 If a responder receives a DSO request message (QR=0) where the
1414 MESSAGE ID is not zero, the responder tracks request MESSAGE IDs, and
1415 the MESSAGE ID matches the MESSAGE ID of a DSO request message it
1416 received for which a response has not yet been sent, it MUST forcibly
1417 abort the connection immediately. This behavior is required to
1418 prevent a hypothetical attack that takes advantage of undefined
1419 behavior in this case. However, if the responder does not track
1420 MESSAGE IDs in this way, no such risk exists. Therefore, tracking
1421 MESSAGE IDs just to implement this sanity check is not required.
1422
1423
1424
1425
1426
1427 Bellis, et al. Standards Track [Page 26]
1428 RFC 8490 DNS Stateful Operations March 2019
1429
1430
1431 5.5.3. Error Responses
1432
1433 When a DSO request message is unsuccessful for some reason, the
1434 responder returns an error code to the initiator.
1435
1436 In the case of a server returning an error code to a client in
1437 response to an unsuccessful DSO request message, the server MAY
1438 choose to end the DSO Session or MAY choose to allow the DSO Session
1439 to remain open. For error conditions that only affect the single
1440 operation in question, the server SHOULD return an error response to
1441 the client and leave the DSO Session open for further operations.
1442
1443 For error conditions that are likely to make all operations
1444 unsuccessful in the immediate future, the server SHOULD return an
1445 error response to the client and then end the DSO Session by sending
1446 a Retry Delay message as described in Section 6.6.1.
1447
1448 Upon receiving an error response from the server, a client SHOULD NOT
1449 automatically close the DSO Session. An error relating to one
1450 particular operation on a DSO Session does not necessarily imply that
1451 all other operations on that DSO Session have also failed or that
1452 future operations will fail. The client should assume that the
1453 server will make its own decision about whether or not to end the DSO
1454 Session based on the server's determination of whether the error
1455 condition pertains to this particular operation or to any subsequent
1456 operations. If the server does not end the DSO Session by sending
1457 the client a Retry Delay message (Section 6.6.1), then the client
1458 SHOULD continue to use that DSO Session for subsequent operations.
1459
1460 When a DSO unidirectional message type is received (MESSAGE ID field
1461 is zero), the receiver should already be expecting this DSO message
1462 type. Section 5.4.5 describes the handling of unknown DSO message
1463 types. When a DSO unidirectional message of an unexpected type is
1464 received, the receiver SHOULD forcibly abort the connection. Whether
1465 the connection should be forcibly aborted for other internal errors
1466 processing the DSO unidirectional message is implementation dependent
1467 according to the severity of the error.
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482 Bellis, et al. Standards Track [Page 27]
1483 RFC 8490 DNS Stateful Operations March 2019
1484
1485
1486 5.6. Responder-Initiated Operation Cancellation
1487
1488 This document, the base specification for DNS Stateful Operations,
1489 does not itself define any long-lived operations, but it defines a
1490 framework for supporting long-lived operations such as Push
1491 Notification subscriptions [Push] and Discovery Relay interface
1492 subscriptions [Relay].
1493
1494 Long-lived operations, if successful, will remain active until the
1495 initiator terminates the operation.
1496
1497 However, it is possible that a long-lived operation may be valid at
1498 the time it was initiated, but then a later change of circumstances
1499 may render that operation invalid. For example, a long-lived client
1500 operation may pertain to a name that the server is authoritative for,
1501 but then the server configuration is changed such that it is no
1502 longer authoritative for that name.
1503
1504 In such cases, instead of terminating the entire session, it may be
1505 desirable for the responder to be able to cancel selectively only
1506 those operations that have become invalid.
1507
1508 The responder performs this selective cancellation by sending a new
1509 DSO response message with the MESSAGE ID field containing the MESSAGE
1510 ID of the long-lived operation that is to be terminated (that it had
1511 previously acknowledged with a NOERROR RCODE) and the RCODE field of
1512 the new DSO response message giving the reason for cancellation.
1513
1514 After a DSO response message with nonzero RCODE has been sent, that
1515 operation has been terminated from the responder's point of view, and
1516 the responder sends no more messages relating to that operation.
1517
1518 After a DSO response message with nonzero RCODE has been received by
1519 the initiator, that operation has been terminated from the
1520 initiator's point of view, and the canceled operation's MESSAGE ID is
1521 now free for reuse.
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537 Bellis, et al. Standards Track [Page 28]
1538 RFC 8490 DNS Stateful Operations March 2019
1539
1540
1541 6. DSO Session Lifecycle and Timers
1542
1543 6.1. DSO Session Initiation
1544
1545 A DSO Session begins as described in Section 5.1.
1546
1547 Once a DSO Session has been created, client or server may initiate as
1548 many DNS operations as they wish using the DSO Session.
1549
1550 When an initiator has multiple messages to send, it SHOULD NOT wait
1551 for each response before sending the next message.
1552
1553 A responder MUST act on messages in the order they are received, and
1554 SHOULD return responses to request messages as they become available.
1555 A responder SHOULD NOT delay sending responses for the purpose of
1556 delivering responses in the same order that the corresponding
1557 requests were received.
1558
1559 Section 6.2.1.1 of the DNS-over-TCP specification [RFC7766] specifies
1560 this in more detail.
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592 Bellis, et al. Standards Track [Page 29]
1593 RFC 8490 DNS Stateful Operations March 2019
1594
1595
1596 6.2. DSO Session Timeouts
1597
1598 Two timeout values are associated with a DSO Session: the inactivity
1599 timeout and the keepalive interval. Both values are communicated in
1600 the same TLV, the Keepalive TLV (Section 7.1).
1601
1602 The first timeout value, the inactivity timeout, is the maximum time
1603 for which a client may speculatively keep an inactive DSO Session
1604 open in the expectation that it may have future requests to send to
1605 that server.
1606
1607 The second timeout value, the keepalive interval, is the maximum
1608 permitted interval between messages if the client wishes to keep the
1609 DSO Session alive.
1610
1611 The two timeout values are independent. The inactivity timeout may
1612 be shorter, the same, or longer than the keepalive interval, though
1613 in most cases the inactivity timeout is expected to be shorter than
1614 the keepalive interval.
1615
1616 A shorter inactivity timeout with a longer keepalive interval signals
1617 to the client that it should not speculatively keep an inactive DSO
1618 Session open for very long without reason, but when it does have an
1619 active reason to keep a DSO Session open, it doesn't need to be
1620 sending an aggressive level of DSO keepalive traffic to maintain that
1621 session. An example of this would be a client that has subscribed to
1622 DNS Push notifications. In this case, the client is not sending any
1623 traffic to the server, but the session is not inactive because there
1624 is an active request to the server to receive push notifications.
1625
1626 A longer inactivity timeout with a shorter keepalive interval signals
1627 to the client that it may speculatively keep an inactive DSO Session
1628 open for a long time, but to maintain that inactive DSO Session it
1629 should be sending a lot of DSO keepalive traffic. This configuration
1630 is expected to be less common.
1631
1632 In the usual case where the inactivity timeout is shorter than the
1633 keepalive interval, it is only when a client has a long-lived, low-
1634 traffic operation that the keepalive interval comes into play in
1635 order to ensure that a sufficient residual amount of traffic is
1636 generated to maintain NAT and firewall state, and to assure the
1637 client and server that they still have connectivity to each other.
1638
1639 On a new DSO Session, if no explicit DSO Keepalive message exchange
1640 has taken place, the default value for both timeouts is 15 seconds.
1641
1642 For both timeouts, lower values of the timeout result in higher
1643 network traffic and a higher CPU load on the server.
1644
1645
1646
1647 Bellis, et al. Standards Track [Page 30]
1648 RFC 8490 DNS Stateful Operations March 2019
1649
1650
1651 6.3. Inactive DSO Sessions
1652
1653 At both servers and clients, the generation or reception of any
1654 complete DNS message (including DNS requests, responses, updates, DSO
1655 messages, etc.) resets both timers for that DSO Session, with the one
1656 exception being that a DSO Keepalive message resets only the
1657 keepalive timer, not the inactivity timeout timer.
1658
1659 In addition, for as long as the client has an outstanding operation
1660 in progress, the inactivity timer remains cleared and an inactivity
1661 timeout cannot occur.
1662
1663 For short-lived DNS operations like traditional queries and updates,
1664 an operation is considered "in progress" for the time between request
1665 and response, typically a period of a few hundred milliseconds at
1666 most. At the client, the inactivity timer is cleared upon
1667 transmission of a request and remains cleared until reception of the
1668 corresponding response. At the server, the inactivity timer is
1669 cleared upon reception of a request and remains cleared until
1670 transmission of the corresponding response.
1671
1672 For long-lived DNS Stateful Operations (such as a Push Notification
1673 subscription [Push] or a Discovery Relay interface subscription
1674 [Relay]), an operation is considered "in progress" for as long as the
1675 operation is active, i.e., until it is canceled. This means that a
1676 DSO Session can exist with active operations, with no messages
1677 flowing in either direction, for far longer than the inactivity
1678 timeout. This is not an error. This is why there are two separate
1679 timers: the inactivity timeout and the keepalive interval. Just
1680 because a DSO Session has no traffic for an extended period of time,
1681 it does not automatically make that DSO Session "inactive", if it has
1682 an active operation that is awaiting events.
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702 Bellis, et al. Standards Track [Page 31]
1703 RFC 8490 DNS Stateful Operations March 2019
1704
1705
1706 6.4. The Inactivity Timeout
1707
1708 The purpose of the inactivity timeout is for the server to balance
1709 the trade-off between the costs of setting up new DSO Sessions and
1710 the costs of maintaining inactive DSO Sessions. A server with
1711 abundant DSO Session capacity can offer a high inactivity timeout to
1712 permit clients to keep a speculative DSO Session open for a long time
1713 and to save the cost of establishing a new DSO Session for future
1714 communications with that server. A server with scarce memory
1715 resources can offer a low inactivity timeout to cause clients to
1716 promptly close DSO Sessions whenever they have no outstanding
1717 operations with that server and then create a new DSO Session later
1718 when needed.
1719
1720 6.4.1. Closing Inactive DSO Sessions
1721
1722 When a connection's inactivity timeout is reached, the client MUST
1723 begin closing the idle connection, but a client is not required to
1724 keep an idle connection open until the inactivity timeout is reached.
1725 A client MAY close a DSO Session at any time, at the client's
1726 discretion. If a client determines that it has no current or
1727 reasonably anticipated future need for a currently inactive DSO
1728 Session, then the client SHOULD gracefully close that connection.
1729
1730 If, at any time during the life of the DSO Session, the inactivity
1731 timeout value (i.e., 15 seconds by default) elapses without there
1732 being any operation active on the DSO Session, the client MUST close
1733 the connection gracefully.
1734
1735 If, at any time during the life of the DSO Session, too much time
1736 elapses without there being any operation active on the DSO Session,
1737 then the server MUST consider the client delinquent and MUST forcibly
1738 abort the DSO Session. What is considered "too much time" in this
1739 context is five seconds or twice the current inactivity timeout
1740 value, whichever is greater. If the inactivity timeout has its
1741 default value of 15 seconds, this means that a client will be
1742 considered delinquent and disconnected if it has not closed its
1743 connection after 30 seconds of inactivity.
1744
1745 In this context, an operation being active on a DSO Session includes
1746 a query waiting for a response, an update waiting for a response, or
1747 an active long-lived operation, but not a DSO Keepalive message
1748 exchange itself. A DSO Keepalive message exchange resets only the
1749 keepalive interval timer, not the inactivity timeout timer.
1750
1751 If the client wishes to keep an inactive DSO Session open for longer
1752 than the default duration, then it uses the DSO Keepalive message to
1753 request longer timeout values as described in Section 7.1.
1754
1755
1756
1757 Bellis, et al. Standards Track [Page 32]
1758 RFC 8490 DNS Stateful Operations March 2019
1759
1760
1761 6.4.2. Values for the Inactivity Timeout
1762
1763 For the inactivity timeout value, lower values result in more
1764 frequent DSO Session teardowns and re-establishments. Higher values
1765 result in lower traffic and a lower CPU load on the server, but a
1766 higher memory burden to maintain state for inactive DSO Sessions.
1767
1768 A server may dictate any value it chooses for the inactivity timeout
1769 (either in a response to a client-initiated request or in a server-
1770 initiated message) including values under one second, or even zero.
1771
1772 An inactivity timeout of zero informs the client that it should not
1773 speculatively maintain idle connections at all, and as soon as the
1774 client has completed the operation or operations relating to this
1775 server, the client should immediately begin closing this session.
1776
1777 A server will forcibly abort an idle client session after five
1778 seconds or twice the inactivity timeout value, whichever is greater.
1779 In the case of a zero inactivity timeout value, this means that if a
1780 client fails to close an idle client session, then the server will
1781 forcibly abort the idle session after five seconds.
1782
1783 An inactivity timeout of 0xFFFFFFFF represents "infinity" and informs
1784 the client that it may keep an idle connection open as long as it
1785 wishes. Note that after granting an unlimited inactivity timeout in
1786 this way, at any point the server may revise that inactivity timeout
1787 by sending a new DSO Keepalive message dictating new Session Timeout
1788 values to the client.
1789
1790 The largest *finite* inactivity timeout supported by the current
1791 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7
1792 days).
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812 Bellis, et al. Standards Track [Page 33]
1813 RFC 8490 DNS Stateful Operations March 2019
1814
1815
1816 6.5. The Keepalive Interval
1817
1818 The purpose of the keepalive interval is to manage the generation of
1819 sufficient messages to maintain state in middleboxes (such at NAT
1820 gateways or firewalls) and for the client and server to periodically
1821 verify that they still have connectivity to each other. This allows
1822 them to clean up state when connectivity is lost and to establish a
1823 new session if appropriate.
1824
1825 6.5.1. Keepalive Interval Expiry
1826
1827 If, at any time during the life of the DSO Session, the keepalive
1828 interval value (i.e., 15 seconds by default) elapses without any DNS
1829 messages being sent or received on a DSO Session, the client MUST
1830 take action to keep the DSO Session alive by sending a DSO Keepalive
1831 message (Section 7.1). A DSO Keepalive message exchange resets only
1832 the keepalive timer, not the inactivity timer.
1833
1834 If a client disconnects from the network abruptly, without cleanly
1835 closing its DSO Session, perhaps leaving a long-lived operation
1836 uncanceled, the server learns of this after failing to receive the
1837 required DSO keepalive traffic from that client. If, at any time
1838 during the life of the DSO Session, twice the keepalive interval
1839 value (i.e., 30 seconds by default) elapses without any DNS messages
1840 being sent or received on a DSO Session, the server SHOULD consider
1841 the client delinquent and SHOULD forcibly abort the DSO Session.
1842
1843 6.5.2. Values for the Keepalive Interval
1844
1845 For the keepalive interval value, lower values result in a higher
1846 volume of DSO keepalive traffic. Higher values of the keepalive
1847 interval reduce traffic and the CPU load, but have minimal effect on
1848 the memory burden at the server because clients keep a DSO Session
1849 open for the same length of time (determined by the inactivity
1850 timeout) regardless of the level of DSO keepalive traffic required.
1851
1852 It may be appropriate for clients and servers to select different
1853 keepalive intervals depending on the type of network they are on.
1854
1855 A corporate DNS server that knows it is serving only clients on the
1856 internal network, with no intervening NAT gateways or firewalls, can
1857 impose a longer keepalive interval because frequent DSO keepalive
1858 traffic is not required.
1859
1860 A public DNS server that is serving primarily residential consumer
1861 clients, where it is likely there will be a NAT gateway on the path,
1862 may impose a shorter keepalive interval to generate more frequent DSO
1863 keepalive traffic.
1864
1865
1866
1867 Bellis, et al. Standards Track [Page 34]
1868 RFC 8490 DNS Stateful Operations March 2019
1869
1870
1871 A smart client may be adaptive to its environment. A client using a
1872 private IPv4 address [RFC1918] to communicate with a DNS server at an
1873 address outside that IPv4 private address block may conclude that
1874 there is likely to be a NAT gateway on the path, and accordingly
1875 request a shorter keepalive interval.
1876
1877 By default, it is RECOMMENDED that clients request, and servers
1878 grant, a keepalive interval of 60 minutes. This keepalive interval
1879 provides for reasonably timely detection if a client abruptly
1880 disconnects without cleanly closing the session. Also, it is
1881 sufficient to maintain state in firewalls and NAT gateways that
1882 follow the IETF recommended Best Current Practice that the
1883 "established connection idle-timeout" used by middleboxes be at least
1884 2 hours and 4 minutes [RFC5382] [RFC7857].
1885
1886 Note that the shorter the keepalive interval value, the higher the
1887 load on client and server. Moreover, for a keepalive value that is
1888 shorter than the time needed for the transport to retransmit, the
1889 loss of a single packet would cause a server to overzealously abort
1890 the connection. For example, a (hypothetical and unrealistic)
1891 keepalive interval value of 100 ms would result in a continuous
1892 stream of ten messages per second or more (if allowed by the current
1893 congestion control window) in both directions to keep the DSO Session
1894 alive. And, in this extreme example, a single retransmission over a
1895 path with, as an example, 100 ms RTT would introduce a momentary
1896 pause in the stream of messages long enough to cause the server to
1897 abort the connection.
1898
1899 Because of this concern, the server MUST NOT send a DSO Keepalive
1900 message (either a DSO response to a client-initiated DSO request or a
1901 server-initiated DSO message) with a keepalive interval value less
1902 than ten seconds. If a client receives a DSO Keepalive message
1903 specifying a keepalive interval value less than ten seconds, this is
1904 a fatal error and the client MUST forcibly abort the connection
1905 immediately.
1906
1907 A keepalive interval value of 0xFFFFFFFF represents "infinity" and
1908 informs the client that it should generate no DSO keepalive traffic.
1909 Note that after signaling that the client should generate no DSO
1910 keepalive traffic in this way, the server may at any point revise
1911 that DSO keepalive traffic requirement by sending a new DSO Keepalive
1912 message dictating new Session Timeout values to the client.
1913
1914 The largest *finite* keepalive interval supported by the current
1915 Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7
1916 days).
1917
1918
1919
1920
1921
1922 Bellis, et al. Standards Track [Page 35]
1923 RFC 8490 DNS Stateful Operations March 2019
1924
1925
1926 6.6. Server-Initiated DSO Session Termination
1927
1928 In addition to canceling individual long-lived operations selectively
1929 (Section 5.6), there are also occasions where a server may need to
1930 terminate one or more entire DSO sessions. An entire DSO session may
1931 need to be terminated if the client is defective in some way or
1932 departs from the network without closing its DSO session. DSO
1933 Sessions may also need to be terminated if the server becomes
1934 overloaded or is reconfigured and lacks the ability to be selective
1935 about which operations need to be canceled.
1936
1937 This section discusses various reasons a DSO session may be
1938 terminated and the mechanisms for doing so.
1939
1940 In normal operation, closing a DSO Session is the client's
1941 responsibility. The client makes the determination of when to close
1942 a DSO Session based on an evaluation of both its own needs and the
1943 inactivity timeout value dictated by the server. A server only
1944 causes a DSO Session to be ended in the exceptional circumstances
1945 outlined below. Some of the exceptional situations in which a server
1946 may terminate a DSO Session include:
1947
1948 o The server application software or underlying operating system is
1949 shutting down or restarting.
1950
1951 o The server application software terminates unexpectedly (perhaps
1952 due to a bug that makes it crash, causing the underlying operating
1953 system to send a TCP RST).
1954
1955 o The server is undergoing a reconfiguration or maintenance
1956 procedure that, due to the way the server software is implemented,
1957 requires clients to be disconnected. For example, some software
1958 is implemented such that it reads a configuration file at startup,
1959 and changing the server's configuration entails modifying the
1960 configuration file and then killing and restarting the server
1961 software, which generally entails a loss of network connections.
1962
1963 o The client fails to meet its obligation to generate the required
1964 DSO keepalive traffic or to close an inactive session by the
1965 prescribed time (five seconds or twice the time interval dictated
1966 by the server, whichever is greater, as described in Section 6.2).
1967
1968 o The client sends a grossly invalid or malformed request that is
1969 indicative of a seriously defective client implementation.
1970
1971 o The server is over capacity and needs to shed some load.
1972
1973
1974
1975
1976
1977 Bellis, et al. Standards Track [Page 36]
1978 RFC 8490 DNS Stateful Operations March 2019
1979
1980
1981 6.6.1. Server-Initiated Retry Delay Message
1982
1983 In the cases described above where a server elects to terminate a DSO
1984 Session, it could do so simply by forcibly aborting the connection.
1985 However, if it did this, the likely behavior of the client might be
1986 simply to treat this as a network failure and reconnect immediately,
1987 putting more burden on the server.
1988
1989 Therefore, to avoid this reconnection implosion, a server SHOULD
1990 instead choose to shed client load by sending a Retry Delay message
1991 with an appropriate RCODE value informing the client of the reason
1992 the DSO Session needs to be terminated. The format of the DSO Retry
1993 Delay TLV and the interpretations of the various RCODE values are
1994 described in Section 7.2. After sending a DSO Retry Delay message,
1995 the server MUST NOT send any further messages on that DSO Session.
1996
1997 The server MAY randomize retry delays in situations where many retry
1998 delays are sent in quick succession so as to avoid all the clients
1999 attempting to reconnect at once. In general, implementations should
2000 avoid using the DSO Retry Delay message in a way that would result in
2001 many clients reconnecting at the same time if every client attempts
2002 to reconnect at the exact time specified.
2003
2004 Upon receipt of a DSO Retry Delay message from the server, the client
2005 MUST make note of the reconnect delay for this server and then
2006 immediately close the connection gracefully.
2007
2008 After sending a DSO Retry Delay message, the server SHOULD allow the
2009 client five seconds to close the connection, and if the client has
2010 not closed the connection after five seconds, then the server SHOULD
2011 forcibly abort the connection.
2012
2013 A DSO Retry Delay message MUST NOT be initiated by a client. If a
2014 server receives a DSO Retry Delay message, this is a fatal error and
2015 the server MUST forcibly abort the connection immediately.
2016
2017 6.6.1.1. Outstanding Operations
2018
2019 At the instant a server chooses to initiate a DSO Retry Delay
2020 message, there may be DNS requests already in flight from client to
2021 server on this DSO Session, which will arrive at the server after its
2022 DSO Retry Delay message has been sent. The server MUST silently
2023 ignore such incoming requests and MUST NOT generate any response
2024 messages for them. When the DSO Retry Delay message from the server
2025 arrives at the client, the client will determine that any DNS
2026 requests it previously sent on this DSO Session that have not yet
2027 received a response will now certainly not be receiving any response.
2028
2029
2030
2031
2032 Bellis, et al. Standards Track [Page 37]
2033 RFC 8490 DNS Stateful Operations March 2019
2034
2035
2036 Such requests should be considered failed and should be retried at a
2037 later time, as appropriate.
2038
2039 In the case where some, but not all, of the existing operations on a
2040 DSO Session have become invalid (perhaps because the server has been
2041 reconfigured and is no longer authoritative for some of the names),
2042 but the server is terminating all affected DSO Sessions en masse by
2043 sending them all a DSO Retry Delay message, the reconnect delay MAY
2044 be zero, indicating that the clients SHOULD immediately attempt to
2045 re-establish operations.
2046
2047 It is likely that some of the attempts will be successful and some
2048 will not, depending on the nature of the reconfiguration.
2049
2050 In the case where a server is terminating a large number of DSO
2051 Sessions at once (e.g., if the system is restarting) and the server
2052 doesn't want to be inundated with a flood of simultaneous retries, it
2053 SHOULD send different reconnect delay values to each client. These
2054 adjustments MAY be selected randomly, pseudorandomly, or
2055 deterministically (e.g., incrementing the time value by one tenth of
2056 a second for each successive client, yielding a post-restart
2057 reconnection rate of ten clients per second).
2058
2059 6.6.2. Misbehaving Clients
2060
2061 A server may determine that a client is not following the protocol
2062 correctly. There may be no way for the server to recover the DSO
2063 session, in which case the server forcibly terminates the connection.
2064 Since the client doesn't know why the connection dropped, it may
2065 reconnect immediately. If the server has determined that a client is
2066 not following the protocol correctly, it MAY terminate the DSO
2067 Session as soon as it is established, specifying a long retry-delay
2068 to prevent the client from immediately reconnecting.
2069
2070 6.6.3. Client Reconnection
2071
2072 After a DSO Session is ended by the server (either by sending the
2073 client a DSO Retry Delay message or by forcibly aborting the
2074 underlying transport connection), the client SHOULD try to reconnect
2075 to that service instance or to another suitable service instance if
2076 more than one is available. If reconnecting to the same service
2077 instance, the client MUST respect the indicated delay, if available,
2078 before attempting to reconnect. Clients SHOULD NOT attempt to
2079 randomize the delay; the server will randomly jitter the retry delay
2080 values it sends to each client if this behavior is desired.
2081
2082
2083
2084
2085
2086
2087 Bellis, et al. Standards Track [Page 38]
2088 RFC 8490 DNS Stateful Operations March 2019
2089
2090
2091 If a particular service instance will only be out of service for a
2092 short maintenance period, it should indicate a retry delay value that
2093 is a little longer than the expected maintenance window. It should
2094 not default to a very large delay value, or clients may not attempt
2095 to reconnect promptly after it resumes service.
2096
2097 If a service instance does not want a client to reconnect ever
2098 (perhaps the service instance is being decommissioned), it SHOULD set
2099 the retry delay to the maximum value 0xFFFFFFFF (2^32-1 milliseconds,
2100 approximately 49.7 days). It is not possible to instruct a client to
2101 stay away for longer than 49.7 days. If, after 49.7 days, the DNS or
2102 other configuration information still indicates that this is the
2103 valid service instance for a particular service, then clients MAY
2104 attempt to reconnect. In reality, if a client is rebooted or
2105 otherwise loses state, it may well attempt to reconnect before 49.7
2106 days elapse, for as long as the DNS or other configuration
2107 information continues to indicate that this is the service instance
2108 the client should use.
2109
2110 6.6.3.1. Reconnecting after a Forcible Abort
2111
2112 If a connection was forcibly aborted by the client due to
2113 noncompliant behavior by the server, the client SHOULD mark that
2114 service instance as not supporting DSO. The client MAY reconnect but
2115 not attempt to use DSO, or it may connect to a different service
2116 instance if applicable.
2117
2118 6.6.3.2. Reconnecting after an Unexplained Connection Drop
2119
2120 It is also possible for a server to forcibly terminate the
2121 connection; in this case, the client doesn't know whether the
2122 termination was the result of a protocol error or a network outage.
2123 When the client notices that the connection has been dropped, it can
2124 attempt to reconnect immediately. However, if the connection is
2125 dropped again without the client being able to successfully do
2126 whatever it is trying to do, it should mark the server as not
2127 supporting DSO.
2128
2129 6.6.3.3. Probing for Working DSO Support
2130
2131 Once a server has been marked by the client as not supporting DSO,
2132 the client SHOULD NOT attempt DSO operations on that server until
2133 some time has elapsed. A reasonable minimum would be an hour. Since
2134 forcibly aborted connections are the result of a software failure,
2135 it's not likely that the problem will be solved in the first hour
2136 after it's first encountered. However, by restricting the retry
2137 interval to an hour, the client will be able to notice when the
2138 problem has been fixed without placing an undue burden on the server.
2139
2140
2141
2142 Bellis, et al. Standards Track [Page 39]
2143 RFC 8490 DNS Stateful Operations March 2019
2144
2145
2146 7. Base TLVs for DNS Stateful Operations
2147
2148 This section describes the three base TLVs for DNS Stateful
2149 Operations: Keepalive, Retry Delay, and Encryption Padding.
2150
2151 7.1. Keepalive TLV
2152
2153 The Keepalive TLV (DSO-TYPE=1) performs two functions. Primarily, it
2154 establishes the values for the Session Timeouts. Incidentally, it
2155 also resets the keepalive timer for the DSO Session, meaning that it
2156 can be used as a kind of "no-op" message for the purpose of keeping a
2157 session alive. The client will request the desired Session Timeout
2158 values and the server will acknowledge with the response values that
2159 it requires the client to use.
2160
2161 DSO messages with the Keepalive TLV as the Primary TLV may appear in
2162 early data.
2163
2164 The DSO-DATA for the Keepalive TLV is as follows:
2165
2166 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
2167 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
2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2169 | INACTIVITY TIMEOUT (32 bits) |
2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2171 | KEEPALIVE INTERVAL (32 bits) |
2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2173
2174 INACTIVITY TIMEOUT: The inactivity timeout for the current DSO
2175 Session, specified as a 32-bit unsigned integer, in network (big
2176 endian) byte order in units of milliseconds. This is the timeout
2177 at which the client MUST begin closing an inactive DSO Session.
2178 The inactivity timeout can be any value of the server's choosing.
2179 If the client does not gracefully close an inactive DSO Session,
2180 then after five seconds or twice this interval, whichever is
2181 greater, the server will forcibly abort the connection.
2182
2183 KEEPALIVE INTERVAL: The keepalive interval for the current DSO
2184 Session, specified as a 32-bit unsigned integer, in network (big
2185 endian) byte order in units of milliseconds. This is the interval
2186 at which a client MUST generate DSO keepalive traffic to maintain
2187 connection state. The keepalive interval MUST NOT be less than
2188 ten seconds. If the client does not generate the mandated DSO
2189 keepalive traffic, then after twice this interval the server will
2190 forcibly abort the connection. Since the minimum allowed
2191 keepalive interval is ten seconds, the minimum time at which a
2192 server will forcibly disconnect a client for failing to generate
2193 the mandated DSO keepalive traffic is twenty seconds.
2194
2195
2196
2197 Bellis, et al. Standards Track [Page 40]
2198 RFC 8490 DNS Stateful Operations March 2019
2199
2200
2201 The transmission or reception of DSO Keepalive messages (i.e.,
2202 messages where the Keepalive TLV is the first TLV) reset only the
2203 keepalive timer, not the inactivity timer. The reason for this is
2204 that periodic DSO Keepalive messages are sent for the sole purpose of
2205 keeping a DSO Session alive when that DSO Session has current or
2206 recent non-maintenance activity that warrants keeping that DSO
2207 Session alive. Sending DSO keepalive traffic itself is not
2208 considered a client activity; it is considered a maintenance activity
2209 that is performed in service of other client activities. If DSO
2210 keepalive traffic itself were to reset the inactivity timer, then
2211 that would create a circular livelock where keepalive traffic would
2212 be sent indefinitely to keep a DSO Session alive. In this scenario,
2213 the only activity on that DSO Session would be the keepalive traffic
2214 keeping the DSO Session alive so that further keepalive traffic can
2215 be sent. For a DSO Session to be considered active, it must be
2216 carrying something more than just keepalive traffic. This is why
2217 merely sending or receiving a DSO Keepalive message does not reset
2218 the inactivity timer.
2219
2220 When sent by a client, the DSO Keepalive request message MUST be sent
2221 as a DSO request message with a nonzero MESSAGE ID. If a server
2222 receives a DSO Keepalive message with a zero MESSAGE ID, then this is
2223 a fatal error and the server MUST forcibly abort the connection
2224 immediately. The DSO Keepalive request message resets a DSO
2225 Session's keepalive timer and, at the same time, communicates to the
2226 server the client's requested Session Timeout values. In a server
2227 response to a client-initiated DSO Keepalive request message, the
2228 Session Timeouts contain the server's chosen values from this point
2229 forward in the DSO Session, which the client MUST respect. This is
2230 modeled after the DHCP protocol, where the client requests a certain
2231 lease lifetime using DHCP option 51 [RFC2132], but the server is the
2232 ultimate authority for deciding what lease lifetime is actually
2233 granted.
2234
2235 When a client is sending its second and subsequent DSO Keepalive
2236 request messages to the server, the client SHOULD continue to request
2237 its preferred values each time. This allows flexibility so that if
2238 conditions change during the lifetime of a DSO Session, the server
2239 can adapt its responses to better fit the client's needs.
2240
2241 Once a DSO Session is in progress (Section 5.1), a DSO Keepalive
2242 message MAY be initiated by a server. When sent by a server, the DSO
2243 Keepalive message MUST be sent as a DSO unidirectional message with
2244 the MESSAGE ID set to zero. The client MUST NOT generate a response
2245 to a server-initiated DSO Keepalive message. If a client receives a
2246 DSO Keepalive request message with a nonzero MESSAGE ID, then this is
2247 a fatal error and the client MUST forcibly abort the connection
2248 immediately. The DSO Keepalive unidirectional message from the
2249
2250
2251
2252 Bellis, et al. Standards Track [Page 41]
2253 RFC 8490 DNS Stateful Operations March 2019
2254
2255
2256 server resets a DSO Session's keepalive timer and, at the same time,
2257 unilaterally informs the client of the new Session Timeout values to
2258 use from this point forward in this DSO Session. No client DSO
2259 response to this unilateral declaration is required or allowed.
2260
2261 In DSO Keepalive response messages, exactly one instance of the
2262 Keepalive TLV MUST be present and is used only as a Response Primary
2263 TLV sent as a reply to a DSO Keepalive request message from the
2264 client. A Keepalive TLV MUST NOT be added to other responses as a
2265 Response Additional TLV. If the server wishes to update a client's
2266 Session Timeout values other than in response to a DSO Keepalive
2267 request message from the client, then it does so by sending a DSO
2268 Keepalive unidirectional message of its own, as described above.
2269
2270 It is not required that the Keepalive TLV be used in every DSO
2271 Session. While many DSO operations will be used in conjunction with
2272 a long-lived session state, not all DSO operations require a long-
2273 lived session state, and in some cases the default 15-second value
2274 for both the inactivity timeout and keepalive interval may be
2275 perfectly appropriate. However, note that for clients that implement
2276 only the DSO-TYPEs defined in this document, a DSO Keepalive request
2277 message is the only way for a client to initiate a DSO Session.
2278
2279 7.1.1. Client Handling of Received Session Timeout Values
2280
2281 When a client receives a response to its client-initiated DSO
2282 Keepalive request message, or receives a server-initiated DSO
2283 Keepalive unidirectional message, the client has then received
2284 Session Timeout values dictated by the server. The two timeout
2285 values contained in the Keepalive TLV from the server may each be
2286 higher, lower, or the same as the respective Session Timeout values
2287 the client previously had for this DSO Session.
2288
2289 In the case of the keepalive timer, the handling of the received
2290 value is straightforward. The act of receiving the message
2291 containing the DSO Keepalive TLV itself resets the keepalive timer
2292 and updates the keepalive interval for the DSO Session. The new
2293 keepalive interval indicates the maximum time that may elapse before
2294 another message must be sent or received on this DSO Session, if the
2295 DSO Session is to remain alive.
2296
2297 In the case of the inactivity timeout, the handling of the received
2298 value is a little more subtle, though the meaning of the inactivity
2299 timeout remains as specified; it still indicates the maximum
2300 permissible time allowed without useful activity on a DSO Session.
2301 The act of receiving the message containing the Keepalive TLV does
2302 not itself reset the inactivity timer. The time elapsed since the
2303 last useful activity on this DSO Session is unaffected by exchange of
2304
2305
2306
2307 Bellis, et al. Standards Track [Page 42]
2308 RFC 8490 DNS Stateful Operations March 2019
2309
2310
2311 DSO Keepalive messages. The new inactivity timeout value in the
2312 Keepalive TLV in the received message does update the timeout
2313 associated with the running inactivity timer; that becomes the new
2314 maximum permissible time without activity on a DSO Session.
2315
2316 o If the current inactivity timer value is less than the new
2317 inactivity timeout, then the DSO Session may remain open for now.
2318 When the inactivity timer value reaches the new inactivity
2319 timeout, the client MUST then begin closing the DSO Session as
2320 described above.
2321
2322 o If the current inactivity timer value is equal to the new
2323 inactivity timeout, then this DSO Session has been inactive for
2324 exactly as long as the server will permit, and now the client MUST
2325 immediately begin closing this DSO Session.
2326
2327 o If the current inactivity timer value is already greater than the
2328 new inactivity timeout, then this DSO Session has already been
2329 inactive for longer than the server permits, and the client MUST
2330 immediately begin closing this DSO Session.
2331
2332 o If the current inactivity timer value is already more than twice
2333 the new inactivity timeout, then the client is immediately
2334 considered delinquent (this DSO Session is immediately eligible to
2335 be forcibly terminated by the server) and the client MUST
2336 immediately begin closing this DSO Session. However, if a server
2337 abruptly reduces the inactivity timeout in this way, then, to give
2338 the client time to close the connection gracefully before the
2339 server resorts to forcibly aborting it, the server SHOULD give the
2340 client an additional grace period of either five seconds or one
2341 quarter of the new inactivity timeout, whichever is greater.
2342
2343 7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option
2344
2345 The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has
2346 similar intent to the edns-tcp-keepalive EDNS(0) Option [RFC7828]. A
2347 client/server pair that supports DSO MUST NOT use the edns-tcp-
2348 keepalive EDNS(0) Option within any message after a DSO Session has
2349 been established. A client that has sent a DSO message to establish
2350 a session MUST NOT send an edns-tcp-keepalive EDNS(0) Option from
2351 this point on. Once a DSO Session has been established, if either
2352 client or server receives a DNS message over the DSO Session that
2353 contains an edns-tcp-keepalive EDNS(0) Option, this is a fatal error
2354 and the receiver of the edns-tcp-keepalive EDNS(0) Option MUST
2355 forcibly abort the connection immediately.
2356
2357
2358
2359
2360
2361
2362 Bellis, et al. Standards Track [Page 43]
2363 RFC 8490 DNS Stateful Operations March 2019
2364
2365
2366 7.2. Retry Delay TLV
2367
2368 The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary TLV
2369 (unidirectional) in a server-to-client message, or as a Response
2370 Additional TLV in either direction. DSO messages with a Relay Delay
2371 TLV as their Primary TLV are not permitted in early data.
2372
2373 The DSO-DATA for the Retry Delay TLV is as follows:
2374
2375 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
2376 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
2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2378 | RETRY DELAY (32 bits) |
2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2380
2381 RETRY DELAY: A time value, specified as a 32-bit unsigned integer in
2382 network (big endian) byte order, in units of milliseconds, within
2383 which the initiator MUST NOT retry this operation or retry
2384 connecting to this server. Recommendations for the RETRY DELAY
2385 value are given in Section 6.6.1.
2386
2387 7.2.1. Retry Delay TLV Used as a Primary TLV
2388
2389 When used as the Primary TLV in a DSO unidirectional message, the
2390 Retry Delay TLV is sent from server to client. It is used by a
2391 server to instruct a client to close the DSO Session and underlying
2392 connection, and not to reconnect for the indicated time interval.
2393
2394 In this case, it applies to the DSO Session as a whole, and the
2395 client MUST begin closing the DSO Session as described in
2396 Section 6.6.1. The RCODE in the message header SHOULD indicate the
2397 principal reason for the termination:
2398
2399 o NOERROR indicates a routine shutdown or restart.
2400
2401 o FORMERR indicates that a client DSO request was too badly
2402 malformed for the session to continue.
2403
2404 o SERVFAIL indicates that the server is overloaded due to resource
2405 exhaustion and needs to shed load.
2406
2407 o REFUSED indicates that the server has been reconfigured, and at
2408 this time it is now unable to perform one or more of the long-
2409 lived client operations that were previously being performed on
2410 this DSO Session.
2411
2412
2413
2414
2415
2416
2417 Bellis, et al. Standards Track [Page 44]
2418 RFC 8490 DNS Stateful Operations March 2019
2419
2420
2421 o NOTAUTH indicates that the server has been reconfigured and at
2422 this time it is now unable to perform one or more of the long-
2423 lived client operations that were previously being performed on
2424 this DSO Session because it does not have authority over the names
2425 in question (for example, a DNS Push Notification server could be
2426 reconfigured such that it is no longer accepting DNS Push
2427 Notification requests for one or more of the currently subscribed
2428 names).
2429
2430 This document specifies only these RCODE values for the DSO Retry
2431 Delay message. Servers sending DSO Retry Delay messages SHOULD use
2432 one of these values. However, future circumstances may create
2433 situations where other RCODE values are appropriate in DSO Retry
2434 Delay messages, so clients MUST be prepared to accept DSO Retry Delay
2435 messages with any RCODE value.
2436
2437 In some cases, when a server sends a DSO Retry Delay unidirectional
2438 message to a client, there may be more than one reason for the server
2439 wanting to end the session. Possibly, the configuration could have
2440 been changed such that some long-lived client operations can no
2441 longer be continued due to policy (REFUSED), and other long-lived
2442 client operations can no longer be performed due to the server no
2443 longer being authoritative for those names (NOTAUTH). In such cases,
2444 the server MAY use any of the applicable RCODE values, or
2445 RCODE=NOERROR (routine shutdown or restart).
2446
2447 Note that the selection of RCODE value in a DSO Retry Delay message
2448 is not critical since the RCODE value is generally used only for
2449 information purposes such as writing to a log file for future human
2450 analysis regarding the nature of the disconnection. Generally,
2451 clients do not modify their behavior depending on the RCODE value.
2452 The RETRY DELAY in the message tells the client how long it should
2453 wait before attempting a new connection to this service instance.
2454
2455 For clients that do in some way modify their behavior depending on
2456 the RCODE value, they should treat unknown RCODE values the same as
2457 RCODE=NOERROR (routine shutdown or restart).
2458
2459 A DSO Retry Delay message (DSO message where the Primary TLV is Retry
2460 Delay) from server to client is a DSO unidirectional message; the
2461 MESSAGE ID MUST be set to zero in the outgoing message and the client
2462 MUST NOT send a response.
2463
2464 A client MUST NOT send a DSO Retry Delay message to a server. If a
2465 server receives a DSO message where the Primary TLV is the Retry
2466 Delay TLV, this is a fatal error and the server MUST forcibly abort
2467 the connection immediately.
2468
2469
2470
2471
2472 Bellis, et al. Standards Track [Page 45]
2473 RFC 8490 DNS Stateful Operations March 2019
2474
2475
2476 7.2.2. Retry Delay TLV Used as a Response Additional TLV
2477
2478 In the case of a DSO request message that results in a nonzero RCODE
2479 value, the responder MAY append a Retry Delay TLV to the response,
2480 indicating the time interval during which the initiator SHOULD NOT
2481 attempt this operation again.
2482
2483 The indicated time interval during which the initiator SHOULD NOT
2484 retry applies only to the failed operation, not to the DSO Session as
2485 a whole.
2486
2487 Either a client or a server, whichever is acting in the role of the
2488 responder for a particular DSO request message, MAY append a Retry
2489 Delay TLV to an error response that it sends.
2490
2491 7.3. Encryption Padding TLV
2492
2493 The Encryption Padding TLV (DSO-TYPE=3) can only be used as an
2494 Additional or Response Additional TLV. It is only applicable when
2495 the DSO Transport layer uses encryption such as TLS.
2496
2497 The DSO-DATA for the Padding TLV is optional and is a variable length
2498 field containing non-specified values. A DSO-LENGTH of 0 essentially
2499 provides for 4 bytes of padding (the minimum amount).
2500
2501 1 1 1 1 1 1
2502 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
2503 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2504 / /
2505 / PADDING -- VARIABLE NUMBER OF BYTES /
2506 / /
2507 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2508
2509 As specified for the EDNS(0) Padding Option [RFC7830], the PADDING
2510 bytes SHOULD be set to 0x00. Other values MAY be used, for example,
2511 in cases where there is a concern that the padded message could be
2512 subject to compression before encryption. PADDING bytes of any value
2513 MUST be accepted in the messages received.
2514
2515 The Encryption Padding TLV may be included in either a DSO request
2516 message, response, or both. As specified for the EDNS(0) Padding
2517 Option [RFC7830], if a DSO request message is received with an
2518 Encryption Padding TLV, then the DSO response MUST also include an
2519 Encryption Padding TLV.
2520
2521 The length of padding is intentionally not specified in this document
2522 and is a function of current best practices with respect to the type
2523 and length of data in the preceding TLVs [RFC8467].
2524
2525
2526
2527 Bellis, et al. Standards Track [Page 46]
2528 RFC 8490 DNS Stateful Operations March 2019
2529
2530
2531 8. Summary Highlights
2532
2533 This section summarizes some noteworthy highlights about various
2534 aspects of the DSO protocol.
2535
2536 8.1. QR Bit and MESSAGE ID
2537
2538 In DSO request messages, the QR bit is 0 and the MESSAGE ID is
2539 nonzero.
2540
2541 In DSO response messages, the QR bit is 1 and the MESSAGE ID is
2542 nonzero.
2543
2544 In DSO unidirectional messages, the QR bit is 0 and the MESSAGE ID is
2545 zero.
2546
2547 The table below illustrates which combinations are legal and how they
2548 are interpreted:
2549
2550 +------------------------------+------------------------+
2551 | MESSAGE ID zero | MESSAGE ID nonzero |
2552 +--------+------------------------------+------------------------+
2553 | QR=0 | DSO unidirectional message | DSO request message |
2554 +--------+------------------------------+------------------------+
2555 | QR=1 | Invalid - Fatal Error | DSO response message |
2556 +--------+------------------------------+------------------------+
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582 Bellis, et al. Standards Track [Page 47]
2583 RFC 8490 DNS Stateful Operations March 2019
2584
2585
2586 8.2. TLV Usage
2587
2588 The table below indicates, for each of the three TLVs defined in this
2589 document, whether they are valid in each of ten different contexts.
2590
2591 The first five contexts are DSO requests or DSO unidirectional
2592 messages from client to server, and the corresponding responses from
2593 server back to client:
2594
2595 o C-P - Primary TLV, sent in DSO request message, from client to
2596 server, with nonzero MESSAGE ID indicating that this request MUST
2597 generate response message.
2598
2599 o C-U - Primary TLV, sent in DSO unidirectional message, from client
2600 to server, with zero MESSAGE ID indicating that this request MUST
2601 NOT generate response message.
2602
2603 o C-A - Additional TLV, optionally added to a DSO request message or
2604 DSO unidirectional message from client to server.
2605
2606 o CRP - Response Primary TLV, included in response message sent back
2607 to the client (in response to a client "C-P" request with nonzero
2608 MESSAGE ID indicating that a response is required) where the DSO-
2609 TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV
2610 in the request.
2611
2612 o CRA - Response Additional TLV, included in response message sent
2613 back to the client (in response to a client "C-P" request with
2614 nonzero MESSAGE ID indicating that a response is required) where
2615 the DSO-TYPE of the Response TLV does not match the DSO-TYPE of
2616 the Primary TLV in the request.
2617
2618 The second five contexts are their counterparts in the opposite
2619 direction: DSO requests or DSO unidirectional messages from server to
2620 client, and the corresponding responses from client back to server.
2621
2622 o S-P - Primary TLV, sent in DSO request message, from server to
2623 client, with nonzero MESSAGE ID indicating that this request MUST
2624 generate response message.
2625
2626 o S-U - Primary TLV, sent in DSO unidirectional message, from server
2627 to client, with zero MESSAGE ID indicating that this request MUST
2628 NOT generate response message.
2629
2630 o S-A - Additional TLV, optionally added to a DSO request message or
2631 DSO unidirectional message from server to client.
2632
2633
2634
2635
2636
2637 Bellis, et al. Standards Track [Page 48]
2638 RFC 8490 DNS Stateful Operations March 2019
2639
2640
2641 o SRP - Response Primary TLV, included in response message sent back
2642 to the server (in response to a server "S-P" request with nonzero
2643 MESSAGE ID indicating that a response is required) where the DSO-
2644 TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV
2645 in the request.
2646
2647 o SRA - Response Additional TLV, included in response message sent
2648 back to the server (in response to a server "S-P" request with
2649 nonzero MESSAGE ID indicating that a response is required) where
2650 the DSO-TYPE of the Response TLV does not match the DSO-TYPE of
2651 the Primary TLV in the request.
2652
2653 +-------------------------+-------------------------+
2654 | C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA |
2655 +------------+-------------------------+-------------------------+
2656 | KeepAlive | X X | X |
2657 +------------+-------------------------+-------------------------+
2658 | RetryDelay | X | X X |
2659 +------------+-------------------------+-------------------------+
2660 | Padding | X X | X X |
2661 +------------+-------------------------+-------------------------+
2662
2663 Note that some of the columns in this table are currently empty. The
2664 table provides a template for future TLV definitions to follow. It
2665 is recommended that definitions of future TLVs include a similar
2666 table summarizing the contexts where the new TLV is valid.
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692 Bellis, et al. Standards Track [Page 49]
2693 RFC 8490 DNS Stateful Operations March 2019
2694
2695
2696 9. Additional Considerations
2697
2698 9.1. Service Instances
2699
2700 We use the term "service instance" to refer to software running on a
2701 host that can receive connections on some set of { IP address, port }
2702 tuples. What makes the software an instance is that regardless of
2703 which of these tuples the client uses to connect to it, the client is
2704 connected to the same software, running on the same logical node (see
2705 Section 9.2), and will receive the same answers and the same keying
2706 information.
2707
2708 Service instances are identified from the perspective of the client.
2709 If the client is configured with { IP address, port } tuples, it has
2710 no way to tell if the service offered at one tuple is the same server
2711 that is listening on a different tuple. So in this case, the client
2712 treats each different tuple as if it references a different service
2713 instance.
2714
2715 In some cases, a client is configured with a hostname and a port
2716 number. The port number may be given explicitly, along with the
2717 hostname. The port number may be omitted, and assumed to have some
2718 default value. The hostname and a port number may be learned from
2719 the network, as in the case of DNS SRV records. In these cases, the
2720 { hostname, port } tuple uniquely identifies the service instance,
2721 subject to the usual case-insensitive DNS comparison of names
2722 [RFC1034].
2723
2724 It is possible that two hostnames might point to some common IP
2725 addresses; this is a configuration anomaly that the client is not
2726 obliged to detect. The effect of this could be that after being told
2727 to disconnect, the client might reconnect to the same server because
2728 it is represented as a different service instance.
2729
2730 Implementations SHOULD NOT resolve hostnames and then perform the
2731 process of matching IP address(es) in order to evaluate whether two
2732 entities should be determined to be the "same service instance".
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747 Bellis, et al. Standards Track [Page 50]
2748 RFC 8490 DNS Stateful Operations March 2019
2749
2750
2751 9.2. Anycast Considerations
2752
2753 When an anycast service is configured on a particular IP address and
2754 port, it must be the case that although there is more than one
2755 physical server responding on that IP address, each such server can
2756 be treated as equivalent. What we mean by "equivalent" here is that
2757 both servers can provide the same service and, where appropriate, the
2758 same authentication information, such as PKI certificates, when
2759 establishing connections.
2760
2761 If a change in network topology causes packets in a particular TCP
2762 connection to be sent to an anycast server instance that does not
2763 know about the connection, the new server will automatically
2764 terminate the connection with a TCP reset, since it will have no
2765 record of the connection, and then the client can reconnect or stop
2766 using the connection as appropriate.
2767
2768 If, after the connection is re-established, the client's assumption
2769 that it is connected to the same instance is violated in some way,
2770 that would be considered an incorrect behavior in this context. It
2771 is, however, out of the possible scope for this specification to make
2772 specific recommendations in this regard; that would be up to follow-
2773 on documents that describe specific uses of DNS Stateful Operations.
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802 Bellis, et al. Standards Track [Page 51]
2803 RFC 8490 DNS Stateful Operations March 2019
2804
2805
2806 9.3. Connection Sharing
2807
2808 As previously specified for DNS-over-TCP [RFC7766]:
2809
2810 To mitigate the risk of unintentional server overload, DNS
2811 clients MUST take care to minimize the number of concurrent
2812 TCP connections made to any individual server. It is RECOMMENDED
2813 that for any given client/server interaction there SHOULD be
2814 no more than one connection for regular queries, one for zone
2815 transfers, and one for each protocol that is being used on top
2816 of TCP (for example, if the resolver was using TLS). However,
2817 it is noted that certain primary/secondary configurations
2818 with many busy zones might need to use more than one TCP
2819 connection for zone transfers for operational reasons (for
2820 example, to support concurrent transfers of multiple zones).
2821
2822 A single server may support multiple services, including DNS Updates
2823 [RFC2136], DNS Push Notifications [Push], and other services, for one
2824 or more DNS zones. When a client discovers that the target server
2825 for several different operations is the same service instance (see
2826 Section 9.1), the client SHOULD use a single shared DSO Session for
2827 all those operations.
2828
2829 This requirement has two benefits. First, it reduces unnecessary
2830 connection load on the DNS server. Second, it avoids the connection
2831 startup time that would be spent establishing each new additional
2832 connection to the same DNS server.
2833
2834 However, server implementers and operators should be aware that
2835 connection sharing may not be possible in all cases. A single host
2836 device may be home to multiple independent client software instances
2837 that don't coordinate with each other. Similarly, multiple
2838 independent client devices behind the same NAT gateway will also
2839 typically appear to the DNS server as different source ports on the
2840 same client IP address. Because of these constraints, a DNS server
2841 MUST be prepared to accept multiple connections from different source
2842 ports on the same client IP address.
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857 Bellis, et al. Standards Track [Page 52]
2858 RFC 8490 DNS Stateful Operations March 2019
2859
2860
2861 9.4. Operational Considerations for Middleboxes
2862
2863 Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
2864 or session multiplexer) is in the path, care must be taken to avoid a
2865 configuration in which DSO traffic is mishandled. The simplest way
2866 to avoid such problems is to avoid using middleboxes. When this is
2867 not possible, middleboxes should be evaluated to make sure that they
2868 behave correctly.
2869
2870 Correct behavior for middleboxes consists of one of the following:
2871
2872 o The middlebox does not forward DSO messages and responds to DSO
2873 messages with a response code other than NOERROR or DSOTYPENI.
2874
2875 o The middlebox acts as a DSO server and follows this specification
2876 in establishing connections.
2877
2878 o There is a 1:1 correspondence between incoming and outgoing
2879 connections such that when a connection is established to the
2880 middlebox, it is guaranteed that exactly one corresponding
2881 connection will be established from the middlebox to some DNS
2882 resolver, and all incoming messages will be forwarded without
2883 modification or reordering. An example of this would be a NAT
2884 forwarder or TCP connection optimizer (e.g., for a high-latency
2885 connection such as a geosynchronous satellite link).
2886
2887 Middleboxes that do not meet one of the above criteria are very
2888 likely to fail in unexpected and difficult-to-diagnose ways. For
2889 example, a DNS load balancer might unbundle DNS messages from the
2890 incoming TCP stream and forward each message from the stream to a
2891 different DNS server. If such a load balancer is in use, and the DNS
2892 servers it points to implement DSO and are configured to enable DSO,
2893 DSO Session establishment will succeed, but no coherent session will
2894 exist between the client and the server. If such a load balancer is
2895 pointed at a DNS server that does not implement DSO or is configured
2896 not to allow DSO, no such problem will exist, but such a
2897 configuration risks unexpected failure if new server software is
2898 installed that does implement DSO.
2899
2900 It is of course possible to implement a middlebox that properly
2901 supports DSO. It is even possible to implement one that implements
2902 DSO with long-lived operations. This can be done either by
2903 maintaining a 1:1 correspondence between incoming and outgoing
2904 connections, as mentioned above, or by terminating incoming sessions
2905 at the middlebox but maintaining state in the middlebox about any
2906 long-lived operations that are requested. Specifying this in detail
2907 is beyond the scope of this document.
2908
2909
2910
2911
2912 Bellis, et al. Standards Track [Page 53]
2913 RFC 8490 DNS Stateful Operations March 2019
2914
2915
2916 9.5. TCP Delayed Acknowledgement Considerations
2917
2918 Most modern implementations of the Transmission Control Protocol
2919 (TCP) include a feature called "Delayed Acknowledgement" [RFC1122].
2920
2921 Without this feature, TCP can be very wasteful on the network. For
2922 illustration, consider a simple example like remote login using a
2923 very simple TCP implementation that lacks delayed acks. When the
2924 user types a keystroke, a data packet is sent. When the data packet
2925 arrives at the server, the simple TCP implementation sends an
2926 immediate acknowledgement. Mere milliseconds later, the server
2927 process reads the one byte of keystroke data, and consequently the
2928 simple TCP implementation sends an immediate window update. Mere
2929 milliseconds later, the server process generates the character echo
2930 and sends this data back in reply. The simple TCP implementation
2931 then sends this data packet immediately too. In this case, this
2932 simple TCP implementation sends a burst of three packets almost
2933 instantaneously (ack, window update, data).
2934
2935 Clearly it would be more efficient if the TCP implementation were to
2936 combine the three separate packets into one, and this is what the
2937 delayed ack feature enables.
2938
2939 With delayed ack, the TCP implementation waits after receiving a data
2940 packet, typically for 200 ms, and then sends its ack if (a) more data
2941 packet(s) arrive, (b) the receiving process generates some reply
2942 data, or (c) 200 ms elapse without either of the above occurring.
2943
2944 With delayed ack, remote login becomes much more efficient,
2945 generating just one packet instead of three for each character echo.
2946
2947 The logic of delayed ack is that the 200 ms delay cannot do any
2948 significant harm. If something at the other end were waiting for
2949 something, then the receiving process should generate the reply that
2950 the thing at the other end is waiting for, and TCP will then
2951 immediately send that reply (combined with the ack and window
2952 update). And if the receiving process does not in fact generate any
2953 reply for this particular message, then by definition the thing at
2954 the other end cannot be waiting for anything. Therefore, the 200 ms
2955 delay is harmless.
2956
2957 This assumption may be true unless the sender is using Nagle's
2958 algorithm, a similar efficiency feature, created to protect the
2959 network from poorly written client software that performs many rapid
2960 small writes in succession. Nagle's algorithm allows these small
2961 writes to be coalesced into larger, less wasteful packets.
2962
2963
2964
2965
2966
2967 Bellis, et al. Standards Track [Page 54]
2968 RFC 8490 DNS Stateful Operations March 2019
2969
2970
2971 Unfortunately, Nagle's algorithm and delayed ack, two valuable
2972 efficiency features, can interact badly with each other when used
2973 together [NagleDA].
2974
2975 DSO request messages elicit responses; DSO unidirectional messages
2976 and DSO response messages do not.
2977
2978 For DSO request messages, which do elicit responses, Nagle's
2979 algorithm and delayed ack work as intended.
2980
2981 For DSO messages that do not elicit responses, the delayed ack
2982 mechanism causes the ack to be delayed by 200 ms. The 200 ms delay
2983 on the ack can in turn cause Nagle's algorithm to prevent the sender
2984 from sending any more data for 200 ms until the awaited ack arrives.
2985 On an enterprise Gigabit Ethernet (GigE) backbone with sub-
2986 millisecond round-trip times, a 200 ms delay is enormous in
2987 comparison.
2988
2989 When this issues is raised, there are two solutions that are often
2990 offered, neither of them ideal:
2991
2992 1. Disable delayed ack. For DSO messages that elicit no response,
2993 removing delayed ack avoids the needless 200 ms delay and sends
2994 back an immediate ack that tells Nagle's algorithm that it should
2995 immediately grant the sender permission to send its next packet.
2996 Unfortunately, for DSO messages that *do* elicit a response,
2997 removing delayed ack removes the efficiency gains of combining
2998 acks with data, and the responder will now send two or three
2999 packets instead of one.
3000
3001 2. Disable Nagle's algorithm. When acks are delayed by the delayed
3002 ack algorithm, removing Nagle's algorithm prevents the sender
3003 from being blocked from sending its next small packet
3004 immediately. Unfortunately, on a network with a higher round-
3005 trip time, removing Nagle's algorithm removes the efficiency
3006 gains of combining multiple small packets into fewer larger ones,
3007 with the goal of limiting the number of small packets in flight
3008 at any one time.
3009
3010 The problem here is that with DSO messages that elicit no response,
3011 the TCP implementation is stuck waiting, unsure if a response is
3012 about to be generated or whether the TCP implementation should go
3013 ahead and send an ack and window update.
3014
3015 The solution is networking APIs that allow the receiver to inform the
3016 TCP implementation that a received message has been read, processed,
3017 and no response for this message will be generated. TCP can then
3018
3019
3020
3021
3022 Bellis, et al. Standards Track [Page 55]
3023 RFC 8490 DNS Stateful Operations March 2019
3024
3025
3026 stop waiting for a response that will never come, and immediately go
3027 ahead and send an ack and window update.
3028
3029 For implementations of DSO, disabling delayed ack is NOT RECOMMENDED
3030 because of the harm this can do to the network.
3031
3032 For implementations of DSO, disabling Nagle's algorithm is NOT
3033 RECOMMENDED because of the harm this can do to the network.
3034
3035 At the time that this document is being prepared for publication, it
3036 is known that at least one TCP implementation provides the ability
3037 for the recipient of a TCP message to signal that it is not going to
3038 send a response, and hence the delayed ack mechanism can stop
3039 waiting. Implementations on operating systems where this feature is
3040 available SHOULD make use of it.
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077 Bellis, et al. Standards Track [Page 56]
3078 RFC 8490 DNS Stateful Operations March 2019
3079
3080
3081 10. IANA Considerations
3082
3083 10.1. DSO OPCODE Registration
3084
3085 The IANA has assigned the value 6 for DNS Stateful Operations (DSO)
3086 in the "DNS OpCodes" registry.
3087
3088 10.2. DSO RCODE Registration
3089
3090 IANA has assigned the value 11 for the DSOTYPENI error code in the
3091 "DNS RCODEs" registry. The DSOTYPENI error code ("DSO-TYPE Not
3092 Implemented") indicates that the receiver does implement DNS Stateful
3093 Operations, but does not implement the specific DSO-TYPE of the
3094 Primary TLV in the DSO request message.
3095
3096 10.3. DSO Type Code Registry
3097
3098 The IANA has created the 16-bit "DSO Type Codes" registry, with
3099 initial (hexadecimal) values as shown below:
3100
3101 +-----------+-----------------------+-------+-----------+-----------+
3102 | Type | Name | Early | Status | Reference |
3103 | | | Data | | |
3104 +-----------+-----------------------+-------+-----------+-----------+
3105 | 0000 | Reserved | NO | Standards | RFC 8490 |
3106 | | | | Track | |
3107 | | | | | |
3108 | 0001 | KeepAlive | OK | Standards | RFC 8490 |
3109 | | | | Track | |
3110 | | | | | |
3111 | 0002 | RetryDelay | NO | Standards | RFC 8490 |
3112 | | | | Track | |
3113 | | | | | |
3114 | 0003 | EncryptionPadding | NA | Standards | RFC 8490 |
3115 | | | | Track | |
3116 | | | | | |
3117 | 0004-003F | Unassigned, reserved | NO | | |
3118 | | for DSO session- | | | |
3119 | | management TLVs | | | |
3120 | | | | | |
3121 | 0040-F7FF | Unassigned | NO | | |
3122 | | | | | |
3123 | F800-FBFF | Experimental/local | NO | | |
3124 | | use | | | |
3125 | | | | | |
3126 | FC00-FFFF | Reserved for future | NO | | |
3127 | | expansion | | | |
3128 +-----------+-----------------------+-------+-----------+-----------+
3129
3130
3131
3132 Bellis, et al. Standards Track [Page 57]
3133 RFC 8490 DNS Stateful Operations March 2019
3134
3135
3136 The meanings of the fields are as follows:
3137
3138 Type: The 16-bit DSO type code.
3139
3140 Name: The human-readable name of the TLV.
3141
3142 Early Data: If OK, this TLV may be sent as early data in a TLS zero
3143 round-trip (Section 2.3 of the TLS 1.3 specification [RFC8446])
3144 initial handshake. If NA, the TLV may appear as an Additional TLV
3145 in a DSO message that is sent as early data.
3146
3147 Status: RFC status (e.g., "Standards Track") or "External" if not
3148 documented in an RFC.
3149
3150 Reference: A stable reference to the document in which this TLV is
3151 defined.
3152
3153 Note: DSO Type Code zero is reserved and is not currently intended
3154 for allocation.
3155
3156 Registrations of new DSO Type Codes in the "Reserved for DSO session-
3157 management" range 0004-003F and the "Reserved for future expansion"
3158 range FC00-FFFF require publication of an IETF Standards Action
3159 document [RFC8126].
3160
3161 Requests to register additional new DSO Type Codes in the
3162 "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert
3163 Review [RFC8126]. The expert review should validate that the
3164 requested type code is specified in a way that conforms to this
3165 specification, and that the intended use for the code would not be
3166 addressed with an experimental/local assignment.
3167
3168 DSO Type Codes in the "experimental/local" range F800-FBFF may be
3169 used as Experimental Use or Private Use values [RFC8126] and may be
3170 used freely for development purposes or for other purposes within a
3171 single site. No attempt is made to prevent multiple sites from using
3172 the same value in different (and incompatible) ways. There is no
3173 need for IANA to review such assignments (since IANA does not record
3174 them) and assignments are not generally useful for broad
3175 interoperability. It is the responsibility of the sites making use
3176 of "experimental/local" values to ensure that no conflicts occur
3177 within the intended scope of use.
3178
3179 Any document defining a new TLV that lists a value of "OK" in the
3180 Early Data column must include a threat analysis for the use of the
3181 TLV in the case of TLS zero round-trip. See Section 11.1 for
3182 details.
3183
3184
3185
3186
3187 Bellis, et al. Standards Track [Page 58]
3188 RFC 8490 DNS Stateful Operations March 2019
3189
3190
3191 11. Security Considerations
3192
3193 If this mechanism is to be used with DNS-over-TLS, then these
3194 messages are subject to the same constraints as any other DNS-over-
3195 TLS messages and MUST NOT be sent in the clear before the TLS session
3196 is established.
3197
3198 The data field of the "Encryption Padding" TLV could be used as a
3199 covert channel.
3200
3201 When designing new DSO TLVs, the potential for data in the TLV to be
3202 used as a tracking identifier should be taken into consideration and
3203 should be avoided when not required.
3204
3205 When used without TLS or similar cryptographic protection, a
3206 malicious entity may be able to inject a malicious unidirectional DSO
3207 Retry Delay message into the data stream, specifying an unreasonably
3208 large RETRY DELAY, causing a denial-of-service attack against the
3209 client.
3210
3211 The establishment of DSO Sessions has an impact on the number of open
3212 TCP connections on a DNS server. Additional resources may be used on
3213 the server as a result. However, because the server can limit the
3214 number of DSO Sessions established and can also close existing DSO
3215 Sessions as needed, denial of service or resource exhaustion should
3216 not be a concern.
3217
3218 11.1. TLS Zero Round-Trip Considerations
3219
3220 DSO permits zero round-trip operation using TCP Fast Open with
3221 TLS 1.3 [RFC8446] early data to reduce or eliminate round trips in
3222 session establishment. TCP Fast Open is only permitted in
3223 combination with TLS 1.3 early data. In the rest of this section, we
3224 refer to TLS 1.3 early data in a TLS zero round-trip initial
3225 handshake message, regardless of whether or not it is included in a
3226 TCP SYN packet with early data using the TCP Fast Open option, as
3227 "early data."
3228
3229 A DSO message may or may not be permitted to be sent as early data.
3230 The definition for each TLV that can be used as a Primary TLV is
3231 required to state whether or not that TLV is permitted as early data.
3232 Only response-requiring messages are ever permitted as early data,
3233 and only clients are permitted to send a DSO message as early data
3234 unless there is an implicit DSO session (see Section 5.1).
3235
3236
3237
3238
3239
3240
3241
3242 Bellis, et al. Standards Track [Page 59]
3243 RFC 8490 DNS Stateful Operations March 2019
3244
3245
3246 For DSO messages that are permitted as early data, a client MAY
3247 include one or more such messages as early data without having to
3248 wait for a DSO response to the first DSO request message to confirm
3249 successful establishment of a DSO Session.
3250
3251 However, unless there is an implicit DSO session, a client MUST NOT
3252 send DSO unidirectional messages until after a DSO Session has been
3253 mutually established.
3254
3255 Similarly, unless there is an implicit DSO session, a server MUST NOT
3256 send DSO request messages until it has received a response-requiring
3257 DSO request message from a client and transmitted a successful
3258 NOERROR response for that request.
3259
3260 Caution must be taken to ensure that DSO messages sent as early data
3261 are idempotent or are otherwise immune to any problems that could
3262 result from the inadvertent replay that can occur with zero round-
3263 trip operation.
3264
3265 It would be possible to add a TLV that requires the server to do some
3266 significant work and send that to the server as initial data in a TCP
3267 SYN packet. A flood of such packets could be used as a DoS attack on
3268 the server. None of the TLVs defined here have this property.
3269
3270 If a new TLV is specified that does have this property, that TLV must
3271 be specified as not permitted in zero round-trip messages. This
3272 prevents work from being done until a round-trip has occurred from
3273 the server to the client to verify that the source address of the
3274 packet is reachable.
3275
3276 Documents that define new TLVs must state whether each new TLV may be
3277 sent as early data. Such documents must include a threat analysis in
3278 the security considerations section for each TLV defined in the
3279 document that may be sent as early data. This threat analysis should
3280 be done based on the advice given in Sections 2.3, 8, and
3281 Appendix E.5 of the TLS 1.3 specification [RFC8446].
3282
3283 12. References
3284
3285 12.1. Normative References
3286
3287 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
3288 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
3289 <https://www.rfc-editor.org/info/rfc1034>.
3290
3291 [RFC1035] Mockapetris, P., "Domain names - implementation and
3292 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
3293 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
3294
3295
3296
3297 Bellis, et al. Standards Track [Page 60]
3298 RFC 8490 DNS Stateful Operations March 2019
3299
3300
3301 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
3302 and E. Lear, "Address Allocation for Private Internets",
3303 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
3304 <https://www.rfc-editor.org/info/rfc1918>.
3305
3306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3307 Requirement Levels", BCP 14, RFC 2119,
3308 DOI 10.17487/RFC2119, March 1997,
3309 <https://www.rfc-editor.org/info/rfc2119>.
3310
3311 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
3312 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
3313 RFC 2136, DOI 10.17487/RFC2136, April 1997,
3314 <https://www.rfc-editor.org/info/rfc2136>.
3315
3316 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
3317 for DNS (EDNS(0))", STD 75, RFC 6891,
3318 DOI 10.17487/RFC6891, April 2013,
3319 <https://www.rfc-editor.org/info/rfc6891>.
3320
3321 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
3322 D. Wessels, "DNS Transport over TCP - Implementation
3323 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
3324 <https://www.rfc-editor.org/info/rfc7766>.
3325
3326 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
3327 DOI 10.17487/RFC7830, May 2016,
3328 <https://www.rfc-editor.org/info/rfc7830>.
3329
3330 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
3331 Writing an IANA Considerations Section in RFCs", BCP 26,
3332 RFC 8126, DOI 10.17487/RFC8126, June 2017,
3333 <https://www.rfc-editor.org/info/rfc8126>.
3334
3335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
3336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
3337 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
3338
3339 12.2. Informative References
3340
3341 [Fail] Andrews, M. and R. Bellis, "A Common Operational Problem
3342 in DNS Servers - Failure To Communicate", Work in
3343 Progress, draft-ietf-dnsop-no-response-issue-13, February
3344 2019.
3345
3346
3347
3348
3349
3350
3351
3352 Bellis, et al. Standards Track [Page 61]
3353 RFC 8490 DNS Stateful Operations March 2019
3354
3355
3356 [NagleDA] Cheshire, S., "TCP Performance problems caused by
3357 interaction between Nagle's Algorithm and Delayed ACK",
3358 May 2005,
3359 <http://www.stuartcheshire.org/papers/nagledelayedack/>.
3360
3361 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
3362 Work in Progress, draft-ietf-dnssd-push-18, March 2019.
3363
3364 [Relay] Lemon, T. and S. Cheshire, "Multicast DNS Discovery
3365 Relay", Work in Progress, draft-ietf-dnssd-mdns-relay-02,
3366 March 2019.
3367
3368 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
3369 Communication Layers", STD 3, RFC 1122,
3370 DOI 10.17487/RFC1122, October 1989,
3371 <https://www.rfc-editor.org/info/rfc1122>.
3372
3373 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
3374 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
3375 <https://www.rfc-editor.org/info/rfc2132>.
3376
3377 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
3378 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
3379 RFC 5382, DOI 10.17487/RFC5382, October 2008,
3380 <https://www.rfc-editor.org/info/rfc5382>.
3381
3382 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
3383 DOI 10.17487/RFC6762, February 2013,
3384 <https://www.rfc-editor.org/info/rfc6762>.
3385
3386 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
3387 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
3388 <https://www.rfc-editor.org/info/rfc6763>.
3389
3390 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
3391 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
3392 <https://www.rfc-editor.org/info/rfc7413>.
3393
3394 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
3395 edns-tcp-keepalive EDNS0 Option", RFC 7828,
3396 DOI 10.17487/RFC7828, April 2016,
3397 <https://www.rfc-editor.org/info/rfc7828>.
3398
3399 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
3400 S., and K. Naito, "Updates to Network Address Translation
3401 (NAT) Behavioral Requirements", BCP 127, RFC 7857,
3402 DOI 10.17487/RFC7857, April 2016,
3403 <https://www.rfc-editor.org/info/rfc7857>.
3404
3405
3406
3407 Bellis, et al. Standards Track [Page 62]
3408 RFC 8490 DNS Stateful Operations March 2019
3409
3410
3411 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
3412 and P. Hoffman, "Specification for DNS over Transport
3413 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
3414 2016, <https://www.rfc-editor.org/info/rfc7858>.
3415
3416 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
3417 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
3418 <https://www.rfc-editor.org/info/rfc8446>.
3419
3420 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
3421 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
3422 October 2018, <https://www.rfc-editor.org/info/rfc8467>.
3423
3424 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
3425 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
3426 <https://www.rfc-editor.org/info/rfc8484>.
3427
3428 Acknowledgements
3429
3430 Thanks to Stephane Bortzmeyer, Tim Chown, Ralph Droms, Paul Hoffman,
3431 Jan Komissar, Edward Lewis, Allison Mankin, Rui Paulo, David
3432 Schinazi, Manju Shankar Rao, Bernie Volz, and Bob Harold for their
3433 helpful contributions to this document.
3434
3435 Authors' Addresses
3436
3437 Ray Bellis
3438 Internet Systems Consortium, Inc.
3439 950 Charter Street
3440 Redwood City, CA 94063
3441 United States of America
3442
3443 Phone: +1 (650) 423-1200
3444 Email: ray@isc.org
3445
3446
3447 Stuart Cheshire
3448 Apple Inc.
3449 One Apple Park Way
3450 Cupertino, CA 95014
3451 United States of America
3452
3453 Phone: +1 (408) 996-1010
3454 Email: cheshire@apple.com
3455
3456
3457
3458
3459
3460
3461
3462 Bellis, et al. Standards Track [Page 63]
3463 RFC 8490 DNS Stateful Operations March 2019
3464
3465
3466 John Dickinson
3467 Sinodun Internet Technologies
3468 Magadalen Centre
3469 Oxford Science Park
3470 Oxford OX4 4GA
3471 United Kingdom
3472
3473 Email: jad@sinodun.com
3474
3475
3476 Sara Dickinson
3477 Sinodun Internet Technologies
3478 Magadalen Centre
3479 Oxford Science Park
3480 Oxford OX4 4GA
3481 United Kingdom
3482
3483 Email: sara@sinodun.com
3484
3485
3486 Ted Lemon
3487 Nibbhaya Consulting
3488 P.O. Box 958
3489 Brattleboro, VT 05302-0958
3490 United States of America
3491
3492 Email: mellon@fugue.com
3493
3494
3495 Tom Pusateri
3496 Unaffiliated
3497 Raleigh, NC 27608
3498 United States of America
3499
3500 Phone: +1 (919) 867-1330
3501 Email: pusateri@bangj.com
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517 Bellis, et al. Standards Track [Page 64]
3518
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.