7Internet Engineering Task Force (IETF) P. Wouters
8Request for Comments: 7828 Red Hat
9Category: Standards Track J. Abley
10ISSN: 2070-1721 Dyn, Inc.
18 The edns-tcp-keepalive EDNS0 Option
22 DNS messages between clients and servers may be received over either
23 UDP or TCP. UDP transport involves keeping less state on a busy
24 server, but can cause truncation and retries over TCP. Additionally,
25 UDP can be exploited for reflection attacks. Using TCP would reduce
26 retransmits and amplification. However, clients commonly use TCP
27 only for retries and servers typically use idle timeouts on the order
30 This document defines an EDNS0 option ("edns-tcp-keepalive") that
31 allows DNS servers to signal a variable idle timeout. This
32 signalling encourages the use of long-lived TCP connections by
33 allowing the state associated with TCP transport to be managed
34 effectively with minimal impact on the DNS transaction time.
38 This is an Internet Standards Track document.
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Further information on
44 Internet Standards is available in Section 2 of RFC 5741.
46 Information about the current status of this document, any errata,
47 and how to provide feedback on it may be obtained at
48 http://www.rfc-editor.org/info/rfc7828.
58Wouters, et al. Standards Track [Page 1]
60RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
65 Copyright (c) 2016 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
81 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
82 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5
83 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
84 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
85 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
86 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6
87 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6
88 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6
89 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
90 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
91 3.5. Non-clean Paths . . . . . . . . . . . . . . . . . . . . . 8
92 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
93 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
97 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
98 7.2. Informative References . . . . . . . . . . . . . . . . . 10
99 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
114Wouters, et al. Standards Track [Page 2]
116RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
121 DNS messages between clients and servers may be received over either
122 UDP or TCP [RFC1035]. Historically, DNS clients used APIs that only
123 facilitated sending and receiving a single query over either UDP or
124 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts
125 that in the past were using stub resolving only is increasing the DNS
126 client base that prefer using long-lived TCP connections. Long-lived
127 TCP connections can result in lower request latency than the case
128 where UDP transport is used and truncated responses are received.
129 This is because clients that retry over TCP following a truncated UDP
130 response typically only use the TCP session for a single (request,
131 response) pair, continuing with UDP transport for subsequent queries.
133 The use of TCP transport requires state to be retained on DNS
134 servers. If a server is to perform adequately with a significant
135 query load received over TCP, it must manage its available resources
136 to ensure that all established TCP sessions are well-used, and idle
137 connections are closed after an appropriate amount of time.
139 UDP transport is stateless, and hence presents a much lower resource
140 burden on a busy DNS server than TCP. An exchange of DNS messages
141 over UDP can also be completed in a single round trip between
142 communicating hosts, resulting in optimally short transaction times.
143 UDP transport is not without its risks, however.
145 A single-datagram exchange over UDP between two hosts can be
146 exploited to enable a reflection attack on a third party. Response
147 Rate Limiting [RRL] is designed to help mitigate such attacks against
148 authoritative-only servers. One feature of RRL is to let some amount
149 of responses "slip" through the rate limiter. These are returned
150 with the TC (truncation) bit set, which causes legitimate clients to
151 resend the same query using TCP transport.
153 [RFC1035] specified a maximum DNS message size over UDP transport of
154 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols
155 subsequently increased the observed frequency at which responses
156 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than
157 512 bytes to be exchanged over UDP, with a corresponding increased
158 incidence of fragmentation. Fragmentation is known to be problematic
159 in general, and has also been implicated in increasing the risk of
160 cache poisoning attacks [fragmentation-considered-poisonous].
162 TCP transport is less susceptible to the risks of fragmentation and
163 reflection attacks. However, TCP transport for DNS as currently
164 deployed has expensive setup overhead, compared to using UDP (when no
170Wouters, et al. Standards Track [Page 3]
172RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
175 The overhead of the three-way TCP handshake for a single DNS
176 transaction is substantial, increasing the transaction time for a
177 single (request, response) pair of DNS messages from 1x RTT to 2x
178 RTT. There is no such overhead for a session that is already
179 established; therefore, the overhead of the initial TCP handshake is
180 minimised when the resulting session is used to exchange multiple DNS
181 message pairs over a single session. The extra RTT time for session
182 setup can be represented as the equation (1 + N)/N, where N
183 represents the number of DNS message pairs that utilize the session
184 and the result approaches unity as N increases.
186 With increased deployment of DNSSEC and new RR types containing
187 application-specific cryptographic material, there is an increase in
188 the prevalence of truncated responses received over UDP with retries
189 over TCP. The overhead for a DNS transaction over UDP truncated due
190 to RRL is 3x RTT higher than the overhead imposed on the same
191 transaction initiated over TCP.
193 This document proposes a signalling mechanism between DNS clients and
194 servers that encourages the use of long-lived TCP connections by
195 allowing the state associated with TCP transport to be managed
196 effectively with minimal impact on the DNS transaction time.
198 This mechanism will be of benefit for both stub-resolver and
199 resolver-authoritative TCP connections. In the latter case, the
200 persistent nature of the TCP connection can provide improved defence
201 against attacks including DDoS.
203 The reduced overhead of this extension adds up significantly when
204 combined with other EDNS0 extensions, such as [CHAIN-QUERY] and
205 [DNS-over-TLS]. For example, the combination of these EDNS0
206 extensions make it possible for hosts on high-latency mobile networks
207 to natively and efficiently perform DNSSEC validation and encrypt
2102. Requirements Notation
212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
214 document are to be interpreted as described in [RFC2119].
226Wouters, et al. Standards Track [Page 4]
228RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
2313. The edns-tcp-keepalive Option
233 This document specifies a new EDNS0 [RFC6891] option, edns-tcp-
234 keepalive, which can be used by DNS clients and servers to signal a
235 willingness to keep an idle TCP session open to conduct future DNS
236 transactions, with the idle timeout being specified by the server.
237 This specification does not distinguish between different types of
238 DNS client and server in the use of this option.
240 [RFC7766] defines an 'idle DNS-over-TCP session' from both the client
241 and server perspective. The idle timeout described here begins when
242 the idle condition is met per that definition and should be reset
243 when that condition is lifted, i.e., when a client sends a message or
244 when a server receives a message on an idle connection.
248 The edns-tcp-keepalive option is encoded as follows:
251 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
252 +-------------------------------+-------------------------------+
253 ! OPTION-CODE ! OPTION-LENGTH !
254 +-------------------------------+-------------------------------+
256 +-------------------------------+
260 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive,
263 OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2
266 TIMEOUT: an idle timeout value for the TCP connection, specified in
267 units of 100 milliseconds, encoded in network byte order.
2693.2. Use by DNS Clients
2713.2.1. Sending Queries
273 DNS clients MUST NOT include the edns-tcp-keepalive option in queries
274 sent using UDP transport.
276 DNS clients MAY include the edns-tcp-keepalive option in the first
277 query sent to a server using TCP transport to signal their desire to
278 keep the connection open when idle.
282Wouters, et al. Standards Track [Page 5]
284RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
287 DNS clients MAY include the edns-tcp-keepalive option in subsequent
288 queries sent to a server using TCP transport to signal their
289 continued desire to keep the connection open when idle.
291 Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT
2943.2.2. Receiving Responses
296 A DNS client that receives a response using UDP transport that
297 includes the edns-tcp-keepalive option MUST ignore the option.
299 A DNS client that receives a response using TCP transport that
300 includes the edns-tcp-keepalive option MAY keep the existing TCP
301 session open when it is idle. It SHOULD honour the timeout received
302 in that response (overriding any previous timeout) and initiate close
303 of the connection before the timeout expires.
305 A DNS client that receives a response that includes the edns-tcp-
306 keepalive option with a TIMEOUT value of 0 SHOULD send no more
307 queries on that connection and initiate closing the connection as
308 soon as it has received all outstanding responses.
310 A DNS client that sent a query containing the edns-keepalive-option
311 but receives a response that does not contain the edns-keepalive-
312 option SHOULD assume the server does not support keepalive and behave
313 following the guidance in [RFC7766]. This holds true even if a
314 previous edns-keepalive-option exchange occurred on the existing TCP
3173.3. Use by DNS Servers
3193.3.1. Receiving Queries
321 A DNS server that receives a query using UDP transport that includes
322 the edns-tcp-keepalive option MUST ignore the option.
324 A DNS server that receives a query using TCP transport that includes
325 the edns-tcp-keepalive option MAY modify the local idle timeout
326 associated with that TCP session if resources permit.
3283.3.2. Sending Responses
330 A DNS server that receives a query sent using TCP transport that
331 includes an OPT RR (with or without the edns-tcp-keepalive option)
332 MAY include the edns-tcp-keepalive option in the response to signal
333 the expected idle timeout on a connection. Servers MUST specify the
334 TIMEOUT value that is currently associated with the TCP session. It
338Wouters, et al. Standards Track [Page 6]
340RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
343 is reasonable for this value to change according to local resource
344 constraints. The DNS server SHOULD send an edns-tcp-keepalive option
345 with a timeout of 0 if it deems its local resources are too low to
346 service more TCP keepalive sessions or if it wants clients to close
347 currently open connections.
3493.4. TCP Session Management
351 Both DNS clients and servers are subject to resource constraints that
352 will limit the extent to which TCP sessions can persist. Effective
353 limits for the number of active sessions that can be maintained on
354 individual clients and servers should be established, either as
355 configuration options or by interrogation of process limits imposed
356 by the operating system. Servers that implement edns-tcp-keepalive
357 should also engage in TCP connection management by recycling existing
358 connections when appropriate, closing connections gracefully, and
359 managing request queues to enable fair use.
361 In the event that there is greater demand for TCP sessions than can
362 be accommodated, servers may reduce the TIMEOUT value signalled in
363 successive DNS messages to minimise idle time on existing sessions.
364 This also allows, for example, clients with other candidate servers
365 to query to establish new TCP sessions with different servers in
366 expectation that an existing session is likely to be closed or to
369 Based on TCP session resources, servers may signal a TIMEOUT value of
370 0 to request clients to close connections as soon as possible. This
371 is useful when server resources become very low or a denial-of-
372 service attack is detected and further maximises the shifting of
373 TIME_WAIT state to well-behaved clients.
375 However, it should be noted that RFC 6891 states:
377 Lack of presence of an OPT record in a request MUST be taken as an
378 indication that the requestor does not implement any part of this
379 specification and that the responder MUST NOT include an OPT
380 record in its response.
382 Since servers must be faithful to this specification even on a
383 persistent TCP connection, it means that (following the initial
384 exchange of timeouts) a server may not be presented with the
385 opportunity to signal a change in the idle timeout associated with a
386 connection if the client does not send any further requests
387 containing EDNS0 OPT RRs. This limitation makes persistent
388 connection handling via an initial idle timeout signal more
394Wouters, et al. Standards Track [Page 7]
396RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
399 attractive than a mechanism that establishes default persistence and
400 then uses a connection close signal (in a similar manner to HTTP 1.1
403 If a client includes the edns-tcp-keepalive option in the first
404 query, it SHOULD include an EDNS0 OPT RR periodically in any further
405 messages it sends during the TCP session. This will increase the
406 chance of the client being notified should the server modify the
407 timeout associated with a session. The algorithm for choosing when
408 to do this is out of scope of this document and is left up to the
409 implementor and/or operator.
411 DNS clients and servers MAY close a TCP session at any time in order
412 to manage local resource constraints. The algorithm by which clients
413 and servers rank active TCP sessions in order to determine which to
414 close is not specified in this document.
418 Many paths between DNS clients and servers suffer from poor hygiene,
419 limiting the free flow of DNS messages that include particular EDNS0
420 options or messages that exceed a particular size. A fallback
421 strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD
422 be employed to avoid persistent interference due to non-clean paths.
4243.6. Anycast Considerations
426 DNS servers of various types are commonly deployed using anycast
429 Changes in network topology between clients and anycast servers may
430 cause disruption to TCP sessions making use of edns-tcp-keepalive
431 more often than with TCP sessions that omit it, since the TCP
432 sessions are expected to be longer lived. It might be possible for
433 anycast servers to avoid disruption due to topology changes by making
434 use of TCP multipath [RFC6824] to anchor the server side of the TCP
435 connection to an unambiguously unicast address.
4374. Intermediary Considerations
439 It is RECOMMENDED that DNS intermediaries that terminate TCP
440 connections implement edns-tcp-keepalive. An intermediary that does
441 not implement edns-tcp-keepalive but sits between a client and server
442 that both support edns-tcp-keepalive might close idle connections
450Wouters, et al. Standards Track [Page 8]
452RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
4555. Security Considerations
457 The edns-tcp-keepalive option can potentially be abused to request
458 large numbers of long-lived sessions in a quick burst. When a DNS
459 server detects abusive behaviour, it SHOULD immediately close the TCP
460 connection and free the resources used.
462 Servers could choose to monitor client behaviour with respect to the
463 edns-tcp-keepalive option to build up profiles of clients that do not
464 honour the specified timeout.
466 Readers are advised to familiarise themselves with the security
467 considerations outlined in [RFC7766]
4696. IANA Considerations
471 IANA has assigned an EDNS0 option code for the edns-tcp-keepalive
472 option from the "DNS EDNS0 Option Codes (OPT)" registry as follows:
474 +-------+--------------------+----------+-----------+
475 | Value | Name | Status | Reference |
476 +-------+--------------------+----------+-----------+
477 | 11 | edns-tcp-keepalive | Standard | RFC 7828 |
478 +-------+--------------------+----------+-----------+
4827.1. Normative References
484 [RFC1035] Mockapetris, P., "Domain names - implementation and
485 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
486 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
489 Requirement Levels", BCP 14, RFC 2119,
490 DOI 10.17487/RFC2119, March 1997,
491 <http://www.rfc-editor.org/info/rfc2119>.
493 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
494 Rose, "DNS Security Introduction and Requirements",
495 RFC 4033, DOI 10.17487/RFC4033, March 2005,
496 <http://www.rfc-editor.org/info/rfc4033>.
498 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
499 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
500 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
506Wouters, et al. Standards Track [Page 9]
508RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
511 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
512 for DNS (EDNS(0))", STD 75, RFC 6891,
513 DOI 10.17487/RFC6891, April 2013,
514 <http://www.rfc-editor.org/info/rfc6891>.
516 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
517 Protocol (HTTP/1.1): Message Syntax and Routing",
518 RFC 7230, DOI 10.17487/RFC7230, June 2014,
519 <http://www.rfc-editor.org/info/rfc7230>.
521 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
522 D. Wessels, "DNS Transport over TCP - Implementation
523 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
524 <http://www.rfc-editor.org/info/rfc7766>.
5267.2. Informative References
529 Wouters, P., "Chain Query requests in DNS", Work in
530 Progress, draft-ietf-dnsop-edns-chain-query-07, February
534 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
535 and P. Hoffman, "Specification for DNS over TLS", Work in
536 Progress, draft-ietf-dprive-dns-over-tls-09, March 2016.
538 [fragmentation-considered-poisonous]
539 Herzberg, A. and H. Shulman, "Fragmentation Considered
540 Poisonous", arXiv: 1205.4011, May 2012,
541 <http://arxiv.org/abs/1205.4011>.
543 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
544 "TCP Extensions for Multipath Operation with Multiple
545 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
546 <http://www.rfc-editor.org/info/rfc6824>.
548 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
549 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
550 <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
562Wouters, et al. Standards Track [Page 10]
564RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016
569 The authors acknowledge the contributions of Jinmei TATUYA and Mark
570 Andrews. Thanks to Duane Wessels for detailed review and the many
571 others who contributed to the mailing list discussion.
578 Email: pwouters@redhat.com
583 103-186 Albert Street
587 Phone: +1 519 670 9327
588 Email: jabley@dyn.com
592 Sinodun Internet Technologies
598 Email: sara@sinodun.com
599 URI: http://sinodun.com
603 Internet Systems Consortium, Inc
605 Redwood City, CA 94063
608 Phone: +1 650 423 1200
610 URI: http://www.isc.org
618Wouters, et al. Standards Track [Page 11]