1 Internet Engineering Task Force (IETF) P. Wouters
2 Request for Comments: 7828 Red Hat
3 Category: Standards Track J. Abley
4 ISSN: 2070-1721 Dyn, Inc.
5 S. Dickinson
6 Sinodun
7 R. Bellis
8 ISC
9 April 2016
10
11
12 The edns-tcp-keepalive EDNS0 Option
13
14 Abstract
15
16 DNS messages between clients and servers may be received over either
17 UDP or TCP. UDP transport involves keeping less state on a busy
18 server, but can cause truncation and retries over TCP. Additionally,
19 UDP can be exploited for reflection attacks. Using TCP would reduce
20 retransmits and amplification. However, clients commonly use TCP
21 only for retries and servers typically use idle timeouts on the order
22 of seconds.
23
24 This document defines an EDNS0 option ("edns-tcp-keepalive") that
25 allows DNS servers to signal a variable idle timeout. This
26 signalling encourages the use of long-lived TCP connections by
27 allowing the state associated with TCP transport to be managed
28 effectively with minimal impact on the DNS transaction time.
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 5741.
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 http://www.rfc-editor.org/info/rfc7828.
43
44
45
46
47
48
49
50
51
52 Wouters, et al. Standards Track [Page 1]
53 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
54
55
56 Copyright Notice
57
58 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
75 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5
76 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
77 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
78 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
79 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6
80 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6
81 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6
82 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
83 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
84 3.5. Non-clean Paths . . . . . . . . . . . . . . . . . . . . . 8
85 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
86 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
90 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
91 7.2. Informative References . . . . . . . . . . . . . . . . . 10
92 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Wouters, et al. Standards Track [Page 2]
108 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
109
110
111 1. Introduction
112
113 DNS messages between clients and servers may be received over either
114 UDP or TCP [RFC1035]. Historically, DNS clients used APIs that only
115 facilitated sending and receiving a single query over either UDP or
116 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts
117 that in the past were using stub resolving only is increasing the DNS
118 client base that prefer using long-lived TCP connections. Long-lived
119 TCP connections can result in lower request latency than the case
120 where UDP transport is used and truncated responses are received.
121 This is because clients that retry over TCP following a truncated UDP
122 response typically only use the TCP session for a single (request,
123 response) pair, continuing with UDP transport for subsequent queries.
124
125 The use of TCP transport requires state to be retained on DNS
126 servers. If a server is to perform adequately with a significant
127 query load received over TCP, it must manage its available resources
128 to ensure that all established TCP sessions are well-used, and idle
129 connections are closed after an appropriate amount of time.
130
131 UDP transport is stateless, and hence presents a much lower resource
132 burden on a busy DNS server than TCP. An exchange of DNS messages
133 over UDP can also be completed in a single round trip between
134 communicating hosts, resulting in optimally short transaction times.
135 UDP transport is not without its risks, however.
136
137 A single-datagram exchange over UDP between two hosts can be
138 exploited to enable a reflection attack on a third party. Response
139 Rate Limiting [RRL] is designed to help mitigate such attacks against
140 authoritative-only servers. One feature of RRL is to let some amount
141 of responses "slip" through the rate limiter. These are returned
142 with the TC (truncation) bit set, which causes legitimate clients to
143 resend the same query using TCP transport.
144
145 [RFC1035] specified a maximum DNS message size over UDP transport of
146 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols
147 subsequently increased the observed frequency at which responses
148 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than
149 512 bytes to be exchanged over UDP, with a corresponding increased
150 incidence of fragmentation. Fragmentation is known to be problematic
151 in general, and has also been implicated in increasing the risk of
152 cache poisoning attacks [fragmentation-considered-poisonous].
153
154 TCP transport is less susceptible to the risks of fragmentation and
155 reflection attacks. However, TCP transport for DNS as currently
156 deployed has expensive setup overhead, compared to using UDP (when no
157 retry is required).
158
159
160
161
162 Wouters, et al. Standards Track [Page 3]
163 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
164
165
166 The overhead of the three-way TCP handshake for a single DNS
167 transaction is substantial, increasing the transaction time for a
168 single (request, response) pair of DNS messages from 1x RTT to 2x
169 RTT. There is no such overhead for a session that is already
170 established; therefore, the overhead of the initial TCP handshake is
171 minimised when the resulting session is used to exchange multiple DNS
172 message pairs over a single session. The extra RTT time for session
173 setup can be represented as the equation (1 + N)/N, where N
174 represents the number of DNS message pairs that utilize the session
175 and the result approaches unity as N increases.
176
177 With increased deployment of DNSSEC and new RR types containing
178 application-specific cryptographic material, there is an increase in
179 the prevalence of truncated responses received over UDP with retries
180 over TCP. The overhead for a DNS transaction over UDP truncated due
181 to RRL is 3x RTT higher than the overhead imposed on the same
182 transaction initiated over TCP.
183
184 This document proposes a signalling mechanism between DNS clients and
185 servers that encourages the use of long-lived TCP connections by
186 allowing the state associated with TCP transport to be managed
187 effectively with minimal impact on the DNS transaction time.
188
189 This mechanism will be of benefit for both stub-resolver and
190 resolver-authoritative TCP connections. In the latter case, the
191 persistent nature of the TCP connection can provide improved defence
192 against attacks including DDoS.
193
194 The reduced overhead of this extension adds up significantly when
195 combined with other EDNS0 extensions, such as [CHAIN-QUERY] and
196 [DNS-over-TLS]. For example, the combination of these EDNS0
197 extensions make it possible for hosts on high-latency mobile networks
198 to natively and efficiently perform DNSSEC validation and encrypt
199 queries.
200
201 2. Requirements Notation
202
203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
205 document are to be interpreted as described in [RFC2119].
206
207
208
209
210
211
212
213
214
215
216
217 Wouters, et al. Standards Track [Page 4]
218 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
219
220
221 3. The edns-tcp-keepalive Option
222
223 This document specifies a new EDNS0 [RFC6891] option, edns-tcp-
224 keepalive, which can be used by DNS clients and servers to signal a
225 willingness to keep an idle TCP session open to conduct future DNS
226 transactions, with the idle timeout being specified by the server.
227 This specification does not distinguish between different types of
228 DNS client and server in the use of this option.
229
230 [RFC7766] defines an 'idle DNS-over-TCP session' from both the client
231 and server perspective. The idle timeout described here begins when
232 the idle condition is met per that definition and should be reset
233 when that condition is lifted, i.e., when a client sends a message or
234 when a server receives a message on an idle connection.
235
236 3.1. Option Format
237
238 The edns-tcp-keepalive option is encoded as follows:
239
240 1 2 3
241 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
242 +-------------------------------+-------------------------------+
243 ! OPTION-CODE ! OPTION-LENGTH !
244 +-------------------------------+-------------------------------+
245 | TIMEOUT !
246 +-------------------------------+
247
248 where:
249
250 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive,
251 11
252
253 OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2
254 if it is present;
255
256 TIMEOUT: an idle timeout value for the TCP connection, specified in
257 units of 100 milliseconds, encoded in network byte order.
258
259 3.2. Use by DNS Clients
260
261 3.2.1. Sending Queries
262
263 DNS clients MUST NOT include the edns-tcp-keepalive option in queries
264 sent using UDP transport.
265
266 DNS clients MAY include the edns-tcp-keepalive option in the first
267 query sent to a server using TCP transport to signal their desire to
268 keep the connection open when idle.
269
270
271
272 Wouters, et al. Standards Track [Page 5]
273 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
274
275
276 DNS clients MAY include the edns-tcp-keepalive option in subsequent
277 queries sent to a server using TCP transport to signal their
278 continued desire to keep the connection open when idle.
279
280 Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT
281 value.
282
283 3.2.2. Receiving Responses
284
285 A DNS client that receives a response using UDP transport that
286 includes the edns-tcp-keepalive option MUST ignore the option.
287
288 A DNS client that receives a response using TCP transport that
289 includes the edns-tcp-keepalive option MAY keep the existing TCP
290 session open when it is idle. It SHOULD honour the timeout received
291 in that response (overriding any previous timeout) and initiate close
292 of the connection before the timeout expires.
293
294 A DNS client that receives a response that includes the edns-tcp-
295 keepalive option with a TIMEOUT value of 0 SHOULD send no more
296 queries on that connection and initiate closing the connection as
297 soon as it has received all outstanding responses.
298
299 A DNS client that sent a query containing the edns-keepalive-option
300 but receives a response that does not contain the edns-keepalive-
301 option SHOULD assume the server does not support keepalive and behave
302 following the guidance in [RFC7766]. This holds true even if a
303 previous edns-keepalive-option exchange occurred on the existing TCP
304 connection.
305
306 3.3. Use by DNS Servers
307
308 3.3.1. Receiving Queries
309
310 A DNS server that receives a query using UDP transport that includes
311 the edns-tcp-keepalive option MUST ignore the option.
312
313 A DNS server that receives a query using TCP transport that includes
314 the edns-tcp-keepalive option MAY modify the local idle timeout
315 associated with that TCP session if resources permit.
316
317 3.3.2. Sending Responses
318
319 A DNS server that receives a query sent using TCP transport that
320 includes an OPT RR (with or without the edns-tcp-keepalive option)
321 MAY include the edns-tcp-keepalive option in the response to signal
322 the expected idle timeout on a connection. Servers MUST specify the
323 TIMEOUT value that is currently associated with the TCP session. It
324
325
326
327 Wouters, et al. Standards Track [Page 6]
328 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
329
330
331 is reasonable for this value to change according to local resource
332 constraints. The DNS server SHOULD send an edns-tcp-keepalive option
333 with a timeout of 0 if it deems its local resources are too low to
334 service more TCP keepalive sessions or if it wants clients to close
335 currently open connections.
336
337 3.4. TCP Session Management
338
339 Both DNS clients and servers are subject to resource constraints that
340 will limit the extent to which TCP sessions can persist. Effective
341 limits for the number of active sessions that can be maintained on
342 individual clients and servers should be established, either as
343 configuration options or by interrogation of process limits imposed
344 by the operating system. Servers that implement edns-tcp-keepalive
345 should also engage in TCP connection management by recycling existing
346 connections when appropriate, closing connections gracefully, and
347 managing request queues to enable fair use.
348
349 In the event that there is greater demand for TCP sessions than can
350 be accommodated, servers may reduce the TIMEOUT value signalled in
351 successive DNS messages to minimise idle time on existing sessions.
352 This also allows, for example, clients with other candidate servers
353 to query to establish new TCP sessions with different servers in
354 expectation that an existing session is likely to be closed or to
355 fall back to UDP.
356
357 Based on TCP session resources, servers may signal a TIMEOUT value of
358 0 to request clients to close connections as soon as possible. This
359 is useful when server resources become very low or a denial-of-
360 service attack is detected and further maximises the shifting of
361 TIME_WAIT state to well-behaved clients.
362
363 However, it should be noted that RFC 6891 states:
364
365 Lack of presence of an OPT record in a request MUST be taken as an
366 indication that the requestor does not implement any part of this
367 specification and that the responder MUST NOT include an OPT
368 record in its response.
369
370 Since servers must be faithful to this specification even on a
371 persistent TCP connection, it means that (following the initial
372 exchange of timeouts) a server may not be presented with the
373 opportunity to signal a change in the idle timeout associated with a
374 connection if the client does not send any further requests
375 containing EDNS0 OPT RRs. This limitation makes persistent
376 connection handling via an initial idle timeout signal more
377
378
379
380
381
382 Wouters, et al. Standards Track [Page 7]
383 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
384
385
386 attractive than a mechanism that establishes default persistence and
387 then uses a connection close signal (in a similar manner to HTTP 1.1
388 [RFC7230]).
389
390 If a client includes the edns-tcp-keepalive option in the first
391 query, it SHOULD include an EDNS0 OPT RR periodically in any further
392 messages it sends during the TCP session. This will increase the
393 chance of the client being notified should the server modify the
394 timeout associated with a session. The algorithm for choosing when
395 to do this is out of scope of this document and is left up to the
396 implementor and/or operator.
397
398 DNS clients and servers MAY close a TCP session at any time in order
399 to manage local resource constraints. The algorithm by which clients
400 and servers rank active TCP sessions in order to determine which to
401 close is not specified in this document.
402
403 3.5. Non-clean Paths
404
405 Many paths between DNS clients and servers suffer from poor hygiene,
406 limiting the free flow of DNS messages that include particular EDNS0
407 options or messages that exceed a particular size. A fallback
408 strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD
409 be employed to avoid persistent interference due to non-clean paths.
410
411 3.6. Anycast Considerations
412
413 DNS servers of various types are commonly deployed using anycast
414 [RFC4786].
415
416 Changes in network topology between clients and anycast servers may
417 cause disruption to TCP sessions making use of edns-tcp-keepalive
418 more often than with TCP sessions that omit it, since the TCP
419 sessions are expected to be longer lived. It might be possible for
420 anycast servers to avoid disruption due to topology changes by making
421 use of TCP multipath [RFC6824] to anchor the server side of the TCP
422 connection to an unambiguously unicast address.
423
424 4. Intermediary Considerations
425
426 It is RECOMMENDED that DNS intermediaries that terminate TCP
427 connections implement edns-tcp-keepalive. An intermediary that does
428 not implement edns-tcp-keepalive but sits between a client and server
429 that both support edns-tcp-keepalive might close idle connections
430 unnecessarily.
431
432
433
434
435
436
437 Wouters, et al. Standards Track [Page 8]
438 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
439
440
441 5. Security Considerations
442
443 The edns-tcp-keepalive option can potentially be abused to request
444 large numbers of long-lived sessions in a quick burst. When a DNS
445 server detects abusive behaviour, it SHOULD immediately close the TCP
446 connection and free the resources used.
447
448 Servers could choose to monitor client behaviour with respect to the
449 edns-tcp-keepalive option to build up profiles of clients that do not
450 honour the specified timeout.
451
452 Readers are advised to familiarise themselves with the security
453 considerations outlined in [RFC7766]
454
455 6. IANA Considerations
456
457 IANA has assigned an EDNS0 option code for the edns-tcp-keepalive
458 option from the "DNS EDNS0 Option Codes (OPT)" registry as follows:
459
460 +-------+--------------------+----------+-----------+
461 | Value | Name | Status | Reference |
462 +-------+--------------------+----------+-----------+
463 | 11 | edns-tcp-keepalive | Standard | RFC 7828 |
464 +-------+--------------------+----------+-----------+
465
466 7. References
467
468 7.1. Normative References
469
470 [RFC1035] Mockapetris, P., "Domain names - implementation and
471 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
472 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
473
474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
475 Requirement Levels", BCP 14, RFC 2119,
476 DOI 10.17487/RFC2119, March 1997,
477 <http://www.rfc-editor.org/info/rfc2119>.
478
479 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
480 Rose, "DNS Security Introduction and Requirements",
481 RFC 4033, DOI 10.17487/RFC4033, March 2005,
482 <http://www.rfc-editor.org/info/rfc4033>.
483
484 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
485 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
486 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
487
488
489
490
491
492 Wouters, et al. Standards Track [Page 9]
493 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
494
495
496 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
497 for DNS (EDNS(0))", STD 75, RFC 6891,
498 DOI 10.17487/RFC6891, April 2013,
499 <http://www.rfc-editor.org/info/rfc6891>.
500
501 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
502 Protocol (HTTP/1.1): Message Syntax and Routing",
503 RFC 7230, DOI 10.17487/RFC7230, June 2014,
504 <http://www.rfc-editor.org/info/rfc7230>.
505
506 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
507 D. Wessels, "DNS Transport over TCP - Implementation
508 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
509 <http://www.rfc-editor.org/info/rfc7766>.
510
511 7.2. Informative References
512
513 [CHAIN-QUERY]
514 Wouters, P., "Chain Query requests in DNS", Work in
515 Progress, draft-ietf-dnsop-edns-chain-query-07, February
516 2016.
517
518 [DNS-over-TLS]
519 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
520 and P. Hoffman, "Specification for DNS over TLS", Work in
521 Progress, draft-ietf-dprive-dns-over-tls-09, March 2016.
522
523 [fragmentation-considered-poisonous]
524 Herzberg, A. and H. Shulman, "Fragmentation Considered
525 Poisonous", arXiv: 1205.4011, May 2012,
526 <http://arxiv.org/abs/1205.4011>.
527
528 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
529 "TCP Extensions for Multipath Operation with Multiple
530 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
531 <http://www.rfc-editor.org/info/rfc6824>.
532
533 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
534 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
535 <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
536
537
538
539
540
541
542
543
544
545
546
547 Wouters, et al. Standards Track [Page 10]
548 RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
549
550
551 Acknowledgements
552
553 The authors acknowledge the contributions of Jinmei TATUYA and Mark
554 Andrews. Thanks to Duane Wessels for detailed review and the many
555 others who contributed to the mailing list discussion.
556
557 Authors' Addresses
558
559 Paul Wouters
560 Red Hat
561
562 Email: pwouters@redhat.com
563
564
565 Joe Abley
566 Dyn, Inc.
567 103-186 Albert Street
568 London, ON N6A 1M1
569 Canada
570
571 Phone: +1 519 670 9327
572 Email: jabley@dyn.com
573
574
575 Sara Dickinson
576 Sinodun Internet Technologies
577 Magdalen Centre
578 Oxford Science Park
579 Oxford OX4 4GA
580 United Kingdom
581
582 Email: sara@sinodun.com
583 URI: http://sinodun.com
584
585
586 Ray Bellis
587 Internet Systems Consortium, Inc
588 950 Charter Street
589 Redwood City, CA 94063
590 United States
591
592 Phone: +1 650 423 1200
593 Email: ray@isc.org
594 URI: http://www.isc.org
595
596
597
598
599
600
601
602 Wouters, et al. Standards Track [Page 11]
603
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.
This RFC is implemented in BIND 9.18 (all versions).